Cloudanix VulnDB

CVE-2022-4967

High · 7.7

CVSS

7.7

EPSS

0.5%

Published

May 14, 2024

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the VPN software let someone with a valid certificate log in while pretending to be a different user, which could give them access they were not supposed to have.

Exploitation
Remote Authenticated
Attacker needs
Low Privilege
Complexity
Low
Impact
Data Exposure
Component
Application
Class
Authorization Bypass
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

In strongSwan 5.9.2-5.9.5, TLS-based EAP methods using certificates do not enforce that the supplied IKE/EAP identity appears in the client certificate, allowing any trusted certificate to authenticate under an arbitrary identity used for policy decisions.

Why it matters to the business

Attackers may obtain unauthorized VPN or network access by impersonating other users, risking data exposure or policy bypass; the issue affects an older release line with low exploit probability and no active campaigns observed.

How an attack unfolds

An attacker obtains any trusted certificate, initiates a TLS-based EAP connection to strongSwan, presents the certificate while supplying an IKE or EAP identity absent from that certificate, and thereby satisfies authentication while evading identity-based authorization controls.

How to fix it

Upgrade strongSwan to version 5.9.6 or later (commit e4b4aabc4996fc61c37deab7858d07bc4d220136) and ensure certificate identity enforcement is active for all TLS EAP methods.

How to confirm the fix worked

Confirm installed strongSwan version is 5.9.6 or newer; test EAP-TLS authentication attempts that supply an identity absent from the presented certificate and verify they are rejected.

Typical attack path

  1. Acquire a certificate trusted by the strongSwan CA
  2. Connect to the VPN endpoint using a TLS EAP method
  3. Present the certificate and claim an arbitrary IKE/EAP identity
  4. Trigger policy evaluation based on the claimed identity
  5. Obtain access granted to the impersonated identity

How to detect it

Examine strongSwan authentication and EAP logs for sessions where the certificate subject does not contain the claimed IKE or EAP identity; correlate with authorization decisions based on that identity.

What your security team should do

  • Upgrade all strongSwan installations to 5.9.6 or later without delay
  • Audit VPN policies that rely on IKE/EAP identities for authorization
  • Enable certificate subjectAltName or DN matching where supported
  • Review authentication logs for historical identity-certificate mismatches

The record

strongSwan versions 5.9.2 through 5.9.5 are affected by authorization bypass through improper validation of certificate with host mismatch (CWE-297). When certificates are used to authenticate clients in TLS-based EAP methods, the IKE or EAP identity supplied by a client is not enforced to be contained in the client's certificate. So clients can authenticate with any trusted certificate and claim an arbitrary IKE/EAP identity as their own. This is problematic if the identity is used to make policy decisions. A fix was released in strongSwan version 5.9.6 in August 2022 (e4b4aabc4996fc61c37deab7858d07bc4d220136).

Affected packages

Ecosystem Package Introduced Fixed
Debian:12 strongswan 0 5.9.6-1
Debian:13 strongswan 0 5.9.6-1
Debian:14 strongswan 0 5.9.6-1
Ubuntu:22.04:LTS strongswan 0 5.9.5-2ubuntu2.3

Related vulnerabilities