FortiOS CAPWAP server two vulnerabilities
Impact DetailCAPWAP stands for Control And Provisioning of Wireless Access Points; it is a standard protocol that enables an Access Controller (AC) to manage a collection of wireless Access Points (AP).
Fortinet FortiOS embeds a CAPWAP server, which allows FortiGates to act as an Access Controller. This CAPWAP server is subject to two vulnerabilities, mitigated by various factors.
1. A DoS condition: The server only accepts to control a limited number of concurrent APs. Sending enough fake "ClientHello" new AP requests to the serverwill prevent the addition of new legitimate APs.
CAPWAP is not enabled by default on FortiOS, hence the vulnerabilities only concern users who actively use it to manage a collection of Access Points.
For the latter, the mitigation factors then apply:
Regarding the DoS condition: The attacker must have network access to the CAPWAP server. This usually implies having access to the physical, wirednetwork linking APs to the server (as the FortiGate is meant to serve as a gateway between the isolated APs network and other networks). Beyond this, asuccessful DoS attack would prevent addition of new APs, but would not disrupt the CAPWAP service for APs that have already been configured.
Regarding the XSS vulnerability: The attacker must have network access to the CAPWAP server (see DoS condition above), and authenticate as a legitimate APduring the DTLS handshake (CAPWAP join requests happen after the DTLS channel is established), which requires being in possession of an X.509 Certificate (and its associated private key) from an actual FortiAP.
According to security-assessment.com, there would be a DTLS Man-in-the-Middle vulnerability, between the CAPWAP server and the APs, due to the fact "TheCAPWAP DTLS protocol was found to use a universal Fortinet_Factory certificate and private key, the certificate authority for which is static across all Fortinet devices".
This is untrue: The Fortinet_Factory certificate is unique to each device, and signed by Fortinet's root CA (Fortinet_ca). An attacker cannot therefore stagea MitM attack using the certificate and private key published by security-assessment.com (except if the attack targets the FortiGate they used for their test).
Affected ProductsFortiOS with CAPWAP enabled:
5.2.2 and below
5.0.11 and below
SolutionsUpgrade FortiOS to the following versions:
Make sure CAPWAP is disabled if not needed:
show system interface
Must not display "capwap" in the "allowaccess" entry. If it is present, the interface must be re-configured without capwap. For instance:
config system interface
set allowaccess ssh https
If CAPWAP is needed, the XSS vulnerability have been fixed starting with FortiOS 5.2.3.
Otherwise the following workarounds apply:
Regarding the DoS condition and the XSS vulnerability: Use a local-in policy to restrict access to the CAPWAP server to IP addresses of legitimate APs. Forinstance, to authorize only the 192.168.1.0/24 subnet:
config firewall address
set subnet 192.168.1.0 255.255.255.0
config firewall service custom
set udp-portrange 5246
config firewall local-in-policy
set intf "any"
set srcaddr "lan_subnet"
set dstaddr "all"
set service "capwap_udp"
set schedule "always"
Regarding the XSS vulnerability, to prevent a successful attacker from hijacking your user session in the GUI, make sure to restrict your Trusted Hosts to your IP address only:
Single-vdom configuration: System->Admin->Administrators
Multi-vdoms configuration: Global->Admin->Administrators