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

Начнем с имен

В форме аутентификации нас, как правило, встречают поля логин и пароль. В теории с логином все относительно просто. Прежде всего любого атакующего будут интересовать административные учетные записи: Administrator, admin, root... Однако, если атакуемое приложение или ОС хотя бы немного соответствует требованиям (рекомендациям, политикам) ИБ, то административные учетные записи будут заблокированы, и будет вестись мониторинг попыток обращений к ним, например, в SIEM.

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

Но мы рассмотрим наиболее сложный вариант, когда логин атакующему также неизвестен. В таком случае можно попробовать воспользоваться ресурсом https://github.com/insidetrust/statistically‑likely‑usernames

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

Как пишет автор данного репозитория: «когда в приложении или сети присутствует много пользователей, я обычно подхожу к атакам с использованием паролей, угадывая вероятные имена пользователей (вместо того, чтобы сосредотачиваться на угадывании слишком большого количества паролей). Это имеет ряд преимуществ (например, позволяет избежать блокировки учетной записи) и почти всегда приводит к успеху (обычно у нескольких пользователей есть либо „Password1“, либо „password“, либо что‑то столь же тривиальное).»

В репозитории есть готовые словари, но если (скорее когда) этого недостаточно, то базовыми списками можно манипулировать и комбинировать самыми разнообразными способами. Например, если пентестеру известно, что формат имени пользователя организации — j_smith, и хочет получить 10 000 предположений (с помощью которых можно попробовать «Password1» или что‑то еще), базовые списки могут быть изменены следующим образом:

head ‑n 10 000 j.smith‑x100 000 | tr “\.” “_” > usernames.txt

Если, опять‑таки ссылаться на лучшие практики ИБ, то приложение не должно при неверном указании логина и/или пароля говорить, что именно указано неверно. Но многие приложения при неверном логине могут сообщить что такого пользователя не существует.

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

Старый добрый брутфорс

Полагаю, все слышали о том, что брутфорс это один из самых распространенных методов взлома. Что бы не придумывали безопасники в своих парольных политиках, все-равно P@ssw0rd, Pa$$w0rd, Passw0rd$1 и их всевозможные, широкораспространенные родственники продолжают селиться в пользовательских аккаунтах. Поэтому подбор по словарю тоже имеет право на жизнь.

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

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

Узнать при каких условиях и насколько будет заблокирована учетка в AD можно с помощью команды:

net accounts

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

Если используется к примеру Kali Linux, то можно воспользоваться одной из следующих команд:

crackmapexec <IP> -u 'user' -p 'password' --pass-pol

enum4linux -u 'username' -p 'password' -P <IP>

rpcclient -U "" -N 10.10.10.10;

rpcclient $>querydominfo

ldapsearch -h 10.10.10.10 -x -b "DC=DOMAIN_NAME,DC=LOCAL" -s sub "*" | grep -m 1 -B 10 pwdHistoryLength

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

Но посмотрим пример. Crackmapexec будет для каждой записи из файла users.txt пробовать каждый пароль из файла passwords.txt. Для представленной выше политики нам нужно делать не больше двух попыток не чаще чем за час. 

crackmapexec smb <IP> -u users.txt -p passwords.txt –t 1 --jitter 1201-1800

Здесь –t 1 это один поток (попытка), а - - jitter 1201-1800 это диапазон в секундах из которого случайным образом будет сгенерирован временной интервал для паузы перед следующей попыткой. Таким образом, в течение каждого часа у нас будет не более двух попыток и мы не заблокируем учетку. Да, скорость 24 попытки за сутки — это не слишком быстро, зато безопасно по крайней мере с точки зрения блокировок. Кстати, не всякий SIEM обнаружит такую активность, так как правила корреляции обычно настраиваются на меньшие временные интервалы во избежание ложных срабатываний.

Распыляемся

Атаку перебора паролей можно распылить (password spraying). Например, если у нас есть несколько логинов и словарь с паролями, то можно при переборе менять не пароль а логин. Это будет выглядеть как неудачные попытки входа для разных пользователей, что при разумном использовании позволит не только обойти политики блокировки, но и обмануть пресловутый SIEM.

Для этого мы можем воспользоваться утилитой spray:

spray -smb <targetIP> <usernameList> <passwordList> <AttemptsPerLockoutPeriod> <LockoutPeriodInMinutes> <Domain>

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

spray -smb 192.168.0.1 users.txt passwords.txt 1 21 CORPORATION

В состав Kali Linux входит множество различных инструментов для перебора паролей, которые можно использовать как для веб ресурсов, так и для файловых шар, баз данных и т.д.

А что делать?

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

Заключение

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

В завершение напомню про открытые уроки, которые пройдут в рамках курса «Информационная безопасность. Basic» и которые можно посетить бесплатно:

• 9 октября: «Управление киберосознанностью сотрудников». Регистрация

• 24 октября: «Механизмы государственного регулирования в ИБ: лицензирование, аккредитация, сертификация и аттестация — что нужно знать начинающему специалисту и как это поможет в работе». Регистрация