Slashdot Mirror
Linux Getting Harder To Crack
AlanS2002 points out today's article from Iain Thomson on vnu.net, which says that "Linux systems are getting tougher for hackers to crack, security experts have reported today," summarizing "A study conducted by the Honeynet Project has found that it takes about 3 months before a unpatched Linux machine will be owned, compared with about 72 hours in the past. According to a report on the study default installations are now more secure with less services enabled by default, added to this is newer versions of software such as OpenSSH being more secure. Interestingly Solaris 8 and 9 did not fare so well."
I am happy to hear this, as I run a linux box. These reports are mostly moot, however, because a router will deter all but hackers with a reason to pwn your box, and there is little reason to do so to a home computer. My unfirewalled SP1 Windows XP box has faired similarly to my linux box, with just a bit of spyware.
My day job's in a big hosting facility, and it was a surprise when setting up RHEL 3.0 that it had by default quite the restrictive iptables ruleset which let very little besides SSH through, and pam_tally was set up in the install, so 5 login failures locked out the account.
Quite refreshing to see, since I was doing the install for a customer who'd decided to go for a reimaging because their machine had been compromised.
500GB of disk, 5TB of transfer, $5.95/mo
De John Wisniewski - a memorial
The game began at 10 a.m. on Friday. The VMS machine on the Green team was configured with Apache web server. As we are aware, VMS is an extremely secure operating system. While many of the other boxes in the room, mostly Unix, linux, and forms of windows, and even a Macintosh, were compromised and subsequently attended to by their masters, the VMS system remained intact. Here is where a real security issue comes into play.
We were very confident of the VMS box, and a lot of interest was generated by it. In the spirit of spreading the good word and educating the people about VMS, we ended up answering a lot of questions about VMS, and showing how the machine automagically added user accounts, and demonstrated the various terminal games and web pages which had been created. We were also aware that, in this crowd of 5000+ hackers, someone might be able to weasel their way into the machine if any security measures were taken lightly.
As events would have it, we had an issue, which we did not understand, with the operation of the serial port used as the operators' console. At 2:00 a.m. Saturday morning the system manager decided to telnet to the box in order to do some routine checks. Using Telnet in an environment with 5000 hackers on your network is an insecure method of administering a computer system. A lot of people were fascinated by the VMS system, and had asked many questions about it, shoulder-surfing the console operator, who of course answered their questions in this friendly game of an environment.
One of the hackers who had been showing a lot of interest in the VMS box happened to be sniffing packets from the system manager's PC. He discovered the password to the account, a simple procedure any 13 year old kid can pull off with ease after a little social engineering. The hacker logged in, and placed a couple text files (his mark for points) in the manager's user directory, and then notified the system manager in order to claim the points. There were no points for hacking the machine because the files were placed in a user directory instead of the `root' VMS directory. He was awarded 10 points for social engineering.
Was this an instance of VMS being hacked? No, it was just a circumstance where a privileged login session was passed in plaintext over a network with 5000 mechanics, social engineers, and hackers on it. By using a telnet session on an open network, the system managers' login information was freely made available to any who cared to record it. Giving away your login info in this way to a hacker who subsequently uses it does not constitute being hacked, it constitutes an error in security procedure. The thought of improved security, such as some level of encryption for telnet on VMS, immediately comes to mind. Be very afraid.
The Alpha was disconnected from the haxor network, the serial port issue (our fault alone) was fixed, and the network was reconnected. The incident did not repeat, nor did any hack whatsoever of the VMS system take place during the event. The hackers bombarded the box with telnets and ftp attempts to every bizarre port number imaginable, obscure ports in the 40,000 range and more. The word of the early-morning incident had spread, and those seeking glory and a reputation besieged the box.
Another kind of social engineering, involving a clever lie intended to trap those who would think it cool to hack the NOC was presented in this way: People came by, with an IP address, saying, "here is the IP address for the NOC, have fun". It was really an outside IP address, and this was a ruse to make those who listened loose points for attacking sites outside the defcon network. Hacking outside the CTF network was forbidden.
As the game progressed, the goons announced that there were not enough hackers (huh? The tables were *full* of people). To make it more enticing, the point award for placing your mark in the root directory of a server
what?
is this a joke, or did you reverse your 's? Either way, you just made Linux much easier to crack than glass...
-Ryan
AUWYHSTOT (Acronyms are Useless When You Have to Spell Them Out Too)
Well they list it in the list but give no data on it what so ever. So one is to assume FreeBSD was never hacked from the data presented (or lack thereof). Way to go BSD!
i have said it before and i will say it again: only because more and more people stand up to state how superior and ultra-safe linux is, won't necessarily make it so!
...) ...). therefore it is as questionable a time to glorify linux as it will ever be.
if it is indeed true what this study claims then i am the first to applaude the kernel guys and the distribution makers.
but there are facts that won't change:
- software monoculture is BAD (no matter what the monoculture consists of)
- linux is NOT the safest alternative out there (compare *BSD, VMS,
- there have been an alarming number of exploits as well for the kernel itself (local root exploits, anybody) as also many exploits for user land applications (mplayer, mpeg123, mozilla,
SECURITY IS A PROCESS NOT A STATE!
please, dear media (and also dear slashdot), make an effort to educate people in security matters instead of putting some solution on the "security pedestal". don't make claims about the absolute security of any alternative.
the complete solution is what makes and breaks security, not the components, and without adequate, highly trained and proficient personell it will always be near impossible to achieve truly secure (whatever THAT means) solutions.
well, at least the uprising unices make it easier for the proficient and maybe even raise the security bar for the amateurs, but alas this is not an end to itself!
jethr0
They have an experiment they run, and they measure the outcomes. The measurements over time have changed. They compared the measurements.
That's pretty much the textbook definition of "scientific" and "statistics".
No, this "study", might be an anecdote (I'm unaware of how many machines they have). However, it is a "fact", N months that putting an unpatched Linux system on the Internet used to on average last X minutes. A more recent measurement shows that it now lasts M * X minutes before being compromised. I'm fairly sure these people have several measurements at several points in time (I've read similar measurments like this from the same people a number of times).
That's a controlled experiment (technically speaking, the old measurement is the "baseline"). It's an interesting fact. It doesn't mean "Linux is getting more Secure". It means that on average it appears that a Linux machine without security patches lasts longer before being compromised. That could be because of the cost of beef in Tokyo. It could be because Linux is more secure. It could be because Linux is a low priority target for blackhats. It could be because the IP ranges used this time are known honeypot addresses by the blackhats (which is one of the few causes of problems that would make this "fact" useless to me).
It's not a measurement of causation. It's not a measurement of security. It's a scientific measurement of a length of time. Just like measuring the length of daylight outside. You can measure that scientifically. It won't explain seasonality. It won't explain the tilt of the earth. It won't explain the nature of quantum mechanics. However, it will be an accurate measurement of what it is: "How long the sun was up". Sure it's not the worlds most fact that Linux machines are lasting longer before being successfully attacked, but it is novel for those of us who have Linux machines on the Internet. However, it's lack of being the end all be all theory of Linux security, that doesn't mean it isn't a well defined measure.
Kirby
When we rolled in Linux to automate our internal business systems, security was at the top of the flag pole for us. Our old systems (AIX) had suffered from numerous repetitive flaws particularly in areas of allowing certain connections and not allowing others, which posed a significant problem when it came to securing the entire network from outside abuse.
We analyzed the various systems available to us at the time we were making the rearchitecture decision, some six months ago or so, and quite rapidly we reached a decision based on the data. That is.. Linux would be more secure in our company because we already have the technical people using Linux outside of work who would be able to already understand the system and be able to fix specific and non-specific security issues themselves rather than having us rely on an outside contractor or vendor. This meant we could buy vanilla beige boxes and install Linux, set up all of our business processes, all without having to go to one of those vendors such as RedHat, Sun, or one of the other many vendors in the Linux field.
So, security is a strong concept of safeness for us, and we're glad we're running Linux.
Interesting study, not all that surprising.
How about a study like this against the varous NAT/routers being used out there? How easy is it to own systems sitting behind those? This appears to be the standard anymore for the millions of cable/dsl connections.
What about client side attacks, such as attacks against web browsers and email clients? These kind of security problems comprise a large portion of attacks against Windows based machines, and with the rising popularity of cheap routers that provide good protection to home users via firewall and NAT rules that will prevent direct attacks against daemons, client side attacks will be rising in popularity over the next few years, and cheaply available firewalls won't do anything to help.
Of course, this kind of analysis would require a more involved approach to testing O/S security, rather than just installing an O/S, throwing it on the internet and sitting back and waiting for whatever randomly happens to it to happen, which doesn't really seem to be the way honeynet likes to operate.
Keep in mind that Honeypots were originally intended to track the behavior of so called blackhats, not to analyze the security of operating systems, and they probbably aren't the best choice for the job.
(The idea being to discourage people from playing at skript-kiddie, but concentrating on the real challenges. Using the above logic, if a box was "practically uncrackable", the incentive should be so great that it becomes almost the sole focus.)
As for Linux, a correctly-configured hardened box should come close to VMS in security. The sorts of things that you could configure to do this are as follows:
The reason for so many steps is that Linux is flexible. Flexibility, if used well, can make for an extremely tough system. If used badly, it can make for a highly vulnerable system. Mistakes are not always easy to catch, so it's better to have enough independent redundancy that a failure isn't catastrophic.
VMS had flaws, too, and could be easily mis-configured. (Being able to put DCL scripts in mail subject lines was plain stupid.) But, again, if set up well, was virtually bullet-proof.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Last week, my friend made the mistake of trying to reinstall a friend's XP machine with the LAN cable connected. By the time we had IE running sufficiently to access Windows Update, the machine was already infected.
To save a bunch of posts:
- No it was not the very latest printing of the CD. It was the one that came with the computer.
- No, he did not use slipstream, jumpstart, SMS, MOM, POP or anything else that needed a CD prepped in advance.
- No, he did not have a router (*).
I'm not saying this is the ideal Windows installation environment but it is the default enviroment of the average schmoe. What really boggles me is how many people there must be out there who just accept that. People who's PCs are nearly unusable but are conditioned to expect such poor quality that they just accept it.
(*) Router Rant: This is the one thing that p***ed me off. IF YOU DONT OWN A DEDICATED FIREWALL, GET ONE! Not once, not one single time, have I had someone come back and say that they wish they hadn't spent $30 on a hardware firewall. It'll make your system faster, simplify configuration, allow you to network if you can't, reduce traffic if you can AND it's cheap g****** insurance. Buy the stupid thing!
Telnet doesn't have to be cracked because everything is transmitted in cleartext including passwords.
Why bother cracking Telnet when the desired secret info is handed over on a silver platter?
SSH is not so weak as you suggest. It is certainly more complex, but it uses stack canaries and privilege separation to reduce its vulnerabilities. While its protocol is nastier, some level of nastiness is necessary to securely encrypt things.
OpenBSD ships SSH open by default, and has only had one root hole in what, 8 years? Any reasonably exploitable SSH root hole would count (although holes which are exploitable on Linux might not be on OpenBSD). And there have been buffer overflows in telnetd, too...
I hereby place the above post in the public domain.
I'm personally wondering how a relatively new system like SELinux combined with Exec-Shield are keeping machines from being rooted. Let's say a cracker a compromises your Apache server through a bug in the server itself or a flaw you've introduced yourself through either a CGI or PHP script. He is simply not breaking out of the kernel security context set by the SELinux policy, so what's a hacker to do these days? Would a local root exploit allow you to bypass SELinux? What if there's no root on the system anymore, which is entirely possible. Doesn't that completely mess up the hacker's plans?
Do people still get rooted running something like Fedora Core 3 with SELinux? I can imagine they do, you just don't really hear about it anymore. Perhaps the system is still too new to tell either way. If every daemon is locked down with a targeted SELinux policy in the future, and I see no reason why you wouldn't want this once someone has done the work of writing the policy, perhaps we'll see a dramatic reduction in compromised systems.
It's like deja vu all over again.
The firewall in XP is disabled by default (before SP2 that is). I bet that if you had enabled it, you'd gotten away trouble-free? This doesn't of course doesn't change the fact that 'the average schmoe' isn't aware of this more than you. The fact still remains: you had a freaking firewall there, but didn't use it, right?
:)
I must agree with you on the router thing. Everyone should have one, especially the average schmoes, who don't have a clue. There's good money in fixing / re-installing peoples computers though.
Nobody ever bothered the Windows box, not that there was much you could do with it.
On the other hand, the Linux box got cracked pretty rapidly, sometimes with Staecheldraht DDOS clients, sometimes with an attacker who appeared to have logged in by hand and installed things once he'd cracked it. After 3-4 rounds of the machine being brutally and senselessly attacked every week, I renamed the box "Kenny"... Sometimes I discovered the crack by looking at the tcpdump ("why is my box pinging a university in Sweden???") and sometimes by running commands like "find" in root's home directory which found files that looked suspicious ("ls" had been replaced with a version that didn't show the cracker's files, and "ps" didn't show his processes, but "ls /proc" showed his processes just fine :-)
As an old Unix hacker, this annoyed me. One major target for the crackers was the WU-FTPD ftp server, so it was somewhat ironic that my machine once attacked or was attacked by machines at Washington University (I forget which - I think my machine was cracking them.) It looked for a while like I was getting attacked by somebody at MIT, but it turns out that the culprit was really in Japan, and had the byte order backwards for the response packets...
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Finally, these kinds of projects demonstrate the effect of hardening to sysadmins when their hardened systems fare better than their stock systems in the face of an attack.
The effect of easing the hardening of systems is to produce far more hardened systems, which has the macroscopic effect of making the Best Practice into a Standard Practice. Take the example of telnet on by default. Bastille and programs like it had been turning off telnet for years and educating sysadmins about SSH as a replacement before vendors became comfortable turning it off.
Here's another example, more complicated. Most Linux vendors chroot their DNS servers, for instance -- they didn't do this for the first two years that Bastille was around until the Lion worm changed their minds. Chroot'ed DNS servers fared much better, it had been best practice to chroot for a while, and projects like Bastille created a larger base of admins comfortable with the practice. When vendors' packagers decide whether to do this by default, they feel more comfortable with the idea if they've seen it done a great deal in the field. They feel even more comfortable if they've seen it done successfully programmatically.
Even if the firewall were enabled, this is a pre-SP2 box he was talking about. That still leaves a short window of vulnerability, as Windows XP will bring up the firewall after the networking is set up.
Mart"I know I will be modded down for this": where's the option '-1, Asking for it'?