Angriffsszenario: SDP Response Spoofing – Wettlauf mit dem SECC
Angriffsszenario: SDP Response Spoofing – Wettlauf mit dem SECC
Wie wir bereits beim vorherigen Angriff gesehen haben, sendet das EVCC eine SDP-Anfrage per UDP an ff02::1 (All-Nodes-Multicast) über Port 15118. Doch was passiert, wenn sich ein Angreifer im selben Netzwerk befindet und schneller antwortet als der legitime SECC?
Genau dieses Szenario untersuchen wir in diesem Test. Dazu erzeugen wir eine gefälschte SDP-Antwort, bevor der echte SECC reagieren kann, und leiten das EVCC auf eine vom Angreifer kontrollierte Adresse um. Anschließend beobachten wir, ob das EVCC die manipulierte Antwort akzeptiert oder auf die Antwort des legitimen SECC wartet.
Dafür müssen wir auf UDP-Port 15118 auf die Multicast-SDP-Anfrage des EVCC lauschen und unmittelbar mit einer manipulierten SECC_ResponseMessage antworten. Diese enthält die IPv6-Adresse und den Port des Angreifers sowie SecurityProtocol = 0x10 (kein TLS).
Der Angreifer-Container enthält bereits ein passendes Skript namens attack1_sdp_spoof.py. Dieses bindet sich an UDP-Port 15118, wartet auf eine gültige V2GTP-SDP-Anfrage und sendet anschließend sofort eine manipulierte Antwort zurück, die auf die eigene Adresse und den eigenen Port verweist.
Das Skript erwartet drei Parameter:
Wie auch SECC und EVCC erhält der Angreifer-Container in der docker-compose.yml eine statische MAC-Adresse (02:00:00:00:00:03). Da IPv6-Link-Local-Adressen über EUI-64 aus der MAC-Adresse abgeleitet werden, erhält der Angreifer dadurch dauerhaft die Adresse fe80::ff:fe00:3. Eine dynamische Ermittlung zur Laufzeit ist somit nicht erforderlich. Deshalb wird der Parameter --fake-ip im folgenden Beispiel fest auf diesen Wert gesetzt.
Ein entscheidender Faktor ist die Reihenfolge der Ausführung. Der Angreifer muss bereits lauschen, bevor das EVCC seine erste SDP-Multicast-Anfrage sendet. Da das EVCC nur zwei Sekunden nach dem Start wartet, ist es immer zu spät, den Angreifer erst nach docker compose up zu starten.
Stellen Sie zunächst sicher, dass Sie sich im Projektverzeichnis befinden. Bereinigen Sie anschließend eventuell vorhandene Container und Volumes aus vorherigen Tests:
# All commands must be run from the project root.
# Cleanup: stop and remove any containers and volumes from a previous run
docker compose down -v
docker rm -f attacker 2>/dev/null || trueNun sind wir bereit. Für diesen Test werden drei Terminals im Projektverzeichnis benötigt.
Wichtig: Die Variable SECC_SCENARIO muss in jedem Terminal gesetzt werden, bevor ein Befehl ausgeführt wird. Docker Compose übernimmt stets die Umgebungsvariablen der jeweiligen Shell.
Terminal 1: SECC starten
Starten Sie den SECC im Vordergrund, damit die Live-Logs sichtbar sind:
export SECC_SCENARIO=attack_sdp_spoof
docker compose up secc
Terminal 2: Spoofing-Skript starten
export SECC_SCENARIO=attack_sdp_spoof
docker compose --profile attack run --name attacker attacker \
python /app/scripts/attack1_sdp_spoof.py \
--iface eth0 --fake-ip "fe80::ff:fe00:3" --fake-port 61341Warten Sie, bis folgende Meldung erscheint:
Listening on eth0 UDP :15118 for SDP requests
Terminal 3: EVCC starten
Anschließend wird das EVCC gestartet. Nach zwei Sekunden sendet es automatisch die SDP-Multicast-Anfrage:
export SECC_SCENARIO=attack_sdp_spoof
docker compose up evcc
Sobald alle Container laufen, sendet das EVCC seine SDP-Anfrage. Der Angreifer antwortet zuerst, woraufhin das EVCC versucht, sich mit der vom Angreifer angegebenen Adresse und dem konfigurierten Port zu verbinden.
Kurz darauf erscheinen im EVCC-Log Einträge wie die folgenden:
Dabei handelt es sich um die manipulierte Antwort, die von attack1_sdp_spoof.py erzeugt wurde.
Nun können sämtliche Container mit Ctrl + C beendet werden, damit die PCAP-Dateien korrekt geschrieben werden. Anschließend erfolgt die Analyse der Aufzeichnungen.
docker compose down
docker rm -f attacker 2>/dev/null || trueTraffic-Analyse
Betrachten wir nun die aufgezeichneten Netzwerkdaten.
Im Verzeichnis attack_sdp_spoof eignet sich insbesondere der Mitschnitt evcc_20260703_085312.pcap zur Analyse dieses Angriffs. Da tcpdump direkt auf der Schnittstelle eth0 des EVCC ausgeführt wird, enthält der Mitschnitt sämtliche ein- und ausgehenden Pakete des EVCC, inklusive der manipulierten SDP-Antwort des Angreifers, die vor der Antwort des legitimen SECC eintrifft.
An der Kommunikation sind drei Systeme beteiligt:
| Rolle | IPv6 Link-Local | MAC-Adresse |
|---|---|---|
| EVCC (Opfer) | fe80::ff:fe00:2 | 02:00:00:00:00:02 |
| Angreifer (Spoofer) | fe80::ff:fe00:3 | 02:00:00:00:00:03 |
| Legitimer SECC | fe80::ff:fe00:1 | 02:00:00:00:00:01 |
Frame 19 – SDP-Anfrage
Nach der zweisekündigen Startverzögerung sendet das EVCC in Frame 19 seine SDP-Multicast-Anfrage. Dabei fordert es eine abgesicherte Verbindung per TLS an.
Alle Geräte innerhalb des IPv6-Segments empfangen diese Nachricht gleichzeitig, darunter sowohl der legitime SECC als auch der Angreifer.
Frames 20–22 – Der Angreifer reagiert zuerst
Nur wenige Mikrosekunden nach dem Empfang der SDP-Anfrage sendet der Kernel des Angreifers eine Neighbor Solicitation, um die MAC-Adresse des EVCC aufzulösen. Zu diesem Zeitpunkt hat der legitime SECC noch nicht reagiert.
Nach Abschluss des NDP-Austauschs sendet der Angreifer seine manipulierte SDP-Antwort ohne TLS und verweist dabei auf seine eigene Adresse und seinen eigenen Port (Frame 22).
Diese Antwort erreicht das EVCC, bevor der echte SECC reagieren kann.
Frames 23–24 – Das EVCC verbindet sich mit dem Angreifer
Sobald das EVCC die SDP-Antwort empfängt, versucht es unmittelbar, per TCP eine Verbindung zur angegebenen Adresse und zum angegebenen Port aufzubauen. Dazu sendet es ein SYN-Paket.
Da auf dem Zielport des Angreifers kein Dienst aktiv ist, beantwortet dessen Kernel die Anfrage mit einem RST-Paket. Im Log des EVCC erscheint daraufhin ein ConnectionRefusedError.
Dieses Verhalten ist in dieser Demonstration ausdrücklich erwünscht.
In einem vollständigen Man-in-the-Middle-Szenario würde der Angreifer auf Port 61341 einen TCP-Proxy betreiben. Dieser würde die Sitzung an den echten SECC weiterleiten und gleichzeitig sämtliche V2G-Nachrichten mitlesen oder manipulieren. Dadurch entstünde ein vollständiger Man-in-the-Middle-Angriff, ohne dass das Protokoll über Mechanismen zur Authentifizierung oder Integritätsprüfung verfügt, die diesen Angriff erkennen könnten.
Damit endet unser Szenario zum SDP Response Spoofing.
Im nächsten Beitrag befassen wir uns mit der Zertifikatsvalidierung. Dabei untersuchen wir im Detail, welche Klassen fehlerhafter Zertifikate vom EVCC erkannt und zurückgewiesen werden und welche Zertifikatsfehler unbemerkt akzeptiert werden.
