brak szyfrowania transmisji danych uwierzytelniających

Brak szyfrowania transmisji danych uwierzytelniających to poważna luka narażająca hasła i tokeny na przechwycenie podczas przesyłania.

Brak szyfrowania transmisji danych uwierzytelniających – czym jest to zagrożenie

Brak szyfrowania transmisji danych uwierzytelniających oznacza, że informacje używane do potwierdzania tożsamości są przesyłane w formie możliwej do odczytania albo w sposób niewystarczająco zabezpieczony. Dotyczy to między innymi haseł, identyfikatorów użytkowników, kodów jednorazowych, tokenów sesyjnych, kluczy dostępowych oraz innych danych, które pozwalają uzyskać dostęp do konta lub usługi. Problem nie musi oznaczać, że dane są przechowywane jawnie. Wystarczy, że zostaną odsłonięte na etapie przechodzenia między urządzeniem a serwerem.

W prawidłowo zaprojektowanym połączeniu dane uwierzytelniające powinny być chronione przed odczytaniem, zmianą i podstawieniem przez osoby nieuprawnione. Szyfrowanie tworzy warstwę, która utrudnia zrozumienie przechwyconego strumienia. Samo szyfrowanie nie rozwiązuje jednak wszystkich problemów. Potrzebna jest także poprawna weryfikacja drugiej strony połączenia, bezpieczna konfiguracja protokołu, właściwe zarządzanie certyfikatami oraz ochrona przed ponownym wykorzystaniem przechwyconych tokenów.

Do ujawnienia transmisji może dojść w sieci bezprzewodowej, w publicznym punkcie dostępu, w niezabezpieczonym segmencie sieci lokalnej, na zainfekowanym urządzeniu pośredniczącym albo podczas korzystania ze starego protokołu. W takiej sytuacji osoba obserwująca ruch może próbować odtworzyć logowanie, przejąć aktywną sesję lub zebrać informacje przydatne do dalszego ataku. Ryzyko rośnie szczególnie wtedy, gdy to samo hasło jest używane w wielu usługach.

Brak szyfrowania danych uwierzytelniających w kontekście protokołów

Znaczenie problemu najlepiej widać przy porównaniu różnych sposobów komunikacji. Połączenie wykorzystujące zwykły, nieszyfrowany protokół może przesyłać formularz logowania, nagłówki żądania lub dane sesji w postaci możliwej do przeanalizowania. Osoba mająca dostęp do odpowiedniego fragmentu ruchu nie musi znać hasła z innego źródła, ponieważ może uzyskać je bezpośrednio z transmisji albo przejąć element pozwalający na utrzymanie zalogowanej sesji.

Połączenie chronione szyfrowaniem transportowym ogranicza możliwość odczytu treści przez obserwatora. W przeglądarce zwykle sygnalizuje się je symbolem kłódki i adresem rozpoczynającym się od https, ale sam wygląd interfejsu nie powinien być jedynym kryterium oceny. Ważna jest poprawność certyfikatu, zgodność nazwy hosta, aktualność używanego protokołu oraz brak ostrzeżeń dotyczących zaufania. Podobne zasady obowiązują przy poczcie elektronicznej, zdalnym dostępie, panelach administracyjnych i aplikacjach mobilnych.

Warto rozróżnić szyfrowanie transmisji od szyfrowania przechowywanych danych. Pierwsze chroni informacje w drodze między punktami komunikacji. Drugie zabezpiecza pliki, bazy danych lub kopie zapasowe zapisane na dysku. Zastosowanie tylko jednego z tych mechanizmów pozostawia drugą część procesu bez ochrony. Nie należy również utożsamiać szyfrowania z haszowaniem. Haszowanie służy przede wszystkim do jednokierunkowego przekształcania wartości, natomiast szyfrowanie pozwala na odzyskanie treści przez uprawnioną stronę posiadającą właściwy klucz.

Różnica występuje także między poufnością a integralnością. Poufność ma ograniczać możliwość odczytu danych, a integralność ma ujawnić albo uniemożliwić nieuprawnioną zmianę komunikatu. Dobrze skonfigurowane rozwiązanie powinno uwzględniać oba aspekty, ponieważ sama nieczytelność danych nie gwarantuje, że nie zostały one podmienione po drodze.

Brak szyfrowania transmisji uwierzytelniających a typowe problemy

Jednym z najczęstszych objawów jest możliwość zalogowania się do panelu przez adres zaczynający się od http zamiast https. Podobne ostrzeżenie może pojawić się przy formularzu, który znajduje się na stronie szyfrowanej, lecz wysyła dane do niezabezpieczonego adresu. W takim przypadku sama strona może wyglądać poprawnie, jednak moment przesłania formularza pozostaje narażony. Problem bywa ukryty również w starszych programach, które korzystają z nieaktualnych bibliotek sieciowych lub wymuszają przestarzały sposób logowania.

Do zagrożeń należy zaliczyć przechwycenie ciasteczka sesyjnego. Jeżeli token sesji nie jest odpowiednio chroniony, przejęcie go może pozwolić na korzystanie z konta bez ponownego wpisywania hasła. Ryzyko zwiększa brak oznaczenia ciasteczka jako dostępnego wyłącznie przez bezpieczne połączenie, brak ograniczenia do transmisji z użyciem protokołu szyfrowanego oraz zbyt długi czas ważności sesji.

Innym problemem jest przesyłanie haseł w ramach nieszyfrowanych usług pocztowych, komunikatorów albo narzędzi zdalnego dostępu. Czasem użytkownik widzi tylko komunikat o błędnym logowaniu i nie ma świadomości, że aplikacja korzysta z niebezpiecznego trybu zgodności. W środowisku domowym trudność może powodować stary router, błędne ustawienia certyfikatów, nieaktualna przeglądarka lub oprogramowanie przechwytujące ruch. W urządzeniach firmowych dodatkowe znaczenie ma sposób filtrowania i rejestrowania komunikacji.

Konsekwencje obejmują przejęcie konta, odczyt korespondencji, zmianę ustawień, podszywanie się pod użytkownika oraz wykorzystanie jednego wycieku do ataku na inne usługi. Jeżeli dojdzie do przechwycenia hasła używanego ponownie w kilku miejscach, pojedynczy incydent może rozszerzyć się na wiele kont. Z tego powodu nie należy ograniczać analizy wyłącznie do programu, w którym zauważono pierwszą nieprawidłowość.

Brak szyfrowania transmisji danych uwierzytelniających – praktyczne wskazówki

Najprostszym działaniem jest sprawdzenie adresu usługi przed wpisaniem hasła. Należy zwrócić uwagę na obecność szyfrowanego połączenia, poprawność certyfikatu i ewentualne komunikaty ostrzegawcze. Nie powinno się zatwierdzać wyjątków certyfikatu bez ustalenia ich przyczyny, zwłaszcza gdy dotyczą panelu logowania, poczty lub zdalnego dostępu. W przypadku nieznanej sieci bezprzewodowej rozsądne jest ograniczenie logowania do usług, które korzystają z prawidłowo skonfigurowanej ochrony transportowej.

Hasła powinny być unikatowe dla każdej ważnej usługi, a tam, gdzie jest to możliwe, należy włączyć dodatkowy składnik uwierzytelniania. Nie zastępuje on szyfrowania transmisji, lecz może ograniczyć skutki poznania samego hasła. Po podejrzeniu niebezpiecznej komunikacji trzeba zmienić hasło w bezpiecznym połączeniu, unieważnić aktywne sesje i sprawdzić historię logowań. Warto również zweryfikować, czy nie pojawiły się nowe reguły przekierowania poczty, nieznane urządzenia lub dodatkowe metody odzyskiwania konta.

Po stronie urządzenia przydatna jest aktualizacja systemu, przeglądarki, routera i aplikacji odpowiadających za komunikację. Należy usunąć programy, których pochodzenie jest nieznane, oraz przeskanować komputer, gdy występują przekierowania, nietypowe ostrzeżenia certyfikatów albo powtarzające się próby logowania. Przy ocenie konfiguracji można sprawdzić, czy aplikacja używa aktualnego protokołu, czy odrzuca starsze warianty oraz czy nie przesyła danych uwierzytelniających w parametrach adresu.

Warto zachować ostrożność podczas testów. Przechwytywanie własnej transmisji może być przydatne diagnostycznie, ale nie powinno obejmować cudzych kont ani cudzej komunikacji. Analizę należy prowadzić na urządzeniach i usługach, do których istnieje uprawniony dostęp. Jeżeli nie da się ustalić, gdzie następuje odsłonięcie danych, przydatne może być porównanie zachowania programu w kilku zaufanych sieciach oraz sprawdzenie logów po stronie usługi.

Kiedy zgłosić brak szyfrowania transmisji uwierzytelniających do serwisu

Zgłoszenie problemu jest wskazane, gdy przeglądarka stale wyświetla ostrzeżenie o certyfikacie, formularz logowania przekierowuje do niezabezpieczonego adresu, aplikacja nie pozwala wybrać bezpiecznego trybu albo połączenie działa wyłącznie po wyłączeniu ochrony. Pomocy wymaga również sytuacja, w której pojawiają się nieznane logowania, samoczynne wylogowania, zmiany ustawień konta lub podejrzenie przejęcia sesji. Jeżeli kilka urządzeń wykazuje ten sam objaw, należy uwzględnić także router, punkt dostępowy i konfigurację sieci.

Przed przekazaniem urządzenia nie powinno się zapisywać haseł w wiadomości ani udostępniać kodów jednorazowych. Wystarczy opisać objawy, wskazać program, moment wystąpienia problemu i rodzaj używanego połączenia. Przydatne mogą być zrzuty komunikatów bez widocznych danych logowania. W razie podejrzenia aktywnego przejęcia konta w pierwszej kolejności należy użyć bezpiecznego urządzenia do zmiany hasła i zakończenia pozostałych sesji.

W Warszawie diagnostykę takich problemów można zgłosić do Warszawskiego Pogotowia Komputerowego 24/7. Naprawy są z reguły realizowane do 3 dni roboczych, zależnie od rodzaju usterki i zakresu koniecznych czynności. W ramach sprawdzenia może zostać oceniona konfiguracja systemu, przeglądarki, karty sieciowej, routera oraz aplikacji korzystających z logowania. Po usunięciu przyczyny zalecane jest ponowne sprawdzenie certyfikatów, sposobu zestawiania połączenia i historii aktywności konta.