CVE-2023-20198 Software Web UI Privilege Escalation Vulnerability

[Thomas Obbekaer Thomsen]

This seems bad. - "I'm fuzzy on the whole good/bad thing. What do you mean, "bad"? "........

LWA, and basically also CWA, uses the webservice of the 9800.

Should we all just shut down our guest networks until a workaround / patch can be found ?

Currently that is what Im thinking.

Can anyone shed some light on my concern ?

[Thomas Obbekaer Thomsen]

Yep that would be really nice to know.

CWA uses some part of the webservice I know (because it does not work if you disable http / https on the 9800), but is this short usage of the webservice for CWA an attack vector ? We just dont know, and Cisco seems awfully quiet

For now, Im recommending customers to not use CWA or LWA, just in case, since this vulnerability has been proven "in the wild". 

[Rich R]

I've been told that there will be additional details and advice on the advisory *soon* (?) for 9800.

[Finn Rud Laursen]

And of course also local web auth

[r.heitmann]

the (obvious) solution is

• "no ip http server"
• "no ip http secure-server"

i would expect that anyone who doesn't need the HTTP/HTTPS services on a device has long since turned them off.
=> if not, the time has come to do so.

For those who do need the HTTP/HTTPS service, the suggested approach is not possible.

Who could this be?

• e.g. operator of an IOS-based CA (Certificate Authority).

For these it would be nice to be able to "harden" HTTP accesses.
=> Allow only specific (e.g. loopback IPs of other routers which are allowed to access the CA) sources to exactly one loopback IP of the CA router.

1. "ip http access-class" - no "extended ACLs" are possible,
2. CoPP (Control-Plane Policing)

• CoPP uses (extended) ACLs to Classify Traffic.

Approach:

*** this doesn't solve any Authentication-Issue, but limits the exposure ***
3 Classes (for this purpose, others possible)
Class (A) - HTTP/HTTPs traffic which is allowed (correct source-IPs, correct destination-IPs - and ports)
Class (B) - all other HTTP/HTTPs traffic
Class (C) - the remaining (class-default) traffic.

Works fine here.

ip access-list extended ACL_HTTP_LOOP
 permit tcp any host <LOOPBACK-IP for CA> eq www
 permit tcp any host <LOOPBACK-IP for CA> eq 443
class-map match-all CM_HTTP_LOOP
 match access-group name ACL_HTTP_LOOP

ip access-list extended ACL_HTTP
 permit tcp any any eq www
 permit tcp any any eq 443
class-map match-all CM_HTTP
 match access-group name ACL_HTTP

policy-map PM_COPP
 !
 ! "transmit any datarate" = permit
 !
 class CM_HTTP_LOOP
  police cir 8000 conform-action transmit exceed-action transmit violate-action transmit
 !
 ! "drop any datarate" = deny
 !
 class CM_HTTP
  police cir 8000 conform-action drop exceed-action drop violate-action drop
 !
 ! add "normal" CoPP-Policies here
 !
 class class-default
  police cir 8000 conform-action transmit exceed-action transmit violate-action transmit

control-plane
 service-policy input PM_COPP
!

CoPP Statistics after "an Attack" - wrong Source-IP or wrong Destination-IP for HTTP:

* get's dropped in Class CM_HTTP

Router# show policy-map control-plane input
 Control Plane

  Service-policy input: PM_COPP

    Class-map: CM_HTTP_LOOP (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match: access-group name ACL_HTTP_LOOP
      police:
          cir 8000 bps, bc 1500 bytes, be 1500 bytes
        conformed 0 packets, 0 bytes; actions:
          transmit
        exceeded 0 packets, 0 bytes; actions:
          transmit
        violated 0 packets, 0 bytes; actions:
          transmit
        conformed 0000 bps, exceeded 0000 bps, violated 0000 bps

    Class-map: CM_HTTP (match-all)
      34 packets, 2127 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match: access-group name ACL_HTTP
      police:
          cir 8000 bps, bc 1500 bytes, be 1500 bytes
        conformed 34 packets, 2127 bytes; actions:
          drop
        exceeded 0 packets, 0 bytes; actions:
          drop
        violated 0 packets, 0 bytes; actions:
          drop
        conformed 0000 bps, exceeded 0000 bps, violated 0000 bps

    Class-map: class-default (match-any)
      1329 packets, 77200 bytes
      5 minute offered rate 2000 bps, drop rate 0000 bps
      Match: any
      police:
          cir 8000 bps, bc 1500 bytes, be 1500 bytes
        conformed 1329 packets, 77200 bytes; actions:
          transmit
        exceeded 0 packets, 0 bytes; actions:
          transmit
        violated 0 packets, 0 bytes; actions:
          transmit
        conformed 2000 bps, exceeded 0000 bps, violated 0000 bps

CoPP Statistics after "allowed HTTP":

* get's permitted in Class "HTTP_LOOP"

!
! Zugriff auf die (erlaubte) Loopback-IP
!
Router# show policy-map control-plane input
 Control Plane

  Service-policy input: PM_COPP

    Class-map: CM_HTTP_LOOP (match-all)
      467 packets, 44940 bytes
      5 minute offered rate 3000 bps, drop rate 0000 bps
      Match: access-group name ACL_HTTP_LOOP
      police:
          cir 8000 bps, bc 1500 bytes, be 1500 bytes
        conformed 188 packets, 14000 bytes; actions:
          transmit
        exceeded 35 packets, 4309 bytes; actions:
          transmit
        violated 244 packets, 26631 bytes; actions:
          transmit
        conformed 2000 bps, exceeded 1000 bps, violated 2000 bps

    Class-map: CM_HTTP (match-all)
      147 packets, 9477 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match: access-group name ACL_HTTP
      police:
          cir 8000 bps, bc 1500 bytes, be 1500 bytes
        conformed 157 packets, 10125 bytes; actions:
          drop
        exceeded 0 packets, 0 bytes; actions:
          drop
        violated 0 packets, 0 bytes; actions:
          drop
        conformed 0000 bps, exceeded 0000 bps, violated 0000 bps

    Class-map: class-default (match-any)
      2744 packets, 159642 bytes
      5 minute offered rate 1000 bps, drop rate 0000 bps
      Match: any
      police:
          cir 8000 bps, bc 1500 bytes, be 1500 bytes
        conformed 2811 packets, 163540 bytes; actions:
          transmit
        exceeded 0 packets, 0 bytes; actions:
          transmit
        violated 0 packets, 0 bytes; actions:
          transmit
        conformed 1000 bps, exceeded 0000 bps, violated 0000 bps

[Thomas Obbekaer Thomsen]

I completely concur that disabling http / https is the solution if you have (for some reason) the webservice of your IOS-XE device exposed to an , lets call it, "open" network.

I just really want to know, for sure,  if this "exposure" also includes 9800 when running CWA. I mean the 9800 does not have an IP interface in the guest network. Buuut, it kinda intercepts the clients request via the webservice anyway (thats why you need it enabled when configuring and using CWA). I just want to knoooowwww !!!

Im pretty sure LWA is vulnerable because the client gets redirected to a , lets call "loopback", interface in the 9800 for the LWA login page. 

[Rich R]

Refer to the URLs Marce shared - the bug has recommended mitigations (which should already be standard practice anyway)
Also see https://vulncheck.com/blog/cisco-implants and https://nvd.nist.gov/vuln/detail/CVE-2023-20198 which has some additional links.
As far as I can tell this affects all current versions of released code, nothing fixed available yet but I think they're still checking.  You should assume they are all vulnerable.

I think this only affects the admin web interface, but web auth interface should never be accessible to internet anyway if you have configured the WLC correctly.  And if you follow standard security guidelines your web admin interface should not be accessible to wireless users and access should be restricted to known authorised IP addresses.

The primary risk is if you have exposed the admin web interface to the internet with unrestricted access - then it's only a matter of time before you're compromised (if not already) unless you take action right away.

[Thomas Obbekaer Thomsen]

But this is what I really want to know .. if its the webservice (no matter if it runs the admin page or a web auth page) that is vulnerabel, then having it "exposed" to an open network (the guest network) is also pretty bad.

Sure, of course we have all protected the admin interface of the device , and surely no-one has anything exposed towards the internet directly. But that open guest network, in a large organization, can be "available" in many places.

And if the webservice can be accessed (not admin, but LWA or CWA) from the guest network for login purposes, and is vulnerabel because of this CVE, it would be disastrous .

[Rich R]

> Sure, of course we have all protected the admin interface of the device , and surely no-one has anything exposed towards the internet directly.
It might horrify you to know but apparently there are at least 10,000 unprotected devices connected directly to the internet - I've seen estimates of up to 140,000! So believe it or not, a LOT of people do not install their equipment according to standard security guidelines.

I agree it would be good to get 100% clarity from Cisco on which components are vulnerable.  I suspect they are not disclosing that at the moment because it might reveal more than they want people to know, about the vulnerability, but I think it's a bit late for that now - they should just be full disclosure.  I've queried via our account team but unlikely to get a response today.

[mschfr]

Well, one could disable the HTTP Server (no ip http-server) and then activate HTTP only for the redirect:

parameter-map type webauth global

  webauth-http-enable

I heard from TAC that from 17.3 onwards the web-auth server is different from the http server.

So an offical statement if we could use the webauth-http-enable command in conjunction with no ip http-server would be great.

[Rich R]

If that works that will be great but I have already been told through our account team that web-auth is also vulnerable.
23-10-2023: see update https://community.cisco.com/t5/wireless/cve-2023-20198-software-web-ui-privilege-escalation/m-p/4945848/highlight/true#M262010

I got a completely generic response from PSIRT team to advisory feedback submitted (saying they don't want to put specific solutions in the advisory and to open a TAC case!!!!!) from which it was obvious that the PSIRT guy didn't even understand the issue with WLC and web-auth!

This has to be the worst Cisco PSIRT incident response I have ever seen in 23 years of working with Cisco - it seems to have been really badly managed!  And given the severity of the problem it's inexcusable.

[Rich R]

The bug status has been changed to Fixed - but it doesn't mention a single Known Fixed Release!
I continue to be disappointed by what we're seeing here ...

498 TAC cases attached to the bug and counting ....
If they just provided all the info needed then people wouldn't need to open TAC cases!

[r.heitmann]

you're right - but it's somehow weird, that a simple

ip http active-session-modules none
ip http secure-active-session-modules none

didn't make it to "recommendations" in the Cisco document - Cisco states "workarounds available: no"

... so "disable http" or "restrict access" is all Cisco recommends, if I'm not wrong.

[Rich R]

That completely cripples the web services anyway so doesn't add any value beyond disabling the service.

[r.heitmann]

but - when

a) disabling the web-service is no option

b) the access-class using standard-ACL is no option

c) the router uses VRFs and there seems to be no possibility to limit the HTTP-server to the global-"VRF" or a specific VRF like possible with SSH

... like the WLC-users who don't want or IOS-CA-users who don't can do this...

- since they don't need the interactive HTTP-Admin-Page - it's no problem, if it might be "crippeled"

[RoadRunner4k]

The BUG/CVE is now updated with all. Will be interesting when they will provide more details, and a patch to fix this.