New issue
Advanced search Search tips
Starred by 3 users

Issue metadata

Status: Fixed
Closed: Feb 2013
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug-Security

Sign in to add a comment

Issue 174129: Security: Silent HTTP Basic Authentification & HTTP Authentification Brute Force

Reported by, Feb 4 2013

Issue description

This template is ONLY for reporting security bugs. Please use a different
template for other types of bug reports.

Please see the following link for instructions on filing security bugs:

The latest version of Google Chrome (Tested on Version 24.0.1312.57) fails to properly recognize HTTP Basic Authentication when injected in various HTML tags. As a result of this behavior Chrome will not alert the user when HTTP Basic Authentication is taking place or when credentials are rejected. This behavior is particularly concerning with respect to small office and home routers. Such devices are easily brute forced using this method. Many of these devices have the default password enabled which brings me to part II of this bug. Silent HTTP Authentication allows the attacker to log into the router and change settings with no alerts and or warnings issued by Chrome. The end result allows an attacker to brute force the router login, connect to the router, enable remote administration and of course control all information on the entire network via DNS attacks etc.
Chrome Version: [24.0.1312.57]
Operating System: [Tested on: Windows 7 & Mac OSX Mountain Lion]

I have attached the following files:

sploit.txt - Indicates the buggy code.
jquery.js - Used for real world scenario but not needed for bug.
brute.js - Real world attack scenario for this bug.
index.html - HTML Attack Page
attack.php - Payload file for Linksys Routers.

The impact for this bug is enormous. Tens of millions of home routers can easily be completely compromised. Distributed brute force attacks can be performed on any HTTP Authentication portal.

Reference how Firefox and Safari handle the attached code.
35.1 KB Download

Comment 1 by, Feb 4 2013

Labels: -Pri-0 -Area-Undefined Pri-3 Area-Internals Internals-Network-Auth OS-All Mstone-24 SecImpacts-Stable SecImpacts-Beta SecSeverity-Low
Status: Assigned
Oops this must have regressed. This was originally fixed in 

Comment 2 by, Feb 4 2013

This duplicates  which was fixed at one time, but appears to have been reverted in , without re-opening the underlying bug.

Since I can't apply the change to remove IDENT_SRC_URL due to the noise in 123150, the best thing to do is to revert the cross-origin supression by flipping the switch, with a note to re-enabling it at such time as 123150 no longer matters.

Comment 3 by, Feb 4 2013

I'm unable to see  

Can you provide access or the details so I can compare it with my findings?

Comment 4 by, Feb 4 2013


Comment 5 by, Feb 4 2013


Comment 6 by, Feb 6 2013

I plan on releasing this bug to several blogs. Is there a time-frame you'd prefer for the release?

Comment 7 by, Feb 6 2013

@t3553r - we'd prefer if you wait until a fix has been released.  The patch is in-progress as we speak.

Comment 8 by, Feb 6 2013

Do I qualify for a bug bounty? 
I'd imagine this could compromise a huge number of networks browsing on chrome which I consider pretty severe.

Comment 9 by, Feb 6 2013

You'd need to have a router that is vulnerable to CSRF as well, right? If so, you could just do the same things during the times the browser happens to be signed into the router. So there is a flaw in the router, too (though we absolutely want to make this safe for chrome users).

Comment 10 by, Feb 6 2013

@t3553r: I think you'll find this general area has already been blogged about by multiple people in the security community, unfortunately. You should make sure to locate and cite prior work otherwise you may come across poorly.

Also, the core bugs are elsewhere:
- A poor password (bad bad!)
- A router with no good login defenses (e.g. login attempt delay / backoffs)
- A router that has chosen to implement a login scheme that is vulnerable to "login XSRF"

That said, we have a history of defending again other vendor's problems in Chrome code, so I'm sure we can consider making a few tweaks to help in the interim whilst router vendors get their act together.

Comment 11 by, Feb 6 2013

I'm still not clear on whether or not I will be receiving a bounty for this discovery?

I certainly agree with your bullet points. There is definitely a huge laundry list of vulnerabilities that the vendors of small and home office routers need to address. However they have had 10+ years to address these design flaws and have yet to improve security to an acceptable level. These devices are an easy target which combined with an attack vector like the one I wrote results in the potential for widespread network compromise. 

While I do agree that the current security levels of these devices is a joke that doesn't change the fact that Chrome is enabling 100's of passwords to be attempted silently with no knowledge by the user. I agree that most of the blame should fall on the vendors of these routers but Chromes defenses in this case are well below the rest of the modern browsers. I'm not sure why it would ever be a good idea to allow HTTP Basic Authentication to take place without the consent of the user.

If you try this in any Safari, IE or Firefox it will either fail or warn you each time your password is invalid. On Safari they actually post a phishing warning if you attempt to use silent HTTP authentication at all.

At the end of the day if you uploaded this to a website that gets substantial traffic and targeted only Chrome users the success rate would be frightening!

Comment 12 by, Feb 6 2013

I'd also note that HTTP basic auth, is increasingly rare, and use of the protocol at all is widely considered a vulnerability due to: no log-out support, retention/passage of clear credentials, and no transport security requirement.

Comment 13 by, Feb 6 2013

Yeah it should really be phased out all together. I haven't found a single home or small office router that doesn't rely on it :/

Comment 14 by, Feb 6 2013

Interesting, I'm now curious to check my own routers when I get home :-)

Comment 15 by, Feb 6 2013

Please let me know, I'd love some more data! What brand do you have? (Linksys is by far the easiest as you can see by the attached payload. Netgear requires a bit more tricks but it's also quite easy ;)

Comment 16 Deleted

Comment 17 by, Feb 6 2013

Also as requested above please let me know if this qualifies for a bug bounty..I'm not sure who to contact about this...

Comment 18 by, Feb 7 2013

Project Member
The following revision refers to this bug:

r181113 | | 2013-02-07T00:32:37.116970Z

Changed paths:

Revert cross-origin auth prompt blocking.
BUG= 174129 

Review URL:

Comment 19 by, Feb 7 2013

Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Status: Fixed

Comment 20 by, Feb 7 2013

Is there a cve for this? Also please see my unanswered questions above

Comment 21 by, Feb 7 2013

No CVE.  You'll be contacted if this is deemed eligible.  Nothing further need be done.

Comment 22 by, Feb 8 2013

Is there someone in particular I can speak to regrading a bug bounty? I'm not sure how this could be considered so insignificant when a patch was issued to prevent it.

Comment 23 by, Feb 12 2013

Labels: -Mstone-24 Mstone-26 Release-0
@t3553r: hey! I'll try to conclude this bug.

I did check my two routers and:
- One had an HTML login UI that does not use basic auth.
- The other (I think it might be OpenWRT based?) does pop up a basic auth prompt.

In terms of the bug bounty, this report doesn't quite clear the bar for bounty. There are a couple reasons:

1) You are not the first to note this.
I believe the first discussions of this were with the Whitehat Security guys. I think one of them may have even publicly presented it. Phil Purviance IIRC.

2) The severity rating is "low".
We don't usually reward for "low" severity issues, and this is "low" severity for a number of mitigating factors:
a) It relies on a weak password, which is a fundamentally broken setup.
b) Brute-forcing is limited a little by network requests. i.e. it's not an offline attack against the password.
c) Even if the login is successful, the same-origin policy prevents reads of data from the router.
d) Even if the login is successful, the router needs to have an XSRF vulnerability in order for writes of data to work.
e) Routers are moving away from HTTP basic auth.
f) Any password brute-force is fairly noisy.
g) Any password brute-force is typically terminated when the bad page is closed or navigated.

Even though there are mitigations that make this issue lower severity, we still do issue patches for lower severity issues.

And it gets even more interesting: it's not even clear what the right thing to do here is. This change is essentially reverting an earlier change we made to prevent HTTP basic auth dialogs from popping up for third-party resource loads. This is a borderline phishing risk in certain interesting situations.

Thanks for your help. Since it's still not clear what the longer term solution to fix both problems is, we'll likely make further code changes in the future. If you had any thoughts on an approach which fixes all of these basic auth issues, I'd be interested to discuss it.

In terms of credit, we'd be happy to credit you by name in a future release notes, if you provide a credit line.

Comment 24 by, Mar 10 2013

Project Member
Labels: -Type-Security -Area-Internals -Internals-Network-Auth -Mstone-26 -SecImpacts-Stable -SecImpacts-Beta -SecSeverity-Low Security-Severity-Low M-26 Security-Impact-Stable Cr-Internals-Network-Auth Security-Impact-Beta Cr-Internals Type-Bug-Security

Comment 25 by, Mar 21 2013

Project Member
Labels: -Security-Severity-Low Security_Severity-Low

Comment 26 by, Mar 21 2013

Project Member
Labels: -Security-Impact-Stable Security_Impact-Stable

Comment 27 by, Mar 21 2013

Project Member
Labels: -Security-Impact-Beta Security_Impact-Beta

Comment 28 by, Mar 23 2013

Labels: CVE-2013-0922

Comment 29 by, May 15 2013

Labels: -Restrict-View-SecurityNotify

Comment 30 by, Jun 12 2013

 Issue 248818  has been merged into this issue.

Comment 31 by, Jun 12 2013

 Issue 248818  has been merged into this issue.

Comment 32 by, Feb 16 2016

 Issue 586965  has been merged into this issue.

Comment 33 by, Jun 14 2016

Project Member
Labels: -security_impact-beta

Comment 34 by, Oct 1 2016

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

For more details visit - Your friendly Sheriffbot

Comment 35 by, Oct 2 2016

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

For more details visit - Your friendly Sheriffbot

Comment 36 by, Oct 2 2016

Labels: allpublic

Comment 37 by, Apr 25 2018

Labels: CVE_description-submitted

Sign in to add a comment