„Security by Obscurity“ ist die implizite Design-Annahme vieler proprietärer Protokolle: Niemand kennt das Format, also kann niemand es angreifen. In der Praxis rekonstruiert ein erfahrener Reverse-Engineer Nachrichtenstruktur, Kommando-Semantik und Zustandsübergänge aus erfasstem Verkehr in Tagen, manchmal Stunden. Danach kennt der Angreifer das Protokoll so gut wie das Engineering-Team, und oft besser, als die Dokumentation es beschreibt.
Was nach der Rekonstruktion bleibt, ist die eigentliche Sicherheit: Authentisierungs-Entscheidungen, Frische-Erzwingung, Privilegien-Grenzen und Parser-Robustheit. Genau diese Komponenten erhalten in proprietären Protokollen die wenigste Design-Aufmerksamkeit, потому das Bedrohungsmodell des Teams annahm, das Format bliebe geheim.
Die häufigsten Post-Rekonstruktions-Fehler sind strukturell: Längenfelder, die vor Validierung vertraut werden; Parser in privilegierten Kontexten; State Machines, die administrative Kommandos in frühen Zuständen freigeben; und Authentisierung, die Präsenz prüft statt Identität. Keiner davon ist in einem Pentest sichtbar, der an der Netzgrenze stoppt.
Protokoll-Sicherheit hängt von mehreren technischen Annahmen ab.
- Nachrichten-Struktur Wie schnell gibt das Format einer systematischen Analyse nach, und was verrät die Struktur allein?
- Authentisierung Authentisiert das Protokoll Identität und bindet den richtigen Peer, oder detektiert es bloß Präsenz?
- Frische Werden Replay-Angriffe auf zustandsändernden Nachrichten durch Nonces, Zähler oder Zeitstempel verhindert?
- State Machine Welche Kommandos sind in welchen Zuständen erreichbar, und überspringen Fehler- oder Recovery-Zustände die Autorisierung?
- Parser-Robustheit Wie behandeln Parser malformede, trunkierte und adversariale Eingaben, besonders in privilegierten Komponenten?
- Privilegien-Grenzen Welche Protokoll-Nachrichten erreichen privilegierte Operationen direkt, und was trennt sie?
- Key-Handling Wie werden Session-Keys etabliert, und was macht Protokoll-Zustands-Manipulation mit ihnen?
Der Angreifer hat das Handbuch gelesen, das Sie nie geschrieben haben.
Nach der Rekonstruktion des Protokolls aus erfasstem Verkehr mappt der Angreifer das Kommando-Set und entdeckt: Der Parser läuft in einem privilegierten Firmware-Dienst. Ein malformedes Längenfeld erreicht eine Memory-Operation vor der Validierung.
Das Protokoll war nie dokumentiert, потому es intern war. Der Angreifer hat es dokumentiert, mit besserer Abdeckung der Fehler-Zustände, als das Engineering-Team je getestet hat.
Zuerst rekonstruieren, dann als informierter Gegner angreifen.
Wir reverse-engineeren das Protokoll aus Mitschnitten und Live-Interaktion, rekonstruieren das Zustandsmodell und identifizieren, wo das Protokoll Trust-Entscheidungen trifft. Dann testen wir es als der informierte Angreifer, den das Design letztlich überstehen muss: Mutation, Replay und Spoofing gegen das rekonstruierte Modell, mit besonderem Blick auf Parser-Flächen in privilegierten Kontexten.
- Neues proprietäres Protokoll vor Produkt-Release
- Protokoll-Dokumentation ist unvollständig oder veraltet
- Protokoll-Parser hinzugefügt oder wesentlich geändert
- Produkt verbindet Gerät-zu-Gerät oder Gerät-zu-Backend über eigene Formate
- Eine gemeldete Protokoll-Schwachstelle muss bewertet werden
- Protokoll wurde nie gegen einen informierten Gegner getestet