如今,越来越多的网络攻击开始瞄准第三方插件或文件。说到安全检测,大家最熟悉的可能是SQL注入、文件上传漏洞,或是因网站配置不当、管理员疏忽导致的隐患。但别忘了,第三方插件和文件同样可能成为攻击者的突破口。这次,我们以ewebeditor在线文本编辑器为例,看看如何利用它的疏漏来获取网站权限。
一天我正在工作,MSN突然弹出消息,朋友说他花钱建了一个网站,购买了域名和空间,希望我帮忙测试网站和服务器安全,尽可能找出潜在风险。盛情难却,于是开始了这次安全检测之旅。
朋友告诉我,他使用的空间就是购买程序时官方赠送的一年免费使用权。这么看来,服务器上肯定部署了不少网站,而且很可能运行着类似的程序。那么,是不是可以先攻破其中一个,摸清配置信息,再用同样的方法拿下其他站点?顺着这个思路,我开始动手。
首先打开朋友发来的域名:www.pockxxx.com。粗略一看,这是一个英文站,主要销售手机和游戏机。用IP138查询了一下,域名对应IP 210.51.22.X,北京网通,应该是托管在IDC机房。接着用Superscan和IIS扫描器进行了扫描,结果如下:
- 服务器操作系统:Windows 2003,IIS版本6.0
- 开放端口:80、1433、3389,共三个
- Telnet 220.250.64.X的1433和3389端口,均无法连通,估计安装了防火墙或IDS之类
既然只有80端口对外开放,那只能从Web程序入手了。
打开网站,界面挺漂亮。初步判断是ASP程序。第一步当然是检查SQL注入。随便点开一个链接:https://www.pcokXXX.com/product.asp?id=1294,在地址后面加一个单引号,返回的错误信息如下:
Microsoft OLE DB Provider for ODBC Drivers错误 '80040e14' [Microsft][ODBC Micorsoft Access Diver] 字符串语法错误 在查询表达式'product。asp?id=1294'中。 /product。asp,行 32
这个错误透露出几个关键信息:
- 网站使用的是Access数据库,通过ODBC连接,而不是JET引擎
- 程序没有对用户提交的数据做合法性校验
- SQL语句查询的表中有一个名为productID的字段
看来是ASP + Access的架构。接着用and 1=1和and 1=2测试,返回结果不一样——存在SQL注入漏洞。不过,Access数据库只能猜解管理员密码,登录后台获取Webshell;如果是SQL Server,还有机会利用BACK备份来获取Webshell。
确认存在注入漏洞后,开始猜解密码。在注入点后面加上:
And (Select Count(*) from Admin)>=0
页面返回正常,说明存在admin表。既然有admin表,继续猜解字段。这种程序常用的字段无非就是username、password、id、userid、user_password、pwd、name、userpwd等等,逐个尝试即可。经过一番猜解,发现admin表里确实有username、password、id三个字段。为了验证,又用啊D的SQL注入工具跑了一遍,结果一致,确认无误。如图1所示。
500)this.width=500" title="点击这里用新窗口浏览图片" />
上一页12 3 下一页 阅读全文
