W trakcie projektu badawczego Timo Longin (@timolongin) – znany ze swoich ataków na protokół DNS – we współpracy z SEC Consult Vulnerability Lab odkrył nowatorską technikę wykorzystania jeszcze jednego protokołu internetowego – SMTP (Simple Mail Transfer Protocol) do atakowania. Podmioty zagrażające mogą wykorzystywać podatne na ataki serwery SMTP na całym świecie w celu wysyłania złośliwych wiadomości e-mail z dowolnych adresów, umożliwiając ukierunkowane ataki phishingowe. Ze względu na charakter samego exploita, ten typ luki został nazwany SMTP Smuggling (przemyt SMTP). Wykryto wiele zero-dayów oraz powiadomiono różnych dostawców. Luki w zabezpieczeniach Microsoft Exchange Online i Ionos zostały załatane, ale sprawdźcie konfigurację Cisco Secure Email Gateway.
Na czym polega atak SMTP Smuggling?
SMTP (z ang. Simple Mail Transfer Protocol) smuggling to technika, w której atakujący wykorzystują niespójności w sposobie, w jaki serwery proxy lub zapory ogniowe analizują i obsługują ruch SMTP. Wykorzystując te niespójności, podmioty zagrażające mogą przemycać szkodliwe ładunki lub unikać wykrycia. Nową technikę wykorzystania SMTP zwaną SMTP Smuggling przedstawił Timo Longin we współpracy z SEC Consult.
Badacz zapożyczył główną koncepcję SMTP Smuggling od innej klasy ataków, znanych jako „HTTP request smuggling” , podczas których napastnicy oszukują znajdujący się z przodu (front-end) moduł równoważenia obciążenia (load balanser) lub zwrotne serwery proxy (reverse proxy) w celu przekazania specjalnie spreparowanych żądań do back-endowego serwera aplikacji w sposób, w którym przetwarza to jako dwa oddzielne żądania zamiast jednego. Osiąga się to poprzez modyfikację nagłówków żądań w sposób dostarczający serwerom sprzecznych informacji o miejscu zakończenia żądania. Jeśli serwery front-end i back-end mają różne interpretacje wartości nagłówków, a tym samym koniec żądania, fałszywe żądania mogą zostać przemycone przez serwer front-end bez poddawania ich normalnym kontrolom bezpieczeństwa.
Podobnie podczas wysyłania wiadomości e-mail przez Internet zaangażowane są co najmniej dwa serwery: serwer SMTP używany przez nadawcę (wychodzące) i serwer SMTP odbiorcy (przychodzące). Jeśli różnie interpretują miejsce zakończenia wiadomości, osoba atakująca może przepuścić fałszywe wiadomości przez kontrolę bezpieczeństwa.
Opisywany powyżej kompletny proces utrudnia systemom bezpieczeństwa dokładne zdiagnozowanie procesu przesyłania wiadomości e-mail, co prowadzi do potencjalnych luk w zabezpieczeniach. Stanowi to bardzo poważny problem.
Oznacza to tyle, że podatne na tę technikę wrażliwe serwery na całym świecie mogą zostać wykorzystane do ataków typu phishing poprzez wysyłanie złośliwych wiadomości e-mail z dowolnego adresu.
Poza tym wykryto wiele usterek typu zero-day, a dostawcy zostali już powiadomieni w odpowiednim dokumencie ujawniającym problemy.
Szczegóły techniczne
Różnice w interpretacji protokołu SMTP umożliwiają przeprowadzenie nowego ataku SMTP, wysyłanie fałszywych wiadomości e-mail podczas weryfikacji kontroli SPF. Umożliwia to fałszowanie komunikacji z różnych domen do głównych serwerów SMTP.
Wykryto dwa rodzaje ataków SMTP Smuggling:
- dla poczty wychodzącej,
- dla poczty przychodzącej.
Microsoft i GMX naprawiły luki w zabezpieczeniach, ale SEC Consult zaleca ręczne aktualizacje dla użytkowników Cisco Secure Email.
MUA (agent użytkownika poczty) łączy się z MTA (agentem przesyłania poczty) programu Outlook za pośrednictwem protokołu TCP/587. Następnie wysyłana jest seria poleceń SMTP; Outlook SMTP ocenia uprawnienia, a następnie wysyła przychodzącą wiadomość e-mail do serwera SMTP odbiorcy za pośrednictwem protokołu TCP/25, omijając:
- AUTH LOGIN (Autoryzację logowania),
- STARTTLS.
Przychodzące serwery SMTP weryfikują autentyczność nadawcy za pomocą SPF, DKIM i DMARC, aby zapobiec wysyłaniu wiadomości e-mail z dowolnej domeny. SPF opiera się na rekordach DNS w celu uzyskania pozwolenia na adres IP nadawcy, a niepowodzenie skutkuje nieprzekazywaniem dalej lub oznaczaniem spamu.
Jednak SPF sprawdza tylko domenę „MAIL FROM”, a nie dowolną wartość w nagłówku „From”, co stanowi ograniczenie.
DKIM podpisuje dane wiadomości, w tym nagłówek „From”, weryfikowane przez odbiorcę kluczem publicznym w DNS…
…ale nie wymusza domeny klucza. DMARC wprowadza dopasowanie identyfikatorów poprzez sprawdzenie czy domena „FROM” jest zgodna z SPF i/lub DKIM.
Polityka (p=) określa odrzucanie wiadomości, które nie spełniają DMARC, zapewniając akceptację tylko z ważnym SPF lub DKIM.
Dostawcy poczty e-mail używani w POC ataku
Poniżej wymieniliśmy wszystkich dostawców poczty e-mail, na których badacze przetestowali atak SMTP Spoofing:
- outlook.com
- gmail.com
- gmx.net
- icloud.com
- zoho.com
- fastmail.com
- runbox.com
- startmail.com
- mailbox.org
- aol.com
- yahoo.com
- web.de
Analiza wychodzących serwerów SMTP ujawniła anomalię na serwerze Microsoft Outlook (outlook.com). Wysłanie sekwencji <LF>.<LF> skutkuje brakiem transmisji i wyświetleniem komunikatu o błędzie:
„550 5.6.11 SMTPSEND.BareLinefeedsAreIllegal; wiadomość zawiera puste przesunięcia wiersza, których nie można wysłać poprzez DATA, a system odbierający nie obsługuje BDAT”.
Skąd serwer SMTP wie, gdzie kończy się sekcja DATA? Kiedy napotka znak „.” (kropka) w osobnej linii. Jest to znane jako sekwencja końca danych i zwykle jest kodowane jako <CR><LF>.<CR><LF> (gdzie CR oznacza powrót karetki, a LF oznacza wysuw wiersza) lub \r\n. \r\n.
W przeciwieństwie do GMX Outlook nie filtruje sekwencji <LF>.<CR><LF>. Przesłanie do niektórych odbiorców jest blokowane ze względu na wykorzystanie przez Outlooka opcjonalnego polecenia BDAT SMTP, będącego alternatywą dla DATA, określającego długość wiadomości bez polegania na sekwencji końca danych.
Ze względu na zaniedbanie czyszczenia serwerów wychodzących, SMTP Smuggling jest możliwy w GMX i Exchange Online.
Skaner badający niezabezpieczone serwery SMTP dla ruchu przychodzącego testuje permisywność w przypadku egzotycznych sekwencji końca danych. W tym miejscu limit czasu oznacza, że serwer zignorował niekonwencjonalną sekwencję.
Badanie ujawniło egzotyczne przychodzące serwery SMTP interpretujące sekwencje końca danych, takie jak <CR><LF>\x00.<CR><LF> (bajt zerowy reprezentowany przez „\x00”).
Pomimo natychmiastowych poprawek opracowanych przez Microsoft i GMX, nadal jest możliwe przesyłanie przychodzących fałszywych wiadomości SMTP do domyślnie skonfigurowanych instancji Cisco Secure Email. Zdecydowanie zaleca się zmianę tych konfiguracji.
Cały raport znajdziecie tutaj.