Wysłany do mnie e-mail jest adresowany na MAIL@MAIL.COM. Jak to się robi?

Niedawno otrzymałem wiadomość e-mail zawierającą oszustwo i na chichoty otworzyłem ją, aby ją przeczytać. Bardzo prosty i nie wymagający dużego wysiłku.

Zauważyłem coś dziwnego; ten adres e-mail nie został do mnie skierowany. Na początku podejrzewałem CC lub BCC, ale nigdzie nie ma mojego adresu na poczcie. Podałem zdjęcie poniżej. Jak to się robi?

Internetowa wiadomość e-mail składa się z dwóch części. Możemy nazywać je kopertą i wiadomością ładunkową lub po prostu wiadomością .

Koperta zawiera dane routingu: przede wszystkim jest to adres nadawcy i co najmniej jeden adres odbiorcy.

Wiadomość ma treść wiadomości: temat, treść wiadomości, załączniki i tak dalej. Zawiera także pewne informacje techniczne, takie jak Received:nagłówki trace ( ), dane DKIM i tak dalej; jak również wyświetlane nadawca i odbiorca adresy (co widać w From, Toi Ccpola w kliencie poczty).

Oto sedno sprawy: nie muszą się zgadzać!

Serwer pocztowy sprawdzi dane koperty, aby ustalić sposób wysłania wiadomości. Z drugiej strony, z nielicznymi wyjątkami, sama wiadomość będzie traktowana jak dane. W szczególności dobrze działający serwer pocztowy nie patrzy na pola To:i Cc:samej wiadomości w celu ustalenia listy adresatów, ani nie patrzy na From:pole w celu ustalenia adresu nadawcy.

Podczas tworzenia i wysyłania wiadomości e-mail klient poczty e-mail bierze to, co wpisałeś w pola Do, DW i UDW, i przekształca to w informacje o routingu kopert. Odbywa się to głównie poprzez usunięcie wszelkich pełnych nazwisk (pozostawiając tylko adresy e-mail), ale może również obejmować takie zmiany, jak przepisywanie adresów, rozwijanie aliasów itp. Rezultatem jest lista adresów e-mail, które są przekazywane do serwera pocztowego, z którym rozmawia klient poczty, jako lista adresatów. Listy Do i DW są przechowywane w wiadomości e-mail, ale UDW nie jest przekazywane do serwera, co czyni go niewidocznym dla odbiorców wiadomości. Adres nadawcy działa bardzo podobnie.

Gdy wiadomość dotrze do miejsca docelowego, dane koperty są wyrzucane lub przechowywane w szczegółowych nagłówkach wiadomości. To jeden z powodów, dla których Spittin 'IT poprosił o pełne nagłówki wiadomości w komentarzu do twojego pytania.

Ponadto dzięki internetowej poczcie e-mail można rozmawiać bezpośrednio z serwerem pocztowym, a tym samym wstrzykiwać wiadomość, która ma niezgodność między danymi koperty a danymi wiadomości, których nie zrobiłby normalny, dobrze działający klient poczty e-mail pozwól ci komponować. Ponadto serwery pocztowe sprawdzają w różnym stopniu adresy nadawcy podane w danych koperty; niektórzy ledwo to sprawdzają, upewniając się, że jest to poprawny pod względem składni adres e-mail. Nagłówek From danych wiadomości podlega jeszcze mniejszej kontroli.

Ponieważ odbierający klient e-mail wyświetla to, co jest w nagłówkach Od, Do i DW, a nie dane adresowe z koperty, możliwe jest umieszczenie tam wszystkiego, co chcesz, a odbierający klient e-mail nie będzie miał innego wyjścia, jak tylko zaufać, że jest dość dokładne. W przypadku legalnej poczty zwykle jest ona wystarczająco dokładna; w przypadku spamu prawie nigdy tak nie jest.

W świecie rzeczowych, obiektów fizycznych zamieszkałych przez nas, zwykłych ludzi, kopercie nadawca i koperta odbiorca odpowiada adresowi adres zwrotny i biorcy, odpowiednio, że piszesz na zewnętrznej kopercie; a nagłówki From:i To:/ i Cc:odpowiadają dowolnemu adresowi podanemu odpowiednio jako adres własny i adresata w liście umieszczonym w kopercie.

tl; dr na dole.

Protokół SMTP nie ma pojęcia odbiorców CC lub BCC; jest to konwencja obsługiwana przez klientów pocztowych. Serwer SMTP zazwyczaj tylko dba o informacje o routingu i dane. Jest to ważne rozróżnienie, ponieważ bez tej możliwości BCC nie mógłby istnieć. Jako prawidłową komunikację BCC należy wziąć pod uwagę następujący zapis klienta:

HELO from-mail-server.com
MAIL FROM:<john.smith@from-mail-server.com>
RCPT TO:<anonymous@another-mail-server.com>
DATA
From: "John Smith" <john.smith@from-mail-server.com>
To: "Jane Doe" <jane.doe@to-mail-server.com>
BCC: "Anonymous" <anonymous@another-mail-server.com>
Subject: Important Meeting Notice
Date: Monday, May 15, 2017 12:20 PM

This is an important meeting notice. We'll meet tomorrow.

.

Teraz w tym przypadku Anonimowi wysłano wiadomość o tym spotkaniu. Jednak ta wersja poczty nie została skierowana do Jane Doe; nic nie wie o powiadomieniu Anonimowego. Natomiast Jane Doe zostanie wysłana wiadomość z innym ciałem i nagłówkiem:

HELO from-mail-server.com
MAIL FROM:<john.smith@from-mail-server.com>
RCPT TO:<jane.doe@to-mail-server.com>
DATA
From: "John Smith" <john.smith@from-mail-server.com>
To: "Jane Doe" <jane.doe@to-mail-server.com>
Subject: Important Meeting Notice
Date: Monday, May 15, 2017 12:20 PM

This is an important meeting notice. We'll meet tomorrow.

.

Ponieważ Anonim był w BCC, wiadomość wysłana do Jane Doe nie zawierała listy odbiorców BCC. Ze względu na konwencję BCC koperta wiadomości e-mail może nie obejmować odbiorców, którzy faktycznie otrzymali wiadomość, a także adresatów, którzy nie pojawiają się w nagłówkach wiadomości.

Jak wspomniała @JonasWielicki , co również chciałem załączyć, to MUA (Mail User Agent) zazwyczaj odpowiada za wysyłanie wielu e-maili wymaganych do wdrożenia BCC. Serwery e-mail nie wiedzą nic o BCC, dlatego MUA musi wdrożyć BCC, wysyłając wiele wiadomości e-mail z różnymi trasami e-mail określonymi w nagłówkach kopert. Z tego powodu BCC wysyłają zwykle więcej czasu niż zwykłe wiadomości e-mail, ponieważ różne treści wiadomości muszą być konstruowane i wysyłane indywidualnie.

Pomaga to również w przypadku niektórych zasad zgodności z pocztą e-mail. Na przykład serwer pocztowy może mieć skonfigurowane reguły do ​​automatycznego BCC zarchiwizowanego serwera e-mail (wszystkie wysyłane do niego wiadomości e-mail są również archiwizowane), w którym to przypadku serwer pocztowy może nawet nie być prawdziwym odbiorcą.

HELO from-mail-server.com
MAIL FROM:<john.smith@from-mail-server.com>
RCPT TO:<mail-archive@archive-server.com>
DATA
From: "John Smith" <john.smith@from-mail-server.com>
To: "Jane Doe" <jane.doe@to-mail-server.com>
BCC: "Anonymous" <anonymous@another-mail-server.com>
Subject: Important Meeting Notice
Date: Monday, May 15, 2017 12:20 PM

This is an important meeting notice. We'll meet tomorrow.

.

Tutaj odbiorca to inna strona, która jest całkowicie niejawna żadnemu z odbiorców, a nawet nadawcy. Jest to cecha protokołu, zwykle używana do przekazywania lub archiwizowania wiadomości.

Ta wiadomość spamowa wykorzystała to zachowanie. Jest to standardowa luka, która technicznie powinna działać z każdym zgodnym serwerem poczty. Oczywiście wiele zaktualizowanych serwerów używa „rozszerzeń”, takich jak DKIM, aby zweryfikować, czy taki e-mail jest autentyczny, ale wciąż istnieje wiele starych serwerów poczty, które nie dbają o to, po prostu dlatego, że kusi nie naprawiać rzeczy, które nie są zepsute.

Zwróć też uwagę, jak podałem nagłówek Date. Może to być dowolna (ale dobrze sformatowana) wartość; wielu klientów chętnie wyświetli dowolny legalny zakres dat od odległej przeszłości po daleką przyszłość. Wiele lat temu osobiście wysłałem do siebie wiadomość e-mail, która pozostanie na górze mojej skrzynki pocztowej długo po mojej oczekiwanej długości życia, a także wiadomość e-mail, która poprzedza moje konto e-mail i moje urodzenie.

tl; dr

Podsumowując, nadawca sfałszował wiadomość e-mail, serwer poczty przychodzącej ją zaakceptował / przekazał, serwer poczty e-mail zaakceptował ją i zapisał w skrzynce odbiorczej, a klient wiernie wyświetlił dane znajdujące się w skrzynce odbiorczej, wszystko bez obchodzenia jakiekolwiek bezpieczeństwo. W tej perspektywie bezpieczeństwo „wysyłania” jest często znacznie mniej ograniczone niż „odbieranie”, ponieważ POP3 prawie zawsze wymaga nazwy użytkownika i hasła, aby uzyskać dostęp do skrzynki pocztowej (teoretycznie można to obejść, ale nie znam żadnego uzasadnionego usługi pocztowe, które to robią).

SMTP i poczta e-mail to bardzo stare usługi internetowe z czasów, gdy bezpieczeństwo i uwierzytelnianie były traktowane o wiele mniej poważnie (DNS to kolejny przykład). Projekt protokołu nie stara się zweryfikować autentyczności adresu nadawcy i sprawdza adres odbiorcy tylko w zakresie, w jakim zapewnia on, że poczta może być dostarczona.

E-mail jest przesyłany za pośrednictwem protokołu SMTP. Protokół SMTP jest stosunkowo głupi; zapewnia możliwość przesyłania zwykłego tekstu na adres e-mail i niewiele więcej. Struktura tego tekstu jawnego jest zdefiniowana w RFC 5322 . Ogólny pomysł jest taki, że tekst wiadomości e-mail ma metadane zwane nagłówkiem i rzeczywistą treść wiadomości. Ten nagłówek e-maila jest generowany przez nadawcę (nie można mu ufać) i zawiera pola takie jak „do:”, „from:”, „subject:” itp.

Protokół SMTP nie sprawdza (i nie powinien) sprawdzać, czy nagłówki wiadomości e-mail pasują do dowolnej z niewielu rzeczy zdefiniowanych w protokole SMTP, którymi są zasadniczo twój adres e-mail i adres e-mail nadawcy, który nigdy nie jest w żaden sposób sprawdzany.

Prawie wszystko w wiadomości e-mail może być fałszywe.

Jedyną rzeczą godną zaufania dzisiaj w przypadku treści wiadomości e-mail są podpisy DKIM, które dowodzą, że wiadomość e-mail została przetworzona za pośrednictwem serwera poczty elektronicznej sankcjonowanego przez rejestrującego domenę. Gdy zagłębię się głębiej, przekonasz się, że ten fałszywy e-mail nie ma podpisu DKIM.

Adres Tow nagłówku e-maila służy do celów informacyjnych i jest wyświetlany przez klienta e-mail. Rzeczywisty adres odbiorcy jest podany RCPT TOw SMTP. To samo, jeśli piszesz list, wkładasz do koperty, piszesz adres 1 na kopercie. Następnie idź do kuriera, podaj kolejny Adres-2. Kurier wkłada kopertę w większą kopertę o adresie 2, a przesyłka trafi tam. Twój sekretarz (oprogramowanie klienta poczty e-mail) umieszcza zewnętrzną kopertę w koszu i pokazuje ci wewnętrzną kopertę z adresem 1. Możesz to zobaczyć w widoku RAW wiadomości e-mail.

Jest to nieco inny wygląd, oparty na badaniu nagłówków. Inne odpowiedzi lepiej niż ja potrafią obsłużyć szczegóły SMTP.

Jeśli można uzyskać pełne nagłówki wiadomości, a następnie wyszukiwać je na adres, to może go znaleźć w polu o nazwie Envelope-to, Delivered-tolub X-Apparently-to. Pierwszy jest używany przez mojego dostawcę poczty, drugi przez Gmaila; Widziałem też trzecią. Są to różne pola, ale dla naszych celów zwykle oznaczają to samo: skrzynkę pocztową, do której faktycznie należy dostarczyć wiadomość. Przetestowałem, wysyłając z programu Outlook (wersja komputerowa) z odbiorcą BCCed.

Mój dostawca poczty używa również Delivered-Topola, ale dla nazwy skrzynki pocztowej na swoim serwerze. To nie jest mój adres e-mail, choć wygląda jak jeden (pomyśl ChrisH-$ACCOUNTNAME@$SERVER.mail.com).

Z drugiej strony program Outlook (w połączeniu z serwerem wymiany) nie zawiera w nagłówkach pojedynczego pola z adresem e-mail odbiorcy, jeśli jest wymieniony jako BCC.