前言

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

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

产品分析

    产品简介

   某安全产品

    产品架构

    程序：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的系统他都或多或少有些毛病，更何况是一些运维类高敏感系统。做好隔离，可以最大限度的将可能存在的风险降低到最小。

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

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

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