DEFCON DFIR CTF 2019 writeup (II): Linux Forensics

Como habíamos visto en la parte de Windows, la adquisición forense del equipo Horcrux nos había dejado una tabla de particiones cargadita, siendo una de ellas una de Linux. Siendo Linux, parece tener sentido el realizar el forense desde otro Linux.

En primer lugar vamos a montar la partición como es debido para poder ver lo que tenemos dentro (si estáis en un sistema Linux necesitaréis las ewftools, y aquí [https://www.andreafortuna.org/2018/04/11/how-to-mount-an-ewf-image-file-e01-on-linux/] tenéis un tutorial estupendo sobre cómo hacerlo):

Montamos el contenedor:

# mkdir rawimage
# ewfmount Horcrux.E01 ./bruto

Sacamos un listado de las particiones:

# fdisk -l rawimage/ewf1 
Disk rawimage/ewf1: 50 GiB, 53687091200 bytes, 104857600 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xc2714295

Device          Boot    Start       End  Sectors  Size Id Type
rawimage/ewf1p1 *        2048   1126399  1124352  549M  7 HPFS/NTFS/exFAT
rawimage/ewf1p2       1126400  67104767 65978368 31.5G  7 HPFS/NTFS/exFAT
rawimage/ewf1p3      67106816  73500671  6393856  3.1G  7 HPFS/NTFS/exFAT
rawimage/ewf1p4      75560958 104855551 29294594   14G  5 Extended
rawimage/ewf1p5      75560960 104855551 29294592   14G 83 Linux

Creamos un punto de montaje temporal:

# mkdir /mnt/disk1

Montamos la partición (cuidado con el offset).

# mount ./rawimage/ewf1 /mnt/disk1 -o loop,offset=$((75560960*512))
mount: cannot mount /dev/loop0 read-only

Esto… ¿cómo no va a dejar montarlo en read-only? ¿Qué quiere, que lo monte en R/W? ¿Qué va a ser lo siguiente, que lo arrope Bill Gates y le cante Steve Jobs una nana? Rebuscando un poco en Google parece que la partición no se desmontó correctamente y que al dar error intenta recuperar el journal… que no puede porque está en read-only, lo que causa un bucle infinito.

Con indicarle al mount que no queremos que recupere nada (opción de montado «norecovery» parece que lo podemos montar correctamente).

# mount ./rawimage/ewf1 /mnt/disk1 -o ro,norecovery,loop,offset=$((75560960*512))
root@MOX:/fast/defcon/linux/Horcrux# cd /mnt/disk1
root@MOX:/mnt/disk1# ls
0  bin	boot  dev  etc	home  initrd.img  initrd.img.old  lib  lib64  lost+found  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var  vmlinuz  vmlinuz.old

Ya lo tenemos todo listo para empezar el análisis, así que al turrón :)

1. ¿Qué distribución de Linux está usando este equipo?

Si hablamos de distribuciones basadas en Red Hat, nuestro fichero es /etc/redhat-release, que en este caso no existe. Para versiones basadas en Debian nos tenemos que ir a /etc/lsb-release, que en este caso nos da nuestra flag:

# cat lsb-release 
DISTRIB_ID=Kali
DISTRIB_RELEASE=kali-rolling
DISTRIB_CODENAME=kali-rolling
DISTRIB_DESCRIPTION="Kali GNU/Linux Rolling"

* Respuesta: Kali

2. ¿Cuál es el hash MD5 del log de apache access.log?

La configuración de los logs está en el fichero /etc/apache2/apache2.conf… pero la configuración nos remite a una variable de entorno:

ErrorLog ${APACHE_LOG_DIR}/error.log

por lo que tenemos que ir al fichero envvars:

export APACHE_LOG_DIR=/var/log/apache2$SUFFIX

En /var/log/apache2 tenemos nuestro fichero de marras, y un md5sum más tarde nuestra flag:

# md5sum access.log 
d41d8cd98f00b204e9800998ecf8427e  access.log

* Respuesta: d41d8cd98f00b204e9800998ecf8427e

3. Se cree que se ha descargado una herramienta de volcado de credenciales. ¿Cuál es el nombre de la descarga?

Si se ha descargado, lo primero que podemos hacer es buscar en los directorios de usuario a ver si tenemos suerte. El /home está vacío (si revisamos el /etc/passwd comprobamos que no hay ningún usuario que tenga directorio en el /home). Sin embargo, el usuario root tiene en su directorio una carpeta preciosa de Downloads dentro de la que tenemos nuestro premio:

root@MOX:/mnt/disk1/root/Downloads# ls

* Respuesta: mimikatz_trunk.zip

4. Se ha creado un fichero supersecreto, ¿cuál es su path absoluto?

Dado que root es el único usuario, es el culpable. Que le corrrrten la cab… digo que revisen lo último que ha hecho (es decir, el .history de cualquiera que sea el shell que esté usando):

# ls -laht |grep history
-rw-------  1 root root 1.5K Mar 22 06:48 .bash_history

El .bash_history parece una pequeña mina de oro, pero no nos vamos por ahora a hacer autospoilers. Nos quedamos con lo que habíamos venido a buscar:

touch snky snky > /root/Desktop/SuperSecretFile.txt
cat snky snky > /root/Desktop/SuperSecretFile.txt

* Respuesta: /root/Desktop/SuperSecretFile.txt

5. ¿Qué programa uso didyouthinkwedmakeiteasy.jpg en su ejecución?

Bueno, hay que confesar que he sido un poco curioso y le he echado un ojo al .bash_history. Solo un vistazo pequeñito de nada… pero he visto ese precioso binwalk usado sobre esa imagen, lo cual nos causa gran curiosidad (y espero saber más de ella ante de que se termine el reto).

* Respuesta:binwalk

6. ¿Cuál es el tercer objetivo de la checklist que ha creado Karen?

Seguimos considerando a root como nuestro «sospechoso preferente”. Vamos a ser perezosos y a intentar un poco de fuerza bruta:

# fgrep aren -R *

(no ponemos la K porque no sabemos si va a ser mayúscula o minúscula, y los fgrep case insensitive cuestan un siglo).

No encontramos nada, por lo que el siguiente paso es listar todos los ficheros a ver si encontramos algo interesante. Y vaya si lo encontramos:

./Desktop/Checklist

# cat Desktop/Checklist 
Check List:

- Gain Bob's Trust
- Learn how to hack
- Profit

* Respuesta: Profit

7. ¿Cuántas veces se ejecutó Apache?

Vamos a ver si tenemos alguna herramienta de auditoria tipo auditd desplegada … nada. Buscamos en los logs del sistema por arranques/paradas … nada. Miramos los logs de /var/log/apache y están vacíos:

# ls -laht
total 8.0K
drwxr-xr-x 22 root root 4.0K Mar 22 16:16 ..
drwxr-x---  2 root adm  4.0K Mar 14 04:23 .
-rw-r-----  1 root adm     0 Nov  9  2017 access.log
-rw-r-----  1 root adm     0 Nov  9  2017 error.log
-rw-r-----  1 root adm     0 Nov  9  2017 other_vhosts_access.log

La ausencia de evidencia también es evidencia. Si el error.log está vacío implica que el servicio no se ha arrancado nunca (siempre se deja un mensaje cuando se arranca o para Apache). Ergo nuestra respuesta es cero (patatero).

* Respuesta: 0

8. Se cree que este equipo ha sido empleado para atacar otro, ¿qué fichero lo prueba?

Rebuscando un poco encontramos una imagen que vale más que mil palabras:

* Respuesta: irZLAohL.jpeg

9. Dentro de la carpeta de Documents, se cree que Karen se estaba mofando de un colega experto en ordenadores a través de un script en bash. ¿Cuál era la mofa de Karen?

Otra pregunta para rebuscar. Dado que tenemos 4 ficheros es más bien sencillo:

# cat firstscript_fixed 
echo "Showing you your current path"
pwd
echo "Show my default route"
ip route | grep --color default
echo "Show network connections w/ port 80"
netstat | grep --color 80
echo "Heck yeah! I can write bash too Young"

Yuhu.

* Respuesta: Young

10. Un usuario empleó el comando su para hacerse root múltiples veces a las 11:26. ¿Quién fue?

El que un usuario emplee sudo/su deja un log en auth.log, por lo que es cuestión de limpiar los accesos típicos de cron del fichero de log:

# egrep -v cron auth.log|less

Mar 20 11:26:22 KarenHacker su[4060]: Successful su for postgres by root
Mar 20 11:26:22 KarenHacker su[4060]: + ??? root:postgres
Mar 20 11:26:22 KarenHacker su[4060]: pam_unix(su:session): session opened for user postgres by (uid=0)
Mar 20 11:26:22 KarenHacker su[4060]: pam_systemd(su:session): Cannot create session: Already occupied by a session
Mar 20 11:26:22 KarenHacker su[4060]: pam_unix(su:session): session closed for user postgres
Mar 20 11:26:22 KarenHacker su[4074]: Successful su for postgres by root
Mar 20 11:26:22 KarenHacker su[4074]: + ??? root:postgres
Mar 20 11:26:22 KarenHacker su[4074]: pam_unix(su:session): session opened for user postgres by (uid=0)
Mar 20 11:26:22 KarenHacker su[4074]: pam_systemd(su:session): Cannot create session: Already occupied by a session
Mar 20 11:26:22 KarenHacker su[4074]: pam_unix(su:session): session closed for user postgres
Mar 20 11:26:22 KarenHacker su[4081]: Successful su for postgres by root
Mar 20 11:26:22 KarenHacker su[4081]: + /dev/pts/0 root:postgres
Mar 20 11:26:22 KarenHacker su[4081]: pam_unix(su:session): session opened for user postgres by (uid=0)
Mar 20 11:26:22 KarenHacker su[4081]: pam_systemd(su:session): Cannot create session: Already occupied by a session
Mar 20 11:26:22 KarenHacker su[4081]: pam_unix(su:session): session closed for user postgres

* Respuesta: postgres

11. Basándonos en el bash_history, ¿cuál es directorio actual de trabajo (CWD)?

Si fuéramos canónicos, el «touch keys.txt» a mí me induciría a pensar que el CWD sería «/root/Documents/» (que es donde está keys.txt). Pero como parece que tenemos varios bash corriendo el history termina siendo una mezcla de todos. Al final por prueba y error la respuesta correcta es la que corresponde al último «cd» realizado y marcado en el .bash_history

* Respuesta: /root/Documents/myfirsthack