Hello security professionals. In the last post, we talked about the XSS finding in the recent penetration test conducted by our company ENCIPHERS. Here is a link to that post. In the same penetration test, we found another vulnerability which was really an interesting one.
But first thing’s first, if you are not sure about access control issues, we have already posted a tutorial for it. Go to this link to read the post.
Now, let’s see what we did and go through step by step. If you know, to test any access control issues, the best way is to create two accounts. You can make 2 accounts which have the same access level or if you can, you should always create 2 accounts 1 with normal features and other with the more features of a Paid account. This is the first thing which we did. Created 2 accounts, one of a Free User and the other of a Pro user and started cross-testing them.
We logged in with both of these accounts in different browsers. Then we opened the account with Pro features. As we already told you in the previous post, there was an option to create self-videos and edit the different details as necessary.
So we created a video and opened the Edit options which led me to a new page. The link to that looked something like this:
The identifier here was not random i.e it wouldn’t change if we made any edits in the video. So this was a plus point and a hint to test for access control because the identifier won’t be unique every time.
The request in Burpsuite looked something like this:
GET /api/v2/videos/fwyFsxFfB8Z?include_content=true HTTP/1.1
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0
Accept-Encoding: gzip, deflate
And the response was the one giving out all the details of that video and stuffs inside it like text.
So we went back to our free account and in that browser opened the above link by pasting it there. It worked.We could see the whole video and even play it with what else has been written or added as animation or text. There were no access control measures in place until this point. To see this in Burpsuite, we just needed to change that identifier fwyFsxFfB8Z to the one from the other account to see all the details.
But right after this point, the system prevented me to Edit or Save the file but we had full read control over the video.This vulnerability was critical in its own sense. Because of:
- All the URL’s were getting saved in the browser’s history. It means anyone gaining an access can then open the link or share it with him to check the video in make.
- The most important issue was the attacker will always see the updated thing. That means if the user has made any changes in the video or animation by adding any text or scenes, the attacker will see the same thing as that user.
- The issue was for both private and public videos.
- This could lead to important information disclosure because the attacker could see the same video. Just think for a second, if it is a reputed company or so, preparing their videos or any stuff and it is in a draft state and if the attacker by any chance get the link, he will see that stuff himself/herself and meanwhile can find any other way to download that thing before the video gets public.
So this was a simple case of access control. You will think that Write access was not granted but gaining access to things which you are not meant to have is what is access control. We had full READ access to that video which is pretty much a problem in itself.
We will be back again with lots of cool stuff which ENCIPHERS findings pentests or Bug Bounties. Hope you will like it and learn a lot from these practical cases. Happy hacking until then.:)