Full Report
With the recent buzz around the iMessage crypto bug from the John’s Hopkins team, several people pointed out that you would need a root CA to make it work. While getting access to the private key for a global root CA is probably hard, getting a device to trust a malicious root CA is sometimes phrased as difficult to do, but really isn’t. (There’s a brief technical note about this in the caveats section at the end.)
Analysis Summary
# Vulnerability: Easy Installation of Malicious Root CAs on iOS Devices
## CVE Details
- CVE ID: Not explicitly provided in the article, as the focus is on a general technique rather than a specific, tracked CVE for the CA installation itself.
- CVSS Score: Not applicable/Not provided.
- CWE: CWE-282: Improper Use of Special Elements (If viewed as a misuse of the certificate trust mechanism).
## Affected Systems
- Products: iOS Devices (iPhone, iPad).
- Versions: Primarily references older iOS versions (pre-9) as being vulnerable to MitM attacks *after* a root CA is installed, but the CA installation technique applies to iOS versions up to the point of the article (March 2016), often requiring users to bypass minor prompts introduced over time.
- Configurations: Devices connected to untrusted Wi-Fi networks, particularly those exhibiting captive portal behavior.
## Vulnerability Description
The core vulnerability discussed is not a flaw in Apple's cryptographic implementation (like the mentioned iMessage bug), but rather the excessively simplistic user interface flow that allows an attacker to trick a user into installing a **malicious self-signed Root Certificate Authority (CA)** onto their trusted store.
This is achieved via three primary methods:
1. **Simple HTTP Serving:** Serving a self-signed certificate file over HTTP (even without the correct MIME type) prompts the user with installation warnings.
2. **Captive Portal Exploitation:** Utilizing common captive portal checks (e.g., accessing `http://captive.apple.com/hotspot-detect.html`) to serve the certificate file, often disguised as an "Autoconfiguration" prompt, increasing visibility during initial network connection.
3. **Configuration Profiles:** Using an unsigned/unencrypted `.mobileprofile` file containing the malicious root CA (and potentially other payloads like hidden Wi-Fi networks). This method removes the red "Not Verified" warning and replaces it with a "Verified" tick if the profile is signed with *any* valid certificate, severely misleading the user, even if the contained root CA is malicious.
Installation requires 2-3 user confirmation prompts. Once installed, the device trusts any certificate signed by this malicious root, enabling Man-in-the-Middle (MitM) attacks against encrypted traffic.
## Exploitation
- Status: PoC available (Demonstrated extensively in the article using captive portal interception).
- Complexity: Low (Requires an attacker to control the network endpoint serving content, easily achieved via a Rogue AP or captive portal manipulation).
- Attack Vector: Network (Requires the target device to connect to the attacker-controlled network or access an attacker-controlled endpoint).
## Impact
- Confidentiality: High (If a root CA is installed, an attacker can decrypt and view most secured communications, including HTTPS traffic, unless the application specifically uses certificate pinning).
- Integrity: High (Attacker can modify encrypted traffic).
- Availability: Low (No direct denial of service via this mechanism).
## Remediation
### Patches
The article implies that the **iOS 9** update implemented certificate pinning for certain services (like iMessage), which prevents MitM attacks even if a user has installed a malicious root CA, provided the application relies on pinning. However, no specific patch ID or version number is provided for fixing the *CA installation bypass* itself.
### Workarounds
1. **For the general MitM concern:** Ensure all sensitive applications utilize **certificate pinning** to resist the installed root CA.
2. **User Education (Implicit Mitigation):** Educate users on the implications of installing root certificates and caution them against prompts during Wi-Fi configuration, especially those labeled "Autoconfiguration."
3. **Configuration Profile Mitigation (If applicable):** Ensure configuration profiles served are trusted if relying on enterprise deployment, or avoid installing unsigned profiles altogether. (Note: The article indicates that iOS 9 updates addressed the prerequisite for the specific iMessage attack, but not the general risk of installing a rogue CA).
## Detection
- Indicators of compromise: Unexpected certificate warnings in applications that should otherwise work without issue, or unusual Wi-Fi profile installation prompts.
- Detection methods and tools: Auditing the device's installed Trusted Root Store to identify unrecognized or self-signed CAs.
## References
- Vendor advisories: None provided referencing this specific technique as an official vulnerability requiring patching (as it exploits user interaction).
- Relevant links - defanged:
* `hXXps://sensepost.com/blog/2016/too-easy-adding-root-cas-to-ios-devices`
* `hXXps://sensepost.com/categories/certificates/`
* `hXXps://sensepost.com/categories/ios/`