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.
[ Also read: Java doesn't have to be unsafe: What developers can do. | InfoWorld columnist Andrew Oliver vouches for Java's runtime security. | Think you know Java? Test your programming smarts in InfoWorld's Java IQ test. | Master the latest in Java development with our JavaWorld Enterprise Java newsletter. ]
"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.