<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>