Собираем легендарный инструмент аудит паролей, в основном написанный на Cи — John The Ripper
John The Ripper (далее
JTR хорош по отношению к любому подобному ПО тем (часть
JTR компилируется с оглядкой на предустановленные пакеты пользователя, например, если у пользователя установлен пакет «libz/libbz2/libpcap», то он сможет брутить гораздо больше хэшей. Кроме того, для извлечения некоторых хэшей требуется сторонние ЯП, например, python/perl.
Код:
Несколько нюансов о ПО:
Код:
Скрин JTR-1
1. Оба архив-формата поддерживаются JTR на Android девайсах (то есть можно проводить брутфорс атаку).
2. Оба архив-формата поддерживают параллельные вычисления на всех ядрах CPU. Параметр «с/s real» отображает реальное положение вещей (на моём гаджете 8 ядер): скорость при брутфорсе будет составлять ~150 паролей/с. для rar и 10,6к паролей/с. для zip форматов. Параметр «c/s virtual» отображает скорость брутфорс атаки на одном ядре CPU . Если на каком-либо хэше с/s real = c/s virtual, то это означает, что параллельные вычисления на CPU для данного формата не поддерживается JTR-ом, и брутфорс такого рода хэшей будет задействовать лишь одно ядро CPU.
3. Из скрина видим, что rar-архив криптостойкий по сравнению с zip-архивом. В целом хэш из разряда медленных и растрескивать его целесообразно разве что на коротких цифровых паролях или обладая достаточно-большой мета-информацией о пароле: сведя к минимуму всевозможные комбинации.
Простая математика брутфорса.
Например, гарантированное время восстановления пароля для rar архива с паролем «6948» ~= (10^4/150) = 67c. А что если мы обладаем меньшей мета-информацией о пароле, например, мы предполагаем, что пароль цифровой, но может иметь длину не строго 4 знака, а от 1-4 цифр в таком случае, гарантированное время восстановления увеличится на 10% ~= (10^4/150) +(10^3/150) +(10^2/150) + (10^1/150) = 74с. Время выросло, но с такими подобными/предварительными данными мы просто «обязаны» атаковать подобные криптостойкие форматы. А вот, например, буквенно-цифровой пароль длиной от 1-4 символов в нижнем регистре мы сможем сбрутить лишь в диапазоне до 3.5ч. (36^4/150) +(36^3/150) +(36^2/150) + (36^1/150).
Расчет: 26 букв + 10 цифр = 36, степень - длина пароля, 150 - перебор хэшей в сек. на всех 8 ядрах CPU. Для батареи гаджета такое время работы CPU на всю катушку явно критическое, но как обычно в подобных делах можно проявить хитрость и «упорство». Возможно, некоторые читатели сразу подумали об искусственном охлаждении девайсана подзарядке в холодильнике, но финиш можно растянуть, контролируя нагрев батареи с прерыванием и последующим возобновлением атаки, и JTR поддерживает данную функцию («ctrl + c» прервать атаку, «john -restore» - продолжить атаку с места прерывания).
Кроме того, в GNU/Linux имеется пользовательская поддержка: настройка ограничений загрузки процессора для любых операций (
Код:
Аналогична и манипуляция:
Давайте наконец-то сбрутим наш пароль подтвердив, вышеизложенные теоретические расчёты на практике.
Код:
Скрин JTR-2
Из скрина JTR2 видим, что JTR разогнался и показал свою ярость, перебирая пароли ~ на 7% быстрее чем в тестах, а пароль «6948» был восстановлен за 38с. то есть в рамках (теоретически рассчитанного выше) гарантированного диапазона расчётного времени: 74с.
Но пользователь человек с интеллектом, а не алгоритм машины, заученные шаги ему не помогут, если неизменно полагаться исключительно на тесты JTR, хотя мы и видим как они важны. На скрине JTR1 в тестах кроме архивов видим и хэш «telegram» (примечание: добавил Tg для сравнения, формат telegram в JTR - это local code telegram, защитный pin/pass на Android; Windows и GNU/Linux desktop программах). Судя по скрину тест JTR информирует нас о том, что хэш telegram из разряда медленных/криптостойких (скорость перебора 417 паролей/с.). Это не совсем так. Хэш telegram-a криптостойкий лишь для Telegram-программ на OS Windows и GNU/Linux, а на Android-е local code — это «пустышка» и его реальная скорость перебора ~составляет не (417 паролей/с., а космические 1.11млн. паролей/с.).
Давайте восстановим цифровой и буквенный «pin/pass пустышки» на Android-Telegram, оценив энергозатраты и сравним с тестами.
Код:
# Пользователю необходимо задать pin/pass в Telegram на своем рутированном Android-устройстве, далее:
Команды аналогичны и для pass local code, изменяя маску/словарь.
Скрин JTR-3
Из скрина видим, что любой pin (в данном примере pin «7596») восстанавливается мгновенно, а буквенный пароль в нижнем регистре на примере пароля «codeby» восстановлен за 2м.13с., что соответствует гарантированному времени восстановления пароля при брутфорсе (и в тоже время противоречит JTR-тестам). Расчет диапазона гарантированного времени восстановления пароля составлял: (26^6/1_100_000/60) ~= 4.5мин.
Для сравнения, если бы ваши данные хранились не в Tg, а в любом другом защищенном контейнере, например в rar, то на брутфорс пароля «codeby» при прочих равных обстоятельствах потребовалось бы гарантированное время восстановления ~24суток.
Обратите внимание, что хэш local code telegram для брутфорса на Android доступен пользователям с рут-правами по пути: "/data/data/org.telegram.messenger/shared_prefs/userconfing.xml", а JTR попросит доставить крипто-python-пакет.
Пример из жизни: однажды мне в лс написал читатель с просьбой о помощи восстановить свой local code telegram, доказав в суде свою непричастность.
Но упомянутый читатель получил отказ в услуге, никто не готов/не может написать скрипт «_iphone2john» для извлечения хэша с яблочных устройств (они же все дорогостоящие для киберпанков).
На сколько целесообразно и актуально проводить брутфорс на гаджете, надеюсь для читателей стало чуть более очевидным.
Хотя, стоп, стоп, стоп! А как же без скрипт-кидди классики:
Рассмотрим вторую из двух частей атаки, которая отработает на любом гаджете: сравнив брутфорс wifi-рукопожатия с помощью JTR и с помощью
Восстановление wifi-пароля с помощью JTR.
Никаких чисток захваченного рукопожатия, якобы ускоряющих атаку, не проводим. Эта чушь, которую новички продолжают черпать с одного источника — не актуальна. Кроме того, нет необходимости в конвертации стандартного cap-формата рукопожатия в индивидуальные форматы (извлечение хэша засчитываем, как стандартную операцию, а не конвертирование).
Код:
Пруф. Пароль в JTR успешно восстановлен. (Примечание — JTR не брутит найденные пароли повторно, чтобы снова брутить один и тот же пароль, необходимо очистить файл ~/john/run/john.pot)
Восстановление wifi-пароля с помощью aircrack.
Aircrack в репозитории багный и если не запускается после установки, то нужно пролечить: переименовать /data/data/com.termux/files/usr/lib/libaircrack-ce-wpa-1.6.0.so > libaircrack-ce-wpa.so.
Код:
Пароль восстановлен и в Aircrack.
Я трижды, дважды, десять не рекомендую пользоваться в принципе aircrack-ng из-за его багов, которые представлены сообществу как фичи.
А много ли хэш-форматов поддерживает JtR? Много
Но как написал выше о хэшах для JTR: некоторые не оптимизированы, некоторые с багами, некоторые требуют perl-настроек подобного.
По итогу, JTR — это лучшее, что есть на Android устройствах в своей области для растрескивания хэшей.
OSINT в Termux
Читая комментарии на Хабре, я обратил внимание на активность «подозрительных аккаунтов»: эти аккаунты объединяла, некая на мой взгляд, закономерность:: во-первых, они имели сходные nickname(s) (k30; k32...), во-вторых, были подписаны на топики «сделай сам».
Я решил проверить популярность k-аккаунтов над другими подобными аккаунтами, например, b-аккаунтами на дистанции в 111 учёток т.е k0, k1..k99. Для этого использовал инструмент разведки по нику —
Код:
# прошу snoop прочекать все 111-аккаунтов на порталах «Habr» и «Codeby».
(Первые верхние два скрина слева) из полученных данных видим преобладание k-аккаунтов над b-аккаунтами ~в 2 раза! Третий скрин — k-аккаунты на Codeby, как русские на мариенплац. Нижние два скрина — отображение последовательного скопления k-аккаунтов в основном в диапазоне от 10-40. Если отбросить все теории заговора, предполагаю, что популярность k-аккаунтов над другими подобными аккаунтами (я прочекал и другие алфавит-аккаунты) связана у пользователей с фильмами (с вертолётами и субмаринами).
Metasploit
Вот скрин с избитой Termux-wiki страницы посвященной инструменту
Нет, это не wiki-вандализм, вот официальная позиция лиц сопровождающих репозиторий, цитирую переводом:
Установка Metasploit
Код:
Metasploit for Termux is running, no problem.
Dirb
Код:
Steghide
Поиграть в
Код:
Продолжение:
Часть 1-я
Часть 2-я
Часть 3-я
Часть 5-я
John The Ripper (далее
Ссылка скрыта от гостей
) — это софт для аудита паролей.JTR хорош по отношению к любому подобному ПО тем (часть
Ссылка скрыта от гостей
опубликована мной), что он может самостоятельно извлекать хэш любого формата с помощью внутренних скриптов *2john. Например, нужно восстановить пароль от своей забытой
Ссылка скрыта от гостей
БД — для извлечения хэша используем keepass2john и т.д.. В
Ссылка скрыта от гостей
, например, на большинстве форматов пользователю необходимо уже иметь готовый хэш на руках, а где его брать, или чем извлекать пользователю киберпанкам из Hashcat не интересно, но в сети встречаются дискуссии: когда таких пользователей Hashcat-овцы отсылают за хэшем к JTR. Кроме того, функционал JTR предназначен в т.ч. и для генерации словарей любой сложности со скоростью Си, а само JTR-ядро made in Russia.JTR компилируется с оглядкой на предустановленные пакеты пользователя, например, если у пользователя установлен пакет «libz/libbz2/libpcap», то он сможет брутить гораздо больше хэшей. Кроме того, для извлечения некоторых хэшей требуется сторонние ЯП, например, python/perl.
Код:
$ git clone https://github.com/openwall/john
$ cd john/src
$ ./configure && make -s clean && make -sj4Несколько нюансов о ПО:
- то что JTR компилируется и запускается на Android устройствах уже хорошо (годами ранее — это было невозможно, да и сейчас поддержка гаджетов заявлена только для оф. Android-приложения
Ссылка скрыта от гостей(кубинская разработка) с ограниченным набором в 14-хэшей);
- при работе JTR нагружает все ядра CPU на 100% (потому что, например, опция контроль утилизации ресурсов «--fork=2»не отработает на Android как заявлено на GNU/Linux и всё равно будет грузить все ядра CPU на всю катушку, а при таком раскладе на длинной дистанции можно получить вместо пароля любые проблемы/ущерб, т.к. JTR-у плевать на температурный контроль вашей батареи, (ниже я покажу обходное решение этой проблемы);
- скорость брутфорса для некоторых хэшей не оптимизирована для нашей среды.
Ссылка скрыта от гостей
vs
Ссылка скрыта от гостей
в JTR и разберём предварительные результаты.Код:
$ ~/john/run/john --test --format=rar5 && ~/john/run/john --test --format=zip
Скрин JTR-1
1. Оба архив-формата поддерживаются JTR на Android девайсах (то есть можно проводить брутфорс атаку).
2. Оба архив-формата поддерживают параллельные вычисления на всех ядрах CPU. Параметр «с/s real» отображает реальное положение вещей (на моём гаджете 8 ядер): скорость при брутфорсе будет составлять ~150 паролей/с. для rar и 10,6к паролей/с. для zip форматов. Параметр «c/s virtual» отображает скорость брутфорс атаки на одном ядре CPU . Если на каком-либо хэше с/s real = c/s virtual, то это означает, что параллельные вычисления на CPU для данного формата не поддерживается JTR-ом, и брутфорс такого рода хэшей будет задействовать лишь одно ядро CPU.
3. Из скрина видим, что rar-архив криптостойкий по сравнению с zip-архивом. В целом хэш из разряда медленных и растрескивать его целесообразно разве что на коротких цифровых паролях или обладая достаточно-большой мета-информацией о пароле: сведя к минимуму всевозможные комбинации.
Простая математика брутфорса.
Например, гарантированное время восстановления пароля для rar архива с паролем «6948» ~= (10^4/150) = 67c. А что если мы обладаем меньшей мета-информацией о пароле, например, мы предполагаем, что пароль цифровой, но может иметь длину не строго 4 знака, а от 1-4 цифр в таком случае, гарантированное время восстановления увеличится на 10% ~= (10^4/150) +(10^3/150) +(10^2/150) + (10^1/150) = 74с. Время выросло, но с такими подобными/предварительными данными мы просто «обязаны» атаковать подобные криптостойкие форматы. А вот, например, буквенно-цифровой пароль длиной от 1-4 символов в нижнем регистре мы сможем сбрутить лишь в диапазоне до 3.5ч. (36^4/150) +(36^3/150) +(36^2/150) + (36^1/150).
Расчет: 26 букв + 10 цифр = 36, степень - длина пароля, 150 - перебор хэшей в сек. на всех 8 ядрах CPU. Для батареи гаджета такое время работы CPU на всю катушку явно критическое, но как обычно в подобных делах можно проявить хитрость и «упорство». Возможно, некоторые читатели сразу подумали об искусственном охлаждении девайса
Кроме того, в GNU/Linux имеется пользовательская поддержка: настройка ограничений загрузки процессора для любых операций (
Ссылка скрыта от гостей
и
Ссылка скрыта от гостей
).Код:
$ OMP_NUM_THREADS=3 ~/john/run/john hash #данная команда разрешает использовать JTR на все 100% только 3 ядра из 8, что в перспективе снизит нагрузку на батарею, но замедлит растрескивание хэша.Аналогична и манипуляция:
$ taskset -c 0,2,7 ~/john/run/john hash #данная команда заставляет JTR использовать CPU 3/8 ядер (первое; третье и восьмое ядра, т.е. контроль утилизации ресурсов предоставлен на выбор пользователя).Давайте наконец-то сбрутим наш пароль подтвердив, вышеизложенные теоретические расчёты на практике.
Код:
$ ~/john/run/rar2john storage/shared/Download/test.rar > hashrar #извлекаем хэш$ ~/john/run/john --incremental=Digits -max-len=4 hashrar #брутим хэш rar архива «test.rar» (сообщаем JTR, что пароль исключительно цифровой от 1 до 4 символов).
Скрин JTR-2
Из скрина JTR2 видим, что JTR разогнался и показал свою ярость, перебирая пароли ~ на 7% быстрее чем в тестах, а пароль «6948» был восстановлен за 38с. то есть в рамках (теоретически рассчитанного выше) гарантированного диапазона расчётного времени: 74с.
Но пользователь человек с интеллектом, а не алгоритм машины, заученные шаги ему не помогут, если неизменно полагаться исключительно на тесты JTR, хотя мы и видим как они важны. На скрине JTR1 в тестах кроме архивов видим и хэш «telegram» (примечание: добавил Tg для сравнения, формат telegram в JTR - это local code telegram, защитный pin/pass на Android; Windows и GNU/Linux desktop программах). Судя по скрину тест JTR информирует нас о том, что хэш telegram из разряда медленных/криптостойких (скорость перебора 417 паролей/с.). Это не совсем так. Хэш telegram-a криптостойкий лишь для Telegram-программ на OS Windows и GNU/Linux, а на Android-е local code — это «пустышка» и его реальная скорость перебора ~составляет не (417 паролей/с., а космические 1.11млн. паролей/с.).
Давайте восстановим цифровой и буквенный «pin/pass пустышки» на Android-Telegram, оценив энергозатраты и сравним с тестами.
Код:
# Пользователю необходимо задать pin/pass в Telegram на своем рутированном Android-устройстве, далее:
$ ~/john/run/telegram2john.py userconfig.xml > hashtelegram #извлекаем хэш из «/data/data/org.telegram.messenger/shared_prefs/userconfing.xml»$ ~/john/run/john hashtelegram --mask=?d?d?d?d #запускаем брутфорс атаку.Команды аналогичны и для pass local code, изменяя маску/словарь.
Скрин JTR-3
Из скрина видим, что любой pin (в данном примере pin «7596») восстанавливается мгновенно, а буквенный пароль в нижнем регистре на примере пароля «codeby» восстановлен за 2м.13с., что соответствует гарантированному времени восстановления пароля при брутфорсе (и в тоже время противоречит JTR-тестам). Расчет диапазона гарантированного времени восстановления пароля составлял: (26^6/1_100_000/60) ~= 4.5мин.
Для сравнения, если бы ваши данные хранились не в Tg, а в любом другом защищенном контейнере, например в rar, то на брутфорс пароля «codeby» при прочих равных обстоятельствах потребовалось бы гарантированное время восстановления ~24суток.
Обратите внимание, что хэш local code telegram для брутфорса на Android доступен пользователям с рут-правами по пути: "/data/data/org.telegram.messenger/shared_prefs/userconfing.xml", а JTR попросит доставить крипто-python-пакет.
Пример из жизни: однажды мне в лс написал читатель с просьбой о помощи восстановить свой local code telegram, доказав в суде свою непричастность.
Но упомянутый читатель получил отказ в услуге, никто не готов/не может написать скрипт «_iphone2john» для извлечения хэша с яблочных устройств (они же все дорогостоящие для киберпанков).
На сколько целесообразно и актуально проводить брутфорс на гаджете, надеюсь для читателей стало чуть более очевидным.
Хотя, стоп, стоп, стоп! А как же без скрипт-кидди классики:
Ссылка скрыта от гостей
? Совершенно верно — никак.Рассмотрим вторую из двух частей атаки, которая отработает на любом гаджете: сравнив брутфорс wifi-рукопожатия с помощью JTR и с помощью
Ссылка скрыта от гостей
.Восстановление wifi-пароля с помощью JTR.
Никаких чисток захваченного рукопожатия, якобы ускоряющих атаку, не проводим. Эта чушь, которую новички продолжают черпать с одного источника — не актуальна. Кроме того, нет необходимости в конвертации стандартного cap-формата рукопожатия в индивидуальные форматы (извлечение хэша засчитываем, как стандартную операцию, а не конвертирование).
Код:
$ ~/john/run/wpapcap2john storage/shared/Download/test/test_wifi.cap > hand_wifi #извлечение хэша$ ~/john/run/john -w=storage/shared/Download/test/word.txt hand_wifi #атака по словарю на извлеченный хэш
Пруф. Пароль в JTR успешно восстановлен. (Примечание — JTR не брутит найденные пароли повторно, чтобы снова брутить один и тот же пароль, необходимо очистить файл ~/john/run/john.pot)
Восстановление wifi-пароля с помощью aircrack.
Aircrack в репозитории багный и если не запускается после установки, то нужно пролечить: переименовать /data/data/com.termux/files/usr/lib/libaircrack-ce-wpa-1.6.0.so > libaircrack-ce-wpa.so.
Код:
$ pkg install aircrack-ng #предполагается, что у пользователя установлен root-repo и имеются рут права.$ head -n 15000 storage/shared/Download/test/word.txt | aircrack-ng -w - -e Ragnar storage/shared/Download/test/test_wifi.cap
Пароль восстановлен и в Aircrack.
Я трижды, дважды, десять не рекомендую пользоваться в принципе aircrack-ng из-за его багов, которые представлены сообществу как фичи.
А много ли хэш-форматов поддерживает JtR? Много
$ ~/john/run/john --list=formats | wc -lНо как написал выше о хэшах для JTR: некоторые не оптимизированы, некоторые с багами, некоторые требуют perl-настроек подобного.
По итогу, JTR — это лучшее, что есть на Android устройствах в своей области для растрескивания хэшей.
OSINT в Termux
Читая комментарии на Хабре, я обратил внимание на активность «подозрительных аккаунтов»: эти аккаунты объединяла, некая на мой взгляд, закономерность:: во-первых, они имели сходные nickname(s) (k30; k32...), во-вторых, были подписаны на топики «сделай сам».
Я решил проверить популярность k-аккаунтов над другими подобными аккаунтами, например, b-аккаунтами на дистанции в 111 учёток т.е k0, k1..k99. Для этого использовал инструмент разведки по нику —
Ссылка скрыта от гостей
.Код:
$ pkg install python libcrypt libxml2 libxslt git
$ pip install --upgrade pip
$ git clone https://github.com/snooppr/snoop -b snoop_termux
$ cd ~/snoop
$ python -m pip install -r requirements.txt
$ ~../john/run/john -min-len=1 -max-len=3 --mask=k?d?d --stdout | sort -n -t "k" -k2 > k-аккаунты #выше я писал, что JTR в т.ч. умеет генерировать словари (альтернатива
Ссылка скрыта от гостей
). Генерирую словарь из 111 к-аккаунтов (почему не 100, первые 10 аккаунтов имеют вид k1 и k01...).$ ~../john/run/john -min-len=1 -max-len=3 --mask=b?d?d --stdout | sort -n -t "b" -k2 > b-аккаунты# прошу snoop прочекать все 111-аккаунтов на порталах «Habr» и «Codeby».
$ python snoop.py -s habr -u k-аккаунты
$ python snoop.py -s habr -u b-аккаунты
$ python snoop.py -s codeby -u k-аккаунты
(Первые верхние два скрина слева) из полученных данных видим преобладание k-аккаунтов над b-аккаунтами ~в 2 раза! Третий скрин — k-аккаунты на Codeby, как русские на мариенплац. Нижние два скрина — отображение последовательного скопления k-аккаунтов в основном в диапазоне от 10-40. Если отбросить все теории заговора, предполагаю, что популярность k-аккаунтов над другими подобными аккаунтами (я прочекал и другие алфавит-аккаунты) связана у пользователей с фильмами (с вертолётами и субмаринами).
Metasploit
Одним из самых популярных true_инструментов у безопасников является
Ссылка скрыта от гостей
, но в местном репозитории он всё: false (кстати, как и sqlmap).Вот скрин с избитой Termux-wiki страницы посвященной инструменту
Нет, это не wiki-вандализм, вот официальная позиция лиц сопровождающих репозиторий, цитирую переводом:
Немного обидно и за OSINT, вспыхнула в памяти фраза главного судьи по делу pgp в далёкие времена, когда криптография приравнивалась к оружию, а шифропанки испытывали давление:
Установка Metasploit
Код:
$ wget https://raw.githubusercontent.com/gushmazuko/metasploit_in_termux/master/metasploit.sh && chmod +x metasploit.sh && ./metasploit.sh$ msfconsole
Metasploit for Termux is running, no problem.
Dirb
Ссылка скрыта от гостей
— это простой, но чертовски популярный сканер, который почему-то ещё не изгнан из стандартного репозитория Termux. Dirb брутфорсит web-каталоги/файлы на true/false указанного ресурса по словарю, что найдёт то и выведет или сохранит в файл. Автор старой школы разработал инструмент для единомышленников почти 20 лет назад, сам же не замечен в проявлении своей онлайн публичности/активности.Код:
$ pkg install dirb #установка сканера$ dirb --help #изучить справку по функциям$ dirb url #самый простой вариант натравить сканер на какой-либо ресурс.
Steghide
Поиграть в
Ссылка скрыта от гостей
со
Ссылка скрыта от гостей
в Termux на Android-устройствах пользователю поможет ПО Steghide, которое по качеству выше аналогичного GUI-приложения: отстойного Pixelknot (стеганография которого детектируется со 100% вероятностью).Код:
$ pkg install steghide
$ steghide embed -cf ./musor/1.jpg -p pass123 -ef ./musor/secret.txt #зашифровать файл secret.txt паролем «pass123» и спрятать текстовый документ в фотографии без намёка на его существование$ steghide extract -sf ./musor/1.jpg #извлечь секрет из фото
Продолжение:
Часть 1-я
Часть 2-я
Часть 3-я
Часть 5-я
Последнее редактирование:
