| |||||||||||||
Storm worm gains strengthStorm worm gains strengthPosted Aug 30, 2007 15:56 UTC (Thu) by smoogen (subscriber, #97)In reply to: Storm worm gains strength by addw Parent article: Storm worm gains strength
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.
(Log in to post comments)
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.
|
|||||||||||||