David LeBlanc wrote: > I've got an overall problem with 'exploits' that require admin access to > run - kind of like worrying about the windows being locked when the > front door has been successfully hit with the crowbar attack. If you > can get to be admin, you can modify the OS, and from there, you can do > anything to any user. I agree with David, in that exploits the require admin/root to gain admin/root are pointless. If you can get the admin to put +s on bash, well, yes...the system is compromised. HOWEVER, this particular problem is interesting. Let me detail a situation in which I can use it to my advantage: I use an exploit to gain access to the box as administrator rights, or I get the admin to run something, whatever. I'm not concerned about 'how', but moreso that it did happen. I now have two routes to take: 1. Grab the SAM, and spend the next 1526 years cracking it on my 486. Bummer if they use syskey. 2. Use the above vulnerability to immediately get the plaintext administrators password. I then continute to compromise other boxes in the domain. As a consultant, time is money. As a hacker, the more time it takes, the more chances of getting caught. Being given the plaintext password, regardless of being admin, is a no-brainer if I don't already have it. So, to further your analogy: > I've got an overall problem with 'exploits' that require admin access to > run - kind of like worrying about the windows being locked when the > front door has been successfully hit with the crowbar attack. If you It's akin to grabbing the house keys once inside--no more need for the cumbersome crowbar. And retrieving the plaintext password is much more stealthy than modification of the OS, installation of trojans, etc. Assuming the tracks are covered and there's no evidence of breakin, there is no evidence that the admin password has floated out. Just a different point of view, .rain.forest.puppy.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:21:10 PDT