ZooKeeper信息泄露漏洞(CVE-2014-085)
研究ZooKeeper时顺便看到的,危害级别比较低,居然上了CVE,目测Apache有干爹照顾。对于node的访问,ZooKeeper提供了相应的权限控制,即使用访问控制列表ACL来进行实现。一个ACL只从属于一个特定的node,而对这个node的子节点是无效的,也就是不具有递归性。比如/app只能被10.10.10.1访问,/app/test为任何人都可以访问(world,anyon...
研究ZooKeeper时顺便看到的,危害级别比较低,居然上了CVE,目测Apache有干爹照顾。
对于node的访问,ZooKeeper提供了相应的权限控制,即使用访问控制列表ACL来进行实现。一个ACL只从属于一个特定的node,而对这个node的子节点是无效的,也就是不具有递归性。比如/app只能被10.10.10.1访问,/app/test为任何人都可以访问(world,anyone)。
创建node的时候如果不指明,那么默认是anyone:
用于访问控制的模式有:
(1)world 代表任何用户
(2)auth 不使用任何id,代表任何已经认证过的用户
(3)digest 使用username:password认证,password使用md5哈希之后base64再编码,现改成了sha1加密。
(4)ip 用客户端的ip作为ACL的标识。
CVE-2014-085是这么说的:
Apache Zookeeper logs cleartext admin passwords, which allows local users to obtain sensitive information by reading the log.
在zookeeper中zoo.cfg中可以配置dataLogDir来单独放置事务log,可以很好的避免与普通log和内存快照混合。
但是Zookeeper中使用了明文来显示密码,这就导致了信息的泄露。
做个例子看看。
如果访问一个受限制的资源,没有携带验证信息的话:
受限制的信息为/javaclient/authtest,设置了ACL为digest,口令为1234.
在java客户端中,我们可以使用ZooKeeper的addAuthInfo来携带认证信息。
如果没有通过验证,就触发异常:
本地使用这个漏洞查看log,就可以看到明文的digest,造成信息泄露,如果是admin的密码,就会造成更大的影响。
访问logs目录,grep一下:
看到了认证中客户端使用的密码1234。
这个漏洞应用场景应该是内网渗透中遇到ZooKeeper集群后,可以查找事务日志来获取admin的密码或者其他敏感资源的认证方法。
更多推荐
所有评论(0)