Security researchers warn that cybercriminals have started using Java exploits signed with digital certificates to trick users into allowing the malicious code to run inside browsers.
A signed Java exploit was discovered Monday on a website belonging to the Chemnitz University of Technology in Germany that was infected with a Web exploit toolkit called g01pack, security researcher Eric Romang said Tuesday in a blog post.
"It's definitely go01 pack," Jindrich Kubec, director of threat intelligence at antivirus vendor Avast, said via email. The first sample of this signed Java exploit was detected on Feb. 28, he said.
It was not immediately clear if this exploit targets a new vulnerability or an older Java flaw that has already been patched. Oracle released new Java security updates on Monday to address two critical vulnerabilities, one of which was being actively exploited by attackers.
Java exploits have traditionally been delivered as unsigned applets -- Java Web applications. The execution of such applets used to be automated in older Java versions, which allowed hackers to launch drive-by download attacks that were completely transparent to the victims.
Starting with the January release of Java 7 Update 11, the default security controls for Web-based Java content are set to high, prompting users for confirmation before applets are allowed to run inside browsers, regardless of whether they are digitally signed or not.
That said, using signed exploits over unsigned ones does provide benefits for attackers, because the confirmation dialogs displayed by Java in the two cases are considerably different. The dialogs for unsigned Java applets are actually titled "Security Warning."
Digital signing is an important part of assuring users they can trust your code, Bogdan Botezatu, a senior e-threat analyst at antivirus vendor Bitdefender, said via email. The confirmation dialog displayed for signed code is much more discrete and less threatening than the one displayed in the case of unsigned code, he said.
"Additionally, Java itself processes signed and unsigned code differently and enforces security restrictions appropriately," Botezatu said. For example, if the Java security settings are set to "very high," unsigned applets won't run at all, while signed applets will run if the user confirms the action. In corporate environments where very high Java security settings are enforced, code signing may be the only way for attackers to run a malicious applet on a targeted system, he said.
This new Java exploit has also brought to light the fact that Java does not check for digital certificate revocations by default.
The exploit found by researchers Monday was signed with a digital certificate that's most likely stolen. The certificate was issued by Go Daddy to a company called Clearesult Consulting based in Austin, Texas, and was subsequently revoked with a date of Dec 7, 2012.
Certificate revocations can apply retroactively and it's not clear when exactly Go Daddy flagged the certificate for revocation. However, on Feb. 25, three days before the oldest sample of this exploit was detected, the certificate was already listed as revoked in the certificate revocation list published by the company, Kubec said. Despite this, Java sees the certificate as valid.
On the "Advanced" tab of the Java control panel, under the "Advanced security settings" category, there are two options called "Check certificates for revocation using Certificate Revocation Lists (CRLs)" and "Enable online certificate validation" -- the second option uses OCSP (Online Certificate Status Protocol). Both of these options are disabled by default.
Oracle does not have any comment about this issue at this time, Oracle's PR agency in the U.K. said Tuesday via email.
"Sacrificing security for convenience is a serious security oversight, especially as Java has been the most targeted third-party piece of software since November 2012," Botezatu said. However, Oracle is not alone in this, the researcher said, noting that Adobe ships Adobe Reader 11 with an important sandbox mechanism disabled by default for usability reasons.
Both Botezatu and Kubec are convinced that attackers will increasingly start using digitally signed Java exploits in order to bypass Java's new security restrictions more easily.
Security firm Bit9 recently revealed that hackers compromised one of its digital certificates and used it to sign malware. Last year, hackers did the same with a compromised digital certificate from Adobe.
Those incidents and this new Java exploit are proof that valid digital certificates can end up signing malicious code, Botezatu said. In this context, actively checking for certificate revocations is particularly important because it is the only mitigation available in case of certificate compromise, he said.
Users who require Java in a browser on a daily basis should consider enabling certificate revocation checking to better protect against attacks exploiting stolen certificates, said Adam Gowdiak, the founder of Polish vulnerability research firm Security Explorations, via email. Security Explorations researchers have found and reported over 50 Java vulnerabilities in the past year.
While users should manually enable these certificate revocation options, many of them will probably not do it considering that they don't even install security updates, Kubec said. The researcher hopes that Oracle will turn on the feature automatically in a future update.