Как да разберем дали един имейл е фалшив

Атаките с фалшиви имейли не са от вчера. Но те са в пъти повече и тенденцията е да се увеличават. Затова е важно да знаете как да разберете, че един мейл е фалшив. Или иначе казано, че не сте станали жертва на spoofing.

Повече по темата със spoofing: Sextorsion атака от .bg домейни: как да разпознаете фалшивото писмо

Дефиницията за mail spoofing е изготвяне и изпращане на имейл от името на нищо неподозиращ потребител. Spoofing-ът се окачествява с това, че за изпращането на мейла не се хаква поща или сървър, а се използват механизми и трикове с които е възможно да се „измами“ системата.

При успешен spoof-нат e-mail, ефекта на spam или phishing атака е, че прави писмата да изглеждат още по–убедителни и „истински“. Често целта на хората, подготвящи атака чрез spoof-нати  мейли, е да се представят за част  от добре известна компания (например на банка или институция), служител на фирмата в която работи жертвата (CEO до счетоводство) или дори от пощата на самта жертва… тоест сам е писал до себе си. Този подход се оказва работещ при споделени пощенски кутии (mail aliases), където няколко служителя получават и четат поща за [email protected].

Трябва да правим разлика от атака използваща spoof методи и email compromise. Да, крайният резултат може да е приблизително еднакъв, но докато spoof разчита на пропуски в настройките за електронна поща (DNS, e-mail сървър)  и защита (antispam / mail gateways), email compromise представлява поемане на контрол върху чужд e-mail акаунт. Най–често e-mail compromise атаките успяват заради слаби/рециклирани пароли и липса на многофакторна автентикация.

Но да се върнем на темата за header-ите. Често получаваме запитвания от фирми и частни лица, които са станали жертва на spoof е-mail атаки. Дори когато знаем къде и как да видим header-ите на писмото в e-mail клиента, може да се окаже, че задачата да се ориентираме какво да проверим е непосилна.

В тази статия ще направим анализ на реални писма с анонимизирани хедъри и ще направим обобщение на това какъв е пътят на всяко писмо.

От MUA до MTA и обратно до MUA

В основата си електронната поща се придвижват чрез Mail User Agent (MUA) и Mail Transfer Agent (MTA). Най–общо казано MUA е програмата с която си четете и изпращате мейлите, примерно Thunderbird, Outlook, Android Gmail app и дори web страници, като abv.bg, gmail.com и т.н. MTA са сървърните програми и устройства, които се грижат да придвижат мейлите от изпращач „А“ до получател „Б“.

Традиционно протокола по който се изпращат писма от mail client (MUA) към mail server (МТА) Simple Mail Transfer Protocol (SMTP – port 25/TCP). Комуникацията между mail сървърите MTA <> MTA отново е по този протокол. От другата страна писмото се чете / изтегля от mail клиент (MUA) чрез протоколи, като Post Office Protocol (POP3) или Internet Message Access Protocol (IMAP). Традиционните mail клиенти (MUA), като Thunderbird трябва да разбират от всички тези протоколи за да четат и изпращат електронна поща.

В крайна сметка комуникацията е следната:

User A <> MUA <> MTA <> MTA1 <> MTA..N<> MUA <>User B

TLS криптиране

Когато е бил изпратен първият e-mail през 1971 г, едва ли е имало нужда от допълнителни механизми, като верификация и криптиране.

Като всяка нещо в интернет, при изготвяне на оригиналният вариант на SMTP протокола, сигурността не е била фактор. Задачата е била ясна – сървъра да приеме всяко писмо, независимо от изпращача, да го препрати до всеки друг сървър, който би могъл да достави до получателя оказан в „To:“ полето. За известно време това работело, понеже малкото хора и машини в интернет си имали доверие.

С комерсиализирането на интернет и нарастващото значение на e-mail услугите за бизнеса, ситуацията бързо ескалирала в кошмарен хаос.

В наши дни е възможно да се изпрати писмо без криптирана връзка и без автентикация, но вероятността да му се лепне етикет SPAM или Junk е доста голяма, тоест съществуват редица anti-spam решения, които защитават съвременната e-mail комуникация.

Модерните e-mail технологии криптират комуникацията между MUA<>MTA и MTA<>МТА по време на обмяната на информация (in-flight) чрез TLS.

Тоест писмата са предпазени от man-in-the-middle атаки и ако някой успее да прихване трафика, няма да му е от голяма полза. Но какво се случва, ако писмото трябва да бъде препратено през три MTAs преди да достигне крайният си получател?

Всеки сървър по пътят би могъл да промени съдържанието на писмото и да го предаде нататък по веригата, тоест липсва криптиране от край до край (end-to-end), нещо с което съвременните instant messangers (Telegram, Viber, WhatsUp и други) могат да се похвалят.

За end-to-end криптиране в e-mail услугите, могат да се използват свободни технологии за асиметрично криптиране пример PGP, както и комерсиални такива, примерно ESET Endpoint Encryption.

SPF – рамка от политики за изпращане

Нека се върнем на темата на spoofing, Вие като собственик на domain може да създадете TXT DNS запис оказващ кои са сървърите на които им е позволено да изпращат писма от ваше име.

Например SPF записа за centio.bg казва, че мейли с @centio.bg могат да бъдат изпращани само от сървърите на Microsoft (Office365), както и от няколко платформи за маркетинг услуги (newsletters). Всеки друг източник ще бъде „посрещнат“ с HardFail , тоест писмото не е оторизирано и трябва да бъде отхвърлено.

SPF не е универсално решение на проблема със spoof-a и не трябва напълно да се има доверие на header стойностите, понеже те могат да бъдат променяни. SPF е полезен на мейл сървърите участващи в комуникацията и то в реално време, което го прави чудесен инструмент за справяне със SPAM и Spoofing.

DKIM – идентифициране на мейли чрез криптография

Подобно на SPF, DKIM се настройва чрез TXT запис за домейна на изпращача. За разлика от SPF, DKIM е техника за автентикиране и валидация съдържанието на самото съобщение.

Генерират се двойка публичен/частен ключ и публичният се записва в TXT записа. Пощенските сървъри отговарящи за изпращане на писма за съответния домейн използват частният ключ за да подпишат (криптографски хеш) писмото – тялото (body) и заглаваната част (headers).

Получателя на писмото от своя страна може да декодира подписа използвайки публичният ключ съхранен в TXT записа на изпращача, така може да се провери интегритета на писмото.

Тоест дали някой не е променил банковата сметка в тялото или не е подменил/добавил хедъри… а защо не и двете!

Това е изключително ценно, когато е необходимо да се прецени дали писмото е легитимно и хедърите не са били променяни:

DMARC – автентикация, доклади и съответствия

DMARC разширява и автоматизира възможностите предоставени от SPF и DKIM, свеждайки всичко до прост набор от инструкции за пощенски сървъри. Тоест когато пощенски сървър получи писмо от даден домейн, той проверява DMARC политиката за този домейн и според нея предприема съответните действия. Тоест може да пропусне, карантинира или да отхвърли писмо базирано на резултатите от SPF и DKIM проверките.

Анализиране на email

Как да видим заглавната част на дадено писмо, много зависи от мейл клиента (MUA), но ето няколко примера.

Thunderbird:

OWA (Office365):

Gmail:

Когато „четем“ хедърите на получено писмо е важно да знаем, че всеки пощенски сървър и устройство по пътя на мейла от изпращача до получателя, може и добавя свои хедъри върху добавени до сега. Тоест когато четем отгоре надолу, ще видим първо хедърите добавени от последното MTA и последни ще са тези добавени от MUA на изпращача:

Също така в дадени ситуации се разкриват и интересни данни, като версии на приложения, операционни системи и частни адреси:

Могат да бъдат идентифицирани и през какви проверки за antivirus / antispam е преминало дадено писмо:

Всичко до тук е доста полезно, но може да се окаже доста трудоемко да се прочетат стотици редове, а може и да допуснем грешка. Има инструменти, които значително могат да улеснят проверката на хедърите. Препоръчваме https://mxtoolbox.com/ и https://mha.azurewebsites.net/

Колко можем да се доверим на информацията от хедърите?

Хедърите могат да бъдат подменяни и фалшифицирани от злонамерени сървъри и податели. При липса на DKIM, хедърите най–отгоре, последните, добавени от вашия мейл сървър, са тези, на които може да се доверите. Всички останали могат да бъдат приети с известна доза съмнение.

Всичко това достатъчно ли е да идентифицираме подателя?

Рядко се случва така, че заглавната част (headers) да разкрият еднозначно подателя. Обикновено се стига до Internet Service Provider-a и доставчика на пощенската кутия, като за по–точно идентифициране е необходима намеса на съдебна и изпълнителна власт.

По данни, като времеви отпечатък (timestamp), уникални идентификатори и IP адреси, доставчика на пощенската услуга (примерно Microsoft Office365) би могъл да се свърже с ISP-то собственик на IP адреса на подателя. Оттам може да се окаже, че зад това IP стои безжична мрежа със свободен достъп в кафене или пък е заделено за домашна услуга на нищо неподозираща възрастна двойка… В практиката ни често се случва, че злонамерените дейности се извършват от безопасно разстояние и никой престъпник не иска да с**е където яде.

Ако все пак искате да направите тест, дали вашият domain и пощенски сървър е добре конфигуриран, може да го направите на: https://mxtoolbox.com/

Ако искате да проверите защитите на Вашата пощенска услуга, може да се опитате да изпратите spoof-нат e-mail оттук: https://emkei.cz/

Длъжни сме да кажем, че разгледаните механизми за защита в текущата статия покриват базови атаки и не изискват никаква инвестиция от ваша страна.

Съществуват методи за атака и зловреден код, който би могъл да преодолее SPF, DKIM и други вградени в мейл услугата механизми. За да преминете на следващо ниво на сигурност при използване на мейл услуга е необходимо да положите допълнителни слоеве за защита, като Sophos Sandstorm:

И ESET Dynamic Threat Defense: