Дисклеймер
Данная статья написана только в образовательных целях и автор не несёт ответственности за ваши действия. Ни в коем случае не призываем читателей на совершение противозаконных действий. Материал размещен только с целью ознакомления и принятию мер по обеспечению безопасности. Использование материалов в противоправных и противозаконных запрещено законом РК. Все персоны или принадлежность к кому-либо только в голове у автора. Любые совпадения с реальностью абсолютно случайны.
![](https://habrastorage.org/getpro/habr/upload_files/3e7/ee7/42b/3e7ee742b636c78ebd024cfa415c18d8.png)
Вступление
Не мало было случаев на просторах интернета , где происходила компрометация приложения с последующим шифрованием , в таких случаях обычно спасает бэкап , но что делать если последний бекап файл был на самом сервере?
В этой статье разберем один интересный кейс, в котором удалось скомпрометировать веб приложение используя тот самый бекап файл, который лежал на сервере в открытом доступе.
Весь chain атаки представлен в виде: fuzzing → backup → code analyzing → admin login → upload
Зачем ломать дверь - когда ключ лежит под ковриком?
Гуляя по просторам суб-доменов и собрав необходимый список хостов, я решил запустить nuclei и пока проходит скан пойти погулять - может что-нибудь да найдется! и о чудо!
Вернувшись и почитав логи я увидел что нашелся интересный архив с надписью api.tgz
- нужно глянуть, по любому там что то есть!
![](https://habrastorage.org/getpro/habr/upload_files/c47/b48/668/c47b486681a0c4e16f134278eff61143.png)
Скачав и распаковав архив, я наткнулся на исходный код бэкенда одного из приложения. Думаю “Ну все, сейчас будет весело - пароли , доступ к базе данных , все вкусное…
![](https://habrastorage.org/getpro/habr/upload_files/34d/d1c/c7f/34dd1cc7fa8d8793116aa057d7b302d2.png)
Можно уже писать отчет” но решил поковырять дальше! Как сказал один мой знаковый “Все что не RCE - то не бага”
“Покажи мне свой код и я скажу как тебя взломали!”
Для этой части статьи мне показалось что этот мем - самым точным образом описывает , дальнейшее описание кейса :-)
![](https://habrastorage.org/getpro/habr/upload_files/11e/0fc/cd5/11e0fccd5cfcfd416992295f522e5e17.png)
Копаясь в куче исходного кода, я наткнулся на файл, где регистрируется первый пользователь - он же и Админ, и там же лежал логин и пароль.
![](https://habrastorage.org/getpro/habr/upload_files/f01/dd2/813/f01dd281309a0622702d5a25e50c2a17.png)
Ура посмотрим что за приложение наконец то! Логин форма довольно простая, так что не стал заморачиваться и крутить скулю, просто ввел креды и пошел дальше.
![](https://habrastorage.org/getpro/habr/upload_files/2bb/6c8/14e/2bb6c814e488ea81e00fc3d8cfdb94a7.png)
Далее был относительно недолгий процесс изучения приложения, по сути это административная панель редактирования статей, и там же находился раздел фотогаллерея - по любому можно будет что-нибудь загрузить…
“Помни Neo! Картинки не существует!”
![](https://habrastorage.org/getpro/habr/upload_files/fee/6ba/58f/fee6ba58f218acfff99f865e72894481.png)
Перейдя в раздел изображений, я увидел, что можно загружать изображения и просто попробуем залить туда простой php-oneliner для проверки отсутствия фильтрации.
![](https://habrastorage.org/getpro/habr/upload_files/20d/35e/153/20d35e153797efc7aa79424316dc17d0.png)
Что и следовало ожидать, никакой проверки файла и никакого переименовывания.
В итоге у нас есть RCE. Можно закрывать проект! Почему?
Изучив сервер, стало ясно, что на этом сервере держится вся инфраструктура и все приложения, “потушив” сервер - встанет все!
![](https://habrastorage.org/getpro/habr/upload_files/bfa/c2e/de7/bfac2ede724382a0c9fcaeff14cdd5ea.png)
От увиденного, любой не опытный “пентестер” будет мягко говоря немного в шоке, а “чернушник” обрадуется от такой находки, потому что все исходники и все базы данных лежали именно на этом сервере.
![](https://habrastorage.org/getpro/habr/upload_files/c69/dd7/1c6/c69dd71c625787dfc7fddaeb454fbe69.png)
Ну теперь точно все: все приложения скомпроментированны, RCE есть - можно спокойно писать отчет и ложиться спать :)
Заключение!
Главная и зачастую допускаемая ошибка системных администраторов, это халатность к хранению резервный копий, где простое упущение может быть “лакомым куском” для злоумышленника и привести к серьезным последствиям для компании. На наглядном примере было показано, что имея исходный код одного приложения - есть вероятность, что можно скомпрометировать всю инфраструктуру полностью, не заморачиваясь на особо тяжелых по реализации векторах атак.
![](https://habrastorage.org/getpro/habr/upload_files/d30/2e6/546/d302e654610d880c4f4a3a7b0159b5dd.png)
Данный кейс был очень похож на лабораторные машины с платформы 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 за помощь в публикации данной статьи!
Всем спасибо за внимание! Подписывайтесь на канал, ставьте лайки, будем продолжать подобную серию историй из жизни простых пацанов жаждущих безопасности в стране и мире…
Комментарии (4)
ifap
12.08.2024 08:43+1Ограничивайте попытки перебора файлов и директорий (средствами nginx.conf или apache .htaccess)
Расскажите или киньтесь ссылкой, пожалуйста.
m4rck_kh1lz Автор
12.08.2024 08:43Буду рад еще ответить в телеграм) к этому вопросу думаю будет еще статья по защите от подобных ситуаций)
clevergod
12.08.2024 08:43+3вариантов много с коробки конфигами:
Для Nginx, можно использовать директивы в конфигурационном файле nginx.conf, чтобы ограничить количество запросов от одного клиента:• Rate Limiting: Ограничение скорости запросов от одного IP-адреса. Это можно сделать с помощью модуля ngx_http_limit_req_module. Пример конфигурации:
http { limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s; server { location / { limit_req zone=one burst=5 nodelay; } } }
Это ограничит частоту запросов до 1 запроса в секунду с одним всплеском до 5 запросов.
• Deny Access: Запрещать доступ к определённым файлам или директориям, используя директиву deny. Пример:
location /secret-folder/ {
deny all;
}Для Apache можно использовать .htaccess файл или конфигурационный файл сервера для реализации аналогичных мер:
• LimitRequestBody: Ограничение размера тела запроса, чтобы предотвратить атаки через длинные или сложные запросы. Пример:
<Directory "/var/www/html">
LimitRequestBody 1048576
</Directory>• ModSecurity: Модуль Web Application Firewall (WAF) для защиты от атак, включая перебор файлов и директорий.
• mod_evasive: Модуль, который помогает предотвращать DoS и DDoS атаки, а также перебор.
• IP Blocking: Блокировка подозрительных IP-адресов, которые совершают большое количество запросов за короткий промежуток времени.1. Возврат 200 для несуществующих файлов и директорий
Можно использовать try_files с директивой =200, чтобы сервер всегда возвращал статус 200, даже если файл или директория не существует.
В Apache можно использовать модуль mod_rewrite для перехвата всех запросов и принудительного возврата статус-кода 200.2. Блокировка IP при обнаружении словарных атак
Чтобы блокировать IP-адреса, можно использовать лимитирование запросов, как было описано ранее. Однако для блокировки можно использовать дополнительный модуль ngx_http_limit_conn_module и директиву deny
В Apache можно использовать модуль mod_evasive, чтобы заблокировать IP-адреса, которые делают слишком много запросов за короткий промежуток времени.
Audrius_P
Да ! Продадим яхту гендира и за полученные денюжки профинансируем реновацию бакапирования и проведем аудит безопастности !!!