2.6 CVE-2004-0473

Ce type d'attaque implique qu'un attaquant exploite les métacaractères des en-têtes de courriel pour injecter un comportement inapproprié dans les programmes de courriel. Les logiciels de messagerie sont devenus de plus en plus sophistiqués et riches en fonctionnalités. En outre, les applications de messagerie sont omniprésentes et directement connectées au Web, ce qui en fait des cibles idéales pour lancer et propager des attaques. Au fur et à mesure que la demande des utilisateurs pour de nouvelles fonctionnalités dans les applications de messagerie augmente, ces dernières ressemblent de plus en plus à des navigateurs avec un rendu complexe et des routines de branchement. Plus la fonctionnalité de messagerie est incluse et abstraite de l'utilisateur, plus cela crée des opportunités pour les attaquants. Pratiquement toutes les applications de messagerie n'affichent pas d'informations d'en-tête par défaut, mais l'en-tête de la messagerie contient des vecteurs d'attaque précieux que le pirate peut exploiter, en particulier s'il connaît le comportement de l'application client de messagerie. Les métacaractères sont cachés à l'utilisateur, mais peuvent contenir des scripts, des énumérations, des sondes et d'autres attaques contre le système de l'utilisateur. Identifier et caractériser les vulnérabilités du traitement des métacaractères dans les en-têtes de courriel] Un attaquant crée des courriels dont les en-têtes contiennent diverses charges utiles malveillantes à base de métacaractères afin de déterminer si l'application cible traite le contenu malveillant et de quelle manière elle le fait. Un attaquant exploite les vulnérabilités identifiées au cours de la phase d'expérimentation pour injecter des en-têtes de courriel malveillants et faire en sorte que l'application de courriel ciblée présente un comportement en dehors des contraintes prévues.

Dans ce type d'attaque, un adversaire injecte des commandes du système d'exploitation dans les fonctions d'une application existante. Une application qui utilise des entrées non fiables pour construire des chaînes de commande est vulnérable. Un adversaire peut tirer parti de l'injection de commandes du système d'exploitation dans une application pour élever ses privilèges, exécuter des commandes arbitraires et compromettre le système d'exploitation sous-jacent. Identifier les entrées pour les commandes du système d'exploitation] L'attaquant détermine les entrées contrôlables par l'utilisateur qui sont transmises dans le cadre d'une commande au système d'exploitation sous-jacent. L'attaquant examine l'application cible, éventuellement en tant qu'utilisateur valide et authentifié [Varier les entrées, à la recherche de résultats malveillants] Selon que l'application exploitée est distante ou locale, l'attaquant crée l'entrée malveillante appropriée, contenant des commandes du système d'exploitation, à transmettre à l'application [Exécuter des commandes malveillantes] L'attaquant peut voler des informations, installer un mécanisme d'accès par porte dérobée, élever les privilèges ou compromettre le système d'une autre manière.

Un adversaire manipule le contenu des paramètres de requête dans le but de porter atteinte à la sécurité de la cible. Certains codages de paramètres utilisent des caractères de texte comme séparateurs. Par exemple, les paramètres d'un message HTTP GET sont codés sous forme de paires nom-valeur séparées par une esperluette (&). Si un attaquant peut fournir des chaînes de texte qui sont utilisées pour remplir ces paramètres, il peut alors injecter des caractères spéciaux utilisés dans le schéma de codage pour ajouter ou modifier des paramètres. Par exemple, si l'entrée de l'utilisateur est introduite directement dans une requête HTTP GET et que l'utilisateur fournit la valeur "monEntrée&nouveau_param=maValeur", le paramètre d'entrée est défini comme monEntrée, mais un nouveau paramètre (nouveau_param) est également ajouté avec une valeur de maValeur. Cela peut modifier de manière significative la signification de la requête traitée par le serveur. Tout schéma de codage dans lequel les paramètres sont identifiés et séparés par des caractères de texte est potentiellement vulnérable à cette attaque - le codage HTTP GET utilisé ci-dessus n'est qu'un exemple.

Un adversaire profite d'une validation incorrecte des données pour injecter des paramètres globaux malveillants dans un fichier Flash intégré à un document HTML. Les fichiers Flash peuvent exploiter les données soumises par l'utilisateur pour configurer le document Flash et accéder au document HTML embarqué. [À l'aide d'un navigateur ou d'un outil automatisé, un adversaire enregistre toutes les instances de documents HTML contenant des fichiers Flash intégrés. S'il existe un fichier Flash intégré, il répertorie la manière de transmettre des paramètres globaux au fichier Flash à partir de l'objet intégré. [Déterminer la sensibilité de l'application à l'injection de paramètres Flash] Déterminer la sensibilité de l'application à l'injection de paramètres Flash. Pour chaque URL identifiée dans la phase d'exploration, l'adversaire tente d'utiliser diverses techniques telles que les attaques basées sur le DOM, réfléchies, flashvars et persistantes, en fonction du type de paramètre transmis au fichier Flash intégré. [Execute Flash Parameter Injection Attack] Injection de paramètres dans le fichier Flash. Sur la base des résultats de la phase d'expérimentation, l'adversaire crée l'URL malveillante sous-jacente contenant les paramètres Flash injectés et la soumet au serveur Web. Une fois que le serveur Web a reçu la demande, le document HTML intégré est contrôlable par l'adversaire.

Un adversaire ajoute des paramètres HTTP GET/POST en double en injectant des délimiteurs de chaîne de requête. Grâce au HPP, il peut être possible de remplacer les paramètres HTTP codés en dur, de modifier les comportements de l'application, d'accéder à des variables incontrôlables et de les exploiter, ainsi que de contourner les points de contrôle de validation des entrées et les règles WAF. [Trouver l'entrée de l'utilisateur] L'adversaire trouve n'importe quel endroit de l'application web qui utilise une entrée fournie par l'utilisateur dans un formulaire ou une action. Cela peut également se faire en examinant les paramètres de l'URL dans la barre de navigation du navigateur. [Ajouter des valeurs de paramètres en double] Une fois que l'adversaire a identifié les entrées utilisateur utilisées comme paramètres HTTP, il ajoute des valeurs en double à chaque paramètre, un par un, pour observer les résultats. Si la réponse à la requête HTTP montre la valeur du paramètre dupliqué concaténé avec la valeur du paramètre d'origine d'une manière ou d'une autre, ou simplement la valeur du paramètre dupliqué, alors le HPP est possible. [Une fois que l'adversaire a identifié la manière dont le backend traite les paramètres dupliqués, il en tirera parti en polluant les paramètres d'une manière qui lui est profitable. Dans certains cas, les paramètres codés en dur ne seront pas pris en compte par le backend. Dans d'autres cas, l'adversaire peut contourner un WAF qui ne vérifie un paramètre qu'avant qu'il ne soit concaténé par le backend, ce qui permet aux requêtes malveillantes de passer.