1447087 - Saving web page embedding file: resources allows accessing SMB resources

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect, P3)

Description

[Björn Ruytenberg]

Attachment: poc.zip

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:59.0) Gecko/20100101 Firefox/59.0
Build ID: 20180315233128

Steps to reproduce:

Loading a file: resource is blocked when viewing pages over HTTP/HTTPS. However, when saving the page, any embedded file: resources are accessed. This may expose the user to SMB Relay Attacks, allowing to steal Windows user credentials.

Steps to reproduce:

Some definitions:
  Victim pc: the "victim's pc".
  HTTP server: a remote machine running a webserver.
  SMB server: a remote machine hosting "smbtrap", a Python-based SMB server that steals Windows user credentials.

1. HTTP server: From the attached ZIP, upload poc.html to this machine, so it can be accessed through e.g.
    http://192.168.1.128/poc.html

2. SMB server: Make sure to use Python 2.7.x. Also, install the Tornado 4.4.2 package, e.g. through "pip":
    sudo pip install tornado==4.4.2
    
3. SMB server: Make sure the host machine has the IP address 192.168.1.128 (or change the hardcoded address in poc.html).

4. SMB server: Download "smbtrap2.py" and "quickcrack.py" from
    https://github.com/CylanceSPEAR/SMBTrap/tree/master/smbtrap
and run SMBtrap through
    sudo python smbtrap2.py
    
5. Victim pc: Open Firefox, and navigate to
    http://192.168.1.128/poc.html
    
6. Victim pc: Save the web page to disk (File > Save Page As)

7. Victim pc: Observe that SMBtrap receives the user's username and NTLM password hash.
   See also attached screenshot "smbtrap_output.png" (in the ZIP) for example output.
   
   Note: quickcrack.py contains a small "dictionary" for demonstration purposes. If the victim's password is one of those listed, SMBtrap will be able to derive the actual password from the NTLM hash.


Actual results:

Firefox accesses the file: resource, which is a path to an SMB resource. This may expose the user to SMB Relay attacks.


Expected results:

Firefox should not have accessed the file: resource when the web page is served over HTTP/HTTPS.

Comment 1

[:Gijs (he/him)]

Jonathan, I don't suppose you have cycles to take this? In nsWebBrowserPersist and friends, we need to start doing something else than blindly passing system principal (esp. for subloads).

X-ref bug 1415636 which is due to the same issue (and marked dupeme, but I couldn't quickly find a dupe). Note that this is somewhat different as it doesn't require the user to load the resulting saved document, which probably makes this more severe. I don't know if the remote smb server stuff would apply to every single windows setup, but we should probably assume the worst.

Comment 2

[:Gijs (he/him)]

(In reply to :Gijs from comment #1)
> Jonathan, I don't suppose you have cycles to take this? In
> nsWebBrowserPersist and friends, we need to start doing something else than
> blindly passing system principal (esp. for subloads).

Assuming I'm reading this right, we should have realized this in bug 1099296, but it got missed. :-(

Comment 3

[Björn Ruytenberg]

I just noticed step 2 doesn't list the correct dependencies for SMBtrap. This step should be:

  Use Python 2.7, and install the following SMBtrap dependencies:
  * Bitarray version 0.8.1
  * PyCrypto version 2.6.1
  * Impacket version 0.9.12

  For example, through:
    sudo pip install bitarray==0.8.1
    sudo pip install pycrypto==2.6.1
    sudo pip install impacket==0.9.12

Comment 4

[Björn Ruytenberg]

Can I ask why this is rated as sec-low?

The vulnerability allows disclosure of OS username, NTLM hash and (depending on password strength) the plaintext password as well. Having both credentials may be used as a stepping stone in further attacks (for example, authenticate to the local SMB server and steal arbitrary local files). This seems to meet the requirements for sec-moderate as listed at [1].

[1] https://wiki.mozilla.org/Security_Severity_Ratings#Severity_Ratings

Comment 5

[Alex Gaynor [:Alex_Gaynor]]

Due to the mitigating circumstance of requiring the user to save the webpage to disk, which is a relatively rare user interaction for websites.

Comment 6

[Björn Ruytenberg]

I see. My understanding though is that sec-low is intended for leaks of non-sensitive information, which to me does not sound like the proper classification. On the other hand, sec-moderate does appear to cover unusual user interaction:

  "Client bugs that might have high or critical results but require the user to perform unusual or complex actions to trigger."

Comment 7

[Jonathan Kingston [:jkt] he/him]

I'm not sure who will be working on this but I know you were looking into fixing this lately.

Comment 8

[:Gijs (he/him)]

I haven't retested but I would expect the poc as described in comment #0 not to work anymore after bug 1469916 (fixed in Firefox 63 and later). Did you check?

Comment 9

[Jonathan Kingston [:jkt] he/him]

I didn't test the POC no sorry. However :ckerschb is looking into isolating file directories further which should hopefully fix this also.

Comment 10

[:Gijs (he/him)]

Reporter, can you still reproduce this on Firefox 63 (released this week) ?

I'm not in a position to set up the testcase myself (no smb infrastructure), but I'm fairly sure we fixed the issue of file: access directly when an http: page is saved.

Comment 11

[Björn Ruytenberg]

(In reply to :Gijs (he/him) from comment #10)
> Reporter, can you still reproduce this on Firefox 63 (released this week) ?
> 
> I'm not in a position to set up the testcase myself (no smb infrastructure),
> but I'm fairly sure we fixed the issue of file: access directly when an
> http: page is saved.

I can confirm this issue is fixed. Tested on Windows 10 (1809) and Windows 8.1 on
  Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0

Comment 12

[:Gijs (he/him)]

(In reply to Björn Ruytenberg from comment #11)
> (In reply to :Gijs (he/him) from comment #10)
> > Reporter, can you still reproduce this on Firefox 63 (released this week) ?
> > 
> > I'm not in a position to set up the testcase myself (no smb infrastructure),
> > but I'm fairly sure we fixed the issue of file: access directly when an
> > http: page is saved.
> 
> I can confirm this issue is fixed. Tested on Windows 10 (1809) and Windows
> 8.1 on
>   Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0) Gecko/20100101
> Firefox/63.0

Thank you!

Comment 13

[Björn Ruytenberg]

Now that this bug has been fixed, would it be possible to re-assess the severity rating?

My apologies for repeating, but for completeness sake, please allow me to summarize:

* Bug type:
This bug allows information disclosure and can be easily used as a stepping stone for RCE:
  - Attackers can immediately obtain the victim's Windows username and NTLM hash.
  - Finding a pre-image (the Windows user password) for NTLM hashes is a matter of minutes with various NTLM lookup services available online (e.g. [1][2][3]). Alternatively, one can use hashcat to bruteforce it fairly quickly (especially when using GPGPU acceleration) [4].

* Impact:
Having both the Windows username and password may be used as a stepping stone in further attacks. For example, authenticate to the local SMB server and steal arbitrary local files, or run arbitrary code (RCE).

* User interaction:
IMHO saving a webpage is quite a common use case, but it's understandable to have different views on this. Nevertheless, 'sec-moderate' allows for unusual user interaction as indicated in [5]:
  "Client bugs that might have high or critical results but require the user perform unusual or complex actions to trigger."


Comparing the above description against the requirements for 'sec-moderate' leads me to believe this is the appropriate severity rating. If I'm mistaken, I would highly appreciate your feedback on this. Thanks.


[1] https://hashkiller.co.uk/ntlm-decrypter.aspx
[2] https://crackstation.net/
[3] https://www.onlinehashcrack.com/hash-cracking.php
[4] https://hashcat.net/hashcat/
[5] https://wiki.mozilla.org/Security_Severity_Ratings#Severity_Ratings

Comment 14

[Daniel Veditz [:dveditz]]

This was probably fixed by bug 1469916. Pretty much bug 332676 which is also sec-moderate -- need to check whether the more generic one is fixed, too.

Comment 15

[:Gijs (he/him)]

(In reply to Daniel Veditz [:dveditz] from comment #14)
> This was probably fixed by bug 1469916. Pretty much bug 332676 which is also
> sec-moderate -- need to check whether the more generic one is fixed, too.

Unfortunately it won't be, bug 332676 is about what happens if the victim actually opens the saved file. The point of this bug is that you don't even need to open the saved file, the access happens immediately as soon as you save the attacker's document. That is now fixed.

Comment 16

[Björn Ruytenberg]

(In reply to Daniel Veditz [:dveditz] from comment #14)
> This was probably fixed by bug 1469916. Pretty much bug 332676 which is also
> sec-moderate -- need to check whether the more generic one is fixed, too.

Thank you!

Comment 17

[Björn Ruytenberg]

Seeing as this bug has been fixed in Firefox 63.0, when would you expect the CVE ID to be published?

Comment 18

[Al Billings [:abillings - ex-MoCo]]

(In reply to Björn Ruytenberg from comment #17)
> Seeing as this bug has been fixed in Firefox 63.0, when would you expect the
> CVE ID to be published?

If this was fixed by by bug 1469916, then it is CVE-2018-12402.

Comment 19

[Al Billings [:abillings - ex-MoCo]]

...and CVE-2018-12402 was published in the Firefox 63 security advisories.

Comment 20

[Daniel Veditz [:dveditz]]

gk: you're going to want to take the patch for this for the Tor Browser. We have not yet fixed it on ESR because it was originally fixed as a less severe "SameSite cookie" issue.

Comment 21

[:Gijs (he/him)]

(In reply to Daniel Veditz [:dveditz] from comment #20)
> gk: you're going to want to take the patch for this for the Tor Browser. We
> have not yet fixed it on ESR because it was originally fixed as a less
> severe "SameSite cookie" issue.

Note that you then want to take a few different patches to avoid some crashes + regressions, see bug 1469916 comment 36 -- and probably the fix for bug 1504159 on top of that, too.

Comment 22

[Georg Koppen]

(In reply to Daniel Veditz [:dveditz] from comment #20)
> gk: you're going to want to take the patch for this for the Tor Browser. We
> have not yet fixed it on ESR because it was originally fixed as a less
> severe "SameSite cookie" issue.

Thanks. I'll look over it and the patches Gijs points to when preparing the next release. We'll probably want to test that in an alpha release first, though, given that there has been quite some fallout after the first fix.

Comment 23

[Julien Cristau [:jcristau] (back April 22)]

Talking to Dan and Gijs it sounds like this isn't serious enough for us to backport to esr60 given the risk. And Tor already know about this so they can choose to carry the needed patches.