Взлом паролей с помощью John the Ripper и соления

Введение

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

Именно здесь в игру вступает "соль" (salting). Соль — это техника, при которой к паролю перед хешированием добавляется уникальная случайная строка (сама "соль"). Затем эта соль хранится вместе с хешем. Когда пользователь пытается войти в систему, та же соль извлекается и объединяется с введенным паролем перед хешированием, а полученный хеш сравнивается с сохраненным хешем.

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

Понимание концепции соления

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

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

Давайте рассмотрим пример соленого хеша. Откройте файл salted_passwords.txt, созданный в вашем каталоге ~/project.

cat ~/project/salted_passwords.txt

Вы увидите вывод, похожий на этот:

user1:$6$salt12345$abcdefghijklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ./:user1password
user2:5f4dcc3b5aa765d61d8327deb882cf99
user3:$6$another_salt$zyxwuvtsrqponmlkjihgfedcba9876543210ZYXWVUTSRQPONMLKJIHGFEDCBA./:anotherpassword
user4:$6$short$abcdefghijklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ./:shortpass

Обратите внимание на строки для user1, user3 и user4. Они содержат раздел типа $6$salt12345$ или $6$another_salt$. $6$ указывает используемый алгоритм хеширования (в данном случае SHA-512), а строка между вторым и третьим знаками $ (salt12345 или another_salt) является солью. Остальная часть строки после третьего $ — это фактический хеш пароля, объединенный с солью. Строка для user2 представляет собой несоленый хеш MD5, который мы будем использовать для сравнения позже.

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

Идентификация соленых хешей

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

Различные алгоритмы хеширования и системы используют различные форматы для хранения соленых хешей. Однако многие распространенные форматы, особенно те, которые используются в системах Linux, следуют шаблону, при котором соль встраивается непосредственно в строку хеша, часто разделяемую специальными символами, такими как $.

Давайте еще раз рассмотрим файл salted_passwords.txt и специально поищем шаблоны, указывающие на соление.

cat ~/project/salted_passwords.txt

Как вы заметили на предыдущем шаге:

user1:$6$salt12345$abcdefghijklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ./:user1password
user3:$6$another_salt$zyxwuvtsrqponmlkjihgfedcba9876543210ZYXWVUTSRQPONMLKJIHGFEDCBA./:anotherpassword
user4:$6$short$abcdefghijklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ./:shortpass

Эти строки явно показывают префикс $6$ (указывающий на SHA-512 crypt), за которым следует строка соли (например, salt12345, another_salt, short), а затем фактический хеш. Эта структура является явным признаком соленого хеша.

В отличие от этого, строка для user2:

user2:5f4dcc3b5aa765d61d8327deb882cf99

Это простой хеш MD5. В нем отсутствуют разделители или встроенная соль, что позволяет легко идентифицировать его как несоленый хеш.

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

Наблюдение за обработкой соленых хешей в John the Ripper

На этом этапе вы будете использовать John the Ripper, популярный инструмент для взлома паролей, чтобы наблюдать, как он обрабатывает как соленые, так и несоленые хеши. Это продемонстрирует практические последствия соления.

Сначала попробуем взломать пароли в файле salted_passwords.txt с использованием простого списка слов. Для этой демонстрации мы будем использовать небольшой пользовательский список слов.

Создайте файл списка слов с именем wordlist.txt в вашем каталоге ~/project с некоторыми распространенными паролями:

echo "password" > ~/project/wordlist.txt
echo "user1password" >> ~/project/wordlist.txt
echo "anotherpassword" >> ~/project/wordlist.txt
echo "shortpass" >> ~/project/wordlist.txt
echo "123456" >> ~/project/wordlist.txt

Теперь запустите John the Ripper против вашего файла salted_passwords.txt, используя этот список слов:

john --wordlist=~/project/wordlist.txt ~/project/salted_passwords.txt

John the Ripper проанализирует хеши. Вы должны увидеть вывод, указывающий, что он пытается взломать пароли. Он, вероятно, быстро найдет пароль user2, поскольку это несоленый хеш MD5, а "password" находится в списке слов. Он также найдет соленые пароли, если соответствующие им открытые тексты находятся в списке слов.

Пример вывода может выглядеть так:

Using default input encoding: UTF-8
Loaded 4 password hashes with no different salts to crack (crypt, generic crypt(3) [MD5/Blowfish/SHA1/SHA256/SHA512/XSHAa/XSHAab/bcrypt/scrypt])
Will run 4 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
password         (user2)
user1password    (user1)
anotherpassword  (user3)
shortpass        (user4)
4g 0:00:00:00 DONE (2023-10-27 10:30) ...
Session completed.

После завершения работы John вы можете просмотреть взломанные пароли, используя опцию --show:

john --show ~/project/salted_passwords.txt

Эта команда отобразит все пароли, которые John успешно взломал.

user2:password (user2)
user1:user1password (user1)
user3:anotherpassword (user3)
user4:shortpass (user4)

4 password hashes cracked, 0 left

John the Ripper разработан для работы с различными форматами хешей, включая те, которые содержат встроенные соли. Он автоматически извлекает соль и использует ее в процессе взлома. Однако наличие уникальных солей для каждого пароля значительно увеличивает вычислительные усилия, необходимые для взлома, особенно при крупномасштабных атаках.

Понимание влияния соления на взлом

На этом этапе вы закрепите свое понимание того, почему соление значительно усложняет взлом паролей, особенно при крупномасштабных атаках.

Рассмотрим запись user2 из нашего файла salted_passwords.txt: user2:5f4dcc3b5aa765d61d8327deb882cf99. Это несоленый хеш MD5 для пароля "password". Если злоумышленник получает базу данных несоленых хешей MD5, он может:

Использовать радужные таблицы (Rainbow Tables): Предварительно вычисленные таблицы хешей для распространенных паролей. Если "password" есть в таблице, там будет и его хеш 5f4dcc3b5aa765d61d8327deb882cf99, и открытый текст может быть мгновенно извлечен.
Взламывать несколько паролей одновременно: Если у многих пользователей один и тот же слабый пароль (например, "123456"), их несоленые хеши будут идентичны. Злоумышленнику достаточно взломать один экземпляр этого хеша, чтобы узнать пароль всех пользователей, использующих его.

Теперь давайте посмотрим на соленые хеши:

user1:$6$salt12345$abcdefghijklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ./:user1password
user3:$6$another_salt$zyxwuvtsrqponmlkjihgfedcba9876543210ZYXWVUTSRQPONMLKJIHGFEDCBA./:anotherpassword

Даже если бы у user1 и user3 был абсолютно одинаковый пароль, их хеши были бы разными, потому что их соли (salt12345 и another_salt) различны. Это имеет несколько критических последствий для злоумышленников:

Радужные таблицы бесполезны: Поскольку каждый хеш уникален из-за своей соли, предварительно вычисленные радужные таблицы становятся неэффективными. Злоумышленнику потребовалась бы радужная таблица для каждой возможной соли, что вычислительно неосуществимо.
Взлом каждого хеша индивидуально: Злоумышленник должен взламывать каждый соленый хеш индивидуально. Если 100 пользователей имеют один и тот же пароль, но у каждого есть уникальная соль, злоумышленнику придется выполнить 100 отдельных операций взлома, по одной для каждой уникальной пары хеш-соль. Это значительно увеличивает время и ресурсы, необходимые для успешной атаки.
Сложность перебора (Brute-Force): При атаке методом перебора злоумышленник должен комбинировать каждый потенциальный пароль с его конкретной солью перед хешированием и сравнением. Это добавляет уровень сложности и значительно замедляет процесс взлома по сравнению с несолеными хешами.

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

Реализация соления при хранении паролей

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

Когда пользователь устанавливает или изменяет свой пароль, безопасная система обычно выполняет следующие шаги:

Генерация случайной соли: Генерируется криптографически безопасная случайная соль. Эта соль должна быть уникальной для каждого пользователя и каждого изменения пароля.
Объединение пароля и соли: Пароль пользователя в открытом виде объединяется с сгенерированной солью.
Хеширование объединенной строки: Объединенная строка пароля и соли затем пропускается через сильный, медленный алгоритм хеширования (например, bcrypt, scrypt, Argon2 или SHA-512 crypt, как показано в наших примерах). Предпочтение отдается медленным алгоритмам хеширования, поскольку они делают атаки методом перебора еще более трудоемкими.
Хранение хеша и соли: Полученный хеш и соль сохраняются вместе в базе данных. Соль не обязательно должна быть секретной; ее назначение — обеспечить уникальность хеша.

Когда пользователь пытается войти в систему:

Извлечение сохраненной соли: Система извлекает соль, связанную с учетной записью пользователя, из базы данных.
Объединение введенного пароля и сохраненной соли: Пароль, введенный пользователем, объединяется с извлеченной солью.
Хеширование объединенной строки: Эта объединенная строка затем хешируется с использованием того же алгоритма хеширования, который использовался при регистрации.
Сравнение хешей: Недавно вычисленный хеш сравнивается с сохраненным хешем. Если они совпадают, пароль правильный.

Давайте смоделируем генерацию соленого хеша с помощью команды mkpasswd, которая является частью пакета whois и может генерировать хеши в стиле crypt(3).

Сначала убедитесь, что whois установлен:

sudo apt install -y whois

Теперь сгенерируйте соленый хеш SHA-512 для пароля "mysecretpassword" с пользовательской солью "mysalt":

mkpasswd -m sha-512 "mysecretpassword" -s "mysalt"

Вы увидите вывод, похожий на этот:

$6$mysalt$some_long_hash_string_here

Вывод $6$mysalt$some_long_hash_string_here является соленым хешем. $6$ указывает на SHA-512, mysalt — это предоставленная вами соль, а остальное — сам хеш. В реальной системе соль генерировалась бы случайным образом, а не предоставлялась вручную.

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

Резюме

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

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

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

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

John the Ripper и соление паролей