W dzisiejszym świecie poczta elektroniczna pozostaje jednym z najczęściej wykorzystywanych kanałów komunikacji, zarówno w celach osobistych, jak i zawodowych. Jednak ta popularność sprawia również, że poczta elektroniczna jest głównym celem cyberprzestępców, którzy chcą ją wykorzystać do osiągnięcia zysków. Jedną z najczęściej stosowanych technik oszukiwania odbiorców poczty elektronicznej jest spoofing SMTP, taktyka pozwalająca atakującym wysyłać wiadomości e-mail, które wyglądają, jakby pochodziły z zaufanego źródła. Metoda ta umożliwia phishing i oszustwa, utrudniając odbiorcom weryfikację autentyczności wiadomości.
W tym blogu dokonuję odpowiedzialnego ujawnienia luki pozwalającej na SMTP spoofing, wykrytej w popularnym polskim kliencie pocztowym serwisu Interia.pl. Chciałbym przybliżyć ten temat oraz poszerzyć świadomość ludzi odpowiedzialnych za te systemy, tak aby luka ta mogła zostać skutecznie usunięta.
Chciałbym serdecznie podziękować zespołowi Interia oraz CERT Polska za współpracę w usuwaniu zgłoszonej luki.
TL;DR - Najważniejsze wnioski
- Analiza podatności SPF Bypass / DMARC Misconfiguration
- Koperta a List (Envelope vs. Header)
- Podatność: SPF Bypass (Obejście SPF)
- Gdzie jest DMARC?
Analiza podatności SPF Bypass / DMARC Misconfiguration
Aby zrozumieć, dlaczego w 2025 roku wciąż możliwe jest podszycie się pod dużego polskiego dostawcę poczty czy bank, musimy cofnąć się do lat 80. Protokół SMTP (Simple Mail Transfer Protocol), na którym opiera się cała światowa poczta, został zaprojektowany w czasach, gdy w Internecie wszyscy sobie ufali. Nie posiada on wbudowanego mechanizmu weryfikacji tożsamości nadawcy.
Współczesne zabezpieczenia to w dużej mierze "łaty" nakładane na ten stary system. Największa dziura, którą wykorzystują atakujący, wynika z fundamentalnego rozróżnienia dwóch pojęć w strukturze e-maila.
1. Koperta a List (Envelope vs. Header)
To kluczowy moment, w którym dochodzi do manipulacji. Każdy e-mail składa się z dwóch warstw adresowych, które nie muszą być ze sobą zgodne:
Envelope From (RFC 5321): To adres na "kopercie". Jest używany przez serwery pocztowe do routingu (np. tam wracają błędy dostarczenia). To ten adres podajemy w komendzie SMTP MAIL FROM.
Header From (RFC 5322): To adres w "liście" w środku koperty. To ten adres widzi użytkownik w swoim Outlooku, Gmailu czy na WP Poczcie w polu "Od:".
Kluczowy problem
Te dwa adresy nie muszą być ze sobą zgodne - i to właśnie jest źródłem podatności. Serwery pocztowe weryfikują adres na kopercie, ale użytkownik widzi adres z nagłówka.
2. Podatność: SPF Bypass (Obejście SPF)
Większość administratorów uważa, że wdrożenie rekordu SPF (Sender Policy Framework) chroni ich domenę. Niestety, SPF sprawdza tylko adres na kopercie (Envelope From).
Atakujący wykorzystuje to w następujący sposób (tzw. SPF Misalignment):
Co widzi serwer odbiorcy? Serwer sprawdza SPF dla domeny z koperty (haker-domena.pl). Adres IP serwera hakera zgadza się z rekordem SPF domeny hakera. Wynik: SPF PASS.
Co widzi ofiara? Ofiara otwiera maila i widzi nagłówek: Od: bezpieczeństwo@wielki-polski-dostawca.pl. Ponieważ SPF przeszedł pomyślnie (dla domeny technicznej), mail ląduje w skrzynce odbiorczej, a nie w spamie.
- Haker stawia własny serwer pocztowy i podpina pod niego domenę, którą kontroluje (np. haker-domena.pl).
- W konfiguracji DNS dla haker-domena.pl ustawia poprawny rekord SPF, autoryzujący jego serwer do wysyłki.
- Jako Envelope From ustawia admin@haker-domena.pl.
- Jako Header From (to, co widzi ofiara) ustawia bezpieczenstwo@wielki-polski-dostawca.pl.
3. Gdzie jest DMARC?
Tutaj dochodzimy do sedna problemu u wielu polskich dostawców. Protokół DMARC został stworzony właśnie po to, by połączyć te dwie warstwy. Wymusza on tzw. Alignment (Dopasowanie), domena w nagłówku "Od" musi być taka sama jak domena zweryfikowana przez SPF (lub DKIM).
Dlaczego więc atak działa?
Ponieważ DMARC działa skutecznie tylko wtedy, gdy jego polityka jest ustawiona na p=reject lub p=quarantine.
4. Symulacja ataku (SMTP Flow)
Gdybyśmy zajrzeli "pod maskę" i połączyli się z serwerem pocztowym przez telnet/netcat, atak wyglądałby tak:
W poniższym przykładzie serwer Interia odpyta DNS o rekord SPF dla haker-domena.pl. Wszystko będzie się zgadzać. Jeśli interia.pl nie ma restrykcyjnego DMARC, klient pocztowy wyświetli pracownikowi fałszywego nadawcę bez żadnych ostrzeżeń.
Podsumowanie analizy
Podatność nie wynika z błędu w oprogramowaniu (bug), ale z błędu konfiguracji i logiki protokołów. To klasyczny przykład długu technologicznego, gdzie brak polityki p=reject w rekordzie DMARC u dużych dostawców otwiera furtkę do trywialnego podszywania się pod ich domeny.
Wnioski
Poniżej znajduje się oryginalna odpowiedź zespołu Interia z dnia 29 września 2024 r., podsumowująca całą sprawę i informująca o wprowadzonych zmianach. Stanowi ona doskonałe podsumowanie całego wpisu na blogu.
Informacje o zgłoszeniu i rozpoczęciu prac
Dnia 30 kwietnia 2024 roku, niezależny badacz zgłosił drogą e-mailową potencjalne luki w zabezpieczeniach dotyczących obsługi protokołu SMTP oraz polityki DMARC w usłudze pocztowej Interia.pl. Zgłoszenie zostało przyjęte do analizy, a prace nad oceną i opracowywaniem odpowiednich poprawek rozpoczęły się w maju 2024 roku. Zespół odpowiedzialny za infrastrukturę pocztową oraz zespół ds. bezpieczeństwa podjął działania, mające na celu zabezpieczenie zgłoszonych obszarów, z jednoczesnym zachowaniem funkcjonalności dla użytkowników.
Zgłoszone błędy
Niezależny badacz zidentyfikował dwa potencjalne problemy związane z bezpieczeństwem:
- DMARC Policy jest ustawiona na wartość "none", co oznacza brak ścisłej weryfikacji autentyczności nadawców wiadomości e-mail. Taki stan rzeczy może umożliwić wysyłanie wiadomości podszywających się pod inne adresy e-mail, bez ograniczeń wynikających z bardziej restrykcyjnej polityki DMARC.
- Występuje możliwość spoofingu mailowego, czyli podszywania się pod inne adresy e-mail poprzez ręczną podmianę nagłówka FROM (RFC5322.From) w przypadku korzystania z protokołu SMTP. Ten problem może prowadzić do złośliwych działań, takich jak wysyłanie wiadomości sugerujących, że zostały wysłane przez innego nadawcę.
Wdrożone poprawki
Po dokładnej analizie zgłoszenia oraz wewnętrznej weryfikacji, wprowadzono następujące zmiany, mające na celu dodanie dodatkowych zabezpieczeń w zgłoszonych obszarach:
- Zablokowano możliwość podszywania się pod inne adresy e-mail przy korzystaniu z protokołu SMTP. Zastosowano mechanizmy weryfikacyjne po stronie serwera pocztowego, które uniemożliwiają ręczną manipulację nagłówkiem FROM, zapobiegając w ten sposób spoofingowi.
- Wzmocniono bezpieczeństwo w kliencie poczty WEB, blokując próby podszywania się pod inne adresy e-mail. Dzięki temu, także użytkownicy korzystający z webmaila nie mogą próbować podszywać się pod inne konta, zarówno w obrębie domeny interia.pl i jej subdomen, jak i pod zewnętrzne adresy e-mail.
Dodatkowo trwają prace nad usprawnieniami wizualnymi, które umożliwią użytkownikom łatwiejszą identyfikację wiadomości typu spoofing, phishing oraz scam, poprzez prezentowanie użytkownikowi w panelu webowym kopertowego adresu nadawcy. Planowane wdrożenie przewidziane jest na listopad.
Niewdrożone elementy
Pomimo wdrożenia wielu zabezpieczeń, DMARC Policy pozostaje ustawione na wartość "none". Decyzja o utrzymaniu takiego ustawienia wynika z troski o naszych użytkowników. Wdrożenie bardziej restrykcyjnej polityki DMARC mogłoby skutkować odrzuceniem ważnych wiadomości w przypadkach, gdy serwery odbiorców są niewłaściwie skonfigurowane. Również CERT Polska traktuje politykę "none" nie jako błąd, a jedynie ostrzeżenie (https://bezpiecznapoczta.cert.pl/).
Podsumowanie
W odniesieniu do zgłoszenia dotyczącego nagłówka RFC5322.From, który może prowadzić do pewnych implikacji związanych z bezpieczeństwem, chcemy podkreślić, że nie był to bezpośredni błąd związany z usługą pocztową Interia.pl, lecz z szeroko stosowanym, choć czasem kontrowersyjnym, standardem wiadomości internetowych. Obsługa tych nagłówków była zgodna z protokołem SMTP oraz RFC i wymagana przez wszystkich popularnych klientów pocztowych.
Zespół odpowiedzialny za infrastrukturę pocztową oraz zespół ds. bezpieczeństwa dołożyły wszelkich starań, aby wyeliminować możliwość spoofingu w poczcie Interia.pl, zapewniając tym samym wysoki poziom ochrony użytkowników przed potencjalnymi zagrożeniami, jednocześnie starając się zachować możliwie największą zgodność ze standardami RFC oraz zasadami działania powszechnie stosowanych protokołów pocztowych.
Podsumowanie
Podatność nie wynika z błędu w oprogramowaniu, ale z błędu konfiguracji i logiki protokołów. To klasyczny przykład długu technologicznego, gdzie brak polityki p=reject w rekordzie DMARC u dużych dostawców otwiera furtkę do trywialnego podszywania się pod ich domeny. Współpraca z zespołem Interia i CERT Polska doprowadziła do wdrożenia poprawek zabezpieczających użytkowników.
Oś czasu
Pierwszy kontakt
Pierwsza wiadomość z powiadomieniem o możliwości spoofowania nadawcy SMTP skierowana do zespołu Interia.pl.
Prośba o szczegóły podatności
Wyznaczenie osoby kontaktowej do dalszej korespondencji.
Wysyłka raportu
Wysyłka szczegółowego raportu pozwalającego na odtworzenie krok po kroku podatności.
Odpowiedzialne ujawnianie informacji
Pytanie dotyczące podejścia zespołu Interia do procesu odpowiedzialnego ujawniania informacji.
It's not a bug, it's a feature :)
Otrzymanie informacji zwrotnej, że po dokładnej analizie przeprowadzonej przez zespół Interia zgłoszona luka nie została uznana za ważną. Przedstawienie argumentów i wniosków z analizy.
Zgłaszam sprzeciw!
Sprzeciw wobec analizy zespołu Interia i podtrzymanie opinii, że luka w zabezpieczeniach istnieje. Przesłanie dodatkowych szczegółów stanowiących kontrargument dla zespołu Interia.
Sprzeciw podtrzymany
Ponowne przyjęcie zgłoszenia luki w zabezpieczeniach i oświadczenie o dalszej analizie.
Prośba o aktualizację statusu sprawy
"Prace wdrożeniowe są w toku"
Zgłoszenie podatności do CERT Polska
Potwierdzenie przyjęcia zgłoszenia
Oświadczenie o podjęciu próby skontaktowania się z zespołem Interia.
Naprawią, naprawią
Informacja, że zespół Interia planuje wprowadzić ulepszenia do początku września.
Update, please
Pytanie o aktualizację statusu sprawy od CERT Polska. Informacje dotyczące planowanego ujawnienia informacji w nadchodzącym tygodniu.
Już za chwilę, już za momencik
Kontakt z zespołem Interia. Informacja od zespołu Interia o ciągłym wprowadzaniu poprawek. Prośba o odroczenie odpowiedzialnego ujawnienia.
Odraczam!
Zgoda na odroczenie odpowiedzialnego ujawnienia informacji do dnia 1 listopada 2024 r.
Roger that, over
Potwierdzenie odbioru wiadomości i przekazanie jej zespołowi Interia.
Zmiany ludzie, zmiany!
Podsumowanie całej sprawy. Informacje o zmianach wprowadzonych przez zespół Interia.
Podsumowanie
Podsumowanie całej sprawy (forward wiadomości od zespołu Interia).
Odpowiedzialne ujawnianie informacji
Publiczna publikacja szczegółów podatności po wdrożeniu poprawek przez zespół Interia.
Bibliografia
Specyfikacja protokołu SMTP definiująca mechanizm Envelope From (MAIL FROM) wykorzystywany w routingu poczty elektronicznej.
Standard formatu wiadomości e-mail definiujący nagłówek Header From, który jest wyświetlany użytkownikowi końcowemu w kliencie pocztowym.
Specyfikacja mechanizmu SPF umożliwiającego weryfikację, czy dany serwer jest uprawniony do wysyłania poczty w imieniu domeny. Definiuje limit 10 DNS lookup-ów.
Specyfikacja protokołu DMARC łączącego SPF i DKIM z mechanizmem alignment, wymuszającego spójność domen w kopercie i nagłówku wiadomości.
Narzędzie CERT Polska do weryfikacji konfiguracji zabezpieczeń poczty elektronicznej polskich domen (SPF, DKIM, DMARC).
Jeden z największych polskich serwisów pocztowych, w którym wykryto opisywaną podatność na SMTP spoofing.
Poradnik krok po kroku, który demonstruje, jak zidentyfikować podatną domenę, skonfigurować infrastrukturę i z powodzeniem sfałszować adres e-mail, omijając przy tym luki w zabezpieczeniach takich jak SPF i DMARC.
Fragment artykułu wyjaśnia, jak cyberprzestępcy omijają zabezpieczenia protokołu SPF, wykorzystując brak rygorystycznej polityki DMARC do skutecznego fałszowania nadawcy e-mail.
Praktyczny przewodnik opisujący techniki e-mail spoofingu oraz mechanizmy zabezpieczające pocztę przed tym zjawiskiem.