Дисклеймер
Данная статья написана только в образовательных целях и автор не несёт ответственности за ваши действия. Ни в коем случае не призываем читателей на совершение противозаконных действий. Материал размещен только с целью ознакомления и принятию мер по обеспечению безопасности. Использование материалов в противоправных и противозаконных запрещено законом РК. Все персоны или принадлежность к кому-либо только в голове у автора. Любые совпадения с реальностью абсолютно случайны.
Вступление
Не мало было случаев на просторах интернета , где происходила компрометация приложения с последующим шифрованием , в таких случаях обычно спасает бэкап , но что делать если последний бекап файл был на самом сервере?
В этой статье разберем один интересный кейс, в котором удалось скомпрометировать веб приложение используя тот самый бекап файл, который лежал на сервере в открытом доступе.
Весь chain атаки представлен в виде: fuzzing → backup → code analyzing → admin login → upload
Зачем ломать дверь - когда ключ лежит под ковриком?
Гуляя по просторам суб-доменов и собрав необходимый список хостов, я решил запустить nuclei и пока проходит скан пойти погулять - может что-нибудь да найдется! и о чудо!
Вернувшись и почитав логи я увидел что нашелся интересный архив с надписью api.tgz - нужно глянуть, по любому там что то есть!
Скачав и распаковав архив, я наткнулся на исходный код бэкенда одного из приложения. Думаю “Ну все, сейчас будет весело - пароли , доступ к базе данных , все вкусное…
Можно уже писать отчет” но решил поковырять дальше! Как сказал один мой знаковый “Все что не RCE - то не бага”
“Покажи мне свой код и я скажу как тебя взломали!”
Для этой части статьи мне показалось что этот мем - самым точным образом описывает , дальнейшее описание кейса :-)
Копаясь в куче исходного кода, я наткнулся на файл, где регистрируется первый пользователь - он же и Админ, и там же лежал логин и пароль.
Ура посмотрим что за приложение наконец то! Логин форма довольно простая, так что не стал заморачиваться и крутить скулю, просто ввел креды и пошел дальше.
Далее был относительно недолгий процесс изучения приложения, по сути это административная панель редактирования статей, и там же находился раздел фотогаллерея - по любому можно будет что-нибудь загрузить…
“Помни Neo! Картинки не существует!”
Перейдя в раздел изображений, я увидел, что можно загружать изображения и просто попробуем залить туда простой php-oneliner для проверки отсутствия фильтрации.
Что и следовало ожидать, никакой проверки файла и никакого переименовывания.
В итоге у нас есть RCE. Можно закрывать проект! Почему?
Изучив сервер, стало ясно, что на этом сервере держится вся инфраструктура и все приложения, “потушив” сервер - встанет все!
От увиденного, любой не опытный “пентестер” будет мягко говоря немного в шоке, а “чернушник” обрадуется от такой находки, потому что все исходники и все базы данных лежали именно на этом сервере.
Ну теперь точно все: все приложения скомпроментированны, RCE есть - можно спокойно писать отчет и ложиться спать :)
Заключение!
Главная и зачастую допускаемая ошибка системных администраторов, это халатность к хранению резервный копий, где простое упущение может быть “лакомым куском” для злоумышленника и привести к серьезным последствиям для компании. На наглядном примере было показано, что имея исходный код одного приложения - есть вероятность, что можно скомпрометировать всю инфраструктуру полностью, не заморачиваясь на особо тяжелых по реализации векторах атак.
Данный кейс был очень похож на лабораторные машины с платформы HackTheBox , поэтому всем, кто хочет развиваться в направление Pentest | Red Team, очень советуем… (не реклама - простой человеческий совет)
Рекомендации:
-
Не храните резервные копии на этом же сервере
-
Ограничивайте IP-адреса с которых можно подключаться к административной части вэб-сервиса
-
Ограничивайте попытки перебора файлов и директорий (средствами nginx.conf или apache .htaccess)
-
Реализуйте фильтрацию и переименование загружаемых файлов с фор загрузки
❕Помимо действий по устранению, приведенных для каждой выявленной уязвимости, рекомендуется также выполнить следующие действия, позволяющие повысить общий уровень информационной безопасности Компании:
-
Не реже 1 раза в квартал проводить сканирование информационной инфраструктуры с применением специализированного ПО (например, Nessus, Acunetix Web Vulnerability Scanner, MaxPatrol, Red Check и др.) как изнутри сети, так и извне, а также устранять обнаруженные в ходе сканирования уязвимости;
-
Регулярно устанавливать для всех системных компонентов и ПО актуальные обновления
безопасности, предоставляемые производителями; -
Не реже 1 раза в год, а также после значительных изменений в информационной инфраструктуре, проводить комплексное тестирование на проникновение, включающее как внешнее тестирование методом черного ящика, так и тестирование из внутренней сети методом серого или белого ящика;
-
Организовать процессы мониторинга, регистрации и обработки событий безопасности для своевременного обнаружения, предупреждения и ликвидации последствий атак;
-
Проводить регулярное повышение осведомленности и тренинги в области информационной
безопасности как для пользователей, так и для персонала, ответственного за администрирование
информационной инфраструктуры. -
Встроить в CI/CD такие решения как статичный анализатор исходного кода(SAST), анализатор
уязвимостей зависимостей, компонентов и библиотек. -
Внедрить/настроить Web Application Firewall (WAF).
-
Внедрить централизованный сбор событий серверов и веб-приложений(SIEM) с последующим реагированием на атаки или попытки реализации недопустимых событий и бизнес рисков(SOAR).
-
Внедрить систему контратаки Fail2Ban/Crowdsec.
Статью подготовил @BismarckIV (Marck Khilz)
Отдельная благодарность @clevergod за помощь в публикации данной статьи!
Всем спасибо за внимание! Подписывайтесь на канал, ставьте лайки, будем продолжать подобную серию историй из жизни простых пацанов жаждущих безопасности в стране и мире…
Автор: m4rck_kh1lz
