Security

Unpatched servers and other insurgents: Antisec vs. Booz Allen Hamilton

Mark Underwood takes a closer look at Antisec's attack on Booz Allen Hamilton. Meanwhile, arrests targeting the so-called hacktivists continue: UK police arrest alleged LulzSec spokesman "Topiary."

The ease of deploying new servers, especially through virtualization, means that many shops will have more Windows or Linux instances to protect against malicious attack. This is true despite the fact that current hardware is faster; faster hardware would otherwise mean fewer OS instances supporting a greater number of applications and users.

Earlier this month, defense contractor Booz Allen Hamilton (BAH is the 16th largest defense contractor with $3.7B in Uncle Sam revenue in 2010) was attacked by the loosely organized hacktivist group "Anonymous" in the name of #Antisec. The breached system reportedly hosted a learning management system and data from the Defense Acquisition University. According to ArsTechnica, the data exfiltrated included as many as 67,000 email addresses of military personnel, plus passwords, including more than 50,000 addresses at .mil domains. Other data stolen likely included email addresses from other defense contractors. Anonymous posted the email addresses along with their hashes. Some analysts believe that because BAH used a comparatively weak SHA hash and the passwords were apparently not "salted" with pseudo-random strings, many of the passwords may be exposed [Ed. Antisec claimed in their tweet announcement of the exploit that BAH used unsalted MD5 hash]. Many of those 67,000 users are probably being told to change their passwords - at the very least.

Defender lessons

What defensive measures should BAH have taken? The full story isn't being told, so what follows is speculation - but hopefully not idle speculation.

(1) Application level security - In this case, apparently for the Learning Management System, they should have undergone one or more security reviews. Possible reviews could have been staged at the time of deployment, or, for new applications, as part of the development process. Some aspects of such reviews could have been manual, since the use of rainbow tables is a known vulnerability for some password encryption schemes, whether LM hash, MD5 or SHA1. Developers could have been instructed to use password libraries that salted encryption processes. In all likelihood, this was an LMS that had been deployed elsewhere. Others had faced similar security concerns, and may have solutions. For instance, the open source LMS Moodle hosts a discussion of password salting for its MD5 password hash.

(2) Monitoring of the movement of data, particularly including interior network traffic (through tools such as open source project Immunity El Jefe), could have detected dimensions of the initial attack, or of the larger scale extraction (more than 130MB was posted by the hacktivists).

(3) Penetration testing, such as with Andrew Gabin's OpenDLP, can uncover weaknesses. As Gavin exhorted listeners at a recent conference, "Got domain admin to a couple of thousand Windows systems? Got an hour to spare? Steal sensitive data from all of these systems simultaneously in under an hour."

(4) Organizational discipline, such as BAH's own recommendation of the CMMI Cyber Operations Maturity Model or training programs can raise awareness of operational, management, and software engineering security. A broader reach of such programs may have alerted the LMS management team to the risks.

(5) Automated patch management systems are the most obvious solutions to servers lacking security remediation. There are commercial solutions, and some open source initiatives. For example, Shavlik is reportedly partnering with the Spiceworks team to provide patch management with the latter's ad-supported offering. However, as the mature system administrator knows, patch management automation is far from a magic bullet. Some patches fail to install expeditiously, or do not install properly. Workstation flaws such as Adobe Flash vulnerabilities can be difficult to administer in a timely way. Lastly, some patches will break applications, leading to workplace consequences more immediate, probable, and dire than the risk of cyber attack. As Secunia writes in a recent report, enterprises cannot afford to patch every flaw.

(6) Life Cycle Management is a concept sometimes applied within larger organizations, but it tends to be overlooked in the haste to deploy applications. The idea that applications and their platforms experience a sort of ecosystem senescence is one that might encourage scheduled retirement of less well-maintained systems before something bad happens.

(7) As I have written in this column previously, risk management expertise comes at the problem from a different angle. These specialists accept the proposition that business requirements may drive the need to deploy applications rapidly. Their idea is to accept that risk when it makes sense, to manage both cost and risk within the affected project or product teams, and, to the extent practicable, in the underlying technologies available within affected configurations.

No security in numbers

"Anonymous" may or may not survive law enforcement actions against some of its members for allegedly attacking Paypal, Mastercard, and Visa in the wake of institutional backlash to WikiLeaks. Nevertheless, such attacks are likely to continue.

The old adage that there is security in numbers may only apply to the most homogeneous and closely monitored server farms. Odds are, that's not your shop.

Related reading:

About

Mark Underwood ("knowlengr") works for a small, agile R&D firm. He thinly spreads interests (network manageability, AI, BI, psychoacoustics, poetry, cognition, software quality, literary fiction, transparency) and activations (www.knowlengr.com) from...

Editor's Picks

Free Newsletters, In your Inbox