Read Time:2 Minute, 55 Second
Executive summary:
Fortinet’s newest vulnerability, CVE-2022-40684, allowing for authentication bypass to manipulate admin SSH keys, unauthorized downloading of configuration files, and creating of super admin accounts, is put a big target on the back’s of unpatched and exposed Fortinet devices.
An AT&T Managed Extended Detection and Response (MXDR) customer was involved in a true positive compromise that was discovered through a threat hunt initiated off an Intrusion Protection System (IPS) alert from Fortinet. With coordination between customer and MXDR and the customer’s network and security teams, the threat was remediated and contained, and the vulnerable devices were patched.
Investigation
The initial investigation began during a tactical check-in with the customer, who mentioned an investigation regarding an IPS detection for two IP addresses that were attempting the authentication bypass exploit.
If we pivot to the event, we can see Fortinet created detections for potentially unauthorized API requests to the cmdb filepath.
Through Fortinet’s advisory on the vulnerability, we learned that potential malicious activity would originate from a user Local_Process_Access and would utilize the Node.js or Report Runner interface. Reports indicate that some of the handlers for API connections check certain conditions, including IP address being a loopback address and User-Agent being either Report Runner or Node.js. Off that information, we’re able to turn our attention to potential true positives that weren’t picked up by the IPS. Doing a quick filter on the Local_Process_Access user produced some interesting events:
This doesn’t look good. The first event we can see the attacker manage to successfully download the Local Certificate:
This allows the attacker to see certificate information such as email address for the certificate owner, IP address of the Fortigate, company name, location where the Fortigate was installed, and other sensitive details. These local certificates a generated and provided to the Certificate Authority (CA) for environment trust.
Shortly after, the attacker managed to download the system config of the Fortigate:
Finally, a few hours later they managed to upload a script and run it to create a super_admin user:
This is where the observable activity ended from the Local_Process_User and newly created admin account. Remediation began at this point.
Response
After discovery of the administrator account, a network administrator was urgently contacted and was able to remove the account. During the remediation process, the network administrator observed that the management port’s external interface had HTTPS open, which is likely how the attacker gained the initial foothold. It’s believed the super_admin account that was created was to be used as a backdoor in case the device was patched, as no activity was seen from the account after creation. The script used by the attacker was not recovered, but following its upload and execution it was likely just used to create the admin account.
Importance of patching:
Fortinet did release a patch the day this vulnerability was announced, as well as mitigation steps if patching was not immediately feasible. One of the mitigation steps was to disable HTTPS/HTTP on the external facing management interface if not needed. The Fortinet Fortigate in question was the only device that had the management interface open, and thus allowed the attacker an easy path to exploit the vulnerability.
As a result of the detection of this activity through threat hunting through customer logs, additional correlation logic was created for the USM Anywhere platform to detect future compromises.
