Zagrożenia związane z atakiem polegającym na sondowaniu

Podczas przeprowadzania audytu aplikacji sieciowych nasi eksperci zidentyfikowali pewną podatność. Zobaczcie, gdzie leży problem oraz jak można go rozwiązać.

Niedawno eksperci z naszego zespołu Kaspersky Blockchain Security testowali platformę łańcucha bloków pod kątem luk w zabezpieczeniach. Odkryli, że proces odzyskiwania hasła do platformy był podatny na atak polegający na sprawdzaniu nazw użytkownika. Producenci aplikacji sieciowych muszą mieć świadomość tego rodzaju ataku oraz zagrożeń, jakie się z nim wiążą.

Na czym polega atak wykorzystujący sondowanie?

Aplikacje sieciowe wykorzystujące do autoryzacji hasło i login zwykle zawierają kilka komponentów, które odwołują się do bazy danych użytkowników. Należy do nich: okno wprowadzania loginu (z oczywistych powodów), formularz rejestracyjny (aby zapobiegać duplikowaniu nazw użytkowników) oraz strony służące do resetowania hasła (aby mieć pewność, że dane konto naprawdę istnieje). Jeśli producenci aplikacji sieciowych zaimplementują te funkcje przy zastosowaniu niewystarczającego poziomu bezpieczeństwa, atakujący mogą użyć ich do określenia, czy dana nazwa użytkownika istnieje w bazie danych.

Dawniej programiści implementowali wspomniane funkcje bez żadnej ochrony, dzięki czemu atakujący mogli wykorzystywać listy zawierające nazwy użytkowników oraz programu, który wprowadzał je po kolei. Z czasem, aby uchronić się przed potencjalnymi atakami, programiści zaczęli stosować sztuczki ochronne takie jak captcha oraz ograniczać liczbę prób zalogowania się, jak również zaczęli stosować gwiazdki lub inne sposoby w celu ukrycia pewnych szczegółów reakcji.

We współczesnych aplikacjach sieciowych okno logowania zwykle jest w ten sposób chronione. Jednak zdarza się, że takich zabezpieczeń brakuje w formularzach rejestracyjnych i na stronach służących do resetowania hasła. Co więcej, programiści nie zawsze biorą pod uwagę, że to, czy dany użytkownik naprawdę istnieje w bazie, można określić poprzez analizę czasu odpowiedzi serwera. Na przykład jeśli nazwa użytkownika znajdowała się w bazie danych, serwer reagował w 2 milisekundy. Jeśli nie, reakcja trwała dwa razy dłużej — 4 milisekundy. Dla człowieka różnica ta jest niemożliwa do zauważenia, ale dla wspomnianych wyżej narzędzi do numeracji to nie problem.

Zagrożenia ze strony ataku polegającego na sprawdzaniu obecności nazwy użytkownika w bazie

Atak ten umożliwia hakerowi sprawdzenie, czy dana nazwa użytkownika istnieje w bazie danych. Nie będzie mógł on się natychmiast zalogować, ale otrzyma połowę potrzebnych informacji. Na przykład aby przygotować atak siłowy, zamiast wyszukiwać parę: login/hasło, musi tylko dopasować hasło do zweryfikowanej nazwy użytkownika. Dzięki temu oszczędza czas i nakład pracy.

Ponadto należy pamiętać, że w niemal wszystkich usługach nazwą użytkownika jest adres e-mail. W efekcie użytkownik ma zwykle taki sam login dla wielu stron, a nie wszystkie z nich równie poważnie traktują kwestie bezpieczeństwa; informacje o wycieku kombinacji loginu i hasła nie są rzadkością. Zbiory danych łączące dane uzyskane w ramach takich wycieków są dostępne na forach dyskusyjnych hakerów. Niestety ludzie często używają tych samych haseł na różnych stronach internetowych, a zatem wiedząc, że nazwa użytkownika istnieje na danej stronie, atakujący może zajrzeć do takiego zbioru w poszukiwaniu hasła, które może pasować na innych stronach — i wypróbować takiej kombinacji.

Osoby stojące za phishingiem ukierunkowanym często stosują ataki polegające na sondowaniu w fazie rekonesansu. Po upewnieniu się, że ich cel ma konto w danym serwisie, mogą wysłać wiadomość e-mail, która rzekomo została wysłana przez ten serwis. Nakazują w niej użytkownikowi zmianę hasła poprzez użycie łącza, które w rzeczywistości prowadzi do strony phishingowej. Oczywiście wyglądem przypomina ona oryginalną. Gdy niczego niepodejrzewający klient wprowadza nowe hasło, musi również potwierdzić dotychczasowe — które wpada wprost w ręce przestępców.

Jak zapewnić sobie bezpieczeństwo przed tym atakiem

W jaki sposób współczesne strony reagują na wysłanie formularza resetowania hasła? Zamiast wyświetlać komunikat w stylu: „Wysłaliśmy do Ciebie łącze umożliwiające zresetowanie hasła” lub „Ten adres e-mail nie znajduje się w naszej bazie”, informują na przykład, że: „Jeśli taki adres e-mail istnieje w naszej bazie, wyślemy Ci wiadomość z łączem”. Innymi słowy strony nie potwierdzają ani nie zaprzeczają, że taka nazwa użytkownika istnieje. Celem takiego podejścia jest ochrona przed wspomnianymi atakami.

Z drugiej strony nie musisz wiedzieć, że w oknie logowania wprowadzone zostało niepoprawne hasło lub że w systemie nie istnieje taki użytkownik. Wystarczy Ci informacja, że kombinacja loginu i hasła nie została znaleziona. Nie jest to idealne z punktu widzenia użytkownika — ja na przykład irytuję się, gdy zapomnę, którego adresu e-mail użyłem podczas rejestracji, ale też nie mam pewności co do wprowadzonego hasła, a strona nie podpowiada, które pole zawiera niepoprawne dane. Jednak bezpieczeństwo zawsze wiąże się z pewnymi niedogodnościami, a w tym przypadku te drobne przeszkody można zaakceptować.

Oczywiście konieczne jest również używanie systemu captcha i ograniczeń prób logowania. Oprócz tego w celu zapewnienia aplikacjom sieciowym bezpieczeństwa zalecamy przeprowadzenie audytu przez firmę zewnętrzną. Jeśli działasz w obszarze technologii blockchain, nasz dział Kaspersky Blockchain Security może Ci pomóc w przeprowadzeniu analizy bezpieczeństwa aplikacji sieciowych.

Porady