14:10
17/10/2017

Wczoraj przez internet przetoczyła się fala paniki i ostrzeżeń, że “wszystkie sieci Wi-Fi zostały zhackowane” i że w ogóle koniec świata. Poniżej przedstawiamy szczegółową analizę ujawnionego wczoraj ataku o nazwie KRACK i wskazujemy kto (i jak bardzo) powinien się obawiać. W skrócie: problem jest poważny, ale możliwość wykorzystania go do przeprowadzenia dotkliwego ataku jest bardzo ograniczona.

KRACK: Key Reinstallation Attacks, czyli atak na WPA2

KRACK został odkryty i ujawniony przez Mathy’ego Vanhoefa. Szczegóły zostały opublikowane na dedykowanej stronie internetowej i towarzyszącej jej pracy naukowej. Jak przystało na współczesną podatność dotykającą sporą rzesze użytkowników, KRACK ma swoje logo:

W praktyce, atak wygląda tak jak na poniższym filmie i w jednym z wariantów pozwala na podsłuchiwanie danych przesyłanych przez urządzenia korzystające z internetu poprzez sieć WPA2 bez konieczności znajomości hasła do niniejszej sieci:

Zanim opiszemy na czym dokładnie atak polega, chcieliśmy Was uspokoić — to nie jest “internetowa apokalipsa“, jak przedstawiają to niektórzy. Bo choć atak faktycznie dotyczy prawie wszystkich urządzeń korzystających z Wi-Fi w standardzie 802.11i (czyli WPA2), to aby przeprowadzić udany atak, spełnione muszą być te warunki:

  • 1. Atakujący musi być w zasięgu sieci Wi-Fi którą atakuje, przy czym nie ma znaczenia czy sieć to WPA, WPA2 i czy skonfigurowana jako personal czy enterprise. Ktoś musi więc podejść pod drzwi Waszego mieszkania albo zaparkować czarnym wanem przed Waszym domem.
  • 2. Ofiara nie może znajdować się blisko oryginalnego Access Pointa. Jeśli jest blisko (oryginalny, prawdziwy sygnał AP jest “silny”) to złośliwe komunikaty potrzebne do przeprowadzenia udanego ataku, a wysyłane przez atakującego zostaną zignorowane. I nici z przechwycenia ruchu.
  • 3. Ofiara musi korzystać z nieszyfrowanych protokołów bo tylko te da się podsłuchać. I dobrze by było, aby korzystała z Androida lub Linuksa, bo te dwa systemy najłatwiej jest zaatakować KRACK-iem. W rzeczywistości jednak, większość ruchu stacji roboczych jest zaszyfrowana — do serwisów łączymy się przez HTTPS. Na filmie badacz celowo pokazał serwis match.com, w którym HTTPS nie jest poprawnie wdrożone i dlatego jest podatne na atak sslstrip.

Podsumowując najważniejsze, po udanym ataku, można podsłuchać tylko to, co w ramach swojej sieci Wi-Fi wysyłasz jako niezaszyfrowane (czyli np. wejścia na strony po HTTP, ale nie HTTPS). Innymi słowy, ktoś atakujący Cię KRACK-iem może robić praktycznie to samo co każdy, kto kiedykolwiek znajdował się razem z Tobą w jednej sieci Wi-Fi, czy to tej hotelowej czy w kawiarnianej. Czy panikujesz za każdym razem kiedy łączysz się do takich “obcych” sieci? No właśnie…

Ba! Wymuszenie przepięcia stacji roboczej na złośliwą sieć Wi-Fi (i podsłuchanie ofiary) można wykonać także bez tego skomplikowanego ataku, przy pomocy jammingu i fałszywego Access Pointa (por. opis tego ataku w wykonaniu hakera Janusza) — i na ten atak byłeś (i narażony jesteś od lat i wciąż będziesz narażony, nawet jak się załatasz na KRACK-a). W przypadku takiego ataku atakujący również musi być w pobliżu ofiary.

Mam Wi-Fi — co robić, jak żyć?

Żeby uchronić się przed atakiem KRACK wystarczy wgrać aktualizację oprogramowania zarówno na Access Poincie jak i na klientach ale przede wszystkim na klientach (komputerach, laptopach, smartfonach), bo to ich dotyczą najpoważniejsze warianty ataku. Prawie każda platforma jest podatna na co najmniej jeden z wariantów ataku:

Załatanie tylko AP lub tylko klienta uniemożliwi tylko część z wariantów ataku KRACK. I nie martw się o niekompatybilność załatanego klienta z niezałatanym AP i na odwrót. Dziurawe i załatane AP mogą bez problemu komunikować się z dziurawymi i załatanymi klientami — łatka jest kompatybilna wstecznie. Większość producentów informacje podatności otrzymała jeszcze w lipcu i z tego powodu albo zaraz ją udostępni, albo już udostępniła odpowiednie łatki:

  • Microsoft po cichu załatał błąd 10 października (miniony wtorek), ale zaznacza, że nawet z łatką, w niektórych przypadkach Windowsy mogą być celem ataku, jeśli w trybie oszczędzania energii przekażą część zadań związanych z obsługą Wi-Fi chipowi. Dlatego trzeba też niezależnie zaktualizować też sterowniki do swojej karty sieciowej.
  • Najpoważniejszy z wariantów ataku nie dotyka urządzeń iOS i macOS. Na mniej istotny wariant Apple już wypuściło łatkę w wersjach beta swoich systemów, które w przeciągu najbliższych dni pewnie zostaną udostępnione wszystkim.
  • Najpoważniejszy z wariantów ataku dotyka urządzenia z Androidem. Google ma wydać patcha dopiero 6 listopada i to tylko na swojego Pixela. Stworzenie i rozpropagowanie łatek na telefony innych producentów pewnie zajmie lata. Ale to nic nowego… tak więc na większości niepobłogosławionych przez Google urządzeniach z Androidem poza wyłączeniem bluetootha będziesz pewnie musiał wyłączyć także Wi-Fi.
  • *nix. OpenBSD już zapatchowane, Debian też. Inne dystrybucje pewnie niebawem. Co ciekawe, OpenBSD nie dotrzymało embarga i załatało się wcześniej ujawniając kod łatki i tym samym obnażając istotę błędu, co ktoś mógł wykorzystać do ataków. Z tego powodu OpenBSD w przyszłości nie będzie otrzymywało od tego badacza wcześniejszych ostrzeżeń o zagrożeniu.
  • Mikrotik też się załatał po cichu tydzień temu
  • Są także dostępne patche na urządzenia Cisco (niektóre z podatnych), Aruba i Ubiquiti

Pełną listę podatnych producentów (lub informacje o tym, kiedy się załatali) znajdziecie w komunikacie amerykańskiego CERT-u. Warto obserwować jak szybko reagują — to może być dobra wskazówka, jakiemu producentowi ufać.

Jeśli na Twoje urządzenie nie ma jeszcze patcha, to:

  • Włącz VPN-a i skonfiguruj go tak, aby cały ruch z Twojego urządzenia przez niego przechodził. Atakujący wtedy nie będzie w stanie niczego zobaczyć, ani złośliwie zmodyfikować. Na urządzenia mobilne dostępna jest darmowa aplikacja OperaVPN.
  • Dodatki do przeglądarki typu HTTPS Everywhere powinny ograniczyć ryzyko wycieku informacji. Warto je zainstalować nawet jeśli nie obawiacie się KRACK-a.
  • W przypadku braka patcha na Twój AP: wyłącz w nim funkcje klienta (używana np. w trybach repeatera) oraz wyłącz 802.11r
  • W ostateczności, zostaje ci rozwiązanie najprostsze. Porzucenie Wi-Fi:

Ah, i ważna (dla niektórych) informacja na koniec. Zmiana hasła do sieci WPA2 nic nie da, bo ten atak w ogóle nie jest w stanie ustalić wartości hasła. Atakujący ustala klucze szyfrujące, które — upraszczając — z hasłem nie są związane. Jeśli więc waszym celem jest poznanie hasła do sieci Wi-Fi sąsiada, to dalej najlepszym atakiem jest atak na WPS.

Na czym dokładnie polega atak?

Problem leży w sposobie implementacji protokołu WPA2. Nie jest więc związanych z jednym czy drugim producentem Access Pointów (AP) czy kart sieciowych (dlatego podatny jest prawie każdy z producentów).

4 way handshake

4 way handshake

Błąd znajduje się w tzw. 4-way handshake, czyli procesie negocjacji podłączenia klienta do sieci WPA2. Proces ten odpowiada za potwierdzenie, że klient zna poprawne dane logowania do sieci Wi-Fi. W trakcie 4-way handshake negocjowany jest też klucz sesyjny, który będzie używany do szyfrowania danych przesyłanych pomiędzy klientem a AP.

Atak KRACK polega na zmuszeniu klienta, poprzez manipulację handshake’a, do ponownego użycia klucza (tzw. reinstalację klucza). Ponowne użycie tego samego klucza nie powinno nigdy mieć miejsca, bo dzięki temu ktoś, kto przechwyci zaszyfrowany ruch WPA2 (tj. sniffuje czyjąś sieć) może na podstawie znajomości tego co było szyfrowane wyznaczyć i w konsekwencji rozszyfrować ruch od klienta do AP. Niestety, atak właśnie takie “przywrócenie” już raz użytego klucza wymusza.

Klient zaczyna używać dany klucz sesyjny po 3 kroku 4 krokowego handshake’a, ale ponieważ ramki bezprzewodowe czasem nie docierają do celu, AP ma możliwość ponownego przesłania klientowi ramki z kroku 3. Badacz odkrył, że jeśli klient dostanie wiele komunikatów z kroku 3, zresetuje nonce (tzw. IV) i licznik otrzymanych “powtórek” i w konsekwencji użyje ponownie już raz wykorzystany klucz sesyjny. Atakujący poprzez wymuszenie wielokrotnej transmisji ramek z kroku 3 wymusza więc reset nonce’a i sprawia, że klient używa dany keystream po raz drugi.

Jeśli już-raz-wykorzystany-keystream zostanie teraz użyty do zaszyfrowania danych znanych atakującemu, mamy wtedy do czynienia z klasycznym atakiem z tekstem jawnym i możemy wyznaczyć wartość tego keystreamu. A następnie wykorzystać tę wiedzę do rozszyfrowania zaszyfrowanych i przesyłanych w sieci Wi-Fi danych.

Czasem wyznaczenie klucza jest możliwe nawet bez znajomości przykładowych danych, które zostały nim ponownie zaszyfrowane.

Jeśli ofiara zamiast AES CCMP używa WPA-TKIP lub GCMP, który to używa tego samego klucza w komunikacji od- i do- klienta, atakujący może nie tylko deszyfrować ruch, ale także wstrzykiwać/modyfikować pakiety w sieć Wi-Fi. A to doprowadzić może do podrzucenia złośliwego skryptu w kod odwiedzanej przez ofiarę strony WWW, która jest nieszyfrowana. A zatem oprócz “wykradania haseł” atakujący ma teraz możliwość podstawiania klientowi fałszywych danych lub prób infekowania go złośliwym oprogramowaniem (klasyczny atak MiTM)

Tą samą techniką można zaatakować klucze grupowe, PeerKey, TDLS (Tunneled Direct-Link Setup) i handshaki BSS oraz WNM Sleep Mode (Wireless Network Management).

Prawie wszystko co używa Wi-Fi jest podatne

Z błędem związanych jest 10 CVE opisujących poszczególne warianty ataku. Niektórzy z producentów są podatni na kilka z nich:

    CVE-2017-13077: Reinstallation of the pairwise encryption key (PTK-TK) in the 4-way handshake.
    CVE-2017-13078: Reinstallation of the group key (GTK) in the 4-way handshake.
    CVE-2017-13079: Reinstallation of the integrity group key (IGTK) in the 4-way handshake.
    CVE-2017-13080: Reinstallation of the group key (GTK) in the group key handshake.
    CVE-2017-13081: Reinstallation of the integrity group key (IGTK) in the group key handshake.
    CVE-2017-13082: Accepting a retransmitted Fast BSS Transition (FT) Reassociation Request and reinstalling the pairwise encryption key (PTK-TK) while processing it.
    CVE-2017-13084: Reinstallation of the STK key in the PeerKey handshake.
    CVE-2017-13086: reinstallation of the Tunneled Direct-Link Setup (TDLS) PeerKey (TPK) key in the TDLS handshake.
    CVE-2017-13087: reinstallation of the group key (GTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame.
    CVE-2017-13088: reinstallation of the integrity group key (IGTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame.

…ale ataki na Linuksa i Androida są najłatwiejsze

Atak jest, jak to nazywa odkrywca, “najbardziej katastrofalny” na Linuksów i Androidów 6+ (czyli ponad 50% obecnie używanych na świecie słuchawek z Androidem). Powodem jest to, że te systemy korzystają z wpa_supplicant w wersji 2.4+. Standard mówi, że należy wyczyścić z pamięci klucz, który został już “zainstalowany” w 3 kroku handshake’a. Te systemy to robią, ale po otrzymaniu od atakującego kolejny raz wiadomości z kroku 3 handshake’a, przywracają “wyczyszczony w pamięci” klucz, który jest samymi zerami.

Błąd najbardziej dotknie firmy a nie osoby prywatne?

Większość ludzi korzysta na swoich urządzeniach przede wszystkim z protokołów szyfrowanych, np. HTTPS, spędzając większość czasu w przeglądarce. Dlatego nawet w przypadku udanego ataku, atakujący nie powinien przechwycić istotnych informacji. Aplikacje też w większości powinny korzystać z połączeń szyfrowanych — chociaż nawet bankowym aplikacjom zdarza się puszczać ruch bez HTTPS albo bez odpowiedniego weryfikowania poprawności certyfikatów.

Inaczej ma się sprawa w przypadku firm. W intranecie dostępnym po Wi-Fi usługi są często stawiane bez poprawnie skonfigurowanego HTTPS. I to może być największy problem. Traktowanie wewnętrznej sieci Wi-Fi jako “zaufanej”. Prawdopodobnie największe żniwo atakujący zbiorą w atakach na firmowe sieci w lokalach użytkowych — ale nie te hotspoty dla gości, ale sieci “wewnętrzne” w których puszcza się ruch pomiędzy terminalami i innymi firmowymi urządzeniami. Tam prawie nikt nie dba o to, aby ruch wymieniany przez poszczególne systemy był szyfrowany — wszystko opiera się na braku dostępu obcych do danej sieci Wi-Fi.

PS. Jeśli jesteś webdeveloperem i chcesz pomóc tym, którzy nigdy się przed KRACK-iem nie załatają, powinieneś wdrożyć HSTS na swojej stronie internetowej.

Przeczytaj także:

74 komentarzy

Dodaj komentarz
  1. A czy włączenie “Management Frame Protection 802.11w” na AP i kliencie rozwiązałoby problem ?

    • To jest ciekawy trop, jakoś jednak nikt go nie podejmuje.
      Moim zdaniem tak. Ale chyba niestety niewielu ap i klientow wspiera .11w

    • włączenie “Management Frame Protection 802.11w” na AP i kliencie nie rozwiązuje w pełni problemu jeśli klient nadal jest daleko od ap, już nie mówiąc o tym że nie wszystkie urządzenia ( OS) posiadają możliwość ochrony ramek

  2. Czy włączenie filtrowania MAC adresów na domowym AP będzie miało wpływ na atak?

  3. Z tym niedotrzymaniem embarga przez OpenBSD to lekkie przekłamanie.

    stsp@ dostał informacje i łatkę z terminem embarga do końca sierpnia. Autor później postanowił zaangażować CERT i przedłużyć embargo o kolejne dwa miesiące, został przez nas poproszony o pozwolenie na wypuszczenie łaty w OpenBSD w terminie oryginalnego embarga i wyraził na to zgodę.

    wiecej od stsp@:
    https://mastodon.social/@stsp/98837563531323569
    https://news.ycombinator.com/item?id=15481819
    https://news.ycombinator.com/item?id=15481819

    • poprawione linki do HN:
      https://news.ycombinator.com/item?id=15482483
      https://news.ycombinator.com/item?id=15482392

    • To w sumie ciekawa sprawa. Latac asap czy jednak dostosowac sie do narzucanej przez badacza daty publikacji w imie wspolnego dobra. Z perspektywy czasu badacz uwaza, ze zle zrobil dajac OpenBSD znac wczesniej. Ma do tego prawo. OpenBSD z kolei ma prawo latac wtedy kiedy chce – mogl im przeciez nie zglaszac wczesniej.

    • > Ma do tego prawo. OpenBSD z kolei ma prawo latac wtedy kiedy chce – mogl im przeciez nie zglaszac wczesniej.

      Mógł nie wyrazić zgody na publikacje łaty w terminie 30 sierpnia (pierwotna data embargo, przed jej przesunięciem).

      > As a compromise, I allowed them to silently patch the vulnerability.

      Nikt, nie opublikował tej laty wbrew woli autora.

      > Latac asap czy jednak dostosowac sie do narzucanej przez badacza daty publikacji w imie wspolnego dobra

      Tu leży pies pogrzebany, przy 3 miesięcznym embargo i po zaangażowaniu CERT w proces – komu służy embargo, sam proces kto otrzymał tą informacje i jak ją wykorzystuje jest niejawny. Z jednej strony, może potrzebują 2 dodatkowych miesięcy na weryfikacje i latanie systemów rządowych a z drugiej może chcą wykorzystać lukę w 2 miesięcznym oknie przed jego zamknięciem? Co w przypadku kolejnego nieplanowego przesunięcia embarga dajmy na to o kolejny miesiąc?

  4. Najpierw BT, teraz WiFi – aż się boję co będzie następne …

    • Dawno czegoś z GSM nie było

    • Irda

    • Z GSM od dawna jest problem – z tego, co wiem, operator może zmieniać oprogramowanie telefonów niezależnie, czy użytkownik tego chce, czy nie.

    • @Seba masz na myśli zapewne OTA – https://en.wikipedia.org/wiki/Over-the-air_programming
      nie pamiętam jak w 2g ale dla 3g i dalej to jest część standardu także zaskoczenia nie ma

    • Ale coś nowego, powiew świeżości bo za dużo zabawy jest by przeprowadzić taki przykładowy atak. Jak mnie pamięć nie myli to trzeba postawić własnego BTS’a.

  5. Czyli wracamy do IrDA ;)

    • Jak i to zhakują to jest jeszcze RS-232. :)

    • W Japonii maja taka z przepustowością ponad 50MB/s także da radę :)

    • chyba na kabel ;)

    • Żeby się przed atakami na IrDĘ zabezpieczyć, wystarczy filtr IR na oknach :)

  6. Wasz tekst mnie bardzo uspokoił, co prawda od jakiegoś czasu na mojej ulicy zaczął parkować jakiś wan, ale na szczęście biały. Tak więc nie ma obawy :D

    • A czarnej Wołgi nie było?

  7. A samba? Też chyba zbytnio szyfrowana nie jest. Ludzie z NASem i firmy pewnie powinny bać się też tego :)

  8. teraz pytanie, kiedy dystrybucje typu Kali będą miały to w standardzie i czy same będą odprne na KRACK

  9. Czy da się jakoś sprawdzić czy mój dostawca internetu zaktualizował mój router?
    Chłopaczki w biurze nie wiedzą nic o KRACKu i twierdzą że to nie dotyczy routera który mi dali tylko innych….

  10. Opera nie oferuje żadnego “VPN”, a proxy do zbierania danych dla siebie. Co za bzdury…

    > Co ciekawe, OpenBSD nie dotrzymało embarga i załatało się wcześniej ujawniając kod łatki i tym samym obnażając istotę błędu, co ktoś mógł wykorzystać do ataków. Z tego powodu OpenBSD w przyszłości nie będzie otrzymywało od tego badacza wcześniejszych ostrzeżeń o zagrożeniu.

    OpenBSD niczego nie złamało. Ich developerzy po prostu dowiadują się o tym czy o tamtym własnymi kanałami od innych developerów i zgodnie z tak otrzymywaną wiedzą wprowadzają poprawki. Nie mogli nie dotrzymać embarga, bo nikt się do nich oficjalnie nie zwracał.

  11. Android może nigdy się nie doczeka, ale LineageOS 14.1 już łatkę posiada https://twitter.com/LineageAndroid/status/920143977256382464

  12. Z opisu wnioskuję, że tak ale chciałbym się upewnić, czy WPA2 EAP z AES CCM ten atak też dotyczy?

  13. Debian i dd-wrt załatane.. :D

  14. A czy NETIA będzie aktualizowała swoje NETIA SPOTY? czy coś ktoś wie?

  15. Czy atak będzie skuteczny jeśli na kontrolerze wifi mam włączoną izolacje klientów, a na switchu port isolation?

  16. Ciekawa jest lista nie powiadomonych znanych dostawcow sprzetu wifi (ta z CERTu)…

  17. Wynika z tego arta, ze tylko ap klienty, roaming, repeatery sa podatne w netia spot nie ma tych trybow, wiec sa bezpieczne

  18. czym to sie różnie od dotychczasowych ataków na wifi?

  19. “Dlatego nawet w przypadku udanego ataku, atakujący nie powinien przechwycić istotnych informacji”

    Sorry mate, but it’s no true. Do u really think HTTPS is “safe” ? hahah lol

    Hint :)
    If u add one thing to it => you can easily see all the traffic

    DONE and checked :)

    Pozdrowienia

    • Oświeć nas, jak sprawić, żeby HTTPS nie szyfrował ruchu.

    • Kolejny, który ma kolegę, którego sąsiad ma kuzyna, którego dobry kolega umie ściągnąć cracka i skrakować grę.

    • #Kolejny, który ma kolegę, którego sąsiad ma kuzyna, którego dobry kolega umie ściągnąć cracka i skrakować grę.

      sorry pal, but it’s better for me to have no friends :) and 15y ago I was cracking games for a fun. I’m really in UK?

      Wait and you will believe.
      Impossible is nothing… Believe :)

  20. Czy możliwe jest po prostu połączenie do AP używając tego klucza?

  21. Właśnie się zastanawiałem skąd ta wszechogarniająca panika. Już zaczynałem wątpić, czy w pełni zrozumiałem powagę ataku, ale jak zawsze mogę liczyć na niebezpiecznik, który bez paniki i rzeczowo opisuje możliwości i ograniczenia luki.

  22. UWAGA!!!

    OperaVPN nie działa po WiFi

  23. Czy wiadomo jak wyglada sprawa z urzadzeniami na esp8266? Czy wystarczy zalatac biblioteki od WIFI w przespawac uklady, czy to siedzi gdzies w hardware?

  24. Ładne wyjaśnienie na Computerphile
    https://www.youtube.com/watch?v=mYtvjijATa4

  25. Czy wyłączenie access point pomoże?

    • Pomoże wyłączenie zasilania w Routerze.

  26. Czy ktoś weryfikował podatność urządzeń popularnych polskich operatorów kablowych na ten atak? Wiecie może coś o planowanych aktualizacjach na te urządzenia? Czy raczej wyłączyć na nich WiFi?

  27. Zle pytania zadajesz :) Jezeli myslicie ze wkleje wam gotowy code to sory ale tego nie zrobie z wiadomych przyczyn :) troche kreatywnosci.

    A TLS… Sami wiecie … Lol
    Pozdrawiam.

  28. czyli doinstalować np HTTPS Everywhere… a czy dotyczy atak dotyczy również jeśli korzystam z (802.11bgn)

  29. W Ubuntu i Mint 16.10.2017 pojawiła się aktualizacja dla wpasupplicant

    pozdr
    M

  30. W artykule jest mowa o Androidach, a w tabeli jest podany tylko Android 6. A co z Androidem 7? No i zdziwiłbym się, gdyby starsze Androidy były odporne, więc chyba ta tabela jest niepełna.

  31. Chciałbym aby ktoś ze specjalistów odniósł się do informacji Drayteka na temat podatności ich urządzeń: http://www.draytek.co.uk/information/our-technology/wpa2-krack-vulnerability
    Czy to znaczy, że ich urządzenia np. router wifi nie są podatne na Krack?
    “If you use a DrayTek wireless product (router or access point) and you are only using it as the wireless base, then it is not vulnerable to ‘Krack’ and a patch/update is not necessary for that operation.”

    • IF “you are only using it as the wireless base”

    • ale czy to nie oznacza, że wszystkie budżetowe routery bezprzewodowe są bezpieczne o ile działają tak jak działają pewnie w większości domów (modem podłączony kablem do naszego budżetowego routera, który udostępnia za pomocą wifi internet)?
      Czy to nie oznacza, że wszystkie modemy kablówek z opcją udostępniania internetu po wifi też są bezpieczne i nie potrzebują aktualizacji?

    • @Piotr Konieczny ale to właśnie Draytek w tym artykule napisał – tylko urządzenia działające jako repeater albo wireless station (ew. te z włączonym wireless wan) czyli podsumowując działające jako KLIENT (w taki czy inny sposób) są podatne, te działające jako nazwijmy to “serwer sieci” nie są. Co mi się nie zgadza z informacjami z powyższego artykułu :-)

  32. No właśnie , które androidy są podatne? Wszystkie ? a może od 6 +, a co z androidem lolipop 5.0.1?

  33. Dobrze zaprogramowane ESP8266, do Sejmu.

  34. A może to nie błąd tylko furtka?

  35. @Piotr: wylapaliscie moze, kiedy autor dopracuje skrypty pozwalajace badac, czy dana siec jest podatna na to ? Jak ja czytalem, to zrozumialem, ze chlop cos tam dlubie i jak sie dodlubie, to wtedy;)

  36. Teraz to już tylko albo kabel albo porządny vps, choć co do tego drugiego też nie ma pewności. Ewentualnie liczyć na aktualizacje oprogramowania producenta routera.

  37. >Innymi słowy, ktoś atakujący Cię KRACK-iem może robić praktycznie to samo co każdy, kto kiedykolwiek znajdował się razem z Tobą w jednej sieci Wi-Fi, czy to tej hotelowej czy w kawiarnianej. Czy panikujesz za każdym razem kiedy łączysz się do takich “obcych” sieci? No właśnie…

    Błędna informacja. 4-way handshake w WPA właśnie zapewnia, że każdy użytkownik do własnej komunikacji używa unikalnego, osobistego klucza sesyjnego, dzięki czemu inni użytkownicy nie mogą podglądać, ani wpływać na jego transmisję.

  38. Dd-wrt wydało patch dla routerów i co więcej pewną metodą zabezpieczenia niezaktualizowanych klientów o nazwie Disable EAPOL Key Retries

  39. Na Xiaomi smartphony w tym tygodniu już jest dostępna aktualizacja łatająca. Dzisiaj właśnie przyszło mi powiadomienie. Polecam zaktualizować :)

  40. Wielka mi sensacja… Kiedyś istniała dziura która pokazywała klucz do dowolnego routera po nieudanym połączeniu np Smartfona z Androidem z root. Po odszukaniu odpowiedniego pliku w systemie Android nawet WPA2 zwracało pełne hasło danemu urządzeniowi który próbował się połączyć…

  41. Nic nie tryeba wzstarcyz kombinować :)

  42. @TWITTER HACKED allow to bypass autentication 2ndFactor

  43. W przypadku braka patcha na Twój AP: wyłącz w nim funkcje klienta (używana np. w trybach repeatera) oraz wyłącz 802.11r

  44. Czy ukrywanie SIDa siech WiFi cos daje, badz utrudnia hack?

  45. Wie ktoś, który numer poprawki do Windows 7 x64 zastosować ?

Twój komentarz

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: