Dlaczego hasła domyślne mogą otworzyć atakującym bezpośredni dostęp do Państwa systemów

01 Tło techniczne

Jedno niebezpieczne hasło może wystarczyć, by atakujący przejął kontrolę nad systemem. W praktyce niebezpieczne hasła pojawiają się przede wszystkim w dwóch sytuacjach:

Po pierwsze, może się zdarzyć, że fabryczne dane dostępowe po uruchomieniu nie zostaną zmienione. Wiele systemów, takich jak routery, kamery sieciowe, bazy danych czy panele administracyjne aplikacji internetowych, jest dostarczanych z fabrycznie skonfigurowanym kontem użytkownika i hasłem domyślnym, np. „admin/admin” lub „root/12345”. Są one przeznaczone wyłącznie do pierwszej konfiguracji i zaraz potem powinny zostać zastąpione indywidualnymi danymi dostępowymi.

Po drugie, użytkownicy wybierają czasem hasła łatwe do odgadnięcia lub znane już z wcześniejszych wycieków danych. Atakujący mogą automatycznie używać takich haseł do prób logowania, korzystając z publicznie dostępnych list haseł. Przykładami są proste ciągi cyfr, takie jak „123456”, łatwe do przewidzenia hasła, takie jak „passwort1”, albo hasła ujawnione już we wcześniejszych wyciekach. Do najbardziej znanych zbiorów należy „Pwned Passwords” serwisu Have I Been Pwned, zawierający ujawnione hasła z licznych opublikowanych wycieków danych.

Obie sytuacje prowadzą ostatecznie do tego samego: atakujący nie musi łamać hasła, bo już je zna albo może je wywnioskować z niewielkiego zbioru możliwych haseł. Choć przyczyny są różne, w obu przypadkach powstają podatności w uwierzytelnianiu, których można uniknąć dzięki odpowiednim środkom organizacyjnym i technicznym.

02 Ryzyka i konsekwencje

Niezmienione dostępy domyślne i niewystarczające wymagania dotyczące haseł należą do najpoważniejszych podatności w obszarze uwierzytelniania. Odzwierciedla to również OWASP Top 10 – międzynarodowo uznane zestawienie najpoważniejszych zagrożeń bezpieczeństwa aplikacji internetowych: obie podatności przypisano do kategorii A07:2021 „Identification and Authentication Failures”. Choć ich przyczyny są różne, ostatecznie prowadzą do tego samego krytycznego problemu: nieuprawnionego dostępu do systemów i danych.

Aby wykorzystać te podatności, atakujący stosują m.in. metody zautomatyzowane. Przy credential stuffingu używa się danych logowania z wcześniejszych wycieków, a przy password sprayingu popularne hasła są testowane na wielu kontach użytkowników. To, czy taki atak się powiedzie, zależy m.in. od tego, czy system ogranicza liczbę prób logowania lub stosuje dodatkowe zabezpieczenia, np. uwierzytelnianie wieloskładnikowe. Szczególnie poważne ryzyko stanowią niezmienione dostępy domyślne, ponieważ atakujący często bez większego wysiłku znajdą fabryczne dane dostępowe w publicznie dostępnej dokumentacji producenta lub innych ogólnodostępnych źródłach. Niezmienione dostępy domyślne występują szczególnie często w systemach testowych, interfejsach kopii zapasowych i rzadko używanych dostępach administracyjnych.

Jeśli uwierzytelnienie się powiedzie, atakujący uzyskuje dostęp do danego konta użytkownika lub panelu administracyjnego. W zależności od uprawnień może zmieniać konfigurację, przeglądać dane lub wykorzystać system jako punkt wyjścia do kolejnych ataków.

Z punktu widzenia ochrony danych art. 32 RODO zobowiązuje administratorów do ochrony systemów przetwarzania danych przed nieuprawnionym dostępem za pomocą odpowiednich środków technicznych i organizacyjnych. Miarą przy doborze tych środków jest aktualny stan wiedzy technicznej. Wskazówek dostarczają w szczególności zalecenia niemieckiego Federalnego Urzędu ds. Bezpieczeństwa Informacji (BSI). Należą do nich m.in. stosowanie indywidualnych i wystarczająco silnych haseł, wymiana haseł domyślnych oraz środki służące wykrywaniu ujawnionych haseł. Uzupełniająco można wytyczne amerykańskiego Narodowego Instytutu Standaryzacji i Technologii (NIST) wziąć pod uwagę. Zalecają one co najmniej 15 znaków przy logowaniu wyłącznie hasłem i co najmniej 8 znaków w połączeniu z drugim składnikiem uwierzytelniania; długość hasła ma przy tym większe znaczenie niż sztywne wymogi dotyczące jego złożoności.

Jeśli wykorzystanie takiej podatności prowadzi do nieuprawnionego ujawnienia, zmiany lub utraty danych osobowych, z reguły dochodzi do naruszenia ochrony danych osobowych.

03 Jak wykryć tę lukę

Wykrywanie tej podatności obejmuje dwa obszary, ponieważ niezmienione dostępy domyślne i niebezpieczne hasła mają różne przyczyny, a więc wymagają różnych kontroli i środków zaradczych. To rozróżnienie znajduje odzwierciedlenie również w Common Weakness Enumeration (CWE) , międzynarodowo uznanym katalogu klasyfikacji podatności: niezmienione dostępy domyślne przypisano do CWE-798 („Use of Hard-coded Credentials”), a niewystarczające wymagania dotyczące haseł do CWE-521 („Weak Password Requirements”).

1. Kontrola dostępów domyślnych (CWE-798)

Najpierw należy sprawdzić w dokumentacji producenta, czy dany system ma udokumentowane fabryczne dane dostępowe. Następnie trzeba skontrolować, czy te dane nadal działają. Jeśli tak, dostępy domyślne nie zostały zastąpione i podatność występuje.

2. Kontrola jakości haseł (CWE-521)

Jakość pojedynczego hasła można sprawdzić w bazie Pwned Passwords bez ujawniania go w postaci jawnej. W tym celu lokalnie oblicza się skrót SHA-1, a do interfejsu przesyła tylko jego fragment. Ta tzw. metoda k-anonimowości umożliwia weryfikację bez przesyłania samego hasła do serwisu:

bash echo -n „haslo” | sha1sum

Następnie można wysłać zapytanie z pierwszymi pięcioma znakami skrótu:

bash curl https://api.pwnedpasswords.com/range/5BAA6

Jeśli pozostała część Państwa skrótu pojawi się na liście odpowiedzi, hasło znalazło się już w którymś z wycieków danych.

Podatność występuje, jeśli dostępy domyślne są nadal używane lub aktywne hasło jest już znane jako ujawnione.

04 Jak usunąć tę podatność

Sposób usunięcia podatności zależy od jej przyczyny. Niezmienione dostępy domyślne trzeba trwale wyeliminować, a niebezpieczne lub już ujawnione hasła zastąpić bezpiecznymi.

1. Usunięcie dostępów domyślnych (CWE-798)

2. Zastąpienie niebezpiecznych haseł (CWE-521)

3. Dodatkowe zabezpieczenia

Po wdrożeniu zmian należy przeprowadzić ponowną kontrolę. Podatność uznaje się za usuniętą dopiero wtedy, gdy nie są aktywne żadne dostępy domyślne, a wszystkie objęte nią konta mają indywidualne, wystarczająco silne i nieujawnione hasła.