Cloud, mobile et IoT — Notions

Le périmètre n'est plus un bâtiment et un firewall. Les données vivent chez un fournisseur, le client tourne dans la poche de l'utilisateur, et le réseau interne accueille des caméras qui n'ont pas vu de correctif depuis 2019. Cette leçon pose les notions. Le lab Flutter de 11.2 et 11.3 applique la partie mobile. Le chapitre 11.5 traite WiFi et caméras. Ici, on apprend à prioriser avant d'ouvrir un outil.

Vous ne pentestez pas AWS

Un pentest cloud vise le compte du client : IAM, buckets, fonctions, clés. Il ne vise pas l'hyperviseur, le datacenter ni l'API du fournisseur. Le RoE le dit en une ligne. Sortir de ce cadre, c'est attaquer un tiers.

Ce que vous saurez faire

• Placer chaque finding dans le modèle de responsabilité partagée : ce que le client peut corriger, ce qu'il doit exiger du fournisseur.
• Reconnaître les trois erreurs cloud qui paient encore en 2026 : IAM trop ouvert, stockage exposé, secrets en clair.
• Nommer les surfaces mobiles (binaire, stockage local, pinning) sans confondre garde client et contrôle serveur.
• Qualifier une cible IoT avec trois questions : compte par défaut, service en clair, firmware récupérable.

1. Pourquoi ces trois surfaces ensemble

Cloud, mobile et IoT n'ont pas le même stack. Ils partagent un même déplacement : la frontière de confiance a quitté le réseau.

Surface	Ce que l'attaquant contrôle	Conséquence
Cloud	Souvent rien au départ — il cherche une clé, un rôle, un bucket	L'erreur est une politique, pas un buffer overflow
Mobile	L'appareil entier, s'il le veut (root, émulateur, proxy)	Tout secret dans le client sortira
IoT	L'objet, la radio, parfois le port série	Les fondamentaux suffisent : défauts d'usine, HTTP, firmware

Un pentest web classique suppose un serveur que vous ne possédez pas et un navigateur que vous maîtrisez à moitié. En mobile, le client est chez l'adversaire. En cloud, le « serveur » est une politique JSON. En IoT, le serveur est parfois un Linux 3.10 compilé en 2018. Les techniques changent ; la question reste : où la confiance est-elle posée, et tient-elle ?

2. Cloud — le modèle de responsabilité partagée

Le fournisseur sécurise le cloud. Le client sécurise ce qu'il met dans le cloud. La frontière bouge selon le service.

Couche	IaaS (EC2, Compute)	PaaS (RDS, App Service)	SaaS (M365, Salesforce)
Données et classification	Client	Client	Client
Identités, clés, IAM	Client	Client	Client + fournisseur
Système d'exploitation	Client	Fournisseur	Fournisseur
Patch applicatif	Client	Partagé	Fournisseur
Réseau virtuel, SG, NSG	Client	Partagé	Fournisseur
Datacenter, hardware	Fournisseur	Fournisseur	Fournisseur

Ce que ça change pour le rapport. Un bucket S3 public, une politique Action: "*" sur Resource: "*", une clé d'accès commitee dans Git : c'est 100 % client. Un 0-day dans l'hyperviseur Xen : hors périmètre. Un élève qui écrit « AWS est vulnérable » a raté le modèle. Il doit écrire « le compte prod-backup autorise s3:GetObject à Principal: "*". »

Le périmètre se négocie avant le scan : comptes et abonnements in-scope, régions, interdiction d'attaquer les endpoints du fournisseur, interdiction de DoS sur les API de facturation. Pacu, Prowler, ScoutSuite et AzureHound travaillent avec les credentials du client, pas contre amazonaws.com.

3. Cloud — les trois erreurs qui paient

Les CVE applicatives existent encore. L'écrasante majorité des incidents cloud de ces cinq années viennent d'autre chose : une identité trop large, un stockage joignable sans compte, un secret qui n'aurait jamais dû être un fichier.

3.1. IAM trop permissif

IAM est le véritable OS du cloud. Une politique qui dit « tout, partout » transforme une clé volée en administration du compte.

{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}

Cette étoile double n'est pas un raccourci de lab. On la trouve sur des rôles d'intégration, des utilisateurs « temporaire » de 2019 et des politiques inline posées un vendredi soir. Variantes qui valent le même finding :

• Action: "s3:*" sur tous les buckets, y compris ceux d'un autre projet.
• Une trust policy qui accepte sts:AssumeRole depuis un compte partenaire sans condition d'ExternalId.
• Des clés d'accès IAM humaines, âgées de deux ans, sans rotation, collées dans un Jenkins.

Ce que ça arrête, concrètement : le moindre privilège nommé (s3:GetObject sur arn:aws:s3:::factures-2026/*), des rôles assumés à durée courte, MFA sur la console, l'interdiction des clés longues au profit de rôles d'instance ou d'OIDC CI/CD.

Outils de revue, en lecture d'abord :

Outil	Cible	Usage
prowler	AWS	Contrôles CIS / finding prêt pour le rapport
scoutsuite	AWS, Azure, GCP	Cartographie multi-cloud
pacu	AWS	Modules offensifs sur le compte autorisé
azure-hound	Entra ID	Graphe des chemins vers un rôle Global Admin

On commence par Prowler ou ScoutSuite. Pacu vient ensuite, pour prouver l'impact d'un rôle déjà identifié — pas pour « voir ce qui passe ».

3.2. Stockage exposé

Un bucket S3, un conteneur Blob, un bucket GCS : trois noms, une erreur. L'objet est joignable sans authentification, ou avec une ACL AllUsers / anonymous.

aws s3 ls s3://sauvegardes-prod-acme --no-sign-request

Si cette ligne liste des préfixes, le finding est déjà Critique. Vous n'avez pas « piraté AWS ». Vous avez lu une ressource que le client a rendue publique. Les variantes :

• Listing public, lecture authentifiée : l'attaquant cartographie, puis cherche une clé ailleurs.
• URL pré-signée valable 7 jours, envoyée par mail, rejouable.
• Compte de stockage Azure avec clé dans une variable d'application, elle-même dans un dépôt.

La remédiation n'est pas « activer le chiffrement ». SSE-S3 chiffre au repos pour le fournisseur ; un objet public reste lisible. Ce qui ferme le trou : blocage des ACL publiques (Block Public Access), politiques de bucket explicites, accès via rôle, journaux d'accès activés.

3.3. Secrets en clair — et le raccourci métadonnées

Trois endroits où une clé d'accès se retrouve encore :

1. Un dépôt Git (historique compris : git rm ne l'efface pas).
2. Une variable d'environnement injectée dans un ticket Jira, un screenshot Confluence, un job CI en clair.
3. Le service de métadonnées d'instance.

Toute VM cloud expose un lien local, souvent http://169.254.169.254/. Une application qui fetch une URL fournie par l'utilisateur (import d'image, webhook, PDF) peut être poussée vers cette adresse : c'est un SSRF qui vole le rôle de la machine. En AWS, IMDSv2 (jeton obligatoire, hop limité) réduit fortement la fenêtre. IMDSv1 reste le défaut de beaucoup d'AMI anciennes.

GET http://169.254.169.254/latest/meta-data/iam/security-credentials/

Si cette URL répond depuis l'application, le finding n'est pas « SSRF théorique ». C'est prise du rôle EC2, donc souvent lecture S3, parfois assume d'un rôle plus haut. Le module 7 a classé ça en A10. Ici, vous le rattachez au cloud : le secret n'était pas dans le code, il était attaché à l'instance.

4. Mobile — le client n'est pas une frontière

Différence essentielle avec le web : le binaire tourne sur un appareil que l'attaquant peut posséder. Root, émulateur, proxy TLS, dump mémoire. Concevoir la sécurité comme « personne ne décompilera l'APK » est une hypothèse fausse.

La garde client sert au design

Un écran qui cache un bouton admin n'est pas un contrôle d'accès. L'API doit refuser. La leçon 11.2 le montre sur une app Flutter : le dashboard s'affiche, le serveur rend 401. Ne confondez pas les deux.

Trois surfaces reviennent dans presque chaque mission mobile.

4.1. Le binaire — APK, IPA, bundle

Un APK est un zip. apktool le démonte, jadx le décompile vers du Java lisible. Les constantes (URL d'API, clé « premium », feature flag, endpoint de debug) survivent à la compilation.

apktool d application.apk -o apk-out
jadx -d jadx-out application.apk
strings application.apk | grep -iE 'api_key|secret|password|http'

Sur Flutter, le code Dart vit dans libapp.so (ou dans main.dart.js pour le build web). Le réflexe est le même : chercher des chaînes, pas « casser » le framework. La démonstration 11.2 part de ce grep. Ici, retenez la règle : si le back a besoin d'un secret, ce secret n'a rien à faire dans le client. Une clé API dans l'APK n'est plus une clé.

Côté iOS, l'IPA se dézippe ; les Info.plist et binaires Swift/Obj-C livrent les mêmes URL. Le jailbreak n'est pas obligatoire pour la revue statique.

4.2. Le stockage local

L'app écrit sur le disque. Un attaquant qui a l'appareil (ou une sauvegarde non chiffrée) lit :

Plateforme	Emplacement typique	Piège fréquent
Android	SharedPreferences XML, bases SQLite	Jeton de session en clair, mot de passe « pour le confort »
iOS	UserDefaults, fichiers plist, Keychain mal utilisé	Secret dans UserDefaults au lieu du Keychain
Flutter	shared_preferences, fichiers d'app	Même erreur, API cross-platform

Le Keychain / Keystore peut tenir un secret. Encore faut-il l'utiliser, avec un niveau de protection qui exige le déverrouillage du téléphone. Une préférence XML n'offre aucune de ces garanties.

4.3. Certificate pinning — ce qu'il fait, ce qu'il ne fait pas

Sans pinning, un proxy (Burp, mitmproxy) intercepte le TLS dès que l'utilisateur accepte une CA d'entreprise — ou dès que l'attaquant contrôle l'appareil. Le pinning ajoute une vérification : le certificat (ou la clé publique) doit matcher celui que l'app a embarqué.

Trois lectures utiles :

• Pinning absent : l'interception TLS est triviale sur un appareil que vous contrôlez. C'est le cas par défaut.
• Pinning présent : ça ralentit l'analyse dynamique. Ça ne rend pas l'API sûre. Frida et Objection accrochent encore TrustManager / boringssl sur la majorité des apps. Le pinning est une friction, pas une frontière.
• Pinning + secrets dans l'APK : vous avez juste rendu le grep un peu plus long.

Outils de la revue mobile, dans cet ordre : statique (apktool, jadx, strings) puis dynamique (frida, objection) sur le lab ou l'app du client. L'atelier 11.3 propose un bonus APK hors Docker pour ceux qui veulent le même reflexe sur un binaire natif.

5. IoT — les fondamentaux suffisent

Un pentest IoT déçoit ceux qui attendent un 0-day radio. Il rassure ceux qui ont déjà fait du durcissement Windows : on retombe sur des comptes d'usine, du HTTP, un firmware téléchargeable.

Trois questions, dans cet ordre.

5.1. Compte par défaut

admin:admin, root:vizxv, admin:12345. Les collections publiques (RouterSploit, listes de CVE constructeur) couvrent une décennie de modèles. Si le mot n'est pas unique par appareil à la sortie d'usine, le finding est le même que Mirai en 2016. La remédiation est organisationnelle : inventaire, changement forcé à la première connexion, retrait du matériel dont le fabricant ne livre plus de correctif.

5.2. Service non chiffré

Telnet, HTTP d'administration, MQTT sans TLS, flux vidéo sans authentification. Un attaquant sur le même LAN (ou sur le WAN si UPnP a ouvert un port) lit la session. Le chiffrement ne remplace pas l'authentification : un RTSP en TLS avec admin:admin tombe quand même.

5.3. Firmware récupérable

Beaucoup de constructeurs publient le .bin sur leur site, ou l'interface le sert à /upgrade. binwalk extrait le système de fichiers. strings sort des clés privées, des mots de passe hardcodés, des URL de mise à jour non signées.

binwalk -e firmware.bin
strings firmware.bin | grep -iE 'admin|password|private|BEGIN RSA'

Un secret dans le firmware est un secret pour toute la flotte du même modèle. C'est l'équivalent IoT de la clé dans l'APK.

WiFi et caméras : un chapitre à part

La radio, WPA2-PSK, PMKID, le deauth et la chaîne type sur une caméra IP sont traités dans la leçon 11.5. Cette page ne les répète pas. Retenez seulement le lien : si le WiFi tombe, l'objet tombe dans la minute. La défense qui tient commence par la segmentation (VLAN / SSID IoT) et l'inventaire, pas par un antivirus sur la caméra.

6. Comment on priorise en mission

Une semaine de pentest ne couvre pas « le cloud, le mobile et l'IoT ». On choisit selon le RoE et la valeur.

Contexte client	Priorité haute	Ce qu'on ne fait pas d'abord
SaaS hébergé AWS	IAM, buckets, métadonnées, clés Git	Kernel de l'AMI
App mobile + API	Bundle, stockage local, contrôles API	0-day du store
Flotte de capteurs	Défauts d'usine, HTTP, segmentation	Protocoles radio exotiques
PME avec caméras	Voir 11.5 : WiFi, RTSP, mots d'usine	Exploit constructeur non public

Le rapport IoT insiste plus que les autres sur les remédiations organisationnelles : inventaire, VLAN, cycle de mise à jour, interdiction d'UPnP. Un correctif firmware que le fabricant ne publiera jamais n'est pas une reco actionnable.

7. Les confusions qui coûtent du temps

• « Le cloud est sécurisé, donc mon S3 l'est. » Le fournisseur sécurise le socle. L'ACL, c'est vous.
• « On a ofusqué l'APK. » L'obfuscation retarde un humain. Elle ne retire pas une clé de l'apk. strings suffit souvent.
• « Le pinning remplace l'auth serveur. » Non. Il gêne le proxy. L'IDOR reste un IDOR.
• « IoT = attaque radio avancée. » En 2026, la majorité des missions IoT se closent sur un mot d'usine et un port 80.
• « Pacu contre AWS. » Pacu contre le compte du client, avec une clé que le client vous a donnée, dans le périmètre écrit.

Ce qu'il faut retenir

Cloud, mobile et IoT se lisent avec la même grille : qui porte la responsabilité, où le secret habite, et ce qu'un attaquant contrôle déjà. En cloud, la réponse est presque toujours une politique (IAM, bucket, clé, métadonnées). En mobile, tout ce qui vit dans le client finira dehors ; le contrôle réel est l'API. En IoT, les fondamentaux — défauts d'usine, HTTP, firmware — ferment plus d'incidents qu'un exploit de protocole.

Prochaine leçon : on applique la grille mobile sur une app Flutter volontairement faible, du grep du bundle jusqu'au flag admin.