Oszukańcze e-maile: dlaczego w ogóle są możliwe

Czasami wiadomość e-mail wyłudzającą informacje można łatwo zdemaskować tylko poprzez sprawdzenie pola „Od”. Jednak nie zawsze tak jest: spreparowanie idealnej fałszywej wiadomości e-mail rzeczywiście jest możliwe. Jeśli ktoś wie, jak ją zrobić, wzięta na celownik organizacja naprawdę może znaleźć się w tarapatach. Większość ludzi bez namysłu kliknie złośliwy link lub plik, który trafił do nich w e-mailu wysłanym rzekomo przez szefa lub najlepszego klienta — i trudno ich za to winić, zwłaszcza jeśli w żaden sposób nie można rozpoznać, że e-mail został sfałszowany.

Ale dlaczego możliwe jest przygotowanie doskonałego e-maila? Andrew Konstantinow opowiedział o autoryzacji poczty e-mail dla testerów penetracyjnych podczas 36 Chaos Communication Congress i opisał skuteczne metody ochrony poczty e-mail przed oszustwami.

Problem nr 1. Poczta musi być w ruchu

We współczesnym świecie poczta e-mail jest podstawową metodą komunikacji, a każda organizacja opiera na niej swoją codzienną działalność. Gdy wszystko działa płynnie, nie myślimy o technologii, ale jeśli nagle e-maile zaczną ginąć, sytuacja nie przejdzie bez echa. W związku z tym niezawodność jest na ogół najwyższym priorytetem każdego administratora serwera poczty e-mail. Wiadomości muszą wychodzić i przychodzić, bez względu na wszystko.

W efekcie serwer poczty e-mail w każdej organizacji musi być jak najbardziej kompatybilny ze wszystkim innym na świecie. I na tym polega problem: standardy poczty e-mail są bardzo przestarzałe.

Problem nr 2. Protokół poczty e-mail bez uwierzytelniania

Najczęściej używanym protokołem w komunikacji e-mail zarówno między klientem a serwerem, jak i między serwerami, jest protokół SMTP. Protokół ten został użyty po raz pierwszy w 1982 r., a ostatnią aktualizację otrzymał w 2008 r. – ponad dziesięć lat temu. I podobnie jak wiele innych starożytnych standardów, SMTP jest koszmarem dla kwestii bezpieczeństwa.

Najpierw powiedzmy sobie, z czego składa się typowa wiadomość e-mail:

• Koperta SMTP. Ta część jest używana do komunikacji między serwerami i nigdy nie jest wyświetlana w klientach poczty e-mail. Określa adresy nadawcy i adresata.
• Nagłówek. Tę część wyświetlają klienty poczty e-mail. Znajdziesz tam pola „Od”, „Do”, „Data” i „Temat”, które widzisz w każdej wiadomości e-mail.
• Treść wiadomości. Znajduje się tu treść wiadomości e-mail i inne treści.

Elementy wiadomości e-mail. Źródło

Największy problem stanowi fakt, że standard ten nie umożliwia uwierzytelniania. Odpowiedzialność za pole adresu nadawcy — zarówno w kopercie SMTP, jak i w nagłówku — spoczywa na serwerze nadawcy. Co gorsza, adres nadawcy w kopercie SMTP nie musi odpowiadać adresowi w nagłówku (który widzi użytkownik).

Ponadto chociaż standard określa jeden nagłówek dla wiadomości e-mail, SMTP faktycznie nie stosuje ograniczenia. Jeśli wiadomość zawiera więcej niż jeden nagłówek, o tym, który z nich ma być wyświetlany użytkownikowi, decyduje klient poczty e-mail.

Nie trzeba być profesjonalnym hakerem, aby dostrzec tu potencjał do nadużyć.

Problem nr 3. Fałszywe odebrane, fałszywe wysłane — muszę oglądać je oba

Sprawę jeszcze bardziej komplikuje fakt, że każda komunikacja za pośrednictwem poczty e-mail obejmuje dwie strony, więc problem braku uwierzytelniania jest w rzeczywistości źródłem dwóch innych kwestii.

Z jednej strony chcesz mieć pewność, że otrzymana wiadomość e-mail została faktycznie wysłana ze wskazanego adresu. Z drugiej strony chcesz uniemożliwić innym osobom wysyłanie wiadomości e-mail w Twoim imieniu. Niestety standard ten nie pomaga w żadnym z tych przypadków.

Nic dziwnego, że skoro protokół SMTP był tak często nadużywany, ludzie zaczęli opracowywać nowe technologie, aby wyeliminować wspomniane wyżej błędy.

Próba naprawienia błędu nr 1. Sender Policy Framework (SPF)

Sender Policy Framework to projekt, którego idea jest dość prosta: serwer odbiorczy powinien mieć możliwość sprawdzenia, czy adres serwera, który faktycznie wysłał wiadomość e-mail, odpowiada adresowi oryginalnego serwera poczty e-mail skojarzonego z domeną.

Niestety łatwiej to powiedzieć niż zrobić. Standard SMTP nie umożliwia takiego sprawdzania, więc konieczne byłoby dodanie jakiekolwiek metody uwierzytelniania. Aby taka technologia stała się „proponowanym standardem”, musieliśmy czekać dekadę. Obecnie tylko około 55% z 1 miliona najlepszych serwerów korzysta z SPF, a większość z nich stosuje dość luźne zasady.

Mechanizm SPF boryka się z wieloma innymi problemami, takimi jak chaotyczna architektura, która m.in. ułatwia niewłaściwą konfigurację i zapewnia sposoby obejścia go przy użyciu innych serwerów hostowanych pod tym samym adresem. Ale największą wadą SPF jest to, że sprawdza tylko adres wskazany w kopercie SMTP, całkowicie ignorując pole „Od” w nagłówku — czyli to, które użytkownik faktycznie widzi.

Podsumowanie:

• SPF pomaga sprawdzić, czy wiadomość e-mail pochodzi z oryginalnego serwera.
• Adres widoczny dla użytkowników nadal może zostać sfałszowany.

Próba naprawienia błędu nr 2. DomainKeys Identified Mail (DKIM)

DomainKeys Identified Mail to inne podejście do problemu. Standard ten podpisuje kryptograficznie nagłówek wiadomości i część treści wiadomości przy użyciu klucza prywatnego, którego podpis można zweryfikować przy użyciu klucza publicznego publikowanego w systemie nazw domen.

Warto jednak wspomnieć, że DKIM nie szyfruje całej wiadomości. Zamiast tego dołącza do niego kryptograficznie podpisane uzupełnienie, co jest pewnym problemem. Część kryptograficzna jest trudna do zmodyfikowania, ale całkowite usunięcie podpisu i spreparowanie fałszywej wiadomości jest łatwe — i jest to nie do wykrycia.

Standard DKIM jest trudny do zaimplementowania, ponieważ obejmuje wydawanie i zarządzanie kluczami kryptograficznymi. Ponadto nieprawidłowo skonfigurowany DKIM może umożliwi osobie atakującej zachowanie oryginalnego podpisu DKIM w wiadomości, jednocześnie całkowicie zmieniając jej nagłówek i treść.

Podsumowanie:

• DKIM pozwala cyfrowo podpisywać wiadomości, dzięki czemu serwer odbiorczy ma pewność, że wiadomość naprawdę pochodzi od Ciebie.
• Jest on trudny w implementacji, ponieważ obejmuje zarządzanie kluczami kryptograficznymi.
• Podczas preparowania wiadomości e-mail w Twoim imieniu fałszerze mogą usunąć podpis.
• Niektóre błędy w konfiguracji mogą umożliwiać tworzenie fałszywych wiadomości zawierających oryginalne podpisy DKIM.

Próba naprawienia błędu nr 3. Domain-based Message Authentication, Reporting and Conformance (DMARC)

Pomimo dość długiej nazwy, oparty na domenie protokół Domain-based Message Authentication, Reporting and Conformance jest w rzeczywistości łatwiejszy do zrozumienia niż SPF czy DKIM. Jest on ich rozszerzeniem i naprawia ich najbardziej rażące błędy.

Po pierwsze, DMARC pomaga administratorowi domeny określić, którego mechanizmu ochrony — SPF, DKIM czy obu — używa serwer, co naprawia mechanizm DKIM. Po drugie, oprócz sprawdzania adresu nadawcy w kopercie SMTP umożliwia sprawdzenie adresu określonego w polu nagłówka „Od” (tego, który jest faktycznie widoczny dla użytkownika), naprawiając w ten sposób SPF.

Niestety protokół DMARC jest stosunkowo nowy i nie jest jeszcze prawowitym standardem (RFC 7489 określa go nie jako standard, ani nawet jako proponowany standard, ale wyłącznie jako „informacyjny”) i nie jest tak szeroko stosowany, jak powinien być. Jak wynika z tego badania obejmującego 20 000 domen, tylko 20% w ogóle przyjęło DMARC do 2019 roku, a tylko 8,4% stosowało surowe zasady.

Niestety, stosowanie DMARC nie jest jeszcze powszechne, a w wielu przypadkach towarzyszy mu brak zasad. Źródło

Podsumowanie:

• Rozwiązuje najważniejsze kwestie związane z protokołem SPF i DKIM.
• Nie został jeszcze powszechnie przyjęty, a zatem nie jest tak skuteczny, jak mógłby być.

Jak zapewnić sobie bezpieczeństwo przed fałszowaniem wiadomości e-mail

Podsumowując: fałszowanie wiadomości e-mail nadal jest możliwe, ponieważ protokół SMTP nie został zaprojektowany z myślą o zabezpieczeniach, dzięki czemu osoba atakująca może wstawić w fałszywej wiadomości e-mail adres dowolnego nadawcy. W ciągu ostatnich kilku dekad pojawiły się pewne mechanizmy ochrony – mianowicie SPF, DKIM i DMARC. Aby jednak mechanizmy te były skuteczne, muszą być używane — i prawidłowo wdrażane — przez jak największą liczbę serwerów poczty e-mail. W idealnym przypadku powinny one zostać zastosowane na każdym serwerze poczty w internecie.

Ponadto należy wziąć pod uwagę, że niektóre serwery przekazujące pocztę mogą zacząć dodawać coś do wiadomości z powodu błędnej konfiguracji, co automatycznie spowoduje niepowodzenie w sprawdzaniu DKIM. Ponadto chociaż technologie te mogą pomóc uporać się z masowymi zagrożeniami, aby chronić firmę przed wyrafinowanymi atakami e-mailowymi, nadal należy korzystać z dodatkowych rozwiązań ochronnych zarówno na stacjach roboczych, jak i na serwerze pocztowym.

Oto kilka zaleceń dotyczących ochrony poczty e-mail:

• Zastosuj co najmniej protokół SPF. Upewnij się, że jest poprawnie skonfigurowany. Pamiętaj, że sprytny atakujący może ominąć SPF (więcej szczegółów znajdziesz w tym wystąpieniu).
• Zastosuj DKIM, aby zwiększyć ochronę. Może to być nieco trudniejsze, ale warto się nad tym zastanowić. Upewnij się, że jest prawidłowo skonfigurowany (kilka wskazówek na temat tego, czego szukają atakujący).
• Jeśli możesz, zastosuj DMARC, ponieważ eliminuje on większość możliwych do wykorzystania wad protokołów SPF i DKIM.
• Sprawdź konfigurację również pod kątem przychodzących wiadomości e-mail.
• Użyj rozwiązań zabezpieczeń, które obsługują nowoczesne mechanizmy uwierzytelniania. W tym celu możesz na przykład użyć Kaspersky Security for Mail Servers lub Kaspersky Security dla usługi Microsoft Office 365.