Active exploitation of Cisco IOS XE Software Web Management User Interface vulnerabilities
pUpdates ppNov 02 Identified a third version of the BadCandy implant Added expected response from the new version of the implant against one of the HTTP requests used to check for infected deviceppNov 1 Observed increase in exploitation attempts since the publication of the proofsofconcept POCs of the exploits involved Named the Luabased web shell BadCandy ppOct 23 Identified an updated version of the implant Provided new curl command to check for infected devices Fixes for CVE202320198 and CVE202320273 started to roll out on Oct 22ppOct 20 Identified an additional vulnerability CVE202320273 that is exploited to deploy the implant Fixes for both CVE202320198 and CVE202320273 are estimated to be available on Oct 22 The CVE20211435 that had previously been mentioned is no longer assessed to be associated with this activityppOct 19 Added additional attacker IP and username defense evasion observations and new Snort rules Also added new information regarding our assessment that the activity is being carried out by the same actor ppWe discovered early evidence of potentially malicious activity on Sept 28 2023 when a case was opened with Ciscos Technical Assistance Center TAC that identified unusual behavior on a customer device Upon further investigation we observed what we have determined to be related activity as early as Sept 18 The activity included an authorized user creating a local user account under the username ciscotacadmin from a suspicious IP address 514924974 Instances of this activity ended on Oct 1 and we did not observe any other associated behavior at that time other than the suspicious account creation ppOn Oct 12 Cisco Talos Incident Response Talos IR and TAC detected what we later determined to be an additional cluster of related activity that began on that same day In this cluster an unauthorized user was observed creating a local user account under the name ciscosupport from a second suspicious IP address 1545356231 Unlike the September case this October activity included several subsequent actions including the deployment of an implant were calling BadCandy consisting of a configuration file ciscoserviceconf The configuration file defines the new web server endpoint URI path used to interact with the implant That endpoint receives certain parameters described in more detail below that allow the actor to execute arbitrary commands at the system level or IOS level For the implant to become active the web server must be restarted in at least one observed case the server was not restarted so the implant never became active despite being installed ppThe BadCandy implant is saved under the file path usrbinosconfnginxconfciscoserviceconf which contains two variable strings made up of hexadecimal characters The implant is not persistentmeaning a device reboot will remove itbut the newly created local user accounts remain active even after system reboots The new user accounts have level 15 privileges meaning they have full administrator access to the device This privileged access to the devices and subsequent creation of new users is tracked as CVE202320198 ppUpon successful exploitation of CVE202320198 the attackers can exploit another component of the WebUI feature to carry out command injection with elevated ie root privileges to write the implant to the file system This refers to CVE202320273 described in more detail below ppWe observed the threat actor gathering information about the device and conducting preliminary reconnaissance using commands listed in the Appendix We also observed the attacker clearing logs and removing users likely to hide evidence of their activity by using the following commands ppWe assess with a high degree of confidence that these clusters of activity were carried out by the same actor In October the actor removed evidence of the ciscotacadmin usernamewhich had been created in Septemberas part of their cleanup efforts suggesting the September and October clusters of activity were part of the same operation The first cluster was possibly the actors initial attempt and testing their code while the October activity seems to show the actor expanding their operation to include establishing persistent access via deployment of the implant ppThe successful exploitation of the vulnerabilities and deployment of the BadCandy web shell by the threat actor resulted in the application of a nonpersistent patch that prevented further exploitation likely to prevent other threat actors from taking control of already compromised systems as the POCs became more accessible ppThe CVE202320198 vulnerability received the highest Common Vulnerability Scoring System CVSS score 10critical Successful exploitation allows the attacker to gain access to the device with full administrator privileges After compromising the device we observed the adversary exploit a second vulnerability CVE202320273 which affects another component of the Web UI feature to install the BadCandy implant This allows the attacker to run arbitrary commands with elevated root privileges thereby effectively taking full control of the device In this particular attack the actor then used the ability to run arbitrary commands to write the implant to the file system CVE202320273 has a CVSS score of 72 high We identified the CVE202320273 activity by leveraging existing Cisco protectionsppBadCandy is based on the Lua programming language and consists of 29 lines of code that facilitates arbitrary command execution The attacker must create an HTTP POST request to the device which delivers the following three functions Figure 1 ppIn most instances we have observed of this implant being installed both the 18character hexadecimal string in the second function and the 40character 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 pp We have also observed a second version of BadCandy which now includes a preliminary check for the HTTP Authorization header Most of the core functionalities of this version remain the same as the previous version Figure 2 The second version likely started to be deployed as early as Oct 20 and was deployed using the earlier version of the implant ppThe addition of the header check in the implant by the attackers is likely a reactive measure to prevent the identification of compromised systems This header check is primarily used to thwart compromise identification using a previous version of the curl command provided by Talos Based on the information assessed to date we believe the addition of the header check in the implant likely resulted in a recent sharp decline in the visibility of publicfacing infected systems We have updated the curl command listed under our guidance advisory to help enable the identification of implant variants employing the HTTP header checks ppOn November 2 Talos discovered a third version of BadCandy which includes a check for the XCsrfToken HTTP header in requests to the implantppThe new variant allows the implant to check for the presence and required values of either the Authorization or the XCsrfToken HTTP headers The logic to check for the header values remains the same across both headers An incoming request to the implant qualifies as authorized as long it has one of the two headers with the correct values The introduction of the XCsrfToken header is likely a measure to communicate with the implant using a new HTTP header parameter to evade existing detection mechanisms that may be relying on the presence of the Authorization header from the previous communication traffic with the implantppThis latest variant also changes the configuration relating to the presence of a in the URI instead of returning a 404 response it now presents a standard login pageppProofofconcept POC exploit code for CVE202320198 and CVE202320273 were published on October 30 and October 31 respectively Immediately following the disclosure of the CVE202320198 POC code we saw a dramatic increase in the number of exploitation attempts against vulnerable devices Historically as POCs gain popularity they are adopted by more threat actors who will use them to conduct indiscriminate opportunistic and targeted attacks ppWe strongly recommend organizations that may be affected by this activity immediately implement the guidance and install the security fixes outlined in Ciscos Product Security Incident Response Team PSIRT advisory ppOrganizations should look for unexplained or newly created users on devices as evidence of potentially malicious activity relating to this threat One method to identify if known variants of BadCandy are present is to run the following commands against the device where the DEVICEIP portion is a placeholder for the IP address of the device to check ppThis will execute a request to the devices Web UI to see if the implant is present If the request returns a hexadecimal string similar to what was outlined in the third function above a known version of the implant is present We note this will only work as an indication of compromise if the web server was restarted by the actor after the implant was installed ppAdditionally a generic curl command can be run to help identify systems with known variants of the implant without interacting with the implants core functionality ppIf this returns a 404 HTTP response with an HTML page comprising of a 404 Not Found message a known one of the first two known variants of the implant is present If this results in a standard login page the third variant of the implant is present A system without any known variant of the implant should return a 200 HTTP response containing a JavaScript redirectppNote The above checks should use the HTTP scheme if the device is only configured for an insecure web interface ppWe also have the following Snort coverage to address this threat ppThe recommendation that Cisco has provided in its security advisory to disable the HTTPS server feature on internetfacing systems is consistent with best practices and guidance the US government has provided in the past on mitigating risk from internetexposed management interfaces This is also in line with Ciscos ongoing work with industry partners as part of the Network Resilience Coalition pp Cisco support centers collaborated with the security team after using methods and procedures to correlate similar indicators in a very small number of cases out of our normal substantial daily case volume ppThe following commands were used by the threat actor usually sequentially to conduct preliminary information gathering and reconnaissance activity on compromised systems ppIOCs for this threat can also be found in our GitHub repository here ppIn addition to the curl command referenced above perform the following checks to determine whether a device may have been compromised ppNote The SYS5CONFIGP message will be present for each instance that a user has accessed the web UI The indicator to look for is new or unknown usernames present in the message ppCVE202344487 a vulnerability in the HTTP2 protocol was recently used to launch intensive DDoS attacks against several targetsppThe group appears to commonly deploy double extortion of the victims that have been listed on the leak site several of them have had some portion of their exfiltrated data exposedppCisco Talos has identified multiple versions of an undocumented malicious driver named RedDriver a driverbased browser hijacker that uses the Windows Filtering Platform WFP to intercept browser trafficpp
Cisco Systems Inc andor its affiliates All rights reserved View our Privacy Policy
p
Cisco Systems Inc andor its affiliates All rights reserved View our Privacy Policy
p