Oracle’s new security model for Java, in place since the release of Java 7 update 11, is under serious fire now that attackers have demonstrated in the wild how to bypass the updated controls with the help of social engineering.
In 7U11, Oracle changed the default security setting in Java from Medium to High, preventing unsigned Java Web applications from executing automatically; users are warned before unsigned applets run, a move intent on preventing silent exploitation, Oracle said.
Yesterday, a Java exploit was found on a German online dictionary compromised by the g01pack Exploit Kit, researcher Eric Romang said. The attack pretends to be a signed ClearWeb Security Update from Clearsult Consulting Inc., a legitimate Texas consultancy. The dialog box presented to the user spoofs the conventions used by the Oracle/Java dialog box that a user would see for a trusted signed Java applet, which encourages the user to trust the applet and run the executable. The dialog box for an untrusted applet has much sterner language, warning that a digital signature could not be verified.
Savvy users who might be inclined to click More Information and Certificate Details tabs presented by the dialog box associated with the malicious applet would see more social engineering regarding the trustworthiness of the Java app. So while the applet did not automatically execute, attackers are trying the next best avenue to exploit it with convincing language hoping the user executes the applet for them.
The kicker in this case, according to Romang, is that the certificate used in the attack was signed with a stolen private key and the certificate was revoked by GoDaddy on Dec. 7, according to Avast security researcher Jindrich Kubec.
“Signing and verifying files is [such] an important part of the Java platform’s security architecture, that Jarsigner validates the file despite the [fact] the certificate is revoked,” Romang wrote in a blogpost.
Attackers using stolen certificates to sign malware is nothing new, but given the current Java security model, it’s now difficult to trust any certificate.
“Both self-signed and signed [certificates] produce different dialogs; the signed one, together with social engineering can convince a user that something quite legitimate is happening,” Kubec told Threatpost. “And, both signed and self-signed, after the user’s click, now have full access to the computer, without any need of exploit.”
Oracle introduced its new security levels in Java 7U10, ranging from Custom, where security settings can be set based on user’s needs, all the way to Very High, where Oracle said users will be prompted before any Java application runs in the browser. In 7U11, the default security setting was set to High.
As for the GoDaddy certificate used in the attack, the GoDaddy Certificate Authority listed a revocation date of Dec. 7, the date from which it should be considered invalid. The certificate was revoked on Feb. 25, but the first malware sample was snared Feb. 28.
The root issue, he said, lies in the default settings in place in the Java Control Panel. Signed applications and self-signed applications both are granted elevated privileges by default. And worse, Certificate Revocation List checking is off by default as is the ability to enable online certificate validation.
“I really don’t know what these guys are thinking,” Kubec said of Oracle. “They give people the tool to shoot themselves in the foot very effectively.”
Yesterday, meanwhile, Oracle rushed an emergency Java update, 7U17 to patch zero-day vulnerabilities CVE-2013-1493 and CVE-2013-0809; the former was discovered last week being exploited in the wild in Java 6 update 41 through Java 7 update 15. In 7U17, the certificate revocation list checking remains off by default, meaning users will have to wait likely until April for the next scheduled Java security update for a possible change.
The news of the release of Java 7 Update 17 came hours after reports surfaced that additional vulnerabilities in Java were discovered by researchers at Security Explorations of Poland. That firm said it has reported seven Java vulnerabilities to Oracle since Feb. 25, none of which were addressed in yesterday’s update.
The new vulnerabilities are related to the Java Reflection API that would allow an attacker to bypass the Java security sandbox. Two bugs were reported to Oracle on Feb. 25, one of which Oracle confirmed as a vulnerability, the other it refused to, calling it “allowed behavior,” the company said, adding that it provided Oracle with code samples proving the “allowed behavior” is not allowed in Java SE.
