TP1 RC54

Le présent rapport a pour but montrer les étapes suivies pour s’introduire dans un système pour lequel nous ne possédons pas les autorisations.

Pour ce faire nous utiliserons Kali Linux et les outils que cette distribution met à notre disposition.

Initialisation

Avant toute chose, il faut lancer nos machines.

Pour Kali, il n’y a pas de problème. C’est notre poste de travail, sur lequel nous avons tous les accès.

Sur l’autre machine, en revanche, c’est un peu plus compliqué :

Nous arrivons sur le login, mais nous n’avons pas connaissance des identifiants.

Scan des ports

Pour tenter l’intrusion, la première chose que nous allons faire est un scan du réseau.

Nous savons que les deux machines sont sur le même réseau local, dont nous pouvons essayer de deviner la plage d’addresses à partir de celle que le DHCP nous a attribué :

root@kali:~# ifconfig eth1
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.56.103  netmask 255.255.255.0  broadcast 192.168.56.255
        inet6 fe80::ca06:299e:8793:9d8d  prefixlen 64  scopeid 0x20<link>
        ether 08:00:27:8f:86:22  txqueuelen 1000  (Ethernet)
        RX packets 185  bytes 25734 (25.1 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 129  bytes 18572 (18.1 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Notre addresse est 192.168.5.103, nous allons donc tenter de scanner la plage d’addresses 192.168.5.0/24. Pour ce faire, nous utilisons le logiciel zenmap.

Nous avons quatre machines sur le réseau :

• 192.168.56.1 : l’hôte VirtualBox
• 192.168.56.100 : le serveur dhcp
• 192.168.56.102 : la machine sur laquelle nous voulons nous introduire
• 192.168.56.103 : notre machine

Sur 192.168.56.102, les ports suivants sont ouverts :

Samba

On peut constater que le port de Samba est ouvert.

On va donc essayer de s’y connecter :

Il n’y a pas de fichier intéressant disponible.

On peut cependant constater que nous avons les droits en écriture. Nous pourrions donc éventuellement remplir le disque entièrement, et ainsi créer un déni de service. Ce n’est pas notre objectif ici, mais c’est un vecteur d’attaque possible.

Accès à MySQL

Nous pouvons également constater que le port de MySQL est ouvert.

Nous allons donc essayer de nous y introduire.

Nous avons le droit de voir toutes les bases de données. Nous pouvons également nous y connecter.

En se baladant dans les tables, on peut constater que tous les mots de passe sont écrits en clair :

Sachant la propention des utilisateurs à utiliser le même de passe pour plusieurs services, il s’agit d’une faille grave. Au-delà de notre objectif, de telles données pourraient être utilisées pour nous connecter sur les comptes d’autres sites appartenant à ces personnes.

Nous pouvons également essayer ces identifiants pour voir si certains possèdent un compte sur le système avec le même mot de passe. Cependant, aucun essai n’est probant avec ces identifiants.

Avant de partir, nous pouvons également supprimer les données présentes sur le serveur.

/etc/shadow et John the Ripper

Parmis les ports ouverts se trouve également le port nfs. Nous pouvons donc monter le système de fichier de la machine cible sur notre machine à nous :

Si nous avons accès au fs, alors nous avons accès au fichier /etc/shadow :

A partir de ces données, nous pouvons tenter une attaque par dictionnaire en utilisant John the Ripper :

(Note : les résultats sont incomplets, étant donné que la commande n’avait pas fini de tourner au moment de la fin du TP.)

Chroot

A partir du montage en NFS, nous avons tous les droits sur le fs de la cible. Nous pouvons donc déjà syphonner toutes les données présentes sur le système.

Encore mieux, nous pouvons utiliser la commande chroot sur le point de montage, puis passwd pour récupérer le compte root :

Et nous pouvons maintenant nous connecter :

Conclusion

Comme ce rapport a été rédigé dans le cadre d’un TP de RC54, il faut bien entendu tirer les leçons des manipulations que nous venons d’effectuer.

En particulier : LES PORTS INUTILES DOIVENT RESTER FERMÉS !

Tout ce que nous avons effectué n’aurait pas été possible si seuls les ports 80 et 443 (et éventuellement 22) étaient restés ouverts. La règle pour les ports réseaux est la même que pour la plupart des choses en cybersécurité : tout doit être inaccessible par défaut et ouvert uniquement au besoin.