SOME/IP-Security-Tests: was prüfen und warum

SOME/IP-Security-Tests beantworten eine Frage: welche Services bietet ein Steuergerät im Netzwerk an, und ist jeder nur für die Clients erreichbar, die ihn erreichen sollen? Das Protokoll hat keine eigene Authentifizierung, ein Service ist also nur dadurch geschützt, wo er im Netz liegt und welche zusätzliche Schicht das Projekt ergänzt hat. Der Test beginnt deshalb damit, ein Inventar aus Service Discovery zu bauen, es mit der Kommunikationsmatrix zu vergleichen und alles zu markieren, was dort oder für den angeboten wird, wo oder für den es nicht sein sollte. Robustheitstests kommen danach, am Prüfstand.

Der Header, wie ein Leser ihn braucht

Eine SOME/IP-Nachricht beginnt mit einem 16 Byte langen Header. Ihn zu lesen ermöglicht, ein Capture zu interpretieren und einen Service vom anderen zu unterscheiden.

12 34 00 01   Message ID: Service 0x1234, Methode 0x0001
00 00 00 0A   Length-Feld
00 01 00 01   Request ID: Client ID und Session ID
01            Protocol Version
01            Interface Version
00            Message Type (REQUEST, RESPONSE, NOTIFICATION, ...)
00            Return Code

Method-IDs mit gesetztem höchsten Bit (0x8000 und höher) sind Events, keine Methoden. Responses tragen einen Return Code, der für einen Tester so nützlich ist wie ein UDS-NRC: 0x00 E_OK, 0x02 E_UNKNOWN_SERVICE, 0x03 E_UNKNOWN_METHOD, 0x07 E_WRONG_PROTOCOL_VERSION, 0x08 E_WRONG_INTERFACE_VERSION. Diese Codes sagen dir, ob ein Service existiert und adressierbar ist, bevor du etwas über seine Funktion weißt.

Schritt 1: das Inventar bauen

Service Discovery (SOME/IP-SD) ist die Quelle des Inventars. Steuergeräte kündigen ihre Services mit OfferService-Einträgen an, die Service ID, Instance ID, Major- und Minor-Version, eine Time-to-live und eine Endpoint-Option mit IP-Adresse, Transportprotokoll und Port tragen. Diesen Verkehr mitzuhören und optional mit einem FindService-Eintrag nach Services zu fragen, ergibt eine Liste dessen, was im Netz ist:

Feld	Was der Tester festhält
Service ID / Instance ID	Welcher Service, welche Instanz
Major- / Minor-Version	Angebotene Interface-Version
Endpoint (IP, Protokoll, Port)	Wo er erreichbar ist
TTL	Wie lange das Angebot gilt

AutoST macht diesen Teil passiv und mit aktivem FindService und bildet die Methoden und Eventgroups, die es beobachten kann, auf jeden Service ab.

Schritt 2: mit der Kommunikationsmatrix vergleichen

Das Inventar allein ist nur eine Liste. Die Findings erscheinen, wenn du es neben die Kommunikationsmatrix legst (das ARXML oder das Service-Design des Projekts), die sagt, was jedes Steuergerät anbieten soll und für wen:

• Ein angebotener Service, der nicht in der Matrix steht: ein undokumentierter oder übrig gebliebener Service, das SOME/IP-Gegenstück zu einem versteckten Diagnosedienst.
• Ein Service auf dem falschen Netzsegment: erreichbar aus einer Domain oder einem VLAN, das das Design nie vorsah, etwa von einer nach außen gerichteten Head Unit.
• Mehr Methoden oder Events, als die Matrix listet: ein Interface breiter als seine Spezifikation.
• Ein Versionskonflikt: ein Steuergerät, das eine alte Interface-Version neben der aktuellen weiter anbietet.

Schritt 3: Erreichbarkeit und Zugriff prüfen

Für jeden Service, der eingeschränkt sein sollte, lautet die Frage, ob die Einschränkung wirklich hält. Bestätige am Prüfstand, aus welchen Segmenten der Service überhaupt antwortet, ob er einem Client antwortet, den das Design nicht als Konsumenten listet, und ob ein Event von einem Endpunkt abonniert werden kann, der es nicht empfangen sollte. Ein Service, der einem nie vorgesehenen Client mit E_OK antwortet, ist ein Zugriffsschutz-Finding, unabhängig davon, was die Methode tut. Wo das Projekt Authentifizierung oder TLS über SOME/IP gelegt hat, bestätige, dass sie tatsächlich erforderlich und nicht nur verfügbar ist.

Schritt 4: Robustheit

Zuletzt, und nur am Prüfstand, kommt die Robustheit: wie der Service-Stack mit fehlerhaften Headern, falschen Length-Feldern, unerwarteten Message-Types und abgeschnittenen Payloads umgeht. Dieselbe Crash- und Hang-Erkennung wie beim UDS- und CAN-Fuzzing gilt, denn eine Service-Implementierung, die bei einem schlechten Header umfällt, ist eine Denial-of-Service-Oberfläche.

Die Ergebnisse lesen

Beobachtung	Was es bedeutet
Service nicht in der Matrix	Undokumentierter oder übrig gebliebener Service
Service aus dem falschen Segment erreichbar	Lücke in der Netzsegmentierung
Zusätzliche Methoden oder Events angeboten	Interface breiter als spezifiziert
Antwortet einem Client, der ihn nicht erreichen sollte	Fehlender Zugriffsschutz
Stack fällt bei einer fehlerhaften Nachricht um	Robustheits- und Denial-of-Service-Finding

Die meisten SOME/IP-Findings drehen sich um Erreichbarkeit und Konfiguration, nicht um einen gebrochenen Algorithmus, der Fix liegt also meist im Netzwerkdesign, in der Service-Konfiguration oder in den Gateway-Regeln.

Wie AutoST SOME/IP testet

AutoST entdeckt SOME/IP-Services passiv und mit aktivem FindService, bildet Services, Methoden und Eventgroups auf ihre Endpunkte ab und bewertet die Exposition, und es läuft über dieselbe Ethernet-Verbindung wie für DoIP, sodass Diagnose- und Service-Findings zusammen landen. Die Ergebnisse fließen in denselben Risiko-Score und Fix Plan wie alles andere. Die tiefere Arbeit an einzelnen Services, die Anwendungslogik hinter einer Methode und die Verbindung zu Sicherheitsfunktionen bleiben beim Penetrationstester.