eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Shortly after 3 a.m. EST last Thursday, eWeeks third Openhack interactive security test finished its 17-day run with all prizes remaining unclaimed.
This is eWeek Labs first Openhack test in three tries that hasnt been penetrated successfully, and the credit goes to Argus Systems Group Inc.s PitBull line of operating systems and to the Argus engineering team that configured the systems so securely.
This result is all the more surprising to us given that, as we expected, hackers were able to find and exploit a number of application- level security holes to get root-level access on both machines, including the Web server, that had shell access.
This test underscores the idea that IT managers cannot secure their applications simply by keeping up-to-date with security patches. There is always one more vulnerability—even on systems that are fully up-to-date and have all available security patches installed, as the Openhack systems did. The series of new security holes announced at the end of last month in the Internet Software Consortiums BIND (Berkeley Internet Name Domain) name server, which powers most of the Internet, is just one more example of this (see story about BIND weaknesses, Page 11).
On a regular version of Unix, root access is the key to the castle. But even with the front door wide open, no one was able to get at the crown jewels because of the kernel-level file and network access controls built into the PitBull-modified versions of Sun Microsystems Inc.s Solaris, Red Hat Inc.s Red Hat Linux and IBMs AIX.
PitBull is no magic bullet, and no system can ever be perfectly secure, but the trusted operating system approach is definitely a big step forward.
The key defense that saved Openhack—and kept the $50,000 in prize money in the bank—was the networking controls in PitBull, which prevented users accessing the server over the network (even if logged in as root) from running privileged commands or from changing protected files.
Only when we logged in through the console or through a secure shell connection to allow remote system monitoring could we gain administrative rights.
This kind of fine-grained, operating system level of security control was the major reason Openhack III wasnt cracked, despite the application security flaws that crackers found. In both previous Openhack tests, users broke in to the site through security bugs in publicly accessible applications.
There were application security problems again in this test with the Perl language interpreter and possibly other tools, including BIND (were not sure what application bugs crackers used to get root-level access on two of the systems), a denial-of-service problem when bad input was fed into IBMs WebSphere Commerce Suite and, most recently, a little-known vulnerability in the imapd mail server on the site.
The particular imapd security problem has been known since last April (it was discussed on the security list BugTraq, under ID 1110), but there are no known exploits, or patches available, for it yet.
Unfortunately, that certainly didnt provide any safety for us. Someone either used a privately held crack or developed a new crack for this imapd vulnerability to gain shell access on the DNS (Domain Name System) server without going though Telnet or another normal remote log-in mechanism.
All the effort didnt pay off, however, as the cracker still wasnt able to do more than a normal user could, and so was unable to modify the DNS configuration file that was the target on that server. ´