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]
Message-Id: <201303111440.r2BEeT8s031713@sf01web3.securityfocus.com>
Date: Mon, 11 Mar 2013 14:40:29 GMT
From: contact@....cc
To: bugtraq@...urityfocus.com
Subject: Privoxy Proxy Authentication Credential Exposure - CVE-2013-2503

Privoxy Proxy Authentication Credential Exposure

Product: Privoxy
Project Homepage: privoxy.org
Advisory ID: c22-2013-01
Vulnerable Version(s): 3.0.20 (and possibly prior)
Tested Version: 3.0.20-1 (tested using Debian Sid)
Vendor Notification: March 6, 2013
Public Disclosure: March 11, 2013
Vulnerability Type: Insufficiently Protected Credentials [CWE-522]
CVE Reference: CVE-2013-2503
Risk Level: Medium
CVSSv2 Base Score: 4.3 (AV:N/AC:M/Au:N/C:P/I:N/A:N)
Discovery: Chris John Riley ( http://blog.c22.cc )

Advisory Details:

During research into browser and proxy server handling of HTTP
Response Codes, an issue with the way that Privoxy handles HTTP
Response code 407 "Proxy Authentication Required" was discovered.
Privoxy in versions 3.0.20 (and possibly prior) ignores the presence of
"Proxy-Authenticate" and "Proxy-Authorization" headers and allows these
values to be passed to and from a remote server without modification.
The resulting behavior could allow a malicious websites to spoof a
Proxy-Authentication response appearing to originate from the Privoxy
service. The Privoxy user will then be prompted for a username and
password that appears to originate from the Privoxy software.

Scenario:

1) A Privoxy user visits a website using a browser of their choice
2) The remote website responds to the request with a 407 "Proxy
Authentication Required" HTTP response code and the appropriate
"Proxy-Authenticate: Basic" HTTP response header
3) This response is passed through the Privoxy service without
modification to the users browser
4) As the browser is configured to use a proxy server, the browser
believes that the upstream proxy (Privoxy) has requested
authentication and prompts the user for a username and password. This
prompt states that the proxy server at "127.0.0.1:8118" requires
authentication (this prompt may vary if Privoxy is running on a
machine other than localhost and/or on a non-default port number)
5) If the user enters a username and password, the browser will send
a request through Privoxy to the remote website with a
"Proxy-Authorization: XXXXXXXX" HTTP request header (where XXXXXXX is
a base64 encoded version of the username and password the user
entered at the browsers proxy authentication prompt)
6) The remote website receives this header and can store or re-use
these captured credentials

Proof of Concept:

http://c22.cc/POC/c22-2013-01.php

The above URL will respond with a "Proxy-Authenticate: basic" header
when a request is received that does no contain a
"Proxy-Authorization" header. This will prompt the users browser to
request a username/password from the user. If you enter a value in the
username/password box and click ok, it will send a Base64 encoded
version to the remote website (the server will display the response
headers at the bottom of the resulting page under request headers (one
of the values will be "Proxy-Authorization" with a base64 encoded
version of the entered username/password). For a full walkthrough it
is suggested to capture this in your favourite packet capture program
and walk through the requests to view the entire process.

Note --> The above POC does not store any data sent to the server,
however it is suggested to use bogus credentials if testing this proof of
concept.

Solution:

The following solution was suggested and implemented in Privoxy 3.0.21
stable.

Proxy authentication headers are removed unless the new directive
enable-proxy-authentication-forwarding is used. Forwarding the headers
potentionally allows malicious sites to trick the user into providing
it with login information.

References:
Privoxy 3.0.21 ChangeLog -->
http://ijbswa.cvs.sourceforge.net/viewvc/ijbswa/current/ChangeLog?revision=1.188&view=markup

Vulnerability Timeline:

March 5, 2013 20:00 - Initial discovery of vulnerability
March 6, 2013 14:48 > Emailed Privoxy developer list to request a
security contact
March 6, 2013 15:26 < Received response with dedicated security contact
information
March 6, 2013 16:01 > Emailed details of the vulnerability to security
contact
March 6, 2013 17:19 < Received response acknowledging issue. Fix
indicated in upcoming release
March 6, 2013 18:38 > Acknowledged receipt of email and advised of
updated CVSSv2 score
March 7, 2013 15:50 < Received response detailing proposed fix,
including link to CVS check-in of new code
March 7, 2013 18:48 > Acknowledged receipt of email
March 9, 2013 16:54 > Emailed CVE number to security contact and
requested information on release plans
March 10, 2013 14:28 < Received confirmation of release timeline
March 10, 2013 14:58 - Release of Privoxy 3.0.21 stable
March 11, 2013 07:45 - Release of advisory

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ