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.
Subscribe To
Posts
All Comments
Thursday, April 16, 2009
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.
Tuesday, February 24, 2009
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
Looks like the next release is due out in June of xprobe
Sunday, February 22, 2009
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
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!
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!
Saturday, January 10, 2009
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.
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.
Subscribe to:
Posts (Atom)