Zły e-mail w kopercie ukryty

Phishing – na co wskazuje m.in. Raport CERT Orange Polska 2017 – to główny wektor dystrybucji złośliwego oprogramowania, które trafia na nasze komputer. A jako, że przy rosnącej świadomości zagrożeń coraz trudniej nas oszukać, przestępcy uciekają się do różnych sposobów. Bo o ile wysłanie emaila z „fakturą” z adresu hacker007@oszukamcie.pl nikogo nie przekona do wykonania przelewu (a w zasadzie nawet do otwarcia dokumentu) to na adres nadawcy sp_marzena.bojar@orange.pl (przykład autentyczny) kilka osób może się już nabrać.

Skąd jednak wyglądający na oficjalny mail z domeny @orange.pl (swoją drogą warto pamiętać, że nasze faktury do klientów wychodzą z domeny @pl.orange.com). Choćby dlatego, że adres źródłowy e-maila wyświetlany w programie pocztowym to jedna z najprostszych rzecz do podrobienia. Wystarczy zapakować mail do… koperty, oczywiście wirtualnej. Jak to robimy? Poniżej przykład komunikacji z serwerem SMTP po połączeniu standardowym programem telnet ({k} – polecenie wysłane od strony programu telnet; {s} – odpowiedź serwera).

{k}helo MyDomain.com //tu przedstawiamy się nazwą swojej domeny

{s}250 smtp.myISP.com

{k}mail from: moj_adres@MyDomain.com //podajemy nasz autentyczny, istniejący adres

{s}250 ok

{k}rcpt to: adresat1@RealDomain.com //pierwszy adresat naszej wiadomości

{s}250 ok

{k}rcpt to: adresat2@RealDomain.com //drugi adresat naszej wiadomości

{s}250 ok

{k}data // rozpoczynamy przekazywanie treści wiadomości

{s}354 go ahead

{k}To: lewy_adres_odbiorcy@example.com // adres odbiorcy widoczny w programie pocztowym

{k}From:  lewy_adres_nadawcy@example.com // adres nadawcy widoczny w programie pocztowym

{k}Subject: Wezwanie do zapłaty

{k}

{k}Proszę opłacić zaległą fakturę

{k}.

{s}250 ok 1384905446 qp 21500

{k}quit

Do przesyłki możemy dołączyć plik faktury, który uprawdopodobni treść wiadomości, a przede wszystkim będzie zawierał skrypty ze szkodliwym oprogramowaniem. Przykład jest oczywiście uproszczony, choćby dlatego, iż zakładamy, że serwer smtp.myISP.com przyjmie przesyłkę dla adresu z domeny MyDomain.com i nie będzie wymagał autoryzacji.

Jak widać w załączonym przykładzie, w widocznym w programie mailowym parametrze „From:” możemy wyświetlić całkowicie zafałszowane informacje, nie powiązane w żaden sposób z faktycznym nadawcą. Stanowią one de facto treść maila, a faktyczne adresy nadawcy i odbiorcy są wymieniane podczas niewidocznej dla nas „rozmowy” między serwerami.

Oczywiście nie musimy pozostawać bezbronni – jest kilka sposobów na ochronę przed oszustami.

1. Sprawdzenie reputacji serwera myISP.com przy użyciu dedykowanego narzędzia. Jeżeli reputacja jest niska, wiadomość powinna trafić do folderu ze spamem.
2. Sprawdzenie w DNS rekordu SPF (Sender Policy Framework), wskazuj ącego jakie serwery mają prawo wysyłać korespondencję w imieniu tej domeny. Najprostszy przykład zapisu w rekordzie SPF wygląda następująco: MyDomain.com. IN TXT „v=spf1 ip4:44.22.33.55 -all”
   Oznacza on, iż wiadomości z domeny MyDomain.com ma prawo wysyłać wyłącznie host o adresie IP 44.22.33.55. Jeżeli serwer myISP.com ma inny adres, sprawdzenie SPF od razu odkryje niecne plany przestępcy.

Obie metody można wykonać ręcznie, tym niemniej są one przede wszystkim podstawą każdego automatycznego systemu antyspamowego. Czy zabezpiecza nas to przed podszywaniem się poprzez zmianę parametru From:? Niekoniecznie. Wystarczy bowiem znaleźć serwer o wysokiej reputacji, założyć na nim konto pocztowe i wysyłać wiadomości, podszywając się pod dowolną domenę np. orange.pl. Filtr antyspamowy sprawdzi zgodność rekordu SPF z adresem serwera, wszystko się będzie zgadzało i pierwsza część planu przestępcy się uda (tym bardziej, że faktycznych parametrów nie widać w programach do obsługi poczty).

Jeżeli nasz filtr antyspamowy nie robi głębszej analizy możemy to zrobić sami, wystarczy w zajrzeć do nagłówka wiadomości. Poniżej przykład nagłówka dla wiadomości zawierającej złośliwe oprogramowanie (z usuniętą nazwą operatora konta pocztowego ofiary):

Od sp_marzena.bojar@orange.pl
Do adresat@[xxxxx].pl

{sekcja 1}

Received from fmx22.pf.[xxxxx].pl (fmx22.pf.[xxxxx].pl [127.0.0.1])
by fmx22.pf.[xxxxx].pl (Postfix) with ESMTP id 72CEB6004E; Wed, 7 Feb 2018 08:58:02 +0100 (CET)
X-Envelope-From <federatest32@certimprese.it>

{sekcja 2}

Received from S041202090027.seint-userreverse.kddi.ne.jp (S041202090027.seint-userreverse.kddi.ne.jp [27.90.202.41])
by fmx22.pf.[xxxxx].pl (Postfix) with ESMTP; Wed, 7 Feb 2018 08:57:55 +0100 (CET)

{sekcja 3}

Received from [163.146.5.184] (account concordp@fastwebnet.it HELO xiwexbgdnkzquk.usamwgcjew.ch)
by S041202090027.seint-userreverse.kddi.ne.jp (Exim 4.89) with ESMTPA id dA6e7935 for adresat@[xxxxx].pl; Wed, 7 Feb 2018 16:57:59 +0900

{sekcja 4}

Received from [149.200.132.165] (account concordp@fastwebnet.it HELO QIPASIH.certimprese.it)
by S041202090027.seint-userreverse.kddi.ne.jp (Exim 4.89) with ESMTPA id aYHVA-OrT0kR-py for adresat@[xxxxx].pl; Wed, 7 Feb 2018 16:57:59 +0900

{sekcja 5}

Subject efaktury
X-Priority 3
Thread-Index JMZltpyQtnK1SYuGwjLak4dSmFkZj==
MIME-Version 1.0
Message-ID <376574.571393.1251fb@HIBYJOX.certimprese.it>
Content-type multipart/mixed; boundary=”_EXK–lvvJcwHI5aNSVqCGfUGzmkn7IsYqPvW2yAejUSZTda”

Kolejne sekcje nagłówka pokazują drogę naszej wiadomości w sieci.

Sekcja 1 to host serwera [xxxxx].pl na którym ofiara ma konto pocztowe. Parametr X-Envelope-From wskazuje faktyczny adres źródłowy wiadomości (federatest32@certimprese.it), którym opisana jest „koperta” naszej wiadomości. Większość filtrów antyspamowych sprawdza tylko ten adres pod względem zgodności rekordu SPF, gdy tymczasem ofiara widzi adres w domenie @orange.pl.

Sekcja 2 to host [27.90.202.41], z którego wiadomość trafiła do naszego serwera, sekcja 3 – host [163.146.5.184], zaś sekcja 4 – host [149.200.132.165] – z dużym prawdopodobieństwem oryginalny nadawca poczty.

Warto pamiętać, że jedynymi nagłówkami na których można polegać to dodawane przez kolejne serwery pocztowe nagłówki Received. Wszelkie pozostałe informacje można z powodzeniem tworzyć własnoręcznie.

Nam zależy na sprawdzeniu czy host z sekcji 2 ma prawo wysyłania wiadomości w imieniu domeny orange.pl . W tym celu korzystamy z ogólnodostępnych narzędzi do sprawdzania rekordów SPF np. na stronie mxtoolbox.com, otrzymując następującą odpowiedź:

Zapytanie o rekord SPF dla Orange.pl wskazuje – jak widać w tabeli – poprawne dane, tym niemniej nie zgadzają się one z adresami IP widocznymi w nagłówkach. Dodatkowo SPF wskazuje także na obecność rekordu MX, a wynikiem jego sprawdzenia jest:

Powyższa analiza dowodzi, że dzięki mechanizmowi kopertowania e-mail dotarł do adresata, mimo iż serwer nadawcy nie miał uprawnień do wysyłania wiadomości w imieniu domeny orange.pl. Dlatego w dzisiejszych czasach tak istotne jest analizowanie każdego rozwiązania IT pod względem bezpieczeństwa – implementacja odpowiedniego, rozbudowanego mechanizmu antyspamowemu na serwerze ofiary spowodowałaby odrzucenie wiadomości jako spamowej/phishingowej zanim trafiłaby do adresata.

Zdjęcie autorstwa Calro na licencji CC BY 2.0.