Jaké certifikáty OpenSSL musíme odvolat?

Aktuálním problémem mnoha administrátorů Linuxu se stala bezpečnostní chyba v OpenSSL známá jako Chyba krvácejícího srdce. Provedli aktualizace software, nahradili a případně i odvolali Heartbleed openssl bug vector shapecertifikáty na webových serverech. Postup ve složitějších případech, jako použití certifikátů v OpenVPN, již není tak jasný. Pokusím se v tomto článku tuto problematiku trochu přiblížit.

 

Vycházím ze stavu, kdy máte OpenSSL již aktualizováno na verzi, která není zranitelná. V tuto chvíli je pro mnohé administrátory Linuxu otázkou, jak přesně postupovat dále.

Je přirozené, že tento problém je aktuálně velice diskutovaný. Ale ono je těch problémů více. Když pomineme možnosti lokálních útoků, které jsou také možné, jak jsem byl upozorněn, jsou tu problémy dva. Každý souvisí s jiným nebezpečím, které chyba OpenSSL přinesla.

Nebezpečí vyplývající ze zranitelnosti OpenSSL

  1. Primární nebezpečí – zneužití ukradených klíčů kompromitovaných certifikátů k utajenému rozkrytí aktuální legitimní komunikace
  2. Sekundární nebezpečí – zneužití ukradených klíčů k dalším druhům útoků, jako např MITM, vylákání přístupových údajů klienta apod.

Primárně je nutné řešit nebezpečí číslo 1. Důvody jsou následující:

  • Rozkrytí komunikace považované za privátní tímto způsobem je zcela skryté, nelze je odhalit
  • Lze jej velice snadno realizovat
  • Může probíhat po dlouhou dobu
  • Může způsobit kompromitaci dalších dat, které jsou nebo v minulosti byly tímto kanálem přenášeny jako privátní
  • Problémy 2. typu jsou za tohoto stavu neřešitelné

Řešení je velice jenoduché:

Neprodleně přestaňte používat potenciálně kompromitované certifikáty. To je asi všem vcelku jasné. Které certifikáty ale to vlastně jsou?

Zranitelné certifikáty

Jsou to ty certifikáty, které byly používány pro zabezpečení komunikace v době, kdy OpenVPN byla dynamicky slinkována se zranitelnými verzemi OpenSSL. Napadnuta mohla být strana serveru i klienta.

Klíč a certifikát certifikační autority by kompromitován být neměl, ani když se nachází na serveru, co používal zranitelnou verzi OpenSSL. Nebyl totiž používán k externí komunikaci. Ale je ale třeba zvážit možnost sekundární kompromitace certifikační autority.

Je kompromitován i klíč mojí certifikační autority?

Jako příklad mohu uvést příklad, kdy jste v minulosti pracovali přes VPN. Ta využívala zranitelnou verzí OpenSSL. A vy jste pracovali s vlastní certifikační autoritou. Generovali jste například certifikáty nebo kontrolovali obsah souboru s klíčem certifikační autority. Používali jste třeba VNC.

Nebezpečí je sice v reálu malé, protože útok je komplikovaný. Stále tu ale existuje možnost kompromitace autority. Předpokladem je, že útočník:

  • Má zaznamenanou v minulosti zachycenou komunikaci VPN
  • Dříve než jste provedl aktualizaci, povedlo se mu pomocí zneužití chyby v OpenSSL získat privátní klíč serveru nebo klienta
  • Dešifruje s ním historickou komunikaci
  • Provede analýzu komunikace a úspěšně zaútočí na nedostatečně zabezpečenou komunikaci (zde VNC)
  • Získá z ní informaci o privátním klíči vaší certifikační autority

Je to postup hodně přitažený za vlasy, to uznávám. Ale je teoreticky možný. Zamyslete se nad úlohami, které jste prováděli skrz zranitelnou VPN. Pokud jste bez další úrovně silné kryprografické ochrany dělali v minulosti cokoli, může to být rozkryto.

Bezpečná je například správa serveru pomocí SSH. Nebezpečná je správa routeru telnetem, kdy jste spoléhali na ochranu šifrovaným kanálem VPN.

To jsou extrémní případy. Obvykle budete někde mezi. Například, připojení vzdálenou plochou může být bezpečné i zcela nebezpečné, podle nastavení, verzí klienta i serveru.

Jako správce Linux serverů s dlouhou praxí jsem dost paranoidní, ale ani já jsem v praxi neřešil bezpečnost přístupu vzdálenou plochou, pokud komunikace procházela VPN. Teď je ale najednou nutné se nad tímto problémem zamýšlet.

Platí zde základní pravidlo: Máte-li pochyby, jestli přístupové údaje mohly být zachyceny, změňte hesla!

Nyní k postupům pro konkrétní aplikace. U webového serveru je to relativně jednoduché:

Řešení pro HTTPS server

Pro stranu serveru vygenerujete nový klíč a požadavek na certifikát. Vaší certifikační autoritou vytvoříte nový certifikát. Starý certifikát pomocí certifikační autority revokujete a vystavite revokační certifikát pro klienty. Upozorníte je na něj a budete doufat, že si jej opravdu naimportují. Poté již nebude možné ukradený klíč s certifikátem u těchto klientů zneužít.

Poznámka: Dejte revokačnímu cerifikátu příponu CRL. Klienti s MS Windows potom certifikát naimportují bez problémů.

Řešení pro OpenVPN server

Pokud spravujete OpenVPN, je třeba v případě užívání zranitelných verzí OpenSSL nahradit certifikát systému, který byl použit v době, kdy byla OpenVPN slinkována se zranitelnou verzí OpenSSL.

Týká se to serverů i klientů. Dle zdroje https://community.openvpn.net/openvpn/wiki/heartbleed se MS Windows klientů problém zřejmě bude týkat jen minimálně. Pouze u verzí OpenVPN 2.3-rc2-I001 až 2.3.2-I003. Verze 2.3.2-I004 má chybu již opravenu.

Opět je ale třeba mít na paměti i možnost jejich sekundární kompromitace. Ptejme se, jak byly privátní klíče distribuovány. Se zašiftovanými klíči? Potom je vše v pořádku. S volně dostupnými klíči skrz VPN? Tady to v pořádku být nemusí. Naštěstí je dnes standardně užívána ta první možnost.

Starý serverový certifikát pomocí certifikační autority revokujte a vygenerujte aktuální revokační certifikát.

Je vhodné jej dodat klientům (do adresáře config) a v konfiguraci
klientů, pokud ho tam už nemáte, přidat následující parametr:

crl-verify jmeno_revokačního_certifikátu.crl

Strana klienta potom odmítne spojení se serverem, pokud se bude snažít nabízet pro komunikaci revokovaný certifikát. Útoky typu 2 (jak jsem psal výše) budou tímto prakticky znemožněny.

Minimum z OpenSSL

To je prozatím vše. Napadlo mě, že bych pro ty, co s OpenSSL nemají moc zkušeností, připravil jakési Minimum pro práci s OpenSSL. Před mnoha roky jsem pro kolegy připravoval na toto téma interní manuál. Během víkendu ho aktualizuji a doplním o popis postupů, které aktuálně potřebujete při výměně certifikátů.

Těším se na vaše komentáře.

 

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna.