frameloss

Making MyNmap more useful: importing scans

Originally MyNmap wasn’t intended to act as a tool to automate scans.  The real goal was to get the grid display with highlighting of what is new.  Looking at tons of Nmap scans makes my head spin, and digesting that information to determine what is new is best left to a computer.

Because of this, you don’t necessarily need to use the scheduling interface to get your nmap scans into MyNmap, furthermore if you have two scans and want to compare differences between the two–you can load them in succession and be able to analyze the differences.

It is quite easy, when you run your scans use the “nmap -oX” flag.  Then copy the XML file into the “/usr/local/mynmap/scans” directory with the file extension “new.xml“.  If you don’t have the “new.xml” at the end of the filename MyNmap will ignore the file (this is to stop it from trying to process files that haven’t been completely written while a scan is in process, sure I could have used another directory for that, but I didn’t.)

I use this at work so that I can visualize scan data from external networks, using cron, a shell script, and SSH allows me to use an external machine to keep an ongoing view of what is in our public accessible network space.

I also use a script that allows me to alert on when new things appear in the DMZ based upon scan results–I will post how that works here soon.

Windows 7 64bit == fail.

Microsoft recently release the release candidate for Windows 7. Unfortunately, they forgot to add standard CDROM drivers (and wonder why people complain about their software.) After booting, it states that it can’t find the CDROM driver (on Vista it uses cdrom.sys, so it isn’t like I am using some sneaky unsupported DVD drive.) Very classy, I am quite impressed! So far I have run half a dozen operating systems on this laptop, and Windows was the first to not be able to use the DVD drive–after booting from it. I was expecting video driver problems, or maybe wireless driver problems, but something as basic as not being able to read the media it just booted off of is impressive!

MyNmap on ESX?

I have received a few requests for an ESX version of the MyNmap virtual appliance.  It turns out that getting it running on ESX is actually pretty simple.  Instead of being redundant, there are great instructions over at Tony Vegue’s website.  Thanks Tony!

2600 Article: Don’t steal music (or how to catch an iPod thief using forensics)

I said I would post this once it was published, and a few days ago I picked up the latest copy.  This article is a bit longer than what 2600 put out, because they were space limited (yes, I tend to be verbose.) So here it is.

Music is important, especially in a noisy office.  There is a girl that sits a few feet away in a cubicle, and she talks to herself all day.  As if it wasn’t bad enough to be stuffed into a cubicle but the constant chatter is maddening.  Honestly there are days that if I didn’t have my headphones on I could quite possibly lose it.  Because of this I am usually very careful to protect my iPod like it is made of gold–and if you look at the RIAA’s assessment (cost estimate of imaginary property? Huh?) of the value of the songs on it, it is worth more than gold!  But that is a different article.

It is a good place to work, they pay people well, and treat employees better than most.  I wasn’t too concerned when on my way home after work when I had realized that I left my iPod plugged into my Apple at work.  Of course, you being an astute reader, already know what happened.  The next morning arriving at work sleepy and slow, I was half way through the first cup of coffee before realizing that my music player was gone!  (Cue dramatic music.)  Of course I am always misplacing things, so I spent the next half hour tearing my cube apart looking for my iPod.  Nothing.  Crap.  Now I am angry.

I work in IT security, so my first reaction is to start putting together a incident timeline.  When did I leave the office, who was still there working as I was leaving.  It didn’t make sense, there was only a couple of folks left when I went home, and I KNOW that they wouldn’t steal from me.  So, maybe it was just a prank–there are a few folks that might find it funny to alarm me (and probably owe me for messing with them in the past.)  Without tact I ask them if they know anything about my iPod and let them know that if it was a prank that it was cool, but I would like my iPod back.  No luck; I believe them when they say they didn’t take it, but would add it to their list of ways to annoy me later.  Everyone I talk to accuses the cleaning crew.  I hate this response, I find it offensive for several reasons.  First, it is racist, even if not overtly.  Most of the cleaning crew are hard-working mexican immigrants that can not risk losing their job, but I know what these guys are thinking as they make the accusation.  Second, it is just too convenient, it is a typical kneejerk reaction–just like blaming every network problem on an IDS or firewall.  People are too quick to place blame and that I find repugnant, especially if they are in a place of power.

Then it strikes me, I have a critical peice of information sitting in my lap and it just might get my iPod back in my hands.  It was plugged into a Mac, not my windows box, woohoo–Unix creates log entries when a hard disk is unplugged!  Sure enough, the /var/log/system.log has a bunch of the following:

Sep 10 22:31:23 computer kernel[0]: disk2s1: media is not present.

So I call up the physical security folks and let them know that there was a theft.  But, that I know what time it happened and because it was at night it should be pretty easy to figure out who did it.  The cleaning crew comes through at 6pm (quite annoying actually) and are usually done by 8pm.  So there should have been no-one in the office around the time my iPod grew legs, if anyone was there: they would look awfully suspicious.  They say they will get back to me, but since I know their manager I give her a call–to ensure that key card access logs get reviewed and that the security camera recordings are preserved.  About half an hour later I get a call saying they know who did it and will handle them later that day when they are scheduled to work.  Sweet.

The next morning the manager of the physical security group stops by and returns my iPod unharmed.  And she explains that it was a member of the cleaning crew that had come back after his shift to steal electronics.  I still feel justified in not having the standard knee-jerk reaction and would give them the benefit of the doubt in the future too!  He was given the opportunity to return the stolen property or we would press charges.  He immediately returned the iPod during the interview.  Of course the guy lost his job.  The moral of the story is that stealing music is wrong ;-)

This wasn’t the first time an iPod had been stolen at the office, and it wasn’t the last either–the things are like little stacks of cash laying around, and to someone desperate for money the temptation is just too much.  Because of that I decided to do a bit more research and look at what it would take to get the same results but from a Windows box.  Unix users have it easy–significant happenings with block devices, such as a hard drive, at the kernel level are logged by default.  For most Unix-like systems you can find these in /var/log/dmesg (or by running the dmesg command.)  But, alas Windows is the dominant OS out there and is likely to remain that way for a while.  The logging on Windows isn’t that great.  Sure it is configurable, but it somehow never seems to have the settings in place beforehand that make this type of work easy.  I found a way to get the same results on Windows XP, under the right circumstances.  Here is what I found under XP Pro SP2, it still seems to work on SP3, but does not work on Vista–sorry, as soon as the iPod is synced the disk is disconnected and you can only get a timestamp of when it was synced, not removed.

A list of forensic evidence retained pertaining to disk removal events in XP Pro, (or catching an iPod thief.)

User was logged in, and the iPod was removed. The system _has_not_ been shut down:

• When iPod was unplugged

• When iPod was last plugged-in

net use \\<hostname>\ipc$ /u:<administrator>

Substitute appropriate values for the <hostname>, and <administrator> account name.
Next you can perform the query:

logparser -i:reg -o:csv “select * from \\<hostname>\HKLM\SYSTEM\CurrentControlSet\ where path like ‘%iPod%’ order by lastwritetime desc” -e:1000 > outfile.csv

You should, once again, substitute an appropriate value for the <hostname> listed above. Also any line breaks should be removed when running the actual command.

Command options explained:

• “-i:reg” instructs “LogParser” to use the system registry as a source.
• “-o:csv” specifies that the output should be comma separated values. This allows for easier analysis within a spreadsheet program.
• “select * from \\<hostname>\HKLM\SYSTEM\CurrentControlSet where path like ‘%iPod%’ order by lastwritetime desc” Is the actual SQL query. It looks at all values in the registry, where the path name (not actual key values) has the text iPod. It then returns it sorted in a list with the most recent entries first.
• The HKLM is shorthand for HkeyLocalMachine.
• To see what other fields can be queried you can run “logparser -i:reg -h”
• There are three subkeys below CurrentControlSet that contain relevant information (Control, ENUM, and Services,) which is why the query is performed at such a high level within the registry.
• The string ‘%iPod%’ can be changed to represent another device, such as a USB thumb drive. You can view the “HKeyLocalMachine\SYSTEM\CurrentControlSet\Enum\USBSTOR\“ area of the registry to see what other removable USB devices (or substitute USBSTOR, with SCSISTOR for SCSI) have been connected, and experiment with the name assigned by the device manufacturer to find the evidence you need. Be sure to encapsulate whatever string you need with a single-quote and percent signs as shown in the above example, surrounding the string “iPod”.
• “-e:1000” instructs “LogParser” to quit after 1000 errors (a number intentionally higher than likely to ever happen in such a restricted query.) If “LogParser” is not given this instruction, errors will not appear in the output, and it is important to see the errors in case you are not seeing all of the necessary data.
• “> outfile.csv” specifies the file name where information will be stored.

Opening the CSV file in your choice of spreadsheat program will allow you to sort the data by access time.  Sort by descending timestamp and you should be able to see when the registry key was last written–this is when the device was unplugged.  I hope you are as lucky as I was and get your iPod back too!