Cloud, Mobile und IoT — Grundlagen

Der Perimeter ist kein Gebäude und keine Firewall mehr. Die Daten liegen bei einem Anbieter, der Client läuft in der Tasche des Nutzers, und das interne Netzwerk beherbergt Kameras, die seit 2019 kein Update mehr gesehen haben. Diese Lektion legt die Grundlagen. Das Flutter-Lab von 11.2 und 11.3 wendet den mobilen Teil an. Kapitel 11.5 behandelt WiFi und Kameras. Hier lernen Sie, zu priorisieren, bevor Sie ein Werkzeug öffnen.

Sie pentesten nicht AWS

Ein Cloud-Pentest zielt auf das Konto des Kunden: IAM, Buckets, Funktionen, Schlüssel. Er zielt nicht auf den Hypervisor, das Rechenzentrum oder die API des Anbieters. Die Regeln des Einsatzes (RoE) sagen das in einer Zeile. Diesen Rahmen zu verlassen bedeutet, einen Dritten anzugreifen.

Was Sie können werden

• Jeden Befund im Modell der geteilten Verantwortung einordnen: was der Kunde selbst beheben kann, was er vom Anbieter verlangen muss.
• Die drei Cloud-Fehler erkennen, die sich 2026 immer noch auszahlen: zu offenes IAM, exponierter Speicher, Klartext-Secrets.
• Die mobilen Angriffsflächen benennen (Binary, lokaler Speicher, Pinning), ohne clientseitige Schutzmaßnahme und serverseitige Kontrolle zu verwechseln.
• Ein IoT-Ziel mit drei Fragen einschätzen: Standardkonto, unverschlüsselter Dienst, abrufbare Firmware.

1. Warum diese drei Angriffsflächen zusammen

Cloud, Mobile und IoT haben nicht denselben Stack. Sie teilen eine gemeinsame Verschiebung: die Vertrauensgrenze hat das Netzwerk verlassen.

Angriffsfläche	Was der Angreifer kontrolliert	Konsequenz
Cloud	Anfangs oft nichts — er sucht einen Schlüssel, eine Rolle, einen Bucket	Der Fehler ist eine Richtlinie, kein Pufferüberlauf
Mobile	Das ganze Gerät, wenn er will (Root, Emulator, Proxy)	Jedes Secret im Client wird herauskommen
IoT	Das Gerät, die Funkstrecke, manchmal die serielle Schnittstelle	Die Grundlagen reichen: Werkseinstellungen, HTTP, Firmware

Ein klassischer Web-Pentest setzt einen Server voraus, den Sie nicht besitzen, und einen Browser, den Sie nur halb kontrollieren. Bei Mobile befindet sich der Client beim Gegner. In der Cloud ist der „Server" eine JSON-Richtlinie. Bei IoT ist der Server manchmal ein 2018 kompiliertes Linux 3.10. Die Techniken ändern sich; die Frage bleibt: Wo liegt das Vertrauen, und hält es stand?

2. Cloud — das Modell der geteilten Verantwortung

Der Anbieter sichert die Cloud. Der Kunde sichert das, was er in die Cloud legt. Die Grenze verschiebt sich je nach Dienst.

Schicht	IaaS (EC2, Compute)	PaaS (RDS, App Service)	SaaS (M365, Salesforce)
Daten und Klassifizierung	Kunde	Kunde	Kunde
Identitäten, Schlüssel, IAM	Kunde	Kunde	Kunde + Anbieter
Betriebssystem	Kunde	Anbieter	Anbieter
Anwendungs-Patches	Kunde	Geteilt	Anbieter
Virtuelles Netzwerk, SG, NSG	Kunde	Geteilt	Anbieter
Rechenzentrum, Hardware	Anbieter	Anbieter	Anbieter

Was das für den Bericht bedeutet. Ein öffentlicher S3-Bucket, eine Richtlinie Action: "*" auf Resource: "*", ein in Git committeter Zugriffsschlüssel: das ist 100 % Kunde. Ein 0-Day im Xen-Hypervisor: außerhalb des Scopes. Ein Teilnehmer, der schreibt „AWS ist verwundbar", hat das Modell verfehlt. Er muss schreiben: „Das Konto prod-backup erlaubt s3:GetObject für Principal: "*"."

Der Scope wird vor dem Scan verhandelt: Konten und Abonnements im Geltungsbereich, Regionen, Verbot, die Endpunkte des Anbieters anzugreifen, Verbot von DoS gegen die Abrechnungs-APIs. Pacu, Prowler, ScoutSuite und AzureHound arbeiten mit den Anmeldedaten des Kunden, nicht gegen amazonaws.com.

3. Cloud — die drei Fehler, die sich auszahlen

Anwendungs-CVEs gibt es noch. Die überwältigende Mehrheit der Cloud-Vorfälle der letzten fünf Jahre stammt aus etwas anderem: einer zu weit gefassten Identität, einem ohne Konto erreichbaren Speicher, einem Secret, das nie eine Datei hätte sein dürfen.

3.1. Zu freizügiges IAM

IAM ist das eigentliche Betriebssystem der Cloud. Eine Richtlinie, die „alles, überall" sagt, verwandelt einen gestohlenen Schlüssel in die Administration des gesamten Kontos.

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

Dieser doppelte Stern ist keine Abkürzung aus dem Lab. Man findet ihn bei Integrationsrollen, „temporären" Benutzern von 2019 und Inline-Richtlinien, die an einem Freitagabend hingelegt wurden. Varianten, die denselben Befund wert sind:

• Action: "s3:*" auf alle Buckets, einschließlich der eines anderen Projekts.
• Eine Trust Policy, die sts:AssumeRole von einem Partnerkonto ohne ExternalId-Bedingung akzeptiert.
• Menschliche IAM-Zugriffsschlüssel, zwei Jahre alt, ohne Rotation, in einem Jenkins abgelegt.

Was das konkret verhindert: benanntes Least Privilege (s3:GetObject auf arn:aws:s3:::factures-2026/*), kurzlebig angenommene Rollen, MFA in der Konsole, das Verbot langlebiger Schlüssel zugunsten von Instanzrollen oder OIDC-CI/CD.

Prüfwerkzeuge, zunächst lesend eingesetzt:

Werkzeug	Ziel	Verwendung
prowler	AWS	CIS-Kontrollen / berichtsfertiger Befund
scoutsuite	AWS, Azure, GCP	Multi-Cloud-Kartierung
pacu	AWS	Offensive Module auf dem autorisierten Konto
azure-hound	Entra ID	Graph der Pfade zu einer Global-Admin-Rolle

Man beginnt mit Prowler oder ScoutSuite. Pacu kommt danach, um die Auswirkung einer bereits identifizierten Rolle zu belegen — nicht, um „zu sehen, was durchgeht".

3.2. Exponierter Speicher

Ein S3-Bucket, ein Blob-Container, ein GCS-Bucket: drei Namen, ein Fehler. Das Objekt ist ohne Authentifizierung erreichbar, oder mit einer ACL AllUsers / anonymous.

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

Wenn diese Zeile Präfixe auflistet, ist der Befund bereits Kritisch. Sie haben nicht „AWS gehackt". Sie haben eine Ressource gelesen, die der Kunde öffentlich gemacht hat. Die Varianten:

• Öffentliches Listing, authentifiziertes Lesen: Der Angreifer kartiert und sucht dann anderswo nach einem Schlüssel.
• Vorsignierte URL, 7 Tage gültig, per E-Mail verschickt, wiederverwendbar.
• Azure-Speicherkonto mit Schlüssel in einer Anwendungsvariable, die selbst in einem Repository liegt.

Die Abhilfe ist nicht „Verschlüsselung aktivieren". SSE-S3 verschlüsselt ruhende Daten für den Anbieter; ein öffentliches Objekt bleibt lesbar. Was das Loch wirklich schließt: Blockieren öffentlicher ACLs (Block Public Access), explizite Bucket-Richtlinien, Zugriff über eine Rolle, aktivierte Zugriffsprotokolle.

3.3. Klartext-Secrets — und die Metadaten-Abkürzung

Drei Orte, an denen ein Zugriffsschlüssel immer noch landet:

1. Ein Git-Repository (Verlauf eingeschlossen: git rm löscht ihn nicht).
2. Eine Umgebungsvariable, eingefügt in ein Jira-Ticket, einen Confluence-Screenshot, einen CI-Job im Klartext.
3. Der Instanzmetadatendienst.

Jede Cloud-VM stellt einen lokalen Link bereit, oft http://169.254.169.254/. Eine Anwendung, die eine vom Nutzer gelieferte URL abruft (Bildimport, Webhook, PDF), kann auf diese Adresse umgeleitet werden: Das ist ein SSRF, der die Rolle der Maschine stiehlt. Bei AWS reduziert IMDSv2 (Token-Pflicht, begrenzte Hops) dieses Zeitfenster deutlich. IMDSv1 bleibt der Standard vieler älterer AMIs.

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

Wenn diese URL von der Anwendung aus antwortet, ist der Befund kein „theoretisches SSRF" mehr. Es ist die Übernahme der EC2-Rolle, also oft S3-Leserechte, manchmal die Übernahme einer höheren Rolle. Modul 7 hat das als A10 eingestuft. Hier ordnen Sie es der Cloud zu: Das Secret war nicht im Code, es war an die Instanz gebunden.

4. Mobile — der Client ist keine Grenze

Wesentlicher Unterschied zum Web: Das Binary läuft auf einem Gerät, das der Angreifer besitzen kann. Root, Emulator, TLS-Proxy, Speicherauszug. Sicherheit so zu konzipieren, „niemand wird die APK dekompilieren", ist eine falsche Annahme.

Die clientseitige Schutzmaßnahme dient dem Design

Ein Bildschirm, der einen Admin-Button versteckt, ist keine Zugriffskontrolle. Die API muss ablehnen. Lektion 11.2 zeigt das an einer Flutter-App: Das Dashboard erscheint, der Server antwortet mit 401. Verwechseln Sie die beiden nicht.

Drei Angriffsflächen tauchen in fast jedem mobilen Auftrag auf.

4.1. Das Binary — APK, IPA, Bundle

Eine APK ist ein Zip. apktool zerlegt sie, jadx dekompiliert sie in lesbares Java. Die Konstanten (API-URL, „Premium"-Schlüssel, Feature-Flag, Debug-Endpunkt) überleben die Kompilierung.

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

Bei Flutter lebt der Dart-Code in libapp.so (oder in main.dart.js für den Web-Build). Der Reflex ist derselbe: nach Zeichenketten suchen, nicht das Framework „knacken". Die Demonstration 11.2 startet mit genau diesem Grep. Merken Sie sich die Regel: Wenn das Backend ein Secret braucht, hat dieses Secret im Client nichts verloren. Ein API-Schlüssel in der APK ist kein Schlüssel mehr.

Bei iOS lässt sich die IPA entpacken; die Info.plist und die Swift/Obj-C-Binaries liefern dieselben URLs. Für die statische Analyse ist kein Jailbreak nötig.

4.2. Der lokale Speicher

Die App schreibt auf die Festplatte. Ein Angreifer mit dem Gerät (oder einem unverschlüsselten Backup) liest:

Plattform	Typischer Ort	Häufige Falle
Android	SharedPreferences-XML, SQLite-Datenbanken	Session-Token im Klartext, Passwort „der Bequemlichkeit halber"
iOS	UserDefaults, plist-Dateien, falsch genutzter Keychain	Secret in UserDefaults statt im Keychain
Flutter	shared_preferences, App-Dateien	Derselbe Fehler, plattformübergreifende API

Der Keychain / Keystore kann ein Secret aufbewahren. Man muss ihn allerdings nutzen, mit einer Schutzstufe, die die Entsperrung des Telefons voraussetzt. Eine XML-Präferenz bietet keine dieser Garantien.

4.3. Certificate Pinning — was es tut, was es nicht tut

Ohne Pinning fängt ein Proxy (Burp, mitmproxy) das TLS ab, sobald der Nutzer eine Unternehmens-CA akzeptiert — oder sobald der Angreifer das Gerät kontrolliert. Das Pinning fügt eine Prüfung hinzu: Das Zertifikat (oder der öffentliche Schlüssel) muss mit dem in der App eingebetteten übereinstimmen.

Drei nützliche Lesarten:

• Kein Pinning: Das Abfangen von TLS ist auf einem von Ihnen kontrollierten Gerät trivial. Das ist der Standardfall.
• Pinning vorhanden: Das verlangsamt die dynamische Analyse. Es macht die API nicht sicher. Frida und Objection hängen sich bei der Mehrheit der Apps immer noch in TrustManager / boringssl ein. Das Pinning ist eine Reibung, keine Grenze.
• Pinning + Secrets in der APK: Sie haben den Grep nur etwas länger gemacht.

Werkzeuge der mobilen Prüfung, in dieser Reihenfolge: statisch (apktool, jadx, strings) dann dynamisch (frida, objection) auf dem Lab oder der App des Kunden. Der Workshop 11.3 bietet einen Bonus-APK außerhalb von Docker für alle, die denselben Reflex an einem nativen Binary üben wollen.

5. IoT — die Grundlagen reichen aus

Ein IoT-Pentest enttäuscht diejenigen, die einen Funk-0-Day erwarten. Er beruhigt diejenigen, die bereits Windows-Härtung gemacht haben: Man landet wieder bei Werkskonten, HTTP, einer abrufbaren Firmware.

Drei Fragen, in dieser Reihenfolge.

5.1. Standardkonto

admin:admin, root:vizxv, admin:12345. Öffentliche Sammlungen (RouterSploit, Herstellerlisten) decken ein Jahrzehnt an Modellen ab. Wenn das Passwort ab Werk nicht pro Gerät eindeutig ist, ist der Befund derselbe wie bei Mirai 2016. Die Abhilfe ist organisatorisch: Inventar, erzwungener Wechsel bei der ersten Verbindung, Ausmusterung von Geräten, für die der Hersteller keine Updates mehr liefert.

5.2. Unverschlüsselter Dienst

Telnet, HTTP-Verwaltung, MQTT ohne TLS, Videostream ohne Authentifizierung. Ein Angreifer im selben LAN (oder im WAN, wenn UPnP einen Port geöffnet hat) liest die Sitzung mit. Verschlüsselung ersetzt keine Authentifizierung: Ein RTSP über TLS mit admin:admin fällt trotzdem.

5.3. Abrufbare Firmware

Viele Hersteller veröffentlichen die .bin-Datei auf ihrer Website, oder die Oberfläche liefert sie unter /upgrade aus. binwalk extrahiert das Dateisystem. strings fördert private Schlüssel, fest einprogrammierte Passwörter, unsignierte Update-URLs zutage.

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

Ein Secret in der Firmware ist ein Secret für die gesamte Flotte desselben Modells. Das ist das IoT-Äquivalent des Schlüssels in der APK.

WiFi und Kameras: ein eigenes Kapitel

Die Funkstrecke, WPA2-PSK, PMKID, Deauth und die typische Kette bei einer IP-Kamera werden in Lektion 11.5 behandelt. Diese Seite wiederholt sie nicht. Merken Sie sich nur den Zusammenhang: Fällt das WiFi, fällt das Gerät binnen einer Minute. Die Verteidigung, die hält, beginnt mit Segmentierung (VLAN / IoT-SSID) und Inventar, nicht mit einem Antivirus auf der Kamera.

6. Wie man im Einsatz priorisiert

Eine Woche Pentest deckt nicht „die Cloud, das Mobile und das IoT" ab. Man wählt anhand der RoE und des Werts.

Kundenkontext	Hohe Priorität	Was man nicht zuerst macht
SaaS bei AWS gehostet	IAM, Buckets, Metadaten, Git-Schlüssel	Kernel der AMI
Mobile App + API	Bundle, lokaler Speicher, API-Kontrollen	0-Day des Stores
Sensorflotte	Werksfehler, HTTP, Segmentierung	Exotische Funkprotokolle
KMU mit Kameras	Siehe 11.5: WiFi, RTSP, Werkspasswörter	Nicht öffentlicher Herstellerexploit

Der IoT-Bericht legt mehr als andere Wert auf organisatorische Abhilfemaßnahmen: Inventar, VLAN, Update-Zyklus, UPnP-Verbot. Ein Firmware-Patch, den der Hersteller nie veröffentlichen wird, ist keine umsetzbare Empfehlung.

7. Verwechslungen, die Zeit kosten

• „Die Cloud ist sicher, also ist mein S3 es auch." Der Anbieter sichert das Fundament. Die ACL, das sind Sie.
• „Wir haben die APK obfuskiert." Die Obfuskation verzögert einen Menschen. Sie entfernt keinen Schlüssel aus der APK. strings reicht oft aus.
• „Das Pinning ersetzt die serverseitige Authentifizierung." Nein. Es behindert den Proxy. Das IDOR bleibt ein IDOR.
• „IoT = fortgeschrittener Funkangriff." 2026 schließen die meisten IoT-Aufträge mit einem Werkspasswort und Port 80 ab.
• „Pacu gegen AWS." Pacu gegen das Konto des Kunden, mit einem Schlüssel, den der Kunde Ihnen gegeben hat, im schriftlich festgelegten Scope.

Was Sie sich merken sollten

Cloud, Mobile und IoT lesen sich mit demselben Raster: wer trägt die Verantwortung, wo lebt das Secret, und was kontrolliert ein Angreifer bereits. In der Cloud ist die Antwort fast immer eine Richtlinie (IAM, Bucket, Schlüssel, Metadaten). Bei Mobile wird alles, was im Client lebt, irgendwann nach draußen gelangen; die echte Kontrolle ist die API. Bei IoT schließen die Grundlagen — Werkseinstellungen, HTTP, Firmware — mehr Vorfälle als ein Protokoll-Exploit.

Nächste Lektion: Wir wenden das mobile Raster auf eine absichtlich schwache Flutter-App an, vom Grep des Bundles bis zum Admin-Flag.