spoofing bez uwierzytelnienia

Spoofing bez uwierzytelnienia jest możliwy dzięki brakowi wdrożonych mechanizmów SPF, DKIM i DMARC.

Architektura protokołu SMTP a podatność na fałszowanie tożsamości nadawcy

Protokół Simple Mail Transfer Protocol (SMTP), zdefiniowany pierwotnie w dokumencie RFC 821 w 1982 roku, został zaprojektowany z myślą o sprawnym przekazywaniu wiadomości tekstowych w zaufanych sieciach akademickich i wojskowych. W swojej podstawowej, nieszyfrowanej specyfikacji nie implementuje on natywnych mechanizmów kryptograficznego uwierzytelniania serwera nadającego ani weryfikacji deklarowanej tożsamości nadawcy. Spoofing bez uwierzytelnienia to w konsekwencji technika ataku polegająca na celowym preparowaniu nagłówków wiadomości e-mail w taki sposób, aby odbiorca oraz jego oprogramowanie pocztowe interpretowały fałszywy adres jako wiarygodne źródło pochodzenia. W klasycznej komunikacji serwer-serwer (MTA-MTA), urządzenie inicjujące połączenie na porcie 25 wysyła komendę HELO lub EHLO, po której następuje komenda MAIL FROM. Ta ostatnia określa adres zwrotny używany do raportowania błędów (tzw. envelope sender, Return-Path), który może całkowicie różnić się od adresu zawartego w nagłówku "From:" prezentowanego przez klienta pocztowego (MUA - Mail User Agent) użytkownikowi końcowemu.

Brak wbudowanej autoryzacji oznacza, że każdy serwer podłączony do globalnej sieci Internet może zadeklarować dowolną domenę w polu nagłówka "From:". Atakujący, wykorzystując ogólnodostępne skrypty lub celowo przekonfigurowane serwery Postfix, Exim czy Sendmail, mogą wstrzykiwać spreparowane pakiety danych bezpośrednio do kolejek docelowych serwerów pocztowych. Dopóki infrastruktura domeny docelowej nie weryfikuje spójności pomiędzy adresem IP serwera nadającego a listą autoryzowanych hostów przypisanych do domeny w systemie DNS, wiadomość taka przejdzie przez początkowe filtry antyspamowe. Spoofing bez uwierzytelnienia opiera się wyłącznie na zaufaniu wbudowanym w przestarzałą konstrukcję SMTP, wykorzystując brak wymuszonych polityk kontroli dostępu. Implementacja nowszych rozszerzeń, takich jak ESMTP (Extended SMTP) oraz protokołów TLS (Transport Layer Security) do szyfrowania sesji, zabezpieczyła warstwę transportową przed podsłuchem, ale nie rozwiązała problemu uwierzytelniania samej domeny nadawcy na poziomie logicznym wiadomości.

Mechanizmy obronne DNS i techniczna analiza brakujących zabezpieczeń

Możliwość przeprowadzenia udanego ataku opiera się na braku lub błędnej konfiguracji trzech kluczowych rekordów w strefie DNS domeny nadawcy: SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) oraz DMARC (Domain-based Message Authentication, Reporting, and Conformance). Sender Policy Framework, publikowany jako rekord TXT, stanowi białą listę adresów IP oraz bloków CIDR upoważnionych do wysyłania poczty w imieniu danej domeny. W przypadku braku tego rekordu, serwer odbierający nie dysponuje mechaniczną metodą sprawdzenia, czy host przekazujący wiadomość jest autoryzowany. Nawet jeśli rekord SPF istnieje, ustawienie polityki na wartość "~all" (SoftFail) lub "?all" (Neutral) sprawia, że spreparowane wiadomości są jedynie oznaczane wyższą punktacją spamową, zamiast być odrzucane na etapie sesji SMTP. Z kolei brak implementacji DKIM ułatwia modyfikację treści wiadomości w trakcie przesyłania. DKIM wykorzystuje kryptografię asymetryczną, najczęściej z algorytmami RSA lub Ed25519, do generowania podpisu cyfrowego nagłówków i zawartości e-maila. Klucz prywatny znajduje się na autoryzowanym serwerze pocztowym, a klucz publiczny jest udostępniany w rekordzie DNS. Brak podpisu DKIM powoduje, że odbiorca nie ma gwarancji integralności wiadomości ani faktu, że rzeczywiście opuściła ona serwery przypisane do właściciela domeny.

Kluczowym ogniwem weryfikującym jest polityka DMARC, która wymusza tzw. "alignment" (zgodność). DMARC sprawdza, czy domena widoczna w nagłówku "From:" pokrywa się z domeną używaną w autoryzacji SPF lub z domeną podpisującą w standardzie DKIM. Jeśli infrastruktura nadawcy nie posiada wdrożonego rekordu DMARC z restrykcyjną polityką "p=quarantine" lub "p=reject", serwery docelowe opierają się na heurystycznych silnikach analitycznych (na przykład SpamAssassin lub Rspamd). Złośliwe oprogramowanie i botnety rozsyłające kampanie phishingowe omijają systemy punktacji heurystycznej poprzez wykorzystywanie czystych sieci botów, co skutkuje dostarczeniem nieuwierzytelnionych, fałszywych e-maili do skrzynki odbiorczej. Rozwiązania klasy Secure Email Gateway (SEG) próbują minimalizować to ryzyko poprzez inspekcję treści, jednak bez mechanizmów SPF, DKIM i DMARC weryfikacja zależy wyłącznie od probabilistycznej analizy behawioralnej, co stanowi fundamentalną podatność całego systemu pocztowego.

Analiza powłamaniowa i interpretacja nagłówków protokołu transportowego

Podczas weryfikacji incydentów informatycznych inżynierowie systemowi muszą polegać na surowym kodzie źródłowym wiadomości e-mail, analizując sekwencję nagłówków "Received". Nagłówki te dodawane są kaskadowo przez każdy kolejny węzeł transportowy przekazujący wiadomość od punktu nadania do skrzynki docelowej. W przypadku udanego spoofingu bez uwierzytelnienia ścieżka routingu zapisana w nagłówkach "Received" zazwyczaj wykazuje pochodzenie z dynamicznych pul adresowych dostawców ISP, chmur obliczeniowych o niskiej reputacji lub serwerów proxy znajdujących się na listach RBL (Real-time Blackhole List). Ważnym polem w analizie jest nagłówek "Authentication-Results", dodawany przez docelowy serwer MTA przed dostarczeniem e-maila do skrzynki lokalnej (Maildir/mbox). Znalezienie tam wartości w postaci "spf=none", "dkim=none" lub "dmarc=none" jest dowodem technicznym na to, że domena zadeklarowana jako nadawca nie wdrożyła wymaganych procedur weryfikacji tożsamości.

Z punktu widzenia systemów operacyjnych użytkowników brak weryfikacji poświadczeń stanowi pierwszy wektor w atakach typu Business Email Compromise (BEC) lub dystrybucji załączników z makrami VBA czy złośliwymi plikami wykonywalnymi. Użytkownik w aplikacji klienckiej widzi poprawny adres, na przykład należący do administracji własnej firmy. Zatajenie rozbieżności pomiędzy polem "From:" a rzeczywistym adresem kopertowym prowadzi do uruchomienia kodu, który dokonuje wstrzyknięcia poleceń do procesów systemowych. Rezultatem jest naruszenie spójności środowiska Windows lub Linux, modyfikacja rejestru, szyfrowanie przestrzeni dyskowej lub instalacja ukrytych procesów komunikujących się z serwerami Command and Control (C2). Diagnostyka takiego zdarzenia wymaga rozdzielenia problemu braku autoryzacji sieciowej na poziomie protokołu pocztowego od jego bezpośredniego rezultatu widocznego na poziomie urządzenia końcowego.

Oddzielenie problematyki protokołów sieciowych od usług sprzętowych

Wdrażanie mechanizmów SPF, DKIM i DMARC dla domen firmowych oraz audyty bezpieczeństwa poczty elektronicznej to zadania z zakresu administracji systemami IT oraz inżynierii bezpieczeństwa sieci. Operacje te w całości wykraczają poza kompetencje i profil placówek naprawiających usterki urządzeń osobistych, takich jak Warszawskie Pogotowie Komputerowe. Serwis sprzętowy zajmuje się wymianą uszkodzonych matryc, lutowaniem układów BGA, diagnozowaniem awarii sekcji zasilania płyt głównych, wymianą zużytych ogniw bateryjnych oraz instalacją modułów pamięci operacyjnej i nośników półprzewodnikowych. Kategoria zabezpieczeń infrastruktury e-mail jest usługą świadczoną przez dostawców usług chmurowych i firmy konsultingowe IT.

Interwencja serwisu sprzętowego jest odpowiednia w momencie, gdy skuteczny atak spoofingowy (skutkujący pobraniem szkodliwego oprogramowania przez pracownika) wywoła bezpośrednie usterki w działaniu maszyny fizycznej. Dotyczy to przypadków, w których stacja robocza nie uruchamia systemu operacyjnego, wymaga niskopoziomowego formatowania nośnika, instalacji czystego obrazu systemu, naprawy sektora rozruchowego lub sprzętowego odzysku danych z dysku twardego. Usterki sprzętowe wywoływane bezpośrednio przez wirusy z fałszywych e-maili dawniej generowały liczne problemy, jednak fizyczne infekcje uszkadzające stary sprzęt komputerowy (takie jak złośliwy kod nadpisujący pamięć układów EEPROM z lat 90.) to obecnie rzadkość w serwisie.