Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
AWS WAF est un pare-feu d'application web conçu pour protéger les applications web ou les API contre diverses exploitations web qui peuvent affecter leur disponibilité, sécurité ou consommation de ressources. Il permet aux utilisateurs de contrôler le trafic entrant en configurant des règles de sécurité qui atténuent les vecteurs d'attaque typiques tels que l'injection SQL ou le scripting intersite, et en définissant également des règles de filtrage personnalisées.
Une Web ACL est un ensemble de règles que vous pouvez appliquer à vos applications web ou API. Lorsque vous associez une Web ACL à une ressource, AWS WAF inspecte les requêtes entrantes en fonction des règles définies dans la Web ACL et prend les actions spécifiées.
Un Groupe de Règles est une collection réutilisable de règles que vous pouvez appliquer à plusieurs Web ACL. Les groupes de règles aident à gérer et à maintenir des ensembles de règles cohérents à travers différentes applications web ou API.
Chaque groupe de règles a sa capacité associée, qui aide à calculer et à contrôler les ressources opérationnelles utilisées pour exécuter vos règles, groupes de règles et Web ACL. Une fois sa valeur définie lors de la création, il n'est pas possible de la modifier.
Une règle définit un ensemble de conditions que AWS WAF utilise pour inspecter les requêtes web entrantes. Il existe deux types principaux de règles :
Règle Régulière : Ce type de règle utilise des conditions spécifiées pour déterminer s'il faut autoriser, bloquer ou compter les requêtes web.
Règle Basée sur le Taux : Compte les requêtes d'une adresse IP spécifique sur une période de cinq minutes. Ici, les utilisateurs définissent un seuil, et si le nombre de requêtes d'une IP dépasse cette limite dans les cinq minutes, les requêtes suivantes de cette IP sont bloquées jusqu'à ce que le taux de requêtes tombe en dessous du seuil. Le seuil minimum pour les règles basées sur le taux est de 2000 requêtes.
AWS WAF propose des ensembles de règles gérés préconfigurés qui sont maintenus par AWS et les vendeurs du marché AWS. Ces ensembles de règles offrent une protection contre les menaces courantes et sont régulièrement mis à jour pour traiter de nouvelles vulnérabilités.
Un Ensemble d'IP est une liste d'adresses IP ou de plages d'adresses IP que vous souhaitez autoriser ou bloquer. Les ensembles d'IP simplifient le processus de gestion des règles basées sur les IP.
Un Ensemble de Modèles Regex contient une ou plusieurs expressions régulières (regex) qui définissent des motifs à rechercher dans les requêtes web. Cela est utile pour des scénarios de correspondance plus complexes, tels que le filtrage de séquences spécifiques de caractères.
Un Jeton de Verrouillage est utilisé pour le contrôle de la concurrence lors de la mise à jour des ressources WAF. Il garantit que les modifications ne sont pas accidentellement écrasées par plusieurs utilisateurs ou processus tentant de mettre à jour la même ressource simultanément.
Les Clés API dans AWS WAF sont utilisées pour authentifier les requêtes à certaines opérations API. Ces clés sont cryptées et gérées de manière sécurisée pour contrôler l'accès et garantir que seuls les utilisateurs autorisés peuvent apporter des modifications aux configurations WAF.
Exemple : Intégration de l'API CAPTCHA.
Une Politique de Permission est une politique IAM qui spécifie qui peut effectuer des actions sur les ressources AWS WAF. En définissant des permissions, vous pouvez contrôler l'accès aux ressources WAF et garantir que seuls les utilisateurs autorisés peuvent créer, mettre à jour ou supprimer des configurations.
Le paramètre de portée dans AWS WAF spécifie si les règles et configurations WAF s'appliquent à une application régionale ou à une distribution Amazon CloudFront.
RÉGIONAL : S'applique aux services régionaux tels que les équilibreurs de charge d'application (ALB), l'API REST d'Amazon API Gateway, l'API GraphQL AWS AppSync, le pool d'utilisateurs Amazon Cognito, le service AWS App Runner et l'instance AWS Verified Access. Vous spécifiez la région AWS où ces ressources sont situées.
CLOUDFRONT : S'applique aux distributions Amazon CloudFront, qui sont globales. Les configurations WAF pour CloudFront sont gérées via la région us-east-1 indépendamment de l'endroit où le contenu est servi.
Conditions spécifient les éléments des requêtes HTTP/HTTPS entrantes que AWS WAF surveille, qui incluent XSS, localisation géographique (GEO), adresses IP, contraintes de taille, injection SQL et motifs (correspondance de chaînes et regex). Il est important de noter que les requêtes restreintes au niveau de CloudFront en fonction du pays n'atteindront pas WAF.
Chaque compte AWS peut configurer :
100 conditions pour chaque type (sauf pour Regex, où seules 10 conditions sont autorisées, mais cette limite peut être augmentée).
100 règles et 50 Web ACLs.
Un maximum de 5 règles basées sur le taux.
Un débit de 10 000 requêtes par seconde lorsque WAF est mis en œuvre avec un équilibreur de charge d'application.
Des actions sont assignées à chaque règle, avec les options suivantes :
Autoriser : La requête est transmise à la distribution CloudFront ou à l'équilibreur de charge d'application approprié.
Bloquer : La requête est immédiatement terminée.
Compter : Compte les requêtes répondant aux conditions de la règle. Cela est utile pour tester la règle, confirmant l'exactitude de la règle avant de la définir sur Autoriser ou Bloquer.
CAPTCHA et Défi : Il est vérifié que la requête ne provient pas d'un bot à l'aide de puzzles CAPTCHA et de défis silencieux.
Si une requête ne correspond à aucune règle dans la Web ACL, elle subit l'action par défaut (Autoriser ou Bloquer). L'ordre d'exécution des règles, défini dans une Web ACL, est crucial et suit généralement cette séquence :
Autoriser les IPs sur liste blanche.
Bloquer les IPs sur liste noire.
Bloquer les requêtes correspondant à des signatures nuisibles.
AWS WAF s'intègre à CloudWatch pour la surveillance, offrant des métriques telles que AllowedRequests, BlockedRequests, CountedRequests et PassedRequests. Ces métriques sont rapportées chaque minute par défaut et conservées pendant une période de deux semaines.
Pour interagir avec les distributions CloudFront, vous devez spécifier la région US East (N. Virginia) :
CLI - Spécifiez la région US East lorsque vous utilisez la portée CloudFront : --scope CLOUDFRONT --region=us-east-1.
API et SDKs - Pour tous les appels, utilisez le point de terminaison de la région us-east-1.
Pour interagir avec les services régionaux, vous devez spécifier la région :
Exemple avec la région Europe (Espagne) : --scope REGIONAL --region=eu-south-2
Du point de vue d'un attaquant, ce service peut aider l'attaquant à identifier les protections WAF et les expositions réseau qui pourraient l'aider à compromettre d'autres sites web.
Cependant, un attaquant pourrait également être intéressé à perturber ce service afin que les sites ne soient pas protégés par le WAF.
Dans de nombreuses opérations de suppression et de mise à jour, il serait nécessaire de fournir le token de verrouillage. Ce token est utilisé pour le contrôle de la concurrence sur les ressources, garantissant que les modifications ne sont pas accidentellement écrasées par plusieurs utilisateurs ou processus tentant de mettre à jour la même ressource simultanément. Afin d'obtenir ce token, vous pourriez effectuer les opérations list ou get correspondantes sur la ressource spécifique.
wafv2:CreateRuleGroup, wafv2:UpdateRuleGroup, wafv2:DeleteRuleGroupUn attaquant serait en mesure de compromettre la sécurité de la ressource affectée en :
Créant des groupes de règles qui pourraient, par exemple, bloquer le trafic légitime provenant d'adresses IP légitimes, provoquant une déni de service.
Mettant à jour des groupes de règles, pouvant modifier ses actions par exemple de Block à Allow.
Supprimant des groupes de règles qui fournissent des mesures de sécurité critiques.
Les exemples suivants montrent un groupe de règles qui bloquerait le trafic légitime provenant d'adresses IP spécifiques :
Le fichier rule.json ressemblerait à :
Impact potentiel : Accès non autorisé, violations de données et attaques potentielles par déni de service.
wafv2:CreateWebACL, wafv2:UpdateWebACL, wafv2:DeleteWebACLAvec ces autorisations, un attaquant pourrait :
Créer un nouveau Web ACL, introduisant des règles qui permettent soit le passage de trafic malveillant, soit le blocage de trafic légitime, rendant ainsi le WAF inutile ou provoquant un déni de service.
Mettre à jour des Web ACL existants, pouvant modifier des règles pour permettre des attaques telles que l'injection SQL ou le scripting intersite, qui étaient auparavant bloquées, ou perturber le flux de trafic normal en bloquant des requêtes valides.
Supprimer un Web ACL, laissant les ressources affectées entièrement non protégées, les exposant à un large éventail d'attaques web.
Vous ne pouvez supprimer le WebACL spécifié que si ManagedByFirewallManager est faux.
Les exemples suivants montrent comment mettre à jour un Web ACL pour bloquer le trafic légitime d'un ensemble d'IP spécifique. Si l'IP d'origine ne correspond à aucune de ces IP, l'action par défaut serait également de le bloquer, provoquant un DoS.
Web ACL d'origine:
Commande pour mettre à jour le Web ACL :
Le fichier rule.json ressemblerait à :
Impact potentiel : Accès non autorisé, violations de données et attaques potentielles par déni de service (DoS).
wafv2:AssociateWebACL, wafv2:DisassociateWebACLLa permission wafv2:AssociateWebACL permettrait à un attaquant d'associer des ACL web (Listes de Contrôle d'Accès) avec des ressources, pouvant contourner les contrôles de sécurité, permettant à un trafic non autorisé d'atteindre l'application, ce qui pourrait conduire à des exploits comme l'injection SQL ou le cross-site scripting (XSS). Inversement, avec la permission wafv2:DisassociateWebACL, l'attaquant pourrait désactiver temporairement les protections de sécurité, exposant les ressources à des vulnérabilités sans détection.
Des permissions supplémentaires seraient nécessaires en fonction du type de ressource protégée :
Associer
apigateway:SetWebACL
apprunner:AssociateWebAcl
appsync:SetWebACL
cognito-idp:AssociateWebACL
ec2:AssociateVerifiedAccessInstanceWebAcl
elasticloadbalancing:SetWebAcl
Dissocier
apigateway:SetWebACL
apprunner:DisassociateWebAcl
appsync:SetWebACL
cognito-idp:DisassociateWebACL
ec2:DisassociateVerifiedAccessInstanceWebAcl
elasticloadbalancing:SetWebAcl
Impact potentiel : Sécurité des ressources compromises, risque accru d'exploitation et interruptions potentielles de service au sein des environnements AWS protégés par AWS WAF.
wafv2:CreateIPSet , wafv2:UpdateIPSet, wafv2:DeleteIPSetUn attaquant pourrait créer, mettre à jour et supprimer les ensembles d'IP gérés par AWS WAF. Cela pourrait être dangereux car il pourrait créer de nouveaux ensembles d'IP pour autoriser le trafic malveillant, modifier des ensembles d'IP afin de bloquer le trafic légitime, mettre à jour des ensembles d'IP existants pour inclure des adresses IP malveillantes, supprimer des adresses IP de confiance ou supprimer des ensembles d'IP critiques destinés à protéger des ressources critiques.
L'exemple suivant montre comment écraser l'ensemble d'IP existant par l'ensemble d'IP souhaité :
Impact potentiel : Accès non autorisé et blocage du trafic légitime.
wafv2:CreateRegexPatternSet , wafv2:UpdateRegexPatternSet, wafv2:DeleteRegexPatternSetUn attaquant disposant de ces autorisations pourrait manipuler les ensembles de motifs d'expressions régulières utilisés par AWS WAF pour contrôler et filtrer le trafic entrant en fonction de motifs spécifiques.
La création de nouveaux motifs regex aiderait un attaquant à autoriser du contenu nuisible
En mettant à jour les motifs existants, un attaquant pourrait contourner les règles de sécurité
La suppression de motifs conçus pour bloquer les activités malveillantes pourrait permettre à un attaquant d'envoyer des charges utiles malveillantes et de contourner les mesures de sécurité.
Impact potentiel : Contourner les contrôles de sécurité, permettant à un contenu malveillant de passer et exposant potentiellement des données sensibles ou perturbant des services et des ressources protégés par AWS WAF.
wavf2:PutLoggingConfiguration & iam:CreateServiceLinkedRole), wafv2:DeleteLoggingConfigurationUn attaquant avec le wafv2:DeleteLoggingConfiguration serait capable de supprimer la configuration de journalisation de l'ACL Web spécifié. Par la suite, avec les permissions wavf2:PutLoggingConfiguration et iam:CreateServiceLinkedRole, un attaquant pourrait créer ou remplacer des configurations de journalisation (après l'avoir supprimée) pour soit empêcher complètement la journalisation, soit rediriger les journaux vers des destinations non autorisées, telles que des buckets Amazon S3, un groupe de journaux Amazon CloudWatch Logs ou un Amazon Kinesis Data Firehose sous contrôle.
Lors du processus de création, le service configure automatiquement les permissions nécessaires pour permettre l'écriture des journaux à la destination de journalisation spécifiée :
Amazon CloudWatch Logs : AWS WAF crée une politique de ressource sur le groupe de journaux CloudWatch Logs désigné. Cette politique garantit qu'AWS WAF dispose des permissions requises pour écrire des journaux dans le groupe de journaux.
Bucket Amazon S3 : AWS WAF crée une politique de bucket sur le bucket S3 désigné. Cette politique accorde à AWS WAF les permissions nécessaires pour télécharger des journaux dans le bucket spécifié.
Amazon Kinesis Data Firehose : AWS WAF crée un rôle lié au service spécifiquement pour interagir avec Kinesis Data Firehose. Ce rôle permet à AWS WAF de livrer des journaux au flux Firehose configuré.
Il est possible de définir une seule destination de journalisation par ACL Web.
Impact potentiel : Obscurcir la visibilité sur les événements de sécurité, rendre le processus de réponse aux incidents difficile et faciliter des activités malveillantes discrètes au sein des environnements protégés par AWS WAF.
wafv2:DeleteAPIKeyUn attaquant avec ces permissions serait capable de supprimer des clés API existantes, rendant le CAPTCHA inefficace et perturbant la fonctionnalité qui en dépend, comme les soumissions de formulaires et les contrôles d'accès. Selon l'implémentation de ce CAPTCHA, cela pourrait conduire soit à un contournement du CAPTCHA, soit à un DoS si la gestion des erreurs n'est pas correctement configurée dans la ressource.
Impact potentiel : Désactiver les protections CAPTCHA ou perturber la fonctionnalité de l'application, entraînant des violations de sécurité et un vol potentiel de données.
wafv2:TagResource, wafv2:UntagResourceUn attaquant pourrait ajouter, modifier ou supprimer des balises des ressources AWS WAFv2, telles que les ACL Web, les groupes de règles, les ensembles d'IP, les ensembles de motifs regex et les configurations de journalisation.
Impact potentiel : Manipulation des ressources, fuite d'informations, manipulation des coûts et perturbation opérationnelle.
Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE) Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE)
