Page MenuHomePhabricator

Reflected File Download from api.php
Closed, ResolvedPublic

Description

Reported by Abdullah Hussam to security@


Hi , this is Abdullah From Isecur1ty
At this time new kind of vulnerability is exploited around which is called "RFD" - Reflected File Download
You can know more from here
https://www.trustwave.com/Resources/SpiderLabs-Blog/Reflected-File-Download---A-New-Web-Attack-Vector/
I addressed some vectors can be used on mediawiki . And I want report it .
Just want to ask if I can send my report and suggest some fixes .If you are interested please contact me .
Wait your replay .
Thanks


Hi , Chris hope you doing well .
I was looking for file that support JSON and JSONP and found that "MedidWiki" have some json endpoint .
Description :
Reflected file download (RFD) is new web attack vectors for attacking website and webapp to show that can be download file from server using attacker file name
As the vector finder talk :
"RFD is a web attack vector that enables attackers to gain complete control over a victims machine by virtually downloading a file from a trusted domain " .
So media wiki used for how much trusted website ?? answer is many ! .
PoC :
The endpoint in PoC
https://en.wikipedia.org/w/api.php
You can see in screen shot it is just JSON content that show on php file .
How I found it ?
I used google dorks for that
Because there are json content it may can be vulnerable .
So here it is what it looks :
Some browsers download json directly but some aren't . But there are new feature in HTML5 can be used for download files with anchor tag
<a href='http://target.com/file.ext' download="file.ext">Download</a>
Works in Chrome latest and Opera ; firefox not supported it.
I work on your some kind to be like this:
https://en.wikipedia.org/w/api.php/;/RFD.bat;?format=json&callback=xxx&requestid=%22||calc.exe||&action=query&prop=revisions&rvprop=content&titles=File%3AProserpineWintersWreath.jpg
Now let's work on Opera or Chrome .
RFD.html
<a href='https://en.wikipedia.org/w/api.php/;/RFD.bat;?format=json&callback=xxx&requestid=%22||calc.exe||&action=query&prop=revisions&rvprop=content&titles=File%3AProserpineWintersWreath.jpg' download="RFD.bat">Download</a>
it's work ?? :
\
This is just example for the vuln it may lead to many more issues ,
Impact
Phishing
download evil fires as updates
download php files as update for mediawiki


last words :
for fix you can do something like :
ModSecurity users can use the following equivalent rule:
SecRule REQUEST_URI "@rx (?i:^[^?]*\.(bat|cmd)(\W|$))" "phase:1,id:100,t:none,t:urlDecodeUni,block,msg:'Potential Reflected File Download (RFD)
​Or any prevent ideas you have .
I just want to ask if there are bounty or credit for this finding .
Thanks for read .
Reference :
https://www.trustwave.com/Resources/SpiderLabs-Blog/Reflected-File-Download---A-New-Web-Attack-Vector/
https://www.blackhat.com/docs/eu-14/materials/eu-14-Hafif-Reflected-File-Download-A-New-Web-Attack-Vector.pdf
https://www.youtube.com/watch?v=dl1BJUNk8V4&noredirect=1

Event Timeline

csteipp created this task.Feb 26 2016, 8:33 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 26 2016, 8:33 PM
Restricted Application changed the visibility from "Custom Policy" to "Custom Policy". · View Herald TranscriptFeb 26 2016, 8:36 PM
Restricted Application changed the edit policy from "All Users" to "Custom Policy". · View Herald Transcript
csteipp triaged this task as Normal priority.Feb 26 2016, 8:59 PM

In my opinion, this is mostly a browser issue. That said, as a high profile site we should probably try to help out users if we can fix this.

The original trustwave whitepaper: https://drive.google.com/file/d/0B0KLoHg_gR_XQnV4RVhlNl96MHM/view?pref=2&pli=1

We rarely set content-disposition in mediawiki, and when we do we usually set a filename as well.

Using the api as Abdullah reported, which sets content-type:text/javascript, IE is vulnerable to direct links, Opera and Chrome require a link with the download attribute set.

I think we could detect this in IEUrlExtension and redirect if we see something suspicious.

csteipp added a subscriber: Tod97.Feb 26 2016, 10:15 PM
Anomie added a subscriber: Anomie.Feb 26 2016, 11:15 PM

I agree, mostly a browser bug. But,

.

csteipp moved this task from Backlog to Ready on the Security-Team board.Mar 9 2016, 9:32 PM
Tod97 added a comment.Jun 10 2016, 2:48 PM

any update ?

Bawolff added a subscriber: Bawolff.

I agree, mostly a browser bug. But,

.

In certain configs, ORIG_PATH_INFO is actually the normal path to the script and not the "extra-path".

In particular this breaks on php 5.5.32 set up in cgi mode with a config like:

ScriptAlias /php-bin /path/to/my/phpbinary/cgi
AddHandler application/x-httpd-php5 php
Action application/x-httpd-php5 /php-bin/php-cgi
<Directory "/path/to/my/phpbinary/cgi">
    Order allow,deny
    Allow from all
</Directory>

Other than the ORIG_PATH_INFO stuff, this patch looks good.

One thing about this patch that gave me slight pause - is it really a good idea to suggest .php (for format=php) and .js (for format=json&callback=foo) as the extension, given php and js are executable format. But given the context, I guess that makes sense - almost no users are going to have php interperters, and even if they did, its not like the output of the api is going to be malicious. So I think that is actually fine.

Will those certain configs also break WebRequest? Or is that why we have $wgUsePathInfo?

Anyway, here's a version that doesn't check ORIG_PATH_INFO:

Tod97 added a comment.Oct 8 2016, 5:53 PM

Is it fixed yet ?

Is it fixed yet ?

Sorry, not yet. It kind of got put at the bottom of the pile and slightly forgotten about due to some other more severe bugs.

Tod97 added a comment.Jun 16 2017, 5:11 PM

Hey ,
any update ?

Hi. Sorry.

Anyway, here's a version that doesn't check ORIG_PATH_INFO:

+1 to this patch.


Some notes about this issue:

  • Requires link to be not-cross origin to work (except chrome, but this will probably change in chrome 61 - https://bugs.chromium.org/p/chromium/issues/detail?id=714373), which makes it much harder to exploit.
  • Behaviour of firefox and chrome seem to both mildly differ from the standard (https://html.spec.whatwg.org/#downloading-resources), and most online docs.
    • The content-disposition: inline seems to totally override the download attribute in firefox causing firefox to not download the file.
    • Google chrome seems to totally ignore the suggested filename if content-disposition is not attachment (Hence this patch does not work for same-origin download attribute on chrome). But using content-disposition: attachment would be a pita.
      • But chrome will not use suggested extension when cross-origin, and it warns me about dangerous extensions like .sh when same origin.

So overall the patch is probably worth it, even if not 100% perfect coverage for chrome in that one case.


@Tod97 We will test this patch on Wikipedia, and if everything works, we will include it in the Next security release of MediaWiki (1.28.3 & 1.27.4) and make this bug public when 1.29.2 is released. I'm not sure what the schedule for the next security release is, but probably about 1.5 months.

Tod97 added a comment.Jun 26 2017, 9:54 AM

@Bawolff Thanks for replay . Please add my name "Abdullah Hussam [@Abdulahhusam] " to the thanks page [https://www.mediawiki.org/wiki/Wikimedia_Security_Team/Thanks] and notice me when the CVE will be assigned .

BR

We are now testing the patch on wikipedia.

We are getting some false positives for this patch due to things like: https://en.wikipedia.org/w/api.php/?format=json&formatversion=2&action=query&titles=Abraham+Lincoln&prop=revisions|images|info&rvprop=content|parsetree&imlimit=500&inprop=url ( https://logstash.wikimedia.org/goto/2dd875f4e42c7297d3320cc2a81c7ca6 )

We should perhaps allow a simple trailing / since that's safe. Or redirect.

[08:50] _joe_ bawolff: I'd issue a 301 to the correct url
[08:50] _joe_ there is no point in allowing that

ATM the patch above issues a 500, which among other things shows up in various ops dashboards. I think in this case we should return a 400 instead since there's nothing we can do

Proposed change, to use 301 instead:

[The above patch is based on top of the other one].

Combined version of the patch:

Proposed change, to use 301 instead:


[The above patch is based on top of the other one].
Combined version of the patch:

Godog +1'd this patch on irc, and I deployed the new version

I also just now sent a message to mediawiki-api (https://lists.wikimedia.org/pipermail/mediawiki-api/2017-June/004002.html ) . Maybe that should go to mediawiki-api-announce, but i don't think i have post rights there. In retrospect, maybe I should have tried to give people more warning beforehand (?)

@Bawolff Hi , I am gonna deactivate the notifications of this . And Just want to make sure that I will get the credit I really waited too long for the patch ( more than a year ) . So please confirm the credit so I can go on my way .

Thanks

@Bawolff Hi , I am gonna deactivate the notifications of this . And Just want to make sure that I will get the credit I really waited too long for the patch ( more than a year ) . So please confirm the credit so I can go on my way .
Thanks

Yes, ill make sure you are properly credited. However we are only going to make this public when the next version of MediaWiki comes out, which may be in a month or 2.

Hmm. there may be a similar issue in load.php

Regarding the 301, has anyone checked the browsers involved to make sure they use the redirected-to URL when determining the filename rather than the original URL? Ideally the Content-Disposition header will still override it, but better to fix it both ways.

Other disadvantages of a 301 that don't necessarily block using it:

  • Some clients have historically turned a 301ed POST into a GET on the target URL. If someone is using a library with that misbehavior and doesn't notice the followed redirect, they may be confused when their request doesn't work right due to lost POST data.
  • If it's not failing people won't fix it.

Regarding the 301, has anyone checked the browsers involved to make sure they use the redirected-to URL when determining the filename rather than the original URL? Ideally the Content-Disposition header will still override it, but better to fix it both ways.

Yes i did that. In the 301 case, it seems like either the content-disposition header rules for filename or the download behaviour is ignored and its displayed inline. (Checked firefox, chrome, and safari)

Tod97 added a comment.EditedOct 8 2017, 2:16 PM

any update for the patch? @Bawolff

Proposed change, to use 301 instead:

Re-reviewing this patch, I note that your 301 is going to move the POST data into the GET part of the URL. You'd need to use $wgRequest->getQueryValues() instead. Although personally I'd still just change the 500 to a 400 and let people fix their broken code.

any update for the patch? @Bawolff

This is considered not serious enough to trigger a new version of mediawiki on its own, so its going to be included in the next security release of mediawiki (whenever that is). Its been a while since last security release, so a new one will probably happen sometime soonish, but I'm not exactly sure when.

Reedy added a subscriber: Reedy.Nov 3 2017, 12:01 AM

Re-reviewing this patch, I note that your 301 is going to move the POST data into the GET part of the URL. You'd need to use $wgRequest->getQueryValues() instead. Although personally I'd still just change the 500 to a 400 and let people fix their broken code.

I guess this patch needs some followup work?





Reedy closed this task as Resolved.Nov 13 2017, 4:18 PM
Reedy assigned this task to Bawolff.

Closes as resolved (due to patches existing, and backports having been made), for ease of tracking in parent bugs

Reedy changed the visibility from "Custom Policy" to "Public (No Login Required)".
Reedy changed the edit policy from "Custom Policy" to "All Users".

Change 391411 had a related patch set uploaded (by Ejegg; owner: Anomie):
[mediawiki/core@fundraising/REL1_27] SECURITY: API: Avoid some silliness with browser-guessed filenames

https://gerrit.wikimedia.org/r/391411

Change 391419 had a related patch set uploaded (by Reedy; owner: Anomie):
[mediawiki/core@REL1_30] SECURITY: API: Avoid some silliness with browser-guessed filenames

https://gerrit.wikimedia.org/r/391419

Change 391419 merged by Reedy:
[mediawiki/core@REL1_30] SECURITY: API: Avoid some silliness with browser-guessed filenames

https://gerrit.wikimedia.org/r/391419

Change 391411 merged by jenkins-bot:
[mediawiki/core@fundraising/REL1_27] SECURITY: API: Avoid some silliness with browser-guessed filenames

https://gerrit.wikimedia.org/r/391411

Change 391449 had a related patch set uploaded (by Reedy; owner: Anomie):
[mediawiki/core@master] SECURITY: API: Avoid some silliness with browser-guessed filenames

https://gerrit.wikimedia.org/r/391449

Change 391449 merged by jenkins-bot:
[mediawiki/core@master] SECURITY: API: Avoid some silliness with browser-guessed filenames

https://gerrit.wikimedia.org/r/391449

Change 391714 had a related patch set uploaded (by Chad; owner: Anomie):
[mediawiki/core@wmf/1.31.0-wmf.8] SECURITY: API: Avoid some silliness with browser-guessed filenames

https://gerrit.wikimedia.org/r/391714

Change 391714 merged by jenkins-bot:
[mediawiki/core@wmf/1.31.0-wmf.8] SECURITY: API: Avoid some silliness with browser-guessed filenames

https://gerrit.wikimedia.org/r/391714

The redirect is being complained about in T215857: api.php PATH_INFO check infinite recursion, FYI.