Resecurity is working on numerous penetration testing and red teaming exercises for major Fortune 500, the security used by web applications still remains one of the key components which often leaves the door wide open for attackers.
The exploitation of certain vulnerabilities by experienced bad actors may lead to fatal events which leads to a data breaches.
Such issues can be especially meaningful for online-services and e-commerce whom work with customers globally, this is also what creates a compliance risk.
Even big technology companies are affected by the insecurity of web applications and invest in timely identification of vulnerabilities to mitigate potential risks.
In this research post, Ahmad Halabi will share some of the recent vulnerability findings which have been timely reported to Apple Security for further patching. Similar issues have been identified on multiple projects providing online-shopping functions and e-commerce.
The Target
When you come across a big Asset like Apple or Microsoft, you have to know from where to start and what to check. For us, we were looking for a target that is considered an important asset to Apple and contains valuable private information so the bounty will be worthy.
For example: https://applepaysupplies.com/
Apple Pay Supplies: allows you to order Apple related Kits such as `Apple Pay Decals Kit` and `Apple Pay Signage Kit`.
Studying The Application Structure
We began with checking the target website as a normal user who wants to order a kit. By turning on Burp Suite, we were able to intercept all the traffic of this website and proceeded with an order by navigating to `Place Order`.
After that we filled the Shipping Information and submitted the order.
The shipping Information included: Full name, Company, Address information (Country, City, Street, Zip code) and Phone Number.
There's a track order feature so after submitting your order you're able to track it.
To track the order, we have to put our email address and the order number that gets assigned once the order is created.
We noticed here two interesting variables that required investigation, Order Number
and Email
.
Identifying The Vulnerability - Chaining IDOR With Rate Limit Discloses Shipping Information.
1st Step:
After hitting the Submit
button to track the Order Status, the page showed my Order details, we noticed this URL in the browser tab:
2nd Step:
Here we thought about an IDOR vulnerability chained with a Rate Limit mechanism to guess the order_id
of an Apple user, we already know the users email ID.
We start analyzing the order_id
value: APP1162306
by generating multiple Orders and comparing their order_id
values.
APP
characters are fixed.- We have 7 numbers after
APP
which can be brute forced.
3rd Step:
We then navigated to the target URL https://applepaysupplies.com/trackorder?order_id=APP1162306&email=my.test.email@gmail.com&language_id=1 but the surprising thing was how it displayed a blank page rather than the Order Details that were shown after hitting the Submit
button.
We were not able to perform the attack by hitting Submit
button nor were we able to intercept the request as the Application was using a front-end fetching mechanism via a JavaScript thus no backend request was related to the target URL. So, we needed to analyze the JavaScript Files / Burp History and check for an API to see how the data is being fetched and retrieved.
4th Step:
After some Recon and Analysis, we found an API that interacts with the backend, it fetches the Order Information.
Alternative Request: https://applepaysupplies.com/api/Home/GetOrderStatus?orderno=APP1162306&email=my.test.email@gmail.com
This API Request is responsible for Fetching the Order Status Details.
5th Step:
Now it was easy to proceed, we can now start generating 7 numbers wordlist to brute force the Order number in a numerical order to get the Valid Order Status Details.
Luckily there was no Rate Limit Protection in place so we could brute force the Order Number of any valid Apple User, we then disclose their Shipping Address Information.
Reporting
- We made a detailed PoC and Reported this Vulnerability to Apple.
- After a while, Apple Fixed the Vulnerability and Requested us to check the Fix.
Checking The Fix
Apple fixed the Vulnerability by removing the API call responsible for fetching the Order Status Details (/api/Home/GetOrderStatus). So now users can only use the main Functionality "Track Order".
Instead of the removed API endpoint, they used the Track Order request (https://applepaysupplies.com/trackorder?order_id=APP1162306&email=my.test.email@gmail.com) to fetch the status details.
However they enhanced the Track Order Functionality. They used CryptoJS Library to encrypt the values since now they are being sent and fetched from the Client Side.
Bypassing The Fix
1st Step:
We checked the website again. we already knew the main endpoint to track orders (https://applepaysupplies.com/trackorder) that accepts GET request with the following parameters: order_id
which stands for the Order Number and email
.
2nd Step:
We start by analyzing the Request.
Using Burp Suite, we tried sending a GET request to the target URL:
https://applepaysupplies.com/trackorder?order_id=APP1162306&email=my.test.email@gmail.com
This time the response was not showing the Order Status nor did it display the Shipping details of this valid order.
This was protection implemented by Apple when they Fixed the old bug. Now, we're unable to use Intruder to brute force the `Order Number` as before with the previous bug and the API Endpoint.
3rd Step:
Now we analyzed the Client Side Behavior.
We opened the request (https://applepaysupplies.com/trackorder?order_id=APP1162306&email=my.test.email@gmail.com) in the browser.
Once opened we noticed a delay while showing the order details. It took 1–2 seconds after loading to display the order details.
This behavior explains why we were not able to see the shipping details on the request level in Burp Suite.
4th Step:
Next, we started analyzing the JavaScript Files.
After checking JavaScript files, we could see how the application was using a Library called CryptoJS
to encrypt the Email
and the Order Number
while requesting an order status. By using this technique, Apple has made it difficult to brute force the Order Number.
We analyzed how the Encryption is implemented within the Application, and with the help of our Friend Max (h1 Profile), We wrote a script to encrypt the required values using the CryptoJS library as the Application did, we could then brute force the Order Number again.
With the advantage of the absence of Rate Limit protection against this GET endpoint, we could brute force the Order Number successfully and once again disclose the Shipping Information.
Reporting
- Apple requested us to send the Bypass Details in a New Report since the Old Fix is Successful and the Vulnerability is now found in a different Endpoint.
- Apple confirmed the Vulnerability.
- Apple Took some time to implement a new Fix.
Confirming The Fix
Apple kept the Crypto JS Library in place, They just enhanced and increased the Encryption Level to make it even harder to break.
Apple didn’t implement a Rate Limit Protection, but they Increased the Length of the Order Number.
Before, the Order Number was made up of: APP + 7 numbers.
Now, the Order Number is made up of: APP + 28 Characters & Numbers.
Example: `APPF68CAA9D1F174F91B61ECC7568D7`
Brute Forcing 28 Random Characters is unfeasible even if you were able to decrypt their Encryption.
We can now consider the vulnerability is fixed and Reported back to Them.