Fortinet has released information about PSIRT FG-IR-22-377, also known as CVE-2022-40684. Following we have a collection of remediation steps to take if your FortiGate has been breached. We have documented some information about this vulnerability in this blog article.
We will update this post as soon as new evolvements are available. Last Update: Initial release.
How to know if your FortiGate got hacked?
Check for additional administrator accounts
Search for accounts with the following names:
- fortigate-tech-support
- fortinet-tech-support
- fortinet_admin
- webadmin
- it.admin28 (where the number at the end is a random number)
- root
Search the logs for traces
Search the logs for:
- System Events -> General System Events -> Filter “Log Description” for “Admin login successful”
- Check if any unauthorized login actions have been logged.
- System Events -> General System Events -> Filter “User” for “Local_Process_access”
- Check if there are unexpected entries visible. If so, check what actions have been done on the FortiGate.
Remediation steps
- Download a configuration backup. You can later compare this backup with an older backup to find which settings have been manipulated on your FortiGate.
- Save as many logs as possible for later analysis. If you’re logging to the memory only and reboot the device, any logs will be lost.
- Upgrade your FortiOS to a fixed version.
- FortiOS 7.0.0 to 7.0.6 -> 7.0.7
- FortiOS 7.2.0 and 7.2.1 -> 7.2.2
If you are for any reasons not able to upgrade your System, we recommend to disable the HTTP/HTTPS administrative access on all incoming interfaces where an attack can source from. If this is also not possible, you can implement local-in policies as a temporary measure:
config firewall address
edit "management_address_01"
set subnet 192.168.0.22/32 # <- Replace this address with your management host/subnet.
next
end
config firewall addrgrp
edit "https_management_addresses"
set member "management_address_01"
next
end
config firewall local-in-policy
edit 0
set intf wan1
set srcaddr "https_management_addresses"
set dstaddr "all"
set action accept
set service HTTPS HTTP
set schedule "always"
set status enable
next
edit 0
set intf wan1
set srcaddr "all"
set dstaddr "all"
set action deny
set service HTTPS HTTP
set schedule "always"
set status enable
end
end- Delete the administrator accounts that have been created.
- Change ALL preshared keys, passwords and certificates. This includes also LDAP credentials and other credentials to connected systems where the login information was stored on the FortiGate. You can find all encrypted strings using this command:
sh | grep -f "ENC"
- Certificates, which private keys were stored on the FortiGate, need to be revoked and newly generated.
- Don’t forget to also check connected systems for traces of compromise.
Reduce the attack surface of your Setup
- Disable administrative access from WAN.
We also recommend to implement solutions to automatically react to suspicious activities. Following some examples:
- Implement a SIEM or SOAR solution.
- Generate an e-mail message on a successfull admin login.
- Enable logging to an external log solution like FortiAnalyzer oder FortiGateCloud
Do you need an even more secure solution?
A lot of customers with highly critical infrastructures are not affected from this problem because they have management only enabled on management interfaces. But if you are affected and you want to be sure that your FortiGate is going back into a secure state, we highly recommend to format your boot storage and reinstall the FortiOS before restoring a clean configuration. With this procedure you can rule out that hidden changes on the FortiOS have been made. At the moment we have not seen such manipulated systems, but there is always a small chance of such manipulations.
