| |||||||||||||
|
| |||||||||||||
Storm worm gains strengthStorm worm gains strengthPosted Aug 30, 2007 8:35 UTC (Thu) by ekj (subscriber, #1524)In reply to: Storm worm gains strength by smoogen Parent article: Storm worm gains strength
If someone has power to change the MOTD and to place executable files in your path, then they already *have* root-access, so it's unclear what exactly this should achieve.
(Log in to post comments)
Storm worm gains strength Posted Aug 30, 2007 9:17 UTC (Thu) by tialaramex (subscriber, #21167) [Link] Locally, true root privileges are all powerful but...
* Root privileges tend to be squashed over the network, you probably don't have any privileges on other machines directly from this account.
* Root can't do the impossible. Cryptographically protected SSH keys can't be unprotected by fiat. MD5-salted-hashes can't be unwound either.
* Privileges to write to MOTD and add or replace some executables don't add up to root privileges. Particularly in an SELinux system, an attacker might be able to read from & write to some parts of the filesystem but not spawn their own processes or make connections over the network.
* Your nefarious activities may be logged without you being able to prevent it, or tamper with the logs after the fact (network logging, tamper-proof external logging) while user actions would go unremarked.
All of these things make it attractive to capture real passwords to go with the usernames stored in the authentication system, valid SSH passphrases for the keys stored on the system, that sort of thing. These allow you to become just one of dozens, hundreds or even millions of users of the system, and their credentials tend to be valid across many different machines on the network.
Storm worm gains strength Posted Aug 30, 2007 9:30 UTC (Thu) by addw (guest, #1771) [Link] Yes - but if someone could have changed /etc/motd, then they could have changed the login or ssh programs to record your password anyway.
Storm worm gains strength Posted Aug 30, 2007 15:56 UTC (Thu) by smoogen (subscriber, #97) [Link] Well first.. this originally was a user and system administrator education test to see if telling people to not give out passwords etc was working or not... and if system administrators were watching the systems they were supposed to be.
The second issue was to avoid tripwire or similar tools. These tools usually cover exectubles like ssh, login etc.. but do not cover motd if the system changes it a lot as it is not something you are normally worried about it changing its checksum. And normally they cover finding new executables in /usr/local/bin etc so you want to be careful.. but they usually do not cover home directories.
With 10 years experience.. we could just change .bash_profile to include $HACKER_HOME/bin on everyone's home directory and have them run passwd or other rooted binaries... However the issue was more on collecting information on how user education was going versus actually doing bad things.
Storm worm gains strength Posted Sep 1, 2007 9:09 UTC (Sat) by drag (subscriber, #31333) [Link] That still doesn't make a whole lot of sense.
If, as a system admin, your changing the MOTD and telling people to run a program you've already placed in their directory wouldn't it be a reasonable assumption for a average person that this sort of thing is legit? That's sorta how things are suppose to work.
Like the other people said, if you got this far you already own the machine and you don't have to do social engineering to get passwords. A simple keylogger is all you'd need. Something simple-stupid like a custom PAM module or hacked ssh server.
Sure, a clever admin might be running Tripwire, but to do that properly the administrator would have to take the machine down time to time to perform the Tripwire audit. This is very unlikely done on a busy multi-user system, and if it is done it's not done very often. Any sort of checksum-style IDS would be fairly easily subverted if it's running on the same machine it's suppose to be checking.
Sure sure people should be fairly paranoid and know that admin will never ask for a password, but this isn't really fair. If you want to test user education then you'll have to do something that is actually relevant to computer security.
Now dropping a binary into /tmp and then emailing other users from a user account about how cool the game it is and everybody needs to try it out... now that would be something that would be a much more effective test.
Or another test would be for a admin to actually request passwords, either through chat or email. That would also be effective.
Storm worm gains strength Posted Sep 4, 2007 17:32 UTC (Tue) by smoogen (subscriber, #97) [Link] Ok I am not communicating very well.. the issue was the following:
The people who made the changes were not the system-admins of the system, they had to attain that via other means. They were basically asked by management to be Internal Auditors. Their role was to check that internal training was working and how on the ball the system administrators were. They made the MOTD in a format that didnt look anything like the standard ones (without downtimes, rules of use, etc). The rule of engagement was to see if a 'breakin' was found, how soon, and how soon the auditor/pentesters could get back in through other systems etc. From what I understand, they used getting users to tell about themselves because they saw that login, telnet and such were watched and would be replaced by clean binaries every 10 minutes or so.
Did users use the same password over and over again against policy? Did system administrators report malicious behaviour and what was done to remove it and change current methods. Did users follow other training and report suspicious system behaviour. Things like that.
Storm worm gains strength Posted Aug 31, 2007 0:57 UTC (Fri) by giraffedata (subscriber, #1954) [Link] * Root privileges tend to be squashed over the network, you probably don't have any privileges on other machines directly from this account. I guess that's true for some definitions of "directly," but none that matter. The point is that if you have root privilege, you don't need to trick someone into sending you his password. You can simply setuid() to his uid without a password. * Root can't do the impossible. Cryptographically protected SSH keys can't be unprotected by fiat. MD5-salted-hashes can't be unwound either. Getting someone else's login password doesn't help here either.
Storm worm gains strength Posted Aug 31, 2007 15:13 UTC (Fri) by smoogen (subscriber, #97) [Link] It does if you want to be able to get onto the system later. Most of the time hackers are looking for multiple ways to get back onto a system.. and while leaving backdoors is one method.. another is user passwords.. and user passwords are a lot harder to deal with in environments that do not have centralized login management.
|
|
||||||||||||