Hlavní navigace

WPA3 stále zranitelná Dragonblood

Sdílet

Jan Fikar 5. 8. 2019
DragonBlood

V dubnu byla zveřejněna zranitelnost nového standardu pro Wi-Fi WPA3 s názvem Dragonblood. Wi-Fi aliance připravila dokument s bezpečnostními pokyny, jak se Dragonboold vyhnout s použitím křivek Brainpool. Bohužel toto nekonzultovala s objeviteli zranitelnosti.

Jak se nyní ukázalo, tak Brainpool křivky umožňují útok CVE-2019–13377, pomocí kterého lze hrubou silou získat heslo. Také byla objevena zranitelnost CVE-2019–13456 v implementaci EAP-pwd v FreeRADIUS . Více detailů na stránce Dragonblood.

(zdroj: slashdot)

Našli jste v článku chybu?
  • Aktualita je stará, nové názory již nelze přidávat.
  • 6. 8. 2019 9:25

    bez přezdívky

    On každý handshake posílaný do etéru bude více či méně napadnutelný. Minimálně nějaká forma DoS bude vždy možná.

    Jedině se snad dohodnout na použitém algoritmu a přenést session key z routeru do androida pomocí tužky a papíru.

  • 6. 8. 2019 16:25

    jouda_

    Tak s tím DoS to není tak pravda. Když děláte design protokolu a máte volné ruce, je tu spousta technik jak se DoSu efektivně bránit.
    Například jakmile zjistíte že se něco nekalého děje, tak můžete požadovat nějaký proof of work a pak je dos prakticky nerealizovatelný.
    Princip asi jako:
    server: dodej_pow("cli­ent_mac:abdcef", _X_)
    (uloží do tabulky client_mac -> "abcdef")
    client: pow("client_mac:ab­cdef" "qjkausjfcyrjgh")
    server udělá jeden hash lookup podle client_mac, když něco najde, tak spočítá sha256("clien­t_mac:abdcefqjkau­sjfcyrjgh") a pokud je prvních _X_ bit bitů jednička, tak teprve pak se s klientem baví dál. Pro server máte náročnost na jeden paket buď jeden lookup + jeden sha256(v řádu deseti bajtů) což je obecně rychlé, nebo jeden insert do stromu/hash tabulky/kombinace což zase nemusí mít dos potenciál, jednou za pár sekund to promažete takže ani na paměť to není problém....
    Zatímco klient musí v průměru spočítat v tomto případě 2^_X_ hashů aby ho to pustilo k výpočetně drahé autentizaci. (a tím pádem se nemusíte pak bát použít složitější autentizace, například založené na zero knowledge proofs apod.)

    (tohle neberte jako návrh protokolu, spíš jako PoC argument že to že to jde vzduchem nutně nemusí znamenat nevyhnutelný dos na protokol)

    P.S. Jasně že zarušení celého pásma nezabráníte, ale to je jiná třída útoků.

  • 7. 8. 2019 12:57

    bez přezdívky

    To je právě ten přístup, který nefunguje. A obvykle končí ještě horším DoS. Kupříkladu váš příklad mnohem zkomplikoval úplně první výměnu zpráv - ozve se nový klient a vy musíte spočítat sha256. Místo DoS typu "neodbytný klient", který už tedy nebude fungovat, to jste vyřešil, přijde DoS "tisíce nových klientů za sekundu". Navíc tam máte problémy rázem dva - tím prvním je, že díky sha256 trvá ta první odpověď mnohem déle a využívá více zdrojů routeru. Tím druhým je nutnost pamatovat si toho klienta a sha256 do doby, než odpoví. A to zabere paměť, hodně paměti. Pokud ji nemáte, tak si budete pamatovat třebas jen posledních 10 000 žádostí, starší budete zahazovat. Což je ale výborný DoS, protože když zahltíte router žádostmi z obrovského množství MAC adres, pak bude router zahazovat klíče z paměti dříve, než se poctivý klient dopočítá ke správné sha256.

    Jinak řečeno: poctivý klient by tu sha256 spočítat musel, ale podvodný klient ne, ten by jen změnil vektor útoku.

    Tohle se bohužel už párkrát povedlo i hodně velkým firmám, že obranou proti jednomu typu DoS zavlekli do systému ještě mnohem horší typ DoS. Představa, že dokážete DoS efektivně zabránit už návrhem protokolu, je dost odvážná. A obvykle to končí právě "střelením se do vlastní nohy", protože se časem přijde na to, jak obranu před DoS efektivně zneužít k DoS útoku proti uživatelům.