Разбираем последствия взлома MS-CHAPv2 для Wi-Fi (WPA/WPA2-Enterprise)

    На последней DEFCON был продемонстрирован взлом протокола аутентификации MS-CHAPv2 (давно пора). В результате многие СМИ разразились информацией о том, что «тысячи VPN и WPA2-утройств находятся в опасности». Рассмотрим, насколько это утверждение верно для Wi-Fi сети реализующей WPA2.
    Скандалы? Интриги? Расследования?


    Дабы не плодить сущности без необходимости, я там выжимку с основными фактами и выводами, а также ссылки на первоисточники для тех, кого интересуют подробности.

    Скандалы

    Исходная информация: блог авторов атаки. Утверждается, что MS-CHAPv2 взламывается с результативностью 100%. Приводятся подробности, из которых видно, что нужно перехватить обмен по протоколу MS-CHAPv2, после чего, используя уязвимости в шифровании можно вычислить реквизиты пользователя. Утверждается, что MS-CHAPv2 используется в системах VPN и WPA2-Enterprise. При этом и VPN и WPA2 упоминаются в контексте AAA-серверов, что весьма логично, ибо именно там и ловится нешифрованный MS-CHAP. Итого — таки да, MS-CHAPv2 взломан. Если перехватить MS-CHAPv2 обмен между клиентом и AAA-сервером — можно вычислить реквизиты пользователя.

    Интриги

    После этого, начали появляться статьи типа этой, где WPA2 уже используется вне контекста AAA-серверов. При этом делаются довольно серьезные заявления: «Users who want to crack the key protecting a target's VPN- or WPA2-protected traffic need only capture a single login attempt» (для взлома VPN/WPA2 достаточно перехватить одну попытку входа) и вплоть до «people should immediately stop using VPN and WPA2 products that rely on MS-CHAP» (людям следует немедленно прекратить использовать VPN/WPA2 с MS-CHAP).

    Расследования

    Ну, для начала, вспомним, что WPA2 существует в двух видах: WPA2-Personal (PSK) и WPA2-Enterprise (802.1x/EAP). MS-CHAPv2 используется только в Enterprise, поэтому пользователи PSK могут спать спокойно.
    В Enterprise, MS-CHAPv2 является только одим из возможных методов EAP (есть еще довольно популярный GTC, TTLS и т.д.). Популярность MS-CHAPv2 вызвана тем, что это наиболее простой метод для интеграции с продуктами Microsoft (IAS, AD, и т.д.).

    Тем не менее, хоть кто-нибудь видел реализацию WPA2-Enterprise с чистым EAP/MS-CHAPv2? Не припоминаю… Любой знающий человек скажет, что должен быть еще туннель (PEAP или TLS). Так вот при наличии туннеля перехват сессии MS-CHAPv2 уже невозможен, т.к. вначале надо взломать шифрование туннеля, так что сенсация отменяется.

    Однако, расслабляться еще рано. Туннель строится между клиентом и точкой доступа. Если имперсонировать точку доступа, можно спокойно заполучить и клиента, и его «чистую» MS-CHAPv2 сессию со всеми вытекающими. Отсюда вывод из категории «уж сколько раз твердили миру»: ставьте сертификаты на точки доступа и включайте проверку сертификатов на клиентах.

    Таким образом, для грамотно построенной беспроводной сети с WPA2-Enterprise на основе PEAP/MS-CHAPv2 новая атака не страшна. Разве что, вклиниться в канал между аутентификатором (ТД, контроллером) и AAA-сервером, но это уже не относится к WPA.

    Подробности, иллюстрации и рекомендации по настройке можно почитать у друх авторитетных специалистов отрасли: Andrew VonNagy и Devin Akin.

    Еще примеры маркетолохии и дурналистики (смотрим теги):
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 17

      0
      Коннекчусть к ворп вайфаю по MS-CHAPv2. Надо будет нашим IT инженерам показать эту статью. Спасибо!
        +2
        Да, но PPTP? это даже серьезнее.
          0
          Не используйте MPPE (который так же надежен, как и MS-CHAP), используйте EAP-TLS. Вроде, с Висты поддерживается нативно PEAP. Ну, или придется чем-то заменять
            0
            Microsoft с выхода 2003-го сервера твердит, что PPTP ненадёжен, используйте L2TP.
              +1
              Так L2TP надо внутри IPSec пускать как раз из-за надежности.
                0
                А внутри еще один IPSec для надежности. :) И сразу вспоминается любимый RFC3251 (прочитайте хотя бы Abstract) :)
                  0
                  Хе хе хе. А насчет L2TP, я действительно не видел чистый L2TP, только L2TP over IPSec.

                  Выходит, что самое надежное на сегодня это WPA2 + AES.
                    0
                    Ну, для Wi-Fi:
                    WPA2-Enterprise — геморно настроить, но зато потом работает надежно и поддерживать не особо накладно. (если не считать EAP-TLS)
                    WPA2-Personal удобен дома, но в корпоративных средах неудобен — менять PSK геморройно, а если кто-то завладеет устройством, на котором закеширован PSK — появляется огромный простор для действий (далеко выходящий за «вычислить ключ — войти в сеть — нагадить»).
                    PPTP, как я понимаю, был упомянут в контексте MS-CHAP, а не в контексте Wi-Fi.

                    Я не разу не встречал L2TP over IpSec за пределами залачи проброса VLAN поверх VPN (когда вместо частной WAN используется обычный Internet-доступ). Тут IPSec чаще для туннелирования используется, а шифрование идет приятным (и полезным) довеском.
                      +1
                      Да, PPTP не в контексте Wi-Fi.

                      > Я не разу не встречал L2TP over IpSec за пределами залачи проброса VLAN поверх VPN (когда вместо частной WAN используется обычный Internet-доступ). Тут IPSec чаще для туннелирования используется, а шифрование идет приятным (и полезным) довеском.

                      Насколько я помню винда не давала создать чистый L2TP без IPSec'a без шаманства. Тоже самое для Mac OS X и iOS. Насколько я знаю это сделано из-за того, что L2TP в публичной сети не очень безопасен.
                        +1
                        Правильнее сказать «L2TP в публичной сети абсолютно небезопасен», поскольку вопросами безопасности этот протокол вообще не заморачивается: он изначально спроектирован для работы поверх IPSec.
              0
              EAP-TLS требует клиентских сертификатов, распространение которых юзерам в не-только-виндовс среде вызывает определенный геморрой. PEAP — вполне себе нормальный выход.
                +1
                Поддерживаю. Хотя обычно все решается с помощью какого-нибудь защищенного веб-сервера реализующего «введи пароль -> выбери ОС -> скачай сертификат/программку-устрановщик сертификата».
                Далее на той же 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-адреса, это, простите, моветон.
                  0
                  Это всё здорово, при наличии а) грамотного админа и б) вменяемого беспроводного оборудования. Однако, увы, до сих пор подавляющее большинство беспроводных сетей строится пионерами и на д-линках. По бедности, конечно же…
            +1
            Собирался написать тоже самое сегодня, поленился в выходные.
            Спасибо за статью, так не люблю, когда раздувают, жаль в карму не могу плюсануть.
            А авторы «атаки» по большей части просто рекламируют свой платный брутфорс-сервис.
              0
              Опоздали они со своим гарантированным взломом на 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 соединений, так же ни в коем случае не должен использоваться для аутентификации по недоверенным каналам связи.
                0
                Где-то в райное этих годов (2004±1) читал отличную книгу по безопасности WinNT, где было сказано то же самое :)
                  +1
                  Максимум, на что они могут претендовать в смысле оригинальности — это взлом DES блоков за один проход, т. к. шифруется один и тот же открытый текст. «Наиболее затратной частью данных циклов являются DES-операции. Но, поскольку в каждом цикле используется один и тот же открытый текст, мы можем соединить все в единственный цикл по ключевому пространству с одним шифрованием для каждого из ключей и двумя сравнениями.» Хотя не факт. То, что в других публикациях это не упоминается еще не значит, что люди в прошлом до этой, в целом весьма простой вещи, не догадались. Просто не акцентировались на тонкостях реализации алгоритма.

              Only users with full accounts can post comments. Log in, please.