Guidance for CVE-2024-3094: Finding and responding to the latest supply chain compromise with Lacework
CVE-2024-3094 is a reported
supply chain compromise of the xz libraries, with a resulting interference
with sshd authentication, potentially enabling an attacker to gain
unauthorized access to the system.
xz is used for data compression/decompression across nearly all Linux
distributions. This particular compromised version of xz is currently only
known to be present in the following OS packages:
| OS | Package name | Package version(s) | Fix package version | Reference |
|---|---|---|---|---|
| Fedora 40, Rawhide | xz | 5.6.0, 5.6.1 | Revert to 5.4.x | Details |
| Debian unstable (Sid) | xz-utils | 5.6.1 | Revert to 5.4.5 | Details |
| Alpine edge | xz | 5.6.1-r2 | Revert to 5.4.x | Details |
| Arch Linux | xz | 5.6.0-1, 5.6.1-1 | Upgrade to 5.6.1-2 | Details |
|
openSUSE Tumbleweed openSUSE MicroOS |
xz | 5.6.0 | Revert to 5.4.x | Details |
Other Linux distributions do not include the malicious version of the package: Amazon Linux, Ubuntu, RHEL, etc. The malicious version of xz is present in homebrew for Mac OSX and it has now been downgraded to a safe version.
What to do next?
If you have the packages xz, or xz-utils, version 5.6.x, it is safer to downgrade them to 5.4.x until the vendor provides a safe version, or confirms the latest versions are not affected. If possible, the hosts and containers with the potentially malicious version should be brought down and replaced in case they have been compromised.
How to look for the xz package with Lacework
Use the following Lacework API call to verify if there are containers with any 5.6 version of xz util. The filter format is different for containers and hosts. You may need to update the startTime and endTime as well as the package name to cover both xz and xz-utils.
Containers
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
/api/v2/Vulnerabilities/Containers/search
{
"timeFilter": {
"startTime": "2024-03-27T00:00:00Z",
"endTime": "2024-03-31T00:00:00Z"
},
"filters": [
{
"field": "featureKey.name",
"expression": "eq",
"value": "xz"
},
{
"field": "featureKey.version",
"expression": "ilike",
"value": "*5.6*"
}
]
}Hosts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
/api/v2/Vulnerabilities/Hosts/search
{
"timeFilter": {
"startTime": "2024-03-27T00:00:00Z",
"endTime": "2024-03-31T00:00:00Z"
},
"filters": [
{
"field": "featureKey.name",
"expression": "eq",
"value": "xz"
},
{
"field": "featureKey.version_installed",
"expression": "ilike",
"value": "*5.6*"
}
]
}Active package detection helps efficiently prioritize risks
When issues like these zero-day vulnerabilities are exposed, it’s important
to quickly and effectively determine what level of risk your organization is
facing. When you only have a list of packages and versions, it can be
difficult to determine which issues are most at risk. That’s why including
run-time active package detection is critical to understand exactly what
blast radius exists inside of your environment. This is particularly
critical for an attack such as this one. In the case that the malicious
actor is attempting to create a backdoor via sshd, you can only determine if
that’s a real, current risk by inspecting whether the package is active or
not.
Due to the nature of this attack, obvious first steps are to lock down SSH exposure (which you should already be doing) and determine package status. These combinations of factors allow organizations to quickly and effectively determine if they are actively at risk.
Quickly and accurately identify active threats
In the case of this CVE, the malicious code has existed since early February. So it’s entirely possible that the threat actor has already used or has been attempting to use this to infiltrate systems. Finding and resolving the vulnerability is one key aspect of securing our systems. The second is ensuring the attacker never got in (or that we kicked them out). Using our patented Lacework Polygraph anomaly detection and Composite Alerts, we enable customers to comprehend the state of their infrastructure and determine not only if they are vulnerable to a given risk, but more importantly if an attacker is actively inside their network. Particularly the usage of our Composite Alerts {Compromised Host} and {Compromised Credentials} are highly effective at detecting bad actors.
Ultimately, this distinct capability is at the heart of the Lacework platform – giving customers the ability to quickly and accurately identify if the threat is active and what needs to happen to resolve it. If you are not currently a Lacework customer and would like to learn more about how we can help protect your multicloud environment, please reach out to us here.
Suggested for you
