W tym roku mija 50. rocznica przesłania pierwszej wiadomości email. Na początku lat 70., gdy projektowane były stojące za tym mechanizmy, niestety mało kto myślał o bezpieczeństwie informacji, a kluczowymi kwestiami były stabiloność i prostota.

Skrzynka pocztowa obecnie jest centrum życia większości z nas, wykorzystywana zarówno w sferze biznesowej, jak i prywatnej. Wraz ze zwiększonym wykorzystaniem pojawiła się potrzeba na zapewnienie lepszego poziomu bezpieczeństwa zarówno samej skrzynki, treści wiadomości, jak i mechanizmów jej przesyłania. W tym artykule skupiamy się na tym ostatnim, bo okazuje się, że mimo upłynięcia 50 lat, podszywanie się pod nadawcę wiadomości jest nadal jedną z podstawowych technik wykorzystywaną przy atakach socjotechnicznych.

Przykładowo, w czerwcu 2021 r. została wykorzystana błędna konfiguracja mechanizów SPF oraz DMARC dla domeny sej.pl, w wyniku czego na skrzynki sejmowe zostały dostarczone maile phishingowe, wykorzystujące jej podobieństwo do domeny sejm.pl.

Źródło: https://twitter.com/radekfogiel/status/1404752636868534279

Przez lata powstawały kolejne standardy i mechanizmy, które miały spowodować, że będzie to trudniejsze. Niestety liczba możliwości ich konfiguracji oraz ich wariantów doprowadziła do tego, że bardzo często są nieużywane albo skonfigurowane niepoprawnie.

W artykule postaramy się wytłumaczyć działanie trzech podstawowych mechanizmów mających na celu weryfikację nadawcy wiadomości: SPF, DKIM i DMARC, oraz spróbujemy obalić kilka powstałych mitów z nimi związanych.

SPF (Sender Policy Framework) – RFC7208

Mechanizm ten pozwala właścicielowi domeny zdefiniować adresy IP serwerów uprawnionych do wysyłki maili w imieniu tej domeny. Sprawdzenie odbywa się na podstawie domeny obecnej w polu MAIL FROM wg. RFC5321 – RFC5321.MailFrom, znane też jako Envelope-Sender. Należy jednak pamiętać, że zawartość pola MAIL FROM może nigdy nie pojawić się w nagłówku widocznym w klientach pocztowych takich jak MS Outlook czy Thunderbird.

Implementacja techniczna SPF

SPF jest definiowany w rekordzie TXT domeny która ma być chroniona. Serwer pocztowy, który otrzymuje wiadomość, wysyła zapytanie o rekord SPF dla domeny z pola MAIL FROM (RFC5321.MailFrom), a następnie go analizuje.

O rekord TXT możemy odpytać np. narzędziem dig i przefiltrować narzędziem grep pod kątem rekordu SPF. Poniżej przykład takiego zapytania dla domeny nask.pl :

dig txt nask.pl | grep 'v=spf1'

W odpowiedzi otrzymamy rekord SPF. W kolejnym podrozdziale zostaną opisane poszczególne jego składowe.

nask.pl. 600 IN TXT "v=spf1 include:_spf.nask.pl include:_spf2.nask.pl     
ip4:195.187.245.33/24 ip4:193.59.201.32/27 ip4:193.59.201.64/27 
ip4:193.59.201.238/32 ip4:195.187.242.0/24 ip4:193.59.204.167/32 
ip4:194.181.0.106 ip4:194.181.0.102 ip4:195.187.6.28 -all"

Serwer pocztowy, który otrzymał wiadomość, sprawdza czy adres IP, z którego wiadomość została nadana, zawiera się na ostatecznej (po rozwiązaniu wszystkich składowych) liście dozwolonych adresów IP w rekordzie SPF. Jeśli nie, to zależnie od konfiguracji serwera pocztowego (lub konfiguracji mechanizmu DMARC), wiadomość może zostać odrzucona albo przeniesiona do spamu.

Struktura rekordu SPF

Rekord SPF zaczyna się od stałego fragmentu v=spf1 i składa się z dyrektyw opisujących oczekiwane zachowanie. W każdej regule kwalifikator określa co powinno się stać w sytuacji, gdy dopasuje się do hosta próbującego przekazać wiadomość.

Dostępne kwalifikatory to:

Jeśli dana dyrektywa nie posiada kwalifikatora, to przyjmowana jest wartość domyślna Pass(+)

Typy dyrektyw (ang. mechanisms) opisane są w piątym rozdziałe RFC. Każda z nich pozwala na określenie warunków, które powinny się spełnić, żeby całe sprawdzenie przebiegło pomyślnie.

• include:_spf.nask.pl - dyrektywa dopasuje się tylko jeśli rekord SPF podanej domeny zwróci wynik Pass(+). W prostych słowach, rekord SPF dla podanej domeny (w przykładzie "_spf.nask.pl") jest również uwzględniany w sprawdzeniach.
• a:google.com - domena jest rozwiązywana i jej rekord A jest porównywany z IP nadawcy. Gdy użyte jest samo a, sprawdzany jest rekord A domeny, dla której aktualnie weryfikowana jest polityka.
• mx:google.com - rekordy A dla rekordów MX podanej domeny dodawane są jako IP uprawnione do wysyłki. Gdy użyte jest samo mx sprawdzany jest rekord MX domeny, dla której aktualnie weryfikowana jest polityka.
• ip4:195.187.245.33/24 - adres IPv4 lub zakres adresacji, który ma zostać porównany z IP nadawcy.
• ip6:2001:db8::cd30 - adres IPv6 lub zakres adresacji, który ma zostać porównany z IP nadawcy.
• exists:<domena> - pozwala na dynamiczne skonstruowanie nazw domen za pomocą makr. Dopasowuje się w przypadku, gdy odpowiedź DNS zwróci przynamniej jeden rekord A.
• all - dyrektywa dopasowująca się do każdego adresu, zazwyczaj jest ustawiana na końcu rekordu SPF jako wartość domyślna z kwantyfikatorem Fail(-) – odrzuć, jeśli nie pasuje do poprzednich dyrektyw.

W sytuacji, gdy nie dopasuje się żadna dyrektywa, to domyślnie zwracanym wynikiem jest "neutral". Tak skonstruowany rekord nie podnosi jednak poziomu bezpieczeństwa w przypadku prób podszywania się. Dlatego sugerowanym rozwiązaniem jest umieszczenie zawsze na końcu rekordu dyrektywy -all (Fail) lub ~all (Softfail).

Ograniczenia dla reguł SPF: Maksymalna długość rekordu to 255 znaków i maksymalnie 10 rozwiązań domen (rozwiązania występują przy tagach: a, mx, ptr, include, exists), wliczając w to rozwiązania rekursywne.

DKIM (DomainKeys Identified Mail) – RFC6376

Jest to kolejny mechanizm, który ma za zadanie utrudnić podszywanie się pod nadawcę wiadomości email, ale także ingerowanie w jej treść. Daje możliwość wzbogacenia wiadomości o podpis kryptograficzny z body, nagłówka From, czy innych wybranych pól. Serwer odbiorcy może zweryfikować autentyczność wiadomości wykorzystując kryptografię asymetryczną oraz klucz publiczny odczytany z odpowiedniego rekordu DNS sprawdzanej domeny.

Podpis jest dodawany do nagłówka wiadomości jako pole DKIM-Signature, na przykład:

DKIM-Signature: 
v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncas.us-cert.gov; s=15q3; [email protected]; h=Content-Transfer-Encoding:
Content-Type:x-subscriber:X-Accountcode:Errors-To:MIME-Version:
Message-ID:X-ReportingKey:Subject:Date:To:Reply-To:From; bh=bqWW
VsSFeYnMUseujsFFol8xU8ZRNz18EBcFtuxI91c=; b=hjQjcCOi/CzTr1STuUnN
digjN5gW2Wr81UR2CBKpwUV8MqYNlZV76YuGdX+T ...

Opis ważnych pól które mogą wystąpić w takich nagłówkach:

• d= - domena, którą należy odpytać o klucz publiczny do odszyfrowania podpisu
• s= - selector wskazujący, który z opublikowanych kluczy publicznych ma być użyty
• h= - jakie pola nagłówka zostały podpisane i mają zostać sprawdzone
• bh= - hash treści wiadomości
• a= - algorytm, który został użyty do wyliczenia hasha (podpisu)
• b= - zaszyfrowany podpis (hash wyliczony przez wysyłającego)

Klucz publiczny jest umieszczany w rekordzie TXT subdomeny zbudowanej z pól Selectora i Domeny nagłówka DKIM-Signature. Np. 15q3._domainkey.ncas.us-cert.gov Gdzie 15q3 jest wartośćią pola s, ncas.us-cert.gov wartością pola d, a _domainkey stałe.

Po pobraniu klucza publicznego, pole b jest odszyfrowywane i otrzymany hash jest używany do weryfikacji zgodności podpisu. Odbywa się to poprzez wyliczenie nowego hasha z aktualnego body oraz nagłówków i porównaniu go z otrzymanym.

DMARC (Domain-based Message Authentication, Reporting & Conformance) – RFC7489

Dopełniającym dwa opisane wcześniej mechanizmy jest DMARC. Stanowi on zestaw reguł budowanych na bazie SPF i DKIM pozwalających zdecydować czy wiadomość faktycznie przyszła od wysyłającego za którego się podaje. Jako centralny punkt odniesienia bierze pole RFC5322.From (widoczone w klientach pocztowych). Posiada też możliwość raportowania wykrytych nieprawidłowości.

DMARC opiera się na dwóch kategoriach sprawdzeń:

• Dla SPF - Czy dla otrzymanej wiadomości reguła SPF przeszła sprawdzenia ORAZ czyRFC5321.MailFrom zgadza się z RFC5322.From (czy pole sprawdzane przez SPF zgadza się z tym wyświetlanym w klientach). Dla ustawienia relax dowolne z pól może być subddomeną, dla strict domeny muszą być dokładnie takie same.
• Dla DKIM - Czy otrzymana wiadomość jest poprawnie podpisana wg. DKIM ORAZ czy wartość w polu d= nagłówka DKIM zgadza się z RFC5322.From. Dla ustawienia relax dowolne z pól może być subddomeną, dla strict domeny muszą być dokładnie takie same.

Dowolne z dwóch kategorii sprawdzeń (SPF LUB DKIM) musi się zakończyć sukcesem, żeby sprawdzenie DMARC zostało uznane za sukces. Dobrze obrazuje to następujące równanie logiczne:

DMARC authentication pass = 
(SPF authentication pass AND SPF identifier alignment) 
OR 
(DKIM authentication pass AND DKIM identifier alignment)

Implementacja techniczna DMARC

W momencie, gdy przychodzi email, serwer odbiorcy bierze domenę z nagłówka RFC5322.From, a następnie sprawdza rekord TXT dla subdomeny _dmarc tej domeny. Np. w przypadku, gdy email przychodzi z domeny wydzial.przykladowauczelnia.edu.pl, odpytana zostanie domena _dmarc.wydzial.przykladowauczelnia.edu.pl.

Jeśli nie ma tam poprawnego rekordu, znajdowany jest Public Suffix, w którym znajduje się badana domena. Public Suffix to taka domena, w której wiele niezależnych organizacji może zarejestrować własną subdomenę. W tym przypadku jest to domena edu.pl. Następnie serwer odbiorcy sprawdza rekord DMARC domeny bezpośrednio poniżej Public Suffix, czyli w tym przypadku przykladowauczelnia.edu.pl - więc kolejne zapytanie o rekord TXT zostanie wykonane do domeny _dmarc.przykladowauczelnia.edu.pl.

Dzięki temu wystarczy skonfigurować rekord DMARC na domenie bezpośrednio poniżej Public Suffix (będzie to ta domena, którą organizacja zakupiła od rejestratora domen).

W rekordzie DMARC umieszczony jest wpis definiujący reguły dopasowania, tzn. co zrobić z wiadomością, gdy nie zostanie spełnione któreś ze sprawdzeń, oraz gdzie wysyłać raporty.

Podobnie jak przy SPF możemy o ten rekord odpytać np. przy użyciu narzędzia dig:

dig +short txt _dmarc.google.com

W odpowiedzi otrzymamy rekord DMARC:

"v=DMARC1; p=reject; rua=mailto:[email protected]"

Opis ważnych pól, które możemy spotkać w takich rekordach:

• v= - wersja protokołu, obecnie musi być DMARC1
• rua= - lista adresów, na które mają przyjść raporty ze sprawdzeń, opisana w formacie mailto:<adres email>. W przykładzie [email protected]
• adkim= - ustawienia restrykcyjności dla sprawdzeń dopasowania DKIM – r (relaxed) lub s (strict). W relaxed porównywane są tylko domeny narzędne (dopuszczalne są subdomeny). Domyślnie relaxed.
• aspf= - ustawienia restrykcyjności dla sprawdzeń dopasowania SPF – r (relaxed) lub s (strict). W relaxed porównywane są tylko domeny narzędne (dopuszczalne są subdomeny). Domyślnie relaxed.

• p= (polityka) - co ma się stać z wiadomością która nie przejdzie sprawdzeń, możliwe opcje:

  Opcja dla p=	Opis
  none	nie są podejmowane żadne akcje, tylko raportowanie
  quarantine	wiadomość powinna zostać przeniesiona do spamu
  reject	wiadomość powinna być odrzucona

Rekomendujemy ustawienie polityki quarantine lub reject, aby zalecić serwerowi odbiorcy by potraktował niepoprawnie zweryfikowaną wiadomość jako spam (quarantine) lub ją odrzucił (reject).

Więcej możliwych pól można znaleźć w standardzie opisującym mechanizm DMARC.

Ustawienia dla domen niesłużących do wysyłki poczty

Warto zaznaczyć, że nawet jeśli nie planujemy używać danej domeny do wysyłania maili, to i tak warto dla niej skonfigurować rekordy SPF oraz DMARC. Ktoś może podszywać się pod naszą domenę, mimo że nie mamy w niej żadnej skrzynki pocztowej. Prosta reguła SPF w postaci v=spf1 -all oraz DMARC w postaci v=DMARC1; p=reject; adkim=s; aspf=s; znacznie to utrudni.

Podsumowanie

Mimo że podstawowe założenia działania poczty są proste, to dodatkowe mechanizmy bezpieczeństwa jak SPF, DKIM czy DMARC mogą przysporzyć kłopotu. W szczególności gdy musimy poprawnie skonfigurować nasz serwer pocztowy albo rozstrzygnąć, czy dana wiadomość została faktycznie wysłana z adresu, za który się podaje.

W kolejnym artykule opiszemy coś, z czym spotykamy się na co dzień. Na przykładzie konkretnego maila i jego nagłówków pokażemy, jak sprawdzić, skąd przyszła wiadomość email i jaki jest jej faktyczny nadawca.