Hlavní navigace

DragonBlood: bezpečnostní chyba ve WPA3 umožňuje získat heslo k Wi-Fi

Sdílet

Petr Krčmář 11. 4. 2019
DragonBlood

Před rokem představený protokol WPA3, který sliboval především výrazné zlepšení bezpečnosti, už má vážnou slabinu. Dle současného trendu má samozřejmě název, logo i webovou stránku: DragonBlood. Jedná se o několik souvisejících zranitelností v samotném protokolu, které dovolují získat heslo k síti Wi-Fi.

Protokol WPA3 používá pro přihlašování handshake Dragonfly, který má lépe chránit heslo a být odolnější proti offline slovníkovým útokům. Pánové Mathy Vanhoef a Eyal Ronen však našli slabinu v implementaci WPA3-Personal, která dovoluje odhalit heslo pomocí postranních kanálů v časování a kešování.

Zároveň byl objeven downgrade attack, který umožňuje vylákat z uživatele heslo tím, že je pro něj spuštěn falešný přístupový bod s podporou oslabeného protokolu WPA2. Pro realizaci tohoto útoku ani není potřeba stát mezi obětí a pravým bodem. Stačí znát jen jeho SSID a pak ho spustit kdekoliv v oblasti, kde se oběť pohybuje.

Aby toho nebylo málo, je možné přístupový bod odstavit pomocí DoS útoku. K tomu je potřeba jej zaplavit velkým množstvím požadavků na handshake. Všechny tyto vlastnosti je možné otestovat pomocí zveřejněných skriptů:

  • Dragonslayer – útočí proti EAP-pwd
  • Dragondrain – provádí DoS pomocí handshake
  • Dragontime – provádí časovací útok proti handshake
  • Dragonforce – pomocí postranních kanálů se snaží zjistit heslo

Wi-Fi Alliance byla o problémech informována s předstihem a v tiskové zprávě potvrdila, že se na nápravě už pracuje. Oprava může proběhnout softwarově a neohrozí interoperabilitu zařízení. Záleží ovšem na jednotlivých výrobcích, kdy ji do svých zařízení implementují.

WPA3 (Wi-Fi Protected Access III) byl vytvořen jako náhrada patnáct let starého protokolu WPA2, který je považován za nebezpečný, protože je náchylný k útoku nazvanému KRACK. Další podrobnosti o útocích na WPA3 si můžete přečíst ve zveřejněné podrobné zprávě [PDF].

Našli jste v článku chybu?
  • Aktualita je stará, nové názory již nelze přidávat.
  • 11. 4. 2019 22:04

    bez přezdívky

    Mno, jmeno je odvozene od Dragonfly coz je lehce pochybny protokol od NSA na kterem je cela ta vec postavena. Mimochem ted pan co tady na tu chybu prisel od zacatku rikal ze to cele smrdi, akorat ho proste vyignorovali. Ona cela ta wifi aliance ma celkem bidny track record co se crypto tyce. Mimochodem 4way handsake vyzaduje aby na ton zarizeni existovalo heslo v plaintextu - je to cele jeden velky facepalm. Ja bych to zahodil a nahradil necim jako FIDO resp webauthen kde hesla nejsou vubec.

  • 12. 4. 2019 7:45

    Vít Šesták

    No, nezapomeňte, že typický scénář je, že se autentizují obě strany vzájemně. Obě tedy budou potřebovat nějaký secret, kterým se odliší od útočníka. Ano, šlo by to třeba ve stylu SSH, kdy každá strana má nějaký privátní klíč. Z hlediska bezpečnosti OK (a v některých případech možná i užitečné), z hlediska UX je to často overkill. Proto se spíše používá jediné heslo, kterým se autentizují AP a klient vzájemně. To ale znamená, že tím secretem bude přímo to heslo, případně něco z toho hesla odvozené (např. hash). Pokud tedy chceme zachovat původní flow, vidím tu dvě možnosti:

    a. Mít na obou stranách heslo v plaintextu.
    b. Mít (klidně na obou stranách) heslo jako hash, ale přijmout útok pass-the-hash, protože tím heslem se najednou stává hash.

    Možná by šlo vymýšlet i nějakou hybridní variantu, která by například jedné ze stran dovolila mít jen hash, ale přitom byla relativně odolná vůči pass-the-hash, ale IMHO tu nebude žádný clear win.

    Ano, je fakt, že tady je těch kompromisů více. Zejména kterýkoli oprávněný uživatel je v principu schopen spoofovat AP jinému oprávněnému uživateli.

  • 12. 4. 2019 7:29

    Vít Šesták

    Je teda problém ve specifikaci, nebo v implementaci?