Hello there! Hope you're having an awesome day :D

Actually, it's been a few months since I found this bug, but I had no success in trying to contact you guys, and now I discovered that you're on Huntr. So now I'm sending my report from here :)

Summary

During this week, I was participating at a bug bounty beginners event and they used Elgg to create a social network example. So...I ended up submitting a report, thinking that it might be an on purpose bug, but it was actually a bug on the Elgg itself, because I installed it on my computer and it still happens.

Basically, the bug is an IDOR on the endpoints below:

https://website-example.com/action/groups/join
https://website-example.com/action/groups/leave

These endpoints request a param called user_guid, which represents the user that will be joining or leaving the group. But also, these endpoints don't filter whether the request is being made by the user itself or not, and because of that, any user is able to intercept the HTTP request and change the user_guid param to any other user ID, in a way that's possible to create a group and add people to it without needing to invite them, or maybe worse than that, it's possible to pick a group that already exists and remove everyone from it (except the group owner) without having enough permissions.

STEPS TO REPRODUCE

1 => Let's begin from an Elgg example instance (I've tested on 3.3.21, and maybe previous versions are also vulnerable to that);

2 => Besides the admin user, create two other users (with three different users, we will have the group owner, the "attacker" and the "victim");

3 => Logged into UserA, create a group. UserA will be the group owner;

4 => Logged into UserB (attacker), go to the profile page of the UserC (victim);

5 => As the UserB, pick up UserC's ID (there are some buttons inside the profile page that show up the user ID, as for example, the "Add friend" button and the "Send a message" button);

6 => Now that UserB has the victim's ID, go to the page of UserA's group;

7 => At this point, maybe you'll need a tool to intercept your own HTTP requests before testing the bug, I used Burpsuite but you guys may test it with any other tool;

8 => With your intercept tool turned on, and looking to the group page as the UserB, click on the "Join group" button and intercept the HTTP request.

9 => Looking at the request URL, you will see a param called "user_guid", which at this moment has the UserB's ID. Replace it with UserC's (victim) ID and forward the request.

10 => The endpoint will return a message telling that UserB succesfully joined the group, but when you look at the group members list, the Victim is the one who joined the group.

11 => These steps are the same for testing the /action/leave endpoint, but the victim ID must be from an user that's already a group member.

POSSIBLE SOLVING WAYS

Probably you guys already know how to solve an IDOR like that, but I would like to point two possibilites:

1 => Verify if the user_guid param is really equal to the id of the user who's requesting these group actions;

2 => Instead of requesting the user ID as a param, the endpoint could also be picking it automatically from the database or from the user session;