December 16, 2018

Introducing Gorp, a Web App Pentesting and Reversing Framework

I would like to introduce Gorp, A modular bug hunting, pentesting, and web application reverse engineering framework written in Go that I have been working on for the past few months.

The idea of gorp came up as I started exploring the Chrome Dev Tools protocol and how to use it in my pentesting and bug hunting work. If you want to learn more about how that came about you can read this blog post. However, note that a lot has changed in the architecture since I wrote that post.

In essence gorp is an engine created for web pentesting and reverse engineering. It leverages the Chrome Dev Tool protocol to intercept HTTP responses as you conduct pentest with Chrome via the use of go plugins. It allows you to process, alter, reverse and analyse web responses by proxying traffic coming from a Chrome instance. It is easy to use: create a yaml config file with a scope ang any number of modules that alter or analyse web responses (along with module specific options) and gorp will start working as you navigate your target with Chrome.

Hmmm, this sounds like Burp

Nope. Gorp is meant for targeted tasks that require more logic than simple regex rules. It is not necessarily suited for your everyday pentesting, but more so for more targeted and in depth analysis of web applications. The idea is to grow a tool that allows you do do things such as:

  • Conduct framework specific analysis of web application code.

  • Alter responses using logic that is more complex than simple regex and find and replace rules. A very basic basic example of this is the plugin data/modules/processors/generic/unhider/, which unhides hidden input elements in the page, using a goquery. Besides revealing the hidden elements in the page, the plugin also adds an indicator of the type of data that the input is meant to be used for next to the field.

  • Alter JavaScript code to do things such as forcing the client to think that you are authenticated, and to have more control on the application.

  • Deobfuscate JavaScript code.

  • Monitor the app for certain types of behavior.

gorp plugins

Gorp plugins are essentially modules that you can use to modify or audit web responses. There are two different types of plugins (so far):

  • Processors: processors plugins alter the response before it is rendered in the browser. This can be useful for things like modifying JavaScript code, changing HTML directives, unhiding elements in the page, highlighting areas of interest, etc.

  • Inspectors:: inspectors conduct analysis on responses. For instance, you may want to record all references to API calls made by the application by inspecting JavaScript code. This way, rather than waiting until the browser makes a call to /api/admin/adduser, you may be able to find a reference to that path in the client side code. JS Framework specific inspectors could also be used to inspect things such as services, controllers, authorization controllers, etc. Inspectors do not modify responses.

Using gorp

  1. Create a configuration file that uses the structure used by the config.yaml file in the root directory of this repo.
  2. You can find information about any plugin by running this command: bash go run main.go -i -m "/the/path/of/the/module/"
  3. To run gorp: bash go run main.g -c "./path/to/your/config/file.yml"

If run successfully, a new Chrome window should open up with two tabs. Use the second tab to navigate to the site that you are currently pentesting. Press ctrl + c to end the session (TODO: make a more effective way to end sessions).

Creating your own gorp plugin

The power of gorp is in the plugins. Creating your own plugin is simple.

  1. Create a file called gorpmod.go under /data/modules/processors or /data/modules/inspectors, depending on your type of plugin (see above for the differences between an inspector and a processor.
  2. Depending on the type of plugin, your code must implement either the Processor or Inspector interface, which are declared in the modules package. Both module types must accept a struct parameter of type modules.WebData which gives your module access the response body, headers and type. The type can be Document, Script or Request (Request types have not been implemented yet but that is my list of priorities for this gorp).
  3. Your plugin must include a symbol to be used by gorp. The symbol should be declared like this:
   //apifinder is just the name of your plugin
   type apifinder struct {
       Registry    modules.Registry
       Options    []modules.Option
   }
  1. Make sure to export the symbol at the end of your plugin, like so:
   var Inspector apifinder
  1. Compile your plugin like so:

    go build -buildmode=plugin -o gorpmod.so gorpmod.go
  2. Now you are ready to use your plugin with gorp.

Configuring a gorp session.

This is what the config should look like

scope: "example.com"
verbose: True
flags: ["-na", "--disable-gpu", "--window-size=1200,800", "--auto-open-devtools-for-tabs","--disable-popup-blocking"]
modules:
  processors:
    - path: "/data/modules/processors/angular/unhider/"
      options: {}
    - path: "/data/modules/processors/generic/unhider/"
      options: {}
  inspectors:
    - path: "/data/modules/inspectors/generic/apifinder/"
      options:
        FilePath : "./logs/apifinds.txt"

All processors that you want to use must be included as shown above. The options will depend on the specific options for that plugin. Note that verbose will output a lot of data to the console, so if a plugin outputs to stdout you may want to set verbose to False.

Can I help?

Hopefully someone is asking this question (I don’t add any trackers to this blog, so I have no idea if anyone is reading this, ever). The answer is yes. The project is hosted at https://github.com/DharmaOfCode/gorp/. I have a long lists of things that I need hel with (other than those listed below).

Immediate Needs

  • I have not found a JS beautifies and deobfuscation go library yet. Worst-case scenario, I could either write one (kinda of a project of its own) or use node libraries via system calls.

Todo

  • Add a fancy, interactive shell-like CLI.
  • Rad CLI colors and functions for fancy cli printing
  • Create more plugins for tasks such as:
    • Keep track of values such as user GUIDs and show alarms when certain conditions occur while you explore an application (helpful for finding IDORs).
    • Perform framework specific analysis of an application as it is explored. For instance, the tool could list all Angular services or all API endpoints as it analyses scripts used by the application.
    • Alter scripts to test for specific behaviors, such as setting isAdmin variables to true before a request is submitted to a server.
    • Other cool stuff.

More to come

This is a work in progress, so there is a lot more to come. In the next few weeks and months I will be adding detailed blog posts about gorp. My next blog post on gorp will be on creating a gorp plugin from beginning to end.

© Dharma of Code 2018