Why use a third party software Firewall?

wat0114 wrote:That's a pretty cool demo, although a firewall protecting the victim machine stops the exploit; no ip to scan so no exposed, vulnerable service to exploit.

I don't think that's the point of the demo though? The exploit could occur locally as well I think - just need the right "bug" to exploit and the right conditions etc.

And when you say firewall in this context, wouldn't a NAT Router or Windows XP's built-in firewall achieve the same thing?

ssj100 wrote:
I don't think that's the point of the demo though? The exploit could occur locally as well I think - just need the right "bug" to exploit and the right conditions etc.

And when you say firewall in this context, wouldn't a NAT Router or Windows XP's built-in firewall achieve the same thing?

My response was formulated on how that particular demo was performed, under its particular conditions. If someone demos another way of exploiting, then I would respond differently As for the firewall, sure, a NAT router or Windows fw would work fine.

A firewall won't do anything if the service is exposed (ie: the port is open). Well, not 'nothing' but not a whole lot. In the case of an outbound Firewall it's a matter of changing ports (you can loop through) or moving to a new program.

Regardless, the point is that this guy gets his shell in an XP service and from that shell is able to steal and relay information from the machine.

You can get valuable system information, user information, etc that can make access profitable and also allow for easier local exploitation.

That's why I don't think an AntiExecutable is worth using. Whether you use Firefox.exe to attack a system or payload.exe you can basically do the same things.

Hungry Man wrote:A firewall won't do anything if the service is exposed (ie: the port is open). Well, not 'nothing' but not a whole lot. In the case of an outbound Firewall it's a matter of changing ports (you can loop through) or moving to a new program.

If the service is exposed, right, but even the most rudientary firewall blocks all inbound connections to all ports by default. The attack as demonstated by the author fails outright if the victim's machine is protected by a default-deny firewall on incoming connections. Even in the MS Security Bulleting on the MS03-026 vulnerability in question:

Mitigating Factors

To exploit this vulnerability, the attacker would require the ability to send a specially crafted request to port 135, 139, 445 or 593 or any other specifically configured RPC port on the remote machine. For intranet environments, these ports would normally be accessible, but for Internet connected machines, these would normally be blocked by a firewall. In the case where these ports are not blocked, or in an intranet configuration, the attacker would not require any additional privileges.

Best practices recommend blocking all TCP/IP ports that are not actually being used, and most firewalls including the Windows Internet Connection Firewall (ICF) block those ports by default. For this reason, most machines attached to the Internet should have RPC over TCP or UDP blocked. RPC over UDP or TCP is not intended to be used in hostile environments such as the Internet.

-http://technet.microsoft.com/en-us/security/bulletin/ms03-026-

Regardless, the point is that this guy gets his shell in an XP service and from that shell is able to steal and relay information from the machine.

You can get valuable system information, user information, etc that can make access profitable and also allow for easier local exploitation.

No arguments from me about what this type of exploit can accomplish in a devastating manner if it's successful.

That's why I don't think an AntiExecutable is worth using. Whether you use Firefox.exe to attack a system or payload.exe you can basically do the same things.

In many cases a payload is dropped or downloaded (though obviously not this one), then executed, and this is where an AE can play a valuable role in stopping it. In the case of this very same MS03-026 exploit, the Blaster worm executed one or more of the follwing:

Msblast.exe, Nstask32.exe, Penis32.exe, Teekids.exe, Winlogin.exe, Win32sockdrv.dll, or Yuetyutr.dll in the Windows\System32 folder.

-http://support.microsoft.com/kb/826955-

I'm willing to bet an AE plays no trivial part against this attack and, of course, once again a firewall would prevent this worm from gaining a foothold in the first place.

You do mention a browser as the avenue of attack, and I don't deny this could be a possibility. However, in the event where an executable payload, even a dll, is involved, an AE could be a formidable defense against it.

EDIT

Clearly I need to be on the same page as you guys, so discussing executable payloads is perhaps not the right direction here, I guess. I don't want to go off on a tangent. Sorry about doing so. So it seems the question is: how to prevent shellcode from running through a vulnerable process, especially a browser? Hopefully this is the right question? Is this where javascript/scripting control can come into play? What about the merits of Chrome's sandboxed renderers? Firefox' NoScript plug-in? I watched another of the author's videos on the same exploit very closely and see he queues up the payload: shell_bind_tcp, and then later adduser. Are these payloads scripts or executables? Can they be stopped from running through a vulnerable process such as Firefox.exe or Chrome.exe?

In many cases a payload is dropped or downloaded (though obviously not this one), then executed, and this is where an AE can play a valuable role in stopping it. In the case of this very same MS03-026 exploit, the Blaster worm executed one or more of the follwing:

Msblast.exe, Nstask32.exe, Penis32.exe, Teekids.exe, Winlogin.exe, Win32sockdrv.dll, or Yuetyutr.dll in the Windows\System32 folder.

-http://support.microsoft.com/kb/826955-

I'm willing to bet an AE plays no trivial part against this attack and, of course, once again a firewall would prevent this worm from gaining a foothold in the first place.

Sure. An AE absolutely would stop all of those and pretty much almost anything you're likely to encounter.

But I could implement 1bit of ASLR in a program and any exploit that doesn't take it into account will fail. That 1bit is not security though - it's virtually useless since it can be bruteforced quickly and reliably.

You do mention a browser as the avenue of attack, and I don't deny this could be a possibility. However, in the event where an executable payload, even a dll, is involved, an AE could be a formidable defense against it.

What's key here to understand is that any attack where an executable payload would be used can just as easily be an attack from within a compromised process. So yes, an AE is a defense against attacks that don't pay attention to AEs but any attack can be modified to bypass one.

So it seems the question is: how to prevent shellcode from running through a vulnerable process, especially a browser?

If there were an answer here one of us would be very rich. Preventing remote code execution vulnerabilities isn't really possible with current technology (languages would have to change and even then...).

Is this where javascript/scripting control can come into play? What about the merits of Chrome's sandboxed renderers? Firefox' NoScript plug-in?

Blocking Javascript is something that would prevent the exploit in teh first place. The Javascript renderer is typically what's going to be exploited (And why Chrome removes all rights from it). The Chrome sandbox assumes the renderer will be exploited because it's exposed to so much so it removes all rights, which won't prevent shell (it can but that' sless relevant) just contain it.

I watched another of the author's videos on the same exploit very closely and see he queues up the payload: shell_bind_tcp, and then later adduser. Are these payloads scripts or executables? Can they be stopped from running through a vulnerable process such as Firefox.exe or Chrome.exe?

Shellcode is assembly code (just like your browser, which was written in some langauge like C++ and then compiled to ASM) and it's executable - hence the name Remote Code Execution. Chrome and Firefox basically contain address space filled with code, an attacker gets some of their code in there and through some tricks they get it to be executable. If the shell never leaves the Firefox or Chrome process and you end that process you kill the shell.

Very interesting topic This strengthens my resolve to stick with Chrome, especially in Linux and Apparmored, for the foreseeable future, and to see what the upcoming IE10 has to offer.

In all, it seems anyone using an updated machine, EMET properly configured, and a good browser like chrome or perhaps FF w/NS is not going to be exploited trivially if an exploitable process is discovered and not yet patched. Still, I can appreciate an appreciable window of opportunity exists against those just running a "mainstream" setup, lagging behind in updates, using IE and no firewall. There's always easy pickings for the attackers.

EMET's use is severely hindered due to a few well known full ASLR bypasses. The Anti-ROP really help out here but those are bypassable as well.

Basically EMET's amazing but it's limited by Windows' terrible ASLR.

Linux doesn't have the same issue AFAIK - there are no universally static areas of address space. And ASLR isn't 'Opt In' like on Windows, only PIE is, otherwise ASLR is enabled.

I would say Firefox with NoScript is difficult to beat but when you whitelist a website any exploit *actually hosted on the page* will work fine. It'll protect you from XSS and Clickjacking but that's all - after a whitelist the exploit will run if it's hosted directly on the page you whitelisted.

IE10 is interesting. They're using the Appcontainer sandbox - but so is Chrome.

I know it's MS, but in their latest Security Intelligence Report, shellcode and heapspray look to be at the bottom of the Exploit report list, if indeed it's the same type discussed here. Not suggesting it's a non-factor, only that it must mean something significant as to why it's hardly prevalent in the malware world. The little bit of research I did on shellcode (most of it's far above my level of understanding because I'm not a programmer), suggests that it's not easy to write a successful shellcode that exploits a vulnerable process. But then again, once it's written and proven successful, it's made readily available on the Internet for any aspiring hacker. Isn't the most common type also the download & execute shellcode, or drive-by download code, whereby it instructs the victim's machine to download and execute a payload? This is apparently the usual case if a browser vulnerability is exploited. In this case, an AE would certainly help a great deal.

BTW, it looks like XSS is a rapidly growing security concern.

I can go into that a bit.

1) Heapspray is a method to bypass ASLR. There are *much* easier ways to bypass ASLR on Windows due to flaws in the implementation. Basically there's a part of every processes address space that's always static on Windows - it sucks. I can give more details on this if you'd like I just have to find some more info since I can't remember the exact address off the top of my head.

2) Shell code is used in most exploits, but it's only used to initially launch the payload. In the case of Java there is no shell, just an attack that allows unsigned code (class files etc) to run.

Shell code is *always* used when it comes to buffer overflow attacks. At that point the attacker loads their code into RAM (memory, where the virtual address space of a program lies) and can do what they want. What they usually do is use that shellcode to start a download and then launch the payload.

The reason they do this is because malware is a business. Being able to customize the payload on a per-customer or per-page basis is ideal for selling exploit kits.

So, yes, the usual case of an exploit is blocked by a payload.

What you have to ask is how difficult a new case would be by comparison. The answer is, essentially, not at all.

XSS is kinda scary for various reasons but there are defenses. Chrome's Content Security Policy for extensions pretty much wipes the floor with XSS. The site isolation policy (in development) can make things harder too.

Hungry Man wrote:Chrome's Content Security Policy for extensions pretty much wipes the floor with XSS.

Didn't know that even existed and just now read up a bit on it. Very nice