| |||||||||||||
Storm worm gains strengthStorm worm gains strengthPosted Aug 30, 2007 1:18 UTC (Thu) by smoogen (subscriber, #97)Parent article: Storm worm gains strength
> While this particular attack does not appear to affect Linux
In my experience.. "likely have a higher clue level" has never been true for Linux users over say any other population. The majority of people will click on links that they get in an email especially if they "trust" the name that the email comes from (say Monster's recent problems).
I have seen where this has been used to great effect against targeted users on Linux and Unix systems. An old trick to make sure you got shell access on a very large system later was to change the MOTD and tell people to run a command to verify account usage. The percentage of Unix savy people who would run a program called "RunMe" that appeared in their Home directory does not seem to be different than it was 10 years ago. And if the program asked for them to verify their password and useraccount for systems maintenance.. the same percentage would fill it out. The percentage of people who report such activity is not greater than it was 10 years ago either :/.
As put in the last sentances.. the only things that help are education and continual testing that people are learning from the education.
(Log in to post comments)
Storm worm gains strength Posted Aug 30, 2007 1:40 UTC (Thu) by rickmoen (subscriber, #6943) [Link] smoogen wrote:An old trick to make sure you got shell access on a very large system later was to change the MOTD and tell people to run a command to verify account usage. The percentage of Unix savvy people who would run a program called "RunMe" that appeared in their Home directory does not seem to be different than it was 10 years ago. Pardon me if I'm being literal-minded, but how did that executable get into the target user's home directory, if you didn't yet have shell access on his/her system? And wouldn't you already (likely) possess at least as much privilege as you could trick a regular user into giving you, if you were already permitted to write files in his/her home directory? (Modern *ix systems don't default to other groups having write permissions to a user's homedir, anyway.) You probably mean tricking a fellow shell user into running an untrustworthy executable, and then social-engineering him/her into disclosing confidential data to that program. If "." isn't part of $PATH, this tends to be at least a little challenging, in the sense that it's difficult to get users to run /tmp/passwd under the misconception that it's /usr/bin/passwd. (The user would have to have "." in $PATH, or you'd have to be able to convince him/her to set a shell alias of your devising, or something like that.) If you're a good enough social engineer to convince a user to run /tmp/passwd knowing that it's not /usr/bin/passwd (or the user is just that gullible), and he/she's willing to pass confidential data to that executable anyway, then there's no helping that person. Rick Moen
Storm worm gains strength Posted Aug 30, 2007 8:35 UTC (Thu) by ekj (guest, #1524) [Link] 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.
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.
|
|||||||||||||