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

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.

Notes

Author	Note
amurray	Ubuntu 18.04 LTS is not affected since the JndiLookup.class was removed in the previous update for CVE-2021-44228
ebarretto	above is also true for Ubuntu 16.04 ESM

Read More

Kronos Ransomware Outage Drives Widespread Payroll Chaos

 

Description

Kronos, the workforce management platform, has been hit with a ransomware attack that it says will leave its cloud-based services unavailable for several weeks – and it’s suggesting that customers seek other ways to get payroll and other HR tasks accomplished.

The outage has left cataclysmic issues for customers in its wake.

Kronos offers a range of solutions for employee scheduling, compensation management, payroll and hours worked, benefits administration, time-off management, talent acquisition, onboarding, and more. It counts some of the largest companies in the world as its customers, such as Tesla and Puma, along with various health, public sector and university customers; organizations like the YMCA; and smaller businesses like restaurants and retailers.

In a message to Kronos Private Cloud (KPC) customers late afternoon on Sunday, the company said that several solutions were knocked offline starting Saturday: UKG Workforce Central, UKG TeleStaff, Healthcare Extensions and Banking Scheduling Solutions.

“At this time, we still do not have an estimated restoration time, and it is likely that the issue may require at least several days to resolve,” the company said in the notice – a timeline that it expanded to likely taking several weeks in a Monday update. “We continue to recommend that our impacted customers evaluate alternative plans to process time and attendance data for payroll processing, to manage schedules, and to manage other related operations important to their organization.”

On-premise deployments are not affected, and neither are the UKG Pro, UKG Dimensions or UKG Ready offerings, it added.

“We recognize the importance of these solutions to your organization,” the company said. “We have actively mobilized all resources at our disposal to address this issue.”

Chaos for Customers

Further details over the weekend were not forthcoming, much to the chagrin of customers.

“This tells us nothing,” one comment reads on the notice page. “Is our data still there? What happened? Why the secrecy?”

Nick Tausek, security solutions architect at Swimlane, noted that the initial access vector is also unknown.

“Although Kronos Private Cloud was secured by firewalls, encrypted transmissions and multi-factor authentication, cybercriminals were still able to breach and encrypt its servers,” he said via email. “While it’s unclear exactly how the breach took place, Kronos predicts that their Private Cloud solutions will be unavailable for a number of weeks. This extended shutdown will likely present challenges for many organizations as they seek to roll out bonuses and employees look to request time off ahead of the holidays.”

And indeed, multiple customers left comments that speak to the chaos the outage is creating within their organizations, with some noting that an ongoing, extended disruption of service is unacceptable in their view.

“That simply cannot happen,” wrote Dave from the Tacoma, Wash., Fire Department, expressing disbelief that a company this large doesn’t seem to have contingency plans in place. “We must have access to rosters for today and coming days – now. Any halfway decent IT application hosting company would have disaster recovery plans for any worst-case-scenario. Running fire and police departments, this data can literally be a matter of life and death for the public and for our people. Yes, I am frustrated and angry that we don’t know what is happening.”

Another noted, “We have 50,000 employees and it’s not easy to manage without a timekeeping system. Very disappointed to say the least…This is absurd and we customers should be told what’s happening.”

Yet another: “We need to get this corrected ASAP. We don’t even know who will be working tomorrow and where. Does anyone have a good back up for if this ever happens again?”

And one resorted to dealmaking: “At this point I don’t even care for a task manager, fancy functions, callback list or picklist…Just give me a plain roster view for five days,” the person wrote. “Let me know who’s working and I’ll pick up a phone start crossing out the sick call out and making phone calls to back fill…I believe with this we can manage while you guys figure out the fix…Public safety in many counties and municipals across the U.S. is basically blind right now.”

A Ransomware Incident

Some customers floated the possibility that Kronos’ data centers are compromised by the Log4Shell vulnerability that’s wreaking havoc across the internet, but Bob Hughes, executive vice president at Kronos, clarified in a Monday update that the issue is a “ransomware incident” and that it was still assessing the scope of the damage and what impact the cyberattack had on its systems and data.

“Given that it may take up to several weeks to restore system availability, we strongly recommend that you evaluate and implement alternative business-continuity protocols related to the affected UKG solutions,” he added.

Erich Kron, security awareness advocate at KnowBe4, noted that the timing of this attack, at the close of the year while organizations are managing not only basic payroll, but also bonuses and other annual calculations that need to take place, is no coincidence.

“Ransomware gangs often time attacks to take place when organizations are short-staffed due to holidays, or when they are extremely busy, with the hope that the attack will take longer to spot and response times will be much slower,” he said via email. “In addition, the pressure to service customers during these crucial times can be very high, making it more likely that the victim will pay the ransom in an effort to get operations back up and running quickly.”

Customers again reacted with concern.

“We are blocking/disabling all ADFS and LDAP connections to UKG/Kronos Cloud until they have a better handle on what they have,” said one. “At this point they are an untrusted entity and will be treated as such. There is no good they can do us at this time.”

Several expressed worries as to the safety of their data housed in the Kronos cloud, and at least one customer has questions about the company’s backups.

“Where are the backups, can’t the backups be restored?” the person said. “Are the backups stored in the same ‘cloud/space’ as production, that doesn’t make sense?”

The situation shows that organizations must actively prepare for ransomware, Kron said.

“This attack drives home the need to not only have, but also to practice, disaster-recovery and continuity-of-operations plans that can be enacted quickly and efficiently,” he said. “The more heavily reliant organizations are on technical services, even those in the cloud, the more important it becomes to have a plan to operate without these services, even for a short time.”

He added, “Unfortunately, the Grinch has impacted Christmas for a lot of people using the KPC services. Hopefully, this does not result in a subscription to the ‘Jelly of the Month Club’ in lieu of the annual bonuses.”

There’s a sea of unstructured data on the internet relating to the latest security threats. ****REGISTER TODAY****_ to learn key concepts of natural language processing (NLP) and how to use it to navigate the data ocean and add context to cybersecurity threats (without being an expert!). This LIVE, interactive Threatpost Town Hall, sponsored by Rapid 7, will feature security researchers Erick Galinkin of Rapid7 and Izzy Lazerson of IntSights (a Rapid7 company), plus Threatpost journalist and webinar host, Becky Bracken._

Read More