Exploiting Two Endpoints to get Account Takeover

Before starting the vulnerability exploitation part let me give you some information regarding the target application. I was invited to a private program, were one of the target website let’s say “ example.com ” had a functionality to create group which consists of a Group Admin and Group Members. In the group the admin can give certain privileges to all the group members, the privileges were like changing the admin’s profile data like name & email, adding users to the group, deleting users from the group, permission to change the current privileges of the group and some other set of privileges. I don’t know why they had put up such weird set of permissions over there, but they were there.

Now lets begin the FUN part i.e Vulnerability Exploitation. As there was a group with the functionality to provide privileges, so I thought to try out privilege escalation.

So while adding a member to the group I found an interesting parameter in the response (The name used for the parameter is different than actual for obvious reasons):

hash:A12B32…

The hash in the response presented us a combination of letters and numbers belonging to the user which was being added to the the group.

Now while adding any privilege mentioned previously to the group the same hash parameter was used in the request being made but now the hash was belonging to the Admin of the group.

After that I intercepted the request to add a privilege to the group and changed the admin’s hash in the request to a group member’s hash and what I saw was pretty unexpected. A privilege to the group was added but now the application interpreted that privilege as if the Group Member[B] (whose hash was used) is the admin of the group i.e let’s say if the privilege was to edit Admin’s[A] profile so now this manipulated privilege has enabled the actual group admin i.e “A” to edit that group member’s i.e “B’s” profile.

As previously mentioned the set of privileges was so weird that now if an attacker created a group and added the victim to that group, then by adding those manipulated privileges to the group the attacker can completely takeover victim’s account. In this way I scored a P1.

The next bug I found in the same program was a functionality bug. One privilege present there was to enable any group member to add or remove any group member except admin. But the flaw in the implementation was that once this permission was added in the group then any group member was not only able to add or remove group members but he/she was also able to change the privileges of the group itself through there API. But since this attack requires the attacker to be member of that group on which the attack is to be performed and also requires that the admin should have added the privilege to add or remove the group members the priority assigned to this bug was P2, which is surely a justified priority.

So what I learn from this experience is that even if we find a P1 in the program, we should keep on looking for other bugs too, who knows you may get another one too.

If do have any doubts or questions put them in the comments box below or do ping me on LinkedIn or Twitter.

  1. LinkedIn
  2. Twitter

See you in my next blog post, till then Happy Hacking!!!!