Skip to content

Controlled and full-read SSRF through URL parameter when testing a request, webhooks and proxy mode in WireMock Studio

High
oleg-nenashev published GHSA-676j-xrv3-73vc Sep 6, 2023

Package

maven wiremock-studio (Maven)

Affected versions

2.32.0-17 and before

Patched versions

N/A
docker wiremock-studio (Docker)
2.32.0-17 and before
N/A

Description

Summary

When certain request URLs like “@127.0.0.1:1234" are used in WireMock Studio configuration fields, the request might be forwarded to an arbitrary service reachable from WireMock’s instance. There are 3 identified potential attack vectors: via “TestRequester” functionality, webhooks and the proxy mode. As we can control HTTP Method, HTTP Headers, HTTP Data, it allows sending requests with the default level of credentials for the WireMock instance.

For example, If someone is running the WireMock Studio Docker container inside an AWS EC2 cluster, they can perform internal request to the metadata server (169.254.169.254) and recover AWS Secret Keys, even if the protection by the token is activated, because an attacker can make POST requests with a token discovered in another way. They may also get full access to unrestricted internal APIs.

“Test Requester” functionality. WireMock itself does not include such functionality, and hence not affected. In WireMock Studio and other similar UI implementations, this vulnerability allows a user to perform any internal request he wants through the "Test Requester" menu in WireMock Studio with default settings. As the result is sent back to the user, this is a full read and controlled SSRF.

Proxy Mode. By default, the proxy mode is affected by a similar vulnerability if a user has access to the administrative API or can configure proxying from WebUI like in WireMock Studio. As we can control HTTP Method, HTTP Headers, HTTP Data, and that the result is sent back to the user, this is a full read and controlled SSRF.

Webhooks. For the webhooks, the vulnerability is similar to the one above, but there is no response being returned to the end user. Nevertheless, webhooks allow sending arbitrary POST requests to privileged addresses that are routable from the host WireMock is running on, and hence achieving the results similar to Test Requester and the Proxy Mode.

Affected distributions

  • WireMock Studio - all versions, this proprietary product was discontinued in 2022
  • Potentially, other distributions that include similar UI functionality without proper protection. The WireMock project does not distribute an official UI as of now

NOTE: WireMock official distributions are not vulnerable since they do not provide similar UI components. It was also confirmed that WireMock Cloud does not expose sensitive internal APIs and hence not vulnerable to the issue. No action is needed if you use this SaaS distribution.

Mitigation

N/A, won't fix. Stop using the discontinued WireMock Studio packages, migrate to other distributions. WireMock Inc, the vendor of WireMock Studio, recommends migration to WireMock Cloud (SaaS or private beta for on-premises)

Investigation details

To exploit this vulnerability :

  • Deploy a new instance of WireMock studio :
docker run -it   -p 9000:9000   -p 8000-8100:8000-8100   up9inc/wiremock-studio:latest
  • Reach the URL http://localhost:9000
  • Create a new Mock API with a random name
  • On the left, click on "Test Requester" :

image

  • Attach to the container, and put a listener on the port 1234 : nc -lnvp 1234
  • On the "URL" field, put "@127.0.0.1:1234" :

image

  • Send the request

PoC

When we send the request, we observe that this one arrives on localhost:1234 :

image

Impact

As we can control HTTP Method, HTTP Headers, HTTP Data, and that the result is sent back to the user, this is a full read and controlled SSRF.

If someone is running this docker inside an AWS EC2 cluster (for example), he can perform internal request to the metadata server (169.254.169.254) and recover AWS Secret Keys, even if the protection by the token is activate (because we can make POST, PUT, ... HTTP).

This vulnerability allows wiremock and wiremock-studio to be transformed into a proxy for the internal network of the company that deployed it.

Root Cause

By looking at crash dump of WireMock-Studio when we put invalid character inside the URL, we can see this :

[test] 2023-08-08 08:31:52.243 Unrecoverable error handling admin request
java.lang.IllegalArgumentException: Illegal character in authority at index 7: http://localhost:8000`
	at java.base/java.net.URI.create(URI.java:906)
[...]

Here our input is concatenate to "http://localhost:8000" which allows to put a "@" character and perform request where we want. In fact, URL parser use the following scheme to determine the host, port, ... :

image

A fix will be to change "http://localhost:8000[USER_INPUT]" to "http://localhost:8000/[USER_INPUT]".

Severity

High

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Adjacent
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Changed
Confidentiality
Low
Integrity
High
Availability
Low

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:L/I:H/A:L

CVE ID

CVE-2023-39967

Weaknesses

Credits