Monday, April 7, 2025
HomeSecurity NewsmacOS Signature Validation Flaw Allows a Malicious Code Appeared to be Signed...

macOS Signature Validation Flaw Allows a Malicious Code Appeared to be Signed by Apple

Published on

SIEM as a Service

Follow Us on Google News

A flaw in third-party macOS APIs could allow attackers to impersonate the malicious programs to be signed by Apple. The vulnerability affects many vendors and open source projects.

The vulnerability resides in how third-party vendors such as Google and Facebook checks the signed code to verify the integrity of the file.

Developers use to codesign the application to ensure the trust of origin and the code has not tampered. Security, incident response, and forensics processes and personnel use code signing to isolate the malicious code form trusted code.

- Advertisement - Google News

Where the Vulnerability Resides

Security researchers Josh Pitts, from Okta, identified the vulnerability in third-party developers’ interpretation of code signing API allowed for an unsigned malicious code to appear to be signed by Apple.

According to Okta the affected vendors are Google, LittleSnitch, F-Secure-xFence, Yelp OSXCollector, VirusTotal, Carbon Black.

Pits explained the “vulnerability exists in the difference between how the Mach-O loader loads signed code vs how improperly used Code Signing APIs check signed code and is exploited via a malformed Universal/Fat Binary.”

The code signing API verifies the first binary in the Fat/Universal to see who signs the executable without passing the flags SecRequirementRef, SecCSFlags, and SecCodeCheckValidity.

macOS Signature Validation Flaw

To verify no tampering via the cryptographic signature and verify binaries Fat/Universal file to verify no tampering via containing cryptographic signature but without checking the CA root of trust.

Conditions for the vulnerability to work

  • The first Mach-O in the Fat/Universal file must be signed by Apple, can be i386, x86_64, or even PPC.
  • The malicious binary, or non-Apple supplied code, must be adhoc signed and i386 compiled for an x86_64 bit target macOS.
  • The CPU_TYPE in the Fat header of the Apple binary must be set to an invalid type or a CPU Type that is not native to the host chipset.

Patches have been released an as soon the issue shared to the public, Pits says the “APIs fall short by default, and third-party developers will need to carve out and verify each architecture in the Fat/Universal file and verify that the identities match and are cryptographically sound.”

VirusTotal – CVE-2018-10408
Google – Santa, molcodesignchecker – CVE-2018-10405
Facebook – OSQuery – CVE-2018-6336
Objective Development – LittleSnitch – CVE-2018-10470
F-Secure – xFence (also LittleFlocker) CVE-2018-10403
Objective-See – WhatsYourSign, ProcInfo, KnockKnock, LuLu, TaskExplorer (and others). – CVE-2018-10404
Yelp – OSXCollector – CVE-2018-10406
Carbon Black – Cb Response – CVE-2018-10407

The vulnerability went unnoticed for years and there is no evidence of this vulnerability being abused. If you are using any of the above-listed tools it is recommended to check for the updates.

Gurubaran
Gurubaran
Gurubaran is a co-founder of Cyber Security News and GBHackers On Security. He has 10+ years of experience as a Security Consultant, Editor, and Analyst in cybersecurity, technology, and communications.

Latest articles

Threat Actors Exploit Fake CAPTCHAs and Cloudflare Turnstile to Distribute LegionLoader

In a sophisticated attack targeting individuals searching for PDF documents online, cybercriminals are using...

HellCat, Rey, and Grep Groups Dispute Claims in Orange and HighWire Press Cases

SuspectFile.com has uncovered a complex web of overlapping claims and accusations within the cybercrime...

AI Surpasses Elite Red Teams in Crafting Effective Spear Phishing Attacks

In a groundbreaking development in the field of cybersecurity, AI has reached a pivotal...

Threat Actors Use Windows Screensaver Files as Malware Delivery Method

Cybersecurity experts at Symantec have uncovered a sophisticated phishing campaign targeting various sectors across...

Supply Chain Attack Prevention

Free Webinar - Supply Chain Attack Prevention

Recent attacks like Polyfill[.]io show how compromised third-party components become backdoors for hackers. PCI DSS 4.0’s Requirement 6.4.3 mandates stricter browser script controls, while Requirement 12.8 focuses on securing third-party providers.

Join Vivekanand Gopalan (VP of Products – Indusface) and Phani Deepak Akella (VP of Marketing – Indusface) as they break down these compliance requirements and share strategies to protect your applications from supply chain attacks.

Discussion points

Meeting PCI DSS 4.0 mandates.
Blocking malicious components and unauthorized JavaScript execution.
PIdentifying attack surfaces from third-party dependencies.
Preventing man-in-the-browser attacks with proactive monitoring.

More like this

Advanced CoffeeLoader Malware Evades Security to Deliver Rhadamanthys Shellcode

Security researchers at Zscaler ThreatLabz have identified a new sophisticated malware family called CoffeeLoader,...

Clio: Real-Time Logging Tool with Locking, User Authentication, and Audit Trails

Clio is a cutting-edge, secure logging platform designed specifically for red team operations and...

Enhancing Satellite Security by Encrypting Video Data Directly on Payloads

The rapid expansion of low-Earth orbit (LEO) satellite constellations has underscored the need for...