利用SAP 0day,四分钟内黑掉华尔街

简介: 本文讲的是利用SAP 0day,四分钟内黑掉华尔街,前一段时间,我一直想对下面一个问题做一个回答:
本文讲的是 利用SAP 0day,四分钟内黑掉华尔街前一段时间,我一直想对下面一个问题做一个回答:

作为一个安全研究专家,在一个小时之内,我可能拿下多少台服务器,这些服务器能够达到什么质量?我可以攻破世界财富排行榜前500的企业服务器吗?

测试表明,只要使用Google、shodan以及masscan,我可以在一个小时之内拿下来10台服务器。其中有6分钟没有进行攻击,只是对痕迹进行擦除以及种植后门。测试过程中,脚本的工作量以及手动的工作量各占一半,我感觉脚本无论如何都不能代替手动验证。当然,这篇文章不是讲述这些的。

在测试过程中,一个问题自然而然的出现在我的脑海中:

黑掉华尔街那些公司、银行以及那些国际商业巨头需要多长时间呢?

他们几乎都使用了SAP,在之前对我一个客户进行渗透测试时,发现了一个SAP的0day漏洞。这个时候我就意识到了一些大的公司都是使用的SAP。

例如:这篇安全人员致谢文章中,你可以在2016年10月份找到我的名字,而且过不了几天你就可以在2017年五月这一挡中找到我的名字:)

比较讽刺的是,我不是一个熟知SAP的人。除了我以前梳理过的简单10页基础教程,别的我对它一无所知。但是我同样使用owasp top10中的方法找到了一个漏洞,所以我为什么不再钓一个大鱼呢?比如SAP的云服务。

挖洞的第一步我采用Google搜索搜集一波信息:

site:*.accounts.ondemand.com

这一搜索我就发现好多使用"SAP云服务"、"SAPHANA版本"、"SAP HANA企业版本"的公司。我随便加载了一个页面,三秒中之内我发现了它前端使用的是ruby,后端使用的是java。既然这样,我们就可以通过模糊测试找到它使用的是哪种框架来搭建的这一服务(Struts, Spring, Hibernate, Tomcat, Jboss, Jenkins, 等等)。

在事实上,我断定struts一定不会被使用,因为它爆出了好多漏洞。任何人都知道。Jenkins同样是这个原因,肯定不会被使用。
tomcat,Spring,Jboss都有很大的可能,而且jboss不会和SPring同时使用。因为这篇文章讲的是挖漏洞,不是上java课,所以这里就不详细说明了。

为了让测试过程变得简单,我制作了一个基于Spring的fuzz列表。任何人都知道这些目录:

actuator, auditevents, autoconfig, beans, configprops, dump, env, flyway, health, info, loggers, liquibase, metrics, mappings, shutdown , trace.

但是这里有一个问题,这些目录因为禁止访问都返回403,不能直接访问。所以我很自然的尝试了一下:”../../../../../目录名”,此时返回了tomcat错误页面。然后我尝试访问admin目录,一个不同出现了。当我输入”/admin/目录”服务器发生了什么?也许一些XML文件只禁止了admin目录访问,而没有禁止admin目录下的文件夹访问。

值得庆幸的是admin目录下可以进行模糊测试。在我测试过程中,最重要的一个目录是/admin/trace。这一目录会产生所有进行登录的管理员的cookie。如果能够到了这一目录,那么整个测试就可以说已经结束了,因为我们可以产生管理员的cookie,进而登录后台。在cookie中最重要的三个为:”IDP_J_COOKIE”、“ids”以及“idsr”。当然还有像“XSRF_COOKIE”这样的其他cookie,但是他们在代码中并没有正确的实现。我现在将这些cookie在浏览器中修改,然后刷新浏览器,就可以得到*.accounts.ondemand.com网站管理员的权限。攻击的图片因为有被攻击网站的ip,所以我进行了一些处理,但是攻击的确已经完成了。大概只需要四分钟左右,通过火狐插件Cookie Manager进行cookie修改,你就可以得到SAP云服务的管理权限。

我将这个漏洞报告给了SAP,他们立即将这个漏洞进行了修补。但是/admin/health这一目录还处于开启的状态(你可以通过搜索然后进行测试),不过不会造成任何危害。health目录会返回一个表示服务器状态的Json。这也许是为了方便写程序批量检测服务器状态。当然其它的目录都可以进行适当的防护措施,进而继续使用。

个人认为,SAP很赞,尽管他们的工作量巨大,但是他们在很短的时间对漏洞进行了修复。而且我认为如果SAP参与了漏洞奖励计划,他们程序的安全性会得到很大的改进。

还有很重要的一点,请阅读下方的漏洞挖掘指南:
https://wiki.scn.sap.com/wiki/display/Security/Disclosure+Guidelines+for+SAP+Security+Advisories

这一漏洞已经由SAP全部进行了修复。下面附上攻击成功的截图:

利用SAP 0day,四分钟内黑掉华尔街

这张图片展示了访问/admin/trace所获得的信息,以及cookie是如何找到的。客户相关的信息已经经过了打码处理。

利用SAP 0day,四分钟内黑掉华尔街

上图是管理员界面

利用SAP 0day,四分钟内黑掉华尔街

上图是实际的账户内容。




原文发布时间为:2017年5月22日
本文作者:xnianq
本文来自云栖社区合作伙伴嘶吼,了解相关信息可以关注嘶吼网站。
目录
相关文章
|
新零售 监控 安全
利用SAP 0day,四分钟内黑掉华尔街
本文讲的是利用SAP 0day,四分钟内黑掉华尔街,2017年5月20日,由唯品会信息安全部主办,唯品会安全应急响应中心承办的“因唯安全,所以信赖——深度揭秘唯品会信息安全建设实践 2017唯品会第二届电商安全峰会”在苏州成功举办。
2055 0
SAP MM/FI_运费处理方式
常见的采购运费处理方式
SAP MM 途损处理方式
通常客户采购业务需求提到货物运输有损耗,需要针对此业务给出合理方案输出,下面笔者针对此类业务分析下各种实现方案的可行性!
SAP MM初阶之事务代码MIGO界面批次拆分最多输入15行?
SAP MM初阶之事务代码MIGO界面批次拆分最多输入15行?
SAP MM初阶之事务代码MIGO界面批次拆分最多输入15行?
SAP MM不常用移动类型之325
SAP MM不常用移动类型之325
SAP MM不常用移动类型之325
SAP MM初阶之采购信息记录里的Prior Supplier栏位
SAP MM初阶之采购信息记录里的Prior Supplier栏位
SAP MM初阶之采购信息记录里的Prior Supplier栏位
SAP MM初阶之ME12里为啥只能维护少量条件类型的价格?
SAP MM初阶之ME12里为啥只能维护少量条件类型的价格?
SAP MM初阶之ME12里为啥只能维护少量条件类型的价格?
SAP MM 采购信息记录里的Automatic Sourcing 之二
SAP MM 采购信息记录里的Automatic Sourcing 之二
SAP MM 采购信息记录里的Automatic Sourcing 之二
SAP MM初阶之没有定义Access Sequence的条件类型不能使用MEK1维护条件记录
SAP MM初阶之没有定义Access Sequence的条件类型不能使用MEK1维护条件记录
SAP MM初阶之没有定义Access Sequence的条件类型不能使用MEK1维护条件记录