Osquery Quick Reference Guide for Tables & Actions: Log4J Remediation

The Security Field’s Hidden Superpower: Community

The single word that encompasses why we believe in the strength of the security field and specifically our project here at Uptycs. The open-source osquery agent has a diverse, brilliant group of contributors that have contributed to its dramatic rise as a go-to unified agent for security teams. 

Over the past week, the security community was put to the test and brilliantly rose to the challenge yet again as teams rallied to uncover and remediate Log4Shell/LogJam vulnerability. CVE-2021-44228 targets a vulnerability in Apache Log4j versions <=2.14.1, a Java logging library. When successful, unauthenticated attackers are able to remotely execute code using the exploit.

In a field that feels like the lurking adversary has unlimited resources at hand, we trust our tools and the people who built them, we find comfort in the underlying camaraderie that stretches from individuals in security teams around the world.

Our team at Uptycs has worked around the clock to support customers with tailored fixes to their environments. In doing so, we analyzed optimal ways to leverage the extensive data from the osquery agent into your remediation efforts.

For the osquery community, Uptycs has compiled the following list of tables and actions to help speed up your investigation and remediation cycle for combating the Log4j vulnerability.

Reference Tables 

• Processes:
• * Get Java processes using name column
• * Use cmdline to check if JVM property "-Dlog4j2.formatMsgNoLookups=true" is set
• * Also use cmdline to check for log4j  jars in -classpath
• process_envs: 
• For Java processes (joined via process id), see if environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS is set to true
• process_memory_map: 
• Get the list of Java processes memory mapped files. Specifically log4j jars.
• process_open_files: 
• Get current files opened by Java processes. Narrow down to log4j jars. 
• Can also point you to the Java application log files location. Not all Java applications log to /var/log
• socket_events: 
• Not all Java processes make egress calls to the Internet. Check socket activity. Narrow down to Java process that are not expected to reach IP addresses on the Internet
• process_file_events: 
• If FIM (file integrity monitoring) is configured and monitoring paths, look for activity performed by Java processes.
• yara/yara_events: 
• To scan the logs for $ {jndi:...} patterns. See: https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b
• deb_packages/rpm_packages: 
• To potentially identify the JDK/JRE version(s) installed

Uptycs Enhancements

Additionally, enterprises working with Uptycs have access to a number of enhancements that help with Log4j remediation and mitigation, including additional telemetry, an eventing framework for real-time detection, and a Flight Recorder that enables historical queries even for systems that are no longer online. 

These extensions to osquery enable faster response times to emerging vulnerabilities like Log4j. For one example, we used our java_packages table to scan inside uber and shaded jars so that Security teams can inventory the vulnerable Log4j library in containerized environments.

If you have any additional tables and actions that you have found particularly useful, please reach out to jcolvin@uptycs.com and we will incorporate them ASAP into this article for the broader community to reference.

Uptycs also helps with Log4j remediation efforts, helping you quickly inventory vulnerable systems and prioritize patch efforts.

To see how Uptycs helps with Log4J remediation, check out our interactive tour.