[x_custom_headline type= »none » level= »h4″ looks_like= »h4″]1 Introduction[/x_custom_headline]
Plusieurs challenges de sécurité ont été organisés en marge du FIC 2018.
Merci à tous les organisateurs, auteurs et sponsors lié à ces challenges.
Cet article montre plusieurs solutions des CTF organisés le soir du premier jour ainsi que le deuxième jour, plutôt dans la catégorie Forensic.
[x_custom_headline type= »none » level= »h4″ looks_like= »h4″]2 Forensic – 50[/x_custom_headline]
Nous avons à notre disposition un fichier pcap : Extract.pcapng.
Le temps de lancer wireshark, et à cause du nom du fichier, je lance aussi un foremost sur cette capture réseau.
------------------------------------------------------------------ File: Extract.pcapng Start: Tue Jan 23 21:28:18 2018 Length: 1 MB (1900172 bytes) Num Name (bs=512) Size File Offset Comment 0: 00003505.png 48 KB 1795007 (736 x 658) Finish: Tue Jan 23 21:28:19 2018 1 FILES EXTRACTED png:= 1 ------------------------------------------------------------------
Le flag est en bas de cette image png :
J’ai fermé wireshark…
[x_custom_headline type= »none » level= »h4″ looks_like= »h4″]3 bashjail – 100[/x_custom_headline]
Celui là n’a pas été résolu par moi, mais par un autre membre de l’équipe qui a trouvé une méthode pour afficher le flag tout à fait dans le style des CTF.
Nous somme face à un « bash jail » :
$ ssh jail1@10.15.20.22 -p 2222 jail1@10.15.20.22's password: Essayez de lire le fichier flag.txt :D Et voici un partie du code dans lequel vous etes : while : do echo "Votre payload :" read input if sanitize "$input" then echo -e '\033[0;31mHop, hop, hop ! Certains caractères sont interdits\033[0m' else output=`/bin/sh -c "$input"` fi done Votre payload :
Il y a quelques semaines, le CCC à proposé un challenge similaire lors du Junior CTF :
https://ctftime.org/task/5155
Nous avons utilisé la technique de représentation octal pour lancer la commande « bash »
Votre payload : $'\\142'$'\\141'$'\\163'$'\\150' bash-4.4# ls bash-4.4# id bash-4.4# pwd
Malheureusement, nous n’avons pas le retour de nos commandes. Nous commencions à réfléchir pour envoyer un reverse shell, quand l’un des membres à trouvé cette méthode :
bash-4.4# export PS1=$(cat flag.txt)
ENSIBS{b45H_0utPu7_4re_fUn!!}
Changer le prompt du bash par le résultat de notre commande… efficace.
Et en bonus :
ENSIBS{b45H_0utPu7_4re_fUn!!}export PS1=$(whoami)
root
rootshutdown -h now
[x_custom_headline type= »none » level= »h4″ looks_like= »h4″]4 forensic – 150[/x_custom_headline]
Pour ce challenge, nous avons un fichier hiberfil.sys, avec comme description quelques chose comme « J’ai écris le mot de passe dans un fichier, mais j’ai oublié de le sauvegarder ».
Volatility fonctionne avec les fichiers hiberfil.sys, mais pour des raisons de performance il est préférable de commencer l’investigation en le copiant avec imagecopy, en précisant le profile :
# vol -f hiberfil.sys --profile=Win7SP0x64 imagecopy -O hiberfil.raw
Après cela nous commencons par rechercher des informations avec les modules classique de volatility tel que pstree, filescan, clipboard, etc.
Un premier indice est trouvé grâce au module screenshot :
# vol -f hiberfil.raw --profile=Win7SP0x64 screenshot
Où nous récupérons l’image suivante :
L’utilisateur avait effectivement ouvert un notepad.exe, et d’après le titre, il ou elle n’a probablement pas encore sauvegardé ni renommé son fichier.
Après quelques tests, nous trouvons ce module, que je ne connaissais pas, et qui résoudra le problème :
# vol --info | grep editbox Volatility Foundation Volatility Framework 2.6 editbox - Displays information about Edit controls. (Listbox experimental.)
# vol -f hiberfil.raw --profile=Win7SP0x64 editbox Volatility Foundation Volatility Framework 2.6 ****************************** Wnd Context : 1\WinSta0\Default Process ID : 1288 ImageFileName : notepad.exe IsWow64 : No atom_class : 6.0.7600.16385!Edit value-of WndExtra : 0x212800 nChars : 56 selStart : 56 selEnd : 56 isPwdControl : False undoPos : 52 undoLen : 2 address-of undoBuf: 0x219bc0 undoBuf : Mà ------------------------- /!\ Password for 192.168.25.18: I_H4te_Hib3rnate_m0de
[x_custom_headline type= »none » level= »h4″ looks_like= »h4″]5 Forensic – 250[/x_custom_headline]
Nous recevons un fichier nomé USB_Partition.img, avec la description suivante du challenge : « Nous avons extrait cette partition, mais l’équipe a rencontré des problèmes d’espace disque lors de l’extraction ».
$ file USB_Partition.img USB_Partition.img: DOS/MBR boot sector, code offset 0x58+2, OEM-ID "mkfs.fat", Media descriptor 0xf8, sectors/track 62, heads 125, hidden sectors 2048, sectors 102400 (volumes > 32 MB) , FAT (32 bit), sectors/FAT 788, serial number 0x8a252437, label: " "
A cause de la description, nous avons commencé par utiliser testdisk sur le fichier et récupéré un fichier nommé memo.kdbx.
C’est un fichier, chiffré, utilisé par Keepass. Maintenant nous devons trouver le mot de passe ou la clé pour ouvrir ce fichier avec l’outil Keepass.exe.
There were a lot of "noises" in this USB extract : $ mkdir mnt $ sudo mount USB_Partition.img mnt $ cd mnt $ ls -larht drwxr-xr-x 2 root root 512 Mar 21 2017 Cliches drwxr-xr-x 2 root root 13K Mar 21 2017 flags drwxr-xr-x 4 root root 1.0K Mar 21 2017 CrackMapExec-master drwxr-xr-x 5 root root 2.5K Mar 21 2017 peepdf-master -rwxr-xr-x 1 root root 5.9M Mar 21 2017 Guide_securite_industrielle_Version_finale.pdf -rwxr-xr-x 1 root root 264K Mar 21 2017 ANSSI-CSPN-CER-I-02_Criteres_pour_evaluation_en_vue_d_une_CSPN_v1-1.pdf -rwxr-xr-x 1 root root 1.4M Mar 21 2017 anssi-cspn-2016_10.pdf -rwxr-xr-x 1 root root 760K Mar 22 2017 Template_Document.docx
_ Le répertoire « flags » contient des images de tous les drapeaux des pays du monde 😉
_ On y trouve aussi les sources d’un outil appelé peepdf, et une rapide analyse des fichiers pdf présent montre que certains sont « bizarres ».
_ Il y a également un autre outil, appelé CrackMapExec, mais nous n’avons pas investigué plus que cela.
Cependant, j’ai trouvé que le plus suspect était le « Template_Document.docx », à cause de son timestamp… Effectivement tous les fichiers possèdent la même date de modification, sauf celui là :
Pour tout les fichiers :
Modify: 2017-03-21 23:28:12.000000000 +0100 Change: 2017-03-21 23:28:12.000000000 +0100
Sauf pour Template_Document.docx :
Modify: 2017-03-22 00:02:28.000000000 +0100 Change: 2017-03-22 00:03:49.000000000 +0100
C’est comme si l’auteur de challenge avait créer/modifier ce fichier en dernier, une fois quelques chose de fait… peut-être l’ajout d’un mot de passe ?
Après avoir dézippé ce .docx, un fichier nommé « help.png » apparaît directement dans le répertoire « word » et non dans le répertoire « media » où sont normalement stockées les images. C’est un QRCode.
# zbarimg help.png QR-Code:GipsyDangerRektsYou scanned 1 barcode symbols from 1 images in 0.02 seconds
C’est aussi le mot passe du fichier keepass récupéré au début.
[x_custom_headline type= »none » level= »h4″ looks_like= »h4″]6 Forensic – ???[/x_custom_headline]
Je ne sais pas combien de points étaient alloués à ce challenge.
Il s’agit du premier challenge forensic des challenges organisés le deuxième jour du FIC.
Nous avons un fichier PNG avec la description suivante « Tout est dans la RAM ».
# file Acissi_2k18.png Acissi_2k18.png: PNG image data, 340 x 50, 8-bit/color RGBA, non-interlaced
# du -h Acissi_2k18.png 303M Acissi_2k18.png
# binwalk Acissi_2k18.png DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- 0 0x0 PNG image, 340 x 50, 8-bit/color RGBA, non-interlaced 152 0x98 Zlib compressed data, best compression, uncompressed size >= 68121 21710 0x54CE Zip archive data, at least v2.0 to extract, compressed size: 316783029, uncompressed size: 1090610472, name: "locky.raw" 316804833 0x12E20EE1 End of Zip archive
Il y a donc un fichier zip après l’image.
# dd if=Acissi_2k18.png of=locky.zip bs=21710 skip=1 14591+1 records in 14591+1 records out 316783145 bytes (317 MB) copied, 5.90328 s, 53.7 MB/s
# 7z x locky.zip 7-Zip [64] 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18 p7zip Version 9.20 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,2 CPUs) Processing archive: locky.zip Extracting locky.raw Everything is Ok Size: 1090610472 Compressed: 316783145
# file locky.raw locky.raw: ELF 64-bit LSB core file x86-64, version 1 (SYSV)
# strings locky.raw | grep BOOT_IMAGE a07e8 file=/cdrom/preseed/custom.seed boot=casper initrd=/casper/initrd.gz quiet splash -- BOOT_IMAGE=/casper/vmlinuz 1ec3a98 Command line: file=/cdrom/preseed/custom.seed boot=casper initrd=/casper/initrd.gz quiet splash -- BOOT_IMAGE=/casper/vmlinuz ...
Cela ressemble à une extraction mémoire d’un Linux, et en googlant ‘/casper/vmlinuz’, il s’avère que c’est probablement une distribution Ubuntu, un « live » CD ou USB.
Après quelques tests, un membre de l’équipe a trouvé que le bon profile était disponible sur le github du projet volatility :
https://github.com/volatilityfoundation/profiles/blob/master/Linux/Ubuntu/x64/Ubuntu1404.zip
# vol.py -f locky.raw --profile=Linuxubuntu14x64 linux_banner Volatility Foundation Volatility Framework 2.6 Linux version 3.16.0-28-generic (buildd@batsu) (gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) ) #38-Ubuntu SMP Sat Dec 13 16:13:28 UTC 2014 (Ubuntu 3.16.0-28.38~14.04.1-generic 3.16.7-ckt1)
Parfait, nous pouvons continuer.
Encore une fois, il y a beaucoup de « bruits » dans ce dump, par exemple l’historique des commandes bash :
# vol.py -f locky.raw --profile=Linuxubuntu14x64 linux_bash | wc -l Volatility Foundation Volatility Framework 2.6 322
Mais à la fin de la liste, il y a quelque chose de suspect :
... 3660 bash 2017-01-12 08:58:01 UTC+0000 ./init_ 3660 bash 2017-01-12 08:58:05 UTC+0000 sudo ./init_ 3660 bash 2017-01-12 08:58:26 UTC+0000 sudo su 3660 bash 2017-01-12 08:58:55 UTC+0000 sudo chmod 777 init_ 3660 bash 2017-01-12 08:58:58 UTC+0000 ./init_
# vol.py -f locky.raw --profile=Linuxubuntu14x64 linux_getcwd | grep init_ Volatility Foundation Volatility Framework 2.6 init_ 3704 /home/cyborg/Downloads
Nous essayons de récupérer ce fichier :
# vol.py -f locky.raw --profile=Linuxubuntu14x64 linux_find_file -f /home/cyborg/Downloads/init_ -D . Volatility Foundation Volatility Framework 2.6 ERROR : volatility.debug : The requested file doesn't exist
Mais cela ne fonctionne pas. Un deuxième essai avec l’extraction du process fonctionnera mieux :
# vol.py -f locky.raw --profile=Linuxubuntu14x64 linux_pstree [...] ....gnome-terminal 3651 1000 .....gnome-pty-helpe 3659 1000 .....bash 3660 1000 ......init_ 3704 1000 [...]
# vol.py -f locky.raw --profile=Linuxubuntu14x64 linux_procdump -D . -p 3704 Volatility Foundation Volatility Framework 2.6 Offset Name Pid Address Output File ------------------ -------------------- --------------- ------------------ ----------- 0xffff880005783d20 init_ 3704 0x0000000008048000 ./init_.3704.0x8048000
# file init_.3704.0x8048000 init_.3704.0x8048000: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, stripped
Un reverse rapide sur le fichier met avant une chaine de caractères :
| 0x0804848e c7442408000. mov dword [esp+0x8], 0x0 | 0x08048496 c7442404000. mov dword [esp+0x4], 0x0 | 0x0804849e c744240f2a4. mov dword [esp+0xf], 0x616c462a | 0x080484a6 c74424135f6. mov dword [esp+0x13], 0x633d675f | 0x080484ae c7442417644. mov dword [esp+0x17], 0x24314064 | 0x080484b6 c744241b695. mov dword [esp+0x1b], 0x35725f69 | 0x080484be c744241f5e6. mov dword [esp+0x1f], 0x6735685e | 0x080484c6 c7442423646. mov dword [esp+0x23], 0x6e766d64 | 0x080484ce c7442427363. mov dword [esp+0x27], 0x2a353a36 | 0x080484d6 c644242b00 mov byte [esp+0x2b], 0x0
Ce qui correspond à : *Fla_g=cd@1$i_r5^h5gdmvn6:5*
Seulement voilà, cd@1$i_r5^h5gdmvn6:5 ne valide pas le challenge !
Il n’y a rien de particulier dans la description concernant le format du flag.
Je perds presque une heure sur binaire.
Il est plutôt simple, mais ne fait rien sur le chaine en question et crash. Je me dis que j’ai raté quelque chose dans le dump mémoire, mais je ne trouve rien de pertinent.
Finalement je soumets la chaine complète avec les « * » et le « Fla_g= », cela valide…
Yvan Genuer