atak siłowy (brute-force)

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]. Celem bywa hasło, kod PIN, kod jednorazowy albo identyfikator sesji. MITRE zalicza atak siłowy do technik zdobywania dostępu do kont, stosowanych, gdy hasła nie są znane albo gdy atakujący zdobył ich skróty ^[2]. Skuteczność ataku zależy od dwóch rzeczy: liczby możliwych wartości i liczby prób, na które pozwala system.

Jak działa

Atakujący automatyzuje logowanie. Program wysyła kolejne kandydatury, odczytuje odpowiedź i przechodzi do następnej, aż któraś zostanie przyjęta. Dokumentacja WordPressa opisuje to jako najprostszy sposób włamania: atakujący wielokrotnie próbuje kombinacji nazwy użytkownika i hasła, aż któraś zadziała ^[4]. Pętlę pokazuje schemat poniżej.

RYS. 1Pętla ataku siłowego na formularz logowania

O tym, jak długo trwa pętla, decyduje przestrzeń wartości. CERT Polska podaje, że czterocyfrowy PIN ma 10 000 możliwych wartości, a sześciocyfrowy kod to tylko milion kombinacji ^[1]. Dla programu wysyłającego żądania bez ograniczeń to niewiele. Dlatego tak ważne są limity prób, którym poświęcony jest osobny artykuł o ochronie przed atakami brute force.

CERT Polska wyróżnia też atak lokalny, prowadzony na skrótach haseł pobranych z bazy, bez wysyłania prób przez sieć ^[1]. Ten wariant opisuje hasło łamanie haseł. Atak rozproszony z kolei celowo rozkłada próby w czasie i na wiele adresów IP, by uniknąć wykrycia ^[1].

Odmiany

MITRE dzieli technikę Brute Force (T1110) na cztery podtechniki ^[2]. Różnią się tym, co atakujący zmienia między próbami i skąd bierze kandydatów. Przy credential stuffing źródłem są combolisty (combolist), czyli zestawienia par login–hasło z wycieków.

MITRE wymienia jako typowe cele usługi SSH, RDP, SMB, aplikacje SaaS, VPN, zapory i inne usługi zdalnego dostępu ^[2]. Na stronach internetowych celem jest formularz logowania i każdy inny punkt, który przyjmuje dane uwierzytelniające.

W WordPressie

Dokumentacja WordPressa zwraca uwagę, że ataki są zautomatyzowane i często rozproszone przez botnet, więc nawet nieudane mogą przeciążyć stronę żądaniami ^[4]. Skutkiem bywa więc nie tylko ryzyko przejęcia konta, lecz także spowolnienie witryny, zbliżone do ataku odmowy usługi.

Typowe cele w WordPressie to /wp-login.php oraz XML-RPC. Dokumentacja określa xmlrpc.php jako częsty cel ataków siłowych i zaleca wyłączenie go, gdy nie jest używany, albo ograniczenie metody system.multicall ^[4].

Atakującemu pomaga znajomość loginów. Dokumentacja odradza nazwę użytkownika admin ^[4], a loginy innych kont ujawnia często enumeracja użytkowników. Zgadywanie haseł do WordPressa jest na tyle typowym ryzykiem, że system Artemis prowadzony przez CERT Polska ma moduł wordpress_bruter, który próbuje odgadnąć dane logowania do WordPressa metodą brute-force ^[6]. Artemis jest bezpłatny dla uczestników, którzy zgłoszą się przez moje.cert.pl, i skanuje wyłącznie usługi dostępne publicznie ^[6].

Zagrożenia i skutki

Udany atak siłowy kończy się przejęciem konta. W WordPressie konto administratora daje kontrolę nad treścią, wtyczkami i często nad kodem wykonywanym na serwerze. Brak ograniczenia prób MITRE klasyfikuje jako słabość CWE-307: produkt nie stosuje wystarczających środków, by zapobiec wielu nieudanym próbom uwierzytelnienia w krótkim czasie ^[3].

MITRE jako środki zaradcze wymienia politykę użycia kont, uwierzytelnianie wieloskładnikowe, politykę haseł i zarządzanie kontami użytkowników ^[2]. Obrona też ma swoją cenę. MITRE zaleca blokadę konta po określonej liczbie nieudanych prób, ale ostrzega, że zbyt surowa polityka może sama spowodować odmowę usługi i uniemożliwić pracę ^[2]. Atakujący, który zna loginy, mógłby celowo wyczerpywać limity cudzych kont. Dlatego CERT Polska zaleca łączyć liczniki dla konta i dla źródła, a nie opierać się wyłącznie na adresie IP, bo ataki rozproszone korzystają z wielu adresów naraz ^[1].

Atak siłowy jest też hałaśliwy. Każda próba to żądanie, które trafia do logów serwera. Dokumentacja WordPressa zaleca więc przegląd nieudanych logowań według źródła i czasowe blokowanie adresów, z których przychodzą nadużycia ^[4].

Jak się bronić

CWE-307 wymienia cztery mechanizmy: rozłączenie po kilku nieudanych próbach, przerwę między próbami, czasową lub trwałą blokadę atakowanego konta oraz wymaganie od użytkownika zadania obliczeniowego ^[3]. CERT Polska zaleca liczenie prób jednocześnie dla konta i dla źródła żądania, egzekwowanie limitów po stronie serwera we wszystkich punktach uwierzytelniania, uwierzytelnianie wieloskładnikowe (multi-factor authentication, MFA) dla kont administracyjnych oraz blokowanie haseł popularnych i znanych z wycieków ^[1].

W WordPressie dokumentacja zaleca kolejne warstwy ^[4]:

• silne, unikatowe hasła i menedżer haseł;
• limit prób logowania i ograniczenia adresów IP dla /wp-login.php;
• uwierzytelnianie dwuskładnikowe (two-factor authentication, 2FA) dla administratorów i passkeys;
• ograniczanie żądań na brzegu sieci, w WAF albo w serwerze;
• przegląd logów nieudanych logowań i czasowe blokowanie źródeł nadużyć.

Atak siłowy nie dotyczy tylko haseł. Kod jednorazowy ma małą przestrzeń wartości, więc także jego weryfikacja wymaga limitu. CERT Polska zaleca ponadto, by ciasteczka sesyjne i tokeny były generowane kryptograficznie bezpiecznie i miały długość uniemożliwiającą ich zgadnięcie ^[1].

Historia i przykłady

Niebezpiecznik 20 listopada 2013 roku opisał atak na konta w serwisie GitHub: serwis zablokował kilka kont, a powodem były słabe hasła właścicieli i botnet z 40 000 unikatowych adresów IP, który próbował logować się, zgadując hasła ^[7].

CERT Polska 30 czerwca 2026 roku opisał podatności w systemie e-BOK firmy KTM System. Według komunikatu CVE-2026-35097 polegała na wymuszaniu hasła złożonego z maksymalnie sześciu cyfr, bez innych znaków, a CVE-2026-35098 na braku ograniczenia liczby i częstotliwości prób logowania ^[5]. Połączenie obu błędów to wzorcowy przypadek: mała przestrzeń haseł i nieograniczona liczba prób.