Explanation Of Browser Exploitation

It was requested that I give a plain English explanation of how an attacker compromises a browser. I’m going to try to give a lot of detail in some areas but I will leave specific things out in order to not confuse. Hopefully by understanding how programs are exploited readers will be better equipped to choose security programs.

The first step in an attack is getting the victim to hit some kind of content that an attacker controls. This is generally achieved by either hacking a legitimate site and waiting for the user to get there, or sending the victim a link and tricking them into clicking it. Those are not the only ways, nor are they mutually exclusive.

Attacks against a browser can potentially be in the JavaScript renderer, a piece of the browser that looks at the JavaScript code on a webpage. The attacker can slip in some malformed and malicious code that may do many things. One of those things may be to overflow a buffer set up by the renderer.

By doing this an attacker can write to data outside of the buffer, and overwrite some piece of code or data that will essentially give them control over the renderer process. This initial code that runs the necessary instructions to compromise the process is the stage one shellcode. All of these instructions are essentially manipulated instructions that already exist in the process, and an attacker calls them from the legitimate program (in order to bypass DEP) using ‘return oriented programming’ (ROP). ASLR randomizes the location of these usable instructions, which forces an attacker to search for them in some manner (information leak is the most reliable, or heap spray). Once an attacker knows the location of the instructions they can chain them (ROP chain) together to call various functions. There are tools to automate ROP chain generation, which means attackers have to do a lot less work.

Attackers will now typically (they could do it all from stage one through ROP) download their second stage shellcode into the victim browsers address space, and this shellcode will carry out some instruction, such as creating a connection to a remote server.

At this point an attacker has full control over the renderer process (in Firefox this is the same as the browser process, in Chrome it is separated into another process) and can execute code in the context of this process. They can make calls that download and execute payloads, or they can create new threads in separate process, or read a file, or write a file, etc. It is important to know that the attacker’s code is the renderer process – they are the same process, no new process has spawned, it’s all happening within the renderer.

If the attacker wants to they can now drop and execute their third payload (as is common), and this is where programs such as antiexecutables come in – very late in the game. Keep in mind that although an antiexecutable can potentially prevent this payload from executing, attackers have already compromised the process – they can enumerate processes in the system, hop control to another process, keylog, read/write to the file system and registry, they can even run local privilege escalation attacks long before they ever execute this final payload or touch the disk.

So as an attack continues the attacker gains more and more control over a process. Defenses that prevent attacks in stage 1 are ideal, and attacks that don’t kick in until stage 3 have to be very powerful to be effective.

One of the restrictions an attacker will come across is the space that they have to fit their shellcode, which is why, oftentimes, they simply drop the initial shellcode in and have it immediately pull down and execute the file payload. But the advantage to staged shellcode that waits before downloading that final payload is obvious – an attacker can gain significant information on the system, they can avoid forensic analysis, AV, AE, etc. But as most users make virtually no effort to secure their systems users of such products have gotten away with it by being a just-difficult-enough target relative to the rest of the world.

It’s important to note that attacks do not have to follow this patter. Java attacks are typically ‘sandbox escapes’, they run Java code on the system and then trick the Java Virtual Machine into running the code as a standard user, so there’s no shellcode, there’s just a malicious class file launching and running the malware directly. I didn’t go into information leaking, I really just talked about a very specific attack using a buffer overflow, and the focus was more to explain how staged shellcode works.

If something needs clarifying just let me know in a comment.

ExploitShield – Smart AntiExecutable

edit: I want this edit right at the top. ES has apparently stated that they have now (October ’13) added in stage one exploit mitigation techniques. They have provided zero documentation on how these techniques supposedly work. My verdict of ‘use EMET’ has not changed, and I suspect one of their techniques is quite similar to the one used in EMET.

Recently a program called ExploitShield by the start up Zero Vulnerability Labs made its way into the security market, offering to protect against a wide variety of exploits. Just the other day it was purchased by Malwarebytes and rebranded as Malwarebytes AntiExploit. I find MBAM to be one of the best antiviruses, and I understand why something like ES would appeal to them, but I don’t see ES as being such a boon to security.

ExploitShield is essentially a “smart antiexecutable”, though they wouldn’t call it that. It actually has very little to do with exploits, and it certainly doesn’t prevent them. Instead it attempts to detect the exploit, and then prevent any new payloads from executing. This is nice, compared to a regular AE, because it’s not so stupidly overbearing. But just like an AE the attacker already has full remote code execution once they get shell, and the defense takes place too late in the game.

ExploitShield does not prevent exploit (despite its name)s, it does not make vulnerabilities more difficult to exploit. What it does is it attempts to detect exploits in various ways, and then, based on that detection, it decides if the ‘shielded’ program should be allowed to execute a payload.

My real issue with ExploitShield is that it actually doesn’t do anything to prevent exploits. It detects them, and then takes basically a single measure against them, preventing their final payload from executing. This is not nearly comprehensive enough. Until the recent merger with MBAM ExploitShield claimed to prevent Advanced Persistent Threats, or APT. APT is basically an attack in which an attacker is dedicated to defeating your system, and has some knowledge of the mechanics behind your security policies. An attacker with knowledge that you are running ExploitShield would tear through it. All of the 0days that work without ExploitShield work with ExploitShield the only thing an attacker has to do is change how they execute the payload.

How I would bypass ExploitShield is creating a buffer in memory, and using reflective DLL injection (optional, just to avoid AV detection, and forensics). I’d load that DLL into another process (AFAIK ExploitShield does not hook CreateRemoteThread()) and then execute it in the context of another, unshielded process, or really any process, shielded or not, because it won’t detect an exploit in Pidgin if I exploited Firefox. The details are a bit more complex, if they detect process ID enumeration, or one of the other steps, that’s that. But I think with just a bit of extra ROP you can prevent their detection.

I’m sure there are many other ways to bypass ExploitShield. For example, I could drop my payload and not execute it, and then, from shell, write a startup entry to the Windows registry. The user reboots at some point, the startup entry activates, and there you go.

I haven’t tried these things, but I’d like to. I’ve been meaning to write a POC “malware” to bypass AV/AE/ES for a while now, and I have the framework written out, I just have to get around to it. Either way, whether these specific bypasses work, or if there’s some tiny flaw, I am certain that, by design, ExploitShield is not going to protect you from exploits, only their payloads.

I take issue with a product saying it prevents something when it doesn’t. All it does is detect specific traits that exploits can leave behind.

A semi-formal review of ExploitShield came out, in reaction to the way-too-positive reviews from journalists who don’t know what they’re talking about, and it wasn’t exactly positive (read it here). The response from ZeroVulnerabilityLabs was to pick out a specific part that was wrong (having to do with detection) and state that that’s not how it works – they don’t say how it works, just that it’s different. Of course the method of detection is irrelevant and the real issue is that it’s simply hooking a few functions and trying to detect exploits when they’re called.

The post details that ExploitShield is fundamentally not about exploits, and that they are misusing the term.

It is my belief that when ExploitShield uses the term ‘exploit’, they really mean ‘payload’.

ExploitShield is great if the attacker doesn’t know it’s there, and, isn’t globally represented enough to be a problem in the large for an attacker. If the attacker knows it’s there, and cares, they can bypass it trivially.

Enough said? Well, not really. The author goes on to discuss other issues, but I don’t feel the need to.

I like Malwarebytes, and I find it to be the best antivirus. They’re a legit company, and maybe they’ll turn ExploitShield into something legitimate as well. But until then I don’t see its use, it just seems like extra attack surface.

If you want a real anti-exploit program, use EMET. It actually prevents exploits, or mitigations stage 1/2 payloads (as opposed to stage 3, which is the final executable) and prevents an attacker from ever getting shell access.

I wish I could write something nicer, because I do like MBAM, but I really dislike products with misleading names. Since the takeover they’ve removed the nonsense about preventing APT, but the name “ExploitShield” is making people ask “Do I still need EMET?” as if they do the same things. It’s a disservice to your customers when they don’t understand your product.

Keep in mind that I began writing this quite some time ago, and only published it recently. In all of this time MBAE may have changed, and they certainly claim to have done so. While I consider their flaws to be somewhat inherent to the design, I can’t confirm that everything I say here will always remain true, and until I perform an in depth reverse of their product I can not claim anything about how they are right now and only how they were in the past. This isn’t to say that I believe they are suddenly incredible, or worse, or anything – but people seem to have some issue so yeah, there’s your little disclaimer.

Microsoft’s Security Bounty Program

Microsoft has revealed details on its new bounty program for security research. Unlike a typical bounty program that just pays a researcher for finding a specific vulnerability, Microsoft is offering rewards for a broader range of attacks on mitigation techniques.

  1. Mitigation Bypass Bounty. Microsoft will pay up to $100,000 USD for truly novel exploitation techniques against protections built into the latest version of our operating system (Windows 8.1 Preview). Learning about new exploitation techniques earlier helps Microsoft improve security by leaps, instead of capturing one vulnerability at a time as a traditional bug bounty alone would. TIMEFRAME: ONGOING
  2. BlueHat Bonus for Defense. Additionally, Microsoft will pay up to $50,000 USD for defensive ideas that accompany a qualifying Mitigation Bypass submission. Doing so highlights our continued support of defensive technologies and provides a way for the research community to help protect more than a billion computer systems worldwide.TIMEFRAME: ONGOING (in conjunction with the Mitigation Bypass Bounty).

As you can see the focus isn’t about specific vulnerabilities, it’s about hardening mitigation techniques to prevent entire classes of vulnerabilities. A mitigation technique, such as DEP, prevents direct code execution. Another technique, ASLR, makes bypassing DEP more difficult by preventing Return Oriented Programming.

Flaws in these techniques can lead to bypasses, and these bypasses can be used across vulnerabilities, and therefor have a much larger impact.

Microsoft has done this before. In the past their rewards program has led to a series of new “Anti-ROP” techniques in the EMET program. Improving and adding to these techniques drives up the cost of every exploit.

Microsoft is also paying out for Internet Explorer 11 vulnerabilities:

  1. Internet Explorer 11 Preview Bug Bounty. 
    Microsoft will pay up to $11,000 USD for critical vulnerabilities that affect Internet Explorer 11 Preview on the latest version of Windows (Windows 8.1 Preview). The entry period for this program will be the first 30 days of the Internet Explorer 11 beta period (June 26 to July 26, 2013). Learning about critical vulnerabilities in Internet Explorer as early as possible during the public preview will help Microsoft make the newest version of the browser more secure. TIMEFRAME: 30 DAYS

IE11 is available on the Windows 8.1 Preview, and Microsoft is hoping that researchers can help break into it so they can gauge security. While solving individual vulnerabilities does not exactly add much to security, it does help developers behind IE11 see where attackers will go. If I were an IE11 developer, and I got a response from a dozen developers showing that they could break into my program through the Javascript Renderer, I’d know that I needed to really focus on securing that component, because it’s likely the easiest spot to attack. So while those patches themselves may not be making the program much more secure, the knowledge I gain from viewing trends will.

I’d like to see more bounty programs like this, but Microsoft is in the best position for it – a browser can’t always do much about mitigation techniques, as they have more to do with the operating system and compilers. I think a lot of good will come from this program.

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.

Security Software Usage Of Mitigation Techniques With Slopfinder

I recently read a post that used static analysis of executable files to see which applications were using DEP/ASLR and to what extent. This inspired me to perform the same analysis with the same tool, but on security software.

Antivirus software runs with very high privileges on a system, and it deals directly with malicious, attacker controlled code. Ensuring that modern mitigation techniques are enabled is essential when designing security software, as your code is inherently exposed to an attacker. In other words, the code here should be held to the highest standard. A

nalysis performed in a Windows 8 64bit VM using slopfinder in Chrome Stable. Slopfinder is a tool that performs static analysis on executable files to check their security flags, whether or not they make use of DEP / ASLR.

Using Slopfinder is as simple as dragging/ dropping a folder full of executables and then looking through the results, which is what I’ve done here.

Default installations – trial software used if available for Pro versions. Some of these programs install “web guards” that are actually glorified Ask Toolbars or some other BS toolbar- these are included in results, they’re part of the ‘security’ package and they’re entirely relevant.

If I don’t specify DEP/ASLR it means both are disabled. This is the case for the majority, which I’m assuming has to do with ‘permanent’ DEP, as I’d be very surprised if DEP were really disabled so frequently – but who knows! UPDATE: Here is an explanation for the DEP.

Keep in mind that just because some files don’t support ASLR or DEP doesn’t mean you’re vulnerable. Some of these files won’t ever interact with ‘attacker code’ – there’s little reason for program uninstallers to support ASLR, for example, and the same goes for installers.

If anyone has more information to add (for example if one of these offending DLLs is particularly critical, like if it’s loaded into the browser) I’ll happily add it in.

Microsoft Security Essentials/ Windows Defender

I found no executable files not compiled with DEP/ASLR.

Avast! Pro Trial (25)
















/Avast/Setup/INF/aswTdi.sys /





















Avira Premium Trial + Toolbar (41)







/AntiVir Desktop/aecore.dll

/AntiVir Desktop/aeemu.dll

/AntiVir Desktop/aeexp.dll

/AntiVir Desktop/aegen.dll

/AntiVir Desktop/aehelp.dll

/AntiVir Desktop/aeheur.dll

/AntiVir Desktop/aeoffice.dll

/AntiVir Desktop/aepack.dll

/AntiVir Desktop/aerdl.dll

/AntiVir Desktop/aesbx.dll

/AntiVir Desktop/aescn.dll

/AntiVir Desktop/aescript.dll

/AntiVir Desktop/aevdf.dll

/AntiVir Desktop/avacl.dll

/AntiVir Desktop/avevtrc.dll

/AntiVir Desktop/aebb.dll

/AntiVir Desktop/libapr-1.dll

/AntiVir Desktop/libapriconv-1.dll

/AntiVir Desktop/libaprutil-1.dll

/AntiVir Desktop/libdb44.dll

/AntiVir Desktop/rchelp.dll

/AntiVir Desktop/unacev2.dll

/AntiVir Desktop/FAILSAFE/aebb.dll

/AntiVir Desktop/FAILSAFE/aeemu.dll

/AntiVir Desktop/FAILSAFE/aeexp.dll

/AntiVir Desktop/FAILSAFE/aegen.dll

/AntiVir Desktop/FAILSAFE/aehelp.dll

/AntiVir Desktop/FAILSAFE/aeheur.dll

/AntiVir Desktop/FAILSAFE/aeoffice.dll

/AntiVir Desktop/FAILSAFE/aepack.dll

/AntiVir Desktop/FAILSAFE/aerdl.dll

/AntiVir Desktop/FAILSAFE/aesbx.dll

/AntiVir Desktop/FAILSAFE/aescn.dl

/AntiVir Desktop/FAILSAFE/aescript.dll

/AntiVir Desktop/FAILSAFE/aevdf.dll

/AntiVir Desktop/FAILSAFE/aecore.dll

AVG Internet Security Pro (27)

/AVG Secure Search/

/AVG Secure Search_toolbar.dll (Browser componnent it would seem)

/AVG2013/HtmLayout.dll (Also possible browser component)

























McAfee All Access – Total Protection (14)

Note: McAfee became increasingly unstable on my system. I uninstalled it before I could analyze the Chrome extension that it installs.



/McAfee Online Backup/MOBKbackup.exe

/McAfee Online Backup/MOBKconf.exe

/McAfee Online Backup/MOBKshell.dll

/McAfee Online Backup/MOBKstat.exe

/McAfee Online Backup/backup.dll

/McAfee Online Backup/oem.dll

/McAfee Online Backup/MOBK.sys

/McAfee Online Backup/librs2.dll





Norton (17)

/Norton 360/Engine/

/Norton 360/Engine64/

/Norton 360/Engine64/

/Norton 360/Engine64/

/Norton 360/Engine/

/Norton 360/Engine64/

/Norton 360/MUI/

/Norton 360/Branding/ NO ASLR

/Norton 360/Engine/

/Norton 360/Engine/

/Norton 360/MUI/ NO ASLR

/Norton 360/MUI/ NO ASLR

/Norton 360/MUI/ NO ASLR

/Norton 360/MUI/ NO ASLR

/Norton 360/MUI/ NO ASLR

/Norton 360/MUI/ NO ASLR

/2013.1.0.32_0/npcoplgn.dll NO ASLR (browser plugin)

Sophos Antivirus (No Firewall) (F-)

It doesn’t seem that any of the executable files support ASLR. Many do not support DEP as well, including quite a few that seem to interact with the web. When your “xmlparser.dll” doesn’t show DEP/ASLR support… yikes. There’s no point listing them all. Sophos gets an F- here.

Panda Cloud AV Pro (42)

/pandasecuritytb/pandasecurityDx.dll (Possibly part of the browser extension)

/pandasecuritytb/pandasecuritytb.dll (Possibly part of the browser extension)

/Toolbar Cleaner/ToolbarCleaner.exe


/Toolbar Cleaner/uninstall.exe

/Panda Security/Panda Cloud Antivirus/cc3290mt.dll

/Panda Security/Panda Cloud Antivirus/bcbie120.bpl

/Panda Security/Panda Cloud Antivirus/MiniCrypto.dll

/Panda Security/Panda Cloud Antivirus/PAV2WSC.exe

/Panda Security/Panda Cloud Antivirus/Pavsddl.dll

/Panda Security/Panda Cloud Antivirus/PSBoot.dll

/Panda Security/Panda Cloud Antivirus/PSBoot.sys

/Panda Security/Panda Cloud Antivirus/pskmad.sys

/Panda Security/Panda Cloud Antivirus/PSUAAlerts.dll

/Panda Security/Panda Cloud Antivirus/PSUNConsole.dll

/Panda Security/Panda Cloud Antivirus/PSUNCtrl.bpl

/Panda Security/Panda Cloud Antivirus/PSUNFwConfig.dll

/Panda Security/Panda Cloud Antivirus/PSUNMsg.dll

/Panda Security/Panda Cloud Antivirus/PSUNPnlConfig.dll

/Panda Security/Panda Cloud Antivirus/PSUNProcMon.dll

/Panda Security/Panda Cloud Antivirus/PSUNReports.dll

/Panda Security/Panda Cloud Antivirus/PSUNScan.dll

/Panda Security/Panda Cloud Antivirus/PSUNSuspects.dll

/Panda Security/Panda Cloud Antivirus/putczip.dll

/Panda Security/Panda Cloud Antivirus/putsig.dll

/Panda Security/Panda Cloud Antivirus/puturar.dll

/Panda Security/Panda Cloud Antivirus/putuzip.dll

/Panda Security/Panda Cloud Antivirus/borlndmm.dll

/Panda Security/Panda Cloud Antivirus/RKPavProc64.sys

/Panda Security/Panda Cloud Antivirus/rtl120.bpl

/Panda Security/Panda Cloud Antivirus/SetupUI.dll

/Panda Security/Panda Cloud Antivirus/bspatch.exe

/Panda Security/Panda Cloud Antivirus/USBVacineDLL.dll

/Panda Security/Panda Cloud Antivirus/vcl120.bpl

/Panda Security/Panda Cloud Antivirus/vclactnband120.bpl

/Panda Security/Panda Cloud Antivirus/vclie120.bpl

/Panda Security/Panda Cloud Antivirus/vclx120.bpl

/Panda Security/Panda Cloud Antivirus/WinSkinc2009.bpl

/Panda Security/Panda Cloud Antivirus/xmlrtl120.bpl

/Panda Security/Panda Cloud Antivirus/DG/MsiZap.Exe

/Panda Security/Panda Cloud Antivirus/DG/PAV2WSC.exe

/Panda Security/Panda Cloud Antivirus/Tools/PandaSecurityTb.exe

Panda left its god damn blekko crapware in my browser.

Comodo CIS (71)

.cav files are definition files, they shouldn’t matter. I realized this partway through and stopped logging them.



/COMODO/COMODO GeekBuddy/uninstall.exe

/COMODO/COMODO Internet Security/cmdagent.exe

/COMODO/COMODO Internet Security/cmdcomps.dll

/COMODO/COMODO Internet Security/cmdhtml.dll

/COMODO/COMODO Internet Security/cmdinstall.exe

/COMODO/COMODO Internet Security/crashrep.exe

/COMODO/COMODO Internet Security/framework.dll

/COMODO/COMODO Internet Security/cfpupdat.exe

/COMODO/COMODO Internet Security/inspect.sys

/COMODO/COMODO Internet Security/msica.dll

/COMODO/COMODO Internet Security/platform.dll

/COMODO/COMODO Internet Security/cfpconfg.exe

/COMODO/COMODO Internet Security/cfp.exe

/COMODO/COMODO Internet Security/cavshell.dll

/COMODO/COMODO Internet Security/signmgr.dll

/COMODO/COMODO Internet Security/cavscan.exe

/COMODO/COMODO Internet Security/7za.dll

/COMODO/COMODO Internet Security/scanners/pe32.cav

/COMODO/COMODO Internet Security/scanners/dosmz.cav

/COMODO/COMODO Internet Security/scanners/dunpack.cav

/COMODO/COMODO Internet Security/scanners/extra.cav

/COMODO/COMODO Internet Security/scanners/gunpack.cav

/COMODO/COMODO Internet Security/scanners/heur.cav

/COMODO/COMODO Internet Security/scanners/mach32.dll /

COMODO/COMODO Internet Security/scanners/mem.cav

/COMODO/COMODO Internet Security/scanners/pe.cav

/COMODO/COMODO Internet Security/scanners/common.cav /

COMODO/COMODO Internet Security/scanners/pkann.dll

/COMODO/COMODO Internet Security/scanners/rkdenum.dll

/COMODO/COMODO Internet Security/scanners/rkdhive.dll

/COMODO/COMODO Internet Security/scanners/rkdntfs.dll

/COMODO/COMODO Internet Security/scanners/script.cav

/COMODO/COMODO Internet Security/scanners/white.cav

/COMODO/COMODO Internet Security/repair/guard32.dll

/COMODO/COMODO Internet Security/repair/7za.dll

/COMODO/COMODO Internet Security/repair/cavscan.exe

/COMODO/COMODO Internet Security/repair/cavshell.dll

/COMODO/COMODO Internet Security/repair/cfp.exe

/COMODO/COMODO Internet Security/repair/cfpconfg.exe

/COMODO/COMODO Internet Security/repair/cfpupdat.exe

/COMODO/COMODO Internet Security/repair/cmdagent.exe

/COMODO/COMODO Internet Security/repair/cmdcomps.dll

/COMODO/COMODO Internet Security/repair/cmderd.sys

/COMODO/COMODO Internet Security/repair/cmdGuard.sys

/COMODO/COMODO Internet Security/repair/cmdhlp.sys

/COMODO/COMODO Internet Security/repair/cmdhtml.dll

/COMODO/COMODO Internet Security/repair/cmdinstall.exe

/COMODO/COMODO Internet Security/repair/common.cav

/COMODO/COMODO Internet Security/repair/crashrep.exe

/COMODO/COMODO Internet Security/repair/default.set

/COMODO/COMODO Internet Security/repair/dosmz.cav

/COMODO/COMODO Internet Security/repair/dunpack.cav

/COMODO/COMODO Internet Security/repair/extra.cav

/COMODO/COMODO Internet Security/repair/framework.dll

/COMODO/COMODO Internet Security/repair/guard64.dll

/COMODO/COMODO Internet Security/repair/gunpack.cav

/COMODO/COMODO Internet Security/repair/heur.cav

/COMODO/COMODO Internet Security/repair/inspect.sys

/COMODO/COMODO Internet Security/repair/mach32.dll

/COMODO/COMODO Internet Security/repair/mem.cav

/COMODO/COMODO Internet Security/repair/msica.dll

/COMODO/COMODO Internet Security/repair/pkann.dll

/COMODO/COMODO Internet Security/repair/platform.dll

/COMODO/COMODO Internet Security/repair/rkdenum.dll

/COMODO/COMODO Internet Security/repair/rkdhive.dll

/COMODO/COMODO Internet Security/repair/rkdntfs.dll

/COMODO/COMODO Internet Security/repair/signmgr.dll

Webroot SecureAnywhere Complete

ASLR/DEP seem to be enabled on all three executable files (including the Chrome extension). Can’t seem to find any others.   If anyone has more info please share.

Pwnium2 Is Over – One Exploit And It’s Already Patched

Pwnium2 is Google’s second competition where they challenge hackers to tear into the Chrome browser. The payouts are much larger than the typical bounty program with the highest being 60,000 dollars for an ‘all Chrome’ exploit.

Last year we saw three exploits – one by Sergey Glazunov, one by ‘Pinkie Pie’, and one by the Vupen team. The Vupen exploit was in the NPAPI flash, Sergey Glazunov used UXSS among other things, and Pinkie Pie used a series of escalation bugs to hop from one sandbox to the next.

This year we saw only one exploit and it was by Pinkie Pie. Details aren’t out yet but it was discovered about 8-10 hours ago (by my count) and it earned him 60,000 dollars.

It’s described as:

Critical CVE-2011-2358: SVG use-after-free and IPC arbitrary file write. Credit to Pinkie Pie.

We’re happy to confirm that we received a valid exploit from returning pwner, Pinkie Pie. This pwn relies on a WebKit Scalable Vector Graphics (SVG) compromise to exploit the renderer process and a second bug in the IPC layer to escape the Chrome sandbox. Since this exploit depends entirely on bugs within Chrome to achieve code execution, it qualifies for our highest award level as a “full Chrome exploit,” a $60,000 prize and free Chromebook.

The big deal there being the IPC arbitrary file write – I suspect the SVG use-after-free was just the initial exploit.

The patch has already been issued to the stable channel. I’ll post more after I listen to the talk about the exploit.

I Think It’s About Time Oracle Steps It Up

A lot of websites have started to flat out state that Java needs to be uninstalled on most users computers. And they’re not wrong – Java is exploited a ton and sandbox escape exploits in the JRE can lead to attacks that hit users running Windows, OSX, and even Linux. And stopping these attacks as a Windows/OSX user is really difficult (Linux makes it pretty easy).

Oracle needs to be more proactive. Honestly, I don’t see why they’re lagging behind in web security – for God sake Adobe’s even doing better, significantly better.

Oracle needs to implement modern hardening techniques into their JIT and they need to redesign the JRE web plugin to work at Low Integrity (Windows sandbox). Adobe has done this and it’s paid off – Flash isn’t the security hole it used to be, I don’t worry at all about Flash exploits anymore as a Chrome user.

Most attacks against Oracle’s JRE aren’t buffer overflows, they’re simple applets that run code on the system. They break out of the JRE sandbox (all the time) and get access to a large part of the system. Due to the nature of how code runs in the JRE (JIT’d code) things like DEP and ASLR aren’t nearly as important. The key here is to contain the exploit with something built into the operating system.

Hopefully with Windows 8 we’ll see AppContainer usage for Oracle’s JRE. The details on AppContainer aren’t really clear yet but it may provide something decent.

Java just isn’t going to get used if people are afraid to have it installed, and that sucks because it’s actually a really cool language.

Java Zero-Day Out In The Wild

Another Java vulnerability is being exploited out in the open internet. It should work against all currently patched versions of Java and there is no patch out for it yet.

Without knowing the details of the exploit I can’t say how something like EMET would change things – if it’s  trying to spawn shell or use a buffer overflow EMET will help, if it’s just a sandbox escape it won’t. I still recommend you use EMET to be safe. Otherwise for Windows users the best you can do is try to stay away from shady sites, don’t let Java run on a website you don’t absolutely trust, and patch as soon as you can.

Linux users can use AppArmor to sandbox Java, this is the most effective way to stay secure against an attack like this. The exploit drops a payload, which then executes. AppArmor would stop this in a lot of ways – preventing the initial write, preventing the payload execution, etc. Even if the second payload launched or if the attacker worked exclusively from their initial .class they’d be very limited.




Pwnium Two – Google Chrome To Hold Another Hacking Contest

Google had so much fun with the Pwnium competition the first time they’ve decided to hold another one. This should be interesting as we’ll get to see if Chrome exploits are really worth 60,000 dollars or if attackers are more willing to sell to higher bidders.

The rewards are similar though now instead of a 1 million dollar limit there’s a 2 million dollar limit. This is largely irrelevant as it is very unlikely there will be that many exploits.

The competition essentially lets a bunch of people come together and see how far they can break Chrome. Last competition we had three exploits bypass Chrome’s sandbox – One by Pinkie Pie, one by Vupen, and one by Sergey Glazunov.

The Vupen exploit was pretty lame and used the Flash plugin. The Flash plugin for Chrome is now PPAPI and far stronger than it used to be so Vupen’s going to have to find another way to get out of the sandbox.

The Vupen exploit was not revealed but the others were. They made use of 6 and 12 bugs respectively and were really brilliant.

Chrome’s sandbox has improved since the last competition – the renderer now runs at Untrusted as does Flash – so it will be fun to see how people break out this time.

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.