Drupal SQL注入漏洞后的一周——黑客教了我们什么？-莱卡云

在10月15日，黑客们忙着跟进一个问题：如何利用Drupal 7的SA-CORE-2014–005漏洞进行SQL注入。一个星期过去了，攻击者们仍然在持续忙碌。Moshe Weizman发文解释了我们如何在这一缺陷暴露的情况下保护客户的网站。在本文中，我们会看看近期对Acquia Cloud中针对SQL注入缺陷的攻击的来龙去脉。

本文的数据基于Acquia Cloud上托管的几万个网站中产出的大量日志，并经过了内部工具的整理和分析。所有本文中提及的时间都是美国东部标准时间。我们目前认为Acquia Cloud中的站点尚未被击破，所以我们只会描述一些入侵的尝试，不过外边的Drupal站点来说，运气可能就没那么好了。如果在阅读本文时你还没有对你的站点进行修补，也许下一分钟你的站点就已经被侵入了。

#模式1：docroot中的后门

攻击次数：7785

首次发现：10.16 4:09

在官方声明当天，很多用户在Drupal.org的论坛和IRC报告他们发现站点的docroot中发现了Josh Koenig描述的后门。它在你的核心模块目录中创建随机文件，例如modules/aggregator/dlov.php，这是一个允许攻击者运行PHP代码的后门，很多用户说他们的站点已经被打了补丁。黑客们利用后门给Drupal打补丁，大概是为了确认他们对站点的所有权，并防止其他黑客的进入。

    INSERT INTO `menu_router` (`path`, `load_functions`, `to_arg_functions`, `description`, `access_callback`, `access_arguments`) VALUES (dlov, '', '', dlov, 'file_put_contents', HEX)

我跟踪这个攻击，发现了一个俄罗斯IP 62.76.191.119。IRC上的其他人也确认他们被入侵的站点也是遭到了同一个IP的入侵。这个IP从10.16 3:00到10.17 13:00的一段时间里，连接我们的平台36786次，这些连接包括：

在用户登录Form中，利用SQL注入漏洞执行上文提到的SQL语句。
多次到/dlov以及/?q=dlov的GET请求，用于在docroot中保存后门。
更多的GET请求用于访问后门文件（modules/aggregator/dlov.php）。

因为Acquia Cloud提供了SQL注入防范，所有的这些GET请求都返回了404，即使是第一个POST请求也没能突破这一防线。因为docroot是web server无法写入的，所以即使SQL注入能够执行，这一攻击对Acquia Cloud也是无法奏效的。

下图展示了34个小时中针对不同站点的的7785次POST：

post diagram

译者注：用find [drupal_path] -mtime -[day_count] -type f -print 列表指定天数内被修改的文件，应该可以检查站点是否符合本模式
#模式2：/user路径中的后门

攻击次数：732

首次发现：10.16 7:38

我在10月17日证实了这一模式后立即发表了一篇文章。这一攻击启用了PHP模块，并更新menu_router中/user的access_callback为php_eval，这使得攻击者可以通过各种请求来执行任意PHP代码。

    TRUNCATE TABLE cache_bootstrap;UPDATE menu_router SET access_arguments=HEX, access_callback=HEX WHERE path=0x75736572;UPDATE system SET status = 1 WHERE name = 0x706870;INSERT INTO registry_file (filename,hash) VALUES (HEX, HEX);

这类攻击的长处在于，无需写入docroot，不过他在清除menu cache的时候同样暴露了。

这类攻击并无特定IP特征，不过猜测可能来自于一群肉鸡。下面是一些我发现的IP：92.222.172.41, 199.27.76.34, 192.42.116.16, 199.27.76.30, 199.27.76.25, 162.247.72.7, 209.234.102.238, 85.25.103.48, 95.130.9.89。所有这些IP在我们的平台上都被标记为垃圾流量，最后四个IP是Tor IP：

tor ip

译者注：用select * from menu_router where access_callback='php_eval'应该可以检查该模式

#模式3：在Body中创建一个PHP代码Block

攻击次数：24

首次发现：10.17 9:17

攻击者创建一个自定义Block，格式为PHP代码，并在Block中插入以下代码：

    

        insert into block(module,delta,theme,status,weight,region,custom,visibility,pages,title,cache) values ('block','63353',(select substring_index(substring_index(value,'"','2'),'"',-1) from variable where name='theme_default'),1,0,'footer',0,0,'','',-1);insert into block_custom(bid,body,info,format) values (63353,HEX,'nonono','php_code');insert into filter_format values ('php_code','PHP_code',0,1,11);insert into filter values ('php_code', 'filter', 'filter_autop', 0, 0, HEX),('php_code', 'filter', 'filter_html', -10, 0, HEX),('php_code', 'filter', 'filter_htmlcorrector', 10, 0, HEX),('php_code', 'filter', 'filter_html_escape', -10, 0, HEX),('php_code', 'filter', 'filter_url', 0, 0, HEX),('php_code', 'php', 'php_code', 0, 1, HEX);update system set status=1,schema_version=0;delete from cache_bootstrap;delete from cache;delete from cache_menu;

译者注：用查询select * from block_custom where format='php_code'，列出格式为PHP CODE的所有Block

#其他模式：复位管理用户名和密码，或者插入新的管理员用户

攻击次数：3000+

首次发现：10.15 20:20

这个模式是最先出现的。

下面这个查询对1号用户进行重命名，并修改了密码：

    update users set name='jhuang' , pass = 'HASH' where uid = '1';

下面的查询创建了一个新的用户，并给他一个巨大的uid，使之不会同现存用户冲突。角色ID为3，3是缺省的管理员角色编号。

    insert into {users} (uid,name,pass,status) values (333333,'admin2','HASH',1);insert into {users_roles} (uid,rid) values(333333,3);

主要的发起IP是：118.113.158.7, 103.242.1.193, 118.113.158.7, 125.70.172.51, 222.211.211.65, 125.70.173.81, 103.242.1.193

另外一个类似的查询是：

    INSERT INTO `users` VALUES (9999,HASH,'test@test.com','','',NULL,1413423527,1413426879,1413426953,1,'Africa/Abidjan','',0,'test@test.com','b:0;');insert into `users_roles` values (9999,3);

这个查询很有趣：攻击者试图把自己的IP替换为Google DNS的8.8.8.8。

下面的查询查找最大UID用于接下来的写入动作：

    set @a=(SELECT MAX(uid) FROM users)+1;INSERT INTO users set uid=@a,status=1,name='phantom' , pass = 'HASH';INSERT INTO users_roles set uid=@a,rid=3;

#结论

这些问题给我们一个机会去学习黑客们面对未关闭漏洞的行为方式。攻击者们在漏洞发现后的几个小时内就开始攻击。我们不确定攻击者需要掌握多少Drupal相关的知识，但是现有情况表明，一点点就足以致命。如果你目前还没有对你的站点进行修补，而且没有托管在Acquia这样的平台上，几乎可以肯定你已经被攻击了。

在对攻击的分析中，我们认为攻击者并不只是针对Drupal 7：我们发现攻击者同样瞄准了Drupal 5和6的站点。99%的被攻击域都是极少被攻击的开发站点或是无用站点。我们没有发现尝试修改内容或停掉网站的攻击，攻击者们似乎只乐于安装后门，获取控制权，并隐藏入侵迹象。本文中多数查询都是节选。被去掉的部分都是MySQL自然支持的十六进制。黑客们似乎偏爱用这种方式来混淆危险的PHP操作，并骗过可能的检测。

要确定你的站点是否被侵入，可参考官方的FAQ，并阅读《站点被黑怎么办？》。另外还有个有用的流程图：Your Drupal website has a backdoor。值得注意的是，即使你打了7.32补丁，也可能在打补丁之前被入侵，可以参看reported a hack on the zen theme on this site。

还有一个问题是，这次SQL注入缺陷是否在login form之外被利用。目前我们还没有发现这种情况，我们的客户以及Drupal社区也没有报告此类攻击。这不意味着不存在这种风险，说不定已经存在这种攻击。我们相信we protected all our customers from this attack能够防范类似的攻击，当然，这种推测只能靠时间来证明。

文章来源于互联网:Drupal SQL注入漏洞后的一周——黑客教了我们什么？

相关推荐