Reach

This vulnerability is exploitable from a linux shell session on a Kubernetes container. It is not a first step in an exploit chain, but it makes privilege escalation to having all kernel capabilities trivial, which means it can bring a higher risk in systems exposed to the internet with vulnerable software (like a popular CMS or CRM) by enabling a longer, more dangerous exploit chain. all kernel versions since 5.1-rc1 are affected through the latest patches (5.4.173, 5.10.93, 5.15.1), however major distributions are already distributing patches on their kernels.

Indicators of Compromise

No clear indicators of compromise are known as of yet, but a possible check is to look for what kernel capabilities processes have, and see if any unusual process has an unusual amount of kernel capabilities.

Patches and mitigations

Kernel patches are being released by major linux distributions to mitigate this issue and should be applied as soon as possible. If a debian-based distribution does not have an available patch yet, this vulnerability can be mitigated by disabling unprivileged kernel namespaces:

sysctl -w kernel.unprivileged_userns_clone=0

This way only privileged pods and containers will be able to escalate their kernel capabilities (Which is as per design for the privilege level specified).

Sources

https://www.bleepingcomputer.com/news/security/linux-kernel-bug-can-let-hackers-escape-kubernetes-containers/

https://sysdig.com/blog/cve-2022-0185-container-escape/

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0185

Geko Cloud

Geko Cloud Consulting we are up to date with any incident or vulnerability. If you want to have your data safe, you need us!

La entrada Security incident with a kubernetes container escape kernel bug se publicó primero en Geko Cloud.

Reach

This vulnerability is exploitable from any Linux user terminal session. It is not a first step in an exploit chain, but it makes privilege escalation from an unprivileged shell trivial, which means it can bring a higher risk in systems exposed to the internet with vulnerable software (like a popular CMS or CRM) by enabling a longer, more dangerous exploit chain. All versions of the pkexec utility since it launched in 2009 are vulnerable, however major distributions are already distributing patches on their repositories.

Indicators of Compromise

A possible indicator of compromise for this vulnerability is a log entry that contains the string “The value for the SHELL variable was not found the /etc/shells file”. Searching for this text on the system logs can be an indicator that the vulnerability was exploited on that local system where the logs are being analyzed.

Patches and mitigations

All versions of the pkexec utility since it launched in 2009 are vulnerable, however major distributions are already distributing patches on their repositories. You can update pkexec from the system’s package manager to patch this vulnerability. If no patch is available for your distribution yet, the binary’s privilege escalation can be disabled by removing the SUID bit from the binary file: chmod 0755 pkexec 

Sources

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-4034

https://www.qualys.com/2022/01/25/cve-2021-4034/pwnkit.txt

https://isc.sans.edu/diary/rss/28272

La entrada Security incident with the pkexec linux privilege escalation binary se publicó primero en Geko Cloud.

There is the possibility to disable the function that allows this vulnerability to be exploted (JNDI) with environment variables in some versions of the library, but the long-term solution is to patch the log4j library to version 2.17.0.

Reach

This vulnerability has a very wide reach into several applications widely used in the technology stack of modern companies. A complete list of currently known affected software can be seen on  CISA‘s github repository about the issue. This list will be updated as new software is discovered to be vulnerable.

Threat hunting and mitigation

It is possible to mitigate this vulnerability by disabling the JNDI lookup library that makes this attack possible with environrment variables, or deleting the java library entirely from the included functions inside the jar file which will make this impossible to exploit. These, however, are temporary patches, and the definitive solution to include on your roadmap is to update to log4j 2.17.0 as soon as possible.

You can investigate common post-exploitation trails and vulnerable log4j library entries with our in-house scanning tool script that has been developed to log detections of common post-exploitation trails in your scanned system, and to scan for any log4j libraries that exist on your filesystem and are vulnerable to this CVE’s.

Update 1: 2021-12-14

It has been discovered that Apache’s fix for this CVE in log4j 2.16.0 was incomplete in some non-default configurations and it still allowed to remotely execute code in some configurations. It is recommended to upgrade to log4j 2.17.0 as soon as possible to avoid being affected by this vulnerability.

La entrada Security incident in the log4j Java logging library se publicó primero en Geko Cloud.

This issue consists on that clients will wrongly identify correct, valid certificates as invalid, because the CA they are based on is now invalid and the client software was not updated to trust the new CA, so it is now giving these authentication problems. We have identified that this is a problem with older software clients like curl, or older versions of programming languages like php that do not have this CA installed in them and thus fail to access clients with letsencrypt certificates. 

Scope

Affected software versions

– OpenSSL <= 1.0.2

– Windows < XP SP3

– macOS < 10.12.1

– iOS < 10 (iPhone 5 is the lowest model that can get to iOS 10)

– Android < 7.1.1 (but >= 2.3.6 will work if served ISRG Root X1 cross-sign)

– Mozilla Firefox < 50

– Ubuntu < 16.04

– Debian < 8

– Java 8 < 8u141

– Java 7 < 7u151

– NSS < 3.26
-CDN like Cloudflare

– Amazon FireOS (Silk Browser)

This is an effect that can not only be felt by users or client applications, but by the application itself. For example, if your application is running on a system using a version lower than the detailed above, like a webserver with openssl 1.0.1, requests to any letsencrypt-backed service will fail. 

Remediation

Solution to this problem is to upgrade the client version of the software stack so it trusts the new root CA as a full solution. You can also patch the issue by modifying your software so it doesn’t check the validity of the CA, although keep in mind that this should be a temporary solution as it is an insecure software practice and should not be left applied in a production environment more time than necessary.

Here’s more technical information about this issue:

https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/

La entrada SSL Root Certificates Let’s encrypt Issue se publicó primero en Geko Cloud.