Outbound Firewalls Require HIPS

There is a reason why almost any major Firewall that uses outbound filtering also pairs with a HIPS component. It is trivial to bypass an outbound firewall without it. Why, you ask? Because Windows does not separate programs that are all running under a single user account – if you’ve got Pidgin open, and you’ve got Firefox open, they may run in a separate address space but they are not isolated from each other.

You need the ability to call exactly two calls from kernel32 in order to bypass a plain, unassisted outbound firewall – CreateRemoteThread() and LoadLibrary().

CreateRemoteThread() is a lot like it sounds, you call it, you pass it a handle, security descriptor (lol if you’re pre-SP2 XP, this’ll get you!), stack size, blah blah blah, the address to load it, and the code you want it to execute. Yes, you read that right! You can have your code executed by another process with a single call. Process A calls CreateRemoteThread() and it can create that thread in Process B.

In this case we would be pointing to the LoadLibrary() function, and pass that function the path too our .dll file.

At this point the .dll file, which holds our code, is loaded into whichever process we like (as long as we share a UID) and we control that process.

This is why a HIPS component will be like “Hey, they’re trying to load a file into this other process” or “Hey, they’re trying to create a thread in this other process” and stop it. Without that specific check the outbound firewall is useless.

Now, of course, even with that check I’d be wary of an outbound firewall. And of course the user has to actually answer those popups correctly… but you see that at least with a HIPS component it’s not bypassable in 10 lines of code.

0-Day Exploit Bypasses Adobe Reader Sandbox

A youtube video demonstrates an attack against Adobe’s PDF Reader – something that used to be completely mainstream, boring. But what makes this interesting is that it also bypasses the Adobe Reader sandbox, based on the sandbox used by Google Chrome, and the exploit doesn’t rely on Javascript.

Adobe Reader implemented a sandbox of similar architecture to Google Chrome, using a low integrity process to handle untrusted code and a broker process to make security decisions. This attack bypasses the Adobe Reader sandbox entirely and, unlike most Adobe Reader exploits, doesn’t require JavaScript to work.

Attacks like this are likely to become more common. As programs make use of sandboxes it becomes necessary for attackers to break out of those sandboxes to further monetize the system.

Adobe Reader has always been a popular program to exploit due to the nature of PDF and the popularity of the software. It seems attackers aren’t giving up just because of a sandbox, though it’s clear that the Adobe Reader Sandbox has reduced attacks in the wild.

The exploit, which is being sold on the black market for 30,000-50,000 dollars is already incorporated into the popular Blackhole Exploit Kit. Blackhole Exploit Kit is a very popular way for attackers to distribute malware such as Zeus (a popular piece of malware that steals bank info) so it’s best to be wary while opening PDFs until a patch is out.

For protection against this exploit I suggest setting up EMET. Click here to read how.


Update: Adobe is now in contact with Group-IB and hopefully there will be a fix out soon.

Another Universal ASLR Bypass Demonstrated

I’ve talked about ASLR issues in the past due to Windows/Linux implementation issues. It’s become more common to see these issues get exploited lately, though still surprisingly few times.

The most recent bypass was with Adobe Reader X and you can read about it here.

Basically some address doesn’t get randomized (VirtualAllocEx maps don’t randomize for some reason) and so they can insert their own ROP code.

There is no way to solve this without Windows picking up slack and randomizing more areas of address space/ specific calls (ie: what PaX does for mmap() base addresses and the hardened toolchain.)

Thankfully this shouldn’t bypass the Reader sandbox and it should be avoidable without Javascript enabled. EMET users are also safe against ASLR bypasses because they’ll benefit from EAF, though EAF is trivially bypassed.

A reminder that implementation flaws in something like ASLR are still around today even though it’s been years since PaX demonstrated the technique.

This vulnerability is pretty interesting and actually makes use of an issue in the sandbox having to do with the IPC handling of syscalls. For more on that you can read the actual post. While the way the sandbox is handled provides an avenue of attack the fault here is most definitely on Windows.

Trusted Path Execution And AntiExecutables

A user commented on my guide for compiling the Linux kernel with Grsecurity and PaX patches and brought up Trusted Path Execution. I somehow missed this feature and I’d like to comment on what it does because it’s relevant to a conversation on another forum about Anti-Executables. So I’m going to look at  TPE and go a bit more in depth about why I don’t find AntiExecutables to be useful for home users.

TPE is, essentially, an antiexecutable. There are three options:

  1. Partially restrict all non-root users.
  2. Invert GID option.
  3. GID for (un)trusted users.

1) Partially restrict all non-root users

Essentially this option stops a program of user ID X from executing a file owned by user ID Y. If a file is owned by root and only root can write to the file that file can be executed.

It seems like a fairly cool feature. What I like is that it enforces a consistent policy – the program that downloads the file is the program that can execute the file. It makes sense and it doesn’t get in the way as this behavior it enforces is the typical behavior a user should observe.

2) Invert GID option

The Invert GID Option changes the ‘GID for untrusted users’ into ‘GID for trusted users’ ie: it flips from a blacklist to a whitelist.

3) GID for untrusted users

Essentially if the GID is set to X then X can’t execute any files. If 2) is set to * and it’s really GID for trusted users then only X can execute files.

I Don’t Like AntiExecutables

Antiexecutables are fine for enforcing policies in the work place. If an IT Admin decides users can only install Word and Adobe Reader they can use an AE to enforce company policy via software policy. It’s great for this because the user does not own the machine and can not bypass the policy.

On a users machine the user is the boss, not the AntiExecutable. They can bypass these restrictions easily.

In neither of these situations is the AntiExecutable stopping an exploit from being successful. An attacker can do just about anything they’d like from a “RAM-Only” attack (ie: a remote code execution that never drops a separate executable file) as they can by writing to the disk. When you drop a shell into Reader.exe you inherit all rights of Reader.exe because you are Reader.exe – you live in that processes address space. So if Reader.exe can create a startup entry then, surprise surprise, so can you. And there’s your persistence since so many people believe that persistence is not possible if one uses an AntiExecutable (the issue of persistence can be more complex depending on the policy, but in my opinion if you’re relying on any traditional AE on its own persistence won’t be difficult to achieve).

An AntiExecutable doesn’t really make things much harder for an attacker. The way attacks typically work now is that you get shell and then you download and execute a new program. This is great because you can switch up your exploit and keep the same payload or you can switch up the payload and keep the same exploit. Either way, it makes things more flexible from a managerial standpoint and does virtually nothing to make things more difficult from an attack standpoint.

Again, if a clean program can do it the hacker who exploits that program can do it. If reader.exe can write to /path/to/x so can the attacker.

And this is why I wouldn’t bother with anything too crazy with AntiExecutables. I think the ‘Partially Restrict All Non-Root Users’ is great because it reinforces some common sense policy. That’s as far as I’d be willing to go – it does not really add significant security, hackers can do it all in RAM from their initial RCE.

On a server you don’t need flexibility and piling on security is basically the best thing you can do. Go ahead and use an AE – use anything, really. If you’ve got a Sys Admin sitting there watching logs then seeing access violations through the TPE could be a really strong indication that you’re being attacked. I leave that to the IT’s judgement here.

As a user you do need flexibility and convoluted policy can even make you less secure. You open yourself up to social engineering (yes, there are different levels of vulnerability here and different programs make you more or less vulnerable) and you complicate your setup. I don’t think TPE is really going to hurt you (especially the partial restriction) but it can be annoying without any real reason for use as a user.

Personally I’ll be using the partial restriction. Why? Not because I think it’s really making me a whole lot more secure… purely to see if it gets in my way and kind of a ‘well I may as well’ thing. I rely on the other security measures in Grsecurity to keep me safe and there are more than enough features in that patch to do so.

So, the conclusion here is simple, if you’re on a server pile it on. If you’re a user just use the ‘partially restrict all non-root users’ option. And, above all else, remember that neither of these should be relied on.

Edit: And as Brad Spengler (creator of Grsecurity) aka Spender has noted there are multiple other techniques implemented by Grsecurity that work with TPE to create a strong system. Grsecurity is obviously a very powerful set of patches and TPE is only one of many features.

Why I Like AppArmor More Than SELinux

AppArmor and SELinux are two of the Linux Security Modules that can be used for fine grained mandatory access control. They both try to accomplish very similar goals but AppArmor is widely considered to be easier to use (and, really, it is) and SELinux is widely considered to be more fine grained.

Bypassing AppArmor

AppArmor is pathbased by nature, which means that it doesn’t know what “pidgin” is it knows what “/usr/bin/pidgin” is. Because of this all AppArmor profiles deny mount and namespace access because they can obviously lead to a bypass.

AppArmor doesn’t limit IPC in any way (DAC handles it) once granted so while “pidgin” may not be able to access a file it may be able to manipulate another process into doing so.

I don’t think there’s been a remote bypass of AppArmor in ages and because AppArmor can actually prevent exploits in the first place (with proper profiles) it’s really very strong.

Bypassing SELinux

SELinux allows for an even tighter sandbox than AppArmor without the restraints of mount/ namespaces because SELinux isn’t name based.

I don’t think there are any inherent weaknesses or limitations of SELinux worth mentioning and, as with AppArmor, there hasn’t been a remote bypass in a long time.

So SELinux is also very powerful.

So What’s The Real Difference?

Often times if one is bypassable the other is. SELinux is truly the more secure option in terms of limiting a process but what comes with that is a very complex policy. An SELinux policy can be a dozen times longer than an apparmor policy and it’s definitely not as user friendly both in terms of readability and configuration. So while SELinux is ideally much more secure they both provide a really high level of security and AppArmor is way easier to apply.

In Other Words…

They’re both incredibly secure but AppArmor is far easier to audit because of the simplicity. I respect that a properly configured SELinux profile is potentially much stronger than a properly configured AppArmor profile but if I can’t audit the policy I can’t verify the policy and that’s important.

I would rather run my system with every damn thing locked under AppArmor because I’m able to write the profiles myself than run a system with a few programs under SELinux written by someone else that I can’t properly audit because the policy is just convoluted.

This isn’t “AppArmor is better than SELinux” at all. I’m not saying that SELinux is weaker or worse. I’m saying that for me, personally, I’ll take AppArmor because having an easy to use security tool feels more secure to me than having a hard to use one. And I like RBAC too but it’s outside of the scope here – I will say that RBAC is really easy to audit and set up.