Dans un monde idéal, les vulnérabilités n’existeraient pas. Une requête serait envoyée à un serveur, correctement validée, et seules les informations prévues seraient fournies par le serveur. Bien sûr, ce n’est pas un monde parfait, et des vulnérabilités peuvent être introduites involontairement, ou même trouvées en raison de faiblesses jusque-là inconnues dans le langage de programmation.

Un type de vulnérabilité qui peut avoir de graves conséquences si elle est exploitée, mais dont on ne parle pas souvent, est la contrefaçon de requête côté serveur (SSRF).

Qu’est-ce que la contrefaçon de requête côté serveur ?

Server Side Request Forgery (SSRF) est un type de vulnérabilité qui permet à un attaquant d’abuser des fonctionnalités normales du serveur en demandant au serveur d’envoyer une requête sur laquelle l’attaquant a le contrôle. Cela peut être accompli relativement simplement avec une URL modifiée dans un navigateur, ou en utilisant un outil comme Burp Suite pour capturer la requête du navigateur et la modifier avant de l’envoyer au serveur.

Les vulnérabilités SSRF ne sont souvent pas difficiles à exploiter, mais peuvent fournir à un acteur malveillant des informations qui peuvent l’aider dans d’autres attaques, ou même lui permettre de faire des demandes aux ressources internes qui peuvent entraîner une altération des données. Dans certains cas, un pirate peut être en mesure d’exécuter des commandes arbitraires sur le serveur, ce qui lui permet d’effectuer une prise de contrôle complète d’un site vulnérable.

Un exemple concret : Vulnérabilité liée à la falsification des requêtes côté serveur dans le plug-in Google Web Stories

Le 25 octobre 2022, un Vulnérabilité SSRF dans le plugin Web Stories par Google a été divulgué dans les versions <= 1.24.0. Cette vulnérabilité a été découverte et divulguée de manière responsable par Aymen Borgi qui a demandé un identifiant CVE à l’équipe Wordfence.

Clôture des mots Prime, Se soucieret Réponse les utilisateurs ont reçu une règle de pare-feu pour bloquer les tentatives d’exploitation ciblant cette vulnérabilité SSRF le 27 octobre 2022. Wordfence Libérer les utilisateurs ont reçu la règle de pare-feu 30 jours plus tard, le 26 novembre 2022.

La vulnérabilité existait en raison d’une validation incorrecte des URL fournies via le paramètre ‘url’ appelé via le point de terminaison de l’API REST /v1/hotlink/proxy. En exploitant cette vulnérabilité, un utilisateur authentifié pourrait effectuer des requêtes Web vers des emplacements arbitraires provenant de l’application Web. L’utilisateur authentifié n’a pas besoin de privilèges de haut niveau pour exploiter cette vulnérabilité. L’attaque peut réussir pour les utilisateurs connectés avec un compte disposant d’autorisations minimales telles qu’un abonné, ce qui serait un accès facile à obtenir sur des sites à inscription ouverte.

Cette vulnérabilité nécessite que l’auteur de la menace obtienne son propre nonce REST, ce qui est un processus simple. Pour obtenir le nonce, il vous suffit de vous connecter au site Web, puis de vous rendre sur le site Web avec /wp-admin/admin-ajax.php?action=rest-nonce annexé au nom de domaine.

nonce

Une fois le nonce obtenu, la vulnérabilité peut être facilement exploitée. A ce stade, un attaquant peut fournir un chemin vers un service interne via le paramètre ‘url’ lors de l’appel du /web-stories/v1/hotlink/proxy Point de terminaison de l’API REST et accédez aux ressources internes.

Tirer parti de la falsification des demandes côté serveur pour extraire des informations sensibles sur AWS

Si le site est hébergé sur un serveur Amazon Web Services (AWS), la collecte des métadonnées AWS est relativement simple. Cet exploit nécessite uniquement d’appeler le point de terminaison de l’API REST approprié avec la bonne charge utile dans le paramètre ‘url’ pour réussir l’exploit. Ce qui suit est un exemple:

?rest_route=/web-stories/v1/hotlink/proxy&url=http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance&_wpnonce=f76869efe5

Les _wpnonce valeur serait remplacée par le nonce obtenu à la première étape. Une fois la vulnérabilité exploitée avec succès, les métadonnées AWS seront affichées dans le navigateur. Comme on le voit ici, les métadonnées demandées incluent des informations sensibles telles que AccessKeyId, SecretAccessKey et Token.

Métadonnées AWS

Ces métadonnées spécifiques sont utilisées pour identifier le logiciel sur l’instance auprès de l’instance EC2 afin d’utiliser des fonctionnalités telles que EC2 Instance Connect. Cette fonctionnalité pourrait alors permettre à un attaquant réussi de se connecter au serveur virtuel et d’exécuter des commandes via le terminal. Il y a beaucoup de catégories de métadonnées fournies par AWS qui ont chacun des utilisations spécifiques et des degrés de gravité variables s’ils sont mal utilisés.

Bien que le plug-in Google Web Stories ait tenté de valider le paramètre ‘url’ lors de sa première tentative de correction de la vulnérabilité, il n’a pas pris en compte AWS dans le code. Deux blocs de code ont été mis à jour pour corriger complètement la vulnérabilité du plugin. Dans le premier bloc de code, des plages d’adresses IP supplémentaires ont été ajoutées à la liste de validation d’URL.

bloc de code 1

L’adresse IP AWS a également été ajoutée en tant qu’adresse IP non autorisée.

bloc de code 2

Avec le correctif appliqué dans la version 1.25.0 et les versions ultérieures, les tentatives d’obtention des métadonnées AWS échoueront.

Comment empêcher la création d’une vulnérabilité de falsification de requête côté serveur

Empêcher la création de vulnérabilités SSRF est similaire à d’autres vulnérabilités. Les développeurs doivent développer leur code d’une manière qui tient compte des vulnérabilités dans le langage de programmation choisi et s’assure également que toute entrée est correctement filtrée et validée.

Afin de valider correctement l’entrée, le développeur doit comprendre comment la fonctionnalité peut être mal utilisée et éliminer par programmation chaque manière dont la fonctionnalité peut être mal utilisée. C’est pourquoi la compréhension de l’impact des vulnérabilités telles que les vulnérabilités SSRF est essentielle pour les développeurs. La sécurité du code peut être difficile à garantir pendant la phase de développement, c’est pourquoi le code doit être testé pour les vulnérabilités pendant et après son écriture.

Pour les vulnérabilités SSRF en particulier, la meilleure méthode pour les développeurs de sécuriser le point de terminaison consiste à s’assurer que toutes les formes d’entrée sont correctement validées et que les URL sont correctement restreintes si elles sont transmises à une fonction qui appelle l’URL. Cela signifie que chaque entrée ne doit être acceptée que si elle respecte le formatage et le contenu attendus, et des contrôles doivent être en place pour s’assurer que l’utilisateur actuel est autorisé à faire la demande. Si la requête ne correspond pas à ce qui est attendu de l’application, si l’utilisateur n’est pas autorisé pour la requête ou si l’emplacement d’où provient la requête n’est pas l’emplacement attendu, la requête doit simplement renvoyer une erreur.

Comment protéger les sites et les réseaux contre la falsification des demandes côté serveur

Certaines mesures peuvent être prises pour protéger les sites Web de cette vulnérabilité et d’autres vulnérabilités. Bien qu’il ne soit pas toujours possible d’éviter complètement les vulnérabilités, prendre des mesures pour protéger les sites Web minimise considérablement les chances de réussite d’un compromis.

La mise à jour des plugins, des thèmes et du noyau WordPress est le meilleur moyen de protéger les sites Web WordPress contre les vulnérabilités. Étant donné que les vulnérabilités peuvent être inconnues, un pare-feu d’application Web (WAF), comme le pare-feu Wordfence, aide à bloquer les tentatives d’attaque contre les vulnérabilités non corrigées sur un site Web et vous alerte également lorsque des vulnérabilités sont présentes sur votre site.

SSRF et zéro confiance

Les vulnérabilités Server-Side Request Forgery rappellent que le cadre Zero-Trust doit être pratiqué dans les environnements modernes. Essentiellement, les vulnérabilités SSRF sont possibles car les ressources internes et externes peuvent être configurées pour supposer que les demandes envoyées à partir d’un emplacement interne sont intrinsèquement fiables. En exigeant une validation et une autorisation pour chaque action, cette confiance par défaut est supprimée et les demandes doivent être validées correctement avant d’être considérées comme fiables.

Si vous pensez que votre site a été compromis en raison de cette vulnérabilité ou de toute autre vulnérabilité, nous proposons des services de réponse aux incidents via Soins des mots. Si vous avez besoin que votre site soit nettoyé immédiatement, Réponse Wordfence offre le même service avec une disponibilité 24/7/365 et un temps de réponse d’une heure. Ces deux produits incluent une assistance pratique au cas où vous auriez besoin d’une assistance supplémentaire.


Source link