嗨,大家好,
这是另一个关于我最近发现的一系列安全漏洞的安全漏洞撰写,这些安全漏洞与印度最赚钱的电子商务公司的数据库之一相关联。让我们看看完整的故事 -

(这是在有关公司的明确许可下完成的)

他应该是一个针对性的攻击,我是专门在寻找一个LFI漏洞(本地文件包含)集中,所以我是在寻找和探索其被相关的一些互动与文件,然后我碰到一个前来的功能和终端更敏锐通常的功能,应用程序为您提供“Android Google Play”和“iPhone App store”选项,以下载他们的应用程序。

他应该是一个针对性的攻击,我是专门在寻找一个LFI漏洞(本地文件包含)集中,所以我是在寻找和探索其被相关的一些互动与文件,然后我碰到一个前来的功能和终端更敏锐通常的功能,应用程序为您提供“Android Google Play”和“iPhone App store”选项,以下载他们的应用程序。

预期的逻辑非常明确,我注意到有趣的事情(正如你在红色框中看到的),有一个php文件“download_handler.php”在URL中缺少,需要参数“path”作为finaldownloadlink和“name”的URL名称,这就是没有下载任何内容的原因。让我们按照上面的代码,所以最终的URL出来了 -

downloadcallback/download_handler.php?path=

我只是尝试了目录遍历攻击(../../../../etc/passwd),幸运的是,文件获得了最大权限(一个常见错误:/)我能够阅读/ etc / passwd内容和各种其他的文件 -


/ etc / passwd文件


通过LFI读取其他敏感文件

我能够读取各种Linux系统文件,配置,访问日志,让我获得用户访问令牌获取参数和更敏感的信息。这个完整漏洞的罪魁祸首是“download_handler.php” -


download_handler.php

php文件只是将文件作为输入并将其读回客户端。很容易看到它也容易受到SSRF的攻击 -

尝试使用不同的URL模式(file:///,dict://,ftp://和gopher://)读取/ etc /密码,并且能够使用file:/// scheme执行相同操作 -


SSRF导致访问/ etc / passwd

早些时候,当我通过LFI攻击抓取敏感文件时,我碰巧读了/ etc / motd文件,该文件表明该应用程序是通过AWS ElasticBeanstalk部署的。


正在使用ElasticBeanstalk

此消息足以让我决定继续通过SSRF搜索AWS Instance元数据和用户数据 -


AWS实例用户数据


AWS Instance MetaData

我还能够从以下API“http://169.254.169.254/latest/dynamic/instance-identity/document” 中检索AWS账户ID和Region -


AWS元数据 - 检索帐户ID和区域

当我阅读AWS Elastic Beanstalk时,我遇到了一个API调用,它可以获取AWS Access Key,Secret Access Key和Token。
http://169.254.169.254/latest/meta-data/iam/security-credentials/aws-elasticbeanstalk-ec2-role

我很快通过SSRF发出攻击,我能够获取他们的AWS Access密钥,ID,令牌,之前我也获得了他们的帐户ID,这就是漏洞变得更加严重的时刻 -


AWS账户访问ID和访问密钥

现在是时候对AWS账户进行身份验证了。为了确保凭证没有过期,我配置了aws-cli并尝试列出并将S3存储桶数据下载到我的本地机器上,我能够这样做 -

配置AWS命令行界面

将s3存储桶内容复制到本地计算机 -


递归复制所有S3 Bucket内容

在查看每个单独的S3存储桶时,我在一些存储桶中发现了一些关键文件,有像database.js,config.js,app.js,payment.config文件这样的文件很快吸引了我的注意力,正如我所料,他们发现包含支付哈希密钥和盐(可能用于篡改订单的付款),几个数据库凭据,一些内部工具用户名和密码等信息。还有一个MongoDB实例正在运行,其凭据也被发现在配置文件的纯文本中,当我尝试连接到它时,我发现他们的客户数据存储在其中 -

虽然它没有包含所有用户的详细信息,但它的数量超过了10K。我在此之后不久就报告了这个漏洞,他们很快就修补了它,并且还轮换了所有受影响的凭据和密钥。所以从LFI开始,我到达了SSRF,从那里我开始知道应用程序是通过Elastic Beanstalk部署的,从那里我能够获取一个AWS账户凭据,这有助于我获得他们的数据库凭证之一躺在一个S3桶中,我有完整的读/写访问权限并连接到数据库,我发现成千上万的客户详细信息以及各种其他敏感的凭据/密钥和信息。

关于这个有趣的发现就是这样!
谢谢阅读!

原文地址 :https://medium.com/@logicbomb_1/chain-of-hacks-leading-to-database-compromise-b2bc2b883915

点击收藏 | 1 关注 | 1
  • 动动手指,沙发就是你的了!
登录 后跟帖