☰

Взлом PHP eval(gzinflate(base64_decode(..))) — как предотвратить его повторение?

tag-icon • tag-icon security php hacking vulnerabilities
Взлом PHP eval(gzinflate(base64_decode(..))) — как предотвратить его повторение?

Недавно наш сайт взломали, и в файл index.php был внедрен PHP-код, который выглядел примерно так:

eval (gzinflate(base64_decode('s127ezsS/...bA236UA1')));

Код вызывал включение другого php-файла (cnfg.php), что приводило к отображению спама, связанного с фармацевтикой (но видимого только для googlebot и т. д.). Это похоже на pharma hack для wordpress, за исключением того, что мы не используем указанное программное обеспечение. Код был удален, но я хотел бы предотвратить возникновение подобных случаев в будущем.

Я понимаю, что это довольно обширная проблема, и за ней может скрываться множество уязвимостей в системе безопасности, но я решил рассказать об этом на случай, если кто-то сталкивался с подобной проблемой в прошлом.

Какие потенциальные дыры в безопасности могут позволить загрузить эти php-файлы? И что я могу сделать, чтобы предотвратить это в будущем?

Ваше здоровье

решение1

Вам нужно выяснить, как это произошло.

  • Имел ли злоумышленник доступ к файловой системе через sftp/scp?
    • Если это произошло, вам необходимо заблокировать ваши методы удаленного доступа.
  • Использовал ли злоумышленник какой-либо скрипт загрузчика или ошибку в существующем скрипте, что позволило ему изменять файлы?
    • Исправьте скрипт, измените разрешения на ваши скрипты и веб-контент, чтобы процесс веб-сервера не мог их изменить. Веб-сервер должен быть ограничен изменением файлов в каталоге данных где-то. Ваши скрипты и файлы, как правило, не должны принадлежать веб-серверу или быть доступны для записи.
  • Может быть, скрипт является частью вредоносного программного обеспечения, которое вы не установили?
    • Я видел, как такие вещи включались в шаблоны WordPress. Ничего не подозревающий пользователь скачивал шаблоны с какого-то случайного сайта. Эти шаблоны включали функцию запуска кода с внешнего веб-сервера. Это в сочетании с плохими настройками разрешений позволяло злоумышленнику изменять другие вещи.

решение2

Просто предупреждение.

Если вы используете FileZilla в качестве FTP-клиента, существует вредоносное ПО, которое извлечет ваши учетные данные FTP из ПРОСТОГО ТЕКСТОВОГО ФАЙЛА Filezilla (ух ты!) и использует эту информацию для вставки вредоносного кода (на который указывает тип кода #b58b6f# вокруг команды "gzinflate(base64_decode)"). Именно так ваши файлы будут атакованы/скомпрометированы.

Посмотрите в папке %APPDATA%/Roaming/Filezilla. Один из XML-файлов там содержит все ваши учетные данные FTP-сайта (имя пользователя/пароль/и т. д.) ОТКРЫТЫМ ТЕКСТОМ! И разработчики FileZilla отказываются исправить эту очевидную дыру в безопасности.

Моя рекомендация: удалите FileZilla с вашего компьютера (и вам придется вручную удалить папку в папке APPDATA).

Если вам нужен безопасный FTP-клиент, используйте WinSCP (www .winscp .net ), где вы можете установить главный пароль, а все ваши учетные данные на сайте будут зашифрованы.

Просто предупреждение...Рик...Дж.

решение3

Существует огромное количество возможностей того, как это могло попасть внутрь. Одна часть информации, которая помогает ограничить это, — это тип вашего хостинга (общий, выделенный, виртуальный) и кто ваш хостер. Некоторые потенциальные точки входа:

  • Взлом учетной записи администратора
  • Компромисствойftp/ssh/веб-консоль/и т.д. аккаунт у вашего провайдера. Если вы когда-либо отправляли свой пароль через незашифрованный протокол (например, FTP), прекратите это делать.
  • Компромисствойсобственная локальная машина разработки
  • Уязвимость существует в любом серверном программном обеспечении на сервере, например, Apache или любом из его модулей.

  • Уязвимость уровня приложения в PHP на вашем сайте:

    • Используете ли вы стороннее программное обеспечение? Если да, то обновлено ли оно до последней версии?
    • Вы написали значительное количество собственного программирования на сайте? Если да, то есть миллион способов, которыми вы могли написать дыру. Проверьте любой метод, который касается данных, полученных от ввода пользователя (REQUEST/GET/POST/COOKIES/FILES). Если вы разрешаете загрузку файлов, сохраняете ли вы эти файлы нефильтрованными в каталоге, доступном для просмотра в Интернете? Если да, то кто-то может загрузить скрипт .php, а затем просто просмотреть его. Операторы include/require являются особенно горячими целями, если вы используете шаблонное решение, например:

    <?php include $_GET['page'] . '.php'; ?>

Как предотвратить повторение этого?

  • Убедитесь, что вы полностью доверяете безопасности вашего хостера. Позвоните им и расспросите об их политике безопасности, о том, как быстро они исправляют свои сервисы при обнаружении уязвимостей и т. д.
  • Откажитесь от дешевого общего хостинга и заплатите за выделенный или виртуально-выделенный. Меньше людей, использующих сервер, означает меньше векторов для атак
  • Поддерживайте актуальность своих сторонних приложений/библиотек. Подпишитесь на их рассылку, RSS-каналы или что-нибудь еще, чтобы быть в курсе их релизов.
  • Аудит собственного кода. Если у вас недостаточно опыта для этого, найдите того, кто за это заплатит.
  • Держите свой сайт в системе контроля версий, например git или subversion. Сохраняйте свой производственный каталог в качестве рабочей копии, чтобы вы могли легко обнаружить изменения в своей кодовой базе (но обязательно заблокируйте доступ к метаданным, таким как каталоги .git и .svn).

решение4

Вы можете попробоватьhttp://www.hardened-php.net/suhosin/что, помимо прочего, могло бы отключить eval(). Если бы cnfg.php был размещен удаленно, это могло бы также помешать его включению.

Если возможно, не предоставляйте пользователю, на котором запущен веб-сервер, права на запись в файлы PHP.

Связанный контент