Using Configuration Management to Detect Unwanted Software

The Log4j vulnerability is the latest cyber exploit, bringing a CVSS critical score of 10. It allows attackers to execute arbitrary Java code on remote computers, including accessing sensitive information.

Only a year since the world addressed the SolarWinds supply chain attack, it’s another  confirmation that network professionals must adopt long-term risk-management strategies.

Are Opmantek products affected? Opmantek does not release software written in Java or Log4J, nor do the projects we depend on directly utilize Java or Log4J. 

Leverage Configuration Data to Identify Risk

It can be difficult to identify if Log4j is being used, as it’s often bundled with other software. A configuration management system provides means to audit a resource configuration and inventory elements against a defined security policy.

Detecting Log4j on a Server with opConfig

Like any organization, our internal teams use a variety of third party software. In the case of the Log4J vulnerability, we needed to confirm if the library was installed on our servers, patch it, and ensure it wouldn’t then be installed in future.

Between our product, development and test servers we had about 50 Linux servers to check, so we needed to find a quick, automated solution.

Detection

Unfortunately, the software does not use a Linux package manager, so we can not use RPM and APT commands.  There is a simple way to verify if the software was installed, look in / (root directory and all child directories) to see if there were any files containing the name log4j.

The Linux command we needed was:

• sudo find / -name “*log4j*”

We wanted to run this command quickly and easily on 50 Linux servers.  A new command set was needed which we called “Linux_Log4j”. We created a new command set file for this and similar things called “Linux_Software_Installed.nmis”.

Linux_Software_Installed Command Set

Command sets in opConfig are stored in /usr/local/omk/conf/command_sets.d by default.  We copied an existing one and edited it to make it reflect what we needed. ​​This change could also be made in the GUI, editing an existing command set and adding a new command collection.  Most importantly, this needed to have os_info matching Linux only and we needed to change the two commands. In the most recent version of opConfig for NMIS9 these files are JSON.

To understand the contents it is quite straightforward, os_info means only run these commands when these os_info conditions are met.  Each of the command sections are simple and the tagging system is powerful:

• privileged: means does this require elevated privileges to run, e.g. sudo access
• command: the command you want to run, which is also how the data is saved into the system
• exec: optional if you want to save the command as some other name, use the exec as the command which is actually executed and the command item will be the name of the command to run.
• tags: HOURLY means this will automatically run every hour, Linux and operations are handy for finding the command, detect-change and report-change means that opConfig will monitor this command output for change and if a change is found raise an event.

Linux_Software_Installed.json

The final command set looks like this:

{

“Linux_Log4j” : {

“commands” : [

{

“privileged” : “true”,

“command” : “Log4jSearch”,

“exec” : “sudo find / -name \”*log4j*\””,

“tags” : [

“HOURLY”,

“Linux”,

“operations”,

“detect-change”,

“report-change”

]

}

],

“scheduling_info” : {

“run_commands_on_separate_connection” : “false”

},

“os_info” : {

“os” : “/(Linux|CentOS|Ubuntu)/”

}

}

}

Running the Command Set

Because it is tagged with “HOURLY” the command set will run automatically every hour.  If you want to run it manually for testing, you run the following command:

sudo /usr/local/omk/bin/opconfig-cli.pl quiet=1 nodes=NODE-TO-TEST-WITH act=run_command_sets tags=HOURLY debug=true

Check for any errors, if all good, run manually for all nodes or wait an hour or so.

You may need to increase the timeout if you see the console lines as below.

[2021-12-22 03:58:48.21513] [23682] [warn] failed to make session privileged: read timed-out

[2021-12-22 03:58:48.21573] [23682] [warn] Failed to run command Log4jSearch: Could not make session privileged: read timed-out

[2021-12-22 03:58:48.21587] [23682] [warn] Command timed out – partial response was: “”

The /usr/local/omk/conf/opCommon.json file can be edited and the value for opconfig_command_timeout increased to a suitable number of seconds.

Running as Non-Privileged

You may not have (or want to use) the privileged user (using sudo). In this case, a more suitable exec string is below (and remember to set “privileged”: “false”).

“exec” : “find / -name \”*log4j*\” 2>/dev/null”,

Diagnose

Now we can go to the opConfig GUI and find the matching nodes.

Access the Commands Overview

From the opConfig menu, select “Views → Recent Commands” and you should see a screen which looks like below.

First we can see how many instances of “Log4jSearch” we have collected.In the box enter “Log4jSearch” change the select to “Command” and click “Go”. You will have a list of nodes and the command name.

Next, click on the “Advanced” button on the right.

Click on the Node Name to see the command output.

Here we can see this node has some possible files of concern.

Remediation

In this case remediation requires one of the operations team to install updated versions of Log4j or the packages from vendors using it. The Opmantek development team use Vagrant to automate this kind of activity and the issue was quickly resolved.

Conclusion

Using the Operational Process Automation methodology of detect, diagnose and act, Opmantek was able to identify which of our servers required change within 15 minutes.

Ready to see what opConfig can do for your organization?

Get in touch to speak with a network engineer. We’re a technically led team, so prepare for a conversation about solutions, not sales.

Or, get started straight away with a time-unlimited 20 node license.