Resending to tor-dev with correct email address. Sorry to those receiving 2 copies. On Oct 8, 2013 2:02 AM, "SiNA Rabbani" <[email protected]> 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. > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >
_______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
