openapi-python-client up to 0.5.2 OpenAPI Document code injection

CVSS Meta Temp Score
CVSS is a standardized scoring system to determine possibilities of attacks. The Temp Score considers temporal factors like disclosure, exploit and countermeasures. The unique Meta Score calculates the average score of different sources to provide a normalized scoring system.
Current Exploit Price (≈)
Our analysts are monitoring exploit markets and are in contact with vulnerability brokers. The range indicates the observed or calculated exploit price to be seen on exploit markets. A good indicator to understand the monetary effort required for and the popularity of an attack.
CTI Interest Score
Our Cyber Threat Intelligence team is monitoring different web sites, mailing lists, exploit markets and social media networks. The CTI Interest Score identifies the interest of attackers and the security community for this specific vulnerability in real-time. A high score indicates an elevated risk to be targeted for this vulnerability.
5.9$0-$5k0.00

Summaryinfo

A vulnerability identified as critical has been detected in openapi-python-client up to 0.5.2. This affects an unknown part of the component OpenAPI Document Handler. This manipulation causes code injection. This vulnerability is handled as CVE-2020-15142. The attack can be initiated remotely. There is not any exploit available. You should upgrade the affected component.

Detailsinfo

A vulnerability classified as critical was found in openapi-python-client up to 0.5.2 (Programming Language Software). Affected by this vulnerability is some unknown functionality of the component OpenAPI Document Handler. The manipulation with an unknown input leads to a code injection vulnerability. The CWE definition for the vulnerability is CWE-94. The product constructs all or part of a code segment using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the syntax or behavior of the intended code segment. As an impact it is known to affect confidentiality, integrity, and availability. The summary by CVE is:

In openapi-python-client before version 0.5.3, clients generated with a maliciously crafted OpenAPI Document can generate arbitrary Python code. Subsequent execution of this malicious client is arbitrary code execution.

The weakness was released 08/14/2020 (GitHub Repository). It is possible to read the advisory at github.com. This vulnerability is known as CVE-2020-15142 since 06/25/2020. The exploitation appears to be difficult. The attack can be launched remotely. A single authentication is required for exploitation. It demands that the victim is doing some kind of user interaction. The technical details are unknown and an exploit is not publicly available. The attack technique deployed by this issue is T1059 according to MITRE ATT&CK.

Upgrading to version 0.5.3 eliminates this vulnerability.

Entry connected to this vulnerability is available at VDB-159930. Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Productinfo

Type

Name

Version

CPE 2.3info

CPE 2.2info

CVSSv4info

VulDB Vector: 🔍
VulDB Reliability: 🔍

CVSSv3info

VulDB Meta Base Score: 6.7
VulDB Meta Temp Score: 6.4

VulDB Base Score: 5.5
VulDB Temp Score: 4.9
VulDB Vector: 🔍
VulDB Reliability: 🔍

NVD Base Score: 8.0
NVD Vector: 🔍

CVSSv2info

AVACAuCIA
💳💳💳💳💳💳
💳💳💳💳💳💳
💳💳💳💳💳💳
VectorComplexityAuthenticationConfidentialityIntegrityAvailability
UnlockUnlockUnlockUnlockUnlockUnlock
UnlockUnlockUnlockUnlockUnlockUnlock
UnlockUnlockUnlockUnlockUnlockUnlock

VulDB Base Score: 🔍
VulDB Temp Score: 🔍
VulDB Reliability: 🔍

Exploitinginfo

Class: Code injection
CWE: CWE-94 / CWE-74 / CWE-707
CAPEC: 🔍
ATT&CK: 🔍

Physical: No
Local: No
Remote: Yes

Availability: 🔍
Status: Not defined

EPSS Score: 🔍
EPSS Percentile: 🔍

Price Prediction: 🔍
Current Price Estimation: 🔍

0-DayUnlockUnlockUnlockUnlock
TodayUnlockUnlockUnlockUnlock

Threat Intelligenceinfo

Interest: 🔍
Active Actors: 🔍
Active APT Groups: 🔍

Countermeasuresinfo

Recommended: Upgrade
Status: 🔍

0-Day Time: 🔍

Upgrade: openapi-python-client 0.5.3

Timelineinfo

06/25/2020 🔍
08/14/2020 +50 days 🔍
08/14/2020 +0 days 🔍
11/10/2020 +87 days 🔍

Sourcesinfo

Advisory: github.com
Status: Not defined
Confirmation: 🔍

CVE: CVE-2020-15142 (🔍)
GCVE (CVE): GCVE-0-2020-15142
GCVE (VulDB): GCVE-100-159931
See also: 🔍

Entryinfo

Created: 08/14/2020 21:43
Updated: 11/10/2020 00:48
Changes: 08/14/2020 21:43 (39), 08/14/2020 21:48 (12), 11/10/2020 00:40 (1), 11/10/2020 00:48 (1)
Complete: 🔍
Cache ID: 216::103

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Discussion

 orubel
(+1)
6 years ago
So this is something that I have talked about for years. This stems around the fact that most API's use the 1970's api pattern wherein the communication logic/data are BOPUND to the business logic (controllers) through annotations and such. As a result, you cannot abstract the data away in things like RAML, API BLueprint or OpenApi without reloading you Application everytime you want to change the data. This also means it will NEVER be 100% in sync.

For that, you have to follow the NEW API Pattern and abstract the communication logic to something akin to a handlerInterceptorAdapter so it can intercept the request/response and do a handoff to itself internally (ie request.forward or 'internal redirect').

This would allow for sync to be done at the central version of truth and to 'push' to all subscribing services (ie webhook) thus keeping all services in sync 24-7 with zero downtime.

See this article for more https://www.linkedin.com/pulse/openapi-security-exploit-owen-rubel/?trackingId=xNyj0R5mSQ%2BwqVO0MysfGg%3D%3D
 orubel
(+0)
6 years ago
one way to demonstrate an example of this exploit is to use a 'forward' in the api application. This bypasses the gateway/proxy where the OpenApi doc resides. You can security rules in OpenApi but the application wont be using them by simply forwarding the request.

It's very basic.
 orubel
(+0)
6 years ago
Another way to demonstrate the issue is that the central version of truth (the annotations in the api application) define the state and OpenApi is a duplication of that state. When the application changes that data, there is a delay between synchronization and generation of the new document.

This relies 100% on ZERO HUMAN ERROR unless you have this ALL AUTOMATED through perfect devops where reload of server redeploys with new version of application which causes regenration of OpenApi with new version so it can detect new version and regenerate doc.

This is VERY HARD to do through devops however as that requires detection at the controllers/business logic. :)

So this ALL relys on ZERO HUMAN ERROR and version detection and humans updating version with every change.

All it takes is one miss, one time and privileges are elevated.

Do you want to use VulDB in your project?

Use the official API to access entries easily!