-----BEGIN PGP SIGNED MESSAGE-----
AUSCERT External Security Bulletin Redistribution
FortiOS CAPWAP server two vulnerabilities
6 February 2015
AusCERT Security Bulletin Summary
Publisher: FortiGuard Labs
Operating System: Network Appliance
Impact/Access: Denial of Service -- Remote/Unauthenticated
Cross-site Scripting -- Remote with User Interaction
CVE Names: CVE-2015-1452 CVE-2015-1451
- --------------------------BEGIN INCLUDED TEXT--------------------
FortiOS CAPWAP server two vulnerabilities
Risk 2 Low
Date Feb 05 2015
Impact Limitation of Capwap service, authenticated XSS
CVE ID CVE-2015-1451, CVE-2015-1452
CAPWAP 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 (AC).
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
server will prevent the addition of new legitimate APs.
2. An XSS vulnerability: Sending a CAPWAP join message to the server, with
when a user attempts to manage the access points from the FortiGate's
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, wired
network 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, a
successful 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 AP
during 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 "The
CAPWAP DTLS protocol was found to use a universal Fortinet_Factory certificate
and private key, the certificate authority for which is static across all
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 stage
a 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).
FortiOS 4.3.0 and later with CAPWAP enabled.
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 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. For
instance, 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
- --------------------------END INCLUDED TEXT--------------------
You have received this e-mail bulletin as a result of your organisation's
registration with AusCERT. The mailing list you are subscribed to is
maintained within your organisation, so if you do not wish to continue
receiving these bulletins you should contact your local IT manager. If
you do not know who that is, please send an email to firstname.lastname@example.org
and we will forward your request to the appropriate person.
NOTE: Third Party Rights
This security bulletin is provided as a service to AusCERT's members. As
AusCERT did not write the document quoted above, AusCERT has had no control
over its content. The decision to follow or act on information or advice
contained in this security bulletin is the responsibility of each user or
organisation, and should be considered in accordance with your organisation's
site policies and procedures. AusCERT takes no responsibility for consequences
which may arise from following or acting on information or advice contained in
this security bulletin.
NOTE: This is only the original release of the security bulletin. It may
not be updated when updates to the original are made. If downloading at
a later date, it is recommended that the bulletin is retrieved directly
from the author's website to ensure that the information is still current.
Contact information for the authors of the original document is included
in the Security Bulletin above. If you have any questions or need further
information, please contact them directly.
Previous advisories and external security bulletins can be retrieved from:
Australian Computer Emergency Response Team
The University of Queensland
Internet Email: email@example.com
Facsimile: (07) 3365 7031
Telephone: (07) 3365 4417 (International: +61 7 3365 4417)
AusCERT personnel answer during Queensland business hours
which are GMT+10:00 (AEST).
On call after hours for member emergencies only.
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----