VeriSign is looking to halt the use of its customers’ digital signatures to sign the Stuxnet Malware currently targeting SCADA systems. On Tuesday, the company briefly explained those plans to us, and also confirmed the two certificates that were being maliciously used are no longer valid.
When Stuxnet was first discovered, one of the things that stood out was that it was digitally signed. Stuxnet targets the WinCC SCADA system by Siemens and uses a digital signature from Realtek Semiconductor Corp.
[Note: More information on the Windows Shell vulnerability being used to spread Stuxnet can be found here and here]
The digital signature has since been revoked, but most SCADA environments will require that software be signed before it is allowed to run. The assumption is that Realtek’s key was compromised, which allowed it to be used maliciously.
Shortly after the Realtek signature was revoked, variants of Stuxnet started to spread that were signed with a signature from JMicron Technology Corp. The visible connection is that both Realtek and JMicron have offices in the same industrial park in Taiwan.
This leads to speculation that there is a targeted attack on businesses in the area. The widely accepted assumption is that both companies were infected with Zeus, which has a module capable of capturing digital signatures.
The Tech Herald spoke to VeriSign’s Tim Callan by phone on Tuesday, hoping to get some insight into what the company was doing to address the malicious use of its customers’ certificates.
Interestingly, VeriSign was not made aware of the Realtek digital signature issue until it appeared in the media. Also, it had no confirmation or details on whether a Malware infection caused the keys to be compromised.
After investigating reports, VeriSign reached out to Realtek and informed it that its certificate was being used to sign malicious code. Realtek was also unaware of the issue, and promptly agreed to allow VeriSign to revoke the certificate used to sign the Malware, as well as the renewal of that certificate, issued shortly after the compromised one expired.
This process was repeated with JMicron, and its certificate was revoked as well. As was the case with Realtek, JMicron was not aware that its certificate was being used to sign malicious code.
At this stage, VeriSign is as much a victim as its clients. It is also in a place where it wants to take action, but needs to walk a thin line. Attack types change all the time, so VeriSign draws on previous experience and deals with issues while being respectful of its customers’ business.
While it would be easy to simply revoke and replace all customer certificates, VeriSign will not and cannot jeopardize its customers’ operations, Callan told us. There could be massive issues if it simply started revoking certificates blindly.
That said, VeriSign isn’t sitting idle. The company is working on plans that will remove it from a reactive posture. One plan, still being discussed internally, involves getting an inventory of certificates used to sign legitimate code by customers in the same business park as Realtek and JMicron.
The inventory would include all of the certificates from the same timeframe as those that have been compromised, in addition to other elements. With such a list, VeriSign could then preemptively contact customers and deal with potential issues by revoking certificates and replacing them before they are used to sign Malware.
“This isn’t a definite plan. It is a plan being investigated. It is something that could work, but we need to determine that before it is implemented,” Callan said.
We’ll keep up with VeriSign, and update this story if and when more information is available.