Безпека електронної пошти

1. Корпоративна листування завжди цікавила конкурентів, і в зв'язку з цим виникає природне запитання:...
2. ПЕРЕХОПЛЕННЯ З ВИКОРИСТАННЯМ широкомовними ПРИРОДИ ETHERNET
3. ПЕРЕХОПЛЕННЯ ПОШТИ З ВИКОРИСТАННЯМ ВРАЗЛИВОСТІ ПОШТОВОЇ СЕРВЕРА
4. ПЕРЕХОПЛЕННЯ З ВИКОРИСТАННЯМ ВРАЗЛИВОСТІ СЕРВЕРІВ DNS
5. ПОРУШЕННЯ ПРАЦЕЗДАТНОСТІ РОБОЧОЇ СТАНЦІЇ ОТРИМУВАЧА
6. ПРОНИКНЕННЯ В ПОШТОВА СКРИНЬКА ОТРИМУВАЧА
7. ВИСНОВКИ
8. ПЕРЕХОПЛЕННЯ З ВИКОРИСТАННЯМ ВРАЗЛИВОСТІ ТРАНЗИТНИХ ВУЗЛІВ

Корпоративна листування завжди цікавила конкурентів, і в зв'язку з цим виникає природне запитання: «А як йдуть справи з безпекою?»

З розвитком комунікаційних засобів з'явилася можливість створення «віртуальних офісів», роботу яких неможливо уявити без електронної пошти. У цій статті розповідається про механізми деяких атак, що реалізуються зловмисниками для перехоплення пошти, порушення працездатності робочої станції одержувача і проникнення в його поштову скриньку. Можливість фальсифікації адреси відправника зважаючи на свою тривіальності тут не розглядається.

ЗАГАЛЬНА ДИСПОЗИЦІЯ

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

1. Зловмисник знаходиться в одному сегменті локальної мережі Ethernet або з Відправником, або з Одержувачем, або з їх поштовим сервером.
2. Відправник і одержувач знаходяться в одній локальній мережі, до якої зловмисник має доступ через Internet.
3. Відправник, Одержувач і Зловмисник знаходяться в різних підмережах, підключених до Internet.

ПЕРЕХОПЛЕННЯ З ВИКОРИСТАННЯМ широкомовними ПРИРОДИ ETHERNET

Уразливість локальних мереж Ethernet пояснюється тим, що вони функціонують за принципом множинного доступу (Carrier Sense Multiple Access / Collision Detection, CSMA / CD) - всі пристрої взаємодіють по одному середовищі, і пакети одного пристрою приймають всі інші. Образно таку схему можна уподібнити телеконференції - навіть якщо повідомлення направлено до якогось конкретній особі, його отримає кожен передплатник конференції. Зрозуміло, передача секретних даних по такому каналу неможлива, якщо, звичайно, їх попередньо не зашифровані.

Будь-який клієнт мережі Ethernet може отримати доступ до всієї інформації, що передається по даному сегменту. Пасивний характер атаки не дозволяє виявити факт перехоплення конфіденційної інформації, а тим більше встановити, на якому вузлі знаходиться атакуючий.

Єдина проблема, що стоїть перед Зловмисником, - як проникнути в локальну мережу, та ще й опинитися в одному сегменті з жертвою? Найчастіше атакуючий знаходиться поза локальної мережі, в кращому випадку має до неї доступ через Internet.

ПЕРЕХОПЛЕННЯ ПОШТИ З ВИКОРИСТАННЯМ ВРАЗЛИВОСТІ ПОШТОВОЇ СЕРВЕРА

Для атаки поштового сервера Зловмисник може використовувати помилки його реалізації, наприклад, у деяких серверів у файлі / etc / aliases присутній рядок decode: | / usr / bin / uudecode автоматичного запуску програми uudecode для розпакування повідомлень UUE.

Багато розшифровувача поміщають розкодований текст в файл, вказаний в заголовку UUE, допускаючи його перезапис без запиту підтвердження від користувача. Якщо, як часто і буває, поштовий сервер має найвищі привілеями, програма uudecode успадкує їх при запуску, а Зловмисник отримує можливість перезапису будь-якого файлу в системі.

Наприклад, він може внести в файл /.forward рядок виду oot, [email protected], [email protected] - для організації дублювання пошти адміністратора на свою власну адресу.

Точно таку операцію можна виконати і з усіма іншими користувачами системи - досить лише змінити файли .forward, що знаходяться в їх домашніх каталогах. Оскільки користувачі можуть самостійно редагувати свої конфігураційні файли, адміністратор не дізнається, хто вніс ці зміни - легальний користувач або зловмисник.

Інша вразливість полягає в можливості виконати код на віддаленому сервері, використовуючи неявну підтримку конвеєра в полях MAIL FROM і RCPT TO у деяких реалізацій поштового сервера. Часом навіть самі розробники не підозрюють про це, оскільки така можливість не завжди очевидна. Наприклад, команда open мови Perl може не тільки відкривати файл, але і запускати його, якщо в імені присутній символ «|», що позначає виклик конвеєра.

Спроби самостійної інтерпретації переданих функції параметрів зустрічаються досить часто. Особливо вони характерні для систем UNIX, в яких конвеєр досить популярний засіб межпроцессорного взаємодії. Однак розробники, що використовують в свій програмі бібліотеки сторонніх постачальників, не завжди перевіряють, як поведе себе та чи інша функція, виявивши символ конвеєра, особливо якщо про це нічого не написано в документації. Схожа проблема виникає і при розробці спільних проектів: один розробник не може знати всіх тонкощів функціонування модулів іншого, а в результаті такої нестиковки отримана програма може неявним чином підтримувати конвеєр!

З цієї причини багато поштові сервери виявляються уразливі перед тривіальним переповненням стека. Наприклад, в лютому 2000 р, в SMTP - сервері MMDF версії 2.44a-B4, що працює під управлінням SCO-UNIX, виявилася помилка переповнення буфера в полях MAIL FROM і RPPT TO, використовуючи яку зловмисник міг виконати будь-який код з привілеями root. А кількома місяцями раніше - в листопаді 1999 року, помилка переповнення була виявлена ​​в POP3SMTP-сервері ZetaMail версії 2.1. Рухаючись командою PASS пароль містився в буфер фіксованого розміру, і занадто довгий рядок не вкладалася в його межі. У листопаді того ж 1999 року було запроваджено повідомлення про наявність аналогічної уразливості в версіях 3.2x SMTP-шлюзу Interscan VirusWall, що працює під управлінням Windows NT. На цей раз переповнення буфера відбувалося під час вітання сервера командою HELLO (якщо це вітання виявлялося надто багатослівним). Приблизно в той же самий час була виявлена ​​уразливість POP3-сервера IMAIL. Версії 5.07, 5.05 і 5.06 не контролювали довжину імені користувача, передану командою USER. Така ж доля спіткала Avirt Mail Server (версії 3.3a, 3.5). Повідомлення про можливість переповнення буфера командою PASS з'явилося на початку листопада всі того ж 1999 р Універсальної захисту від помилок реалізації немає. Адміністратору можна тільки порадити оперативно встановлювати свіжі «заплатки» і оновлення.

На міжмережевий екран сподіватися безглуздо - в даній ситуації він нічим не може допомогти, оскільки ніяк не перешкоджає прийому повідомлень поштовим сервером, що приходять з глобальної мережі. А при введенні заборони прийом листів від нелокальних респондентів стане неможливим, що в переважній більшості випадків є неприйнятним.

ПЕРЕХОПЛЕННЯ З ВИКОРИСТАННЯМ ВРАЗЛИВОСТІ СЕРВЕРІВ DNS

Не всі адресати знаходяться в рамках однієї локальної мережі, і в деяких випадках з ними доводиться зв'язуватися через Internet. Для встановлення з'єднання з віддаленим вузлом необхідно знати його IP-адресу, але в адресах електронної пошти зазвичай використовуються не IP-адреси, а доменні імена поштових серверів абонентів. Для того щоб дізнатися адресу вузла по його доменному імені, зазвичай програма і користувачі звертаються до служби DNS - розподіленої базі даних, найчастіше функціонує на базі протоколу UDP.

Такий вибір пояснюється тим, що протокол UDP працює без встановлення з'єднання і тому має кращу продуктивність в порівнянні з TCP. Розплатою за швидкість стають відсутність контролю доставки пакетів, неможливість визначення автентичності відправника, нездатність протистояти збоїв і виявляти повторювані пакети.

Вузол, який отримав пакет UDP, не може достовірно встановити його істинного відправника, отже, у Зловмисника існує можливість послати повідомлення від чужого імені. Для перехоплення кореспонденції сервера Відправника достатньо надіслати фальсифіковане послання, замаскувавши його під відповідь справжнього DNS-сервера. Якщо сервер не розпізнає обману, він встановить з'єднання не з поштовою скринькою Одержувача, а з зазначеним Зловмисником вузлом, і передасть йому повідомлення.

Якщо Відправник знехтував шифруванням і послав повідомлення у відкритому вигляді, то будь-який бажаючий без праці зможе ознайомитися з його змістом (але навіть якщо лист зашифровано, Зловмисник зміг досадити Відправником, по крайней мере, тим, що Одержувач не отримав лист і тепер уже ніколи не отримає ).

При оцінці ймовірності здійснення загрози необхідно враховувати, що для підробки відповіді DNS зловмисник повинен підібрати правильне значення порту-відправника та унікального ідентифікатора, присутнього у відповіді DNS.

Як пише Ілля Медведовський з співавтором у своїй книзі «Атака через Internet», «початкове значення« порту відправника »в UDP-пакеті> = 1023 і збільшується з кожним переданим запитом DNS», а «значення ідентифікатора (ID) запиту DNS встановлюється наступним чином . У разі передачі запиту DNS з хоста воно залежить від конкретного мережевого додатки, який виробляє запит DNS. Експерименти показали, що якщо запит надсилається з оболонки командного інтерпретатора (SHELL) операційних систем Linux і Windows 95 (наприклад, ftp nic.funet.fi), то це значення завжди дорівнює одиниці. Якщо ж запит DNS передається з Netscape Navigator або його посилає безпосередньо DNS-сервер, то з кожним новим запитом сам браузер або сервер збільшує значення ідентифікатора на одиницю ».

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

Зловмисник повинен не тільки правдоподібно фальсифікувати пакет, але і доставити його жертві раніше, ніж та отримає відповідь від справжнього DNS-сервера. Найпростіше цього досягти, на якийсь час блокувавши сервер DNS Відправника, наприклад, направивши на нього шквал запитів DNS, обробка яких повинна зайняти весь вільний час сервера, або ж спробувати «заблокувати» його якимось іншим способом (а такі способи в арсеналі зловмисників наявні в достатку).

Таким чином, Зловмисник повинен знати не тільки адреси відправника та отримувача, а й адресу сервера DNS Відправника. А ось це вже становить певну проблему! У найпростішому випадку, коли при відправці використовується наданий провайдером сервер DNS, з'ясувати його адресу можна без труднощів: достатньо довідатися про це у провайдера, а його, в свою чергу, можна визначити за IP-адресою Відправника.

Провести атаку на корпоративного користувача значно складніше, оскільки він використовує власний сервер DNS, для надійності закритий ззовні фаєрволом. Створити непереборну захист теоретично цілком можливо. Першим завданням атакуючого стане визначення адреси сервера DNS (а точніше, серверів DNS, оскільки їх може бути і більше одного). Сканування IP-адрес на предмет відкритого 53 порту запобігає той же міжмережевий екран, який блокує прийом пакетів з зовнішніх IP-адрес.

Втім, з цією проблемою атакуючий може впоратися ( «може» слід розуміти двояко - т. Е. Може впоратися, а може і не впоратися) - будь-який міжмережевий екран без вбудованого штучного інтелекту діє по раз закладеної в нього схемою, а тим часом з'являються нові все більш і більш витончені алгоритми сканування, які йому не так-то просто буде розпізнати!

Однак якщо адміністратор мережі запровадить безліч фальшивих серверів DNS, які не здійснюють жодних дій, крім «прослуховування» 53-ї порту, дезорієнтований Зловмисник буде змушений або блокувати їх все до єдиного (при цьому не знаючи напевно, чи присутній серед них справжній сервер DNS), або атакувати жертву яким-небудь іншим способом.

Навіть якщо Зловмисник якимось чином омине міжмережевий екран, йому невідомо точний час відправлення листа - адже не може ж він нескінченно довго закидати Відправника пакетами: така поведінка швидко зверне на себе увагу і демаскує атакуючого. Якщо Відправник відповідає Одержувачу в абсолютно непередбачуване час, і у Зловмисника немає ніяких, навіть непрямих зачіпок, що дозволяють хоча б приблизно визначити час пересилки листа, то йому доведеться змінити свою тактику і атакувати сам сервер DNS.

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

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

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

Як захистити себе від таких атак? Теоретично адміністратор сервера DNS може дещо зробити для підвищення захищеності своїх клієнтів. Наприклад, деякі керівництва з безпеки рекомендують відмовитися від використання протоколу UDP і перейти на TCP. Протокол TCP вигідно відрізняється тим, що працює з встановленням з'єднання і дозволяє ідентифікувати відправників. Падіння продуктивності компенсується підвищеною захищеністю.

Втім, перше, з чим доведеться зіткнутися адміністратору при переході на TCP, - відсутність в документації відомостей про те, як такий трюк виконати (правда, на цю тему є маса прекрасної літератури). Наприклад, в описі демона named, що працює під управлінням Linux, можливість вибору протоколу TCP не згадується взагалі! Але навіть якщо адміністратор зможе зв'язатися з розробниками і ціною безсонних ночей навчить свій сервер «розмовляти» на TCP, то це не зніме загрозу атаки.

По-перше, протокол TCP зовсім не такий захищений, яким здається. Деякі програмні реалізації TCP / IP генерують передбачувані ідентифікатори, дозволяючи Зловмиснику посилати пакети від чужого імені. Саме ця обставина використовував відомий Кевін Митник в своїй атаці проти Цутомі Шимомури (сам Цутому з даного приводу сказав наступне: «Проблема не в Кевіна, проблема в тому, що більшість систем дійсно погано захищене; те, що робив Митник, залишається здійсненним і зараз» ). Вперше на таку вразливість звернув увагу ще Морріс-старший, опублікувавши в лютневому номері журналу Bell Labs за 1985 г. (за десятиліття до Митника!) Докладний технічний звіт по даній проблемі. Але навіть сьогодні, через п'ятнадцять років після публікації, вона залишається актуальною.

Як і друга, Популярні операційні системи містять одну маловідому тонкість (про ті, что НЕ всі з них вміють формуваті Предложения TCP до DNS, доводитися Взагалі мовчати): посилаючися запит DNS, смороду не знають, з которого самє протоколу працює сервер, и пріпускають, что за замовчуванню избран UDP (у всякому разі так налаштовані LINUX и Windows). Тому в назвах випадки сеанс обміну почінається з посилки пакета UDP. При нормальному ході речей сервер може дати клієнтові вказівку перейти на протокол TCP, але якщо Зловмисник зуміє послати жертві підроблений відповідь раніше, ніж це встигне зробити справжній сервер, то клієнт виявиться введеним в оману з усіма наслідками, що випливають звідси наслідками.

Проте, не дивлячись на таку вразливість DNS, реалізувати таку атаку на практиці надзвичайно важко - занадто багато перешкод доведеться подолати зломщику перш, ніж він досягне мети. Але невисока вірогідність успішної атаки - ще не захищеність! У критичних випадках для забезпечення власної безпеки при з'єднанні з вузлом можна використовувати його IP-адресу, а не доменне ім'я.

Якщо Відправник пошле повідомлення за адресою: [email protected], ніякі маніпуляції з сервером DNS не дозволять Зловмиснику перехопити такий лист, оскільки в цьому випадку звернень до DNS не відбувається! З незручностями ж запам'ятовування ряду безглуздих цифр цілком можна змиритися, особливо якщо згадати, що популярні поштові клієнти підтримують адресні книги і автоматично підставляють адресу отримувача по його імені.

Однак такий підхід не позбавлений недоліків. По-перше, Відправник швидше за все не знає IP-адреси вузла отримувача і буде змушений звернутися за ним до DNS. А як було показано вище, сервер DNS міг бути атакований Зловмисником, нав'язати йому помилковий IP-адреса доменного імені поштового сервера отримувача.

По-друге, з одним доменним ім'ям може бути пов'язано безліч IP-адрес. Це дозволяє рівномірно розподілити навантаження між декількома серверами і значно збільшує надійність системи: якщо на одному з серверів відбудеться збій, то обробку запитів продовжать всі інші. В принципі відправник може вибрати якийсь один, що сподобалася йому IP-адреса, але це призведе до істотного зниження надійності зв'язку, що в ряді випадків неприйнятно.

Таким чином, краще, що можна зробити, - це встановити міжмережевий екран, при необхідності перевести сервер DNS на протокол TCP, заборонити клієнту DNS приймати пакети UDP, встановити максимально можливий розмір кешу DNS для запобігання його переповнення, не використовувати генеруючих передбачувані ідентифікатори реалізацій протоколу TCP / IP і, по можливості, попросити виконати ці вимоги адміністратора сервера DNS більш високого рівня.

ПОРУШЕННЯ ПРАЦЕЗДАТНОСТІ РОБОЧОЇ СТАНЦІЇ ОТРИМУВАЧА

Загроза перехоплення конфіденційної кореспонденції - не єдина проблема. Зловмисник може послати Відправникові особливе злоблива повідомлення, читання якого в кращому випадку зіпсує Відправникові настрій, а в гіршому - призведе до крадіжки секретної інформації або навіть форматування жорсткого диска.

На початку жовтня 2000 р якийсь зловмисник, імені якого історія не зберегла, послав автору цієї статті дуже цікаве лист, яке, за його задумом, призначалося для блокування роботи поштового клієнта. У тексті листа, переданого в форматі HTML, присутній наступний тривіальний код Java: «while (1) {alert (« Hello, Kris I love your! »); } ».

При спробі перегляду листи на екрані з'являвся модальний діалог, до закриття якого весь інтерфейс поштового клієнта блокувався. А оскільки діалог видавався в нескінченному циклі, закрити його не було ніякої можливості (т. Е. Закрити-то можна було, але він тут же з'являвся знову). Після перезавантаження (або зняття процесу за допомогою Alt-Ctrl-Del) і повторного запуску поштового клієнта все повторювалося знову. Суть атаки полягала в тому, що для видалення листи доводилося переходити в папку «Вхідні», після чого в області попереднього перегляду відображалося останнім отримане повідомлення, а разом з ним запускався шкідливий сценарій. Втім, автор статті нітрохи не постраждав, оскільки з міркувань безпеки машина Java була відключена.

Який прийшов через пару днів повідомлення на цей раз відкривало в нескінченному циклі безліч вікон розміром мільйон на мільйон пікселів, що в дуже короткий час могло привести до зависання Windows 9x, але встановлена ​​на комп'ютері автора операційна система Windows NT таку атаку благополучно пережила.

Подібні «атаки» викликають посмішку у професіоналів, але здатні поставити в глухий кут новачків, які не мають жодного уявлення про віртуальних машинах Java і не знають, як вийти з такої ситуації. В результаті - втрачений час, нерви, настрій і бурчання потурбований адміністратора. Але як би не було велике його бажання «відключити у всіх користувачів підтримку Java», таке рішення не завжди допустимо, так як перегляд багатьох сайтів після цього виявиться неможливий.

Подібні жарти неприємні, але не більше того. Куди більшу небезпеку становлять сценарії для крадіжки секретних файлів з локального диска користувача. Такі атаки стають можливими завдяки численним помилок в браузерах і віртуальних машинах Java. Навіть п'ята версія браузера Internet Explorer, остання на момент написання статті, запущена під керуванням Windows 2000, залишається небезпечною. Виклик windows.open () в поєднанні з функцією location () дозволяє виконати аплет Java в контексті локального документа, внаслідок чого сценарій Зловмисника отримує доступ до вмісту файлу.

Підтримка плаваючих форм в Internet Explorer 5.01 (і в деяких інших версіях) реалізована з помилкою. Подія NavigateComplete2, що сповіщає про завершення переміщення документа на нове місце, відкриває доступ до нього, навіть якщо документ розташований на локальному диску клієнта. Наведений нижче код демонструє читання файлу «C: est.txt» з виведенням його вмісту в діалоговому вікні:

Але на цьому потік помилок не закінчується. Зловмисник може вставити в лист HTML файл підказки Windows в форматі chm з командами виклику виконуваних файлів, причому останні не обов'язково повинні знаходитися на локальному диску жертви і цілком можуть розташовуватися на комп'ютері зломщика - адже завдяки вбудованій в Windows підтримки загальної міжмережевий файлової системи (Common Internet File System, CIFS) відмінності між локальними і віддаленими файлами нівелюються!

Небезпека такої атаки полягає в тому, що від Відправника не вимагається виконання жодних додаткових дій - Одержувачу достатньо переглянути вміст листа, і код Зловмисника відразу отримає управління. На тлі цієї загрози, гучний вірус I LOVE YOUR і всі інші комахи, що вимагають для свого запуску відкриття прикріпленого до листа вкладення, виглядають дитячою іграшкою.

Нещодавно в Outlook Express 5.х була виявлена ​​серйозна помилка, яка полягає в тому, що занадто довге поле заголовка листа може переповнити буфер і передати управління коду зловмисника ще на стадії отримання листа з сервера, т. Е. Задовго до того, як його встигнуть перевірити всі існуючі антивіруси! Неважко уявити собі, як це могло б бути використано спритнішими зловмисниками (якби вони не такими ледачими)! Втім, така можливість у них ще є - адже не всі користувачі піклуються про оновлення своїх додатків, і вразливий Outlook Express 5.x досі широко поширений.

Жартома можна сказати: листи, особливо надіслані в форматі HTML, краще взагалі не читати, а вже тим більше, отримані в п'ятницю, що припадає на тринадцяте число тринадцятого місяця.

ПРОНИКНЕННЯ В ПОШТОВА СКРИНЬКА ОТРИМУВАЧА

Ще однією метою атаки Зловмисника може бути поштова скринька отримувача. Якщо зломщик зможе якимось чином підібрати до нього пароль, то він отримає доступ до всієї зберігається в ньому кореспонденції. Перший спосіб убезпечити себе - використовувати дуже довгий, безглуздий, іррегулярні пароль, знайти який лобовим перебором Зловмисник не зможе навіть за все життя. Вибираючи такий пароль, Одержувач повинен враховувати, що багато поштові служби підтримують опцію «забули пароль?». У загальних рисах суть її полягає в наступному: реєструючись в системі, користувач повідомляє деяку додаткову інформацію про себе, наприклад дату народження улюбленої щури свій подруги. Якщо пароль забутий, то, ввівши цю інформацію, можна отримати новий. З найбільш загальних міркувань слід: контрольна інформація повинна бути стільки ж непередбачувана, як і сам пароль, інакше це полегшить Зловмиснику проникнення в систему. Наприклад, всіляких дат в діапазоні між 1950 і 2000 рр. існує трохи більше десяти тисяч, і для їх перебору не буде потрібно багато часу, тому використання будь-якої дати в якості контрольної інформації нерозумно!

Припустимо, Одержувач правильно поставився до вибору пароля і контрольної інформації. Чи може він тепер відчувати себе в безпеці? Якщо використовувана поштова служба не містить помилок реалізації, що дозволяють Зловмиснику отримати доступ до вмісту чужих ящиків (взагалі-то системи без помилок сьогодні велика рідкість), то на перший погляд йому ніщо не загрожує.

Тим часом протокол POP3, який використовується для доставки пошти з сервера на комп'ютер клієнта, передає ім'я користувача і пароль у відкритому, незашифрованому вигляді. Зловмиснику досить перехопити мережевий трафік і отримати відповідні пакети. Широкомовне середу локальних мереж Ethernet дозволить здійснити цю операцію без праці, а міжсегментного атака може бути реалізована компрометацією DNS.

У специфікації протоколу POP3 можна виявити необов'язкову для реалізації команду APOP для шифрування пароля перед його відправкою на сервер. Однак її підтримують не всі поштові служби і не всі поштові клієнти. З'ясувати, як йдуть справи в конкретному випадку можна у адміністратора системи (наприклад, популярний сервер mail.ru застосовує такий метод аутентифікації користувачів).

ВИСНОВКИ

Проаналізувавши ситуацію, що склалася, доводиться констатувати: конфіденційність електронної переписки на сьогоднішній день не гарантується. Загроза виходить не тільки від спецслужб, на зразок СОРМ, а й від звичайних підлітків, озброєних одним лише модемом, простеньким персональним комп'ютером і базовими технічними знаннями. Всі атаки, описані вище, не представляють ніякого секрету і добре відомі як спеціалістам з безпеки, так і зловмисникам. Відсутність гучних прецедентів, пов'язаних з розкраданням пошти, не дає приводу надягати рожеві окуляри. На відміну від прикраси сторінок Web своїм графіті, перехоплення кореспонденції відбувається непомітно, а жертвам невигідно розголошувати факт доконаний атаки, особливо якщо зловмисникам вдалося викрасти дійсно цінну інформацію.

В ідеальному випадку слід було б порадити відмовитися від пересилки пошти на віддалені вузли Internet, а якщо така операція неминуча, - обов'язково шифрувати вміст послання за допомогою таких утиліт, як PGP.

Ні в якому разі не варто економити на фахівцях: адміністратор повинен володіти глибокими знаннями пристрої мережі і необхідним досвідом роботи. Але не варто переоцінювати можливості навіть найталановитішого «гуру». Адміністратор - не бог, і усунути уразливості базових протоколів і систем захисту він не силах.

Строго кажучи, будь-який протокол Internet, заснований на TCP / IP, принципово вразливий для злому, а перехід на нові захищені протоколи з деяких причин затягується і відбувається не так швидко, як хотілося б.

У той же час необхідно відзначити відносну нечисленність описаних вище атак у зв'язку з труднощами їх реалізації. Так що не варто впадати в паніку - незважаючи на проблеми з безпекою Internet живе і працює, його захищеність поступово поліпшується.

Кріс Касперски - незалежний експерт з комп'ютерної безпеки. З ним можна зв'язати за адресою: [email protected] .

ПЕРЕХОПЛЕННЯ З ВИКОРИСТАННЯМ ВРАЗЛИВОСТІ ТРАНЗИТНИХ ВУЗЛІВ

В ідеальному випадку сервер відправника встановлює пряме з'єднання з поштовою скринькою одержувача і опускає в нього конверт. Але така схема дуже рідко відповідає реальній дійсності. Величезні обсяги щомиті оброблюваної кореспонденції змусили розбити процес доставки повідомлень на безліч етапів і створити вузькоспеціалізовані вузли, що займаються виключно транспортуванням пошти від одного сервера до іншого.

Така схема дозволила оптимізувати мережевий трафік, але породила цілий ряд проблем: листи стали губитися, «застрявати», спотворюватися в результаті подвійної перекодування і т. Д. До того ж багато проміжних вузли слабо захищені і представляють легку мішень для злому.

Для зв'язку один з одним проміжні вузли часто використовують доменні імена, тому існує можливість перехоплення потоку кореспонденції спрямованим штурмом хибні відповіді DNS на один з таких вузлів. Подібна атака вимагає знання маршруту листи і адреси сервера DNS, якому проміжний вузол направляє запит.

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

Якщо ж ця операція не вдасться (а вона, швидше за все, не вдасться), Зловмисник може вступити в листування з Відправником або будь-яким іншим користувачем того ж сервера. Йому достатньо отримати хоча б один конверт, щоб відновити траєкторію подорожі листи.

Адреса сервера DNS можна з'ясувати тривіальним скануванням - більшість великих транзитних вузлів мають свої власні сервери DNS, розташовані в тій же підмережі. Звичайно, адміністратор вузла, що атакується міг встановити міжмережевий екран, що перешкоджає визначенню адреси його сервера DNS, але не всі проміжні вузли забезпечені таким захистом.

Для забезпечення конфіденційності листування Відправникові доведеться або повністю відмовитися від пересилання, або довіряти її лише надійним вузлам. І те й інше можна реалізувати клієнтськими засобами, не звертаючись за допомогою до адміністратора. Спеціальні програми дозволяють здійснювати так звану директивну розсилку. Вони не потребують серверах вихідної пошти і при відправці повідомлення встановлюють з'єднання безпосередньо з поштовою скринькою одержувача. Якщо жодної такої програми під рукою немає, то на худий кінець зійде і штатний поштовий клієнт - досить в поле адреси сервера вихідної пошти прописати адресу поштової скриньки одержувача повідомлення.

Для листування з одним лише Одержувачем запропонована вище схема цілком прийнятна, але якщо Відправник переписується з величезною кількістю респондентів, то виникають певні складнощі. Наприклад, ящики деяких одержувачів на момент відправки повідомлення можуть не працювати (або працювати нестабільно), і відправку кореспонденції доведеться повторювати знову і знову. Як покласти це завдання на чужі плечі і при цьому не погіршити безпеку (варіант найняти секретаря тут не розглядається)?

Вивчаючи специфікацію протоколу SMTP, відповідального за пересилку кореспонденції, можна виявити давно забутий рудимент, що залишився з тих незапам'ятних часів, коли ніякої автоматичної маршрутизації ще не існувало і маршрут проходження пакетів відправнику доводилося вказувати самостійно.

У системах UNIX для цієї мети використовувався ліс знаків оклику для перерахування всіх проміжних вузлів один за іншим. Розробники протоколу SMTP замінили знаки оклику на легким для читання коми, чому повну адресу одержувача став виглядати приблизно так: «», де one і two адреси проміжних вузлів, які пересилають пошту один одному по ланцюжку. Якщо жоден проміжний вузол не вказано, сервер-відправник самостійно визначає маршрут передачі повідомлення. Коли пряме з'єднання між вузлами one і two неможливо, лист або повернеться назад до відправника, або вузол one передасть його через посередника, якого вибере самостійно. Т. е. За умови дотримання стандартів гарантується, що лист відвідає всі перераховані вузли в зазначеному порядку, але не факт, що воно пройде тільки через перераховані вузли.

Правильний підбір вузлів передбачає, що кожен вузол надійно захищений від зазіхань зловмисника і забезпечує безпосередній зв'язок зі своїм «сусідом».

Якщо Відправник успішно впорається з підбором транзитних серверів, то йому залишиться вирішити одну маленьку проблему, а саме: відмова популярних поштових клієнтів прийняти таку адресу, оскільки вони вважатимуть його «неправильним». Вихід із ситуації полягає у використанні спеціалізованих клієнтів, яких неважко знайти в мережі.