Spoofing wykorzystuje rozszerzenie ESMTP tak samo jak podstawowe SMTP — samo rozszerzenie nie chroni przed podszyciem.
ESMTP nie potwierdza tożsamości nadawcy
Spoofing w kontekście ESMTP oznacza podszywanie się pod innego nadawcę wiadomości elektronicznej. ESMTP, czyli rozszerzony wariant protokołu SMTP, służy do przekazywania poczty między klientem a serwerem albo między serwerami pocztowymi. Rozszerzenia są ogłaszane przez serwer po komendzie EHLO. Mogą dodawać między innymi obsługę uwierzytelniania, szyfrowania, większych wiadomości czy przesyłania załączników, ale samo użycie ESMTP nie jest dowodem, że nadawca wiadomości jest tym, za kogo się podaje.
Podczas transmisji poczty występuje kilka różnych informacji o nadawcy. Komenda MAIL FROM określa tak zwanego nadawcę kopertowego, wykorzystywanego między innymi do obsługi zwrotek. W treści wiadomości znajduje się natomiast nagłówek From:, który jest wyświetlany użytkownikowi jako adres nadawcy. Te wartości mogą być różne. Osoba analizująca wiadomość musi więc sprawdzić zarówno dane koperty SMTP, jak i nagłówki, a także dodatkowe ślady zapisane przez serwery pośredniczące.
Jak wygląda podszycie w przebiegu dostarczania wiadomości
W najprostszym scenariuszu system wysyłający przekazuje serwerowi pocztowemu fałszywy adres w polu MAIL FROM albo wpisuje podrobiony adres w nagłówku From:. Historyczny model SMTP zakładał zaufanie do informacji przekazywanych przez klienta, dlatego adres widoczny w wiadomości nie jest automatycznie poświadczeniem prawa do korzystania z danej domeny. Serwer może przyjąć wiadomość do dalszego przetwarzania, odrzucić ją, oznaczyć jako podejrzaną albo przekazać do analizy antyspamowej.
Znaczenie ma także etap połączenia. Komendy EHLO, MAIL FROM, RCPT TO i DATA opisują sesję SMTP, lecz nie tworzą same z siebie mechanizmu wiążącego wiadomość z właścicielem domeny. Rozszerzenie AUTH może wymagać uwierzytelnienia klienta, ale dotyczy dostępu do konkretnego serwera lub konta i nie oznacza, że każdy adres wpisany w nagłówku From: został zweryfikowany. Z kolei STARTTLS szyfruje połączenie po jego ustanowieniu, lecz szyfrowanie transportu nie potwierdza prawdziwości adresu nadawcy.
SPF, DKIM i DMARC jako niezależne warstwy weryfikacji
Ograniczanie spoofingu domeny zwykle opiera się na mechanizmach DNS i podpisywaniu wiadomości. SPF, opisany w RFC 7208, pozwala domenie opublikować w DNS regułę wskazującą, jakie serwery mogą wysyłać pocztę dla danej domeny. Serwer odbiorczy porównuje adres IP systemu wysyłającego z polityką SPF. Wynik SPF dotyczy jednak przede wszystkim nadawcy kopertowego, czyli domeny użytej w mechanizmie przekazywania zwrotek, a niekoniecznie adresu wyświetlanego w polu From:.
DKIM, opisany w RFC 6376, dodaje do wiadomości podpis kryptograficzny. Serwer odbiorcy pobiera klucz publiczny z DNS domeny wskazanej w parametrze d= podpisu i sprawdza, czy podpis pasuje do treści oraz wybranych nagłówków. Pomyślna weryfikacja DKIM potwierdza integralność podpisanych elementów i udział domeny podpisującej, ale sama nie musi oznaczać zgodności z adresem widocznym dla użytkownika. DMARC, opisany w RFC 7489, łączy wynik SPF lub DKIM z tak zwaną zgodnością domen. Domena publikująca politykę DMARC określa również, jak odbiorca powinien postąpić przy nieudanej kontroli, na przykład monitorować wiadomość, umieścić ją w spamie albo odrzucić.
Ślady techniczne przy analizie podejrzanej poczty
Analiza wiadomości powinna obejmować pełne nagłówki, a nie tylko nazwę i adres pokazane w programie pocztowym. Nagłówki Received: są dopisywane przez kolejne serwery uczestniczące w przekazywaniu wiadomości. Zwykle należy czytać je od dołu do góry, ponieważ najniższy wpis opisuje wcześniejszy etap trasy, a kolejne wpisy powstają później. Trzeba jednak pamiętać, że wpisy dodane przed wejściem wiadomości do zaufanej infrastruktury mogą zostać sfałszowane. Większą wartość dowodową mają informacje dopisane przez własny serwer odbiorczy oraz przez zaufane systemy pośredniczące.
W praktyce warto porównać domenę z nagłówka From: z domeną nadawcy kopertowego, wynikiem SPF, domeną podpisu DKIM oraz wynikiem wyrównania DMARC. Nieudany SPF nie zawsze dowodzi oszustwa, ponieważ przyczyną może być błędna konfiguracja, przekazywanie wiadomości lub niepełna lista uprawnionych serwerów. Pomyślny SPF również nie wystarcza, jeśli wiadomość nie spełnia zgodności DMARC albo zawiera nieautoryzowany adres w nagłówku. Diagnostyka wymaga więc oceny całego łańcucha: adresu serwera łączącego się z odbiorcą, parametrów sesji ESMTP, nagłówków, podpisu kryptograficznego i polityki domeny zapisanej w DNS.
