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.
Subscribe to:
Posts (Atom)