OpenHack 2: Lessons Learned
OpenHack 2: Lessons Learned
eWeek Labs OpenHack.com e-business site was built from the ground up with security in mind, and the site was co-designed and co-maintained by security company Guardent Inc. Yet OpenHack was cracked-by two different people in less than one month.
After we reported the hacks, a reader asked despairingly whether there was hope for anyone to stay secure. There is hope, but only for organizations that acknowledge the risk and work to manage it-constantly.
eWeek Labs launched the OpenHack interactive security test June 26 in an effort to further define the hacker threat and provide e-businesses with the knowledge, and thus ammunition, to head off the menace.
Gauging that security threat is a key part of any organizations measured response. Spanish security consultant Lluis Mora was successful in cracking into eWeek Labs interactive security test two years in a row. Moras exploits were skillful but not beyond the realm of untold numbers of technically savvy people whose motivations range from mischief to malice.
We asked Mora to try to quantify the threat. "I couldnt give you a figure, but certainly there are lots of people out there with the required skills to do it," he said. "[It takes] just some Perl knowledge, a basic understanding of how IP networks work and lots of imagination. If you havent addressed application security, its just a matter of time till somebody finds out and exploits it."
"Just a matter of time" is a scary statement, but given the complexity of modern IT systems, especially dynamic Web sites, we think its realistic. That has been our OpenHack experience, and we advise expecting and planning for security breaches.
Doing so requires defense in depth. We designed OpenHack to include a complex mixture of corporate applications and operating systems, which turned out to be a security measure in and of itself.
Diversity increases costs and is difficult to maintain. But if a break happens, a diverse computing platform will prevent attackers from having the run of the store (in some cases, literally).
Only two of OpenHacks target systems-the e-commerce server and the database-were cracked. The three other targets-the e-mail server, domain name server and Web server-and the firewalls were not cracked, nor did anyone ever gain root access.
Through the use of basic hardening techniques and standard off-the-shelf security products, we were able to repel most of the low- to midlevel attackers and prevent the handful of highly skilled hackers who got into our systems from gaining root access. However, even without root access, an experienced hacker can do serious harm.
The hacks that were successful were achieved via vulnerabilities in Akopia Inc.s MiniVend storefront app and the Solaris documentation server AnswerBook2. MiniVend 4.04a fixes all the vulnerabilities found in the OpenHack test and is available at www.minivend.com/iri/mvend.html.
Organizations running Solaris should make sure that AnswerBook2 is shut off on production systems or install AnswerBook2 1.4.2, available at www.sun.com/software/ab2. Then install patches 110011-02 (for Sparc) or 110012-02 (for Intel) from sunsolve.sun.com. The AnswerBook2 vulnerability affects all versions of AnswerBook, at least as far back as Solaris 2.6, according to Sun officials.
Suns security white papers state that all nonessential components (such as AnswerBook2) should be removed on production servers, something we should have done on OpenHack.
: Double-Edged Sword">
Because of its security benefits and risks, open-source software was characterized as "a double-edged sword" by MiniVend creator Mike Heins. "[The OpenHack scrutiny] is worse than I thought it might be, but ... it shows how opening the source can help you find security problems," said Heins, in Oxford, Ohio. "This is [an exercise] I should have gone through sooner."
Security vulnerabilities are much more difficult to spot in closed-source applications, but that doesnt mean the vulnerabilities are not there. Moras success with AnswerBook2 shows that clearly.
Another lesson we learned from OpenHack is that, when setting up complex systems, its easy to miss simple things-especially in places where problems are not expected. For example, an unchanged default password account on the Oracle8i server gave Mora access to database files.
Some take the low road
Application-level attacks caused the most damage to OpenHack, but lower-level network and DoS (denial-of-service) attacks also caused problems. During the first few days the OpenHack site was up, the sheer volume of these attacks at times overwhelmed the sites 10M-bps pipe to the outside world.
There remains no definitive way to prevent distributed DoS attacks, but damage can be minimized through timely communication among IT managers across organizations.
"Good security involves having diverse, well-coordinated and protected systems, and even then, you can overlook something," Mora said. "As somebody said, the only safe computer is unplugged, locked in a safe and buried in the desert."