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
