bugtraq - Re: Google Chrome: HTTP AUTH Dialog Spoofing through Realm Manipulation (Restated)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Mon, 23 Aug 2010 20:45:31 -0400
From: Aditya K Sood <0kn0ck@...niche.org>
To: Tim <tim-security@...tinelchicken.org>
Cc: bugtraq@...urityfocus.com, websecurity@...appsec.org
Subject: Re: Google Chrome: HTTP AUTH Dialog Spoofing through Realm Manipulation
 (Restated)

Hi Tim

You can have a look at the screenshot at below mentioned link

http://www.secniche.org/goog_chr_auth_spoof.jpg

Kind Regards
Aditya


Tim wrote:
> Aditya,
>
>   
>> First of all, the dialog spoofing issue still works in Google Chrome and
>> it has not been patched. 
>>     
>
> I'm not surprised.  There didn't seem to be a lot of interest in these
> issues from any browser vendor when I brought them to their attention.
>
>   
>> A lot of tests have been
>> conducted considering different variants spoofing. I missed your paper
>> previously. I must say its a very good read. 
>>     
>
> Not a problem; the paper only addressed this topic tangentially.  I
> only brought it up because I wasn't sure how things had changed since
> I last tested and thought you could enlighten me.
>
>   
>> Further, it has been mentioned several times that it is a legitimate
>> attack point used by phishers. For example:
>>
>> http://code.google.com/p/browsersec/wiki/Part3#HTTP_authentication
>>     
>
> Yup, the attack scenario I described came straight from the BSH,
> though I didn't mess around with the password-in-URL stuff.
>
>   
>> Even this issue is not patched. May be URL protection like Mozilla is a
>> good practice.
>>
>> Further, Mozilla has worked pretty fine after the dialog spoofing
>> vulnerability disclosed by Aviv Raff on below mentioned
>> link
>> :http://aviv.raffon.net/2008/01/02/YetAnotherDialogSpoofingFirefoxBasicAuthentication.aspx
>>     
>
> Ah, nice, I didn't see this one when I was last testing this stuff.
>
>   
>> We have used a well defined PHP script in this demo combining with a URL
>> obfuscation issue. Since spoofing aims at
>> manipulating the security features in user interfaces, it requires a new
>> model dialog for HTTP authentication that should disseminate
>> the realm value from domain name. Restricting, the string length of
>> Realm value could be a good lead here.
>>     
>
> More usefully, the realm should be clearly separated from the domain
> and labeled in the dialog like Opera does it.  See the screenshot of
> that in my paper.  There could still be some confusion, but it's
> clearly much better than trying to embed potentially malicious strings
> within the same sentences as more carefully validated ones (the
> domain).
>
>
> So, once again, could you send the realm string/auth header you were
> setting in that demo?
>
> thanks,
> tim
>
>
>