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.
Thursday, September 24, 2009
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.
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!
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!
Saturday, August 22, 2009
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.
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.
Wednesday, August 12, 2009
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!
"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]
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]
Thursday, May 28, 2009
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.
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.
Thursday, April 16, 2009
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.
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.
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.
Tuesday, April 7, 2009
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.
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.
Subscribe to:
Posts (Atom)