Poniedziałek z trenerem – ciekawe ataki na nagłówki wiadomości

Oprócz testów aplikacji i systemów czasem potrzeba (i opłaca się) sprawdzić odporność na ataki samych pracowników. Nie znaczy to jednak, że nie warto wspomagać się w takich działaniach wiedzą techniczną.

Jeśli chodzi o ataki na użytkowników bardzo popularne (i skuteczne) okazują się zwyczajne wiadomości e-mail. Typowo zawierają one odnośnik do fałszywej strony lub złośliwy załącznik. Odkładając na bok jednak samą zawartość wiadomości, zaufanie budzi głównie jej nadawca. Jeśli serwer poczty z którego korzystamy nie jest zabezpieczony odpowiednimi mechanizmami, bez problemu przyjmie wiadomości o sfałszowanym nagłówki From:. Takie wiadomości mogą wyglądać identycznie jak pochodzące z wybranego przez napastnika adresu. Całe szczęście w dzisiejszych czasach duża liczba serwerów zabezpieczona jest przy pomocy odpowiednich mechanizmów weryfikacji nadawcy (DMARC). Podejrzane e-maile są oznaczane jako SPAM, niebezpieczne, lub usuwane przed dostarczeniem.

W poprzednich odcinkach

W cyklu Poniedziałek z trenerem opisywaliśmy już:

• dwa proste błędy w kodzie Facebooka,
• cztery błędy do zdalnego wykonania kodu,
• modyfikacja jednego parametru za 10 000 dolarów.

Jak podrobić nagłówek

Jak poprawić skuteczność ataków socjotechnicznych z wykorzystaniem wiadomości e-mail? Z pomocą przychodzą twórcy Mailsploit. Jest to projekt skupiony wokół błędów w samych klientach poczty, a więc krok dalej niż mechanizmy zabezpieczeń w serwerach ją przekazujących. Przypomnijmy, że zależy nam na sfałszowaniu adresu nadawcy wiadomości. W zasadzie wystarczy, że program pocztowy z którego korzysta ofiara odpowiednio go wyświetli! Mailsploit jest zbiorem takich tricków dla ponad 30 klientów, m.in. Apple Mail, Mozilla Thunderbird, czy ProtonMail.

Główny błąd polega na przetwarzaniu znaków spoza ASCII w nagłówkach wiadomości. Większość klientów poczty (również aplikacji webowych) nie przetwarza poprawnie takich nagłówków, co pozwala na fałszowanie nadawcy. Reprezentacja takiego ciągu może wyglądać tak:

=?utf-8?b?[BASE-64]?=

lub tak:

=?utf-8?Q?[QUOTED-PRINTABLE]?=

Wykorzystując kombinacje sekwencji i znaków specjalnych, np. znaków nowej linii czy null-byte możliwe jest ukrycie lub usunięcie domeny z pola nadawcy. Na przykład klient na iOS podatny jest na wstrzykiwanie null-byte, a klient na macOS wyświetla wartość zawartą w nawiasach. Wyobraźmy sobie taki nagłówek:

From:
=?utf-8?b?${base64_encode('adam[at]zaufanatrzeciastrona.pl')}?==?utf-8?Q?=00?==?utf-8?b?${base64_encode('(p.sierocinski[at]logicaltrust.net)')}[email protected]

który po faktycznym zakodowaniu base64 można wysłać w wiadomości:

From:
=?utf-8?b?YWRhbUB6YXVmYW5hdHJ6ZWNpYXN0cm9uYS5wbA==?==?utf-8?Q?=00?==?utf-8?b?KHAuc2llcm9jaW5za2lAbG9naWNhbHRydXN0Lm5ldCk=?=@domena.atakujacych

Po odczytaniu przez program przybierze formę:

From:
adam[at]zaufanatrzeciastrona.pl\0(p.sierocinski[at]logicaltrust.net)@domena.atakujacych

Wyświetlony pod iOS nadawca e-maila będzie wyglądał jak

adam[at]zaufanatrzeciastrona.pl

podczas gdy wyświetlony na macOS będzie to

p.sierocinski[at]logicaltrust.net

Dodatkowo może być pomocne dodanie odpowiedniego nagłówka Reply-To:, na wypadek jeśli ofiara postanowi odpowiedzieć na naszą wiadomość. Wysyłając w ten sposób spreparowane wiadomości warto skonfigurować na serwerze DMARC, bo podczas sprawdzania domeny na serwerze (domena.atakujacych) będzie się ona zgadzać. Może to wręcz uwiarygodnić nasze wiadomości, przynajmniej na początku działania kiedy nasza domena nie będzie oznaczona jako podejrzana.

Kto był podatny – lub raczej kto nie był

Statystyki projektu podają, że błąd dotykał przynajmniej 33 różnych produktów. W 8 z nich błąd został poprawiony, w 12 przyjęty do wiadomości przez producentów. Dwóch z nich (Mozilla i Opera) nie zamierza poprawić błędu, podczas gdy jeden (Mailbird) zamknął komunikację bez odpowiedzi. 12 pozostałych otrzymało informacje o błędzie, lecz nie określiło czy udostępni poprawkę. Odkrywcy ataków prowadzą dokładna listę podatnych programów i usługodawców.

Na stronie odkrywców można przetestować różne wersje na własnej skórze – demo. A jak się bronić? Dobrze jest podpisywać (oraz szyfrować) nasze wiadomości przy pomocy PGP. Poza tym na pewno warto aktualizować oprogramowanie z którego korzystamy.

Jako bonus twórcy projektu wykryli podatności XSS w kilku klientach poczty, np. Hushmail. Payload wyglądający w taki sposób:

From:
=?utf-8?b?c2VydmljZUBwYXlwYWwuY29tPGlmcmFtZSBvbmxvYWQ9YWxlcnQoZG9jdW1lbnQuY29va2llKSBzcmM9aHR0cHM6Ly93d3cuaHVzaG1haWwuY29tIHN0eWxlPSJkaXNwbGF5Om5vbmUi?==?utf-8?Q?=0A=00?=@mailsploit.com

czyli po odkodowaniu:

From: [email protected]<iframe style="display: none;" src="https://www.hushmail.com" width="300" height="150">

Powodował dopisanie kodu HTML do strony. Po kliknięciu w przycisk „Create a rule” kod wskazany przez atakującego był uruchamiany.

Wygląda na to, że badania wciąż trwają, a kolejni badacze zainspirowani przez pwnsdx rozszerzają je o następne produkty.

Naucz się zabezpieczać swoje aplikacje

Wielu programistów nie posiada umiejętności pozwalających im na wykrywanie podobnych scenariuszy ataku. Na naszych szkoleniach pokazujemy wiele przykładów zagrożeń, dzięki którym autorzy aplikacji lepiej przewidują takie sytuacje jak opisana powyżej.