FortiGate firewalls provide crucial security at the edge of an organization’s network. These firewalls protect internet-facing services, terminate VPN connections, enforce security policies, and provide the path into the internal network in many environments.
When you are warned about potentially compromised FortiGate credentials across over 80,000+ verified devices across almost 200 countries, you should heed the warning.
Earlier this year in June, security researchers identified a large-scale credential compromise campaign targeting internet-facing FortiGate firewalls and SSL-VPN gateways. This campaign has been referred to as “FortiBleed”. This campaign has involved wide-spread use of previously compromised credentials, credential stuffing, brute-force activity, and password attacks against exposed FortiGate internet ports.
FortiBleed is not a new Fortinet vulnerability. Concerned individuals should think of this as a high-impact incident and take corrective measures to lower the risk of becoming another victim of FortiBleed. This campaign is taking advantage of credential reuse, weak authentications practices, and insufficient or non-existent MFA. As of June 19th, it was reported that more than 86,644 devices had become compromised.
Attackers can use previously obtained credentials against internet-facing FortiGate devices without requiring a new zero-day vulnerability. Fortinet’s analysis has identified the reuse of credentials from previous incidents. Once attackers obtain valid access, the risk extends beyond the compromised account. A compromised FortiGate administrator account can potentially allow an attacker to modify firewall policies, create unauthorized admin accounts, change passwords, alter security controls, obtain reconnaissance information, and perform numerous other detrimental actions that a threat actor can take with super admin access to an organization’s firewall.
FortiBleed requires a different approach than traditional vulnerability management. FortiGate administrative and remote-access credentials must be treated as privileged credentials and protected accordingly. Organizations must not solely rely on a strong password, current FortiOS version, VPN password, login page, or the firewall’s perimeter security controls. Organizations must instead follow the these rules:
1. No unnecessary public management exposure.
2. Phishing-resistant MFA on administrative and remote-access accounts.
4. Password rotation every 90 days
3. Unique credentials
5. Continuous monitoring
Organizations operating FortiGate firewalls should approach FortiBleed remediation as a credential containment and privileged-access review. The steps to take in response to this should be as follows:
1. Identify internet-facing FortiGate devices
2. Remove public management exposure where its not needed
3. Terminate existing sessions for SSL-VPN and administrative sessions (Changing a password does not necessarily remove an already-established session.)
4. Rotate credentials across VPN and administrative accounts.
5. Enable strong MFA.
6. Validate PBKDF2 password hashing.
7. Audit administrator and VPN accounts.
8. Review logs.
FortiGate devices can easily disable or enable specific network services on its interfaces. If a specific port is required to be publicly facing, its security can be increased by utilizing a local-in-policy to block specific administrative traffic. The widgets on FortiGate make it easy to terminate any active administrator sessions or VPN sessions for unknown accounts or as part of the response to FortiBleed. The FortiGate also allows administrators to force a password reset after a specified amount of days. By utilizing FortiToken or FortiAuthenticator, a firewall administrator account can be configured to use MFA. Starting from FortiOS 7.2.11, 7.4.8, and 7.6.1, the hash function used to store administrator credentials is updated from SHA256 to PBKDF2. PBKDF2 is used to improve security against brute-force and dictionary attacks.
It is important to note that just because passwords were changed does not indicate sufficient measures taken to prevent a compromise. Organizations must ensure every administrator account has an identified owner, uses unique credentials, is protected by phishing-resistant MFA, while removing dormant accounts and regularly reviewing VPN access. FortiGate management must not be publicly accessible; administrative access must be restricted to approved management networks; external management must be explicitly controlled; and SSL-VPN should be migrated to a Dial-Up IPsec VPN configuration.
Administrative and VPN credentials must be rotated, PBKDF2 must be used for administrator password storage, and legacy, weaker password-hashing mechanisms must be eliminated. In addition, administrative and VPN authentication events and configuration changes must be logged and forwarded to the organization’s SOC or monitoring platform, with alerts configured to detect suspicious activity. Finally, administrator and VPN accounts must be validated, firewall policies reviewed, configurations compared against a known-good baseline, and any unauthorized changes investigated to determine whether a compromise has occurred and ensure the environment has been returned to a trusted state.
FortiBleed serves as a reminder that perimeter security is only as strong as the credentials and access measures protecting it. Organizations can’t rely solely on firmware updates or password resets to prevent a compromise. A successful response requires an in-depth review of privileged access, authentication controls, network exposures, logging, and configuration integrity. By restricting public access, enforcing phishing-resistant MFA, monitoring suspicious activity, and validating firewall configurations, organizations can significantly reduce the risk of credential-based attacks and unauthorized access. The goal is not simply to change compromised credentials, but to restore trust in the FortiGate environment and ensure that attackers can no longer leverage previously obtained access.
Leave a Reply