This issue has been reviewed by the Drupal security team and it was decided that this can be handled as public security improvement. The issue was reported by
Hugh Davenport →
.
Problem/Motivation
There is Server Side Request Forgery (SSRF) vulnerability in the Aggregator module.
The vulnerability lies in the URL of a feed in the aggregator module, which can be edited at the URL path /admin/config/services/aggregator/edit/feed/1
The URL needs to be changed, then "Save" clicked, then on the new page (/admin/config/services/aggregator/), "update items" needs to be clicked. The output will
be shown close to the top of the page.
You can use the "URL" input to do any of the following:
Proposed resolution
- Mark the "administer news feeds" permission as restrict access => TRUE, so that it should be only given to trusted users. But that might be a bit overkill since a port scan does not really offer you the opportunity to take over the site or compromise the security in a severe way
- Rate limiting (how many feeds can a person reasonably add? maybe 50?) would make this tool much less useful to an attacker.
- Another fix, rather than ratelimiting, is to not show any error messages (port scan attack would not be possible), and not allowing access to certain hosts. There is a php library that stops curl accessing things (not fully functional, but can take ideas from it) at https://github.com/fin1te/safecurl
Remaining tasks
- Agree on a solution
- Write a patch, including tests
- Review the patch
User interface changes
Likely none
API changes
Likely none
Original issue
Hi,
I would like to report a Server Side Request Forgery (SSRF) [1] vulnerability
in the aggregator module.
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.
The vulnerability lies in the URL of a feed in the aggregator module, which can be edited
at the URL path /admin/config/services/aggregator/edit/feed/1
The URL needs to be changed, then "Save" clicked, then on the new page
(/admin/config/services/aggregator/), "update items" needs to be clicked. The output will
be shown close to the top of the page.
You can use the "URL" input to do any of the following possible exploits:
- Port scanning, by using http://allthethings.co.nz:1/ through to http://allthethings.co.nz:65535/. Example responses:
* Port closed:
The feed from test seems to be broken, because of error "-111 Connection refused".
* Port open but not HTTP:
Notice: Undefined offset: 1 in drupal_http_request() (line 984 of /var/www/snip/includes/common.inc).
Status message
The feed from test seems to be broken, because of error "0 ".
* Port open with HTTP, and is a feed:
There is new syndicated content from test.
* Port open with different HTTP status, or another error.
- Internal IP scan, by using http://192.168.1.1/ (with ports as well, to get full scan)
* similar error messages as above ^^
- Localhost scan, use http://localhost/ (with ports), or with a HTTP redirect (http://allthethings.co.nz/test.php), or with a DNS record (http://testing.allthethings.co.nz, or http://testing6.allthethings.co.nz), or with ip's (http://127.0.0.1 or http://[::1]).
* simial error messages as above ^^
You could also use this vulnerability to perform attacks on internal systems with
vulnerabilities exploitable only with GET requests, such as SQLi in query strings.
Note that the following limitations are present:
- No output returned of the resource
- Only allowed http and http schemas (even with HTTP redirect)
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 all helps. Let me know whether you need any more information.
As you are using PHP, there is a library that can sit as a wrapper over libcurl, called safecurl [2], but currently has some issues before being usable.
This information was provided to you in good faith. I see there is a security bounty program at [3] and have followed those guidelines by submitting this bug here.
Cheers,
Hugh
[1] http://www.acunetix.com/blog/articles/server-side-request-forgery-vulnerability/
[2] https://github.com/fin1te/safecurl
[3] http://www.whitefirdesign.com/about/drupal-security-bug-bounty-program.html
Original comments
I don't agree that this is an
Comment #1 Dave Reid commented November 27, 2014 at 1:51am
I don't agree that this is an actual security vulnerability. I would say this could be filed as a public security improvement, but I don't think it's something that needs fixing. You could do this same thing with many different Chrome extensions, or even Guzzle or cURL yourself.
Comment #2 hughdavenport commented November 27, 2014 at 3:03am
Hi Dave,
I would disagree, sure you can do this with a chrome extension and cURL locally, but in that case "localhost" means a completely different thing. If I used curl on my laptop and did this same attack, the port scan would come from my laptop, and localhost is my laptop. If this attack was done on a drupal in the wild, I could do a port scan *from that server* (not my laptop), and localhost *would be that server* (not my laptop). The point is you are changing the systems you can access, which may be a different set than before. If a server runs behind a firewall, this attack could allow attackers to scan machines behind that firewall that were previously unreachable.
This attack is also known as a Cross Site Port Attack (XSPA), which there is a good 3-part writeup at [1].
I hope that helps clear things up. Feel free to comment if you are still unsure and I can try to explain it a bit better.
Cheers,
Hugh
[1] http://www.riyazwalikar.com/2012/11/cross-site-port-attacks-xspa-part-1....
Comment #3 hughdavenport commented January 18, 2015 at 2:24am
Hi,
Just chasing up on this? Is it deemed a security vulnerability (and therefore needs a patch), or not (and can be made public and marked wontfix).
Happy to provide any additional info if needed.
Cheers,
Hugh
Comment #4 greggles commented January 18, 2015 at 2:39pm
Component: » aggregator.module
The two process outcomes are a little different than stated in #3 - in both cases it would be reasonable to add a patch and fix it. Just one of them happens in private and results in a security advisory while the other happens in the public queue and results in a patch to a future release.
I personally think this should be made public. It's definitely something that could be used in an attack on a site. However, I think the mitigating factors (an attacker has to have "administer news feeds" permission, the target of their attack has to either provide an rss feed OR they are just looking to fingerprint IPs/hostnames/ports) make it obscure and low value enough that it's not worth focusing on in the private security team tracker.
@hughdavenport - am I right to assume that you don't plan to provide a patch? If you were willing to work on a patch that could affect whether this is private or public.
Comment #5 hughdavenport commented January 20, 2015 at 3:08am
Hi @Greggles,
I could potentially provide a patch time permitting, but don't hold your breath on that.
Just to correct what you said a bit, the target of the attack would be the the server hosting the drupal, not the site hosting an rss.
There isn't actually a need for an rss (and doesn't make the attack any more powerful), as the point is to do a port scan from
the POV of the drupal host (including behind any firewall of the drupal host, such as localhost, which wouldn't be accessible normally).
Agree that the exploitability is quite low, as you do require that permission.
Cheers,
Hugh
Comment #6 greggles commented January 22, 2015 at 12:55pm
The rss feed scenario I was considering is like intranet.somecompany.com/rss.xml which is a site only accessible on the private network and that includes a feed of information that is generally confidential. If we're judging this vulnerability by a worst-case-scenario, I think a confidential feed is a worse thing to have exposed than the enumerated list of hosts/ports that are online.
Comment #7 hughdavenport commented January 22, 2015 at 9:47pm
Ah yeh, I would agree with that. I was just going from the aspect you could do *something* you couldn't, but scenario wise that would be bad. Port scanning is useful for other attacks maybe, but no real info leaked
Comment #8 klausi commented March 10, 2015 at 10:10am
Status: Active » Needs team response
I agree that this can be a public hardening issue. The easiest solution seems to be to just mark the "administer news feeds" permission as restrict access => TRUE, so that it should be only given to trusted users. But that might be a bit overkill since a port scan does not really offer you the opportunity to take over the site or compromise the security in a severe way ...
Let me know if you think we should keep this private, otherwise we can move this to the public queue in 2 weeks.
Comment #9 hughdavenport commented March 10, 2015 at 7:30pm
Potentially this could cause more than just a port scanning attack if there are services with weak security accessible from the drupal host (ie, can exploit by sending a GET request to an internal management webserver to change state or something).
Cheers,
Hugh
Comment #10 Pere Orga commented April 11, 2015 at 7:16pm
If an attacker can't make a connection to that server, I don't think it's very useful for him to scan its open ports.
Potentially this could cause more than just a port scanning attack if there are services with weak security accessible from the drupal host (ie, can exploit by sending a GET request to an internal management webserver to change state or something).
But that would mean that the service has a CSRF vulnerability and that the attacker knows about it. It's possible but I don't think that makes it deserve an advisory.
+1 to fix this in public - but I don't know how this should be fixed.
Comment #11 greggles commented April 13, 2015 at 3:56am
I think rate limiting some amount (how many feeds can a person reasonably add? maybe 50?) would make this tool much less useful to an attacker. If there aren't any watchdog messages about "added a feed" then we should add some.
Comment #12 hughdavenport commented April 15, 2015 at 4:59am
@Pere, they would either need to know what service is there, or just scan a whole bunch of well known ones, such as EC2 or openstack (see https://hackerone.com/reports/53088), or anything from https://docs.google.com/document/d/1v1TkWZtrhzRLy0bYXBcdLUedXGb9njTNIJXa...
Another fix, rather than ratelimiting, is to not show any error messages (port scan attack would not be possible), and not allowing access to certain hosts. There is a php library that stops curl accessing things (not fully functional, but can take ideas from it) at https://github.com/fin1te/safecurl
Cheers,
Hugh
Comment #13 greggles commented April 15, 2015 at 2:10pm
I don't think Drupal core can reduce the specifics of the error message or reduce the hosts available - both of those are important for the tool to be able to work well in a variety of environments.
Comment #14 dokumori commented May 2, 2015 at 11:45am
Status: Needs team response » Needs public issue created
It seems majority of the people here agree this can be treated as a public hardening. If no one opposes in one week's time, I'll make it public.
If anyone feels this should be fixed privately, please state your reason here and also change the issue status.
