Comments 194
Деанонимизируем пользователей Windows. Снова.
У меня не воспроизводится. Для логина используется аккаунт Майкрософт.
Скрин
А в MS зарепортили?
Спасибо за статью.
Но я не понял одного момента, вроде в IE, в настройках по умолчанию, автоматический логон разрешен только в Intanet zone.
Т.е. эта атака подействует если пользователь изменил настройки безопасности?
Или я чего-то не понимаю?
Но я не понял одного момента, вроде в IE, в настройках по умолчанию, автоматический логон разрешен только в Intanet zone.
Т.е. эта атака подействует если пользователь изменил настройки безопасности?
Или я чего-то не понимаю?
Эта настройка, внезапно, просто игнорируется в библиотеке inetcplc.dll! Она считывается из реестра, но не обрабатывается.
Ух ты!!!
Вот за это огромное спасибо!
Правда с другой стороной, когда пытаешься развернуть какой-нибудь web сервис, на который доменный пользователь должен автоматом заходить, то приходится его адрес вносить в Trusted Sites. И только тогда пользователь начнет заходить, до этого у него спрашивает авторизацию.
Вообщем надо мне этот момент поподробней изучить, видимо.
Вот за это огромное спасибо!
Правда с другой стороной, когда пытаешься развернуть какой-нибудь web сервис, на который доменный пользователь должен автоматом заходить, то приходится его адрес вносить в Trusted Sites. И только тогда пользователь начнет заходить, до этого у него спрашивает авторизацию.
Вообщем надо мне этот момент поподробней изучить, видимо.
Она не игнорируется, просто не имеет никакого отношения к SMB.
В первый момент возникала мысль: а что, ещё не все провайдеры блокируют 445-ый порт?
Брутилка сломалась, довольствуйтесь пока только хешами.
Можете использовать https://msleak.perfect-privacy.com/
Для меня оказалось откровением то, что популярные утилиты — Hashcat (-legacy) и John The Ripper (OpenCL-реализация) — неправильно взламывают NTLMv2-хеши. Просто не могут подобрать пароль, хотя он гарантированно есть в словаре. С oclHashcat и Hashcat 3.0, вроде бы, все в порядке. Остается только догадываться, сколько паролей не было взломано из-за этих ошибок…
А можно поподробнее?
«Для меня оказалось откровением то, что популярные утилиты — Hashcat (-legacy) и John The Ripper (OpenCL-реализация) — неправильно взламывают NTLMv2-хеши»
Скорее всего некорректно сформирован хеш для брута, сам на этом попадался в jtr. Но если с этим же хешем иные сборки работают правильно, то дело конечно в самих крякерах.
Скорее всего некорректно сформирован хеш для брута, сам на этом попадался в jtr. Но если с этим же хешем иные сборки работают правильно, то дело конечно в самих крякерах.
apistoletov@outlook.com::MicrosoftAccount:1122334455667788:9C22646B3139840F7B0F83ED88D0EE5F:01010000000000004013BCA0D0E4D10182D8FAEDA695C1340000000002000A0053004D0042003100320001000A0053004D0042003100320004000A0053004D0042003100320003000A0053004D0042003100320005000A0053004D00420031003200080030003000000000000000010000000020000020B3933DD93DA6CA0E16279689BEEB7BD3F8DB084528F396AA0B9899391BCC310A001000000000000000000000000000000000000900200063006900660073002F00330031002E003200320030002E0035002E00340033000000000000000000Пароль — 123123qq. Hashcat-legacy не находит. Сейчас поищу еще без пароля, которые john с --format=ntlmv2-opencl не мог сбрутить.
которые john с --format=ntlmv2-opencl не мог сбрутить
было бы здорово
valdikss::MicrosoftAccount:1122334455667788:F74ECC1AECC1D113782C823BB330772E:010100000000000039B063751BECD1017BAAF43DFFEEB51D0000000002000E004E004F004D00410054004300480001000A0053004D0042003100320004000A0053004D0042003100320003000A0053004D0042003100320005000A0053004D0042003100320008003000300000000000000001000000001000007A91E6D78F02D98EB60F535074AB74D9FA5E62D85D40CB60DC5510339F9537450A001000000000000000000000000000000000000900340063006900660073002F00770069007400630068002E00760061006C00640069006B00730073002E006F00720067002E00720075000000000000000000Пароль — 123qq
cc: Intercepter
Странно, у меня все находится.
Есть возможность поподробнее описать ситуацию тут? — https://github.com/magnumripper/JohnTheRipper/issues/2194
$ 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
проксировать запросы от клиента к удаленному серверу и от сервера к клиенту, и успешно на нем аутентифицируетесь!
Правильно ли я понимаю, что это работает только если у клиента разрешен NTLMv1? По умолчанию он запрещен начиная с Win 7, с чем у нас были как-раз проблемы, так как Alfresco очевидно не может поддерживать NTLMv2 pass through authentication :(
Нет, работает и с NTLMv2, но только с отключенной SMB Signature.
А по-моему будет работать и с SMB Signing. SMB Signing должно помогать только от релея SMB -> Rogue SMB -> SMB, а от SMB -> Rogue SMB -> HTTP — не должно, по идее. Там же просто SMB-пакеты подписываются NT-хэшем (условно). Но вообще надо пробовать.
В любом случае, находка с MS Account шикарная, вся кривая попытка MS сделать облачный «домен» из обычного трещит по швам :) Полагаю, есть даже шанс что исправят на сей раз. Облако — это у них сейчас святое.
В любом случае, находка с MS Account шикарная, вся кривая попытка MS сделать облачный «домен» из обычного трещит по швам :) Полагаю, есть даже шанс что исправят на сей раз. Облако — это у них сейчас святое.
> вся кривая попытка MS сделать облачный «домен» из обычного трещит по швам :)
Не надо таких глупостей писать, построенные на OAuth «облачные домены» сейчас используются более-менее всеми, и то же самое использует облако MS. Вся проблема в том, что MS, в отличие от остальных провайдеров аутентификации, надо тащить груз обратной совместимости с кучей древнего и/или криво написанного софта, отсюда периодически и всплывают косяки.
Не надо таких глупостей писать, построенные на OAuth «облачные домены» сейчас используются более-менее всеми, и то же самое использует облако MS. Вся проблема в том, что MS, в отличие от остальных провайдеров аутентификации, надо тащить груз обратной совместимости с кучей древнего и/или криво написанного софта, отсюда периодически и всплывают косяки.
Нет, вся проблема в том что MS встроила облачный аккаунт кривым образом в Windows, и теперь он зачем-то используется для проверки подлинности по SMB, в котором в свою очередь без Кербероса (а его не будет, если это домашний пользователь) без вариантов используется древний NTLM.
MS вместо логичной архитектуры прикрутили облако к Windows всеми костылями, какие были под рукой. Причем в W8 это было бы простительно, но то что в W10 работы над ошибками не случилось — показательно.
MS вместо логичной архитектуры прикрутили облако к Windows всеми костылями, какие были под рукой. Причем в W8 это было бы простительно, но то что в W10 работы над ошибками не случилось — показательно.
> Нет, вся проблема в том что MS встроила облачный аккаунт кривым образом в Windows
«Кривое» встраивание — это следствие из того, о чем я вам пишу — нужна обратная совместимость. Если юзер залогинен с аккаунтом MS, он, тем не менее, должен всё ещё быть способен работать внутри рабочей или домашней сети, в том числе иногда и с ресурсами, которые не понимают ничего, кроме NTLM.
Я уверен, что вы, как большой гуру в таких делах, всё сделали бы сразу и без ошибок, но, к сожалению, такие идеальные люди, как вы, не проектируют софт и не пишут код. Поэтому периодически появляются такие ошибки. А также случаются всякие нearthbleed, shellshoсk, дырки в аутентфикации различных сервисов, и т.п. :) А мы с этим живем.
Тут по соседству в ветке как раз обсуждается PKU2U.
«Кривое» встраивание — это следствие из того, о чем я вам пишу — нужна обратная совместимость. Если юзер залогинен с аккаунтом MS, он, тем не менее, должен всё ещё быть способен работать внутри рабочей или домашней сети, в том числе иногда и с ресурсами, которые не понимают ничего, кроме NTLM.
Я уверен, что вы, как большой гуру в таких делах, всё сделали бы сразу и без ошибок, но, к сожалению, такие идеальные люди, как вы, не проектируют софт и не пишут код. Поэтому периодически появляются такие ошибки. А также случаются всякие нearthbleed, shellshoсk, дырки в аутентфикации различных сервисов, и т.п. :) А мы с этим живем.
в котором в свою очередь без Кербероса (а его не будет, если это домашний пользователь) без вариантов используется древний NTLM
Тут по соседству в ветке как раз обсуждается PKU2U.
No NTLM hash is leaked. Edge.
Сначала выдал это:
:1122334455667788:813A2FE0D59A69680908C8E808F49BBF:0101000000000000504BB5280BECD101B87D68927A8E96360000000002000E004E004F004D00410054004300480001000A0053004D0042003100320004000A0053004D0042003100320003000A0053004D0042003100320005000A0053004D0042003100320008003000300000000000000000000000002000005377377153B0C0362E732719935BDA82E8614B42CAE0BB1D711EB51514F93B0A0A001000000000000000000000000000000000000900340063006900660073002F00770069007400630068002E00760061006C00640069006B00730073002E006F00720067002E00720075000000000000000000
Потом no hash is leaked
Неужто такой хэш брутится??
:1122334455667788:813A2FE0D59A69680908C8E808F49BBF:0101000000000000504BB5280BECD101B87D68927A8E96360000000002000E004E004F004D00410054004300480001000A0053004D0042003100320004000A0053004D0042003100320003000A0053004D0042003100320005000A0053004D0042003100320008003000300000000000000000000000002000005377377153B0C0362E732719935BDA82E8614B42CAE0BB1D711EB51514F93B0A0A001000000000000000000000000000000000000900340063006900660073002F00770069007400630068002E00760061006C00640069006B00730073002E006F00720067002E00720075000000000000000000
Потом no hash is leaked
Неужто такой хэш брутится??
У вас что-то косячит.
Windows 10/Firefox 47. Пишет:
Windows 10/Firefox 47. Пишет:
Скрин
C Edge то же самое, открытие новой вкладки с file:// не помогает…
C Edge то же самое, открытие новой вкладки с file:// не помогает…
В Firefox и не должно работать, он не поддерживает SMB.
У вас же прокси, да? С прокси не будет работать.
Нет, я сижу напрямую с IP, выданного провайдером… Только DNS от DNS.Watch. Никаких прокси и средств анонимизации в системе.
Сервис 2ip выдал верный браузер и систему.
Хочу отметить, что ваш сервис раньше выдавал верные данные, т.к. я видел ваш сайт раньше. Но после последнего накопительного обновления теперь некорректно определяет ни браузер ни систему, тот же IPLEAK выдает верные данные. Не знаю, с чем связано, возможно какие-то недокументированные патчи.
Сервис 2ip выдал верный браузер и систему.
Хочу отметить, что ваш сервис раньше выдавал верные данные, т.к. я видел ваш сайт раньше. Но после последнего накопительного обновления теперь некорректно определяет ни браузер ни систему, тот же IPLEAK выдает верные данные. Не знаю, с чем связано, возможно какие-то недокументированные патчи.
За что минусуют? Я ниже уточнил, что в Edge также не работает у меня. Пример с Firefox привел в доказательство того, что вне зависимости от браузера неверно определяет систему и текущий браузер. Причём, сижу без каких-либо средств анонимизации.
Не поленился, запустил IE11. Результат вообще огонь:
Не поленился, запустил IE11. Результат вообще огонь:
Заголовок спойлера
Можно без фаервола групповыми политиками:
- Network security: Restrict NTLM: Incoming NTLM traffic.
- Network security: Restrict NTLM: Outgoing NTML traffic to remote servers.
Класс, работает без домена?
А можно попроще — как это?
RTFM
https://technet.microsoft.com/library/jj852213(v=ws.10).aspx
https://technet.microsoft.com/library/jj852167(v=ws.10).aspx
https://technet.microsoft.com/library/jj852213(v=ws.10).aspx
https://technet.microsoft.com/library/jj852167(v=ws.10).aspx
Для владельцев домашних редакций Windows (в которых нет оснастки управления групповой политикой):
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0]
"RestrictReceivingNTLMTraffic"=dword:00000002
"RestrictSendingNTLMTraffic"=dword:00000002
Важная ремарка: после этого перестает пускать по RDP.
Не наступите на мои грабли.
Не наступите на мои грабли.
Проверил: пускает. Windows Server 2012R2.
У меня на домашней Windows 10 стало выдавать ошибку:
Подключился через PowerShell, удалил эти значения из реестра — RDP заработал.
Видимо здесь срабатывает комбинация факторов.
В любом случае — лучше проверить, чтоб не остаться без рук.
An authentication error has occurred.
The function requested is not supported.
Подключился через PowerShell, удалил эти значения из реестра — RDP заработал.
Видимо здесь срабатывает комбинация факторов.
В любом случае — лучше проверить, чтоб не остаться без рук.
Не пускает при включенном NLA и не запоминает пароли.
Когда как.
Обращение по RDP к доменному серверу по имени (в том числе с недоменной машины) — не перестаёт, там работает Kerberos.
Обращение по RDP к недоменному серверу, или к любому по IP — перестанет, надо дополнительно включить политику «NTLM: Добавить удаленные серверы в исключения....»
Исключения можно добавить вообще для любых серверов, законно требующих NTLM, не только RDP.
Обращение по RDP к доменному серверу по имени (в том числе с недоменной машины) — не перестаёт, там работает Kerberos.
Обращение по RDP к недоменному серверу, или к любому по IP — перестанет, надо дополнительно включить политику «NTLM: Добавить удаленные серверы в исключения....»
Исключения можно добавить вообще для любых серверов, законно требующих NTLM, не только RDP.
Windows 8.1 Проф — перестал запоминать пароль для RDP, после применения локальных политик
Ага, отваливается в том числе и Azure VM RDP, причем жестко
Сегодня вот отобщался с саппортом который помогал восстановить доступ к машине по RDP. Печально вот так применять реестрик чтобы одну проблему исправить, а вторую, скрытую, добавить.
Именно поэтому надо не тупо копировать найденные на просторах интернета настройки реестра, а сначала понять, что они делают. Там, блин, даже опция предварительного аудита для этого есть. Нет никакой «скрытой проблемы», есть недостаточное понимание вопроса.
А что они делают — вполне понятно. А вот почему такая комбинация приводит к неработоспособным новым RDP ( которые с NLA) — не очень понятно, потому как NTLM это вроде как не очень свежее и очень внутридоменное и локальное, и какого это внутрилокальное влияет на RDP по интернету (куда никакие NTLM вообще ходить не должны ) — не так уж очевидны
Угу. Сначала «всё понятно, ща я настрою!» А потом «ой, всё сломалось». У тех, кому понятно, настройки срабатывают полностью предсказуемым образом (если, конечно, не натыкаешься на баг).
NTLM сам по себе не имеет никакого отношения ни к домену, ни к локальности — это просто встроенный в Windows протокол аутентификации, который изначально был основным, а сейчас по умолчанию используется, когда по какой-то причине недоступен Kerberos (например, при аутентификации на одиноком недоменном хосте). Интернет там или не интернет — разницы никакой.
NLA же вообще не влияет на выбор способа аутентификации, а просто позволяет аутентифицировать пользователя до того, как тот установит RDP-сессию, а не после, как было до появления этого механизма.
Поэтому надо понимать, что полное отключение NTLM отрубит доступ, в частности, ко всем недоменным ресурсам, для которых используется встроенная аутентификация Windows (если не предпринять каких-то мер, чтобы этого избежать).
NTLM сам по себе не имеет никакого отношения ни к домену, ни к локальности — это просто встроенный в Windows протокол аутентификации, который изначально был основным, а сейчас по умолчанию используется, когда по какой-то причине недоступен Kerberos (например, при аутентификации на одиноком недоменном хосте). Интернет там или не интернет — разницы никакой.
NLA же вообще не влияет на выбор способа аутентификации, а просто позволяет аутентифицировать пользователя до того, как тот установит RDP-сессию, а не после, как было до появления этого механизма.
Поэтому надо понимать, что полное отключение NTLM отрубит доступ, в частности, ко всем недоменным ресурсам, для которых используется встроенная аутентификация Windows (если не предпринять каких-то мер, чтобы этого избежать).
Ну раз они все такие друг с другом не связанные — почему при выключеном NTLM не пускает на сервер по RDP (сервер не в домене, просто свежая виртуалка в ажуре) пока на сервере включен NLA.
Выключаем NLA на сервере при выключенном NTLM на клиенте — все работает снова, включаем NLA и включаем NTLM — все тоже ок.
Это клево конечно что МС в документации написали что никто ни на что не влияет, но по полученному фидбеку от инженера МС саппорта — они тоже удивились когда мы вместе докопались до реальной причины.
Потому что при выключенном NLA «аутентификация» между клиентом и сервером — не NTLM, а просто plain text, завернутый в RDP (вы устанавливаете RDP-сессию, когда у вас появляется окошко логина — передаете на сервер логин/пароль открытым текстом, а NTLM отрабатывает уже локально на сервере).
Саппорт первой линии — это не всезнающие люди. Обычно они более-менее натасканы на решение часто встречающихся проблем, а запрет NTLM на клиенте к таковой не относится.
Саппорт первой линии — это не всезнающие люди. Обычно они более-менее натасканы на решение часто встречающихся проблем, а запрет NTLM на клиенте к таковой не относится.
Это была вторая линия, первая обычно там мартышки на телефоне, он лазил по логам… Ну или они сильно проапгрейдили саппорт.
Извините но или я не понимаю ваши аргументы или вы не очень четко объясняете, т.к. я все еще не могу понять:
при ВКЛЮЧЕННОМ NLA на сервере в облаке ( не доверенный домен, не локальная сеть, не VPN) почему клиентские настройки NTLM влияют на способность подсоединяться по RDP?
Пока у меня сложилось впечатление что вы утверждаете что настроки NTLM на клиенте НЕ могут влиять на способность ходить по RDP на сервер с NLA. Но тогда ваши утверждения противоречат моей реальности.
Это я непонятно объясняю. :)
Когда работает RDP без NLA, там механизма сетевой аутентификации как такового нет. Вы просто открываете RDP-сессию на сервер, и он локально обрабатывает весь ваш ввод. Поэтому NTLM тут не при делах.
Что происходит, когда работает NLA?
Клиент подключается, сервер просит NLA. А дальше задействуется механизм согласования протокола аутентификации между клиентом и сервером (SPNEGO), который и согласовывает протоколы из доступных на сервере и клиенте. Этот протокол не является частью RDP-клиента, он общесистемный. Именно это я имел в виду, говоря «NLA сам по себе не влияет на выбор протокола». Что система предложит, то и будет использоваться. Проблема в том, что по умолчанию система предлагает либо Kerberos, либо NTLM. То есть при недоступности домена остаётся только NTLM, отсюда и грабли.
Когда работает RDP без NLA, там механизма сетевой аутентификации как такового нет. Вы просто открываете RDP-сессию на сервер, и он локально обрабатывает весь ваш ввод. Поэтому NTLM тут не при делах.
Что происходит, когда работает NLA?
Клиент подключается, сервер просит NLA. А дальше задействуется механизм согласования протокола аутентификации между клиентом и сервером (SPNEGO), который и согласовывает протоколы из доступных на сервере и клиенте. Этот протокол не является частью RDP-клиента, он общесистемный. Именно это я имел в виду, говоря «NLA сам по себе не влияет на выбор протокола». Что система предложит, то и будет использоваться. Проблема в том, что по умолчанию система предлагает либо Kerberos, либо NTLM. То есть при недоступности домена остаётся только NTLM, отсюда и грабли.
Так, я немного уточню предыдущие комментарии, вредно отвечать быстро :)). При установлении RDP-сессии без NLA локально работает, конечно, не NTLM. Что касается NLA — замечание о том, что этот механизм не влияет на выбор способа аутентифкации, следует понимать как «при использовании NLA вы можете использовать любой поддерживаемый клиентский SSP, сама по себе технология не диктует выбор какого-то определенного способа аутентификации».
Важная ремарка: после этого перестает пускать по RDP.
Не наступите на мои грабли.
Не только RDP, после этого не работают сетевые ресурсы \\COMPUTERNAME
Через реестр:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0]
"RestrictSendingNTLMTraffic"=dword:00000002
"RestrictReceivingNTLMTraffic"=dword:00000002Если наступили на эти грабли и у вас перестал работать 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"
Пуск -> Панель управления -> Административное -> Службы -> Модуль поддержки NetBIOS через TCP/IP -> Свойство -> Нажать стоп и сменить тип запуска на «Отключена»
UFO just landed and posted this here
Кстати, у меня Руслан Карманов ответил в комментах.
"> Итак, мы выяснили, что любой, кто попытается открыть какой-то файл или директорию с нашего SMB-сервера из-под Windows, автоматически отправит свои данные либо локального аккаунта, либо аккаунта Microsoft, либо логин и хеш пароля от VPN. Что же мы можем с этим сделать?
Ничего, потому что это дефолтное поведение дефолтных настроек NT 6.0.
Известно это 10 лет, и лечится настройками NTLMv2. EPA, в частности.
http://www.atraining.ru/lm-ntlm-ntlmv2-armoring/
Проверено с 5 серверов и домашней машины — ничего оный тест не видит, ничего ему не отправляется.
Ломать дефолтные настройки винды, которые сделаны для совместимости — удобно и приятно, я понимаю.
Просто реальность такова, что это не дыра — это личный уровень компетентности автора.
Примерно поэтому мы курсы дописываем по материалу сами, а не стандартные Microsoft'овские про Next-next-finish читаем. Потому что натаскивание на «как можно быстрее деплоить дефолтные конфиги» приводит к таким вот постам.
СЕНСАЦИЯ! ВЕНДА ВЗЛОМАНА ПОЛНОСТЬЮ! ПАРОЛЬ МОЖНО ПОДОБРАТЬ ЗА ПОЛСЕКУНДЫ! Ну и так далее. На тему а-ля «по дефолту, оказывается, LM-хэш сохраняется»."
"> Итак, мы выяснили, что любой, кто попытается открыть какой-то файл или директорию с нашего SMB-сервера из-под Windows, автоматически отправит свои данные либо локального аккаунта, либо аккаунта Microsoft, либо логин и хеш пароля от VPN. Что же мы можем с этим сделать?
Ничего, потому что это дефолтное поведение дефолтных настроек NT 6.0.
Известно это 10 лет, и лечится настройками NTLMv2. EPA, в частности.
http://www.atraining.ru/lm-ntlm-ntlmv2-armoring/
Проверено с 5 серверов и домашней машины — ничего оный тест не видит, ничего ему не отправляется.
Ломать дефолтные настройки винды, которые сделаны для совместимости — удобно и приятно, я понимаю.
Просто реальность такова, что это не дыра — это личный уровень компетентности автора.
Примерно поэтому мы курсы дописываем по материалу сами, а не стандартные Microsoft'овские про Next-next-finish читаем. Потому что натаскивание на «как можно быстрее деплоить дефолтные конфиги» приводит к таким вот постам.
СЕНСАЦИЯ! ВЕНДА ВЗЛОМАНА ПОЛНОСТЬЮ! ПАРОЛЬ МОЖНО ПОДОБРАТЬ ЗА ПОЛСЕКУНДЫ! Ну и так далее. На тему а-ля «по дефолту, оказывается, LM-хэш сохраняется»."
Так, э, никакой сенсации и нет, я знаю, что эта проблема известна еще с 1997. Автор комментария, вероятно, не читал статью.
Остается один вопрос.
Почему поведение винды, по дефолту, практически во всех случаях, это «лечь и раздвинуть ноги»?
Почему поведение винды, по дефолту, практически во всех случаях, это «лечь и раздвинуть ноги»?
Можно по подробней, что именно необходимо настроить из этой статьи? Выполнил почти все, что можно выполнить с локальной машины без 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 трафик пока не готов, как советуют коллеги выше и ниже
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 трафик пока не готов, как советуют коллеги выше и ниже
Я не вижу, как EPA может спасти от автоматической попытки аутентификации, этот механизм совсем от другого защищает.
>Блокировать полностью NTLM трафик пока не готов, как советуют коллеги выше и ниже
Не надо сразу блокировать. Надо сначала включить аудит и посмотреть, а куда у вас вообще машина по NTLM ходит.
А если вы сами уже точно знаете, куда должна — тогда включаете политику для блокировки и политику для исключений, они там рядышком.
>Блокировать полностью NTLM трафик пока не готов, как советуют коллеги выше и ниже
Не надо сразу блокировать. Надо сначала включить аудит и посмотреть, а куда у вас вообще машина по NTLM ходит.
А если вы сами уже точно знаете, куда должна — тогда включаете политику для блокировки и политику для исключений, они там рядышком.
можете использовать:
это оставляет 192.168.* рабочими
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.* рабочими
Спасибо, помогло! Хэш наружу закрыт, внутри всё проходит.
Не работает:
Win10 Pro, 192.168.0.0/24
Windows не может получить доступ к \\COMPUTERNAME
Проверьте правильность написания данного имени. В противном случае возможна проблема с вашей сетью. Для определения и разрешения проблем с сетью щелкните кнопку «Диагностика».
Win10 Pro, 192.168.0.0/24
к сожалению тут смотрится не айпи, а имя по которому обращаетесь (у меня просто обращение по ip), поэтому тут только добавить все интересующие имена (может даже в таком виде *.office.somedomain) — просто открыть руками реестр и добавить строчки с именами в ClientAllowedNTLMServers
ну либо закрывать фаерволом
ну либо закрывать фаерволом
Подтверждаю, отвалилась Домашняя Группа с цифровой подписью пакетов. Впрочем и без подписи аналогично не работает. Win 7 Ult.
Хз, чет не помогло =( Даже с Allow, перестали монтироваться диски через cifs на ubuntu… Стираешь ключи, все работает… Ставишь, диски не монтируются.
Что-то вообще никак не работает. Ни один из тройки браузеров хэш не показал и все трое отказались переходить на «file://» ссылку. Настройки в десятке все стандартные, в качестве юзера используется учетка МС. Никаких VPN, обычный interz
Под Хромом и под Edge результаты разные (причем противоположно — по версии браузера и ОС) но Edge действительно сдал WindowsID и хеш. Мощная технология!
Есть мнение, что локально это блокируется отвязкой CIFS от VPN-интерфейсов использующихся для анонимизации. Если VPN корпоративный, то галку оставить, но блокировать на корп периметре — как для внутренней сети, так и для VPN-клиентов. Что вроде очевидно.
При этом, блокировать tcp/445 — маловато будет.
Занимался давно, могу наврать, но:
1) CIFS умеет работать как по tcp, так и по udp. Соответственно надо фильтровать и udp/445
2) SMB, со всей своей утечкой хешей, бывает (был?) и через NBT. А это уже tcp/139.
При этом, блокировать tcp/445 — маловато будет.
Занимался давно, могу наврать, но:
1) CIFS умеет работать как по tcp, так и по udp. Соответственно надо фильтровать и udp/445
2) SMB, со всей своей утечкой хешей, бывает (был?) и через NBT. А это уже tcp/139.
Есть мнение, что локально это блокируется отвязкой CIFS от VPN-интерфейсов использующихся для анонимизации.Не работает, я проверил. С OpenVPN работает, т.к. он устанавливает свой драйвер сетевого интерфейса, а вот на VPN-подключениях Windows не работает.
NetBIOS через TCP по умолчанию отключили в каком-то недавнем обновлении.
В следующей статье:
Шокирующие новости! Аккаунт ValdikSS на Хабре взломали, сервер использовался для взлома аккаунтов всех посетителей Хабрахабра!
Спасибо! Вы открыли мне глаза на безопасность моего VPN. Сижу в тихом шоке. На Edge через L2TP показало все что нужно.
UFO just landed and posted this here
Это нормально, так и должно быть.
UFO just landed and posted this here
Попробуйте это.
Необходимо еще NetBios закрывать. TCP и UDP 137-139 и 445
NetBIOS через TCP отключили по умолчанию, насколько мне известно, пару месяцев назад.
А с VPN всегда передаёт реквизиты или только с установленной по-умолчанию галкой?
С отрицанием история забавная — на каждом мероприятии у MS рассказывают про более продвинутую атаку на Kerberos, а этой как бы не существует, хотя даже в STIG нет рекомендаций по фильтрации NTLM.
Include Windows logon domain
С отрицанием история забавная — на каждом мероприятии у MS рассказывают про более продвинутую атаку на Kerberos, а этой как бы не существует, хотя даже в STIG нет рекомендаций по фильтрации NTLM.
UFO just landed and posted this here
Стало интересно, спасает ли от данной уязвимости антивирус (у меня установлен Avast Internet Security). Это же вроде как и есть сетевая угроза. Оказалось, что нет. Открыл ссылку в edge и сразу пошел менять пароль на аккаунт.
От данной уязвимости не защитил даже DrWeb Security Space, что уж говорить про Аваст, у которого защита в разы ниже.
У меня оставался ровно месяц до окончании лицензии Avast. Я решил его снести и протестировать с Kaspersky. Дефолтно он от данной уязвимости не спасает. Помогает активация расширения «Kaspersky Protection» в Chrome + установка режима блокировки запросов сбора данных.
P.S. Думаю, надо дополнить, что Avast IS у меня работал в параноидальном режиме.
P.S. Думаю, надо дополнить, что Avast IS у меня работал в параноидальном режиме.
Так это не уязвимость, и не баг — это фича! © Microsoft
))))
))))
Можете код дать сайта, который используется для теста.
Я думал они уже давно NTLM выпилили, он уже довольно давно считается устаревшим и небезопасным. Вместо него предлагаяется использовать Kerberos.
А то что настройка игнорируется, вообще "порадовало" — вот это настоящий epic fail!
@ValdikSS, спасибо, читать как всегда очень интересно и познавательно.
Простите, но как вы себе представляете применение Kerberos для аутентификации на компьютере, не входящем в домен?
Собственно, вся безопасность Kerberos достигается за счет наличия отдельного доверенного сервера (KDC), который проверяет учетные данные пользователей и, в случае их корректности, предоставляет билеты на доступ к сервисам. И понятно, что если два компьютера не входят в один и тот же домен, то KDC которому могли бы доверять оба этих компьютера, просто напросто не существует.
В общем, Kerberos далеко не панацея и наличие NTLM вполне оправдано, на мой взгляд. Хотя, конечно, с описанным в статье поведением бороться надо. Например, по умолчанию активировав запрет на доступ к удаленным SMB-серверам
Собственно, вся безопасность Kerberos достигается за счет наличия отдельного доверенного сервера (KDC), который проверяет учетные данные пользователей и, в случае их корректности, предоставляет билеты на доступ к сервисам. И понятно, что если два компьютера не входят в один и тот же домен, то KDC которому могли бы доверять оба этих компьютера, просто напросто не существует.
В общем, Kerberos далеко не панацея и наличие NTLM вполне оправдано, на мой взгляд. Хотя, конечно, с описанным в статье поведением бороться надо. Например, по умолчанию активировав запрет на доступ к удаленным SMB-серверам
Благодарю за развернутый ответ! Я просто не думал что NTLM сейчас где-то может использоваться без нормального контроллера домена.
Ведь в этом случае вам придется вручную настраивать учетные записи на компьютерах и синхронизировать пароли между клиентом и сервером, иначе NTLM не заработает.
Насколько мне известно на данный момент для построения сетей без контроллера домена, у Microsoft есть новая фишка, называется она "Домашняя группа". Там используется протокол PKU2U, который, если не ошибаюсь, и использует Kerberos для аутентификации пользователей.
Понятно, что без домена для более или менее крупной организации не обойтись. Но для малого офиса или дома NTML вполне себе вариант.
Да, я в курсе про домашнюю группу, но пользоваться ей, лично мне, было не удобно — слишком много магии. Нигде нет нормального описания как это работает и что делать, когда что-то сломалось. Проще уж одинаковых учеток насоздавать.
Про PKU2U я правда не знал, и нормального описания этого протокола пока не нашел. Буду благодарен за полезные ссылки на эту тему.
Да, я в курсе про домашнюю группу, но пользоваться ей, лично мне, было не удобно — слишком много магии. Нигде нет нормального описания как это работает и что делать, когда что-то сломалось. Проще уж одинаковых учеток насоздавать.
Про PKU2U я правда не знал, и нормального описания этого протокола пока не нашел. Буду благодарен за полезные ссылки на эту тему.
https://tools.ietf.org/html/draft-zhu-pku2u-09
Не совсем то, что я имел в виду. Хотелось почитать что-нибудь написанное экспертами для не экспертов, ну да ладно.
Сразу хочу сказать, что для досконального изучения документа у меня не хватает ни времени, ни мотивации, ни компетентности. Тем не менее после прочтения некоторые, возможно ошибочные, выводы я сделал.
Во-первых, в документе нигде не говорится про парольную аутентификацию, везде описывается применение сертификатов. Не, PKI — это конечно замечательно, но для SOHO, на мой взгляд, это overkill, а у крупных предприятий для этого есть домен и Kerberos.
Во-вторых, даже если возможность парольной аутентификации есть, то преимуществ перед NTMLv2 я, в данном случае, не вижу, поскольку в качестве KDC предлагается использовать потенциально передоверенного участника взаимодействия, играющего роль сервера. Т.е., в контексте данной статьи, PKU2U не помог бы никак. Все равно на сервер злоумышленника ValdikSS передалась бы некоторая производная от пароля. А имея эту производную и зная алгоритм её получения, можно подобрать пароль атакой по словарю или брутфорсом (ну или обломиться, если пароль достаточно сложный).
Сразу хочу сказать, что для досконального изучения документа у меня не хватает ни времени, ни мотивации, ни компетентности. Тем не менее после прочтения некоторые, возможно ошибочные, выводы я сделал.
Во-первых, в документе нигде не говорится про парольную аутентификацию, везде описывается применение сертификатов. Не, PKI — это конечно замечательно, но для SOHO, на мой взгляд, это overkill, а у крупных предприятий для этого есть домен и Kerberos.
Во-вторых, даже если возможность парольной аутентификации есть, то преимуществ перед NTMLv2 я, в данном случае, не вижу, поскольку в качестве KDC предлагается использовать потенциально передоверенного участника взаимодействия, играющего роль сервера. Т.е., в контексте данной статьи, PKU2U не помог бы никак. Все равно на сервер злоумышленника ValdikSS передалась бы некоторая производная от пароля. А имея эту производную и зная алгоритм её получения, можно подобрать пароль атакой по словарю или брутфорсом (ну или обломиться, если пароль достаточно сложный).
Все равно на сервер злоумышленника ValdikSS передалась бы некоторая производная от пароля. А имея эту производную и зная алгоритм её получения, можно подобрать пароль атакой по словарю или брутфорсом
Вы только что повергли в прах всю современную криптографию. :)
А в чем я не прав? По вашему алгоритм аутентификации без проверки подлинности сервера может быть устойчив против атаки по словарю? Каким образом? Я не иронизирую, к слову, правда интересно.
В том же Kerberos клиент передает, на начальном этапе, на сервер текущее время зашифрованное симметричным алгоритмом, используя в качестве ключа хеш от пароля. Бери и подбирай.
В том же Kerberos клиент передает, на начальном этапе, на сервер текущее время зашифрованное симметричным алгоритмом, используя в качестве ключа хеш от пароля. Бери и подбирай.
Вы раздел Introduction в документе, который я вам дал, прочитали? Третий абзац?
Для начала вам надо компьютер ручками добавить в «домашнюю группу» (или автоматически — в случае использования PKI), после чего используется механизм PKINIT для преаутентификации.
Для начала вам надо компьютер ручками добавить в «домашнюю группу» (или автоматически — в случае использования PKI), после чего используется механизм PKINIT для преаутентификации.
Прочитал, но видимо невнимательно. И в этом абзаце есть такая фраза: «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)», но как-то это не очень помогает.
При использовании сертификатов у меня вопросов к протоколу нет — всё логично. Но я не могу понять, как он работает без сертификатов и работает ли вообще. Что происходит при добавлении в домашнюю группу по паролю? Создается новый сертификат? Кто выступает в роли центра сертификации? Почему ему доверяют другие участники группы?
Если вы в теме, напишите, пожалуйста, развернутый комментарий или даже статью. Думаю, многим полезно будет — информации по протоколу и технической информации по домашней группе кот наплакал.
При использовании сертификатов у меня вопросов к протоколу нет — всё логично. Но я не могу понять, как он работает без сертификатов и работает ли вообще. Что происходит при добавлении в домашнюю группу по паролю? Создается новый сертификат? Кто выступает в роли центра сертификации? Почему ему доверяют другие участники группы?
Если вы в теме, напишите, пожалуйста, развернутый комментарий или даже статью. Думаю, многим полезно будет — информации по протоколу и технической информации по домашней группе кот наплакал.
Без сертификатов оно не работает. Каждая станция генерит свой сертификат, при создании группы её члены должны обменяться сертификатами, после чего уже спокойно аутентифицируют друг друга. Случайный компьютер в группу сам не добавится — пароль нужен. Такая вот одноранговая PKI, где все сертификаты — корневые, и все члены друг другу доверяют.
На статью у меня материала нет, но исследовать, как оно на самом деле в текущей реализации функционирует — мысль интересная. :)
На статью у меня материала нет, но исследовать, как оно на самом деле в текущей реализации функционирует — мысль интересная. :)
Спасибо. В целом да, протокол довольно интересный. Особенно, перспективным мне кажется его применение совместно с онлайн-аккаунтами Microsoft. Т.е. сертификаты генерируются и хранятся на серверах Microsoft, и могут быть запрошены для проверки подлинности пользователя.
В принципе, в Windows 10 есть возможность дать доступ пользователю к компьютеру по имени его (пользователя) учетной записи Microsoft. Думаю, при этом используется механизм схожий с описанным выше. Но будет ли при этом доступ по SMB, я пока не проверял.
Но вообще на замену NTLM PKU2U не тянет, хотя бы потому, что все сценарии использования NTLM он не покрывает.
В принципе, в Windows 10 есть возможность дать доступ пользователю к компьютеру по имени его (пользователя) учетной записи Microsoft. Думаю, при этом используется механизм схожий с описанным выше. Но будет ли при этом доступ по SMB, я пока не проверял.
Но вообще на замену NTLM PKU2U не тянет, хотя бы потому, что все сценарии использования NTLM он не покрывает.
и куда девать эту домашнюю группу дома, связывая 2 виндовых лаптопа, одну самбу на линуксе и один nas на непонятно чем (скорее всего какой-то линукс)?
Согласен, свободных реализаций к сожалению пока нет. Но для таких вот случаев я бы сделал галочку в венде как с клиентом Telnet.
Если вы Ъ-админ, вы конечно можете поднять свой контроллер домена на nas, но этот вариант к сожалению не всем подходит...
ну тут вопрос не в том, что я как Ъ-админ могу сделать. У меня и порты закрыть проблемы нет. Тут скорее просто ответ на «не думал что NTLM сейчас где-то может использоваться». Простых NAS-ов сейчас как собак нерезаных (и очень мало кто из них не только свой домен могут держать, они не все в существующий умеют входить). И люди ими активно пользуются. И хотят, чтоб оно работало «искаропки». Поэтому любые лишние галочки — это будет уже большое no-no.
Как по мне, единственное рабочее решение — это таки провайдерам перекрывать порты. Причем вплоть до на уровне закона. Кому таки очень надо через Интернет ползать на SMB-ресурсы пускай городит VPN. И это по-любому правильнее.
Как по мне, единственное рабочее решение — это таки провайдерам перекрывать порты. Причем вплоть до на уровне закона. Кому таки очень надо через Интернет ползать на SMB-ресурсы пускай городит VPN. И это по-любому правильнее.
Как по мне это решение совсем неправильное. Провайдера совсем не должно беспокоить какие порты у меня открыты и для чего. Максимум, как опция у провайдера (у билайна такая есть).
Правильное решение это если Microsoft выпустят патч который разрешает использование NTLM по умолчанию только для локальных подключений.
тоже вариант. геморно для контор у которых сервера не в «локальной» сети. особенно если в конторе разрешается и активно используется политика работы «гостевых» компов. У меня так, например. Каждому юзеру, пришедшему со своим лаптопом объяснять почему он не может зайти на корпоративный сервер — это много лишней головной боли. Но тут можно сказать, что нечего плакаться, работа такая.
Почему не смогут? — смогут, просто им свой логин и пароль нужно будет ввести вручную при первом подключении, там и галочка есть "сохранить пароль" и "подключаться автоматически"
Вот уж не поверю что вы на своем сервере создаете такие же учетки как у пользователя на лаптопе, только ради того что бы автоматический вход работал...
или я чего-то не понимаю, или запрет NTLM-аутентификации полностью запретит логон. Это не запрет «автоматической посылки имени и пароля залогинившегося юзера», это запрет аутентификации вообще.
Вот патч, который таки запретит посылку имени и пароля автоматом — это да, решило-бы проблему.
P.S. я не создаю на сервере учетки, совпадающие с юзеровскими учетками на их домашних лаптопах. А вот они таки да, создают локальные аккаунты, совпадающие с их рабочим аккаутом, дабы иметь прозрачный доступ к ресурсам. Но это действительно, уже совсем другая проблема.
Вот патч, который таки запретит посылку имени и пароля автоматом — это да, решило-бы проблему.
P.S. я не создаю на сервере учетки, совпадающие с юзеровскими учетками на их домашних лаптопах. А вот они таки да, создают локальные аккаунты, совпадающие с их рабочим аккаутом, дабы иметь прозрачный доступ к ресурсам. Но это действительно, уже совсем другая проблема.
Отличным решением было бы официально выпустить Windows 10 Paranoid Edition…
У меня английская Win10Home (Version 10.0.10586) с прокатанным по ней DWS, учетка MS не используется. Просто файл не открывается.
Вообще не понимаю людей, кто ставит ванильную винду и к тому же с аккаунтом от мелкософта.
Вообще не понимаю людей, кто ставит ванильную винду и к тому же с аккаунтом от мелкософта.
картинки
Файлволл ничего не блочит
Файлволл ничего не блочит
telnet 31.220.5.43 445 — работает
Ну это больше из-за perfect-privacy.
Некоторые провайдеры, например Ростелеком, блокируют доступ по этим портам в своих сетях, что довольно мило с их стороны.
Боюсь что это не так…
Скрин
Уже на хакере написали)
Кстати, requestPolicy заблокировал 1 картинку… интересно насколько хорошо он ее не пропустил?
Кстати, requestPolicy заблокировал 1 картинку… интересно насколько хорошо он ее не пропустил?
Провайдер Tomtel блокирует все порты «сетевого окружения». Открывает только при запросе у администратора, причём у меня спросили, достаточно понимаю ли я понимаю опасность данного действия :) А вот «Томика» не блокирует никак.
ValdikSS, Ну вот зачем «Была выполнена неудачная попытка входа в Вашу учетную запись LogMeIn.»?
Вообще, чем бо́льшая начнётся шумиха и истерия, тем лучше. То, что IT-специалисты знают об этом с 97го года, ни о чём руководству не скажет. Нужно, чтобы хотя бы десять англоязычных бытовых СМИ растрезвонили на бытовом уровне, сдобрив страшными словечками не к месту, смысла которых они не понимают. Тогда на это очень быстро и как следует отреагируют.
Считать ли утекшие пароли в Witch или через подобные сервисы дискредитированными?
fd00::/8 или fc00::/7 или холивар?
Оказалось, что в Firefox тоже SMB работает, но через \\, а не через file://. Дополнил статью.
Здравствуйте, Влад. Зарегистрировалась, чтобы написать вам. Я не знаю, можно ли писать сообщения лично, поэтому оставляю свой комментарий здесь(он не по теме поста). Я хотела бы узнать, Влад Щукин на ЖЖ и вы — это один и тот же человек? Надеюсь на ваш ответ)
Просто на всякий случай распишу, как читать полученные хеши и как получать из них свои пароли (чтобы проверить, например, проверить правильность работы). Распишу потому, что сам с протоколом 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).
Классный пост!
Хм, а разве вообще требуется какая то дополнительная настройка чтобы было безопасно? Ведь при подключении к любой сети система, точнее фаервол спрашивает к какому типу сети она относится и SMB будет работать только в «домашней» или в «сети предприятия», в «общественных» сетях (а любая новая сеть по умолчанию как раз такая) он работать не будет не при каких настройках. Во вторых для того чтобы работала данная уязвимость особенность да ничего особенного на самом деле, надо чтобы хост на Windows был напрямую подключён к интернету или хотя бы к локалке провайдера в которой этот трафик не режется и у него должен быть отключен фаервол, т. е. если хотя бы этот трафик рубится, а у большинства провайдеров он рубится или если хост c Windows находится за роутером (за NAT) то и проблемы нет. В третьих если компьютер подключён напрямую к интернету то в фаерволе SMB вообще закрыт совсем и полностью поскольку именно такая настройка используется по умолчанию, а чтобы SMB заработал её ещё надо поменять, а если пользователь не лазил в «сетевое окружение» то и этого предложения не будет. В четвёртых NTLM аутентификация работает только если включена авторизация по логину с паролем, по умолчанию это тоже не так и используется «домашняя группа». Вроде я нигде не ошибся, поправьте, пожалуйста, если что то забыл или не учёл.
P.S. Kalter и Funbit как по мне и не должно работать и нужно специально настраивать чтобы заработало :)
P.S. Kalter и Funbit как по мне и не должно работать и нужно специально настраивать чтобы заработало :)
Файрволл по умолчанию ограничивает входящие соединения, а не исходящие. Здесь же используются только исходящие соединения, и не имеет значения, за NAT компьютер, или нет. Провайдеров, блокирующих SMB-трафик, меньшинство, если что.
Благодарю, агу это так. Но значит всё равно надо включать поддержку SMB 1.0 в сетевом окружении, а потом ещё переключить управление аккаунтами с «Домашней группы» на логины с паролем. То есть по умолчанию работать не должно.
Нет, не надо. Поддержка SMB 1.0 не требуется (но она и по умолчанию включена), а домашняя группа работает, как я понимаю, только в пределах локальной сети. Здесь же речь об интернете.
Благодарю, попробую ещё полазить тогда чтобы заработало. Собственно с UNC путями в Firefox не работает, в Chrome ни file:/ ни UNC не работает, в IE тоже file:/ не работает, Win 7 SP1 x64.
P.S. провайдера я сразу «сменил» с помощью OpenVPN на того который точно SMB не блочит, трафик на порт точно ходит. В общем буду думать что и где у меня совсем не так.
P.S. провайдера я сразу «сменил» с помощью OpenVPN на того который точно SMB не блочит, трафик на порт точно ходит. В общем буду думать что и где у меня совсем не так.
Чтобы работал конкретно ＷＩＴＣＨ？, вам нужна поддержка SMB1, т.к. софт, который используется там, не поддерживает SMB2. Но если говорить в общем, то поддержка SMB1 не обязательна. Возможно, дело в этом? Здесь кто-то описывался, у кого, по какой-то причине, поддержка SMB1 была отключена.
Агу, для витч, SMB1 у меня точно включена, специально перепроверил, но даже без этого очевидно что она включена ибо я спокойно подключаюсь к Windows Mobile 6.1 и она ко мне тоже. XP под руками нет уже давно, но и она должна работать, так что SMB1 точно вкл.
Нашёл наконец то причину :) Удалось таки себя хакнуть, мухахахахах, шлюз домашний резал лишнее, а поскольку VPN настроено на нём же, то и через других провайдеров не работало :)
Кстати, определение версии ОС, похоже и правда поломалось ибо пишет Detected OS = Windows 7 or 8 [fuzzy] что странно ибо браузер уже отдаёт эту инфу и там корректно написано Windows NT 6.1, так что перепутать невозможно.
P.P.S. Вот на XP без SP2 будет работать точно, а может на любой XP будет ибо в SP2 фаервол хоть и ввели, но классификации типа сети вроде не было. Вот этот момент уже честно не помню совсем ибо для меня XP уже давно (примерно с июня-июля 2009) не актуальна.
Проверил на 3-х компах и планшете, с двумя разными провайдерами. Win 8.1 и Win10.
Все отлично работает, к сажалению(
Все отлично работает, к сажалению(
Не открывается Ваша ссылка:
https://s.mail.ru/7RKm/WA5NR2Hsi
Касперский негодует!
https://s.mail.ru/7RKm/WA5NR2Hsi
Касперский негодует!
Хочу поделиться способом блокировки трафика SMB за пределами локальной сети средствами брандмауэра Windows.
Ниже представлено содержимое пакетного файла bat вносящего изменения в правила брандмауэра Windows. Для запуска пакетного файла требуются права администратора. Работа пакетного файла проверялась на Windows 7.
Перед применением правил создается файл с текущими правилами брандмауэра Windows «c:\tmp\log_rule_org.txt», после применения правил создается файл с новыми правилами — «c:\tmp\log_rule_new.txt». Соответственно сравнив эти два файла можно проверить изменения в правилах брандмауэра.
В правила вносится блокировка SMB трафика для всех IP адресов IPv4 за исключением частных адресов: 10.0.0.0/8, 127.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16.
Windows7-Netsh_AdvFirewall_Firewall.bat
Ниже представлено содержимое пакетного файла bat вносящего изменения в правила брандмауэра Windows. Для запуска пакетного файла требуются права администратора. Работа пакетного файла проверялась на Windows 7.
Перед применением правил создается файл с текущими правилами брандмауэра Windows «c:\tmp\log_rule_org.txt», после применения правил создается файл с новыми правилами — «c:\tmp\log_rule_new.txt». Соответственно сравнив эти два файла можно проверить изменения в правилах брандмауэра.
В правила вносится блокировка SMB трафика для всех IP адресов IPv4 за исключением частных адресов: 10.0.0.0/8, 127.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16.
Windows7-Netsh_AdvFirewall_Firewall.bat
@chcp 1251
netsh advfirewall firewall show rule name=all > c:\tmp\log_rule_org.txt
:: SMB 137 (TCP, UDP)
netsh advfirewall firewall add rule name=«SMB_137(TCP-In)» dir=In action=block enable=yes profile=any localip=any remoteip=0.0.0.0-9.255.255.255,11.0.0.0-126.255.255.255,128.0.0.0-172.15.255.255,172.32.0.0-192.167.255.255,192.169.0.0-255.255.255.255 localport=137 remoteport=any protocol=tcp
netsh advfirewall firewall add rule name=«SMB_137(UDP-In)» dir=In action=block enable=yes profile=any localip=any remoteip=0.0.0.0-9.255.255.255,11.0.0.0-126.255.255.255,128.0.0.0-172.15.255.255,172.32.0.0-192.167.255.255,192.169.0.0-255.255.255.255 localport=137 remoteport=any protocol=udp
netsh advfirewall firewall add rule name=«SMB_137(TCP-Out)» dir=out action=block enable=yes profile=any localip=any remoteip=0.0.0.0-9.255.255.255,11.0.0.0-126.255.255.255,128.0.0.0-172.15.255.255,172.32.0.0-192.167.255.255,192.169.0.0-255.255.255.255 localport=any remoteport=137 protocol=tcp
netsh advfirewall firewall add rule name=«SMB_137(UDP-Out)» dir=out action=block enable=yes profile=any localip=any remoteip=0.0.0.0-9.255.255.255,11.0.0.0-126.255.255.255,128.0.0.0-172.15.255.255,172.32.0.0-192.167.255.255,192.169.0.0-255.255.255.255 localport=any remoteport=137 protocol=udp
:: SMB 138 (UDP)
netsh advfirewall firewall add rule name=«SMB_138(UDP-In)» dir=In action=block enable=yes profile=any localip=any remoteip=0.0.0.0-9.255.255.255,11.0.0.0-126.255.255.255,128.0.0.0-172.15.255.255,172.32.0.0-192.167.255.255,192.169.0.0-255.255.255.255 localport=138 remoteport=any protocol=udp
netsh advfirewall firewall add rule name=«SMB_138(UDP-Out)» dir=out action=block enable=yes profile=any localip=any remoteip=0.0.0.0-9.255.255.255,11.0.0.0-126.255.255.255,128.0.0.0-172.15.255.255,172.32.0.0-192.167.255.255,192.169.0.0-255.255.255.255 localport=any remoteport=138 protocol=udp
:: SMB 139 (TCP)
netsh advfirewall firewall add rule name=«SMB_139(TCP-In)» dir=In action=block enable=yes profile=any localip=any remoteip=0.0.0.0-9.255.255.255,11.0.0.0-126.255.255.255,128.0.0.0-172.15.255.255,172.32.0.0-192.167.255.255,192.169.0.0-255.255.255.255 localport=139 remoteport=any protocol=tcp
netsh advfirewall firewall add rule name=«SMB_139(TCP-Out)» dir=out action=block enable=yes profile=any localip=any remoteip=0.0.0.0-9.255.255.255,11.0.0.0-126.255.255.255,128.0.0.0-172.15.255.255,172.32.0.0-192.167.255.255,192.169.0.0-255.255.255.255 localport=any remoteport=139 protocol=tcp
:: SMB 445 (TCP, UDP)
netsh advfirewall firewall add rule name=«SMB_445(TCP-In)» dir=In action=block enable=yes profile=any localip=any remoteip=0.0.0.0-9.255.255.255,11.0.0.0-126.255.255.255,128.0.0.0-172.15.255.255,172.32.0.0-192.167.255.255,192.169.0.0-255.255.255.255 localport=445 remoteport=any protocol=tcp
netsh advfirewall firewall add rule name=«SMB_445(UDP-In)» dir=In action=block enable=yes profile=any localip=any remoteip=0.0.0.0-9.255.255.255,11.0.0.0-126.255.255.255,128.0.0.0-172.15.255.255,172.32.0.0-192.167.255.255,192.169.0.0-255.255.255.255 localport=445 remoteport=any protocol=udp
netsh advfirewall firewall add rule name=«SMB_445(TCP-Out)» dir=out action=block enable=yes profile=any localip=any remoteip=0.0.0.0-9.255.255.255,11.0.0.0-126.255.255.255,128.0.0.0-172.15.255.255,172.32.0.0-192.167.255.255,192.169.0.0-255.255.255.255 localport=any remoteport=445 protocol=tcp
netsh advfirewall firewall add rule name=«SMB_445(UDP-Out)» dir=out action=block enable=yes profile=any localip=any remoteip=0.0.0.0-9.255.255.255,11.0.0.0-126.255.255.255,128.0.0.0-172.15.255.255,172.32.0.0-192.167.255.255,192.169.0.0-255.255.255.255 localport=any remoteport=445 protocol=udp
netsh advfirewall firewall show rule name=all > c:\tmp\log_rule_new.txt
@pause
UPD 11.04.2018: Windows 10 отключает автоматический вход на SMB-ресурсы, если в системе используется учетная запись Microsoft. Хеш локальной учетной записи и учетных данных IPsec все еще продолжает передаваться сторонним хостам.
Sign up to leave a comment.
Деанонимизируем пользователей Windows и получаем учетные данные Microsoft и VPN-аккаунтов