Support technique
Documentation
Connexion
Nous contacter
Les bogues derrière les vulnérabilités Partie 2
Joao Correia
14 novembre 2022 - Évangéliste technique
Nous continuons à examiner les problèmes de code à l'origine des vulnérabilités qui ont un impact sur le monde informatique. Dans cet épisode de notre série de blogs en cinq parties qui explore ces bogues, nous passons en revue les bogues n°20 à n°16 du Mitre CWE Top 25 de Mitre pour 2022 - en fournissant un contexte et des informations supplémentaires sur les problèmes de code réels qui conduisent à des vulnérabilités dans les applications et les systèmes en général.
Vous pouvez trouver le post précédent de cette série ici.
20 - Permissions par défaut incorrectes
Cette catégorie de bogues provient de la façon dont les progiciels sont préparés - soit au niveau du système d'exploitation, soit au niveau de l'application - en incluant des permissions pour un sous-ensemble d'éléments dont la portée est trop large. En général, il s'agit de fichiers exécutables dont les permissions permettent à des utilisateurs non privilégiés d'exécuter ces fichiers alors qu'ils ne devraient pas pouvoir le faire ou d'exécuter ces fichiers avec des privilèges tels qu'ils peuvent manipuler d'autres composants du système de manière involontaire.
Cela peut également se produire dans l'autre sens : une autorisation trop restrictive pour un fichier exécutable, et le système d'exploitation trouve alors automatiquement une alternative située dans un emplacement contrôlé par l'attaquant (plutôt que le composant inclus dans le paquetage d'origine).
Le principal risque est que ce sont les par défaut par défaut, donc dès que le paquet est déployé, il est immédiatement menacé sans qu'aucune autre action ne soit nécessaire. Cela déplace le vecteur de risque de utilisation à déploiement.
19 - Restriction inappropriée des opérations dans les limites d'un tampon mémoire
Généralement appelée "débordement de tampon" ou "dépassement de tampon", cette anomalie tente de lire une position dans la mémoire en dehors de l'espace pré-établi pour une variable donnée, ou d'écrire à un tel emplacement.
Cela peut se produire soit en passant intentionnellement un emplacement mémoire qui se trouve en dehors du tampon, soit en utilisant le résultat d'une opération comme position de lecture/écriture sans valider s'il est acceptable ou non dans le contexte donné.
Prenons l'exemple suivant :
int main (int argc, char **argv) {
char *items[] = {"A", "B", "C", "D"};
int index = AskUserForIndex();
printf("You selected %s\n", items[index-1]);
}
(Exemple de code adapté de celui présent sur https://cwe.mitre.org/data/definitions/119.html)
Dans cet exemple, si l'utilisateur saisit "5" comme indice, le programme s'y pliera volontiers et renverra le contenu d'un emplacement mémoire situé en dehors du tableau. Selon le système d'exploitation et l'architecture de la mémoire, plusieurs choses peuvent se produire : des valeurs de mémoire hors de l'espace du programme peuvent être renvoyées, le programme peut se planter, un autre programme peut se planter (si une écriture se produit), l'état du système peut être compromis, ou rien ne se plante et l'attaque peut être répétée. Il est possible de lire de grandes quantités de mémoire en répétant le processus avec différentes valeurs d'index.
Cette catégorie de bogues peut créer des problèmes lors de la lecture, mais aussi lors de l'écriture de valeurs dans un tampon - en écrivant plus de données que le tampon n'a été créé pour en accueillir. Si la région de la mémoire située juste après le tampon contient un drapeau qui indique si l'utilisateur a des privilèges ou non, un simple changement d'octet peut transformer un utilisateur normal en administrateur.
Bien que ce type de bogue soit généralement enseigné dans les cours de programmation, ainsi que la manière de l'éviter en plaçant des contrôles avant tout accès à la mémoire, il n'est parfois pas évident de savoir où le problème se produit en premier lieu. Les outils d'analyse statique du code, l'examen par les pairs et la programmation en binôme sont autant de moyens d'essayer d'attraper ces problèmes avant qu'ils ne se retrouvent dans le code de production.
Un autre concept lié à la programmation est le "canari" (analogue au canari dans une mine de charbon), dans lequel une valeur est écrite juste après le tampon, puis sa présence est vérifiée après l'écriture d'une valeur dans le tampon. Si la valeur d'origine n'est plus présente, le programmeur peut supposer qu'un dépassement de tampon s'est produit et faire planter intentionnellement l'application pour éviter d'autres dommages ou traiter le problème en alertant l'utilisateur ou par un autre mécanisme. Bien qu'utile, les attaquants astucieux peuvent contourner ces problèmes en incluant la valeur canari dans la nouvelle valeur afin de ne pas la déclencher.
18 - Authentification manquante pour une fonction critique
Toute fonction modifiant la fonctionnalité doit valider si l'acteur effectuant l'action est autorisé à le faire ou non, et empêcher l'action lorsque l'acteur n'est pas autorisé à le faire. Lorsqu'une application ne parvient pas à valider ces éléments, elle entre dans cette catégorie.
Les applications effectuent souvent des tâches telles que l'ajout, la suppression, la modification ou l'effacement de données, d'utilisateurs ou de connexions. Il suffit qu'une de ces actions soit manquante, comme une vérification d'authentification pour l'ensemble de l'application, pour que celle-ci soit compromise ou peu fiable. Et comme chacune de ces opérations comporte plusieurs étapes, la validation devrait idéalement intervenir à chaque étape ou, à défaut, aux points d'entrée de chaque processus.
Un autre exemple typique est celui des contrôles d'authentification manquants dans le stockage en nuage (c'est-à-dire "leaky S3 buckets"), où des données confidentielles sont accidentellement stockées de manière publiquement accessible.
17 - Neutralisation incorrecte des éléments spéciaux utilisés dans un commandement
Lorsqu'une entrée est acceptée par une application puis exécutée, si elle n'est pas correctement vérifiée, elle peut contenir des commandes, des paramètres ou des drapeaux supplémentaires qui modifient son objectif.
Si une application système est censée exécuter une commande avec un paramètre fourni par l'utilisateur, un utilisateur rusé pourrait inclure un caractère de fin de commande suivi d'une commande différente qui s'exécuterait alors avec le même niveau de privilège que le programme d'origine. Ces types de problèmes sont étroitement liés aux bogues d'"injection SQL" et de "contrôle inapproprié du code généré", car ils proviennent tous de la confiance implicite accordée aux entrées.
La source du problème se situe généralement au niveau de l'architecture, où les questions de sécurité ne sont pas prises en compte de manière adéquate, ce qui introduit des comportements non sécurisés dans les applications. En règle générale, aucune entrée ne devrait jamais être considérée comme bonne - idéalement même au niveau de la fonction individuelle, mais au moins au niveau de l'application.
16 - Autorisation manquante
Dans le numéro 18, nous avons vu comment certaines parties d'une application pouvaient manquer une vérification d'authentification. Dans celui-ci, nous examinons comment une autorisation manquante peut également entraîner des problèmes.
Il est courant pour les sites web de protéger les sections sensibles derrière des mécanismes d'authentification, mais chaque page individuelle doit appliquer ce contrôle au risque que l'accès direct à une URL divulgue des informations autrement inaccessibles. Cela s'applique aux téléchargements, téléchargements et requêtes et pas seulement aux accès aux pages.
Au niveau de l'application traditionnelle, l'autorisation manquante se produit lorsque la confiance implicite est accordée à un utilisateur ou à une application d'appel externe.
Comme dans le cas du n° 17, la faille provient généralement de la phase architecturale du développement - ne pas prendre en compte les tactiques de sécurité adéquates pour appliquer des mécanismes de contrôle d'accès appropriés à tous les niveaux. Identifier puis corriger le code d'une application donnée après l'identification de ce type de bogue entraîne généralement une charge de travail importante, car le code doit être remanié en profondeur pour être correctement sécurisé après coup.
Au niveau du système d'exploitation, ce type de problème se produit lorsqu'un outil n'est pas associé à une liste de contrôle d'accès, ce qui permet à tout utilisateur de l'exécuter.
