Log4j update: a Federal deadline, Conti sightings, and the scanning challenge.

CSO offers a timeline of Log4j vulnerability story, starting at December 9th, when the Apache Foundation publicly released details on the issues Alibaba had discovered and privately disclosed.

Barracuda usefully frames exploitation of Log4j vulnerabilities as a species of log injection attack: "Log injection is possible when user-controlled input is logged without sanitation, and it and can have a number of consequences, including remote code execution (RCE). This was the case with the recently disclosed CVE-2021-44228 a.k.a. “log4shell” attack against log4j versions prior to 2.15.0 or attacks that have overridden the default formatMsgNoLookups property in 2.15.x versions before the functionality was removed completely in 2.16.0 and above."

Advice on Log4j vulnerabilities from the Five Eyes.

The Five Eyes (Australia, Canada, New Zealand, the United Kingdom, and the United States) have updated their guidance on mitigating the risk Log4j vulnerabilities pose. Their advice has remained generally stable. They recommend:

• "Identifying assets affected by Log4Shell and other Log4j-related vulnerabilities, 
• "Upgrading Log4j assets and affected products to the latest version as soon as patches are available and remaining alert to vendor software updates, and
• "Initiating hunt and incident response procedures to detect possible Log4Shell exploitation." 

CISA's first Log4j remediation deadline falls this afternoon.

Today is the deadline for US Federal civilian agencies to mitigate Log4j vulnerabilities in compliance with the Cybersecurity and Infrastructure Security Agency's (CISA) Emergency Directive (ED) 22-02. CISA "encourage[s] all organizations to take similar steps." The steps agencies that fall within CISA's remit must take, by 5:00 PM Eastern today, are:

1. "Enumerate all solution stacks accepting data input from the internet.
2. "Evaluate all software assets in identified solution stacks against the CISA-managed GitHub repository (https://github.com/cisagov/log4j-affected-db) to determine whether Log4j is present in those assets and if so, whether those assets are affected by the vulnerability.
3. "If the software product is not listed in the repository, request addition by submitting a “pull” request using the link on the GitHub page[1].
4. "For all software assets that agencies identify as affected by CVE-2021-44228:
5. "Update assets for which patches have been provided. Remediation timelines prescribed in BOD 22-01 “may be adjusted in the case of grave risk to the Federal Enterprise.” Given the criticality of CVE-2021-44228, agencies must immediately patch any vulnerable internet-facing devices for which patches are available, under an emergency change window. OR
6. "Mitigate the risk of vulnerability exploitation using one of mitigating measures provided at: ED 22-02: Apache Log4j Recommended Mitigation Measures | CISA. OR
7. "Remove affected software assets from agency networks.
8. "For all solution stacks containing software that agencies identified as affected: assume compromise, identify common post-exploit sources and activity, and persistently investigate and monitor for signs of malicious activity and anomalous traffic patterns (e.g., JDNI LDAP/RMI outbound traffic, DMZ systems initiating outbound connections)."

The next deadline arrives on December 28th. By 5:00 PM next Wednesday, agencies are to report on the affected applications they've found, and to confirm "that your agency’s Internet-accessible IP addresses on file with CISA are up to date, as required by CISA Binding Operational Directive 19-02."

Scanning for Log4j vulnerabilities.

CISA has also published an open-sourced scanner designed to detect Log4j vulnerabilities. "This tool is intended to help organizations identify potentially vulnerable web services affected by the log4j vulnerabilities." The scanner was developed from a variety of other open source tools developed in response to the discovery and disclosure of Log4j issues. The scanner is available on GitHub. BleepingComputer points out some of the scanner's more significant features:

• Support for lists of URLs.
• Fuzzing for more than 60 HTTP request headers (not only 3-4 headers as previously seen tools).
• Fuzzing for HTTP POST Data parameters.
• Fuzzing for JSON data parameters.
• Supports DNS callback for vulnerability discovery and validation.
• WAF Bypass payloads.

Scanning is not, as researchers at Rezilion blog, a trivial matter:

"In order to estimate how big the industry’s current blindspot is Rezilion’s vulnerability research team conducted a survey where multiple open source and commercial scanning tools were assessed against a dataset of packaged Java files where Log4j was nested and packaged in various formats. All formats are commonly used by developers and IT teams. Some scanners did better than others, but none was able to detect all formats."

The scanning tools are good as far as they go, but they miss "edge cases," and Rezillion says there are, in this case, a lot of "edge cases." The company writes:

"As we’ve seen, scanners have blindspots. Security leaders cannot blindly assume that various open source or even commercial-grade tools will be able to detect every edge case.

"In order to fully understand the risk, and be able to effectively mitigate it, it is imperative to understand these limitations. Consider what might be absent from your scanning tools’ results, as they all have blindspots. Ensure that your scanner takes transitive dependencies into account when you scan your codebase for vulnerable components. And lastly, complement static scanning with code-level detection in runtime memory, where the code isn’t packaged or nested." 

Responsible disclosure, sure, but responsible to whom?

Engineers at Hangzhou-based online retailer Alibaba were the ones who discovered and disclosed Log4Shell. But Chinese authorities have taken issue with the way Alibaba disclosed it. The Ministry of Industry and Information Technology (MIIT) has suspended its data-sharing agreement with Alibaba Cloud, to be lifted, Reuters reports, in six months if Alibaba mends its ways. The South China Morning Post explains that, while disclosing vulnerabilities to vendors first has long been the normal industry practice, a new law "encourages" Chinese companies to share such discoveries first with the Chinese government. The Wall Street Journal's brief account of why that courtesy has become an industry norm is clear: "Cybersecurity experts say the general etiquette for researchers who find software flaws is to privately report the vulnerabilities to developers who can issue fixes. Making software flaws or updates public before such patches are in place can set off a race among hackers to take advantage of such issues." Reuters suggests that such encouragement is of a piece with Beijing's policy of bringing IT infrastructure under government control.

What we now characterize as responsible disclosure has become the norm, but it's also been controversial before. The relatively open US Vulnerabilities Equities Process, has, for example, attracted some industry criticism for being too open, that intelligence services (and inter alia the national interest) might be better served with quieter, more targeted disclosures.

Conti is taking full advantage of Log4Shell.

The gang behind the Conti ransomware is aggressively pursuing targets vulnerable to Log4Shell exploitation. Venture Beat quotes AdvIntel to the effect that signs point to a useful diversification (useful from Conti's point-of-view) in the gang's arsenal. “For Conti, this is a major leap in their offensive operations, as they can now experiment and diversify their arsenal,” a company representative said. “This means, if a certain attack vector, like VPN accesses, becomes less profitable, they can always compensate by investing more in Log4j. Additionally, it gives them another edge in competition with smaller groups who can not afford the proper research to exploit such vulnerabilities efficiently.” Tech Republic reminds its readers that Conti's style is the double-extortion attack: steal the data, render them inaccessible, and then threaten to both withhold decryption and release stolen files unless the victims pay up.