Hacking ignorance isn't bliss

Just because you haven't been hacked doesn't mean you can't be

I teach and penetration test for a living. I find it disturbing how many system administrators think their networks and systems are secure just because they aren’t often attacked.

What launched me on my latest rant was an AS/400 penetration test that was included as part of a much larger PC engagement. The AS/400 system administrator bragged about how secure AS/400s were as compared with those silly Windows PCs. I then broke into his system in less than one minute on my first attempt.

Even though he had the system for 20 years, and through multiple upgrades, he had not changed many of the initial installation passwords. In this case, his Qsysopr (the system operator or admin) and Qsecofr (system security officer) accounts still had their default install passwords from decades ago. This isn’t unusual on AS/400 systems -- incidentally, their default passwords are the same as their log-on names listed above. To up the ante, his AS/400 is reachable over the Internet.

[Talkback: Is Apple really better at security than Microsoft?]

I doubt I’m the first person to find his misconfiguration. Just because you’re not hacked, doesn’t mean you can’t be hacked.

I’m not the only one who laments about security administrators who don’t get this. Last month, Kaspersky attendees of the LinuxTag 2006 conference in Germany complained about similar worries with Linux in their May 9 "Illusion of Invulnerability" blog posting. It’s a good, short read. To summarize, the writers feel that people’s illogical belief (in stark contrast to the facts) that their operating systems are secure will lead them to complacency.

I think the more you know about Linux, the more you realize how easily it can be hacked. Although it isn’t targeted nearly as much as Windows PCs, it has the same problems as any other computer platform.

No platform is truly immune. Hackers break in using a variety of methods, including:

-- buffer overflows

-- misconfigurations

-- OS or application vulnerabilities

-- password guessing/cracking

-- sniffing

-- data malformation

-- social engineering

Although the code used to do the buffer overflow as well as what is vulnerable may change, the techniques are the same whether you're running Windows, Linux, or AS/400s.

Many people would have you believe that Mac OS X is supposed to be security’s holy grail. As reported in InfoWorld two weeks ago, Apple just released a patch closing 31 holes, and even that patch didn’t plug all the leaks. According to the article, security researcher Tom Ferris is so frustrated that Apple didn’t close all his previously reported holes with this action that he is contemplating releasing the yet-unpatched holes to full disclosure lists as zero days. Let’s hope he doesn’t.

But it’s more than just the patching problems. Secunia now reports 70 Mac OS X advisories; there were 22 of them in 2005. Some of them discussed dozens of individual security vulnerabilities.

The way I count it, Mac OS X has had nearly 200 discovered security holes during the past few years. With Mac OS X now running on the Intel platform, many analysts are expecting Apple’s market share to outpace Linux’s desktop ownership in less than a year. But with hundreds of known vulnerabilities and frustrated security researchers, is Apple going to do a better job than Microsoft as it increases its popularity?

When I started in the security world 20 years ago, only Apple computers had viruses. Then DOS and Windows got more popular, and the Internet connected everything. As Linux and Macs gain larger market shares, they will be hacked more, not less.

The real answer to the "what's more vulnerable" question is that all systems need a proactive security defense. All computers must be patched, configured correctly, defended in-depth, and monitored.

The day after my AS/400 break-in, I broke into a university’s mainframe computer. Again, the culprit was poor passwords: The maximum password size was six characters. Luckily, I didn’t need to guess too hard because the zTEST user account had the first password I guessed -- and yes, it was "test."

Although it only got me in as a non-privileged user, I was quickly able to break out of the initially presented log-on menu and access functions the system administrator probably thought were "hidden” just because most users didn’t know what to do if they escaped around the menu system. That "ignorance is bliss" policy won't keep your data secure when a real hacker comes sniffing around your systems.

Copyright © 2006 IDG Communications, Inc.

How to choose a low-code development platform