[tor-dev] Project *Cute* - draft design and challenges

SiNA Rabbani sina at redteam.io
Tue Oct 8 09:10:27 UTC 2013

Resending to tor-dev with correct email address. Sorry to those receiving 2
On Oct 8, 2013 2:02 AM, "SiNA Rabbani" <sina at redteam.io> wrote:

> Dear Team,
> I have started on a draft design document for Project cute.
> Please let me have your kind 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:creator>John
> 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://wordpress.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.
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20131008/645dda30/attachment-0001.html>

More information about the tor-dev mailing list