Most software security vulnerabilities are quietly patched by vendors and don’t make front page news. The recently publicized Java 7 vulnerability made headlines after being announced by US-CERT (Vulnerability Alert #625617) on January 10. (US-CERT stands for US Computer Emergency Readiness Team and is a part of the Department of Homeland Security.)
Mainstream news outlets such as CNN and NBC began carrying the story on Friday, January 11, 2013 reporting that the Department of Homeland Security was recommending that users uninstall Java version 7 or disable it in their web browsers until a security update was available.
This vulnerability made headlines because it was a zero day exploit with both significant breadth and potential impact. Essentially, everyone with Java 7 installed and active in their web browser was vulnerable to having malicious software (such as a key logger) installed onto their computer by visiting a compromised website (or site that is serving ads that point to compromised servers).
A zero day exploit occurs when the public at large learns of the vulnerability because it is being actively exploited instead of from a vendor that is describing a vulnerability that has been addressed by a generally available security update. Zero day exploits are analogous to pandemics without cures, at least temporarily.
Approximately 3 days passed between the CERT announcement and Oracle’s patch release to partially address the problem. Dan Goodin reported on arstechnica.com that the attack code had already “been added to the Blackhole, Cool, Nuclear Pack, and Redkit exploit kits” by the time CERT had announced the vulnerability. Again, this reinforces the fact that with zero day exploits, the attackers leverage the element of surprise and have a window of opportunity when the security community is determining how to best protect against a new threat.
This issue seems to be related to an August 2012 Java vulnerability of similar characteristics and impact. We can be fairly confident to expect that this will not be the last zero day attack of a pervasively deployed software product, so it is worthwhile to examine how effectively we (and our vendors) were able to deal with this type of situation so we can refine our security response strategies.
Below are a few of the lessons we (and our customers) have learned from these types of incidents:
Restrict Users Administrative Rights – Most web-based attacks leverage the rights of the logged in user so restricted user accounts limit the amount of damage.
Establish an Incident Response Communication Process – Often critical decisions need to be made quickly and require both technical and business stakeholders to collaborate to determine how to balance risk / impact. Establishing a communication process and who should be involved in those discussions is a key to making a wise decision quickly.
Ensure you (or your vendors) have the right management tools in place – These tools should allow you to inventory your systems in near real time, and modify configurations quickly and at scale. For example, we were quickly able to identify all the computers that had Java 7 installed and begin evaluating the implications of silently removing or disabling Java if that proved to be the best option. We were also able to remotely reconfigure at-risk endpoints within minutes.
Maintain a level of vendor diversity in terms of security technologies — Our immediate response to this security issue was to block Java at the network level where possible. This augmented our efforts to secure endpoints, and reduced the window of vulnerability for many systems. Having a diverse toolset allows you to evaluate a wider variety of approaches when considering countermeasures. I would also consider ensuring technical diversity in your anti-malware infrastructure. For example, if your desktop AV engine uses a signature based approach, consider a sandbox model for your secure web gateways. (If you don’t have a network-based anti-malware layer, you should strongly consider adding it as it the preferred vector for zero day attacks.)
Additional Information: http://www.kb.cert.org/vuls/id/625617