Forensics Contest #3 released

For the holidays they released challenge #3. This time you'll need to reassemble packets to get the whole picture! May be beyond what I can throw together in perl, actually 99% sure it is since I tried to do this a little last time. I'll probably write something in C or Pascal for it. Problem with doing it in pascal is they are going to want the source and I'm not sure i'm willing to give up my source on winpcap stuff. We'll see, maybe use something else to rip the traffic out and then just put a nice gui front end on it with pascal. Who knows.

Anyway, check it out.

Forensics Contest #2 Finalists and Winners

Based on the PaulDotCom 180 podcast Franck and Jeremy were the winners, they decided to have co-winners this time around. Erik and NetworkMiner ended up being finalists again and got special mention in the podcast.

As of this posting they haven't actually published this at the forensicscontest site, but I guessed at the URL and picked up the Finalists along with the winners from the podcast.

Will be fun to look through the winners submissions over the next few days/weeks. Contest #3 is hopefully due out in the next 7-14 days.

Update:
Posted:
Contest Winners and writeup now posted

I made the SemiFinalist list (top 15), just didn't make the finalist list (top 8). Maybe Contest #3!

DFRWS results posted

At the time the 2009 challenge was posted I think I only looked at the network traffic side of things and didn't get a lot out of it. Not sure if I'd done the GCFA and SANS 508 course at that time or not, but I know I didn't dig into the memory or disk dumps. Would have been nice to knowing a bit more about that stuff now. Anyway, glanced through a few of the writeups, very nice work!

You can find the writeups, challenge info, etc here

I think NetworkMiner will make much better use of the pcap files that Satori does, but Satori isn't designed for this type of thing anyway!

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!

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.

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.

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.

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.

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.

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

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.

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.

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!

Telnet Recon

Google Alert just popped this up on a program called telnetrecon. Telnetrecon is just that a recon program for the telnet service. It appears to be an active scanner. I have very few devices/systems with telnet open these days, so it isn't something I've tried out. If anyone runs it let me know any feedback you have or feel free to add a post.

Looks like it was initially released about a year ago. Not sure how much additions have been done to it. Something that may come in useful to do some testing though.

Sayings that drive me crazy

Ok, nothing to do with OS Fingerprinting, but I've seen this comment twice this week and it drives me nuts:

"Either way, ESX is just software and can suffer from
vulnerabilities just like any other piece of software."

Yes, 100% true, the above was when I asked if VM Escape had actually been shown in ESX, not just workstation/server. Earlier this week, someone else said the same thing on a different security list in regards to trunked VLANs into an ESX box and that trusting VMware to do it in ESX was crazy and you should use a real Firewall because "ESX is just software... and has vulns in it".

What do these security people think runs firewalls? Lets see, Cisco device runs IOS, IOS is software! Better yet, Network Engineers put rules in FWs, NEs get lazy sometimes and put bad rules in them.

Give me a break, YES ESX is software, YES software has vulns in it, but everything we do on these lovely pieces of hardware we are sitting at requires software to run. Even to boot them up there is software. What do you think the BIOS is!

Ok enough ranting, but next time you hear someone say "It is just software, so it has vulns in it" smack them upside the head for me!

ICMP OS Fingerprinting

Quite honestly I thought ICMP based OS Fingerprinting was dead and had been for years now that almost all OS's default to running a firewall! I was quite surprised to see that NetScanTools Pro has an option in it to still do this.

Happened to pick up an article from Laura Chappell, which had a link to this quicktime audio: http://www.screencast.com/users/laurachappell/folders/Media%20Roll/media/75047d06-2801-49b7-87d3-0e41a3abd500

NetscanPro appears to be doing the standard:
ICMP Request
Timestamp Request
AddressMask Request
Information Request
ICMP Request (Code <> 0)
TOS and Precedence

Without going back and reading Ofir's paper again, or looking at my old ICMP program I'm not sure if any of them are new from what Ofir presented in his paper back in 2001 "ICMP Usage In Scanning" or not. I wonder if LNSS is still using the the Code <> 0 test at all?

ICMP fingerprinting seems about the same as before. Useful in some cases, not so useful in others. It is good to see that it is still being used and therefor some new database has probably been made.

Out of the 4 main types of devices on my network it identified them as [Actual - Identification}:
Netgear WAP - HP Procurve Switch 2500 Series
Brother Printer - Unable to identify operating system.
Linksys VOIP Device - HP LaserJet 2800 Series
XP - Windows XP responding to Ping only

Ok, I had my box crash twice while doing OS Fingerprinting with this. It could be a problem on my box or it could be a bad dissector on their end. Will follow up with them. [note: Kirk was quick on responses, looks like it was probably in WinpCap since the BSOD pointed at npf.sys, trying to duplicate on another system, may also be a NIC driver combination, looking into it, but doesn't appear to be NetScanTools related]

Anyway, out of 4 devices it could ID 1 correctly. Any fingerprinting program is only as good as its DB, so maybe I'll have to play with it a bit more and send it some new fingerprints if they have the ability to add them. [Note: Looks like the ability to add more will be in version 11, so I'll have to try to follow up with them in the future]

Web Fingerprinting

Fingerprinting web sites via the Server tag has been done for years (and years and years). Then came fingerprinting it based on the order of responses (httprint). Now something new (or at least new to me) has shown up, fingerprinting it based on certain files on the site.

Article can be found here

In a nutshell:
"What these fingerprints are, depend on the web application, but generally we can use .js (javascript) , .css and a few other files that are available and we can access the source remotely. We can't do the same with .php, because it will not return the source (only the executed output)."

In their example they fingerprint wordpress sites. Interesting new approach.

AD, Scheduled Tasks, and batch files

Ok, totally off subject for why I started this blog, but....

Was looking at a bunch of Scheduled Tasks on a bunch of servers today, thinking about how, if configured incorrectly, Scheduled Jobs can be a major security hole.

Take for example a scheduled job that accesses multiple systems. Instead of setting up a specific account that has access to only "X" number of systems, a domain admin account is used. There are many things wrong with this scenario, but I've seen it, and I'm sure others have to. On top of this, lets assume that this scheduled job calls a batch file, instead of an exe directly (though this could also be used in this type of attack).

If you go in to modify a scheduled job, the file it points to, the time it runs, etc, Windows prompts you for the password again. All well and good, but instead of modifying the job, you just look to see what it points at and who it is run as.

In this case, a batch file, setup to run as a domain admin. Go in, modify the batch file, put some things like "net user add" in there or your favorite command line utility (for that matter a GUI utility) and go back into scheduled tasks and say run. You've now escalated from a normal user, on this system, to whatever you want! This assumes you have some type of access to the system in the first place and all that goes with that.

Moral of the story:
1. Don't run tasks as Domain Admins, practice the whole least priv ideology.
2. If you must run things via Scheduled Tasks, the files you are calling should be in a directory that is locked down by ACL that only allows the user calling them access to them.

It would be nice if MS added some type of checksum to the files called. When you create the job have it run a checksum against the file it is to run and to verify that each time it runs the process.

The forgotten power of SNMP

I keep wondering when the next big breakthrough will come and from where. Most protocols have been done, tricks have been played, and now it is a lot of rehashing of old tricks. I'm not saying someone won't come up with something new, because I'm sure they will, I'm just curious when it will happen and how they'll come up with it.

While I'm waiting though, I decided to revisit SNMP capabilities. I still get emails from time to time about the objects_id.txt file that I originally compiled and then updated for Languard Network Security scanner back in 2001. (Or did Bogdan come up with it and I just updated it, sad how quickly the memory goes!)

Anyway, recently our network engineer and I were trying to track down some rough MACs that were infected with DHCPChanger and another box that had Microsoft's Internet Connection Sharing turned on (what a pain that is in a large environment!) There are things that can be done, such as DHCP Snooping on the switch, etc, and that is mostly in place now, but this whole issue got me thinking of how we could do this quicker and easier. Jumping on switch after switch, dumping the MAC table, determine what port it was coming down, remoting into that switch and doing the whole process over again seemed like a waste of time.

Enter SNMP. I had looked at this idea back in 2001, but articles like this, from the vendor weren't readily available. Cisco published this one which helped a lot on trying to figure this out.

Anyway, the idea is simple enough, and I'm sure there are other products out there to do it, but you give it the MAC you are looking for, the IP to start with (probably a nice Layer 3 device at the "center" of your infrastructure) and the public community name and you hit go. Depending on the number of VLANs you have to enumerate, you are looking at 20-30 seconds per device to determine all the ports, neighbors connected via those ports, ip address and desc of those neighbors and all MACs associated with each of the ports. Assuming their is another switch down Port X, snmp walk that device next, repeat and rinse until you get to the end port where that MAC resides. A lot nicer than bouncing through 3-7 devices trying to find something!

Taking that of course to the next level is to build a tree of all devices, pulling their object ids, system descriptions, etc. Start at device 1, anywhere in the infrastructure, query it, ask it about its neighbors, query each of them in turn, walking round and round until you've mapped it all out.

Tracking the MAC back to a specific port is pretty much done, nothing pretty, but it works. Building the map is all in my head, but the ground work is laid out in what I've already accomplished, so now I just need some free time to code! Only thing still to figure out is what happens, or how to detect, redundant links. Don't want to start a loop, walking down the port I just came from, or if multiple paths exist, wandering back down to devices I've already scanned. All doable, just have to sit down and think about it.

Again, nothing ground breaking here, just finally getting back to a project we talked about in the 2001-2002 era, but didn't have enough info on how vendors were storing info via SNMP. Oh, and for initial release, if that ever does happen, it will probably only work on Cisco devices, since that is all I have to play with.

Satori - Linux Version Part 2

Ok, officially have links on my website for the linux version of Satori. Made some bug fixes from the initial release to get around 256 char strings in fpc that I had forgotten about.

Added a few more command line options, updated the dhcp.xml file, etc.

Version 0.1.1 is now out there for anyone that is interested.

Satori, Linux version

Ok, been busy working on a command line version of Satori for Linux. There are certain functionality in the cmd line version that I will not try to replicate that are in the windows version. Since I'm just doing output to screen an overall score and some of the other things, such as ICMP sequence differences will not be there.

So far I've ported the DHCP, TCP, p0f and ettercap stuff over.

It is written in free pascal (fpc) with the lazarus IDE. Ultimately my goal is to get as much of it over to Linux as possible and most likely to rewrite the whole thing in fpc so that I can have a GUI version on both windows and linux.

Main reason I'm writing it for Linux is so I can play with it on the wall-warts I wrote about a few weeks ago. Assuming I have some extra cash I'll probably be ordering one in the near future. This will require me to compile it for ARM also, hopefully all goes well!

If anyone wants a copy, let me know.

Trojan.Flush.M and DHCP

Symantec has a nice writeup on this, it is a few months old, but a new variant appears to be running around now.

Now from an identification prospective, DHCP fingerprinting comes in quite nicely here! I was able to get someone to send me a packet capture of DHCP Offers and ACKs from an infected machine on the latest variant. I'd like to get a few others also, but have not had a chance to look into it much due to other projects and work.

I'll be adding the fingerprint into the dhcp.xml file here shortly, assuming time permits. If anyone has packet captures from other variants of this trojan, or others that are doing dhcp offers/acks, please email them to me.

Cool little device

Ok, nothing to do with OS Fingerprinting, but since I've been looking into Pentesting so much lately also, when I saw this post earlier today on Twitter by Hal, all I could think of was how much fun one could have with one of these!

http://www.linuxdevices.com/news/NS9634061300.html?kc=rss

These devices are getting smaller and smaller all the time and cheaper and cheaper.

I'm waiting to see one with two ethernet ports on it, basically an internal switch so that you can drop one of these behind someones desk, plug their computer feed into your device, a short cable from the device to their computer and then have this thing phone home and open some type of door for you.

As it is now that could still be done easily enough with it, but you also have to find a network port that is live. Adding the internal switch would just make things easier.

Insecure Magazine, os fingerprinting and xprobe2

The latest version of (in)secure was released here recently. The first article this month was on using a new version of xprobe2 to do fingerprinting. Sounds like some new features have been added and some cleanup has been done.

Looks like the next release is due out in June of xprobe

EDHCPFingerprint & EFFormat

Both programs from enterasys have been updated again! They've been busy. Main change I know about is a repository.xml file that is generated. It looks to see what names show up across multiple .xml files (tcp, mac, dhcp, smb, etc). It was a very useful feature in cleaning up some of my files. Some of which I'm not even using yet, but that I've been adding to from time to time in the past and hope to use in the future!

I've pretty much started using EFFormat full time now in editing my fingerprint files!

As always, they can be found here at enterasys

Updated Software

Satori updated to version 0.62. Lots of new fingprints added and others updated. Took like Linux distro's and combined them where it made sense instead of having 5 fingerprints that were all the same because they were based on the same distro. Also added the packetfence fingerprint info back into my dhcp.xml file. We'll see if the packetfence project starts using the .xml file or not, it has been discussed in the past and may be being looked at again. We'll see.

With the addition of these fingerprints back into dhcp.xml I decided to give the user a few more options in parsing dhcp fingerprints. You'll find it under options. I also added a new feature for arp parsing also since it was in an 'addon' dll instead before. Now it is just an option.

Last major change was an update program. It is a stand alone program that will update the .exe, .dll, and .xml files. It is nothing fancy, but it gets the job done. It will let you keep up to date on the latest fingerprint files, dll's, etc without me having to do a full new .zip file!

EDHCPFingerprint & EFFormat

As mentioned previously we've been busy recently on the fingerprint files. Jeff of enterasys has been quite busy on 2 programs this past month.

EDHCPFingerprint - reads in the dhcp.xml file and an exported tcpdump file of bootp packets in text format and will determine the OS based on that. It also has some other cool export features.

EFFormat - reads in all the .xml files that I have built for satori (some that I'm not even using yet) and allows you to modify them. I have a built in version in Satori that sorta did this, but nothing as nice!

Both programs can be found at Enterasys Tools page.

Due to all the recent work on these files we of course found and cleaned up a lot of old fingerprints that were inaccurate or did not provide enough info anymore. There has also been a few new fingerprints added. So the fingerprinting based on DHCP should be more accurate.