Internetové připojení ve vlacích českých drah útočí na HTTPS!

Pokud jezdíte ve vlacích Českých Drah a máte štěstí, připojíte se na internet prostřednictvím wifi sítě s názvem CDWiFi. Problém ale je, že některé vlaky podvrhují SSL certifikáty, a v podstatě útočí na cestující Man in the middle útokem. (Aktualizováno 22.6.2016)

Vlastní SSL

Man in the middle útok je velmi známý druh útoku, kdy se útočník dostane mezi klienta a server a vydává se za server. Jakákoliv komunikace kterou na internetu děláte je vždy „viditelná“ vašemu poskytovateli internetového připojení. Tomu většinou důvěřujete, což je ale rozhodně špatně. V každém případě nikdy nevíte, kudy data která si vyměňujete se serverem tečou a kdo do nich vidí. Nejen pro tyto účely vzniklo HTTPS a mnoho dalších SSL rozšíření internetových protokolů.

HTTPS tedy SSL/TLS nadstavba HTTP komunikace, funguje tak, že zašifruje požadavky klienta a serveru, a jediný kdo je komunikaci schopný přečíst je pak klient nebo server. Jak funguje HTTPS v tomto článku popisovat nechci. To co je ale důležité říci, že teoreticky mezi takovou komunikaci nikdo vstoupit nemůže. Teoreticky z několika důvodů:

• Šifrovaná data mohou být přečtena z důvodů chyb v aplikacích.

• Šifrovaná data mohou být z přečtena z důvodů slabých algoritmů, nebo klíčů.

• Šifrovaná komunikace je podmíněna důvěrou v certifikáty.

První dva body ovlivní klient hůře. Závisí na konfiguraci serveru, stáří serverové i klientské aplikace a stáří, resp. stavu operačních systémů u klienta i na serveru. Lepší algoritmy, resp. silnější klíče je možné vynutit v podstatě jen tlakem na autory aplikací a provozovatele webu.

Poslední komunikace je kámen úrazu, kterého internetové připojení ve vlacích Českých Drah zneužívá. A týká se problému SSL certifikátů jako takových. Do nedávna se SSL certifikáty daly rozdělit na drahé, ještě dražší a zdarma. S tím že ty zdarma, kterých je na internetu zřejmě zatím většina, jsou generovány různými neznámými autoritami.

SSL rozlišuje mezi několika různými certifikáty. Pomineme-li ty, které slouží k ověření serverů, vydavatelů softwaru a lidí, dali by se rozdělit na certifikační autority a certifikáty. Komerční certifikáty, ty drahé, jsou vydávány společnostmi, které za certifikát očekávají výdělek. Ovšem, na oplátku zákazník, majitel certifikátu, něco získá. Je lustrován, zda je opravdu majitel domény, a má právo takový certifikát dostat. Tím certifikační autorita splňuje kritéria, která jí zjednodušeně řečeno umožňují stát se součástí systémů a prohlížečů.

Právě certifikáty certifikačních autorit, jsou součástí operačních systémů a aplikací. V takovém případě daná aplikace, např. webový prohlížeč, automaticky důvěřuje certifikátům vydaných (ověřených) právě touho certifikační autoritou. Celý systém je o něco složitější, ale v podstatě to takto funguje. Pokud ovšem nechce majitel webu platit takovéto certifikační autoritě, často nemalé částky za certifikát, má ještě další možnosti. Vytvoří si vlastní certifikační autoritu, ovšem o té nikdo neví, a jediný způsob jak ji korektně používat, je importovat ji do systémů (aplikací) všech uživatelů webu. Druhá možnost je použít nějakou certifikační autoritu, která vydává certifikáty zdarma, ovšem, jediným bonusem je naděje, že díky rozšířenosti certifikační autority, ji bude uživatel webu mít již importovanou. Poslední relativně čerstvou možností je mít certifikát ověřený certifikační autoritou Let's Encrypt, která od loňského roku umožňuje automaticky vytvořit, resp. aktualizovat certifikáty pro webové servery a to zcela zdarma. Certifikáty jsou podepsané certifikační autoritou, která je podepsána takovými autoritami, které se již ve většině systémů nebo browserů nachází.

Díky tomto slabému místu, jsou uživatelé bohužel zvyklí, ignorovat chyby týkající se schválení nedůvěryhodného certifikátu. Ovšem těch chyb stran ověření certifikátu je několik. První se týká samotné nedůvěry v certifikační autoritu, která certifikát ověřila. Druhá se týká vypršení platnosti certifikátu. A třetí neshody domény, na kterou uživatel přistupuje a domény uvedené v certifikátu. Všechny tyto tři chyby je důležité brát vážně. A jak je vidět na snímcích obrazovky, chyby na které jsem byl upozorněn, byly právě ty poslední.

Vlastní certifikát

Nějaká proxy, říkejme ji temná, která je mezi cestujícím některých vozů českých drah, podvrhuje certifikát pro jednotlivé domény. Pokud se tedy cestující pokusí navštívit stránku, která je zabezpečená SSL certifikátem, dojde k tomu, že se dotyčná proxy u ČD pokusí cestujícímu podstrčit vlastní certifikát. Pokud by jej cestující schválil, došlo by k tomu, že šifrovaná data budou chodit od cestujícího k této temné proxy, tam budou plně čitelná, a dále budou šifrovaná mezi proxy a opravdovým webem.

Tato temná proxy se tedy pokouší vydávat za server někde v internetu. A díky tomu, že uživatelé jsou bohužel zvyklí ignorovat bezpečností chyby, často se stane, že této temné proxy předají své přihlašovací údaje do mailu, banky, cloudu, eshopu, Facebooku či jakéhokoli jiného systému kdesi v internetu.

Takto vypadá certifikát získaný v některých vlacích ČD. Soubor certifikátu je zazipovaný, aby jej laskavý čtenář hůře importoval do svého systému.

Vyjádření

Soudě podle nedostupnosti stránek, na doméně, ke které byl certifikát vydán, a výpisu z whois usuzuji, že domény byla zaregistrovaná právě pro vytvoření certifikátu, jejímž jediným účelem je Man in Middle útok na HTTPS komunikaci. Na tento text byly také upozorněny České Dráhy následujícím mailem. Případná reakce bude následně uveřejněna:

Dobrý den,

v některých Vašich vlacích, naposledy to bylo v druhém vagóně ve vlaku IC 561 Šohaj z Prahy do Veselí nad Moravou odjíždějícího 4.4.2016 v 17:24 z Prahy, dochází k pokusu o odposlouchávání zabezpečené HTTP komunikace prostřednictvím Vaší wifi CDWiFi. Veškerá HTTPS komunikace je zprostředkovávána proxy službou, která vydává svůj vlastní certifikát patřící doméně www.ombord.info.

O tuto zkutečnost jsem se podělil prostřednictvím článku na mém blogu na adrese https://zeropage.cz/a/internetove_pripojeni_ve_vlacich_ceskych_drah_utoci_na_https

Proto Vás tímto prosím o vyjádření k celé situaci. Vaše odpověď bude v článku uveřejněna také.

S pozdravem

--

Ondřej Tůma <mcbig@zeropage.cz>

Na odpověď jsem si musel chvíli počkat, nicméně dočkal jsem se ji. Bohužel se do celé věci musela vložit ještě další osoba, novinářka z České Televize Dagmar Klimovičová. Zřejmě jen díky ní, se celou věcí začali České, a jak jsem zjistil i Slovenské dráhy zabývat. Nakonec se to jeví, že se mi jen podařilo trefit na nějakého útočníka po cestě:

Vážený pane Tůmo,

odpovídám na Vaši stížnost ve věci pokusu o odposlouchávání zabezpečené HTTP komunikace prostřednictvím WiFi s SSID CDWiFi ve vlaku IC 561 Šohaj z Prahy do Veselí nad Moravou odjezd 4. 4. 2016 17:24 z Prahy.

Omlouvám se za opakování některých informací, které již víte z Vaší komunikace s paní redaktorkou Klimovičovou, které na její dotaz odpovídalo naše tiskové oddělení.

V uvedeném vlaku byly řazeny vozy slovenské společnosti ZSSK, která v nich poskytuje svou WiFi. ČD v tomto vlaku svou síť WiFi neměla.

Dále doplňuji ze stanoviska ZSSK informaci, že WiFi Access Pointy v uvedeném vlaku nemají MAC adresu, která je uvedena ve Vašem článku na zeropage.cz, a nebyly zaznamenány pokusy o získání přístupu k aktivním prvkům poskytujícím WiFi ve vozech ZSSK v uvedeném vlaku.

Z uvedených skutečností vyvozuji, že se s největší pravděpodobností jednalo o falešný Access Point s účelově uvedeným SSID CDWiFi a nelze ani spoléhat na to, že MAC adresa byla reálná.

Uvedený odposlech nebo pokus o odposlech nemá spojitost s činností ČD a poskytováním WiFi sítě ve vlacích ČD.

Pokud by z dat, která máte k dispozici, vyplynuly ještě nějaké další informace, které by pomohly objasnit tento případ, uvítám jejich zaslání.

S pozdravem

Ing. Vladimír Valda

systémový specialista

České dráhy, a.s., Generální ředitelství

Kancelář předsedy představenstva | Oddělení bezpečnosti a nouzového plánování

nábřeží Ludvíka Svobody 1222/12, 110 15 Praha 1

Od té doby se mi podařilo získat další nové informace, tedy odpovídám na mail:

Dobrý den,

podařilo se mi získat nějaké další informace, které Vám tímto zasílám.

"Nakaženou" wifi mají různé vlaky, které stojí na Hlavním nádraží v Praze. Toto jsem vysledoval tak, že jsem mnohokrát od popsaného incidentu detekoval podvržený HTTPS certifikát, bohužel ve vlaku jsem přímo neseděl, a tak jsem neměl čas získat nějaké další informace.

Dnes 22.6.2016 v 6:35 jsem měl to štěstí, že jsem notebook nevypnul po příjezdu na Hlavní nádraží, a tak, po tom co jsem si všiml nakažené wifi, jsem získal alespoň pár další informací. Stačí ale zajít na Hlavní nádraží a věřím že během jediného dne takových incidentů zjistíte dostatek. Podezření mám i na vlak Pendolino, neboť jsem jednou o nakaženou wifi přišel právě po odjezdu Pendolina z Prahy, Hlavního nádraží.

K informacím:

wlan0     IEEE 802.11abgn  ESSID:"CDWiFi"
          Mode:Managed  Frequency:2.412 GHz  Access Point: F4:EA:67:12:3F:30
          Bit Rate=26 Mb/s   Tx-Power=16 dBm
          Retry short limit:7   RTS thr:off   Fragment thr:off

Má získaná adresa byla 10.0.1.17, s tím že brána byla 10.0.1.254.

Na zařízení (bráně) běží služby v těchto verzích:

22/tcp  open   ssh      Dropbear sshd 2012.55 (protocol 2.0)
80/tcp  open   http     lighttpd 1.4.31
443/tcp open   ssl/http lighttpd 1.4.31

Operační systém Linux, jeho verzi však neznám.

Lighttpd na tomto zařízení přesměrovává na adresu http://10.0.0.60, na které běží palubní intranet, stránka s nadpisem Vítejte na palubě, tlačítkem pokračovat a checkboxem pro odsouhlasení podmínek používání wifi.

S pozdravem Ondřej Tůma

Fakta na závěr

Na závěr je třeba říci, že toto se neděje ve všech vlacích ČD. Jednak se v některých ani na internet nepřipojíte, a pak v některých zdá se vše funguje tak jak má, alespoň co se HTTPS týče. Tento případ, který jsem nezaznamenal poprvé. Naposled se stal ve vlaku IC 561 Šohaj z Prahy do Veselí nad Moravou odjíždějícího 4.4.2016 v 17:24 z Prahy, v druhém vagónu. AP mělo MAC adresu a4:18:75:02:36:30. Vzhledem k tomu, že jsem patřil mezi první cestující, je nepravděpodobné, že by šlo o podvržené připojení nějakého spolucestujícího - hackera, vyloučit to však nelze.