CVE-2014-7144

What it actually does

The vulnerability causes certificate verification to be disabled whenever the 'insecure' option appears in the paste.ini configuration, irrespective of its assigned value, enabling interception of TLS connections to Keystone.

Why it matters to the business

Attackers can perform man-in-the-middle attacks on authentication traffic, potentially compromising OpenStack identity services and allowing unauthorized access to cloud resources across affected deployments.

How an attack unfolds

An attacker positions themselves on the network path between an OpenStack client and the Keystone service, presents a crafted certificate, and because verification is unconditionally disabled due to the misparsed 'insecure' setting, the client accepts the invalid certificate and proceeds with the connection, exposing tokens and session data.

How to fix it

Upgrade openstack keystonemiddleware to version 0.11.0 or later and python-keystoneclient to version 1.2.0 or later. Audit all paste.ini files to remove or correctly handle the 'insecure' option and enforce proper certificate validation.

How to confirm the fix worked

Verify installed package versions meet or exceed the fixed releases. Inspect paste.ini configurations for presence of the 'insecure' key and test connections using invalid certificates to confirm verification is enforced.

Typical attack path

1. Identify OpenStack deployments using vulnerable keystonemiddleware or python-keystoneclient versions
2. Position on the network to intercept TLS traffic to Keystone endpoints
3. Serve a crafted certificate mimicking the legitimate service
4. Trigger client connection which skips verification due to the configuration parsing flaw
5. Capture authentication tokens or inject modified responses

How to detect it

Review application and Keystone logs for unexpected certificate handling or connections that bypass validation. Examine historical network captures for anomalous TLS handshakes involving self-signed or mismatched certificates. Check configuration management history for past presence of the 'insecure' option.

What your security team should do

• Prioritize upgrade of all affected OpenStack components to the fixed versions given the long exposure window since 2014
• Review and harden paste.ini configurations across environments to eliminate insecure TLS settings
• Implement network segmentation and certificate pinning where feasible to reduce MITM exposure
• Monitor EPSS and threat intelligence feeds for any late-stage exploitation despite low current scores