Discord relay - allowed-roles ambiguity between role IDs and names can lead to privilege escalation
arjunsatarkar opened this issue ยท 1 comments
Type of bug
Exploit
/ess dump all
output
Not important, but https://essentialsx.net/dump.html?id=1a8fa338bb9c488784b4810bd3581e8f
Error log (if applicable)
No response
Bug description
In EssentialsDiscord/config.yml
there are allowed-roles
options for the execute
, msg
, and list
Discord slash commands, which accept both role IDs and role names.
One might add for example "395277849877151767"
, which could be the role ID of a staff role, to this list, with the intent that it will only give access to the role with that ID. However, if a new role is created with the name 395277849877151767
, then that is also interpreted as an allowed role.
This means if any role ID is in the allowed-roles list for execute
, then any user with Manage Roles permission could create a new role whose name is the same as the allowed role ID, assign it to themselves, and thereby give themselves access to console commands.
Steps to reproduce
- Add a role ID to
allowed-roles
for theexecute
command. - Make a new role whose name is the same as that ID, for example name it
395277849877151767
if you have allowed the role with ID395277849877151767
.
Expected behaviour
An allowed role ID should not also allow roles whose name is that ID - in some way the ambiguity should be resolved - and therefore people with the new role should not be able to run /execute
.
Actual behaviour
People with the new role now have console access by running /execute
(this is an exploit because step 2 could be done by anyone with the ability to rename or create roles).
It's also worth noting this attack is even easier if a role name is used. For example, the default config.yml has the string "Admins" in the allowed-roles for /execute - if you don't remove that line, then someone can create a role named that (even if it actually has no permissions) and immediately gain access to /execute.
Frankly this would be simpler if allowed-roles only allowed role IDs and not role names, which fixes both these things - but I suppose that would be a breaking change.