This is default featured slide 1 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 2 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 3 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 4 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 5 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

Critical Apache HTTPD Server Bugs Could Lead to RCE, DoS

 

Description

Don’t duck at the latest mention of Apache: Two critical bugs in its HTTP web server – HTTPD – need to be patched pronto, lest they lead to attackers triggering denial of service (DoS) or bypassing your security policies.

Apache, the open-source software foundation behind the Log4J logging library that’s been making for so many Log4Shell headlines, on Monday put out an update to fix the two bugs in HTTPD, which is a web server that’s right up there with Log4j in its ubiquity.

Both vulnerabilities are found in Apache HTTP Server 2.4.51 and earlier.

The first issue (CVE-2021-44790) is with the function “r:parsebody” of the component “mod_lua Multipart Parser.” As the VulDB vulnerability database describes it, “manipulation with an unknown input leads to a memory-corruption vulnerability” that “is going to have an impact on confidentiality, integrity and availability.”

VulDB also noted that the issue is reportedly easy to exploit: It is possible to launch the attack remotely. The exploitation doesn’t require any form of authentication.”

Although technical details are known, there’s no available exploit – at least, not yet. As of Monday, the vulnerability’s structure had suggested that an exploit would fetch between $5,000 and $25,000, VulDB estimated.

In a Tuesday writeup of the two CVEs, Sophos principal security researcher Paul Ducklin said that the two bugs could leave servers at risk of some serious hurt.

“These bugs might not be exposed in your configuration, because they are part of optional run-time modules that you might not actually be using,” Ducklin noted. “But if you are using these modules, whether you realize it or not, you could be at risk of server crashes, data leakage or even remote code execution.”

On Monday, Apache published these details for the two CVEs in its changelog:

  • CVE-2021-44790: Possible buffer overflow when parsing a carefully crafted request in the mod_lua multipart parser of Apache HTTP Server 2.4.51 and earlier. Apache said that its HTTPD team hasn’t seen an exploit, but “it might be possible to craft one.”
  • CVE-2021-44224: Possible NULL dereference or Server Side Request Forgery (SSRF) in forward proxy configurations, likewise in Apache HTTP Server 2.4.51 and earlier.

On Tuesday, CERT-FR sent out an alert about the issue.

CERTFR-2021-AVI-972 : Multiples vulnérabilités dans Apache httpd (21 décembre 2021)https://t.co/SB0gpBJcd4

— CERT-FR (@CERT_FR) December 21, 2021

HTTPD: It’s Here, It’s There, It’s Every-Bleeping-Where

Ducklin noted that Apache’s brawny server has “more than 3,000 files totaling close to a million [lines] of source code,” making it not only “a large and capable server,” but one with “myriad combinations of modules and options, making it both powerful and dangerous at the [same] time.”

These bugs shouldn’t get lost amidst the Log4J brouhaha, Ducklin said, given that “you almost certainly have Apache HTTPD in your network somewhere. Just like Log4j, HTTPD has a habit of getting itself quietly included into software projects, for example as part of an internal service that works so well that it rarely draws attention to itself, or as a component built unobtrusively into a product or service you sell that isn’t predominantly thought of as ‘containing a web server.’”

Sean Nikkel, senior cyber-threat intel analyst at Digital Shadows, noted that a quick peek at the Shodan search engine reveals that there more than 3 million public devices running some version of HTTPD as of this writing, meaning there’s a chance that HTTPD is running on some internal or otherwise non-public instances.

That could mean that this vulnerability “may also be just as far-reaching as log4j,” Nikkel said.

The silver lining: “Apache dissuades people from using the mod_lua functionality in several circumstances due to the amount of control it potentially has,” he told Threatpost on Wednesday. In fact, Apache has this cautionary note on its mod_lua site:

This module holds a great deal of power over httpd, which is both a strength and a potential security risk. It is not recommended that you use this module on a server that is shared with users you do not trust, as it can be abused to change the internal workings of httpd.

However, Nikkel said, that doesn’t rule out the human factor: “There’s always the chance a server was misconfigured,” he noted.

Kudos to Patchy Apache

Used to be, the name “Apache” was presumed to be a pun for building “patchy” software, given how the open-source software was built on existing code and a bunch of software patches (but that’s not really how it got its name, according to the project’s official documentation).

Still, kudos to Apache for being extremely patchy of late, security experts said.

“It should be noted that Apache has done an exceptional job addressing the vulnerabilities that have been discovered in their products this year,” Hank Schless, senior manager of security solutions at Lookout, commented to Threatpost via email. “They’re pushing updates as soon as possible, and making it widely known that patches are available for teams. It’s important to keep in mind that software vulnerabilities are inevitable – especially these days when applications are so complex and users expect constant updates from the developers.”

OK, gratitude aside, could we just catch up with all these issues, already? That’s what Yaniv Bar-Dayan, CEO and co-founder at Vulcan Cyber, wants to know. “The integrated IT security industry is not very good at effectively mitigating known vulnerabilities, and Apache vulnerabilities are no exception,” he told Threatpost via email. “Our cyber-debt specific to Apache software was substantial prior to Log4Shell or these new HTTPD web server vulns.”

He pointed to CVE-2020-1938, the so-called “Ghostcat” security bug in the popular Apache Tomcat web server that cropped up in 2020, as an example. The bug led to a working exploit leaking on GitHub that made it a snap to exploit.

That same bug, in the Apache JServ Protocol (AJP), “has been getting a lot of interest on Remedy Cloud almost a full two years after it was disclosed,” Bar-Dayan said.

If Apache were the only software the industry had to worry about securing when vulnerabilities are found, that would be manageable, he said. But no: According to NIST, 2021 will be another record year for new vulnerability disclosures, Bar-Dayan continued.

“We need to do much better as cybersecurity pros to identify the vulnerabilities that matter to our businesses and organizations, by assessing and prioritizing associated risk,” he said. “Then we need to take control and orchestrate the mitigation effort while measuring our ability to drive cyber-hygiene and attain acceptable levels of risk.”

This Is a Priority Patch

Schless urged IT teams to address the CVEs immediately, prioritizing anything that’s publicly accessible or web-facing. “These assets are the ones that attackers will scan for in order to find vulnerable systems and exploit the vulnerability,” he said.

After that, security teams should then move on to assessing and addressing internal servers and applications to which only employees have access, he added.

“The scope of impact is likely more limited than what we’ve seen recently, but that shouldn’t change the urgency with which the CVEs are patched,” Schless recommended. “If attackers aren’t yet in a vulnerable environment, they will be scanning the internet for vulnerable software using HTTPD. However, if the attacker has already made their initial entry and is performing reconnaissance on the environment, they will likely try to locate vulnerable internal assets. This highlights the importance of understanding how every user in your infrastructure accesses and interacts with your apps and the data stored in them.”

Nikkel noted that support teams that might be stressing over yet another patch might wring some solace out of the fact that there are “some conditions and mitigations to this, so it may not apply to all installations.”

Still, given that “these are typical web services deployed facing the internet,” the “patch ASAP” rule yet again applies, he said.

_Image courtesy of Tom Thai. Licensing details. _

China suspends deal with Alibaba for not sharing Log4j 0-day first with the government

 

Description

China’s internet regulator, the Ministry of Industry and Information Technology (MIIT), has temporarily suspended a partnership with Alibaba Cloud, the cloud computing subsidiary of e-commerce giant Alibaba Group, for six months on account of the fact that it failed to promptly inform the government about a critical security vulnerability affecting the broadly used Log4j logging library.

The development was disclosed by Reuters and South China Morning Post, citing a report from 21st Century Business Herald, a Chinese business-news daily newspaper.

“Alibaba Cloud did not immediately report vulnerabilities in the popular, open-source logging framework Apache Log4j2 to China’s telecommunications regulator,” Reuters said. “In response, MIIT suspended a cooperative partnership with the cloud unit regarding cybersecurity threats and information-sharing platforms.”

Tracked as CVE-2021-44228 (CVSS score: 10.0) and codenamed Log4Shell or LogJam, the catastrophic security shortcoming allows malicious actors to remotely execute arbitrary code by getting a specially crafted string logged by the software.

Log4Shell came to light after Chen Zhaojun of Alibaba cloud security team sent an email alerting the Apache Software Foundation (ASF) on November 24 about the flaw, adding that it “has a major impact.” But just as the fix was being put in place, details of the vulnerability were shared on a Chinese blogging platform by an unidentified actor on December 8, sending the Apache team scrambling to release a patch on December 10.

Post the bug’s public disclosure, Log4Shell has been subjected to widespread exploitation by threat actors to take control of susceptible servers, thanks to the near-ubiquitous use of the library, which can be found in a variety of consumer and enterprise services, websites, and applications — as well as in operational technology products — that rely on it to log security and performance information.

In the ensuing days, further investigation into Log4j by the cybersecurity community has since uncovered three more weaknesses in the Java-based tool, prompting the project maintainers to ship a series of security updates to contain real-world attacks exploiting the flaws.

Israeli security firm Check Point noted that it has blocked over 4.3 million exploitation attempts so far, with 46% of those intrusions made by known malicious groups. “This vulnerability may cause the device to be remotely controlled, which will cause serious hazards such as theft of sensitive information and device service interruption,” the MIIT had previously said in a public statement published on December 17, adding it was only made aware of the flaw on December 9, 15 days after the initial disclosure.

The pushback from MIIT arrives months after the Chinese government issued new stricter vulnerability disclosure regulations that mandate software and networking vendors affected with critical flaws, alongside entities or individuals engaged in network product security vulnerability discovery, to report them first-hand to the government authorities mandatorily within two days.

In September, the government also followed it up by launching “cyberspace security and vulnerability professional databases” for the reporting of security vulnerabilities in networks, mobile apps, industrial control systems, smart cars, IoT devices, and other internet products that could be targeted by threat actors.

Update: After China’s internet security regulator dropped Alibaba Cloud from its cyber threat intelligence partnership for six months, the cloud computing company on Thursday said it would work towards improving its risk management and compliance, according to a new report from the South China Morning Post. Alibaba Cloud also said it did not fully comprehend the severity of the flaw and that it did not share the details with the government in a timely fashion.

Mitigating Log4Shell and Other Log4j-Related Vulnerabilities

 

Description

CISA, the Federal Bureau of Investigation (FBI), the National Security Agency (NSA), and the cybersecurity authorities of Australia, Canada, New Zealand, and the United Kingdom have released a joint Cybersecurity Advisory in response to multiple vulnerabilities in Apache’s Log4j software library. Malicious cyber actors are actively scanning networks to potentially exploit CVE-2021-44228 (known as “Log4Shell”), CVE-2021-45046, and CVE-2021-45105 in vulnerable systems. According to public reporting, Log4Shell and CVE-2021-45046 are being actively exploited.

This advisory expands on CISA’s previously published guidance, drafted in collaboration with industry members of CISA’s Joint Cyber Defense Collaborative (JCDC), by detailing recommended steps that vendors and organizations with information technology, operational technology/industrial control systems, and cloud assets should take to respond to these vulnerabilities.

CISA, FBI, NSA, the Australian Cyber Security Centre (ACSC), the Canadian Centre for Cyber Security (CCCS), the Computer Emergency Response Team New Zealand (CERT NZ), the New Zealand National Cyber Security Centre (NZ NCSC), and the United Kingdom’s National Cyber Security Centre (NCSC-UK) assess that exploitation of these vulnerabilities, especially Log4Shell, is likely to increase and continue over an extended period. CISA and its partners strongly urge all organizations to review AA21-356A: Mitigating Log4Shell and Other Log4j-Related Vulnerabilities for detailed mitigations.

This product is provided subject to this Notification and this Privacy & Use policy.

Java Code Repository Riddled with Hidden Log4j Bugs; Here's Where to Look

 

Description

There’s an enormous amount of software vulnerable to the Log4j bug through Java software supply chains — and administrators and security pros likely don’t even know where to look for it.

About 17,000 Java packages in the Maven Central repository, the most significant collection of Java packages available to developers, are vulnerable to Log4j — and it will likely take “years” for it to be fixed across the ecosystem, according to Google security.

Following the CVE update that just Log4j-core was affected, eliminating vulnerable instances of the Log4j-api, Google Security determined that as of Dec. 19, more than 17,000 packages in Maven Central were vulnerable, about 4 percent of the entire repository. Of those, just 25 percent of the packages had updated versions available, Google added.

For comparison, the Google researchers explained in a Tuesday blog post that the average bug affects between 2 percent and less than .01 percent of such packages.

Sonatype, the organization which maintains Maven Central, has a dashboard that’s updated several times a day with the latest on Log4j and reported that since Dec. 10, more than 40 percent of the packages being downloaded were still vulnerable, totaling nearly 5 million downloads.

And those are new downloads that leave apps and projects open to Log4j attacks.

Start At the Deepest Point in Supply Chain and Work Up

Log4j is lurking in “dependencies” on flawed code, both direct and indirect, up and down the supply chain, Google explained.

“The majority of affected artifacts come from indirect dependencies (that is, the dependencies of one’s own dependencies), meaning Log4j is not explicitly defined as a dependency of the artifact, but gets pulled in as a transitive dependency,” the Google team said.

Making these unpatched Log4j versions even sneakier to track down is “how far down the software supply chain it’s typically deployed,” the analysts added.

“For greater than 80 percent of the packages, the vulnerability is more than one level deep, with a majority affected five levels down (and some as many as nine levels down),” the report warned. “These packages will require fixes throughout all parts of the tree, starting from the deepest dependencies first.”

Why Java Is Trickier Than Other Ecosystems

Adding another degree of difficulty to ferreting out the Log4j bugs is Java’s “soft” version requirements, according to Google.

“Propagating a fix often requires explicit action by the maintainers to update the dependency requirements to a patched version,” the Google researchers said. “This practice is in contrast to other ecosystems, such as npm, where it’s common for developers to specify open ranges for dependency requirements.”

In the face of these unique challenges, Google reported open-source maintainers and security teams have already made incredible efforts to patch systems. But there’s still a ton of work left to do before Log4j is in the industry’s rear view for good.

To help out, Google has pulled together a list of the 500 most-used and impacted Java code packages.

“We looked at all publicly disclosed critical advisories affecting Maven packages to get a sense of how quickly other vulnerabilities have been fully addressed,” the team said. “Less than half (48 percent) of the artifacts affected by a vulnerability have been fixed, so we might be in for a long wait, likely years.”

Two Active Directory Bugs Lead to Easy Windows Domain Takeover

 

Description

A proof-of-concept tool has been published that leverages two Windows Active Directory bugs fixed last month that, when chained, can allow easy Windows domain takeover.

In a Monday alert, Microsoft urged organizations to immediately patch the pair of bugs, tracked as CVE-2021-42287 and CVE-2021-42278, both of which were fixed in its November 2021 Patch Tuesday release.

Both vulnerabilities are described as a “Windows Active Directory domain service privilege-escalation” bugs and are of high severity, with a CVSS criticality score of 7.5 out of 10.

“As always, we strongly advise deploying the latest patches on the domain controllers as soon as possible,” Microsoft advised.

Bugs Give Attackers ‘Straight Path’ to Admin Privileges

The vulnerabilities allow attackers to easily jack up privileges to that of domain admin in unpatched Windows Active Directory domain services after impersonating a regular domain user, according to Microsoft’s advisory.

Domain administrators in Windows are users that can modify the configuration of Active Directory servers and can modify any content stored there. Domain admins can create new users, delete users and change their permissions; and can control authorization and authentication to Windows services.

“​When combining these two vulnerabilities, an attacker can create a straightforward path to a domain admin user in an Active Directory environment that hasn’t applied these new updates,” according to the security alert. “This escalation attack allows attackers to easily elevate their privilege to that of a Domain Admin once they compromise a regular user in the domain.”

On Dec. 11, a proof-of-concept (PoC) tool to exploit the bugs was publicly released on Twitter and GitHub, just a few weeks after Patch Tuesday November 2021. Multiple security researchers confirmed that it works and that the exploit is easy.

Exploiting CVE-2021-42278 and CVE-2021-42287. From Standard AD User to a Domain Admin! (default configuration)https://t.co/feX2OBe5BJ pic.twitter.com/3tbYtOgEMW

— Hsm (@safe_buffer) December 11, 2021

How to Tell if Systems Have Been Compromised

Microsoft defines the exploit as SAM Name impersonation. Same Account Name (SAM) refers to the sAMAccountName attribute: a logon name used to support clients and servers from previous versions of Windows, such as Windows NT 4.0, Windows 95, Windows 98 and LAN Manager.

Microsoft’s research team published detailed guidance on detecting signs of exploitation and identifying compromised servers with a Defender for Identity advanced hunting query that sniffs out abnormal device name changes: changes that “should happen rarely to begin with,” it said. Defender for Identity is a cloud-based security tool that uses on-premises Active Directory signals to identify, detect and investigate advanced threats, compromised identities and malicious insider actions.

The query compares those name changes with a list of domain controllers in your environment, researchers said. “To investigate if these vulnerabilities might have been exploited in your environment before the hotfixes were deployed, we highly recommend you follow the step-by-step guide,” Microsoft recommended, providing these instructions:

  1. The sAMAccountName change is based on event 4662. Please make sure to enable it on the domain controller to catch such activities. Learn more of how to do it here.
  2. Open Microsoft 365 Defender and navigate to Advanced Hunting.
  3. Copy the following query (which is also available in the Microsoft 365 Defender GitHub Advanced Hunting query):
    IdentityDirectoryEvents | where Timestamp > ago(1d) | where ActionType == “SAM Account Name changed” | extend FROMSAM = parse_json(AdditionalFields)[‘FROM SAM Account Name’] | extend TOSAM = parse_json(AdditionalFields)[‘TO SAM Account Name’] | where (FROMSAM has “$” and TOSAM !has “$”) or TOSAM in (“DC1”, “DC2”, “DC3”, “DC4”) // DC Names in the org | project Timestamp, Application, ActionType, TargetDeviceName, FROMSAM, TOSAM, ReportId, AdditionalFields
  4. Replace the marked area with the naming convention of your domain controllers
  5. Run the query and analyze the results which contains the affected devices. You can use Windows Event 4741 to find the creator of these machines, if they were newly created
  6. We recommend investigating these compromised computers and determine that they haven’t been weaponized.
  7. Make sure to update the devices with the following KBs: KB5008102, KB5008380, KB5008602.

“Our research team continues its effort in creating more ways to detect these vulnerabilities, either with queries or out-of-the-box detections,” Microsoft said.

Don’t Let the Log4j Noise Drown This One Out

The Log4j Apache logging library misery is sucking all the oxygen out of the room right now, but security experts said that organizations have to find time for dealing with these bugs. Securing Active Directory is crucial, given its pivotal role in account authorization and authentication and the horrific compromise that can result if vulnerabilities like these are exploited.

“Active Directory is typically the keys to the kingdom,” Tyler Shields, CMO at JupiterOne and a former Forrester Research analyst, told Threatpost via email on Tuesday. “Targeting the system that holds account authorization and authentication information can result in massive compromise of an enterprise. It’s one of the most commonly deployed account management systems on the planet and must be kept secure and up to date.”

John Bambenek, principal threat hunter at Netenrich, said that if an attacker gets domain admin privileges, they can “quite literally do almost anything they want to any machine in an organization with impunity.”

Ransomware operators, for example, would find these vulnerabilities interesting if they want to “ransom an entire organization at once,” Bambenek said. Using the PoC to install ransomware on every Windows machine in an organization “would be trivial,” he added.

AD is not only ubiquitous – it’s also constantly under siege by adversaries, noted Tim Wade, technical director, CTO team at AI-based cybersecurity firm Vectra. It’s “the preferred method of progress through an enterprise once an initial foothold has been achieved,” he told Threatpost via email.

A case in point: AD played a part in the SolarWinds attacks, when adversaries hit Active Directory Servers with the FoggyWeb backdoor. AD is, unfortunately, a nightmare to secure, as has been outlined by SpecterOps researchers who’ve tried to get the security community to think about the AD problem in terms of “misconfiguration debt”: as in, incremental misconfigurations that build up over time, such that attackers are virtually guaranteed to find an attack path to their objective on any network.

Don’t let these bugs add to that misconfiguration debt, experts said.

“These two bugs … [are] absolutely worth attention, given the direct line of sight between their presence and full domain compromise” Wade stressed. ” When it rains in information security, it seems to pour – but this isn’t something that network defenders should lose any time patching out of their environment.”

122121 12:54 UPDATE: Added input from Tyler Shields, John Bambenek and Tim Wade.

122121 14:23 UPDATE: Corrected misspelling of John Bambenek’s name.

Conti Ransomware Gang Has Full Log4Shell Attack Chain

 

Description

The Conti ransomware gang, which last week became the first professional crimeware outfit to adopt and weaponize the Log4Shell vulnerability, has now built up a holistic attack chain.

The sophisticated Russia-based Conti group – which Palo Alto Networks has called “one of the most ruthless” of dozens of ransomware groups currently known to be active – was in the right place at the right time with the right tools when Log4Shell hit the scene 10 days ago, security firm Advanced Intelligence (AdvIntel) said in a report shared with Threatpost on Thursday.

As of today, Monday, Dec. 20, the attack chain has taken the following form, AdvIntel’s Yelisey Boguslavskiy told Threatpost: Emotet -> Cobalt Strike -> Human Exploitation -> (no ADMIN$ share) -> Kerberoast -> vCenter ESXi with log4shell scan for vCenter.

Attack Chain

Stepping through that attack chain:

  1. Emotet is a botnet that resurfaced last month on the back of TrickBot, now with the ability to directly install …
  2. Cobalt Strike, the legitimate, commercially available tool used by network penetration testers on infected devices and pervasively adopted by cybercriminals. It gives threat actors direct access to targets and, according to Boguslavskiy, precedes…
  3. Human Exploitation, which describes the stage of an attack in which threat actors personally investigate the network, looking for critical data, analyzing the network structure, defining the most important network shares, and looking at ways to elevate privileges, among other things. That poking around is followed by …
  4. Missing ADMIN$ share.Administrative shares are hidden network shares created by Microsoft’s Windows NT operating systems that grant system administrators remote access to every disk volume on a network-connected system. As Microsoft puts it, “Missing administrative shares typically indicate that the computer in question has been compromised by malicious software.” Next up comes …
  5. Kerberoast.Kerberoasting, a common, pervasive attack that exploits a combination of weak encryption and poor service account password hygiene, is a post-exploitation attack that extracts service account credential hashes from Active Directory for offline cracking. With regards to the final link in the attack chain, the Conti gang last week zeroed in on …
  6. VMWare vCenter servers. As of Wednesday, Dec. 15, Conti was looking for vulnerable VMWare networks for initial access and lateral movement. The VMWare servers are on a dismayingly long list of affected components and vendors whose products have been found to be vulnerable to Log4Shell.

Within two days of the public disclosure of the vulnerability in Apache’s Log4j logging library on Dec. 10 – a bug that came under attack within hours – Conti group members were discussing how to exploit it as an initial attack vector, according to AdvIntel.

Apache patched the bug on Dec. 11, but its patch, Log4J2, was found to be incomplete in certain non-default configurations and paved the way for denial-of-service (DoS) attacks in certain scenarios.

As if two bugs aren’t enough, yet another, similar but distinct bug was discovered last week in the Log4J logging library. Apache issued a patch on Friday.

Conti Winds Up Its Exploit Machine

According to the Thursday AdvIntel writeup, from Vitali Kremez and Yelisey Boguslavskiy, multiple Conti group members on Dec. 12 began to chat about exploiting the Log4Shell vulnerability as an initial attack vector. That led to scanning for vulnerable systems that AdvIntel first tracked the next day, on Dec. 13.

“This is the first time this vulnerability entered the radar of a major ransomware group,” according to the writeup. The emphasis is on “major,” given that the first ransomware group to target Log4Shell was a ransomware newcomer named Khonsari. As Microsoft has reported, Khonsari was locking up Minecraft players via unofficial servers. First spotted by Bitdefender in Log4Shell attacks, the ransomware’s demand note lacked a way to contact the operators to pay a ransom. That means that Khonsari is more of a wiper, meant to troll Minecraft users by taking down their servers, rather than ransomware.

Khonsari ransomware was just one malware that’s been thrown at vulnerable servers over the course of the Log4j saga. Within hours of public disclosure of the flaw, attackers were scanning for vulnerable servers and unleashing quickly evolving attacks to drop coin-miners, Cobalt Strike, the Orcus remote access trojan (RAT). reverse bash shells for future attacks, Mirai and other botnets, and backdoors.

A Perfect Storm

Log4Shell has become a focal point for threat actors, including suspected nation state actors who’ve been observed investigating Log4j2, AdvIntel researchers noted. The compressed timeline of the public disclosure followed fast by threat actor interest and exploits exemplifies the accelerated trajectory of threats witnessed since the ProxLogon family of bugs in Exchange Server in March and the subsequent attacks, they said: “if one day a major CVE is spotted by APTs, the next week it is weaponized by ransomware,” according to their writeup.

But out of all the threat actors, Conti “plays a special role in today’s threat landscape, primarily due to its scale,” they explained. It’s a highly sophisticated organization, comprising several teams. AdvIntel estimates that, based on scrutiny of Conti’s logs, the Russian-speaking gang made over $150 million over the past six months.

But still they continue to expand, with Conti continually looking for new attack surfaces and methods.

AdvIntel listed a number of Conti’s innovations since August, including:

  • Secret backdoors: Conti’s Atera Agent allows the gang to gain persistence on infected protected environments: especially those equipped with more aggressive machine learning endpoint detention and response anti-virus productions. “The IT management solution enables monitoring, management and automation of hundreds of SMB IT networks from a single console,” AdvIntel described in an August report.
  • New backup removal solutions that expanded Conti’s ability to blow up backups.
  • An entire operation to revive Emotet, which resurfaced in November.

The writeup shared a timeline of Conti’s search for new attack vectors, shown below.

Timeline of Conti’s search for new attack vectors. Source: AdvIntel.

Keeping Your Head Above the Logjam’s Water

AdvIntel shared these suggested recommendations and mitigations for Log4Shell:

  • The Dutch National Cyber Security Center shared a list of the affected software and recommendations linked to each one of them on GitHub.
  • Here are VMWare’s workaround instructions to address CVE-2021-44228 in vCenter Server and vCenter Cloud Gateway (87081).

When Will It All End?

Lou Steinberg, former chief technology officer at TD Ameritrade, said it ain’t over til it’s over, “And it’s not over.”

“We don’t know if we patched systems after they were compromised from Log4J, so it may be a while before we know how bad things are,” he said in an article shared with Threatpost on Monday. “This will happen again. Modern software and systems are built from components which aren’t always trustworthy. Worse, bad actors know this and look to subvert the components to create a way into otherwise trusted software.”

122121 10:25 Added more attack chain details provided by AdvIntel.

122121 13:00 Removed brute-force from the attack chain, given that, as AdvIntel explained, the brute-forcing of encrypted hashes carried out in these attacks is a different kind of brute-forcing than the typical definition of trying numerous credentials.

Third Log4J Bug Can Trigger DoS; Apache Issues Patch

 

Description

No, you’re not seeing triple: On Friday, Apache released yet another patch – version 2.17 – for yet another flaw in the ubiquitous log4j logging library, this time for a DoS bug.

Trouble comes in threes, and this is the third one for log4j. The latest bug isn’t a variant of the Log4Shell remote-code execution (RCE) bug that’s plagued IT teams since Dec. 10, coming under active attack worldwide within hours of its public disclosure, spawning even nastier mutations and leading to the potential for denial-of-service (DoS) in Apache’s initial patch.

It does have similarities, though: The new bug affects the same component as the Log4Shell bug. Both the Log4Shell, tracked as CVE-2021-44228 (criticality rating of CVSS 10.0) and the new bug, tracked as CVE-2021-45105 (CVSS score: 7.5) abuse attacker-controlled lookups in logged data.

The difference: The lookups in the new bug, CVE-2021-45105, are Context Map lookups instead of the Java Naming and Directory Interface (JNDI) lookups to an LDAP server that allow attackers to execute any code that’s returned in the Log4Shell vulnerability.

ContextMapLookup allows applications to store data in the Log4j ThreadContext Map and then retrieve the values in the Log4j configuration: For example, an app would store the current user’s login id in the ThreadContext Map with the key “loginId”.

The weakness has to do with improper input validation and uncontrolled recursion that can lead to DoS.

As explained by Guy Lederfein of the Trend Micro Research Team, “the Apache Log4j API supports variable substitution in lookups. However, a crafted variable can cause the application to crash due to uncontrolled recursive substitutions. An attacker with control over lookup commands (e.g., via the Thread Context Map) can craft a malicious lookup variable, which results in a Denial-of-Service (DoS) attack.”

The new vulnerability affects all versions of the tool from 2.0-beta9 to 2.16, which Apache shipped last week to remediate the second flaw in the trio. That second bug was the RCE flaw CVE-2021-45046, which, in turn, stemmed from Apache’s incomplete fix for CVE-2021-44228, aka the Log4Shell vulnerability.

Lederfein continued: “When a nested variable is substituted by the StrSubstitutor class, it recursively calls the substitute() class. However, when the nested variable references the variable being replaced, the recursion is called with the same string. This leads to an infinite recursion and a DoS condition on the server. As an example, if the Pattern Layout contains a Context Lookup of ${ctx.apiversion}, and its assigned value is ${${ctx.apiversion}}, the variable will be recursively substituted with itself.”

The vulnerability has been tested and confirmed on Log4j versions up to and including 2.16, he said.

Apache has listed mitigating factors, but ZDI recommends upgrading to the latest version to ensure that the bug is completely addressed.

The latest bug and Apache’s new round of fixes are just the latest news in the ongoing, ever-shifting log4j situation. As exploits flood in, new vulnerabilities emerge and patches turn out to need patching, huge tech players such as SAP have been hurrying to hunt down the logging library and to release product patches.

CISA Mandates Immediate Patching

On Thursday, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) issued an emergency directive mandating federal civilian departments and agencies to immediately patch their internet-facing systems for the Log4j vulnerabilities by Thursday, Dec. 23.

The risk presented by the library’s vulnerabilities is sky-high, as multiple threat actors have jumped on the opportunities to exploit vulnerable systems. As Check Point Research (CPR) highlighted last week, real-life attacks have included a crypto-mining group that launched attacks in five countries.

Last week, Microsoft reported that nation-state groups Phosphorus (Iran) and Hafnium (China), as well as unnamed APTs from North Korea and Turkey, are actively exploiting Log4Shell in targeted attacks. Hafnium is known for targeting Exchange servers with the ProxyLogon zero-days back in March, while Phosphorus – aka Charming Kitten, APT35, Ajax Security Team, NewsBeef and Newscaster – made headlines for targeting global summits and conferences in 2020.

CPR said that Charming Kitten had gone after seven Israeli targets as of Wednesday.

Conti Ransomware Gang Is Among the Attackers

The Conti ransomware gang is in on it too: AdvIntel researchers said last week that they’re seen Conti operators going after VMware vCenter.

“The current exploitation led to multiple use cases through which the Conti group tested the possibilities of utilizing the Log4j 2 exploit,” the researchers said last week. “The criminals pursued targeting specific vulnerable Log4j 2 VMware vCenter [servers] for lateral movement directly from the compromised network resulting in vCenter access affecting U.S. and European victim networks from the pre-existent Cobalt Strike sessions.”

Last week, a ransomware attack that some suspect may be attributable to the Conti gang forced a family-run chain of restaurants, hotels and breweries, McMenamins, to shut down some operations.

The bugs are also being leveraged by botnets, remote access trojans (RATs), initial access brokers, and a new ransomware strain called Khonsari. As of Monday, CPR said that it’s seen more than 4.3 million attempted exploits, more than 46 percent of which were made by “known malicious groups.”

Yet More Sleepless Nights

Trend Micro’s Lederfein noted that the log4j component has had quite a run in the vulnerability spotlight, having received “quite a bit of attention” since the Log4Shell vulnerability was revealed 10 days ago. Expect more of the same, he predicted, as “it would not be a surprise to see further bugs disclosed – with or without a patch.”

Tom Garrubba, CISO with Shared Assessments, concurred: “This vulnerability has been keeping a lot of security professionals up at night,” he told Threatpost. This Javageddon has even percolated up to the C-suite, he said, with the vulnerability “keeping a lot of security professionals up at night.”

“Executives and board members are also gaining interest as to how this will affect them as well,” he said via email. “Log4j is used all throughout the Internet and [affects] multiple applications and systems with deep roots.”

“The best path you can take right now it’s a stay alert of all patches that are coming out to address this vulnerability and put them into place immediately,” Garrubba advised. “Sadly, it appears this is going to affect organization’s continuously into the future as they identify more items that are affected by this vulnerability.”