The default bug view has changed. See this FAQ.

(CVE-2012-0474) URL & SSL/TLS Spoofing and saved password stealing using multiple history.back() and history.forward()

VERIFIED FIXED in Firefox 12

Status

()

Core
Document Navigation
VERIFIED FIXED
6 years ago
2 years ago

People

(Reporter: Jordi Chancel, Assigned: smaug)

Tracking

Trunk
mozilla14
x86_64
Windows 7
Points:
---
Bug Flags:
sec-bounty +

Firefox Tracking Flags

(firefox11 wontfix, firefox12 fixed, firefox13 fixed, firefox14 fixed, firefox-esr1012+ verified)

Details

(Whiteboard: [sg:high][qa!] fixed by bug 737307, URL)

Attachments

(8 attachments, 1 obsolete attachment)

(Reporter)

Description

6 years ago
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)
(Reporter)

Comment 1

6 years ago
Created attachment 561095 [details]
TESTCASE1

Please try and retry this TESTCASE ! (don't works perfectly the first time)
(Reporter)

Updated

6 years ago
Attachment #561095 - Attachment is obsolete: true
(Reporter)

Comment 2

6 years ago
Created attachment 561100 [details]
TESTCASE1.1

Better Testcase!
(Reporter)

Comment 3

6 years ago
If the testcase1.1 don't works the first time , please back or forward manually ( button back or forward).
(Reporter)

Comment 4

6 years ago
Result of testcase1.1 can show the cookie of attacker but the content is linkedin.com . I think we can bypass de cross origin.
(Reporter)

Comment 5

6 years ago
Created attachment 561127 [details]
ScreenShot2 (saved password)

screenshot2 with saved password
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [sg:high]
(Reporter)

Comment 7

6 years ago
i will try to code a better testcase!
(Reporter)

Comment 8

6 years ago
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)
(Reporter)

Comment 9

6 years ago
@Brandon Sterne : this testcase don't works with you?
(Reporter)

Comment 10

6 years ago
@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 !
(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.
Component: General → Document Navigation
Product: Firefox → Core
QA Contact: general → docshell
(Reporter)

Comment 12

6 years ago
This vulnerability works again on Firefox 7.0.1 !
(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?
(Reporter)

Comment 14

6 years ago
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)
(Reporter)

Comment 15

6 years ago
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 !
(Reporter)

Comment 16

6 years ago
New URL of the testcase => http://www.alternativ-testing.fr/Research/Mozilla/564fg65gf465gfbh42gpossible%20ssl%20tls%20spoof%20with%20saved%20password%20stealing/spoofing.html (more sure)
(Reporter)

Updated

6 years ago
(Reporter)

Comment 17

6 years ago
don't forget back manually!
(Reporter)

Comment 18

6 years ago
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!
(Reporter)

Updated

6 years ago
(Reporter)

Updated

6 years ago
Summary: URL & SSL/TLS Spoofing with saved password stealing using multiple history.back() and history.forward() → URL & SSL/TLS Spoofing and saved password stealing using multiple history.back() and history.forward()
(Reporter)

Comment 19

6 years ago
movie of testcase1.1 => http://www.youtube.com/watch?v=PXl-Z5YKiYQ    
but now the spoofing works without back manually !
NEW +> ASSIGNED OR NOT ? :(
Attachment #561100 - Attachment mime type: application/octet-stream → application/java-archive
(Reporter)

Comment 20

6 years ago
Created attachment 567588 [details]
TESTCASE2.0 (back automaticaly, can steal saved password)

New better Testcase (v2.0)
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.
(Reporter)

Comment 23

6 years ago
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!
I have not yet tried testcase2.0, my comments were based on the initial testcase and the one hosted on your site.
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?
(Assignee)

Updated

6 years ago
Attachment #567588 - Attachment mime type: text/plain → application/x-rar-compressed
(Assignee)

Comment 26

6 years ago
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.
(Reporter)

Comment 27

6 years ago
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).
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.
Assignee: nobody → Olli.Pettay

Updated

6 years ago
Version: 6 Branch → Trunk
(Reporter)

Comment 30

6 years ago
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 )
(Reporter)

Comment 31

6 years ago
Created attachment 571824 [details]
TestCase3.0 with developer.mozilla.org
(Reporter)

Comment 32

6 years ago
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.
(Reporter)

Comment 33

5 years ago
I have cc'd Eddy Bordi because he help me to exploit bug 703111 wich is very similar to this.

Comment 34

5 years ago
Created attachment 575054 [details]
Basic testcase

I simplified the operation of spoofing, simply click on "Spoof" and after page loading, click on forward.
(Reporter)

Updated

5 years ago
Duplicate of this bug: 703111
(Reporter)

Updated

5 years ago
(Reporter)

Updated

5 years ago
(Reporter)

Updated

5 years ago
(Reporter)

Comment 36

5 years ago
this vulnerability isn't patched but ihave reported this last year.
can you fix it please? this vulnerability is high!
(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?
This may be the same as bug 737307, which has a working testcase.
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.
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.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
status-firefox-esr10: --- → affected
tracking-firefox-esr10: --- → 12+
Depends on: 737307
Whiteboard: [sg:high] → [sg:high] fixed by bug 737307
(Reporter)

Comment 41

5 years ago
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.
Jordi, you will get credit.
[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?
(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.
status-firefox-esr10: affected → fixed
(Reporter)

Comment 45

5 years ago
Yes i wiil get credit , but the first please!
(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?
(Reporter)

Comment 47

5 years ago
yes i am concerned which order names go in on the advisories for the bugs you write
(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.
If you have more questions, Jordi, let's discuss this in email and not the bug.
Whiteboard: [sg:high] fixed by bug 737307 → [sg:high][qa+] fixed by bug 737307
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.
status-firefox-esr10: fixed → verified
Whiteboard: [sg:high][qa+] fixed by bug 737307 → [sg:high][qa!] fixed by bug 737307
Verified in nightly (Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120416 Firefox/14.0a1).
Status: RESOLVED → VERIFIED
status-firefox11: --- → wontfix
status-firefox12: --- → fixed
status-firefox13: --- → fixed
status-firefox14: --- → fixed
Target Milestone: --- → mozilla14
(Reporter)

Comment 52

5 years ago
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?
Group: core-security
(Reporter)

Comment 53

5 years ago
http://www.alternativ-testing.fr/blog/index.php?post/2011/Mozilla-Firefox-URL-SSL/TLS-Bar-Spoofing-with-form-input-stealing
rforbes-bugspam-for-setting-that-bounty-flag-20130719
Flags: sec-bounty+
(Reporter)

Updated

2 years ago
Summary: 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 multiple history.back() and history.forward()
(Reporter)

Updated

2 years ago
Summary: 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 multiple history.back() and history.forward()
(Reporter)

Updated

2 years ago
Alias: (CVE-2012-0474)
(Reporter)

Updated

2 years ago
Alias: (CVE-2012-0474)
Summary: (CVE-2012-0474) URL & SSL/TLS Spoofing and saved password stealing using multiple history.back() and history.forward() → URL & SSL/TLS Spoofing and saved password stealing using multiple history.back() and history.forward()
(Reporter)

Updated

2 years ago
Summary: 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 multiple history.back() and history.forward()
You need to log in before you can comment on or make changes to this bug.