Безопасность проекта: дебаг и логи для разработки, забытые утилиты и не самое обновленное ПО

Привет! Сегодня хочу поговорить про безопасность разработки. В последнее время команда безопасности ASAP Lab обнаруживает возрастающее количество атак на сайты клиентов на разных CMS на нашем хостинге Scalesta и поддержке и администрировании сторонних серверов.

Мы провели совместное расследование с командой CS-Cart и пришли к совершенно ожидаемым, но не самым утешительным результатам :confused:

По результатам расследования мы выявили 3 общие группы проблем, которые, к сожалению, и приводят к взломам сайтов и утечке данных. Обе они связаны с некорректно выстроенным процессом разработки.

  • Забытые файлы логов и дебаг-информации, а иногда даже и дампы баз данных, скорее всего по неосторожности или невнимательности, но это факт :frowning:
  • Доступные извне утилиты, такие как Adminer или Git - но тут скорее из-за некорректной конфигурации серверов
  • Местами есть дефолтные креды к админкам и вендоркам с дефолтными путями типа vendor.php

Конечно, это лишь верхушка айсберга, но давайте вместе внимательнее посмотрим на последствия таких ошибок. Кстати, не лишним будет эту ветку и своим разработчикам показать, а если есть у кого возражения или вопросы какие – велкам с вопросами в тред, отвечу всем :slight_smile:

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

А файлы phpinfo.php, info.php, i.php и прочие, которые содержат в себе информацию phpinfo(); могут раскрыть не только пути к страницам сайта, но и в совокупности с такой атакой как Cross Site Scripting (XSS) могут дать злоумышленнику доступ ко всем cookie-файлам (да-да, даже с флагами http-only). А это в свою очередь даст хакеру доступ, например, уровня администратора. А выглядит так, как будто там просто информация о версии PHP, да?

Утилиты, доступные извне, такие как Adminer или Git
Некорректная конфигурация сервера может раскрыть исходный код проекта или дать доступ к директориям и файлам, к которым доступа вообще быть не должно (да, директории и файлы с точки). Ни у кого! Давайте используем для примера утилиту для совместной разработки Git. Если директория существует и она доступна, то при определенных знаниях и умениях можно получить весь исходный код проекта и там уже искать уязвимости или захардкоженные креды.

Ну и не пройдем мимо “первопричины” самых частых утечек, и я говорю про утилиту для администрирования базы данных Adminer. У нее много уязвимостей, которые вендор, безусловно, исправляет. Но вот разработчики и администраторы очень неохотно обновляют ее.

Вообще, доступная извне утилита Adminer, так же как и phpMyAdmin, и другие утилиты для доступа к базе данных могут предоставить злоумышленнику достаточно информации для эксплуатации таких уязвимостей как CVE-2021-43008 (7.5/10 HIGH), CVE-2021-21311 (7.2/10 HIGH) и CVE-2020-35572 (6.1/10 MEDIUM). Особенно в совокупности с доступными лог-файлами и phpinfo или даже просто включенным debug-режимом (а что уж говорить про другие техники). Ну и как результат это в 90% случаев приводит к доступу к базе данных и утечкам.

Да, я не исключаю, что иногда бывают ситуации, когда разработчикам или аналитикам нужно получить прямой доступ к базе данных, но это скорее говорит о “сломанном” процессе. Изменения в базу данных лучше вносить миграциями, которые есть в CS-Cart, кстати, а для аналитиков рекомендую делать read-only реплику базы данных, закрытую извне и доступную только через SSH-туннель.

Результаты исследования

  • Из более чем 100к проверенных проектов 14% имеют различного рода уязвимости и находятся в зоне риска, а 5% из выявленных уязвимостей - критические. В ближайшее время команда CS-Cart свяжется с владельцами таких проектов, чтобы исправить эти уязвимости.
  • 71% из всех утилит доступа к базам данных не обновлены и имеют уязвимости, а 17% из них имеют критические уязвимости уровня remove code execution и arbitrary file read
  • 3% процента проектов имеют доступную извне директорию .git, что говорит о некорректной настройке веб сервера и может также раскрывать исходный код проекта
  • 67% работают на устаревших версиях PHP, которые имеют проблемы с производительностью и безопасностью и уже не будут иметь исправления безопасности
  • Мы не везде смогли определить версию CS-Cart и модулей (по понятным на то причинам) – это думаю каждый знает по своему магазину

Отдельно хочу остановиться на устаревшем или не обновленном программном обеспечении. CMS, модули или серверное ПО — все это нуждается в регулярном обновлении, чтобы быть в безопасности. Обновления не только добавляют новую функциональность, но, что более важно с точки зрения безопасности, имеют исправления уязвимостей, улучшения производительности и патчи безопасности.

Помните – защита вашего магазина зависит не только от качества CMS или опыта ваших разработчиков и поставщиков услуг, но и вас самих. Внимание к деталям, налаженный процесс разработки (CI/CD) и регулярные обновления (кэп) также могут оградить вас от распространенных проблем с безопасностью.

7 лайков