Un ver pour Apache

Posté par Olivier le 29 juin 2002 à 09:24. Modéré par Benoît Sibaud.

Étiquettes : aucune

juin

2002

Encore une faille de sécurité sur Apache. Et cette fois-ci, il semble que l'alerte soit assez grave pour suivre ceci de très près.

La faille a été détectée par un pot de miel (« honeypot »), sur un Apache 1.3.24, et ce qu'on en sait pour l'instant est que le code qui est propagé est un code pour FreeBSD. Par une requête HTTP qui est affichée sur le site, le ver s'installe sur le disque, et se met à écouter le port 2001 en UDP, et envoie des messages UDP vers une IP codée en dur...

Rien ne prouve pour l'instant que les autres plateformes ne sont pas vulnérable, car il peut exister plusieurs variantes de ce ver. D'après l'analyse du code qui a été récupéré sur le honeypot, il s'avère que les versions suivantes d'Apache seraient vulnérables, du moins avec FreeBSD :
- FreeBSD 4.5 x86 / Apache/1.3.22-24 (Unix)
- FreeBSD 4.5 x86 / Apache/1.3.20 (Unix)

A suivre de très près...

Aller plus loin

Analyse du ver (2 clics)
Message posté sur FreeBSD-security et Bugtraq (2 clics)
Autre analyse (2 clics)
Discussion sur Bugtraq (2 clics)

# ZDNet en parle aussi

Posté par Korbinus (site web personnel) le 29 juin 2002 à 09:47. Évalué à 10.

http://zdnet.com.com/2100-1105-940601.html(...)

En résumé, ca raconte que ca marche que sur FreeBSD, que ca fait planter l'Indien sur les autres plateformes, et que ça pourrait être en fait utilisé pour des DoS.

-1 parce que je voulais être le premier à poster :-)
- [^] # Re: ZDNet en parle aussi
  
  Posté par Sébastien Koechlin le 29 juin 2002 à 17:20. Évalué à 10.
  
  Maintenant que le code source du vers a été publié, on peut s'attendre à ce que de nouvelles variantes surgissent sur le net, avec plus de dégats et éventuellement plus de plateforme supportée...
  
  Ceci dit, vu l'hétérogénéité du parc sur lequel tourne Apache, je pense qu'il y a peu de risque
  que ça fasse comme CodeRed et Nimda qui circulent toujours.
# On casse beaucoup de sucre sur le dos de m$, mais ...

Posté par Yves Dessertine le 29 juin 2002 à 10:06. Évalué à 1.

... Apache n'est pas non plus exempt de bugs. Bon, il n'est pas aussi buggé que IIS, mais le plus important, c'est que la faille sera sans doute assez rapidement corrigée (du moins, je l'espère), contrairement à d'autres...
- [^] # Re: On casse beaucoup de sucre sur le dos de m$, mais ...
  
  Posté par Euclide (site web personnel) le 29 juin 2002 à 10:18. Évalué à 10.
  
  Vu ce que ca utilise (les chunks) ca doit utiliser la derniere faille en date pour apache.
  Donc le patch est déjà sorti.
  (c'est corrigé dans apache 1.3.26 et 2.0.39)
# J'aime pas les news alarmistes

Posté par Anonyme le 29 juin 2002 à 11:11. Évalué à 10.

Ce ver utilise la vulnérabilité connue depuis plus d'une semaine maintenant, celle des chunks. Ce n'est donc pas une nouvelle faille de sécu sur Apache, mais la même exploitée par un ver.
A priori, il doit utiliser l'algo proposé par gobbles et doit fonctionner sur *BSD.
Si vous avez patché la semaine dernière, vous êtes tranquille...
- [^] # Re: Moi non plus
  
  Posté par Annah C. Hue (site web personnel) le 29 juin 2002 à 11:26. Évalué à -10.
  
  Même si on n'est pas touché par le bug, si la propagation du ver est assez importante (ce qui m'étonnerait vu qu'il doit pas y avoir plus de 100 serveurs freebsd dans le monde), on va encore avoir des remplissages inutiles de logs, comme avec les vers pour les IIS (qui continuent encore : j'ai environ une tentative d'attaque par jour chez moi, saloperie de windows, c'est vraiment un amplificateur de bugs ce "système").
  - [^] # Re: Moi non plus
    
    Posté par spim le 29 juin 2002 à 12:02. Évalué à 3.
    
    (ce qui m'étonnerait vu qu'il doit pas y avoir plus de 100 serveurs freebsd dans le monde)
    
    Troll minable, -1
    
    (et -1 pour moi aussi en passant)
# Le code source dispo !!!

Posté par Foxy (site web personnel) le 29 juin 2002 à 11:28. Évalué à 10.

Le decouvreur du vers (Domas MItuzas) vient de recevoir le code source du ver dans son mail !!!! Il vient de poster la news sur BugTraq.

Le code du vers est dispo ici, pour analyse : http://dammit.lt/apache-worm/apache-worm.c(...)
- [^] # Re: Le code source dispo !!!
  
  Posté par Christophe Merlet (site web personnel) le 29 juin 2002 à 16:51. Évalué à 10.
  
  C'est quelle license ? GPL ? C'est pas indiqué dans le source
  
  Je peux le modifier pour créer mon propre virus ? Je suis obligé de redistribuer mes modifications ?
  
  ([+1] parce que je le veau bien)
# difficile à retrouver dans les logs

Posté par Lucas le 29 juin 2002 à 14:36. Évalué à 10.

A noter que la requete envoyée par le client pour tenter de "conquérir" d'autres machines est :
write(sock,"GET / HTTP/1.1\r\n\r\n",strlen("GET / HTTP/1.1\r\n\r\n"));
Etant donné d'un qu'il s'agit d'un simple GET tout classique, il sera difficile d'évaluer la propagation du vers, à moins de se baser sur les requêtes sans UserAgent... mais c'est pas très fiable.

On peut déjà s'attendre à ce que Microsoft annonce sur MSNBC que 99.99% du trafic vers www.microsoft.com est causé par le vers, puisqu'il s'agit de requêtes GET :)

(les autres HTTP GET présents dans les sources sont utilisés par les fonctions de DDOS)
- [^] # Re: difficile à retrouver dans les logs
  
  Posté par jimee (site web personnel) le 01 juillet 2002 à 11:00. Évalué à 4.
  
  Dans les logs d'apache, ca sera un peu plus visible. Si la réponse au GET contient un entête commençant par Server: Apache, la requête est immédiatement suivie par 2 tentatives de POST / HTTP/1.1 et ce, quelles que soient la version d'apache et la plateforme.
  
  Petit détail pour les paranos du spam comme moi, parmi les divers fonctionnalités du serveur udp, en plus des DDOS, une commande permet de récupérer tous les emails stockés sur l'arborescence (en évitant /bin, /dev et /proc), ainsi qu'une autre pour envoyer un mail à toute une liste d'adresses (avec résolution des MX et tout).

Suivre le flux des commentaires

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