Insecure Privoxy Configuration in Vidalia Bundles Prior to 0.1.2.18
Summary
Versions of the Vidalia bundle prior to 0.1.2.18 install Privoxy with an insecure configuration file. In combination with web browser vulnerabilities, these configuration values could be used to bypass the Privoxy filtering or cause Privoxy to block or redirect user requests. Both Windows and Mac OS X versions are affected.
Disclaimer
Some of the demonstrations linked from this page attempt to modify your Privoxy configuration in malicious ways. Backing up the 'user.action' configuration file is recommended before running any of these demonstrations.
All of the demonstrations and attacks were tested using Mozilla Firefox 2.0.0.9. On Windows, the Sun Java Runtime Environment (JRE) 1.6u2 was used. Mac OS X testing was performed using the latest version of Apple's Mac OS Runtime for Java (MRJ) 10.4 release 5.
The use of vulnerable software versions is meant to illustrate the types of attacks that can be performed. Simply because (most of) the flaws present have been patched does not mean that there aren't other potential vulnerabilities which could be exploited to achieve similar results.
Description
The Vidalia Project provides a cross-platform GUI controller for Tor. The Tor Project provides package downloads that bundle Tor, Privoxy and Vidalia. In versions of the bundle prior to 0.1.2.18, an insecure default Privoxy configuration file was included.
The installed 'config.txt' file ('config' on Mac OS X) had the following option values set to 1:
- enable-remote-toggle
- enable-edit-actions
Additionally, on Windows the following option was set to 1:
- enable-remote-http-toggle
Malicious sites (or malicious exit nodes) could include active content (e.g., JavaScript, Java, Flash) that caused the web browser to:
make requests through the proxy that causes Privoxy filtering to be bypassed or completely disabled
establish a direct connection from the web browser to the local proxy and modify the user defined configuration values
The Privoxy documentation recommends against enabling these options in multi-user environments or when dealing with untrustworthy clients. However, the documentation does not mention that client-side web-browser vulnerabilities could be exploited as well.
It should be noted that using Tor is not a prerequisite for some of these attacks to be successful. Users of Tor may be at greater risk, because malicious exit nodes can inject content into otherwise trusted sites.
Option: enable-remote-http-toggle
The enable-remote-http-toggle option allows web clients to include a special header that disables any Privoxy content filtering of the client request. If Privoxy determines that the header "X-Filter: No" has been included in the web request, all content level filtering is disabled for that specific request. Such filtering includes the ability for Privoxy to prevent pop-up windows, disable content re-directions and prevent cookies from being set through meta tags.
Normally, a web browser is unable to set specific headers. However, active content typically provides mechanisms to set headers on a per request basis:
- JavaScript: setRequestHeader() for XMLHttpRequest
- Flash: addRequestHeader() for LoadVars
- Java: setRequestProperty() for URLConnection
For example, a simple XMLHttpRequest could appear as:
var xhr = new XMLHttpRequest();
xhr.open("GET", "http://example.com/whatever", false);
xhr.setRequestHeader("X-Filter", "No");
xhr.send(null);
document.write(xhr.responseText);
The following demonstrations have been constructed to show how the 'X-Filter' header can bypass content filtering. These demonstrations attempt to bypass the following filter actions: content-cookies, refresh-tags, all-popups. If these actions are not enabled in Privoxy, the demonstrations will not appear to do anything special.
- JavaScript demonstration: makes identical XMLHttpRequest requests except one includes the 'X-Filter: No' header.
- Flash demonstration: makes request using LoadVars with 'X-Filter: No' with a target iframe.
Option: enable-remote-toggle
The enable-remote-toggle option allows the user to either enable or disable Privoxy through her web browser. When using Privoxy as a proxy, navigating to http://config.privoxy.org/toggle opens the toggle page. Privoxy filtering can either be enabled or disabled from this page.
This functionality is described as:
When enabled, Privoxy performs its magic - blocking adverts, filtering cookies, regex-filtering, etc.
When disabled, Privoxy behaves as a normal HTTP proxy, and will not affect your web browsing.
Privoxy is disabled by visiting http://config.privoxy.org/toggle?set=disable and enabled by visiting http://config.privoxy.org/toggle?set=enable. In order to prevent arbitrary web requests from invoking these requests, Privoxy verifies that the HTTP Referer header matches "http://config.privoxy.org/". In theory, this should prevent simple cross-site request forgery (CSRF) attacks.
Unfortunately, web browser vulnerabilities occasionally allow the Referer header to be forged. Vulnerabilities have been found in virtually all facets of active content. In the past, XMLHttpRequests allowed setting the Referer header, Flash movies could forge Referer headers and Flash or Java applets could use DNS-rebinding (or the document.domain bypass) to connect to the localhost and use TCP sockets to construct requests.
The Mozilla Firefox window.location race condition described in MFSA 2007-39 was developed in part to bypass the CSRF protection employed by Privoxy. Because Privoxy accepted GET requests, only checked the Referer header and didn't include any type of token or nonce, a simple request with a forged Referer header is sufficient to disable Privoxy.
Under Firefox 2.0.0.9, the following HTML is generally sufficient to set Privoxy to a disabled state:
<form name="pwn" target="_self" action="http://config.privoxy.org/">
</form>
<script defer="defer" type="text/javascript">
eval("setTimeout")('document.forms["pwn"].submit()', 100);
window["alert"]("wait for it");
window["location"] = "http://config.privoxy.org/toggle?set=disable";
</script>
Here are some additional demonstrations:
- Disable Privoxy - JavaScript: the original JavaScript attack.
- Disable Privoxy - Java/LiveConnect: the attack that set this all in motion. Using a vulnerable version of the Sun Java Runtime Environment, it is possible to connect to the localhost using TCP sockets and construct the appropriate request. Unlike some of the other attacks, this one does not require that user to be using Privoxy; instead, Privoxy only needs to running and listening on port 8118.
Option: enable-edit-actions
The enable-edit-actions option allows a user to configure the content filtering and blocking policy for Privoxy by accessing the configuration interface from the web browser. The configuration can be edited by browsing to http://config.privoxy.org/show-status.
The 'default.action' file defines the basic rules that apply to all requests and is processed first. It can be safely ignored in most cases.
The 'user.action' file is where attacks would be focused. It is processed after the default file and rules defined here take precedence. The default 'user.action' files ships with several sample rules (we'll see later, in some cases, these sample rules can be used to attack the system). Rules are defined by creating Actions and then specifying URL patterns. Later rules take precedence over early rules. A top-level rule can be defined by specifying an URL match of "/".
On the surface, the Privoxy configuration editor is safe from drive-by modification using CSRF. In addition to the checking the Referer header, the configuration editing also employs a file version. The file version value is derived from the modification time of the configuration file. When any requests are submitted, the file version in the request is compared to the current modification time of the file. If a mismatch is detected, the request is rejected. Ostensibly, this is to prevent overlapping edits from corrupting the file, but it actually provides fairly strong CSRF protection. As edits are made, the file version is constantly changing. This makes attacks much more complicated because in addition to forging a Referer header, the file version must be guessed. The following demonstrations present two possible attack approaches.
Demonstrations:
- JavaScript Attack (Windows Only)
Since it is impossible to "guess" the file version, we must cheat. On Windows, all recent Vidalia bundles install the Privoxy 'user.action' file with the same modification time. This means that if the user has never edited any actions, the file version will be the same and can be targeted.
The next issue is that once an edit is made, a new file version is going to be created. To get around this problem, the best approach is to aim for a one-shot attack. Since the existing assumption is that the user has not edited the file, any existing "sample" rules are fair game. There are two good possibilities: the "+block" and the "+block,+handle-as-image". The "+block" rule will block any user request, but it provides an override method. So, we target the "+block,+handle-as-image" rule and create a URL pattern that will match every single request. If the attack is successful, the user will be unable to use Privoxy to access any websites.
Unfortunately, if the user has changed time zones, then there is not a straight-forward method to determine what the file version is (it is not impossible though). Adjustments for Daylight Saving Time (aka Summer Time) will also influence what the calculated file version is. To address these issues, the attack tries with three values: default value, uses one hour before and one hour after.
- Java/LiveConnect Attack
An enabled and vulnerable version of Java/LiveConnect can be used to totally take over the Privoxy configuration. Since TCP sockets can be used, a custom user-agent can be constructed to make requests, read file versions, generate new sections and submit modification requests. Every aspect of the user action configuration can be adjusted and edited.
If this attack is successful, it enables all possible security by-passes and then redirects all web traffic to a single site.
End Notes
Although Vidalia does not have a bundle for Linux, these attacks are equally applicable to many Linux distributions. Any distribution that ships Privoxy with an insecure default configuration file is vulnerable. The Privoxy source distribution is also vulnerable.
Also available is an unfinished Flash with DNS rebinding demonstration. Originally envisioned as an attack against the Incognito CD, work was abandoned after Incognito switched to Polipo. If you want to use the demo, download the code and edit the 'hostname' to point to a hostname that can be used for DNS rebinding or enter one and relaunch the demo. Effective DNS rebinding through the Tor network faces additional challenges due to some of the timing and caching issues. This is an open research question.
Flash Bits
The Flash demos were created using the Open Source SWF Tools collection. Each of the following scripts was compiled using the 'swfc' command.
The source:
- x-filter.sc: source for bypass Privoxy using X-Filter header.
- xmlsocket.sc: source for XMLSocket wrapper in unfinished Privoxy disabling demo.