From CRLF Injection to XSS: Elevating the Stakes in Apple iTunes Security
Description
بسم الله الرحمن الرحيم
Approximately eighteen months ago, I discovered a significant vulnerability within Apple iTunes, starting with a Carriage Return Line Feed (CRLF) issue. Through persistent effort, this initial finding was escalated to reveal a Cross-Site Scripting (XSS) vulnerability, showcasing the potential for extensive exploitation. Additionally, in the latter stages of investigation, a colleague contributed by identifying a Cross-Origin Resource Sharing (CORS) exploit within the same endpoint where the CRLF was found, further emphasizing the critical nature of the security flaw we uncovered.
Discover Stage
On a Friday, similar to today, I discovered a vulnerability while running my bash script to aggregate subdomains and Wayback Machine URLs for each, subsequently analyzing them with tools like Dalfox and Nuclei. Despite initially finding nothing, my focus shifted to the main Apple domain (apple.com). While monitoring traffic through the Burp Suite proxy, I stumbled upon a subdomain utilized as an API by the main domain for fetching iTunes offer data. This discovery was prompted by examining the source code of the main domain, where I noticed this subdomain accepted certain parameters.
Exploitation
I identified a subdomain within the iTunes.apple.com domain, referenced in the main website’s source code. This subdomain, which took specific parameters, was my focus. Using Burp Suite’s repeater tool, I began testing for vulnerabilities like XSS and LFI through fuzzing. A breakthrough was achieved when injecting %0d%0aSet-Cookie:%20attacker=exploit led to the successful reflection of the attacker=exploit cookie in the response page, indicating a potential security exploit.
Despite discovering a CRLF vulnerability, I encountered a challenge as the response was in JSON content-type, a scenario I’ve faced before where the reflection in JSON rendered the exploit less impactful. However, after some research and experimentation, I found that manually adjusting the content-type in the request successfully bypassed this limitation, marking a significant breakthrough in my exploration. This adjustment allowed the exploit to be reflected outside the JSON response, enhancing its potential impact.
Ultimately, after successfully manipulating the content-type, I managed to intercept and reflect cookies back to myself. Furthermore, with the CORS vulnerability that my colleague Zyead identified on the same endpoint, we were able to capture cookies via a third-party domain, demonstrating a significant security flaw that could potentially be exploited by unauthorized entities to gain access to sensitive information.
As we conclude this brief exploration, I hope you’ve found the insights shared both enlightening and useful. Should you have any questions or wish to engage further on this topic, don’t hesitate to reach out to me on Twitter. Your feedback and inquiries are always welcome!
