Slashdot Mirror
Ongoing Linux/Solaris Compromise Epidemic
An anonymous reader writes to point out that Stanford's Information Technology Systems and Services "has written a summary of a series of compromises that have been happening at universities, research institutions, and high performance computing centers, for the last month or more. The attackers are using known vulnerabilities in Linux and Solaris, along with compromised user accounts, to gain access and control of systems, from standalone servers to HPC clusters ... (the attacks are still ongoing)."
a variety of local exploits, including the do_brk() and mremap() exploits on Linux
In other words, Stanford doesn't keep its Linux boxes up to date. These exploits have been fixed. Linux too requires maintenance and patching, not just Windows.
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
It says that good passwords are a good defense.
We know this.
No more default last 4 digits of SSN as a password.
Make them use something more secure! And disable telnet, for goodness sakes.
Inconvieience (sp?) your students in order to secure your system. It's all fun and games until someone uses a rootkit to play with GPAs.
Jay | http://oldos.org
on just how widespread this attack really is. The story IS HERE
...because you never know who you're dealing with.
What gets me is that you can tell the white hats and black hats are both lazy.
If the sysadmins had actually patched their servers with the appropriate security patches the "hackers" would have never gotten in, in the first place. If you read the counter measure section this isn't anything new that they shouldn't be doing every day and enforcing.
If you look at the section entitled Evidence of compromise you can see that the people breaking into the systems are leaving a pretty big trail to follow. In my job, when customers start complaining that their servers are working quite right, when you take a look at whats going on you can see a root kits been installed. The whole idea of a root kit is to cover your tracks. If these guys did a better job you'd never know you were hacked. Its quite sad really. Laziness is the biggest security problem if you ask me.
How does that differ from the worms which get released for Microsoft almost a year after the patch was released? I hear people railing Microsoft all the time for not 'getting it right the first time' when THAT happens...
"If we let things terrify us, life will not be worth living."
- Seneca
If more sysadmins installed this, perhaps we wouldn't have problems with so many Linux compromises? Of course it's no substitute for patching, but seems like a good additional security measure.
This is from the gnu.org software directory
The exploitation of buffer overflow and format string vulnerabilities in process stacks are a significant portion of security attacks. 'libsafe' is based on a middleware software layer that intercepts all function calls made to library functions known to be vulnerable. A substitute version of the corresponding function implements the original function in a way that ensures that any buffer overflows are contained within the current stack frame, which prevents attackers from overwriting the return address and hijacking the control flow of a running program.
The true benefit of using libsafe is protection against future attacks on programs not yet known to be vulnerable. The performance overhead of libsafe is negligible, it does not require changes to the OS, it works with existing binary programs, and it does not need access to the source code of defective programs, or recompilation or off-line processing of binaries.
No Worries. I've already changed it for you.
My favorite phrase: You have 5 Moderator Points! Use 'em or lose 'em!
Now, my opinion of MS is not that great, but this just seems wrong.
Regards,
John
Falling You - beautiful
I was looking at one of the Solaris vulnerabilities, and I saw "sadmind".
I thought it was some kind of nasty name for a hacking daemon - until I found out that sadmind was the "Solaris ADMIN Daemon"
READY.
PRINT ""+-0
Heh, I'm running Windows 95. I figure by now the hackers are just bored of hacking me.
Security through boredom, my new secret weapon take th^454&*%2^$^^^B
Your CPU is not doing anything else, at least do something.
Why not?
Well, what happens if that system just happens to be the payroll system, for example? What happens if the patch just manages to break the system so that the fortnightly payroll run doesn't happen? What happens when that money, which you expected to be in your bank account, doesn't appear? What happens when your mortgage provider goes to pull out your fortnightly mortgage repayment, and finds that there's no money in there to grab?
It isn't as simple as "Here's a patch, you're now secure as long as you apply it." We're talking real-world systems, with real-world conflicts and requirements. If you step outside the known and tested, you're liable to break things.
In other words: have a second system which you can throw patches onto and pound away on for a week or two, to make sure that those patches don't break anything important. Then throw the patches onto the live, production system. Doing it any other way could cause serious problems.
Sometimes, it's a case of having a choice: either you're secure, or your business is functioning. This is not a choice that I would want anybody to have to make, but you need to know that that choice is entirely possible, every time a new patch is released from your vendor, whether that vendor be Microsoft, Sun, IBM, HP, SGI, Apple, or Linus. Note that I'm not talking about deliberately (or through slacking off) avoiding application of patches; I'm talking about verifying that the patches still let you function as a business.
Or, in other words: IT exists to serve the business. The business does not operate to serve IT. Most of the time, there is no conflict between the two, but when there is, you need to make damn sure that the right one wins.
Yeah, I've been involved in some of the staff discussions at one of the compromised institutions. The vulnerabilities listed seem old because these attacks have been ongoing for a while now. Some of those vulnerabilities were actually discovered originally in relations to this situation. What's important to realize is that this situation is very unlike what's happened to windows machines recently. Most of the Windows intrusions have been remote exploits via services. We've been facing primarily local-root exploits. These people are breaking into accounts--usually by password sniffing, key-stroke logging, etc from other compromised machines. Those accounts are then used to launch various known (and previously unknown) local-root exploits. These people appear to be after other systems for an unknown purpose rather than just "games" or DoS attacks. Most of the targeted institutions have substanial DARPA/government research contracts. It's reasonable that these attacks are being used to steal information. The focus has not been on High Performance Clusters but rather on interactive clusters. These people are after information not computing power.
Here is a list of some things that I feel are worth considering:
:). Next configure swatch to alert you upon recieving such messages! Of course you can always use perl or even grep -v to parse logs, but for repeated use I think a specialised tool would save you some trouble in the long run.
1. Patch your system! As soon as a patch comes out, get it applied and reboot if you have to! Also, stay up to date on security issues by subscribing to mailing lists that are related to the software your using. One good general purpose site is cert.org. Keep in mind that while mailing lists are great ways of being notified, they arent fool proof. If your subscription expires and you dont know about it, you wont be exactly up to date in the community now will you?
2. Use grsecurity. This is a kernel patch that is briefly lagged behind official Linux kernel versions. It has many great features for protecting against stack attacks/buffer overflows. ie: Those latest greatest scripts your local script kiddie just downloaded wont likely do anything against you since special addresses are randomised. It can also hide files on your computer such as intergrity checkers so nobody except you know they exist. Plus it can stop insert code into a running kernel by making kernel memory readonly (which btw, would have prevented at least one of the attacks they mentioned).
3. Install a filesystem intergrity checker. Aide, integrit and tripwire all come to mind and essentially all do the same thing but with different config file syntax. Besides, how can you tell if a file is changed if you dont actually check? Also, dont forget to hide the existence of this program using something like grsec's gradm filesystem ACL util and be careful of automating checks in the crontab!
4. Read a good linux securing article. One such article I have read is called Securing & Optimizing Linux: The Ultimate Solution. It will teach you how to lock a system down a fair bit and how to remove unused/unneeded services from your computer.
5. Watch those logs! Log files provide a wealth of information, but administrators rarely check them (well, not all). If you dont know what a log entry means, research it, or else you may be looking at an attack and not even realise it. Now I know some of you are thinking I am nuts considering just how many logs even a small system generates, but there are tools to help you. One way is to use a program called swatch (a perl script). It can parse existing and old archived log files using a perl regex syntax and trigger actions based on found text. Start by configuring the system to ignore any log entries that are known to be friendly and show you everything. Then slowly eliminate each friendly entry one at a time. What will be left is a list of purely evil enteries
Now I know I could go on forever with suggestions, but I think that these few things should give anyone a kick in the right direction. I hope this has been helpful.