ochrona przed atakami brute force

Ochrona przed atakami brute force (brute force protection) to zestaw mechanizmów, które utrudniają zgadywanie haseł i innych danych logowania. Atak siłowy (brute-force) polega według CERT Polska na systematycznym sprawdzaniu kolejnych możliwych wartości danych uwierzytelniających, aż do znalezienia poprawnej ^[1]. Ochrona nie polega na jednym zabezpieczeniu. Łączy limity prób, opóźnienia, blokady, weryfikację, że po drugiej stronie jest człowiek, oraz drugi składnik logowania. Brak takich mechanizmów MITRE opisuje jako słabość CWE-307: produkt nie stosuje wystarczających środków, by zapobiec wielu nieudanym próbom uwierzytelnienia w krótkim czasie ^[5].

Jak działa

Podstawą jest licznik nieudanych prób. CERT Polska zaleca ograniczać częstotliwość prób uwierzytelnienia i liczyć je jednocześnie dla konta oraz dla źródła żądania ^[1]. Po przekroczeniu limitu stosuje się narastające opóźnienia, blokadę czasową, dodatkową weryfikację albo CAPTCHA ^[1]. Reakcja rośnie więc stopniowo, co pokazuje schemat poniżej.

RYS. 1Stopniowana reakcja na nieudane logowania

OWASP opisuje politykę blokady trzema parametrami: liczbą nieudanych prób, po której konto jest blokowane, oknem czasu, w którym te próby się liczą, oraz czasem trwania blokady ^[3]. Wymienia też blokadę wykładniczą, która zaczyna się od bardzo krótkiego czasu, na przykład sekundy, i podwaja go po każdej kolejnej nieudanej próbie ^[3].

NIST w wytycznych SP 800-63B wymaga, by liczba kolejnych nieudanych prób dla jednego uwierzytelniacza na jednym koncie nie przekraczała 100 ^[4]. To górna granica; organizacje mogą ustalać niższe ^[4]. Zamiast twardej blokady NIST dopuszcza test wykrywający boty, oczekiwanie rosnące wraz ze zbliżaniem się do limitu, na przykład od 30 sekund do godziny, oraz techniki oparte na ocenie ryzyka ^[4].

Odmiany ataków

Licznik prób działa różnie w zależności od tego, co atakujący zmienia między próbami. OWASP rozróżnia trzy zautomatyzowane odmiany ^[3].

Dlatego CERT Polska zaleca liczenie prób jednocześnie dla konta i źródła, a zarazem przestrzega przed poleganiem wyłącznie na ograniczeniach opartych na adresie IP ^[1]. Ataki rozproszone przez botnet korzystają z wielu adresów naraz.

W WordPressie

Sekurak w poradniku z 2017 roku zauważył, że WordPress nie ma wbudowanych zabezpieczeń przed atakami słownikowymi ^[6]. Formularz logowania rdzenia nie ogranicza więc sam liczby prób; robią to wtyczki, serwer lub usługa przed stroną. Dokumentacja WordPressa ostrzega, że ataki są zautomatyzowane i często rozproszone, więc nawet nieudane mogą przeciążyć stronę ^[2].

Zalecenia z dokumentacji rdzenia obejmują kilka warstw ^[2]:

• nieużywanie nazwy użytkownika admin oraz silne, unikatowe hasła wspierane przez menedżer haseł;
• ochronę /wp-login.php hasłem na poziomie serwera, ograniczenia adresów IP i limit żądań;
• CAPTCHA albo podobne wyzwanie w formularzu logowania;
• wyłączenie XML-RPC, jeśli nie jest używany, bo xmlrpc.php, zwłaszcza metoda system.multicall, jest częstym celem;
• uwierzytelnianie dwuskładnikowe (two-factor authentication, 2FA) i passkeys.

Dokumentacja dopuszcza wtyczki bezpieczeństwa ograniczające próby logowania, ale zaleca, by tam, gdzie to możliwe, robić to na brzegu sieci albo na serwerze ^[2]. Wtyczka obsługuje każde żądanie dopiero po uruchomieniu WordPressa, więc przy dużym ataku sama zużywa zasoby. Tę rolę pełni WAF albo rate limiting w serwerze WWW.

CERT Polska sprawdza podatność stron na zgadywanie haseł także w praktyce. System Artemis ma moduł wordpress_bruter, który próbuje odgadnąć dane logowania do WordPressa metodą brute-force ^[7].

Zagrożenia i skutki

Udany atak kończy się przejęciem konta; przy koncie administratora oznacza to kontrolę nad całą stroną. Sama ochrona też ma koszt. OWASP ostrzega, że mechanizm blokady trzeba zaprojektować tak, by nie dało się go użyć do blokowania kont innych użytkowników ^[3]. Atakujący, który zna loginy, na przykład dzięki enumeracji użytkowników, mógłby celowo wyczerpywać ich limity i odcinać ich od panelu. To powód, dla którego NIST wymienia opóźnienia i testy na boty jako alternatywy dla twardej blokady ^[4].

Dobre praktyki

Zalecenia CERT Polska wykraczają poza formularz logowania ^[1]:

• te same limity we wszystkich miejscach uwierzytelniania, także w API, panelach administracyjnych i usługach sieciowych;
• limity również przy resetowaniu hasła i weryfikacji drugiego składnika;
• uwierzytelnianie wieloskładnikowe dla kont administracyjnych;
• wymóg odpowiednio długich haseł i blokowanie haseł popularnych oraz znanych z wycieków, zgodnie z zasadami bezpiecznych haseł;
• monitorowanie nieudanych prób według konta, źródła, urządzenia, czasu i wzorca aktywności.

MITRE wśród typowych mechanizmów ochrony wymienia rozłączenie po kilku nieudanych próbach, limit czasu, zablokowanie atakowanego konta i wymaganie od użytkownika zadania obliczeniowego ^[5]. W WordPressie najprostszy zestaw to limit prób logowania na serwerze, drugi składnik dla administratorów oraz zamknięcie nieużywanych kanałów logowania.

# ilustracja: dostęp do wp-login.php tylko z biura
<Files "wp-login.php">
  Require ip 192.0.2.10
</Files>

Taka biała lista adresów IP odcina większość zautomatyzowanych prób, ale wymaga stałego adresu u wszystkich osób, które się logują.

Historia i przykłady

Niebezpiecznik 20 listopada 2013 roku opisał atak na konta w serwisie GitHub. Według wpisu serwis zablokował kilka kont, a powodem były słabe hasła ich właścicieli oraz botnet z około 40 000 unikatowych adresów IP, który próbował logować się, zgadując hasła ^[8]. Przypadek pokazuje oba problemy naraz: rozproszony atak omija proste limity liczone tylko dla jednego adresu, a słabe hasło pozostaje najsłabszym punktem nawet w dużym serwisie.