FortiClient for Linux, Mac OSX and Windows stores encrypted VPN authentication credentials in improperly secured locations; regular users may therefore be able to see each other’s encrypted credentials. This is an issue, because the key used to encrypt the aforementioned credentials may be retrieved from the binary.
“From the start, the Fortinet vision has been to deliver broad, truly integrated, high-performance security across the IT infrastructure. We provide top-rated network and content security, as well as secure access products that share intelligence and work together to form a cooperative fabric. Our unique security fabric combines Security Processors, an intuitive operating system, and applied threat intelligence to give you proven security, exceptional performance, and better visibility and control–while providing easier administration.”
The patched FortiClient versions should be installed immediately as the VPN credentials could be decrypted by an attacker.
FortiClient stores the VPN authentication credentials in a configuration file (on Linux or Mac OSX) or in registry (on Windows). The credentials are encrypted but can still be recovered since the decryption key is hardcoded in the program and the same on all installations. Above all, the aforementioned storage is world readable, which actually lays the foundation for the credential recovery.
Proof of concept
1) Hardcoded key
The hardcoded key can be disclosed on the Linux version by issuing the following command:
$ strings forticlientsslvpn |grep "fc_1A"
The same decryption key can be found in the Windows and Mac OSX binary.
2) Overly permissive access control
The read access of the configuration file is set for “others” too, making the file world-readable. On Mac OSX, the file can be found under
while the same dataset is stored in the registry key
on Windows, which is world-readable for all users as well.
$ ls -l /home/user/.fctsslvpnhistory
-rw-rw-rw- 1 root root 1227 Aug 23 12:26 .fctsslvpnhistory
$ cat /home/user/.fctsslvpnhistory
Combining the two issues, an attacker can steal the password of any user who has a FortiClient profile on the system. In an enterprise environment, where employees usually log onto VPN server with their domain credentials, a vicious employee can extensively harvest the credentials of colleagues by logging onto the workstation where the credentials have been stored. Hence an attacker might steal credentials of any user in the domain and gain access to their user account (e.g. emails, other private data).
SEC Consult developed a proof of concept tool which takes as input the encrypted string, and prints the decrypted hexdecimal bytes followed by the recovered password. For now, this tool will not be released to give users more time to patch.
$ kr 420d2ee65abded897a69c50f49956909f61e3e549873cdfecf12bafdfa7b78f789a17ba1a5a6c9eb1803
0x50 0x61 0x73 0x73 0x77 0x6f 0x72 0x64
0x52 0x65 0x63 0x6f 0x76 0x65 0x72 0x65
The key generation module is based on a modified SHA-1 hash function, where the hardcoded key and IV flow in and the 24 bytes AES key comes out, what is followed by the AES-192 key expansion routine:
Figure 1: Key generation schema.
The decryption routine takes the form of AES-192 encryption algorithm operating in CTR mode, which takes an integer counter as input and uses the round key from the key expansion. The counter starts from 1 without any nonce involved, while the ciphertext is the hex string read from the .fctsslvpnhistory file.
Figure 2: Decryption schema.
IDA can generate the call graph involving all the routines within the key generation module, which all starts with the routine framed in blue.
Figure 3: Key generation call graph.
Looking back after the work of reverse engineering, the hex string stored in the configuration file can be broken down into a four parts format. Pre_chk and post_chk provide an integrity check against any tamper on the whole hex string, which however plays no role to recover the password, whereas the other two parts of IV and enc(pwd) are relevant for the recovery and self-explanatory.
Figure 4: Hex string breakdown.
Vulnerable / tested versions
The vulnerabilities have been identified in version 4.4.2332 on Linux, version 184.108.40.2065 on Windows as well as version 220.127.116.113 on Mac OSX, which were the latest version of the product at the audit time to our best knowledge.
Vendor contact timeline
2017-08-30: Contacting vendor through firstname.lastname@example.org
2017-09-19: Contacting vendor again due to lost message
2017-09-20: Vendor confirmed and assigned CVE-2017-14184 to the issues
2017-10-19: Vendor requested to postpone the release date
2017-11-02: Vendor informed the fix for Windows and OS X was done
2017-11-22/23: Vendor released 5.6.1 for OS X and 5.6.2 for Windows
2017-12-08: Vendor informed that the fix for Linux is available together with FortiOS release version 5.4.7
2017-12-13: Public disclosure of advisory
According to the vendor, all the identified issues have been fixed in the following versions:
- FortiClient for Windows v5.6.1
- FortiClient for Mac OSX v5.6.1
- FortiClient SSLVPN Client for Linux v4.4.2335 released together with FortiOS 5.4.7
For further information see the website of the vendor:
Please upgrade to the latest version immediately.
It is recommended not to save the password and remove “read/write” permissions for low privileged users or groups.
EOF M. Li / @2017
- TitleVPN credentials disclosure
- ProductFortinet FortiClient
- Vulnerable version<4.4.2335 on Linux, <5.6.1 on Windows, <5.6.1 on Mac OSX
- Fixed version4.4.2335 on Linux, 5.6.1 on Windows, 5.6.1 on Mac OS X
- CVE numberCVE-2017-14184
- Homepagehttps://www.fortinet.com/ | http://forticlient.com/
- ByM. Li (Office Singapore) | SEC Consult Vulnerability Lab