Чи можна довіряти vpn-мереж свої секрети
Перше, що спадає на думку при згадці VPN, - це анонімність і захищеність переданих даних. Чи так це насправді? Давай розберемося.
Коли необхідно отримати доступ до корпоративної мережі, безпечно передати важливу інформацію по відкритих каналах зв'язку, приховати свій трафік від пильного погляду провайдера, приховати своє реальне місце розташування при проведенні будь-яких не зовсім законних (або зовсім не законних) дій, зазвичай вдаються до використання VPN . Але чи варто сліпо покладатися на VPN, ставлячи на кін безпеку своїх даних і власну безпеку? Однозначно - ні. Чому? Давай розбиратися.
VPN нам потрібен!
Віртуальна приватна мережа, або просто VPN, - узагальнена назва технологій, що дозволяють забезпечити одне або кілька мережних з'єднань (логічну мережу) поверх іншої мережі, наприклад Інтернету. Незважаючи на те що комунікації можуть бути реалізовані через публічні мережі з невідомим рівнем довіри, рівень довіри до побудованої логічної мережі не залежить від рівня довіри до базових мереж завдяки використанню засобів криптографії (шифрування, аутентифікації, інфраструктури відкритих ключів, засобів для захисту від повторів і змін переданих по логічної мережі повідомлень). Як бачиш, в теорії все райдужно і безхмарно, на практиці ж все трохи інакше. У цій статті ми розглянемо два основних моменти, які обов'язково потрібно брати до уваги, користуючись VPN.
Витік VPN-трафіку
Корінь зла
Це співіснування протоколів означає, що, коли клієнт, що підтримує обидва стека, збирається взаємодіяти з іншою системою, наявність А- і АААА-записів буде впливати на те, який протокол буде використовуватися для зв'язку з цією системою.
VPN і подвійний стек протоколів
Основна причина проблеми криється в тому, що, хоча IPv4 і IPv6 - два різних протоколу, несумісних один з одним, вони тісно використовуються в системі доменних імен. Таким чином, для системи, що підтримує обидва стека протоколів, неможливо забезпечити безпеку з'єднання з іншою системою, не забезпечивши безпеку обох протоколів (IPv6 і IPv4).
Легітимний сценарій витоку VPN-трафіку
Розглянемо хост, який підтримує обидва стека протоколів, використовує VPN-клієнт (працює тільки з IPv4-трафіком) для підключення до VPN-сервера і підключений до dual-stacked мережі. Якщо якомусь з додатком на хості потрібно взаємодіяти з dual-stacked вузлом, клієнт зазвичай запитує і А-, і АААА-DNS-записи. Так як хост підтримує обидва протоколи, а віддалений вузол буде мати обидва типи DNS-записів (А і АААА), то одним з можливих варіантів розвитку подій буде використання для зв'язку між ними IPv6-протоколу. А так як VPN-клієнт не підтримує шосту версію протоколу, то IPv6-трафік не буде відправлятися через VPN-з'єднання, а відправлятиметься у відкритому вигляді через локальну мережу.
Такий варіант розвитку подій ставить під загрозу передаються у відкритому вигляді цінні дані, в той час як ми думаємо, що вони безпечно передаються через VPN-з'єднання. В даному конкретному випадку витік VPN-трафіку є побічним ефектом використання ПЗ, який не підтримує IPv6, в мережі (і на хості), що підтримує (їм) обидва протоколи.
Навмисно викликаємо витік VPN-трафіку
Атакуючий може навмисно викликати підключення по протоколу IPv6 на комп'ютері жертви, посилаючи підроблені ICMPv6 Router Advertisement повідомлення. Подібні пакети можна розсилати за допомогою таких утиліт, як rtadvd. SI6 Networks 'IPv6 Toolkit або THC-IPv6. Як тільки з'єднання по протоколу IPv6 встановлено, «спілкування» з системою, що підтримує обидва стека протоколів, може вилитися, як розглянуто вище, в витік VPN-трафіку.
І хоча дана атака може бути досить плідною (через зростаючого числа сайтів, що підтримують IPv6), вона призведе до витоку трафіку, тільки коли одержувач підтримує обидві версії протоколу IP. Однак для зловмисника не важко викликати витоку трафіку і для будь-якого одержувача (dual-stacked чи ні). Розсилаючи підроблені Router Advertisement повідомлення, що містять відповідну RDNSS-опцію, атакуючий може прикинутися локальним рекурсивним DNS-сервером, потім провести DNS-спуфинг, щоб здійснити атаку man-in-the-middle і перехопити відповідний трафік. Як і в попередньому випадку, такі інструменти, як SI6-Toolkit і THC-IPv6, можуть легко провернути такий трюк.
Корисні поради
Зовсім не справа, якщо трафік, що не призначений для чужих очей, потрапить у відкритому вигляді в мережу. Як же убезпечити себе в таких ситуаціях? Ось кілька корисних рецептів:
- Якщо VPN-клієнт налаштований таким чином, щоб відправляти весь IPv4-трафік через VPN-з'єднання, то:
- якщо IPv6 VPN-клієнтом не підтримує - відключити підтримку шостої версії протоколу IP на всіх мережеві інтерфейси. Таким чином, у додатків, запущених на комп'ютері, не буде іншого вибору, як використовувати IPv4;
- якщо IPv6 підтримується - переконатися, що весь IPv6-трафік також відправляється через VPN.
- Щоб уникнути витоку трафіку, в разі якщо VPN-з'єднання раптово відвалиться і всі пакети будуть відправлятися через default gateway, можна:
- примусово змусити весь трафік йти через VPN
- скористатися утилітою VPNetMon. яка відстежує стан VPN-з'єднання і, як тільки воно пропадає, миттєво завершує зазначені користувачем додатки (наприклад, торрент-клієнти, веб-браузери, сканери);
- або утилітою VPNCheck. яка в залежності від вибору користувача може або повністю відключити мережеву карту, або просто завершити зазначені додатки.
- Перевірити, вразлива чи твоя машина до витоку DNS-трафіку, можна на сайті. після чого застосувати поради, як пофиксить витік, описані тут.
Розшифровка VPN-трафіку
Навіть якщо ти все налаштував правильно і твій VPN-трафік не витікає в мережу у відкритому вигляді - це ще не привід розслаблятися. Вся справа в тому, що якщо хтось перехопить зашифровані дані, що передаються через VPN-з'єднання, то він зможе їх розшифрувати. Причому на це ніяк не впливає, складний у тебе пароль або простий. Якщо ти використовуєш VPN-з'єднання на базі протоколу PPTP, то зі стовідсотковою впевненістю можна сказати, що весь перехоплений зашифрований трафік можна розшифрувати.
Ахіллесова п'ята
При VPN-судинних на базі протоколу PPTP (Point-to-Point Tunneling Protocol) аутентифікація користувачів проводиться по протоколу MS-CHAPv2, розробленим компанією Microsoft. Незважаючи на те що MS-CHAPv2 застарів і дуже часто стає предметом критики, його продовжують активно використовувати. Щоб остаточно відправити його на смітник історії, за справу взявся відомий дослідник Моксі Марлінспайк, який на двадцятій конференції DEF CON відзвітував, що поставлена мета досягнута - протокол зламаний. Треба сказати, що безпекою цього протоколу спантеличувалися і раніше, але настільки тривале користування MS-CHAPv2, можливо, пов'язано з тим, що багато дослідників концентрувалися тільки на його уразливості до атак за словником. Обмеженість досліджень і широке число підтримуваних клієнтів, вбудована підтримка операційними системами - все це забезпечило протоколу MS-CHAPv2 широке поширення. Для нас же проблема криється в тому, що MS-CHAPv2 застосовується в протоколі PPTP, який використовується багатьма VPN-сервісами (наприклад, такими великими, як анонімний VPN-сервіс IPredator і The Pirate Bay's VPN).
Протокол MS-CHAPv2
Як вже було сказано, MSCHAPv2 застосовується для аутентифікації користувачів. Відбувається вона в кілька етапів:
- клієнт надсилає запит на аутентифікацію сервера, відкрито передаючи свій login;
- сервер повертає клієнтові 16-байтовий випадковий відгук (Authenticator Challenge);
- клієнт генерує 16-байтовий PAC (Peer Authenticator Challenge - рівний відгук аутентифікації);
- клієнт об'єднує PAC, відгук сервера і своє user name в один рядок;
- з отриманого рядка знімається 8-байтовий хеш за алгоритмом SHA-1 і надсилається сервера;
- сервер витягує зі своєї бази хеш даного клієнта і розшифровує його відповідь;
- якщо результат розшифровки співпаде з вихідним відгуком, все ОK, і навпаки;
- згодом сервер бере PAC клієнта і на основі хешу генерує 20-байтовий AR (Authenticator Response - аутентифікаційний відповідь), передаючи його клієнтові;
- клієнт проробляє ту ж саму операцію і порівнює отриманий AR з відповіддю сервера;
- якщо все збігається, клієнт аутентифицирующей сервером. На малюнку представлена наочна схема роботи протоколу.
На перший погляд протокол здається зайво складним - купа хешів, шифрування, випадкові challenge. Насправді все не так вже й складно. Якщо придивитися уважніше, то можна помітити, що в усьому протоколі залишається невідомою тільки одна річ - MD4-хеш пароля користувача, на підставі якого будуються три DES-ключа. Решта ж параметри або передаються у відкритому вигляді, або можуть бути отримані з того, що передається у відкритому вигляді.
Так як майже всі параметри відомі, то ми можемо їх не розглядати, а зупинити свою пильну увагу на те, що невідомо, і з'ясувати, що це нам дає.
Отже, що ми маємо: невідомий пароль, невідомий MD4-хеш цього пароля, відомий відкритий текст і відомий шифртекст. При більш детальному розгляді можна помітити, що пароль користувача нам не важливий, а важливий його хеш, так як на сервері перевіряється саме він. Таким чином, для успішної аутентифікації від імені користувача, а також для розшифровки його трафіку нам необхідно знати всього лише хеш його пароля.
Маючи на руках перехоплений трафік, можна спробувати його розшифрувати. Є кілька інструментів (наприклад, asleap), які дозволяють підібрати пароль користувача через атаку по словнику. Недолік цих інструментів в тому, що вони не дають стовідсоткової гарантії результату, а успіх безпосередньо залежить від обраного словника. Підбирати ж пароль простим брутфорсом теж не дуже ефективно - наприклад, у випадку з PPTP VPN сервісом riseup.net, який примусово встановлює паролі довжиною в 21 символ, доведеться перебирати 96 варіантів символу для кожного з 21 символів. Це в результаті дає 96 ^ 21 варіантів, що трохи більше, ніж 2 ^ 138. Іншими словами, треба підібрати 138-бітний ключ. У ситуації ж, коли довжина пароля невідома, має сенс підбирати MD4-хеш пароля. З огляду на, що його довжина дорівнює 128 біт, отримуємо 2 ^ 128 варіантів - на даний момент це просто нереально обчислити.
Розділяй і володарюй
MD4-хеш пароля використовується в якості вхідних даних для трьох DES-операцій. DES-ключі мають довжину 7 байт, так що кожна DES-операція використовує 7-байтовий фрагмент MD4-хешу. Все це залишає можливість для класичної атаки divide and conquer. Замість того щоб повністю Брут MD4-хеш (а це, як ти пам'ятаєш, 2 ^ 128 варіантів), ми можемо підбирати його по частинах в 7 байт. Так як використовуються три DES-операції і кожна DES-операція абсолютно незалежна від інших, це дає загальну складність підбору, рівну 2 ^ 56 + 2 ^ 56 + 2 ^ 56, або 2 ^ 57.59. Це вже значно краще, ніж 2 ^ 138 і 2 ^ 128, але все ще занадто велика кількість варіантів. Хоча, як ти міг помітити, в ці обчислення закралася помилка. В алгоритмі використовуються три DES-ключа, кожен розміром в 7 байт, тобто всього 21 байт. Ці ключі беруться з MD4-хешу пароля, довжина якого всього 16 байт.
Три DES-ключа по 7 байт
Тобто не вистачає 5 байт для побудови третього DES-ключа. У Microsoft вирішили це завдання просто, тупо заповнивши відсутні байти нулями і фактично звівши ефективність третього ключа до двох байтам.
Так як третій ключ має ефективну довжину всього лише два байта, тобто 2 ^ 16 варіантів, його підбір займає лічені секунди, доводячи ефективність атаки divide and conquer. Отже, можна вважати, що останні два байта хешу відомі, залишається підібрати залишилися 14. Також розділивши їх на дві частини по 7 байт, маємо загальне число варіантів для перебору, що дорівнює 2 ^ 56 + 2 ^ 56 = 2 ^ 57. Все ще занадто багато, але вже значно краще. Зверни увагу, що залишилися DES-операції шифрують один і той же текст, тільки за допомогою різних ключів. Можна записати алгоритм перебору наступним чином:
Але так як текст шифрується один і той же, то правильніше зробити ось так:
Тобто виходить 2 ^ 56 варіантів ключів для перебору. А це означає, що безпека MS-CHAPv2 може бути зведена до стійкості одного DES-шифрування.
Для автоматизації роботи з сервісом і обробки перехопленого трафіку Моксі виклав у відкритий доступ утиліту chapcrack. Вона парсит перехоплений мережевий трафік, шукаючи MS-CHAPv2 handshake'і. Для кожного знайденого «рукостискання» вона виводить ім'я користувача, відомий відкритий текст, два відомих шифртекста і зламує третій DES-ключ. Крім цього, вона генерує токен для CloudCracker, в якому закодовані три параметра, необхідні, щоб сервіс зламав залишилися ключі.
CloudCracker Chapcrack
На випадок, якщо тобі знадобиться зламати DES-ключі з перехопленого призначеного для користувача трафіку, наведу невелику покрокову інструкцію.
До невеликого жаль, сервіс CloudCracker платний. На щастя, за злом ключиків доведеться віддати не так вже й багато - всього 20 доларів.
Що робити?
Хоч Microsoft і пише на своєму сайті, що на даний момент не має відомостей про активні атаках з використанням chapcrack, а також про наслідки таких атак для призначених для користувача систем, але це ще не означає, що все в порядку. Моксі рекомендує всім користувачам і провайдерам PPTP VPN рішень починати міграцію на інший VPN-протокол. А PPTP-трафік вважати незашифрованим. Як бачиш, у наявності ще одна ситуація, коли VPN може нас серйозно підвести.
висновок
Так склалося, що VPN асоціюється з анонімністю і безпекою. Люди вдаються до використання VPN, коли хочуть приховати свій трафік від пильних очей провайдера, підмінити своє реальне географічне положення і так далі. На ділі виходить, що трафік може «протекти» в мережу у відкритому вигляді, а якщо і не в відкритому, то зашифрований трафік можуть досить швидко розшифрувати. Все це ще раз нагадує, що не можна сліпо покладатися на гучні обіцянки повної безпеки та анонімності. Як то кажуть, довіряй, але перевіряй. Так що будь напоготові і стеж за тим, щоб твоє VPN-з'єднання було по-справжньому безпечним і анонімним.
Покажи цю статтю друзям: