Support technique
Documentation
Connexion
Nous contacter
Les bogues derrière les vulnérabilités - Partie 1
Joao Correia
31 octobre 2022 - Évangéliste technique
Il est courant d'entendre parler de nouvelles vulnérabilités et de nouveaux exploits, dont certains reçoivent même des noms fantaisistes, mais parfois les détails de leur apparition sont enfouis sous le code de preuve de concept et les scores d'impact.
Cette série d'articles vise à démystifier ces bogues cachés en donnant un aperçu des problèmes de code qui sont à l'origine de la plupart des failles de sécurité qui affectent les systèmes partout dans le monde.
Nous pourrions passer en revue les différents bugs et erreurs de code dans l'ordre que nous voulons. Mais Mitre a publié une liste des 25 bogues les plus dangereux en 2022, et cette liste est aussi bonne qu'une autre. Nous allons donc la passer en revue, en expliquant comment les problèmes de code conduisent à chacun de ces bogues et en indiquant certaines vulnérabilités qui découlent de la présence de ce code dans une application.
Dans le premier volet de cette série, nous examinerons les entrées 25 à 21 du Top 25 des bogues les plus dangereux de 2022, selon Mitre.
25 - Contrôle impropre de la génération du code ("injection de code")
Il s'agit d'un problème courant lorsqu'un programmeur ne fournit pas un code défensif suffisant pour les entrées fournies par l'utilisateur. En d'autres termes, le logiciel utilise les entrées qu'il reçoit sans les nettoyer, puis les utilise telles quelles pour alimenter les fonctionnalités internes.
À un niveau très bas, des entrées spécialement conçues peuvent modifier le fonctionnement du programme de manière imprévue, ce qui permet aux utilisateurs de mieux contrôler le programme et, dans certains cas, l'ensemble du système.
Cela conduit à des situations où l'entrée est soigneusement construite pour introduire des effets secondaires indésirables, comme la corruption de données ou des modifications involontaires du déroulement du programme.
Un cas particulier très courant de ce type de bogue est l'"injection SQL", qui mérite une catégorie à part plus loin dans cette série d'articles, mais qui n'est rien d'autre qu'un cas particulier d'injection de code.
Par exemple, l'utilisation de "eval()" en PHP est souvent une "odeur" de code qui indique une situation possible d'injection de code si la valeur passée n'est pas correctement validée au préalable.
24 - Restriction inappropriée de la référence à une entité externe XML
Les fichiers XML peuvent contenir des références à des documents externes dans le cadre de leur structure, mais cela peut conduire une application à charger des documents hors du champ d'application prévu. Il peut en résulter des problèmes de traversée de chemin, des accès incorrects à des fichiers ou des données erronées considérées comme bonnes par l'application.
Cela s'applique aux URI (identificateurs de ressources uniques) qui pointent vers d'autres fichiers locaux ou même vers des fichiers sur Internet en utilisant des URI file:// ou http://.
En plus de permettre l'accès à des fichiers autrement inaccessibles, il peut également être utilisé pour forcer l'application à traiter des quantités démesurées de données en lui fournissant des documents d'une taille inattendue, en la ralentissant, voire en rendant ces applications insensibles.
Si l'application ne s'en protège pas, il devient possible d'exploiter un système en créant un fichier XML de ce type :
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>
<stockCheck>
<productId>&xxe;</productId>
</stockCheck>
Et ensuite observer le résultat.
[Cet exemple provient de https://portswigger.net/web-security/xxe.]
Si le serveur cible est en mesure d'accéder à d'autres systèmes internes auxquels un attaquant ne pourrait normalement pas accéder, ce bogue pourrait être exploité comme tremplin pour obtenir des informations de ces systèmes.
Bogue 23 - Consommation incontrôlée des ressources
Toutes les ressources disponibles pour une application sont limitées : puissance de traitement, stockage, largeur de bande du réseau, capacité de mémoire, connexions aux bases de données, etc.
Si l'application peut être amenée à abuser d'une ou plusieurs de ces ressources, elle peut les épuiser et faire en sorte que l'application, ou dans certains cas l'ensemble du système, ne réponde pas ou soit carrément inutilisable.
Il peut apparaître dans le code sous la forme de fonctions à forte intensité de calcul qui ne sont pas protégées contre les appels répétés (alors que les appels précédents ne sont pas encore terminés), ou même de fonctions qui génèrent une quantité disproportionnée de données à partir de très petites entrées (par exemple, des messages d'erreur complexes à partir d'erreurs d'un seul caractère), qui sont deux sources potentielles de ce type de bogue.
Une autre manifestation courante de ce bogue est le cas où une application ne se débarrasse pas des ressources qu'elle a allouées, ce qui entraîne des erreurs de mémoire insuffisante ou quelque chose de similaire.
Il s'agit d'un type de bogue particulièrement grave qui est souvent difficile à diagnostiquer avant qu'une application n'atteigne le stade de la production - ou en raison de tests inadéquats - et qui peut potentiellement laisser une application dans un état de panne ou, pire encore, dans un état inattendu.
La plupart des outils d'analyse statique du code ont mis en place des contrôles pour détecter ce type de situation, mais comme le code peut être écrit de différentes manières, il est toujours possible d'avoir un code tellement alambiqué que ces outils d'analyse seront incapables de le détecter.
Bug 22 - Exécution simultanée utilisant une ressource partagée avec une synchronisation incorrecte ("Race Condition")
Lorsque plusieurs applications tentent d'utiliser la même ressource, ou même plusieurs threads au sein d'une même application, une certaine forme de coordination doit être mise en place pour s'assurer que chacun dispose de l'accès dont il a besoin aussi longtemps qu'il en a besoin.
Si ce n'est pas le cas, il peut arriver qu'une application commence à écrire dans un fichier en même temps qu'une autre application et qu'au final, vous ayez un mélange du contenu que vous étiez censé avoir dans le fichier, uniquement le contenu d'une des applications, ou même un fichier vide.
Ce type de situation étant très dépendant de la charge, il est également difficile à reproduire et à identifier de manière adéquate.
Elle peut affecter tout type de ressource, et pas seulement les fichiers. Par exemple, il peut avoir un impact sur les données en mémoire, les réseaux, les bases de données - à tel point que de nombreuses constructions spécifiques au langage ont été ajoutées au fil du temps pour faire face à cette situation, dans le but ultime de créer un type d'accès appelé "atomique", qui est garanti pour se produire complètement ou pas du tout, assurant ainsi qu'aucune lecture/écriture partielle ne se produise.
Une opération aussi simple que l'augmentation de la valeur d'une variable (x++) est en fait sujette à ce type de problème, car l'opération réelle est décomposée en de multiples opérations au niveau de la machine (lecture de la valeur originale de x, incrémentation de celle-ci, réaffectation de la nouvelle valeur à x). Si x était une variable partagée par plusieurs threads dans une application, cela pourrait conduire à des bogues si plusieurs threads essayaient de l'incrémenter en même temps.
Des constructions linguistiques telles que les mutex, les sémaphores et d'autres mécanismes de synchronisation des threads ont été introduits spécifiquement pour résoudre ce type de problème. Compte tenu de la prévalence des vulnérabilités provenant de cette catégorie de bogues, la mise en œuvre réussie de ces constructions peut être loin d'être idéale.
Bogue 21 - Falsification de requête côté serveur (SSRF)
Il est possible de tromper les serveurs pour qu'ils envoient les réponses aux requêtes à d'autres destinations que l'adresse du demandeur initial.
Comme décrit précédemment dans le bogue n° 24, il est possible de faire en sorte qu'une application accède à un autre contenu en incluant des URI dans des fichiers XML spécialement conçus. Si ces fichiers se trouvent dans un emplacement tiers, la requête semblera provenir du serveur traitant le fichier XML plutôt que du système de l'attaquant. Bien qu'il ne s'agisse pas du seul bogue entrant dans cette catégorie, il s'agit d'un exemple clair d'un serveur ou d'une application qui se fait piéger en établissant une connexion avec un système tiers.
Toute entrée qui peut contenir une liste d'URI qui ne sont pas correctement validés peut être utilisée comme mécanisme SSRF.
Par exemple, le format de fichier format de fichier M3U peut inclure des références à des fichiers externes. Si vous aviez un service web d'encodage vidéo qui accepte un fichier M3U comme liste de contenu, il serait possible d'inclure une référence à des fichiers système autrement inaccessibles et de les inclure dans la sortie du service web.
