pappyproxy 0.0.1

Introduction

The Pappy (Proxy Attack Proxy ProxY) Proxy is an intercepting proxy for performing web application security testing. Its features are often similar, or straight up rippoffs from Burp Suite. However, Burp Suite is neither open source nor a command line tool, thus making a proxy like Pappy inevitable. The project is still in its early stages, so there are bugs and only the bare minimum features, but it should be able to do some cool stuff soon (I’m already using it for realtm work).

Contributing

I am taking any and all feature requests. If you’ve used Burp and had any inconvenience with it, tell me about it and I’ll do everything in my power to make sure Pappy doesn’t have those issues. Or even better, if you want Burp to do something that it doesn’t already, let me know so that I can [STRIKEOUT:use it to stomp them into the dust] improve my project.

If you’re brave and want to try and contribute code, please let me know. Right now the codebase is a giant clusterfun which I have refactored a few times already, but I would be more than happy to find a stable part of the codebase that you can contribute to.

Installation

Pappy supports OS X and Linux (sorry Windows). Installation requires pip or some other command that can handle a setup.py with requirements. Once the requirements are installed, you can check that it installed correctly by running pappy -l to start the proxy.

$ git clone https://github.com/roglew/pappy-proxy.git
$ cd pappy-proxy
$ pip install .

Quickstart

Pappy projects take up an entire directory. While a full directory may seem like a dumb idea compared to storing everything in a zip file, future releases will do fun stuff like generate attack scripts or other files that need to be used by other programs on a regular basis. To start a project, do something like:

$ mkdir test_project
$ cd test_project
$ pappy
Copying default config to directory
Proxy is listening on port 8000
itsPappyTime> exit
$ ls
data.db            project_config.json  project_config.pyc
$

And that’s it! The proxy will by default be running on port 8000 and bound to localhost (to keep the hackers out). You can modify the port/interface in config.json. You can list all your intercepted requests with ls, view a full request with vfq <reqid> or view a full response with vfs <reqid>. No you can’t delete them yet. I’m working on it.

Lite Mode

If you don’t want to dirty up a directory, you can run Pappy in “lite” mode. Pappy will use the default configuration settings and will create a temporary datafile in /tmp to use. When you quit, the file will be deleted. If you want to run Pappy in line mode, run Pappy with either -l or --lite.

Example:

$ pappy -l
Temporary datafile is /tmp/tmpw4mGv2
Proxy is listening on port 8000
itsPappyTime> quit
Deleting temporary datafile
$

Adding The CA Cert to Your Browser

In order for Pappy to view data sent using HTTPS, you need to add a generated CA cert (certificate.crt) to your browser. Certificates are generated using the gencerts command and are by default stored in the same directory as pappy.py. This allows Pappy to act as a CA and MITM HTTPS connections. I believe that Firefox and Chrome ignore keychain/system certs, so you will have to install the CA cert to the browsers instead of (or in addition to) adding the cert to your keychain.

Configuration

Configuration for each project is done in the config.json file. The file is a JSON-formatted dictionary that contains settings for the proxy. The following fields can be used to configure the proxy:

The following tokens will also be replaced with values:

Generating Pappy’s CA Cert

In order to intercept and modify requests to sites that use HTTPS, you have to generate and install CA certs to your browser. You can do this by running the gencerts command in Pappy. By default, certs are stored in the same directory as Pappy’s script files. However, you can change where Pappy will look for the private key file in the config file. In addition, you can give the gencerts command an argument to have it put the generated certs in a different directory.

Browsing Recorded Requests/Responses

The following commands can be used to view requests and responses

The table shown will have the following columns:

Context

The context is a set of filters that define which requests are considered “active”. Only requests in the current context are displayed with ls, and eventually contexts will be how Pappy will manage requests for group operations. By default, the context includes every single request that passes through the proxy. You can limit down the current context by applying filters. Filters apply rules such as “the response code must equal 500” or “the host must contain google.com”. Once you apply one or more filters, only requests/responses which pass every active filter will be a part of the current context.

Filter Strings

Filter strings define a condition that a request/response pair must pass to be part of a context. Most filter strings have the following format:

<field> <comparer> <value>

Where <field> is some part of the request/response, <comparer> is some comparison to <value>. Also if you prefix a comparer with ‘n’ it turns it into a negation. For example, if you wanted a filter that only matches requests to target.org, you could use the following filter string:

host is target.org

field = "host"
comparer = "is"
value = "target.org"

For fields that are a list of key/value pairs (headers, get params, post params, and cookies) you can use the following format:

<field> <comparer1> <value1>[ <comparer2> <value2>]

This is a little more complicated. If you don’t give comparer2/value2, the filter will pass any pair where the key or the value matches comparer1 and value1. If you do give comparer2/value2, the key must match comparer1/value1 and the value must match comparer2/value2 For example:

Filter A:
    cookie contains Session

Filter B:
    cookie contains Session contains 456

Filter C:
    cookie ncontains Ultra

Cookie: SuperSession=abc123
Matches A and C but not B

Cookie: UltraSession=abc123456
Matches both A and B but not C

Scope

Scope is a set of rules to define whether Pappy should mess with a request. You define the scope by setting the context to what you want the scope to be and running scope_save. The scope is saved in data.db and is automatically restored when using the same project directory.

Any requests which don’t match all the filters in the scope will be passed straight to the browser and will not be caught by the interceptor or recorded in the database. This is useful to make sure you don’t accidentally do something like log in to your email through the proxy and have your plaintext username/password stored and accidentally shown to your coworkers.

Interceptor

This feature is like Burp’s proxy with “Intercept Mode” turned on, except it’s not turned on unless you explicitly turn it on. When the proxy gets a request while in intercept mode, it lets you edit it before it forwards it to the server. In addition, it can stop responses from the server and let you edit them before they get forwarded to the browser. When you run the command, you can pass request and/or response as arguments to say whether you would like to intercept requests and/or responses. Only in-scope requests/responses will be intercepted (see Scope section).

The interceptor will use your EDITOR variable to decide which editor to edit the request/response with. If no editor variable is set, it will default to vi.

To forward a request, edit it, save the file, then quit.

Intercept both requests and responses:
> ic requests responses
> ic req rsp

Intercept just requests:
> ic requests
> ic req

Intercept just responses:
> ic responses
> ic rsp

Be totally useless:
> ic

Repeater

This feature is like Burp’s repeater (yes, really). You choose a request and Pappy will open vim in a split window with your request on the left and the original response on the right. You can make changes to the request and then run “:RepeaterSubmitBuffer” to submit the modified request. The response will be displayed on the right. This command is bound to <leader>f by default, but you can rebind it in your vimrc (I think, dunno if vim will complain if it’s undefined). This command will submit whatever buffer your cursor is in, so make sure it’s in the request buffer.

To drop a request, delete everything, save and quit (ggdG:wq).

When you’re done with repeater, run “:qa!” to avoid having to save changes to nonexistent files.

Logging

You can watch in real-time what requests are going through the proxy. Verbosisty defaults to 1 which just states when connections are made/lost and some information on what is happening. If verbosity is set to 3, it includes all the data which is sent through the proxy and processed. It will print the raw response from the server, what it decodes it to, etc. Even if you don’t run this command, all the information is stored in the dubug directory (the directory is cleared every start though!)