EssentialsX

EssentialsX

2M Downloads

Discord relay - allowed-roles ambiguity between role IDs and names can lead to privilege escalation

arjunsatarkar opened this issue ยท 1 comments

commented

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

  1. Add a role ID to allowed-roles for the execute command.
  2. Make a new role whose name is the same as that ID, for example name it 395277849877151767 if you have allowed the role with ID 395277849877151767.

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).

commented

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.