Hlavní navigace

POODLE útok na SSLv3

20. 10. 2014
Doba čtení: 3 minuty

Sdílet

POODLE je nový útok na SSL verzi 3, umožňující dešifrovat komunikaci aktivním útočníkem. V ideálním světě by POODLE byl jenom kuriozitou obstarožního protokolu, ale SSL verze 3 se dosud kvůli zpětné kompatibilitě používá. Možná je tento útok připomínkou, aby se již od SSL3 definitivně upustilo.

Nový týden, nová zranitelnost v SSL. Je známou věcí, že útoky se pouze zlepšují a nikdy nezhoršují – ovšem, jak se zdá, už to neplatí o jejich jménech. Jméno POODLE je backronym z Padding Oracle On Downgraded Legacy Encryption a podobá se mírně staršímu BEAST, což je také útok založený na padding oracle dotýkající se šifrování v CBC módu.

Útok vyžaduje:

  • útočník musí být aktivní man-in-the-middle s možností měnit pakety
  • oběť musí spustit útočníkův javascript, který bude generovat HTTPS dotazy

Útok by teoreticky fungoval i proti jiným SSL/TLS klientům než je prohlížeč, ale bylo by potřeba místo javascriptu najít jiný způsob, jak generovat požadavky se specifickou strukturou.

Použiji příklad od Adama Langleyho – budeme uvažovat blokovou šifru o velikosti bloku 8 bajtů. Předtím, než se plaintext zašifruje, přidá se MAC a nakonec padding (což je několik bajtů) a to tak, aby zpráva byla velikosti násobku bloku. Padding je vždy přítomen. Před zašifrováním to bude vypadat následovně:

GET request rozdělený na bloky

Úplně poslední bajt v paddingu s hodnotou 7 říká, že před ním je 7 bajtů, které nepatří do zprávy, ale jsou tam jen jako „výplň“. Na jejich hodnotě nezáleží, což je podstatné, protože bez toho by útok nefungoval (zde se to liší od TLS, kde jsou v paddingu vyžadovány specifické hodnoty). Jak se v CBC módu dešifruje, si připomeňme diagramem z Wikipedie:

CBC dešifrování

Důležité je, že útočník musí vědět, kde v plaintextu se nachází cookie, kterou chce dešifrovat a ukrást, i když správu rozšifrovat ještě neumí. Ví, že v tomto případě se nachází ve čtvrtém bloku. V momentě, kdy oběť odesílá šifrovaný požadavek, vezme čtvrtý blok a zkopíruje ho na místo posledního bloku, který šifroval padding.

Co získá útočník nahrazením původního posledního bloku? S největší pravděpodobností dojde k chybě při dešifrování, protože „nový poslední bajt“ bude nějaké nesmyslné číslo – pozná se to podle toho, že se spojení ukončí. Trik spočívá v případu, kdy se útočníkovi povede trefit, aby poslední bajt po dešifrování posledního bloku byl opět původních 7. To se statisticky povede v jednom případě z 256. K tomu slouží ten zmiňovaný javascript, aby opakovaně generoval požadavky, dokud nenastane tento případ.

Teď útočník ví z konstrukce CBC dešifrování, že poslední bajt z dešifrovaného duplikovaného cookie bloku, xorován s posledním bajtem předposledního šifrovaného bloku, je roven 7. Z tohoto už dokáže dopočítat poslední bajt cookie.

Další bajty cookie dostane podobným způsobem: stačí, aby se v požadavku o jeden bajt prodloužila cesta, tak aby se na hranici bloku dostal další bajt z cookie na dešifrování:

GET request posunut

V praxi by bylo asi lepší používat POST požadavky, protože pomocí parametrů se snáze ovládá počet bajtů za cookie, tak aby data nepřetekla do padding bloku.

root_podpora

Jako nejlepší obrana proti POODLE je zjevně vypnutí podpory SSL3. U dvou nejběžnějších serverů Apache a nginx se podpora vypíná následovně v jejich konfiguračních souborech:

Apache:

SSLProtocol All -SSLv2 -SSLv3 

nginx:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2; 

Existuje i mechanismus SCSV, který má zabránit downgrade útoku. I když draft není kompletní, Chrome a poslední Firefox ho už implementuje. Podpora na straně serverů vyžaduje poslední openssl, aby ji servery jako Apache a nginx mohly využít.

Byl pro vás článek přínosný?

Autor článku

Autor textu pracuje jako programátor pro výzkum a vývoj v Laboratořích CZ.NIC, výzkumném a vývojovém centru správce české národní domény.