Account Takeover via Access Token Leakage

Hello guys! My name is Tuhin Bose (@tuhin1729). I am currently working as a Chief Information Security Officer and Infosec trainer at DSPH. In this write-up, I am going to share one of my interesting findings. So without wasting time, let’s start:

大家好!我的名字是 Tuhin Bose (@tuhin1729)。我目前在卫生和公共卫生部担任首席信息安全官和信息安全培训师。在这篇文章中,我将分享我的一个有趣的发现。所以,不要浪费时间,让我们开始:

tuhin1729

Introduction:

Basically the target was a marketing automation website where you can automate your marketing stuffs efficiently. Let’s call it target.com. I have already found more than 10 bugs on the target and earned $$$$ from there.

基本上目标是一个营销自动化网站,在那里你可以有效地自动化你的营销工作。我们就叫它 target.com 吧。我已经在这个目标上发现了10多个 bug,并从中获得了 $$。

Now while testing the profile update feature, I came across with this interesting request:

现在当我在测试档案更新功能的时候,我遇到了这个有趣的请求:

PUT /api/account/general-info/ HTTP/1.1
Host: services.target.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0
Accept: application/json, text/plain, */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://bo.target.com/
Content-Type: application/json
accessToken: 795b74eXXXXXXXXXXcba9abd3beaa3ec40b5d3ed
Content-Length: 213
Origin: https://bo.target.com
DNT: 1
Connection: close
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: cross-site{"company":"DSPH","domain":"https://darksocietypenetration.com","cellphone":"+91-83xxxxxx36","companySize":"2","businessSector":20,"logo":{"height":0,"base64":"","square":true,"width":0}}

They are using accessToken header for changing the profile details (For other authenticated actions, there is no such header). I quickly changed the value of accessToken header with my 2nd account and my 2nd account’s details were changed. I tried to add the accessToken header in other authenticated requests and it got successful and 2nd account’s details were changed. While doing more research on this, I have discovered that the value of accessToken is static i.e. accessToken is same even after logout. That means, if somehow I can get the accessToken of victim, I would be able to takeover his complete account. But the value of accessToken header is non-guessable so I thought to find a way to get victim’s accessToken. But at that time, I was unable to do so. After 3 – 4 days of hunting, I forgot about that and started hunting on other functionalities.

他们使用 accessToken 头更改配置文件详细信息(对于其他经过身份验证的操作,没有这样的头)。我很快用我的第二个账户更改了 accessToken 头部的值,我的第二个账户的详细信息也被更改了。我尝试在其他认证请求中添加 accessToken 标头,成功了,第二帐户的详细信息被修改了。在对此做了更多的研究之后,我发现 accessToken 的价值是静态的,也就是说 accessToken 即使在注销后也是一样的。这意味着,如果我能以某种方式获得受害者的辅助戒指,我就能够接管他的全部账户。但 accessToken 头部的值是不可猜测的,所以我想找到一个获取 accessToken 的方法。但当时,我无法这样做。经过3-4天的搜索,我忘记了这一点,开始搜索其他功能。

Getting Victim’s accessToken

获得受害者的接触权

In the website, under email marketing, there is a section where we can make our own email templates. While testing that feature, I tried to upload an image file in the email. There are 2 ways to do so either from my device or via an image url. I tried some DoS, SSRF, XSS and file upload tricks. But it seems that they have a strong file type validation. Also they are fetching the image from client side so SSRF is not possible. Now when I tried to use my burp collaborator’s link to see the request, I noticed an interesting thing:

在网站的电子邮件营销下,有一个部分,我们可以制作自己的电子邮件模板。在测试这个功能的时候,我尝试在邮件中上传一个图片文件。有两种方法可以做到这一点,或者通过我的设备或通过一个图像的网址。我尝试了一些 DoS,SSRF,XSS 和文件上传技巧。但是他们似乎有一个强大的文件类型验证。而且他们正在从客户端获取图像,所以 SSRF 是不可能的。现在,当我试图使用我的 burp 合作者的链接查看请求时,我注意到一件有趣的事情:

tuhin1729

Then accessToken is getting leaked in the Referrer header via the token parameter.

然后 accessToken 通过令牌参数在 referer 头中获得泄漏。

So what would be the attacking scenario?

那么攻击方案是什么呢?

Attacking Scenario

攻击方案

  1. Victim is creating a manual template.
  2. 受害者正在创建一个手动模板。
  3. Victim adds an image to his template from 3rd party website.
  4. 受害者从第三方网站的模板中添加了一张图片。
  5. The 3rd party website owner (or employees) gets victim’s access token (from their logs) and can able to takeover their complete account.
  6. 第三方网站所有者(或员工)获得受害者的访问令牌(从他们的日志) ,并能够接管他们的完整帐户。

Response

回应

I quickly made a POC and send it to them. After one week, they replied me:

我很快做了一个 POC 发给他们,一周后,他们回复我:

tuhin1729

Timeline

时间轴

06/05/21 — Reported Vulnerability

06/05/21ー报告的脆弱性

14/05/21 — Replied with the bounty email

14/05/21ー用电子邮件回复

Follow me on Twitter: @tuhin1729_

关注我的推特:@tuhin1729

Thanks for reading. I hope you enjoyed this blog.

谢谢阅读。我希望你喜欢这个博客。

RCE on Starbucks Singapore and more for $5600 

星巴克新加坡的 RCE,5600美元

Recon

侦察

After I found a critical vulnerability in Starbucks Singapore web application, I wanted to dig a little deeper and began to examine the com.starbucks.singapore Android app. Unfortunately, I did not find any weaknesses in the mobile application and I decided to focus on the application server on which the application interacts. The mobile application was interacting mostly to a REST API on the server, but I noticed that in some operations it is talking to an endpoint with the extension “.aspx”. I did not find any weaknesses in the endpoints…

当我发现星巴克新加坡网络应用程序的一个关键漏洞后,我想深入挖掘并开始研究 com.Starbucks.Singapore Android 应用程序。不幸的是,我没有发现移动应用程序中的任何弱点,所以我决定把重点放在应用程序交互的应用服务器上。移动应用程序主要与服务器上的 REST API 进行交互,但我注意到在某些操作中,它与带有扩展的端点进行对话。“ aspx”。我没有在终点发现任何弱点..。

Recon Harder

侦查难度

After a few weeks of break, I decided to research IIS vulnerabilities, as I know that the application server is running on IIS. While researching, I came across the Hacking IIS video of shubs. I thank him for reminding me the IIS Tilde Enumeration Scanner by Soroush Dalili in this video, which I knew before but didn’t come to mind during my exploration. I started exploring more endpoints using this tool that automates the vulnerability and caught my attention some “.ashx” endpoints in the “/api” directory.

经过几个星期的休息,我决定研究 IIS 漏洞,因为我知道应用服务器是在 IIS 上运行的。在研究的过程中,我偶然看到了黑客的 IIS 视频。我感谢他在这个视频中提醒我索鲁什 · 达利设计的 IIS Tilde 枚举扫描仪,这个我以前就知道,但在我的探索过程中却没有想到。我开始使用这个工具来探索更多的端点,这个工具可以自动化漏洞并引起我的注意。“/api”目录中的“ ashx”端点。

DOWNLO~1.ASH
EMAIL-~1.ASH
IMAGEU~1.ASH
MAILIN~1.ASH

The IIS Tilde Enumeration Scanner tool exploits a vulnerability, which Microsoft describes as a feature, discovers the first 6 characters of a file’s name and the first 3 characters of its extension. Based on this information, I tried to find all the file names and quickly found some of them.

IIS Tilde Enumeration Scanner 工具利用了一个漏洞,微软将其描述为一个特性,发现文件名的前6个字符和扩展名的前3个字符。根据这些信息,我试图找到所有的文件名,并很快找到了其中的一些。

download.ashx
email-bounce.ashx

Unfortunately I couldn’t use these endpoints for any purpose and focused on the IMAGEU ~ 1.ASH endpoint. What did the letter U mean, I wonder if it could be upload? I started scanning with the ffuf tool in the form of “imageuploadFUZZ.ashx” and discovered that this endpoint is imageuploadhandler.ashx. Looking at the name of the endpoint, it is understood that it is used to upload image files. But there are a few problems here. Is this endpoint accessible to unauthorized users? What is the accepted format of this endpoint while sending a request? Can I upload any files other than image files? If I can upload a file, what is the full path to acces it? Will I be able to run the file?

不幸的是,我无法将这些端点用于任何目的,只能将重点放在 IMAGEU ~ 1上。灰渣终点。那个字母 u 是什么意思,我想知道它是否可以上传?我开始用 ffuf 工具以“ imageuploadFUZZ.ashx”的形式进行扫描,发现这个端点是 imageuploadhandler.ashx。查看端点的名称,可以理解该端点用于上传图像文件。但是这里有一些问题。未经授权的用户是否可以访问该端点?发送请求时该端点可接受的格式是什么?我可以上载图像文件以外的其他文件吗?如果我可以上传一个文件,完整路径是什么?我能运行这个文件吗?

Exploitation

剥削

To find the answers to these questions, I sent random GET/POST requests to this endpoint, but the only response I got was 200 OK nothing more. I did not get any error codes or error/success messages. I wasn’t sure if this endpoint was working. At this point let’s think from the perspective of a developer, you have an endpoint that you use to upload files, how do you send requests to this endpoint from the frontend? Either from within an HTML form or via javascript with an XMLHttpRequest. I started exploring javascript files and found a file named ajaxfileupload.js.

为了找到这些问题的答案,我向这个端点随机发送了 GET/POST 请求,但得到的唯一回复是200 OK,没有其他的了。我没有得到任何错误代码或错误/成功消息。我不确定这个终点是否起作用。现在,让我们从开发人员的角度考虑一下,您有一个用于上传文件的端点,如何从前端向这个端点发送请求?无论是通过 HTML 表单还是通过 XMLHttpRequest 的 javascript。我开始研究 javascript 文件,发现了一个名为 ajaxfileupload.js 的文件。

As you can see here, the file to be uploaded is sent as “multipart/form-data”. With some extra research, I found proper upload request format.

正如您在这里看到的,要上传的文件是作为“ multipart/form-data”发送的。通过一些额外的研究,我发现了正确的上传请求格式。

At this point, I tried to upload a file with “.aspx” extension containing only text and it was successfully uploaded. Endpoint was converting the filename to UUID format, which would also return the uuid+extension in response. The uploaded file could be found in the “/api” directory.

在这一点上,我试图上传一个文件与“。“ aspx”扩展只包含文本,并成功上传。Endpoint 将文件名转换为 UUID 格式,该格式也将返回 UUID + 扩展作为响应。上传的文件可以在“/api”目录中找到。

I immediately reported the vulnerability to Starbucks via Hackerone and asked permission to try remote code execution. After getting permission from triager, I uploaded a simple script and ran the “whoami” command and added the output to the report.

我立即通过 Hackerone 向星巴克报告了这个漏洞,并请求允许尝试远程代码执行。在获得 triager 的许可之后,我上传了一个简单的脚本并运行“ whoami”命令,并将输出添加到报告中。

Impact

影响

Did you notice something interesting? whoami command returns iis apppool\cards.starbucks.com.hk, HK is for Hong Kong but we are in Singapore domain. So it was an indicator that I should also check if Hong Kong zone is using same application.

你注意到什么有趣的事情了吗?Whoami 命令返回/apppool cards.starbucks.com。HK,HK 代表香港,但我们是在新加坡的领域。因此,这是一个指标,我也应该检查香港区是否使用相同的应用程序。

My concerns turned out to be true, Starbucks Hong Kong application server has the same endpoint and the same vulnerability. Then I tried to find other zones using the same application, and I found out that the Starbucks mobile application servers belonging to

我的担心被证明是正确的,星巴克香港应用服务器有相同的端点和相同的漏洞。然后我试图找到其他区域使用同一应用程序,我发现星巴克移动应用服务器属于

  • Singapore 新加坡
  • Hong Kong 香港
  • Vietnam 越南
  • Thailand 泰国
  • Malaysia 马来西亚
  • Cambodia 柬埔寨

in total had the same vulnerability and I added them to the report but vulnerabilities belonging to other zones were not rewarded, as only Singapore applications were within the scope.

总体上也有同样的脆弱性,我将它们添加到报告中,但属于其他地区的脆弱性没有得到奖励,因为只有新加坡的应用程序在范围之内。

A malicious person could use this vulnerability to seize the entire server, databases, user information, application source code. He/She could make apps inaccessible or manipulate them however he/she wanted. Considering that the payment systems of mobile applications in Starbucks stores are also located on these servers, much more critical damages could be incurred.

恶意用户可以利用这个漏洞获取整个服务器、数据库、用户信息、应用程序源代码。他/她可以让应用程序无法访问,或者随心所欲地操纵它们。考虑到星巴克的移动应用支付系统也位于这些服务器上,更严重的损害可能会发生。

How I got 9000 USD by hacking into iCloud

我是怎么通过入侵 iCloud 赚到9000美元的

You may be wondering what the hell this image means… This is a summary photo of a possible attack vector that I found on iCloud, but either way, don’t pay attention to my poor image handling skills, in the end, you will have a clear view of this image.

Introduction

引言

In this post, I’m going to share a vulnerability that I found in ICloud that could allow an attacker to execute malicious code in another iCloud account. We will see how the attack could be exploited and what an attacker could do in the victims’ accounts.

Apple and the iCloud

苹果和 iCloud

In December 2020, I came across an amazing tweet of a group of researchers who hacked Apple for 3 Months. In the blog post shared in the tweet, 55 vulnerabilities in the Apple domain are explained. I spent long hours reading the great content, and then I decided to try to hack Apple as well.

2020年12月,我偶然看到一组研究人员在 twitter 上发了一条令人惊讶的推文,他们黑了苹果公司3个月。在推文中分享的博客文章中,苹果域名的55个漏洞得到了解释。我花了很长时间阅读这些伟大的内容,然后我决定尝试黑掉苹果。

My strategy was to focus on a single target: iCloud. I have limited time during the week and I decided to explore iCloud in order to understand the functionalities, the interactions among the subdomains and identify some possible approaches to use.

我的策略是专注于一个目标: iCloud。我在这一周的时间有限,我决定探索 iCloud,以便了解其功能,子域之间的互动,并确定一些可能的使用方法。

The XSS Vulnerability

漏洞

The vulnerability exploited is a Cross-site Scripting in the process of creating a File or a Folder in iCloud Drive.

被利用的漏洞是一个在 iCloud 驱动器中创建文件或文件夹的跨网站脚本。

A Cross-site scripting (a.k.a XSS), briefly speaking, is a type of security vulnerability that allows an attacker to execute malicious code on the victims’ browser. There are different ways to do it, in this blog post from BugCrowd you can find a great explanation about this type of attack.

简而言之,跨网站脚本安全漏洞是一种允许攻击者在受害者的浏览器上执行恶意代码的安全漏洞。有不同的方法来做到这一点,在这篇博客帖子从 BugCrowd 你可以找到一个伟大的解释这种类型的攻击。

System Context

系统环境

In iCloud Drive, we are able to upload our files and organize them in folders.

在 iCloud Drive 中,我们可以上传文件并将它们组织到文件夹中。

Those Folders and files can be shared with other iCloud users using their emails, or we can simply turn the file/folder public and share its link to any iCloud user interested to have access to it.

这些文件夹和文件可以通过电子邮件与其他 iCloud 用户共享,或者我们可以简单地将文件/文件夹转为 public,并将其链接分享给任何有兴趣访问它的 iCloud 用户。

Here, the sharing functionality is important in the context of the attack, as it allows the attacker to share the XSS with the victim in that way.

在这里,共享功能在攻击上下文中非常重要,因为它允许攻击者以这种方式与受害者共享 XSS。

The XSS…

的 XSS..。

Each folder or file has an Icon where we can see the details and edit name

每个文件夹或文件都有一个图标,我们可以在其中查看详细信息并编辑名称

When the tiny window is opened, along with other information, an HTML span tag is injected into the DOM.

当打开这个小窗口时,连同其他信息,一个 HTML span 标记被注入到 DOM 中。

And due to a server misconfiguration, an attacker would be able to include HTML tags on the directory name and it would be loaded into the DOM.

由于服务器的错误配置,攻击者可以在目录名上包含 HTML 标记,并将其加载到 DOM 中。

Having the ability to insert new elements in the DOM, the attacker would be able to execute javascript on the page:

有了在 DOM 中插入新元素的能力,攻击者就可以在页面上执行 javascript:

The POC

原产地证书

In iCloud Drive, they have a strict CSP which at that time was not allowing me to use script tags or request a domain out of *.icloud.com and *.apple.com but I was able to use event handlers to execute the javascript from the XSS.

在 iCloud Drive 中,他们有一个严格的 CSP,当时不允许我使用脚本标记或请求来自 * . iCloud. com 和 * . apple. com 的域名,但我可以使用事件处理程序来执行 XSS 中的 javascript。

In the beginning, I spent some time thinking about what the XSS could do, I had found the XSS and the way to share it. I decided to stop from here and share it immediately with Apple before someone else would do.

一开始,我花了一些时间思考 XSS 可以做什么,我已经找到了 XSS 和共享它的方法。我决定在其他人做之前停下来,立即与苹果分享它。

Some days later, I sent another report to Apple to be appended to the ticket.

几天后,我又给苹果公司发了一份报告,附在罚单后面。

In the final POC, the Attacker shares a folder with the victim where the folder name was:

在最后的 POC 中,攻击者与受害者共享一个文件夹,其中的文件夹名称是:

PLEASE EDIT DIR NAME <img src onerror=”(function hacking(){//BAD JS STUFF}())”/>

请编辑目录名称 < img src onerror =”(函数 hacking (){//BAD JS STUFF }())”/>

Inside the Javascript function, I added a code that performed some requests to the iCloud APIs, to retrieve all the files/folder ids and move them to the folder shared by the Attacker, allowing the attacker to get access to all the victim’s files.

在 Javascript 函数中,我添加了一个代码,可以执行一些对 iCloud api 的请求,检索所有文件/文件夹 id,并将它们移动到攻击者共享的文件夹,让攻击者可以访问所有受害者的文件。

In the end, the victim will have all of their files automatically moved to the folder by the XSS and that is the explanation for the image from the beginning of this post.

最后,受害者会通过 XSS 将他们所有的文件自动转移到文件夹中,这就是本文开头对图片的解释。

Points to be considered

需要考虑的要点

In this scenario, the XSS would be fully exploited by the attacker only if the victim accepts the shared folder and decides to open the tiny window. If the tiny window is not opened the XSS would not be executed.

在这种情况下,只有当受害者接受共享文件夹并决定打开小窗口时,XSS 才会被攻击者充分利用。如果小窗口没有打开,XSS 将不会被执行。

Apart from that, when the attacker shares the malicious folder, the victim can edit the name and remove the XSS, but when it is done, the change occurs only on the victim’s side. Based on that, the attacker would be able to share the same malicious folder with many victims and get access to the files from all the victims that opened the tiny window.

除此之外,当攻击者共享恶意文件夹时,受害者可以编辑名称并删除 XSS,但是当这样做时,更改只发生在受害者一侧。基于这一点,攻击者将能够与许多受害者共享同一个恶意文件夹,并且能够访问所有打开这个小窗口的受害者的文件。

Last but not least, as soon as the attacker is able to see the victims file inside the shared folder, the attacker would be able to stop sharing the Folder, stealing all the files from the victims

最后但并非最不重要的是,一旦攻击者能够看到共享文件夹中的受害者文件,攻击者就能够停止共享该文件夹,从受害者那里窃取所有文件

In the end, the XSS will move all the files/folders from the victim into the shared folder, and the attacker could remove the access to the victim by performing a data-stealing approach.

最后,XSS 将受害者的所有文件/文件夹移动到共享文件夹中,攻击者可以通过执行数据窃取方法来移除对受害者的访问。