瑞星某站SQL注入29个库泄漏(获取OS Shell)

漏洞概要

缺陷编号:WooYun-2015-0127886

漏洞标题:瑞星某站SQL注入29个库泄漏(获取OS Shell)

相关厂商:RiSing

漏洞作者:路人甲

提交时间:2015-07-21 10:14

公开时间:2015-09-04 13:16

漏洞类型:SQL注射漏洞

危害等级:高

自评Rank:20

漏洞状态:厂商已经确认

Tags标签:

漏洞详情

披露状态:

2015-07-21: 细节已通知厂商并且等待厂商处理中
2015-07-21: 厂商已经确认,细节仅向厂商公开
2015-07-31: 细节向核心白帽子及相关领域专家公开
2015-08-10: 细节向普通白帽子公开
2015-08-20: 细节向实习白帽子公开
2015-09-04: 细节向公众公开

简要描述:

一个查询页面存在sql注入,然后全部29个数据库;同时获取OSshell

详细说明:

注入地址: http://chat.rising.com.cn/webcsc/ens/ashx/GetCity.ashx?pid=9

漏洞证明:

修复方案:

验证所有输入始终通过测试类型、长度、格式和范围来验证用户输入。实现对恶意输入的预防时,请注意应用程序的体系结构和部署方案。请记住,为在安全环境下运行而设计的程序可能被复制到不安全的环境中。以下建议应被视为最佳做法:对应用程序接收的数据不做任何有关大小、类型或内容的假设。例如,您应该进行以下评估:如果一个用户在需要邮政编码的位置无意中或恶意地输入了一个 10 MB 的 MPEG 文件,应用程序会做出什么反应?如果在文本字段中嵌入了一个 DROP TABLE 语句,应用程序会做出什么反应?测试输入的大小和数据类型,强制执行适当的限制。这有助于防止有意造成的缓冲区溢出。测试字符串变量的内容,只接受所需的值。拒绝包含二进制数据、转义序列和注释字符的输入内容。这有助于防止脚本注入,防止某些缓冲区溢出攻击。使用 XML 文档时,根据数据的架构对输入的所有数据进行验证。绝不直接使用用户输入内容来生成 Transact-SQL 语句。使用存储过程来验证用户输入。在多层环境中,所有数据都应该在验证之后才允许进入可信区域。未通过验证过程的数据应被拒绝,并向前一层返回一个错误。实现多层验证。对无目的的恶意用户采取的预防措施对坚定的攻击者可能无效。更好的做法是在用户界面和所有跨信任边界的后续点上验证输入。例如,在客户端应用程序中验证数据可以防止简单的脚本注入。但是,如果下一层假设其输入已被验证,则任何可以跳过客户端的恶意用户就可能不受限制地访问系统。绝不串联未验证的用户输入。字符串串联是脚本注入的主要输入点。在可能据以构造文件名的字段中,不接受下列字符串:AUX、CLOCK$、COM1 到 COM8、CON、CONFIG$、LPT1 到 LPT8、NUL 以及 PRN。参考地址:https://technet.microsoft.com/zh-cn/library/ms161953(v=sql.90).aspx

漏洞回应

厂商回应:

危害等级:中

漏洞Rank:5

确认时间:2015-07-2113:14

厂商回复:

3Q

最新状态:

暂无

评价

  1. 2010-01-01 00:00 evethunder 白帽子 | Rank:0 漏洞数:0)

    那个。。 是不是我表达的不够细致,危害描述的不够清楚。
    这么大量的数据库泄漏,包括全部用户信息、密码、OS管理员权限等等。
    怎么就给了5个rank。。。。好郁闷。

  2. 2010-01-01 00:00 凌零1 白帽子 | Rank:187 漏洞数:16)

    @evethunder 节哀!!以后记得多贴点

  3. 2010-01-01 00:00 evethunder 白帽子 | Rank:0 漏洞数:0)

    @凌零1 学习了

  4. 2010-01-01 00:00 憋屈 白帽子 | Rank:15 漏洞数:1)

    @evethunder 楼主问下,你绝对路径怎么找到的,,,每次os_shell都是找不到绝对路径而没继续了

  5. 2010-01-01 00:00 dr.m1st3r 白帽子 | Rank:15 漏洞数:1)

    权限真尼玛大。。。