Lehet-e egy Spotify-gombból fékhiba? Tíz éve még sci-finek hangzott, ma viszont nagyon is valós kockázat: 2015-ben etikus hackerek egy Jeep Cherokee fedélzeti szórakoztató rendszerén keresztül távolról avatkoztak be a jármű kormányzásába és fékezésébe. A botrány után 1,4 millió autót hívtak vissza egyetlen szoftverhiba miatt.

Azóta az autók még okosabbak, még jobban hálózatba kötöttek – és ezzel együtt még sebezhetőbbek is lettek. A kérdés ma már nem az, hogy „feltörhető-e” egy modern autó, hanem az, hogy hol és milyen úton érdemes védekezni. Egy friss, átfogó kutatás 413 új, autóipari szoftverhez köthető sérülékenységet elemzett ki, és 20 nyílt forrású, autós környezetben használt projektet fésült át automatikus eszközökkel. A kép kijózanító: a problémák súlyosbodnak, és egyre inkább a felhőben, webes felületeken és külső szolgáltatásokban koncentrálódnak – nem az autó belsejében.

Az alábbiakban összefoglaljuk, hogyan változott az autók kiberbiztonsági kockázati térképe, milyen konkrét technológiák érintettek, és mit tehetnek a gyártók, fejlesztők és – nem utolsósorban – a felhasználók.

Az autó ma már nem „doboz a kerekeken”, hanem elosztott felhőalkalmazás

A modern, hálózatba kötött jármű (Connected Vehicle, CV) nem egy magányos beágyazott rendszer. Sokkal inkább egy elosztott, több szereplős ökoszisztéma, amelyben négy nagy szoftveres világ találkozik:

• Járművön belüli szoftverek: ECU-k, motor- és fékvezérlők, fedélzeti infotainment, telematikai egység, GPS, kulcsnélküli rendszerek.
• Külső entitások: flottakövető és parkolási rendszerek, gyártói felhőszolgáltatások, adatgyűjtő és analitikai platformok, ügyfélportálok, mobil- és webappok.
• Fejlesztői / OEM-ökoszisztéma: build- és CI/CD-rendszerek, konténer-infrastruktúra, szimulátorok, tesztkörnyezetek – vagyis maga a szoftverellátási lánc.
• Kommunikációs réteg: V2X-protokollok, MQTT, DSRC, mobilhálózati modemek, Wi-Fi, Bluetooth.

Mindegyik réteg más-más szereplő kezében van: OEM, Tier1 beszállító, félvezetőgyártó, felhőszolgáltató, nyílt forrású közösség. Ez azt is jelenti, hogy a sebezhetőségek kezeléséhez nem elég „az autót” nézni – érteni kell, melyik komponensért ki felel, hol frissíthető a kód, és hol csak kerülő úton lehet védekezni (pl. hálózati szegmentációval).

413 új sérülékenység, 827 sebezhető könyvtár: mit talált a kutatás?

A svédországi Göteborgi Egyetem és a Chalmers kutatói 2022 januárja és 2024 szeptembere között publikált, autóipari szempontból releváns sérülékenységeket gyűjtöttek össze a NVD adatbázisból és további forrásokból (CISA KEV, VulDB, MITRE stb.). Emellett 20, autós környezetben használt nyílt forrású projektet (pl. telemetriai dashboardok, buildeszközök, perception stackek) vizsgáltak öt különböző sérülékenység-vizsgáló eszközzel (Snyk, Grype, Trivy, Docker Scout, Vulert).

A kép a következő:

• 413 új, autóipari szoftverhez köthető CVE-t azonosítottak.
• A vizsgált nyílt forrású projektekben 827 sebezhető könyvtárat találtak.
• A sérülékenységek 44,8%-a magas, 16,3%-a kritikus súlyosságú volt (CVSS 3.0 alapján).
• A legtöbb hiba már nem a „vasban”, hanem külső alkalmazásokban és felhőszolgáltatásokban jelent meg.

Ez utóbbi a legfontosabb trend: míg a 2010–2019 közötti időszakban a hibák többsége még az autó belső rendszereiben (ECU, firmware) bukkant fel, mostanra a hangsúly eltolódott a webes és felhőalapú komponensek felé. Az autó köré épülő szolgáltatások – telematikai portálok, flottamenedzsment, OTA backendek – lettek az új frontvonal.

Nem csak több, hanem súlyosabb hibák is: a HIGH és CRITICAL kategória előretört

A kutatók összevetették eredményeiket egy korábbi, 2010–2019 közötti vizsgálattal. Akkor a sérülékenységek közel fele közepes súlyosságú volt, a kritikus hibák aránya mindössze ~5%. Ma már egészen más a kép:

• HIGH (magas) súlyosság: ~45% az összes CVE-ből.
• CRITICAL (kritikus): ~16% – több mint háromszoros növekedés a korábbi időszakhoz képest.

Ráadásul a súlyos hibák időben is koncentrálódnak: 2022 második negyedévében jelent meg a legtöbb kritikus, 2023 harmadik negyedévében a legtöbb magas súlyosságú sérülékenység. A kritikus hibák többsége külső webalkalmazásokhoz, a magas súlyosságúak jelentős része SoC/ECU-szoftverek buffer overflow és memória-korrupciós problémáihoz köthető.

Kívülről befelé: az új fő támadási felület a felhő és a web

A 413 sérülékenységet a kutatók kilenc „támadási vektorba” sorolták, attól függően, hogy melyik szoftverkomponensben jelent meg a hiba. Az eredmény:

• Külső alkalmazások (web- és mobilappok, felhőszolgáltatások) – 36,2%
• SoC / chipset szoftver – 23,5%
• Telematikai rendszerek – 14,8%
• Infotainment, kommunikációs protokollok, OEM-eszközök stb. – a maradék.

Ha ezt összevetjük a 2010–2019-es képpel, egyértelmű trend rajzolódik ki: a támadások fókusza az autó belsejéből a „köré épülő” szoftvervilág felé tolódik. Ez logikus: a webes és felhőalapú rendszerek könnyebben elérhetők, gyakran gyorsan fejlesztik őket, sok harmadik féltől származó komponenst használnak, és sokszor nem esnek át olyan szigorú biztonsági minősítésen, mint egy fékvezérlő ECU.

Konkrét példa a kockázatra: a Volkswagen-csoportnál nemrég egy harmadik fél által kezelt, rosszul védett AWS-kulcs miatt szivárgott ki mintegy 800 ezer ügyfél hely- és elérhetőségi adata. Itt nem az autó „romlott el”, hanem a köré épített felhőszolgáltatás.

Ki szállítja a legtöbb hibát? Qualcomm, Grafana, SourceCodester

A sérülékenységeket OEM-ekhez és beszállítókhoz is hozzárendelték. A lista élén:

• Qualcomm – 58 sérülékenység különböző autós chipset-platformokban (Snapdragon Auto 4G/5G modemek, Snapdragon 820 Automotive, QCA-s Wi-Fi/Bluetooth chipek).
• SourceCodester – 55 hiba egy nyílt forrású, járműszerviz-menedzsment rendszerben (klasszikus webes sebezhetőségek: SQL injection, XSS).
• Grafana – 53 sérülékenység telemetriai dashboardokban, pluginekben, IoT-connectorokban.

Fontos árnyalat: a magas CVE-szám nem feltétlenül „rossz minőséget” jelent. A Qualcomm például hatalmas piaci részesedéssel, összetett szoftverstackkel és viszonylag átlátható, rendszeres biztonsági közleményekkel dolgozik, így látszik, ami máshol rejtve marad. A Grafana pedig tipikus példája annak, hogyan lesz egy általános célú, nyílt forrású eszköz az autóipari telemetria szerves része – és vele együtt az összes, webes világban jól ismert sebezhetőség is beköltözik a jármű környezetébe.

Hol csúszik be a hiba? A fejlesztési fázis a fő gócpont, de a tervezés is ludas

A kutatás nem állt meg a „hol van a bug?” kérdésnél: megpróbálta visszakövetni, melyik SDLC-fázisban (szoftverfejlesztési életciklus) keletkezhetett a sérülékenység. Ehhez a CVE-khez rendelt CWE-k (Common Weakness Enumeration) leírásait használták, amelyek gyakran jelzik, hogy a hiba tipikusan melyik fázisban születik (követelmény, tervezés, fejlesztés, gyártás stb.).

Az eredmény:

• A legtöbb hiba a fejlesztési fázishoz köthető (klasszikus programozási hibák, inputkezelés, memóriahasználat).
• Jelentős mennyiség már a tervezési fázisban születik (pl. hardcoded credential, rossz jogosultsági modell, gyenge architektúra-szegmentáció).
• A tesztelés és utóélet (post-production) fázisaihoz alig tudtak hibát kötni – nem azért, mert ott nem lenne gond, hanem mert ezeket a hibákat ritkán így dokumentálják.

Érdekes különbség: infotainment és telematikai rendszerek esetén a hibák viszonylag egyenletesen oszlanak meg a követelmény-, tervezési-, fejlesztési- és gyártási fázis között. Ez azt sugallja, hogy ezeknél a komponenseknél végig hiányzik a biztonsági szemlélet, nem csak a kódolásnál.

Mit támadnak valójában? SQL injection, XSS, jogosultságkezelési hibák, buffer overflow

A 413 CVE-t a kutatók CAPEC-típusokhoz (Common Attack Pattern Enumeration and Classification) is hozzárendelték, vagyis megnézték, milyen támadási minták húzódnak mögöttük. 90 különböző CAPEC jelent meg, az élmezőnyben:

• CAPEC-1 – Hozzáférés nem megfelelően korlátozott funkciókhoz (ACL-hibák, rossz jogosultságkezelés) – növekvő trend.
• CAPEC-233 – Privilege Escalation – szintén növekvő trend.
• CAPEC-66 – SQL Injection – még mindig sok, de enyhén csökkenő.
• CAPEC-63 – Cross-Site Scripting (XSS) – 2023-ban kiugróan sok, 2024-ben visszaesés.
• CAPEC-100 – Buffer Overflow – továbbra is jelentős, de csökkenőben.

A kép nagyon hasonlít a klasszikus web- és backend-világra: inputvalidációs hibák, injekciók, jogosultságkezelési bakik, memória-korrupció. A különbség az, hogy itt nem egy webshop kosara fagy le, hanem egy járműrendszer állhat meg, vagy kerülhet illetéktelen kézbe.

Nyílt forrás, rejtett kockázatok: TensorFlow, MySQL, OpenJDK, QtWebEngine

A 20 vizsgált nyílt forrású projekt (köztük autós perception stackek, szimulátorok, telemetriai eszközök, buildrendszerek) átvizsgálásakor 827 sebezhető könyvtárat találtak. Néhány tanulság:

• A legtöbb CVE-t a Grype találta meg, de a különböző eszközök eltérő eredményeket adtak – vagyis egyetlen scannerre támaszkodni veszélyes.
• Akadtak „rejtett” hibák: volt olyan repo, ahol csak a Snyk jelzett problémát, a többi eszköz nem.
• A legsebezhetőbb repo a grafana/grafana volt (több ezer CVE-vel a teljes történetét nézve), ami jól mutatja, mennyire kockázatos egy komplex, plugin-alapú, webes technológiákra épülő eszköz.
• A legtöbb hibával rendelkező könyvtár a tensorflow_gpu (361 CVE) – ezek ~70%-a DoS-t okozó „reachable assertion” jellegű hiba, ami perception moduloknál különösen kellemetlen: egy rossz bemenet egyszerűen leállíthatja az egész feldolgozó pipeline-t.

Emellett kirajzolódik egy „közös mag” is: olyan könyvtárak, amelyek szinte minden projektben felbukkannak – openssl, libgcrypt20, libgnutls30, libc6, coreutils stb. Ha ezek közül bármelyikben komoly 0-day jelenik meg, az egész ökoszisztémára kihat: OTA backend, telematikai szerver, fejlesztői pipeline, sőt akár a járműben futó Linux-alapú rendszerek is érintettek lehetnek.

Autó vs. IoT vs. ipari vezérlők: miben más az autóipari kockázat?

A kutatás összevetette az autóipari sérülékenységek gyengeség- és súlyossági mintázatát az IoT- és ICS (ipari irányítórendszerek) világgal. Néhány érdekes különbség:

• Az autóiparban CWE-89 (SQL Injection) és CWE-79 (XSS) dominál – ez azt mutatja, hogy az autók egyre inkább webes technológiákra támaszkodnak (infotainment, telematika, OTA-portálok).
• ICS-ben sokkal gyakoribbak a klasszikus memóriahibák (CWE-787, CWE-125, CWE-416, CWE-121) – régi C/C++ kód, ritka frissítések, valós idejű követelmények.
• IoT-ben vegyes a kép: inputvalidációs gondok, hozzáférés-vezérlési hibák, integer overflow-k.
• A magas súlyosságú hibák mindhárom doménben dominálnak, a kritikus hibák aránya 15–16% körül mozog – tehát az autóipar nem „különlegesen rossz”, de a következmények itt sokkal látványosabbak lehetnek.

Az autóipar tehát egy hibrid világban él: egyszerre kell webes biztonsági gyakorlatokat (inputvalidáció, paraméterezett lekérdezések, CSP, XSS-elleni védelem) és beágyazott rendszerekre jellemző hardeninget (memóriabiztonság, ASLR, sandboxing, ECU-szegmentáció) alkalmazni.

Mit tehet a gyártó és a fejlesztő? Konkrét irányok a gyakorlatban

A kutatás nem csak diagnózis, hanem konkrét ajánlásokat is megfogalmaz, kifejezetten modern eszközökre és szolgáltatásokra fókuszálva. A legfontosabbak:

1. Memóriabiztonság az ECU-kban és SoC-kben

• Memóriabiztos nyelvek (pl. Rust, részben Go) fokozatos bevezetése biztonságkritikus komponensekben, ahol a teljesítmény engedi.
• Biztonságos C-könyvtárak (pl. Microsoft Strsafe.h, SafeStr) használata, veszélyes stringműveletek kerülése, előre allokált pufferkezelés.
• Fordítóflag-ek (FORTIFY_SOURCE, stack canary-k, /GS, ProPolice) bekapcsolása, ASLR és PIE használata a nagyobb, Linux-alapú ECU-kon.
• Memóriaanalízis-eszközök (Valgrind, AddressSanitizer, Memcheck) integrálása a CI/CD pipeline-ba.

2. Webes backendek és telematikai portálok: SQL injection és XSS kiirtása

• Paraméterezett lekérdezések, ORM-ek (Hibernate stb.) következetes használata, allowlist alapú inputvalidáció.
• Output-encoding minden felhasználói adat megjelenítésekor (OWASP ESAPI, templaterendszerek auto-escapinggel).
• Hibakezelés: ne szivárogjon SQL-séma, stack trace vagy VIN a hibaoldalakon; részletes logokhoz szigorú hozzáférés-szabályozás.
• Automatizált tesztelés: sqlmap, ZAP Proxy, Burp Suite integrálása a tesztelési folyamatba.

3. Infotainment és telematika: tűzfal az autó és a web között

• Hálózati szegmentáció: infotainment/telematika és biztonságkritikus ECU-k (fék, kormány, motor) közé erős gateway, szigorú üzenetszűrés.
• Threat modeling kifejezetten a külső interfészekre (Wi-Fi hotspot, Bluetooth, mobilapp-API, OTA-csatorna).
• SBOM-alapú ellenőrzés: minden beépített komponens (nyílt forrású könyvtár, konténerimage) folyamatos monitorozása CVE-kre.

4. Jogosultságkezelés és privilege escalation elleni védelem

• Legkisebb jogosultság elve: külön felhasználók, szerepkörök, finomhangolt ACL-ek minden komponenshez (pl. Grafana, telemetriai backend).
• Privilege separation: magas jogosultságú műveletek (firmware-frissítés, kulcskezelés) izolált szolgáltatásokban, védett kommunikációs csatornán.
• Időben korlátozott privilégium: csak a szükséges időre emelt jogosultság, utána azonnali visszavétel.
• Sandboxing: AppArmor, SELinux, seccomp profilok használata infotainment és gateway rendszereken.

5. Ellátási lánc-biztonság: SBOM, többféle scanner, közös könyvtárak figyelése

• SBOM-készítés minden komponenshez (CycloneDX, SPDX), és ezek folyamatos összevetése CVE-adatbázisokkal.
• Több eszköz használata (Snyk, Grype, Trivy, Docker Scout, Vulert) – az eltérő eredmények miatt nem elég egyetlen scanner.
• Központi, „kritikus” könyvtárak (openssl, libgcrypt, libgnutls, libc6, TensorFlow, MySQL-kliensek) kiemelt figyelése, gyors patchmenedzsment.

És mit tehet a felhasználó?

A kutatás hangsúlyozza: az elsődleges felelősség a gyártóké és beszállítóké, de a felhasználó sincs teljesen eszköztelen helyzetben. Néhány praktikus lépés:

• Szoftverfrissítések: ne halogassuk az OTA-frissítéseket, és szervizben is kérdezzünk rá, hogy a jármű szoftvere naprakész-e.
• Erős, egyedi jelszavak a gyártói portálokhoz, mobilappokhoz; jelszó-újrahasznosítás kerülése.
• Mobilapp-jogosultságok felülvizsgálata: tényleg kell-e állandó helyhozzáférés, kontaktlista, kamera?
• Eszközbiztonság: a járműhöz kapcsolt telefon, tablet, laptop is része a támadási felületnek – itt is fontos a frissítés, kéttényezős azonosítás, kártevővédelem.

Merre tovább? Az autóipari biztonság új realitása

A connected vehicle ma már nem csak CAN-busz és ECU-k halmaza, hanem egy komplex, felhőre, webes technológiákra és nyílt forrású komponensekre épülő rendszer. A mostani kutatás azt mutatja, hogy:

• a sérülékenységek száma nő,
• a súlyosságuk is emelkedik,
• és egyre inkább kívülről, webes és felhőalapú szolgáltatásokon keresztül érkeznek.

A védekezés kulcsa az, hogy az autóipar teljes értékű szoftveriparként kezdjen gondolkodni magáról: SDLC-szintű biztonsági tervezéssel, DevSecOps-folyamatokkal, SBOM-alapú ellátási lánc-felügyelettel, és a webes világban már bevált védelmi minták következetes átvételével. Aki ma autós szoftvert fejleszt – legyen az Linux-alapú infotainment, felhős telemetriai backend vagy épp egy perception modul TensorFlow-val – valójában nem „autóelektronikát”, hanem egy kritikus, elosztott rendszert épít, amely ugyanazokkal a kockázatokkal él, mint bármely modern felhőszolgáltatás – csak a tét nagyobb.