Вот уж точно, ровно 50%: суслик либо есть, либо его нет Надеюсь, все местные завсегдатаи знают что такое WPA хэндшейк, как и где его лучше ловить и что с ним потом делать. В этой небольшой заметке я хочу сконцентрировать внимание на самом процессе хендшейка, или говоря научным языком, проведения процедуры аутентификации беспроводной точки доступа (AP) и клиента беспроводной сети. Итак что мы имеем в начале пути? Мы знаем, что каждый беспроводный интерфейс имеет псевдоуникальный шестибайтовый MAC-адрес, обычно записываемый через двоеточие или тире, например 00:03:BF:08:CA:04. Только шесть байт на интерфейс и больше ничего. Со стороны точки доступа (далее AP, Access Point) этот адрес именуется BSSID. Но поскольку людям свойственна тяга к прекрасному, а цифры скучны и однообразны, разработчики семейства стандартов 802.11 добавили нам каплю радости в виде возможности называть свои любимые сеточки красивыми именами, например xyi, kvartira_22 или Trump4President. Для этого они ввели еще один идентификатор, в терминологии 802.11 он называется ESSID или просто SSID, это обычная строчка символов длиной до 32 байт (именно байт, а не символов, т.к. символы в ESSID допустимы и многобайтные). Помимо своего развлекательного назначения, ESSID играет весьма важную роль в процессе аутентификации клиента и AP, но об этом чуть позже. Каждая WPA-PSK или WPA2-PSK сеть имеет статически предустановленный пароль (собственно PSK, или Pre-Shared Key это он и есть). Стандартом оговорен лимит длины пароля от 8 до 63 символов в кодировке ASCII. Пароль устанавливается владельцем точки доступа и затем он же вводится пользователем мобильного устройства при подключении к сети. Пароль статичен, это важно. В процессе аутентификации и вообще обмена данными по протоколам семейства 802.11 принимает участие туева хуча самых разных статических и динамических ключей. Все они имеют более-менее вменяемые названия и зачастую легко вычисляются, но вполне могут запутать человека мало знакомого с этим процессом. Чтобы было более понятно, основные ключи и связи между ними приведены на рисунке 1 (рисунок не мой, нашел в интернете). Далее мы поверхностно пройдемся по процедуре вычисления этих ключей и роли каждого из них. Прежде чем начать процедуру аутентификации, каждая из сторон вычисляет PMK (Pairwise Master Key). PMK это статический ключ, вычисляемый с помощью воздействия алгоритма PBKDF2 на пару ESSID+пароль. Как следует из названия (мастер-ключ), этот ключ является важнейшим во всей процедуре аутентификации. Алгоритм PBKDF2 включает в себя 4096 циклов хэширования по алгоритму HMAC-SHA1, и нужен исключительно для усложнения жизни хакерам пытающимся подбирать пароли WPA, т.к. им для проверки каждой следующей кандидатуры пароля нужно заново пересчитать хэш SHA-1 4096 раз, что нехило нагружает считалку. Важно заметить, что исходными данными для PBKDF2 наравне с паролем является и ESSID сети, а это значит что если мы не знаем ESSID или знаем, но неточно, рассчитать PMK "как надо" нам не удастся и все попытки аутентифицироваться будут безуспешны. В случае подбора пароля WPA важен не то что каждый символ, а каждый бит ESSID атакуемой сети, не говоря уже о кодировке, регистре символов и возможных пробелах до и после них. Именно поэтому "голого" хэндшейка недостаточно для полноценной атаки на WPA, а желательно еще наличие beacon frame или другого метода однозначного определения ESSID атакуемой сети. Все, у нас закончены все приготовления, PMK посчитан, начинаем процесс аутентификации. Естественно, инициатором является клиент, который начинает обмен с AP пакетами Probe Request, Authentication и Association Request. AP отвечает пакетами Probe Response, Authentication и Association Response, где указывает свои возможности и пожелания, и начинает процесс собственно EAPOL-аутентификации отправкой первого (из четырех) ключевого пакета EAPOL (Wireshark называет его Key 1/4, мы будем называть также). Чтобы упростить понимание процедуры аутентификации, смотрим на рисунок 2. В первом пакете содержится только ANonce - "придуманное" AP псевдослучайное 256-битное число, призванное внести некий элемент динамики в процесс аутентификации. Получив от AP ANonce, клиент аналогично "загадывает" подобное число со своей стороны, назовем его SNonce, и вычисляет сессионный ключ PTK (Pairwise Transient Key). Вычисление PTK также выполняется с помощью HMAC-SHA1, а в качестве параметров задаются собственно мастер-ключ PMK, BSSID, MAC-адрес клиента, свежепридуманные ANonce и SNonce и, зачем-то, строка с фразой "Pairwise key expansion" (ну захотелось им так). Вычислив сессионный ключ PTK, клиент не передает его в эфире, а вместо этого отвечает вторым ключевым пакетом key 2/4, который содержит SNonce и некий проверочный код MIC (Message Intergity Code), который вычисляется как HMAC-MD5 от первых 16 байт PTK (иногда называемых KCK, Key Confirmation Key) и собственно тела EAPOL frame с заполненым нулями полем MIC. AP, получив SNonce, теперь имеет все необходимые ингридиенты для вычисления PTK, чем и занимается сразу после получения второго ключевого пакета. Вычислив PTK, AP затем временно запоминает MIC из пакета клиента, зануляет поле MIC в EAPOL frame, вычисляет свою версию MIC и сравнивает его с запомненым значением MIC полученным от клиента. В случае совпадения, продолжает процедуру аутентификации (да-да, мы еще только на середине пути). Если же вычисленное значение MIC не совпадает с вариантом клиента, AP завершает процедуру аутентификации и игнорирует последующие пакеты. Для продолжения процесса аутентификации AP вычисляет групповой сессионный ключ GTK используя случайное значение GMK, шифрует GTK с помощью ключа шифрования ключей KEK (Key Encryption Key, пздц...), также являющегося частью PTK. Процесс вычисления GTK в принципе похож на вычисление PTK, и для упрощения и без того сложного рассказа мы вполне можем его опустить, нам оно сейчас не надо. Важно то, что вычисленное и зашифрованное значение группового сессионного ключа GTK передается в третьем пакете хендшейка (от AP к клиенту), равно как и новое значение MIC, смысл которого (помимо контроля целостности сообщения) убедить клиента что AP знает и умеет вычислять PTK, а значит не является Fake AP и к ней можно подключаться. Новое значение MIC вычисляется аналогично предыдущему как HMAC-MD5(KCK, EAPOL frame с зануленным полем MIC) и для нас является важнейшим параметром. Почему? Ответ в следующем абзаце. Итак, получив от АР третий пакет, клиент расшифровывает ключ GTK, рутинно проверяет значение MIC и если все в порядке, вычисляет MIC еще раз по той же схеме и отправляет в сторону AP четвертый пакет с очередным новым значением MIC, получение которого означает для AP что ключи шифрования на клиенте установлены успешно и теперь можно гнать зашифрованный трафик. Теперь перейдем к тому, зачем мы морщили ум и все это писали и читали. При подборе паролей к WPA хендшейкам иногда складывается ситуация когда пароль подобрался по хендшейку (ура!), причем самыми разными программами включая aircrack-ng, но увы "не подходит" к сети. Чисто физически причин подобному явлению может быть несколько, однако учитывая сложность процесса аутентификации и количество циклов хеширования данных на всех этапах, все нюни про нестабильность приема сигнала, интерференцию и помехи с соседних каналов и т.д. можно смело отбросить и остается только одна причина - пока мы ловили хендшейк кто-то (а зачастую это и есть сам "хакер") пытался подключиться к АР c неправильным паролем. В результате мы имеем "обрезанный" заведомо левый хендшейк из двух первых ключевых пакетов, в котором MIC есть только во втором пакете, идущем (внимание!) от клиента к АР. А значит, подбором мы найдем пароль "верный" по версии клиента, но неверный для АР. Имея в своем распоряжении третий ключевой пакет от АР к клиенту, мы без всяких сомнений можем убедиться, что АР умеет вычислять PTK (еще бы!), а значит, быть уверенными, что найденный пароль верен для точки доступа. Строго говоря, для полноценной атаки достаточно только 2-го и 3-го ключевых пакетов, т.к. параметр ANonce передается и в первом, и в третьем. Если же никто не мешал "истинному" клиенту аутентифицироваться на собственной точке доступа, а нам в силу различных причин (интерференция, помехи, бла-бла-бла) от всего хендшейка достались только два первых пакета, но в целости и сохранности - не беда, это вполне рабочая ситуация и моя практика показывает, что в подавляющем большинстве случаев из двух первых пакетов удается подобрать вполне себе неплохой парольчик. Самая хреновая ситуация когда ключевые пакеты битые. Тогда пароль будет либо неподобрать вообще, либо (что крайне сомнительно и я бы сказал невозможно) он подберется неверно. Еще один важный вывод - все ключевые пакеты всегда должны относиться к одному хендшейку. Виною тому случайные числа ANonce и SNonce, различные для разных сессий. Взяв первый и второй пакет (или второй и третий) от разных хендшейков, успеха не добьешься. Небольшой апдейт: Еще легче понять ситуацию можно разглядывая формат всеми любимого файла .hccap, вот он: Что мы видим? Сначала идут компоненты PTK: ESSID, BSSID, MAC клиента, ANonce (1 или 3 пакет), SNonce (2-й без вариантов), потом один EAPOL frame (2 или 3 пакет) и MIC соответствующий этому пакету, и всё, больше ничего нет! При этом если EAPOL frame и его MIC взяты из второго ключевого пакета - всего лишь невозможно проверить умеет ли AP вычислять PTK, т.е. подходит ли к ней возможный пароль. Если из третьего - никаких проблем. Какие могут быть варианты если у нас только первых два пакета? 1. Пароль не найден - неопределённость (пароля нет в словаре, пакеты от разных хендшейков, просто битые пакеты) 2. Пароль найден но не подходит - кто-то подключался с неправильным паролем в момент снятия хендшейка 3. Пароль найден и подходит - здесь всё понятно А если есть второй и третий? Всё то же самое, кроме п.2 \\ добавил в Карту раздела.
Если уж меня процитировали, то отвечу. Моя практика показывает, что в большинстве случаев неудача при подборе пароля является результатом битых пакетов в перехваченном файле. Особенно если перехват сделан с помощью besside-ng. Пакеты от разных хэндшейков определяются сразу по счётчику и по времени прибытия, в расчёт не берутся и отсекаются сразу. Логично. Да вот besside-ng никогда не собирает 3-ий пакет, следовательно атака на 1 и 2 "неполноценна"!? Ваши слова. А многие, если не большинство новичков, используют именно besside-ng в разных "обёртках". И что в итоге получили? Путём долгих и кропотливых разбирательств в сути происходящих процессов при аутентификации клиента на точке, в итоге мы и пришли к тому, что вероятность наличия пароля в "неполноценном" хэше с пакетами "1/4 + 2/4" около 50%. Именно "наличие", а не вероятность "нахождения". Для новичков столь подробное углубление в детали слишком утомительно и трудно для восприятия. К тому же в интернете уже давно полно таких статей - изучай на здоровье если есть желание. Я же в двух(!) предложениях изложил самую суть. Всем понятно - все довольны. Чего и вам желаю!
Хорошая статья от участника gpuhash, можно сказать мат.часть. А я попробую описать то же самое чуть другими словами, может кому-то будет проще. Представьте, начинающий пентестер решает проверить на возможность подключения какую-то точку wi-fi. Он берет свой смартфон (планшет, нетбук, ноутбук) и пытается подключиться по паролям типа 12345678, 123123123, qwertyui, 1qaz2wsx и другим подобным «паролям простаков». После какого-то количества неудачных попыток он бросает это занятие и начинает изучение задачи. Через какое-то время ему удается записать переговоры точки с каким-то клиентом (хендшейк) и он начинает подбирать пароль перебором или просит помощи. И каково же его удивление, когда он сам или другие брутеры находят, что паролем, о котором идет речь в хендшейке, является один из тех «паролей простаков», которые он уже пробовал, но они не подошли. А все дело в том, что те гаджеты, на которых начинающий пентестер пробовал подключиться к точке, продолжают попытки подключения по последнему испробованному неудачному паролю и пойманный хендшейк – это как раз запись этих самых попыток. Были случаи, когда начинающий пентестер уверенно утверждал, что он не пробовал найденный в хендшейке пароль. Брутеры же настаивали, что в хендшейке именно такой пароль, какой они называют, хотя он не позволяет подключиться к точке. Это значит, что кто-то еще пытался подключаться к точке и так же бросил свои попытки не удалив эту точку из списка возможных в своем гаджете, и именно эти продолжающиеся попытки подключения и были записаны в хендшейк. Почти невероятно, но возможно, что точку пытаются изучать сразу два начинающих пентестера! И как же диагностировать такую ситуацию? Наибольшее распространение получила запись переговоров (хендшейка) в файлы формата .cap/.pcap. Их содержание можно посмотреть в программе wireshark. В мат.части выше сказано, что если есть три из четырех или все четыре ключевых пакета, то можно утверждать, что клиент успешно подключился к точке. Если только первые два пакета из четырех, то этого утверждать нельзя, это вполне могли быть и шальные попытки подключения с неправильным паролем. Еще в мат.части выше сказано, что для возможности подбора пароля необходимо наличие в хендшейке «привязки» к названию точки wi-fi. Как правило для «привязки» используют пакет Beacon frame, но еще подойдут Probe Response или Association Request (смотреть в wireshark). В сети очень во многих местах в инструкции о том, как пользоваться программой CommViewforwifi написано, что beacon пакеты не нужны и предлагают поставить галочку на Игнорировать beacon. Это странно, потому что эти пакеты необходимы для «привязки» в процессе перебора в любой программе. (Встречали фразу «нет бекона»?) Одной из программ для подбора паролей является hashcat. Для нее необходимо провести конвертацию хендшейка из .cap файла в .hccap, при которой из файла .cap берется только минимум необходимых данных. Конвертируют обычно утилитой aircrack-ng, которая до сих пор развивается и некоторые ее бета версии глючно проводили конвертацию. Чтобы минимизировать возможность глюков, рекомендуется оставлять в .cap файле лишь необходимый минимум - лишь пакет-«привязку» и пару ключевых пакетов, желательно 1-й и 2-й (Key (Message 1 of 4) и Key (Message 2 of 4)). Вот почему большинство утилит и скриптов для ловли хендшейков, получив эти пакеты сразу заканчивают запись в .cap файл, а некоторые даже удаляют лишние ненужные пакеты. Казалось бы, для уверенности, что подбирается не шальная попытка подключения, нужно выбирать 2-й и 3-й ключевые пакеты, но брутеры на форумах пишут, что самый лучший вариант с точки зрения минимизации возможного пропуска пароля (а такое случается) - это оставлять для перебора или конвертации 1-й и 2-й ключевые пакеты. Наличие 3-го ключевого пакета в хендшейке лишь убеждает, что это было реальное подключение, а не попытка. Для перебора 3-й ключевой пакет не нужен при наличии 1-го и 2-го. В мат.части выше упоминалось, что ключевые пакеты должны быть близки по времени друг к другу (принадлежать одной сессии переговоров). При этом пакет-«привязка» может быть далеко по времени, даже вставлен из другого хендшейка другой календарной даты. Каков временной диапазон сессий у различных устройств сказать трудно. Были случаи успешного подбора пароля по ключевым пакетам с разницей в 12 секунд, а бывало, что 6 секунд -это уже разные сессии и пароль не находился (находился потом в другом, правильном хендшейке). Считается, что интервал до 1 секунды – это хорошо, а в идеале не более 0.05 секунды. Еще пакеты могут быть неполными, как говорят «битыми». В wireshark сильно "битые" пакеты выделяются красным. Но бывает так, что не хватает совсем немного данных или они не полностью соответствуют стандартам, и тогда wireshark указывает на это подсвечивая часть данных в пакете голубым цветом во втором окне (если встать на интересующий пакет). Иногда с такими, отмеченными голубым пакетами подобрать пароль не получается, хотя процесс перебора идет как обычно, а иногда получается. Видимо это зависит от устройств и от характера "голубой" проблемы - вопрос в стадии изучения. Теперь должно быть понятно, почему брутеры просят предоставлять для перебора хендшейк в виде .cap/.pcap файла. Они предпочитают самостоятельно выбрать пакеты и, при необходимости, самостоятельно конвертировать его прежде чем начать перебор. А если найденный пароль не позволит подключиться к точке, то отсутствие 3-го и 4-го ключевых пакетов в хендшейке даст одну из возможных причин.
Не надо передергивать. Написано "для полноценной атаки достаточно только 2 и 3 пакетов", т.е. все четыре не нужны. Не написано, что хендшейк из 1 и 2 пакетов является неполноценным. Далее по исходному тексту разбираются все возможные ситуации. Да ничего подобного, я в корне не согласен, что если в хендшейке два пакета, то вероятность что он рабочий 50%. Ну бред же. Неполноценным хэндшейк может быть и с третим битым пакетом. Почему второй пакет может быть битым, а третий нет? Заколдован? И откуда вообще такая цифра в 50%? Я про вероятность нахождения пароля кстати вообще нигде не говорю. В последнем абзаце вроде четко указано - разница между 1/2 и 2/3 наступает только в случаях когда пойман левый хендшейк. Именно левый, когда клиент вводил неверный пароль и получил отлуп. Этих случаев 50% что ли? Или я что-то не так понимаю в хендшейках. Вот из-за таких скоропалительных заявлений про 50% люди будут выкидывать годные хендшейки. Смысл этой статьи как раз разобраться какой хендшейк годный, а какой нет.
Никаких "передёргиваний" нет и в помине. Только ваши слова. Раз существует атака полноценная, то и неполноценная тоже обязана существовать! Иначе такие заявления - просто выдумка... Бред? Ваше право. Мне практика как-то ближе, чем рассуждения на тему "может быть - не может быть"... "...потому что не может быть никогда". А вот на практике и выходит те самые 50 на 50. Се-ля-ви. Вот где "бред"! Выкинуть годный хэш - убыток на миллион! Лучше поймать один хороший хэндшейк, чем десяток "обрезанных" - вероятность взлома выше. Потому что валидный пароль в нём присутствует, хоть и в виде хэша. Не согласны - ваше дело, "каждый выбирает по себе: женщину, религию, дорогу"...
На этом обсуждение предлагаю прекратить, ибо моя практика как раз доказывает обратное, и при этом полностью согласуется с теорией.
ловить стандартным инструментом, airodump. Всякие автоматические перехватчики типа besside или kismet лучше не использовать, они обрезают хендщейк до 2 пакетов, это делает утилита wpaclean, которая неоднократно замечена в порче хендшейков. Проверять вручную, открыв cap файл в wireshark и найти где хендшейк. Вот так выглядит идеальный, 1000% рабочий хендшейк. Но это только хендшейк, а для успешного перебора ещё нужен пакет с именем сети, Beacon Frame или Probe Responce пакет подойдет прекрасно. *** Вот так в идеале должен выглядеть тот файл, который пойдет на перебор. Ни один брутер не придерется ни к чему, а для вас - это 1000% процентов гарантии успешного перебора, в случае, если пароль найдется в словарях.
Code: wlan.fc == 0x8000 || wlan.fc == 0x5008 || eapol.type == 3 Вот вам быстро-фильтр для Wireshark, который будет показывать необходимый минимум пакетов. Первое выражение пропускает Beacon frame, второе - Probe Response, а третье - собственно хендшейки. Остаётся только посмотреть на тайминги, чтобы выбрать идеальный набор пакетов для выкладывания в соответствующей теме.
из всех скриптов, программ для автоматического перехвата хендшейков, которые встречались мне, только одна программа захватывает полный пакет хендшейка -это minidwep-gtk, кроме того сохраняет свой результат в трех форматах .cap, .hccap и .wkp
Code: (eapol || wlan.fc.type_subtype == 0x08) А вот вам ещё фильтр - ничего лишнего. Code: wps.wifi_protected_setup_state == 0x02 Для WPS.
А теперь яркий пример того, для чего в реальности нужен полный шейк со всеми пакетами, и важны временные интервалы между пакетами. Пару часов назад (относительно времени написания сего поста) в тему с перебором был сброшен шейк, снятый с отличным сигналом, и к нему был прикреплен перечень промешенных словарей, в которых пароля, естественно, не нашлось. Spoiler: Цитата запроса Качаем хендшейк, и смотрим что там есть. Spoiler: Большая картинка А там картина маслом: у пакетов нет временных отметок, да еще и один пакет подсвечен синим, с флагом R - означает, что пакет был передан повторно. На лицо использование софта для автоматической чистки cap файлов от мусора: cleancap или wpaclean, не важно. Важно то, что этот софт тупо видя первый и второй пакет, просто склеивает их в один файл. В теме была дана просьба переловить, и был сброшен новый, полный шейк. Посмотрим на него: Spoiler: Большая картинка То же самое, но теперь с подробностями: первый ключевой пакет был переотправлен + временная метка 64:81, в то время как остальная часть имеет метку 64:92. Может это не критично? Иногда такие шейки удается подобрать, но посмотрим внимательнее на 1 и 3 пакет. Напоминаю, что хеши в 1 и 3 пакете ДОЛЖНЫ быть одинаковыми, это указывает на то, что перед нами полный хендшейк. Spoiler: Картинка Всего лишь 2 байта разницы и пароль к хендшейку не подберется. Что собственно и произошло, испробовано масса словарей и уйма времени была потрачена ЗРЯ на подбор пароля к битому рукопожатию. А пасс оказался простым и из ходового словаря.
Все хендшейки без временных меток и только с message 1 и 2-это лотерея.Анализировать невозможно,выбирать не из чего. В теме перебора полно таких проходило,где либо вообще ничего не находилось,либо были захвачены "левые" пароли. Если нравится такое,можно и дальше пользоваться besside. И в самой последней версии конвертера cap в hccapx для хэшкета https://hashcat.net/cap2hccapx/ из-за отсутствия временных меток будете получать отказ вот такого вида и это правильно. Zero value timestamps detected in file: in ***.cap. This prevents correct EAPOL-Key timeout calculation. Do not use preprocess the capture file with tools such as wpaclean.
