从对一个安全产品的测试看产品架构安全

前言

由于之前工作需要,笔者经常接触一些业界安全产品,对其性能、安全性等等的分析自然是关注的重点。好的地方自然要学习,如果有缺陷的地方则值得我们自省,看自己的系统和产品是否也会有这些问题呢?

鉴于商业产品的保密性,将隐去部分敏感内容。

产品分析

产品简介

某安全产品

产品架构

程序:Web管理界面+后台服务。

网络:可串联或并联于网络中,管理通过web接口或自定义的console

探测分析

通过简单的扫描分析,其web前端采用的是Apache+php+DB 架构。


安全性测试

    帐户安全

虽然此产品我们能见到的只是一个‘铁盒子’,但通常能猜测到,它其实就是一个linux系统加自研的安全产品的形式。

它提供了console模式的管理,web管理用户和console账户是同一个,我们发现如果添加的账户名为root会失败,基本上能证明他是linux系统。

除root之外的普通用户登陆后,出现的是一个自定义的console界面,不是bash。

在这里给大家提个醒:类似的铁盒子(安全产品),root账户和密码是没有提供给用户的,也就是说开发商知道你的产品的root密码,如果将其架设在一个外部用户能访问的地方,可能会导致开发商有机会登陆你的系统。就算开发商很有良知,员工不会违反职业道德,也不排除它同类产品root密码可能一致,此商家的其他用户获知此密码用于尝试您的系统的可能性。所以此产品或管理端口,必须设置为外网不能访问,且内部员工仅有有限的访问权限

web安全

此产品提供web管理界面,web类安全问题常见的是2种:1、注入;2、xss跨站。

Sql注入自不必说,可修改DB 数据。一个依赖DB数据进行运转的系统来说,sql注入的危害已经是非常大了。

命令注入是指某些需要将用户输入的数据作为命令的一部分时,未对数据的合法性作校验,导致恶意用户可以随意构造命令执行。

Xss跨站问题,大家觉得在一个后台维护类系统上问题不大。其实不然,如果一个低端用户(来宾访问、厂商例行查验)利用XSS 的ajax方式,可将自身的权限提升至受害者用户一样的权限。

通过简单的测试,发现一处很明显的sqlinject漏洞:

GET /server/ip_edit.php?id=1;select version();

从架构缺陷到系统权限

如果仅停留在web漏洞上,大家显然觉得不过瘾。下一步我们来看如何得到整个系统的权限。显然用linux系统exploit不太可能,厂商的补丁齐全,且无gcc环境。只能改由其他途径。

对于架构的思考:一个web系统,通过添加web账户,能使其账户也添加到系统账户中去,他是如何做到的呢?

 


我们暂且作2个假设,然后做相应的尝试和探索,或许能绕过安全防范获得root权限:

a) webserver 是root 权限

b) 通过db数据或其他媒介,让一个具有root 权限的后台程序来自动完成添加操作。

 

前面的sql注入漏洞,使我们已经能访问其文件系统和执行系统命令。通过读取此产品的后台系统代码。发现了确实是上述的第二个猜想。

我们在后台系统代码中发现命令注入漏洞,而后台进程是root权限启动的,通过sql注入漏洞结合某来至db的参数的命令注入漏洞,继承了后台进程的root权限。

So,一切都结束了。

总结与思考

对于以上产品的分析,我们总结一下它的问题。

 

 

利用sql注入漏洞,攻击者获得继承了webserver权限

利用后台系统命令注入漏洞,攻击者获得继承了后台系统的root权限

由此可看出,要想建设一个安全的产品和系统,权限的隔离是关键。但如何能做到权限隔离呢,从以下几个方面:

 

网络隔离。再NB的系统他都或多或少有些毛病,更何况是一些运维类高敏感系统。做好隔离,可以最大限度的将可能存在的风险降低到最小。

严格校验数据输入。严格校验数据输入应该是开发人员的常识,对任意一条数据来源都要假设他是‘不可靠’的,即使它来至内部系统。

最小权限原则 。最小权限原则也是一种隔离的思想,假设你的系统也不是完美了,可能会出现瑕疵和漏洞。如果它运行在较低权限,就算出现任何安全问题,也不会导致系统最高权限被入侵者拿到。

相信从网络、主机、代码三个层面的纵深防御,您的系统将更加安全可靠。

本文作者xti9er[TSRC]转自腾讯安全应急响应中心由网络安全攻防研究室(www.91ri.org)信息安全小组收集整理。