Pentagrid AG (Posts about Portswigger)

Hackvertor EAN-13 and TOTP tags for web-application penetration testing with Burp

Pentagrid AG — Fri, 06 Dec 2024 08:42:00 GMT

Hackvertor is a standalone tool and more importantly for us an extension for the penetration testing tool Portswigger Burp Suite by Gareth Heyes of the Portswigger Research team, which performs dynamic data conversions. For example, the tool can be used to encode data fields as Base64 before Burp sends a HTTP POST request to a server. This happens automatically and there is no need to manually convert anything or copy and pasting between different windows.

We had an example in our blog, where we generated Swiss social security numbers for a pentest and explained how to program custom Hackvertor tags. There are all kinds of tags already available inside Hackvertor and users can also code their own custom tags. Nowadays Hackvertor has it's own public tag store, where users can submit custom tags. Pentagrid provided two custom tags that made it into the Hackvertor tag store. One tag is for calculating the check-digit of EAN-13 numbers and another is for Time-based one-time password (TOTP) calculation.

As already explained in our blog post Teaching Burp a new HTTP Transport Encoding, being able to customise Burp like this is a helpful instrument to automate and increase test coverage during a security analysis.

EAN-13 Hackvertor tag

EAN is the European Article Number, a standard to encode article numbers. And while it became more international than European and is now called Global Trade Item Number, it is often still referred as EAN-13. Swiss AHV/AVS numbers use the check-sum calculation from EAN-13 and store the check-sum as the 13th digit.

The custom tag code from our blog post was made available as a Hackvertor tag in the tag store. To use the EAN-13 tag, see the following two examples:

# the "append" parameter can be set to 0 or 1.
<@_ean13(1,'[...]')>756.9217.0769.8</@_ean13> # -> 756.9217.0769.85
<@_ean13(0,'[...]')>756.9217.0769.8</@_ean13> # -> 5

The omission [...] is the place where a so-called Hackvertor code execution key must be inserted. The Hackvertor Burp extension will add the code execution key automatically, if the tags are used and prepared in the Hackvertor tab in the Burp UI. The execution key is a random 40-hex character string that prevents websites processed by Burp from triggering harmful actions. The code execution key is unique to your Burp application start. Only code execution tags (with custom code such as the ones in the tag store) require code execution keys.

TOTP Hackvertor tag

Pentagrid also implemented a TOTP tag. This time-based one-time password is used for second factor authentication. If such a second factor is required during the penetration test, this Hackvertor tag can be used. The code was recently added to the tag store. To use the TOTP tag, extract the seed from the QR code that was handed over to you to scan it with an authenticator app. The command line tool zbarimg can dump QR code content from an image file:

% zbarimg ~/Authenticator-QR-Code.png
QR-Code:otpauth://totp/SomeOrg:something?secret=MYSEEDMYSEED2342&issuer=SomeOrg
scanned 1 barcode symbols from 1 images in 0.05 seconds

The tag can then be used analogue to this example:

<@_totp('[...]')>MYSEEDMYSEED2342</@_totp> # -> 797723

There are several parameters for TOTP. In practise, the tag only supports the commonly used parameters SHA1, 30 seconds, 6 digits. Let us know if you find a different configuration in the wild, it should be fairly simple to adapt the custom tag in that case.

In order to access the tag store, just go to the menu entry "View tag store" from the Hackvertor menu in Burp and install the plugins you want. Then also make sure to allow code execution tags via the menu entry "Allow code execution tags" from the Hackvertor menu in Burp.

Update 2025-06-04: An update of Hackvertor in 2025 changed the style of closing elements from <@/name> to </@name>. Therefore, we updated the post.

Teaching Burp a new HTTP Transport Encoding

Pentagrid AG — Wed, 13 Apr 2022 10:42:00 GMT

Today we would like to talk about Burp Suite Professional and extensions again. In this blog post we explain how we can teach Burp Suite to handle a custom Transport Encoding that is spoken between an HTTP client and a server by using Burp extensions.

Introduction

Burp has many nice features, but sometimes it lacks a feature we would like to have or our target application is customized so that it is necessary to teach Burp new things. More specifically:

Burp has no support for the standard HTTP brotli Transport-Encoding, but all modern browsers do. This problem is handled by Burp by removing brotli from the Accept-Encoding request header (see Proxy - Options - Miscellaneous - Remove unsupported encodings from Accept-Encoding headers in incoming requests), which works for modern browsers. However, we encountered situations during tests where a non-browser HTTP client software required brotli and refused to talk to the server when brotli encoding is missing.
Java fat clients sometimes zlib-encode the entire HTTP body when talking to a server and vice-versa. They also often refuse to speak non-zlib and do not signal it at all in an HTTP header, therefore it is necessary to implement zlib-decoding and encoding to be able to use Burp properly.
If a website uses JavaScript to encrypt all HTTP bodies when talking to a server and vice-versa, we also would like to implement a decryption and encryption routing to use the Burp tools. We also encountered the same situation with other HTTP clients that used additional transport encryption, such as mobile banking apps.

The biggest issue for us was to figure out how we approach these situations consistently and we show our approach in this blog post.

In this blog post we often refer to "encoding" or "encrypting", which obviously is not the same, but both operations have to be done at the same place inside Burp. Encryption or encoding is merely an implementation detail in this blog post. Also "cleartext" is used to indicate decoded or decrypted content.

Why are you doing all of this?

If Burp is not seeing decoded messages for one of the reasons above, it won't work properly. Tools such as Burp Scanner, Repeater, Intruder and other extensions will often fail to interpret the encoded HTTP content and will for sure fail with encrypted content. It won't matter if you use the scanner or not, in many cases it won't do anything useful if you don't implement this custom decoder/encoder. On the contrary, very often a tester's task is to make their tools work. This might be rewarded in the end by simply pressing the active scan button in Burp and then finding security issues. To us, this is a huge difference between a good and a bad security analysis.

Usually we would suggest to solve this problem with features or extensions that are already present, for example the Hackvertor extension would be a good candidate. However, Hackvertor won't modify responses, so this isn't an option here.

Burp's API for extensions

Burp provides several APIs an extension can use. The API code didn't get much love in the last few years, but this is hopefully changing when Burp releases the New API and multi-language extensibility. Let's hope for the best, but for now we're stuck with the API we have. There are two main API hooks that matter in the situation of a missing Transport Encoding. We'll use the name of the function name in the rest of this blog post, but the interfaces that provide the functionality are called:

IProxyListener, which means you have to implement the function processProxyMessage.
IHttpListener, which means you have to implement the function processHttpMessage.

While both interfaces sound similar, the proxy listener will only see requests and responses going through the proxy (e.g. from the browser), whereas the HTTP listener will see the requests and responses of all tools (Proxy, Crawler, Scanner, Repeater, Intruder, other extensions, etc.). However, there's one little detail that is important to mention: If you want to change messages going throught the proxy, you have to do that in the processProxyMessage function and you can't do that in the processHttpMessage. It's just a Burp API limitation that you can't modify messages from TOOL_PROXY in the processHttpMessage. That means we have to get around this limitation by choosing the correct API.

While we think it is better to use Kotlin to write large Burp extensions nowadays, rapid prototyping is still quicker with Python. Therefore we use Python (or rather, Jython 2.7 in Burp) in this blog post.

Here's a little Python sample extension that handles the API confusion of processProxyMessage and processHttpMessage, so we don't need to care about it anymore and can just modify messages in the newly created processMessage function:

from burp import IBurpExtender
from burp import IHttpListener
from burp import IProxyListener
from burp import IBurpExtenderCallbacks

NAME = "Pentagrid Extension Template"

class BurpExtender(IBurpExtender, IProxyListener, IHttpListener):

    def registerExtenderCallbacks(self, callbacks):
        # keep a reference to our callbacks object
        self._callbacks = callbacks

        # set our extension name
        callbacks.setExtensionName(NAME)

        # register ourselves as an Proxy listener
        callbacks.registerProxyListener(self)

        # register ourselves as an HTTP listener
        callbacks.registerHttpListener(self)

        print("Loaded "+NAME+" successfully!")

    #
    # implement IHttpListener
    #

    def processHttpMessage(self, toolFlag, messageIsRequest, messageInfo):
        if toolFlag == IBurpExtenderCallbacks.TOOL_PROXY:
            # DONT'T DO ANYTHING HERE
            # Instead, use processProxyMessage below
            # https://github.com/nccgroup/BurpSuiteLoggerPlusPlus/issues/42
            return
        self.processMessage(toolFlag, messageIsRequest, messageInfo)

    #
    # implement IProxyListener
    #
    def processProxyMessage(self, messageIsRequest, message):
        self.processMessage(IBurpExtenderCallbacks.TOOL_PROXY, messageIsRequest, message.getMessageInfo())


    def processMessage(self, toolFlag, messageIsRequest, messageInfo):
        # TODO: Implement whatever you would like to do
        pass

As a bonus, the Burp UI will show the "Edited request" or "Edited response" option in the Proxy tool whenever we change a proxy message. However, for processHttpMessage we are partially blind, the request and responses will simply be changed, but depending on where we measure we might see them in a different state in the UI (discussed in the next section).

Burp's hooking locations

We would like to hook as early as possible and as late as possible. We would like to make sure that we decode or decrypt early, so that all other Burp tools can work with readable non-compressed HTTP requests and responses. We also want to encode or encrypt as late as possible, just before the request leaves Burp for the same reason. The problem here is that processProxyMessage is called before processHttpMessage for requests, but for responses processHttpMessage is called before processProxyMessage. When analysing the exact behavior, we saw it's a non-trivial setup. For example, the built-in Burp Logger is a tab in the Burp UI showing all requests/responses that flow through Burp. But the question is, where does the Burp Logger hook the API itself? Moreover, users who have advanced knowledge of Burp also know that the extension order in the loaded extension list matters. So where should we put our decoder or decrypter and where should we put our encoder or encrypter? This is not easy to explain and it took us a little trial and error, but we figured out that this diagram should be accurate:

Diagram showing how requests and responses are processed inside Burp when we load our Burp extensions. Green is for cleartext (decoded or decrypted) traffic, red for encoded or encrypted traffic.

This diagram shows several interesting details:

We achieve what we want: Target, Intruder, Repeater, Scanner and other extensions can deal with "cleartext" requests. However, we can't make it work with Proxy match/replace rules for requests (they are applied to the encoded content).
Burp's built-in Logger is not last in the chain for responses, it's possible that Burp extensions modify the responses. This means you don't necessarily see what was delivered to the client/server in Logger. You should better use Logger++ and put it last in the extension list to see which requests are sent to the server and which responses are returned after processing in Burp. Of course it depends on what you want to see, but that's what is the most logical setup.
Our extension we would like to write for our purpose has to be first and last (well, second-last before Logger++) to make sure it does its job well. This means we need to write two extensions, an early-decoder that is first in the list for requests (see DECRYPTER top left in the diagram) and responses (see DECRYPTER bottom right) and a late-reencoder that is last in the list for requests (see ENCRYPTER bottom left) and responses (see ENCRYPTER top right). So the order of the extensions has to be like in the following image:

Extension order is important to make sure all extensions see the correct traffic. Early decoder as the first extension, late encoder as the second-last.

Now that we know we need two extensions, how would the Python extensions look like? Here's the early decoder:

from burp import IBurpExtender
from burp import IHttpListener
from burp import IProxyListener
from burp import IBurpExtenderCallbacks

NAME="Pentagrid early decoder"

class BurpExtender(IBurpExtender, IHttpListener, IProxyListener):

    def registerExtenderCallbacks(self, callbacks):

        # keep a reference to our callbacks object
        self._callbacks = callbacks

        # obtain an extension helpers object
        self._helpers = callbacks.getHelpers()

        # set our extension name
        callbacks.setExtensionName(NAME)

        # register ourselves as an HTTP listener
        callbacks.registerHttpListener(self)
        callbacks.registerProxyListener(self)

        print("Loaded "+NAME+" successfully!")

    #
    # implement IHttpListener
    #

    def processHttpMessage(self, toolFlag, messageIsRequest, messageInfo):
        if toolFlag == IBurpExtenderCallbacks.TOOL_PROXY and messageIsRequest:
            # Already processed in processProxyMessage
            return
        self.filter_message(toolFlag, messageIsRequest, messageInfo)

    #
    # implement IProxyListener
    #
    def processProxyMessage(self, messageIsRequest, message):
        # Responses are handled as early as possible in processHttpMessage
        if messageIsRequest:
            self.filter_message(IBurpExtenderCallbacks.TOOL_PROXY, messageIsRequest, message.getMessageInfo())


    def filter_message(self, toolFlag, messageIsRequest, messageInfo):
        # TODO: implement decoding
        pass

And here's the late encoder:

from burp import IBurpExtender
from burp import IHttpListener
from burp import IProxyListener
from burp import IBurpExtenderCallbacks

NAME="Pentagrid late encoder"

class BurpExtender(IBurpExtender, IHttpListener, IProxyListener):

    def registerExtenderCallbacks(self, callbacks):

        # keep a reference to our callbacks object
        self._callbacks = callbacks

        # obtain an extension helpers object
        self._helpers = callbacks.getHelpers()

        # set our extension name
        callbacks.setExtensionName(NAME)

        # register ourselves as an HTTP listener
        callbacks.registerHttpListener(self)
        callbacks.registerProxyListener(self)

        print("Loaded "+NAME+" successfully!")

    #
    # implement IHttpListener
    #

    def processHttpMessage(self, toolFlag, messageIsRequest, messageInfo):
        if toolFlag == IBurpExtenderCallbacks.TOOL_PROXY and not messageIsRequest:
            # Requests are handled as late as possible in processProxyMessage
            return
        self.filter_message(toolFlag, messageIsRequest, messageInfo)

    #
    # implement IProxyListener
    #
    def processProxyMessage(self, messageIsRequest, message):
        # Responses are handled as late as possible in processHttpMessage
        if not messageIsRequest:
            self.filter_message(IBurpExtenderCallbacks.TOOL_PROXY, messageIsRequest, message.getMessageInfo())


    def filter_message(self, toolFlag, messageIsRequest, messageInfo):
        # TODO: implement encoding
        pass

Bonus

To make this a little more convenient for you, we've set up a Github repository with all the examples from above (in the "minimal" subfolder). However, that's not all:

A fully working example for the zlib-body encoding/decoding.
A template that has some more helpful functions if you want to implement your own decoding/encoding.
An additional extension that implements an IMessageEditorTabFactory, so if you encounter an encoded message in Burp you can click the message viewer option of the extension and will see it in decoded form.

More advanced examples

With the above examples it should be no problem for you to also create extensions that do decryption/encryption instead of decoding/encoding in more complicated setups. In one of our security analysis, we were able to implement the decryption/encryption and hardcoded the key at first. However, then we realised we could additionally inject a JavaScript tag into the HTML single-page response of the server to "steal" our own encryption key from our browser. This removed the requirement to hard-code the encryption key. We did this by replacing </body> with:

<script>let lastKey = null; function pentagrid () {let nowKey = window.encryptionKey; if(nowKey && nowKey !== lastKey){lastKey = nowKey; let pentagrid2 = new XMLHttpRequest(); pentagrid2.open("GET", "/pentagridDiscloseKey=" + nowKey, false); pentagrid2.send(null);}}; setInterval(pentagrid, 500);</script></body>

This JavaScript extracted the encryption key from the browser DOM and sent it through Burp, so we could catch it in our decrypter/encrypter extensions and therefore fully intercept cleartext traffic.

Happy hacking!

Response Overview Burp Extension

Pentagrid AG — Wed, 12 Jan 2022 13:30:00 GMT

Today we would like to announce the release of an updated BurpSuite extension in the BApp store.

In the last few months we've been busy improving some of our own tools. One of them was the Response Overview (used to be called "Response Clusterer") Burp extension. We did a complete rewrite from Jython to Kotlin. Jython has some huge compatibility issues inside Burp, just to mention some of them:

Extensions break depending on if Jython version 2.7.0 or 2.7.2 is installed.
Type issues as Jython needs to convert Java arrays to Python string, which is not trivial in deeply-nested objects.
Jython is not available for Python 3, which is okay, but when our extensions grew large, we missed the type hinting feature of Python 3.
Cool features of Kotlin such as null-checking or automatically generated getter and setter methods are missing.

The only real downside we see is that Kotlin extensions need to be compiled before they can be used, whereas changing a line in a Python script is much easier.

This extension groups all response bodies by similarity and shows a summary, one request/response per group. The extension will allow a tester to get an overview of the tested website's responses from all tools (scanner, proxy, etc.). It provides an additional "semi-automated detection method" (compared to the usual detection methods response-based, time-based, interaction-based, etc.).

The new Response Overview extension has some huge memory, performance and UI improvements. This includes being able to sort the overview table as well as hiding items in it.

Moreover, according to Portswigger, this was the first Kotlin-only extension that was submitted to the Burp internal BApp store. They changed their build-pipeline to make sure Kotlin extensions can be auto-built in the future when submitted to the BApp store. So if you write an extension in Kotlin, make sure to have a look at our Github repository. Moreover, include the API files found in the burp-extender-api-kotlin Github repository as we did in the Response Overview extension.

During the journey of learning Kotlin and writing the extension, we encountered two annoying Kotlin compiler bugs. One bug could be circumvented because Portswigger agreed that Kotlin extension can provide their own API files (see above). The other bug was fixed when a new compiler version came out. We still haven't figured out another Serialization bug we encountered. So if you are a Java/Kotlin wizard, we would also be interested to hear from you why the Java Serialization (or rather the deserialization) of the boolean "hidden" flag in the LogEntry class is not working (hidden flag is always false when deserialized).

The Github repository also features more technical information about the extension. The extension can be found in BApp now and the BApp store listing can be found on the Portswigger website.

Have fun with the extension and happy bug hunting!

Password reset code brute-force vulnerability in AWS Cognito

Pentagrid AG — Fri, 30 Apr 2021 08:00:00 GMT

The password reset function of AWS Cognito allows attackers to change the account password if a six-digit number (reset code) sent out by E-mail is correctly entered. By using concurrent HTTP request techniques, it was shown that an attacker can do more guesses on this number than mentioned in the AWS documentation (1587 instead of 20). If the attack succeeds and the attacked accounts do not have multi-factor authentication enabled, a full take-over of the attacked AWS Cognito user accounts would have been possible. The issue was fixed by AWS on 2021-04-20.

Impact

An attacker who guessed the correct reset code can set a new password for the attacked AWS Cognito account. This allows attackers to take over the account that is not using additional multi-factor authentication.

Timeline

2021-03-17: Discovery of the issue by Pentagrid
2021-03-22: Initial contact of AWS security according to the vulnerability reporting website
2021-03-23: AWS responds the issue is being investigated, Pentagrid responds with vulnerability details
2021-03-24: AWS requests more details, Pentagrid responds with more vulnerability details
2021-03-25: AWS requests more details about late invalidation of password-reset codes
2021-03-26: Pentagrid responds with more details regarding late invalidation of password-reset codes
2021-04-01: AWS responds the issue is still being investigated
2021-04-08: AWS responds the issue is still being investigated and asks for a phone call
2021-04-13: to 2021-04-19: More E-mails regarding organisation of the phone call
2021-04-22: Phone call between AWS security and Pentagrid AG: Issue has been fixed for all AWS customers on 2021-04-20
2021-04-27: Pentagrid verifies the fix, only 20 code mismatches could be provoked.
2021-04-30: Advisory published

Affected Components

AWS Cognito user accounts are affected.

Technical details

AWS Cognito is an AWS Service that provides user account management. This includes a password reset functionality as a self-service for Cognito end-users.

The attack described here assumes that the AWS Cognito service is directly exposed to the web without custom filtering in the program code of the AWS customer. This is likely to be a common configuration. In the setup that was tested, an AWS Lambda instance forwarded requests to the AWS Cognito service by using the Python Chalice library.

If no attack happens, the user's workflow is as following:

The user enters his account's E-mail address in the password forgotten web form
The user receives an E-mail that includes a six digit password reset code (from now on this is referred to as "code")
By entering them into forms, the user sends the code, his account's E-mail address and a new password to the password forgotten functionality. This triggers the confirm_forgot_password function shown below.

As the code is the only secret value, it is crucial that an attacker can not guess its value. The codes have six digits, therefore the key space is 1'000'000, which corresponds to around 20 bits of security. As this is not sufficient from a generic security perspective because an attacker could potentially brute-force the code, AWS has to limit the number of times it can be entered.

After the three-step process is done, the server will respond with one of the following responses:

If the code is correct, the password for the account is immediately changed to the new value (HTTP 200 response)
If the code is incorrect, the server responds with a cognito_client.exceptions.CodeMismatchException, further referenced as code mismatch (HTTP 500 response)
If the confirm_forgot_password function was called too many times, the server responds with a cognito_client.exceptions.LimitExceededException, further referenced as limit exceeded (HTTP 500 response)
An internal server error if something went wrong, the source of this error is unknown to Pentagrid (HTTP 500 response)

An attacker would like to trigger the code mismatch as many times as possible until the password is changed, without triggering the limit exceeded response. The AWS documentation about password resets of AWS Cognito accounts states:

In a given hour, we allow between 5 and 20 attempts for a user to request or enter a password reset code as part of forgot-password and confirm-forgot-password actions. The exact value depends on the risk parameters associated with the requests. Please note that this behaviour is subject to change.

There is no more information from AWS about how exactly the rate limiting is implemented. During our testing the behaviour of this rate limiting was non-deterministic in two ways:

The amount of times the code mismatch message could be triggered before a limit exceeded message was received was non-deterministic. In our tests we were able to trigger between 20 and 1587 code mismatch responses with the used concurrency technique.
Even after the limit exceeded message was received, this does not mean that the code was invalidated. Although an attacker has to wait until the AWS rate limiting cool-down is expired, he can then repeat the attack until a limit exceeded value is received again. In our tests, the limit exceeded could be received at least twice for the same code before the entire attack had to be restarted.

We were able to show that, using a concurrency technique that sends requests simultaneously, it was possible to try up to 1587 codes before being blocked with a limit exceeded message for the first time. 1587 attempts corresponds to a 0.16 % chance to guess the correct code in one attack. As the attacks conducted allowed anywhere between 20 and 1587 guesses, it is unclear how successful an attacker would be if multiple user accounts would be attacked simultaneously.

The approach we used is based on opening several hundred TCP connections simultaneously, send all bytes except the last byte in each of the HTTP requests and then try to simultaneously send the last byte of the requests at once. This technique was developed by James Kettle of PortSwigger and is described in the corresponding blog post "Embracing the billion-request attack". The attack was conducted by using the Turbo Intruder tool created by James Kettle. More specifically, the race.py script of Turbo Intruder was used.

The Turbo Intruder setup is shown in the following picture:

For demonstration purposes, in some of the guesses sent during the attacks, the known correct code was sent which returned an HTTP 200 response, changing the password of the attacked account immediately, which proofed that the attack did work.

The likelihood that an attack succeeds depends on how the undeterministic parts of AWS Cognito would behave during the attack, but we assume successful attacks would have been possible. First, a single attack with a 0.16 % chance means that every 625th attack would succeed. Second, the attack could be repeated at least once for the same code after the cool-down, meaning every 312th attack could succeed. Moreover, the entire attack could be repeated and additionally applied to different AWS Cognito user accounts in parallel to increase the likelihood to succeed at all.

Preconditions

The attacker's requests have to be forwarded to AWS Cognito quickly without disturbing the attack (e.g. no delays or heavy processing)
The attacker has to know valid E-mail addresses with an account on the AWS Cognito instance.
The attacker has to be able to turn the attack into a feasible attack, for example by attacking many accounts at the same time or find a way to trigger the attacker's best-case situation more often and therefore improving the probabilities for the attacker.
The attacked accounts cannot have multi-factor authentication enabled, otherwise the attack fails (although the password will be changed, a login is not possible without the second factor).
The attacked user will get at least one E-mail and depending on how many times the attack is repeated will get several E-mails that include reset codes. The attacked user has to ignore the reset E-mails sent to his mailbox and not alert the AWS customer or AWS about the suspicious E-mails the user did not trigger himself.

Recommendation

The issue was fixed by AWS on 2021-04-20. According to AWS the issue was not actively exploited.
It is recommended to all AWS Cognito customers to require multi-factor authentication on AWS Cognito accounts to improve security.
AWS customers can implement their own rate-limiting before sending requests to AWS Cognito.

Steps to reproduce

As the issues is fixed, it is not reproducible any more. But for future reference we include the steps here:

Setup AWS Lambda with the Chalice library and the necessary AWS Cognito components. The Python program code used in the setup was similar to what is explained on this blog post about AWS cognito with Python but instead of the boto3 library the Chalice library was used. The concurrency and speed of the library might be important for the attack, as concurrency issues in the AWS Cognito service will be exploited. The attack was only tested with the Chalice library. Here is some pseudo-code that shows the most important function that was exploited during our research:

from chalicelib.common.app import app
from chalicelib.common.auth import (cognito_client, get_hmac_digest)

# route the HTTP request to this function
def confirm_forgot_password():
    req = app.current_request
    body = req.json_body
    username = body['username']
    password = body['password']
    code = body['code']
    digest = get_hmac_digest(username)
    resp = cognito_client.confirm_forgot_password(
        ClientId=APP_CLIENT_ID,
        SecretHash=digest,
        Username=username,
        Password=password,
        ConfirmationCode=code)
    # Now make sure that the response from the AWS Cognito server is sent back in the response to the client of this API

Setup an AWS Cognito user account.
Request a password reset via E-mail for the AWS Cognito user account.
Prepare BurpSuite that allows you to repeat HTTP requests.
Send an HTTP request to the confirm_forgot_password AWS Lambda function with an incorrect code, some new password you would like to set and the correct username of the AWS Cognito user account (for example the E-mail address). Make sure you also see the request in BurpSuite. You get an HTTP response that includes code mismatch.
Send an HTTP request to the confirm_forgot_password AWS Lambda function with a correct code. You should get an HTTP response with no error message in it.
Send the incorrect code HTTP request from point 5 about 30 times (e.g. Repeater functionality in BurpSuite). At one point you should get the error cognito_client.exceptions.LimitExceededException.
Wait several hours or use a different AWS Cognito user account, so the limit exceeded does not apply any more.
Request a password reset via E-mail for the AWS Cognito user account
Install Turbo Intruder in BurpSuite.
Send the HTTP request that is sent to the confirm_forgot_password AWS Lambda function to Turbo Intruder.
Choose the race.py preinstalled script of Turbo Intruder.
Replace the code in the HTTP request (for example 123123) with %s to tell Turbo Intruder where to inject
Replace the race.py script part with the following script:

def queueRequests(target, wordlists):
    tries = 800
    engine = RequestEngine(endpoint=target.endpoint,
                           concurrentConnections=tries+10,
                           requestsPerConnection=1000,
                           pipeline=True
                           )

    # the 'gate' argument blocks the final byte of each request until openGate is invoked
    area = 100100
    for i in range(area - int(float(tries)/2), area + int(float(tries)/2)):
        engine.queue(target.req, str(i).zfill(6), gate='race1')

    # wait until every 'race1' tagged request is ready
    # then send the final byte of each request
    # (this method is non-blocking, just like queue)
    engine.openGate('race1')

    engine.complete(timeout=60)

def handleResponse(req, interesting):
    table.add(req)

Click the "Attack" button.
You should see all the HTTP responses after a while. Usually there are at least 20 answers that include the message code mismatch. If you are lucky you can see up to 800 code mismatch responses.
The attack can be repeated until one limit exceeded response is triggered. When it is received, repeat the attack after waiting some time (for example an hour). If you get an answer saying the reset code expired, you have to start the entire attack from scratch.
If you get an HTTP 200 answer, you successfully attacked the user account and reset the password.

Credits

This issue was found by Tobias Ospelt of Pentagrid AG. Pentagrid AG would also like to thank the AWS Security team for the collaboration on this issue.

Burp Suite - solving E-mail and SMS TAN multi-factor authentication with Hackvertor custom tags

Pentagrid AG — Wed, 17 Mar 2021 08:00:00 GMT

Why bother investing time to automate work when doing IT security testing? On one hand, manual testing is a tedious work, where you spend time doing vulnerability tests that could be done by a machine. On the other hand, letting a machine decide fully on its own on how to do tests will mostly result in the machine doing nothing useful. This is especially true for security testing, where manually checking every parameter for injection attacks is very laborious and automated security scanners go on scanning for hours while a human would have aborted the scan for various reasons. However, if we teach automated tools to do things correctly each time, we get the sweet middle spot of semi-automated security testing, where the tools do the automatic and systematic security tests and the analyst can focus on the parts of a security test, where the tools are likely insufficient.

Burp Suite Pro is one of the main tools to do all kind of HTTP related security analysis and that supports a semi-automated testing. But now and then it lacks certain features. Burp extensions can again add some of them. In this post we would like to show how to use one of the most powerful extensions, Hackvertor by Gareth Hayes and its relatively new feature of Python scripting.

Use Hackvertor to generate Swiss social security numbers

Let's start with a simple example. Imagine you are security testing a website and you found an HTTP-API that expects the de facto Swiss social security number [1] as a parameter. Nearly every adult in Switzerland has such a number. After researching, you find out this unique number always starts with 756, followed by two times four random characters and ending with another two random characters like this:

756.9217.0769.85

If you would just like to brute-force random social security numbers in HTTP requests, you could use Burp's Intruder feature that allows you to try generate different numbers. But what if you would like to send a new random number each time you send the request in Burp's Repeater? This is where Hackvertor can be used. In Hackvertor's UI you can search for tags and you should quickly find the random_num tag. The purpose is simply to generate a random number as shown in the input and output field in the following picture:

So generating a new random social security number is as easy as pasting the following value into an HTTP request in Burp's Repeater:

756.<@random_num_0(4) />.<@random_num_1(4) />.<@random_num_2(2) />

For example, the following request can be created in the Burp Repeater:

However, it will not be sent out from Burp as-is and the tags will be replaced by Hackvertor. How does an example request look like when it leaves Burp? This can be observed in the Logger++ extension (another very helpful extension you should use) as shown in the following picture:

This was just an easy example to start. But the truth is, Swiss social security numbers are not fully random and the last character is an EAN13 checksum over the other characters. And instead of sending incorrect social security numbers to a website, how about calculating that checksum in Hackvertor? That's where custom Hackvertor code execution tags come into play. You can write them in JavaScript or Python, we'll use Python here. Hackvertor code execution tags allow you to write code that takes an input (passed in the variable input, that's whatever is put between the tags) and define the output variable. A no-transformation example looks like this:

So here's a little Python one-liner that calculates the checksum number from the nine random numbers that were passed as input and assigns the value to the variable output:

z=input;y=z.replace('.','');output=z+str(10-(sum([3*int(x) for x in y[1:][::-2]])+sum([int(x) for x in y[::-1][1::2]]))%10)[-1]

Defining it as the tag name ean13 and you should get the following picture when you open the tag in the edit window:

Note that the leading underscore is used for every custom tag, so Hackvertor knows it is not a built-in Hackvertor tag. So how do we use such a custom tag?

First of all, there is a security measure so other people that send traffic through your Burp can't execute the custom tag on your Burp machine. Code execution tags are only executed when a certain random token is included in the tag. This means you'll need to create a custom tag in the Hackvertor UI first to get that random token. Creating the custom tag for our ean13 tag in the Hackvertor UI will result in something like this:

So keep in mind that for your Burp installation, that random number in double qutoes will be different. As the output windows in the above picture tells you, code execution tags are still disabled by default for security reasons. This is a second setting you'll need to change. You can enable them in the top main menu of Burp under the Hackvertor item. What you need to do then is to allow code execution tags in Hackvertor:

After that you will probably not see much in the output window of Hackvertor. That's because we have to give our custom tag the correct input. For example:

<@_ean13_3("83a52168fad35b2d85f6972b0eb1db91")>756.9217.0769.8</@_ean13_3>

Now you should see the correct social security number being generated, namely 756.9217.0769.85. And here comes the real power of Hackvertor. Now you can combine the generation of random numbers feature of Hackvertor and our custom tag in a nested form:

<@_ean13_3("83a52168fad35b2d85f6972b0eb1db91")>756.<@random_num_0(4) />.<@random_num_1(4) />.<@random_num_2(1) /></@_ean13_3>

Whenever you send this value in the Burp Repeater, it will be replaced with a random social security number with a correct checksum. Of course you can now not only generate random social security numbers, but you can also generate the random numbers with Burp Intruder and brute-force with valid EAN13 checksums.

In some cases it might be even possible to simply paste the above tags into the browser you use with Burp and the web server will receive a random social security number. However, this only works if the web application you are testing does not encode the values we put into HTML fields and Hackvertor is still able to see the tag exactly as written above. This is rather a rare case, but it might work.

Update 2024-12-06: The EAN-13 tag is available via the Hackvertor tag store.

Use Hackvertor to fetch second-factor authentication token

Let's do a more advanced custom tag example. Could you use the scripting capabilities of Hackvertor to automatically solve TAN second factor verification in multi-factor authentication web forms? At Pentagrid we have an SMS to E-mail gateway for pentesting purposes, meaning if second factor TANs are sent out via SMS or E-mail, they will always land in one of our testing E-mail inboxes. Can we retrieve the second factor TAN tokens from the E-mail inbox with a Hackvertor tag? Yes we can, with the very useful Python imaplib and an E-mail server that supports IMAP. Of course the entire parsing logic for the incoming TANs is highly dependent on the web application and how the SMS or E-mails look like. You will need to change the parsing code according to your needs. So here's a quick'n'dirty example that worked for us for a certain web application. We created the new Hackvertor tag like this:

import getpass, imaplib
import time

time.sleep(0.1)

class Email:
    def __init__(self, data):
        self.data = data.decode()
        self.body = "\r\n\r\n".join(self.data.split("\r\n\r\n")[1:])

M = imaplib.IMAP4_SSL(host='use-your-own-mail-host') # warning: no certificate verification
M.login("pentagrid@example.org", "email-password")
M.select()
typ, data = M.search(None, 'ALL')
token = "NO TOKEN WAS FOUND"
for num in data[0].split()[::-1]:
    typ, data = M.fetch(num, '(RFC822)')
    email = Email(data[0][1])
    for line in email.body.splitlines():
        #print(line)
        if line.startswith("Your TAN is: "):
            token = line.split("Your TAN is: ")[1].strip()
    if token:
        print(token)
        break
    else:
        print("No token found")
    #print('Message %s\n%s\n' % (num, data[0][1]))
print("Final token:", token)
output = token
M.close()
M.logout()

The Python code will login to the IMAP mailbox, retrieve E-mails starting with the newest, quick'n'dirty parse the TAN from the E-mail by interating through each line of the E-mail and assign the the first token found to the output variable that Hackvertor expects. You might need to play with the sleep delay we introduced at the beginning of the script to make sure the E-mail reaches the mailbox before you try to retrieve it. Otherwise you could change the script to only consider the very newest E-mail but you would need to take care to delete old E-mails. And of course you need to change your E-mail server, username and password. Please be aware that this is as well not thread-safe, you would need a seperate E-mail mailbox for each thread to make it concurrent.

Configuring a search and replace rule in the Burp Proxy to replace any second factor you enter with the Hackvertor tab is left as an exercise to the reader. We were able to test websites without ever entering the second factor manually again, as the entered token was replaced with a Hackvertor tag and Hackvertor fetched the token from the mailbox.

Hackvertor is therefore the perfect solution if you would like to script things that are sent in HTTP requests. With the new scripting capabilities, it is not necessary to write extensions when you want to change things sent out. Or do you? Unfortunately, there are certain limitations with this approach and in Burp. The search and replace rule for the Proxy of course only works for the Burp Proxy. But what if we want to make the Burp Crawler be able to login with second-factor TANs? We can't use session handling rules (another advanced topic of Burp), as they don't apply for Burp Crawler. But we were able to write an extension that handles that part, but that's for another blog post (it is really cool to see the headed browser of Burp login correctly). And what if you would also like to modify HTTP responses? Or what if you would like to even enhance Burp with a Transfer-Encoding feature it does not yet support? Do you want to know how you could set up an SMS to E-mail gateway? Stay tuned for our next blog posts, subscribe to our RSS feed or follow us on Twitter or LinkedIn.

Update 2025-06-04: An update of Hackvertor in 2025 changed the style of closing elements from <@/name> to </@name>. Therefore, we updated the post, but not the screenshots.

Block browser requests to Google during security analysis in Burp

Pentagrid AG — Wed, 04 Nov 2020 09:00:00 GMT

How to stop Portswigger's Burp Proxy's built-in Chromium browser to leak information to Google's Safe Browsing during a web application penetration test?

When doing web application security research and penetration tests for customers, we sometimes get insights into tools we use that seem weird and undesired. A while ago we were testing a financial website with confidential data with the Mozilla Firefox browser and Firefox was sending the following requests whenever we downloaded a PDF from the website:

POST /safebrowsing/clientreport/download?key=%GOOGLE_SAFEBROWSING_API_KEY% HTTP/1.1
Host: sb-ssl.google.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:70.0) Gecko/20100101 Firefox/70.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/octet-stream
Content-Length: 189
Connection: close

blob:https://www.example.org/6f75423b-3828-5e4b-8241-3e633c684041___________
Dblob:https://www.example.org/6f75423b-3828-5e4b-8241-3e633c684041___
txt_download_name_file_overview.pdf
[...]

As you can see, Firefox leaks the PDF file name we were downloading, the hostname of the website we were testing and some more binary data that could include a file hash. On one side we were happy that we found this privacy issue and could report it to our customer, because this browser behaviour affects normal users. On the other side we do not want our testing tools to behave like this. Safebrowsing can be disabled via the pentest browser's settings menu or by setting these values in about:config and it must be done for every web application test browser in use:

browser.safebrowsing.malware.enabled = false
browser.safebrowsing.phishing.enabled = false

In the meantime the Portswigger Burp proxy we use regularly and write extensions for was updated to include a new feature: A builtin Chromium browser. We really appreciate the added usability and were happy to use this feature in a security analysis in a corporate Windows AD environment, where changing proxy settings was not allowed for the preinstalled browser. Fortunately because we asked our customer to install Burp with administrative privileges, the built-in Chromium browser of Burp could be used. However, we noticed that the preconfigured Chromium browser was again very verbose and contacted Google servers, especially during startup. As we would like to keep all information about our security analysis to our customers and ourselves, we avoid any third-party services wherever feasible. That's why we operate and use our own Burp Collaborator server, for example.

It is possible to disable the Safe Browsing feature in the browser used to perform web application pentests. However, if it is necessary to switch the browser, these settings must be changed there as well and the approach does not really work for the the built-in Chromium browser, because its settings are reset on every start. The easiest solution is to control traffic in the Burp Proxy: We can abuse the Upstream-Proxy setting found in "User options - Connections" in Burp for this purpose. While the following approach will block the requests from reaching the Google servers, they will still show up in the history tab of Burp.

Download google-blocking.json.
In Burp, go to "User options - Connection".
On the left of the "Upstream Proxy Servers" headline, click the settings and chose "Load options".
Chose the file you just downloaded and press "OK". Then, the upstream proxy settings look like in the screenshot below.

This configuration will redirect requests to most Google domains to TCP port 1337 on localhost, which is (hopefully) a dead end. It is possible to use the file as a Burp startup configuration, or even better, merge it with your existing startup configuration by editing the Burp settings JSON file manually. Then, your are able to use these Burp settings in new projects as well.

A drawback of the approach is that your test browser cannot be used for Google searches afterwards and it may break functionality if the tested sites requires resources from Google of course. However, it is recommended to use separate browsers for regular work and for web application testing anyway, because they are configured for different purposes.