Пользователь
0,0
рейтинг
18 июня 2014 в 12:08

Разработка → Wi-Fi сети: проникновение и защита. 3) WPA. OpenCL/CUDA. Статистика подбора



Баста карапузики, кончилися танцы.

В предыдущей части мы детально рассмотрели «читерские» приёмы обхода «защит» (скрытие SSID, MAC-фильтрация) и защит (WPS) беспроводных сетей. И хотя работает это в половине случаев, а иногда и чаще — когда-то игры заканчиваются и приходится браться за тяжёлую артиллерию. Вот тут-то между вашей личной жизнью и взломщиком и оказывается самое слабое звено: пароль от WPA-сети.

В статье будет показан перехват рукопожатия клиент-точка доступа, перебор паролей как с помощью ЦП, так и ГП, а кроме этого — сводная статистика по скоростям на обычных одиночных системах, кластерах EC2 и данные по разным типам современных GPU. Почти все они подкреплены моими собственным опытом.

К концу статьи вы поймёте, почему ленивый 20-значный пароль из букв a-z на пару солнц более стоек, чем зубодробительный 8-значный, даже использующий все 256 значений диапазона.

Оглавление:
1) Матчасть
2) Kali. Скрытие SSID. MAC-фильтрация. WPS
3) WPA. OpenCL/CUDA. Статистика подбора


PMK, PTK, РПГ




Как всегда, начнём с теории. Строго говоря, она нам не нужна, чтобы подбирать пароли, и кому лень — могут пропустить этот раздел до практики. Однако, на мой взгляд, знать, как происходит проверка подлинности клиента и шифрование данных — очень полезно и объяснит все трудности, которые мы, как атакующий, испытываем при попытке взломать этот протокол. Более детальное описание понятным английским языком с разбором форматов всех пакетов авторизации можно найти здесь.

WPA и WPA2 (первый основан на черновике IEEE, второй — на финальной версии, но в нашем случае оба можно считать синонимами) используют довольно хитрую схему обмена ключами. Вернее, их необмена. Как мы помним по первой части, самое слабое место в любой защите — это передача ключей, даже зашифрованных — ведь хакер может перехватить эти значения и попытаться подобрать по ним изначальный ключ в offline-режиме, то есть никак более не общаясь с точкой доступа или клиентом. Разработчики WPA устранили всякий обмен и шифрованными, и открытыми паролями. Как это всё работает как раз и будет описано ниже.

Начнём с конца. Допустим, мы хотим передать зашифрованный пакет данных. Для этого нам нужны сами данные и ключ, по которому алгоритм вроде AES (а именно он используется в CCMP) преобразует их в нечто неудобоваримое шифрованную форму. Дешифровать данные обратно можно передав этому же алгоритму шифрованную строку и ключ, который использовался для зашифровки.

Самый простой способ — использовать в виде ключа сам пароль от беспроводной сети. Однако это чревато серьёзными проблемами:

  • Слишком быстрые вычисления — если мы знаем начальные байты исходных данных (а почти всегда это так, ведь в начале идёт какой-нибудь стандартный заголовок), то простым перебором мы сможем попробовать дешифровать перехваченный пакет, подставляя разные пароли и смотря, что получилось на выходе — если он содержит похожий на корректный заголовок, то скорее всего мы нашли исходный пароль.
  • Гарантия на всю жизнь — если каким-то образом мы узнали пароль, то сможем расшифровать всё, что передавалось ранее и будет передано позднее, пока администратор не сменит ключ сети. А как показывает практика, даже при смене роутера люди обычно ставят на него старый пароль, так что надеяться на их благоразумие не, гм, благоразумно.
  • Отсутствие защиты от любопытного соседа — если мы можем авторизоваться в сети, то ничто не помешает нам читать пакеты других клиентов и даже произвольно подменять их, так как тапки одни на всех пароль, используемый для шифрования наших данных, используется и для всех остальных клиентов в рамках этой сети

Это похоже на то, как если бы между нами и конечной целью стояло много-много дверей, каждая из которых ведёт внутрь. Двери — клиенты сети, «нутрь» — сама сеть. Если ко всем дверям подходит одинаковый ключ, то мы можем пройти через соседнюю дверь и посмотреть, что там происходит.

Вторую и третью проблемы легко устранить, добавив к ключу случайное значение, которое меняется каждый раз при запуске защищённого соединения и даже в процессе его работы. Первую — очень длинным ключом. Но тогда встаёт вопрос: кто будет его помнить если его будет вводить не человек, то как получить этот длинный ключ из короткого (от пользователя), да ещё и не подверженному атаке на перебор?

Для этого есть два стандартных решения: либо введение ограничений на число попыток входа, либо многократное шифрование, чтобы замедлить процесс получения конечной строки. Первый вариант не подходит, так как он годится для online-атак (обычно на формы входа на веб-сайты) и бесполезен, когда сам хэш уже «утёк». А вот второй — как раз наш случай.

Однако и тут есть проблема: если мы просто прогоняем некий алгоритм 10 000 раз на нашей исходной строке с паролем, то возможен вариант, когда хакер создаст словарь, предварительно прогнав этот же алгоритм на всех возможных комбинациях паролей, и затем всё, что ему останется — перехватить рукопожатие и посмотреть хэш в нём по таблице, которую он уже успел вычислить. Если в таблице такой хэш есть — значит, есть и исходная строка, из которой он был вычислен, и она ему известна. А затем ту же самую таблицу можно использовать для расшифровки других данных. Такая таблица называется радужной (rainbow table). Особую популярность техника получила при подборе паролей в украденных базах старых форумных и прочих движков на PHP.

Решается это добавлением «соли» — случайной или более-менее уникальной строки, которая даже при совпадении самих паролей сделает вычисленные хэши разными.

Посмотрим, как авторы стандарта WPA справились с этими задачами:

Схема шифрования данных в рукопожатии

Схема выше отражает процессы, происходящие параллельно на обеих сторонах (клиенте и точке доступа), а не то, что передаётся по радиоканалу — это важно и об этом ниже. Ещё до начала вычислений и клиент, и ТД уже имеют следующие данные:

  • Пароль сети, как он указан администратором — на схеме 12345678 (ай-яй-яй, какой несознательный администратор)
  • Имя сети (SSID) — аналогично указан администратором — на схеме mynet
  • MAC-адрес клиента — на схеме FF:EE:DD:...
  • MAC-адрес точки доступа (BSSID) — на схеме 11:22:33:...

Всё начинается с того, что «короткий пароль» (от пользователя) преобразуется в более длинный ключ с добавлением секретного ингредиента имени беспроводной сети — для этого используется PBKDF, что можно приравнять к вычислению хэша по SHA-1 4096 раз подряд (если вы думаете, что это много, то скажите об этом Microsoft — Word 2007 делает это 50 000 раз). В результате у нас получается 256-битная строка, то есть 32 байта. Обратим внимание, что она уникальна для разных сетей с одинаковыми паролями, если у них разные имена. Важный вывод: всегда меняйте стандартное имя сети и не оставляйте ASUS, dlink, SKY, linksys и прочие неоригинальные названия. Этим вы предотвратите атаку по радужным таблицам, усложнив перебор на 4096 итераций SHA-1, что много. (Справедливости ради надо сказать, что я не слышал о применении такой атаки к WPA, но зачем давать хакеру лишний шанс?)

Строка, полученная выше, называется PMK (Pairwise Master Key — главный парный ключ). Она статичная, то есть нам не стоит шифровать данные с её помощью, ведь она, как и пароль, не меняется, если не меняется имя сети — а, значит, нет разницы шифрованием по PMK и по самому паролю (о проблемах этого было сказано в начале). Соответственно, точно так же, как и паролем, мы не должны «светить» и PMK.

Поэтому дальше нам нужно получить временный, очень длинный и очень уникальный ключ, который бы мы использовали конкретно для данного сеанса передачи данных. То есть временный ключ. То есть PTK (Pairwise Transient Key — кратковременный парный ключ). Для этого используется тот же алгоритм PBKDF, но передаются ему на вход 5 значений:

  1. PMK — уже вычислен на основе пароля и имени сети
  2. A-Nonce — это просто случайная строка, переданная точкой доступа на запрос клиента о подключении (самый первый пакет при авторизации)
  3. S-Nonce — ещё одна случайная строка, но переданная клиентом к ТД в следующем пакете
  4. BSSID точки доступа (MAC-адрес)
  5. MAC-адрес клиента

Итак, связав 5 значений в строку и прогнав их 4096 раз через SHA-1 мы получили 256-битный PTK. Именно он и будет использоваться для шифрования всех данных от клиента к ТД и обратно.

Последний этап — проверка на то, что клиент на самом деле обладает верным паролем к сети, из-за которого-то всё и затеяно. Вы ведь не забыли, что описанные манипуляции происходят на обеих сторонах независимо и без взаимодействия друг с другом, если не считать пересылки двух nonce? В этом случае, имея разные исходные данные стороны получат разные PTK и если, скажем, клиент зашифрует свой трафик и отправит точке доступа, то та не сможет его расшифровать из-за того, что её PTK отличается от ключа, которым был зашифрован поток у клиента. Разные «исходные данные» здесь — это, конечно, в первую очередь пароль от сети, так как исходит он от нестабильного элемента — человека, тогда как MAC-адреса, имя сети и прочее исходит от «железа», которое между собой обычно договаривается без проблем.

Для проверки переданного пакета данных к нему добавляется MIC — Message Integrity Code, или код целостности сообщения. В WPA для его вычисления используется HMAC-MD5 (разновидность всем известного MD5). К слову, все знакомы с CRC32 — это ещё один алгоритм для подобных целей, часто используется для проверки файлов в архиве. Полученный в результате код также называют хэш-суммой.

Идея в том, что подав на вход хэш-функции (MD5, CRC, SHA и других) любой поток данных произвольной длинны мы получим некую строку на выходе, которая будет уникальна для этого потока данных. Естественно, 100% уникальность невозможна — если выходная строка 4 байта, то при всём желании она не сможет вместить все возможные входные комбинации. Тем не менее, алгоритм создан так, что найти, какие ещё строки могут выдать точно такой же хэш, мы не можем (на самом деле для слабых алгоритмов вроде CRC это не так; они используются для проверки данных на случайное повреждение, а не умышленную фабрикацию).

Соответственно, представим, что нам нужно передать строку 12345 и при этом позволить принимающей стороне проверить, что в процессе передачи строка не изменилась. Для этого мы прибавим к ней её собственный хэш:

input  = 1 2 3 4 5
sha1(1 2 3 4 5) = 8cb2237d0679ca88db6464eac60da96345513964
output = 1 2 3 4 5 | 8c b2 23 7d 06 79 ca 88 db 64 64 ea c6 0d a9 63 45 51 39 64

При приёме устройство отрезает хэш от принятого сообщения (после "|"), вычисляет хэш-сумму для того, что было слева, и сравнивает обе части. Сошлись — значит, ничьи ловкие ручки к данным не прикасались.

… Но, конечно, всё не так просто. Легко заметить, что зная алгоритм вычисления хэш-суммы атакующий может поменять сообщение, вычислить его новую сумму и заменить старую на новую. Что делать? А гори оно всё синим пламенем! А мы снова добавим «соль» — значение, которое знает принимающая сторона, но не знает хакер. Тогда вычислить новый хэш он уже не сможет.

Схема шифрования данных в рукопожатии

Снова посмотрим на эту схему, на этот раз нас интересует последняя строка. MIC составляется из PTK и потока байтов самого сообщения. PTK — это как раз наша «соль» (как мы помним, PTK используется и для шифрования самого потока, и теперь ещё для вычисления его хэш-суммы, то есть MIC). Поток и PTK передаются в HMAC-MD5 и полученный хэш называется MIC. Он передаётся вместе с сообщением принимающей стороне, которая декодирует пакет, вычисляет его MIC и если этот MIC отличается от того, который был найден в самом пакете — считает, что кто-то влез в процесс передачи или просто была не лётная погода, и отбрасывает этот пакет.

А теперь внимание: как нам понять, что клиент обладает верным паролем к сети и, как следствие, вычислил верный PTK, без передачи этого самого PTK? Просто: попробовать зашифровать первое сообщение на одной стороне и посмотреть, смогут ли его расшифровать на другой. Если использовались одинаковые PTK — значит при расшифровке полученный MIC совпадёт с переданным. Если разные — MIC не сойдутся, как следствие, PTK были разные, как следствие, PMK были разные, и, как следствие, исходные пароли тоже были разные.

Напоследок для закрепления — упрощённая схема того, что, собственно, передаётся в открытом виде по радиоканалу при рукопожатии.


Как видим, из всех более-менее закрытых данных хитрые парни в IEEE обошлись передачей одного MIC, который к тому же передаётся уже зашифрованным с помощью PTK.

Карамба!


(Оригинальный арт.)

Что делать, Семёныч?


Надеюсь, мой краткий обзор пролил кое-какой свет на то, какую чёрную магию используют инструменты вроде aircrack-ng и hashcat при попытке определить пароль в рукопожатии. Как мы теперь знаем, им нужно раскрутить всю цепочку назад, имея на руках всего-навсего хэш-сумму одного из пакетов (MIC). А именно, сделать следующее:

  1. Первым делом вычислить главный ключ сети — PMK. Для этого берётся пароль и имя сети. Последнее берётся из перехваченных пакетов рукопожатия (об этом ниже), а первый можно брать из словаря по одному или перебирать всё доступное пространство ключей «в лоб», но только если вы джедай и обладаете особой уличной магией в виде пары GPU.
  2. Дальше вычисляется PTK — хэш-сумма из полученного PMK (выше), MAC-адресов клиента и ТД и случайных nonce-строк от них же (берутся из перехваченных пакетов).
  3. Наконец, для пакета, переданного с MIC, вычисляется MIC на основании PTK, полученного выше, при этом переданный MIC игнорируется (так как он зависит от всего сообщения, в том числе самого MIC, то перед вычислениями это поле устанавливается в 0, иначе невозможно вычислить сумму, не зная MIC, для вычисления которого нужно знать эту сумму).
  4. Оба MIC сравниваются — если совпали — пароль найден (PTK верен > PMK верен > пароль верен), если нет — go to line 1

Таким образом, каждая итерация требует как минимум 8192 вычислений SHA-1, который в 3 раза медленнее MD5. Это очень затратный процесс. А что мы получим в итоге?

А в итоге — только исходный пароль и PTK того незадачливого клиента, аутентификацию которого мы перехватили. Это значит, что мы не сможем прочитать потоки других клиентов — у них другие PTK. Мы не сможем прочитать данные, которые этот клиент передал до того, как подключился — у него тоже был другой PTK. Мы даже не сможем прочитать то, что он передаст после того, как подключится в следующий раз — ведь PTK снова изменится!

Это очень важный вывод, который в четвёртой статье цикла нам будет очень кстати при перехвате пакетов в Wireshark. Там нам придётся не только получить пароль от сети, как описано в этой статье, но и перехватить рукопожатия всех клиентов, которых мы хотим прослушать (либо использовать ARP-спуфинг, но это атака на другом уровне). Та ещё работёнка.

Кстати, опыт с PTK — сын ошибок трудных в WEP, где для шифрования всех потоков клиентов всегда использовался одинаковый ключ.


К оружию!




С теорией всё, обещаю. Теперь только практика — отсюда и до обеда.

Итак, ещё раз: наша задача — перехватить первые 4 пакета, которыми обмениваются клиент и точка доступа (по 2 с каждой стороны) при установлении соединения. В сумме они называются рукопожатием (handshake). После них начинается уже шифрованная передача данных, из которой нам ничего не вытащить. Кстати, эти пакеты — часть протокола EAP (или EAPOL), и под таким именем они фигурируют в Wireshark (см. следующую статью цикла).

Перехватив их мы можем сохранить их к себе и затем провести offline-атаку — то есть попытаться подобрать оригинальный пароль к сети, поочерёдно пробуя разные пароли для генерации PMK > PTK > MIC и сравнивая последний с тем, который был передан на самом деле, как это было описано выше.

Перехват делается с помощью airodump-ng, с которой мы уже знакомы по второй части. С параметрами можете поиграть, о них писалось там же, но в общем случае вызов выглядит так:
airodump-ng mon0 -c 5 --bssid AP_BSSID -w caps

Перед этим вам нужно перевести свою карту в «хакерский режим» (monitor mode) и проделать все прочие манипуляции (смена MAC, txpower и т.д. — см. вторую часть).

В команде выше мы используем интерфейс под идентификатором mon0 для сбора пакетов атакуемой сети на канале 5, которая имеет MAC, указанный после --bssid, сохраняя пакеты в файл caps-NN.cap (по умолчанию используется стандартный формат libpcap, который поддерживается очень многими библиотеками на всех ОС, в том числе и Wireshark). NN будет заменено на уникальное число, таким образом при повторных запусках airodump-ng с теми же параметрами старые файлы не будут перезаписаны, а будут иметь имена вида cap-01.cap и дальше.

Допустим, что атакуемая нами сеть имеет BSSID 4F:B1:A4:05:5C:21 и находится на канале 11. Тогда делаем так:
airodump-ng mon0 -c 11 --bssid 4F:B1:A4:05:5C:21 -w caps

После запуска откроется уже знакомое консольное окно с двумя таблицами. Оставим его висеть, пока кто-нибудь не подключится к нашей сети…

Но ведь мы можем ускорить этот процесс! Читатель помнит про то, что мы можем отключить имеющихся клиентов и заставить их передать данные аутентификации повторно — очень полезно для таких непоседливых хакеров, как мы. Уже знакомая aireplay-ng с радостью поможет нам:
aireplay-ng mon0 -0 5 -a 4F:B1:A4:05:5C:21 -c 5B:23:15:00:C8:57

5B:23:15:00:C8:57 — MAC-адрес клиента, который мы почерпнули из таблицы запущенного ранее airodump-ng.

Если всё сделано правильно, aireplay-ng выведет 5 строк вида Sending directed deauth, а в окне с airodump-ng мы должны наблюдать быстро увеличивающееся число «потерянных» пакетов (в графе Lost). Оно может пойти на тысячи.

После этого наш дорогой клиент, если он был в радиусе действия нашего передатчика и если он был активный (иногда устройство остаётся подключенным к сети, но не использует её, и отключение не заставляет его переподключиться), тут же начнёт авторизацию заново и мы поймаем эти пакеты, о чём в правом верхнем углу airodump-ng победно сообщит надписью [ WPA handshake: 4F:B1:A4:05:5C:21 ] (MAC-адрес сети, рукопожатие с которой было перехвачено).

Если так и случилось — атака проведена успешно, airodump-ng можно закрывать, копировать полученный caps-01.cap на флешку и сматываться. Ещё бы — ведь у нас в руках есть ключи…

Зашифрованные.

Подбор пароля

Первая часть с перехватом рукопожатия обычно самая простая, особенно в сетях со множеством активных клиентов. Мы получили пакеты с MIC и прочими данными авторизации. Теперь нужно найти, какой же из наших ключей подойдёт к этому замку?

Подбор требует больших вычислительных мощностей и ради них можно арендовать EC2-кластер или даже собрать свою ATI-ферму. А можно просто прогнать пакеты через словарь самых распространённых паролей на обычном ЦП с надеждой, что пользователь ССЗБ. Последнее, кстати, очень может быть — на протестированных мной 11 сетях одна использовала пароль «12345678», вторая — «123456789», а пять других — пароли из 8 цифр, которые на средней системе взламываются за сутки. При этом из оставшихся 4 три были взломаны ещё за двое суток через WPS (см. вторую часть). А последняя была моя (на самом деле нет, но её пароль мне так и не удалось подобрать.)

Не повторяйте таких ошибок.

Другой часто встречающийся вариант — номер телефона (только цифры). Особенно актуально для сетей фирм, магазинов, кафе. Обычно такой «пароль» висит прямо на входе в заведение. Сгенерировать все номера, если известен код, можно через crunch 10 10 -t 063%%%%%%% (RaSta).

aircrack-ng

Самый простой способ перебора. aircrack-ng использует только ЦП, зато отлично поддерживает многопоточность. Она перебирает значения по словарю для WPA-сетей (также умеет взламывать WEP).

Kali идёт с набором словарей в /usr/share/wordlists/, но их при желании можно легко найти на просторах Интернета любого размера — от мегабайт до десятков гигабайт. Довольно хорошая компиляция — WPA-PSK Wordlist 3 Final, а также сгенерированный словарь из всех комбинаций 8-значных числовых паролей, который получается с помощью crunch 8 8 1234567890

aircrack-ng -w /usr/share/wordlists/fasttrack.txt caps-01.cap

/usr/share/wordlists/fasttrack.txt (идёт в комплекте с Kali) — путь к словарному файлу с паролями, один пароль на строку. Строки короче 8 символов будут проигнорированы, так как это минимальная длина для WPA.

На моём i7 3840QM 4x3.8 GHz aircrack-ng выжимает ~4700 паролей в секунду. Таким образом, мы можем подсчитать, сколько времени птребуется для полного перебора всех возможных комбинаций из 8 цифр:
(10^8) / (4700 * 3600) = 5,91 часов

Проверить скорость подбора без собственно подбора (бенчмарк) можно так:
aircrack-ng -S
# 4713 k/s

А так можно посмотреть, сколько при подборе будет использоваться ядер:
aircrack-ng -u
# No CPU detected: 8  (SSE2 available)

Итого, за 6 часов можно перебрать 10 миллионов паролей на high-end мобильном ЦП. Цифровой пароль такой длинны не стоит рассматривать в качестве серьёзной защиты, и даже не поэтому — применив ГП (GPU), который даёт в десятки и сотни раз большую скорость, такой пароль сломается за минуты. Об этом ниже.

Если атака прошла успешно, то есть aircrack-ng нашла пароль, то она завершит работу и на экране будет выведено радостное KEY FOUND! [ ... ] — запишите его и используйте для входа в сеть. Также можно записать найденный пароль в файл через -l pass.txt, что полезно при запуске перебора в фоне как aircrack-ng ... -l pass.txt &

Пояснения по формуле выше:

  • 10^8 — 10 в степени 8, число возможных комбинаций; вычисляется как число_возможных_символов ^ длина_строки. К примеру, для 6-значного пароля из латинских символов в нижнем регистре будет 266 = 308 915 776 комбинаций. К слову, это наглядно показывает, что длина пароля имеет куда большее значение, чем возможное число символов в нём: запомнить "this weirdo voodoo" куда проще, чем "0.o@&z%_" — тогда как комбинаций первого на 1025 больше (десять и 24 нуля).
  • 4700 — число сравнений паролей в секунду (скорость перебора)
  • 3600 — приведение результата деления от паролей в секунду к паролям в час (60 секунд * 60 минут)

Ещё подсчёты для сравнения:
 (26^8) / (4700 * 3600 * 24)        = 514 суток для перебора 8-значного пароля с a-z
(10^10) / (4700 * 3600 * 24)        = 24,6 суток для 10-значного цифрового пароля
(26^10) / (4700 * 3600 * 24 * 365)  = 952 года для 10-значного пароля с a-z
(10^12) / (4700 * 3600 * 24 * 365)  = 6,7 лет для 12-значного цифрового пароля
(10^14) / (4700 * 3600 * 24 * 365)  = 674,6 лет для 14-значного цифрового пароля

Статистику для более длинных строк нет смысла вычислять, если речь идёт только о ЦП. Но перед тем, как делать выводы, подождите, пока мы не познакомимся с голиафами от ATI.

Мир сошёл с ума или GPGPU — «ГП общего назначения»



Времена, когда игры были тёплыми и ламповыми, а графические процессоры имели по 4 Мб памяти использовались по прямому назначению, уже давно прошли. Сегодня их, кажется, используют для всего чего угодно, но не для игр. По крайней мере я не видел геймеров с 8-мью R290X в одной системе, а вот «майнеров», «фолдеров» и прочих гиков с целыми стойками — хоть отбавляй. Почему так?

Графические чипы по своим конструкционным особенностям кардинально отличаются от архитектуры ЦП. Если с ЦП мы говорим о 4, 8, 16 ядрах (не берём сервера), то в случае с ГП речь идёт о тысячах независимых ядер. При обработке графики нужно быстро выполнять операции над большими массивами — матрицами. И именно такие операции и нужны в криптографии. Поэтому ГП можно использовать для вычисления хэшей — или добычи криптовалют.

ГП можно собирать вместе в рамках одной системы, а системы — в кластеры, создавая «фермы». При колоссальном отрыве в производительности от обычных ЦП куда эффективнее собрать ферму из 10 систем с 4 ГП, чем из 10 систем с 4 ЦП.

Дать большую производительность могут только ASIC и FPGA — специальные устройства, которые можно программировать на выполнение определённых вычислений, но с ними надо возиться и писать отдельный софт, а ГП и SDK к ним существуют уже давно и начать писать под них сравнительно легко. Особенно привлекательно выглядят ATI-шные карточки, которые благодаря своей архитектуре на порядок превосходят карточки от nVidia конкретно для этих задач, и при этом значительно дешевле. Не иначе, как инженеры AMD сами балуются с LTC.

В контексте нашей задачи подбор паролей с использованием ГП могут делать две замечательные программы: hashcat и pyrit.

hashcat — закрытая, бесплатная утилита для молниеносного вычисления хэшей различных форм, используя различные алгоритмы (MD5, SHA, WPA и ещё пару десятков), с применением правил к словарным словам и даже с добавлением соли. На мой взгляд это лучшее, что существует на сегодня. Немного огорчает закрытость проекта, но автора можно понять — это большая работа.

hashcat состоит из трёх программ: hashcat (не использует ГП и по моим тестам по скорости сравнима с pyrit и немного медленнее aircrack-ng, которая вообще работает быстрее всех на ЦП); oclhashcat для OpenCL (SDK от ATI) и cudaHashcat (nVidia). Последние две идентичны в возможностях, но должны соответствовать производителю вашего ГП. Перед их работой нужно поставить драйвера и SDK, так как без них ядра ГП опознаны не будут.

pyrit — открытый инструмент для подбора WPA-ключей на Python. В целом приятная программа, для своих целей подходит замечательно. Так же имеет версии для ЦП и обоих производителей ГП, однако работает только с WPA. В отличии от oclhashcat, pyrit использует и ЦП, и ГП, тогда как oclhashcat — только ГП. Автор последней объясняет это тем, что выигрыш минимален, а затрат по программированию много.

Установка драйверов

Итак, посмотрим, как нам задействовать этот инструментарий. Описанный ниже механизм был выявлен после многих часов борьбы с Kali, CUDA и исходниками Pyrit, поэтому надеюсь, что он сэкономит это время для вас. Всё было успешно протестировано на версии Kali 1.0.7 x64 и версиях cuda_6.0.37_linux_64 и NVIDIA-Linux-x86_64-331.67. На ноутбуке используется Optimus (технология от nVidia для переключения между встроенным ГП от Intel). В документации Kali есть страница об установке драйверов nVidia — тоже может пригодиться.

Изначально в Kali не установлены программы для работы с ГП, так как сегодня есть два соперничающих стандарта (OpenCL от AMD и CUDA от nVidia), и кроме того, CUDA использует закрытые драйверы, а не стандартный nouveau. Поэтому придётся устанавливать всё самим.

Для начала установим заголовки исходников ядра Linux:
apt-get install linux-headers-`uname -r`

Далее скачиваем драйвера для nVidia и SDK для CUDA. Ссылки на RUN-файлы возьмите с сайта nVidia и из раздела CUDA.
wget http://.../NVIDIA-Linux-x86_64-331.67.run
wget http://.../cuda_6.0.37_linux_64.run

Дальше нам нужно выйти из оконного менеджера (X). На самом деле эта загадочная фраза (в мануалах — shutdown the X server/session) обозначает буквально следующее:
shutdown 0

Это переведёт систему в maintenance/single user mode. Kali запросит пароль от root или нажатие Ctrl+D — последнее приведёт к повторному запуску GNOME, что нам совсем не нужно. Вводим пароль, который по умолчанию toor, и попадаем в консоль. Там выполняем:
modprobe -r nouveau
chmod +x *.run
./NVIDIA-Linux-x86_64-331.67.run
./cuda_6.0.37_linux_64.run

При этом при установке драйверов (предпоследняя команда):

  1. Выбираем No, когда установщик сообщает нам, что мы должны быть в runlevel 3 (перейти в него через telinit 3 у меня не получилось, так как он всё так же ругался, но на нормальной работе дальше это никак не отразилось)
  2. Выбираем No при вопросе об установке 32-битных версий (для 64-битных систем)
  3. Последний вопрос будет об установке закрытых драйверов nVidia в качестве системных (с заменой nouveau) — у меня они вешали X после перезагрузки и я решил с этим не возиться, поэтому ответил No

Для установщика CUDA отвечаем n, когда он захочет установить драйвера nVidia (второй вопрос после принятия лицензии) — этот момент мне не понятен, но устанавливая драйвера через него установка всегда заканчивается с Installation failed, тогда как ставя, по идее, те же самые драйвера через скачанный ранее первый установщик всё проходит успешно.

На все остальные вопросы установщика CUDA отвечаем y. Samples можно ставить, можно нет (занимают около 230 Мб).

Для проверки работоспособности поставленной CUDA можно запустить nvcc (находится в /usr/local/cuda/bin) — если прошло без ошибок, значит всё работает.

Если в процессе установки отключился интерфейс проводной сети (иногда бывает) — его можно поднять так:
ifconfig eth0 up
dhclient eth0

Наконец, если с установкой что-то не так и вы хотите вернуть старый драйвер, чтобы снова открыть GNOME — вначале загрузите обратно nouveau, а затем нажмите Ctrl+D.:
modprobe nouveau

Все манипуляции с драйверами рекомендую проводить после загрузки ОС в read only (см. вторую часть), так как повредив драйвер очень легко потом лишиться нормального рабочего стола и придётся обходиться консолью в поисках проблемы.

Установка cpyrit_cuda и oclhashcat

Теперь можно ставить собственно сами утилиты. hashcat ставится через apt-get install -y oclhashcat (для обеих версий OpenCL/CUDA), а pyrit собирается из исходников (внимание: используйте последнюю версию в trunk, так как в текущей стабильной версии есть баг, из-за которого компиляция может не пройти на некоторых nVidia, как это было с моей картой).

Установка pyrit (если у вас OpenCL — см. документацию на сайте проекта):
apt-get install -y libpcap-dev python-scapy
svn checkout http://pyrit.googlecode.com/svn/trunk/ psrc
cd psrc/pyrit
sudo python setup.py build
sudo python setup.py install
cd ../cpyrit_cuda
sudo python setup.py build
sudo python setup.py install

Сборка закончена. Посмотрим, нашёл ли pyrit наши карточки:
pyrit list_cores

В случае успеха будет выведено #0 GPU ... — по одной строчке на каждое ядро, плюс по одной строке на каждое ядро ЦП (правда, на моей системе одно ядро процессора «съелось» ядром ГП — возможно, pyrit не поддерживает больше 8 потоков).

Дальше мы можем запустить тест и через 10-20 секунд узнать примерную скорость перебора с использованием возможностей ГП:
pyrit benchmark

На моей системе и pyrit, и hashcat выдают 10 500 (ГП) + 4 000 (ЦП) паролей в секунду, что лишний раз подтверждает непригодность nVidia для подобных вычислений (у меня GeForce GTX 675MX). Аналогичная мобильная карточка от ATI выдаёт около 40 000 п/с.

Итак, запустим перебор на pyrit:
pyrit -r caps-01.cap -e MYNET -i /usr/share/wordlist/fasttrack.txt attack_passthrough

Параметры аналогичны параметрам aircrack-ng. Когда совпадение будет найдено pyrit завершит работу и ключ будет виден на экране.

Если при запуске pyrit и hashcat появляются предупреждения об ACPI — их можно игнорировать, если вычисления идут нормально. У меня их бывает по 10-15 штук.

Если мы хотим перебрать все цифровые пароли определённой длинны — это можно сделать двумя способами: на лету или сгенерировав словарь на диске. Для генерации словарей у Kali есть несколько утилит, одна из них — crunch:
crunch 8 10 0123456789 | pyrit -r caps.cap -e MYNET -i - attack_passthrough

-i - говорит pyrit читать пароли из stdin, а 8 10 — минимальный и максимальный длины генерируемых crunch слов, состоящих из символов 0123456789. Не имеет смысла генерировать словарь с сохранением на диск, так как файл будет в 112 Гб и их можно сэкономить, так как на скорости перебора генерация на лету никак не скажется.

Запуск hashcat

Так как hashcat — более универсальная утилита, то синтаксис её параметров сложнее, и кроме того, она принимает на вход не стандартный файл libpcap (который мы ранее сохранили через airodump-ng), а собственный — *.hccap.

Процесс преобразования из .cap в .hccap описан в официальной вики. Делается это просто: сначала мы убираем из файла все пакеты, кроме рукопожатия, а затем преобразуем оставшиеся в .hccap: На сайте там же есть online-конвертер, принимающий файлы размером до 5 Мб — если вас вопрос приватности не очень волнует, то можно воспользоваться и им (делает он то же самое, что описано ниже).

wpaclean clean.cap caps-01.cap 
aircrack-ng clean.cap -J hashcat

Получившийся в итоге hashcat.hccap передаём в hashcat, oclhashcat или cudahashcat. Кстати, wpaclean (идёт вместе с Kali) иногда может вырезать не те пакеты, поэтому можно пользоваться скриптом с этого сайта. Если файл был обрезан не верно, то подобрать пароль становится невозможно (сообщений об ошибок не будет, просто aircrack, hashcat, pyrit и пр. будут рапортовать о том, что пароль не найден, даже если в вашем словаре настоящий пароль был).

За подробностями по работе hashcat я отправлю вас в oclhashcat -h и к её отличной документации. Ниже — несколько коротких примеров.

Так можно запустить простой перебор по маске (здесь -m2500 обозначает подбор ключа в WPA-рукопожатии, -a3 задаёт режим подбора по маске, а ?d... — саму маску для генерации слов (?d обозначает символы 0-9, а восемь ?d подряд обозначают 8 цифр одна за другой):
oclhashcat -m2500 -a3 caps.hccap ?d?d?d?d?d?d?d?d

Аналогично, но перебор по словарю (-a0 можно не указывать):
oclhashcat -m2500 -a0 caps.hccap /usr/share/wordlists/fasttrack.txt

А так мы запускаем простой перебор подряд (-a3) паролей по хэшам в файле ~/hashes.txt, вычисленных по алгоритму sha1(пароль+соль) (-m110), причём пароли шестизначные и имеют форму [A-Z] [A-Z0-9] [A-Z0-9] [A-Z0-9] [A-Z0-9] [0-9]:
oclhashcat -m110 -a3 -1?d?l ~/hashes.txt ?u?1?1?1?1?d

Наконец, так можно запустить тест на скорость:
oclhashcat -b

Найденные пароли будут отображаться на экране, а также записываться в файл /usr/share/hashcat/hashcat.pot, либо для ГП-версий — в /usr/share/oclhashcat/hashcat.pot.

Пока утилита работает, в терминале можно нажать на Enter для вывода текущего состояния (скорости, оставшемся % и прочего). Если нажать на q, то программа прервётся, сохранив состояние, и продолжить с того же самого места можно используя ту же самую командную строку с добавленным -s 1234, где число обозначает номер сессии (оно выводится в момент выхода из утилиты).

Amazon EC2

Для интереса я прогнал подбор WPA-ключей на двух самых мощных кластерах от AWS: cc2.8xlarge (32 ядра ЦП) и g2.2xlarge (1 nVidia Tesla и 8 ядер ЦП):

g2.2xlarge  = 22000 k/s [pyrit+cuda]
cc2.8xlarge = 14000 k/s [aircrack-ng]
              13500 k/s [pyrit]

Как видим, даже ультра дорогая карта от nVidia не справляется с задачей вычисления хэшей так, как средние ГП от ATI. На самом деле Tesla даёт даже меньшую скорость, чем обычные GTX. Оно и понятно — у неё совсем иное назначение. А вот почему ATI так хорошо в это дело вписались — интересный вопрос…

И, конечно, 32 серверных ядра не способны потягаться даже с Tesla.

Почему AMD настолько превосходит аналогичные решения nVidia? Дело в большем числе потоковых процессоров (ядер), как следствие, более быстрых операциях над целочисленными значениями (не числах с плавающей точкой, которые в криптографии не нужны) и в особенности — благодаря специальным инструкциям, которые можно использовать при шифровании (BIT_SELECT и BFI_INT).

Кто хочет попробовать сам — устанавливается aircrack-ng на EC2 с Debian или Ubuntu так:
sudo yum install gcc libnl-devel openssl-devel
wget http://download.aircrack-ng.org/aircrack-ng-1.2-beta3.tar.gz
tar xf aircrack-ng-1.2-beta3.tar.gz
cd aircrack-ng-1.2-beta3
sudo make install

Статистика


Вот теперь, посмотрев, как ЦП и ГП справляются с перебором паролей, можно делать выводы. Ниже — статистика по некоторым современным на сегодня (июнь 2014) видеокартам. Данные получены по нескольким моим системам, от товарища chem_ua и открытых источников (golubev.com, страницы oclhashcat и форума). Сравнить возможности разных карт относительно друг друга можно по обширной таблице в вики Litecoin и аналогичной у Bitcoin.

Цифры — ориентировочные, зависят от конфигурации системы, ОС, температуры/охлаждения и разгона. Если у вас есть свои данные — поделитесь в комментариях или лично, я добавлю их в таблицу. kh/s — число вычислений и сравнений паролей в секунду в тысячах (10 kh/s = 10 000 паролей в секунду).

nVidia  670           24 kh/s
nVidia  675MX         11 kh/s
nVidia  780M          42 kh/s
nVidia  580           47 kh/s
nVidia  Tesla K20     85 kh/s
nVidia  750 Ti        55 kh/s
nVidia  Titan Black   108 kh/s
AMD     280X          160 kh/s
AMD     290X          190 kh/s
AMD     295X*2        203*2 kh/s
AMD     5870          101 kh/s
AMD     5870          153 kh/s
AMD     6870          72 kh/s
AMD     6990          181 kh/s
AMD     7970          128 kh/s
AMD     7990          220 kh/s

Внимание: хотя цифры зашкаливают даже при сравнении low-cost ГП (к примеру, 5870 за $90) с результатами ЦП помните, что в отличии от последних графические процессоры, и в особенности от AMD, потребляют в десятки раз больше электроэнергии (к примеру, желательно иметь БП на 0,75-1 кВт для всего двух 290X). Так что перед покупкой такого «генератора» вначале посчитайте, во сколько обойдётся вам ежемесячный счёт на электричество, особенно если планируется их разгонять. Либо посмотрите на 750 Ti, для которой нужно всего 300 Вт.

Сухой остаток

Знакомство с вычислением хэшей с помощью ГП даёт нам понять, насколько всё печально какова истинная цена коротким и «сложным» паролям. Это относится не только к WPA — как раз PBKDF подвержен этому меньше из-за своей ресурсоёмкости. Если взять верхнюю на сегодня планку для одиночной системы — 8 AMD 290X, что в сумме около $3000 — получается 1,5 миллиона WPA-хэшей в секунду, или 94 миллиарда MD5-хэшей.

Таким образом, озвученные выше цифры по времени на перебор для WPA выглядят так:
 (26^8) / (1500000 * 3600) = 38,7 часов для перебора 8-значного пароля с a-z (было 514 суток)
(10^10) / (1500000 * 3600) = 2 часа для 10-значного цифрового пароля (было 25 суток)
(26^10) / (1500000 * 3600 * 24 * 365) = 3 года для 10-значного пароля с a-z (было 952 года)
(10^12) / (1500000 * 3600 * 24)       = 7,7 дней для 12-значного цифрового пароля (было 7 лет)
(10^14) / (1500000 * 3600 * 24 * 365) = 2,1 года для 14-значного цифрового пароля (было 674 года)

Как видим, цифры изменились кардинально. Более того, если мы посмотрим на стойкость паролей с MD5 (который вычисляется в 61 000 раз быстрее, и это без rainbow-таблиц, которые, впрочем, бесполезны для длинных паролей из-за своего объёма):

 (26^8) / (94000000000)      = 2 секунды для перебора 8-значного пароля с a-z
(10^10) / (94000000000)      = 100 миллисекунд для 10-значного цифрового пароля
(26^10) / (94000000000 * 60) = 25 минут для 10-значного пароля с a-z
(10^12) / (94000000000)      = 10,6 секунд для 12-значного цифрового пароля 
(10^14) / (94000000000 * 60) = 17,7 минут для 14-значного цифрового пароля 

MD5 и SHA1 (который всего в три раза медленнее первого) до сих пор используются многими сайтами для хэширования паролей пользователей, часто без добавления соли, хотя и они ситуации сильно не меняют. Так как мы не можем поручиться за благонадёжность всех сайтов, где регистрируемся (особенно имея перед глазами пример крупного сайта — Adobe), то использовать цифровые пароли длиной менее 20 символов (см. ниже) или буквенные длиной менее 14 — по меньшей мере безрассудно. И дело даже не в добавлении скобочек и точек (которые некоторыми сайтами вообще запрещены в паролях по каким-то своим соображениям) — как видим, разница между 10-значным цифровым и буквенным паролями продлит стойкость последнего где-то на полчаса.

Так что же делать?

Как говорится, спасение отца русской демократии — дело рук самой демократии. Посмотрим, что получается, если мы добавим по 4 символа к длине пароля:

(26^10) / (1500000 * 3600 * 24 * 365) = 3 года для перебора 10-значного пароля с a-z
(26^12) / (1500000 * 3600 * 24 * 365) = 2 017 лет для перебора 12-значного пароля с a-z
(10^16) / (1500000 * 3600 * 24 * 365) = 211 лет для 16-значного цифрового пароля
(10^18) / (1500000 * 3600 * 24 * 365) = 21 140 лет для 18-значного цифрового пароля

И для MD5:

(26^12) / (94000000000 * 3600 * 24)       = 11,6 дней для перебора 12-значного пароля с a-z
(10^16) / (94000000000 * 3600 * 24)       = 1 день для 16-значного цифрового пароля
(10^18) / (94000000000 * 3600 * 24)       = 123 дня для 18-значного цифрового пароля
(26^16) / (94000000000 * 3600 * 24 * 365) = 14 710 лет для перебора 16-значного пароля с a-z
(26^14) / (94000000000 * 3600 * 24 * 365) = 21,7 лет для перебора 14-значного пароля с a-z
(26^16) / (94000000000 * 3600 * 24 * 365) = 14 710 лет для перебора 16-значного пароля с a-z
(10^20) / (94000000000 * 3600 * 24 * 365) = 34 года для 20-значного цифрового пароля
(10^22) / (94000000000 * 3600 * 24 * 365) = 3 373 года для 22-значного цифрового пароля

Как видим, даже «быстрый» MD5 длиной от 16 буквенных символов ломать уже не имеет смысла. Тем более при отсутствии «словарных» слов такой длины — если только мы не говорим о qwertyuiopasdfghjk.

Данная идея — о важности длины пароля, а не его содержимого — не нова. Три года назад XKCD нарисовал свой исторический стрип:


(«Спустя 20 лет постоянных усилий мы, наконец, преуспели в том, что научили людей придумывать сложные для запоминания пароли, которые легко подбираются компьютером.»)

А в апреле Стенфорд опубликовал новые требования к паролям, которые сводятся к тому, что на пароли длиной от 20 не накладываются требования к алфавиту (не обязательно наличие цифр, букв в верхнем регистре и так далее).


При всём этом печально выглядят требования таких организаций, как Альфа-Банк, где длина пароля ограничена 16 знаками без допуска большей части спецсимволов. Сразу понятно, для чего такие пароли нужны.

Подведём итог: чтобы не оставить злоумышленнику шансов подобрать пароль для WPA стоит придумать 12-значный буквенный пароль и если в ближайшие годы квантовый компьютер не станет доступен массам — бояться нечего. Ну, а для паролей к сайтам достаточно 16 символов и если они не хранят их в открытом виде — что бы вы не придумали, это так и останется тайной. До следующего пришествия компьютеров.

(Примечательным и неожиданным примером сайта, хранящем пароли в открытом виде, является форум ixbt.ru: «Пожалуйста, имейте в виду, что Ваш пароль не будет закодирован и может быть просмотрен администратором конференции. » — так что будьте бдительны!)

На этом экскурс в дебри вычислений закончен. В следующей, вероятно, последней статье цикла — о прослушивании трафика беспроводной сети после того, как вы туда проникли.

Понравилась ли вам статья? Был ли понятно изложен процесс рукопожатия? Были ли ошибки/неточности в описании (для знатоков)? Есть чем поделиться? Жду ваших комментариев, которые к тому же ускорят написание следующей части!

Оглавление:
1) Матчасть
2) Kali. Скрытие SSID. MAC-фильтрация. WPS
3) WPA. OpenCL/CUDA. Статистика подбора
Павел @ProgerXP
карма
121,7
рейтинг 0,0
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (57)

  • 0
    sudo yum install gcc libnl-devel openssl-devel

    Так это же Debian/Ubuntu, почему yum?
    И в том же листинге make install чуть-чуть напряг.
    А статья хорошая, спасибо за проделанную работу.
    • 0
      Так это же Debian/Ubuntu, почему yum?

      Я использовал AMI и ещё какую-то сборку из репозитория AWS, где yum шёл в комплекте, для меня он привычней. Что касается make install — это был чисто тестовый запуск, вопрос о поддержке не стоял. Хотя за ссылку спасибо, кое-что для себя прояснил.
  • 0
    Спасибо за статью, будет ли что то про Radius?
    • 0
      Не думаю. Это более «промышленная» система, много отличий, да и слегка выходит за рамки «общеобразовательного взлома».
  • 0
    Статья мне показала главное — моя система паролей — пока не очень вскрываема… Но подумать еще немного стоит… Спасибо! Было интересно!
  • 0
    Огромное спасибо за статью! Дело конечно не новое, но результаты впечатляют. За ссылки отдельное спасибо. Для себя отметил «7870 XT 485 3.09 1.8726 157 » — из всех карточек наивысший индекс Mhash/J.
  • 0
    Отлично, значит тактика придумывания пароля для wifi вида «голивудский хакер за клавиатурой» будет жить вечно.
    • +3
      тогда уж «галивуцкий хацкэр топчит кнопкэ» =)) чтобы избегать соединения слов из словарей.

      P.S. Вспоминается Лукьяненко с 'сорок тысяч обезьян...'' =)
      • 0
        Имелось ввиду то, как в кинце про хацкеров енти самые хацкеры стучат по клавиатуре =) Какраз с такой скоростю 40 символьные пароли за секунду будут генериться.
  • +1
    Вот кстати разве пароли по рекомендации xkcd не гораздо легче вскрываются составным словарным перебором? Все слова вполне словарные, берём обычный словарь, загоняем его в переборщик, который может составлять из слов комбинации, и на выходе получаем результат. Или вариантов (даже как в примере xkcd — 4 слова) — будет СЛИШКОМ много?
    • +1
      Это легко подсчитать. Допустим, у нас 100 000 возможных слов. В пароле используется 4. Тогда это (10^5)^4 = 10 в 20 степени — аналогичен 20-значному цифровому паролю (см. статистику в статье). Конечно, люди могут использовать только какие-то 10 000 из этого точно так же, как сейчас выбирают qwerty и princess вместо других слов, но всё же пространства для фантазии с многословными словами больше — ведь большинство людей знают не только английский, плюс эти слова можно коверкать. В итоге «moy super sekret» можно будет очень долго и безуспешно пытаться подобрать по словарям.

      Естественно, в любом деле есть возможность накосячить и даже 64-значный пароль, состоящий из единиц вас не сильно спасёт (вероятно). Основная идея, которую выразили на xkcd — более сложные для запоминания пароли совсем не обязательно более сложные для подбора. Проявите фантазию, выберете себе какую-нибудь секретную фразу-девиз на 2-3 языках — и такой пароль можно будет ломать вечно.

      • 0
        Проблема не в том, какой пароль назначает IT специалист, проблема в том, какой пароль назначает обычный человек.
        Я с детства помню соотношение «словарный запас Шекспира 20000 слов, а словарный запас любого номера газеты Times — 200 слов», может мои данные и устарели, но обычный человек использует от силы тысячу слов, а легко-запоминаемыми считает, думаю, как раз 200. Ну пусть 500.
        И вот наша оценка сокращается до 500^4=6.25E10, аналогично 10-значному числовому паролю, который в посте признан моветоном.

        Еще раз повторяю, речь о пароле, который назначит обычный человек.

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

        И вообще — против алгоритмов перебора нужно бороться алгоритмами создания паролей. Давно уже нужно сформулировать алгоритм создания по настоящему стойких паролей. И доверить это нужно профессионалам, а то обычные админы как ни пытаются, толку пока нет.
        Ведь не составит труда добавить «соль» и в пароль — значок "#" «где-то» в середине одного из слов пароля заставит обломаться атаку по словарю, но это же алгоритм, это же нужно описать. А пока у нас только чудесная картинка «correct horse battery stapple», без намека на невысокую сложность такого пароля при атаке по словарю, без намека на добавление каких-нибудь символов.

        Уфф. Наболело.
        • 0
          словарный запас любого номера газеты Times — 200 слов

          На самом деле 600, исследовали New York Times. Это число теперь считают достаточным, чтобы выучить язык до уровня бытового. Не то что это сильно меняет ваш расчёт, конечно.

          Но, как я уже сказал, можно с любой системой напортачить, если иметь на это установку. «Алгоритмы создания паролей» есть и сейчас (один даже по xkcd), есть и менеджеры паролей — да только ими пользуются малый процент от всех людей.

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

          Как это по вашему будет выглядеть и чем отличаться от уже имеющихся случайных генераторов? И чем случайный генератор слов сюда не подходит? По настоящему стойкий — возьмёт оксфордский словарь и вперёд, подбирай полмиллиона слов в одном английском. Причём необычные слова поди и запомнить будет проще, чем обычные.

          Ведь не составит труда добавить «соль» и в пароль — значок "#" «где-то» в середине одного из слов пароля

          А потом как в комиксе — «где же я её поставил и не была ли это собака?» :) На самом деле всё, чего достигли рекомендации/требования наличия спецсимволов, цифр и заглавных букв — того, что люди ставят в конце точку, первую букву делают заглавной, а цифры добавляют в конец как год своего рождения или просто единицы. Особо пространство ключей это не расширяет. hashcat вообще умеет все эти пермутации проводить на лету. А вот народ уже путается и подбирает собственные пароли, когда забыл, сколько единиц добавил.

          А пока у нас только чудесная картинка «correct horse battery stapple»

          Это всё равно лучше, чем просто набор букв и цифр. Сейчас, когда в паролях используют только латиницу и спецсимволы в случайном порядке — их можно перебрать брутфорсом, гарантированно. А вот со словами не понятно: здесь и словари нужны особые, и слова могут быть исковерканы очень разными способами, и языки разные — это как минимум требует информации о том человеке/ресурсе, от которого пришёл хэш. А если это массовая дыра, как на Adobe? Как вы определите, кто из пользователей кем работает и где?
          • 0
            и языки разные — это как минимум требует информации о том человеке/ресурсе, от которого пришёл хэш. А если это массовая дыра, как на Adobe? Как вы определите, кто из пользователей кем работает и где?

            Это да. Я имел в виду подбор пароля к роутеру. Или подбор пароля при известной жертве — взлом под заказ, так сказать.

            Это всё равно лучше, чем просто набор букв и цифр. Сейчас, когда в паролях используют только латиницу и спецсимволы в случайном порядке — их можно перебрать брутфорсом, гарантированно
            В перспективе двух ближайших лет это (без дополнительного усложнения) ничем не лучше, т.к. по мере увеличения распространенности таких паролей появятся и словари и алгоритмы под них.

            В новостях я уже читал про то, что какой-то эксперт продемонстрировал нестойкость паролей из нескольких слов. (на русском найти не могу, вот ссылка на английском). Там, кстати, в последнем абзаце резюмируется, что при большой аудитории даже при использовании 5 слов, у 50% людей стойкость пароля оказывается эквивалентной 30-битному паролю (2^30 чуть больше миллиарда). Это статья 2012 года. Что я там говорил про перспективу? — Забудьте, словари уже должны быть.
            • 0
              Я имел в виду подбор пароля к роутеру. Или подбор пароля при известной жертве — взлом под заказ, так сказать.

              Ну, «жертва на заказ» наверняка будет использовать что-то серьёзное и не словарное, хоть 8-символьное, хоть 20-ти.

              у 50% людей стойкость пароля оказывается эквивалентной 30-битному паролю (2^30 чуть больше миллиарда).

              Тут уже ничего не сделаешь, статья действительно доказывает, что какие люди — такие пароли, в смысле что в любой системе человек — самое слабое место. На мой взгляд пока люди сами не поймут, что такое слабый пароль и как он влияет на их жизнь — так и будут выбирать «harry potter». Видимо мало сайтов взломали…
              • 0
                А, да, забыл!
                Отличный цикл статей! Спасибо, всё это отличная, хорошо изложенная и ценная для всех нас — читателей информация.
                • 0
                  Очень приятно это слышать. Надеюсь, четвертая часть подведет под этим материалом такую же хорошую черту.
            • 0
              Ну так пассфраза и случайно сгенерированный по словарю пароль — две разные вещи. Да, человек — плохой генератор случайных фраз.
        • 0
          А пока у нас только чудесная картинка «correct horse battery stapple», без намека на невысокую сложность такого пароля при атаке по словарю


          Насчёт невысокой сложности: этот самый correct horse battery staple при атаке по точно тому же словарю, что и при генерации пароля (да, такие пароли можно генерировать автоматически) с теми же 200 000 попытками перебора в секунду на топовой видеокарте даже при сравнительно бедном словаре в 2000 слов перебирается более чем 2 года. И это без многократного хэширования. При этом сгенерированный по словарю пароль запоминается лучше, чем сгенерированный как мешанина букв/цифр/спецзнаков. Об этом и xkcd.

          //юзер keepass с 110+битными паролями
          • 0
            пожалуйста покажите, как вы это посчитали (2 года на перебор), или киньте ссылку.
            • 0
              correct horse battery staple по условиям задачи — случайно сгенерированная (ни в коем случае не человеком! её всё равно будет просто запомнить) фраза по словарю в ~2000 слов. Это 11 бит на слово, 44 бит на фразу при словарном же переборе. Общее число комбинаций — 2⁴⁴ ≈ 17.6・10¹². Полный перебор этих комбинаций на, скажем, AMD 6990 (в статье приведена цифра в 181 kh/s на WPA) займёт ≈ 97・10⁶ секунд, что есть 3 года с небольшим.

              Я ошибся: посчитал, что в статье приведены цифры перебора RSA1, а не WPA. Перебор, например, двукратного sha265 займёт всего неделю если я правильно оценил производительность этой видеокарты (более половины гигахэша). От этого спасаться разве что увеличением словаря (словарь в 4000 слов отодвигают проблему до 111 дней) либо добавлением пятого слова (~39 лет). Варианты с добавлением модификаций в пароль — имхо, хуже запоминаются, чем пароль из расширенного словаря.
              • 0
                ну дык, я беру 500 слов, а не 2000, это 2^9 вместо 2^11 комбинаций на слово, 4 слова в фразе дают тогда 2^36 вместо 2^44, и перебирать — на видеокарте.
                ProgerXP привел данные, что словарь современной газеты содержит 600 слов, я с ним согласен, но оценку времени перебора это сильно не изменит.
                • 0
                  Ну так никто не просит брать словарь одной газеты. xkcd-подобные берутся как слова, наиболее часто встречающиеся в разных газетах же. Только не надо говорить, что русскоязычные газеты не наберут 4000 слов в словаре.

                  По ссылке к тому же английскому варианту: 2900-3000 по частоте употребляемости известны даже мне, а я далеко не носитель языка. И вообще, не надо путать активный и пассивный словарный запасы: для пароля нужен пассивный, а это десятки тысяч слов для любого языка.

                  Опять же альтернатив случайной парольной фразе нет: прочие пароли гораздо легче забыть.

                  Кстати, выдержка из русского частотного словаря:
                  бесчувствие 32440, приобщать 32442, окрас 32444, распить 32445, безотрадный 32446
                  • 0
                    согласен, реальный словарь может быть в несколько тысяч слов, время перебора достаточно большое.
                    всё же почитайте результаты исследований, ссылку я давал выше, это может оказаться интересным.
                    • 0
                      Прочитайте это исследование. Там говорится о слабости сравнительно популярных фраз. Я раза 3 подчеркнул, что говорю о случайно сгенерированных по словарю фразах. Исследование абсолютно нерелевантно, там о случайных паролях говорят лишь что
                      For now we can only be comfortable that randomly-generated passphrases (using tools like Diceware) will resist offline brute force.
    • +1
      откуда переборщик узнает сколько слов в пароле, на каком они языке, не набраны ли в другой раскладке?
      Мой «стандарный» пароль состоит из 6 русских слов с профессиональным жаргоном в латинской раскладке, с заменой отсутствующих знаков (Б Ю Э Ж… до сих пор не понимаю почему в паролях не принимают символы пунктуации...) на одному мне известные символы.
      Хоть уподбирайся.
      • 0
        Совершенно верно.
      • 0
        С клавиатуры мобильного устройства фиг наберешь, единственный минус )
        У меня такие же в целом.
        • 0
          Как раз нет, я свои специально подбираю как комбинация пробелов и латинских букв в обоих регистрах так, чтобы можно было легко набирать даже на iOS, где на цифры и спецсимволы надо переключаться. Таким образом 8-мизначный пароль со звёздочками набирается дольше, чем 16-20-значиный.
          • 0
            Я имел ввиду русские слова в английской раскладке.
            • +1
              Можно транслитом, если не помнить раскладку наизусть. Я уже года два сижу на американском ноутбуке без русских символов — ничего, привык :)
              • +4
                Ха, на ноуте я тоже легко набираю. На телефоне — не получается.
          • 0
            О, вот это отличный совет. Мне что-то долго не приходил в голову надежный мастер-пароль к ластпассу, такой, чтобы быстро набирать на телефоне, но ваш комментарий навел на хорошую идею. Спасибо )))
        • 0
          Яндекс клавиатура имеет режим ввода пароля, с ней можно.
          • 0
            А хакеры у нас ведь глупее, чем обычные люди, правда?
            И про Яндекс-клавиатуру они не узнают никогда-никогда?

            Ребята, через годик у всех хакеров будут словари для русских раскладок. Яндекс — не виноват, они просто сделали удобный ввод. Плохо, что Яндекс рекламирует надежность таких паролей.
            • 0
              Понимаете, я лично этот метод использую не столько ради усложнения пароля (что неправда), сколько для 100% ввода пароля. А то знаете ли, с русскими символами бывают разные чудеса — то их не принимают, то они с разных устройств по-разному воспринимаются и в итоге верный пароль не принимается системой, то ещё что. В английской раскладке набрать просто надёжнее.
    • 0
      Пароли лучше всего составлять такие, которые имеют легко запоминающуюся структуру чередования гласных/согласных.
      К примеру, «хараводкер_Истангера».
      Составление правил для такого словаря, конечно же, уменьшает стойкость пароля. Но так как длина пароля при этом растет, а сложность запоминания нет, то в общем случае, криптостойкость тоже растет.

      Моя практика назначения таких паролей показывает, что пароль не запоминают только те, кто вводит его раз в неделю и реже. Как вы понимаете, таких сотрудников на производстве исчезающе малый процент.
      • 0
        Моя практика назначения таких паролей показывает, что пароль не запоминают только те, кто вводит его раз в неделю и реже.

        Кстати да — давно заметил, что даже если меняешь пароли на что-то новое в одночасье, то первый день путаешься и пытаешься набрать старый (или комбинацию из обоих, если это несколько слов), а на второй и далее уже автоматом печатаешь и не задумываешься.
  • 0
    Нигде нету сервиса который позволяет быстренько прогнать короткие и простые пароли за минуту на таком кластере (для уже пойманного рукопожатия)? За какую нибудь адекватную цену?
    • 0
      За адекватную — вряд ли. Облачные сервисы есть, но стоят они $5-20 в час, что на мой взгляд может быть хорошо для пентеста (если у вас нет своего кластера), но для частого применения слишком накладно.

      Мне известны такие: cloudcracker.com, pwaudit.com (ещё не запущен), gpuhash.me (есть бесплатный прогон, но мои пароли он ни разу не подобрал — видимо словарь маленький). Основная проблема сервисов, если не считать стоимость — нет гибкой настройки атаки, то есть если я могу запустить hashcat тысячей и одним способом с разными словарями и масками, то здесь фиксированный набор каких-то непонятных словарей, которые они даже не показывают.
      • +1
        2 года назад писал сервис для распределенного подбора паролей через hashcat под заказ, самое интересное, что заказчик деньги заплатил и исчез, мистика
        • 0
          Повязали :)
  • 0
    Очень умная и поучительная статья. Спасибо за такие статьи. Прочитал с удовольствием.
  • 0
    Интересно и полезно, но так много зачеркнуто — что желание дочитывать теорию успело пропасть. Только погрузишься чуть более чуть полностью — как на тебе, оказывается это была шутка.
    • 0
      Приму к сведению в следующей части.
  • 0
    Было интересно освежить знания по «матчасти», спасибо :)

    Из мелочей, что заметил:
    1. На картинке-иллюстрации алгоритма шифрования используется «S/A-none» вместо положенного «S/A-nonce». Всё таки none и nonce — совершенно разная терминология.
    2. Время вычисления 14-значного пароля на CPU сначала:
    (10^14) / (4700 * 3600 * 24 * 365) = 674,6 лет для 14-значного цифрового пароля

    Потом при сравнении с GPU откуда-то появляется ещё один десяток:
    (10^14) / (1500000 * 3600 * 24 * 365) = 2,1 года для 14-значного цифрового пароля (было 684 года)

    3. Некорректное сравнение продолжительности перебора MD5 на CPU/GPU:
    (10^12) / (94000000000) = 10,6 секунд для 12-значного цифрового пароля (было 7 лет)
    (10^14) / (94000000000 * 60) = 17,7 минут для 14-значного цифрового пароля (было 684 года)

    «7 лет» и «684 года» — это, по вашим словам, время перебора WPA со скоростью 4700 паролей в секунду. Скорость брута MD5 на CPU легко достигает нескольких миллионов, соответственно затраченное время будет в сотни раз меньше.
    • 0
      На картинке-иллюстрации алгоритма шифрования используется «S/A-none» вместо положенного «S/A-nonce».

      Опечатка, «none» приходится печатать чаще, чем «nonce». +1 за внимательность.

      Потом при сравнении с GPU откуда-то появляется ещё один десяток:

      Верно, исправил.

      Некорректное сравнение продолжительности перебора MD5 на CPU/GPU:

      Тоже верно подмечено, при копировании стоило удалить эту часть.

      Спасибо.
  • +3
    Спасибо за ещё одно обьяснение того простого факта что лучше использовать длинный пароль из слов чем короткий пароль из цифр и букв. А то когда я в прошлый раз пытался защитить этот комикс, то народ решил что он умнее математики.
  • +1
    отличний цикл, по хорошему дотошный подход, спасибо)

    но пара наблюдений дабы проапгрейдить статью
    1. при использовании команды отключения клиента не обязательно использовать имя оригинального интерфейса, енжи сам понимает что от него надо. (это к предыдущей статье)
    2. пароли в одном месте лежали в бт, в кали недавно сделали алиасы для списков паролей в /usr/share/wordlists
    3. пирит при любом раскладе съедает одно ядро, наверное для контроля над остальным процессом
    4. мне пришлось поменять пару куллеров после таких экспериментов, имейте ввиду

    и пример подстановке через кранч, не обязательно хешкєт, простой баш в помощь.
    подбор на лету мобильного телефона с конкретным префиксом (063). всего 10млн комбинаций. со средним гпу — 10 минут
    crunch 10 10 -t 063%%%%%%% | pyrit -r handshake.cap -o found.pass.txt -i — attack_passthrough
    • 0
      Спасибо, обновил. Пути в командах писал по памяти, совсем забыл про share.
  • +1
    а самое печальное, что пароли из русских букв (т.е. слов) практически нигде не разрешаются. А если вводить русские буквы по английской раскладке — то «б» и «ю» попадают на "<" и ">", которые обычно запрещены.
    • 0
      … что подразумевает, что таким методом именно Вы пользовались. :-)
  • 0
    А с reaver приходилось иметь дело?
  • 0
    Дешифровать данные обратно можно передав этому же алгоритму шифрованную строку и ключ, который использовался для зашифровки.

    Здесь неточность термина — если известен ключ то мы говорим о расшифровывании:

    «Расшифровывание — процесс нормального применения криптографического преобразования шифрованного текста в открытый.
    Дешифрование (дешифровка) — процесс извлечения открытого текста без знания криптографического ключа на основе известного шифрованного. Термин дешифрование обычно применяют по отношению к процессу криптоанализа шифротекста» википедия

    Но цикл статей просто отличный! Спасибо

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.