AntarcticVault 1/2
La description indique qu’un attaquant a compromis un noeud, il a ensuite monté un point d’accès malveillant et le noeud compromis s’y est connecté. L’objectif est de retrouver les secrets exfiltrés.
Dans cette étape, on récupère une capture mémoire et une capture réseau (Wi-Fi).
Etant donné que l’on cherche à récupérer les secrets exfiltrés, on se dit qu’ils peuvent être dans la capture Wi-Fi. On voit qu’elle commence par un paquet de Deauth, on cherche donc un échange WPA.
Les paquets 27 à 37 contiennent cet échange. On voit qu’il s’agit d’un échange WPA3 (plus d’infos ici : D’abord le protocole SAE (Simultaneous Authentication of Equal) est utilisé pour dériver une PMK (paquets 27-30), celle-ci est ensuite utilisée dans le 4-way handshake (34-37) pour envoyer la clé de chiffrement qui sera utilisée.
Si on filtre les paquets d’annonces (dans wireshark: wlan.fc.type_subtype != 8
), on voit qu’il a assez peu d’éléments au final.
Outre l’authentification, il n’y a que quelques paquets de données échangés, mais qui sont chiffrés.
La cryptographie du Wi-Fi étant très fortement basée sur AES pour les algorithmes symétriques, la première idée fut de chercher des clés AES dans le dump et de voir si on pouvait en tirer quelque chose. Après compilation du projet aeskeyfind, on trouve 5 clés dans le dump :
c89aeb02dfae6cdba6af63d63bcb084b
7f644d88a631f075bfe6ac7686dc68cf
c89aeb02dfae6cdba6af63d63bcb084b
12226b002034077bc4007b73308e4e98
d18ed9b8c3816ef786a30633efb88e57
On peut les faire manger à Wireshark : Clic droit sur un paquet -> Préférences du protocole -> IEEE 802.11 Wireless LAN -> Decryption keys… Il faut leur donner le type “TK” pour que Wireshark soit content.
Wireshark retrouve ses petits et déchiffre les paquets, on peut donc constater qu’il n’y a qu’un flux TCP dans la capture. Si on le suit (Clic droit -> Suivre -> Flux TCP), on récupère la sortie suivante :
bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell
root@vault42:/# ls -al /
ls -al /
total 76
drwxr-xr-x 20 root root 4096 Mar 19 05:22 .
drwxr-xr-x 20 root root 4096 Mar 19 05:22 ..
lrwxrwxrwx 1 root root 7 Jan 28 11:01 bin -> usr/bin
drwxr-xr-x 3 root root 4096 Jan 1 1970 boot
drwxr-xr-x 17 root root 3700 Mar 19 05:18 dev
drwxr-xr-x 81 root root 4096 Mar 12 11:31 etc
drwxr-xr-x 3 root root 4096 Jan 28 11:24 home
lrwxrwxrwx 1 root root 7 Jan 28 11:01 lib -> usr/lib
drwx------ 2 root root 16384 Jan 28 11:22 lost+found
drwxr-xr-x 2 root root 4096 Jan 28 11:02 media
drwxr-xr-x 2 root root 4096 Jan 28 11:02 mnt
drwxr-xr-x 2 root root 4096 Jan 28 11:02 opt
dr-xr-xr-x 140 root root 0 Jan 1 1970 proc
drwx------ 4 root root 4096 Mar 19 05:28 root
drwxr-xr-x 25 root root 780 Mar 19 05:45 run
lrwxrwxrwx 1 root root 8 Jan 28 11:01 sbin -> usr/sbin
dr-x------ 2 root root 4096 Mar 15 07:18 secrets
drwxr-xr-x 2 root root 4096 Jan 28 11:02 srv
dr-xr-xr-x 12 root root 0 Jan 1 1970 sys
drwxrwxrwt 9 root root 4096 Mar 19 05:22 tmp
drwxr-xr-x 11 root root 4096 Jan 28 11:02 usr
drwxr-xr-x 11 root root 4096 Mar 12 11:31 var
drwxr-xr-x 3 root root 4096 Jan 29 20:57 www
root@vault42:/# cd secrets
cd secrets
root@vault42:/secrets# ls -al
ls -al
total 12
dr-x------ 2 root root 4096 Mar 15 07:18 .
drwxr-xr-x 20 root root 4096 Mar 19 05:22 ..
-rw------- 1 root www-data 71 Mar 15 07:18 fcsc_secret
root@vault42:/secrets# cat fcsc_secret
cat fcsc_secret
FCSC{6d6862a2d54b8d01880a8acfb57c25d1d49a9929f1ea5da92f411234aba51065}
root@vault42:/secrets# kill -9 $$
kill -9 $$
Cela donne le flag de l’étape 1: FCSC{6d6862a2d54b8d01880a8acfb57c25d1d49a9929f1ea5da92f411234aba51065}