嗨，大家好！这是我最近发现的一系列安全缝隙傍边的一个，该缝隙与印度最挣钱的电子商务公司的一个数据库有关。下面让我们回忆下这个完好的故事。
注：这是在有关公司的授权答应下完结的！任何未经授权的行为，都归于违法行为！
这应该是一次有针对性的浸透，自己专心于LFI（本地文件包括）缝隙查找，所以我很热心与文件交互相关的功用和端点。一个常见的用于下载App的“Android Google Play”和“iPhone App store”选项功用引起了我的留意。

当我点击它时，它将我重定向到了另一个页面，其链接地址如下 -

接着又当即重定向到之前引证的页面，当我在隐身窗口中翻开它检查没有引证页面时的呼应是什么时，它被重定向到了一个404页面，因而很明显它正在寻觅某些条件和参数，然后进行简略的if/else逻辑判别。为了检查是否有任何缺失的参数，我偶尔发现了页面的以下HTML代码 -

逻辑十分明晰，正如你在赤色框中看到的，有一个php文件“download_handler.php”在URL中短少，需求参数“path”作为finaldownloadlink以及“name”的URL称号，这便是没有下载任何内容的原因。所以终究的URL应该是 -
downloadcallback/download_handler.php?path=
我测验了目录遍历进犯（../../../../etc/passwd），十分走运文件简直都给了更大权限（一个常见过错：/），我可以读取/etc/passwd文件以及各种其它文件中的内容 -


我可以读取各种Linux体系文件，装备，拜访日志，并获取get参数中的用户拜访令牌以及其它更为灵敏的信息。导致这个缝隙的元凶巨恶是“download_handler.php” -

PHP文件仅仅将该文件作为输入并将其读取回客户端。很简单可以看出它应该也十分简单遭到SSRF的进犯 -

测验运用不同的URL schemas（file:/// , dict:// , ftp:// and gopher://）读取 /etc/password，你也可以运用file:/// scheme履行相同操作 -

早些时分，当我经过LFI进犯抓取灵敏文件时，我可巧读取了/etc/motd文件，该文件标明该应用程序是经过AWS ElasticBeanstalk布置的。

这也让我决议持续经过SSRF搜索AWS实例元数据和用户数据 -


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

当我读取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 key，ID，token，在此之前我也获得了他们的帐户ID，这标明比较之前缝隙变得愈加严峻了 -

现在是时分对AWS账户进行身份验证了。为了保证凭据没有过期，我装备了aws-cli企图列出并将S3 bucket数据下载到我的本地机器上 -

[1] [2]  黑客接单网