Security Concern – Local WebAuth Pages Accessible via HTTP on C9800-L-

[rwilkinson]

Hi,

One of our customers has a C9800-L-F-K9 HA pair running Cisco IOS XE Software, Version 17.09.05. They operate a BYOD SSID, which uses local WebAuth with custom webauth pages stored locally on the controllers:

bootflash:/custom_webauth/login.html

bootflash:/custom_webauth/failed.html

bootflash:/custom_webauth/logout.html

This configuration has been in place and functioning successfully for several years. Recently, during a penetration test, a security consultant identified a vulnerability related to the WebAuth redirection process.

When a client is redirected to the login page, the redirection occurs over HTTPS as expected, for example: https://boyd.espo.org/login.html?redirect=http://msftconnecttest.com/redirect

However, the tester was able to manipulate the URL to use HTTP instead of HTTPS (this can be done by simply removing the 's' from https://) and successfully perform an insecure login, thereby capturing the username and password with a WIFI sniffer.

We understand that HTTP must be enabled on the C9800 for WebAuth redirection to function properly, since browsers initiate the redirection using an HTTP probe. This has been tested with both of the following configurations:

- Global command: ip http server

- Parameter map command: webauth-http-enable

Both configurations expose the same vulnerability. If "no ip http server" is configured and "webauth-http-enable" is not present in the parameter map, the redirection fails entirely.

Question: Is there a way to prevent the locally hosted WebAuth pages from being directly accessed over HTTP (port 80) through URL manipulation, while still maintaining functional redirection?

We did some in house testing with WebAuth on IOS-XE17.15.03 and found that we could replicate the issue. Once the client is redirected to the login page we were able to manipulate the URL to use HTTP and login successfully. We also captured the CAPWAP traffic (unencrypted by default) and we were able to extract the username and password from the HTTP.

This is very surprising that the security can so easily be circumvented.

Any thoughts here. I've attached a snippet of the packet capture.

Cheers,

Richard.

[Mark Elsen]

  - @rwilkinson   You can (also) report  your findings to : psirt@cisco.com

  That is the Product Securkty Incident Respons Team.

 M.

[rwilkinson]

@Mark Elsen I'll look into doing that.. Thanks.

[srimal99]

I would raise a tac case as well.

[rwilkinson]

@srimal99 Thanks for the response - first thing I did was raise a case with TAC. Thought it would be worth getting community advice also.

[srimal99]

@rwilkinson Any suggestion from Tac ? 

[rwilkinson]

@srimal99 Not yet... I provided them with "show tech wireless", and they have gone very quiet over the last few days.

[rwilkinson]

So, the latest update. After TAC did some in house testing, they organised a Webex with the customer and have finally concluded the following:

====
Based on our review of the Catalyst 9800 LWA design and IOS XE 17.09.05 code, the HTTP server on port 80 is required to intercept client HTTP probes and issue the 302 redirect. There is no supported feature or parameter that distinguishes between a probe request and a user manually browsing to the local WebAuth pages, any request to port 80 will return the portal content (login, failed, logout). Disabling HTTP entirely or removing webauth-http-enable will always break the automatic redirect, and currently there is no provision to force an HTTP→HTTPS rewrite or to selectively block manual HTTP access to those pages.

As a result, this behavior is expected and considered a design limitation for (LWA) local WebAuth on the C9800. To achieve an HTTPS-only experience, you can:

• Migrate your portal to an external HTTPS-terminated web server and configure the WLC parameter map to redirect to that URL
• Use (CWA) Central WebAuth (ISE or other external portal) where the WLC only redirects and does not serve the pages directly

Both approaches allow the WLC to listen on port 80 for the probe while hosting the actual login pages on port 443 under a valid certificate.

Please let me know if you have any other queries or you’d like assistance with an external WebAuth deployment or integration with ISE.
====

Therefore, it appears that TAC are acknowledging that local Web Authentication on the c9800 is insecure and this behavior is expected and considered a design limitation.
This is a very concerning outcome from a security perspective.

====

Based on the latest findings, we understand that:

- The C9800 must listen on port 80 to intercept HTTP probes for redirection.
- The platform cannot differentiate between an HTTP probe and a user manually accessing the WebAuth pages.
- Any HTTP request to port 80 will return the WebAuth content in clear text.
- There is no supported configuration on IOS XE 17.09.05 (or the current LWA design in general) to enforce HTTPS-only access, redirect HTTP → HTTPS, or block manual HTTP access to the login/failed/logout pages.
- Therefore, this is considered expected behaviour and a design limitation of Local WebAuth on the Catalyst 9800.

This effectively means that credentials submitted via the local WebAuth login page can be captured in clear text simply by accessing the page via HTTP, which has been independently validated during penetration testing.

Given the above, the conclusion that “Local Web Authentication (LWA) on the C9800 cannot be secured against credential exposure over HTTP” is extremely concerning from a security and compliance standpoint.

This raises several points that require clarification:

1) Does Cisco officially consider C9800 Local WebAuth unsuitable for any environment requiring secure credential handling (e.g., GDPR, Cyber Essentials, ISO27001, PCI-DSS)?
2) Are there any planned enhancements, feature requests, or defect records addressing the inability to force HTTPS or block HTTP access to the portal pages?
3) Is there an official Cisco statement or security advisory that documents this limitation so it can be referenced in our security reports?

The recommendation is to migrate to an external HTTPS-hosted portal (or ISE/CWA). However, the fact remains that the current C9800 LWA implementation exposes users to credential interception, and this needs to be acknowledged in a more formal way so we can advise the customer appropriately.