cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6214
Views
20
Helpful
0
Comments
brmcmaho
Cisco Employee
Cisco Employee

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.

orbital-os.png 

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:

catalog.png

If we check the details, we find this:

details.png

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.

add-query.png 

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.

query2.png

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.

schedule.png

 

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:

results1.png

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.

results2.png

 

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:

windows.png

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

 

 

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Recognize Your Peers