Weekly Edition
Return to the Security page
| |||||||||||||
Storm worm gains strengthSpam rates are rising, rapidly, with a lot of the blame being placed on the "storm worm." The worm is targeted at PCs, to build an enormous botnet for purposes that can only be speculated upon. Estimates of the size of the botnet vary, but it is probably fair to say that millions of machines are infected. Interestingly, the techniques used to propagate the worm are evolving and some defense mechanisms are emerging. The storm worm has been with us since January, its name stems from the subject of the earliest emails that propagated it, attacking in multiple waves of spam since then. It uses the simplest of all infection techniques: tricking recipients into running a program. Those programs, which, from all reports, only run on Windows, then install various kinds of malware, including programs to connect the machine to a massive botnet. At its root, the storm worm uses various "social engineering" tactics to convince people to either open an executable in the email or to visit a website and download software from there. Several different messages have been tried recently, electronic greeting cards, welcome messages from various "groups" (Wine Lovers, Poker Players, etc.) and the most recent, that claims to be a pointer to a YouTube video that shows you or your family. These messages have been pumped out at enormous rates by the botnet as it tries to grow bigger. Some defensive behavior has been noted as well. When infected machines are scanned for vulnerabilities or malware, they sometimes react by calling in a distributed denial-of-service (DDoS) attack on the scanning machine. The main concern is for academic networks that sit directly on the internet, machines behind firewalls are generally protected, unless a significant part of the botnet also lives there. These evolving tactics and defensive measures are not being implemented for fun, the botnet herders probably have a plan for using such a huge botnet, the only question is: for what? The most likely explanation is for DDoS attacks on targeted sites, quite possibly to get paid to stop, which is also known as extortion. They presumably also get paid to send spam – other than that used to increase their size – but extorting money from sites that depend on traffic is probably much more lucrative. Unlike other botnets, storm's does not rely on a single central server that can be shut down, destroying the botnet. Instead it uses peer-to-peer technology, distributing its command and control infrastructure throughout the network, making it much more difficult to combat. That coupled with the furious spamming and defensive responses makes this the most robust botnet we have seen yet. While this particular attack does not appear to affect Linux users directly, we should not be resting on our laurels. Linux users likely have a higher clue level, overall, than Windows users, but that level is dropping. As Ubuntu and other desktop, newbie-oriented distributions gain ground, the average computer literacy of the Linux community drops. There is no defense, other than educating users, against folks who download random things and run them on their computer. If the storm botnet herders decide they need even more machines for their plan for total world domination, they might just turn to Linux. (Log in to post comments)
Storm worm gains strength Posted Aug 30, 2007 1:18 UTC (Thu) by smoogen (subscriber, #97) [Link] > While this particular attack does not appear to affect Linux> users directly, we should not be resting on our laurels. Linux > users likely have a higher clue level, overall, than Windows users, > but that level is dropping. As Ubuntu and other desktop, > newbie-oriented distributions gain ground, the average computer > literacy of the Linux community drops. There is no defense, > other than educating users, against folks who download random things > and run them on their computer. If the storm botnet herders > decide they need even more machines for their plan for total > world domination, they might just turn to 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.
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.
Storm worm gains strength Posted Aug 30, 2007 3:54 UTC (Thu) by flewellyn (subscriber, #5047) [Link] Technologies like SELinux, properly configured and widely deployed, would do a lot to helpharden our systems against this kind of attack, as well.
Storm worm gains strength Posted Aug 30, 2007 4:44 UTC (Thu) by tzafrir (subscriber, #11501) [Link] Even without SELinux: there should not be a habit of running an executable.You should not be able to easily install an rpm or deb package from your browser.
Note that if installing an rpm or deb off-the-net becomes a common practice, then simply blocking an automated of it will not help - users will soon find the manual procedure for that.
It's a procedure users should know not to try. The problem here is not technological. It is a matter of getting the right working habits.
Storm worm gains strength Posted Aug 30, 2007 8:53 UTC (Thu) by IkeTo (subscriber, #2122) [Link] > You should not be able to easily install an rpm or deb package from your browser.
That is true, but it is harder and harder to see why social engineering will not happen. All it takes is for a page from somewhere like 12.34.56.78:9012 claiming that you can do some interesting stuff (e.g., free access to porn) by installing their .deb or .rpm, and tell their users to just download their file and say "sudo dpkg -i interesting.deb" or "sudo rpm -i interesting.rpm". Voila, a whole bunch of clueless users will join their botnet. And their naiveness will tell them to just run "sudo dpkg -r interesting" or "sudo rpm -e interesting" to deal with the problem, and their package will be successfully cleaned up, only that their ls, rm, or even dpkg/rpm are already replaced by something downloaded from the web.
Ease of use and security should always go together. The current problem of the whole industry is that they don't. The public directly react to ease of use, they don't react to security, so the producers of software are geared towards creating software that are easy to use and compromise. If we start from having "must be secure" as one of our top priority, we will instead install every package in a sandbox, and have dpkg/rpm manage the external interface of the sandboxes, and have SELinux to make sure that the dpkg/rpm database as well as their binaries and other supporting files can only be modified by dpkg/rpm itself or in recovery mode. This is never done.
Counting on education is dangerous too. With the Internet/computer users doubling every few years, it means there are always half the users that have less than a few years experience with Internet/computers.
Perhaps it should be time to start something new, making use of all the fancy security features available, to make sure we have a "easy to use *and* secure" system to offer to the naive mass.
Storm worm gains strength Posted Aug 30, 2007 10:25 UTC (Thu) by MathFox (guest, #6104) [Link] Sorry, security and ease of use are conflicting requirements. A simple example: wouldn't it be much easier if you didn't use the lock on your front door, no need to worry about taking the key with you, no need to put the bag with groceries on the doorstep while digging up the key....I agree with you that security has been undervalued by major Operating System vendors, but even Microsoft is working very hard on fixing that.
About your proposed social engineering attack: the post-install script of the rpm or dpkg can just copy and activate the rootkit that's hidden in the package... nasty nasty nasty. Is there an easy way to prevent these kind of social engineering attacks; nothing that beats education.
Storm worm gains strength Posted Aug 30, 2007 12:44 UTC (Thu) by IkeTo (subscriber, #2122) [Link] > Sorry, security and ease of use are conflicting requirements.
> A simple example: wouldn't it be much easier if you didn't use the lock on your front door, no need to worry about taking the key with you, no need to put the bag with groceries on the doorstep while digging up the key....
If you want the easiest to use system in the world to be rock secure, you are of course toasted. But if you want reasonable security in a system reasonably easy to use, there can be some discussion. Of course, adding development cost into the equation makes it harder. But to say "I only cater for the uneducated, some functionality can be forgone if most Joe users don't need them" can make it a easier.
> I agree with you that security has been undervalued by major Operating System vendors, but even Microsoft is working very hard on fixing that.
If you can enlighten us about what has been done by MS to prevent social engineering, it can be very constructive.
> About your proposed social engineering attack: the post-install script of the rpm or dpkg can just copy and activate the rootkit that's hidden in the package... nasty nasty nasty.
By "every package is in its sandbox" it means even the post-install (or whatever) script is running in its own sandbox, and if a program has been installed in global space for others to run, that program is under a sandbox that never include more than the combined power of the user and sandbox of that package. Everything, like installing a file in "/bin" or creating a cron job, can only be done under the management of dpkg/rpm. Other tweaking might be required, this need to at least give dpkg/rpm a perfect picture to clean up any mess produced by any package.
Of course, this is just out of my imagination. Any system that provides equivalent security is probably just as useful. It is not easy to develop such a system, at all. One must think about how programs are going to interact, how they are going to access user data, and there must be some serious research on how these things cannot be turned into attack vector. In a world where the threats are not there or are seldom seen, these will never happen. But in a world where threats are the norm, there are definitely incentives.
> Is there an easy way to prevent these kind of social engineering attacks; nothing that beats education.
Education can be "easy" to a single individual, it is hard to ensure education to a huge population, all of them from different countries and hence different law systems and values. In fact I believe it isn't going to work at all. Even for well educated people, it is sometimes very tempting to install something that they really shouldn't, and it can be real hard for them to know whether something is safe to install. And the black hat only need a few percent of the network population to have made a wrong decision before they can build a huge botnet. In such hostile environment, we simply cannot count on 90% of the people won't make a wrong decision during at least the first half of the life of their OS install!
Problem is, people are frequently asked to install a program, to the point that most people will not think that it is a security problem. Except it is. And people frequently see packages floating on the web, and many claims to do useful things that they want to do. And in most cases these claims turn out to be true. To the point that most people will trust that the thing they found will be among them, except they might be wrong. If we create a system to "look safe", it needs to actually be safe. Our current systems "look" safe, but they aren't.
Storm worm gains strength Posted Aug 30, 2007 19:24 UTC (Thu) by oak (guest, #2786) [Link] > that program is under a sandbox that never include more than thecombined power of the user and sandbox of that package.
So you would be only securing the system, not what user has? (user doesn't
> And people frequently see packages floating on the web, and many claims
And currently Ubuntu is educating users with its sudo system that whenever
Security by obscurity... "our system is more secure because it doesn't
Storm worm gains strength Posted Sep 1, 2007 8:42 UTC (Sat) by IkeTo (subscriber, #2122) [Link] > So you would be only securing the system, not what user has? (user doesn't> care about "system", they care about their own data, the data to which > they have access)
Then they should. If the system itself is not secure, we don't have a basis to talk about data security. If the system is compromised, you can trust the system to recover from neither the system nor its data. If only user data is damaged you can still trust the system. Also, since distributions like Ubuntu enpower users without much previous Unix experience or knowledge to install a Linux based system, it means they are in charge of the system, so there is no "system administrator" but themselves to keep the system in a secure shape. But how distributions can make sure their users are capable to do so? The answer needs to be: By making it simple enough. Of course the user *also* care about data security. That is very much the same argument, albeit much more difficult to provide without very much education.
> And currently Ubuntu is educating users with its sudo system that whenever
I actually do not use a Ubuntu system regularly, I have installed one and used it for less than a week. So I don't perfectly know the security implications, even though I read a lot about it. On the other hand, popping up the password dialog is no longer unique to Ubuntu. Fedora does the same. The only difference is that they prompt for the root password rather than your own password.
So Fedora is more secure *because* it prompts for the root password instead of the user password? When a Fedora (or even Debian!) system asks for a user password? What is the difference that the system trains the user to distinguish? The answer: a Fedora user prompts for the user password only for (1) login, and (2) change user password. The system thus trains the user to distinguish system access and login/password changing. What a good deal... even the worst naive idiot can distinguish them! Bottom line, if a home user using Ubuntu can be tricked to type his own password and install a malicious .deb package, the same user having switched to Fedora can be tricked to type the root password to install an equivalent malicious .rpm package.
My belief is that the system design should distinguish two types of activities that the user can be expected to do: (1) those that the users are expected to do from time to time and are easy to do, and (2) those that are hard enough to do that the user will never do casually. (1) should be safe enough that the action cannot jeapodize the system at all; and (2) should be rare enough that a casual user need not use them at all. Since Ubuntu (Debian, Fedora, whatever) is a system that allows third party packages, and their target is to make it easy, it is in class (1), so it means they should be rock solid. This is perhaps a big dream, but having a dream is better than having no dream.
User education is a dumb idea Posted Sep 11, 2007 8:42 UTC (Tue) by koide (guest, #22687) [Link] We should stop pretending that user education will solve all our problems. People don't even want to be educated. We should design and implement systems that'll work for the uneducated and dumb and stay reasonably secure. It's not impossible.Ranum's article is pretty interesting in this regard and I rather agree with him. V.
|
|||||||||||||