Підробка листів. Як захищатися



Привіт habr! У даній замітці вирішив зачепити тему захисту від фішингових листів (Email spoofing, Forged email). Мова піде про листи, в яких так чи інакше підробляється інформація про відправників. Одержувач бачить лист, відправлений нібито довіреною особою, але насправді, лист відправлено зловмисником.

Останнім часом все частіше чуємо про проблему підроблених листів від наших замовників, так і просто знайомих. Ця проблема не тільки актуальна, але, схоже, набирає обертів. Ось реальна історія від знайомого, який був близький до того, щоб втратити суму з чотирма нулями в доларовому еквіваленті. У компанії велася переписка англійською мовою з зарубіжною компанією про придбання дорогого спеціалізованого обладнання. Спершу нюанси виникли на стороні нашого знайомого – потрібно змінити реквізити рахунка відправника (компанію-покупця). Через деякий час, після успішного узгодження нових реквізитів, постачальник обладнання також повідомив про необхідність зміни реквізитів рахунку одержувача (компанію-продавця). Ось тільки листи про зміну даних одержувача йшли вже від зловмисників, вдало подменявших адресу відправника. На тлі деякої загальної метушні, посилюється ще і тим, що обидві сторони не були носіями мови листування, помітити підміну листів було практично неможливо. Не можна не відзначити і той факт, що зловмисники старанно копіювали стилі, шрифти, підпис і фотографії в листах. Як саме витекла інформація про угоду – швидше за все була скомпрометована поштова переписка. За тиждень до фінального узгодження угоди, про яку йдеться у цій статті, на пошту знайомого прийшов лист з трояном, у вигляді рахунку-фактури *.exe архіві. На момент приходу листа антивірус не відловив зловредів, і той, деякий час встиг «попрацювати» на комп'ютері, і навіть підтягнути на підмогу пару своїх побратимів.



Через кілька днів сигнатури антивіруса оновилися і він з побратимами був видалений, але до того моменту в переписку вже вклинилися, відправника підробили, гроші пішли на чужий рахунок.
В даному прикладі підміна адреси відправника була зроблена вкрай нехитро. Реальні адреси ми не опублікуємо, але наведемо аналогічний приклад.

Правильний адреса відправника: best@bestofall.com
Підроблений адреса відправника: bestbestofall.com@spoofed.ru.

Поштова обліковий запис зловмисника включала ім'я «best@bestofall» та прізвище ".com". Частина листування знайомий вів з мобільного пристрою, поштовий клієнт якого відображав в полі відправника лише ім'я та прізвище відправника. А так роблять всі мобільні поштові клієнти. Тому, вхідний лист в цьому поштовому клієнті бачилося як від best@bestofall «пробіл» .com. Що дуже схоже на оригінал. Нижче лист від зловмисника і під ним легітимне лист в інтерфейсі Яндекс.Пошти:




В Outlook лист від зловмисника теж виглядало досить схоже на оригінал, якщо уважно не вдивлятися, то теж можна і не помітити підробку.

Все спливло, коли подзвонив постачальник і запитав: «Веэр з травень мані?». На щастя знайомого, з-за подвійної зміни реквізитів (одержувача і відправника) щодо початкового підписаної угоди $$$$$ не були остаточно зараховані на рахунок зловмисників, а зависли на транзитному рахунку банку-одержувача, і їх вдалося повернути.

Компанії по всьому світу терплять істотні збитки через Email-атак (джерело). Так з жовтня 2013 по серпень 2015 сукупний збиток від компрометаций корпоративної електронної пошти компаній по всьому світу склав 1,2 мільярда доларів США. А атаки з підробленими листами знаходяться серед найбільш поширених видів атак на корпоративні поштові системи.

Особлива увага приділяється атакам, при яких зловмисник відправляє підроблене лист від імені високопоставленого керівника компанії. У тексті листа зловмисник вимагає негайної відповіді, або якоїсь термінової реакції від співробітника або групи співробітників компанії. Наприклад, може вимагати відповісти на лист відправкою будь-якої конфіденційної інформації. Це може призвести до витоку даних. Або зловмисник може зажадати строковий банківський переклад якої-небудь великої суми. В описаних випадках співробітник відчуває тиск: високопоставлений керівник вимагає невідкладних дій. Цей факт підвищує ймовірність успіху атаки. Крім того, атаці може передувати рекогносцировка методами соціальної інженерії, щоб найбільш ефективно сформувати текст листа і найбільш точно виявити цільову групу співробітників, які отримають підроблене лист. Даний підхід також благотворно впливає на успіх атаки.

Для того, щоб розібратися з механізмом підробки адреси відправника, згадаємо структуру електронного листа, переданого по протоколу SMTP. Електронний лист складається із конверта (envelope), заголовків (headers) і тіла листа (message body). Інформація про відправника міститься в конверті. Ця інформація формується SMTP-командою mail from і справляє безпосередній вплив на процес пересилки повідомлення по мірі проходження поштових серверів Mail Transfer Agent (MTA). Однак, інформація про відправника також міститься в деяких заголовках листи, таких як «From:», «Return-Path:» можливо «Reply-To:». Заголовок «From:» не обов'язково має збігатися з тим, що написано в конверті листа і може представляти деяку «дружнє ім'я» (friendly name, friendly from). Заголовок «Return-Path:» копіює відправника з конверта. Заголовок Reply-To:" містить адресу для відповіді. Заголовки значущі для поштового клієнта (наприклад, MS Outlook), по заголовкам заповнюються відповідні поля.
Розглянемо приклад SMTP-команд для відправлення листа з підробленими заголовками «From:» і «Reply-To:». Підключаємося до поштового сервера Exchange за допомогою telnet:

telnet 10.1.2.3 25
220 Microsoft Exchange ESMTP MAIL Service ready at Wed, 26 Oct 2016 10:28:00 +0300
helo
250 Exchange Hello [192.168.100.100]
mail from: attacker@spoofed.ru
250 2.1.0 Sender OK
rcpt to: uskov@cbs.ru
250 2.1.5 Recipient OK
data
354 Start mail input; end with <CRLF>.<CRLF>
From: Ivanov Ivan <CEO@cbs.ru>
To: Boris <uskov@cbs.ru>
Reply-To: attacker@yandex.ru
Subject: Urgent!

Need your credit card information.

Ivanov Ivan Ivanovich,
CEO,
Computer Business Systems

.
250 2.6.0 Queued mail for delivery
quit
221 2.0.0 Service closing transmission channel

У даному прикладі ми відправляємо з реального адреси attacker@spoofed.ru лист, але в заголовку From:" вказуємо ім'я та адресу керівника компанії, а в заголовку «Reply-to» на адресу mail.yandex, куди неуважний співробітник відправить конфіденційну інформацію. У підсумку листа у поштовому клієнті Outlook буде виглядати наступним чином:



А якщо натиснути «Відповісти» автозаполнится адресу одержувача:



Як видно з попереднього прикладу, відправити підроблене лист не становить великої праці, якщо сервер не захищений. У гіршому випадку, значення в конверті листа mail from також може бути підмінене на легітимне. Якщо тіло листа складено акуратно і з застосуванням результатів соціальної інженерії, виявити підроблене лист стає все складніше для кінцевого користувача. Ситуація ще більш ускладнюється для користувачів мобільних пристроїв. Концепція мобільності передбачає, що всі дії виконуємо швидко, «на ходу», та ще й на невеликому екрані, не звертаючи увагу на дрібниці/невідповідності. До речі кажучи, у прикладі про угоду з зарубіжною компанією у знайомого теж не обійшлося без фактора «мобільності». Частина листування проходила з мобільного пристрою, поштовий клієнт в полі відправника відображав тільки ім'я/прізвище відправника, але приховував повна поштова адреса.
Не існує єдиного методу боротьби з подмененными листами. Захист від даного виду атак потребує комплексного і багаторівневого підходу. Спробую виділити основні підходи боротьби з підробленими листами:

  1. Фільтрація на основі репутації сервера-відправника.
  2. Фільтрація на основі перевірок записів DNS сервера відправника.
  3. Фільтрація на основі перевірок записів DNS домену відправника з конверта листа.
  4. Фільтрація на основі перевірок SPF-записів.
  5. Фільтрація на основі DKIM.
  6. Фільтрація на основі DMARC.
  7. Створення гранулярних фільтрів «вручну».
З перерахованих методів перші три є фільтрами грубого очищення, що дозволяють боротися з масовими розсилками спаму, шкідливої пошти, у тому числі з подмененным відправником. В даному випадку зловмисники використовують ефект масовості, не здійснюючи до атаки якоїсь спеціальної рекогносцировки і не намагаючись точно підібрати контент під одержувача. Наприклад, листи від імені Ощадбанку з проханням повідомити будь-яку конфіденційну інформацію (логін/пароль від особистого кабінету, номери карт, PIN-коди), що розсилаються на величезне число одержувачів. За принципом, хто-небудь та клюне.

Методи 4-6 допомагають боротися з точними підмінами відправників, тобто ситуаціями, коли в заголовках листи зловмисник вказує з точністю до знака подменяемый відправник.
До методу 7 доведеться вдаватися у випадках, як у прикладі про листування з зарубіжною компанією на початку статті, коли заголовок листа модифікується таким чином, щоб стати схожим на реального відправника. Але при цьому, заголовок в подмененном листі все ж відрізняється від заголовка реального відправника, що дозволяє обійти перевірки методами 4-6.

Розглянемо перераховані методи більш докладно.

1. Фільтрація на основі репутації сервера-відправника. Якщо система захисту корпоративної пошти забезпечує якісну базу репутацій відправників, ми можемо фільтрувати значний відсоток розповсюджувачів спаму і шкідливою кореспонденції будь-якого виду вже на етапі встановлення TCP-сесії, не заглядаючи ні в тіло, ні в конверт листа. Такий підхід істотно заощаджує ресурси системи. Як тільки відправник намагається встановити TCP-сесію на порт 25, система захисту визначає репутацію для IP-адреси відправника, і приймає рішення.
Приклад Cisco ESA. Репутаційна фільтрація.Трохи конкретики на прикладі Cisco ESA. Рішення використовує репутаційну базу Sender Base. Ми бачимо, що репутаційна фільтрація допомагає зупиняти в районі 80% шкідливих листів. Причому з багаторічного досвіду впровадження та супроводу даного рішення можу сказати, що кількість помилкових спрацьовувань репутаційної фільтрації Cisco ESA прагне до нуля.

Нижче зведення нашої організації:



У залежності від репутації відправника Cisco ESA не тільки приймає рішення відкинути лист або пропустити далі, але і визначає подальший сценарій обробки листа. Для різних значень репутації ми можемо застосовувати різні політики:


2. Фільтрація на основі перевірок записів DNS сервера відправника. Відправник поштових повідомлень повинен бути коректно зареєстрований в DNS. Для відправника повинні існувати коректні PTR запис, А-запис. Відправник повинен коректно представлятися в SMTP-команді HELO. При масові розсилки спаму і шкідливий зловмисники постійно змінюють IP-адреси розсилають серверів. Адреси змінюються щодня і навіть частіше. Реєструвати необхідні запису в DNS складно і навіть неможливо. Тому, багато розповсюджувачів спаму та шкідливих повідомлень нехтують цими вимогами, відповідно, з'являється можливість їх фільтрувати за ознаками DNS.
Приклад Cisco ESA. DNS-перевірки IP-адреси відправника.Розглянемо DNS-перевірки на прикладі Cisco ESA. При встановленні TCP-сесії виконуються наступні перевірки відправника DNS:

  1. Перевірка наявності PTR запису. PTR запис повинна бути єдиною і повертати коректне канонічне ім'я хоста відправника.
  2. Перевірка наявності А-записи для імені хоста, знайденого на першому кроці (за PTR-запису).

  3. Перевірка збігу forward DNS lookup для А-записи з попереднього кроку з IP-адресою відправника.
Якщо PTR запис не існує, або знайдена A-запис вказує на сторонній IP-адресу, з найбільшою часткою ймовірності ми приймаємо сесію від нелегітимного відправника. Для таких відправників на Cisco ESA ми можемо застосовувати обмежують політики (відкидаємо лист, відправляємо в карантин, модифікуємо заголовок, обмежуємо кількість сесій і т. д.), в залежності від поставлених вимог.

Хочу звернути увагу, на даному етапі перевірок ESA не контролює легітимність відправника, тобто не перевіряє, чи має право відправник слати листи від вказаного домену. Більш того, на даному етапі ні конверт листа, ні заголовки не проглядаються. Відпрацьовує тільки перевірка за IP-адресою. Наприклад, якщо листи від домену mycompany.ru будуть йти з «лівого» IP-адреси з коректними A — і PTR-записами DNS, наприклад, «smtp.spamer.ru», перевірка пройде успішно і лист буде пропущено для подальшої обробки. Перевірка легітимності відправників здійснюється іншими методами (див. далі SPF-записи, DKIM, DMARC).
3. Фільтрація на основі перевірок записів DNS домену відправника з конверта листа. Інформація mail from також підлягає перевірці з DNS. На прикладі Cisco ESA лист може бути відкинуто якщо:

  1. Інформація про домені відправника відсутня в конверті.
  2. Ім'я домену не дозволяється в DNS.
  3. Ім'я домену не існує в DNS.
Даний тип перевірок не особливо ефективний, відкидаються листи з завідомо неправильно сформованими конвертами.

4. Фільтрація на основі перевірок SPF-записів. SPF – Sender Policy Framework – система перевірки відправників електронних повідомлень. Перевірка методом 2 «DNS сервера відправника» говорить тільки про те, що для IP-адреси відправника існують необхідні запису в DNS (PTR — і A-записи). Однак ці перевірки не допомагають визначити, чи має право сервер відправник слати листи від вказаного домену. Варто зауважити, часто A-записи поштових серверів містять у собі ім'я домену компанії, наприклад, smtp01.mycompany.ru. Якщо цей сервер використовується для прийому пошти, то ця ж A-запис буде входити і в MX-запис. Можна припустити, що якщо лист від mycompany.ru відправлено з сервера smtp01.mycompany.ru, то це не підроблене лист, в іншому випадку, якщо лист надіслано з smtp01.anythingelse.ru лист штучно. Але насправді часто компанії відправляють електронну кореспонденцію не безпосередньо зі своїх поштових серверів, а через якісь додаткові сервери MTA, наприклад, через сервера своїх провайдерів. В цьому випадку одержуємо, що лист від домену mycompany.ru відправляється через сервери, наприклад, smtp01.provider.com, smtp02.provider.com і т. д. Канонічні імена серверів відправників не належать домену компанії mycompany.ru. Як на стороні одержувача в даному випадку зрозуміти, чи є сервери-відправники легітимними чи ні? Це завдання вирішує система перевірок SPF.

Завдання вирішується знову ж таки з допомогою DNS. Для домену відправника публікується запис TXT спеціального формату. В даній TXT перераховуються IP-адреси або підмережі А-записи серверів, які можуть відправляти кореспонденцію, сервери, які не є легітимними відправниками. Завдяки системі SPF одержувач може звернутися до DNS і уточнити, чи можна довіряти серверу відправника листа, або ж сервер відправник намагається видати себе за когось іншого.

На даний момент SPF-запису формують далеко не всі компанії.

5. Фільтрація на основі DKIM. DKIM — DomainKeys Identified Mail – технологія аутентифікації електронних повідомлень. Повернемося до прикладу з розгляду SPF-записів, коли компанія mycompany.ru відправляє кореспонденцію назовні через провайдерські MTA smtp01.mycompany.ru і smtp02.provider.com. Для MTA існують SPF-запису, тому листи від mycompany.ru надіслані через ці сервери, успішно проходять перевірку. Але що якщо дані MTA виявляться скомпрометованими, і зловмисник також отримає можливість відправляти підроблені листи через ці сервери? Як встановити автентичність відправника в цьому випадку? На допомогу приходить аутентифікація листів.

Для аутентифікації використовується асиметрична криптографія і хеш-функції. Закритий ключ відомий виключно сервера відправнику. Відкритий ключ публікується знову ж таки з допомогою DNS в спеціальній TXT. Сервер відправник формує відбиток заголовків листа з допомогою хеш-функції і підписує його, використовуючи закритий ключ. Підписаний відбиток вставляється в заголовок листа «DKIM-Signature:». Тепер одержувач листа з допомогою відкритого ключа може отримати розшифрований відбиток і порівняти його з відбитком полів отриманого листа (хеш-функція відома). Якщо відбитки збігаються, підписані заголовки не були змінені при передачі, а відправник листа, сформував заголовок «DKIM-Signature:», є легітимним.

6. Фільтрація на основі DMARC. DMARC — Domain-based Message Authentication, Reporting and Conformance — технічна специфікація, що описує як саме слід використовувати результати перевірок і DKIM SPF. Політики DMARC публікуються як зазвичай з допомогою DNS в TXT. Політики DMARC вказують, що саме потрібно робити з листом на стороні одержувача (доставити, відкинути, відправити в карантин), залежно від результатів перевірок і DKIM SPF. Крім того, DMARC забезпечує зворотний зв'язок відправника з його одержувачами. Відправник може отримувати звіти про всіх електронних листах, які мають домен відправника. Інформація включає IP-адреси серверів-відправників, кількість повідомлень, результат у відповідності з політиками DMARC, результати перевірок і DKIM SPF.

7. Створення гранулярних фільтрів «вручну». На жаль, далеко не всі організації використовують SPF, DKIM, DMARC при відправці електронної пошти. Крім того, в деяких випадках перевірки SPF, DKIM і DMARC можуть пройти успішно, але листи виявляються все одно підробленими (Cousin domain, Free Email Accounts). Для таких випадків допомагають налаштування фільтрів. Можливості різних систем по створенню правил фільтрації різняться. Фільтри налаштовуються під різні сценарії проведення атаки і залежать від особливостей організації поштових систем в компаніях. Наприклад, в якихось компаніях можуть приходить із зовні листи з доменом-відправником цієї ж компанії. Хоча у більшості випадків такі листи повинні пересилатися тільки в межах периметра організації.

Ми більше орієнтовані на Cisco ESA, тому у висновку розглянемо кілька прикладів налаштування фільтрів на цьому рішенні, а також цікаву функціональність, що з'явилася в релізі 10.0 (від червня 2016) програмного забезпечення для Cisco ESA — Forged Email Detection. Дана функціональність як раз дозволяє боротися з неточною підробкою відправників, як у прикладі з початку статті. Якщо зацікавило, велкам в підкат.

Приклад Cisco ESA. Фільтри.Cisco ESA пропонує два типи фільтрів: Content Filters та Message Filters. Перші настроюються за допомогою GUI і пропонують кінцевий (хоча і досить великий) список умов і дій. Приклад з GUI:



Якщо Content Filters не вистачає, щоб описати умови попадання листи під дію фільтру, можна використовувати Message Filters. Message Filters налаштовуються з командного рядка, використовують регулярні вирази для опису умов і дозволяють створювати складні умови (наприклад, If (((A and B) and not C) or D)). Message Filters обробляють лист до Content Filters і дозволяють створювати більш гранулярні правила.

Розглянемо кілька сценаріїв підробки відправника і відповідні фільтри Cisco ESA для боротьби з атакою.

Приклад 1. Листи з доменом організації у відправника не повинні приходити з поза. Приклад взятий з cisco.com: ссылка. Приклад актуальне в тому випадку, коли організація не готова публікувати свої SPF і Domain Keys в DNS. У даному прикладі використовується наступний Message Filter:

MarkPossiblySpoofedEmail:

if ( (recv-listener == "InboundMail") AND
(subject != "\\{Possibly Forged\\}$") ) // Якщо лист отримано з поза і в заголовку ще не позначено, що лист як «Possibly Forged»
{
if (mail-from == "@yourdomain\\.com$") OR
(header("З") == "(?i)@yourdomain\\.com") // Якщо в конверті mail from присутній домен організації або в заголовку From присутній домен організації 
{
strip-header("Subject");
insert-header("Subject", "$Subject {Possibly Forged}");
}
}
// Додаємо до заголовка запис «Possibly Forged»

У якості дії можуть бути обрані й інші варіанти: відправити в карантин, відкинути лист і т. д.

Приклад 2. На початку статті ми розглядали приклад, коли mail from з конверта листа був не підроблений (attacker@spoofed.ru, тобто атакуючий пише свій вірний адреса), однак у заголовку From вказувався підроблений адреса (uskov@cbs.ru). При цьому, ніщо не заважає атакуючому завести SPF і Domain Keys у DNS для вашого домену spoofed.ru. Отримуємо, що підроблене лист пройде перевірки і DKIM SPF. Також, перевірки і DKIM SPF будуть успішно пройдені, якщо зловмисник використовує безкоштовну пошту (free mail accounts – gmail.com, mail.ru і т. д.).

Боротися з цією ситуацією можемо, перевіряючи рівність значень mail from і заголовку From. Відразу варто обмовитися, в загальному випадку RFC зовсім не вимагає, щоб mail from дорівнював From. Тому застосовувати такий фільтр потрібно тільки до деяких відправникам.

У Cisco ESA на даний момент (листопад 2016) є обмеження: не можна порівнювати значення полів між собою, тобто не можна просто написати if mail from != header (From). Задачу можна розв'язати іншим способом. Створюємо словник імен відправників Spoofed_senders, в який будемо заносити відправників, схильних до підміни. У фільтрі ставимо умову: якщо mail from не містить відправника зі словника, а заголовок From містить відправника зі словника, виконувати дію. Можна відправити листа в карантин або відкинути, але cisco рекомендує записати підробленого значення заголовка From в новий заголовок X-Original-From, а поле From взагалі видалити. У цьому випадку Cisco ESA автоматично сформує заголовок From значення mail from. Приклад такого фільтра:

SpoofedSendersFilter:

if (header-dictionary-match("Spoofed_Senders","З", 1))
AND 
(NOT (mail-from-dictionary-match("Spoofed_Senders", 1))) // Якщо поле From містить ім'я словника, а значення mail from не містить ім'я зі словника
{
insert-header("X-Original-From", "$From");
strip-header("З");
} // Формуємо заголовок X-Original-From і видаляємо заголовок From

Приклад 3. Зловмисники використовують адреси, схожі на адреси відправників, так звані «Cousin domains» і «Cousin addresses». Наприклад, адреса uskov@cbs.ru замінюється на usk0v@cbc.ru. Для домену cbc.ru формуються SPF і Domain Keys у DNS, тому листи проходять відповідні перевірки і DKIM SPF успішно, а одержувач листа бачить знайомого відправника. Боротися з такою підміною складніше. Доведеться заносити до словника Spoofed_senders з попереднього прикладу всі схожі варіанти імен, адрес і назв домену, що навряд чи можливо.

Для боротьби з даним видом підміни відправників у Cisco ESA, починаючи з релізу AsyncOS 10.0 (від червня 2016 року), з'явилася цікава функціональність «Forged Email Detection». Спершу створюється словник імен відправників (в прикладах використовується ім'я словника FED), як і в попередньому прикладі, в який будемо заносити відправників, схильних до підміни. Цей словник формується з імен відправників, а не з імен поштових скриньок. Тобто потрібно писати Olivia Smith замість olivia.smith@example.com. Система Forged Email Detection буде звіряти заголовок From з іменами зі словника FED і видавати ймовірність (від 1 до 100), з якої відправника можна вважати підробленим.

Наприклад, якщо у словнику є «John Simons», а в заголовку From фігурує j0hn.sim0ns@example.com система видасть ймовірність підробки 82. Якщо в заголовку From фігурує john.simons@diff-example.com (тобто те ж ім'я, але інший домен), система видасть ймовірність підробки 100.

Forged Email Detection налаштовується через Content Filters Message або Filters. Нижче скріншот налаштування Content Filter:



Необхідно вказати назву словника, і порогове значення вірогідності, після якого вважаємо відправника підробленим. Для даної умови можна вибрати будь-який з доступних дій (відкинути, відправити в карантин, модифікувати тему листа і т. д.). Крім того, з'явилося нове додаткове дію для Forged Email Detection: замінити значення заголовка From на значення mail from. Дана дія не пропонує якихось опцій:


Висновок

Атаки на електронну пошту з підробкою відправника, на жаль, повсякденна реальність. А наслідки успішного проведення такого роду атаки можуть бути дуже плачевними як для кожної людини окремо, так і для атакується організації в цілому. Можливі значні матеріальні втрати і витоку конфіденційної інформації. Сподіваюся, ця стаття допоможе розібратися з анатомією атак підробленими листами, так і зі способами захисту. У прикладах я оперував рішенням Cisco ESA, однак, інструменти захисту, згадані в статті, реалізуються і на інших системах захисту корпоративної електронної кореспонденції.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.