Le principe des backdoors est aussi vieux que l’informatique. « Le but est finalement de laisser l’utilisateur installer lui-même la vulnérabilité qui permettra de compromettre sa machine », résume à merveille Chris Wysopal, ancien membre du groupe L0pht et aujourd’hui CTO de la société Veracode .

Et ce n’est pas de la science-fiction : d’après une étude du Department of Defense américain, citée par Wyzopal, les backdoors sont l’outil privilégié des attaquants de haut niveau. Elles permettent notamment de dissimuler le trafic malveillant aux yeux des IDS/IPS, pour qui il ne s’agit que d’un flux applicatif normal.

Selon Chris Wysopal la détection des backdoors ne peut que se faire qu’en analysant l’application elle-même, car il est très difficile de suivre la « supply chain » d’un éditeur de logiciels. Il existe tout simplement trop d’opportunités de placer une backdoor durant le développement ou la livraison d’une application pour sécuriser cette voie là.

L’analyse préconisée par Veracode est statique (observation du code) : une analyse dynamique (analyse du comportement à l’exécution) est considérée trop complexe. Cette analyse statique peut porter aussi bien sur le code source (ce qui facilite bien entendu la tâche) que sur un binaire.

Mais que rechercher exactement ? Voici une liste de points suspects notés par Chris Wyzopal lors de ses précédents audits :

– Des valeurs statiques (logins, mots de passe ou hashes) stockées en dur dans le code. Par exemple : la paire login / mot de passe qui apparaissait en dur dans Borland Interbase (le fameux « politically : correct »)

– Des valeurs statiques envoyées à la routine de chiffrement. Par exemple la solution NetStructure d’Intel, où un mot de passe était dérivé de l’adresse MAC de l’interface réseau afin de faciliter l’accès des techniciens de maintenance à distance.

– Des variables statiques qui ressemblent à des clés cryptographiques.

– Des paramètres invisibles récupérés depuis l’URL (pour les applications web).

– L’usage de la commande « passthru » en PHP (ou ses variantes). Elle est souvent utilisée dans le cadre d’une backdoor pour exécuter des commandes shell sur le système à partir de l’URL (par exemple le CMS Artmedic).

– Des routines pour dissimuler des blocs de code (en base64, XOR, ou via la fonction eval() ).

– Des constructions de code communes aux backdoors telles que dissimuler une chaîne, la passer à travers une routine de déchiffrement puis directement à une fonction telle eval() ou similaire.

– Des comparaisons avec des valeurs d’adresses IP ou de noms de domaine stockés en dur dans l’application.

– Des routines de chiffrement qui ne sont pas utilisées par le reste du code.

– Des actions qui sortent du cadre de la logique du programme. Par exemple changer l’UID après une condition.

– Des connexions sortantes (usage d’API sockets, etc…) qui n’auraient pas lieu d’être.

Enfin, Chris Wyzopal offre une astuce pour faciliter les audits de binaires : il conseille de procéder systématiquement à une analyse de l’entropie : des portions à l’entropie élevée indiquent généralement la présence de données chiffrées, qui doivent alors être étudiées (d’où viennent elles, comment sont-elles utilisées par l’application…).