The Goal

Whitetrash provides a user-friendly and sysadmin-friendly proxy that makes it significantly harder for malware to use HTTP and SSL for:

• initial compromise;
• data exfiltration; and
• command and control.

Current Status

The last commit made on whitetrash was in October 2010, and I haven't found any spare time to work on it since then. Since I no longer run whitetrash or maintain it, I'm now (May 2014) declaring the project abandoned. The code and website will remain available as is. I have received some email from people interested in forking the project, if that happens I'll post a link here.

Features

The operation of whitetrash is best demonstrated by the flash demo and screenshots.

Whitetrash features:

• Provides whitelisting for HTTP and SSL that is good for both users and sysadmins, but defends against malware and browser exploits, including some classes of 0-days.
• New in 1.0: Integration with the Google Safebrowsing API, so that urls are checked against the Google malware and phishing blacklists. Blacklisted domains cannot be whitelisted by normal users.
• New in 1.0: Improved authentication using the Django web framework. Adding new authentication methods is simple. LDAP support means user passwords and permissions can be centrally managed, with simple integration with Windows domain controllers and OpenLDAP servers.
• New in 1.0: Authentication can be disabled, which when used in conjunction with the CAPTCHA system, provides most of the security benefits without the overhead of user management.
• New in 1.0: A CAPTCHA system has been implemented to prevent malware adding itself to the whitelist. CAPTCHA can be enabled for HTTP, SSL, or both.
• New in 1.0: A Django-based admin interface that allows admins to manage users and whitelist entries.
• New in 1.0: Memcached support to reduce the load on the database and allow for scaling to very large enterprises. Memcached is used by sites such as slashdot, livejournal, and sourceforge.
• New in 1.0: SSL certificate generation. Improvements to the firefox security model have rendered the previous approach to displaying the whitetrash form for SSL requests unusable. Whitetrash now creates its own certificate authority, which is used to display the form for new SSL domains. SSL sessions to whitelisted domains are simply proxied.
• New in 1.0: Learning mode. Whitetrash can be placed in a learning mode where all domains requested are added to the whitelist. Once the list has been reviewed, whitelisting by users can begin with a baseline of popular domains pre-whitelisted.
• New in 1.0: A firefox plugin has been developed, similar in style to the noscript plugin, that gives users the ability to quickly whitelist domains. This is useful for page elements that do not display the whitetrash form, such as images and video provided by content-delivery-network domains.
• Reports are available to all whitetrash users, including:
  • Details of the most popular whitelisted domains
  • Details of the most-requested but not whitelisted domains. These are typically malware, spyware, advertising, and user-tracking domains.
• Fast: no noticeable impact on users browsing urls already in the whitelist, and adding a new URL is very quick.
• Secure: As this is a security product, great care has been taken to ensure that the whitelist cannot be easily circumvented or exploited.
• Users can delete their own whitelist entries (optional). Admins can delete any whitelist entry.

Whitetrash implements a whitelisted web proxy as a Squid plugin.

What Is Whitelisting?

Generally whitelisting is defined as having a default deny policy, and only allowing specific types of objects/packets/requests/strings/accounts - those that are known to be 'good'. Blacklisting is the opposite of this process where all types of objects/packets/requests/strings/accounts etc. are allowed by default, and only specific 'bad' entities on the blacklist are denied.

Whitetrash whitelists web traffic at the domain level, and is a powerful technique to eliminate (or at least make difficult) communications for a lot of malware.

How Does That Help?

Whitelisting is a technique that makes it difficult for malware to use HTTP and SSL.

Consider the following common scenario: malware is delivered to the user in the form of a word processor document attached to an email. The user opens the document, and the malware executes. The malware's next actions are usually to use HTTP to download tools, beacon back to the attacker, or exfiltrate data. With a whitelist in place, all of these actions will be blocked because the attacker's domain is not in the whitelist.

The whitelist also provides good protection against browser exploits, which often employ cross-site scripting or other techniques to present a legitimate looking web-page while downloading content from the attacker's website. The ghost in the browser paper told us malware is almost always downloaded from a different domain to the one visited by the user. With a whitelist in place, the download from the attacker's domain will be blocked.

A sophisticated attacker will often use different domains for exploitation, command/control, and data exfiltration. A whitelist will block all of these additional domains.

Next Release

Work on the next release is underway. On the roadmap:

• Moving to version 2 of Google's safebrowsing API.
• Moving from memcached to Redis.
• Improving the wildcard logic and adding increased flexibility: global settings for wildcarding one, all or 0 domain labels in each domain (e.g. *.sf.net, **.sf.net, or sf.net), or allowing users to choose with a new form element.
• Adding an approvals workflow - a number of users have requested a submission/approval mechanism for new domains.
• Refactoring the squid url rewriter to simplify and improve test coverage.

More Information

See the FAQ or send me an email.

Get The Code