Możliwy atak SMTP Smuggling na popularne serwery pocztowe

Tim Longin, znany z ataków na protokół DNS, we współpracy z SEC Consult, opublikował informację o możliwości ataku SMTP Smuggling na popularne serwery i usługi pocztowe. Cała historia rozpoczyna się w czerwcu 2023 roku, kiedy to przedstawiono pierwszy PoC (Proof of Concept) ataku SMPT Smuggling działającego w systemie pocztowym firmy GMX. W kolejnych dniach udało się potwierdzić występowanie podatności w Exchange Online, a w ciągu następnych miesięcy badacze odkrywali możliwość przeprowadzenia ataku w kolejnych infrastrukturach oraz podejmowali bardziej i mniej udane próby nawiązania kontaktu osobami odpowiedzialnymi za ich rozwój i działanie. 18 grudnia pojawił się wpis na blogu SEC Consult opisujący szczegóły techniczne ataku.

We wpisie na blogu SEC Consult autorzy objaśniają, jak wygląda obsługa protokołu SMTP. Możemy zapoznać się tam z pokazanymi przykładami poprawnej oraz błędnej wymiany danych.

Technika przemycania danych nie jest nowa. Inspiracją do badań było wcześniejsze odkrycie Jamesa 'albinowax’ Kettle’a. Zaprezentował on atak HTTP Smuggling, który wykorzystywał niejednoznaczności w interpretacji nagłówków HTTP. Różnice w interpretacji nagłówków HTTP przez różne elementy infrastruktury serwera pozwalały na doklejanie żądań umożliwiających m. in. nieuprawniony dostęp do miejsc, do których użytkownik nie powinien mieć dostępu (np. do panelu administracyjnego) poprzez normalnych reguł obsługi takich żądań. Wizualizację jednego z możliwych wariantów ataku HTTP Smuggling można zobaczyć w prezentacji sekuraka. 

Atak SMTP Smuggling wynika z błędnej obsługi sekwencji końca linii. Prawidłowa sekwencja zakończenia linii podczas sesji z serwerem SMTP powinna kończyć się <CR><LF>.<CR><LF> (\r\n.\r\n).

Na obrazku widzimy transfer wiadomości, w której występuje znak <LF>.<LF>. Serwery ignorują ten znak. Znak <LF>.<LF> (\n.\n) nie jest interpretowany jako koniec danych. Całość przesyłana jest jako jedna wiadomość.

Jeśli serwery SMTP inaczej rozumieją, gdzie kończą się dane wiadomości, osoba atakująca może wydostać się z danych wiadomości.

Na obrazku widzimy skutek ataku SMTP Smuggling. Podatny na atak serwer wychodzący widzi tylko jedną wiadomość, podczas gdy serwer przychodzący interpretuje te dane jako dwie osobne wiadomości.

Wykorzystanie innej sekwencji, jak na przykład <LF>.<LF> lub <LF>.<CR><LF> w podatnym serwerze może pozwolić na wykonanie dowolnego polecenia SMTP lub nawet przemycenie 'nadprogramowej’ wiadomości e-mail poprzez doklejenie nadprogramowych wartości po właściwej wiadomości. W praktyce pozwala(ło) to atakującemu na 'legalne’ wysyłanie wiadomości ze wszystkich domen obsługiwanych przez podatny serwer. Wiadomości takie poprawnie przechodziły sprawdzenie przez mechanizmy SPF, DKIM i DMARC. Aby atak mógł się powieść konieczne jest, żeby wychodzący i przychodzący serwer SMTP błędnie interpretowały sekwencje zakończenia linii.

Tyle teorii. Teraz czas na praktykę. Załóżmy, że z serwisu GMX z adresu user@gmx.net wysyłamy wiadomość na podatny serwer provider.example.

Jak widzimy, w wiadomości pojawia się znak <LF>.<CR><LF> (\n.\r\n). Znak ten powinien zostać zignorowany, a wszystko co znajduje się po nim potraktowane jako dalsza treść tej samej wiadomości, jednak podatne serwery potraktują tę sekwencję jako koniec danych. W istocie rzeczy, wszystko, co znajduje się dalej zostanie wykonane (z pominięciem normalnych reguł postępowania dla takich wiadomości).

W efekcie nasz adresat, user@provider.example, otrzymał dwie wiadomości. 

Jak widać, w określonych sytuacjach atak umożliwia wysyłanie wiadomości z wiarygodnie zespoofowanymi danymi nadawcy, co może zostać wykorzystane do przeprowadzania efektownych ataków phishingowych oraz podszywania się pod znane i zaufane osoby lub instytucje.

Wietse Venema z Postfiksa przypomina, że luka została wprowadzona „wiele dekad temu” w Sendmailu. Ze względu na kompatybilność wiele serwerów przejęło zachowanie Sendmaila. Takie zachowanie jest niezgodne ze specyfikacją RFC. Badacze z SEC Consult przytaczają dokument RFC 5322, który mówi, że zwyczaj akceptowania linii kończących się na <LF> okazał się powodować więcej problemów ze zgodnością niż rozwiązywać, a sekwencja <LF>.<LF> (pusta linia, bez powrotu karetki) nie może być traktowana jako równoważna sekwencji <CRLF>.<CRLF> jako wskazanie końca danych. CR i LF muszą występować razem jako CRLF.

Pewne kontrowersje wywołał sposób oraz czas publikacji informacji. Członkowie zespołu SEC Consult zauważają, że skontaktowali się z konkretnymi dostawcami, których dotyczył problem (Microsoft, Cisco, GMX/Ionos). Microsoft i GMX szybko naprawiły problemy. Inaczej było w przypadku Cisco, gdzie problem ten został określony jako cecha oprogramowania, a nie problem bezpieczeństwa. 

Badacze zadeklarowali, że podczas całego procesu ściśle przestrzegali swoich zasad odpowiedzialnego ujawniania informacji. Ponadto zwracają uwagę, że przy braku zaangażowania ze strony Cisco („the „vulnerability” in Cisco Secure Email (Cloud) Gateway is not a bug, but a feature”) chcieli, aby użytkownicy bramki Cisco Secure Email Gateway oraz usługi Cisco Secure Email Cloud Gateway dowiedzieli się o problemie, a także zyskali szansę na odpowiednią zmianę swoich konfiguracji.

Z taką oceną sytuacji nie zgadza się odpowiedzialny za rozwój Postfiksa Wietse Venema, który zauważa, że kluczowe informacje nie zostały przekazane opiekunom Postfiksa przed publikacją informacji o ataku, co w jego ocenie doprowadziło do prawdopodobnego niezamierzonego opublikowania błędu typu 0-day. Dodatkowo punktuje on publikację na kilka dni przed przerwą świąteczną i związanym z nią zamrożeniem zmian w konfiguracji w wielu środowiskach produkcyjnych.

Sposób działania bramki i usługi Cisco (konwersja znaków CR i LF na znaki CRLF) sprawia, że atak SMTP Smuggling jest możliwy w przypadku domyślnej konfiguracji. Zgodnie ze stanowiskiem Cisco taki sposób działania jest zgodny z ich założeniami i jako taki nie jest traktowany jako błąd. Użytkownicy i klienci rozwiązań pocztowych Cisco mogą uniknąć otrzymywania wiadomości z wiarygodnie zespoofowanymi kopertami poprzez zmianę domyślnej konfiguracji zgodnie z zaleceniami dostępnymi na tej stronie.

Problem stwierdzono także w popularnych MTA takich, jak Postfix, Exim i Sendmail, gdzie identyfikowany jest jako CVE-2023-51764 odpowiednio dla Postfiksa, CVE-2023-51766 dla Exima oraz CVE-2023-51765 dla Sendmaila. Warto zapoznać się z uwagami publikowanymi przez dystrybutorów oprogramowania. Na przykład w Postfiksie poprawka bezpieczeństwa obejmuje wprowadzenie nowej opcjonalnej funkcji 'smtpd_forbid_bare_newline’, która ze względu na konieczność zachowania stabilności i ewentualnej kompatybilności z istniejącymi już instalacjami domyślnie jest ustawiona w pozycji 'no’. Administratorzy powinni samodzielnie i świadomie ustawić wartość 'yes’ po uprzednim stwierdzeniu braku problemów w działaniu ich serwera pocztowego. Aby zachować kompatybilność z niestandardowymi klientami, Postfix domyślnie wyklucza klientów zawartych w mynetworks (zmienna ‘smtpd_forbid_bare_newline_exclusions = $mynetworks’ w pliku konfiguracyjnym main.cf).

Tak prosty i tak dobrze poznany protokół także może kryć niespodzianki. Prawdopodobnie jest kwestią czasu, kiedy luka zacznie być wykorzystywana przez przestępców na podatnych serwerach. Niestety przestępcy (cyberzbóje?) mogą wykorzystywać nawet tak pozornie błahe problemy do swoich celów. Tym bardziej jest to groźne, jeśli bezgraniczne zaufanie do mechanizmów kontroli i bezpieczeństwa usypia naszą czujność.

Linki:

1. https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide/

2. https://pl.wikipedia.org/wiki/Koniec_linii

3. https://www.rfc-editor.org/rfc/rfc5321

4. https://sec-consult.com/vulnerability-lab/responsible-disclosure-policy/

5. https://www.postfix.org/smtp-smuggling.html

6. https://www.cisco.com/c/en/us/td/docs/security/esa/esa15-0/user_guide/b_ESA_Admin_Guide_15-0/b_ESA_Admin_Guide_12_1_chapter_0100.html?bookSearch=true

~pu