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.