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" :

• 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" :

• Send the request

PoC

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

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, ... :

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