freeBuf
主站

分类

漏洞 工具 极客 Web安全 系统安全 网络安全 无线安全 设备/客户端安全 数据安全 安全管理 企业安全 工控安全

特色

头条 人物志 活动 视频 观点 招聘 报告 资讯 区块链安全 标准与合规 容器安全 公开课

官方公众号企业安全新浪微博

FreeBuf.COM网络安全行业门户,每日发布专业的安全资讯、技术剖析。

FreeBuf+小程序

FreeBuf+小程序

对印度某电子商务公司从LFI到数据库获取的渗透测试过程
2019-03-14 13:00:54

1_aaEYT_KIZoSgoLi9Qykt1g.jpeg本文分享的是作者在渗透测试过程中,通过不同漏洞的组合利用,最终拿下印度某大型电子商务公司数据库权限。(文章已经相关公司许可发布)

从LFI漏洞入手

本次渗透测试的目标比较确定,最初我偏向去发现其中的本地文件包含漏洞(LFI),所以我着重对其中的文件交互功能和特性进行了深入的测试分析,很巧的是,我发现了该公司一个针对不同移动设备显示 “Android Google play” 和 “iPhone App store” 的自身APP下载页面,如下:

01.png当我点击页面中 “Android Google play” 和 “iPhone App store”任意一个按钮,之后就会跳到如下的页面:http://www.xxxx.com/downloadcallback/null

02.png接着,就会马上重定向到相应的APP下载引用页面(Referrer Page)。当我在浏览器隐身模式下把引用页面去掉,想看看有什么反应时,请求服务端后返回了一个“404 Page not found” 的响应,很明显,它查询了某些条件或请求参数,可能遵循了某种简单的if/else逻辑。为了详细查看是否有其它参数遗漏,我看到了页面中的以下HTML源码:

03.png以上代码中的逻辑已经很明显了,有意思的是,在红框标注内可以发现有一个名为“download_handler.php”的PHP文件,在点击首次跳转时出现的URL中 - http://www.xxxx.com/downloadcallback/null,这个PHP文件是不存在的,然而这个PHP文件请求的是一个“path”的路径参数,其路径URL如代码中描述的finaldownloadlink,其“name” 名称为nameURL。所以,去掉引用页面后,最终也就返回了“404 Page not found”没东西下载的响应了。如果按照上述HTML代码的规定,那么其final URL应该是这种样子的:

downloadcallback/download_handler.php?path=

于是,在该处我偶然地尝试了一下目录遍历攻击,path=../../../../etc/passwd,哇,竟然有读写权限,除了/etc/passwd,还能读取到其它服务端敏感文件:

04.png

05.png而且,我还可以读取到各种Linux系统文件、配置文件和访问日志信息,这样一来,还能深入获取到用户的access token、参数和其它更敏感的信息,这一切的罪魁祸首就是“download_handler.php”这个文件:

06.png

转化为SSRF攻击

可知,这个PHP文件只是简单地执行用户请求输入,然后把输入请求的响应返回,这种模式也很容易存在SSRF漏洞,比如:

07.png这里,读取/etc/password的方式,还能用file:/// 方式(打开对应的本地系统文件):

08.png

发现AWS ElasticBeanstalk实例

另外,当我用这种LFI和SSRF方式测试时,在读取服务器端/etc/motd文件(系统布告信息栏)时,我发现这个Linux系统部署了AWS ElasticBeanstalk:

09.png这个线索让我有了深入渗透的决心,我们可以用上述SSRF方式来具体找找一些AWS实例,如MetaData或User Data:

10.png11.png利用上述SSRF方式,从“ http://169.254.169.254/latest/dynamic/instance-identity/document”的系统服务API中,还可获取到一些AWS账号ID和云服务区域信息,如下:

12.png在我检查系统的AWS Elastic Beanstalk部署环境时,还发现了一个API调用,用它可以获取到AWS Access Key、Secret Access Key和Token等重要的验证信息,这个API是:

http://169.254.169.254/latest/meta-data/iam/security-credentials/aws-elasticbeanstalk-ec2-role

直接用上述的SSRF方式,加上这个API调用,在响应信息中就能返回AWS Access Key、Secret Access Key和Token,结合之前发现的账户ID,现在的情况是越来越严重了:

13.png接下来,我们可以来验证一下这些AWS账户了,只要密码不过期,就可以在aws-cli命令行界面中来进行操作了,如下:

14.png也可以列出相关信息或下载S3 bucket数据到本地系统中,如下:

15.png

获取数据库

当细细查看S3 bucket数据时,我发现了一些很敏感的文件,如database.js、config.js、app.js、payment.config,果不其然,这些文件中包含了支付相关的哈希键值、加盐值、数据库存密码凭据、内部使用工具名称和密码信息等等。而且,我还发现了一个正在运行的MongoDB实例,其密码就存在于明文的配置文件中,我连接上之后,在其中发现了一些客户数据,如下图所示:

16.png尽管它没有包含所有的用户详细信息,但这些信息涉及10000多名客户。之后,我向该公司上报了该漏洞,他们非常重视,给予了及时的漏洞修复,并轮换了所有受影响的密钥和凭据。最终,这次从LFI到SSRF,再到Elastic Beanstalk实例,最后再到S3 bucket数据库权限获取的操作,导致了上万名目标公司客户的敏感密钥凭据信息泄露。

*参考来源:medium,clouds编译,转载请注明来自FreeBuf.COM

# 渗透测试 # LFI漏洞
本文为 独立观点,未经允许不得转载,授权请联系FreeBuf客服小蜜蜂,微信:freebee2022
被以下专辑收录,发现更多精彩内容
+ 收入我的专辑
+ 加入我的收藏
相关推荐
  • 0 文章数
  • 0 关注者