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
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.
You're joking.
All the vulns mentioned have patches/fixes/replacements for the faulty code.
The System Administrators are at fault FOR NOT MAINTAINING THEIR SYSTEMS PROPERLY.
If you believe your Unix computer has been affected by these intrusions, please contact the Information Security Services office (650-723-2911 or security@stanford.edu). Please include the name or IP address of the affected machine, as well as any compromised userIDs.
Never mind the compromised machines. Let's try social engineering instead. I know! We'll make a security alert, get it on Slashdot, and the poor trusting souls will beat a path to our POP3 account!
Seriously, you might as well just hand them your hard drive and credit card number.
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
Now that said, you have an interesting slant on ethics. By that mindset, a burglar is perfectly entitled to break into your apartment because your door could be kicked in. A theif can swipe your radio because, hey, it was only glass between him and what he wanted.
Yes, there is a certain amount to be said for not painting a target on yourself. But regardless of how much you "had it coming" it's still a crime to break into your dwelling, steal your property, or damage your person or posessions. System intrusion is a crime, and a matter for law enforcement.
"Learning is not compulsory... neither is survival."
--Dr.W.Edwards Deming
There is a well founded fear many Windows admins have about MS patches. They tend to break things. Patch Win2k, and MS-SQL does not work upon reboot. Or that third party medical charting software suddenly does not work.
Windows is very complex (many would say "too complex"), and certainly suffers from the "integration" of its parts. Therefore, unintentional side effects of patches are envitable. With Unix(ish) systems, the descrete parts can be patched, well, descretely. You can patch Sendmail, or MySQL, or OpenSSL all by itself (although sometimes you must recompile applications that depend on shared libraries, such as OpenSSL).
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.