Sécurité Linux/Cdorked.A : nouvelle porte dérobée discrète sur un Apache httpd modifié

Posté par . Édité par Nÿco, Benoît Sibaud et Florent Zara. Modéré par Benoît Sibaud. Licence CC by-sa
Tags : aucun
26
3
mai
2013
Sécurité

Une nouvelle porte dérobée (« backdoor ») utilisant un Apache httpd modifié, nommée Linux/Cdorked.A, a été détectée par ESET et Sucuri. L’intérêt de cette porte dérobée est qu'elle est très évoluée et se dissimule très bien, rendant difficile sa découverte. Seul le fichier binaire httpd (le démon Apache) est modifié, et toutes les informations du logiciel malveillant (« malware ») sont stockées en mémoire partagée. La configuration du logiciel malveillant et ses ordres sont envoyés par des requêtes HTTP GET rendues peu lisibles, mais surtout non-journalisées par Apache.

Ce logiciel malveillant redirige les utilisateurs vers des sites malveillants utilisant le paquet d'exploitation Blackhole, pour infecter le client. Après redirection, un cookie est enregistré sur le poste, pour ne plus rediriger l'utilisateur lors des prochaines visites. Ce cookie est aussi installé si la page demandée par l'utilisateur ressemble à une page d'administration (si l'URL contient des mots comme admin, webmaster, support) pour ne pas rediriger un potentiel administrateur du site afin de ne pas l'alerter.

NdM : merci à xenom pour son journal.

Actuellement une centaine de serveurs compromis ont été détectés. Les différents articles à ce sujet peuvent paraître alarmistes, car aucune nouvelle technique n'aurait été utilisée pour l'infection, il faut donc que le serveur présente une vulnérabilité quelconque permettant à l'attaquant d'installer la porte dérobée (faille logicielle, mot de passe SSH faible…), mais sa capacité de dissimulation, surtout sur l'utilisation de la mémoire partagée pour stocker son état et sa configuration la rend plutôt intéressante.

ESET recommande de vérifier tous ses serveurs, avec un outil mis à disposition sur leur site, ainsi que l'analyse technique.. Ajoutons que des outils comme rkhunter ou tripwire permettent de vérifier si des fichiers ont été modifiés, ce qui permet de détecter rapidement le remplacement de httpd.

  • # pas un vrai Apache

    Posté par . Évalué à  10 .

    (si j'ai bien compris…) Étant donné que le binaire httpd en question est un binaire fabriqué et placé là par un attaquant, est-il pertinent de dire qu'il s'agit d'une backdoor Apache ? Je dirais plutôt qu'il s'agit d'une backdoor qui se fait passer pour Apache, mais ce n'est pas un Apache.

    L'inconvénient de le présenter comme une "backdoor Apache" laisserait croire que c'est une vulnérabilité d'Apache. Ce qui n'est pas vrai.

    Ou alors je n'ai pas bien compris, et dans ce cas, merci de m'éclairer.

    • [^] # Re: pas un vrai Apache

      Posté par (page perso) . Évalué à  6 .

      Moi, sur le coup, j'ai compris que la fondation Apache avait intégré une backdoor dans son serveur. Tellement improbable que j'ai lu l'info. Et j'ai eu du mal a comprendre tout de suite le détail de l'histoire…

    • [^] # Re: pas un vrai Apache

      Posté par . Évalué à  4 . Dernière modification : le 03/05/13 à 13:54

      Tu as bien compris, c'est un Apache modifié pour intégrer une backdoor. L'attaquant remplace le binaire Apache par le sien.
      J'ai repris l'expression qu'on trouve dans l'article original d'ESET, mais c'est vrai que ca peut facilement etre mal compris.

      Il serait peut-être judicieux de remplacer la première phrase par "Une nouvelle porte dérobée (« backdoor ») remplaçant Apache"

    • [^] # Re: pas un vrai Apache

      Posté par (page perso) . Évalué à  7 .

      J'ai modifié le titre et la dépêche pour clarifier ce point.

Suivre le flux des commentaires

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