What is the OpenSSH vulnerability? #

• GCE bulletin - A vulnerability (CVE-2024-6387) has been discovered in OpenSSH. Successful exploitation of this vulnerability allows a remote, unauthenticated attacker to execute arbitrary code as root on the target machine. All GCE VMs that use a glibc-based Linux distribution and have OpenSSH exposed are vulnerable to this issue.
• GKE bulletin - A remote code execution vulnerability, CVE-2024-6387, was recently discovered in OpenSSH. The vulnerability exploits a race condition that could be used to obtain access to a remote shell, enabling attackers to gain root access to GKE nodes. At the time of publication, exploitation is believed to be difficult and take several hours per machine being attacked. We are not aware of any exploitation attempts. All supported versions of Container Optimized OS and Ubuntu images on GKE run versions of OpenSSH that are vulnerable to this issue. GKE clusters with public node IP addresses and SSH exposed to the Internet should be treated with the highest priority for mitigation. The GKE control plane is not vulnerable to this issue.

How to identify GCP Assets potentially vulnerable to the OpenSSH Vulnerability? #

select
 id as gcp_resource_id,
 project_id as gcp_project_id,
 name,
 description,
 kind,
 network,
 disabled
from gcp_compute_firewalls
where name = 'default-allow-ssh'
and disabled is false;

with allowed_ports_flattened as (
select
 _cq_id,
 JSONB_ARRAY_ELEMENTS(allowed) as allowed
from gcp_prod.gcp_compute_firewalls
), --get all allowed ports and protocols from jsonb array in allowed field
ports_protocols_separated as (
select
 _cq_id,
 JSONB_ARRAY_ELEMENTS_TEXT(allowed -> 'ports') as ports,
 allowed ->> 'I_p_protocol' as protocol
from allowed_ports_flattened
), --get all allowed ports as text and separate out protocol
port_ranges as (
select
_cq_id,
protocol,
nullif(split_part(ports, '-', 1), '')::integer AS range_start,
nullif(split_part(ports, '-', 2), '')::integer AS range_end
from ports_protocols_separated
) --calculate ip range start and end if a range exists
 id as gcp_resource_id,
 project_id as gcp_project_id,
 name,
 description,
 kind,
 network,
 protocol,
 allowed as ports_allowed,
 range_start as allowed_ports_range_start,
 range_end as allowed_ports_range_end,
 disabled
from gcp_compute_firewalls gcp_cf
join port_ranges pr on gcp_cf._cq_id = pr._cq_id
where
--check if port 22 is in the allowed port range or is the single port
((22 between range_start and range_end) or range_start = 22)
and protocol = 'tcp' --the vuln only relates to TCP traffic
and disabled is false; --select for only active firewalls

1. The allowed_ports_flattened CTE takes the allowed JSONB field and flattens out all the elements of the array of ports and protocols using the JSONB_ARRAY_ELEMENTS this allows you to separate and transform these values for calculation. We also include the _cq_id field as a unique identifier that we will use to join back to your base gcp_compute_firewalls table
2. Next, the ports_protocols_separated CTE takes your results from allowed_ports_flattened and separates the I_p_protocol and ports fields in the JSONB into their own columns.
3. The final port_ranges CTE is where the now-separated ports field can be further split into a start and end range and converted back to integers. The left side of the range is split out as the start of your allowed port range and the right side is the end of your allowed port range. If only a single port exists then it will appear in the range start field and the range end field will be null.

select
 id as gcp_resource_id,
 project_id as gcp_project_id,
 name,
 description,
 network,
 status,
 private_cluster_config
from gcp_container_clusters
where
private_cluster_config ->> 'enable_private_nodes' = 'false'

Summary #