Przejdź do treści

Szukaj w Security Magazine

NewsletterNewsletter
CybernewsyBezpieczeństwo łańcucha dostawCompliance i ład organizacyjnyLogistyka i bezpieczeństwo transportuOprogramowanie i narzędzia pracy

Telematyka, OTA i łańcuch dostaw: nowe ryzyka cyber w transporcie publicznym

Zakup kolejnych 30 elektrycznych autobusów Yutong przez Warszawę zwrócił uwagę opinii publicznej na kwestię cyberbezpieczeństwa pojazdów w transporcie miejskim. W Polsce takie autobusy są już eksploatowane w ponad 30 samorządach, a ich flota szybkorn rośnie. Tymczasem testy przeprowadzone w Norwegii ujawniły potencjalne ryzyka zdalnego dostępu producenta do subsystemów pojazdu, co wywołało natychmiastową reakcję władz w Danii. Przypadek pokazuje, że wraz z elektryfikacją transportu rośnie znaczenie polityki cyberbezpieczeństwa — od telematyki i OTA po łańcuch dostaw oprogramowania.

W tym tekście (4)

Norwegia sprawdza niezależność eautobusów

W drugiej połowie października 2025 r. norweski operator transportu publicznego Ruter AS przeprowadził szczegółowe testy bezpieczeństwa z udziałem elektrycznych autobusów Yutong, obsługiwanych w regionie Oslo i Akershus. Testy realizowano w dniach 20–29 października 2025 r., z udziałem wewnętrznych zespołów cyber oraz zewnętrznych konsultantów. Ich celem było porównanie poziomu zabezpieczeń telematycznych pomiędzy różnymi producentami taboru.

W trakcie kontroli wykryto potencjalną możliwość nawiązania zdalnego połączenia z subsystemami diagnostycznymi i telemetrycznymi pojazdu poprzez moduł komunikacyjny wyposażony w SIM/eSIM. Analiza wskazała, że połączenie mogło umożliwiać:

  • zmianę parametrów diagnostycznych pojazdu bez fizycznego dostępu, 
  • obserwację wybranych danych operacyjnych, 
  • ingerencję w konfigurację usług sieciowych. 

Segmentacja komunikacji pomiędzy telematyką a subsystemami sterowania wymagała doprecyzowania. Nie potwierdzono bezpośredniego wpływu na układy napędowe, jednak sam fakt statystycznej możliwości takiej ścieżki zwrócił uwagę regulatora.

W dniu 31 października 2025 r. Ruter podjął decyzję o czasowym odcięciu zdalnego dostępu do pojazdów Yutong poprzez ograniczenie dostępu zdalnych kanałów diagnostycznych. Działanie było środkiem ostrożnościowym, mającym zapobiec ewentualnemu wykorzystaniu wektora przez podmiot nieuprawniony.

Na początku listopada (02–04.11.2025 r.) raport przesłano do norweskiej Agencji ds. Bezpieczeństwa Transportu (Statens vegvesen) oraz do Ministerstwa Transportu, które zarekomendowały analizę:

  • kontroli nad telemetrią, 
  • warstw separacji sieci pojazdu, 
  • modeli uwierzytelniania OTA, 
  • lokalizacji i własności danych diagnostycznych. 

W odpowiedzi regulator rozpoczął prace nad doprecyzowaniem wymagań cyberbezpieczeństwa w specyfikacjach przetargowych dla taboru zeroemisyjnego, które mają wejść w życie w 2026 r.

Operator podkreślił, że incydent miał charakter prewencyjny — nie stwierdzono realnego ataku, ale wykazana możliwość ingerencji w subsystemy diagnostyczne została uznana za nieakceptowalne ryzyko z punktu widzenia bezpieczeństwa publicznego.

Istotnym wnioskiem technicznym z badań było wskazanie na konieczność:

  • stosowania kryptograficznie podpisanych aktualizacji OTA, 
  • zasady zero trust pomiędzy subsystemami pojazdu, 
  • obowiązkowego logowania zdarzeń telemetrycznych, 
  • pełnej transparentności dokumentacji firmware. 

Co więcej, Ruter zwrócił uwagę na brak standardów branżowych w zakresie zdalnej diagnostyki autobusów komercyjnych — w przeciwieństwie do sektora motoryzacyjnego UE.

W konsekwencji, norweska administracja zapowiedziała rekomendację:

  • obowiązkowych testów penetracyjnych przy odbiorach pojazdów, 
  • deklaracji lokalizacji danych telemetrycznych, 
  • udzielania operatorom prawa do blokowania zdalnego dostępu producenta, 
  • formalnych audytów łańcucha dostaw oprogramowania. 

Przypadek Norwegii stał się szeroko komentowany w Europie ze względu na praktyczny charakter wniosków: potencjalna ścieżka ataku, nawet niewykorzystana, wystarczyła, by uruchomić działania na poziomie regulatora. To sygnalizuje zwrot w podejściu do cyberbezpieczeństwa transportu publicznego — z reaktywnego na proaktywny.

Kryzys zaufania w Kopenhadze

Jednym z największych odbiorców Yutong w Europie jest Dania. W aglomeracji kopenhaskiej działa ponad 350 autobusów tej marki. Po ujawnieniu ryzyk władzom transportowym przedstawiono raport audytowy. W konsekwencji:

  • rozpoczęto przegląd procedur zakupowych, 
  • zaostrzono zasady dostępu do telemetrii, 
  • zwrócono uwagę na lokalizację danych w infrastrukturze poza UE. 

Ministerstwo Transportu zapowiedziało doprecyzowanie kryteriów cyber przy przetargach taborowych w 2026 r.

Yutong w Polsce

Według danych Busnex Poland (czerwiec 2024), oficjalnego przedstawiciela Yutong, dostawy i kontrakty obejmują ponad 310 egzemplarzy autobusów elektrycznych Yutong w Polsce, skierowanych do ok. 30 samorządów w 11 województwach.  W Warszawie operator MZA eksploatował już 18 autobusów Yutong (stan na Q4/2023), a kontrakt podpisany 25.10.2024 r. powiększył flotę o kolejne 30 sztuk modelu U12.

Pojazdy te pozostają w łączności telematycznej z producentem, co wzmacnia znaczenie doświadczeń państw skandynawskich.

Potencjalne wektory ataku

1) Moduły telematyczne (LTE/5G, SIM/eSIM)

  • Wektor: nieautoryzowane połączenie z backendem producenta lub MITM na łączu mobilnym. Możliwe bruteforce/credential stuffing na API/serwisy serwisowe. 
  • Techniki ataku: wykorzystanie słabych certyfikatów, brak mutual TLS, statyczne tokeny API, exploity w modemach (firmware). 
  • Mitigacje: mutual TLS z rotacją certyfikatów, device identity (X.509), HSM/secure element w telematics box, ograniczenie uprawnień (least privilege), egress filtering na bramce. 

2) OTA (Over-The-Air updates)

  • Wektor: wgranie nieautoryzowanego lub zmanipulowanego firmware (sideload, downgrade attack). 
  • Techniki ataku: brak/wadliwa weryfikacja podpisów, replay/downgrade, exploity w bootloaderze. 
  • Mitigacje: secure boot + chain of trust; podpisywanie binariów (PKI), firmware roll-forward only, wykorzystanie TPM/HSM do weryfikacji, podpisy oparte na ECDSA, audyt kodu u dostawcy, podpisy wielostronne (operator + producent). 

3) Magistrala pojazdowa — CAN / automotive Ethernet

  • Wektor: injection spoofed CAN frames, fuzzing sterowników, ARP spoofing na Ethernetie. 
  • Techniki ataku: frame injection, timing attacks (manipulacja priorytetów), flooding (DoS), exploitation of ECUs with known CVEs. 
  • Mitigacje: gateway/firewall CAN (whitelisting PID/IDs), CAN IDS (anomaly detection), network segmentation (separate CAN buses for critical/non-critical), secure gateways (message authentication codes, TESLA-like schemes), secure diagnostics gateway z preautoryzacją. 

4) Diagnostyka i protokoły (UDS, ISO-TP)

  • Wektor: nieautoryzowane użycie UDS service routines (erase, reflash, security access). 
  • Techniki: brak challenge-response, brak rate-limiting, nieaudytowane test-interfaces. 
  • Mitigacje: UDS SecurityAccess z opartym na HSM challenge-response; logging i SIEM; rolowanie kluczy serwisowych; hardware e-fuse dla trybów serwisowych. 

5) BMS (Battery Management System)

  • Wektor: manipulacja parametrami ładowania, SOC, czujników temperaturowych; fałszywe odczyty mogą prowadzić do nadmiernego prądu lub niewłaściwych pól ładowania. 
  • Techniki: injection telemetry spoofing, man-in-the-middle pomiędzy BMS a backendem, firmware tampering. 
  • Mitigacje: zabezpieczenie kanału BMS (TLS), sensor redundancy & plausibility checks, anomaly detection na poziomie BMS, tryb fail-safe w hardware (current cutoff), audyty firmware BMS, bezpieczny boot. 

6) Infrastruktura ładowania (OCPP, TLS)

  • Wektor: atak na OCPP backend, MITM, token theft, manipulacja profilem ładowania (V2G/Smart charging). 
  • Techniki: wykorzystanie słabej implementacji TLS, brak certyfikatów CA, exploity w charge point firmware. 
  • Mitigacje: OCPP 2.0.1 z autoryzacją opartą na certyfikatach, mutual TLS, network segregation (VLAN), monitoring metryk energetycznych, SIEM integracja z operatorami grid. 

7) Backend producenta / supply-chain

  • Wektor: kompromitacja kont serwisowych, CI/CD poisoning, wstrzyknięcie złośliwego kodu do firmware. 
  • Techniki: phishing, lateral movement w chmurze, tampering w pipeline. 
  • Mitigacje: SCA (Software Composition Analysis), code-signing enforced at CI, access controls (RBAC), monitoring kont uprzywilejowanych, regularne SCA/pen tests dostawców, umowy SLA/Right to Audit. 

8) Systemy zarządzania flotą (dashboards, API)

  • Wektor: przejęcie konta operatora → issuing commands, schedule manipulation, mass OTA trigger. 
  • Techniki: credential stuffing, CSRF, broken access control, vulnerable third-party libs. 
  • Mitigacje: MFA, RBAC, API rate limiting, WAF, regular dependency patching, tenant isolation, central logging with alerting thresholds. 

Powiązane materiały