Приветствую, коллеги!
В данной статье рассмотрим простой кейс, где будет уделено внимание следующим моментам:
- Мисконфигурация Django (режим Debug)
- Эксплуатация странного эндпоинта API
- Брутфорс хеша SHA-256
Приступим к разбору кейса!
Сбор информации
Для начала протыкиваю всё, что вижу на хосту, чтобы узнать основной функционал. Однако затея в данном случае оказалась тухлая.
Проверим какие заголовки можно встретить на сайте, которые могут выдать нам используемые библиотеки и фреймворки с их версиями.
Питон! А вот это уже интересно -_-
При выводе страницы 404 видим информацию о путях с ошибкой фреймворка python Django.
Вот оно! А вот и вывод избыточной информации о сервере из-за некорректной настройки сервера.
Мисконфигурация — это неправильная, ошибочная или неоптимальная настройка программного обеспечения, компьютерной системы, сети или приложения.
В settings.py при настройке параметра DEBUG = True хост выводит всю техническую информацию, включая шаблоны. При выводе несуществующей страницы видим нужную нам информацию. Выглядит эта настройка так:
Теперь, очевидно, можем не фазить директории вовсе. Вызываем страницу 404 и смотрим куда двигаться по директориям дальше.
Форма авторизации находится в emplees_login, которая понадобится нам далее. Об этой странице мы и узнали из вывода в странице 404.
Будем двигаться далее по пути /api
Эксплуатация мисконфигурации
Обратимся к /api и посмотрим что делает хост:
API — это набор правил, протоколов и инструментов, который определяет, как разные программы должны взаимодействовать между собой.
Эндпоинт — это конкретный "адрес" в API, который выполняет определенную функцию.
В приложении есть эндпоинт, который выдаёт приветствие при обращении к /api. По этому правилу сервер отвечает нам на странице, выдавая message.
Можем предположить, что при помимо приветствия он выдаст нам и какого-то пользователя. Это нужно проверить.
Есть и /v2 у API. Ковыряем тогда её. Возможно там что-то будет.
Двигаемся дальше. Ничего нового...
И тут мы находим login/hash пользователя в эндпоинте /api/v2/get_users.
Брутим хэш
Для начала воспользуемся флагом --show для того, чтобы понять какой алгоритм хеширования использовался.
Вероятнее всего это SHA-256. Во флаге -m укажем код 1400 (номер алгоритма хеширования hashcat). Флаг -a 0 говорит о том, что мы будем брутить по словарю, а не по маске. Далее указываем имя файла с хшом и путь к словарю. Всё просто.
Чуть погодя видим надпись Cracked. Хеш поддался бруту!
Далее вводим креды в форму авторизации и забираем наш флаг. Победа!
Выводы
Я знаю, что этот кейс простой как 5 копеек, но для новичков его есть смысл показать.
Django встречается не так часто и уязвимостей на него выходит довольно таки средне в год. Чаще всего в CTF web-приложения на django ломаются при помощи мисконфигурации, чем уязвимости. Разработчики фреймворка уже подумали за безопасников как можно исключить дыры в безопасности web-приложения.
На примере решённого кейса мы выяснили, что режим Debug стоит отключать. Это хорошая фича во время разработки, но не после точно :)
За счёт эндпоинта /api/v2/get_users, который к слову не был защищён никакой авторизацией, получили доступ к актуальному списку пользователей приложения и паролям. В рамках CTF это нормальная практика. Раскрыть эндпоинты нам здорово помог Debug-режим. Если бы такой возможности не было, то нужно было брутить словарями, относящимися к API. Таких, благо, достаточно в сети.
Хеширование паролей - распространённая практика в web-приложениях. Частенько в базах данных хеширование применяется с солью. Соль — это случайные данные, которые добавляются к исходному паролю перед хэшированием. Это сильно затрудняет брутфорс хеша и делает практически невозможным. В рассмотренном кейсе всё было просто и нам хватило одного словаря rockyou.
Спасибо за внимание! Не забывайте оценивать моё творчество лайком. Всех благ!