Prawda, czy fałsz? Weryfikujemy rzeczywistego nadawcę wiadomości e-mail

W obecnych czasach nie wyobrażamy sobie korespondencji bez użycia poczty elektronicznej, która w codziennej wymianie informacji całkowicie wyparła przesyłki tradycyjne. Niestety postęp cywilizacyjny i udogodnienia jakie niesie nam natychmiastowe dostarczenie przesyłki do celu potrafi przysporzyć wielu problemów z weryfikacją rzeczywistego nadawcy wiadomości. 

SMTP i problem z weryfikacją nadawcy wiadomości

Protokół komunikacji mailowej (Simple Mail Transfer Protocol – SMTP) jest to bardzo prosty zbiór reguł pozwalających na przesłanie wiadomości tekstowych. Początkowo wspierał wysyłanie tylko znaków tekstowych ASCII, w późniejszym okresie wprowadzono kodowania MIME, dzięki któremu może on służyć do wysyłania załączników binarnych (np. .zip, .jpg, .pdf). Należy jednak pamiętać, że pliki binarne zostają skonwertowane na rozpoznawane dla SMTP znaki ASCII przez co w/w załącznik w takiej wiadomości zostaje powiększony o około 50%.

Podstawowym problemem protokołu SMTP jest brak mechanizmu, dzięki któremu przeciętny użytkownik jest w stanie zweryfikować rzeczywistego nadawcę wiadomości. To niedociągnięcie pozwala nadużywać wiadomości e-mail zarówno do rozsyłania wirusów, spamu oraz prób podszywania się pod instytucje lub inne osoby w celu wyłudzenia danych.

Autoryzacja po stronie nadawcy (SMTP-AUTH)

Aby zaradzić powyżej opisanym niebezpieczeństwom, stworzono mechanizmy autoryzacji adresu wysyłającego wiadomość (SMTP-AUTH). Nie jest to jednak rozwiązanie skuteczne gdyż pozwala tylko na częściową weryfikacje nadawcy i to tylko w przypadku jeśli jego skrzynka znajduje się na serwerze pocztowym, z którego wysyłany jest e-mail. W takiej sytuacji nadawca musi dokonać autoryzacji przez podanie loginu i hasła, aby możliwe było wysyłanie wiadomości z jego konta.

Dzięki temu mechanizmowi mamy pewność, że osoba posługująca się kontem kowalski@adresfirmy.pl musiała się autoryzować, aby móc wysłać maila ze swojej skrzynki. Należy jednak pamiętać, że w tym momencie sprawdzany jest tylko tzw. envelope-sender, zaś sam protokół SMTP pozwala na dowolne manipulowanie polami nagłówka FROM, dlatego nawet jeśli kowalski@adresfirmy.pl po dokonaniu autoryzacji wysyła wiadomość, może w polu FROM wstawić nowak@innyadres.pl i taki właśnie adres ukaże się odbiorcy w programie pocztowym. Ponadto może dojść nawet do sytuacji, w której osoba z zewnątrz korzystając z niebezpiecznego serwera pocztowego (open-relay) lub bezpośrednio łącząc się z serwerem nadawcy, może podać jako envelope-sender cokolwiek@cokolwiek.pl zaś w polu FROM wiadomości wpisać jakiegoś zaufanego adresata (np. adres banku) próbując w treści wyłudzić często ważne dane.

Jak temu przeciwdziałać?

Na szczęście istnieją nieoficjalne „poprawki” protokołu SMTP, które weryfikują przesyłane dane np. sprawdzają czy envelope-sender zgadza się z wpisanym polem FROM wiadomości. Istnieje również mechanizm SPF, dzięki któremu weryfikowane jest IP serwera nadawcy z listą dozwolonych adresów, z których taka wiadomość mogła zostać wysłana . Należy jednak pamiętać, że wymieniane powyżej mechanizmy muszą być zaimplementowane po stronie serwera odbierającego wiadomość i nie zawsze są stosowane na mniejszych serwerach pocztowych, poważnie obniżając ich poziom zabezpieczenia. Niestety mechanizmy te podnoszą tylko poziom bezpieczeństwa nie pozwalając jednak na 100% weryfikację rzeczywistego nadawcy.

W Kei.pl domyślnie stosowane są wszystkie mechanizmy weryfikacji takie jak smtp-auth (również lokalnie), RBL (odrzucając wiadomości wysyłane z serwerów typu open-relay) oraz SPF. Na życzenie Klienta możliwe jest również włączenie mechanizmu weryfikowania ustawionego nagłówka FROM z envelope senderem.

Coraz częściej spotykanym zjawiskiem jest brak autoryzacji lokalnej, dzięki której administratorzy próbują „ułatwić życie” klientom. Brak autoryzacji przy wysyłce wiadomości na zewnątrz dyskryminuje w ogóle serwer pocztowy do wysyłania wiadomości (serwer taki staje się open-relay i bardzo szybko trafia na listę RBL uniemożliwiając mu dalsze wysyłki). Wyłączenie autoryzacji lokalnej polega na tym, że nadawca może wysłać wiadomość w obrębie jednego serwera bez weryfikacji poprzez login/hasło. Czyli np. władciciel konta kowalski@adresfirmy.pl może wysłać wiadomość do nowak@adresfirmy.pl, gdzieserwer pocztowy nie będzie wymagał podawania hasła i loginu od kowalskiego. Na pierwszy rzut oka taka konfiguracja nie wygląda groźnie, przynosi nawet pewne korzyści (brak problemów z forwardami wiadomości z serwerów, które nie korzystają z mechanizmów SRS, oraz możliwość wysyłki maili z urządzeń mobilnych które nie zawsze potrafią się autoryzować). Teoretycznie właściciel takiego serwera pocztowego będzie borykał się ze spamem rozsyłanym tylko lokalnie na jego serwerze. Spróbujmy jednak wyobrazić sobie sytuację, gdy osoba nieautoryzowana podszyje się pod swojego przełożonego prosząc o wysłanie poufnych danych na zewnętrze konto pocztowe (wystarczy zastosować metody socjotechniki). Taka osoba może również skorzystać z listy mailingowej podając jako envelope-sender adres moderatora dzięki czemu będzie mogła rozsyłać spam dla wszystkich subskrybentów takiej listy.

W Kei.pl włączona jest autoryzacje lokalna. Jedynie na wyraźne zlecenie Klienta usługa ta może zostać wyłączona, wykluczając tylko wskazany adres IP.

Poniżej zamieszczamy przykład nadużycia przy wyłączonej autoryzacji lokalnej. Aby wykonać tego typu działania wystarczy np. telnet.

telnet adresfirmy.pl 25

Trying xxx.xxx.xxx.xxx...
Connected to xxx.xxx.xxx.pl.
Escape character is '^]'.
220 smtp.tld.pl ESMTP
ehlo due
250-smtp.adresfirmy.pl
250-PIPELINING
250-8BITMIME
250-SIZE 31457280
250 AUTH LOGIN PLAIN CRAM-MD5
mail from: <kowalski@adresfirmy.pl>
250 ok
rcpt to: <nowak@adresfirmy.pl>
250 ok
data
354 go ahead
from: szef <kowalski@adresfirmy.pl>
to: NOWAK <nowak@adresfirmy.pl>
subject: prosze przeslij mi dane

Witam, wlasnie wyjezdzam na delegacje i nie bede mial dostepu do swojej skrzynki pocztowej.
Prosze przeslij mi hasla dostepowe na moj zewnetrzny adres:
nazwisko@innyadres.pl.

250 ok 1222786247 qp 22270

Jak zapobiec tego typu zdarzeniom?

Niestety nie można wymóc na użytkownikach analizy nagłówków mailowych i analizy trasy wiadomości. Dla przeciętnego Pana Nowaka nie są znane skróty w popularnych klientach pocztowych, które pozwalają obejrzeć nagłówek. Dodatkowo czytanie nagłówka wymaga pewnej wprawy i wiedzy gdyż osoba niepowołana może je celowo „zaciemnić”, a nawet częściowo sfałszować.

Jeśli już pokusimy się na taką pełną analizę (np. wciskając kombinację CTRL+U) należy pamiętać, że:

• Należy ufać tylko i wyłącznie nagłówkom doklejanym przez nasz serwer (odbiorcy), wszystkie inne informacje mogą być już sfałszowane.
• Na serwerach w Kei.pl w pierwszym polu nagłówka zawsze podawany jest envelope-sender.

1. Return-Path: <kowalski@adresfirmy.pl>
2. X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on 3032.s.tld.pl
3. X-Spam-Level: 
4. X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,DNS_FROM_RFC_POST,
 MISSING_MIMEOLE,SPF_PASS autolearn=disabled version=3.1.7
5. Delivered-To: firmax.pl-nowak@adresfirmy2.pl
6. Received: (qmail 18680 invoked by uid 45007); 30 Sep 2008 15:21:20 -0000
7. X-clamdmail: clamdmail 0.18a
8. Received: from smtp.adresfirmy.pl (123.123.123.123)
 by smtp.firmax.pl with SMTP; 30 Sep 2008 15:21:20 -0000
9. Received: by 239.firmax.pl (FIRMAX.PL, from userid 666)
 id 123QQQ; Tue, 30 Sep 2008 17:21:20 +0200 (CEST)
10. Received: from full.adresfirmy.pl (fu11.adresfirmy.pl [192.168.1.1])
 by 239.adresfirmy2.pl (ADRESFIRMY2.PL) with ESMTP id 4598320BAD
 for <nowak@adresfirmy2 .pl>; Tue, 30 Sep 2008 17:21:20 +0200 (CEST)
11. Received: from localhost (localhost [127.0.0.1])
 by fu11.xxx.pl (Postfix) with ESMTP id POSTFIX 832819831DA
 for <nowak@adresfirmy2.pl>; Tue, 30 Sep 2008 17:21:20 +0200 (CEST)
12. Date: 30 Sep 2008 17:21:20 +0200
13. From: KOWALSKI <kowalski@adresfirmy2.pl>
14. Subject: Haslo
15. To: nowak@adresfirmy2.pl
16. MIME-Version: 1.0
17. Content-Type: TEXT/plain; CHARSET=ISO-8859-2

Analizując więc źródło powyższej wiadomości należy zauważyć:

1. Envelope-senderem (rzeczywistym nadawcą) jest kowalski@adresfirmy.pl
2. Mamy pewność tylko i wyłącznie do nagłówków 1-8 , cała reszta wiadomości zależy już tylko i wyłącznie od tego co nadawca zechce nam przesłać.
3. Należy zauważyć, że envelope-sender jest różny od nadawcy podanego w polu FROM kowalski@adresfirmy.pl podszył się pod adres: kowalski@adresfirmy2.pl

Jak w takim razie zwykły użytkownik bez wnikania w źródła wiadomości może zweryfikować tożsamość swojego przełożonego?

Jednym z najprostszych i najpopularniejszych sposobów jest cyfrowe podpisywanie wiadomości po przez użycie mechanizmów kluczy asymetrycznych PGP. Taki podpis daje nam pewność, że nadawcą jest osoba, która jest w posiadaniu takiego podpisu i zna do niego hasło, dodatkowo podpis kluczem zabezpiecza przed modyfikacją wiadomości w kanale transmisji. Osoba wysyłająca wiadomość korzystając z tylko dla siebie znanego klucza prywatnego podpisuje maila, zaś program pocztowy odbiorcy weryfikuje czy w/w podpis pasuje do przekazanego mu wcześniej klucza publicznego nadawcy. Dodatkowo PGP pozwala na szyfrowanie wiadomości dzięki czemu tylko osoba upoważniona będzie mogła daną wiadomość przeczytać.

W Kei.pl każda osoba korzystająca z udostępnionego programu do odbioru poczty – (Webmail) ma możliwość szyfrowania i podpisywania swojej wiadomości poprzez intuicyjny panel okna pocztowego. Wymagane jest tylko stworzenie odpowiedniej pary kluczy i przekazanie ich publicznych wersji odbiorcom, w celu zweryfikowania podpisu.

Ela Kornaś

Od 15 lat zajmuje się technologiami hostingowymi, domenowymi oraz związanymi z bezpieczeństwem. Odpowiada za produkty domenowe oraz certyfikaty SSL. Codzienna praca polega na zapewnianiu Ci najciekawszej na rynku oferty nazw domenowych i certyfikatów SSL. Prywatnie uwielbia tenis i bieganie.