Pentagrid AG (Einträge über Tools)

Parsing modern ASP.NET Core Identity password hashes to Hashcat

Yannic Hemmer, Pentagrid AG — Wed, 03 Jun 2026 09:23:00 GMT

While this would not be anything out of the ordinary, the environment certainly was. So where do we expect ASP.NET Core Identity hashes? Some obscure cloud application, local Windows application, ... but surely not on an embedded linux system!?

While the vulnerability itself was discovered at this point - exposing password hashes without any authentication is not exactly considered best practice - it was decided to investigate the password hashes further in an attempt to showcase password cracking and detect weak passwords.

Despite numerous tools on the internet advertising the capability of converting ASP.NET Core Identity hashes into Hashcat format, all attempts at cracking the extracted password hashes remained unsuccessful despite knowing some pairs of plaintext passwords and ASP.NET Core Identity hashes.

Why? It was time to dig in!

No Country for Old Hashes: Cracking ASP.NET Core Identity with Hashcat

Before we look at why all of the current tools fail to correctly convert ASP.NET Core Identity hashes into Hashcat format, let us establish some background on the ASP.NET Core Identity Hashes.

ASP.NET Core Identity Hashes

Offical documentation from Microsoft on the structure is sparse. Luckily some amazing blog posts have been written by Filip W. and Rui Figueiredo. To avoid regurgitating their entire works and opinions here, we are going to provide a brief overview of ASP.NET Core Identity password hashes:

ASP.NET Core Identity hashes are base64-encoded byte structures split into multiple sets of magic length and values.

The magic marker starts at the first byte, notated in the following as [0], called the format marker (mostly referred to as version) where we must differentiate between ASP.NET Core Identity v2 and v3 hashes.

The old v2 hashes have a non-configurable structure: The format marker is followed by the salt [1,16] consisting of 16 bytes and the subkey [17,49] with 32 bytes. The key derivation PRF (pseudo-random function) is PBKDF2+HMAC-SHA1 with 1,000 iterations, taking the password and salt as input and producing the 32 bytes long subkey.

With the introduction of ASP.NET Core Identity v3 hashes, the key derivation PRF, number of iterations, length of the salt, and length of the subkey can be customized. The PRF [1,4] can be chosen based on the KeyDerivationPrf enum [3]: either HMACSHA1, HMACSHA256, or HMACSHA512.

The number of iterations (ITER) [5,8] in combination with the chosen PRF defines the work factor.

The length of the salt (SALTLEN) [9,12] is the input of a random number generator which generates the salt. The interval of the salt [13,(13+SALTLEN-1)] therefore depends on this length of the salt.

After the salt, the actual subkey follows. The length of the subkey is not stored inside the ASP.NET Core Identity hash. Therefore, the only way to determine the length of the subkey is to read the byte structure until the end of the input [(13+SALTLEN-1), EOL]. Here, EOL represents the index of the last byte of the structure.

Diving into the implementation in .NET, the PasswordHasher class provides two methods of creating v3 hashes by overloading the HashPasswordV3 method [3]. The first method is a convenience wrapper of the second using static magic values. Here, PRF is set to HMAC-SHA512 (HMAC-SHA256 for .NET versions <7.0), ITER to 100,000 (10,000 for .NET versions <7.0), and SALTLEN to 16. Additionally, 32 bytes are requested back from the PRF (length of the subkey). These values are most often referenced as "default values".

The non-wrapped method allows unrestricted configuration of these values. There is no apparent limit on ITER, SALTLEN, and number of requested subkey bytes. Only the PRF is constrained by the enum Microsoft.AspNetCore.Cryptography.KeyDerivation [4].

While we did not encounter any example that deviates from these "default values", simply assuming static magic values when reading a v3 hash will result in incorrect handling for the "non-default" ASP.NET Core Identity v3 hashes.

The following Listing shows the above described structure of ASP.NET Core Identity hashes:

| [0] | ...
   |
   '--> 0x00 ASP.NET Core Identity hashing logic version v2
   |    | [0]  | [1,16] | [17,49] |
   |    | 0x00 | SALT   | SUBKEY  |
   |
   '--> 0x01 ASP.NET Core Identity hashing logic version v3
        | [0]  | [1,4] | [5,8] | [9,12]  | [13,(13+SALTLEN-1)] | [(13+SALTLEN),EOL] |
        | 0x01 | PRF   | ITER  | SALTLEN | SALT                | SUBKEY             |
                   |       |
                   |       ' -->  10,000 (HMAC-SHA256 .NET < 7.0 default)
                   |       ' --> 100,000 (HMAC-SHA512 .NET >= 7.0 default)
                   |
                   ' --> 0x00 HMAC-SHA1
                   ' --> 0x01 HMAC-SHA256
                   ' --> 0x02 HMAC-SHA512
   ASP.NET_IDENTITY_HASH_...
       SALT (32 bytes)    --> Password salt used in PBKDF2+HMAC-SHA{1,256,512} function
       SUBKEY (32 bytes)  --> Result of PBKDF2+HMAC-SHA{1,256,512}

       (only v2 -- method HashPasswordV2 in [#1]_)
       Number of iterations: 1,000 (static)
       Length of the salt: 16 bytes (static)
       Length of the subkey: 32 bytes (static)

       (only v3 -- method HashPasswordV3 in [#1]_)
       PRF  (uint32BE)    --> Pseudo-random function used for key derivation (see [#2]_)
       ITER (uint32BE)    --> Number of iterations the hashing algorithm is applied
       SALTLEN (uint32BE) --> Length of the salt (saltSize)

ASP.NET Core Idenity Hash to Hashcat Format Convertion

To generate valid Hashcat format from ASP.NET Core Identity hashes, the PRF, number of iterations, salt, and subkey must be brought into the following structure:

<PRF>:<ITER>:<base64enc(SALT)>:<base64enc(SUBKEY)>

Let us do this process for the following ASP.NET Core Identity password hash:

AQAAAAIAAYagAAAAEPcrvDihsovZNHxRFrv1y3i4qfjKsXn+JzKD7AOIlxe5YSb/s+tMXJVQeU1//VQXow==

Base64-decoded and structured:

01 := (0x) ASP.NET Core Identity v3 hash
00000002 := (0x) HMAC-SHA512
000186a0 := (0x) 0d100,000 iterations
f7 2b bc 38 a1 b2 8b d9 34 7c 51 16 bb f5 cb 78 := salt
b8 a9 f8 ca b1 79 fe 27 32 83 ec 03 88 97 17 b9 61 26 ff b3 eb 4c 5c 95 50 79 4d 7f fd 54 17 a3 := subkey

ASP.NET Core Identity v3 hash PRF, iterations, salt, and subkey converted to Hashcat format:

sha512:100000:9yu8OKGyi9k0fFEWu/XLeA==:uKn4yrF5/icyg+wDiJcXuWEm/7PrTFyVUHlNf/1UF6M=

When attempting to break the ASP.NET Core Identity hashes with Hashcat, we need to ensure that Hashcat correctly identifies the hash type or set it manually with the hash-mode (aka hash-type). This also means that we need to use multiple Hashcat runs when encountering differing PRFs. Ideally, the hashes with differing PRFs are split into multiple files.

Table showing the different hash types per ASP.NET version/format marker and .NET versions, as well as the corresponding Hashcat hash-mode (`-m` parameter).
ASP.NET version	Hash type	Hashcat hash-mode
v2, v3	PBKDF2+HMAC-SHA1	12000
v3	PBKDF2+HMAC-SHA256	10900
v3 (.NET > 7.0)	PBKDF2+HMAC-SHA512	12100

Current Tooling

From what we have seen so far, the process of converting ASP.NET Core Identity hashes seems a bit convoluted due to their magic structure, but otherwise relatively straightforward.

So what occurred during initial attempts of converting the hash with one of the available tools? The tried tools being:

ASP.NETIdentity2hashcat and identity-to-hashcat both lack the support for ASP.NET Core Identity v3 hashes from .NET versions 7.0 or higher. Instead, they wrongfully default to a statically set SHA256 as the PRF.

Further, ASP.NETIdentity2hashcat uses the wrong byte interval for the number of iterations, returning the encoded PRF enum instead.

ASP.NET Identity seems to use a more solid approach by using the AspNetIdentityHashInfo class from the NetDevPack.Utilities namespace instead of using their own implementation. Yet similarly, this falls short of .NET version 7.0 and higher compatibility. In this case it was necessary to dig deeper to find out why the resulting Hashcat hashes cannot be broken. The answer lies in the NetDevPack repo on commit b3106b8. Therefore, all three tools do not handle configured ASP.NET Core Identity v3 hashes: Only SHA256 support as well as the default values for the length of the salt and length of subkey are statically assumed as 16 and 32 bytes respectively.

Instead of displaying any warnings or errors, the tools report back false PRFs, salts, and subkeys.

TL;DR. The tested tools lack support for the PRF HMAC-SHA512 which was introduced with .NET version 7.0 (which was released in 2022). We need a tool that supports all currently supported ASP.NET Core Identity hashes and .NET versions.

Contributions

Instead of extending one of the existing tools, a ground-up approach was taken to reach the following goals:

Clear type system for the structured components of ASP.NET Core Identity hashes. Errors are thrown if parsed content does not fit type system. Type system can be extended for future .NET releases.
Input of ASP.NET Core Identity hashes:
- Capability to parse large numbers of ASP.NET Core Identity hashes at once. This allows us to parse entire excerpts of real-world ASP.NET Core Identity databases which may hold hundreds of user entries.
- Allow annotations of the hashes which can be used for usernames, suspected passwords, or other remarks.
Output of Hashcat formatted hashes:
- Structured output split by PRF due to Hashcat expecting only a single hash type in its input file.
- Annotations from input file can be prepended to the formatted hashes for compatibility with the Hashcat --username option.
Documentation on the ASP.NET Core Identity structure, conversion process, and supported versions/PRFs. At time of writing v2 and v3 (PBKDF2+HMAC-SHA{1,256,512}) with default or custom configuration hashes are supported.
Test cases for all "default variants" of ASP.NET Core Identity hashes to confirm proper conversion.
Verbose output options to allow debugging.

The conversion script is hosted at Codeberg and at Github.

Recommendation for ASP.NET Core Identity Production Use

If you are using ASP.NET Core Identity hashes for authentication, we strongly recommend reviewing the work effort of all stored hashes. OWASP publishes and continuously updates their recommendations for the work effort of PBKDF2. The .NET "defaults" do not meet these recommendations at all:

Table showing the number of iterations over different key derivation/hashing algorithms used as .NET "defaults", which represents the work effort, compared to the OWASP recommendations as of 2026-06-01.
Key derivation and hash	.NET "defaults"	OWASP recommendations
PBKDF2+HMAC-SHA1	1,000	1,400,000 iterations
PBKDF2+HMAC-SHA256	10,000	600,000 iterations
PBKDF2+HMAC-SHA512	100,000	220,000 iterations

To the best of our knowledge, newly created "default" ASP.NET Core Identity v3 hashes for .NET version 7.0+ use PBKDF2-HMAC-SHA512 which only lags behind the OWASP recommendations by a factor of two.

.NET versions below 7.0 ASP.NET Core Identity v3 "default" hashes use PBKDF2-HMAC-SHA256 with work effort an order of magnitude lower than recommended by OWASP.

Regardless of the .NET version: If ASP.NET Core Identity v2 hashes are generated, PBKDF2-HMAC-SHA1 with 1,000 iterations will always be used. This is multiple magnitudes below current OWASP recommendations. It cannot be customized. This poses direct risk by allowing attackers to break hashed and salted passwords without major computational and time effort. Therefore, v2 hashes are always a bad sign.

Perhaps it would be a good time for Microsoft to set their own standards or mandate those of others, rather than passing the buck down to developers and customers.

ISO 20022, Pain001 and payment of your salary

Pentagrid AG — Fri, 21 Nov 2025 13:30:00 GMT

At Pentagrid, we occasionally review our clients' internal processes to identify IT security risks. When we discovered that large sums of money are transferred with just a few clicks and no transaction verification, we helped securing the process. At the same time, we developed a tool to support this improvement.

The following blog post outlines the complexity of pain.001 files, the risk of transfering payment files via insecure channels and the problem of reviewing payment details when the pain.001 file is uploaded into an e-banking interface. Pentagrid's tool follows a diff-like approach to detect changes among monthly payments. The "riskless pain" tool is available on Github.

Introduction to ISO 20022, pain.001 and salary payments

If you get paid a salary, it is likely that the payment will be transfered to the bank as part of a pain.001 file. In national and international banking, there is a common (and machine-readable) way of talking about such bank payments and other transactions. ISO 20022 defines this "standard for electronic data interchange". One part of it is Customer Credit Transfer Initiation (pain.001). As the name implies, it is used when a bank customer (e.g. a company) would like to instruct the bank to make payments. In essence, it is a standardised XML message saying something like Please use my account with IBAN CH9999999910378969399 to pay CHF 500.00 to Bob Foo, Zurich with IBAN LI7008805599999999999.

The pain.001 format supports thousand of payments in one single file. It also accommodates a wide range of special cases, including intermediary banks and cheques, which leads to complexity. This complexity is the first challenge: While verifying a pain.001 file against its XML schema is straightforward, ensuring that it matches the human intent behind the payment is not. The complexity increases when supporting all the various formats and versions. There are old formats/specifications and new ones (versions) as well as country-specific specifications. Especially the old specifications include questionable design decisions. For instance, the old Swiss format uses the <BIC> tag to represent a bank's clearing number, while newer international formats use <BICFI> for the actual Bank Identifier Code. Add to this the many optional fields, and it becomes easy to generate a technically valid but semantically dubious pain.001 file.

Let's look at an example of Please use my account with IBAN CH9999999910378969399 to pay CHF 500.00 to Bob Foo, Zurich with IBAN LI7008805599999999999. The follwing XML file is in the new Swiss format pain.001.001.09.ch.03:

<?xml version="1.0" encoding="UTF-8"?>
<Document
    xmlns="urn:iso:std:iso:20022:tech:xsd:pain.001.001.09"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:iso:std:iso:20022:tech:xsd:pain.001.001.09 pain.001.001.09.ch.03.xsd">
    <CstmrCdtTrfInitn>
        <GrpHdr>
            <MsgId>MSG-2025-05-21T13:44:43</MsgId>
            <CreDtTm>2025-05-21T13:44:43</CreDtTm>
            <NbOfTxs>1</NbOfTxs>
            <CtrlSum>500.0</CtrlSum>
            <InitgPty>
                <Nm>Example AG</Nm>
                <CtctDtls>
                    <Othr>
                        <ChanlTp>NAME</ChanlTp>
                        <Id>Infoniqa ONE Start </Id>
                    </Othr>
                    <Othr>
                        <ChanlTp>VRSN</ChanlTp>
                        <Id>V-2025.00)</Id>
                    </Othr>
                    <Othr>
                        <ChanlTp>PRVD</ChanlTp>
                        <Id>Infoniqa Schweiz AG</Id>
                    </Othr>
                    <Othr>
                        <ChanlTp>SPSV</ChanlTp>
                        <Id>2.0</Id>
                    </Othr>
                </CtctDtls>
            </InitgPty>
        </GrpHdr>
        <PmtInf>
            <PmtInfId>PMTINF-2025-05-21T13:44:43-1</PmtInfId>
            <PmtMtd>TRF</PmtMtd>
            <BtchBookg>true</BtchBookg>
            <PmtTpInf>
                <CtgyPurp>
                    <Cd>SALA</Cd>
                </CtgyPurp>
            </PmtTpInf>
            <ReqdExctnDt>
                <Dt>2025-05-26</Dt>
            </ReqdExctnDt>
            <Dbtr>
                <Nm>Example AG</Nm>
            </Dbtr>
            <DbtrAcct>
                <Id>
                    <IBAN>CH9999999910378969399</IBAN>
                </Id>
                <Tp>
                    <Prtry>CND</Prtry>
                </Tp>
            </DbtrAcct>
            <DbtrAgt>
                <FinInstnId>
                    <ClrSysMmbId>
                        <ClrSysId>
                            <Cd>CHBCC</Cd>
                        </ClrSysId>
                        <MmbId>774</MmbId>
                    </ClrSysMmbId>
                </FinInstnId>
            </DbtrAgt>
            <CdtTrfTxInf>
                <PmtId>
                    <InstrId>287</InstrId>
                    <EndToEndId>001283545D024C86401A11A21A2B12CF</EndToEndId>
                </PmtId>
                <Amt>
                    <InstdAmt Ccy="CHF">500.00</InstdAmt>
                </Amt>
                <CdtrAgt>
                    <FinInstnId>
                        <BICFI>LILALI2XXXX</BICFI>
                    </FinInstnId>
                </CdtrAgt>
                <Cdtr>
                    <Nm>Bob Foo</Nm>
                    <PstlAdr>
                        <StrtNm>Foo 13</StrtNm>
                        <PstCd>8400</PstCd>
                        <TwnNm>Zurich</TwnNm>
                        <Ctry>CH</Ctry>
                    </PstlAdr>
                </Cdtr>
                <CdtrAcct>
                    <Id>
                        <IBAN>LI7008805599999999999</IBAN>
                    </Id>
                </CdtrAcct>
                <RmtInf/>
            </CdtTrfTxInf>
        </PmtInf>
    </CstmrCdtTrfInitn>
</Document>

Some of the complexity we encounter in these files may be intentional and necessary for certain use cases. However, from our perspective, it also introduces potential issues. For instance, while the pain.001 file explicitly specifies the recipient's bank using a BIC (e.g., LILALI2XXXX), the IBAN itself also encodes a bank identifier (in this case, the LI7008 prefix). So what happens if the bank indicated by the IBAN doesn't match the one specified in the BIC? Which one takes precedence? This scenario is likely addressed somewhere in the ISO 20022 specification. But it's easy to get wrong in practice. We suspect there are financial systems out there that mishandle such discrepancies.

Trust or how the file reaches the bank

Obviously, if you instruct your bank to do a payment with an attacker-controlled pain001 file, this is bad news and your money (which was supposed to be your employee's salaries) is gone.

You might say that an untrusted pain001 file should never reach the bank and you are absolutely right. In theory, you should trust whatever creates such files, such as your book keeping software (e.g. Infoniqa, SAGE, Bexio, Abacus just to name a few here in Switzerland). But how does the XML file from your software reach the bank?

One option (at least here in Switzerland) is to transfer the pain001 file directly from the book keeping software to the bank via EBICS. EBICS is again a different standard, an XML protocol used to login to the bank account and then send the pain001 file (yes, XML in XML). The protocol can be used to do a lot of other things, too. EBICS has it's own complexity we don't want to look at today (e.g. your book keeping software has access to your bank account) but at least nowadays if configured correctly this should use TLS and in-protocol mutual public key authentication (yes, not mutual TLS usually). We've tested many EBICS systems before and you can read about an XSS vulnerability here, but for the scope of this article, EBICS is good from a trust perspective. The pain001 reaches the bank directly over a secure channel.

Another option is to generate the file in the software directly and then the same person uploads the file to the bank. This is usually fine, too.

However, in practice pain001 files are also exported from book keeping software and kept as files. Many companies use external book keeping services or payroll contractors, which then transfer the pain001 file to the customer to do the actual payment in the electronic banking portal. Unfortunately, often enough the files are sent via email or other untrusted channels. As standard email is unauthenticated, this means the recipient needs to verify the contents of the pain001 file before doing the payment. And this is where it gets tricky. We've seen multiple Chief Financial Officers (CFO) of companies receiving pain001 files for salary payment and sending millions of swiss francs without verifing the contents of the pain001 file, doing this every single month of the year. Imagine one spoofed email that sends a pain001 file one day early before the regular salary payments are due... and there could be immediate financial damage.

The most important and obvious thing to do is to secure the channel first and use something secure rather than email. This is what we recommend to do first. But then you might still wonder what kind of payments are included in the pain001 file you get: Control is better than trust. And honestly, investing a minute to check the file before you send a couple of million swiss francs looks like a good trade-off.

This leads to the next problem in the chain: E-Banking interfaces of banks. It is very unfortunate that many banks do not handle pain001 files in a user friendly way (although we heard at least from one bank doing it right in Switzerland). When uploading the file, most banks check the integrity of the file, but then only show the total amount and the number of transactions, but no list of transactions. This means it is still not possible to know which recipient or which bank will get the money. And in many cases the "independent payment verification" on the mobile phone will only show the same data instead of the list of transactions. Even the four-eyes principle with joint signatories doesn't help in this case if all four eyes don't see any transaction details.

As usual there are multiple things that usually have to be wrong, but we saw the problem in practice.

Riskless pain tool and salary use case

For the simple case of reoccuring monthly salary payments where a lot of the transactions stay the same month after month, we created a tool to look at a pain001 file or compare two pain001 files. Our goal was to show where money is going to end up, therefore we parse all CdtTrfTxInf tags from a pain001 file, but don't care about the rest. E.g. we don't care about from which account the money is paid from. With the creation of our tool the complexity of pain001 started to show. Due to all the optional fields that are possible which might reroute a payment to a malicious actor, it is hard for a GUI tool to show all the data that could be represented. We went for a pragmatic approach which shows the most common fields. But to be on the secure side we can also display the XML tree (CdtTrfTxInf). The tool will also try to match similar payments of two pain001 files are compared, so modifications can be detected and a diff-style difference between the payment XML tree can be displayed in the GUI.

We hope the "riskless pain" tool is helpful to all people who would like to show details of pain.001.001 files. However, there is absolutely no warranty whatsoever, because simply put, pain001 files are pretty complex. We assume that when looking at all CdtTrfTxInf XML tag you should know to whom you send money, but this assumption could be wrong. However, we support version pain.001.001.01 all the way up to pain.001.001.11.xsd and also the Swiss standard. We're pretty sure the tool will fail for other national standards that are not compatible with the ISO20022 international XML schemes. We also have only tested the tool with a couple of XML test files that are again only a selection from a handful of XML schemas out of the many supported ones. We did not look through each and every version to make sure that looking at CdtTrfTxInf tags in the XML files is sufficient. We haven't even read the ISO2022 standard. So please take this with a grain of salt and let us know if you find a way to transfer money to an attacker without the GUI warning of a modification (or showing any details in the XML tab).

If you are an expert for ISO 20022 (e.g. a developer of a library for pain001), we would like to hear your feedback.

We would also like to see more banks (especially in Switzerland) who show transaction details for pain.001.001 files or even a diff-style analysis tool in their electronic banking interfaces. It would definitely help to cover one of the very common use cases and could actually prevent fraud. We would be happy if our "riskless pain" tool gets obsolete in the future.

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.

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

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

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

Motivation

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

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

Ansatz

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

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

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

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

Implementation und Betriebsmodus

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

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

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

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

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

Betrieb einer eigenen Installation

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

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

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!

Shreddy2 – Ein Raspberry Pi als Löschstation für USB-Sticks

Pentagrid AG — Mon, 20 Dec 2021 05:12:21 GMT

"Delete early, delete often" ist das leicht abgewandelte Motto, dass daran erinnert, Datenlecks durch verlorene oder gestohlene USB-Sticks mittels regelmäßigem Löschen zu minimieren. Sind Sie es leid, beim Formatieren eines USB-Sticks auf Ihrem lokalen Computer darauf zu achten, nicht versehentlich das falsche Gerät zu löschen? Um den Vorgang zu vereinfachen, haben wir eine USB-Löschstation als Software auf einem Raspberry Pi implementiert. Die Software wartet drauf, dass ein USB-Stick angeschlossen wird. Der wird dann bereinigt. Also: shreddy, ready, go!

Warnhinweis

Zunächst einmal sollten sensible Informationen nicht ungeschützt auf mobilen USB-Sticks gespeichert werden, vor allem dann nicht, wenn die Gefahr besteht, dass sie verloren gehen. Es ist daher immer eine gute Idee, Daten vor dem Speichern zu verschlüsseln oder einen USB-Stick mit Verschlüsselungsfunktion zu verwenden, der man vertrauen kann oder noch besser, die verifiziert wurde. Nichtsdestotrotz werden viele Daten auf USB-Sticks gespeichert. Wenn diese nicht regelmäßig gelöscht werden, sammelt sich ein Informationsberg, der, auch wenn einzelne Dateien weniger sensibel sind, in der Menge viel über interne Aktivitäten oder persönliche Angelegenheiten preisgeben kann. Daher verringert das regelmäßige Löschen von USB-Sticks die Auswirkungen im Falle eines Verlustes.

Löschen von Flash-Speichern

USB-Sticks nutzen Flash-Speicher. Werden Informationen darauf gelöscht, werden die Daten zunächst nicht wirklich gelöscht. Dateiinhalte können oft auf der Ebene des Dateisystems wiederhergestellt werden, insbesondere bei FAT-Dateisystemen, die auf USB-Sticks weit verbreitet sind. Ein Wiederherstellen ist solange möglich, wie Verwaltungsinformationen und Dateiinhalte nicht überschrieben werden. Aber selbst bei teilüberschriebenen Dateien können noch genügend extrahierbare Informationen erhalten bleiben. Früher wurden Dateien auf Magnetplatten mit speziellen Löschprogrammen mehrfach überschrieben, um eine Wiederherstellung zu verhindern oder zu erschweren. Während dies bei magnetischen Festplatten gut funktioniert, funktioniert dieser Ansatz bei Flash-Speichern nicht. Der Flash-Speicher-Controller versucht, Schreibvorgänge über den Flash-Speicher zu verteilen, sodass eine gleichmäßige Schreibbelastung der Speicherzellen erzielt wird. Diese Methode wird als Wear-Levelling bezeichnet und verlängert die Lebensdauer eines Speichermediums. Dieses Wear-Leveling verhindert jedoch, eine einzelne Datei einfach zu überschreiben. Beim Versuch eine Datei mehrfach zu überschreiben würden zwar mehrere Regionen innerhalb des Flash-Speichers überschrieben werden, nicht notwendigerweise aber die Speicherzellen, an denen der ursprüngliche Dateiinhalt gespeichert war. Außerdem hält der Flash-Speicher-Controller zusätzlichen Speicherplatz als Ersatz für ausfallende Speicherzellen vor. Wurde der Dateiinhalt an eine solche nun nicht mehr nutzbare Stelle geschrieben, kann er ohne Low-Level-Zugriff auf den Flash-Speicher nicht mehr überschrieben werden.

Was ist also der richtige Weg, um einen USB-Speicherstick zu löschen? NIST SP 800-88 Rev. 1 "Guidelines for Media Sanitization" empfiehlt das folgende Verfahren zum Löschen von USB-Wechselmedien (einschließlich sogenannter Pen Drives, Thumb Drives, Flash Memory Drives, Memory Sticks usw.):

Datenträger werden mit organisatorisch genehmigten und getesteten Überschreibtechnologien/-methoden/-tools überschreiben. Das Überschreiben sollte mindestens zwei Durchgänge umfassen, und dabei ein Muster im ersten Durchgang und sein Komplementärmuster im zweiten Durchgang verwenden. Es können zusätzliche Durchgänge verwendet werden.

Das NIST fügt jedoch auch als Hinweis hinzu: "In den meisten Fällen, in denen eine Bereinigung gewünscht ist, sollten USB-Wechselmedien vernichtet werden." Das ist die Empfehlung, um auf Nummer sicher zu gehen.

Für weniger kritische Daten und Datensammlungen kann jedoch ein einfacher Überschreibansatz mit mehreren Durchgängen ausreichend sein. Da das Überschreiben einer einzelnen Datei aufgrund der Art und Weise, wie der Flash-Speicher verwaltet wird, prinyipbedingt kein Überschreiben darstellt, bleibt als Ansatz ein mehrfaches vollständiges Überschreiben, um das Risiko von Datenrückständen erheblich zu verringern. Wei et al. beobachteten in ihren praktischen Wiederherstellbarkeitstests:

In den meisten Fällen reichte das zweimalige Überschreiben des gesamten Datenträgers aus, um den Datenträger zu säubern, unabhängig vom vorherigen Zustand des Laufwerks. Es gab drei Ausnahmen: Etwa 1 % (1 GB) der Daten blieb auf Laufwerk A nach zwanzig Durchläufen übrig. Wir testeten auch eine kommerzielle Implementierung des 5220.22-M-Standards mit vier Durchläufen auf Laufwerk C. Für den Fall der sequentiellen Initialisierung entfernte sie alle Daten, aber bei der zufälligen Initialisierung blieb ein einzelner Fingerabdruck (Anmerkung: zuvor wurden auf dem Datenträger Testdaten verteilt) übrig.

Mit anderen Worten: Es gibt keinen wirklich korrekten Weg der sicheren Datenlöschung, außer die Daten nicht außerhalb eines Verschlüsselungscontainers zu verarbeiten oder den Datenträger physisch zu zerstören. Sagen Sie uns nicht, Sie seien nicht gewarnt worden. Trotzdem haben wir ein Tool erstellt, wenn Sie versuchen möchten, Daten zu löschen.

Software

Wir haben eine Software in Python implementiert. Diese nutzt die Bibliothek py-udev für das Monitoring von entsprechenden USB-Events. Die Speichermedien werden dann in drei Durchgängen überschrieben: Der erste und zweite Durchgang verwenden den Befehl badblocks, um die komplementären Muster 0x00 und 0xff zu schreiben. Der badblocks-Befehl ist eigentlich nicht für das Überschreiben von Daten gedacht. Dies ist jedoch ist ein Nebeneffekt beim Prüfen des Speichers auf beschädigte Bereiche. Wir verwenden das Programm hier, weil es die Angabe eines expliziten Schreibmusters erlaubt. Das Überschreiben des Blockgeräts in einem dritten Durchgang wird durch den Aufruf des shred-Befehls im Zufallsmodus umgesetzt. Das Überschreiben des Speichers mit Zufallsdaten soll den Aufwand für die Suche nach extrahierbaren Datenresten erhöhen. Anschließend legt die Software ein neues FAT-32-Dateisystem an. Dazu nutzt das Programm parted und mkfs.

Die Software kann auf einem Raspberry Pi installiert werden, der in einem Büro in einer vertrauenswürdigen Umgebung platziert wird. Nutzerinnen und Nutzer können ihre benutzten USB-Sticks anstecken und später wiederkommen, um sie abzuholen. Dies kann ein eigenes Sicherheitsproblem darstellen. Nochmals, Sie wurden gewarnt.

Die Software implementiert zwei Methoden, um über den Status zu informieren. In einem Netzwerkmodus hat die Löschstation Netzwerkschnittstelle, über die mittels netcat oder telnet Statusinformationen abgefragt werden können (siehe Screenshot). Da der Netzwerkmodus einem möglicherweise kompromittierten Raspberry Pi erlaubt, den Inhalt des USB-Sticks auszulesen und Daten an einen Angreifer auszuleiten, könnte der Raspberry Pi alternativ in einem Funkschnittstellen blockierenden Metallgehäuse und ohne Ethernet betrieben werden. Die zweite Methode der Statussignalisierung ist ein am Raspberry Pi angebrachtes USB-Busylight. Solange ein Löschvorgang läuft, leuchtet das Busylight rot, ein rotes Blinken meldet einen Fehler, und ein grünes Licht bedeutet, dass alle eingesteckten USB-Sticks verarbeitet wurden. Im Leerlauf, wenn kein USB-Speicherstick eingesteckt ist, spart das Busylight Energie und ist aus. Die Software unterstützt derzeit Busylights von Kuando über die Python-Bibliothek pyBusylight.

Der Quellcode ist auf Github verfügbar. Dort ist auch die Installationsanleitung zu finden.