Edit note, October 24: Added a section regarding updates to include additional Indicators of Compromise (IOCs) and methods for detecting the updated implant code.
In recent days, a previously undisclosed vulnerability in Cisco’s IOS XE software has sent shockwaves across the cybersecurity community. The vulnerability, tagged as CVE-2023-20198, affects physical and virtual devices running Cisco IOS XE software with the HTTP or HTTPS Server feature enabled.
Cisco uncovered early indications of potentially malicious activity on September 28, 2023, when unusual behavior was detected on a customer device. Upon delving deeper, a pattern of related activity traced back to as early as September 18 emerged. Initially, an authorized user created a local user account under the username “cisco_tac_admin” from a suspicious IP address. The saga continued into October when another cluster of related activities was discovered. This time, an unauthorized user was spotted creating a local user account named “cisco_support” from a different suspicious IP address. Unlike the September incident, this cluster revealed a more sinister plot, including the deployment of an implant consisting of a configuration file, marking a shift from mere account creation to establishing persistent access via implant deployment.
How it works
The exploit allows an attacker to create an account on the affected device with privilege level 15 access, effectively granting them full control over the compromised device. The attackers initially exploit the new vulnerability to gain a foothold on the device. Once in, they turn to a two-year-old bug, CVE-2021-1435, to install an implant on the device. Even devices patched against the old vulnerability were unsafe as the attackers managed to install the implants through an undetermined mechanism.
According to Cisco Talos, the implant, based on the Lua programming language, enables the execution of arbitrary commands at either the system level or the IOS level, depending on the parameters set in the HTTP POST request to the device. The implant code requires two parameters: “menu” and “logon_hash” to function. Interestingly, in most instances, the values of these parameters across different devices were unique, suggesting a form of authentication required for the arbitrary command execution provided in the third function of the implant.
What you should do
Cisco has provided a nice step-by-step guide on how to do this. Here is a complete flow chart of what you should do:
Cisco has urged customers to disable the HTTP Server feature on all internet-facing systems to mitigate the risks associated with this vulnerability. The Cybersecurity and Infrastructure Security Agency (CISA) echoed this advice, emphasizing the importance of reducing the risks posed by internet-exposed management interfaces. However, there is no workaround to resolve the issue, and no patch is available yet.
Next, you should verify if you have been compromised already by this exploit. The best way to do this is to look for suspicious new accounts created.
To detect if the implant is present, Cisco Talos suggests to check it via running the following command against the device, where the “DEVICEIP” portion is a placeholder for the IP address of the device to check:
curl -k -X POST "https[:]//DEVICEIP/webui/logoutconfirm.html?logon_hash=1"
This incident underscores the ever-evolving nature of cybersecurity threats and the importance of vigilance and proactive measures to mitigate such threats. The exploitation of CVE-2023-20198 highlights a grim reality – that even patched devices can fall prey to sophisticated cyber adversaries. With approximately 40.000 Cisco devices having their web UI exposed to the internet (using Shodan query), the potential scale of this vulnerability is enormous, urging for immediate and robust countermeasures. According to a post on social media platform X (former Twitter), there is already 30.000 compromised devices that have implant installed on it.
UPDATE [2023-10-24]: We would like to address the recent report throughout Cybersecurity news sites talking about a significantly decreased number of detected vulnerable devices. We would like to clarify a bit on this. The proposed initial number was from a Shodan query (internet-facing devices that can be identified via scanners) and also based on the behavior of the implant reverse-engineered by Cisco Talos. Since the vulnerability received a lot of attention, things, of course, started to change.
There are really three options that could impact such change in detection numbers (purely from internet-facing devices):
The vulnerability was mitigated according to the suggested steps.
The devices are pulled off the internet (are no longer internet-facing).
The threat actors started to change the code of the implant, so it is no longer detected by the original method.
Cisco Talos also posted an updated version of the implant code, and we can notice a change that now includes an HTTP Header check in order to thwart the identification of the implant code. There is a new suggested command for a more general check of the presence of the implant code:
curl -k "https[:]//DEVICEIP/%25"
Moreover, there are additional IOCs (Indicators of Compromise) available for the exploit attempt, which we are also continuing to contribute to the community.
These are the SNORT Rule IDs that can help you detect the exploit attempt:
3:50118 – alerts for initial implant injection (CVE-2023-20273)
3:62527 – alerts for implant interaction
3:62528 – alerts for implant interaction
3:62529 – alerts for implant interaction
3:62541 – alerts on attempted exploitation for initial access (CVE-2023-20198)
3:62542 – alerts on attempted exploitation for initial access (CVE-2023-20198)
Again, we would refer you to Cisco’s Advisory page for detailed coverage of the vulnerability developments.