Beyond Long4j: A Twitter Spaces Summary

In the latest Long4j Twitter spaces discussion, @syndrowm from the team at RandoriAttack, Laughing Mantis and MG, led a community-wide discussion on the latest log4j updates and fielded questions from around the community from both red and blue team members. Below is a brief summary of the discussion (caveat that I joined late and may have missed some of the beginning).

Discussion Topics

China Suspends Alibaba Deal

The group spent some time discussing the recent allegations that China suspended a deal with Alibaba over the “unlawful” disclosure of the log4j vulnerability. On December 22, Reuters announced that Chinese regulators from the Ministry of Industry and Information Technology (MIIT) suspended a partnership with Alibaba over failure to report the log4j vulnerability to government officials before disclosing it to the U.S.-based Apache Foundation.

Honeypotting Log4J

The group discussed ongoing efforts to use honeypots to monitor log4j exploitation. Some Log4j honeypots from Laughing Mantis saw the activity as early as November that targeted active directory environments and was capable of exploiting Log4J and subsequently escalating privileges to domain admin.

Tools

The group planned to mention some of the best log4j scanning tools, ultimately only getting to one, yahoo/check-log4j, mentioning that it checks at the disk level for log4j and finds a lot more stuff than the standard scanning services. It was mentioned that even this scanner might be blind to vulnerable IoT devices that organizations do not have control over.

IoT as the Future of Long-Term Log4J Exploitation

IoT devices (i.e Siemens), were frequently brought up as a potential attack vector where attackers might look towards for long-term exploitation of log4j vulnerabilities, especially if organizations do not implement defense-in-depth strategies.

Community Questions

Q: What strategies are being implemented from a post-exploitation perspective?

Most environments do not monitor all system commands for “random” events (i.e system commands issued, for example at the command line, that is rarely used or functions that are not typically necessary for normal business use). Some environments that do monitor for such events have been effective at stopping red teamers from exploiting log4j vulnerabilities. For example, most systems don’t typically have Java as the parent process running things like CURL, and on Windows systems, a Java parent process running command.exe or other similar commands could be an easy thing for blue teams to detect.

Q: Why is log4j a long-term issue? Is it because organizations don’t know where to look for patching or becuase patch roll out has been so inneffective?

Log4j is likely a long-term issue because organizations don’t know of all the places they should be patching. There are optional things that java projects implement where organizations don’t realize could be vulnerable to log4j. In some instances, organizations have “trusted” logging traffic and refuse to patch because of its trusted level, but failure of the imagination makes them vulnerable to potential log4j attacks. Other longer-term issues include log4j vulnerabilities in IoT devices, where attackers could leverage such devices to stick around if defense-in-depth strategies are not implemented.