Any company can be the target of a hack, every company has vulnerabilities. Even one as big as Apple.
In 2020, vulnerabilities were discovered in Apple’s infrastructure. There was a huge amount of hype in the bug bounty community about finding these vulnerabilities. For both the reputation of finding them but also for the bounty itself. A team of bug bounty hunters, ethical hackers seeking to find vulnerabilities before they could be exploited, were hard at work for three months. Once found, each and every vulnerability was sealed by the team at Apple.
At Cyrex, we were keen to see what we could find. But we wanted to test ourselves in a short timeframe. Two of our security engineers, using a pair hacking approach, gave it a try. Here’s what they found in only four hours.
Cross-Site Scripting
The first vulnerability found was in Apple Pages, Numbers, and on iCloud. This vulnerability presented across each application but was sourced through the same issue.
A vulnerable parameter in the URL that is reflected on the webpage for the end-user. Essentially, this would allow a malicious actor to inject malicious code which would be executed on the user’s browser.
It would be the legitimate iCloud page with the exception that the script would be executed, allowing the hacker to steal the user’s data, redirect them to a phishing page, or even modify contents on the page. This final action could present the user with harmless-looking elements like a login or something similar. But of course, once the data is entered here it goes to the hacker – not Apple. This would have been too perfect for a malicious actor impersonating an Apple Tech Operator.
Authentication Flaw – One Time Password
A One Time Password or OTP is something most users would be familiar with. It is, as the name suggests, a once-off password that is usually generated to authenticate a user. An OTP is typically deployed for use and is immediately destroyed upon use – hence its name.
The impact of a flaw regarding an OTP is critical, though difficult to find. In this case, our security engineers discovered that the OTP in the system was only destroyed once it reached a time limit. Thus, it could be reused with this timeframe.
Pair hacking allowed this to be checked easily, with one hacker simply providing their unique OTP to the other. Should a hacker get access to this OTP, they would be able to login to any profile that they had credentials to (other than 2-Factor-Authentication).
Open Redirect Vulnerability
An open redirect vulnerability is essentially saying that a skilled hacker could redirect a user from a trusted domain to any domain they pleased.
Sending a legitimate Apple link, it would contain a return URL. Typically, this would redirect you back to the trusted domain.
Instead, a malicious actor could automatically redirect you to a similar website for easy phishing. Unless the user was specifically looking out for an unusual change in the domain, they could be caught out and have their information stolen. In a normal situation, the redirect functionality would have the Apple sub-domains as the only allowed redirect, and all others returning an invalid error.
Business Logic Flaw – Application ID
While creating an application for the Apple store, you are given a unique application ID. It distinguishes your app from another. Our security engineers found that using a developer profile, they could manipulate these IDs. In doing so, they could create a new app and replace its ID with an existing one. This would overwrite the current, existing application, and replace it with this new, likely fraudulent one.
This permission shouldn’t exist at all, but it was a vulnerability the pair found. In addition, they discovered that they could assign an Apple domain to their new application to further its legitimate appearance.
Business Logic Flaw – Upload/Download functionality
iCloud has an upload and download functionality. While uploading, you can only use allowed extensions – your typical word files or pictures/videos. You can’t upload any scripting extension.
However, in the download functionality – you could specify the extension. You uploaded a word document but in the download link – you could say it was an HTML file. You were free to determine the type, regardless of its original type. Typically, this would result in a gibberish file. But if you inject code into a word document, once downloaded as an HTML – the code will then be readable and effectively activate.
In this way, once visiting the download link, a hacker could gain full control of the user’s browser. And any vulnerabilities found from there could be exploited.
Even Apple, with its scale, is subject to vulnerabilities. If professional, ethical hackers can find these bugs in a short time – imagine how vulnerable a company without a security budget could be. Thanks to our pair hacking and expert penetration testing, we were able to collaborate and cross-validate our findings. We were able to clear the same amount of work, in half the time.
If you’d like to test your system against hacking, please contact us! We’ll deliver high-quality, pair hacking penetration testing to ensure only the best for your system. If you’d like to learn more about our security reports, you can find those here!