Scanner d'exposition continu pour les connexions API Azure
Audite en continu les API Connections d'Azure Logic Apps pour détecter les jetons surprivilégiés et les chemins d'attaque inter-locataires connus, avant que d'autres ne les trouvent.
Un brief prêt à coller dans Claude Code, Cursor ou tout agent de code (en anglais).
Pour
- Qui paie
- Responsables de la sécurité cloud et de l'AppSec dans les entreprises très orientées Azure (500+ salariés) utilisant Logic Apps et Power Platform ; 1 à 3 k$/mois, issus du budget de posture de sécurité cloud.
- Ce que les gens ont dit · 4
- L'article présente cinq chemins distincts de compromission inter-locataires via les API Connections, donnant accès aux Key Vaults, bases SQL, Jira et Salesforce des victimes ; l'auteur suppose que les jetons de connexion sont presque jamais limités au strict nécessaire. Tiré de l'article ↗
- Microsoft a corrigé le bug signalé de manière incorrecte, puis un correctif ultérieur a réintroduit la faille précédente, laissant le système de nouveau vulnérable. Lire le commentaire ↗
- Azure semble en tête des concurrents pour les fuites inter-locataires, pourtant les entreprises continuent de l'adopter. Lire le commentaire ↗
- Les failles sont des traversées de chemin et des IDOR élémentaires, qui existent probablement depuis le lancement de la fonctionnalité. Lire le commentaire ↗
Reformulé à partir de la discussion. Suivez les liens pour lire les commentaires d'origine.
- Concurrents et manque
Les outils CSPM signalent des erreurs de configuration génériques, mais aucun ne modélise en profondeur la surface d'attaque de Logic Apps et des API Connections : endpoints proxy de type DynamicInvoke, surcharges de host.api.RuntimeUrl, accès implicite des connexions V1 contre V2, et portée de privilèges des jetons par connecteur. Defender for Cloud est l'éditeur qui livre sans cesse des correctifs défaillants sur cette surface précise.
- Pourquoi maintenant
- Cinq exploits inter-locataires fonctionnels sur un même sous-système de connecteurs ont été publiés dans une même série, les correctifs ont régulièrement régressé, et les commentateurs anticipent que la découverte assistée par LLM va multiplier cette catégorie de failles : les défenseurs ont besoin de tests continus, pas de pentests ponctuels.
- Avantage défensif · 6/10
- Une bibliothèque de règles et de graphes d'attaque mise à jour en continu, couvrant des centaines de types de connecteurs Azure et d'endpoints non documentés, construite à partir de recherches originales ; les harnais de reproduction et la télémétrie des locataires se capitalisent et sont difficiles à répliquer rapidement pour les CSPM génériques.
Contre
- Équipe rouge
- Les CSPM ratent démontrablement cette surface d'attaque précise de Logic Apps et des API Connections, les recherches prouvent une exploitabilité réelle, et les entreprises très orientées Azure paient déjà des budgets de l'ordre de Wiz pour les outils de posture.
- Ce qui la ferait échouer
- Microsoft finit par refondre correctement les API Connections (imposant partout les identités managées et la V2), et la surface d'attaque spécifique disparaît plus vite que la base de clients ne se convertit.
Démarrer
- Les trois premières étapes
- Construire un auditeur Azure en lecture seule qui énumère les API Connections d'un locataire, signale les connexions V1, les jetons OAuth non gérés aux portées backend étendues et les endpoints dynamiques accessibles.
- Reproduire des contrôles sûrs et non destructifs pour les classes d'attaque publiées (traversée de chemin via DynamicInvoke, surcharge de RuntimeUrl) sur les propres connexions du client.
- Livrer un tableau de bord et des alertes qui relancent les contrôles à chaque changement de configuration et après chaque correctif Microsoft, avec des conseils de remédiation pour limiter la portée du jeton de chaque connecteur.
- Discussion d'origine
- Azure's Weakest Link – Five Full Cross-Tenant Compromises ↗ 329 points60 commentairesDe l'articleArticle lié
Traduit de l'anglais. Lire l'original