Simple Mail Transfer Protocol (SMTP) i problemy z weryfikacją nadawcy wiadomości

Protokół komunikacji mailowej (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.

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 iż nadawca może wysłać wiadomość w obrębie jednego serwera bez weryfikacji poprzez login/hasło.

Czyli np. właściciel konta kowalski@adresfirmy.pl może wysłać wiadomość do nowak@adresfirmy.pl, gdzie serwer 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 jakiś 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.

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:
250 ok
rcpt to:
250 ok
data
354 go ahead
from: szef
to: NOWAK
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:
1. Należy ufać tylko i wyłącznie nagłówkom doklejanym przez nasz serwer (odbiorcy), wszystkie inne informacje mogą być już sfałszowane
2. Na serwerach w Kei.pl w pierwszym polu nagłówka zawsze podawany jest envelope-sender

1. Return-Path:
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 ; 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 ; Tue, 30 Sep 2008 17:21:20 +0200 (CEST)
12. Date: 30 Sep 2008 17:21:20 +0200
13. From: KOWALSKI
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ć.

Poradę dla Czytelników Dziennika Internautów przygotowała firma Kei.pl dostawca usług hostingowych.