Mr. Herzog suggests in this presentation that the “Defense in Depth” strategy, with regards to network defense, is ineffective and antiquated, and needs to be replaced with a new and updated defense model. His proposed model is called the “Mobius Defense”.

The basic tenet of this defense is one in which each individual asset should be protected as if it were the only asset in the model as opposed to forming lines of defense to secure the entire asset base as a whole. Two important facets are stated in his presentation:

• Network security is a zero sum game in which a single compromise is all that is required to “win”
• The network perimeter is truly nonexistent

If we take the above two statements to be true, then there really are no clearly defined lines of defense in which we can accurately create a defense in depth model and instead we should secure the individual asset by limiting its in and out dataflow, minimizing trust, and implementing a minimal interconnectedness policy across the board. Distilled, the Mobius model creates a network security design that disregards network boundaries and theoretical demarcation lines in favor of “guerilla defense” in which every actor fends for themselves.

So what does this mean for the application security landscape? If what Mr. Herzog presents is reality, then the application layer truly is the last, and best, line of defense (pardon the pun). With the degradation of the network perimeter, thanks in part to the iPhone, Blackberry, Web Browser, and other assorted peripherals and client based designs; there is a new found urgency to secure each individual network touch point to the best extent possible. It’s with this urgency in mind that application security assessments should move upward in the prioritization of security spending. While I don’t suggest that defense in depth should go away and die, I do suggest that we should focus on securing the most common target of attack, the application layer. If the paradigm of the network has changed shouldn’t our defense models change as well?

Veracode Security Solutions

Veracode Security Threat Guides

I guess it is never too late to fix a bug. Don Hodges used the old video game firmware and a MAME machine to debug and fix a problem which has kept expert Donkey Kong players from ever getting past level 22. If you have seen King of Kong you would know that one of the challenges of getting a high score is getting as many possible points before a software glitch causes the game to end abruptly at level 22. This is because the time is calculated incorrectly and there is not enough time to complete the level.

In his diagnosis, How High Can You Get, Don Hodges determines that the level counter is multiplied by 10 and then has 40 added to it which overflows a single byte (max is 255) value causing the time to be incorrectly calculated. Don then goes on to implement a fix. The article is a good read for low level code and arcade game junkies.

Veracode Security Solutions

Security Threat Guides

• Stack buffer overflow in URL blacklisting code due to a fixed-length buffer, triggered by URLs longer than approximately 2064 characters
• Stack buffer overflow in filter file parsing due to a fixed-length buffer used in a call to fscanf()

In addition, the Michigan team noted that the software fails to encrypt or authenticate the filter auto-update process, and the use of unsafe string processing functions is systemic, meaning that other exploitable vulnerabilities may be lurking just beneath the surface.

Upon learning of these vulnerabilities, the Chinese government ordered Green Dam to fix the security holes immediately. But even with those hastily applied patches, it seems likely that the software is probably riddled with additional flaws. In downplaying the severity of the entire matter, Green Dam implies that their development process probably doesn’t include independent, third-party security assessments. If quick fixes of the most severe issues are sufficient to appease the government, that is probably all they will do.

Ironically, by attempting to “protect” Chinese citizens from online content, the government is doing exactly the opposite by reducing the security posture of those PCs and homogenizing the attack surface. You can just envision all the foreign governments and botnet operators rubbing their hands together with glee as they prepare to fuzz Green Dam for some 0-day exploits. The government wants to be perceived as caring about Internet safety (hence the public insistence on the bug fixes) but in reality they are adding a weak link to the chain.

The Green Dam software is available for free download.

Veracode Security Solutions

Security Threat Guides

I checked out the lxlabs product documentation and website and could not find any reference to using a secure development lifecycle. I did find this rather disturbing post to their forum as the first post on a new topic “Security” in April 10, 2009. It was not replied to until yesterday.

http://forum.lxlabs.com/index.php?t=msg&th=11197&start=0&:

Lxadmin/hyperVM has become popular enough that people are SPECIFICALLY targeting these softwares now, and so we are now redoubling our focus on security.

If anybody knows about any vulnerability in hyperVM or lxadmin, please contact lxinfo at lxlabs.com, and we can negotiate a payment if you can demonstrate it clearly.

Of course, after we fix the bug and update the softwares, we will absolutely disclose it publicly too, since we believe in 100% openness, but we need to know about vulnerabilities before it can impact our clients.

Thanks.

This is obviously not a good software security strategy. The owner of the IP is responsible for testing for security flaws. It was obviously too little too late for lxlabs. The industry can learn from this lesson. Don’t wait until your software reaches critical mass and raises the attention of blackhat researchers before you start to think about application security.

The bigger issue and one that Vaserve should be asking itself is why did they place so much trust in software that clearly didn’t have a software security process behind it. Vaserve should have looked for evidence of a 3rd party security review before they accepted the risk of an application that has the potential to bring down their whole company.

Hosting and cloud provider customers need to ask themselves how they vet the providers they use. Have their providers demanded evidence of 3rd party security reviews of the products in their infrastructure stack? Until customers start requiring this evidence these disasters will continue. Evidence of a security review has to start with the end user customer and work its way up the supply chain to hosting/cloud provider and then to the software vendor.

Veracode Security Guides

Data Security Resources