SSRF via Improper Redirect Validation in Rocket.Chat oEmbed Function

How it was found

Summary

In Rocket.Chat version 7.10.1, the oEmbed feature is enabled by default and automatically generates a preview whenever a valid URL is posted in a chat. If the URL redirects to another site, the feature follows the redirect to the final destination. While the initial URL is filtered for local IP addresses and other checks—so SSRF protections are effective—the same protections are not applied to the redirected URL. Therefore, an attacker can use a shortened URL or similar to access hosts on the internal network and obtain a preview.

Details

In my test environment, I set up an httpbin server on the same LAN as the Rocket.Chat server to verify whether SSRF was possible. The httpbin server is running at 192.168.100.9:8080, and the attacker cannot reach this server directly.

Step 1. The attacker uses a URL-shortening service to create a valid URL that redirects to http://192.168.100.9:8080. In this case I used "https://tinyurl.com/".

Step 2. The attacker posts that URL to any channel or DM. Then the Rocket.Chat server sends a GET request to the httpbin server on the internal network, resulting in SSRF. Additionally, the attacker can view parts of the httpbin server’s web page via the oEmbed preview feature.

PoC

In the attached PoC video (PoC_SSRF.mp4) we performed the following three attempts.

・Posting http://example.com 　Because this is a valid URL, a preview was displayed.

・Posting http://192.168.100.9:8080 　Because this is a host on the internal network, the SSRF protection prevented a preview from being displayed.

・Posting https://tinyurl.com/bdhdhmrn 　This is a shortened URL that redirects to http://192.168.100.9:8080, but because the redirect destination is not validated. That is why the Rocket.Chat server finally accessed http://192.168.100.9:8080 and displayed a preview.

{F4891683}

Impact

Impact

This allows an attacker to access internal network resources that would otherwise be unreachable and to perform network scanning. Because the attacker can receive portions of responses from internal hosts, the risk of data leakage is extremely high and urgent remediation is required. Furthermore, the same technique could be used to reach cloud services and metadata endpoints (for example, AWS IMDS), potentially exposing sensitive cloud-side data and credentials, so there is also a significant risk of cloud information leakage. To fix this, it is necessary to properly validate not only the posted URL but also the URL(s) of any redirect destinations.