Last Comment Bug 687745 - (CVE-2012-0474) URL & SSL/TLS Spoofing and saved password stealing using multiple history.back() and history.forward()
: (CVE-2012-0474) URL & SSL/TLS Spoofing and saved password stealing using mult...
Status: VERIFIED FIXED
[sg:high][qa!] fixed by bug 737307
:
Product: Core
Classification: Components
Component: Document Navigation (show other bugs)
: Trunk
: x86_64 Windows 7
: -- normal (vote)
: mozilla14
Assigned To: Olli Pettay [:smaug] (way behind * queues, especially ni? queue)
:
:
Mentors:
http://www.alternativ-testing.fr/Rese...
: 703111 (view as bug list)
Depends on: CVE-2012-0474
Blocks:
  Show dependency treegraph
 
Reported: 2011-09-19 18:26 PDT by Jordi Chancel
Modified: 2015-07-22 12:42 PDT (History)
14 users (show)
rforbes: sec‑bounty+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
wontfix
fixed
fixed
fixed
12+
verified


Attachments
ScreenShot.png (122.28 KB, image/png)
2011-09-19 18:26 PDT, Jordi Chancel
no flags Details
TESTCASE1 (1.73 KB, application/octet-stream)
2011-09-19 18:35 PDT, Jordi Chancel
no flags Details
TESTCASE1.1 (1.66 KB, application/java-archive)
2011-09-19 19:05 PDT, Jordi Chancel
no flags Details
ScreenShot2 (saved password) (64.62 KB, image/png)
2011-09-19 23:13 PDT, Jordi Chancel
no flags Details
ScreenShot firefox 7.0.1 (84.74 KB, image/png)
2011-10-12 14:36 PDT, Jordi Chancel
no flags Details
TESTCASE2.0 (back automaticaly, can steal saved password) (1.62 KB, application/x-rar-compressed)
2011-10-17 14:52 PDT, Jordi Chancel
no flags Details
ScreenShot4 Firefox 7.0.1 with developer.mozilla.org (99.83 KB, image/png)
2011-11-03 16:05 PDT, Jordi Chancel
no flags Details
TestCase3.0 with developer.mozilla.org (1.63 KB, application/octet-stream)
2011-11-03 16:08 PDT, Jordi Chancel
no flags Details
Basic testcase (198 bytes, text/plain)
2011-11-16 17:33 PST, Eddy Bordi
no flags Details

Description Jordi Chancel 2011-09-19 18:26:11 PDT
Created attachment 561093 [details]
ScreenShot.png

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20100101 Firefox/6.0.2
Build ID: 20110902133214

Steps to reproduce:

The problem originated is from the creation of a link with javascript (window.open ; document.location ; back() ; forward() ; fragment navigation and Redirect.) . When you open a new tab via window.open on another address (with SSL or not) and use all of this elements,  it's possible to spoof the URL and SSL/TLS.
It's also possible to steal saved password on Mozilla firefox if the web page spoofed contains a form with saved password. the form should be like : <form ACTION="/connect.php"> but not like this : <form ACTION="HTTP://www.xxx.yyy/connect.php"> for steal the saved password and login (I have chosen linkedin.com for demonstrate this).

This blank page can be changed with javascript with making a spoofing attak.



Actual results:

URL with SSL/TLS is Spoofed and we can steal saved password of linkedin.com (and many other website with a connection formulary's like linkedin.com)

/!\ I had found a very similare vulnerability on Google chrome in the past (same impact => SecSeverity:high)
Comment 1 Jordi Chancel 2011-09-19 18:35:04 PDT
Created attachment 561095 [details]
TESTCASE1

Please try and retry this TESTCASE ! (don't works perfectly the first time)
Comment 2 Jordi Chancel 2011-09-19 19:05:31 PDT
Created attachment 561100 [details]
TESTCASE1.1

Better Testcase!
Comment 3 Jordi Chancel 2011-09-19 21:25:33 PDT
If the testcase1.1 don't works the first time , please back or forward manually ( button back or forward).
Comment 4 Jordi Chancel 2011-09-19 21:49:55 PDT
Result of testcase1.1 can show the cookie of attacker but the content is linkedin.com . I think we can bypass de cross origin.
Comment 5 Jordi Chancel 2011-09-19 23:13:45 PDT
Created attachment 561127 [details]
ScreenShot2 (saved password)

screenshot2 with saved password
Comment 6 Brandon Sterne (:bsterne) 2011-09-20 10:14:32 PDT
I had to run the testcase several times, but it does reproduce for me in Firefox 6 and Nightly.  Just to make clear what Jordi is reporting:

When using window.open and some APIs to navigate the opened document, it is possible to navigate the opened document to a different site, while the location bar doesn't stay in sync with the new location.  In cases where the navigated document winds up on a login form with a relative <form action>, an attacker could steal the submitted form data because it would be presumably sent to the relative location on the attacker's domain.
Comment 7 Jordi Chancel 2011-09-20 23:26:45 PDT
i will try to code a better testcase!
Comment 8 Jordi Chancel 2011-09-21 02:54:51 PDT
http://www.alternativ-testing.fr/Research/Mozilla/possible%20ssl%20tls%20spoof%20with%20saved%20password%20stealing/spoofing.html

Please use this testcase , if it don't works the first time , forward or back manually for show the spoofing !

I think this testcase don't works the first time, so please try and retry for show the spoofing (don't forget back or forward manually if the spoofing don't works directly)
Comment 9 Jordi Chancel 2011-09-21 12:00:17 PDT
@Brandon Sterne : this testcase don't works with you?
Comment 10 Jordi Chancel 2011-09-21 13:31:11 PDT
@Brandon : I've coded a better Testcase ! 
=> http://www.alternativ-testing.fr/Research/Mozilla/possible%20ssl%20tls%20spoof%20with%20saved%20password%20stealing/spoofing.html

+ back or forward manually if it don't work directly !
Comment 11 Brandon Sterne (:bsterne) 2011-09-21 14:24:07 PDT
(In reply to Jordi Chancel from comment #9)
> @Brandon Sterne : this testcase don't works with you?

The first testcase works, so that's why I confirmed this bug.
Comment 12 Jordi Chancel 2011-10-07 17:49:14 PDT
This vulnerability works again on Firefox 7.0.1 !
Comment 13 Johnny Stenback (:jst, jst@mozilla.com) 2011-10-10 17:28:39 PDT
(In reply to Jordi Chancel from comment #8)
> http://www.alternativ-testing.fr/Research/Mozilla/
> possible%20ssl%20tls%20spoof%20with%20saved%20password%20stealing/spoofing.
> html
> 
> Please use this testcase , if it don't works the first time , forward or
> back manually for show the spoofing !

Jordi, the above url is a 404 for me. Did it get removed from the server?
Comment 14 Jordi Chancel 2011-10-12 14:27:48 PDT
Sorry for the elimination!

http://www.alternativ-testing.fr/Research/Mozilla/possible%20ssl%20tls%20spoof%20with%20saved%20password%20stealing/spoofing.html

+ back manually if it don't work directly !

I think this testcase don't works the first time, so please try and retry for show the spoofing (don't forget back or forward manually if the spoofing don't works directly)
Comment 15 Jordi Chancel 2011-10-12 14:36:49 PDT
Created attachment 566637 [details]
ScreenShot firefox 7.0.1

http://www.alternativ-testing.fr/Research/Mozilla/possible%20ssl%20tls%20spoof%20with%20saved%20password%20stealing/spoofing.html
 works perfeclty using back manually on Mozilla Firefox 7.0.1 !
Comment 17 Jordi Chancel 2011-10-12 14:51:28 PDT
don't forget back manually!
Comment 18 Jordi Chancel 2011-10-12 23:48:12 PDT
I've coded a better testcase => http://www.alternativ-testing.fr/Research/Mozilla/564fg65gf465gfbh42gpossible%20ssl%20tls%20spoof%20with%20saved%20password%20stealing/spoofing.html   //It works without back manually and can steal the saved password and login!
Comment 19 Jordi Chancel 2011-10-17 11:34:59 PDT
movie of testcase1.1 => http://www.youtube.com/watch?v=PXl-Z5YKiYQ    
but now the spoofing works without back manually !
NEW +> ASSIGNED OR NOT ? :(
Comment 20 Jordi Chancel 2011-10-17 14:52:15 PDT
Created attachment 567588 [details]
TESTCASE2.0 (back automaticaly, can steal saved password)

New better Testcase (v2.0)
Comment 21 Daniel Veditz [:dveditz] 2011-10-17 15:08:34 PDT
Neither Brandon nor I have been able to reproduce this "seemlessly", though a couple of times (out of many, many, more failed attempts) I did get the PoC to work by hitting the forward (not back!) button once I was on the LinkedIn page. At that point the URL changed to www.alternativ-testing.fr but the "Larry" button continued to say LinkedIn (slight difference from the movie). The LinkedIn content was not deleted (including the replayed saved password) and clicking submit did send the password to Jordi's site as shown in the movie.

On the times I've gotten to almost the right state (LinkedIn showing, password replayed, forward button but not back enabled) I can go back to the original window and manually do "a.history.forward()" to bring about the spoof so maybe it's just a timing issue that could be easily solved.

This report is more of a constellation of issues rather than a simple singular bug.

As a "spoof" it's about on par with your typical phishing page (URL bar has the wrong domain), but the fact that Firefox has replayed the password could be convincing. 

Although the form submit relative URL goes to the wrong domain, apparently internally we still think we're on LinkedIn because I cannot access any properties of the document through the window handle held by the original page.

1) Is the bug that the content (or bfcache?) and URL history got out of sync, or that we didn't clear the content when we navigated to www.alternativ-testing.fr? Or that we changed the URL without really navigating at all?

2) There's a Larry-spoofing problem in that we take the current-page's URL rather than a URL from the certificate, leading to showing the remembered secure state (blue larry) with an HTTP insecure domain.

3) If we think the content is from LinkedIn why is the form submitting somewhere else? Are other relative URLs also incorrectly calculated in this state (say some AJAX-y script) or is this problem restricted to <form>s?

4) This is another case where auto-replaying of passwords before there's any indication of intent to use the form gets us into trouble.
Comment 23 Jordi Chancel 2011-10-17 15:31:47 PDT
or one vulnerability with multiple effect!

a simpler and better testcase is possible ! but on my firefox , testcase2.0 works perfectly or half the time!
Comment 24 Daniel Veditz [:dveditz] 2011-10-17 17:51:28 PDT
I have not yet tried testcase2.0, my comments were based on the initial testcase and the one hosted on your site.
Comment 25 Boris Zbarsky [:bz] (still a bit busy) 2011-10-17 20:23:09 PDT
I have no idea about #1 and #3 from comment 21.  That just should not be happening.  Even if the url bar is confused, relative URLs for something like forms should be resolved wrt the document base URI...

Justin, Olli?
Comment 26 Olli Pettay [:smaug] (way behind * queues, especially ni? queue) 2011-10-18 14:38:10 PDT
Just FYI, I've managed to reproduce the problem twice using testcase2.0.

I didn't really debug this yet, but it looked like the linkedin page got different documentURI, which
is why some relative urls in the page didn't link to linkedin.
Comment 27 Jordi Chancel 2011-10-20 09:47:17 PDT
And you can see that <form> of linkedin (e-mail and password) is redirected to my site (https://www.alternativ-testing.fr/secure/login inftead of https://www.linkedin.com/secure/login).
Comment 28 Johnny Stenback (:jst, jst@mozilla.com) 2011-10-21 17:12:30 PDT
Olli, can you own this and investigate further? If not, let me know and we'll see who else might be able to help out here.
Comment 30 Jordi Chancel 2011-11-03 16:05:49 PDT
Created attachment 571822 [details]
ScreenShot4 Firefox 7.0.1 with developer.mozilla.org

The new screenshot of result of the new testcase(using developer.mozilla.org) (so without Linkedin.com, Because Linkedin.com password stealing don't work now because they are a new security in login page )
Comment 31 Jordi Chancel 2011-11-03 16:08:27 PDT
Created attachment 571824 [details]
TestCase3.0 with developer.mozilla.org
Comment 32 Jordi Chancel 2011-11-03 16:18:58 PDT
You can see than the saved password and login of developer.mozilla.org are sent to attacker page . this time i've don't coded a PHP stealer of the password sent because it requiere a .htaccess but i already use a different htaccess on my website base.
Comment 33 Jordi Chancel 2011-11-16 16:07:56 PST
I have cc'd Eddy Bordi because he help me to exploit bug 703111 wich is very similar to this.
Comment 34 Eddy Bordi 2011-11-16 17:33:53 PST
Created attachment 575054 [details]
Basic testcase

I simplified the operation of spoofing, simply click on "Spoof" and after page loading, click on forward.
Comment 35 Jordi Chancel 2011-11-17 09:17:12 PST
*** Bug 703111 has been marked as a duplicate of this bug. ***
Comment 36 Jordi Chancel 2012-03-19 05:06:50 PDT
this vulnerability isn't patched but ihave reported this last year.
can you fix it please? this vulnerability is high!
Comment 37 Al Billings [:abillings] 2012-03-19 14:11:48 PDT
(In reply to Johnny Stenback (:jst, jst@mozilla.com) from comment #28)
> Olli, can you own this and investigate further? If not, let me know and
> we'll see who else might be able to help out here.

This was asked in October of 2011. Can we get an update and make sure someone is looking at this issue?
Comment 38 Justin Lebar (not reading bugmail) 2012-03-20 20:14:29 PDT
This may be the same as bug 737307, which has a working testcase.
Comment 39 Justin Lebar (not reading bugmail) 2012-03-23 10:21:15 PDT
We fixed bug 737307 in trunk.  I've never been able to reproduce this bug, but to those of you who can, it would be great if you could tell us if the issue is now fixed.
Comment 40 Al Billings [:abillings] 2012-03-23 10:24:20 PDT
Mid-air with Justin!

I've verified bug 737307 with a nightly. 

I've verified with the testcase in comment 34 that the behavior in nightly seems to be fixed for this after the fix for bug 737307. The testcase still works in current Aurora but not the nightly.
Comment 41 Jordi Chancel 2012-04-04 06:50:01 PDT
I have multiple working testcase too , please credit me the first , i'm the first to report this bug and demonstrate that it's a high vulnerability (stealing of credential password and login saved into a input ).

So please credit me the first.
Comment 42 Al Billings [:abillings] 2012-04-05 15:34:31 PDT
Jordi, you will get credit.
Comment 43 Lukas Blakk [:lsblakk] use ?needinfo 2012-04-06 14:51:37 PDT
[Triage Comment]
If bug 737307 is fixed on ESR is there something else here to give us a reason to keep tracking this bug for ESR or can we mark this one fixed too?
Comment 44 Justin Lebar (not reading bugmail) 2012-04-06 14:57:58 PDT
(In reply to Lukas Blakk [:lsblakk] from comment #43)
> [Triage Comment]
> If bug 737307 is fixed on ESR is there something else here to give us a
> reason to keep tracking this bug for ESR or can we mark this one fixed too?

We can mark this as fixed for ESR.
Comment 45 Jordi Chancel 2012-04-08 05:47:04 PDT
Yes i wiil get credit , but the first please!
Comment 46 Al Billings [:abillings] 2012-04-09 14:36:27 PDT
(In reply to Jordi Chancel from comment #45)
> Yes i wiil get credit , but the first please!

I'm not sure what you're asking, Jordi. Are you concerned which order names go in on the advisories for the bugs we write?
Comment 47 Jordi Chancel 2012-04-09 21:41:45 PDT
yes i am concerned which order names go in on the advisories for the bugs you write
Comment 48 Al Billings [:abillings] 2012-04-10 11:27:06 PDT
(In reply to Jordi Chancel from comment #47)
> yes i am concerned which order names go in on the advisories for the bugs
> you write

All right, Jordi. From our point of view, the order isn't important and we don't specifically put one name before another as a way of indicating which bug reporter is more important.
Comment 49 Al Billings [:abillings] 2012-04-10 11:27:38 PDT
If you have more questions, Jordi, let's discuss this in email and not the bug.
Comment 50 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-04-16 12:04:28 PDT
Using the testcase in comment 34, I confirm this behaviour is fixed for Firefox 10.0.4esr.
10.0.3esr exhibits the bug, 2012-04-16 esr10 does not.
Comment 51 Al Billings [:abillings] 2012-04-16 14:16:15 PDT
Verified in nightly (Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120416 Firefox/14.0a1).
Comment 52 Jordi Chancel 2012-04-27 09:59:45 PDT
it's the Bug 700080 witch was fixed on the last update ... not this bug ? BUT http://www.mozilla.org/security/announce/2012/mfsa2012-27.html SHOW THIS BUG on the bugs list.
an error of you?
Comment 54 Raymond Forbes[:rforbes] 2013-07-19 18:23:52 PDT
rforbes-bugspam-for-setting-that-bounty-flag-20130719

Note You need to log in before you can comment on or make changes to this bug.