Однажды Nutella предложила своим поклонникам обновить пароли в соцсетях. Пост с изначально благими намерениями появился в Twitter (запрещен в РФ). Но компания просчиталась в деталях: она открыто призывала людей заменить пароли на (цитирую) «то, что дорого сердцу, как “Nutella” например».
Конечно, в комментариях тут же пояснили, что это плохая идея. Nutella предлагает использовать неуникальный пароль, который теперь известен злоумышленникам. Они смогут его легко подобрать. Еще хуже — если такие комбинации начнут использовать не только поклонники, но и сотрудники компании.
К чему это я? К тому, что безответственное отношение к учетным данным — проблема, которая встречается часто и даже в крупных компаниях. Вот почему так важно проводить проверки «стойкости» паролей сотрудников. Чем больше слабых комбинаций они используют, тем выше вероятность, что компания станет жертвой злоумышленников.
Один из вариантов такой проверки — прогон учетных данных по утекшим базам через хэши. Фактически речь идет об имитации атаки с использованием хэшей, чтобы защититься от возможных атак на формы аутентификации и компрометации учетных записей. Процесс может быть трудоемким, особенно для сложных паролей, но часто бывает эффективным.
Подробнее о том, как проводятся аудиты хэшей паролей, можно прочитать в этой статье на Хабре.
А сегодня поговорим о другом. Так как обычно такие проверки проходят долго, мне всегда хотелось найти способ их ускорить. Чтобы узнать, на каких GPU дело пойдет быстрее и какой будет реальная разница с CPU, я решился на небольшое тестирование. Запустил Hashcat на нескольких устройствах с разными CPU и GPU. Какие варианты рассмотрел и что в итоге получил, читайте далее.
Почему Hashcat
Hashcat — пожалуй, самая знаменитая программа для таких задач. Она умеет вычислять хэши различных типов, поддерживает множество алгоритмов хэширования и использует сразу несколько методов в работе со словарями.
Программа работает с различными операционными системами и поддерживает техники перебора паролей на ресурсах с CPU и GPU, а также в гибридном формате.
База выгруженных пользователей
Моя тестовая база составила 221 учетную запись. Все это — доступы к корпоративной почте. Именно их я и сверял со словарями.
Словари и где их найти
Все популярные словари доступны для скачивания бесплатно и без СМС:
Top29Million-probable-v2 — 29 млн паролей на 300 Mb (ссылка);
CrackStation — 1,5 млрд паролей на 15 Gb (ссылка);
All-in-One — 28,3 млрд паролей на 329 Gb (ссылка).
Для проверок я использовал первый словарь, так как он содержит меньше данных. Проводить сверки по огромным базам было бы слишком долго.
Тестовые стенды и драйверы
Сразу решил использовать четыре стенда: виртуальную машину, стационарный ПК, ноутбуки со встроенной и дискретной видеокартами. В общем, тестировал работу Hashcat на том, что оказалось под рукой.
Стенд № 1. Виртуальная машина
Размещается в облаке NGcloud. Гипервизор VMware ESXi:
CPU — Intel Xeon Gold 6226R 2.9GHz 12 ядер,
RAM — 24 Gb,
GPU — NVIDIA TESLA A16,
OC — Windows Server 2019/Ubuntu Server 22.04.
Протестировал разные политики на видеокарте: 2, 4, 8 и 16 Gb.
Стенд № 2. Стационарный ПК
Системный блок:
CPU — i3-10100,
GPU — RTX 3060 12 Gb/1660 SUPER 8 Gb,
RAM — 16 Gb,
OC — Windows 10 Pro.
Стенд № 3. Ноутбук с Iris Xe
Lenovo ThinkPad T14 Gen3 со встроенной видеокартой:
CPU — i5-1235U,
GPU — Iris Xe,
RAM — 16 Gb,
OC — Windows 10 Pro.
Стенд № 4. Ноутбук с GTX
Lenovo IdeaPad l340 с дискретной видеокартой:
CPU — i5-9300H,
GPU — GTX 1650 8 Gb,
RAM — 16 Gb,
OC — Windows 10 Pro.
По драйверам для Windows Server 2019 подборка такая:
1. На GPU:
NVDIA Графический драйвер 528.24,
NVIDIA RTX Desktop Manager 203.87 (ссылка),
NVDIA CUDA SDK Toolkit 12.0 (ссылка).
2. На CPU:
Intel® CPU Runtime for OpenCL™ Applications 23.2.0.49500 (ссылка).
Для Ubuntu Server 22.04 установил:
1. На GPU:
Дистрибутив opencl-headers.
Драйвер nvidia-linux-grid-525_525.85.05, который удобнее загрузить через run-файл NVIDIA-Linux (ссылка).
CUDA SDK Toolkit 12 (ссылка).
2. На CPU:
Дистрибутив pocl-opencl-icd.
Если не определится, то догружаем OpenCL™ Runtime 16.1 for Intel® Core™ and Intel® Xeon® Processors (ссылка).
А теперь к делу
Если вдруг захотите провести тестирование самостоятельно, то порядок действий будет примерно таким.
1. Создаем учетную запись с правами Domain Admins, если ее еще нет. Она нужна для того, чтобы забрать хэши паролей напрямую с AD.
Есть много способов, как и чем можно сдампить данные. Я предпочитаю использовать secretsdump (ссылка на exe), только не забудьте отключить антивирус перед скачиванием. Это самый простой вариант, и его советуют опытные коллеги.
Вот другие известные мне способы, которыми также можно забрать хэши с AD:
ntdsutil и NtdsAudit (ссылка),
если не доверяете ПО, то можно подгрузить модуль PS (ссылка),
еще можно сделать шадоу-копии ntds.dit и SYSTEM.
2. После снятия хешей скачиваем Hashcat, подготавливаем систему и саму программу.
Затем проверяем, что в программе определилось необходимое устройство:
./hashcat.bin -I
Флаг -I показывает установленные устройства, на которых можно запустить перебор паролей.
Далее проваливаемся в директорию с hashcat и прописываем запуск с нужными флагами. В нашем случае выходит так:
./hashcat.bin -D 1 -m 1000 --hwmon-disable -a 0 -O -w 4 /home/user/hashcat626/hash/AD1903.txt /home/user/hashcat626/database/Top29Million-probable-v2. txt -r rules/OneRuleToRuleThemAll.rule
А теперь рассмотрим запрос в деталях:
./hashcat.bin — обращение к программе. На Windows в PS будет выглядеть как .\hashcat.
-D 1 — выбор устройства, на котором запускаем перебор (1=CPU, 2=GPU). По дефолту Hashcat использует GPU.
-m 1000 — тип хэширования.
--hwmon-disable — отключение показателей температуры и вентиляторов.
-a 0 — режим атаки по словарю (также есть режимы брутфорса, атаки по Маске, гибридный и т.д.).
-O – включение оптимизированных ядер, которое влияет на максимальную длину пароля.
-w 4 — режимы рабочей нагрузки (1 — самый низкий, 4 — самый большой).
/home/user/hashcat626/hash/AD1903.txt — путь к хэшам. На Windows будет так: "C:\hashcat626\hash\AD1903.txt".
/home/user/hashcat626/database/Top29Million-probable-v2.txt — путь к парольной базе. На Windows — C:\hashcat626\database\Top29Millionprobable-v2.txt.
-r rules/OneRuleToRuleThemAll.rule — путь к правилу мутации (оно отвечает за преобразование слов из словаря по заранее заданным условиям). На Windows нужно заменить / на \ .
Важные нюансы
В процессе столкнулся с неожиданными ошибками. Оказалось, что все они решаемы. Но если бы знал о них заранее, то сэкономил бы много часов и нервов.
1. При запуске теста на Toolkit 12.4 (актуальная версия на этап теста) вышла ошибка: OpenCL 8.4 не поддерживается. Можно использовать только 8.0. В документации не было уточнений, какую именно версию брать. Поэтому глянул год выпуска Hashcat, сверил с датами релизов OpenCL. Совпали сроки выхода 12-й версии. Сработало ;)
2. Если устанавливаете программу на виртуальную машину в гипервизоре ESXi, то сначала нужно поставить vmware tools, и только потом заливать драйвера на видеокарту. Иначе получите черный экран, как я, и придется откатывать систему.
3. При работе с виртуальной машиной лучше указывать флаг --hwmon-disable. Так вы сможете избежать спам-ошибок о недоступных датчиках температуры и скорости вентиляторов.
4. При установке драйверов на Ubuntu лучше изначально инсталлировать opencl-headers. Только после этого можно заливать драйвера на видеокарту. В такой последовательности программа успешно устанавливалась всегда. Если делал все в обратном порядке, то приходилось повторно запускать run-файл.
5. Лучше использовать deb (local) установку CUDA SDK Toolkit, так как в онлайне возникали ошибки на некоторых стендах. При локальной установке таких проблем не было.
Результаты
Напомню, что главной целью было проверить скорость проверок на разных устройствах с разными GPU и CPU. Итак, что получилось.
1. Тест по словарю Top29Million-probable-v2. Здесь собрал по всем стендам, так как изначально планировал тестировать скорость только на этой базе.
Виртуальная машина (Стенд № 1) | ПК (Стенд № 2) | Ноутбук Lenovo ITL 14 Gen 3 (Стенд № 3) | Ноутбук Lenovo IdeaPad l340 (Стенд № 4) | ||||||||||
Ubuntu Server | Windows | ||||||||||||
CPU | GPU 16 Gb | CPU | GPU 2Gb | GPU 4Gb | GPU 8Gb | GPU 16Gb | CPU | GPU RTX 3060 | GPU GTX 1660 super | CPU | GPU Iris Xe | CPU | GPU GTX 1650 |
174 мин. | 9 мин. 33 сек. | 148 мин. | 9 мин. 33 сек. | 9 мин. 35 сек. | 9 мин.36 сек. | 9 мин. 41 сек. | 282 мин. | 3 мин. 31 сек. | 6 мин. | 216 мин. | 93 мин. | 384 мин. | 6 мин.41 сек. |
2. Тест по словарю CrackStation — дополнительный, поэтому ограничился только одним ноутбуком и не стал запускать на Ubuntu.
Виртуальная машина (Стенд № 1) | ПК (Стенд № 2) | Ноутбук Lenovo IdeaPad l340 (Стенд № 4) | |||
Windows | |||||
CPU | GPU 4Gb | GPU 16Gb | RTX 3060 | 1660 super | GPU 1650 |
5737 мин. | 379 мин. | 382 мин. | 136 мин. | 186 мин. | 252 мин. |
3. Тест по словарю All-in-One — тоже дополнительный, поэтому выборка та же, что и выше.
Виртуальная машина (Стенд № 1) | ПК (Стенд № 2) | Ноутбук Lenovo IdeaPad l340 (Стенд № 4) |
Windows | ||
GPU 16Gb | RTX 3060 | GPU |
9420 мин. | 3118 мин. | 6385 мин. |
Вы уже наверняка заметили: разница скорости CPU и GPU получилась внушительной.
1. На виртуальной машине скорость проверки на GPU выше показателя CPU в 15—18 раз. Хотя я думаю, что такая огромная разница могла получиться из-за того, что на ВМ не хватило каких-то драйверов. Возможно поэтому я получил низкую производительность. Все-таки на GPU показатели все получились плюс-минус одинаковые.
Еще один вывод: Hashcat действительно не использует объем видеокарты, а только CUDA ядра. Получается, для аудита хэшей паролей можно использовать GPU с любым количеством гигабайт.
Главное — учитывать выделяемый объем ядер. Чем их больше, тем быстрее пройдет проверка.
2. На ПК с видеокартой RTX 3060 (3584 ядер) разница скорости с CPU составила аж 86 раз, а с GTX 1660 (1408 ядер) — 47 раз.
3. На ноутбуке со встроенной видеокартой Ires Xe (96 ядер) получил не такие космические показатели, как на предыдущих стендах. В целом GPU оказалась всего в 2-3 раза быстрее CPU. И это логично: видеокарта здесь — не отдельное устройство, а всего лишь контроллер самого процессора или чипсета, который использует часть оперативной памяти.
4. На ноутбуке с дискретной картой GTX 1650 (1024 ядра) в 60 раз быстрее CPU.
В гибридном же режиме существенных изменений не увидел совсем. Вероятно, с более производительными процессорами разница все же будет. Но у меня не было возможности это проверить.
Если интересно, вот скрины всех проверок >>
1. База Top29Million-probable-v2.
Тест виртуальной VM OC Windows Server на CPU:
Тест виртуальной VM OC Ubuntu на CPU:
Тест ПК на CPU:
Тест виртуальной VM на GPU 2 Gb:
Тест виртуальной VM на GPU 4 Gb:
Тест виртуальной VM на GPU 8 Gb:
Тест виртуальной VM на GPU 16 Gb:
Тест виртуальной VM с Ubuntu Server на GPU 16 Gb:
Тест на ноутбуке с GTX 1650 8 Gb:
Тест на ПК с GPU 1660 SUPER 8 Gb:
Тест на ПК с GPU RTX 3060 12 Gb:
Тест на ноутбуке Lenovo ITL 14 Gen 3 CPU:
Тест на ноутбуке Lenovo ITL 14 Gen 3 GPU Iris Xe:
2. База CrackStation.
Тест на виртуальной машине на CPU:
Тест на виртуальной машине на GPU 4 Gb:
Тест на виртуальной машине на GPU 16 Gb:
Тест на ПК с 1660 SUPER 8 Gb:
Тест на ПК с RTX 3060 12 Gb:
3. База All-in-One.
Тест на виртуальной машине на GPU 16 Gb:
Тест на ноутбуке с GTX 1650 8 Gb:
Тест на ПК с GPU RTX 3060 12 Gb:
Бонус: правила мутации и скорость
В процессе тестирования также замерил время, за которое проводится проверка по основным правилам мутации. По базе Top-29 получилось как-то так:
Правило | OneRuleToRuleThemAll.rule | dive.rule | generated2.rule | rockyou-30000.rule | d3ad0ne.rule |
Затраченное время | 9 мин. 41 сек. | 16 мин. 44 сек. | 9 мин. 18 сек. | 5 мин. 21 сек. | 5 мин. 47 сек. |
Кол-во слабых паролей | 14 | 14 | 9 | 11 | 11 |
Вывод такой: OneRuleToRuleThemAll.rule обрабатывает практически в два раза быстрее и с тем же результатом, что и другие правила. Возможно, на больших словарях разница в скорости будет больше, чем 7 минут.
А что в итоге с паролями?
Проверки по разным словарям выдали (ожидаемо) разные результаты. Из 221 учетных данных нашлось такое количество слабых паролей:
Top29Million-probable-v2 | CrackStation | All-in-One |
14 | 15 | 31 |
Переведем цифры в проценты: доля плохих комбинаций по базе Top-29 составила 6,33%, по CrackStation — 6,79%. Но больше всего совпадений нашлось по словарю All-in-One — 14,03%.
Получается, что при более серьезном аудите лучше использовать третью базу. Пусть и проходит такая проверка очень долго. Спасибо, кэп, да.
Хотя есть любопытный нюанс: я также закидывал на проверку 61 учетную запись, но время по All-in-One вообще не изменилось. То есть процесс длился столько же, сколько и по 221 учетке. Что это было, не понял. Ваши предположения?