reader comments
38 with
Cisco is urging customers to protect their devices following the discovery of a critical, actively exploited zero-day vulnerability that’s giving threat actors full administrative control of networks.
“Successful exploitation of this vulnerability allows an attacker to create an account on the affected device with privilege level 15 access, effectively granting them full control of the compromised device and allowing possible subsequent unauthorized activity,” members of Cisco’s Talos security team wrote Monday. “This is a critical vulnerability, and we strongly recommend affected entities immediately implement the steps outlined in Cisco’s PSIRT advisory.”
Under exploitation for 4 weeks
The previously unknown vulnerability, which is tracked as CVE-2023-20198, carries the maximum severity rating of 10. It resides in the Web User Interface of Cisco IOS XE software when exposed to the Internet or untrusted networks. Any switch, router, or wireless LAN controller running IOS XE that has the HTTP or HTTPS Server feature enabled and exposed to the Internet is vulnerable. At the time this post went live, the Shodan search engine showed that as many as 80,000 Internet-connected devices could be affected.
Cisco said that an unknown threat actor has been exploiting the zero-day since at least September 18. After using the vulnerability to become an authorized user, the attacker creates a local user account. In most cases, the threat actor has gone on to deploy an implant that allows it to execute malicious commands at the system or iOS level, once the web server is restarted. The implant is unable to survive a reboot, but the local user accounts will remain active.
hexadecimal characters. The advisory continued:
The implant is based on the Lua programming language and consists of 29 lines of code that facilitates the arbitrary command execution. The attacker must create an HTTP POST request to the device, which delivers the following three functions (Figure 1):
- The first function is dictated by the “menu” parameter, which must exist and must be non-empty. This returns a string of numbers surrounded by forward-slashes, which we suspect might represent the implant’s version or installation date.
- The second function is dictated by the “logon_hash” parameter, which must be set to “1”. This returns an 18-character hexadecimal string that is hardcoded into the implant.
- The third function is also dictated by the “logon_hash” parameter, which checks to see if the parameter matches a 40-character hexadecimal string that is hardcoded into the implant. A second parameter used here is “common_type”, which must be non-empty, and whose value determines whether the code is executed at the system level or IOS level. If the code is executed at the system level, this parameter must be set to “subsystem”, and if it is executed at the IOS level, the parameter must be “iox”. The IOX commands are executed at privilege level 15.
In most instances we have observed of this implant being installed, both the 18-character hexadecimal string in the second function and the 40-character hexadecimal string in the third function are unique, although in some cases, these strings were the same across different devices. This suggests there is a way for the actor to compute the value used in the third function from the value returned by the second function, acting as a form of authentication required for the arbitrary command execution provided in the third function.
The Talos team members strongly urge administrators of any affected gear to immediately search their networks for signs of compromise. The most effective means is by searching for unexplained or newly created users on devices. One means of identifying if an implant has been installed is by running the following command against the device, where the “DEVICEIP” portion is a placeholder for the IP address of the device to check:
PSIRT advisory and follow all recommendations as soon as possible.