Давным-давно, когда компьютеры были одноядерными и прекрасно работали с 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-сервера на страницу сайта, или отправить вам письмо, которое достаточно будет просто открыть, и — бум! — данные вашей учетной записи в руках злоумышленника. До недавнего времени считалось, что ничего особо страшного от того, что кто-то узнает имя вашей учетной записи и хеш пароля домашнего компьютера не произойдет (если это не направленная атака), т.к. в имени зачастую написана ерунда, пароль часто не ставят, а если он и установлен, вряд ли его можно использовать во вред.
[ad name=»Responbl»]
Ситуация кардинально меняется в случае корпоративного компьютера, который введен в домен. Из названия домена обычно несложно понять, к какой организации относится учетная запись, а дальше, в случае успешного подбора пароля, можно попробовать аутентифицироваться на корпоративных ресурсах, доступных из интернета (почта, 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-компьютерах, многие их них по умолчанию аутентифицируются с текущей учетной записью. Так мы можем узнать имя компьютера, имя пользователя и хеш пароля машины, с которой нас сканируют.
[ad name=»Responbl»]
Весело, но малорезультативно, ведь что-то вменяемое в имени пользователя пишут не так уж и часто, MS-аккаунты на сканерах практически не используют, а с локальной учетной записью доступ вряд ли куда-то можно получить. Для сбора хешей проще всего использовать Responder, я добавил в него настройку, чтобы можно было собирать несколько хешей, если таковые имеются, манипулируя NetBIOS-именем (CaptureMultipleCredentials = On в конфигурационном файле).
Эксплуатация с целью деанонимизации — поинтересней. Учетка будет отправляться со страниц сайта, если жертва использует Internet Explorer, или при клике внутри письма, в случае с Outlook. Почти все веб-интерфейсы почтовых служб фильтруют картинки со схемой file:// при выводе письма (схема file:// является аналогом схемы ), но не Яндекс, который не считает это своей уязвимостью (что, в общем-то, корректно). Деанонимизация с использованием почты более опасна, т.к. дает связь не только IP-адреса с аккаунтом Windows, но и с почтой.
В Chrome схема file:// тоже работает, но только из адресной строки. Загрузить что-либо с SMB картинкой или при нажатии на ссылку не получится. Так как Chrome гораздо популярней Internet Explorer, придется применять социальную инженерию.
Можно воровать аккаунты себе во благо. Некоторые VPN-провайдеры используют одинаковые логины и пароли как для входа в аккаунт, так и для VPN-аутентификации. Принадлежность аккаунта к тому или иному сервису можно определить по IP-адресу входящего подключения пользователя. А если вам достался Microsoft Account, и вы нашли пароль из хеша, то поздравляю — у вас есть доступ к файлам в облаке OneDrive, почте Outlook, аккаунту Skype, если он привязан к Microsoft-аккаунту, и еще куче всего.
Разумеется, старые известные атаки вроде SMB Relay тоже продолжают работать.
Как защититься от раскрытия IP windows
Не стоит думать, что вы в полной безопасности, если не пользуетесь 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 в своих сетях, что довольно мило с их стороны.
Заключение
Я добавил возможность проверить, касается ли вас эта проблема, в ＷＩＴＣＨ？. Попробуйте открыть ее через Internet Explorer или Edge, и если ваш хеш утекает в интернет, ＷＩＴＣＨ？ попробует подобрать пароль, используя небольшой словарь, и покажет вам его. Если перед заходом подключитесь к VPN, то ＷＩＴＣＨ？ также покажет данные вашего VPN-аккаунта. Если вы читаете эту статью через вышеупомянутые браузеры, то ваш хеш уже у меня 🙂
[ad name=»Responbl»]
О проблеме известил некоторых VPN-провайдеров, которые либо заблокировали порт 445 внутри VPN, либо добавили опцию для локальной блокировки в свое ПО.
Для меня оказалось откровением то, что популярные утилиты — Hashcat (-legacy) и John The Ripper (OpenCL-реализация) — неправильно взламывают NTLMv2-хеши. Просто не могут подобрать пароль, хотя он гарантированно есть в словаре. С oclHashcat и Hashcat 3.0, вроде бы, все в порядке. Остается только догадываться, сколько паролей не было взломано из-за этих ошибок…
