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.
Subscribe To
Posts
All Comments
Saturday, August 22, 2009
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.
Sunday, March 22, 2009
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.
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.
Tuesday, March 17, 2009
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.
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.
Wednesday, February 25, 2009
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.
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.
Subscribe to:
Posts (Atom)