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