[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
copies.
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