Názory k článku Heartbleed Bug: jak se k chybě v OpenSSL staví české i světové firmy
Článek je starý, nové názory již nelze přidávat.
-
Netrápí je proto, protože zranitelnost je dána kódem na serveru, nikoli obsahem hlavičky, kterou server vrací. A kód zpracovávající SSL je na klient1 až klient4.rb.cz v pořádku.
Je možné, že hlavička vracená serverem je vymyšlená a server je něco úplně jiného. Je možné, že před serverem je nějaká brána, na které je SSL zakončeno. Je možné, že mají na serveru OpenSSL 1.0.1e s patchem. Je možné, že mají na serveru OpenSSL 1.0.1e s vypnutým heartbeats. Vzhledem k tomu, že servery mají čerstvé certifikáty, tipoval bych si, že servery postižené byly a platí tedy některá z variant s opravenou verzí 1.0.1e.
-
Michal (neregistrovaný) 109.159.232.---
Když jsem se o téhle chybě dočetl na BBC, tak jsem šel na Lupu, kde jsem čekal nějaký detailnější rozbor, ale nenašel jsem nic. Postupně se objevil předchozí i tenhle článek. Oba mě ale dost zklamaly, protože takovýhle článek bych čekal spíše na IDNES, než na Lupě.
Technických detailů je pomálu, vlastně jen "Chyba v knihovně OpenSSL, ..., teoreticky umožňuje odposlechnutí zašifrovaných údajů – včetně například privátních klíčů." a v předchozím článku "Chyba umožňuje útočníkům bez omezení číst údaje zašifrované přes SSL/TSL – včetně například privátních klíčů a dalších dat."
Tenhle popis je ale nejen dost neurčitý, ale IMO prostě chybný, protože podle https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160 chyba není o "odposlechnutí zašifrovaných údajů", ale o možnosti nechat si posílat úseky z paměti serveru, na který se útočník připojí. To znamená číst údaje, které nikdy nebyly přes SSL spojení přeneseny (a ani nemusí být zašifrované). To znamená leccos, co má zrovna server v paměti, což mohou být např. jeho privátní klíče. Což je něco dost jiného, než odposlech šifrované komunikace.
-
mc (neregistrovaný) 188.175.65.---
Pokud získáte privátní klíč serveru, můžete pak komunikaci odposlouchávat a to dokonce i včase, když už je server zaplátován (pokud nezměnil klíč a nezneplatnil předchozí certifikát).
Nicméně souhlasím, že bych čekal větší rozbor.
Tahle chyba mi připadá opravdu gigantická. Dokonce paradoxně se dá říci, že servery, které nepoužívají šifrování jsou snad na tom líp. Přece jen odposlouchávat komunikaci nemůže každý (je nutné například být někde na cestě komunikace, či je nutné použít techniky, které tok nasměřují přes Vás, ale to nemusí být obecně jednoduché).
Zde ovšem došlo k šílené věci. Bylo možné si číst v paměti serveru a získávat hesla (protože server rád poskytl segmenty paměti). Navíc je to zpětně téměř nedohledatelné, že někdo něco takového dělal. Tohle je snad sen NSA.
-
Ta otázka přece stojí jinak, běží naše banky na open source? Skoro určitě ne, a pravděpodobně vůbec nejedou na platformách kde se OpenSSL používá. Takže soráč, to co možná napadlo statisíce škudlilů co jedou na Linuxu nebo open source knihovnách ve Windows, to se velkých seriózní společnosti vůbec nemuselo dotknout...
-
Mají vydaný čerstvý certifikát, takže chybou asi postiženi byli. Pokud se přihlašujete privátním klíčem, není čeho se bát. Pokud jednorázovým heslem, záleží na implementaci – ale i kdyby se používalo symetrické šifrování a klíč pro jednorázové heslo byl v paměti serveru, je extrémně nepravděpodobné, že by jej útočník získal a dokázal rozpoznat.
-
Zen (neregistrovaný) ---.eurotel.cz
Dobry rozbor je na http://www.root.cz/clanky/heartbleed-bug-vazna-zranitelnost-v-openssl/
-
Dle https://www.openssl.org/news/secadv_20140407.txt
může odposlouchávající útočník získat data nejen ze serveru, ale i klienta.Stále mi není jasný princip chyby. Dle jednoho z výše uvedených komentářů nejde prvoplánově o rozšifrování odposlouchávaného spojení, ale o vyžádání si dat z paměti serveru i klienta - což může/nemusí vést (až následně) k získání priv. klíče a k rozkódování komunikace.
Mám tomu rozumět tak, že útočník může zasáhnout do komunikace KTERÉ NEROZUMÍ - zasláním nějakého TLS "příkazu" - a získat data z paměti ?
A teď k titulku: co když server bude záplatován a klient nikoli ?
Co může útočník získat ? Nic ? Nebo data z paměti klienta - čili typicky datový blok z prohlížeče (který např. může obsahovat priv. klíče certifikátů, hesla, ... ? -
??? - jak to, že "blbě". Chápu to stejně. Tedy dle http://www.root.cz/clanky/heartbleed-bug-vazna-zranitelnost-v-openssl/
-
Jirka (neregistrovaný) 2a00:1028:8d1e:----:----:----:----:----
Takto blbě:
> A jelikož zprávy TLS heartbeat jsou přenášeny uvnitř šifr. kanálu, tak (snad ?!) padá riziko odposlechu (útok MITM).
Ne, každé spojení k danému serveru může útočník odposlouchávat (i když to není 100%). S nějakým šifrovaným kanálem chyba nijak nesouvisí. Navíc, pokud se útočníkovi podaří ukrást ze serveru certifikát a klíče, může klidně udělat MITM.
> Tedy útok na klienta může vést "jen" server v rámci navázaného spojení.
Ano v úzkém smyslu, že paměť klienta si může přečíst jen server. Nicméně je otázka, co by tam asi hledal - jak poznamenal někdo v příspěvku nade mnou. Většinu klientova tajemství stejně najdete buď ve spojení, nebo rovnou na serveru.
Pokud to berete v širším smyslu, že Eva útočí na Frantu Pepu Jedničku a chce si přečíst jeho maily, opět nemáte pravdu
-
V paměti internetového prohlížeče, kde je na jedné záložce otevřený webmail, na druhé elektronické bankovnictví a na třetí stránka se vtipným videem by se ten server s vtipným videem mohl dozvědět zajímavé věci. Naštěstí žádný běžně používaný webový prohlížeč OpenSSL nepoužívá, moderní prohlížeče navíc používají systém jedna záložka - jeden proces.
-
Milos (neregistrovaný) ---.cust.nbox.cz
Česká firma Lamantine, která vytvořila Sticky Password, napsala o té chybě článek na svém blogu - http://blogen.stickypassword.com/sticky-password-and-the-heartbleed-bug/
Přiznám se, že jiné české firmy, které by se k chybě nějak vyjádřily nevím.
-
Milos (neregistrovaný) ---.cust.nbox.cz
Česká firma Lamantine, která vytvořila Sticky Password, napsala o té chybě článek na svém blogu - http://blogen.stickypassword.com/sticky-password-and-the-heartbleed-bug/
Přiznám se, že jiné české firmy, které by se k chybě nějak vyjádřily nevím.
-
W (neregistrovaný) 85.93.112.---
To co píšete dává smysl a doufejme, že to tak je. Nicméně bych si asi vyloučil to, že je hlavička vymyšlená,.. než by si jí někdo vymýšlel, tak by ji spíše neposílal vůbec... Když už, tak je asi pravděpodobný ten patch, ale v případě patchů bych čekal, že se to dost možná projeví nějakou příponou ve verzi, což se automaticky projeví i v odesílané hlavičce (pokud jak píšete si ji někdo záměrně nevymýšlí), ale to může a nemusí být.
-
Koukám, minimálně jeden ten test je k ničemu.
Mě to hlásíServer software: Not reported
Vulnerable: Possibly (might use OpenSSL)
SSL Certificate: Possibly Unsafe (created 7 months ago at Sep 2 10:35:43 2013 GMT)
Assessment: Wait for the site to update before changing your passwordPřitom jsem tam nikdy neměl postiženou verzi a to OpenSSL je hodně ořezaný.
https://www.ssllabs.com/ssltest/ tenhle test mi příjde věrohodnější.
-
Jirka (neregistrovaný) 2a00:1028:8d1e:----:----:----:----:----
Ne, chápete to úplně blbě.
Jen v rychlosti jak to všechno funguje: Někdo se spojí se serverem a pošle mu zprávu (zašifrovanou) "Ahoj, já jsem Franta Pepa Jednička a mám heslo Sisi." Někdo jiný se taky připojí a pošle zprávu "Ahoj, já jsem Mařka Terezka a mám heslo František." No a útočník se taky připojí, jako by chtěl poslat "Ahoj, já jsem Eva a mám heslo Adam," ale to je úplně nedůležité, útok proběhne i bez toho.
Dúležitý je, že tihle tři se sejdou u jednoho serveru, v jednom procesu - z výkonnostních důvodů je prakticky vyloučeno aby každý měl proces pro sebe (i v případě, že je možno připojit se na více serverů, se v jednom procesu obsluhuje víc klientů). V paměti tohohle procesu budou aspoň po nějakou dobu zprávy od klientů v plaintextu, aby podle nich mohl server odpovědět (odpovědi tam budou samozřejmě také). No a v případě, že Eva má štěstí (kterému může jít hodně naproti), tak heartbleed útokem získá ze serveru právě tyto zprávy s hesly Franty Pepy Jedničky a Mařky Terezky (prostě proto, že ty zprávy můžou být v paměti hned vedle sebe). To znamená, že může částečně odposlouchávat cizí spojení tím, že se dívá serveru pod ruce.
Jinak přemýšlet o této chybě v souvislosti s šifrovanými kanály, SSL a kryptografií je spíš zavádějící. Ve skutečnosti je to obyčejná (bezpečnostní) programátorská chyba, kterých bylo, je, a bude neurékom. Ta závažnost je daná tím, že k ssl serveru se připojit a chybu tak využít může každý. Ale v principu je to podobný, jako bezpečnostní chyby např. v Apachi, PHP, ....
-
... no sorry - teď jsem si teprve přečetl též odkazovaný http://www.root.cz/clanky/heartbleed-bug-vazna-zranitelnost-v-openssl/ , jež je vice méně odpovědí. Moje chyba.
A jelikož zprávy TLS heartbeat jsou přenášeny uvnitř šifr. kanálu, tak (snad ?!) padá riziko odposlechu (útok MITM).
Tedy útok na klienta může vést "jen" server v rámci navázaného spojení.Right ?
-
Není potřeba doufat, že mají servery tuto chybu opravenou si můžete sám snadno ověřit.
Pokud se použije opatchovaný distribuční balíček, zvýší se jen číslo distribučního updatu (třeba to deb7u6). Verze aplikace se ale samozřejmě změnit nemůže (byl aplikován jen ten jeden patch, nebyly provedeny všechny změny v dané verzi). Tohle číslo distribučního updatu se pak ani nemusí objevit v informaci o verzi, kterou o sobě poskytuje sám program (takže třeba Apache se od OpenSSL může dozvědět jen 1.0.1e, že má Debian ve verzi balíčku ještě -deb7u6 už se nedozví). Pokud by si administrátoři záplatu aplikovali sami, asi nebudou s číslem verze dělat vůbec nic. No a pokud jenom vypnuli při konfiguraci heartbeat, mohou klidně používat původní nezáplatovanou verzi 1.0.1e. Pokud si OpenSSL kompilují sami, připadá mi ta poslední varianta nejbezpečnější.
-
Útok lze vést jen v rámci spojení, ale je k tomu příležitost velmi brzy při navazování spojení, takže třeba (pokud vím) i když server vyžaduje přihlášení klientským certifikátem, k útoku může dojít dřív, než je to přihlášení vyžádáno. Útok na klienta tedy může přijít jen od serveru, ke kterému je klient připojen.
Útok pak spočívá v tom, že je možné z druhé strany přenést kus paměti procesu, ve kterém je SSL spojení navázáno. V té paměti může být ledacos – třeba komunikace z jiných spojení, ve které mohou být citlivé údaje. Z tohoto pohledu je to horší, než MITM útok – při MITM musí být útočník na trase mezi vámi a serverem, v případě heartbleed může být úplně kdekoli a tu komunikaci si přečte z paměti serveru. Jediné štěstí je, že si oblast paměti nemůže vybírat, ale dostane ten kus paměti, který zrovna sousedí s místem, kam se do paměti zapíše útočníkův požadavek.
Jinak Firefox, Chrome ani Internet Explorer OpenSSL nepoužívají, takže tam nebezpečí nehrozí. Z rozšířenějších protokolů pak připadá v úvahu útok na poštovního klienta nebo VPN klienta – pořád ale záleží na tom, zda ten program používá OpenSSL v postižené verzi. A další věc je, že případný útočící poštovní nebo VPN server se z klienta nejspíš nedozví nic, co by mu klient dříve neposlal dobrovolně. Riziko by bylo jen při používání většího množství účtů, kdy by se server mohl dozvědět něco patřícího pod ostatní účty.
-
Jarda Kuba (neregistrovaný) ---.200.broadband10.iol.cz
Mě zase trochu mrzí, že na Lupě (v době psaní tohoto příspěvku) není ani čárka o posledních rozsudcích soudu v EU o data retention a výpalném za cd/dvd/usb atd., na což navazuje i další důležitá informace o stahování autorsky chráněných děl pro vlastní potřebu z nelegálního zdroje. Chlapci, vstávat, cvičit a psát, už jste předvedli, že psát umíte, tak hurá do toho! :-)
-
- Quality Assurance Specialist
- Administrátor/Linux/Windows/Networking
- C++ vývojář
- Senior C++ Developer
- C++ Developer
- Junior Online Specialist
-
- Prokreslete se k úspěšné prezentaci
- Seznamy na SharePointu 1: vytvářejte seznamy a sloupce
- Vše, co jste kdy chtěli vědět o anglických časech II
- Firma a rodina jako kmen
- Logické funkce v Excel
- Úvod do G Suite - bezpečnost v cloudu, hesla a Chrome
-
- TŘEBÍČ - instalace internetových přípojek, home-office
- Administrátor/Linux/Windows/Networking
- C++ vývojář
- C++ Developer
- Jednoduchý prodej po telefonu
- Integrační vývojář
-
- Cesta k dobrému jazykovému stylu II
- Seznamy na SharePointu 1: vytvářejte seznamy a sloupce
- Firma a rodina jako kmen
- Logické funkce v Excel
- Úvod do G Suite - bezpečnost v cloudu, hesla a Chrome
- Microsoft Teams 3: sdílené soubory
