SMTP Smuggling 2024: nowy atak na pocztę i ochrona

W grudniu 2023 roku badacze z SEC Consult opublikowali raport, który wstrząsnął środowiskiem e-mail security. Odkryta przez nich technika — SMTP Smuggling — pozwala atakującemu wstrzyknąć sfałszowaną wiadomość do cudzego serwera pocztowego w taki sposób, że przechodzi ona przez filtry SPF, DKIM i DMARC bez żadnego alarmu. W 2024 roku temat wrócił ze zdwojoną siłą, gdy pojawiły się pierwsze udokumentowane przypadki wykorzystania tej luki w rzeczywistych kampaniach phishingowych. Jeśli prowadzisz firmę wysyłającą e-maile z własnego serwera SMTP — ten artykuł jest dla Ciebie.

Czym jest SMTP Smuggling i skąd się wziął

SMTP Smuggling to atak klasy request smuggling — analogiczny do HTTP Request Smuggling, ale przeniesiony na grunt protokołu pocztowego. Jego istota tkwi w tym, że różne implementacje serwerów SMTP interpretują sekwencje końca wiadomości w odmienny sposób. Protokół SMTP definiuje koniec treści wiadomości jako sekwencję <CR><LF>.<CR><LF> (czyli \r\n.\r\n), jednak część serwerów akceptuje też wariant \n.\n (samo LF bez CR).

Jeśli serwer wysyłający i serwer odbierający różnie interpretują tę sekwencję, atakujący może „przemycić" drugą, ukrytą wiadomość wewnątrz pierwszej. Serwer wysyłający widzi jedną wiadomość, serwer odbierający — dwie. Druga z nich może mieć dowolny nagłówek From:, w tym adres zaufanej domeny, np. ceo@twojafirma.pl.

Powiązane CVE — co warto znać

Badania SEC Consult doprowadziły do przyznania kilku identyfikatorów CVE dotyczących konkretnych implementacji. Najważniejsze z nich to:

• CVE-2023-51766 — podatność w serwerze Exim (popularne oprogramowanie MTA w systemach Linux); dotyczy nieprawidłowej obsługi sekwencji końca danych.
• CVE-2024-27497 — luka w Postfixie zgłoszona na początku 2024 roku w kontekście konfiguracji z niektórymi filtrami treści.
• Podatności w komercyjnych bramkach e-mail (Cisco Secure Email Gateway, Microsoft Exchange Online) — część z nich została załatana w trybie pilnym po publikacji raportu.

Warto podkreślić: sam protokół SMTP (RFC 5321) nie jest wadliwy. Problem leży w implementacjach, które zbyt liberalnie interpretują standard — i właśnie te rozbieżności są exploitowane.

Jak wygląda atak krok po kroku — scenariusz

Wyobraź sobie firmę Alfa Sp. z o.o., która korzysta z serwera pocztowego opartego na Postfixie 3.5 (wersja sprzed patcha). Firma ma poprawnie skonfigurowane rekordy SPF, DKIM i DMARC — wszystko wygląda wzorowo. Atakujący, nazwijmy go Marek, planuje atak na pracownika działu finansowego.

Krok 1 — rozpoznanie

Marek ustala, że firma Alfa korzysta z serwera MX podatnego na SMTP Smuggling. Wystarczy mu do tego publiczny rekord MX i proste testy połączenia SMTP (port 25). Sprawdza też, czy serwer odbierający akceptuje sekwencje \n.\n zamiast standardowego \r\n.\r\n.

Krok 2 — przygotowanie spreparowanej wiadomości

Marek łączy się ze swoim własnym serwerem SMTP (np. VPS za granicą) i wysyła wiadomość do ofiary. Treść tej wiadomości zawiera jednak ukryty ładunek — po sekwencji \n.\n dołącza nagłówki i treść drugiej wiadomości, podszywając się pod adres prezes@alfa.pl.

Krok 3 — dostarczenie i ominięcie filtrów

Serwer Alfa odbiera połączenie. Zewnętrzny serwer Marka ma własny rekord SPF — pierwsza wiadomość przechodzi weryfikację. Ale serwer Alfa, akceptując \n.\n jako koniec danych, „widzi" też drugą wiadomość. Tę drugą traktuje jako lokalnie przetworzoną — bez ponownej weryfikacji SPF/DKIM dla domeny alfa.pl. Efekt: pracownik finansowy dostaje e-mail z adresu prezes@alfa.pl, który wygląda w 100% autentycznie.

Krok 4 — phishing / BEC

Treść fałszywej wiadomości to klasyczny atak BEC (Business Email Compromise): prośba o pilny przelew 48 000 zł na „nowe konto dostawcy". Pracownik nie ma powodów do podejrzeń — nadawca to prezes, filtry antyspamowe milczą, podpis DMARC zielony.

Według raportu FBI IC3 za 2023 rok ataki BEC spowodowały globalne straty przekraczające 2,9 miliarda dolarów. SMTP Smuggling otwiera nowy, trudniejszy do wykrycia wektor tego typu ataków.

Które serwery i konfiguracje są podatne

Podatność nie dotyczy wszystkich serwerów w równym stopniu. Kluczowe znaczenie ma para: serwer wysyłający (relay) i serwer odbierający. Poniższa tabela pokazuje, które kombinacje były podatne w momencie publikacji badań SEC Consult (stan na grudzień 2023 / Q1 2024):

Ważne zastrzeżenie: nawet zaktualizowany serwer może być podatny, jeśli w łańcuchu dostarczania poczty znajduje się stary relay lub filtr treści z nieaktualnym oprogramowaniem. Bezpieczeństwo całego systemu jest równe jego najsłabszemu ogniwie.

Jak się chronić — konkretne kroki

Dobra wiadomość jest taka, że większość wektorów ataku można zamknąć stosunkowo szybko, bez kosztownych inwestycji. Poniżej lista działań w kolejności priorytetu.

1. Zaktualizuj oprogramowanie MTA

To podstawa. Jeśli używasz Postfixa, zaktualizuj go do wersji co najmniej 3.8.4 (gałąź stabilna) lub 3.7.9 (gałąź LTS). Dla Exima wymagana jest wersja 4.97.1 lub nowsza. Sprawdź też wszystkie komponenty w łańcuchu — filtry antywirusowe, bramki SMTP, proxy pocztowe.

2. Wymuś ścisłą obsługę sekwencji CRLF

W konfiguracji Postfixa ustaw parametr smtpd_forbid_bare_newline = yes (dostępny od wersji 3.8.x). Powoduje on odrzucanie połączeń, które przesyłają samo LF zamiast CRLF — eliminuje to główny wektor SMTP Smugglingu. Analogiczną opcję znajdziesz w dokumentacji Exima jako ALLOW_INSECURE_TAINTED_DATA (wyłącz ją).

3. Weryfikuj SPF/DKIM/DMARC — ale nie ufaj im ślepo

SMTP Smuggling pokazuje, że same rekordy uwierzytelniające nie wystarczą. Uzupełnij je o:

• DMARC z polityką p=reject — odrzucaj wiadomości, które nie przejdą weryfikacji SPF lub DKIM dla Twojej domeny.
• ARC (Authenticated Received Chain) — pomaga śledzić uwierzytelnienie wiadomości przez pośrednie serwery relay.
• MTA-STS — wymusza szyfrowanie TLS między serwerami, co utrudnia ataki man-in-the-middle przy okazji smugglingu.

4. Monitoruj logi SMTP i anomalie

Skonfiguruj alerty na niestandarowe sekwencje w logach serwera pocztowego. Warto szukać m.in. wiadomości zawierających \n.\n w danych surowych (raw SMTP data) oraz połączeń z podejrzanych zakresów IP wysyłających wiadomości z Twoich domen. Narzędzia SIEM (np. Wazuh, Graylog) pozwalają zautomatyzować takie reguły.

5. Segmentacja i uwierzytelnianie relayów

Jeśli korzystasz z wewnętrznych relayów SMTP (np. do obsługi formularzy kontaktowych, powiadomień systemowych), upewnij się, że są one uwierzytelnione i nie akceptują połączeń z zewnątrz bez autoryzacji. Otwarty relay to zaproszenie dla atakującego.

SMTP Smuggling a RODO i odpowiedzialność prawna

Skuteczny atak SMTP Smuggling, który prowadzi do wyłudzenia danych lub środków finansowych, może rodzić konsekwencje na gruncie RODO. Zgodnie z art. 32 RODO administrator danych jest zobowiązany do wdrożenia odpowiednich środków technicznych i organizacyjnych zapewniających bezpieczeństwo przetwarzania — w tym ochronę przed nieuprawnionym dostępem i modyfikacją danych. Brak aktualizacji serwera pocztowego mimo dostępnych patchy może być potraktowany przez UODO jako naruszenie tego obowiązku.

Dodatkowo, jeśli atak doprowadzi do naruszenia ochrony danych osobowych (np. wycieku listy kontaktów lub danych klientów), administrator ma obowiązek zgłoszenia incydentu do UODO w ciągu 72 godzin od jego wykrycia (art. 33 RODO). W przypadku wysokiego ryzyka dla osób fizycznych konieczne jest też poinformowanie tych osób bezpośrednio (art. 34 RODO).

Czy MailerPRO i własne serwery SMTP są bezpieczne?

Jeśli wysyłasz kampanie e-mail przez własne skrzynki SMTP — np. za pośrednictwem MailerPRO — kluczowe jest to, na jakim oprogramowaniu stoi Twój serwer i czy jest on regularnie aktualizowany. MailerPRO łączy się z serwerami SMTP podanymi przez użytkownika, co oznacza, że odpowiedzialność za konfigurację i bezpieczeństwo samego serwera leży po stronie administratora. Dlatego warto traktować opisane powyżej kroki jako obowiązkową checklistę dla każdego, kto zarządza własną infrastrukturą pocztową.

Dobrą praktyką jest też regularne testowanie swojego serwera pod kątem podatności na SMTP Smuggling. Narzędzie smtp-smuggling-scanner (dostępne na GitHubie SEC Consult) pozwala sprawdzić, czy Twój serwer akceptuje niestandardowe sekwencje końca danych — bez konieczności przeprowadzania rzeczywistego ataku.

Podsumowanie — checklista bezpieczeństwa SMTP

SMTP Smuggling to atak, który boli podwójnie: jest trudny do wykrycia i uderza w infrastrukturę, którą administratorzy uważali za bezpieczną. Poniżej zwięzła checklista do wdrożenia:

1. Zaktualizuj Postfixa do ≥ 3.8.4 lub Exima do ≥ 4.97.1.
2. Włącz smtpd_forbid_bare_newline = yes w konfiguracji Postfixa.
3. Ustaw politykę DMARC na p=reject dla wszystkich swoich domen.
4. Wdróż MTA-STS i monitoruj raporty DMARC (rua/ruf).
5. Przeskanuj serwer narzędziem smtp-smuggling-scanner.
6. Skonfiguruj alerty SIEM na anomalie w logach SMTP.
7. Zweryfikuj, czy żaden relay w Twoim łańcuchu nie jest otwarty lub nieaktualny.

Bezpieczeństwo poczty elektronicznej to nie jednorazowy projekt, lecz ciągły proces. Ataki takie jak SMTP Smuggling przypominają, że nawet dobrze znane protokoły mogą kryć niespodzianki — i że regularne audyty konfiguracji serwera to nie paranoja, lecz elementarna higiena IT. Wdróż powyższe kroki jeszcze w tym tygodniu — zanim zrobi to za Ciebie ktoś, kto nie ma dobrych intencji.