web应用程序中的rootkit
Author: jianxin [80sec]
EMail: jianxin#80sec.com
Site: http://www.80sec.com
Date: 2009-3-28
From: http://www.80sec.com/release/webapp-rootkit.txt
[ 目录 ]
0×00 为什么我们会有这个想法
0×01 web应用程序中后门的基本思想
0×02 实际应用中的一些例子
0×00 为什么我们会有这个想法
毫无疑问，web是近几年的热点，各种各样的服务都开始网络化，用户的敏感信息也开始不只是存储在自己的计算机里，而开始存储在服务提供商的数据库里，用 户无须为这些数据的存储和处理消费本地资源，只需要使用一个终端就可以访问和使用这些数据，而这些终端往往只需要一个浏览器和一些小小的网速就可以了。这 样的服务非常多，譬如非常典型的一个例子就是webmail，用户收发邮件，联系朋友或者客户，只需要打开浏览器就足够了。
同时，对于攻击者发生了一个什么样的变化呢？随着web的发展，越来越多的攻击开始指向web。开始的某些时候，黑客可能可以通过web程序的某些漏洞而 直接控制整个web程序，但是随着厂商安全意识的提高和在安全方面的投入，攻克一个如gmail这样的应用商已经不太现实了，那么自然越来越的攻击开始在 用户使用的终端上，因为一旦能控制某个用户终端的行为，实际上已经能完全控制这个用户的所有信息了，尽管黑客不能攻陷web服务器，但已经足够了。
但是这远远不够，因为往往一次攻击只能取得一次的效果，有没有可能在攻击成功之后，只要用户再次登陆这个web应用程序或者再次使用这个web应用程序的 时候都可以被我们监视到呢？有没有一种类似于后门的方式长期潜伏在应用程序里，适时地为我们再次获得该用户的应用程序权限，或者为我们一直监视用户的行为 呢？入侵服务器很明显是不太现实的，那有没有可能以其他的方式实现呢？
0×01 web应用程序后门的基本思想
传统的后门都潜伏于被攻陷的系统中，基于应用程序的后门为了实现我们指定的一些功能，也必须潜伏于一个环境当中，并且可以在一定条件下得以运行。譬如一些 经典的windows传统木马就是一个程序，在系统启动的时候启动起来。如果我们要控制一个应用程序，我们也必须需要一些代码，而且在某些时候能够运行起 来。
那么我们的后门代码可以存储在哪里呢？现在的应用程序越来越复杂，用户可以控制的东西也越来越多，用户控制的东西最终是存储在应用厂商的数据库里，然后每 次用户需要的时候，这些数据才被取出来展现给用户。那么很容易想到，存储的问题比较好解决，我们的代码其实是可以存储在应用厂商的数据库里的，甚至在某些 条件下的Cookie也是可以作为代码存储地，只要它将进入到我们所期望的逻辑。
那么我们的后门代码怎么样才可以运行呢？数据在不被执行的时候，永远不会有什么危害，所以执行是web应用程序后门的一个难点，不过也并非不可能。对于一 个web应用程序，数据最终是要处理好展现给用户终端的，这里的终端就是用户浏览器，如果这些数据在输出的时候没有进行安全处理，是很有可能发生一个 xss漏洞从而在用户浏览器里执行js代码的，利用js代码，其实就已经控制了浏览器了。现在的web应用程序变得非常复杂，在进行安全处理的时候往往关 注于外界来的数据的安全处理，而却可能忽视来自于自身数据库的数据的处理，拿一个webmail为例子，一般的思路往往把安全注重于在别人发送过来的电子 邮件上（数据来自于外部），而对于用户自身的数据（譬如邮件回复地址等个人设置选项，别人是无法控制的）却缺乏安全的过滤，这就让我们的后门获得执行的机 会。
那么我们的后门代码可以做什么呢？像上面所说，我们的代码执行的地点的不同决定了它可以做不同的事情，实现不同的目的。譬如如果我们的代码在每一次登录进 应用程序都会执行的话，那我们就可以每次都可以获取到用户最新的登录信息从而登录进应用程序，这种机会尽管非常小，但是不是没有哦！另外某些应用程序提供 些特殊的功能，譬如webmail可能会提供邮件转发的功能，那么我们可以利用这个功能来实现后门，但是这样是非常不隐蔽的，用户很可能会在进行邮箱设置 时发现我们所做的修改，这个时候如果在同一页面存在xss漏洞的话，我们就可以将这段设置从用户的浏览器里抹除掉，并且对用户在该页面进行提交的动作进行 监视，完全实现一个类似于rootkit的功能。我们所能作的，完全取决于应用程序自身的逻辑和我们的exploit点所处的位置。
0×02 实际应用中的一些例子
在07年的时候，我们曾经报告给Yahoo一个漏洞，在yahoo webmail的常规首选项里由于对回复地址的过滤存在问题，导致在这里写入exploit代码，可以在用户登录的时候就执行，从而实现一个后门，在每一 次用户登录进yahoo webmail的时候就可以触发。当时的exploit代码：
在回复地址里写上：
",aaa:alert(document.cookie),b:"@80sec.com这部分代码将在登陆时出现在页面的js代码中，并且由于对恶意字符的过滤不严格，导致执行js代码。
该漏洞已经得到修复。最近在QQ Mail里出现的一个漏洞也证明了在实际应用中的可能性，在QQ Mail的常规设置面板里存在一个xss漏洞，一般安全人员对于这种漏洞都会忽视，因为这里的漏洞必须要求用户已经登录，并且自己对自己实现xss攻击。 但是一旦将漏洞利用到后门上，将会非常美妙，因为通过这里的xss可以修改用户在设置面板里所看到的任何东西，并且对用户的提交做自己的预处理，用户可能 永远也不知道在这背后被人修改了什么，而这被修改的东西往往是非常重要的东西，譬如邮件转发地址。
0×03 启示录
现在的web应用越来越复杂，各种客户端技术如json，ajax，flash的使用，使得即使在客户端往往也存在着各种各样的输入输出逻辑，这也提供了 更多的可能供黑客利用的地方。我们更倾向于将web应用作为一个独立的系统来看待，数据的计算存储都是在远程的服务器上进行（类似于传统的硬件资源），但 是数据的展示和交互却是在客户端上（类似于传统的操作系统），在这个操作系统上执行的任意的代码都可能给这个系统带来严重的安全问题，这样我们在评估一个 漏洞的严重性的时候，也需要结合具体的应用程序的上下文，不同的地方相同的漏洞执行相同的代码，得到的效果也是不同的，而在考虑应用程序安全性的时候也该 考虑那些来自于用户的看起来比较可信的数据了。
本站内容均为原创，转载请务必保留署名与链接！
web应用程序中的rootkit:http://www.80sec.com/webapp-rootki.html
