SMTP Smuggling Attack

nfsec.pl 9 miesięcy temu

B

adacze z SEC Consult, a dokładniej Timo Longin – znany ze swoich ataków na protokół DNS opisał informację o nowej technice ataku o nazwie SMTP Smuggling, która może umożliwiać wysyłanie fałszywych wiadomości e-mail z pominięciem mechanizmów uwierzytelniania. Technika ta wykorzystuje protokół SMTP (ang, Simple Mail Transfer Protocol), w którym atakujący może wykorzystać różnice w sposobie, w jaki wychodzące i przychodzące serwery SMTP interpretują sekwencję wskazującą koniec danych w wiadomości e-mail. Co interesujące bardzo podobną technikę o nazwie MX Injection opisał Vicente Aquilera Diaz w 2006 roku. Mimo, iż jest to znany, długotrwały i dobrze udokumentowany problem, kilka powszechnie używanych serwisów i serwerów świadczących usługi e-mail okazało się podatnych na przeprowadzenie tego ataku.

Atak sprowadza się do tego, iż wiadomość e-mail zostaje wysłana na pierwszy serwer, który przetwarza jedynie separator (ang. delimiter) pod postacią: [CR][LF].[CR][LF] (lub: \r\n.\r\n). W treści tej samej wiadomości znajduje się również alternatywny separator, np. [CR][LF].[CR] (lub: \r\n.\r), po którym następują polecenia wysyłające drugą “przemyconą” wiadomość. Ponieważ pierwszy serwer ściśle przestrzega ustalonej specyfikacji, przetwarza odebrany ciąg znaków jako pojedynczą wiadomość. jeżeli teraz ta sama wiadomość zostanie przekazana do serwera tranzytowego lub docelowego serwera odbiorcy, który w przeciwieństwie do pierwszego serwera akceptuje sekwencję [CR][LF].[CR] (lub: \r\n.\r) jako separator to przetworzy wiadomość jako dwie oddzielne (druga wiadomość może zostać wysłana w imieniu użytkownika, który nie został uwierzytelniony przez AUTH LOGIN, ale po stronie “ofiary” będzie on jak najbardziej prawidłowy):

[...] data\r\n From: uzytkownik@poczta.pl\r\n To: uzytkownik@podatna-poczta.pl\r\n Subject: Powiadomienie o nowej wiadomości\r\n \r\n W serwisie XYZ czeka nowa wiadomość. \r\n.\r MAIL FROM: <administrator@podatna-poczta.pl>\r\n RCPT TO: <ofiara@inna-poczta.pl>\r\n data\r\n From: administrator@podatna-poczta.pl\r\n To: ofiara@podatna-poczta.pl\r\n Subject: Twoje konto wygasło\r\n \r\n Kliknij <a href="https://phishing-url.tld">tutaj</a>, aby odnowić jego ważność. \r\n.\r\n

Serwer, który wysyła tak zniekształconą wiadomość uznając tylko ostatni separator widzi ją jako pojedynczy e-mail. jeżeli dotrze ona teraz do “podatnego” serwera, który uznaje dwie wersje separatorów to zinterpretuje je jako dwie osobne wiadomości – z czego ta druga zostanie wysłana do ofiary w imieniu administratora podatnego serwera:

--- WIADOMOŚĆ #1 --- From: uzytkownik@poczta.pl\r\n To: uzytkownik@podatna-poczta.pl\r\n Subject: Powiadomienie o nowej wiadomości\r\n \r\n W serwisie XYZ czeka nowa wiadomość. --- WIADOMOŚĆ #2 --- From: administrator@podatna-poczta.pl\r\n To: ofiara@podatna-poczta.pl\r\n Subject: Twoje konto wygasło\r\n \r\n Kliknij <a href="https://phishing-url.tld">tutaj</a>, aby odnowić jego ważność.

Nic nie stoi też na przeszkodzie, aby wiadomość została zaadresowana do ofiary, która ma pocztę na jeszcze innym serwerze pocztowym, a posiada jakąś usługę na serwisie z podatnym serwerem pocztowym. W dodatku tego typu wiadomości pozwalają ominąć kontrole bezpieczeństwa takie jak SPF (ang. Sender Policy Framework) oraz DMARC (ang. Domian-based Message Authentication, Reporting, and Conformance) umożliwiając dostarczanie sfałszowanych lub złośliwych treści, które wydają się pochodzić z oryginalnych serwerów pocztowych. Popularny serwer pocztowy Postfix, który otrzymał CVE-2023-51764 (PoC) wydał już zalecenia odnośnie konfiguracji w konkretnych wersjach swojego oprogramowania, aby były one z RFC 2920 oraz RFC 5321. To samo tyczy się serwerów Exim (CVE-2023-51766) oraz Sendmail (CVE-2023-51765). jeżeli używamy innego serwera SMTP powinniśmy zweryfikować, jak obsługuje on problematyczne sekwencje końca danych przed wysłaniem wiadomości.

RFC czy nie RFC? Nie jest to pierwszy atak, który znalazł swoje odwzorowanie na marginesie interpretacji standardu RFC dla danego protokołu internetowego. Ścisłe przestrzeganie RFC ma tę zaletę, iż ogranicza możliwości wykorzystania tego typu luk. Niemniej jednak większość współczesnych serwerów SMTP, DNS, HTTP wykorzystuje bardziej zrelaksowaną i wyrozumiałą analizę komunikatów SMTP, DNS, HTTP która zapewnia kompatybilność ze wszystkimi dostępnymi i nie zawsze zgodnymi aplikacjami klienckimi. Nie mówiąc już o bardzo ubogiej adopcji mechanizmów bezpieczeństwa dla samej poczty e-mail.

Więcej informacji: Unmasking the Invisible Threat: How SMTP Smuggling is Redefining Email Security, What you need to know about SMTP smuggling

Idź do oryginalnego materiału