发 现
10月18日,笔者手上的项目做完以后,便和网上的朋友天南海北地聊天。听到朋友网站的开张,心里也是非常的羡慕。
什么时候我才能拥有自己的主机和域名……想到申请主机和域名,笔者自然想到了X网(在中国太有名嘛^_^)。顺手打开其主页,突然看到了主页右上角的会员登录界面,这让笔者“贼”心又起——要是能发现什么漏洞就好了,反正现在也没什么事情。
笔者拿出端口扫描工具扫了一下X网的服务器,竟然什么漏洞都没有发现,真是郁闷!转念一想,毕竟X网也做了10多年了,这些大型网站服务器的安全措施恐怕不会少——映射,外加IDS和防火墙,补丁肯定也早打全了,说不定还有蜜罐程序等着你呢!
过了不久,笔者突然发现了一个情况,X网原来是用ASP写的。前段时间ASP+MSSQL的注入漏洞可是闹得沸沸扬扬,不少网站都吃了苦头。这里会有这类问题吗?不管了,先试一试再说。笔者随手找了一个购买虚拟主机的页面:http://www.???.cn/HAS_Client/buy/vir_host/vir_ host1_SB.asp?PackageID=10341。先用经典的方法来测试了一下,返回类型均为不匹配: ‘CDbl'错误。X网用的什么数据库呢?笔者在参数后面加上一个单引号,再提交请求,页面返回了一段报错信息。
原来用的是Oracle,一般Oracle数据库出现这样的返回错误,都可能存在漏洞的。这和MSSQL未闭合引号的返回错误差不多,不过MSSQL出现这样的错误提示,我们几乎可以肯定存在注入漏洞了,而Oracle则要再进一步确定。
确 认
以下几步为入侵的基础,非常重要。我们分别在IE中输入:
http://www.???.cn/HAS_Client/buy/vir_ host/vir_host1_SB.asp?PackageID=10341‘and%200<>(select%20count(*)%20from%20all_tables)%20and%20'1‘='1;
http://www.???.cn/HAS_Client/buy/vir_ host/vir_host1_SB.asp?PackageID=10341‘and%200<>(select%20count(*)%20from%20user_tables)%20and%20'1‘='1;
http://www.???.cn/HAS_Client/buy/vir _host/vir_host1_SB.asp?PackageID=10341‘and%200<>(select%20count(*)%20 from%20user_tab_columns)%20and%20'1‘='1;
以上这些是笔者猜测的Oracle的系统表:all_tables,user_tables和user_tab_col umns。如果没有,就没戏了。
没想到页面全都返回成功,这说明笔者猜测的系统表都是存在的,同时也说明提交的SQL语句,程序已经做了处理。
至此,笔者确认X网存在注入漏洞。
利 用
数据库可以说是一个站点的重中之重,通过笔者发现的这个漏洞,我们完全可以访问并修改数据库中的所有数据。不光是用户账号,对于所有存在数据库中的数据,我们都可以获取并修改。
在开放Public组的UTL_File权限的情况下,其实还可以利用Union查询、读取服务器上的文件,这点和PHP+MYSQL注入漏洞中的load_file()有些相似,当然也可以执行Update之类的。只是在Oracle注入漏洞研究上,笔者还是个菜鸟,没能实现插入数据和进行更高级的注入攻击。在整个测试漏洞的过程中,由于利用了NBSI的后台扫描功能和WPE,大大提高了效率。
现在,笔者已经可以得到X网所有用户的信息,只要登录进去,就能轻易更改他们的域名指向。如果笔者是一个恶意攻击者,只要把某个商业站点的域名指向指到自己制作的一个假站点上,那么用户登录这个商业站点的账号信息就毫无安全可言了。其实此漏洞和域名劫持有些相似,只要你是X网的用户,笔者肯定就能黑了你的站点。对于X网来说,其所有的业务都有可能受到影响,数据可以被任意获取窜改。
其他的一些危害也是显而易见的,就不再做具体说明了。
修 补
要防止这类注入漏洞其实很简单,只要对URL中提交的参数进行严格的过滤,去除一些比如单引号、SQL关键字等字符即可。具体做法:利用程序检查提交的URL中问号后的字符串,一旦发现单引号、分号、SQL关键字等特殊字符,马上就 会跳转到一个自定义的Error页面。
对于X网的网管来说,解决这个问题其实花的时间不到5分钟。另外,X网也应加强一下数据库中的数据安全,至少加个密吧!
顺便提一下,国内还有很多站点都存在这样的注入漏洞。
编 后
自从经历了许许多多蠕虫和病毒的攻击后,大家普遍对服务器的安全十分关注,有些站点甚至只开了80端口。如今在服务器上运行的代码的安全,就显得格外重要了。代码上一个小小的疏忽,往往就可能造成全局的崩溃。
今天有数据库的注入漏洞,明天又将出现什么呢?
声明: 此文观点不代表本站立场;转载须要保留原文链接;版权疑问请联系我们。