Monday, November 23, 2009

Network Forensic Challenge #2 - update

Ok, the submission date got extended an extra week, which ended yesterday. Erik put out version 0.90 of NetworkMiner in which he added support to pull out SMTP messages from captured data. He found a bug in 0.90 and released 0.91 yesterday, it can be found here.

My answers are here:
1. Username:sneakyg33k@aol.com
2. Password:558r00lz
3. mistersecretx@aol.com
4. fake passport and a bathing suit.
5. secretrendezvous.docx
6. 9E423E11DB88F01BBFF81172839E1923
7. Playa del Carmen, Mexico
8. AADEACE50997B1BA24B09AC2EF1940B7

I used the pcapcat perl script from NFC #1 to extract the initial data. The one thing I think is a bit unrealistic in these contests is the packet captures are too small, there isn't 100-500 MB of stuff to sift through, trying to decide what is needed/not. Due to download feeds and whatnot I understand why that is, but.... Feeding a 100 kb pcap file through makes life quite simple. Anyway, I emailed the author of pcapcat, for what we've seen in #1 and #2 that script works fine, but if any packets are resent, or out of order, pcapcat fails to take that into account and just puts the data in the output file in the order it was seen in the pcap file. I tried to make some changes to it to fix that, but it was beyond what i could figure out in a short enough time period. Sent my thoughts on to him and we'll see if it gets updated in a future release. We could have used tcpflow, wireshark, etc to get the initial conversation dumped out.

Anyway, however you get the raw data is up to you, dump to it a file and then for me, feed it through smtpcat.pl which will parse it into whatever attachments it may have, pull the username/password out and decode them. You'll still need to do an MD5Sum on the extracted file. My script was completely hacked together, no subs, just start to finish run and output. Not pretty, but functional!

Open up the extracted file and you'll see the location they are meeting at and because .docx files are just zipped up files you can do an unzip on the .docx file, browse around, find the image file and do an MD5Sum on it also.

I'm being a bit vague on this one because it has been well over a month since I did most of this, and I don't recall all the specifics anymore. Here is someone else's writeup on how they did it, goes into a bit more detail, but same idea. His smtpcat is of course different than mine.

Update: (ok had some time to run through this for those who may need some more info)

First lets see what conversations we have going on in evidence02.pcap:
C:\nft>perl pcapcat.pl -r evidence02.pcap
[1] TCP 192.168.1.159:1036 -> 64.12.102.142:587
[2] TCP 192.168.1.159:1038 -> 64.12.102.142:587

Lets dump each:
C:\nft>perl pcapcat.pl -r evidence02.pcap -w file1.txt -d 1
C:\nft>perl pcapcat.pl -r evidence02.pcap -w file2.txt -d 2

Pull up each file in notepad or your favorite text editor and you'll see file1.txt isn't what we want, but about canceling lunch with someone. File2.txt though appears to have an attachment. Looking through it we can see the answers to some of our questions and we can see what the attachment is:
------=_NextPart_000_000D_01CA497C.9DEC1E70
Content-Type: application/octet-stream;
name="secretrendezvous.docx"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="secretrendezvous.docx"

We could just copy/paste the attachment into a nice web form on google and get it to spit out the file, but that defeats the purpose the exercise (though that is what I did initially to get the answers).

So next we feed it through smtpcat.pl like this:
C:\nft>perl smtpcat.pl -r file2.txt -w dir2

it will create the directory dir2 if it doesn't already exist and drop the attachments found in file2.txt into it.

We also get the following output:
Credentials:
username: sneakyg33k@aol.com
password: 558r00lz

Other info:
From: "Ann Dercover"

To:
Subject: rendezvous


Attachments and other top level info:
Content-type: multipart/mixed
Effective-type: multipart/mixed
Body-file: NONE
Subject: rendezvous
Num-parts: 2
--
Content-type: multipart/alternative
Effective-type: multipart/alternative
Body-file: NONE
Num-parts: 2
--
Content-type: text/plain
Effective-type: text/plain
Body-file: dir2\msg-860-1.txt
--
Content-type: text/html
Effective-type: text/html
Body-file: dir2\msg-860-2.html
--
Content-type: application/octet-stream
Effective-type: application/octet-stream
Body-file: dir2\secretrendezvous.docx
Recommended-filename: secretrendezvous.docx

We now know her username, password, who the email was from and to, along with the subject and the # of parts and what it created. Since there were no suggested names for the plain and html parts it made some up for it.

The username/password were both base64 encrypted. The 2 types of Authentication that we can easily decode are AUTH LOGIN and AUTH PLAIN, both being base64 encrypted, just different formats of storing the data. smtpcat.pl will handle both, even though only one was needed for this.

Here is what we have in dir2:
Directory of C:\nft\dir2

11/28/2009 02:53 PM 87 msg-860-1.txt
11/28/2009 02:53 PM 402 msg-860-2.html
11/28/2009 02:53 PM 207,438 secretrendezvous.docx

Looking at the .txt or .html files (both the same info one just plain text, one html) Ann asks her sweetheart to bring their fake passport and bathing suit to the attached address. Guess we need to go look at the .docx file.

Opening up the .docx file in OpenOffice we see that it is a picture of google maps telling where to meet. Running an extraction on the .docx file we can go to the word\media directory and find the attached image called image1.png. Do an md5sum on that file and on the original .docx file to get the md5's for them.

Again smtpcat.pl could be cleaned up a bit to add more stuff and be written cleaner, but for what was needed here this worked great. Using pcapcat.pl worked in this example, but as noted before, it does not take into consideration out of order packets, retransmissions, etc, so something else may be needed in "real life", though I still really like it!

Friday, October 30, 2009

Yokoso!

The first I saw of this was on one of the Twitter posts from someone I follow. This is a sourceforge project.

On a read of the sourceforge page you'll see:
Yokoso is a project geared toward fingerprinting infrastructure. Yokoso will determine what web interfaces are available on a specific network.

But based on the net-security article it is a bit more. First it tries to exploit your browser, goes through and finds out what sites you may have admin rights on, and then does some type of fingerprinting.

I'm going to try to find some time in the next week or two to test this out, if/when I do I'll post back my results. It looks promising, but anything doing browser exploits makes me nervous.

Thursday, October 29, 2009

DHCP Fingerprint Manager updated

New release of DHCP Fingerprint Manager (1.00.01) released earlier today. In earlier versions you had to export the data out of wireshark in a text format and it would read that in and DHCP Fingerprint your data, in the latest release it now reads in .pcap files.

I've mentioned some of the features of this program before, that I'd love to steal and add into Satori, but I'll probably never get around to it. I love the statistics feature when it is done! It also gives you the ability to update the fingerprint data and then reparse the data from the pcap file and get the new fingerprint for the device if it happens to have changed.

Check it out and give him some feedback on the product when you get a chance.

Update (note from the author):
Note that open/save handles user data in XML format. It contains end-systems and fingerprints (content of both tabs).
The import function allows to get end-systems for DHCP trace (*.txt or *.pcap or *.cap) and to get fingerprints.
Note that fingerprints are "imported" by default when creating a new data file.

Here is a quick link to the program.

Saturday, October 24, 2009

Network Forensics Challenge #2

They are at it again, we barely got the answers for #1 and #2 got put up a few weeks ago. I did it originally within ~30 mins using the web, wireshark and a few other local programs on my machine. But I wanted to stand a chance of actually winning this time, so instead of just sending them the answers I actually started writing a few .exe programs to parse the data out. I have/had them done and then decided I better do something I was willing to share the source code on, so I wrote out a perl script.

Perl is not something I ever work in, have only done it a few times before, so it was a bit painful to do, especially coming from a Pascal background and not a c one! if statements and eq vs = and other little gotchas killed me today, but after about 4 hours or so I came up with a 258 line .pl file that parses it out nicely. There is a lot more I could add to it, but since I'm by no means a perl programmer and my hands are cramping up typing this as it is, it was time for a break and time to call good enough good enough!

I'll release the script after the deadline if i'm not picked as a finalist and it is added to their site.

This was another fun project to work on and it forced me to dig into a programming language I should have learned long ago, but never have. So always good to expand your knowledge some.

Wednesday, October 14, 2009

Small Linux Devices

Just a followup on the Wall-Wart type linux devices, something new came out.

If you thought the last one was small, then check this out. There are advantages to the Wall Wart design (usb to add wireless or a 2nd nic, etc), but if you are just looking at size this thing is great. Not sure if it is POE or how they power it, didn't look into details.

Wednesday, October 7, 2009

SANS Reading room

Not sure how new the article is based on the fact that all referenced material is from 2002 or before, but here it is. It is about using Telnet Negotiation Data to passively fingerprint a system.

Being that telnet isn't used much anymore, it may be a little dated now, but it popped up in my Google Alerts, so figured I'd at least put it here so I could find it easier in the future if need be.

While looking around SANS reading room I also came across this article which also appears to be dated, but still somewhat useful. It is about using passive fingerprinting to audit and discover network vulnerabilities.

Saturday, September 26, 2009

Network Forensics Contest Results

A month or two ago philosecurity.org started a nice little Network Forensic contest. It wasn't too hard and wasn't too easy. It gave me a chance to parse through some traffic and see what was going on. Then to carve a file out of a packet capture, using some of the SANS 508 stuff I learned awhile back before I picked up my GCFA cert.

The original puzzle can be found here and then again here when SANS decided to sponsor it and give an On-Demand course away for the winner.

Well happy to say I at least got everything right, though I didn't win, nor was I one of the finalists. All of the finalists scripted out a way to answer the questions, or had one program that did it all (or most of it). The results can be found here.

Erik Hjelmvik, author of NetworkMiner, who is using some of the tcp and dhcp fingerprinting stuff from Satori was one of the finalists and implemented some new stuff in 0.89 to become a finalist, though not a semifinalist since it wasn't all scripted out either. (When I used NetworkMiner to parse it out, it was only version 0.88, Erik hadn't released 0.89 until after I put my submission in).

From a straight Network Forensics standpoint I understand why they wanted it scripted out, but from understanding how to actually do it I'm glad I didn't depend on an automated program to do it (granted each of the finalists I believe had to write their own programs to do this). If you understand how to carve the data out then you can do this with pretty much any data, if you depend on a utility to do it, you may have to wait for updates to it if/when things change.

Ultimately I just wanted to make sure I could do it and am happy that I got it done and answered correctly. I was more interested in it from fingerprinting stand point anyway and spent more of my time on seeing what else was on the network!

If anyone wants to do it, the puzzle and pcap files are still out there!

Here was my submission and all my notes (again I was interested in the rest of the network):

Answers:

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.

How I got there:

Tools Used:
Satori - http://myweb.cableone.net/xnih - Passive OS Fingerprinting
NetworkMiner - http://sourceforge.net/projects/networkminer/ - Network Forensic Analysis Tool, used for cookie stuff and a few other sanity checks
FrHed - http://frhed.sourceforge.net/ - used to Hex Edit the file to remove the initial stuff prior to the magic number
Wireshark - http://www.wireshark.org - view and export pcap file
HashGenerator - http://pagesperso-orange.fr/cycocrew/delphi/applications.html - computer hashes
Google of course to find some of the other info
----

Writeup:
I started with 2 programs, one I wrote geared completely towards passive OS fingerprinting, Satori, and the other program NetworkMiner which I've worked with the developer on a little in the past. Using Satori I mapped out the machines identified in the packet capture and got an initial layout of the network. Determing which systems did what on the network. Then feeding the capture through NetworkMiner I was able to get some of the initial Clear Text information that was going on between clients. Once I had a better idea of what type of data was in the capture I started picking away at it with Wireshark.

Knowing Ann's IP it was easy to get started in wireshark with a simple filter of (ip.host == 192.168.1.158). With this in place and scanning through the packets for anything out of the ordinary in the hex window. Basically I knew there had to be some type of clear text conversation going on due to what NetworkMiner had seen. We see Ann's computer is talking to a 64.12.24.50 (bos-m013a-sdr3.blue.aol.com). Since it is an AOL server it is probably AIM being used, but I did not verify that. The information looks to be SSL based on the destination port, but ends up being in clear text. I assume this was an attempt to get past any egress filtering, but didn't dig into it since that wasn't requested at this time.

Identifying who she was talking to was fairly simple, and digging into whatever protocol the chat program she was using would have probably been a good idea. Based on other things I saw she appears to be comunicating with Sec558User1.

Eventually she transfers the file to the other user at computer 192.168.1.159, which appears to be a Windows XP box. Depending on your env this may be a dead give away that you are having issues. Looking at the other systems on this network they all appear to be Linux Boxes, so a new rogue XP box sticks out like a sore thumb. Something like packet fence which does DHCP fingerprinting may be useful to block computers like this off their network or at least make it a little harder for them to get a valid IP and use the network.

In packet 92 we see the beginning of the file transfer. Sending the file recipe.docx

The rest of the file transfer which starts in about packet 109 where we are able to right click on it and do "Follow TCP Stream". This shows both directions of traffic. Next we need to go to the bottom and filter by 192.168.1.158 --> 192.168.1.159, getting just the data that Ann's computer is sending to the XP box. Select Raw and do a Save As. This will save "extra" info in the file, which we will need to remove based on some file carving next.

We now know, or appear to know the type of file it is based on the file name above. We need to look up that magic number. A docx file really is a zipped file so it has the same magic number which is: 50 4B 03 04 14 00 06 00

We now open up the file we saved in a hex editor and do a search for the above magic number. Once we find it we delete anything prior to it and resave the file. There is always the chance that there will be extra junk at the end too that may need carved off.

After that, we can open up the file with OpenOffice or Microsoft Word and see what the data is. We could also unzip it instead and look at the .xml files generated if we need to find out more about the initial file.

Run the file through your choice of md5sum programs and you should be good to go.

-----

Below is the notes I took while I went through the system, typically wouldn't put them in a report, but there was a few interesting pieces of info in there I found.

Extra info and general notes on systems on the network and what they appear to do:

192.168.1.2 - Linux 2.6 possibly, limited info, did what may have been a scan of 192.168.1.157. Connected on port 80, but just did a handshake and said goodbye, no header info exchanged.
192.168.1.10 - default gateway I assume
192.168.1.30 - NTP Client Box, running SSH server (192.169.1.2 connected to it)
192.168.1.157 - running Samba 2.2.7 - 3.0.x client (actually 3.2.0, need to update Satori)
print queue
HTTP Server, or at least port 80 is open
Herbivore/SANS
192.168.1.158 - Linux 2.4 or 2.6 box, packet 92 starts sending recipe.docx, packet 112 using cool filexfer sends it also
NTP Client
Talking to 64.12.24.50, most likely sec558user1
FTPs file to 192.168.1.159, syn comes in in packet 109
192.168.1.159 - Windows XP, 2000 or 2003 box (XP based on Web)
talking to 64.12.25.91
downloads zip file of smiley faces from 205.188.13.12
goes off to at.atwola.com, requesting DNS info for them after download of resume.doc
pulled file (httpget) with: (removed since it was actually linking to the ad in this post!)
pulled file (httpget) with: (removed since it may have linked to ad also).
"username" on cookie: JEB2=4A839DDB6E65181C45921CB2F00016D8; ATTACID=a3Z0aWQ9MTU4NzdpYTAwYTh2Ymk=; ATTAC=a3ZzZWc9OTk5OTk6NTAyODA=; badsrfi=V0d710994e8ccb8db64a83a07939b2; atdemo=a3ZhZz1hbTM6dWEzOTtrdnVnPTE7; AxData=; atdses=0
atwola.com appears to be "spyware/adware" based on a quick search

External Hosts
64.12.24.50 - bos-m013a-sdr3.blue.aol.com
64.12.25.91 - bos-m007c-sdr4.blue.aol.com
64.236.68.245 (dns requested info by 192.168.1.159)
64.236.68.246 (dns requested info by 192.168.1.159)
205.188.13.12 - no DNS entry, only talking to 192.168.1.159 via SSL), downloaded a zipped file of smile faces and their manifest.
10.1.1.20 - DNS server, NTP Server

Clear text data, (192.168.1.158 to 64.12.24.50) (owned by AOL, so possibly AIM traffic)
E4628778....Sec558user1
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 >:-)
E4628778....Sec558user1*..c.z.........
G7174647....Sec558user1.......R..7174647..F.CL...."DEST.......................F.........'...........recipe.docx.*.V......
G7174647....Sec558user1*.V..{.......*..
7174647....Sec558user1..............J.H.........+..1n....+...O............J.........7174647..F.CL...."DEST.......*.V..".......*.1...........
Sec558user1..*.V..........*.y..N....w...
Sec558user1..............J.H.........+..1n....+...O............J......a........X....< HTML >< BODY >< FONT FACE="Arial" SIZE=2 COLOR=#000000>thanks dude< /FONT>< /BODY>< /HTML >.
......+..1n....+...O.........*.V..".......*.............Sec558user1..*.V..........+.Q.....L.....Sec558user1..............J.H.........+..1n....+...O............J......s........j....< HTML >< BODY>< FONT FACE="Arial" SIZE=2 COLOR=#000000>can't wait to sell it on ebay< /FONT>< /BODY>< /HTML >
............Sec558user1..*.V..".......+.............Sec558user1..*..d.".........H...........Sec558user1..*..e.J.........
I5088496....Sec558user1..."................see you in hawaii!....*..f.".........J...........Sec558user1..*.V......

DOCX (zip) Magic Number:
50 4B 03 04 PK..
ZIP PKZIP archive file (Ref. 1 | Ref. 2)
Trailer: filename 50 4B 17 characters 00 00 00
Trailer: (filename PK 17 characters ...)
DOCX, PPTX, XLSX Microsoft Office Open XML Format Document
JAR Java archive; compressed file package for classes and data
SXC, SXD, SXI, SXW OpenOffice spreadsheet, drawing, presentation, and text files
WMZ Windows Media compressed skin file
XPI Mozilla Browser Archive
XPT eXact Packager Models

50 4B 03 04 14 00 06 00 PK......
DOCX, PPTX, XLSX Office 2007 documents

Use Follow TCP Stream, just get one side of converation. Save as Raw. Lookup "magic number"
Search for it in Saved file. Delete everything prior to that and resave, get:

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.

Hash on the File is:
8350582774E1D4DBE1D61D64C89E0EA1

Thursday, September 24, 2009

Updated Fingerprint Programs

Jeff has done a great job making it easy to update the different xml files I use in Satori, along with the ability to have an underlying repository that helps keep everything the same across all of the files! He's also written a nice DHCP Fingerprinting program himself. These can be found at Devonic Delphi Page

DHCP Fingerprint Manager: imports text-based Wireshark traces to populate and fingerprint systems. Basically, you take a pcap file, parse out just the DHCP packets and export to a text file. You then dump that in and dhcp fingerprint the systems.

It is a lot faster than Satori and it gives you a lot of nice features after you are done. The Statistics is a wonderful little chunk of it you can do after reading in a file. I may have to steal some ideas from him on this! In the statistics area it breaks down % of End Systems by MAC Vendors, Fingerprint Names, Fingerprint Match Scores, OS Names, OS Classes OS Vendors, Device Types, Device Vendors, and then the Authors of the individual Fingerprints.

Fingerprint Editor: The program I use all the time these days to modify the different xml files that Satori and these different programs are using. I used to always do it by hand, but inevitably I always missed updating something. It was nice to have this to help keep things in sync, update the time stamps, etc! If you are creating fingerprints to send me, and not just sending me the raw data, this is the perfect program to use!

There is also DEF File Editor that modifies the definition files the programs above use.

He has quite a few other nice programs out there, and if any of you are delphi programs check out his Delphi Components page. I used a few pieces from there myself.

Friday, September 11, 2009

Gaining ground?

2 blogs talking about DHCP fingerprinting in 2 days, not bad. The 2nd one may have been inspired by the first since it links to it, but it also has a link to my BH briefing, so hey, I can't complain.

Meraki did the first one yesterday. (I love Google Alerts) I've tried to contact Hans about what they are doing (option55 data only, or more like I'm doing with the dhcp.xml file), so far I haven't heard anything back, but it was a Friday. We'll see if I get any response or not. If anyone has a POC for Meraki maybe check into it for me.

The second blog was from coova.org. They have a link to David and my Blackhat Presentation from 2007 for those that haven't looked at it before. He mentions a product CoovaRADIUS which I hadn't heard of before (nor had I heard of Meraki for that matter). It appears CoovaRADIUS can do dhcp fingerprinting via CoovaChilli. They appear to be using the packetfence data, so just option55 without taking into account if it is a Request/Discover/Offer/Inform/etc packet. May have to try to get a hold of the developer there too and see if they are interested in trying to use the dhcp.xml file. Always good to get more people using it, thereby expanding the database as more people have access to more devices.

Monday, September 7, 2009

Great Dataset to parse through by ITOC

ITOC has a great set of data to parse through for those that are interested:
http://www.itoc.usma.edu/research/dataset/index.html

Just over 8 GB of data between inside/outside captures.

They also have a blog setup:
http://datasetsfortheresearchcommunity.blogspot.com/

I'm hoping for some more information on exact OS's being released so that I can take the data that Satori spit out and use that to extend the fingerprints on FreeBSD and possibly some of the other OS's seen on the network. I'd hate to just take and put it under the generic FreeBSD if we can tell for sure it was 7.0 or whatever.

Satori already has ID'd the systems, quite well from their initial diagram, but it would be nice to know for sure that it is correct before extending some of the fingerprints!

One problem I'm having it is takes forever to go through 1 GB files with Satori. Some of it has to do with the amount of "stuff" I've added to it, but that is just a lot of data to parse too! Oh well, 1-2 hours per file, come back, see if it blew up, etc. (Update: Make that 1-2 hours on the 100 MB files, not sure how many days to get through the 1 GB files!) This data set at least gave me some new packets that I hadn't seen before that caused some problems, so I updated a few of the dlls to handle vlan traffic in them. I was feeding it in, just not parsing it correctly!