Попытаемся все же разобраться, что случилось и чем это может нам грозить. Поскольку криптографические атаки — вещь, требующая для понимания весьма много специфических знаний, статью можно считать в некотором роде ознакомительной с безопасностью в 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 бит). Основные уязвимости WEP связаны с малой длиной IV, примитивном алгоритме получения per-packet key, уязвимостями самого RC4 алгоритма и его потоковой природой. WPA Итак, на этой картинке то, что я раньше называл 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 с данным отправителем. Т.о. поддельные пакеты безнаказанно (относительно) можно слать не чаще, чем раз в минуту. Chop-Chop атака Из внушительного списка атак, к которым уязвим 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 пакет произвольной длины. Атака на 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 раз (меньше, если трафик идет по более, чем одному каналу), дальше придется «чоп-чопить» другой пакет. Заключение: степень угрозы и меры защиты Если вспомнить сообщения в прессе до доклада Тьюза, например: то очевидно, что краски «чуть-чуть» сгущены — читать трафик от AP к клиенту в реальности нельзя, да и как-то непонятно, что за «mathematical breakthrough» такой совершили авторы, ибо chop-chop атака известна аж с 2004 года… Несмотря на то, что звучали заявления о взломе шифрования, сами WPA пароли и даже временные сессионные ключи (не считая MIC ключа) в полной безопасности. Атака позволяет расшифровать отдельные короткие пакеты, с которыми ведется работа, затрачивая в самом лучшем случае по 4-5 минут на пакет, и, используя результаты дешифровки, инжектировать очень ограниченное число столь же коротких пакетов обратно в сеть. Да, это, по всей видимости, первая серьезная атака, продемонстрировавшая уязвимость протокола TKIP, но абсолютному большинству волноваться по этому поводу причин не видно. По словам Тьюза: «если Вы использовали шифрование лишь для того, чтобы оградить свой интернет канал от использования случайными людьми, Вы в полной безопасности». Атака не может быть использована ни для подключения к домашней или корпоративной сети, ни для того, чтобы отслеживать в них трафик. Тем не менее, мелкие пакости теоретически сделать можно, как то: «отравить» ARP (может быть, и DNS) кеш, прочитать некоторый объем приватного трафика, Тьюз также указывает на возможность обмануть некоторые фаерволы. Какими методами можно бороться с такого вида атаками? Ну, во-первых, конечно же, можно просто перейти на WPA2 с AES шифрованием. Также авторы советуют уменьшить время регенерации ключей точкой доступа (вплоть до 2-3 минут, что сделает в принципе невозможными описанные выше процедуры) и отключить автоматическую отсылку сообщений о неверном MIC в принятом пакете. К сожалению, неясно, предоставляют ли современные точки доступа такие тонкие параметры настройки (лично я вот понятия не имею, если кто-то встречал, было бы интересно узнать). Что ж, вряд ли можно сказать, что WPA взломан. Более того, я думаю, что пока волноваться особенно не о чем. Однако, цитируя один из источников, «теперь, когда эти двое (Бек и Хьюз) открыли дверь, WPA наверняка привлечет пристальное внимание тысяч исследователей: белых, серых и черных». (с) _habrahabr.ru/blogs/infosecurity/
