Note: This article was originally posted on 15 Dec 2021 and last updated on 20 Dec 2021.
1. What's New?
Well, it's been a while since our last Orbital Query Corner update, and we've been eager to talk about several new things related to Orbital, but as happens from time to time in this business, news events can sometimes push certain things to the top of the priority queue in a hurry. Specifically, now that Orbital support has been extended to both macOS and Linux connectors, we had intended to find a couple of good illustrations of how to start taking advantage of the new multi-OS Orbital capabilities.
Well, the good news and the bad news is that we now have a great use case for Linux Orbital queries, straight out of this week's headlines, namely the log4j vulnerability (CVE-44228). [1] For details, we highly recommend our Talos threat intelligence team's blog post [2] as well as the Cisco Event Response page [3] on the subject.
2. Using Orbital to Monitor for the Vulnerability
Okay, but what about Orbital, and specifically the shiny new Linux support there? Well, as of yesterday, the catalog of Orbital Linux queries has a new entry:
If we check the details, we find this:
Turns out that this is more than just a single simple check. The Orbital engineering team has provided a fairly comprehensive set of checks, including several ways of checking to see if the vulnerability is present, and also a scan of log events for indications of exploitation.
So what might we do with this new query? Why, run it, of course. It's all set up and ready to go. All we need to do is click the Add to New Query button in the catalog page.
Then, select the targets. For an initial check across all Orbital-enabled Linux systems, the simplest approach would be just to select the target by operating system.
And finally, decide when we want to run this. To run it immediately, use the Live Query button. To schedule it for either a one-time run (maybe during off-peak hours) or repeatedly, use the Schedule button.
And that's it! Well, actually one more thing: After the initial scan for vulnerabilities, we might want to schedule followup scans for only those systems that were initially found to be vulnerable. That actually leads naturally to another of those new features that we've been intending to get written up, namely linked queries.
But that's a topic for another Query Corner. Watch this space!
2.1 Addendum: Usage Note
By the way, in case you haven't interacted with catalog entries that use more than one SELECT statement before, there's something we'd like to point out about the results. Notice that you get multiple tabs in the job output. Here's a sample query on two systems, one of which has log4j installed and the other of which does not:
Under "DEB Packages", we see the results of the first SELECT statement (including the all-important version information). Selecting other tabs in the output also helpfully highlights which SELECT in the query provided the output we're looking at.
2.2 Second Update: Windows
As a quick addition to the above, please note that there is now also a Windows OS version of the log4j monitoring query:
Links and References
[1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228
[2] https://blog.talosintelligence.com/2021/12/apache-log4j-rce-vulnerability.html
[3] https://tools.cisco.com/security/center/resources/prod_svc_info_log4j.html
