Dear Team,
Sorry for multiple emails, I failed to send to tor-dev@ properly. Here is an attempt, a first attempt at the "Cute" project. Please let me have your comments and suggestions.
https://trac.torproject.org/projects/tor/wiki/org/sponsors/Otter/Cute
All the best, SiNA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
"Cute" design and challenges - draft 0.1 By: SiNA Rabbani - sina redteam io
*Overview*
Project Cute is part of the Otter contract. This project is to provide (in the parlance of our time) "point-click-publish" hidden services to support more effective documenting and analysis of information and evidence documenting of ongoing human rights violations and corresponding training and advocacy Our goal is to improve hidden services so that they're more awesome, and to create a packaged hidden-service blogging platform which is easy for users to run.
*Objective*
To make secure publishing available to activists who are not IT professionals.
*Activities*
Tor offers Hidden Services, the ability to host web sites in the Tor Network. Deploying hidden services successfully requires the ability to configure a server securely. Mistakes in setup can be used to unmask site admins and the location of the server. Automating this process will reduce user error. We have to write "point-click-publish" plugins that work with existing blogging and micro-blogging software.
*Expected results*
The result will be a way to provide portals to submit text, pictures, and video. These sites will not have the ability to log information that can be used to track down citizen journalists or other users, and will be resistant to distributed denial of service (DDoS) attacks.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
*Introduction*
This document describes the technical risks associated with running a web-based blog tool and exposing it over a hidden service (.onion address). Our goal is to create a packaged blogging platform that is easy to operate for the non-technical user, while protecting the application from a set of known attacks that can reveal and compromise the network identity.
Hidden-services make it possible for content providers and citizen journalists to offer web-applications such as blogs and websites, hosted completely behind a firewall (NAT Network) never revealing the public IP of such services. By design, Hidden Services are resilient to attacks such as traffic analysis and DDoS, therefore it becomes compelling for the adversary to focus on the application layer vulnerabilities.
According to OWASP Top 10, Injection is the number one security risk for web applications. "Injection flaws, such as SQL, OS, and LDAP injection occur when untrusted data is sent to an interpreter as part of a command or query. The attacker?s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization." [1]
Running a site such as WordPress involves a LAMP (Linux, Apache, Mysql, PHP) installation. This stack needs to be carefully configured and implemented to meet the desired privacy and security requirements. However, default configuration files are not suitable for privacy and lead to the leakage of identity.
WordPress is the most popular blog platform on the Internet. We select WordPress due to it's popular and active core development. WordPress features a plug-in architecture and a template system, "Plugins can extend WordPress to do almost anything you can imagine. In the directory you can find, download, rate, and comment on all the best plugins the WordPress community has to offer." http://wordpress.org/plugins/
Themes and plugins are mostly developed by programmers with little or no security in mind. New code is easily added to the site without the need for any programming skills. This is recipe for disaster, a quick look at the publicly available plugin repository and security forums reveals many of the OWASP top 10 vulnerabilities such as XSS and injection vulnerabilities:
http://packetstormsecurity.com/search/?q=wordpress http://wordpress.org/plugins/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
*Adversary Model*
We use the range of attacks available to the adversary adversary as the base for our Threat Model and proposed requirements.
*Adversary Goals*
*Code Injection* This is the most direct compromise that can take place; the ability for the adversary to execute code on the host machine is disastrous.
*XSS the front-end, DoS the back-end* The adversary can overwhelm the database backed or the web-server of a dynamically hosted application, denying access to the service.
*Location/Identity information* Applications that are not designed with privacy in mind tend to reveal information by default. For example, WordPress includes the name of the editor of a post inside the RSS feed: dc:creatorJohn Smith</dc:creator>
*Adversary Capabilities - Positioning*
The adversary can position themselves at a number of places to execute their attacks.
*Local Network/ISP/Upstream Provider* The attacker can hijack the DNS of the plugin repository or perform a man-in-the-middle attack and push malicious code into the blog. *Third party service providers* It is common for a blog to email authentication information. This information is at risk of social and legal attacks. The repository of the blog's source code where themes and plugins are downloaded is a target for the adversary to insert malicious code.
*Adversary Capabilities - Attacks*
The adversary can perform the following attacks in order to accomplish varies aspects of their goals. Most of these attacks are due to the dynamic and Web 2.0 nature of blog platforms.
*SQL Injection & XSS* Dynamic sites take advantage of databases for content storage and JavaSript for client-side presentation. Programming mistakes can lead to code injection on server or client side.
*Inserting plugins or core updates* Blog platforms have automatic update install features, WordPress connects to a remote repositories to download updated code. Adversary can perform a man-in-the-middle attack and insert malicious code.
*Misbehaving plugins/features* Some plugins depend on remote connections to provide a feature, for e which can lead to leakage of identity.
*Brute-force the admin password* Weak passwords are vulnerable to brute-force attacks. Blog engines do not provide protection against such attacks.
*Remotely exploiting the LAMP stack* A determined adversary has a very large attack surface to analyze and discover 0-day vulnerabilities in Apache, PHP or Mysql applications.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
*Proposed requirement*
*Dynamic to Static* A simple yet effective way to protect dynamic websites is to save a 100% static copy, hosted with a lightweight and well configured http server. We propose Nginx which is a free, open-source, high-performance HTTP server. We have the option of extending existing WordPress plugins such as "Really-Static" (HTTP://word press.or/plugins/really-static/) to generate 100% static files.
*Disable Comments and New User signup (POST REQUESTS)* The ability to receive and store comments involves actions and configurations that expose the installation to DoS and other web attacks. We propose to completely disable reader's backed interactions, specifically disabling New User Registration and Comment features.
*SOCKS Proxy support for WordPress* WordPress has the ability to proxy its outgoing connections, however the current implementation only supports HTTP proxy. We propose to submit a patch to WordPress core, enabling SOCKS Proxy support: http://core.trac.wordpress.org/browser/tags/3.6.1/wp-includes/class-http.php
*Update safety* Tor Project or a partner such as WordPress.org should maintain the latest copy of the WordPress source-code over a .onion address. This will allow for the Core application updates to take place without ever leaving the Tor network and we achieve end-to-end encryption without relying on the traditional SSL/CA model.
*OnionPress plugin* Instead of hard-coding our modifications to control WordPress' functionalities, we propose to develop a custom plugin. The plugin will provide a new menu in the Administrative panel of the site. Providing options to interact with Hidden Service features. (Note that Administrative features are going to be restricted from the public and only available to localhost)
*User Authentication/Permission Levels*
a) Blog Administrator This person is hosting the blog on a local computer and has physical access to the installation. There is only 1 of such role. This login will be restricted to localhost only.
b) Blog editors/contributors These are the active content publishers. Each person has the ability to remotely connect, login and publish content. Editors do not have any administrative permissions such as adding or deleting users. Each editor is assigned a dedicated key and .onion hostname using the HidServAuth and HiddenServiceAuthorizeClient features in stealth mode.
"HiddenServiceAuthorizeClient auth-type client-name,client-name,… If configured, the hidden service is accessible for authorized clients only. The auth-type can either be 'basic' for a general-purpose authorization protocol or 'stealth' for a less scalable protocol that also hides service activity from unauthorized clients. Only clients that are listed here are authorized to access the hidden service. Valid client names are 1 to 19 characters long and only use characters in A-Za-z0-9+-_ (no spaces). If this option is set, the hidden service is not accessible for clients without authorization any more. Generated authorization data can be found in the hostname file. Clients need to put this authorization data in their configuration file using HidServAuth." c) Readers (the world) These are the site visitors, they will be able to send GET requests to the .onion address and receive HTML and multimedia content. No login or comment posting permissions granted.
*Packaged System*
We propose to design and develop a Debian based Live OS that can be started as a Virtual Machine or to boot a personal computer. This OS will include Tor, LAMP stack and a running copy of WordPress.
The LAMP installation will be hardened and configured to meet our security desires. We require a secondary USB disk for persistent storage. Desired outcome is a point-and-click and maybe portable solution that can be launched from inside of Windows, Linux or Mac OSX.
VirtualBox is a second candidate to host the VM. http://wiki.qemu.org/Main_Page and/or https://www.virtualbox.org/
*Edge Cache Nodes*
In order to provide "blazing-fast" access to the published content outside of the Tor network, we propose the deployment of caching servers operated by semi-trusted third party organizations or persons. These are similar to tor2web nodes:http://tor2web.or/
The content providers (bloggers) would select from a list of available edge servers and send a pgp signed zip file of the latest static version over Tor. Edge servers will reduce traffic from the Tor network, also provide a chance for content to reach the world in case of a DDoS or technical issues with the Tor network itself.
Having cached copies available remotely make it possible for the blogger to get on-line, publish content and go back off-line, minimizing the amount of time and traffic spent on the Internet.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Hi!
Great work on that draft! :)
My comments follow:
SiNA Rabbani:
*Adversary Model*
We use the range of attacks available to the adversary adversary as the base for
^^^^^^^^^^^^^^^^^^^ one adversary is not enough? ;)
our Threat Model and proposed requirements.
*SOCKS Proxy support for WordPress* WordPress has the ability to proxy its outgoing connections, however the current implementation only supports HTTP proxy. We propose to submit a patch to WordPress core, enabling SOCKS Proxy support: http://core.trac.wordpress.org/browser/tags/3.6.1/wp-includes/class-http.php
Ok, this one might be a crazy idea but what about wrapping Apache or PHP with torsocks?
*OnionPress plugin* Instead of hard-coding our modifications to control WordPress' functionalities, we propose to develop a custom plugin. The plugin will provide a new menu in the Administrative panel of the site. Providing options to interact with Hidden Service features. (Note that Administrative features are going to be restricted from the public and only available to localhost)
So we need WordPress to interact with the ControlPort, here. This opens a new set of potential problem. It would be great if we could allow tor to only accept a very limited set of commands.
*User Authentication/Permission Levels*
a) Blog Administrator This person is hosting the blog on a local computer and has physical access to the installation. There is only 1 of such role. This login will be restricted to localhost only.
As you are proposing to package the whole thing using a virtual machine, this would not be localhost. Unless you are thinking to have a GUI on the VM? In that case, this would probably be better to write it clearly.
b) Blog editors/contributors These are the active content publishers. Each person has the ability to remotely connect, login and publish content. Editors do not have any administrative permissions such as adding or deleting users. Each editor is assigned a dedicated key and .onion hostname using the HidServAuth and HiddenServiceAuthorizeClient features in stealth mode. "HiddenServiceAuthorizeClient auth-type client-name,client-name,… If configured, the hidden service is accessible for authorized clients only. The auth-type can either be 'basic' for a general-purpose authorization protocol or 'stealth' for a less scalable protocol that also hides service activity from unauthorized clients. Only clients that are listed here are authorized to access the hidden service. Valid client names are 1 to 19 characters long and only use characters in A-Za-z0-9+-_ (no spaces). If this option is set, the hidden service is not accessible for clients without authorization any more. Generated authorization data can be found in the hostname file. Clients need to put this authorization data in their configuration file using HidServAuth."
What worries me usability-wise is that we currently have no way to configure this without needing users to edit their torrc. Tor Launcher UI could probably be extended in a way or another, but that probably needs to be part of the plan.
c) Readers (the world) These are the site visitors, they will be able to send GET requests to the .onion address and receive HTML and multimedia content. No login or comment posting permissions granted.
One thing in the model you describe requires WordPress to be able to transparently run from at least 2 different addresses: localhost, editor2222222222.onion. As far as I understood from the discussion held around proposal 204 and the upcoming support of hidden services by the noblogs.org platform this kind of setup was not something that WordPress supported out of the box. I might be mistaken, but that's worth taking a closer look.
*Packaged System*
We propose to design and develop a Debian based Live OS that can be started as a Virtual Machine or to boot a personal computer. This OS will include Tor, LAMP stack and a running copy of WordPress.
The LAMP installation will be hardened and configured to meet our security desires. We require a secondary USB disk for persistent storage. Desired outcome is a point-and-click and maybe portable solution that can be launched from inside of Windows, Linux or Mac OSX.
VirtualBox is a second candidate to host the VM. http://wiki.qemu.org/Main_Page and/or https://www.virtualbox.org/
This is *not* an easy task to do properly. Tails “server edition” [1] might be a more ambitious project, but even something simplier based on Tails would require a lot of attention to details. Starting from scratch even more.
For example, USB support in VirtualBox is non-free and qemu does not have good support for USB 2 devices IIRC. Not sure how to reconcile that with the “VM or bare wardware” feature.
[1] https://tails.boum.org/blueprint/server_edition/
How about using APAF?
How about updates?
*Edge Cache Nodes*
In order to provide "blazing-fast" access to the published content outside of the Tor network, we propose the deployment of caching servers operated by semi-trusted third party organizations or persons. These are similar to tor2web nodes:http://tor2web.or/
The content providers (bloggers) would select from a list of available edge servers and send a pgp signed zip file of the latest static version over Tor. Edge servers will reduce traffic from the Tor network, also provide a chance for content to reach the world in case of a DDoS or technical issues with the Tor network itself.
Having cached copies available remotely make it possible for the blogger to get on-line, publish content and go back off-line, minimizing the amount of time and traffic spent on the Internet.
This is a really good idea, but maybe this should be tackled in a second (or third) phase of the project?
Lunar:
So we need WordPress to interact with the ControlPort, here. This opens a new set of potential problem. It would be great if we could allow tor to only accept a very limited set of commands.
That is https://trac.torproject.org/projects/tor/ticket/8369 by the way.
-
adrelanos -
Lunar -
SiNA Rabbani