Home

New Relic - Blind SSRF in Ticketing Integrations Jira webhooks leading to internal network enumeration and blind HTTP requests

• Bug Reports

HackerOne bug report to New Relic: The Ticketing Integrations Jira webhooks for Jira 5/6 and Jira 4 are vulnerable to Blind SSRF issues. These endpoints can be abused to map internal NewRelic network services and send blind HTTP GET and POST requests to identified services.

Note: This previously disclosed report has been re-posted here as the New Relic program migrated away from HackerOne, which un-disclosed all reports 😑

Summary The Ticketing Integrations Jira webhooks for Jira 5/6 and Jira 4 are vulnerable to Blind SSRF issues. These endpoints can be abused to map internal NewRelic network services and send blind HTTP GET and POST requests to identified services.

Details The Ticketing Integrations Jira 4 and Jira 5/6 webhooks accept arbitrary URLs for webhook destinations. Internal or local IP addresses can be used as the URL host, causing the webhooks to fire against these internal systems.

HTTP responses received from testing the webhooks can be assessed to determine the state of the webhook destination. The HTTP responses differ if a webhook destination URL points to a closed tcp port (e.g. http://nr.webhooks.pw:21) or an open tcp port (e.g. http://nr.webhooks.pw:22).

This technique was used to profile the open tcp ports on the local system making the webhook HTTP requests. The following open ports were identified on http://127.0.0.1:

22/tcp
25/tcp
80/tcp
199/tcp
514/tcp
5666/tcp
8100/tcp
9999/tcp
55555/tcp

A small scan of internal accessible systems identified the following hosts with open SSH ports (22/tcp)

10.1.0.5
10.1.0.6
10.1.0.7
10.1.0.8
10.1.0.9
10.1.0.17
10.1.0.18

Once services have been identified, restricted HTTP requests can be sent to the service endpoint via the webhooks functionality. In these requests the attacks has full control over the HTTP path and query string. The HTTP response code can often be inferred, however the response body is not accessible

Suggested Fix Restrict permitted webhook addresses to only external network addresses outside the NewRelic external networks, i.e. exclude 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 and New Relic external ranges e.g. 185.221.84.0/21, 162.247.240.0/22 and 50.31.164.0/24 (and any other NewRelic owned external IP address ranges). Also consider restricting access to local IPv6 addresses.

Browsers Verified

  • Firefox 59.0.2 (64-bit) macOS

Steps to Reproduce

  1. Browse to the Jira 4 Ticketing Integrations Page for your account (https://rpm.newrelic.com/accounts/xxxxxxx/integrations?page=ticketing#tab-integrations=_jira_4) OR
  2. Browse to the Jira 5/6 Ticketing Integrations Page for your account (https://rpm.newrelic.com/accounts/xxxxxxx/integrations?page=ticketing#tab-integrations=_jira_5_6)
  3. Add http://127.0.0.1: for the URL, choosing a port you would like to check the state of on the local system, e.g. 22
  4. Select the “Integrate with JIRA” button

For Jira 4 If the HTTP response code is 200 an error message will display the state of the port, e.g. Error authenticating connection: can't connect to http://127.0.0.1:21, otherwise if the response code is 500 it indicates the chosen port is open.

For Jira 5/6 If the HTTP response code is 200 it indicates the chosen port is closed, otherwise if the response code is 500 it indicates the chosen port is open.

Supporting Material

Port Scanning 10.1.0.17

Using the Jira 4 Ticketing Integration to port scan 10.1.0.17:

Response showing closed port 21/tcp on 10.1.0.17:

HTTP/1.1 200 OK
...
Error authenticating connection: can't connect to http://10.1.0.17:21/

Error response indicating open port 22/tcp on 10.1.0.17:

HTTP/1.1 500 Internal Server Error
...
Oops! You've found our error page.

Response showing closed port 23/tcp on 10.1.0.17:

HTTP/1.1 200 OK
...
Error authenticating connection: can't connect to http://10.1.0.17:23/

Impact

An attacker could abuse this issue in order to identify hosts and service on the internal New Relic networks. Once identified, blind HTTP payloads could be sent to these services in an attempt to exploit them.

The hacker selected the Server-Side Request Forgery (SSRF) weakness. This vulnerability type requires contextual information from the hacker. They provided the following answers:

Can internal services be reached bypassing network access control? Yes

What internal services were accessible?

127.0.0.1:22/tcp
127.0.0.1:25/tcp
127.0.0.1:80/tcp
127.0.0.1:199/tcp
127.0.0.1:514/tcp
127.0.0.1:5666/tcp
127.0.0.1:8100/tcp
127.0.0.1:9999/tcp
127.0.0.1:55555/tcp
10.1.0.5:22/tcp
10.1.0.6:22/tcp
10.1.0.7:22/tcp
10.1.0.8:22/tcp
10.1.0.9:22/tcp
10.1.0.17:22/tcp
10.1.0.18:22/tcp

Security Impact An attacker could abuse this issue in order to identify hosts and service on the internal NewRelic networks. Once identified, blind HTTP payloads could be sent to these services in an attempt to exploit them.

Comment - April 27, 2018

…

One potential avenue I thought of with this issue is gaining access to IP gated external services, such as https://rpm-admin.newrelic.com. When attempting to access this service from an external IP address the following error is presented:

Please connect (or VPN) to an office network to access. IP: 146.198.145.57

Using this issue it may be possible to circumvent the IP restrictions present on this service.

…

Home More bug report posts