CWE-798. Verwendung hardcodierter Credentials, bleibt eine der häufigsten Schwachstellen-Klassen in vernetzten Produkten. Secrets landen in Firmware-Images, Mobile-Applikationen, Konfigurationsdateien und sogar API-Responses: API-Keys für Cloud-Backends, Service-Passwörter, Zertifikate, Verschlüsselungs-Schlüssel, Tokens für Drittanbieter-Dienste.
Das strukturelle Problem ist keine Schlamperei; es ist Architektur unter Druck. Ein Cloud-API-Key in der Firmware vermeidet ein per-device Identity-System. Ein geteiltes Service-Passwort vermeidet einen Enrollment-Flow. Jede Abkürzung ist einzeln rational, und gemeinsam erzeugen sie ein Credential, das sich nicht ohne Firmware-Release rotieren lässt, nicht auf ein Gerät scoping lässt und nicht widerrufen lässt, ohne die Flotte zu bricken.
Extraktion ist Routine. Firmware-Images sind in der Praxis öffentliche Artefakte: aus einem Gerät gedumpt, aus einem Update-Paket gezogen oder aus dem Binary einer Mobile-App wiederhergestellt. Allein 2025 umfassen reale Fälle administrative Credentials, die aus API-Responses und Mobile-Applikationen wiederherstellbar waren. Nach der Extraktion propagiert das Secret an jeden Ort, der es als Autorisierung akzeptiert.
Secret-Exposition hängt von mehreren technischen Annahmen ab.
- Secret-Inventar Welche Credentials, Keys, Tokens und Zertifikate stecken tatsächlich in Firmware, Apps, Configs und Responses?
- Extraktions-Widerstand Wie viel Aufwand erfordert jeder Speicherort, von String-Extraktion bis Reverse Engineering?
- Trust-Scope Wo wird jedes Secret als Autorisierung akzeptiert: Gerät, API, Backend, Drittanbieter-Dienst?
- Teilungs-Breite Ist das Secret pro Gerät eindeutig, pro Charge, oder global über die Produktlinie?
- Rotations-Fähigkeit Lässt sich das Secret ohne Firmware-Release ersetzen, und was bricht, wenn Sie es versuchen?
- Kompensations-Kontrollen Gibt es Rate-Limiting, Anomalie-Erkennung oder Scoping, das ein geleaktes Secret eindämmt?
- Drittanbieter-Exposition Verraten API-Responses oder App-Binaries Secrets, die der Server als privat behandelt?
Der API-Key öffnete die Cloud, und jedes Gerät mit ihm.
Ein Backend-API-Key steckt in der Firmware, um die Gerät-zu-Cloud-Kommunikation zu vereinfachen. Ein Researcher extrahiert ihn an einem Nachmittag aus einem Firmware-Image.
Der Key gilt für die Produktions-API. Er gewährt jedem Gerät der Flotte denselben Zugriff, потому es derselbe Key ist. Rotation erfordert ein Firmware-Update, das die Flotte über Monate ausrollt. Bis dahin teilen sich Angreifer und Produkte ein Credential.
Die Secrets finden, dann testen, wo sie Vertrauen genießen.
Wir extrahieren Secrets aus Firmware, Apps und API-Responses mit denselben Techniken, die ein Angreifer anwendet, und mappen dann jedes Credential auf die Systeme, die es akzeptieren. Das Assessment beantwortet die kommerzielle Frage: Was kostet ein Leak tatsächlich, und welche Architektur-Änderung entfernt die Exposition.
- Neues Produkt verbindet sich mit einem Cloud-Backend
- Mobile-Applikation greift auf Geräte- oder Backend-Dienste zu
- Drittanbieter-Dienste mit API-Keys integriert
- Ein Firmware-Image oder App-Binary ist öffentlich zugänglich
- Ein geleaktes Credential wurde in der Wild beobachtet
- Compliance-Review markiert eingebettete Credentials
- SBOM oder Source-Review vor Release vorbereiten