podrobione Authentication-Results

Podrobiony nagłówek Authentication-Results to próba upozorowania pozytywnej weryfikacji SPF i DKIM — zaufać można tylko wpisom własnego serwera.

Podrobione Authentication-Results jako fałszywy ślad w wiadomości

Podrobione Authentication-Results to zmieniony albo dopisany nagłówek poczty elektronicznej, który ma sprawiać wrażenie, że wiadomość została pomyślnie sprawdzona pod kątem autentyczności. W takim wpisie mogą pojawić się informacje sugerujące prawidłowy wynik SPF, DKIM lub DMARC, mimo że właściwa weryfikacja nie została wykonana przez zaufany serwer odbiorcy. Sam tekst widoczny w nagłówku nie jest dowodem pochodzenia wiadomości. Może zostać przesłany jako część danych przygotowanych przez nadawcę, zmieniony przez złośliwe oprogramowanie albo wprowadzony do obiegu przez źle skonfigurowany system pocztowy.

Authentication-Results jest nagłówkiem technicznym, który powinien być tworzony przez serwer sprawdzający wiadomość. Znaczenie ma więc nie tylko treść pola, lecz także miejsce jego dodania, kolejność nagłówków oraz zgodność z informacjami zapisanymi w innych częściach wiadomości. W praktyce serwer odbiorczy może usunąć wcześniejsze wpisy, oznaczyć je jako niegodne zaufania i dodać własny rezultat kontroli. Jeśli pozostawiono kilka pól o tej samej nazwie, starszy wpis nie musi mieć żadnej wartości dowodowej.

Warto odróżnić samą nazwę nagłówka od wyniku kontroli. Authentication-Results nie jest podpisem kryptograficznym i nie gwarantuje, że osoba lub organizacja wskazana w polu rzeczywiście wysłała wiadomość. Jest to opis czynności wykonanych przez konkretny system pocztowy. Z tego powodu należy analizować pełne nagłówki, a nie tylko pojedynczą linię wyświetloną w programie pocztowym.

Authentication-Results i kontekst SPF, DKIM oraz DMARC

SPF odnosi się do uprawnienia określonych serwerów do wysyłania wiadomości w imieniu danej domeny. Weryfikacja porównuje adres serwera wysyłającego z polityką opublikowaną w systemie nazw domenowych. Pozytywny wynik SPF nie potwierdza jednak, że treść wiadomości nie została zmieniona ani że nadawca z pola „Od” jest zgodny z domeną używaną podczas połączenia. Może zostać potwierdzona wyłącznie określona relacja techniczna.

DKIM wykorzystuje podpis kryptograficzny umieszczony w wiadomości. Serwer odbiorczy pobiera klucz publiczny z domeny wskazanej w podpisie i sprawdza, czy podpis odpowiada wybranym fragmentom wiadomości. Pomyślne sprawdzenie DKIM oznacza, że podpis jest zgodny z treścią objętą podpisem oraz z kluczem opublikowanym dla danej domeny. Nie oznacza automatycznie, że cała wiadomość jest bezpieczna, że adresat jest znany nadawcy ani że każda informacja przedstawiona w innych nagłówkach jest prawdziwa.

DMARC łączy wyniki SPF i DKIM z oceną zgodności domeny widocznej dla odbiorcy. Jeżeli ktoś dopisze tekst „dkim=pass” albo „spf=pass” do wiadomości przed dostarczeniem jej do serwera odbiorczego, taki wpis może wyglądać przekonująco dla osoby wykonującej pobieżną analizę. Nie zastępuje to jednak sprawdzenia podpisu, domeny, adresu IP, łańcucha dostarczenia i wyniku uzyskanego przez serwer, który przyjął wiadomość.

W tym kontekście szczególne znaczenie ma domena uwierzytelniająca, identyfikator selektora DKIM, adres IP nadawcy oraz wynik kontroli DMARC. Należy sprawdzić, czy wskazana domena ma sens w odniesieniu do adresu w polu „Od”, czy podpis obejmuje istotne nagłówki i czy rezultat został zapisany przez zaufany system. Pomocne jest również porównanie dat, identyfikatorów wiadomości i kolejnych wpisów „Received”.

Podrobione Authentication-Results a typowe problemy analityczne

Jednym z częstych problemów jest odczytywanie nagłówków od góry do dołu bez uwzględnienia kierunku dostarczania. W wielu przypadkach najnowsze serwery dopisują swoje dane na początku zestawu nagłówków, a wcześniejsze serwery pozostawiają informacje poniżej. Pojedynczy wpis z wynikiem pozytywnym może więc pochodzić od systemu, który nie miał podstaw do przeprowadzenia rzetelnej kontroli albo sam otrzymał już zmodyfikowane dane.

Niepokój powinny wzbudzić niespójności między Authentication-Results a innymi elementami wiadomości. Przykładem może być pozytywny wynik DKIM przy braku prawidłowego pola DKIM-Signature, domena podpisu różna od domeny nadawcy, adres IP niepasujący do deklarowanej usługi albo rekord SPF wskazujący na inne źródło wysyłki. Znaczenie ma także błędna składnia, nietypowa kolejność parametrów, nieznana nazwa serwera oraz wpisy odnoszące się do domeny, która nie występuje w pozostałych danych.

Innym problemem jest kopiowanie wiadomości do zgłoszenia bez zachowania pełnych nagłówków. Przekazanie samego tematu, treści i adresu nadawcy nie pozwala odtworzyć drogi wiadomości ani ocenić autentyczności wyników. Zdarza się też, że program pocztowy ukrywa część pól, przez co podrobiony wpis jest jedyną informacją widoczną dla użytkownika. Do analizy należy pozyskać oryginalną wiadomość w formacie zachowującym wszystkie nagłówki.

Fałszywy wynik może towarzyszyć wiadomościom nakłaniającym do przelewu, zmiany rachunku, podania hasła, otwarcia załącznika lub wejścia na stronę logowania. Nie powinno się oceniać bezpieczeństwa wyłącznie na podstawie SPF, DKIM albo DMARC. Równie ważne są treść, kontekst kontaktu, oczekiwany sposób komunikacji oraz zgodność danych z wcześniejszą korespondencją.

Jak sprawdzać podrobione Authentication-Results praktycznie

Najpierw należy zachować wiadomość w oryginalnej postaci, bez przeklejania jej do nowego e-maila. Przekazanie jako zwykłego tekstu może usunąć część danych potrzebnych do analizy. Następnie warto wyświetlić pełne nagłówki i odszukać wszystkie pola Authentication-Results, Received, DKIM-Signature, Return-Path oraz informacje dotyczące nadawcy. Nie należy usuwać kopii przed zakończeniem sprawdzania, ponieważ nawet pozornie nieistotne elementy mogą pomóc ustalić źródło problemu.

W kolejnym kroku należy ustalić, który serwer dodał poszczególny wpis. Sama obecność nazwy w parametrze „by” nie wystarcza do potwierdzenia wiarygodności, ale pozwala rozpocząć analizę. Należy porównać nazwę serwera z domeną używaną przez odbiorcę, sprawdzić kolejność dostarczania oraz ocenić, czy wynik odnosi się do aktualnej wiadomości. Jeśli kilka wpisów opisuje tę samą kontrolę, nie powinno się wybierać korzystniejszego rezultatu bez ustalenia, który z nich powstał na granicy zaufanej infrastruktury.

Warto sprawdzić, czy DKIM-Signature obejmuje nagłówki podatne na zmianę, czy wartość „d=” odpowiada oczekiwanej domenie i czy parametr „bh” pasuje do treści. Przy SPF należy zwrócić uwagę na adres IP i domenę używaną do oceny, a przy DMARC na zgodność domeny z adresem widocznym dla odbiorcy. Takie sprawdzenie wymaga ostrożności, ponieważ częściowy wynik może być prawidłowy, a mimo to nie potwierdzać tożsamości podmiotu wskazanego w wiadomości.

Do czasu wyjaśnienia nie należy klikać odnośników, otwierać załączników ani odpowiadać na wiadomość. W sprawach dotyczących płatności lub danych dostępowych bezpieczniej jest potwierdzić prośbę innym, wcześniej znanym kanałem. W przypadku podejrzenia infekcji można odłączyć urządzenie od sieci, zachować materiał dowodowy i skorzystać z pomocy osoby zajmującej się diagnostyką poczty oraz bezpieczeństwem urządzeń.

Kiedy zgłosić podrobione Authentication-Results do serwisu

Do serwisu warto zgłosić sprawę, gdy analiza wskazuje na sprzeczne nagłówki, nieoczekiwaną zmianę ustawień pocztowych, powtarzające się podejrzane wiadomości albo objawy przejęcia konta. Dotyczy to także sytuacji, w której po otwarciu wiadomości pojawiły się nietypowe okna logowania, nowe reguły przekierowania, znikające wiadomości lub korespondencja wysyłana bez wiedzy użytkownika. Takie symptomy mogą wymagać sprawdzenia nie tylko samej wiadomości, lecz także programu pocztowego, przeglądarki, systemu i zapisanych danych dostępowych.

Warszawskie Pogotowie Komputerowe 24/7 może przyjąć do analizy zachowaną wiadomość wraz z pełnymi nagłówkami i pomóc oddzielić rzeczywisty rezultat kontroli od tekstu, który został jedynie dołączony do przekazu. Przed przekazaniem materiału należy zabezpieczyć kopię oryginalnego pliku, zanotować moment otrzymania wiadomości oraz opisać wykonane działania. Nie powinno się zmieniać nagłówków ani usuwać podejrzanych reguł przed wykonaniem kopii, chyba że dalsze działanie stwarza bezpośrednie zagrożenie.

W przypadku przejęcia konta pocztowego potrzebna może być zmiana hasła z zaufanego urządzenia, zakończenie aktywnych sesji, włączenie dodatkowego składnika logowania oraz usunięcie nieznanych metod odzyskiwania dostępu. Należy też sprawdzić, czy nie ustawiono automatycznego przekazywania poczty do obcego adresu. Sama zmiana hasła nie zawsze wystarcza, jeśli urządzenie zostało zainfekowane albo dane dostępowe zostały zapisane w niebezpiecznym miejscu.

Podstawowa zasada pozostaje prosta: podrobione Authentication-Results nie staje się wiarygodne tylko dlatego, że zawiera słowa „pass”, nazwę znanej domeny lub opis poprawnego sprawdzenia. Liczy się serwer, który wykonał kontrolę, możliwość odtworzenia przebiegu dostarczenia oraz zgodność wyniku z podpisem i rzeczywistą konfiguracją domeny. Dopiero połączenie tych informacji pozwala ocenić, czy wiadomość zasługuje na zaufanie.