ThreatsDay Bulletin: Pre-Auth Chains et Rootkits Android
Origines et historique
Les attaques en chaîne ont quitté le terrain du cas d'école pour devenir une menace opérationnelle régulière. Depuis 2022, la fréquence et la complexité des compromissions ont augmenté, portées par trois dynamiques convergentes.
- Explosion de la surface d'attaque: la montée en puissance des architectures à microservices, des API publiques et des environnements cloud hétérogènes multiplie les interfaces exposées. Chaque interaction entre composants est une opportunité pour un acteur malveillant de pivoter.
- Automation des exploit-kits: les frameworks d'exploitation et les fuzzers modernes permettent d'automatiser l'identification et l'enchaînement de failles. Des scénarios qui exigeaient des semaines de travail manuel peuvent être réalisés en quelques heures.
- Évolution des modèles d'authentification: tokens JWT, flux OIDC, clefs API et sessions longues créent de nouveaux points d'entrée. Une contournement discret des contrôles d'authentification peut conduire rapidement à une élévation de privilèges.
Le bulletin ThreatsDay documente plusieurs campagnes où des acteurs ont combiné défaut de validation d'URL, erreurs de logique d'autorisation et mauvaises configurations S3 pour compromettre des infrastructures cloud¹. L'ANSSI publie, de son côté, des recommandations pratiques pour durcir les terminaux mobiles et améliorer la gestion des logs². Ces rapports montrent que la menace n'est pas théorique: elle repose sur des enchaînements simples mais efficaces.
Fonctionnement technique
Mécanique générale des pre-auth chains
Une "pre-auth chain" est une suite d'exploits qui commence depuis un état non authentifié et qui mène, étape par étape, à un accès authentifié, à une élévation ou à une persistance. L'intérêt pour un attaquant est clair: éviter les barrières classiques en combinant des failles de faible à moyenne gravité.
- Point d'entrée faible - un endpoint public mal filtré (par exemple une API REST) sert d'amorce.
- Contournement de contrôles - en forçant des paramètres JSON ou des headers, on déclenche des branches de code qui divulguent des secrets ou des tokens.
- Escalade/pivot - le token obtenu permet d'appeler des endpoints internes ou d'accéder à des métadonnées d'instance.
- Persistance - création de clés IAM, manipulation des pipelines CI/CD, implantation de backdoors.
Parmi les combinaisons observées: désérialisation vulnérable + SSRF, log forging qui corrompt le parsing des identifiants, ou encore parameter pollution qui neutralise des ACLs. Pour visualiser: non authentifié -> SSRF sur endpoint public -> accès à metadata d'instance -> token temporaire -> création de rôle/service account -> backdoor.
Défense opérationnelle: détecter et corréler les événements sur plusieurs plans (web, API, metadata) et limiter les chances d'aboutissement d'une chaîne en appliquant le principe du moindre privilège partout.
Rootkits Android: techniques et subtilités
Les rootkits Android modernes sont conçus pour survivre aux protections actuelles: partitions signées, SELinux en enforcing et mises à jour OTA. Ils combinent plusieurs approches pour obtenir et maintenir des privilèges élevés.
- Modifications 'systemless' du ramdisk: injection au démarrage pour éviter d'écrire sur la partition system et passer sous le radar des vérifications de signature.
- Modules noyau malveillants: un exploit kernel place un module qui altère la surface d'observation du système, masque processus et trafic, et ignore certaines politiques SELinux.
- Hooking de processus et ptrace: intercepter des appels sensibles pour masquer activités ou manipuler API de logging.
- Persistance multivectorielle: modification de scripts d'init, création de services masqués, altération d'OTA ou de gestionnaire de mise à jour.
La détection nécessite une combinaison d'approches: vérification de l'intégrité des images de boot et du ramdisk, surveillance des hooks du Binder et des modifications de policies SELinux, et analyses forensiques à froid sur l'image NAND. Les indicateurs comportementaux (trafic réseau anormal, accès répétés à interfaces bas niveau) restent essentiels².
Évasion de CloudTrail et altération de télémétrie
CloudTrail fournit une piste d'audit centrale, mais elle peut être ciblée par un acteur ayant obtenu des droits IAM suffisants. Tactiques observées:
- Désactivation ou modification du trail via CreateTrail/UpdateTrail/DeleteTrail une fois des credentials compromis.
- Suppression ou écrasement des logs dans S3, ou mise en place de lifecycle policies pour purger rapidement les objets. Sans Object Lock ou MFA Delete, la conservation n'est pas garantie.
- Utilisation de credentials temporaires pour appeler des API qui restreignent la collecte d'événements (PutEventSelectors) et limiter ainsi la visibilité.
- Redirection des flux CloudWatch Logs vers des destinations contrôlées pour masquer les événements en temps réel.
Les bonnes pratiques pour limiter ces risques incluent la séparation des comptes pour la journalisation, l'immutabilité des buckets de logs et l'alerte sur les appels de gestion de trail. Les recommandations AWS listent des mesures concrètes pour préserver l'intégrité des logs et détecter les tentatives d'altération³.
Études de cas
Cas 1 - Chaîne API publique -> metadata -> backdoor
Une plateforme SaaS exposait un endpoint d'upload. L'attaque a combiné une SSRF et une restriction d'origin mal configurée pour atteindre les métadonnées d'instance EC2. Le token temporaire obtenu a servi à créer une clé IAM et déployer une porte dérobée, permettant un accès persistant pendant plusieurs semaines.
Cas 2 - Rootkit Android dans un écosystème IoT
Des périphériques Android intégrés à des routeurs ont conservé des images OTA signées. Un exploit kernel a été utilisé pour obtenir des privilèges et injecter un module noyau masquant processus et logs. La persistance est restée indétectable après des réinstallations classiques, obligeant une analyse matérielle approfondie pour confirmer la compromission.
Cas 3 - Évasion CloudTrail via policies S3 et rôles compromis
Un attaquant a compromis des credentials de développeur, créé une policy S3 permettant d'archiver puis purger les logs CloudTrail, désactivé le trail principal et mis en place un trail alternatif censurant certains événements. CloudWatch Events n'étant pas configuré pour surveiller les changements de trail, l'exfiltration a duré 48 heures sans alerte.
Perspectives et recommandations
La normalisation des attaques en chaîne impose de penser la sécurité comme un système distribué plutôt que comme une addition de contrôles isolés. Voici des mesures prioritaires à mettre en oeuvre:
- Conception 'assume breach' - segmenter les comptes et appliquer le principe du moindre privilège. Isoler les pipelines CI/CD et utiliser des comptes dédiés pour la télémétrie.
- Immutabilité des logs - activer S3 Object Lock (modes Governance/Compliance), MFA Delete et transférer les logs vers un compte central dédié à la journalisation.
- Hardening mobile et OTA - vérifier l'intégrité du ramdisk et des images de boot, intégrer des scans natifs dans la chaîne de build et auditer régulièrement le code natif.
- Threat hunting axé sur chaînes - construire des corrélations entre SSRF, accès metadata et modification des trails; créer des règles détectant la séquence d'événements plutôt que des anomalies isolées.
- Automatisation de la remédiation - réduire le temps de réaction en automatisant la rotation de clés compromises, l'isolement de comptes affectés et la restauration des configurations critiques.
Ces actions requièrent coordination entre équipes de développement, cloud et sécurité. Investir dans la visibilité inter-systèmes et dans des exercices red team focalisés sur l'enchaînement de vulnérabilités permet de transformer des failles isolées en risques maîtrisés.
