Stuxnet-style code signing is more widespread than anyone thought | Ars Technica

Link articolo originale

Archivio di tutti i clip: href=”http://clips.quintarelli.it”>clips.quintarelli.it
(Notebook di Evernote).

Stuxnet-style code signing is more widespread than anyone thought

Forgeries undermine the trust millions of people place in digital certificates.

Dan Goodin – 11/3/2017, 5:55 PM

Enlarge The two legitimate signing certificates Stuxnet used to bypass Windows protections.

One of the breakthroughs of the Stuxnet worm that targeted Iran’s nuclear program was its use of legitimate digital certificates, which cryptographically vouched for the trustworthiness of the software’s publisher. Following its discovery in 2010, researchers went on to find the technique was used in a handful of other malware samples both with ties to nation-sponsored hackers and, later on, with ties to for-profit criminal enterprises.
Now, researchers have presented proof that digitally signed malware is much more common than previously believed. What’s more, it predated Stuxnet, with the first known instance occurring in 2003. The researchers said they found 189 malware samples bearing valid digital signatures that were created using compromised certificates issued by recognized certificate authorities and used to sign legitimate software. In total, 109 of those abused certificates remain valid. The researchers, who presented their findings Wednesday at the ACM Conference on Computer and Communications Security, found another 136 malware samples signed by legitimate CA-issued certificates, although the signatures were malformed.
The results are significant because digitally signed software is often able to bypass User Account Control and other Windows measures designed to prevent malicious code from being installed. Forged signatures also represent a significant breach of trust because certificates provide what’s supposed to be an unassailable assurance to end users that the software was developed by the company named in the certificate and hasn’t been modified by anyone else. The forgeries also allow malware to evade antivirus protections. Surprisingly, weaknesses in the majority of available AV programs prevented them from detecting known malware that was digitally signed even though the signatures weren’t valid.
“Our results show that compromised certificates pose a bigger threat than we previously believed, as it is not restricted to advanced threats and that digitally signed malware was common in the wild before Stuxnet,” Tudor Dumitraș, one of three professors at the University of Maryland, College Park, who performed the research, told Ars. “The findings also raise important concerns about the security of the code signing ecosystem.”

Enlarge The lifecycle of abusive certificates. Red-filled circles, empty circles, green bars, and orange diamonds indicate malware, benign samples, expiration dates, and revocation dates, respectively.

Kim et al.

Bypassing AV on the cheap
An accompanying research paper, titled Certified Malware: Measuring Breaches of Trust in the Windows Code-Signing PKI, found that even when a signature isn’t valid because it doesn’t match the cryptographic hash of the file being signed, at least 34 AV programs to some degree failed to identify the easy-to-spot error. As a result, the AV programs often failed to detect malware that was known to be malicious. The failure, the paper reported, is the result of faulty implementations of Microsoft’s Authenticode specification.
To prove the point, the researchers downloaded five unsigned ransomware samples that AV programs almost universally detected as malicious. The researchers then took two expired certificates that previously had been used to sign both legitimate software and malware and used the certificates to sign each of the five ransomware samples. When analyzing the resulting 10 files, the AV programs to varying degrees failed to detect they were malicious.
Three AV programs—nProtect, Tencent, and Paloalto—had the most trouble, reporting eight of the 10 files as benign. Even well-known AV engines from Commodo, TrendMicro, Microsoft, Symantec, and Kaspersky Lab had problems, failing to detect 6, 3, 2, 2, and 1 of the known malicious samples, respectively. On average, the malformed signatures reduced the overall detection rate by 20 percent. The other affected AV packages included:

AegisLab, with 7 samples missedCAT-QuickHeal, 6 samplesTheHacker, 6 samplesRising, 5 samplesAVware, 4 samplesClamAV, 4 samplesCrowdStrike, 4 samplesF-Prot, 4 samplesIkarus, 4 samplesVIPRE, 4 samplesBkav, 3 samplesCyren, 4 samplesAvira, 2 samplesFortinet, 2 samplesK7GW, 2 samplesK7AntiVirus, 2 samplesMalwarebytes, 2 samplesNANO-Antivirus, 2 samplesSentinelOne, 2 samplesSophos, 2 samplesTrendMicro-HouseCall, 2 samplesVBA32, 2 samplesViRobot, 2 samplesQihoo-360, 1 sampleZillya, 1 sampleZoneAlarm, 1 sample
“We believe that this [failure] is due to the fact that AVs take digital signatures into account when [they] filter and prioritize the list of files to scan, in order to reduce the overhead imposed on the user’s host,” the researchers wrote. “However, the incorrect implementation of Authenticode signature checks in many AVs gives malware authors the opportunity to evade detection with a simple and inexpensive method.”
Key mismanagement
The researchers identified two other key weaknesses in code-signing regimens that allow forgeries to flourish. One is software publishers who mismanage the private keys they use to sign their wares. The 189 malware samples bearing valid digital signatures were signed by 111 unique certificates. Of those 111 certificates, 75 of them had been used previously to sign legitimate software, an indication that the publisher had lost control of the private key portion of the certificate. Of those 75 certificates, 72 were compromised and three were used on infected developer computers. Five of the eight certificate holders that the researchers alerted to the theft were previously unaware their certificates had been compromised or misappropriated.
Verification failures
The third key weakness in the code-signing ecosystem was the failure of certificate authorities to verify the identities of people applying for code-signing certificates. Twenty-seven certificates in the group of 111 misappropriated certificates that the researchers identified fell into this class. Twenty-two of the certificates were improperly issued as a result of identity theft of a legitimate company. In some cases, malicious actors impersonated legitimate companies, in some cases ones that had no involvement at all in publishing software. In the remaining five cases, the certificates were issued to fraudulent shell companies. A list of all the abusive certificates is here.The research comes seven years after the discovery that Stuxnet used two stolen certificates from two separate companies—JMicron and Realtek—that happened to be located in the same business complex in Taiwan. By signing key device drivers that Stuxnet used to decrypt and load encrypted dynamic link library files into the Windows kernel, the worm developers were able to satisfy a newly created Windows requirement that all such drivers be verified as coming from a trustworthy source. Malware with the same digital DNA as Stuxnet—Duqu discovered in 2011 and the Duqu 2.0 that
infected Kaspersky Lab’s corporate network starting in 2014—also used code signing. The
certificate used to sign Duqu 2.0 belonged to Foxconn, the electronics manufacturing giant and maker of the iPhone, Xbox, and other well-known products.
Identifying the misuse of code-signing certificates is hard because unlike transport layer security certificates used to secure websites, there is no central database people can search. The new research is significant because it’s the first to reveal how prevalent abused certificates are and how they can be used to bypass key protections, including those provided by AV. The researchers have proposed several improvements to make code signing more trustworthy.

If you like this post, please consider sharing it.

Leave a Comment

Your email address will not be published. Required fields are marked *