How to detect Log4Shell security vulnerability exposures and attacks

The corporate security team is still busy with a series of vulnerabilities discovered in the Log4j open source Java component over the past few weeks. Patching affected libraries should be a priority, but it is not easy to identify all affected applications and servers in a vast network. This is due to indirect software dependencies and third-party products.
ⓒ Getty Images Bank

The problem is that the longer it takes a company to find potentially exposed assets, the more time an attacker has to find and exploit them. Remote code execution vulnerabilities are being exploited by a variety of attack groups, from government-backed cyberattack groups to ransomware attack groups, cryptocurrency mining and DDoS botnets.

Therefore, enterprises must not only identify vulnerable assets and formulate mitigation strategies on a case-by-case basis, but also look for signs of breaches and vulnerabilities in server and application logs.

Detect application and server vulnerabilities

The security community has developed and distributed several open source tools that can scan directories and filesystems for Log4j package instances. There are also commercial vulnerability scanners that can detect these vulnerabilities. However, all scanners can have blind spots, especially Java components like lLog4j.

In fact, many Java packages are in JAR (Java Archive) files, but besides JARs, uncompressed TAR (Tape Archive), WAR (Web Application Archive), EAR (Enterprise Application Archive), SAR (Service Application Archive), PAR (Portlet) Archive), RAR (Resource Adapter), and KAR (Apache Karaf Archive) formats are also used to deploy Java applications.

In addition, there are different types of JARs. A package called an Uber Jar or Fat Jar contains a Java program and all its dependencies, but can be shaded, unshaded, or nested. A nested JAR contains other JARs and consists of several stages.

Therefore, the Log4j vulnerability scanner must be able to support all these application types and nesting as well. Scanning only JARs with Log4j in their name in the directory can miss many instances.

Incomplete or indirect dependencies further complicate these problems. You shouldn’t only scan your application’s main dependencies, as Log4j can be a dependency of a specific dependency. According to Google researchers, as of December 19th, there were over 17,000 Java component packages that depend on Log4j in the Maven Central Repository, but only 25% of them had released a modified version. In other words, while only about 4% of these flaws directly affect the ecosystem, 80% of these packages are affected by indirect dependencies. There is no Log4j specified as a direct dependency, but it depends on other packages that pull and use Log4j. According to Google, the majority of them are intricately intertwined with five or more levels.

Researchers at Rezilion, a software configuration analysis and vulnerability management company, tested some of the open-source Log4j vulnerability scanning tools and three market-leading commercial vulnerability scanners. As a result, detection blind spots were found in all tools. While some scanners performed relatively well, none of the tools could detect Log4j instances in all the scenarios the researchers utilized. Scanners tested include Qualys and Tenable, Rapid7, Anchor’s Grype, Palantir’s Log4j-sniffer, and Aqua Security. Trivy from Aqua Security, log4j-tools from JFrog, log4j-detector from MergeBase, Dependencies from OWASP There is a Dependency Checker.

“This study proves that static scanning is limited in detecting Log4j instances,” Regilion researchers wrote in a company blog. You may also find that your code needs code-level visibility into runtime memory, where it is not packaged or nested. It also reminds us that “sensing method determines sensing performance. The scanner has blind spots. Security leaders should not blindly assume that all vulnerabilities can be detected by various open source or commercial tools. In the case of Log4j, this is because there are many cases where vulnerabilities exist in blind spots.”

In conclusion, companies should use a variety of tools, including commercial vulnerability tools, to detect vulnerabilities. This is because results may vary from scanner to scanner. Additionally, if the scanner has access to the application source code, then a software configuration analysis tool and a code vulnerability scanner should be used together to find and resolve incomplete dependencies. Ultimately, this scanning blind spot reminds us of the importance of continuously monitoring vulnerability attack attempts and potential breaches.

How to detect a Log4j vulnerability attack

As with a vulnerable Log4j instance, it is not easy to identify all exploit attempts from a log file. This is because there are many ways that attackers can hide their malicious requests. The discovery of a vulnerability attack signal in a server log file does not mean that the attack attempt was successful.

Many automated attacks attempt brute force hacking into Java applications with or without Log4j. Another example is where attacking is easier than defending. In this case, attackers must follow up to detect security vulnerabilities with a detailed forensic investigation into whether the targeted application is actually using Log4j. Previously modified apps should be checked again with a different scanner. This is because Log4j may exist in incomplete dependencies or nested JARs.

Before excluding the breach, it is necessary to investigate the currently known Log4j attack-related artifacts or signs of breach. All of these fall into the realm of threat hunting, which is difficult to define clearly. Here are some free tools and resources to help you defend against exploits.

  • In addition to the YARA rules related to the Log4j IOC, Nextron Systems researcher Florian Ross has also created a log analysis tool called Log4Shell Detector. You can also utilize Nextron’s free multi-platform IOC and YARA scanner THOR Lite.
  • A researcher using the nickname back2root created a RegEx called ‘Log4Shell-Rex’. This regular expression is used from the command line or SIEM to look for signs of a Log4Shell vulnerability, including attacks using various obfuscation techniques. RegEx detects as many attacks as possible, but there are also an acceptable degree of false positives. According to the researcher, while RexEx is effective for most attacks, sophisticated attackers can find ways to circumvent it if they so desire.
  • Mandiant has developed two open source tools to detect attempted attacks against Java deserialization vulnerabilities. This vulnerability is an entire vulnerability category including Log4Shell.
  • Palo Alto Networks has also created a number of Log4Shell rules that can be utilized to inspect cloud logs as well as processes and outbound in network environments.
  • The Microsoft Azure team has created several detection rules for the Log4Shell IOC that can be used with Azure Sentinel.
  • Curated Intel, a voluntary community of private researchers around the world, has profiled active exploit risks associated with Log4Shell, and in addition to a list of known vulnerability products, AlienVault, KPMG, Equinix ), IOC feeds from several security companies were also analyzed and validated.
  • The NCC group has published a list of IOCs as well as detection rules that can be used with Suricata, an open source network threat detection engine.
  • The CISA advisory contains links to additional free resources with detection rules and IOCs created by trusted vendors and researchers. [email protected]

Source: ITWorld Korea by www.itworld.co.kr.

*The article has been translated based on the content of ITWorld Korea by www.itworld.co.kr. If there is any problem regarding the content, copyright, please leave a report below the article. We will try to process as quickly as possible to protect the rights of the author. Thank you very much!

*We just want readers to access information more quickly and easily with other multilingual content, instead of information only available in a certain language.

*We always respect the copyright of the content of the author and always include the original link of the source article.If the author disagrees, just leave the report below the article, the article will be edited or deleted at the request of the author. Thanks very much! Best regards!