Comments 17
Коннекчусть к ворп вайфаю по MS-CHAPv2. Надо будет нашим IT инженерам показать эту статью. Спасибо!
UFO just landed and posted this here
Не используйте MPPE (который так же надежен, как и MS-CHAP), используйте EAP-TLS. Вроде, с Висты поддерживается нативно PEAP. Ну, или придется чем-то заменять
Microsoft с выхода 2003-го сервера твердит, что PPTP ненадёжен, используйте L2TP.
Так L2TP надо внутри IPSec пускать как раз из-за надежности.
А внутри еще один IPSec для надежности. :) И сразу вспоминается любимый RFC3251 (прочитайте хотя бы Abstract) :)
Хе хе хе. А насчет L2TP, я действительно не видел чистый L2TP, только L2TP over IPSec.
Выходит, что самое надежное на сегодня это WPA2 + AES.
Выходит, что самое надежное на сегодня это WPA2 + AES.
Ну, для Wi-Fi:
WPA2-Enterprise — геморно настроить, но зато потом работает надежно и поддерживать не особо накладно. (если не считать EAP-TLS)
WPA2-Personal удобен дома, но в корпоративных средах неудобен — менять PSK геморройно, а если кто-то завладеет устройством, на котором закеширован PSK — появляется огромный простор для действий (далеко выходящий за «вычислить ключ — войти в сеть — нагадить»).
PPTP, как я понимаю, был упомянут в контексте MS-CHAP, а не в контексте Wi-Fi.
Я не разу не встречал L2TP over IpSec за пределами залачи проброса VLAN поверх VPN (когда вместо частной WAN используется обычный Internet-доступ). Тут IPSec чаще для туннелирования используется, а шифрование идет приятным (и полезным) довеском.
WPA2-Enterprise — геморно настроить, но зато потом работает надежно и поддерживать не особо накладно. (если не считать EAP-TLS)
WPA2-Personal удобен дома, но в корпоративных средах неудобен — менять PSK геморройно, а если кто-то завладеет устройством, на котором закеширован PSK — появляется огромный простор для действий (далеко выходящий за «вычислить ключ — войти в сеть — нагадить»).
PPTP, как я понимаю, был упомянут в контексте MS-CHAP, а не в контексте Wi-Fi.
Я не разу не встречал L2TP over IpSec за пределами залачи проброса VLAN поверх VPN (когда вместо частной WAN используется обычный Internet-доступ). Тут IPSec чаще для туннелирования используется, а шифрование идет приятным (и полезным) довеском.
Да, PPTP не в контексте Wi-Fi.
> Я не разу не встречал L2TP over IpSec за пределами залачи проброса VLAN поверх VPN (когда вместо частной WAN используется обычный Internet-доступ). Тут IPSec чаще для туннелирования используется, а шифрование идет приятным (и полезным) довеском.
Насколько я помню винда не давала создать чистый L2TP без IPSec'a без шаманства. Тоже самое для Mac OS X и iOS. Насколько я знаю это сделано из-за того, что L2TP в публичной сети не очень безопасен.
> Я не разу не встречал L2TP over IpSec за пределами залачи проброса VLAN поверх VPN (когда вместо частной WAN используется обычный Internet-доступ). Тут IPSec чаще для туннелирования используется, а шифрование идет приятным (и полезным) довеском.
Насколько я помню винда не давала создать чистый L2TP без IPSec'a без шаманства. Тоже самое для Mac OS X и iOS. Насколько я знаю это сделано из-за того, что L2TP в публичной сети не очень безопасен.
EAP-TLS требует клиентских сертификатов, распространение которых юзерам в не-только-виндовс среде вызывает определенный геморрой. PEAP — вполне себе нормальный выход.
Поддерживаю. Хотя обычно все решается с помощью какого-нибудь защищенного веб-сервера реализующего «введи пароль -> выбери ОС -> скачай сертификат/программку-устрановщик сертификата».
Далее на той же WLAN поднимается NAC на основе Role-Based Access Control и Captive Portal'а:
Если юзер зафейлил аутентификацию 802.1x точка производит (для него лично) fallback на Captive Portal (HTTPS), где его имя/пароль дают ему доступ к защищенному серверу (и только!), с которого можно обновить сертификат. При этом, RBAC (он же RBF — Role-Based Firewall у других вендоров) не позволяет пользователю сунуться куда-либо еще.
Заметьте, что все эти операции проводятся на той-же самой корпоративной WLAN, которой в это же время полноценно пользуются полноценно авторизованные пользователи — никаких дополнительных костылей в виде запасных WLAN придумывать не надо. Правда, это возможно только с WPA2-Enterprise, с Personal такой фокус не прокатит. Поднимается такой сетапчик (не считая сервера обновления сертификатов) минут за 30.
Хотя, многие предпочитают давать доступ к серверу обновления сертификатов только по проводу и только изнутри собственных офисов, что тоже считаю вполне обоснованным.
Сейчас идет волна BYOD'а и такие штуки будут ой-как востребованы, ибо enrollment на основе MAC-адреса, это, простите, моветон.
Далее на той же WLAN поднимается NAC на основе Role-Based Access Control и Captive Portal'а:
Если юзер зафейлил аутентификацию 802.1x точка производит (для него лично) fallback на Captive Portal (HTTPS), где его имя/пароль дают ему доступ к защищенному серверу (и только!), с которого можно обновить сертификат. При этом, RBAC (он же RBF — Role-Based Firewall у других вендоров) не позволяет пользователю сунуться куда-либо еще.
Заметьте, что все эти операции проводятся на той-же самой корпоративной WLAN, которой в это же время полноценно пользуются полноценно авторизованные пользователи — никаких дополнительных костылей в виде запасных WLAN придумывать не надо. Правда, это возможно только с WPA2-Enterprise, с Personal такой фокус не прокатит. Поднимается такой сетапчик (не считая сервера обновления сертификатов) минут за 30.
Хотя, многие предпочитают давать доступ к серверу обновления сертификатов только по проводу и только изнутри собственных офисов, что тоже считаю вполне обоснованным.
Сейчас идет волна BYOD'а и такие штуки будут ой-как востребованы, ибо enrollment на основе MAC-адреса, это, простите, моветон.
Собирался написать тоже самое сегодня, поленился в выходные.
Спасибо за статью, так не люблю, когда раздувают, жаль в карму не могу плюсануть.
А авторы «атаки» по большей части просто рекламируют свой платный брутфорс-сервис.
Спасибо за статью, так не люблю, когда раздувают, жаль в карму не могу плюсануть.
А авторы «атаки» по большей части просто рекламируют свой платный брутфорс-сервис.
Опоздали они со своим гарантированным взломом на 8 лет и даже более.
Новость 2012 года
www.securitylab.ru/analytics/428488.php
…
Присмотревшись, можно видеть, что MD4-хэш пользовательского пароля служит эквивалентом пароля, то есть, MD4-хэша пароля пользователя достаточно для аутентификации от имени этого пользователя, равно как и расшифровки любого его трафика. Итак, нашей целью является восстановление MD4-хэша пользовательского пароля.
…
В ситуации с неограниченной длиной пароля, составленного из широкого набора символов, имеет смысл напрямую подбирать результат MD4-хэширования. ... Преследуемый нами хэш, однако, используется как ключевой материал для трех DES-операций. DES-ключи имеют длину 7 байт, так что каждая DES-операция использует 7-байтовый фрагмент MD4-хэша. Это дает нам возможность для классической атаки «разделяй и властвуй».
2004 год
www.securitylab.ru/contest/212100.php
Возникает закономерный вопрос: если у нас есть на руках NT и LM хэши можем ли мы использовать их, например, для аутентификации по сети без восстановления пароля в открытом тексте? Очевидно, да.… Урок, который должен быть извлечен – хэш пароля с точки зрения протокола NTLM абсолютно равнозначен самому паролю, возможность получения хэша означает возможность полного использования пароля.
…
Сразу должно бросаться в глаза, что не так с этим алгоритмом – проблема та же, что и при вычислении LM-хэша, все три DES-блока вычисляются независимо. Это означает, что и восстанавливаться по известному запросу и ответу они так же могут независимо. Для современного PC время восстановление одного блока хэша пароля методом полного перебора составляет порядка нескольких недель и не зависит от сложности пароля.
…
Из этого, в сочетании с тем, что имея хэш мы не нуждаемся в пароле в открытом тексте, следует однозначный вывод – NTLM 0.12 и MS-CHAP не должны использоваться для аутентификации в сетях, где возможен перехват трафика.… Протокол аутентификации удаленного доступа MS-CHAPv2 является всего лишь расширением протокола MS-CHAP и, соответственно, NTLM 0.12.
…
Из этого следует, что MS-CHAPv2, который часто используется для аутентификации, например, PPTP соединений, так же ни в коем случае не должен использоваться для аутентификации по недоверенным каналам связи.
Новость 2012 года
www.securitylab.ru/analytics/428488.php
…
Присмотревшись, можно видеть, что MD4-хэш пользовательского пароля служит эквивалентом пароля, то есть, MD4-хэша пароля пользователя достаточно для аутентификации от имени этого пользователя, равно как и расшифровки любого его трафика. Итак, нашей целью является восстановление MD4-хэша пользовательского пароля.
…
В ситуации с неограниченной длиной пароля, составленного из широкого набора символов, имеет смысл напрямую подбирать результат MD4-хэширования. ... Преследуемый нами хэш, однако, используется как ключевой материал для трех DES-операций. DES-ключи имеют длину 7 байт, так что каждая DES-операция использует 7-байтовый фрагмент MD4-хэша. Это дает нам возможность для классической атаки «разделяй и властвуй».
2004 год
www.securitylab.ru/contest/212100.php
Возникает закономерный вопрос: если у нас есть на руках NT и LM хэши можем ли мы использовать их, например, для аутентификации по сети без восстановления пароля в открытом тексте? Очевидно, да.… Урок, который должен быть извлечен – хэш пароля с точки зрения протокола NTLM абсолютно равнозначен самому паролю, возможность получения хэша означает возможность полного использования пароля.
…
Сразу должно бросаться в глаза, что не так с этим алгоритмом – проблема та же, что и при вычислении LM-хэша, все три DES-блока вычисляются независимо. Это означает, что и восстанавливаться по известному запросу и ответу они так же могут независимо. Для современного PC время восстановление одного блока хэша пароля методом полного перебора составляет порядка нескольких недель и не зависит от сложности пароля.
…
Из этого, в сочетании с тем, что имея хэш мы не нуждаемся в пароле в открытом тексте, следует однозначный вывод – NTLM 0.12 и MS-CHAP не должны использоваться для аутентификации в сетях, где возможен перехват трафика.… Протокол аутентификации удаленного доступа MS-CHAPv2 является всего лишь расширением протокола MS-CHAP и, соответственно, NTLM 0.12.
…
Из этого следует, что MS-CHAPv2, который часто используется для аутентификации, например, PPTP соединений, так же ни в коем случае не должен использоваться для аутентификации по недоверенным каналам связи.
Где-то в райное этих годов (2004±1) читал отличную книгу по безопасности WinNT, где было сказано то же самое :)
Максимум, на что они могут претендовать в смысле оригинальности — это взлом DES блоков за один проход, т. к. шифруется один и тот же открытый текст. «Наиболее затратной частью данных циклов являются DES-операции. Но, поскольку в каждом цикле используется один и тот же открытый текст, мы можем соединить все в единственный цикл по ключевому пространству с одним шифрованием для каждого из ключей и двумя сравнениями.» Хотя не факт. То, что в других публикациях это не упоминается еще не значит, что люди в прошлом до этой, в целом весьма простой вещи, не догадались. Просто не акцентировались на тонкостях реализации алгоритма.
Sign up to leave a comment.
Разбираем последствия взлома MS-CHAPv2 для Wi-Fi (WPA/WPA2-Enterprise)