AuthMatrix v0.6 Released

Since its release a year ago, AuthMatrix has enabled countless engineers to unwind the manual loop of authorization testing and simplify the task of securing web applications.

Today I am excited to announce the newest major version release: AuthMatrix v0.6.

AuthMatrix v0.6 is a three week effort resulting in approximately 1000 additional lines of code to provide a suite of new features, improvements, and bug fixes. With these changes, the capabilities of AuthMatrix have been heavily expanded. AuthMatrix can now be used to achieve more comprehensive authorization testing in more complex web applications and services.

Whats New?

A complete list of new improvements and features can be found the CHANGES file on Github.

Some of the highlighted changes include:

Failure Response Regex

One of the most requested features for AuthMatrix was the ability to set regexes for failure cases rather than success cases.  This might be handy in situations where every page returns a unique response on success, but returns a predictable error when the application fails due to authorization errors.

For example, let's say your application returns a unique response on success, but consistently returns an HTTP 303 when authorization fails.  With AuthMatrix v0.6 you can simply set your Response Regex to that HTTP code, right click the relevant messages, and Toggle the Regex Mode to Failure.  The regex will be highlighted in purple to indicate the setting and AuthMatrix will successfully confirm that only users with insufficient permissions see that failure response code.

Edit Requests from AuthMatrix

Before this release, if you wanted to edit the baseline request of a message in AuthMatrix, you had to move that message to another area of Burp like repeater and edit it there, adding it back to AuthMatrix once completed.  Now AuthMatrix allows users to edit requests from within AuthMatrix itself, saving users the hassle of removing and reorganizing messages. Simply select the message you would like to change and type in the Original Request text box as you would with Repeater.

Additionally, users can now right click messages within the message table and modify the target server as well. Through this interface, users can edit the target host, port, and HTTPS configuration of any message.

One of the common use-cases is to configure AuthMatrix against a target webapp in a development environment.  This presented challenges to users who had saved AuthMatrix states with messages targeting domains that had changed or were no longer accessible.  Now users can load AuthMatrix State Files and simply edit all requests to point at the new target.

AuthMatrix Chains

AuthMatrix Chains is a new feature for advanced configuration of AuthMatrix.  With chains, you can link values found in a message's response and replace them into the body of another message.  Users have the option of connecting messages to perform advanced actions within AuthMatrix, such as populating fresh CSRF tokens into each request or running authorization checks against newly generated IDs/GUIDs.

Chains can be configured through clicking the New Chain button at the bottom of AuthMatrix.  Once clicked, a new table appears that allows configuring a Chain using regex search and replacement.

To configure a Chain, enter the source message's ID, an optional User ID (for Pitchfork Mode discussed below), a regex to extract the value from the source message's response, a list of destination messages, and the regex used to replace the value into the proper location.

When a chain is enabled, AuthMatrix will run the regex against the source message's response and identify the value to be extracted.  For each of the destination messages that are run after, AuthMatrix will automatically insert this value into the request as defined by the regex.

Additionally, since chains require destination messages to be run after a source message, the message table now supports the ability to drag-and-drop messages in order to modify their run order.

AuthMatrix Chain Modes

There are two modes in which chains can be used: Standard and Pitchfork

Standard Mode: A value will be extracted from the message response for each individual user and then placed into those corresponding users' destination messages. Chains in this mode are not directly used for testing new authorization scenarios, but may be useful in order to run an AuthMatrix configuration successfully. A common scenario for using Chains in Standard Mode is with Anti-CSRF tokens, since these tokens can be short-lived and user-specific.

For example, Message 1 might be a simple GET request to a "Contact Us" page that returns a form with a new Anti-CSRF token. Message 2 might then be a POST request submitting that form.  By chaining the token from Message 1 into Message 2, you can successfully use AuthMatrix to test authorization, despite any advanced CSRF protections present in the application.

To set a chain to Standard Mode, leave the SRC - User ID field empty.

Example Chain Entry: 
Name:   CSRF
SRC - Msg ID:   1
SRC - User ID:
SRC - Regex:   <input .* name="csrfToken" value="(.*)" />
DEST - Msg ID:   2
DEST - Regex:   csrfToken=(.*?)&


Pitchfork Mode: The source value is extracted from the message response of only one selected user. This value is then inserted into the subsequent requests for all users. This is most useful when testing new authorization cases where a newly created identifier must only be accessible to that one specific user.

For example, Message 1 might be a request that creates a new order on an e-commerce website and returns an Order ID. Message 2 might then be a request that views the status of that order.  To test this authorization case, you can define a new role called "Only Bob" and set Message 2 to only allow that role.

You can then define a chain that propagates the Order ID generated when user "Bob" runs request 1 into the parameters of Message 2 for all users.  If any user that is not "Only Bob" succeeds with this new Order ID, AuthMatrix will flag this as a vulnerability.

Pitchfork Mode can be enabled by entering the User ID of the user whose response value is to be propagated.

Example Chain Entry: 
Name:   OrderStatus
SRC - Msg ID:   1
SRC - User ID:   0
SRC - Regex:   "orderID"="(.*?)"
DEST - Msg ID:   2
DEST - Regex:   GET /orderStatus\?id=(.*?) HTTP/1.1

Try it Now!

AuthMatrix v0.6 is available on Github and will be updated in the BApp Store soon. Give it a try and be sure to submit any feedback to the Github issues page!

https://github.com/SecurityInnovation/AuthMatrix

Cheers,
-Mick

AuthMatrix for Burp Suite

I'm very excited to announce the release of a project that I have been working on for some time now. AuthMatrix is an extension to the Burp Suite testing utility designed to improve the process of verifying authorization protections in web applications and web services.

The idea for AuthMatrix came in an attempt to solve a huge problem in web security testing. Unlike many other classes of vulnerabilities common in webapps, authorization bugs are hard to generalize between applications and because of that, the process for validating all authz cases can be time consuming and painstakingly manual. Not only this, but once the testing is completed, it is rarely possible to quickly repeat the test or verify the tester's results with any level of assurance.

As I describe during my talk given at Appsec California 2016 introducing AuthMatrix, the current manual process for testing authorization in web apps and web services can look a bit like this.

• Enumerate roles and map entire application's functionality
• Authenticate all necessary users
• Test every combination of user and request:
• Run request
• Observe response
• Determine if behavior is correct for that user's privilege level
• Record results to a notes file

There are several major choke points to note with this testing methodology. The first being that the majority of this process is done manually, with only a checkbox in a notes doc to verify the results.  Additionally, the testing process described in the last item above can essentially be viewed as a LARGE manual for-loop, where initiating requests, calculating results, and recording the output is all done by hand. This combination introduces a significant number of opportunities for human error to occur with no ability to verify the tests were performed correctly. This, unfortunately, can often result in critical authorization vulnerabilities being missed, even by the most skilled and diligent pentesters.

With AuthMatrix, we restructure this process so that defining your system's characteristics are front-loaded and the application takes care of all the testing and validation.  Pentesters define a set of roles, users, and requests that sufficiently cover their target application's capabilities and assemble tables similar to those used in many threat modeling techniques. These tables can be verified at any stage of the testing process and saved to disk for later regression testing.

The primary goal of the project was to create a tool that made this process easier and more efficient for the tester.  No point in making an App that no one will use. AuthMatrix achieves a high level of usability with a simple UI and provides an easy to read interface indicating the results of the test.

With AuthMatrix, we've managed to unwind the manual for-loop in the methodology above so that the risk of missed vulnerabilities due to complexity and human error is significantly reduced.

So, after a warm reception at the Appsec California 2016 conference, I'm happy to say that the extension is now fully available to the public. AuthMatrix can be found through the Security Innovation public Github page or can simply be installed directly in Burp for free in the BApp Store.

Give it a try and let me know what you think.

-Mick Ayzenberg


Links:

https://github.com/SecurityInnovation/AuthMatrix

https://portswigger.net/bappstore/ShowBappDetails.aspx?uuid=30d8ee9f40c041b0bfec67441aad158e

http://schd.ws/hosted_files/appseccalifornia2016/50/AppSec-AuthMatrix-MickAyzenberg.pdf