WHMCS взломан с помощью {php} и кода Eval base64 с помощью билетов [закрыто]
WHMCS использует Smarty для своей системы шаблонов, хотя у отличной системы шаблонов есть недостаток - теги {php}. Эти теги позволяют smarty интерпретировать PHP-код непосредственно в шаблоне или, в данном случае, через систему тикетов при создании нового тикета. Этот взлом происходит постоянно в системах WHMCS, вы можете попробовать заблокировать код в WHMCS с помощью опции блокировать текст в конфигурации. Но в большинстве случаев это не работает.
Что происходит, так это то, что WHMCS принимает билет и хакер добавил следующее в сообщение о билете:
{php}eval(base64_decode(encoded message));{\php}
Итак, smarty видит часть {php} и немедленно запускает эту команду. Поэтому он сначала декодирует PHP, закодированный в base64. Это приведет к появлению некоторой функции/скрипта PHP, которую пытается запустить хакер.
Затем eval берет на себя и фактически оценивает PHP-код и запускает его на стороне сервера.
Многие хакеры поступают таким образом, они запускают коды, которые, как они знают, будут работать в WHMCS, которые затем захватывают информацию базы данных и передайте его в файл. Затем они просто захватывают этот файл через URL-адрес браузера и получают нужную им информацию.
Это работает только на некоторых установках WHMCS, хотя WHMCS говорит, что самая последняя версия этого не позволяет, и {php} отключен в Smarty, иногда хакеры находят способ обойти это и eval их код.
2 answers
В конфигурации Smarty есть флаг для включения/отключения этого, и он должен быть выключен по умолчанию.
Если WHMCS требует использования тегов {php}, то они [выражаясь как можно вежливее] невероятно отсталые и должны уйти из бизнеса выставления счетов или любого другого программного обеспечения.
Редактировать: Да, прямо здесь, в их документах. "Эй, смотри! Мы включили эту супер гигантскую дыру в безопасности только для ты!"
Возможно, вам захочется просмотреть файлы шаблонов, чтобы найти любое использование этих тегов {php}, поскольку это укажет на любую функциональность, которую вы потеряете, заткнув эту зияющую дыру в безопасности.
На самом деле это очень простой хак, который можно исправить с помощью mod_security. Во-первых, найдите, где находится ваш конфигурационный файл mod_security, все зависит от вашей установки mod_security и операционной системы, но обычно он называется modsec.conf или modsec2.conf, иногда security.conf, но очень редко.
Вы можете найти его с помощью команды locate, если она установлена, в большинстве систем Linux.
sudo updatedb
locate modsec.conf
or
locate modsec2.conf
Если у вас нет locate, вам нужно будет перейти в каталог / и просто запустить find, это займет некоторое время но иногда панели устанавливают его в странных местах, а не только в /etc.
cd /
find . -type f -iname 'modsec*.conf'
В любом случае будет работать, чтобы найти файл конфигурации. После того, как вы нашли, используйте свой любимый редактор, чтобы отредактировать файл, перейдите в самый низ и добавьте следующее:
SecRuleEngine On
SecRule ARGS {php} "severity:4,log,deny"
SecRule ARGS eval "severity:4,log,deny"
SecRule ARGS base64_decode "severity:4,log,deny"
В основном вы говорите ему фильтровать аргументы в GET и POST. Вот и все, перезагрузите apache сейчас:
CentOS:
service httpd restart
Ubuntu:
service apache2 restart
Теперь вы можете подумать, что это вообще не позволит вам использовать эти команды в сценариях. Это только блокирует те слова, отправленные по GET или POST. Если кто-то попытается, он получит ошибку Not Acceptable, и это просто не сработает вообще.
Это избавляет вас от необходимости блокировать кучу IP-адресов с вашего брандмауэра или WHMCS и потенциальных клиентов.