Pentagrid AG (Einträge über Multi-Factor Authentication)

EAN-13- und TOTP-Hackvertor-Tags für Penetrationstests von Webanwendungen mit Burp

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

Hackvertor ist ein Standalone-Werkzeug und eine Erweiterung für das Penetrationstest-Tool Burp Suite. Gareth Heyes vom Portswigger Research Team hat Hackvertor entwickelt. Die Erweiterung führt dynamische Datenkonvertierungen durch. Das Tool kann beispielsweise dazu verwendet werden, Datenfelder als Base64 zu kodieren, bevor Burp eine HTTP-POST-Anfrage an einen Server sendet. Dies geschieht automatisch und es ist nicht notwendig, Daten manuell zu konvertieren oder zwischen verschiedenen Fenstern zu kopieren.

In unserem Blog schrieben wir über das Generieren schweizer Sozialversicherungsnummern bei einem Pentest und das Programmieren benutzerdefinierter Hackvertor-Tags. Es gibt verschiedene Arten von Tags. Viele sind bereits in Hackvertor integriert und Benutzer können darüber hinaus ihre eigenen Tags programmieren. Hackvertor verfügt mittlerweile über einen öffentlichen Tag Store, in dem Benutzer Tags einreichen können. Pentagrid hat nun zwei Tags entwickelt und im Hackvertor-Tag-Store veröffentlich. Ein Hackvertor-Tag dient der Prüfziffernberechnung von EAN-13-Codes und ein anderes für die Berechnung von Time-based one-time Passwords (TOTP).

Wie bereits in unserem Blog-Beitrag „Burp eine neue HTTP-Transportkodierung beibringen“ erläutert, ist das Anpassen von Tests in Burp ein wichtiges Instrument, um Tests zu automatisieren und eine hohe Test-Coverage bei einer Sicherheitsuntersuchung zu erzielen.

EAN-13-Hackvertor-Tag

EAN ist die European Article Number, ein Standard zur Kodierung von Artikelnummern. Und obwohl sie eher international als europäisch geworden ist und jetzt Global Trade Item Number heißt, wird dieses Artikelnummernformat oft noch als EAN-13 bezeichnet. Schweizer AHV-Nummern verwenden die Prüfsummenberechnung von EAN-13 und speichern die Prüfsumme als 13. Zeichen.

Den benutzerdefinierte Tag-Code aus unserem Blog-Artikel haben wir als Hackvertor-Tag im Tag Store veröffentlicht. Das EAN-13-Tag wird wie in den folgenden beiden Beispielen verwendet:

# 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

An der Stelle der Auslassung [...] muss ein sogenannter Ausführungsschlüssel eingefügt werden. Die Hackvertor-Extension für Burp fügt den Code-Ausführungsschlüssel automatisch hinzu, wenn die Tags im Hackvertor-Tab in Burp vorbereitet und verwendet werden. Der Ausführungsschlüssel ist eine zufällige Zeichenfolge von 40 Hex-Ziffern, der verhindert, dass mit Burp verarbeitete Webseiten schädliche Aktionen in Burp auslösen. Burp würfelt bei jedem Start einen neuen Ausführungsschlüssel. Nur Codeausführungs-Tags (mit benutzerdefiniertem Code, wie z. B. die im Tag Store) benötigen einen Codeausführungsschlüssel.

TOTP-Hackvertor-Tag

Pentagrid implementierte ebenfalls ein Hackvertor-Tag für TOTP. Dieser zeitbasierte Token wird für Zweifaktor-Authentifizierung verwendet. Wenn während des Penetrationstests ein derartiger Token notwendig ist, kann das Hackvertor-Tag verwendet werden. Der Code wurde kürzlich dem Tag Store hinzugefügt. Um das TOTP-Tag zu verwenden, extrahiert man den Initialisierungswert aus dem QR-Code, der ausgehändigt wurde, um ihn mit einer Authentifikator-App zu scannen. Das Kommandozeilenwerkzeug zbarimg kann den Inhalt des QR-Codes aus einer Bilddatei auslesen:

% 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

Das Hackervertor-Tag kann dann analog zu diesem Beispiel verwendet werden:

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

Es gibt mehrere Parameter für TOTP. Das Tag unterstützt nur die in der Praxis häufig verwendeten Parameter SHA1, 30 Sekunden und 6 Ziffern. Falls in der freien Wildbahn andere Konfiguration genutzt werden, sollte es recht einfach sein, das benutzerdefinierte Tag anzupassen.

Um auf den Tag Store zuzugreifen, gehen Sie einfach zum Menüeintrag „View tag store“ im Hackvertor-Menü in Burp und installieren die gewünschten Erweiterungen. Stellen Sie dann auch sicher, dass Sie die Codeausführungs-Tags über den Menüeintrag „Allow code execution tags“ im Hackvertor-Menü in Burp zulassen.

Update 2025-06-04: Eine Aktualisierung von Hackvertor in 2025 änderte den Stil für schliessende Elemente von <@/name> nach </@name>. Daher haben wir den Beitrag aktualisiert.

Ein Open-Source-SMS-Gateway für Pentest-Projekte

Pentagrid AG — Tue, 06 Dec 2022 08:23:00 GMT

Zugänge für mobile Anwendungen sind oft an Telefonnummern gebunden. Die Arbeit mit mehreren Personen an einem Projekt kann es irgendwann erfordern, Mobiltelefonnummern für den SMS-Empfang zu teilen. Beim Testen mobiler Anwendungen, die durch eine SMS-basierte Second-Factor-Authentisierung (2FA) geschützt sind, ist die gemeinsame Nutzung von Telefonnummern durch das Testteam manchmal notwendig und sicherheitstechnisch akzeptabel, wenn es sich nur um ein Testsystem handelt. Bei Pentagrid betreiben wir daher ein kleines SMS-Gateway, das wir hiermit als Open Source veröffentlichen.

Motivation

Mit SMS als zweitem Authentisierungsfaktor, sendet ein Zielsystem eine SMS an ein Mobiltelefon, und der Prüfer gibt das Token dann manuell in den Webbrowser ein. Während dies für die normale Arbeit noch einigermaßen praktikabel ist, ist es bei einem Penetrationstest ziemlich ineffizient. Insbesondere, wenn die Serverseite die Sitzung hin und wieder invalidiert, weil die getestete Anwendung die Eingabe nicht mag und lediglich die Ablehnung der HTTP-Anfrage von den Softwareentwicklern als nicht schmerzhaft genug erachtet wurde. Wenn ein System nicht dafür ausgelegt ist, mit halbautomatischen Tools wie dem Burp Proxy getestet zu werden, kann 2FA oft nicht einfach für bestimmte Testkonten deaktiviert werden. Um ein solches System dennoch testen zu können, ist es sinnvoll, den zweiten Faktor in den Burp Proxy einzubinden.

Es gibt viele kommerzielle SMS-Gateways, die eine API für den Versand und Empfang von SMS anbieten. Da der Token jedoch ein Authentisierungsfaktor ist, wenn auch nur ein Teil des gesamten Prozesses, ist die Weitergabe dieser sensiblen Informationen an Dritte keine Option, auch nicht für Testsysteme. Aus diesem Grund haben wir ein SMS-Gateway implementiert, um Drittanbieter-Infrastruktur zu vermeiden.

Ansatz

Es gibt ebenfalls einige Mobil-Applikationen für das Weiterleiten von SMS, die auf einem Mobiltelefon eingehende Kurznachrichtenan eine Ziel-E-Mail-Adresse weiterleiten. Das funktioniert, aber die Methode hat Nachteile. Sie erhöht Abhängigkeiten: Man muss zusätzlich dem Anwendungsentwickler, dem E-Mail-Anbieter (wenn man sich dabei auf einen Drittanbieter verlässt) und letztlich auch anderen Anwendungen auf dem Mobiltelefon vertrauen - zumindest zu einem gewissen Grad. Der Ansatz ist zudem nicht gut skalierbar. In der Regel kann ein Telefon bis zu zwei physische SIM-Karten aufnehmen. Für drei oder mehr SIM-Karten wären zusätzliche Telefone erforderlich. Außerdem wird Service-Monitoring kaum unterstützt. Um zu prüfen, ob die Weiterleitungsanwendung noch funktioniert, ist die fast einzige Möglichkeit eine Ende-zu-Ende-Prüfung, die das Senden einer SMS und den Empfang einer Mail umfasst.

Um diese Nachteile zu vermeiden, haben wir ein SMS-Gateway implementiert, dessen Hauptzweck der Empfang von SMS ist. Es ist außerdem möglich, SMS zu senden, was wir für den Versand von Alarmmeldungen bei der Serverüberwachung nutzen, aber das war nicht der Fokus.

In dieser ersten Version bietet der SMS-Gateway die folgenden Funktionen:

Verwalten eines Modempools
Empfangen und Senden von SMS
Weiterleiten empfangener SMS an eine Mailadresse
Senden und Abrufen von SMS über eine XMLRPC-Schnittstelle
Unterstützung für Unstructured Supplementary Service Data, also USSD-Codes für das Aufladen von Prepaid-SIM-Karten
Unterstützung von TLS
Integration von Icinga2/Nagios für die Prüfung des inneren Funktionszustandes
Integration von Munin für ein paar Statistiken

Implementation und Betriebsmodus

Der SMS-Gateway ist als Python-Programm für Linux implementiert. Das Modul python-gsmmodem bildet die Schnittstelle zum Modem und verarbeitet Modembefehle. Dazu läuft jedes Modem in seinem eigenen Thread. Mehrere Modems werden zu einem Modem-Pool zusammengefasst, der es uns ermöglicht, mehrere SIM-Karten parallel zu betreiben. Der Modem-Pool überwacht den Gesundheitszustand jedes Modems, einschließlich der seriellen Verbindung zum Modem, der Signalstärke und des Kontostandes bei Prepaid-SIM-Karten. Außerdem versucht der Modem-Pool, die Modems im Falle von Problemen neu zu initialisieren.

Wenn ein Modem eine SMS empfängt, wird sie in eine interne Queue eingetragen. Ein Client holt die SMS über die API eines integrierten XMLRPC-Servers ab, der auf der Netzwerk-Engine Twisted basiert. Alternativ ist das SMS-Gateway in der Lage, eingehende SMS über SMTPS an eine Ziel-Mailbox zuzustellen. Die SMS-Weiterleitung über SMTPS wird auch als Health-Check überwacht. Wenn es ein Problem mit der SMTPS-Verbindung gibt, schlägt der Health-Check folglich fehl.

Mit einem XMLRPC-Client kann man mit dem XMLRPC-Server interagieren. Ein XMLRPC-Client kann empfangene SMS abrufen. Die API dafür ist einfach gehalten. Es gibt keine Benutzerverwaltung. Stattdessen autorisiert der XMLRPC-Server Vorgänge mittels API-Token, welche der Client beim Aufruf von Remote-API-Funktionen als Parameter übergibt. Der Server speichert berechtigte API-Token als Hash in einer Konfigurationsdatei und prüft die Token bei Anfragen auf Gültigkeit. Dabei unterscheidet der XMLRPC-Server API-Token für den allgemeinen Abruf von SMS, für den Abruf von SMS für einzelne Modems, für den Versand von USSD-Codes, für den Versand von SMS, für die Abfrage des Zustellungsstatus von SMS und für Überwachungs- und Statistikzwecke.

Das SMS-Gateway wird mit einem Munin- und einem Icinga-/Nagios-Plugin ausgeliefert, um die Betriebsüberwachung zu unterstützen. Die Monitoring-Plugins sind als XMLRPC-Clients implementiert, die Zustandsinformationen bzw. Statistiken vom XMLRPC-Server abrufen.

Das SMS-Gateway unterstützt ebenfalls den Versand von SMS. Das birgt allerdings das Risiko, dass SMS an Premiumdienste versendet werden und erhebliche Kosten verursachen. Ebenfalls lassem sich eventuell Buchungsoptionen ändern. Daher kann das Versenden von SMS über eine Präfix-Liste für erlaubte Ziele eingeschränkt werden.

Betrieb einer eigenen Installation

Wir haben den Quellcode des SMS-Gateways auf Github veröffentlicht, zusammen mit weiterer Dokumentation, wie man ein solches Gateway einrichtet. Es sollte gängige 2G-/3G-/4G-/5G-Modems unterstützen. Im einfachsten Fall könnte man Plastik-USB-Modem-Sticks verwenden, die als "Surfstick" oder ähnlich gehandelt werden.

Wie man den SMS-Gateway automatisiert nutzen kann, um während des Testens mit der Portswigger Burp Suite keine 2FA-Tokens eingeben zu müssen, erfährt man in unserem englischen Blog-Post Burp Suite - solving E-mail and SMS TAN multi-factor authentication with Hackvertor custom tags.

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.