Backup-FuckUp — история про RCE с помощью архива резервного копирования
Дисклеймер
Данная статья написана только в образовательных целях и автор не несёт ответственности за ваши действия. Ни в коем случае не призываем читателей на совершение противозаконных действий. Материал размещен только с целью ознакомления и принятию мер по обеспечению безопасности. Использование материалов в противоправных и противозаконных запрещено законом РК. Все персоны или принадлежность к кому-либо только в голове у автора. Любые совпадения с реальностью абсолютно случайны.
Вступление
Не мало было случаев на просторах интернета , где происходила компрометация приложения с последующим шифрованием , в таких случаях обычно спасает бэкап , но что делать если последний бекап файл был на самом сервере?
В этой статье разберем один интересный кейс, в котором удалось скомпрометировать веб приложение используя тот самый бекап файл, который лежал на сервере в открытом доступе.
Весь 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 за помощь в публикации данной статьи!
Всем спасибо за внимание! Подписывайтесь на канал, ставьте лайки, будем продолжать подобную серию историй из жизни простых пацанов жаждущих безопасности в стране и мире…
