Broken Authentication (Skills Assessment) — HTB Academy

Автор: B0rn2beR00T (специалист по тестированию на проникновение web-приложений)

Приветствую, коллеги!

Форма аутентификации присутствует во многих ПО. Она встречается в web-приложениях, интерфейсах сетевых железок, виртуализации, БД, файловых хранилищах, CRM и многом другом. Пользователь в такой системе предоставляет такую информацию, как пароли, кодовые фразы, PIN-коды или ответы на секретные вопросы, чтобы подтвердить, что он привилегированный.

Частые случаи, когда система аутентификации настроена или написана недобросовестно, что позволяет обходить её за счёт таких ошибок. Обычно эти ошибки — это неправильная конфигурация, ошибка в логике аутентификации или отсутствие санитаризации ввода пользователя. Даже популярные вендоры допускают баги аутентификации, что приводит к её обходу (bypass). Критичность при обходе такой системы может вылиться в неприятные последствия, например: получение прав админа на сайте. Именно поэтому, для тестировщиков важно понимать как следует проверять такую точку входа в систему.

В новой статье мы разберём Skills Assessment в модуле Broken Authentication платформы Hack The Box Academy, где и протестируем уязвимую систему аутентификации.

Затронутые темы:

• Энумерация пользователей web-приложения

• Обход авторизации благодаря прямого обращения

• Смена ответов сервера BurpSuite

• Слабая реализация 2FA

Приступим к разбору!

Немного теории

Многие путают два популярных понятия (Аутентификация и Авторизация). Давайте разберёмся с двумя этими понятиями:

Аутентификация — это процедура проверки подлинности пользователя или устройства. Простыми словами, это процесс, который отвечает на вопрос: «Вы ли тот, за кого себя выдаете?».

Ввод логина и пароля

Авторизация — это процесс проверки прав пользователя после того, как он уже подтвердил свою личность.

Система решает, к чему у тебя есть доступ (Admin=Try/False)

Аутентификация в web-приложениях может быть реализована различными способами. Например, при помощи Session-Cookie, JWT-токенов, OAuth 2.0, LDAP, SAML и ещё куча вариаций.

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

В своё время он мне также помог в этом хорошо разобраться.

Существует 3 типа аутентификации:

• На основе знаний

• На основе владения

• На основе биометрических данных

Аутентификация на основе знаний (Knowledge-based authentication, KBA) основана на проверке секретов, известных только пользователю и системе. Это могут быть пароли, PIN-коды или ответы на контрольные вопросы.

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

Аутентификация на основе владения (Possession-based authentication, PBA)
Проверяется наличие у пользователя уникального второго или более фактора или устройства. Например:

• одноразовые пароли TOTP/HOTP (Google Authenticator);

• SMS или push-коды;

• криптографические ключи, хранящиеся на устройстве.

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

Главная угроза для такого решения — физическая кража устройств с токеном или с TOTP/HOTP ключами (телефон).

Аутентификация на основе биометрии (Inherence-based authentication)
Основана на измерении уникальных характеристик пользователя (сканер отпечатка). Конечно, этот тип аутентификации мы не затронем, т.к. в web-приложениях он вряд ли встречается часто.

Решаем Skills Assessment

Технологическая компания SecureMint Innovations поручила вам провести оценку безопасности своего веб-приложения после внедрения совершенно новой концепции аутентификации, включающей обновленную политику использования паролей, призванную повысить общую безопасность учетных записей. Клиент хочет убедиться, что никакие скрытые уязвимости не подвергают риску учетные записи пользователей. Ваша задача — выявить уязвимости в процессе аутентификации. Попробуйте использовать различные методы, о которых вы узнали в этом модуле, чтобы выявить и устранить уязвимости в веб-приложении.

Исследуя главную страницу web-приложения выяснил, что многие кнопки не прожимаются, а значит нам явно прямая дорога к форме аутентификации. Хоть это и очевидно, но всегда стоит посмотреть какие-то дополнительные точки входа или данные, которые могут пригодится (почтари сотрудников).

Переходим в /login.php:

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

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

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

Фильтруем список паролей следующим образом:

grep -a -E ‘^[[:alnum:]]{12}$’ /usr/share/wordlists/rockyou.txt | grep -a ‘[[:upper:]]’ | grep -a ‘[[:lower:]]’ | grep -a ‘[[:digit:]]’ > pass_wordlist.txt

Пароль должен содержать:

• Хотя бы одну цифру

• Хотя бы одну заглавную букву

• Хотя бы одну букву нижнего регистра

• Быть длинной в 12 символов

• Не содержать спец. символов

Теперь попробуем перебирать учётки admin или administrotor, но станет ясно, что это бессмысленно. Было бы неинтересно, если бы всё так было просто.

Чтобы найти ответ сервера, где мы исключаем ответ «Unknown username or password». в инструменте fuzz используется флаг -fr.

Значит мы не там копаем. Попробуем найти другие признаки уязвимости. Зарегаем нашего пользователя под любым паролем из отфильтрованного списка:

После чего мы провалимся в /profile.php, где указывают, что в систему мы зашли, но прав администратора у нас нет. Эх…

Вернёмся в форму аутентификации. Попробуем ввести неверный пароль при входе в нашу У.З. И видим, что хост реагирует иначе при неверном пароле (Invalid credentials).

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

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

Таким образом переберём username в приложении, чтобы выявить действующую учётку. Для этого я использовал словарь Seclist под названием xato-net-10-million-usernames.txt.

ffuf -w xato-net-10-million-usernames.txt -u http://154.57.164.67:31398/login.php -X POST -d «username=FUZZ&password=123» -H «Content-Type: application/x-www-form-urlencoded» -H «Cookie: PHPSESSID=5l6l5d6dcvc2l8hmvknvd4rodp» -fr «Unknown username or password.» -t 60

Так мы находим учётку gladys! Проверим как на неё отреагирует хост:

Да, наблюдаем такое же поведение, как и с нашей учёткой ранее. Зная какие пароли используются на хосте, можем для пользователя gladys перебрать наш отфильтрованный вордлист. Если ответ сервера будет не «Invalid credentials.», значит вход успешный.

ffuf -w pass_wordlist.txt -u http://154.57.164.67:31398/login.php -X POST -d «username=gladys&password=FUZZ» -H «Content-Type: application/x-www-form-urlencoded» -H «Cookie: PHPSESSID=5l6l5d6dcvc2l8hmvknvd4rodp» -fr «Invalid credentials.» -t 60

Ответ с редиректом (код 302) указывает на то, что пароль подобран:

После успешного входа нас встречает двухфакторка:

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

Попробуем также перебрать различные комбинации токенов и проверить есть ли среди них верный. Для этого создаём список токенов с набором 4-х значных цифр. Попробуем хотя бы 4-х значный для начала перебрать:

seq -w 0 9999 > tokens.txt

Перебирать смысла оказалось, что вовсе нет 🙁

Рассмотрим запрос при аутентификации:

Обратим внимание, что сервер редиректит нас в заголовке Location на /2fa. Значит, при помощи Intercept в BurpSuite можно попробовать изменить ответ сервера и направить нас на другой Location. Например, /profile.php.

Перехватив запрос в Intercept, необходимо прожать опцию Do Intercept и вариант далее, что позволит поменять ответ сервера, постепенно Forward-я запросы.

Меняем заголовок Location в ответе сервера:

Однако, сервер всё равно перенаправляет нас на /2fa.php.

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

В таком случае проверим ещё один вариант обхода — напрямую обратимся к профилю после авторизации.

Ага! Хоть сервер и выдаёт 302, но содержимое страницы прогружается. Вот мы и нашли missconfig аутентификации!

Так мы и получаем наш флаг! Победа!

Выводы

Фух! Довольно интересный и не такой уж и простой был кейс, согласны? 🙂 Давайте обсудим, что важно соблюдать в системе аутентификации, чтобы подобных уязвимостей в ней не возникало.

Рейт-лимиты

Рейт-лимиты очень важно реализовывать на странице аутентификации т.к. это закрывает несколько возможных векторов, таких как Bruteforce и DOS-атака. При ограничении кол-ва запросов в секунду злоумышленник не сможет перебрать много комбинаций и не закидает приложением запросами, что может заставить его прилечь.

Правила создания паролей

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

Одинаковые ответы сервера

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

Существует реальный пример уязвимости с подобной энумерацией пользователей. В CRM WordPress при неверной настройке можно заметить разные ответы сервера на ввод кредов учётной записи. Подробнее тут.

Форма сброса пароля

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

Прямой доступ к форме

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

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

2FA/MFA

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

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

CAPCHA

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

Default Creds

Никогда не оставляйте развернутую систему с примитивными кредами или дефолтными, которые находятся в сети за пару кликов мыши.

Спасибо за внимание! Не забывайте оценивать моё творчество. Всех благ!