Niektóre implementacje protokołów WPA i WPA2 używanych do uwierzytelniania i szyfrowania komunikacji w sieciach WiFi pozwalają atakującym na jej podsłuchanie oraz wstrzyknięcie spreparowanych pakietów. Podatne na atak są m.in. urządzenia z niektórymi wersjami systemów operacyjnych Android (od wersji 6), Mac OS X oraz Linux (możliwość podsłuchiwania całej komunikacji), a względnie bezpieczne są urządzenia z systemami iOS oraz Windows (tylko możliwość wstrzykiwania pakietów typu broadcast, bez podsłuchiwania komunikacji).
Powiązane CVE: CVE-2017-13077, CVE-2017-13078, CVE-2017-13079, CVE-2017-13080, CVE-2017-13081, CVE-2017-13082, CVE-2017-13084, CVE-2017-13086, CVE-2017-13087, CVE-2017-13088Na bieżąco aktualizowane informacje na temat ewentualnych poprawek w urządzeniach i systemach od poszczególnych producentów:
http://www.kb.cert.org/vuls/byvendor?searchview=&Query=FIELD+Reference%3D228519&SearchOrder=4
Podatność trzeba naprawić przede wszystkim po stronie systemów oraz urządzeń, które łączą się do sieci WiFi (w tym access-pointy działające w trybie klienta oraz wszystkie access-pointy dla niektórych wariantów ataku). Zalecamy sprawdzenie czy dla naszego systemu bądź urządzenia istnieje już poprawka i jej niezwłoczne zainstalowanie.
Szczególnie narażeni są posiadacze podatnych urządzeń oraz systemów, które nie otrzymują już poprawek bezpieczeństwa (np. część urządzeń z systemem Android czy urządzeń IoT).
Na dzień 16 października 2017 odpowiednie poprawki bezpieczeństwa otrzymały systemy: Windows (7, 8.1 oraz 10), Debian, Ubuntu, Arch Linux, OpenBSD.
Stosowanie szyfrowanych protokołów komunikacji z bezpieczną wymianą kluczy (np. przeglądanie stron HTTPS i/lub używanie bezpiecznego połączenia VPN) w większości przypadków pozwoli na ochronę komunikacji choćby w przypadku pomyślnie przeprowadzonego ataku.
Zalecenia dla administratorów:
- sprawdzać regularnie informacje na temat podatności oraz ewentualnych poprawek producentów systemów operacyjnych i urządzeń z funkcją łączenia do sieci WiFi (zbiorcza lista aktualizowana przez amerykański CERT/CC) oraz instalacja poprawek niezwłocznie, gdy się pojawią
- nie zmieniać protokołu z WPA2 na inne (są podatne na groźniejsze ataki)
- nie zmieniać hasła WPA2 (nie ma takiej potrzeby, atak nie pozwala na jego przechwycenie)
- używać komunikacji dodatkowo szyfrowanej z bezpieczną wymianą kluczy (HTTPS, VPN)
https://cwe.mitre.org/data/definitions/323.html Szczegółowy opis techniczny autorów podatności: https://papers.mathyvanhoef.com/ccs2017.pdf
Skrócony opis techniczny podatności:
W protokołach WPA oraz WPA2, stosowanych w sieciach WiFi, do uwierzytelnienia oraz wymiany klucza szyfrującego przy nawiązaniu połączenia pomiędzy access-pointem a klientem używany jest tzw. 4-way handshake. Klient przyjmuje podany przez access-point klucz po otrzymaniu wiadomości nr 3. Ze względu na możliwe zakłócenia transmisji, według obowiązującego standardu access-point może ponawiać wysłanie tej wiadomości dopóki nie otrzyma zwrotnego potwierdzenia, co z kolei klient powinien odpowiednio obsłużyć. Okazuje się, iż o ile atakujący przechwyci wiadomość nr 3 i wyśle ją klientowi jeszcze raz, podczas już nawiązanego połączenia, niektóre implementacje klienckie ustawią klucz i/lub jego parametry do ich wartości początkowych. W zależności od implementacji klienckiej może oznaczać to możliwość odszyfrowania pakietów, wstrzyknięcia do sesji wcześniejszych bądź całkowicie spreparowanych przez atakującego pakietów.
Warto zwrócić uwagę na szczególnie podatną implementację klienta wpa_supplicant w wersjach 2.4-2.6 (używany w systemach Linux, a przede wszystkim w systemie Android od wersji 6) – klient przy ponownym ustawieniu klucza zastosuje stały, wyzerowany klucz, co umożliwia nie tylko odszyfrowanie, ale i wstrzyknięcie spreparowanych pakietów.
Względnie bezpieczne są urządzenia z systemami iOS oraz Windows, których implementacja protokołów WPA/WPA2 nie jest do końca zgodna ze standardem, i które nie pozwalają na ponowne ustawienie klucza (i/lub jego parametrów), więc i odszyfrowania komunikacji. Wciąż możliwe jest wysyłanie przez atakującego pakietów broadcast na niezaktualizowanych systemach.
Atakujący (w zasięgu naszej sieci WiFi) do przeprowadzenia ataku potrzebuje najpierw przechwycić pierwotny handshake. Dzieje się to tylko w momencie zawarcia połączenia z access-pointem, natomiast proces ten może być transparentnie przeprowadzany w przypadku utraty sygnału lub okresowo. Niektóre access-pointy pozwalają na wymuszenie przeprowadzenia tej procedury na żądanie przez atakującego.
