Shodan is a search engine for everything on the internet — web cams, water treatment facilities, yachts, medical devices, traffic lights, wind turbines, license plate readers, smart TVs, refrigerators, anything and everything you could possibly imagine that’s plugged into the internet (and often shouldn’t be). Google and other search engines, by comparison, index only the web.

The best way to understand what Shodan does is to read founder John Matherly’s book on the subject. The basic algorithm is short and sweet:

1. Generate a random IPv4 address
2. Generate a random port to test from the list of ports that Shodan understands
3. Check the random IPv4 address on the random port and grab a banner
4. Goto 1

To read this article in full, please click here

Read More

CrowdStrike discloses container escape vulnerability affecting CRI-O for Kubernetes. Here’s how Tenable.cs can help you detect vulnerable pods.

Background

On March 15, CrowdStrike published technical details and a proof-of-concept for CVE-2022-0811, a vulnerability they have named cr8escape, in the CRI-O Container Engine for Kubernetes. CRI-O is an open source container runtime engine that is used to share kernel resources among applications running on a container node. There have not been any reported exploitations in the wild of this vulnerability at the time of publication.

CrowdStrike identified Red Hat’s OpenShift 4+ and Oracle Container Engine for Kubernetes as two products that integrate CRI-O and warns that other software and platforms may deploy the engine by default.

Analysis

CVE-2022-0811 is a container escape vulnerability in CRI-O that can lead to elevation of privileges. According to CrowdStrike, this vulnerability was introduced in CRI-O version 1.19 and allows an attacker to bypass the standard security controls that typically prevent one pod from changing the kernel parameters of others, allowing them to set arbitrary kernel parameters to the host.

An attacker with “rights to deploy a pod on Kubernetes cluster that uses the CRI-O runtime” could elevate their privileges and potentially execute code on other nodes in the cluster with root permissions. This could further allow the attacker to spread malware or exfiltrate sensitive data, making it a useful flaw for ransomware groups in particular.

Proof of concept

As part of their technical write up, CrowdStrike walked through a proof of concept that exploits CVE-2022-0811 to execute malware.

Solution

The vulnerability was introduced in CRI-O version 1.19 in September 2020 and impacts all versions since. On March 15, version 1.22.3 was released to address CVE-2022-0811. Both Oracle and Red Hat have deployed the fixed version as part of updates to Oracle Linux and OpenShift.

How Tenable.cs can help

To exploit this vulnerability on clusters running vulnerable versions of CRI-O, an attacker has to create a pod with a ‘sysctl’ containing “+” or “=” in the value.

Tenable.cs can help you detect such misconfigurations in your Kubernetes clusters by scanning your infrastructure as code (manifests, helm, or kustomize), as well as your runtime cluster.

Tenable.cs uses policy as code (open policy agent Rego) to find the misconfigurations in all your cluster workloads. Let’s take a look at the code that helps detect this misconfiguration.

Before CVE-2022-0811 was reported, Tenable.cs was already scanning your workloads against kernel level syscalls. The policy to check for these misconfigurations looks like this:

kernelLevelSysCalls[pod.id] {

pod := input.kubernetes_pod[_]

forbiddenSysctls = [“kernel.*”]

sysctl := pod.config.spec.securityContext.sysctls[_].name

forbidden_sysctl(sysctl, forbiddenSysctls)

}

forbidden_sysctl(sysctl, arg) {

arg[_] == sysctl

}

forbidden_sysctl(sysctl, arg) {

startswith(sysctl, trim(arg[_], “*”))

}

In the above policy, we are checking for the name of sysctl if it includes “kernel.” However, to detect CVE-2022-0811, we have added another policy which will first verify for kernel level calls through name as in the above policy, then it will check for the value in the sysctl and alert you if it contains [“=”, “+”].

{{.prefix}}{{.name}}{{.suffix}}[pod.id] {

pod := input.kubernetes_pod[_]

forbiddenSysctls = [“kernel.*”]

sysctl := pod.config.spec.securityContext.sysctls[_].name

forbidden_sysctl(sysctl, forbiddenSysctls)

disAllowedValues := [“=”, “+”]

sysctlValue := pod.config.spec.securityContext.sysctls[_].value

contains(sysctlValue, disAllowedValues[_])

}

Note: The above policies are an example used just for kubernetes pods, Tenable.cs can scan the same for all different kinds of workloads, such as, Deployment/ReplicaSet/DaemonSet etc.

Now, let’s look at the Tenable.cs results for the scan of the pod used by CrowdStrike in its proof of concept.

Tenable.cs provides an issues tab with all the violations specific to the infrastructure one has scanned. The screenshot above shows the results of a failed CVE-2022-0811 policy check in Tenable.cs. For every violation, Tenable.cs provides technical details and remediation advice.

Identifying affected systems

A list of Tenable plugins to identify this vulnerability can be found here.

Get more information

CrowdStrike’s Blog Post on CVE-2022-0811
CRI-O GitHub

Join Tenable’s Security Response Team on the Tenable Community.

Learn more about Tenable, the first Cyber Exposure platform for holistic management of your modern attack surface.

Get a free 30-day trial of Tenable.io Vulnerability Management.

Read More

Ukrainian Directorate of Intelligence shares personal data of Russian agents

Read More

Researcher claims Russian tech company is sending data harvested from iOS app users to Russia

Read More

The researchers also found the public sector takes twice as long to fix flaws once detected compared to other industries

Read More

OCR fines dental practice $50K for disclosing PHI of patient who posted a negative review online

Read More

If you don’t currently have your own security operations center (SOC), you have two ways to get one: Build your own or use some managed collection of services. In past years the two paths were distinct, and it was relatively easy to make the call based on staffing costs and skills.

Now, the SOC-as-a-service (SOCaaS) industry has matured to the point now where the term is falling into disfavor as managed services vendors have become more integral to the practice. As cloud-based security tools have gotten better, data centers and applications have migrated there as well. Some of the services discussed here call themselves SOCaaS, while others use other managed services designations.

To read this article in full, please click here

Read More