По мотивам топика о взломанном WPA.
Попытаемся все же разобраться, что случилось и чем это может нам грозить. Поскольку криптографические атаки — вещь, требующая для понимания весьма много специфических знаний, статью можно считать в некотором роде ознакомительной с безопасностью в Wi-Fi сетях.
Ну что же, для начала придется немного пройтись по теории протоколов шифрования Wi-Fi. Хотя нетерпеливым и тем, кого не интересует вся это наукообразная казуистика, не возбраняется сразу проследовать к заключению.
Протокол WEP в данный момент считается устаревшим, не рекомендуемым к использованию вовсе в пользу WPA и WPA2. Еще бы! Уязвимости его настолько серьезны, что позволяют взломать ключ и подключиться к защищенной сети за считанные минуты. Сколько этих самых минут понадобится, зависит от интенсивности трафика в сети; среднестатистическая нагруженная сеть ломается за одну-две минуты (интересующихся этим вопросом отсылаю к статье и на домашнюю страничку главной хакерской тулзы для wi-fi aircrack-ng). Сами WPA/WPA2 являются в некоторой степени надстройками над WEP, в том смысле, что основной формат пакета и алгоритм шифрования (для WPA) не поменялись, т.о. не было необходимости в смене оборудования, в большинстве случае достаточно было обновить прошивку (правильнее говорить не о WPA/WPA2, а о стандарте IEEE 802.11i; WPA — это его часть, включающая протокол управления ключами и шифрованием TKIP, WPA2 же полностью реализует стандарт, в том числе протокол CCMP с AES-шифрованием).
Поскольку форматы пакетов для всех протоколов имеют много общего, начнем с WEP пакета как самого простого:
Нас в этом пакете в наибольшей степени интересуют передаваемые данные (Network Data)
Здесь IV — это Initialization Vector, соль, необходимая для создания per-packet key. Data — это собственно передаваемые данные, формируемые вышележащими протоколами в стеке OSI (например, данные могут быть IP пакетом). IC (далее будем называть это поле ICV — Integrity Check Value) — это CRC32 чек-сумма от Data, служащая для проверки целостности данных. Data + ICV шифруются алгоритмом RC4 с ключом IV + WEP_key, т.е. полученным простой конкатенацией IV и пароля WEP. Размер IV — 24 бита, RC4 шифр использует ключи длины 64 или 128 бит. Отсюда понятно, почему пароли WEP бывают длины 5 или 13 символов (т.е. 40 или 104 бит).
Основные уязвимости WEP связаны с малой длиной IV, примитивном алгоритме получения per-packet key, уязвимостями самого RC4 алгоритма и его потоковой природой.
Итак, на этой картинке то, что я раньше называл Network Data, идет после MAC Header (чек-сумма FCS здесь не показана, как на рисунке для WEP; она нас не интересует, т.к. ее обработка ведется на нижележащем уровне модели OSI). IV — это тот же 24-битовый WEP Initialization Vector, только смысл его несколько иной, структура данных же пакета значительно усложнилась. Чтобы понять, что означают представленные поля, рассмотрим вкратце (а полностью рассматривать сил и времени нет, да и боюсь наскучить :-)) протокол TKIP, о котором я уже упоминал:
Основной сессионный ключ PTK (Pairwise Transient Key) — это набор из 4-х 128-битных ключей, используемый для TKIP для шифрования отдельных пакетов в периоды между сменами ключей. Заметим, что PTK — это не пароль WEP и ни он, ни механизм его генерации частью TKIP не являются.
В PTK входят 4 ключа: один для шифрования данных в TKIP (назовем его TK), один для вычисления MIC (а его MTK) и еще два так называемых EAPOL ключа, которых я касаться не буду. Ключи генерируются с использованием пароля WPA (наконец-то, появился пароль!), известного обеим сторонам, в процессе четырехэтапного «рукопожатия» (картинка, там же довольно подробная статья на английском про WPA).
Возвращаясь к предыдущему рисунку со структурой пакета WPA, видим, что все, что между MAC Header и Data по сути — счетчик TSC плюс некоторые служебные поля, служащие для защиты от слабых ключей и говорящие, о том, что используется Extended IV. TSC устанавливается в нуль при начале сессии и монотонно увеличивается с каждым переданным данным устройством пакетом, емкости в 48 бит хватит на ~250 триллионов пакетов, что можно считать достаточным с учетом периодической реинициализации сессионных ключей (в отличии от 24-битного IV в WEP). Уникальный ключ для шифрования пакета вычисляется из TK, TA (Transmittor Address — MAC адрес передатчика) и TSC путем определенного двухфазного механизма хеширования, который дает на выходе 104-битовую строку, к которой добавляется WEP IV (да-да, тот самый 24-битовый IV) для получения 128-битового ключа (на самом деле рисунок про формирование ключа наглядный, но неточный, дотошные могут взглянуть на этот).
Уфф… Что там у нас осталось? Ах да, MIC.
Он создан в основном для борьбы с поддлекой (forgery) пакетов. Код вычисляется от данных всего сообщения (плюс адреса передатчика и приемника) еще до фрагментации и возможной смены порядка пакетов с помощью алгоритма под названием MICHAEL, генерирующего подпись длины 64 бит. Алгоритм, кроме данных, использует ключ, а именно, вышеупомянутый MTK. Что немаловажно, алгоритм в некотором смысле обратим, т.е. зная данные и MIC подпись, можно вычислить ключ MTK.
Борьба с подделкой со стороны Access Point происходит, собственно, так: если пришел пакет с неверным MIC (при этом он валиден по остальным признакам, т.е. имеет допустимое значение TSC и ICV сумма прошла проверку), то отправителю посылается уведомление и, если есть возможность, данное событие фиксируется в журнале как попытка взлома. Если в течение 60 секунд приходит еще один пакет с неверным MIC, точка доступа инициализирует rekeying с данным отправителем. Т.о. поддельные пакеты безнаказанно (относительно) можно слать не чаще, чем раз в минуту.
Из внушительного списка атак, к которым уязвим WEP, рассмотрим так называемую Chop-Chop атаку (от англ. chop, вольный перевод — «отрезать ломтик»). Эта атака позволяет узнать plaintext сообщения (т.е. данные сообщения до шифрования), а значит и RC4 keystream пакета (plaintext + keystream = ciphertext => keystream = ciphertext + plaintext). Атака использует тот факт, что CRC32 чек-сумма отнюдь не проходит по требованиям в криптографическую хеш-функцию.
В WEP-пакете последние байты данных (Network Data) — это зашифрованный ICV, т.е. CRC от сообщения. Забудем на время о шифровании и рассмотрим, что будет, если убрать последний байт, который обозначим как R, из пакета. Пусть Q — пакет без последнего байта, тогда Q уже навряд ли будет иметь нужный остаток (т.е. CRC). Но оказывается, что к Q можно прибавить некий многочлен M так, чтобы исправить CRC. Подставив сначала SO = Q * X8 + R, а затем S1 = Q + M в (2), легко найти, что
M = (X32)-1 * (1 + (X8)-1) * (Pzero + Lf) + (X8)-1 * R
Если перебирать все байты R от 0 до 255 и отправлять их в сеть точке доступа, мы, в конце концов, наткнемся на правильный. Понять, что мы попали в байт в реальности также несложно: пакеты с неверным ICV тихо дропаются как переданные с ошибкой; если же CRC верна, мы вправе ожидать ответный пакет, например, в случае WPA, это обычно будет пакет, информирующий о неверном MIC. Но об этом чуть позже.
А как же шифрование? Оказывается, тот факт, что пакет шифрован, значения не имеет, т.к. шифрование RC4 алгоритмом сводится к XOR-иванию данных с keystream'ом, но прибавление M суть тот же XOR, а так как операция XOR коммутативна и ассоциативна, то и неважно, прибавлять M к исходным данным, а потом шифровать, или к уже зашифрованным.
Описанный процесс можно повторять дальше, «откусывая» по байту от сообщения, и теоретически можно расшифровать WEP пакет произвольной длины.
Перейдем, наконец, собственно, к теме статьи.
Итак, что будет, если попытаться применить Chop-Chop атаку к сети с WPA защитой?
TKIP имеет, в основном, 2 средства для защиты от подобных атак:
Первый пункт частично на руку атакующему, т.к. позволяет понять, когда он угадал очередной байт. Со вторым сложнее: действительно, пусть мы поймали ARP пакет, посланный одним из устройств в сети, его же поймала и Access Point, пересылать этот пакет ей еще раз бессмысленно, ведь TSC уже инкрементирован, плюс то первое устройство, возможно, наслало еще пакетов, увеличив счетчик еще больше. Авторы рассматриваемой атаки нашли выход в спецификации IEEE 802.11e, определяющей улучшения в QoS для сетей Wi-Fi. Сухой остаток здесь таков: устройства Wi-Fi поддерживают несколько очередей пакетов (именно их я выше назвал каналами; какое точно отношение они имеют к реальным радио каналам, я утверждать не берусь), по словам одного из авторов, Эрика Тьюза, предполагалось использовать 4 канала, в стандарте их 8, в реальности авторы обнаруживали до 16. Каналы обыкновенно не используются одновременно, экономя пропускную способность для важных пакетов. В ненагруженной сети часто весь трафик идет в один канал, т.о. пакет мы скорее всего поймаем на канале с высоким значением счетчика TSC, перепосылать же его можно, переключившись на менее нагруженный канал. Важно, что, опять же ссылаясь на авторов, при отсылке сообщения о неправильном MIC счетчик канала не увеличивается, т.о. дальше каналы можно не переключать.
Если в сети не поддерживаются QoS расширения, атака, в принципе, также осуществима, если удастся предотвратить попадание выбранного для дешифровки пакета на AP и отключить пославшее его устройство от сети.
Понятно, что пытаться расшифровать сколько-нибудь длинные пакеты по байту в минуту, дело довольно-таки безнадежное — стандартный Wi-Fi пакет имеет размер ~2300 байт, т.е. на него уйдет порядка полутора суток, а за это время или TSC счетчик увеличится, или ключи сменятся, или точка доступа сребутится, или Вас «запалят». Причем, имея одно устройство, ломать можно только один пакет.
Ну что ж, сниффер сделать не выйдет, посмотрим, что нам может дать расшифровка коротких пакетов, например, ARP, которые легко идентифицировать по их длине (14 байт). Собственно, атакующий знает большую часть содержимого APR пакета, а именно, заголовки и MAC адреса. Если можно также сделать и некоторые предположения об IP структуре взламываемой сети (в сети созданной из под Windows, например, можно ожидать, что IP адреса будут иметь вид 192.168.0.x), то угадать останется совсем ничего. Т.е., угадав 12 байт ICV + MIC, остальное можно просто подобрать, используя ICV сумму. Отсюда упомянутая в прессе цифра в 12 минут на взлом.
Что же дальше? Расшифровав один пакет, атакующий узнает RC4-keystream пакета (использовать его, правда, можно только, пока TSC не изменился) и, что более важно, сессионный MTK — я упоминал, что MIC обратим, и по данным и подписи можно установить ключ. Последнее означает, что до следующей смены ключей, нет необходимости больше угадывать MIC, и, например, чтобы взломать следующий ARP пакет (с теми же предположениями о структуре сети), уйдет 4-5 минут. Использовать дешифрованные данные для посылки forged пакетов можно, в зависимости от количества QoS каналов, от 7 до 15 раз (меньше, если трафик идет по более, чем одному каналу), дальше придется «чоп-чопить» другой пакет.
Если вспомнить сообщения в прессе до доклада Тьюза, например:
то очевидно, что краски «чуть-чуть» сгущены — читать трафик от AP к клиенту в реальности нельзя, да и как-то непонятно, что за «mathematical breakthrough» такой совершили авторы, ибо chop-chop атака известна аж с 2004 года…
Несмотря на то, что звучали заявления о взломе шифрования, сами WPA пароли и даже временные сессионные ключи (не считая MIC ключа) в полной безопасности. Атака позволяет расшифровать отдельные короткие пакеты, с которыми ведется работа, затрачивая в самом лучшем случае по 4-5 минут на пакет, и, используя результаты дешифровки, инжектировать очень ограниченное число столь же коротких пакетов обратно в сеть. Да, это, по всей видимости, первая серьезная атака, продемонстрировавшая уязвимость протокола TKIP, но абсолютному большинству волноваться по этому поводу причин не видно. По словам Тьюза: «если Вы использовали шифрование лишь для того, чтобы оградить свой интернет канал от использования случайными людьми, Вы в полной безопасности». Атака не может быть использована ни для подключения к домашней или корпоративной сети, ни для того, чтобы отслеживать в них трафик.
Тем не менее, мелкие пакости теоретически сделать можно, как то: «отравить» ARP (может быть, и DNS) кеш, прочитать некоторый объем приватного трафика, Тьюз также указывает на возможность обмануть некоторые фаерволы.
Какими методами можно бороться с такого вида атаками?
Ну, во-первых, конечно же, можно просто перейти на WPA2 с AES шифрованием. Также авторы советуют уменьшить время регенерации ключей точкой доступа (вплоть до 2-3 минут, что сделает в принципе невозможными описанные выше процедуры) и отключить автоматическую отсылку сообщений о неверном MIC в принятом пакете. К сожалению, неясно, предоставляют ли современные точки доступа такие тонкие параметры настройки (лично я вот понятия не имею, если кто-то встречал, было бы интересно узнать).
Что ж, вряд ли можно сказать, что WPA взломан. Более того, я думаю, что пока волноваться особенно не о чем. Однако, цитируя один из источников, «теперь, когда эти двое (Бек и Хьюз) открыли дверь, WPA наверняка привлечет пристальное внимание тысяч исследователей: белых, серых и черных».
Материалы и ссылки
Battered, but not broken (популярная и доступная статья об атаке)
Статья Бека и Тьюза
Статья о WPA
Презенташка (в статье использовал пару картинок)
aircrack-ng
Неплохая статья о CRC и теории ее взлома
Статья о способах быстрого взлома WEP и FMS атака в викиредии
Disclaimer
Прошу не судить строго, не являюсь специалистом по информационной безопасности и беспроводным протоколам, ни даже любителем, скорее из интересующихся :-) И заранее прошу прощения, если перегрузил статью теорией и подробностями.
Попытаемся все же разобраться, что случилось и чем это может нам грозить. Поскольку криптографические атаки — вещь, требующая для понимания весьма много специфических знаний, статью можно считать в некотором роде ознакомительной с безопасностью в Wi-Fi сетях.
Ну что же, для начала придется немного пройтись по теории протоколов шифрования Wi-Fi. Хотя нетерпеливым и тем, кого не интересует вся это наукообразная казуистика, не возбраняется сразу проследовать к заключению.
WEP
Протокол WEP в данный момент считается устаревшим, не рекомендуемым к использованию вовсе в пользу WPA и WPA2. Еще бы! Уязвимости его настолько серьезны, что позволяют взломать ключ и подключиться к защищенной сети за считанные минуты. Сколько этих самых минут понадобится, зависит от интенсивности трафика в сети; среднестатистическая нагруженная сеть ломается за одну-две минуты (интересующихся этим вопросом отсылаю к статье и на домашнюю страничку главной хакерской тулзы для wi-fi aircrack-ng). Сами WPA/WPA2 являются в некоторой степени надстройками над WEP, в том смысле, что основной формат пакета и алгоритм шифрования (для WPA) не поменялись, т.о. не было необходимости в смене оборудования, в большинстве случае достаточно было обновить прошивку (правильнее говорить не о WPA/WPA2, а о стандарте IEEE 802.11i; WPA — это его часть, включающая протокол управления ключами и шифрованием TKIP, WPA2 же полностью реализует стандарт, в том числе протокол CCMP с AES-шифрованием).
Поскольку форматы пакетов для всех протоколов имеют много общего, начнем с WEP пакета как самого простого:
Нас в этом пакете в наибольшей степени интересуют передаваемые данные (Network Data)
Здесь IV — это Initialization Vector, соль, необходимая для создания per-packet key. Data — это собственно передаваемые данные, формируемые вышележащими протоколами в стеке OSI (например, данные могут быть IP пакетом). IC (далее будем называть это поле ICV — Integrity Check Value) — это CRC32 чек-сумма от Data, служащая для проверки целостности данных. Data + ICV шифруются алгоритмом RC4 с ключом IV + WEP_key, т.е. полученным простой конкатенацией IV и пароля WEP. Размер IV — 24 бита, RC4 шифр использует ключи длины 64 или 128 бит. Отсюда понятно, почему пароли WEP бывают длины 5 или 13 символов (т.е. 40 или 104 бит).
RC4 — это потоковый шифр. Инициализируется ключом, после чего выдает последовательность псевдослучайных битов с равномерным распределением, называемую keystream. Эта последовательность может быть использована для шифрования данных (традиционно называемых plaintext) путем операции XOR, получающаяся последовательность обычно называется ciphertext.
Основные уязвимости WEP связаны с малой длиной IV, примитивном алгоритме получения per-packet key, уязвимостями самого RC4 алгоритма и его потоковой природой.
WPA
Итак, на этой картинке то, что я раньше называл Network Data, идет после MAC Header (чек-сумма FCS здесь не показана, как на рисунке для WEP; она нас не интересует, т.к. ее обработка ведется на нижележащем уровне модели OSI). IV — это тот же 24-битовый WEP Initialization Vector, только смысл его несколько иной, структура данных же пакета значительно усложнилась. Чтобы понять, что означают представленные поля, рассмотрим вкратце (а полностью рассматривать сил и времени нет, да и боюсь наскучить :-)) протокол TKIP, о котором я уже упоминал:
TKIP (Temporal Key Integrity Protocol) реализует три подхода к улучшению безопасности радио-протоколов семейства IEEE 802.11. Во-первых, это функция смешения ключей, которая комбинирует секретный основной ключ PTK (см. ниже) с вектором инициализации перед тем, как передать его в качестве ключа алгоритму RC4. Во-вторых, это последовательный счетчик (TSC — TKIP Sequence Counter) 48-битной длины, значение которого растет с каждым переданным пакетом. Пакеты, полученные в неверном порядке, будут отвергнуты (а именно, будут отвергнуты пакеты с более ранним TSC), что позволяет защищаться от так называемых replay-атак. Наконец, это 64-битный код защиты сообщения MIC (Message Integrity Code).
TKIP реализует также механизм rekeying'а — смены сессионных ключей и гарантирует, что каждый пакет будет передан с уникальным RC4 ключом.
Основной сессионный ключ PTK (Pairwise Transient Key) — это набор из 4-х 128-битных ключей, используемый для TKIP для шифрования отдельных пакетов в периоды между сменами ключей. Заметим, что PTK — это не пароль WEP и ни он, ни механизм его генерации частью TKIP не являются.
В PTK входят 4 ключа: один для шифрования данных в TKIP (назовем его TK), один для вычисления MIC (а его MTK) и еще два так называемых EAPOL ключа, которых я касаться не буду. Ключи генерируются с использованием пароля WPA (наконец-то, появился пароль!), известного обеим сторонам, в процессе четырехэтапного «рукопожатия» (картинка, там же довольно подробная статья на английском про WPA).
Возвращаясь к предыдущему рисунку со структурой пакета WPA, видим, что все, что между MAC Header и Data по сути — счетчик TSC плюс некоторые служебные поля, служащие для защиты от слабых ключей и говорящие, о том, что используется Extended IV. TSC устанавливается в нуль при начале сессии и монотонно увеличивается с каждым переданным данным устройством пакетом, емкости в 48 бит хватит на ~250 триллионов пакетов, что можно считать достаточным с учетом периодической реинициализации сессионных ключей (в отличии от 24-битного IV в WEP). Уникальный ключ для шифрования пакета вычисляется из TK, TA (Transmittor Address — MAC адрес передатчика) и TSC путем определенного двухфазного механизма хеширования, который дает на выходе 104-битовую строку, к которой добавляется WEP IV (да-да, тот самый 24-битовый IV) для получения 128-битового ключа (на самом деле рисунок про формирование ключа наглядный, но неточный, дотошные могут взглянуть на этот).
Уфф… Что там у нас осталось? Ах да, MIC.
Он создан в основном для борьбы с поддлекой (forgery) пакетов. Код вычисляется от данных всего сообщения (плюс адреса передатчика и приемника) еще до фрагментации и возможной смены порядка пакетов с помощью алгоритма под названием MICHAEL, генерирующего подпись длины 64 бит. Алгоритм, кроме данных, использует ключ, а именно, вышеупомянутый MTK. Что немаловажно, алгоритм в некотором смысле обратим, т.е. зная данные и MIC подпись, можно вычислить ключ MTK.
Борьба с подделкой со стороны Access Point происходит, собственно, так: если пришел пакет с неверным MIC (при этом он валиден по остальным признакам, т.е. имеет допустимое значение TSC и ICV сумма прошла проверку), то отправителю посылается уведомление и, если есть возможность, данное событие фиксируется в журнале как попытка взлома. Если в течение 60 секунд приходит еще один пакет с неверным MIC, точка доступа инициализирует rekeying с данным отправителем. Т.о. поддельные пакеты безнаказанно (относительно) можно слать не чаще, чем раз в минуту.
Chop-Chop атака
Из внушительного списка атак, к которым уязвим WEP, рассмотрим так называемую Chop-Chop атаку (от англ. chop, вольный перевод — «отрезать ломтик»). Эта атака позволяет узнать plaintext сообщения (т.е. данные сообщения до шифрования), а значит и RC4 keystream пакета (plaintext + keystream = ciphertext => keystream = ciphertext + plaintext). Атака использует тот факт, что CRC32 чек-сумма отнюдь не проходит по требованиям в криптографическую хеш-функцию.
Напомню, что идеологически CRC есть остаток от деления исходной строки S, представленной в виде многочлена (от X) с коэффициентами, равными соответствующим разрядам в ее двоичной записи, на предопределенный многочлен PCRC(X), причем арифметические операции выполняются в поле GF(2) (подробнee, например, в википедии). Однако, в такой форме CRC нечувствителен к нулям в начале и в конце исходной строки, поэтому на практике в начало и конец дописываются специальные строки (длины, равной количеству разрядов CRC), которые обозначим как Li (начало) и Lf (конец). Обычно обе они состоят из 32-х двоичных единиц. Таким образом, для CRC32:
CRC = (X32 * S + Li * Xn+32 + Lf) mod PCRC (1)
где n — длина S в битах.
Примечательно, что если к исходной строке S приписать справа ее CRC, то CRC от полученной строки будет постоянна и равна CRC пустой строки, которую обозначим за Pzero (доказывается очень просто, достаточно помнить, что в GF(2) сложение и вычитание суть одна и та же операция — XOR), или в виде формулы
(X32 * (X32 * S + CRC) + Li * Xn+64 + Lf) mod PCRC = Pzero (2)
В WEP-пакете последние байты данных (Network Data) — это зашифрованный ICV, т.е. CRC от сообщения. Забудем на время о шифровании и рассмотрим, что будет, если убрать последний байт, который обозначим как R, из пакета. Пусть Q — пакет без последнего байта, тогда Q уже навряд ли будет иметь нужный остаток (т.е. CRC). Но оказывается, что к Q можно прибавить некий многочлен M так, чтобы исправить CRC. Подставив сначала SO = Q * X8 + R, а затем S1 = Q + M в (2), легко найти, что
M = (X32)-1 * (1 + (X8)-1) * (Pzero + Lf) + (X8)-1 * R
Возвести многочлен P в -1ю степень означает найти такой многочлен P', что P * P' = 1 mod PCRC, что всегда возможно, т.к. PCRC неприводим и многочлены с операциями по модулю PCRC образуют поле. Кстати, степень М не превышает 32, т.к. M достаточно взять по модулю PCRC.
Если перебирать все байты R от 0 до 255 и отправлять их в сеть точке доступа, мы, в конце концов, наткнемся на правильный. Понять, что мы попали в байт в реальности также несложно: пакеты с неверным ICV тихо дропаются как переданные с ошибкой; если же CRC верна, мы вправе ожидать ответный пакет, например, в случае WPA, это обычно будет пакет, информирующий о неверном MIC. Но об этом чуть позже.
А как же шифрование? Оказывается, тот факт, что пакет шифрован, значения не имеет, т.к. шифрование RC4 алгоритмом сводится к XOR-иванию данных с keystream'ом, но прибавление M суть тот же XOR, а так как операция XOR коммутативна и ассоциативна, то и неважно, прибавлять M к исходным данным, а потом шифровать, или к уже зашифрованным.
Описанный процесс можно повторять дальше, «откусывая» по байту от сообщения, и теоретически можно расшифровать WEP пакет произвольной длины.
Атака на WPA
Перейдем, наконец, собственно, к теме статьи.
Итак, что будет, если попытаться применить Chop-Chop атаку к сети с WPA защитой?
TKIP имеет, в основном, 2 средства для защиты от подобных атак:
- Пакеты с неверной ICV, как я уже упоминал, отбрасываются. Если ICV угадана, но неверен MIC код, атакующий должен выдержать минуту, чтобы не спровоцировать смену ключей
- Если пакет принят, TSC счетчик для этого канала (TSC счетчики существуют отдельно для каждого канала, в которые данное устройство может слать пакеты; о каналах — чуть позже) увеличивается на 1. Пакеты с меньшим, либо равным TSC с этого момента отбрасываются (снова не совсем точно: на самом деле существует небольшое окно значений TSC, внутри которого пакеты принимаются, но не суть)
Первый пункт частично на руку атакующему, т.к. позволяет понять, когда он угадал очередной байт. Со вторым сложнее: действительно, пусть мы поймали ARP пакет, посланный одним из устройств в сети, его же поймала и Access Point, пересылать этот пакет ей еще раз бессмысленно, ведь TSC уже инкрементирован, плюс то первое устройство, возможно, наслало еще пакетов, увеличив счетчик еще больше. Авторы рассматриваемой атаки нашли выход в спецификации IEEE 802.11e, определяющей улучшения в QoS для сетей Wi-Fi. Сухой остаток здесь таков: устройства Wi-Fi поддерживают несколько очередей пакетов (именно их я выше назвал каналами; какое точно отношение они имеют к реальным радио каналам, я утверждать не берусь), по словам одного из авторов, Эрика Тьюза, предполагалось использовать 4 канала, в стандарте их 8, в реальности авторы обнаруживали до 16. Каналы обыкновенно не используются одновременно, экономя пропускную способность для важных пакетов. В ненагруженной сети часто весь трафик идет в один канал, т.о. пакет мы скорее всего поймаем на канале с высоким значением счетчика TSC, перепосылать же его можно, переключившись на менее нагруженный канал. Важно, что, опять же ссылаясь на авторов, при отсылке сообщения о неправильном MIC счетчик канала не увеличивается, т.о. дальше каналы можно не переключать.
Если в сети не поддерживаются QoS расширения, атака, в принципе, также осуществима, если удастся предотвратить попадание выбранного для дешифровки пакета на AP и отключить пославшее его устройство от сети.
Понятно, что пытаться расшифровать сколько-нибудь длинные пакеты по байту в минуту, дело довольно-таки безнадежное — стандартный Wi-Fi пакет имеет размер ~2300 байт, т.е. на него уйдет порядка полутора суток, а за это время или TSC счетчик увеличится, или ключи сменятся, или точка доступа сребутится, или Вас «запалят». Причем, имея одно устройство, ломать можно только один пакет.
Ну что ж, сниффер сделать не выйдет, посмотрим, что нам может дать расшифровка коротких пакетов, например, ARP, которые легко идентифицировать по их длине (14 байт). Собственно, атакующий знает большую часть содержимого APR пакета, а именно, заголовки и MAC адреса. Если можно также сделать и некоторые предположения об IP структуре взламываемой сети (в сети созданной из под Windows, например, можно ожидать, что IP адреса будут иметь вид 192.168.0.x), то угадать останется совсем ничего. Т.е., угадав 12 байт ICV + MIC, остальное можно просто подобрать, используя ICV сумму. Отсюда упомянутая в прессе цифра в 12 минут на взлом.
Что же дальше? Расшифровав один пакет, атакующий узнает RC4-keystream пакета (использовать его, правда, можно только, пока TSC не изменился) и, что более важно, сессионный MTK — я упоминал, что MIC обратим, и по данным и подписи можно установить ключ. Последнее означает, что до следующей смены ключей, нет необходимости больше угадывать MIC, и, например, чтобы взломать следующий ARP пакет (с теми же предположениями о структуре сети), уйдет 4-5 минут. Использовать дешифрованные данные для посылки forged пакетов можно, в зависимости от количества QoS каналов, от 7 до 15 раз (меньше, если трафик идет по более, чем одному каналу), дальше придется «чоп-чопить» другой пакет.
Заключение: степень угрозы и меры защиты
Если вспомнить сообщения в прессе до доклада Тьюза, например:
Erik Tews will show how he was able to crack WPA encryption… in a relatively short amount of time: 12 to 15 minutes… in order to read data being sent from a router to a laptop computer.
To pull off their trick, the researchers first discovered a way to trick a WPA router into sending them large amounts of data. This makes cracking the key easier, but this technique is also combined with a «mathematical breakthrough», that lets them crack WPA much more quickly than any previous attempt, Ruiu said.
www.pcworld.com
то очевидно, что краски «чуть-чуть» сгущены — читать трафик от AP к клиенту в реальности нельзя, да и как-то непонятно, что за «mathematical breakthrough» такой совершили авторы, ибо chop-chop атака известна аж с 2004 года…
Несмотря на то, что звучали заявления о взломе шифрования, сами WPA пароли и даже временные сессионные ключи (не считая MIC ключа) в полной безопасности. Атака позволяет расшифровать отдельные короткие пакеты, с которыми ведется работа, затрачивая в самом лучшем случае по 4-5 минут на пакет, и, используя результаты дешифровки, инжектировать очень ограниченное число столь же коротких пакетов обратно в сеть. Да, это, по всей видимости, первая серьезная атака, продемонстрировавшая уязвимость протокола TKIP, но абсолютному большинству волноваться по этому поводу причин не видно. По словам Тьюза: «если Вы использовали шифрование лишь для того, чтобы оградить свой интернет канал от использования случайными людьми, Вы в полной безопасности». Атака не может быть использована ни для подключения к домашней или корпоративной сети, ни для того, чтобы отслеживать в них трафик.
Тем не менее, мелкие пакости теоретически сделать можно, как то: «отравить» ARP (может быть, и DNS) кеш, прочитать некоторый объем приватного трафика, Тьюз также указывает на возможность обмануть некоторые фаерволы.
Какими методами можно бороться с такого вида атаками?
Ну, во-первых, конечно же, можно просто перейти на WPA2 с AES шифрованием. Также авторы советуют уменьшить время регенерации ключей точкой доступа (вплоть до 2-3 минут, что сделает в принципе невозможными описанные выше процедуры) и отключить автоматическую отсылку сообщений о неверном MIC в принятом пакете. К сожалению, неясно, предоставляют ли современные точки доступа такие тонкие параметры настройки (лично я вот понятия не имею, если кто-то встречал, было бы интересно узнать).
Что ж, вряд ли можно сказать, что WPA взломан. Более того, я думаю, что пока волноваться особенно не о чем. Однако, цитируя один из источников, «теперь, когда эти двое (Бек и Хьюз) открыли дверь, WPA наверняка привлечет пристальное внимание тысяч исследователей: белых, серых и черных».
Материалы и ссылки
Battered, but not broken (популярная и доступная статья об атаке)
Статья Бека и Тьюза
Статья о WPA
Презенташка (в статье использовал пару картинок)
aircrack-ng
Неплохая статья о CRC и теории ее взлома
Статья о способах быстрого взлома WEP и FMS атака в викиредии
Disclaimer
Прошу не судить строго, не являюсь специалистом по информационной безопасности и беспроводным протоколам, ни даже любителем, скорее из интересующихся :-) И заранее прошу прощения, если перегрузил статью теорией и подробностями.