Ataki brute force¶

Atak typu brute force polega na systematycznym sprawdzaniu kolejnych możliwych wartości danych uwierzytelniających, aż do znalezienia poprawnej. Przeprowadzenie ataku nie wymaga znalezienia żadnego błędu w aplikacji, a jedynie odpowiednio dużej liczby prób.

Wyobraźmy sobie aplikację, która prosi użytkownika o czterocyfrowy kod PIN i zwraca informację o tym, czy jest on poprawny. Możliwych wartości jest dziesięć tysięcy. Atakujący sprawdza je po kolei, aż trafi na właściwą:

Tak samo można zgadywać hasła, tokeny i kody jednorazowe.

W praktyce atak brute force jest realizowany w sposób zautomatyzowany przy użyciu narzędzi lub skryptów. Próby mogą być wykonywane szybko albo celowo rozłożone w czasie i prowadzone z wielu adresów IP w celu uniknięcia wykrycia.

Ataki lokalne

Brute force bywa prowadzony również na skrótach haseł pozyskanych z bazy danych. Atakujący nie wysyła wtedy do systemu żadnych żądań, więc limity prób nie mają znaczenia, a odporność zależy od tego, jakim algorytmem hasła zostały zabezpieczone. Opisano to w osobnym artykule: Przechowywanie haseł.

Skutki udanego ataku¶

Skuteczny atak brute force może prowadzić do:

przejęcia konta użytkownika i wykonywania operacji w jego imieniu,
odczytu, modyfikacji, usunięcia lub eksportu danych dostępnych dla przejętego konta,
przejęcia konta administracyjnego i uzyskania pełnej kontroli nad systemem,
wykorzystania przejętego konta do uzyskania dostępu do kolejnych systemów organizacji,
utrzymania dostępu przez atakującego również po zmianie hasła, jeżeli zdążył utworzyć własne konto, klucz lub token.

Możliwe problemy¶

Brak limitów poza formularzem logowania¶

Tymi samymi danymi można zwykle zalogować się w kilku miejscach. Oprócz głównego formularza logowania takimi miejscami bywają API, panel administracyjny albo usługi sieciowe takie jak SSH, RDP czy FTP. Limit wdrożony w jednym z tych miejsc nie chroni pozostałych, a atakujący wybierze tę drogę, której nikt nie ograniczył.

Limity oparte na adresie IP¶

Dla atakującego adres IP jest zasobem tanim i wymiennym. Do dyspozycji ma sieci proxy, serwery w chmurze i botnety, a przy IPv6 cały prefiks przydzielony przez operatora. Typowy prefiks /64 obejmuje 2^64 adresów IPv6, więc próby można rozłożyć tak, aby nie przekroczyć nawet najbardziej rygorystycznych limitów.

Jednocześnie wielu użytkowników współdzieli jeden adres, na przykład w sieciach firmowych za NAT lub u operatorów komórkowych stosujących CGNAT. Blokada takiego adresu odcina od usługi osoby niezwiązane z atakiem.

Trwała blokada konta¶

Blokada konta po kilku nieudanych próbach jest prostym i skutecznym sposobem na zatrzymanie ataku. Pozwala jednak celowo odciąć od usługi dowolnego użytkownika. Wystarczy do tego znajomość loginu, którym często jest adres e-mail. Blokadę może nieświadomie wywołać też sam użytkownik. Wystarczy, że zmieni hasło, a telefon albo klient poczty dalej będzie próbował logować się poprzednim, wyczerpując limit prób.

Zbyt krótkie i przewidywalne tokeny¶

Odporność tokenu zależy od tego, ile ma możliwych wartości i czy da się je przewidzieć. Sześciocyfrowy kod to tylko milion kombinacji. Z kolei wartości tworzone ze znacznika czasu lub kolejnego numeru są łatwe do przewidzenia. Przy ciasteczkach sesyjnych oraz tokenach i kluczach API limitów zwykle się nie stosuje. Nie ma takiej potrzeby, o ile wartość jest dostatecznie długa i losowa. Bezpieczeństwo wynika wtedy z dużej liczby możliwych kombinacji i ich nieprzewidywalności, a nie z limitu prób.

Rekomendacje¶

Aby utrudnić atak brute force, należy:

Ograniczać częstotliwość prób uwierzytelnienia, licząc je jednocześnie dla konta i dla źródła żądania,
Po przekroczeniu limitu stosować narastające opóźnienia, blokadę czasową, dodatkową weryfikację albo CAPTCHA,
Egzekwować limity po stronie serwera, spójnie we wszystkich instancjach aplikacji oraz we wszystkich miejscach prowadzących do tego samego uwierzytelnienia, w tym w API, panelach administracyjnych i usługach sieciowych,
Stosować limity na wszystkich etapach uwierzytelniania, czyli przy resetowaniu hasła oraz weryfikacji kodów MFA,
Nie opierać limitów wyłącznie na adresie IP,
Wdrożyć uwierzytelnianie wieloskładnikowe przynajmniej dla kont administracyjnych i kont o podwyższonych uprawnieniach,
Wymagać odpowiednio długich haseł oraz blokować hasła powszechnie używane i ujawnione w wyciekach, zgodnie z zasadami opisanymi w artykule Polityka haseł,
Generować ciasteczka sesyjne, tokeny resetowania hasła i klucze API kryptograficznie bezpiecznym generatorem liczb losowych, o długości uniemożliwiającej ich zgadywanie,
Monitorować nieudane próby uwierzytelnienia z uwzględnieniem konta, źródła żądania, urządzenia oraz czasu i charakteru aktywności, tak aby wykrywać również próby rozłożone w czasie i prowadzone z wielu adresów.