Skip navigation
All Places > Metasploit > Blog > 2011 > January

Originally Posted by jduck



In the final days of 2010, an exploit for the Windows CreateSizedDIBSECTION vulnerability was added to the Metasploit trunk. The trigger bitmap was taken byte-for-byte from Moti and Xu Hao's slides from the Power of Community conference. However, the method for achieving code execution on Windows XP was slightly different.


Since this vulnerability is basically equivalent to "memcpy(stack_buffer, user_input, -1);", the most reliable road to exploitation is achieved using an SEH overwrite. Unfortunately, Windows XP SP2 and later protects all modules loaded in Explorer.exe with SafeSEH. Additionally, Windows opts in to DEP/NX for Windows Explorer by default. Therefore, both DEP and SafeSEH must be bypassed for successful exploitation.


In order to accomplish that feat, Moti and Xu Hao used the "l3codeca.acm" module. Sadly, that module didn't get loaded during my tests. I later found that it loads when determining the duration of video in the "Details" view mode. Still, relying on two different Explorer window view modes seemed like a bad idea. So I looked for another way.


After a minute or so, the "msacm32.drv" module gets loaded into Windows Explorer's address space. This module is presumably used for handling something to do with ACM sound, but that's largely unimportant. It does mean that this technique will only work on Windows XP machines that have a compatible sound device though. The key fact is that this module isn't protected by SafeSEH! Win! We can use any address in the code segment of this library as our fake SEH handler.


So, now the problem is how to leverage this module to kick off a ROP-stage. At first I was a bit frazzled and rather than deduce the solution logically, I used a technique I like to call trigger-fuzzing. That is, I repeatedly triggered the vulnerability each address in "msacm32.drv" code segment and monitored the results. After less than 512 attempts, I noticed I had a crash with EIP containing the tell-tale Rex::Text pattern.


After investigating the instruction sequence that led to EIP control, I realized the beauty of it. Trigger-fuzzing had led me to a technique that enables replacing pop/pop/ret addresses with something turning them into ROP fairly easily. The magic sauce boils down to this:



mov reg32, [esp+8]
call [reg32+off]



As you can see, this will load the address of the SEH record from the stack, then use it's contents for the next gadget. As a bonus, we now have the address of the exception record in a register and can easily reference our payload (since we already know the SEH record offset in our buffer).


Of course, this isn't exactly breaking information, Nor is it the only instruction sequence that will work. While chatting with Peter Van Eeckhoutte, he pointed out that a similar gadget is on the corelan wallpaper. Here are some other possible instructions that could work, just to get your creative juices flowing.



mov reg,[ebp+0c] + call [reg] (from corelan wallpaper)
mov reg, fs:[0] / ... / ret (also from corelan wallpaper)
pop regX / pop regY / pop regZ / call [regZ+8]
push regX / mov regY,[esp+0xc] / call [regY+0xc]
mov regY, [ebp+0xc] / push [regY-0x4] / ret
mov regY, fs:[0] / mov reg, [regY-0x8] / jmp reg



The question that remains -- Which sequences are most common? Is there anything as common as Pop/Pop/Ret?


PS. If you're interested in these kinds of things, we're hiring! See our previous blog post, and try not to be too intimidated :-)

Originally Posted by jduck



After the incredible success of the Metasploit Express and Metasploit Pro product launches last year, we are happy to announce a new position on the Rapid7 Metasploit team. Effective immediately, we are seeking a self-driven Exploit Engineer to join the team of full-time Metasploit developers. 


Job duties include researching vulnerabilities and writing exploit code in the form of Metasploit modules (Ruby). Exploit modules will be released to the public under the BSD open source license. 


The ideal candidate will primarily work from home, but will meet with team members approximately once a week in Austin, TX. However, exceptions may be made for the perfect candidate. Candidates must have the right to work in the United States.


Benefits include:


  • Competitive salary and bonus plan
  • Health care and medical benefits
  • Paid to contribute to an open-source project
  • Exploits publicly released under BSD license

A candidate must have a solid understanding of:


  • Common vulnerability classes
  • State-of-the-art exploitation techniques
  • Programming in Ruby, C, C++, and x86 assembly
  • Common networking protocols (TCP/IP and related protocols)
  • Network and system administation of a lab environment
  • Using debuggers and disassemblers (WinDbg, IDA Pro)
  • Binary patch diffing (BinDiff or otherwise)
  • Common operating system implementations (Windows, Linux, etc)

In addition to the requirements, we prefer candidates who have experience:


  • Developing exploits using the Metasploit Framework
  • Reverse engineering compiled applications
  • SMT/SAT solvers
  • Various run-time analysis techniques
  • Dynamic Binary Instrumentation/Translation
  • Fuzz-testing
  • Programming in other assembly languages, such as ARM, PPC, SPARC, MIPS
  • Embedded device research and exploitation

All interested parties should email their resumes to jobs[at]

Originally Posted by jduck



Back in November, Thomas Cannon brought to light an issue within the Android operating system. Specifically, he found that it was possible to obtain the contents of files on an Android device by simply persuading its owner to visit a web site under attacker control. The issue only garners a 3.5 CVSS score, but yet it’s still fairly serious.


Thomas reported this issue responsibly to Google and they took it seriously. However, since then they have come back with a ridiculous remediation plan. Granted, its probably not entirely Google’s fault, but the overall situation looks very bleak for Android.


The problem is that Google stated that a fix will be available as part of an update to the upcoming Android 2.3. While that, in itself, may not be totally ridiculous, the reality of the situation is that Google is only one party involved in Android. There are two other groups, namely OEMs and Carriers, that must also do their part in getting the fix to users. Although Android devices are becoming increasingly functional, the security posture remains abysmal.


The security posture for desktop applications has improved vastly with all of the sand-boxing, automatic updates, and various other exploit mitigation technologies. Meanwhile, Android includes almost none of existing security protections. In fact, mobile users are being left out in the cold, unable to get a patch for a trivially exploitable cross-zone issue. For that matter, they can’t even control whether their device’s browser automatically downloads files or not.


This situation is not news, rather it is a sad fact. It is totally unfair for end users to be left out to fend for themselves. After all, they are paying a small fortune for these devices and the service to be able to use them. Hopefully the vendors involved will wake up before a network worm outbreak occurs.


Originally, Thomas disclosed the details of his bug on his blog. Later, he removed some details to help protect users. I believe that responsible disclosure is a two-way street that requires responsibility on both sides. Since Google, OEMs, and carriers all continue to act irresponsibly, it is necessary bring more attention to this issue and the situation as a whole.


I spent a little time and managed to recreate the issue with nothing more than HTML and JavaScript. As of today, I have released a Metasploit module to take advantage of the flaw. It is available in the latest copy of our Framework product, or you can view the source via the link to our Redmine project tracker above.


Before I go deeper into the consequence of this bug, I want to point out that Thomas outlined several workarounds for this vulnerability in his blog.


Now, take a deep breath give some thanks to the fact that, under Android, most every process runs under a separate, confined, unix-style user account. This design feature partially mitigates this issue, lowering confidentiality impact to “Partial” and bringing the CVSS score from 5 to 3.5. That said, an attacker can still gain access to some pretty interesting stuff.


For starters, an attacker can steal any world-readable file. In my tests it was possible to get potentially sensitive information from the within the “proc” file system. This type of information could include kernel versions, addresses, or configuration that can be used enhance further attacks.


Also, you can snarf any files that are used by the browser itself. This includes bookmarks, history, and likely more. This kind of information could potentially be embarrassing or possibly even give an attacker access to any saved passwords or session cookies you might have stored.


Perhaps the easiest win though, is that you can grab anything off of the SD card. You might ask, “Anything?! What about the user separation?” Well, because the SD card has been formatted with the “vfat” (aka “fat32”) file system, there is no concept of ownership. All files are owned by the same user id since the file system itself cannot encapsulate who created which file. As Thomas said, files in the SD card that have predictable names are ripe for the picking. This includes pictures and movies. These may in fact be some of the most private data on your device.


In conclusion, I hope that the Android security debacle will get resolved as soon as possible. If Google, OEMs, and carriers can’t work it out, perhaps another party will step in to maintain the operating system. I believe this could be very similar to the way various Linux distributions operate today. If the situation is not resolved, I fear the Android device pool could become a seething cesspool of malicious code...

Filter Blog

By date: By tag: