1340601 - Interesting Bug -Address Bar redirection with Double URL Encoding of %

Status: RESOLVED DUPLICATE of bug 1339497

(Firefox :: Address Bar, defect)

Description

[Vijay Kumar Adapa]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36

Steps to reproduce:

Video POC URL: https://youtu.be/moDNCwq4WGc

Watch the above video POC before proceeding any further  !

Version : 51.0.1
   
Payload -  %25%32 or %25%32%35 ...etc (Other variants of % url encoding also possible ex:%2525 in somecases)

How it is prepared : Just double encode % (i.e, %->%25->%25%32%35)

Prerequisite:

 User should open that website url before with vulnerable paramter(Eg:Search) 

 PS:-> Which is very common since google ,  other browsers, also facebook, twitter and other ecommerce websites is used for search as a part of general usage.  
-> Otherwise we can even make the user opening required url with so many ways.

Without Prerequisite:
Good example to make no above prerequisite without any interaction from victim :<meta http-equiv="refresh" content="5; URL=javascript:window.open('http://URLtobeOpened.com/%25%32','_parent');">  ) 

which will open required url in the new tab automatically without any click.So no user interaction in this regard)  



Repro Steps & Payloads:
step1: Make that prerequisite happen in victim browser either through click or without interaction
Step2:
   Enter these payloads in paramters of URL bar and hit “ENTER” keystroke



Actual results:

For Google:  
 payload1 - https://www.google.co.in/#q=%25%32
 payload2 - https://www.google.co.in/#q=%25%32%35

For Facebook:
 payload1 - https://www.facebook.com/search/top/?q=%25%32
 payload2 - https://www.facebook.com/search/top/?q=%25%32%35

For Twitter:
payload1 - https://twitter.com/search?q=%25%32
payload2 - https://twitter.com/search?q=%25%32%35 

PS:Watch Video POC


Expected results:

It shouldn't redirect victims from trusted websites to untrusted just by "ENTER" key
I'm mentioning two of the few serious  impacts here:

Impacts: 

Critical: Due to redirection possible using parameters we can steal oauth tokens of social media and other sites which provides oauth support  using sophisticated attack

High: We can host malcious content on redirected websites (Eg:twittwitter.com for twitter redirection)
PS: Watch Video POC

Comment 1

[:Gijs (he/him)]

I can't reproduce, and I don't understand the "prerequisite" instruction. The 'prerequisite' also doesn't show up in the video - you just open new tabs.

So please provide more complete steps to reproduce and ideally a clear testcase that reproduces the problem in a clean Firefox profile (there's several add-ons installed in the profile you use in the video, and it's possible they're causing the location bar to misbehave). Also please be clear on what OS and with what versions you have/haven't tested.

Finally, what is the impact of the vulnerability? Who controls the extra strings that you see appear in the location bar? Do you? How? If you need the user to load your magic string, which then redirects to another domain why not make them load the target URL directly? How would you use this to steal oauth credentials?

Comment 2

[Vijay Kumar Adapa]

Point1: Regarding Reproducing

Ans)
Prerequisite is : Open the payload url(Ex: https://twitter.com/search?q=%25%32%35) in victim browser before actually attack begins.

Steps to reproduce will be:

-> Open https://twitter.com/search?q=%25%32%35 in firefox. (prerequisite) that we can do using above mentioned trick without user interaction.

->Now copy paste the above payload in  url bar and hit ENTER key (not mouse click)


Point2: Does it work everywhere or plugins creating this problem ?

Ans) No i have tested this in windows 7/windows 8 where no plugins installed also Mac sierra And the affected firefox version is 51.0.1 is vulnerable regardless of OS platforms.

Point3:Impact of the vulnerability? and other questions

Ans)

->  We can redirect users to malcious sites where attacker content is hosted to takeover !

Even security minded people also never think in their wild dreams that typing  facebook url (https://www.facebook.com/search/top/?q=%25%32%35 ) will land them in trouble since trust the have these websites.

Similarly is the google case , who will doubt this url(https://www.google.co.in/#q=%25%32%35) to enter/copypaste this  in url bar and hit enter .

We can use trust of these famous website url's to attack users.

In the End ; It's very much easy to convince even security people to enter https://www.google.co.in/#q=%25%32%35 than https://www.EVILWEBSITE.com/#q=%25%32%35 as a part of instructions steps !

And coming to Oauth i haven't tried this exploit yet using this, but Still  if redirection accepts anything we can short(bit.ly) payload url and that may work.

Comment 3

[:Gijs (he/him)]

OK, so clearer steps to reproduce...:

1. select the following URL (don't right click and copy the link location as that alters the link content) and copy it as plain text:

https://www.facebook.com/search/top/?q=%25%32%35

2. open a new tab, paste the URL and hit enter

3. wait for 5 seconds for everything to end up in history

4. open another new tab, paste the same URL, hit enter again.


Marco, as far as I can tell the history entry is somehow causing the garbled URL to get hit, which feels pretty crazy to me. Not convinced it's an actual security issue because I don't think the attacker can control how the text gets garbled, but it's confusing that it does get garbled. Any idea what's happening?

Comment 4

[Vijay Kumar Adapa]

Hello there , First three steps reproduction steps mentioned are trivial.
We can make it easy :

 ->No, we can right click and copy the link location ! It won't change the link

   Just Try copying any of the above links and paste it in URL bar ,then you can observe that nothing changed.

  Further, He need not to hit the "Enter" first time ,he can do paste & go. But we will use <a> or <meta> or <script> to make this very much trivial.

Note:Only he need "ENTER" one time. i.e , he when he copy/paste and hit the Enter . First time opening of url can be done by attacker easily by using mentioned ways.

And yes it's security issue, we can control the redirected website by hosting malicious content !

Ex:This is universal bug not limited Facebook,twitter,google only. It can be used in all the website using parameters !

And 90% of the redirected domains are available to buy online .So it's that attacker can succeed almost every time.

For ex microsoft Payload URL:https://www.microsoft.com/en-in/search/result.aspx?q=%25%32%35 redirect us to www.microsmicrosoft.com which is available .Also twitter redirect domain also as mentioned above .

Also we can use variance in the payload url to get the desired redirect domain.Hence it' attackers safe game !

And i have tried to understand what's happening behind the scenes but it's very weird behaviour  that it exhibiting !

Comment 5

[Marco Bonardo [:mak]]

Thank you, the video was quite clear.
This is basically bug 1339497 that was reported some days ago, I think the problem lies into some wrong cropping of the text that seems to calculate the indices on a decoded string and then applying those indices to an encoded string. It's likely a bug in the autocomplete controller. I'll take that bug.

Fwiw, I also don't see this as an interesting attack vector, the maximum that can happen is that the user visits the wrong page, but the locationbar is pretty clear about which page he's on. Even if the target page hosts malicious content, it's pretty clear it's not facebook, nor google. It would be different if there'd be a locationbar spoof.
the only attack vector I see here, but it's not exposed in the bug, is forcing a download from the "wrong" domain, but again the download UI is clear about which domain the file comes from. If this is considered a valid attack, it would be a sec-low, imo.

We could even dupe to bug 1339497, if we agree on the security risk.

Comment 6

[Vijay Kumar Adapa]

Hi Marco,


  Thanks for the reply and also for disclosing unpublished attack vector in this regard.
-> Your assumption(maximum that can happen is that the user visits the wrong page) is absolutely right , but the attack surface is not minimal Here is why !

Your comment: Locationbar is pretty clear about which page he's on. Even if the target page hosts malicious content, it's pretty clear it's not facebook, nor google !

Ans) This functions absolutely like open redirection and we can make the target.com automatically redirects to something close to victim.com domain name.

And thanks to your vector , we can use it very well. 
->As soon as user redirected to target.com from victim.com ,we can initiate the .exe or something executable and redirect back to victim.com. 
This make user believe that downloaded file from victim.com which is not !

Considering these risks , this report carries average risk at least as per my understanding , Thanks !

Regards
Vijay Adapa

Comment 7

[Vijay Kumar Adapa]

Open redirection which is few months back https://www.hackread.com/pakistani-hacker-chrome-firefox-flaw/

Comment 8

[Marco Bonardo [:mak]]

This is something for the security team to evaluate, I'm fixing the underlying bug in the meanwhile.

Comment 9

[Daniel Veditz [:dveditz]]

(In reply to Vijay Kumar Adapa from comment #7)
> Open redirection which is few months back
> https://www.hackread.com/pakistani-hacker-chrome-firefox-flaw/

That was a different issue. In that case the URL bar lied about where you were, visually appearing as "www.google.com" when it was somewhere completely different. Also didn't require the user to interact with the location bar to get there so it was a much more convincing spoof.

We don't need to keep this bug hidden.