Skutečné příběhy z kyberprostoru Díl 9: Dva politici, třicet policejních aut, 800 000 GPS souřadnic. Útok nebyl potřeba.

David Martínek
22. května 2026
7 min čtení

Prosinec 2024, Hamburg, konference Chaos Computer Clubu. Na pódiu se otevírá ukázka: mapa Německa, na ní 30 modrých teček. Postupně se v reálném čase pohybují – některé se shlukují kolem hamburských policejních stanic, jiné cestují k místům zásahu. Na další obrazovce dvě jména: Nadja Weippert a Markus Grübel. Dva němečtí politici. Jejich pohyb za poslední rok do detailu – dům, kancelář, zasedání, soukromé schůzky. K tomu pár dalších profilů osob spojených s tajnými službami. Vše s deseticentimetrovou přesností.

A žádný útok se nestal. Nic se neprolamovalo. Žádný 0-day, žádný APT, žádný ransomware. Někdo prostě zapomněl uklidit memory dump na veřejně přístupné stránce. A další někdo na to přišel s nástroji, které jsou v Kali Linuxu po instalaci.

Tohle je ten příběh, který jsme před pár dny v článku o shared responsibility slíbili. Reálná ukázka toho, jak vypadá „bezpečnost v cloudu" v praxi, když ji nezvládnete.

Co bylo na stole

Subjektem nebylo Volkswagen Group jako celek, ale jeho softwarová dcera Cariad. Cariad je novější struktura založená v roce 2020 jako jednotná softwarová platforma pro elektrická auta celé skupiny – VW, Audi, Seat, Škoda.

Rozsah úniku v číslech:

  • 800 000 elektromobilů napříč značkami a Evropou (plus některé i jinde ve světě),
  • 460 000 vozů s GPS daty,
  • u VW a Seat přesnost 10 centimetrů,
  • u Audi a Škoda přesnost zhruba 10 kilometrů (jiný režim ukládání),
  • 300 000 vozů jen v Německu, desetitisíce v dalších zemích,
  • terabajty dat v cloudu nezašifrované,
  • mezi cíli 30+ aut hamburské policie a údajně i auta spojená s německými tajnými službami,
  • mezi jmény i dva němečtí politici: Markus Grübel (poslanec Bundestagu, CDU) a Nadja Weippert (komunální politička Strany zelených, starostka města Tostedt) – Spiegel zkontroloval jejich data a oslovil je s otázkou „víte, co o vás teď víme?".

Co konkrétně se v cloudu sbíralo: souřadnice při vypnutí motoru, stav baterie, status servisních prohlídek, kdy auto jelo, kdy stálo, kde stálo, jak dlouho. Vše údajně v rámci „vylepšování softwaru baterie a nabíjení".

Bezpečnostní analytička, která pod přezdívkou Flüpke o případu mluvila na CCC kongresu, k tomu poznamenala větu, kterou by si měl každý vývojář vyvěsit na nástěnku: „Pokud chcete hodnotit bezpečnost baterie, nepotřebujete polohu na deset centimetrů."

Útok, který se neudál, ale data odešla

Tady je celý technický řetězec. Žádný kus z toho nepatří mezi pokročilé útočné techniky.

Krok 1: Cariad měl interní webovou aplikaci s veřejně přístupnými subpages. „Veřejně" tu znamená, že se na ně z internetu šlo dostat. Bez autentizace. Tyhle subpages obsahovaly informaci, kde leží na serveru kopie memory dumpů z jiné interní aplikace.

Krok 2: Memory dumpy byly přístupné na předvídatelných URL. Anonymní whistleblower je systematicky procházel pomocí běžně dostupných nástrojů a jeden si stáhl.

Krok 3: V memory dumpu byly v plain textu AWS access keys. Klíče, které měly oprávnění číst telemetrický S3 bucket. Klíče dlouhodobé, nerotované, bez kontextového omezení.

Krok 4: AWS access keys dovolily přihlášení k S3 bucketu Cariad. V bucketu byly terabajty telemetrických dat z 800 000 vozů. Soubory měly předvídatelné názvy – takže jakmile se útočník dostal k jednomu, dokázal odhadem najít zbytek. Žádné šifrování at rest. Žádný KMS klíč navíc.

Krok 5: Whistleblower poskytl nález CCC a Spiegelu. CCC poté upozornil Cariad (26. listopadu 2024), německé Spolkové ministerstvo vnitra a státní policii. Dal Cariadu 30 dní na opravu, než půjde s případem ven.

Krok 6: Cariad opravil chybu během několika hodin. CCC potvrdil, že technický tým Cariadu reagoval „rychle, důkladně a zodpovědně". Pak ale přišel kongres CCC, prezentace 38C3 v Hamburku 27. prosince, a celý případ šel do médií.

Co se z toho má naučit IT specialista

Tohle je z technického pohledu pětibodový průvodce „jak ne". Každý bod má svůj odpovídající positive: takhle ne, takhle ano.

1. Memory dumpy nikdy nepatří na veřejně přístupné endpointy. Nikdy. Ani v rámci interních testovacích nástrojů, ani na „skoro veřejných" subpages, na které někdo říká „ale to nikdo nezná, je to v podsložce". Internet je systematický – nástroje na content discovery (ffuf, gobuster, dirsearch, feroxbuster) projdou všechny kombinace jmen souborů, které kdy někdo vyslovil. Bezpečnostně relevantní artefakty patří do internal-only sítě, nebo do storage chráněné autentizací s logováním přístupů.

2. AWS access keys v paměti aplikace nemají co dělat. Pokud se chcete autorizovat z aplikace běžící na AWS, používáte IAM Role pro EC2 instance, ECS task role, Lambda execution role, případně IRSA (IAM Roles for Service Accounts) v EKS. Žádné aws_access_key_id a aws_secret_access_key v environment proměnných, v config souborech, ani v paměti. Pokud máte non-AWS workload, používáte AWS IAM Identity Center s federovaným přihlášením + krátkodobé STS credentials (max. 12 hodin, ideálně 1 hodina). Statické klíče v paměti aplikace jsou anti-pattern z roku 2015.

A pokud opravdu, opravdu musíte mít statické klíče (legacy importy, exotické integrace), patří do AWS Secrets Manager nebo Parameter Store s automatickou rotací po 30 dnech a omezením přístupu na konkrétní IAM principal.

3. Šifrování at rest není volitelné. AWS S3 SSE (Server-Side Encryption) má dnes několik módů: SSE-S3 (AWS spravuje klíče), SSE-KMS (vlastní KMS klíč) a SSE-C (vlastní klíč). Pro citlivá data (a GPS souřadnice osobních vozů citlivá data jsou) používáte SSE-KMS s customer-managed KMS klíčem a politikou klíče omezenou na konkrétní role. Kdyby Cariad měl SSE-KMS s key policy „accessible only by service-role-X", útočník s memory-dump-keys by sice viděl seznam objektů, ale dešifrování by mu KMS nepovolil. To je další vrstva, která stojí měsíčně desítky dolarů a šetří miliardové GDPR pokuty.

4. Předvídatelné názvy souborů jsou jako veřejný adresář. Pokud máte v bucketu objekty pojmenované vehicle_data_2024_01.json, vehicle_data_2024_02.json atd., útočník po jednom obejde celý měsíc. Pojmenovávejte objekty s neuhodnutelnými identifikátory (UUID, hash z dat + soli). Pro citlivé prefix-y použijte navíc S3 Object Ownership: BucketOwnerEnforced a vypněte ACLs.

5. Pseudonymizace ≠ anonymizace. Cariad opakovaně tvrdil, že data byla „pseudonymizovaná". To technicky znamenalo, že místo přímého jména byl použit identifikátor. CCC a Spiegel ale ukázali, že korelací s veřejně dostupnými daty (politici mají adresy ve veřejných rejstřících, hamburská policie publikuje fleet informace) lze pseudonym napárovat na konkrétního člověka.

Podle GDPR článku 4 odst. 5 je pseudonymizace ochranným opatřením, ale pseudonymizovaná data stále spadají pod definici osobních údajů, pokud existuje rozumný způsob, jak je deanonymizovat. GPS souřadnice plus časové razítko plus znalost, kde subjekt bydlí, vždy umožňují deanonymizaci. To není teorie – to je matematicky dokázáno (papíry „On the uniqueness of human mobility traces" z 2013 ukazují, že 4 datapointy z mobility dat stačí k jedinečné identifikaci 95 % lidí).

Pokud sbíráte mobility data, anonymizace musí být na úrovni dat samotných (k-anonymity, differential privacy, geo-truncation na úroveň města), ne jen na úrovni přístupových klíčů.

Český kontext: co by tohle znamenalo u nás

Volkswagen incident dopadl primárně do německé jurisdikce (Bundesdatenschutzbeauftragte – BfDI byl informován), ale paralelně proběhl pod evropským GDPR. Pokud by se podobná věc stala u české firmy se sídlem v ČR, na stůl přicházejí dvě paralelní povinnosti.

GDPR (Nařízení 2016/679):

  • Článek 32 – povinnost adekvátních technických opatření (šifrování, pseudonymizace, schopnost obnovit důvěrnost).
  • Článek 33 – ohlášení úniku ÚOOÚ do 72 hodin.
  • Článek 34 – informování dotčených subjektů, pokud je riziko vysoké (a u GPS dat s identifikací je vysoké vždy).
  • Sankce: až 20 milionů EUR nebo 4 % celosvětového obratu (vyšší z obou).

Zákon č. 264/2025 Sb. o kybernetické bezpečnosti (pokud je firma regulovaným subjektem):

  • § 15 + § 16 odst. 1 – hlášení incidentu NÚKIB do 24 hodin od zjištění.
  • Vyhláška 409/2025 § 24 – aplikační bezpečnost (toto by Cariad zařízlo na povinnosti pravidelného skenování zranitelností a penetračního testování).
  • Vyhláška 409/2025 § 25 – kryptografické algoritmy (šifrování at rest = explicitní povinnost, vč. správy klíčů).
  • Vyhláška 409/2025 § 9 + příloha č. 5 – řízení dodavatelů (cloud poskytovatel je významný dodavatel).
  • Sankce: až 250 milionů Kč nebo 2 % obratu.

Při souběhu by česká Cariad-obdoba čelila dvojímu řízení: GDPR od ÚOOÚ a kyberzákonné od NÚKIB. Stejný incident, dva regulátory, dvě potenciální pokuty.

Tři otázky, které byste si měli položit zítra ráno

Tohle není abstraktní příběh. Pravděpodobnost, že podobný řetězec běží i v české firmě, je vysoká. Pokud máte produkt nebo službu, která sbírá osobní data a běží na cloudu, dejte si v týdnu hodinu a projděte tyto otázky:

Otázka první: Kde u nás žijí statické AWS/Azure/GCP přístupové klíče?

Najděte je. Doslova grep -r AKIA napříč repozitáři a config soubory. Najděte je v environment proměnných produkčních deploymentů. Najděte je v memory dumpech, log souborech, error reportech. Pokud nějaký najdete, rotujte ho během hodiny a přejděte na role-based access.

Otázka druhá: Která data, co u nás tečou do cloudu, by se dala použít k identifikaci konkrétního člověka?

Pseudonymizace, kterou jsme nasadili dva roky zpátky, dnes možná stačí, ale možná taky ne. GPS souřadnice + čas + cokoli jiného = de facto identifikátor. Telefonní číslo bez prvních tří číslic + bydliště okresního města = de facto identifikátor. Zamyslete se nad korelací.

Otázka třetí: Pokud by zítra naše data utekla, kolik bychom o tom věděli za hodinu? Za den? Za týden?

Cariad o úniku nevěděl několik měsíců (závisí na zdroji – Spiegel uvádí „několik měsíců", Born uvádí, že data byla dostupná „od léta 2024"). Únik nezachytili jejich vlastní logy ani alerty. Zachytil ho whistleblower. To je IT specialistovi varování: detekční mechanismy, které nikdy nesepnuly, nejsou důkaz, že se nic neděje. Jsou důkazem, že máte hluché místo v monitoringu.

Závěr a co dál

Pokud potřebujete pomoc s tím, jak audit cloudové konfigurace zarámovat do požadavků vyhlášek 409/410 (a u GDPR posoudit pseudonymizační schéma), Kraita Cyber One vám provede systematickou gap analýzou. Nemapuje vám AWS prostředí (na to máte CSPM), ale provazuje vaše technické kontroly s tím, co musíte podle českého zákona doložit – písemně, evidovaně, s evidencí změn.

Vyzkoušejte demo zdarma

Nebo 15 minut nezávazně s naším týmem – bez přesvědčování, jen konkrétní odpovědi.

Co se týče příštího dílu série: skok zpět k managementu. Audit a pentest – kdy je to povinnost, kdy je to investice, a proč většina českých firem dělá oboje špatně. Pondělí 25. května.

Zdroje

  • Der Spiegel: Datenleck beim Volkswagen-Konzern: Wir wissen, wo dein Auto steht (27. 12. 2024)
  • Chaos Computer Club, prezentace na 38C3, Hamburg, 27. 12. 2024 (Flüpke et al.)
  • TechCrunch: Volkswagen leak exposed precise location data on thousands of vehicles across Europe for months (30. 12. 2024)
  • The Register: Data describing 800K VW EVs exposed online (6. 1. 2025)
  • BleepingComputer: Customer data from 800,000 electric cars and owners exposed online (7. 1. 2025)
  • Electrek: Massive data leak at Volkswagen exposes locations of 800,000 EV drivers, for months (30. 12. 2024)
  • Techzine: Volkswagen data breach highlights major privacy risks (30. 12. 2024)
  • Nařízení Evropského parlamentu a Rady (EU) 2016/679 (GDPR), čl. 4 odst. 5, čl. 32–34
  • Zákon č. 264/2025 Sb., o kybernetické bezpečnosti, § 14
  • Vyhláška č. 409/2025 Sb., § 9, § 12, § 13 a příloha č. 5
  • de Montjoye, Y.-A. et al.: Unique in the Crowd: The privacy bounds of human mobility (Scientific Reports, 2013)

Full name
David Martínek

Kontaktujte nás

Jsme tu pro vaše dotazy. Věříme, že společně najdeme řešení, které vám bude dávat smysl.