Writeup DGA - CTF - Server room
This article describes my solution for the 100-point challenge called “Server room”.
Introduction
Nous avons trouvé un boitier connecté à un switch dans notre salle serveur à Bruz. Personne ne sait qui a pu le déposer dans un endroit si sécurisé.
Pour votre premier job à la DGA, il faudrait mieux que vous trouviez rapidement à quoi il sert !
Start
We have at our disposal a gzip file, the first thing is obviously to decompress it.
file found_in_server_room.img.gz
found_in_server_room.img.gz: gzip compressed data, was "found_in_server_room.img", last modified: Thu Nov 12 07:23:20 2020, from Unix, original size modulo 2^32 1845493248
gzip -d found_in_server_room.img.gz
file found_in_server_room.img
found_in_server_room.img: DOS/MBR boot sector; partition 1 : ID=0xc, start-CHS (0x40,0,1), end-CHS (0x3ff,3,32), startsector 8192, 524288 sectors; partition 2 : ID=0x83, start-CHS (0x3ff,3,32), end-CHS (0x3ff,3,32), startsector 532480, 3072000 sectors
We can assume that this file is a disk image from the description of the challenge, but we can use mmls to make sure.
mmls found_in_server_room.img
DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors
Slot Start End Length Description
000: Meta 0000000000 0000000000 0000000001 Primary Table (#0)
001: ------- 0000000000 0000008191 0000008192 Unallocated
002: 000:000 0000008192 0000532479 0000524288 Win95 FAT32 (0x0c)
003: 000:001 0000532480 0003604479 0003072000 Linux (0x83)
We can see 2 partitions. Based on their type, one seems to be the boot partition (W95 FAT32), and the other the filesystem (Linux).
Mounting
Well, since mmls gives us a lot of information about the size of the blocks (512 bytes) and the start-block (8192) for the boot partition, we can mount it like follows.
sudo mkdir -p /mnt/server-room/boot
sudo mount -o offset=4194304 found_in_server_room.img /mnt/server-room/boot/
You can find the specific offset by multiplying the start-block of the partition by the size of the block, for the boot partition it is 8192 * 512 = 4194304.
By mobing into /mnt/server-root/boot, we can find files that contain *rpi-zero*, *rpi-2-b*… It makes me think it’s a disk image from a Raspberry Pi. To make sure, I ran the following command to find relationships with the word Raspberry Pi.
strings /mnt/server-room/boot/* | grep -i "raspberry pi"
Several occurrences are out.
I encountered problems mounting the partition on my filesystem, so I decided to copy the contents of this image to a USB key.
sudo dd if=found_in_server_room.img of=/dev/sda bs=4M status=progress
1757413376 bytes (1.8 GB, 1.6 GiB) copied, 1 s, 1.8 GB/s
439+1 records in
439+1 records out
1845493248 bytes (1.8 GB, 1.7 GiB) copied, 272.329 s, 6.8 MB/s
Mount it.
sudo mkdir -p /mnt/server-room/fs
sudo mount /dev/sda2 /mnt/server-room/fs/
We can now navigate into the filesystem of the Raspberry Pi.
cd /mnt/server-room/fs
ls -lah
total 96K
drwxr-xr-x 21 root root 4.0K Aug 20 12:47 ./
drwxr-xr-x 4 root root 4.0K Nov 30 12:38 ../
drwxr-xr-x 2 root root 4.0K Aug 20 12:32 bin/
drwxr-xr-x 2 root root 4.0K Aug 20 12:47 boot/
drwxr-xr-x 4 root root 4.0K Aug 20 12:26 dev/
drwxr-xr-x 82 root root 4.0K Aug 27 15:30 etc/
drwxr-xr-x 3 root root 4.0K Aug 20 12:31 home/
drwxr-xr-x 16 root root 4.0K Aug 20 12:33 lib/
drwx------ 2 root root 16K Aug 20 12:47 lost+found/
drwxr-xr-x 2 root root 4.0K Aug 20 12:26 media/
drwxr-xr-x 2 root root 4.0K Aug 20 12:26 mnt/
drwxr-xr-x 3 root root 4.0K Aug 20 12:31 opt/
drwxr-xr-x 2 root root 4.0K May 10 2020 proc/
drwx------ 3 root root 4.0K Aug 27 15:28 root/
drwxr-xr-x 4 root root 4.0K Aug 20 12:26 run/
drwxr-xr-x 2 root root 4.0K Aug 20 12:33 sbin/
drwxr-xr-x 2 root root 4.0K Aug 20 12:26 srv/
drwxr-xr-x 2 root root 4.0K May 10 2020 sys/
drwxrwxrwt 7 root root 4.0K Aug 27 15:33 tmp/
drwxr-xr-x 10 root root 4.0K Aug 20 12:26 usr/
drwxr-xr-x 11 root root 4.0K Aug 20 12:47 var/
Forensic
The first thing to do when you have a filesystem is to look at the history of executed commands.
sudo find . -type f -name .bash_history
./root/.bash_history
./home/pi/.bash_history
The commands executed by the user pi do not give anything interesting.
sudo cat home/pi/.bash_history
sudo systemctl halt
However, the root user’s one, it is (I display only the interesting ones).
sudo cat root/.bash_history
[...]
systemctl start dnsmasq
systemctl status dnsmasq
systemctl status hostapd
nano /etc/hostapd/hostapd.conf
systemctl reboot
history
The configuration file /etc/hostapd/hostapd.conf contains all the settings for configuring the Wi-Fi access point. Let’s explore this file.
sudo cat etc/hostapd/hostapd.conf
country_code=FR
interface=wlan0
ssid=BackpackNet
hw_mode=g
channel=11
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_passphrase=BackpackBackdoorNet
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP
The wpa_passphrase parameter is used to set the passphrase of the BackpackNet access point.
It turns out that the flag for this challenge is the password for this access point, so BackpackBackdoorNet.