Efficacy of different setups at containing a userspace attack on Windows XP SP3

First off, this is not intended as an instructional post. Seriously, don't take anything I say as necessarily accurate. If you actually intend to try and secure a legacy OS, you do so at your own risk, and against my advice. If you keep running Windows XP on your desktop, and get burned, don't blame me; I told you it was a bad idea, okay?

Now that that's out of the way...

This is basically intended as a less biased, and hopefully less inflamatory, continuation of my earlier tests with Metasploit. What I'm lookin at is how effective different programs and setups seem to be at containing a successful userspace exploit. I'm using a legacy system (Windows XP SP3, no further updates) on the target VM so that said exploits are plentiful and reliable, not because I think there's anything cool about it.

Anyway, I'll start where I left of, with Geswall...

 

Geswall 2.9.2
Setup: allow Geswall to isolate IE6, and point the browser at the Aurora exploit.

Results...

- Keylogging fails.
- Screenshot fails.
- Attempts to execute programs are intercepted, resulting in a query popup.
- All attempts to escalate privilege in userspace are unsuccessful.
- Kernel font rendering exploit once again triggers an OS crash, and is unsuccessful. I think this may be a Metasploit bug, as I've been unable to get the font exploit to work with anything thus far.
- Viewing other processes is rather limited.
- Code injection into unsandboxed processes fails.
- Migration into unsandboxed processes fails.
- No tokens are stealable (or visible for that matter).
- Attempting to view the contents of the "Confidential" folder does not work, unless specifically allowed by the user. The query popup's wording is a little confusing, but it basically works.

 

PrivateFirewall 7.0.30.2

Setup:
- Process monitor to medium
- New process detection off
- Network settings to high
- Internet Explorer filters set to "deny" wherever applicable. (Only "Set hooks" and "Write protected registry area" are allowed.)
- IE is pointed to Aurora exploit page.

Results:
- Exploit succeeds
- getsystem() succeeds, granting SYSTEM privileges; but IE still cannot execute anything
- Cannot inject code into any process
- Cannot migrate to any other process
- Cannot steal tokens
- Cannot log keystrokes
- Cannot take screenshots
- Privileges are limited as SYSTEM user, e.g. I cannot download or upload files, or even enumerate files in the administrator's home dir
- But I can still upload, download, and otherwise manipulate files when running as the administrator

Comments:

This is a different setup than I used earlier with HIPS software, and overall it seems much more effective. It looks like HIPS are best used in the same fashion as e.g. an AppArmor sandbox; i.e. limiting the damage that can be inflicted by specific threat-gate applications, rather than as an anti-executable, or attempting to restrict the whole system.

 

Geswall

 

Happy to have a licence of Geswall Pro Edition (purchased two years ago)!

 

Keep in mind though that Geswall itself seems to be unmaintained. Vulnerabilities in its driver may become known at some point down the road. Personally I'd stick with Sandboxie at the moment.

 

Gullible Jones, the great question is: and AppGuard ?

 

Christmas Wish List 2013

GesWall for 64bits!

PrivateFireWall to finally install in Windows 8 instead of Ndis.sys error.

 

All make think that it is discontinued.

 

Yes but the owner of source code might change his mind. GesWall is Awesome!

 

That are interesting tests. Thnx for sharing results. Are you planning to test some other applications?

 

Funny, I just started testing that.

Blue Ridge Appguard

Setup:
- Appguard is installed and set to "Locked Down" status (that was easy)
- IE is pointed towards the Aurora exploit page

Results:
- Aurora exploit succeeds
- Executables can be started
- Files can be manipulated and viewed freely in user's home dir, but not outside it
- Payloads can be injected into spawned processes, but not other processes running as the same user, or as different users (access is denied by blocking memory allocation)
- Migration to other processes is blocked (unless they're spawned by the compromised process)
- Tokens cannot be stolen
- Keylogging works via winlogon (but not through Explorer)
- Screenshot works
- All password hashes are accessible
- Users' passwords can be changed (via 'net user')
- Persistence can be established via a system service
- getting SYSTEM privileges works
- Exporting the C: drive as a network block device works (though I don't have the software to verify the device's readability)
- Setting up a user for RDP access, and enabling said access, works
- Processes can be killed freely (even without SYSTEM privileges)
- However, Appguard's service cannot be killed

And just for fun...
- ppr_flatten_rec kernel vulnerability works
- But Appguard still cannot be killed after the privilege escalation. Nor can I inject code into it (memory allocation is once again denied), or migrate to it.
- Still can't migrate to other processes, etc.
- Can steal tokens but can't seem to do anything with them

Comments:
Implements rather weak MAC, something like Biba style IIRC. Not bad, but not good enough if you're running as admin. As with other HIPS, it won't prevent data theft from compromised users; or from anyone at all, depending on how far the attacker goes. The resistance to being killed/compromised by highly privileged processes is curious, but persistence can be established easily enough; and if the attacker has a kernel exploit, all bets are off.

On a final note, the one thing that really impressed me about this product is the lack of interactivity. It's the only HIPS I've seen so far that I'd consider suitable for end users... That at least is something. I wouldn't give it a snowball's chance in hell against an APT though.

 

Could you test DefenseWall, please?

 

Defensewall shall be next.

(Give me some time though. I have to un-root the XP virtual machine first.)

 

@Gullible Jones

No offense, but have you put IE in the guarded apps? Also, AppGuard can prevent data theft if you put your personal folder in the private folder setting and set it to "deny access".

 

Very interesting and reassuring, as a PF user.

There is one more thing that can be done to restrict an application with Private Firewall: In Settings> Advanced> Detected Applications> Processes, right click on the app's name and select 'Limited'. It will restrict permissions for that program as if it were on a limited user account. It's not the same thing of course, using a limited account gives always stronger protection.

 

@GrafZeppelin: No offense taken.

IE is guarded by default. I didn't notice the private folder though. Let's run that part again...

@vojta: don't be too reassured, an attacker can still grab your files.

 

I don't worry about that. My computer is very boring. Lol.

 

Okay, Appguard blocks access to the private folder not just as SYSTEM, but even after a kernel exploit. Very impressive, I wonder how they do that.

[Edit: N/M, I did flub the kernel exploit; Appguard has to be unhooked first, which I neglected to do. Props to Hungry Man for pointing this out.]

It still doesn't quite work though. Once I have persistance via a system service, I can look at the private folder's contents without trouble.

 

Defensewall HIPS

Setup:
- Install the thing
- Make sure IE is set as untrusted
- Point IE to Aurora exploit page

Results:
- Aurora exploit succeeds
- Can spawn applications, but not migrate to them (and the shell session gets killed when trying ) Also the processes seem to be in some kind of filesystem sandbox.
- Cannot inject payloads into apps running as the same user (access denied, can't attach to process)
- Screenshot comes out completely blank.
- Keylogging fails with Explorer
- Secured files and folders are inaccessible. Others can be downloaded, but not deleted, and uploads get tagged as untrusted.
- Tokens can't be seen or stolen
- getsystem() results in the shell session getting killed.

Okay, now the heavy stuff:
- ppr_flatten_rec kernel exploit fails because Notepad's attempt to make an internet connection gets blocked. Oh, and the shell session gets killed. Clever!
- The Stuxnet kbdlayout exploit (MS10-073) fails. No, it doesn't crash the VM, it fails! because the malicious file created cannot be deleted.
- DropLNK attack fails.
- Can't get password hashes.
- Serving up C: as a network block device succeeds.
- Running PXExploit results in IE getting killed.
- Logging keystrokes with Winlogon works, but Defensewall notifies you that IE is logging keystrokes
- The AdfJoinLeaf kernel exploit fails due to inability to allocate memory properly.

Comments:
... Wow. I'm trying not to be biased here, but it seems as if the Defensewall developers have thought of everything. This product contains all manner of attacks, and stays a step ahead of ones it can't contain; and it does so with very little configuration. Impressive.

 

Nice set of results. Well done Ilya. Can't say I'm surprised... safe and secure on 32bit Windows with Defensewall

 

A comodo test.?

 

Maybe later. Done with this stuff for today.

 

@GJ,

maybe unintentionally, you of all people might be giving XP holdouts reason to continue with it

 

@wat0114: Maybe. But don't blame me if it backfires.

BTW, I found it interesting how Defensewall blocked the ppr_flatten_rec exploit, i.e. using its outbound firewall to intercept the connection. Evidently outbound firewalls are not so useless when used in conjunction with policy and/or COW sandboxing.