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 w tej chwili 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ę, iż mimo upłynięcia 50 lat, podszywanie się pod nadawcę wiadomości jest przez cały czas 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ć, iż będzie to trudniejsze. Niestety liczba możliwości ich konfiguracji oraz ich wariantów doprowadziła do tego, iż 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ć, iż zawartość pola MAIL FROM może nigdy nie pojawić się w nagłówku widocznym w klientach pocztowych takich jak MS Outlook czy Thunderbird.
Uwaga!
SPF samodzielnie nie sprawdza pola From wyświetlanego w klientach pocztowych –RFC5322.From, a jedynie RFC5321.MailFrom. SPF może przejść sprawdzenia poprawnie, choćby gdy pole From jest fałszywe. W prostych słowach, SPF nie chroni przed popularnym w atakach spoofingiem wyświetlanego adresu mailowego. Wyjątkiem od tego jest dodatkowe poprawne skonfigurowanie mechanizmu DMARC.
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 :
W odpowiedzi otrzymamy rekord SPF. W kolejnym podrozdziale zostaną opisane poszczególne jego składowe.
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żeli nie, to zależnie od konfiguracji serwera pocztowego (lub konfiguracji mechanizmu DMARC), wiadomość może zostać odrzucona albo przeniesiona do spamu.
Uwaga!
Zachowanie serwera pocztowego, do którego dotarła wiadomość niepoprawna według mechanizmu SPF, zależy od jego konfiguracji. Możliwe jest, iż mimo błędnej weryfikacji SPF, wiadomość dotrze do adresata.
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:
| - | Fail | Odrzuć |
| ~ | Softfail | Rekomenduj odrzucenie |
| + | Pass | Akceptuj |
| ? | Neutral | Nic nie sugeruj (Neutralne) |
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żeli 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 dzięki makr. Dopasowuje się w przypadku, gdy odpowiedź DNS zwróci przynamniej jeden rekord A.
- all - dyrektywa dopasowująca się do każdego adresu, zwykle jest ustawiana na końcu rekordu SPF jako wartość domyślna z kwantyfikatorem Fail(-) – odrzuć, jeżeli 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).
Uwaga!
W wielu miejscach RFC znajdziemy informacje o tym, iż jakieś zachowanie serwera pocztowego jest rekomendowane, a nie wymagane. Trzeba pamiętać, iż różne serwery pocztowe odbiorcy mogą różnie interpretować otrzymany rekord SPF. Np. wiele serwerów traktuje -all oraz ~all tak samo.
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:
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.
Uwaga!
DKIM sam w sobie nie ma mechanizmów sugerowania co zrobić z wiadomością z niezgodnym podpisem, mimo iż niektóre serwery pocztowe mogą to na różne sposoby interpretować. Aby świadomie wskazać co zrobić z taką wiadomością potrzebny jest mechanizm DMARC.
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:
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 mail.google.com, odpytana zostanie domena _dmarc.mail.google.com. jeżeli nie ma tam poprawnego rekordu, pytana o niego jest domena narzędna, w tym przypadku google.com, więc kolejne zapytanie o rekord TXT zostanie wykonane do domeny _dmarc.google.com.
W tym rekordzie 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:
W odpowiedzi otrzymamy rekord DMARC:
Opis ważnych pól, które możemy spotkać w takich rekordach:
- v= - wersja protokołu, w tej chwili musi być DMARC1
- rua= - lista adresów, na które mają przyjść raporty ze sprawdzeń, opisana w formacie mailto:<adres email>. W przykładzie mailauth-reports@google.com
- 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= - co ma się stać z wiadomocią 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
Więcej możliwych pól można znaleźc w RFC
Uwaga!
Ustawienia DMARC są jedynie wskazówką dla serwera pocztowego odbierającego wiadomość, nie są obligatoryjne. Jednak większość serwerów weźmie je pod uwagę.
Uwaga!
Mechanizm DMARC powinien być implementowany stopniowo, z początkowymi ustawieniami reakcji na none, ale z włączonymi raportami. Na bazie analizy otrzymywanych raportów z sytuacji gdzie sprawdzenie się nie powiodło należy poprawiać konfiguracje usług wysyłających maile. Nagłe włączenie DMARC z ustawieniem quarantine lub reject może spowodować, iż ważne procesy biznesowe, o których nie pomyśleliśmy, np. newsletter u zewnętrznego dostawcy, mogą przestać działać.
Ustawienia dla domen niesłużących do wysyłki poczty
Warto zaznaczyć, iż choćby jeżeli 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 iż 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 iż 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.
