macOS Mojave Exploit can reveal encryption keys, passwords
The researcher who demonstrated the zero-day exploit isn’t giving up the goods out of protest
Here’s an interesting exploit from the land of Apple. A new zero-day, demonstrated in a YouTube video by security researcher Linus Henze, makes it possible for an attacker without administrative privileges or root access to steal all the passwords and encryption keys saved in a Mac’s keychain.
And here’s where it gets interesting. In protest of Apple’s lack of a bug bounty program, the researcher who discovered the exploit isn’t sharing the details.
So, let’s spend a few minutes talking about the KeySteal exploit, bug bounty programs and whether it’s fair to extort a company with something like this.
Let’s hash it out.
KeySteal and Keychain
Keychain is Apple’s built-in key and password manager. It’s a critical component of macOS, storing all of the system’s passwords, encryption keys and digital certificates. Obviously, as we cover all the time, certificate management and key security are of the utmost importance considering all the can go wrong when a compromise occurs.
In 2017, a researcher named Patrick Wardle discovered an exploit that he named KeychainStealer, which Apple promptly patched. Henze’s exploit, KeySteal, is like the spiritual successor to KeychainStealer, and it is still wide open.
In the video below, posted to YouTube, Henze demonstrates the exploit on a 2014 MacBook Pro.
As you can see, it works perfectly.
To disclose, or not to disclose
Now let’s get to the interesting bit: Henge isn’t disclosing this exploit to Apple. At least not yet. The reason is a Bug Bounty program, or more aptly, a lack thereof.
Bug Bounty programs are good things, they encourage third-party security researchers to probe and test various products and report any exploits or vulnerabilities they find. It keeps the researchers in business and it keeps the public safer as a lot of these white hats are more talented than the QA and dev teams that these organizations field. They also have the benefit of a fresh perspective. They haven’t been elbow-deep in the build, which can bias and blind you to certain things.
But, as you might reasonably expect, Bug Bounty programs have more than their fair share of problems. While in a perfect world everyone would function collegially, in reality you see a lot of stuff that would make an elementary school playground seem like a model of decorum.
Case in point, earlier this week in an unrelated incident, the COO of Atrient physically assaulted a researcher that had discovered a critical exploit after trying to quash any news of the vulnerability with a Non-Disclosure Agreement.
That’s pretty standard, companies don’t want publicity about the fact that their WAS/IS a vulnerability, let alone what it was. After all, nobody likes admitting to a mistake.
Another common tact is for company’s to accuse the researchers of hacking them and attempt to have them arrested.
Obviously, this is no way for a company to behave, but it’s worth noting that a lot of these researchers are also sanctimonious, with over-inflated opinions of themselves and a complete lack of an offline social life. So, they’re not entirely sympathetic, either.
In this case, the researcher isn’t disclosing the exploit because Apple doesn’t even have a bug bounty program for macOS. That’s kind of surprising with a company like Apple. To give you some context, Google has a program and regularly publishes the payouts with each new update to a given application, service, device, etc.
Now, the researcher also isn’t disclosing details about the exploit to anyone else, either (aside from the video). He’s not trying to hurt Apple – just extort it. And that’s what this is. Whether or not there may be some justification for it doesn’t excuse the fact that he’s essentially trying to ransom a zero day to Apple.
“The reason [for the non-disclosure] is simple: Apple still has no bug bounty program (for macOS),” Henge told TechSpot. “Maybe this forces Apple to open [one] at some time.”
Is that ethical? I’ll leave that up to you. But neither party is behaving well right now.
As always, leave any comments or questions below…

5 Ways to Determine if a Website is Fake, Fraudulent, or a Scam – 2018
in Hashing Out Cyber SecurityHow to Fix ‘ERR_SSL_PROTOCOL_ERROR’ on Google Chrome
in Everything EncryptionRe-Hashed: How to Fix SSL Connection Errors on Android Phones
in Everything EncryptionCloud Security: 5 Serious Emerging Cloud Computing Threats to Avoid
in ssl certificatesThis is what happens when your SSL certificate expires
in Everything EncryptionRe-Hashed: Troubleshoot Firefox’s “Performing TLS Handshake” Message
in Hashing Out Cyber SecurityReport it Right: AMCA got hacked – Not Quest and LabCorp
in Hashing Out Cyber SecurityRe-Hashed: How to clear HSTS settings in Chrome and Firefox
in Everything EncryptionRe-Hashed: The Difference Between SHA-1, SHA-2 and SHA-256 Hash Algorithms
in Everything EncryptionThe Difference Between Root Certificates and Intermediate Certificates
in Everything EncryptionThe difference between Encryption, Hashing and Salting
in Everything EncryptionRe-Hashed: How To Disable Firefox Insecure Password Warnings
in Hashing Out Cyber SecurityCipher Suites: Ciphers, Algorithms and Negotiating Security Settings
in Everything EncryptionThe Ultimate Hacker Movies List for December 2020
in Hashing Out Cyber Security Monthly DigestAnatomy of a Scam: Work from home for Amazon
in Hashing Out Cyber SecurityThe Top 9 Cyber Security Threats That Will Ruin Your Day
in Hashing Out Cyber SecurityHow strong is 256-bit Encryption?
in Everything EncryptionRe-Hashed: How to Trust Manually Installed Root Certificates in iOS 10.3
in Everything EncryptionHow to View SSL Certificate Details in Chrome 56
in Industry LowdownA Call To Let’s Encrypt: Stop Issuing “PayPal” Certificates
in Industry Lowdown