12.08.2024 08:15
m4rck_kh1lz 4 1300 Источник

Дисклеймер

Данная статья написана только в образовательных целях и автор не несёт ответственности за ваши действия. Ни в коем случае не призываем читателей на совершение противозаконных действий. Материал размещен только с целью ознакомления и принятию мер по обеспечению безопасности. Использование материалов в противоправных и противозаконных запрещено законом РК. Все персоны или принадлежность к кому-либо только в голове у автора. Любые совпадения с реальностью абсолютно случайны.

Вступление

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

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

Весь chain атаки представлен в виде: fuzzing → backup → code analyzing → admin login → upload

Зачем ломать дверь - когда ключ лежит под ковриком?

Гуляя по просторам суб-доменов и собрав необходимый список хостов, я решил запустить nuclei и пока проходит скан пойти погулять - может что-нибудь да найдется! и о чудо!

Вернувшись и почитав логи я увидел что нашелся интересный архив с надписью api.tgz - нужно глянуть, по любому там что то есть!

Скачав и распаковав архив, я наткнулся на исходный код бэкенда одного из приложения. Думаю “Ну все, сейчас будет весело - пароли , доступ к базе данных , все вкусное…

Можно уже писать отчет” но решил поковырять дальше! Как сказал один мой знаковый “Все что не RCE - то не бага”

“Покажи мне свой код и я скажу как тебя взломали!”

Для этой части статьи мне показалось что этот мем - самым точным образом описывает , дальнейшее описание кейса :-)

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

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

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

“Помни Neo! Картинки не существует!”

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

Что и следовало ожидать, никакой проверки файла и никакого переименовывания.

В итоге у нас есть RCE. Можно закрывать проект! Почему?

Изучив сервер, стало ясно, что на этом сервере держится вся инфраструктура и все приложения, “потушив” сервер - встанет все!

От увиденного, любой не опытный “пентестер” будет мягко говоря немного в шоке, а “чернушник” обрадуется от такой находки, потому что все исходники и все базы данных лежали именно на этом сервере.

Ну теперь точно все: все приложения скомпроментированны, RCE есть - можно спокойно писать отчет и ложиться спать :)

Заключение!

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

Данный кейс был очень похож на лабораторные машины с платформы HackTheBox , поэтому всем, кто хочет развиваться в направление Pentest | Red Team, очень советуем… (не реклама - простой человеческий совет)

Рекомендации:

  1. Не храните резервные копии на этом же сервере

  2. Ограничивайте IP-адреса с которых можно подключаться к административной части вэб-сервиса

  3. Ограничивайте попытки перебора файлов и директорий (средствами nginx.conf или apache .htaccess)

  4. Реализуйте фильтрацию и переименование загружаемых файлов с фор загрузки

❕Помимо действий по устранению, приведенных для каждой выявленной уязвимости, рекомендуется также выполнить следующие действия, позволяющие повысить общий уровень информационной безопасности Компании:

  • Не реже 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)


  1. Audrius_P
    12.08.2024 08:43
    #27155818
    +3

    Да ! Продадим яхту гендира и за полученные денюжки профинансируем реновацию бакапирования и проведем аудит безопастности !!!


  1. ifap
    12.08.2024 08:43
    #27157784
    +1

    Ограничивайте попытки перебора файлов и директорий (средствами nginx.conf или apache .htaccess)

    Расскажите или киньтесь ссылкой, пожалуйста.


    1. m4rck_kh1lz Автор
      12.08.2024 08:43
      #27159544

      Буду рад еще ответить в телеграм) к этому вопросу думаю будет еще статья по защите от подобных ситуаций)


    1. clevergod
      12.08.2024 08:43
      #27159550
      +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-адреса, которые делают слишком много запросов за короткий промежуток времени.