Thanks for your report!

I can't quite tell what you mean with "establish a transparent authenticating proxy", and an internet search isn't turning up anything that would make an external proxy show up the prompt fro your fist screenshot. Could you provide more details?

Not sure how to repro this, but from the screenshots it looks like we might be showing the wrong origin in the auth dialog. Adding Http Auth label since the UI code is shared between HTTP auth and Proxy auth.

davidben: Any thoughts?

+asanka for auth stuff.

Could you send us a net-internals log? https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details explains how to do so.

I'd like to understand what the transparent proxy does a bit better.

To the reporter: could you please send a net-internals log as requested in #5? It would help us debug the issue. Thanks.

lgarron: Presumably, WPAD hijacking would be sufficient for this vector.

cbentzel@, I see that you've worked on some net auth bugs before. Could you PTAL at this one, or help us re-assign?

#11: I was thrown off a bit by the mention of a transparent proxy. We shouldn't be prompting for proxy auth challenges coming from a transparent proxy since the browser should be treating the request as having been sent via DIRECT.

I'm guessing that's not what's going on here.

cbentzel: Uh oh! This issue still open and hasn't been updated in the last 17 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I think the issue here from screenshot (need to confirm) is that there is explicit proxy auth going on (407) but the origin of the site trying to be accessed is displayed rather than the name of the proxy. 

The screenshot shows "The proxy https://www.google.com requires a username and password."

Looking at LoginPrompt it appears this happens.

A couple things:

1) Yes, it is showing the wrong origin for the proxy but see #3.
2) This attack vector works whether a user is using an authentication proxy or not.  In other words, as long as they have an autoproxy or proxy config, even if they are using a non-authenticating proxy, an attacker can intercept the HTTP response to the CONNECT and to prompt them for credentials.
3) Even if you show the correct origin, through exploitation of autoproxy configurations the attacker can simply setup the proxy as the name of the site being targeted and do a forced DNS on the network (ergo., evil WiFi vector).
4) 407 is always subject to downgrade.  It supports NTLM & Kerberos, but can be easily downgraded to basic-realm, not to mention NTLM doesn't buy much these days anyway, so that dialog must tell the user that their credentials are not safe.
5) To point #4, many users have no idea what a proxy is because they are using a host configured by their library, their government agency, or their company, therefore I believe that even asking for proxy credentials in this manner is a dubious proposition.  Therefore it would seem this needs some pushing to the OS platform unless you are going to do your own proxy implementation like the Mozilla team.  On this note, Microsoft doesn't appear to support the entry and storage of proxy authentication credentials at the OS level.  I've notified them of this bug and I would hope they are considering implementing something here.
6) This is now being tracked by CERT as VU#905344 aka., FalseCONNECT and the  Opera folks have been pointed your way as they are impacted and using Chromium. 

In addition to the items covered previously, just to make sure everyone is on the same page:

7) The context of the authentication ask is within HTTPS.
8) This was trivial to exploit without DNS or WPAD tricks although WPAD is effective for those using autoproxy settings to get them to the point this vector works.  The UI misidentifies the ask within a trusted realm.
9) The result is that if the user inputs their credentials for what they believe to be a trusted HTTPS connection, they are in fact sent in clear text to an attacker.
10) Several million people are at least impacted.
11) This vector is transparent (ergo silent) for users not utilizing proxies, as such it can be setup in public areas (airports, coffee shops, hotel networks) and only target those.
12) This impacts other projects like Opera.

Please see the latest screenshot of exploitation on OSX.

Deleted: wellsfargo_phishing_osx.png 104 KB

	wellsfargo_phishing_osx.png 104 KB View Download

Could you please send a net-internal log as requested in #5?

In the meantime I'll look into this.

Interesting.  I responded on June 5th with the net-internal log via e-mail.  Here it is again.  It's from one of my older 32-bit machines.

Deleted: net-internals-log.json.txt 785 KB

net-internals-log.json.txt 785 KB View Download

I agree that attributing the authentication prompt to the target server if a 407 is received before the tunnel completion is a bug, and that UI should certainly be fixed.


As a side comment though, unfortunately I don't believe that along will solve the general problem with HTTP auth UI. If a user was fooled by this phishing attempt, they may just as easily be fooled by the modified string:

   The proxy "http://www.wellsfargo.com" requires a username and password.

Or for that matter simply painting a similar looking dialog on another webpage.

There isn't the ordinary lock icon UI to guide user's understanding here, and auth UI is not generally something users are trained to understand, nor for that matter one easily distinguished as originating from the browser. Proxy auth UI in particular is a disaster in terms of user expectations as it can pop up at completely unexpected times and not as the result of direct user action.

Spot on!

Because this is an authentication ask within a security (HTTPS) realm it will always be a vector for phishing if only minor tweaks are made to the wording.  As such I believe the only way to properly handle this is to direct the user to their proxy settings where they must enter their credentials in the proxy setup.  This may not be so hard for iOS, OSX, Android, and ChromeOS, however, Windows could pose some challenges as the last time I checked it doesn't support the entry of proxy authentication credentials in their proxy setup.  Microsoft has been notified as IE, Edge, and their Windows apps are impacted but have yet to engage in a conversation with me about this vector.

RE comment #23 -- Ah, I see that is your proposal in comment #16. Apologies I had not quite digested that when I first read it :)

I think there is merit to the idea (i.e. basically have the password manager be solely responsible for filling those in), but that is probably a separate discussion to be had.

Cheers.

I'm talking with the Apple folks tomorrow and will be doubling down on the recommendation.  I've notified Microsoft of a bunch of FalseCONNECT related issues in their products and have given them a heads up on what I'd like to see.  Google keeps pointing me to your team.  If we are going to get this tackled, now is the time to lay that foundation.  The idea may not be helpful for this round of patching but certainly is something we need to do a better job at in the future.  The key here is that these dialogs, in the context of an https:// request and lock tend to imply trust.  Without turfing to the system proxy settings I believe the only rational thing to do in the near term is to implement a scull and crossbones approach where you do a red strike-through of the address, remove the lock, and pop a really scary dialog which reads:

"You are being asked to enter your proxy authentication credentials to proceed, if you don't know why this is happening, don't continue.  The credentials you enter here will not be transmitted securely."

For the win, put a shadow of skulls and crossbones as a watermark behind it.

However, in all seriousness.  This is really is the only situation I'm aware of where an authentication dialog like this can be controlled by an attacker through a clear-text vector which has implications within the security context of a request so it really is unprecedented.

I'll address the login prompt behavior regarding proxies which is a bad regression that went undetected since M49.

I think we can mitigate the UI issue somewhat using our login interstitial by overriding the omnibox URL in addition to hardening the login prompt string.

https://codereview.chromium.org/2067933002 for those wondering.

Updating OS labels.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/098c009df7a4ddc5c23d4d3c9dccf5eff1f24c98

commit 098c009df7a4ddc5c23d4d3c9dccf5eff1f24c98
Author: asanka <asanka@chromium.org>
Date: Thu Jun 16 20:18:43 2016

Use correct origin when prompting for proxy authentication.

Since M49, Chrome has been prompting for proxy authentication
credentials using the target origin instead of the origin of the proxy
server. Even if the proxy origin was displayed correctly, a mischievous
network operator could still spoof the proxy server origin. To mitigate
these problems, this CL:

* Fixes the origin used in the proxy authentication login prompt to use
  the origin of the proxy server.

* Indicate if the proxy server connection is insecure.

* Always throw up an interstitial and clear the omnibox when showing a
  proxy auth prompt.

* Use the correct origin when saving proxy authentication credentials.

BUG= 613626 ,  620737 

Review-Url: https://codereview.chromium.org/2067933002
Cr-Commit-Position: refs/heads/master@{#400247}

[modify] https://crrev.com/098c009df7a4ddc5c23d4d3c9dccf5eff1f24c98/chrome/browser/ui/login/login_handler.cc
[modify] https://crrev.com/098c009df7a4ddc5c23d4d3c9dccf5eff1f24c98/chrome/browser/ui/login/login_handler.h
[modify] https://crrev.com/098c009df7a4ddc5c23d4d3c9dccf5eff1f24c98/chrome/browser/ui/login/login_handler_unittest.cc
[modify] https://crrev.com/098c009df7a4ddc5c23d4d3c9dccf5eff1f24c98/content/shell/browser/shell_login_dialog.cc
[modify] https://crrev.com/098c009df7a4ddc5c23d4d3c9dccf5eff1f24c98/net/base/auth.cc
[modify] https://crrev.com/098c009df7a4ddc5c23d4d3c9dccf5eff1f24c98/net/base/auth.h
[modify] https://crrev.com/098c009df7a4ddc5c23d4d3c9dccf5eff1f24c98/net/http/http_auth_controller.cc
[modify] https://crrev.com/098c009df7a4ddc5c23d4d3c9dccf5eff1f24c98/net/http/http_network_transaction_unittest.cc
[modify] https://crrev.com/098c009df7a4ddc5c23d4d3c9dccf5eff1f24c98/net/url_request/url_request_ftp_job.cc

Marking as Fixed for now. I didn't make any string changes in #31 due to complications that can arise when we consider this change for merge.

I'll follow up with a change for the strings after any required merges are complete.

Adding Merge-Triage label for tracking purposes.

Once your fix had sufficient bake time (on canary, dev as appropriate), please nominate your fix for merge by adding the Merge-Request-XX label, where XX is the Chrome milestone.

When your merge is approved by the release manager, please start merging with higher milestone label first. Make sure to re-request merge for every milestone in the label list. You can get branch information on omahaproxy.appspot.com.

- Your friendly ClusterFuzz

Please make sure you coordinate with CERT for VU#905344 or myself on the embargo.  A lot of vendors were impacted and public release needs coordinated.

Requesting merge into M52.

See #31 for description of issue and how the fix addresses them. The change has baked on Canary and hasn't caused problems. No string changes are being made for the change that is the subject of the merge request.

Your change meets the bar and is auto-approved for M52 (branch: 2743)

Re-opening for merge.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8c8b7cc66aa395a12b7a25f59d9cd4d1eb71f1a4

commit 8c8b7cc66aa395a12b7a25f59d9cd4d1eb71f1a4
Author: Asanka Herath <asanka@chromium.org>
Date: Mon Jun 20 14:53:42 2016

[Merge M52] Use correct origin when prompting for proxy authentication.

Since M49, Chrome has been prompting for proxy authentication
credentials using the target origin instead of the origin of the proxy
server. Even if the proxy origin was displayed correctly, a mischievous
network operator could still spoof the proxy server origin. To mitigate
these problems, this CL:

* Fixes the origin used in the proxy authentication login prompt to use
  the origin of the proxy server.

* Indicate if the proxy server connection is insecure.

* Always throw up an interstitial and clear the omnibox when showing a
  proxy auth prompt.

* Use the correct origin when saving proxy authentication credentials.

BUG= 613626 ,  620737 

Review-Url: https://codereview.chromium.org/2067933002
Cr-Commit-Position: refs/heads/master@{#400247}
(cherry picked from commit 098c009df7a4ddc5c23d4d3c9dccf5eff1f24c98)

Review URL: https://codereview.chromium.org/2082513003 .

Cr-Commit-Position: refs/branch-heads/2743@{#397}
Cr-Branched-From: 2b3ae3b8090361f8af5a611712fc1a5ab2de53cb-refs/heads/master@{#394939}

[modify] https://crrev.com/8c8b7cc66aa395a12b7a25f59d9cd4d1eb71f1a4/chrome/browser/ui/login/login_handler.cc
[modify] https://crrev.com/8c8b7cc66aa395a12b7a25f59d9cd4d1eb71f1a4/chrome/browser/ui/login/login_handler.h
[modify] https://crrev.com/8c8b7cc66aa395a12b7a25f59d9cd4d1eb71f1a4/chrome/browser/ui/login/login_handler_unittest.cc
[modify] https://crrev.com/8c8b7cc66aa395a12b7a25f59d9cd4d1eb71f1a4/content/shell/browser/shell_login_dialog.cc
[modify] https://crrev.com/8c8b7cc66aa395a12b7a25f59d9cd4d1eb71f1a4/net/base/auth.cc
[modify] https://crrev.com/8c8b7cc66aa395a12b7a25f59d9cd4d1eb71f1a4/net/base/auth.h
[modify] https://crrev.com/8c8b7cc66aa395a12b7a25f59d9cd4d1eb71f1a4/net/http/http_auth_controller.cc
[modify] https://crrev.com/8c8b7cc66aa395a12b7a25f59d9cd4d1eb71f1a4/net/http/http_network_transaction_unittest.cc
[modify] https://crrev.com/8c8b7cc66aa395a12b7a25f59d9cd4d1eb71f1a4/net/url_request/url_request_ftp_job.cc

Let's wait a bit before touching M51.

Congratulations! Our panel has reward $1,000 for this bug.  A member of our finance team will be in touch shortly.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot