Если вы не видите эту картинку, то данные вашей учетной записи 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:// тоже работает, но только из адресной строки, как и в Firefox (но в нем, наоборот, работает только \\, но не file://). Загрузить что-либо с SMB картинкой или при нажатии на ссылку не получится. Так как Chrome и Firefox гораздо популярней Internet Explorer, придется применять социальную инженерию.
Можно воровать аккаунты себе во благо. Некоторые VPN-провайдеры используют одинаковые логины и пароли как для входа в аккаунт, так и для VPN-аутентификации. Принадлежность аккаунта к тому или иному сервису можно определить по IP-адресу входящего подключения пользователя. А если вам достался Microsoft Account, и вы нашли пароль из хеша, то поздравляю — у вас есть доступ к файлам в облаке OneDrive, почте Outlook, аккаунту Skype, если он привязан к Microsoft-аккаунту, и еще куче всего.
Разумеется, старые известные атаки вроде SMB Relay тоже продолжают работать.
Как защититься?
Не стоит думать, что вы в полной безопасности, если не пользуетесь Internet Explorer и не открываете вручную ссылки со схемой file://. Достаточно установить не слишком надежное приложение, которое попытается загрузить какие-то данные с SMB-сервера через штатные функции Windows API, например, URLDownloadToFile(). Таким образом приложение, у которого нет привилегий на получение пароля вашей учетной записи, украдет его через интернет.Если вам не нужен доступ к SMB-ресурсам в интернете, надежнее всего стандартным брандмауэром Windows ограничить доступ к 445, 137 и 139 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
Некоторые провайдеры, например Ростелеком, блокируют доступ по этим портам в своих сетях, что довольно мило с их стороны.
UPD: в комментариях navion и dartraiden подсказывают правильный способ:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0]
"RestrictReceivingNTLMTraffic"=dword:00000002
"RestrictSendingNTLMTraffic"=dword:00000002Заключение
Я добавил возможность проверить, касается ли вас эта проблема, в WITCH?. Попробуйте открыть ее через Internet Explorer или Edge, и если ваш хеш утекает в интернет, WITCH? попробует подобрать пароль, используя небольшой словарь, и покажет вам его. Если перед заходом подключитесь к VPN, то WITCH? также покажет данные вашего VPN-аккаунта. Если вы читаете эту статью через вышеупомянутые браузеры, то ваш хеш уже у меня :)О проблеме известил некоторых VPN-провайдеров, которые либо заблокировали SMB-порты внутри VPN, либо добавили опцию для локальной блокировки в свое ПО.
Для меня оказалось откровением то, что популярные утилиты — Hashcat (-legacy) и John The Ripper (OpenCL-реализация) — неправильно взламывают NTLMv2-хеши. Просто не могут подобрать пароль, хотя он гарантированно есть в словаре. С oclHashcat и Hashcat 3.0, вроде бы, все в порядке. Остается только догадываться, сколько паролей не было взломано из-за этих ошибок…
Комментарии (175)
Kalter
01.08.2016 17:33+1У меня не воспроизводится. Для логина используется аккаунт Майкрософт.
Скрин
MaximChistov
01.08.2016 17:36пробовали в другой вкладке открыть file://witch.valdikss.org.ru/?
у меня на edge сработалоKalter
01.08.2016 17:41+1Не работает.
Скрин
MaximChistov
01.08.2016 17:45ссылка на файл у меня тоже не открылась, но после этого вкладка с сайтом увидела аккаунт
Funbit
08.08.2016 03:57Подтверждаю, у меня тоже не сработало с аккаунтом MS. Пробовал разные браузеры, с VPN и без. No NTLM hash is leaked.
lafa
01.08.2016 17:36+3Спасибо за статью.
Но я не понял одного момента, вроде в IE, в настройках по умолчанию, автоматический логон разрешен только в Intanet zone.
Т.е. эта атака подействует если пользователь изменил настройки безопасности?
Или я чего-то не понимаю?
ValdikSS
01.08.2016 17:38+20Эта настройка, внезапно, просто игнорируется в библиотеке inetcplc.dll! Она считывается из реестра, но не обрабатывается.
lafa
01.08.2016 17:42Ух ты!!!
Вот за это огромное спасибо!
Правда с другой стороной, когда пытаешься развернуть какой-нибудь web сервис, на который доменный пользователь должен автоматом заходить, то приходится его адрес вносить в Trusted Sites. И только тогда пользователь начнет заходить, до этого у него спрашивает авторизацию.
Вообщем надо мне этот момент поподробней изучить, видимо.
evg_krsk
01.08.2016 17:39В первый момент возникала мысль: а что, ещё не все провайдеры блокируют 445-ый порт?
ValdikSS
01.08.2016 17:45+1Брутилка сломалась, довольствуйтесь пока только хешами.
ValdikSS
01.08.2016 18:46+2Можете использовать https://msleak.perfect-privacy.com/
plan2000
01.08.2016 17:50+1Для меня оказалось откровением то, что популярные утилиты — Hashcat (-legacy) и John The Ripper (OpenCL-реализация) — неправильно взламывают NTLMv2-хеши. Просто не могут подобрать пароль, хотя он гарантированно есть в словаре. С oclHashcat и Hashcat 3.0, вроде бы, все в порядке. Остается только догадываться, сколько паролей не было взломано из-за этих ошибок…
А можно поподробнее?
Intercepter
01.08.2016 17:53+3«Для меня оказалось откровением то, что популярные утилиты — Hashcat (-legacy) и John The Ripper (OpenCL-реализация) — неправильно взламывают NTLMv2-хеши»
Скорее всего некорректно сформирован хеш для брута, сам на этом попадался в jtr. Но если с этим же хешем иные сборки работают правильно, то дело конечно в самих крякерах.ValdikSS
01.08.2016 18:10+2apistoletov@outlook.com::MicrosoftAccount:1122334455667788:9C22646B3139840F7B0F83ED88D0EE5F:01010000000000004013BCA0D0E4D10182D8FAEDA695C1340000000002000A0053004D0042003100320001000A0053004D0042003100320004000A0053004D0042003100320003000A0053004D0042003100320005000A0053004D00420031003200080030003000000000000000010000000020000020B3933DD93DA6CA0E16279689BEEB7BD3F8DB084528F396AA0B9899391BCC310A001000000000000000000000000000000000000900200063006900660073002F00330031002E003200320030002E0035002E00340033000000000000000000
Пароль — 123123qq. Hashcat-legacy не находит. Сейчас поищу еще без пароля, которые john с --format=ntlmv2-opencl не мог сбрутить.plan2000
01.08.2016 20:39которые john с --format=ntlmv2-opencl не мог сбрутить
было бы здоровоValdikSS
01.08.2016 20:42+1valdikss::MicrosoftAccount:1122334455667788:F74ECC1AECC1D113782C823BB330772E:010100000000000039B063751BECD1017BAAF43DFFEEB51D0000000002000E004E004F004D00410054004300480001000A0053004D0042003100320004000A0053004D0042003100320003000A0053004D0042003100320005000A0053004D0042003100320008003000300000000000000001000000001000007A91E6D78F02D98EB60F535074AB74D9FA5E62D85D40CB60DC5510339F9537450A001000000000000000000000000000000000000900340063006900660073002F00770069007400630068002E00760061006C00640069006B00730073002E006F00720067002E00720075000000000000000000
Пароль — 123qq
cc: Intercepterplan2000
02.08.2016 09:55+1Странно, у меня все находится.
$ cat ValdikSS_2.dic
123qq
$ cat ValdikSS_2.pass
valdikss::MicrosoftAccount:1122334455667788:F74ECC1AECC1D113782C823BB330772E:010100000000000039B063751BECD1017BAAF43DFFEEB51D0000000002000E004E004F004D00410054004300480001000A0053004D0042003100320004000A0053004D0042003100320003000A0053004D0042003100320005000A0053004D0042003100320008003000300000000000000001000000001000007A91E6D78F02D98EB60F535074AB74D9FA5E62D85D40CB60DC5510339F9537450A001000000000000000000000000000000000000900340063006900660073002F00770069007400630068002E00760061006C00640069006B00730073002E006F00720067002E00720075000000000000000000
$ ./john --format=ntlmv2-opencl -w=ValdikSS_2.dic -pot=ValdikSS_2.pot ValdikSS_2.pass
Device 1: Tahiti
Loaded 1 password hash (ntlmv2-opencl, NTLMv2 C/R [MD4 HMAC-MD5 OpenCL])
Press 'q' or Ctrl-C to abort, almost any other key for status
123qq (valdikss)
1g 0:00:00:00 DONE (2016-08-02 09:52) 2.857g/s 5.714p/s 5.714c/s 5.714C/s 123qq
Use the "--show" option to display all of the cracked passwords reliably
Session completed
Есть возможность поподробнее описать ситуацию тут? — https://github.com/magnumripper/JohnTheRipper/issues/2194
StasTs
01.08.2016 18:31проксировать запросы от клиента к удаленному серверу и от сервера к клиенту, и успешно на нем аутентифицируетесь!
Правильно ли я понимаю, что это работает только если у клиента разрешен NTLMv1? По умолчанию он запрещен начиная с Win 7, с чем у нас были как-раз проблемы, так как Alfresco очевидно не может поддерживать NTLMv2 pass through authentication :(ValdikSS
01.08.2016 18:32+2Нет, работает и с NTLMv2, но только с отключенной SMB Signature.
kvant21
03.08.2016 08:21А по-моему будет работать и с SMB Signing. SMB Signing должно помогать только от релея SMB -> Rogue SMB -> SMB, а от SMB -> Rogue SMB -> HTTP — не должно, по идее. Там же просто SMB-пакеты подписываются NT-хэшем (условно). Но вообще надо пробовать.
В любом случае, находка с MS Account шикарная, вся кривая попытка MS сделать облачный «домен» из обычного трещит по швам :) Полагаю, есть даже шанс что исправят на сей раз. Облако — это у них сейчас святое.ildarz
03.08.2016 11:27> вся кривая попытка MS сделать облачный «домен» из обычного трещит по швам :)
Не надо таких глупостей писать, построенные на OAuth «облачные домены» сейчас используются более-менее всеми, и то же самое использует облако MS. Вся проблема в том, что MS, в отличие от остальных провайдеров аутентификации, надо тащить груз обратной совместимости с кучей древнего и/или криво написанного софта, отсюда периодически и всплывают косяки.kvant21
03.08.2016 12:51Нет, вся проблема в том что MS встроила облачный аккаунт кривым образом в Windows, и теперь он зачем-то используется для проверки подлинности по SMB, в котором в свою очередь без Кербероса (а его не будет, если это домашний пользователь) без вариантов используется древний NTLM.
MS вместо логичной архитектуры прикрутили облако к Windows всеми костылями, какие были под рукой. Причем в W8 это было бы простительно, но то что в W10 работы над ошибками не случилось — показательно.ildarz
03.08.2016 13:43> Нет, вся проблема в том что MS встроила облачный аккаунт кривым образом в Windows
«Кривое» встраивание — это следствие из того, о чем я вам пишу — нужна обратная совместимость. Если юзер залогинен с аккаунтом MS, он, тем не менее, должен всё ещё быть способен работать внутри рабочей или домашней сети, в том числе иногда и с ресурсами, которые не понимают ничего, кроме NTLM.
Я уверен, что вы, как большой гуру в таких делах, всё сделали бы сразу и без ошибок, но, к сожалению, такие идеальные люди, как вы, не проектируют софт и не пишут код. Поэтому периодически появляются такие ошибки. А также случаются всякие нearthbleed, shellshoсk, дырки в аутентфикации различных сервисов, и т.п. :) А мы с этим живем.
в котором в свою очередь без Кербероса (а его не будет, если это домашний пользователь) без вариантов используется древний NTLM
Тут по соседству в ветке как раз обсуждается PKU2U.
whiplash
01.08.2016 18:44Сначала выдал это:
:1122334455667788:813A2FE0D59A69680908C8E808F49BBF:0101000000000000504BB5280BECD101B87D68927A8E96360000000002000E004E004F004D00410054004300480001000A0053004D0042003100320004000A0053004D0042003100320003000A0053004D0042003100320005000A0053004D0042003100320008003000300000000000000000000000002000005377377153B0C0362E732719935BDA82E8614B42CAE0BB1D711EB51514F93B0A0A001000000000000000000000000000000000000900340063006900660073002F00770069007400630068002E00760061006C00640069006B00730073002E006F00720067002E00720075000000000000000000
Потом no hash is leaked
Неужто такой хэш брутится??
nomoneynohoney
01.08.2016 18:50У вас что-то косячит.
Windows 10/Firefox 47. Пишет:
Скрин
C Edge то же самое, открытие новой вкладки с file:// не помогает…ValdikSS
01.08.2016 19:04+1У вас же прокси, да? С прокси не будет работать.
nomoneynohoney
01.08.2016 19:21+2Нет, я сижу напрямую с IP, выданного провайдером… Только DNS от DNS.Watch. Никаких прокси и средств анонимизации в системе.
Сервис 2ip выдал верный браузер и систему.
Хочу отметить, что ваш сервис раньше выдавал верные данные, т.к. я видел ваш сайт раньше. Но после последнего накопительного обновления теперь некорректно определяет ни браузер ни систему, тот же IPLEAK выдает верные данные. Не знаю, с чем связано, возможно какие-то недокументированные патчи.nomoneynohoney
01.08.2016 19:52+1За что минусуют? Я ниже уточнил, что в Edge также не работает у меня. Пример с Firefox привел в доказательство того, что вне зависимости от браузера неверно определяет систему и текущий браузер. Причём, сижу без каких-либо средств анонимизации.
Не поленился, запустил IE11. Результат вообще огонь:
Заголовок спойлера
SamDark
01.08.2016 18:54+7Можно без фаервола групповыми политиками:
- Network security: Restrict NTLM: Incoming NTLM traffic.
- Network security: Restrict NTLM: Outgoing NTML traffic to remote servers.
MonkAlex
01.08.2016 19:54А можно попроще — как это?
RZK333
01.08.2016 19:55+1RTFM
https://technet.microsoft.com/library/jj852213(v=ws.10).aspx
https://technet.microsoft.com/library/jj852167(v=ws.10).aspxMonkAlex
01.08.2016 20:09+3Вот, за Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options спасибо. А то фиг так поймешь, где оно спрятано.
dartraiden
01.08.2016 21:31+4
dartraiden
01.08.2016 21:38+4Для владельцев домашних редакций Windows (в которых нет оснастки управления групповой политикой):
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0]
"RestrictReceivingNTLMTraffic"=dword:00000002
"RestrictSendingNTLMTraffic"=dword:00000002
Maximenko
02.08.2016 09:59+4Важная ремарка: после этого перестает пускать по RDP.
Не наступите на мои грабли.
LoadRunner
02.08.2016 10:13Проверил: пускает. Windows Server 2012R2.
Maximenko
02.08.2016 10:17У меня на домашней Windows 10 стало выдавать ошибку:
An authentication error has occurred.
The function requested is not supported.
Подключился через PowerShell, удалил эти значения из реестра — RDP заработал.
Видимо здесь срабатывает комбинация факторов.
В любом случае — лучше проверить, чтоб не остаться без рук.
ildarz
02.08.2016 14:43Когда как.
Обращение по RDP к доменному серверу по имени (в том числе с недоменной машины) — не перестаёт, там работает Kerberos.
Обращение по RDP к недоменному серверу, или к любому по IP — перестанет, надо дополнительно включить политику «NTLM: Добавить удаленные серверы в исключения....»
Исключения можно добавить вообще для любых серверов, законно требующих NTLM, не только RDP.
MuratovTM
02.08.2016 15:22Windows 8.1 Проф — перестал запоминать пароль для RDP, после применения локальных политик
centur
03.08.2016 06:15Ага, отваливается в том числе и Azure VM RDP, причем жестко
Сегодня вот отобщался с саппортом который помогал восстановить доступ к машине по RDP. Печально вот так применять реестрик чтобы одну проблему исправить, а вторую, скрытую, добавить.
ildarz
03.08.2016 11:30Именно поэтому надо не тупо копировать найденные на просторах интернета настройки реестра, а сначала понять, что они делают. Там, блин, даже опция предварительного аудита для этого есть. Нет никакой «скрытой проблемы», есть недостаточное понимание вопроса.
centur
03.08.2016 14:33А что они делают — вполне понятно. А вот почему такая комбинация приводит к неработоспособным новым RDP ( которые с NLA) — не очень понятно, потому как NTLM это вроде как не очень свежее и очень внутридоменное и локальное, и какого это внутрилокальное влияет на RDP по интернету (куда никакие NTLM вообще ходить не должны ) — не так уж очевидны
ildarz
03.08.2016 17:40Угу. Сначала «всё понятно, ща я настрою!» А потом «ой, всё сломалось». У тех, кому понятно, настройки срабатывают полностью предсказуемым образом (если, конечно, не натыкаешься на баг).
NTLM сам по себе не имеет никакого отношения ни к домену, ни к локальности — это просто встроенный в Windows протокол аутентификации, который изначально был основным, а сейчас по умолчанию используется, когда по какой-то причине недоступен Kerberos (например, при аутентификации на одиноком недоменном хосте). Интернет там или не интернет — разницы никакой.
NLA же вообще не влияет на выбор способа аутентификации, а просто позволяет аутентифицировать пользователя до того, как тот установит RDP-сессию, а не после, как было до появления этого механизма.
Поэтому надо понимать, что полное отключение NTLM отрубит доступ, в частности, ко всем недоменным ресурсам, для которых используется встроенная аутентификация Windows (если не предпринять каких-то мер, чтобы этого избежать).centur
04.08.2016 16:57Ну раз они все такие друг с другом не связанные — почему при выключеном NTLM не пускает на сервер по RDP (сервер не в домене, просто свежая виртуалка в ажуре) пока на сервере включен NLA.
Выключаем NLA на сервере при выключенном NTLM на клиенте — все работает снова, включаем NLA и включаем NTLM — все тоже ок.
Это клево конечно что МС в документации написали что никто ни на что не влияет, но по полученному фидбеку от инженера МС саппорта — они тоже удивились когда мы вместе докопались до реальной причины.
ildarz
04.08.2016 17:51Потому что при выключенном NLA «аутентификация» между клиентом и сервером — не NTLM, а просто plain text, завернутый в RDP (вы устанавливаете RDP-сессию, когда у вас появляется окошко логина — передаете на сервер логин/пароль открытым текстом, а NTLM отрабатывает уже локально на сервере).
Саппорт первой линии — это не всезнающие люди. Обычно они более-менее натасканы на решение часто встречающихся проблем, а запрет NTLM на клиенте к таковой не относится.centur
05.08.2016 06:32Это была вторая линия, первая обычно там мартышки на телефоне, он лазил по логам… Ну или они сильно проапгрейдили саппорт.
Извините но или я не понимаю ваши аргументы или вы не очень четко объясняете, т.к. я все еще не могу понять:
при ВКЛЮЧЕННОМ NLA на сервере в облаке ( не доверенный домен, не локальная сеть, не VPN) почему клиентские настройки NTLM влияют на способность подсоединяться по RDP?
Пока у меня сложилось впечатление что вы утверждаете что настроки NTLM на клиенте НЕ могут влиять на способность ходить по RDP на сервер с NLA. Но тогда ваши утверждения противоречат моей реальности.
ildarz
05.08.2016 12:28+1Это я непонятно объясняю. :)
Когда работает RDP без NLA, там механизма сетевой аутентификации как такового нет. Вы просто открываете RDP-сессию на сервер, и он локально обрабатывает весь ваш ввод. Поэтому NTLM тут не при делах.
Что происходит, когда работает NLA?
Клиент подключается, сервер просит NLA. А дальше задействуется механизм согласования протокола аутентификации между клиентом и сервером (SPNEGO), который и согласовывает протоколы из доступных на сервере и клиенте. Этот протокол не является частью RDP-клиента, он общесистемный. Именно это я имел в виду, говоря «NLA сам по себе не влияет на выбор протокола». Что система предложит, то и будет использоваться. Проблема в том, что по умолчанию система предлагает либо Kerberos, либо NTLM. То есть при недоступности домена остаётся только NTLM, отсюда и грабли.centur
06.08.2016 07:14Теперь понятно, спасибо. Это печалька что при использовании NLA опять надо быть или доменным пользователем или ходить со старым NTLM
ildarz
04.08.2016 18:42Так, я немного уточню предыдущие комментарии, вредно отвечать быстро :)). При установлении RDP-сессии без NLA локально работает, конечно, не NTLM. Что касается NLA — замечание о том, что этот механизм не влияет на выбор способа аутентифкации, следует понимать как «при использовании NLA вы можете использовать любой поддерживаемый клиентский SSP, сама по себе технология не диктует выбор какого-то определенного способа аутентификации».
jabr
03.08.2016 16:15Важная ремарка: после этого перестает пускать по RDP.
Не наступите на мои грабли.
Не только RDP, после этого не работают сетевые ресурсы \\COMPUTERNAME
navion
01.08.2016 21:37+1Через реестр:Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0]
"RestrictSendingNTLMTraffic"=dword:00000002
"RestrictReceivingNTLMTraffic"=dword:00000002centur
03.08.2016 06:32Если наступили на эти грабли и у вас перестал работать RDP к серверам — вот как вычистить эти эээ "настройки безопасности" через PowerShell ( выполнять под админом):
# these settings are the conflicting configuration on the client Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -name "RestrictReceivingNTLMTraffic" Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -name "RestrictSendingNTLMTraffic" # Remove these settings to restore NLA support for RDP and working latest RDP to Azure VMs Remove-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -name "RestrictReceivingNTLMTraffic" Remove-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -name "RestrictSendingNTLMTraffic" # Restore these settings to have protection from NTLM hash leak until there will be better ways to prevent the problem #Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -name "RestrictReceivingNTLMTraffic" -value 2 #Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -name "RestrictSendingNTLMTraffic" -value 2 Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -name "RestrictReceivingNTLMTraffic" Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -name "RestrictSendingNTLMTraffic"
hikkivision
01.08.2016 22:07+1Пуск -> Панель управления -> Административное -> Службы -> Модуль поддержки NetBIOS через TCP/IP -> Свойство -> Нажать стоп и сменить тип запуска на «Отключена»
jabr
03.08.2016 17:25В этом случае ресурсы локальной сети также не работают,
аналогично этому: https://habrahabr.ru/post/306810/#comment_9729830hikkivision
03.08.2016 17:48Ну или шашечки или ехать, самый быстрый и простой для рядовых юзеров способ.
whiplash
01.08.2016 18:58-8Кстати, у меня Руслан Карманов ответил в комментах.
"> Итак, мы выяснили, что любой, кто попытается открыть какой-то файл или директорию с нашего SMB-сервера из-под Windows, автоматически отправит свои данные либо локального аккаунта, либо аккаунта Microsoft, либо логин и хеш пароля от VPN. Что же мы можем с этим сделать?
Ничего, потому что это дефолтное поведение дефолтных настроек NT 6.0.
Известно это 10 лет, и лечится настройками NTLMv2. EPA, в частности.
http://www.atraining.ru/lm-ntlm-ntlmv2-armoring/
Проверено с 5 серверов и домашней машины — ничего оный тест не видит, ничего ему не отправляется.
Ломать дефолтные настройки винды, которые сделаны для совместимости — удобно и приятно, я понимаю.
Просто реальность такова, что это не дыра — это личный уровень компетентности автора.
Примерно поэтому мы курсы дописываем по материалу сами, а не стандартные Microsoft'овские про Next-next-finish читаем. Потому что натаскивание на «как можно быстрее деплоить дефолтные конфиги» приводит к таким вот постам.
СЕНСАЦИЯ! ВЕНДА ВЗЛОМАНА ПОЛНОСТЬЮ! ПАРОЛЬ МОЖНО ПОДОБРАТЬ ЗА ПОЛСЕКУНДЫ! Ну и так далее. На тему а-ля «по дефолту, оказывается, LM-хэш сохраняется»."ValdikSS
01.08.2016 19:02+8Так, э, никакой сенсации и нет, я знаю, что эта проблема известна еще с 1997. Автор комментария, вероятно, не читал статью.
melt
02.08.2016 12:40Можно по подробней, что именно необходимо настроить из этой статьи? Выполнил почти все, что можно выполнить с локальной машины без Active Directory, но хэш все равно утекает:
1. Отключил хранение хэшей LAN Manager (было и так включено в политиках)
2. Отправка только NTLMv2-ответов с отказом от LM и NTLM
3. Требование NTLMv2 при RPC-запросах (на всякий случай)
4. EPA: HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Control \ LSA \ DWORD-параметр SuppressExtendedProtection 0 и 3 пробовал
5. EPA для SMB: HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ LanmanServer \ Parameters \ DWORD-параметр SmbServerNameHardeningLevel 1 и 2 пробовал
Ничего из этого не помогло против WITCH. Блокировать полностью NTLM трафик пока не готов, как советуют коллеги выше и нижеildarz
02.08.2016 14:37+1Я не вижу, как EPA может спасти от автоматической попытки аутентификации, этот механизм совсем от другого защищает.
>Блокировать полностью NTLM трафик пока не готов, как советуют коллеги выше и ниже
Не надо сразу блокировать. Надо сначала включить аудит и посмотреть, а куда у вас вообще машина по NTLM ходит.
А если вы сами уже точно знаете, куда должна — тогда включаете политику для блокировки и политику для исключений, они там рядышком.
neolink
02.08.2016 19:54можете использовать:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0]
"RestrictReceivingNTLMTraffic"=dword:00000002
"RestrictSendingNTLMTraffic"=dword:00000002
"ClientAllowedNTLMServers"=hex(7):31,00,39,00,32,00,2e,00,31,00,36,00,38,00,2e,\
00,2a,00,00,00,00,00
это оставляет 192.168.* рабочимиjabr
03.08.2016 17:06Не работает:
Windows не может получить доступ к \\COMPUTERNAME
Проверьте правильность написания данного имени. В противном случае возможна проблема с вашей сетью. Для определения и разрешения проблем с сетью щелкните кнопку «Диагностика».
Win10 Pro, 192.168.0.0/24neolink
03.08.2016 19:18к сожалению тут смотрится не айпи, а имя по которому обращаетесь (у меня просто обращение по ip), поэтому тут только добавить все интересующие имена (может даже в таком виде *.office.somedomain) — просто открыть руками реестр и добавить строчки с именами в ClientAllowedNTLMServers
ну либо закрывать фаерволомjabr
04.08.2016 02:00Ок, спасибо. Когда писал ответ что «192.268.*» не работает, поиск в гугле формата «ClientAllowedNTLMServers» был безрезультатный.
Ledzorn
03.08.2016 20:00Подтверждаю, отвалилась Домашняя Группа с цифровой подписью пакетов. Впрочем и без подписи аналогично не работает. Win 7 Ult.
me2you
05.08.2016 12:36Хз, чет не помогло =( Даже с Allow, перестали монтироваться диски через cifs на ubuntu… Стираешь ключи, все работает… Ставишь, диски не монтируются.
creker
01.08.2016 19:08Что-то вообще никак не работает. Ни один из тройки браузеров хэш не показал и все трое отказались переходить на «file://» ссылку. Настройки в десятке все стандартные, в качестве юзера используется учетка МС. Никаких VPN, обычный interz
unbeliever
01.08.2016 19:58+1Под Хромом и под Edge результаты разные (причем противоположно — по версии браузера и ОС) но Edge действительно сдал WindowsID и хеш. Мощная технология!
Roy
01.08.2016 20:07Есть мнение, что локально это блокируется отвязкой CIFS от VPN-интерфейсов использующихся для анонимизации. Если VPN корпоративный, то галку оставить, но блокировать на корп периметре — как для внутренней сети, так и для VPN-клиентов. Что вроде очевидно.
При этом, блокировать tcp/445 — маловато будет.
Занимался давно, могу наврать, но:
1) CIFS умеет работать как по tcp, так и по udp. Соответственно надо фильтровать и udp/445
2) SMB, со всей своей утечкой хешей, бывает (был?) и через NBT. А это уже tcp/139.
ValdikSS
01.08.2016 20:08Есть мнение, что локально это блокируется отвязкой CIFS от VPN-интерфейсов использующихся для анонимизации.
Не работает, я проверил. С OpenVPN работает, т.к. он устанавливает свой драйвер сетевого интерфейса, а вот на VPN-подключениях Windows не работает.
NetBIOS через TCP по умолчанию отключили в каком-то недавнем обновлении.Roy
01.08.2016 20:14О как. А какая винда? На XP проверял когда-то — вообще SMB трафика не было при отвязанном MS-клиенте.
Через DNS правда текло. Но лечилось.
Кстати, через WebDAV еще фильтрацию CIFS обрйти можно.ValdikSS
01.08.2016 20:31Пробовал Windows 7 и 10. Думаю, через WebDAV не будет посылаться хеш в интернет, но нужно попробовать.
keenx
01.08.2016 20:51+1Спасибо! Вы открыли мне глаза на безопасность моего VPN. Сижу в тихом шоке. На Edge через L2TP показало все что нужно.
sumanai
01.08.2016 21:14+1Что я у себя сломал?
Ужасающая истина
alfutur
01.08.2016 22:02Необходимо еще NetBios закрывать. TCP и UDP 137-139 и 445
ValdikSS
01.08.2016 22:03+1NetBIOS через TCP отключили по умолчанию, насколько мне известно, пару месяцев назад.
alfutur
01.08.2016 22:04Для теста виртуалка с Win10 со всеми обновлениями со стандартными настройками. Пока TCP 137-139 не закрыл — хэш утекал.
А если дома не один комп — лучше перестраховаться, тем более, что NetBios в Интернет не нужен
navion
01.08.2016 22:55А с VPN всегда передаёт реквизиты или только с установленной по-умолчанию галкой?
Include Windows logon domain
cyreex
02.08.2016 09:04Стало интересно, спасает ли от данной уязвимости антивирус (у меня установлен Avast Internet Security). Это же вроде как и есть сетевая угроза. Оказалось, что нет. Открыл ссылку в edge и сразу пошел менять пароль на аккаунт.
Kriegen
02.08.2016 09:37От данной уязвимости не защитил даже DrWeb Security Space, что уж говорить про Аваст, у которого защита в разы ниже.
cyreex
02.08.2016 09:46У меня оставался ровно месяц до окончании лицензии Avast. Я решил его снести и протестировать с Kaspersky. Дефолтно он от данной уязвимости не спасает. Помогает активация расширения «Kaspersky Protection» в Chrome + установка режима блокировки запросов сбора данных.
P.S. Думаю, надо дополнить, что Avast IS у меня работал в параноидальном режиме.cyreex
02.08.2016 10:03Я был не прав.
В Chrome увидеть данные учетной записи можно только после посещения данной ссылки через Edge/IE.
Вывод — в данном случае Avast IS и Kaspersky IS одинаково бесполезны.
kvaps
02.08.2016 10:24Я думал они уже давно NTLM выпилили, он уже довольно давно считается устаревшим и небезопасным. Вместо него предлагаяется использовать Kerberos.
А то что настройка игнорируется, вообще "порадовало" — вот это настоящий epic fail!
@ValdikSS, спасибо, читать как всегда очень интересно и познавательно.
NicolasSnake
02.08.2016 11:35+1Простите, но как вы себе представляете применение Kerberos для аутентификации на компьютере, не входящем в домен?
Собственно, вся безопасность Kerberos достигается за счет наличия отдельного доверенного сервера (KDC), который проверяет учетные данные пользователей и, в случае их корректности, предоставляет билеты на доступ к сервисам. И понятно, что если два компьютера не входят в один и тот же домен, то KDC которому могли бы доверять оба этих компьютера, просто напросто не существует.
В общем, Kerberos далеко не панацея и наличие NTLM вполне оправдано, на мой взгляд. Хотя, конечно, с описанным в статье поведением бороться надо. Например, по умолчанию активировав запрет на доступ к удаленным SMB-серверамkvaps
02.08.2016 11:54Благодарю за развернутый ответ! Я просто не думал что NTLM сейчас где-то может использоваться без нормального контроллера домена.
Ведь в этом случае вам придется вручную настраивать учетные записи на компьютерах и синхронизировать пароли между клиентом и сервером, иначе NTLM не заработает.
Насколько мне известно на данный момент для построения сетей без контроллера домена, у Microsoft есть новая фишка, называется она "Домашняя группа". Там используется протокол PKU2U, который, если не ошибаюсь, и использует Kerberos для аутентификации пользователей.
NicolasSnake
02.08.2016 12:15Понятно, что без домена для более или менее крупной организации не обойтись. Но для малого офиса или дома NTML вполне себе вариант.
Да, я в курсе про домашнюю группу, но пользоваться ей, лично мне, было не удобно — слишком много магии. Нигде нет нормального описания как это работает и что делать, когда что-то сломалось. Проще уж одинаковых учеток насоздавать.
Про PKU2U я правда не знал, и нормального описания этого протокола пока не нашел. Буду благодарен за полезные ссылки на эту тему.ildarz
02.08.2016 17:37https://tools.ietf.org/html/draft-zhu-pku2u-09
NicolasSnake
03.08.2016 05:01Не совсем то, что я имел в виду. Хотелось почитать что-нибудь написанное экспертами для не экспертов, ну да ладно.
Сразу хочу сказать, что для досконального изучения документа у меня не хватает ни времени, ни мотивации, ни компетентности. Тем не менее после прочтения некоторые, возможно ошибочные, выводы я сделал.
Во-первых, в документе нигде не говорится про парольную аутентификацию, везде описывается применение сертификатов. Не, PKI — это конечно замечательно, но для SOHO, на мой взгляд, это overkill, а у крупных предприятий для этого есть домен и Kerberos.
Во-вторых, даже если возможность парольной аутентификации есть, то преимуществ перед NTMLv2 я, в данном случае, не вижу, поскольку в качестве KDC предлагается использовать потенциально передоверенного участника взаимодействия, играющего роль сервера. Т.е., в контексте данной статьи, PKU2U не помог бы никак. Все равно на сервер злоумышленника ValdikSS передалась бы некоторая производная от пароля. А имея эту производную и зная алгоритм её получения, можно подобрать пароль атакой по словарю или брутфорсом (ну или обломиться, если пароль достаточно сложный).ildarz
03.08.2016 11:34Все равно на сервер злоумышленника ValdikSS передалась бы некоторая производная от пароля. А имея эту производную и зная алгоритм её получения, можно подобрать пароль атакой по словарю или брутфорсом
Вы только что повергли в прах всю современную криптографию. :)NicolasSnake
03.08.2016 12:19А в чем я не прав? По вашему алгоритм аутентификации без проверки подлинности сервера может быть устойчив против атаки по словарю? Каким образом? Я не иронизирую, к слову, правда интересно.
В том же Kerberos клиент передает, на начальном этапе, на сервер текущее время зашифрованное симметричным алгоритмом, используя в качестве ключа хеш от пароля. Бери и подбирай.ildarz
03.08.2016 13:31Вы раздел Introduction в документе, который я вам дал, прочитали? Третий абзац?
Для начала вам надо компьютер ручками добавить в «домашнюю группу» (или автоматически — в случае использования PKI), после чего используется механизм PKINIT для преаутентификации.NicolasSnake
03.08.2016 14:29+1Прочитал, но видимо невнимательно. И в этом абзаце есть такая фраза: «PKU2U can be used without a PKI by pre-sharing certificates and/or pre-associating name/certificate bindings». Т.е. получается документ парольную аутентификацию не определяет в принципе. А именно она меня интересует, коли уж мы рассматриваем в этой ветке PKU2U, как замену NTLM. Ну да, в 7-ом разделе говорится о том, что «implementers may provide methods for user interaction related to credential selection and acquisition (e.g., name and password/PIN prompts)», но как-то это не очень помогает.
При использовании сертификатов у меня вопросов к протоколу нет — всё логично. Но я не могу понять, как он работает без сертификатов и работает ли вообще. Что происходит при добавлении в домашнюю группу по паролю? Создается новый сертификат? Кто выступает в роли центра сертификации? Почему ему доверяют другие участники группы?
Если вы в теме, напишите, пожалуйста, развернутый комментарий или даже статью. Думаю, многим полезно будет — информации по протоколу и технической информации по домашней группе кот наплакал.ildarz
04.08.2016 17:55Без сертификатов оно не работает. Каждая станция генерит свой сертификат, при создании группы её члены должны обменяться сертификатами, после чего уже спокойно аутентифицируют друг друга. Случайный компьютер в группу сам не добавится — пароль нужен. Такая вот одноранговая PKI, где все сертификаты — корневые, и все члены друг другу доверяют.
На статью у меня материала нет, но исследовать, как оно на самом деле в текущей реализации функционирует — мысль интересная. :)NicolasSnake
05.08.2016 04:38Спасибо. В целом да, протокол довольно интересный. Особенно, перспективным мне кажется его применение совместно с онлайн-аккаунтами Microsoft. Т.е. сертификаты генерируются и хранятся на серверах Microsoft, и могут быть запрошены для проверки подлинности пользователя.
В принципе, в Windows 10 есть возможность дать доступ пользователю к компьютеру по имени его (пользователя) учетной записи Microsoft. Думаю, при этом используется механизм схожий с описанным выше. Но будет ли при этом доступ по SMB, я пока не проверял.
Но вообще на замену NTLM PKU2U не тянет, хотя бы потому, что все сценарии использования NTLM он не покрывает.
ctapnep
02.08.2016 17:47и куда девать эту домашнюю группу дома, связывая 2 виндовых лаптопа, одну самбу на линуксе и один nas на непонятно чем (скорее всего какой-то линукс)?
kvaps
02.08.2016 18:20Согласен, свободных реализаций к сожалению пока нет. Но для таких вот случаев я бы сделал галочку в венде как с клиентом Telnet.
Если вы Ъ-админ, вы конечно можете поднять свой контроллер домена на nas, но этот вариант к сожалению не всем подходит...ctapnep
02.08.2016 18:31ну тут вопрос не в том, что я как Ъ-админ могу сделать. У меня и порты закрыть проблемы нет. Тут скорее просто ответ на «не думал что NTLM сейчас где-то может использоваться». Простых NAS-ов сейчас как собак нерезаных (и очень мало кто из них не только свой домен могут держать, они не все в существующий умеют входить). И люди ими активно пользуются. И хотят, чтоб оно работало «искаропки». Поэтому любые лишние галочки — это будет уже большое no-no.
Как по мне, единственное рабочее решение — это таки провайдерам перекрывать порты. Причем вплоть до на уровне закона. Кому таки очень надо через Интернет ползать на SMB-ресурсы пускай городит VPN. И это по-любому правильнее.kvaps
02.08.2016 19:07+1Как по мне это решение совсем неправильное. Провайдера совсем не должно беспокоить какие порты у меня открыты и для чего. Максимум, как опция у провайдера (у билайна такая есть).
Правильное решение это если Microsoft выпустят патч который разрешает использование NTLM по умолчанию только для локальных подключений.ctapnep
02.08.2016 19:14тоже вариант. геморно для контор у которых сервера не в «локальной» сети. особенно если в конторе разрешается и активно используется политика работы «гостевых» компов. У меня так, например. Каждому юзеру, пришедшему со своим лаптопом объяснять почему он не может зайти на корпоративный сервер — это много лишней головной боли. Но тут можно сказать, что нечего плакаться, работа такая.
kvaps
02.08.2016 19:40Почему не смогут? — смогут, просто им свой логин и пароль нужно будет ввести вручную при первом подключении, там и галочка есть "сохранить пароль" и "подключаться автоматически"
Вот уж не поверю что вы на своем сервере создаете такие же учетки как у пользователя на лаптопе, только ради того что бы автоматический вход работал...ctapnep
02.08.2016 20:04или я чего-то не понимаю, или запрет NTLM-аутентификации полностью запретит логон. Это не запрет «автоматической посылки имени и пароля залогинившегося юзера», это запрет аутентификации вообще.
Вот патч, который таки запретит посылку имени и пароля автоматом — это да, решило-бы проблему.
P.S. я не создаю на сервере учетки, совпадающие с юзеровскими учетками на их домашних лаптопах. А вот они таки да, создают локальные аккаунты, совпадающие с их рабочим аккаутом, дабы иметь прозрачный доступ к ресурсам. Но это действительно, уже совсем другая проблема.
nikitasius
02.08.2016 10:24У меня английская Win10Home (Version 10.0.10586) с прокатанным по ней DWS, учетка MS не используется. Просто файл не открывается.
Вообще не понимаю людей, кто ставит ванильную винду и к тому же с аккаунтом от мелкософта.
картинки
Файлволл ничего не блочит
telnet 31.220.5.43 445— работаетnikitasius
02.08.2016 10:31Ну и второй тест
так же по нулям
navion
02.08.2016 11:00У меня из трёх провайдеров доступ к 445 порту был лишь через одного. Ещё проверьте SMB 1.0, её может не быть по-умолчанию в десятке.
ctapnep
02.08.2016 17:50после запроса файла ( file://… ) обновить страничку http://witch.valdikss.org.ru пробовали?
Ghost_Russia
02.08.2016 16:01Некоторые провайдеры, например Ростелеком, блокируют доступ по этим портам в своих сетях, что довольно мило с их стороны.
Боюсь что это не так…
malefistofel
02.08.2016 16:01Уже на хакере написали)
Кстати, requestPolicy заблокировал 1 картинку… интересно насколько хорошо он ее не пропустил?
enamchuk
02.08.2016 17:05Провайдер Tomtel блокирует все порты «сетевого окружения». Открывает только при запросе у администратора, причём у меня спросили, достаточно понимаю ли я понимаю опасность данного действия :) А вот «Томика» не блокирует никак.
Namynnuz
02.08.2016 20:06Вообще, чем бо?льшая начнётся шумиха и истерия, тем лучше. То, что IT-специалисты знают об этом с 97го года, ни о чём руководству не скажет. Нужно, чтобы хотя бы десять англоязычных бытовых СМИ растрезвонили на бытовом уровне, сдобрив страшными словечками не к месту, смысла которых они не понимают. Тогда на это очень быстро и как следует отреагируют.
ValdikSS
03.08.2016 15:42+4Оказалось, что в Firefox тоже SMB работает, но через \\, а не через file://. Дополнил статью.
MRad
04.08.2016 14:59-2Здравствуйте, Влад. Зарегистрировалась, чтобы написать вам. Я не знаю, можно ли писать сообщения лично, поэтому оставляю свой комментарий здесь(он не по теме поста). Я хотела бы узнать, Влад Щукин на ЖЖ и вы — это один и тот же человек? Надеюсь на ваш ответ)
Kremnik
05.08.2016 04:11+3Просто на всякий случай распишу, как читать полученные хеши и как получать из них свои пароли (чтобы проверить, например, проверить правильность работы). Распишу потому, что сам с протоколом NTLMv2 знаком не был и пришлось разбираться, как проверить, что полученный хеш содержит пароль от моего аккаунта.
Для примера рассмотрим хеш, который приводит автор статьи в одном из комментариев. Выглядит хеш следующим образом:
valdikss::MicrosoftAccount:1122334455667788:F74ECC1AECC1D113782C823BB330772E:010100000000000039B063751BECD1017BAAF43DFFEEB51D0000000002000E004E004F004D00410054004300480001000A0053004D0042003100320004000A0053004D0042003100320003000A0053004D0042003100320005000A0053004D0042003100320008003000300000000000000001000000001000007A91E6D78F02D98EB60F535074AB74D9FA5E62D85D40CB60DC5510339F9537450A001000000000000000000000000000000000000900340063006900660073002F00770069007400630068002E00760061006C00640069006B00730073002E006F00720067002E00720075000000000000000000
Когда я впервые увидел такой-же хеш для своего аккаунта, моей первой мыслью было: "ну и где тут именно хеш моего пароля?", потому что для меня хеширование и его результат представлялось как что-то типа md5("password") = abc34.......gb. А тут столько данных.
Итак. В протоколе NTLMv2 используется хеширование, которое в качестве входных данных использует не только сам пароль, но и имя аккаунта, имя домена, в котором аккаунт находится, а также (далее подробнее)server challenge (SC)иclient challenge (CC).
ЗначенияSCиCCиспользуются в качестве дополнительных данных, передаваемых сервером клиенту (SC) и клиентом серверу (CC). При этомSCформируется сервером независимо ни от чего, а вотCCформируется на основе множества данных, генерируемых самим клиентом.
Формат, в котором представлен полный хэш (длиннющая строка выше) расшифровывается следующим образом:
AccountName::DomainName:SC:HASH:CC
1) AccountName — имя аккаунта. Тут всё понятно. В данном случае — valdikss. Может быть и просто именем, может быть и в виде адреса электронной почты — apistoletov@outlook.com.
2) DomainName — имя домена. Если вы не находитесь в домене (т. е. если у вас не серверная ОС), то по-умолчанию будет MicrosoftAccount.
3) SC — Server challenge. Строка длиною в 8 байт, сгенерированная сервером случайным образом. Отправляется сервером клиенту в качестве ответа на запрос авторизации. В данном случае: 1122334455667788
4) HASH — итоговый хеш. Тот самый хеш, который мы хотим проверить (ну или сбрутфорсить, если заранее не знаем пароля). В данном случае — F74ECC1AECC1D113782C823BB330772E.
5) CC — Client challenge. Огромная строка, которая по-другому называется blob (в некоторых статьях указывается название CC, а в некоторых blob, при этом CC называется другая строка, входящая в blob). CC формируется клиентом из множества данных и имеет следующую структуру:
НазваниеРазмер (байты)Значение из примера
Постоянное значение, открывает начало blob-строки4`01010000`
Постоянное значение, зачем оно нужно, неизвестно4`00000000`
Timestamp8`39B063751BECD101`
Сlient challenge (его ещё называют Client nonce)8`7BAAF43DFFEEB51D`
Постоянное значение, назначение неизвестно4`00000000`
Target information block. Набор значений, включающих имена NetBios в кодировке UTF-16LEМеняющаяся`02000E004E004F004D00410054004300480001000A0053004D0042003100320004000A0053004D0042003100320003000A0053004D0042003100320005000A0053004D0042003100320008003000300000000000000001000000001000007A91E6D78F02D98EB60F535074AB74D9FA5E62D85D40CB60DC5510339F9537450A001000000000000000000000000000000000000900340063006900660073002F00770069007400630068002E00760061006C00640069006B00730073002E006F00720067002E007200750000000000`
Постоянное значение, назначение опять неизвестно4`00000000`
Чуть более подробно рассмотрим структуру поля Target information block:
НазваниеРазмер (байты)Значение из примера
Тип данных, хранящихся в этом блоке (`0x0000` — конец блока
`0x0100` — имя сервера
`0x0200` — имя домена
`0x0300` — полное DNS-имя сервера (maps.yandex.ru)
`0x0400` — DNS-имя сервера (yandex.ru)2`0200` (в нашем случае должно быть имя домена)
Длина значения в байтах2`0E00`
Значение в кодировке UTF-16LEМеняющаяся длина (указана в предыдущем поле)`4E004F004D00410054004300480001000A0053004D0042003100320004000A0053004D0042003100320003000A0053004D0042003100320005000A0053004D0042003100320008003000300000000000000001000000001000007A91E6D78F02D98EB60F535074AB74D9FA5E62D85D40CB60DC5510339F9537450A001000000000000000000000000000000000000900340063006900660073002F00770069007400630068002E00760061006C00640069006B00730073002E006F00720067002E007200750000000000`
В данном случае значение поля "Значение" при переводе в символы unicode даёт следующее:
NOMATCH SMB12 SMB12 SMB12 SMB1200?i???????????????? 4cifs/witch.valdikss.org.ru
И мне это, честно говоря, не очень пока понятно.
Так, окей, со структурой хеша разобрались. Теперь, как же нам получить этот самый хеш, зная пароль? В протоколе NTLMv2 алгоритм получения хеша следующий:
- Преобразуем пароль в последовательность байт юникод-кодировки UTF-16LE (именно LE!).
- Полученную последовательность хешируем алгоритмом md4.
- Имя пользователя переводим в верхний регистр. Объединяем его в одну строку с именем домена. Полученную строку преобразуем в последовательность байт UTF-16LE. Полученную последовательность хешируем алгоритмом HMAC-md5, используя значение из шага 2 в качестве ключа.
- Объединяем в одну строку SC и CC (blob) и хешируем полученную строку (преобразовывать в UTF-16LE не надо, т.к. эти две строки и так уже представлены в шестнадцатеричном виде) алгоритмом HMAC-md5, используя значение из шага 3 в качестве ключа.
Всё, результат из шага 4 и есть искомый хеш.
Далее представляю код на php, реализующий данный алгоритм:
<?php function GenerateNTLMv2($password, $account, $domain, $server_challenge, $blob) { $unicode_password= iconv ( 'UTF-8', 'UTF-16LE', $password ); $NTLM_Key = mhash ( MHASH_MD4, $unicode_password); $NTLM_Hash = mhash ( MHASH_MD5, iconv ( 'UTF-8', 'UTF-16LE', strtoupper ( $account ) . $domain ), $NTLM_Key ); $NTLM_Chal_Hash = mhash ( MHASH_MD5, pack ( "H*", $server_challenge . $blob ), $NTLM_Hash ); return strtoupper ( bin2hex ( $NTLM_Chal_Hash ) ); } $password = '123qq'; $blob = '010100000000000039B063751BECD1017BAAF43DFFEEB51D0000000002000E004E004F004D00410054004300480001000A0053004D0042003100320004000A0053004D0042003100320003000A0053004D0042003100320005000A0053004D0042003100320008003000300000000000000001000000001000007A91E6D78F02D98EB60F535074AB74D9FA5E62D85D40CB60DC5510339F9537450A001000000000000000000000000000000000000900340063006900660073002F00770069007400630068002E00760061006C00640069006B00730073002E006F00720067002E00720075000000000000000000'; $server_challenge = '1122334455667788'; $domain = 'MicrosoftAccount'; $account = 'valdikss'; echo GenerateNTLMv2($password, $account, $domain, $server_challenge, $blob); ?>
Выполнить код в песочнице
Выполнив данных код, получим значение:
F74ECC1AECC1D113782C823BB330772E
что и равняется нашему полю HASH из полученного общего хеша (AccountName::DomainName:SC:HASH:CC).
Taras_Serevann
Деанонимизируем пользователей Windows. Снова.
il--ya
Это негуманно! Никто не может быть
осуждёндеанонимизирован повторно за одно и то же преступление!