writeups/ilm0/ctfzone.md

   1 # <u>CTFZone 2019 Quals</u>
   2
   3
   4
   5 ## Strange PDF
   6
   7 **category**: forensics, rev
   8
   9 **description**:
  10
  11 You have one PDF file. Now calculate the flag. It's in decimal, by the way.
  12
  13 ___
  14
  15 ### Recon + solution
  16
  17 We receive a .pdf file. Opening it we find a strange function definition f(x) = 109394007*x + 13
  18 In itself, this is not very helpful!
  19
  20 I tried looking for clues in the file details, then taking it apart with LibreOffice draw, but nothing unusual was revealed.
  21
  22 Analysing the file with the unix tool `strings` did not reveal any hidden information, but it revealed the underlying file structure.
  23
  24 After getting into the details of how .pdf files are built up (see TD) , I took a closer look with `less`:
  25
  26 The xref table:
  27
  28 ```
  29 xref
  30 0 26
  31 0000000000 65535 f
  32 0000020069 00000 n
  33 0000000019 00000 n
  34 0000000294 00000 n
  35 0000000314 00000 n
  36 0000000511 00000 n
  37 0000020212 00000 n
  38 0000000551 00000 n
  39 0000006741 00000 n
  40 0000006762 00000 n
  41 0000006964 00000 n
  42 0000007312 00000 n
  43 0000007527 00000 n
  44 0000012420 00000 n
  45 0000012442 00000 n
  46 0000012649 00000 n
  47 0000012966 00000 n
  48 0000013155 00000 n
  49 0000019098 00000 n
  50 0000019120 00000 n
  51 0000019317 00000 n
  52 0000019672 00000 n
  53 0000019891 00000 n
  54 0000019944 00000 n
  55 0000020311 00000 n
  56 0000020402 00000 n
  57 ```
  58
  59 There is only one section with 26 objects. First I thought that some of these are somehow hidden, I tried copying parts into a new file, but it did not work, later it turned out because of the offsets. As I looked into the exact specifications, it turned out that the offsets for the original file were not correct in the first place and that the file contained a mysterious second comment, apart from the standard pdf-header defining the version and file type.
  60
  61 I tried interpreting the comment in many ways, looked at the hex and binary values, but could not determine the purpose of it. I was stuck here, until I've stumbled upon a writeup, which stated that the file command should've identified the file as a DOS/MBR boot sector. Which is surprising as I have received:
  62
  63 ```
  64 $ file document.pdf
  65 document.pdf: PDF document, version 1.4
  66 ```
  67
  68 every time when I tried identifying the data type.
  69
  70 With this new information, the only thing standing in my way was being able to execute the instructions to get x.
  71
  72 Interpreting the code as x86 assembly:
  73
  74 ```nasm
  75 and ax, 0x4450
  76 inc si
  77 sub ax, 0x2e31
  78 xor al, 0xa
  79 and ax, 0xb7e2
  80 mov ah, 2
  81 mov bh, 0
  82 mov dh, 1
  83 mov dl, 1
  84 int 0x10
  85 mov ah, 0xa
  86 mov al, 0x39
  87 mov bh, 0
  88 mov cx, 5
  89 int 0x10
  90 mov ah, 2
  91 mov bh, 0
  92 mov dh, 1
  93 mov dl, 3
  94 int 0x10
  95 mov ah, 0xa
  96 mov al, 0x33
  97 mov bh, 0
  98 mov cx, 1
  99 int 0x10
 100 ```
 101
 102 This code returns 99399, substituting it into the original equation:
 103
 104 109394007*99399 + 13 = 10873654901806, so the flag is: ctfzone{10873654901806}
 105
 106 ### Technical details
 107
 108 Structure of PDF files:
 109
 110 ![pdf.png](ctf_zone/pdf.png)
 111
 112 [https://d3i71xaburhd42.cloudfront.net/b4f47fb71221a0676e2e892af7b98acad2c3c5cd/2-Figure1-1.png]
 113
 114 ### Lessons learned
 115
 116 - PDF file structure
 117 - Always go a level deeper!
 118
 119
 120
 121 ## Joshua
 122
 123 **category**: forensics
 124
 125 **description**:
 126
 127 This should be an easy one, just remember to rock. (Sorry, the flag on disk begins with CTFZone, please change it to all lowercase, when you submit).
 128
 129 ___
 130
 131 ### Recon + solution
 132
 133 We get a 20GB raw disk image. The unix tool `file` tells us:
 134
 135 ```
 136 $ file joshua.img
 137 joshua.img: DOS/MBR boot sector
 138 ```
 139
 140 that it is the image of an MBR disk.
 141
 142 I tried to mount the mentioned image, but it does not go as easy as one would think.
 143
 144 We have to find the starting sector with the `fdisk` tool:
 145
 146 ```
 147 $ fdisk -l joshua.img
 148 Disk joshua.img: 20 GiB, 21474836480 bytes, 41943040 sectors
 149 Units: sectors of 1 * 512 = 512 bytes
 150 Sector size (logical/physical): 512 bytes / 512 bytes
 151 I/O size (minimum/optimal): 512 bytes / 512 bytes
 152 Disklabel type: dos
 153 Disk identifier: 0x70b3f931
 154
 155 Device      Boot    Start      End  Sectors  Size Id Type
 156 joshua.img1 *        2048  7999487  7997440  3.8G 82 Linux swap / Solaris
 157 joshua.img2       8001534 39835647 31834114 15.2G  5 Extended
 158 joshua.img3      39835648 41932799  2097152    1G 83 Linux
 159 joshua.img5       8001536 39835647 31834112 15.2G 83 Linux
 160
 161 Partition table entries are not in disk order.
 162 ```
 163
 164 Based on these results we can calculate the offset:
 165
 166 ```
 167 mount -o ro,loop,offset=$((512 * 8001536)) joshua.img5 /mnt/joshua
 168 ```
 169
 170 After mounting the largest partition, we immediately head over to /etc/passwd, to find some more information about who this drive could belong to. (It needed reading around online how to approach such challenges.) We find an interesting entry:
 171
 172 ```
 173 joshua:x:1000:1000:joshua:/home/joshua:/bin/bash
 174 ```
 175
 176 there seems to be a user called "joshua", let's check out his home directory!
 177
 178 We find an interesting file .bash_history:
 179
 180 ```
 181 sync
 182 sudo cryptsetup close cryptovolume
 183 chsh -s /bin/zsh
 184 echo $(SHELL)
 185 zsh
 186 cat /var/log/auth.log
 187 faillog
 188 chsh -s zsh
 189 sudo apt install zsh
 190 chsh -s /bin/zsh
 191 sudo apt install keepass2
 192 keepass2
 193 sudo luksformat /dev/sda3
 194 sudo cryptsetup close /dev/mapper/
 195 ls /dev/mapper
 196 chsh -s /bin/bash
 197 rm ~/.zshrc
 198 rm ~/.zsh_history
 199 sudo apt remove zsh
 200 ls -a
 201 cd ~
 202 ls
 203 ls -a
 204 rm -r .oh-my-zsh/
 205 ```
 206
 207 We can make some interesting observations:
 208
 209 - joshua has sudo access
 210 - he used the zsh shell and he deleted its history
 211 - he set up an encrypted volume (probably joshua.img3)
 212 - he used the keepass2 password safe
 213
 214 In the Documents folder we find a KeepItSafe.kdbx keepass2 file. But we do not have a key for opening it!
 215
 216 ```
 217 $ mount -o ro,loop,offset=$((512 * 39835648)) joshua.img3 /mnt/joshua_crypt
 218 mount: /mnt/joshua_crypt: failed to setup loop device for joshua.img3.
 219 ```
 220
 221 I could not mount the encrypted partition, probably the encryption prevents us from loading it.
 222
 223 We also find an interesting file in the home directory ".recently-used":
 224
 225 ```
 226 <RecentFiles>
 227   <RecentItem>
 228     <URI>file:///home/joshua/Documents/KeepItSafe.key</URI><Mime-Type>application/x-iwork-keynote-sffkey</Mime-Type><Timestamp>1570444296</Timestamp><Groups/>
 229   </RecentItem>
 230   <RecentItem>
 231     <URI>file:///home/joshua/Documents/KeepItSafe.kdbx</URI><Mime-Type>application/x-keepass2</Mime-Type><Timestamp>1570444267</Timestamp><Groups/>
 232   </RecentItem>
 233   <RecentItem>
 234     <URI>file:///home/joshua/Documents/KeepItSage.kdbx</URI><Mime-Type>application/x-keepass2</Mime-Type><Timestamp>1570444179</Timestamp><Groups/>
 235   </RecentItem>
 236 </RecentFiles>
 237 ```
 238
 239 He seems to have created an other keepass2 file, maybe deleted it later? But what is even more interesting: He created a key file to the safe, it has to be somewhere around!
 240
 241 We find the key in the trash `/local/share/Trash`! This seems to easy!
 242
 243 Unfortunately, it really is, keepass2 reports that the composite key is invalid! Maybe a password is also needed.
 244
 245 I tried brute-forcing /etc/shadow with hashcat to maybe get a relevant password, but it took too long, maybe with a strong graphics card it would go faster!
 246
 247
 248
 249 ### Technical details
 250
 251 Linux file structure:
 252
 253 `/etc/passwd`:
 254
 255 > The password file is human-readable file that contains information about users on the system including their encrypted passwords. Some systems don’t have encrypted passwords in this file if [/etc/shadow](https://kerneltalks.com/user-management/understanding-etc-shadow-file/) file is generated.
 256
 257 [https://kerneltalks.com/user-management/understanding-etc-passwd-file/]
 258
 259 ```
 260 joshua:x:1000:1000:joshua:/home/joshua:/bin/bash
 261 ```
 262
 263 In our case the second "x" meant that the password is in an encrypted format in the /etc/shadow file.
 264
 265
 266
 267 `/etc/shadow`
 268
 269 > The /etc/shadow file stores actual password in encrypted format.
 270
 271 [https://www.2daygeek.com/understanding-linux-etc-shadow-file-format/]
 272
 273 ```
 274 joshua:$6$6PWRmE20$BAkQBhvRUnnyuGBgIrikxBp8YkOOUO7REg285NqJbFNt7E.19xNTfa2wdT0.NiFxdcw2nMLmT3/hgw1doIB2x/:18176:0:99999:7:::
 275 ```
 276
 277 In our case the prefix $6$6 means that the password is hashed with 6 rounds of SHA-512 and
 278 PWRmE20$BAkQBhvRUnnyuGBgIrikxBp8YkOOUO7REg285NqJbFNt7E.19xNTfa2wdT0.NiFxdcw2nMLmT3/hgw1doIB2x/ is the hashed password of the user "joshua".
 279
 280
 281
 282 ### Lessons learned
 283
 284 - Mounting .img files
 285 - Approaching a forensic challenge