Hello Friends,

Welcome back, This time i would be talking about a Bug which i found in Apple’s acquisition Beats by Dr dre. It was  2015 and i was trying to fiddle with Apple related Web applications and found Beats by Dr. Dre website. In this article, i would like to emphasis on the CSRF (Cross Site Request Forgery) Vulnerability which i found on Beats main domain. Apple has knack for CSRF Protection against their web-apps. Till date only 8 CSRF (Including mine’s) were found on total Apple domains + acquisitions.

Apple as we all know doesn’t needs an introduction. This logo is enough !

In beats main website, the Work flow is typical like most of Web-site has, Singup -> Login -> Fill Information -> Browse -> Logout . When you first create a Beats account it normally asks you Details about you like First Name, Last name, Email, Password and after you Verify your email address, it allows you to go to User dashboard where User can further do browsing, Shopping and whatever they like. Additionally, the Beats has ‘Account settings’ where a user can edit his / her information like First Name, Last Name, Email, Subscription etc. and an another section which is Password change feature where users can enter the password and cross-verify it by typing again and Password gets changed. That said, it was evident that it has two separate submit forms

1. Details Edit
2. Password Change

Now, there is a bit mess up with the Work-Flow here, whenever a User submits the Form after editing his details in Edit details form, than they also include a Field called E-Mail Address . Moreover, after submitting this Edit details form, the site didn’t asked like Enter your Password to confirm the details entered or something like this as an additional check. But it’s all alright, that wasn’t a security issue but by the end of article you will know how can it prove lethal. So, coming back to this My first thought was either they were confident of their CSRF Validation or either they are doing some cryptic checks for Server-Side validate. I intercepted the requests using Burp-Suite after editing the Details of my account in the form and saw that it supplied an Anti-CSRF token in the $POST Requests body.

As expected ! The only good thing was there was no Double CSRF Validation and the Request was in $POST. But it was doing the session_id and Cookie check in the Header. So forget about IDOR. Now, i had few options but the main goal was to bypass the Anti-CSRF token. The most trivial attack vector which i tried was that i removed the Anti-CSRF Token Parameter from the request body and forwarded the request. But, as usual that trick didn’t worked here as the Anti-CSRF Token was getting validated on the server-side than i tried to fiddle by Changing Request types but nothing worked as expected, than finding weakness or to check what is exactly getting validated in the token was the only way. I made two accounts on Beats to check if the Re-usability of the token was working or not. But Apple was ahead of me in that too :p , but than i noticed that both were trying to Request at the same end-point. It was

https://www.beatsbydre.com/on/demandware.store/Sites-beats-Site/en_US/GigyaRAAS-SaveCustomer

That’s not enough, There must be some check going on Server-Side after Request is sent to this End-Point. I played with the Lengthy 80 chars Anti-CSRF token for some time and yield no fruitful results than i tried. Than i compared the length of Anti-CSRF token intercepted from my different accounts and found every token had an definite total length. The picture was looking more clearer now, the questions were

1. Is the server side check Full Length Token Based validation ?
2. Analyze the Token, Randomness, Complexity and Compare similarities ?
3. Any Constant characters length  in the Token?
4. Weakness in Token Itself?

The first 20 characters were using a Fixed Token Value for every Request from [a-zA-Z0-9] just like VxM7k0ya2N1R69Ix9E3m

The point is, if they haven’t used Fixed characters here than the Entropy of the First part of the Token would be 95.6 bits. Even if the Characters were swapped or randomly changed than it could not pose a risk as there is much more parts left in token. In most of the Anti-CSRF Token i have encountered, the separation are mostly done by forward slash (/) . After the Slash the next part contained a Hash which most of the Accounts Anti-CSRF Tokens had the same length but different characters.

2165n60n2p399n38q6r1904o1po98r1snn323q0q   was the Next piece of the Puzzle. Length was 40, at first strike i thought It must be a SHA1 Hash because it is 160 Bits, Now 8 Bits = 1 Bytes . Therefore, 160 / 8 = 20 Bytes. Two Hex characters like  0000 0000 (0) – 1111 1111 (255) makes a single Byte. So, 20 x 2 = 40 Hex digits, which was indeed the size of the Token Hash. Now, as this is a Hash than my next line of action was to Bruteforce, i tried bruteforcing it with Name + UserID , UserID + Email , Email + Name etc Combos . Nothing Worked :p . My guess was are they including a Timestamp to build a hash Just like email:id:timestamp . If that was the case, it was Impossible to get through it making a Universal CSRF. Nothing was going well at this moment, until i went to think it in reverse manner. Now, i took combo of UserID , Name , E-Mail Id and Tried hashing them and cross-verifying with that Token portion. Two things were possible now:

1. That SHA1 Random portion was Hashed further by an other Hashing Algorithm
2. It was only the SHA1 portion, but it might contained another Parameter.

I tried to go with the First one, And ANOTHER Encoding. I have played a few CTF’s in past and have also Contributed to Github’s CTF’s main repo in past to submit my Writeup. In one of the CTF i played recently, i saw they were using ROT13 Encoding to brainstorm the players. After that, i pentested a Ruby based web application which used ROT13 based for a Download functionality without access-controls. But here, the case was a Bit different. Here, only the NumericID was Hashed with SHA1 and than converted to ROT13. Let’s see in depth. As i wrote earlier, i took Bottom-Up approach, which means Hashing every suspicious things like ID, Email , Email+ID to SHA1 and than converting it into ROT13. Make two text files and cross-verifying with the Token’s Hash.

Procedure:

2165n60n2p399n38q6r1904o1po98r1snn323q0q – Initial Hash

2165a60a2c399a38d6e1904b1cb98e1faa323d0d – SHA1 Hash (by Rot13)

d0d323aaf1e89bc1b4091e6d83a993c2a06a5612 – Reverse

2292 – Plain Text (https://md5hashing.net/hash/sha1 or Cross-Verification)

That was the User ID infact. What ?? After some days of testing, i finally saw something in Plain-Text :p . Next was the Last 18 characters, Oh no. Beats be like

I was feeling too much bored and had no power to Crack this weird thing 3Ex5Klu9mD1x5vMo91 . I was thinking it might be some Cryptic thing now, with 85.7 Bits of entropy i didn’t wanted to waste my Thousands of years on this ! Than, i had to think positive that it must be Full Length token based Validation with those 18 chars keeping it completely same for Every Account. Final csrf_token be like VxM7k0ya2N1R69Ix9E3m/2165n60n2p399n38q6r1904o1po98r1snn323q0q/3Ex5Klu9mD1x5vMo91 .

Guess what. Fortune Favours the Brave

A sigh of Relief but it wasn’t over yet, Now i had to try the same for other users account (Test Accounts of mine), This could have been IDOR if session_token wasn’t supplied by the web-application. But who cares? I gave my everything top shot on this CSRF which was enough and that too a Site wide Beats main domain CSRF. Now, I tried by using same Encoding method of UserId for Victim’s account and Voila it worked. 🙂

Response:

{“isCustomerSavedSuccessfully”: true, “unsubscribeStatus”: null } -> Attack Successful

{“isCustomerSavedSuccessfully”: false, “unsubscribeStatus”: null } -> Attack Unsuccessful

Proof Of Concept: https://gist.github.com/aadityapurani/80ed9e4a2032d8d060e619ade68547c8

Now, if you remember before the Article i told you that Supplying E-Mail id change in a Separate form in Risky, now it’s time to assess why it is, Here in this case My CSRF Request to any account could be able to Change E-Mail Id of the Victim user ( Not only Email but everything like Name, Last Name, Number, Zip). After E-Mail address is changed to Attacker’s dummy email, i could go to forgot Password and Takeover Victim’s account. This is what i tried to show in this short Video POC

That’s it, it is quite evident how much significant risk it can impose on Beats users. Kudos to Responsive Apple team for extremely well co-operation and resolution of the Bug report. This bug has been patched before 2 months ( April 2016) . And now Apple has framed a super cool protection by Cross-verifying the token in Headers too. And in Set-Cookie now they are sending the Details of input values separated by | . Moreover, Now they changed the Endpoint to other One which Has particular random numbers at it’s end. A Serious CSRF Protection out there now and amazing team to work with.

What’s Next?

Apple Acknowledged me in their Prestigious Hall of fame:

https://support.apple.com/en-us/HT201536

Sweet, that was the complete story about the 8th CSRF on Apple product till date ! Cheers.

Timeline:

October 8th 2015 – Reported
October 23th 2015 – Triaged
November 6th 2015 – Responded that “Matter is being investigated”
January 18th 2016 – Fixed
June 20th 2016 – Acknowledged

I think that A Better Fix > A Fast Fix . Apple took time, but in the end Everything ends well.

Follow: