FIC 2018 – Quelques solutions des challenges forensics

CERT-DVT Forensics, Writeups

1 Introduction

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.

2 Forensic – 50

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…

3 bashjail – 100

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

4 forensic – 150

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

5 Forensic – 250

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.

6 Forensic – ???

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