Деанонимизируем користувачів Windows і отримуємо облікові дані Microsoft і VPN-акаунтів


Якщо ви не бачите цю картинку, то дані вашого облікового запису Windows вже скомпрометовані.

Введення

Давним-давно, коли комп'ютери були одноядерними і чудово працювали з 256 МБ RAM, а мережі під управлінням Windows вже використовувалися дуже широко, хлопці з Microsoft подумали, що було б зручно аутентифицироваться тільки один раз, при завантаженні комп'ютера, а доступ на внутрішні ресурси відбувався б автоматично, без введення пароля, і зробили так звану технологію єдиного входу (Single Sign-on). Єдиний вхід працює дуже просто: коли користувач намагається отримати доступ до певного ресурсу з NTLM-аутентифікацією (стандартний спосіб аутентифікації в мережах Windows), ОС відразу передає назву домену, ім'я облікового запису і хеш пароля поточного користувача, і якщо під цими даними увійти не вдалося, показує діалог введення імені користувача і пароля. Йшли роки, проблеми з безпекою реалізації технології єдиного входу давали про себе знати, одні з яких успішно виправляли, інші виправляли менш успішно, а про третє чомусь зовсім забули. Так і забули про проблему передачі облікових даних для єдиного входу SMB-ресурси (мережеві ресурси: файли, папки, принтери, тощо) через інтернет, яку можна експлуатувати в усіх сучасних ОС, включаючи Windows 10 з усіма останніми оновленнями. Про особливості роботи стека аутентифікації згадують кожні 1-2 роки, останній раз про неї розповідали на Blackhat US 2015, але Microsoft не поспішає щось змінювати.

Як це працює?

Як тільки ви намагаєтеся відкрити посилання на SMB-ресурс в стандартному браузері Internet Explorer, Edge) або будь-якому додатку, що працює через стандартні виклики API Windows або використовують Internet Explorer в якості рушія для відображення HTML (Outlook, провідник Windows), SMB-ресурс відразу отримує дані вашого облікового запису ще до того, як ви побачите діалог введення імені та пароля. Атакуючому достатньо, наприклад, додати посилання на картинку з SMB-сервера на сторінку, або відправити вам листа, якого достатньо буде просто відкрити, і — бум! — дані вашого облікового запису в руках зловмисника. До недавнього часу вважалося, що нічого особливо страшного від того, що хтось дізнається ім'я вашого облікового запису і хеш пароля домашнього комп'ютера не відбудеться (якщо це не спрямована атака), т. к. в імені часто написана нісенітниця, пароль часто не ставлять, а якщо він і встановлено, навряд чи його можна використовувати на шкоду.

Ситуація кардинально змінюється в разі корпоративного комп'ютера, який введено в домен. З назви домену зазвичай нескладно зрозуміти, до якої організації належить обліковий запис, а далі, у разі успішного підбору пароля, можна спробувати аутентифицироваться на корпоративних ресурсів, доступних з інтернету (пошта, VPN).
Але пароль не завжди необхідно підбирати. Якщо ви наперед знаєте якийсь ресурс, куди можна входити з використанням NTLM-аутентифікації, ви можете у режимі реального часу, як тільки клієнт підключається до вашого SMB-сервера, проксировать запити від клієнта до віддаленого сервера і від сервера до клієнта, і успішно на ньому аутентифицируетесь! Якщо вам пощастило, і ви перебуваєте в одному сегменті мережі з адміністратором домену і знаєте IP домен-контролера, ви без праці їм оволодієте, що показував Intercepter ще два роки назад:


Windows 8 і Microsoft Account

Сучасні операційні системи від Microsoft тісно інтегровані з інтернетом і практично змушують вас створювати не локальний обліковий запис для входу в систему, а обліковий запис Microsoft. Без MS-аккаунта ви не зможете скористатися, наприклад, магазином додатків, OneDrive і Cortana, а інше буде постійно розповідати, як добре вам жилося з синхронізацією файлів, налаштувань і пошти, якщо ви його собі зареєструєте.
Усі ранні серйозні дослідження обговорюваної особливості проводилися до Windows 8, і навіть в презентації з Blackhat обліковий запис Microsoft згадується тільки побіжно, а даремно — при використанні Microsoft Account на комп'ютерах під управлінням Windows 8, 8.1 і 10, ваша ОС передасть на SMB сервер зловмисника в інтернеті дані не вашого локального облікового запису, з якими майже нічого не можна зробити, а скомпрометує прямо-таки ваш обліковий запис Microsoft, з якої можна виробляти набагато більш веселі речі. Таким чином, стару атаку, яка всі ці роки представляла загрозу тільки корпоративному сектору, тепер цілком можна застосовувати і на домашніх користувачів.

Нові подробиці

Під час тестування передачі облікових даних під різними версіями Windows я виявив, що 3 машини з Windows 10, які були встановлені відносно давно, цілком успішно спілкуються спрощеними реалізаціями SMB (Responder, Impacket), а комп'ютер зі свіжовстановленому ОС майже відразу після підключення розриває з'єднання, не встигаючи передати дані для входу, хоча відмінно працює з повноцінною Samba. Кілька днів налагодження відкрили цікаву особливість стека облікових записів Windows: якщо NetBIOS і Workstation-імена SMB-сервера збігаються, то Windows використовує поточну обліковий запис (локальну або Microsoft) для входу на ресурс, але якщо імена не співпадають, і ви підключені до VPN з аутентифікацією по MSCHAPv2, то ОС надсилає логін і хеш пароля цього VPN-підключення! Я припустив, що дана особливість притаманна MSCHAPv2-аутентифікації в цілому, але немає, з Wi-Fi WPA-Enterprise (PEAP/MSCHAPv2) такий трюк не працює.

Як це використовувати?

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

Найпростіший спосіб експлуатації — просто налаштувати SMB сервер і відстежувати, хто ж буде намагатися на нього увійти. Довго чекати не доведеться, оскільки весь маршрутизируемый діапазон IPv4-адрес постійно сканується з метою наживи. Сканери часто запускаються на Windows-комп'ютерах, багато їх них за замовчуванням аутентифицируются з вашим обліковим записом. Так ми можемо дізнатися ім'я комп'ютера, ім'я користувача і хеш пароля машини, з якою нас сканують. Весело, але малорезультативно, адже щось осудна імені користувача пишуть не так вже й часто, MS-акаунти на сканерах практично не використовують, а з локального облікового запису доступ навряд чи кудись можна отримати. Для збору хешів простіше всього використовувати Responder, я додав до нього параметр, щоб можна було збирати кілька хешів, якщо такі є, маніпулюючи NetBIOS-ім'я (
CaptureMultipleCredentials = On
в конфігураційному файлі).

Експлуатація з метою деанонімізація — цікавіше. Учетка буде відправлятися зі сторінок сайту, якщо жертва використовує Internet Explorer, або при натисканні всередині листа, у випадку з Outlook. Майже всі веб-інтерфейси поштових служб фільтрують картинки зі схемою file:// при виведенні листи (схема file:// є аналогом схеми \\), але не Яндекс, який не вважає це своєю вразливістю (що, загалом-то, коректно). Деанонімізація з використанням пошти більш небезпечна, оскільки дає зв'язок не тільки IP-адреси облікових записів Windows, але і з поштою.


У Chrome схема file:// теж працює, але тільки з адресного рядка. Завантажити що-небудь з SMB картинкою або при натисканні на посилання не вийде. Так як Chrome набагато популярніший Internet Explorer, доведеться застосовувати соціальну інженерію.
image

Можна красти акаунти собі на благо. Деякі VPN-провайдери використовують однакові логіни і паролі для входу в аккаунт, так і для VPN-аутентифікації. Приналежність запису до того чи іншого сервісу можна визначити за IP-адресою вхідного підключення користувача. А якщо вам дістався Microsoft Account, і ви знайшли пароль хешу, то вітаю — у вас є доступ до файлів в хмарі OneDrive, поштою Outlook, акаунта Skype, якщо він підключений до Microsoft-аккаунту, і ще купу всього.


image

Зрозуміло, старі відомі атаки на зразок SMB Relay теж продовжують працювати.

Як захиститися?

Не варто думати, що ви в повній безпеці, якщо не користуєтеся Internet Explorer і не відкриваєте вручну посилання зі схемою file://. Досить встановити не надто надійне додаток, яке спробує завантажити якісь дані з SMB-сервера через штатні функції Windows API, наприклад, URLDownloadToFile(). Таким чином додаток, у якого немає привілеїв на отримання пароля облікового запису, вкраде його через інтернет.

Якщо вам не потрібен доступ до SMB-ресурсів в інтернеті, надійніше всього стандартним брандмауером Windows обмежити доступ до 445 TCP-порту для всіх діапазонів адрес, крім:
  • 192.168.0.0/16
  • 169.254.0.0/16
  • 172.16.0.0/12
  • 10.0.0.0/8
  • fd00::/8
  • fe80::/10
Деякі провайдери, наприклад Ростелеком, блокують доступ по порту 445 у своїх мережах, що досить мило з їх боку.

Висновок

Я додав можливість перевірити, стосується вас ця проблема, WITCH?. Спробуйте відкрити її через Internet Explorer або Edge, і якщо ваш хеш витікає в інтернет, WITCH? спробує підібрати пароль, використовуючи невеликий словник, і покаже вам його. Якщо перед заходом підключення до VPN, то WITCH? також покаже дані VPN-аккаунта. Якщо ви читаєте цю статтю через вищезгадані браузери, то ваш хеш вже в мене :)
Про проблему сповістив деяких VPN-провайдерів, які заблокували порт 445 всередині VPN, або додали опцію для локальної блокування свого ПЗ.
Для мене виявилося одкровенням те, що популярні утиліти — Hashcat (-legacy) і John The Ripper (OpenCL-реалізація) — неправильно зламують NTLMv2-хеш. Просто не можуть підібрати пароль, хоча він гарантовано є в словнику. З oclHashcat і Hashcat 3.0, начебто, все в порядку. Залишається тільки здогадуватися, скільки паролів не було зламано з-за цих помилок…
Прихований текстpBDmmYm5fxfloFf6@yandex.ru, перевір пошту, якщо ти це читаєш.
Джерело: Хабрахабр

0 коментарів

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