Win Bounties even for soon-to-be-Patched Bugs
By Zuk Avraham
Following the recent disclosures by Google Project Zero of iPhone mass-targeting in the wild, the need to investigate iOS attacks is becoming of critical importance to the DFIR community. This is not the first time iPhones are actively being attacked, and definitely not the last one either.
The challenge starts when an iOS device is confirmed or suspected as compromised. Remarkably, Google Project Zero Team observed messages that were sent in plain text, however usually sophisticated threat operators would rarely make such mistakes. Moreover, even when phones are confirmed to be infected, if the exploit is not available, the device has to be hacked in order to extract the payload.
Two years ago, my iOS device was exposed to two failed attack attempts. Without disclosing sensitive information that would tip off the attackers, the first failed attack was a trigger to a security mitigation and the second failed attack was a failed execution of non-signed binary in a system path. The binary that was tampered with was CommCenterMobileHelper which is the binary that is in charge of baseband / cellular communication.
At that time, I could only deduce that a device was attacked, I knew the exact path but I couldn’t extract the payload. Skipping the full details, I was only able to perform filesystem extraction about a month later once GP0 released a Local Privilege Escalation (LPE) for that version. In an era when even non-sophisticated malware implement time-bombs to avoid detection, it was undoubtedly way too long from the moment of the attack.
At ZecOps we decided to change the odds in favor of DFIR community. By promoting #FreeTheSandbox we believe that DFIR community should be empowered to analyze every sandboxed device (especially the ones that have a microphone), without requiring to use an LPE exploit, and especially if users have a physical access + a pin code to their device. Currently, accessing plain text passwords and messages is allowed, but TFP0 / Read-Only access to file system is not. iOS DFIR is currently a constant Catch 22: even if you have an LPE exploit, you’re facing a challenge: as a white-hat hacker you want to report such vulnerabilities, but if they are patched, you can’t analyze infected devices anymore.
For the first competition, we’re willing to pay even for bugs that other bounties would consider worthless LPEs. For example, vulnerabilities that are already known to be patched in iOS 13 / 13.1 and are still working on iOS 12.4.1. We’re announcing our first Task For Pwn Zero competition:
We’ll use disclosed bugs for defensive purposes in order to analyze infected devices.
FREQUENTLY ASKED QUESTIONS:
1. What type of access are you looking for?
Vulnerabilities / POCs that provide Task For PID 0 (TFP0) and kernel ProcStructAddr for the current process. Please include in your submission email to [email protected]:
- A short explanation of the vulnerability
- POC (without full exploit code)
- Proof for the POC (crash or other)
- Which devices can you support? Does it work with PAC?
- Was this vulnerability disclosed to Apple? Is it patched on iOS 13/iOS 13.1?
- Will you include a write-up (yes/no)
PGP Public Key is available below.
2. What’s the starting point? Do I need a full chain?
Full chain is not required! The vulnerability should work as an app. Our goal is to extract malicious payloads and to analyze persistent and non-persistent payloads on devices. We are only interested in LPEs. We install the app manually on suspected devices, WITH user’s permission. The app won’t be in the App Store.
3. How much will ZecOps pay?
We’ll pay up to $40k if the vulnerabilities were already patched in iOS 13 / iOS 13.1.
The parameters that would provide the maximal bounty includes:
- Number of devices that this vulnerability can obtain access on (A8~A12 are preferred)
- PAC Bypass
- Write up
- We’ll pay more than the maximum bounty for vulnerabilities that are not patched yet in iOS 13 / 13.1.
- We’ll also pay more if Apple doesn’t know about the vulnerability, and we are the first to disclose it to them.
- Although unlikely, an additional bonus will be provided if Apple will provide us a bounty. In any way, we guarantee that the payout will be more than $50k if Apple will provide us with any bounty due to the disclosure. $50k is the price Apple listed for LPEs in the latest bug bounty program so it’s more beneficial to share it with us first.
4. How many vulnerabilities will you purchase?
Although it may change, as a starting point, one for each version. The one with most devices coverage will win. If another vulnerability was not purchased, and it’s still unpatched after an update, we’ll prioritize it for the following version. We will not disclose any vulnerabilities we didn’t purchase, without written permission.
5. Will you share the vulnerability with Apple?
Yes, we’re white-hats. Although this situation is ridiculous, and we hope Apple will fix it, if this vulnerability not previously responsibly disclosed to Apple (please elaborate in the submission), we will. Although we do not anticipate to receive any bounty this time as a result, we’ll provide a bonus to the sender if we receive any bounty and the final outcome will be higher than the entire bounty.
6. Do you require exclusivity?
No, you can do whatever you want with this vulnerability.
7. Do you require a write-up?
No, but as part of our internal bounty evaluation, we will provide you with an additional $5k bonus which will help to achieve the maximum payout.
8. Will you share the vulnerability with other parties?
Currently not. We do not plan to share the vulnerability except for ZecOps customers and partners when devices were found to be suspicious. Down the road, we may share with other companies for defensive purposes only, under a strict agreement that does not allow to resell this vulnerability. If we ever share an exploit, it will only be one that we ended up purchasing, and following a responsible disclosure to Apple.
Once the vulnerability is patched, we will share a blog post with the details and the POC.
9. Does Apple new Research Program helps iOS DFIR analysts? Unfortunately no. Although it’s a good step in the right direction, it’s far from sufficient and it won’t help any iOS DFIR analysts. Even if receive access to a device with root & ssh access, it only help to investigate that particular device. It does not help to analyze suspected devices – even in examples such as the attack disclosed last week where the device was communicating in plain text.
10. How can Apple (& Google) help to fight malicious actors?
Devices must be inspectable by device owners, without tipping of the attackers and without tampering with evidence (flashing a new kernel / unlocking bootloader just to enable inspection is tampering with evidence). Even compromised devices cannot be inspected hence malware/payloads/exploits cannot be easily extracted on latest versions.
In order to extract persistent malware we need to have read-only filesystem access. In order to extract non-persistent, in-memory, malware, we need TFP0 on iOS or equivalent on Android (non-sandboxed, root process).
Android Device Bridge (ADB) user is not sufficient for that purpose too and attackers can use the sandbox limitations to hide from iOS and Android DFIR analysts.
We understand it will be a bit hard to swallow at first, but if the vendors will hear us out they will understand it makes total sense. We can start with SSH access with physical connection and pin code. Secrets like plain-text passwords are available simply with pincode / facial recognition – full analysis of devices should be achieved in exactly the same way.
What’s the value to Apple and Google? They will have an army of hundreds of thousands of Android and iOS DFIR analysts finding persistent and non-persistent attacks on their devices. Making the platform much more secure. Win-Win to everybody.
We would love to maintain an open communication with Apple and Google to achieve proper analysis capabilities.
11. I support the cause, what can I do to help?
- Send us your name and address to [email protected] and we’ll send you free #FREE THE SANDBOX stickers. Just spread the word, together we will make it happen!
- Spread the word with the hashtag #FreeTheSandbox