Escalating privilege

Starting from an ordinary account

When someone takes over an ordinary account, they get whatever that account can do. Riley works in Cedar Inc.'s finance team. Riley's account can read and send Riley's mail, open the invoices the team works on and look colleagues up in the staff directory. It cannot create accounts, reset anyone else's sign-in methods or change Cedar's sign-in policy. An attacker who signs in as Riley gets the first list and not the second.

The second list is the bigger prize. An account that can reset other people's sign-in methods can take over any of them, and an account that can change policy can switch off the checks that would notice. Turning the access you were given into access you were not given is privilege escalation. Reaching more powerful permissions, such as administration, is often called vertical escalation. Reaching other people's data at the same level, such as a colleague's invoices, is horizontal escalation.

Both start from what a signed-in account can see, and ordinary accounts can usually see a lot. A staff directory shows who belongs to which team and who the administrators are. Group listings show which groups exist and who owns them. None of this needs to be secret, but together it is a map. At Cedar, the attacker's most direct try for more was a call to the help desk that was refused. The routes that follow are quieter. They run through the configuration itself, and each step can look like ordinary administration in the records.

Granting yourself more

The most direct route is an account that can change permissions and uses that ability on itself. Suppose a finance systems lead at Cedar may edit the roles the finance team uses, so that the team's access keeps up with its work. The lead also holds one of those roles, Finance reviewer. Adding a permission to Finance reviewer adds it to the lead, so the right to edit a role has quietly become the right to grant oneself anything the editor can add.

The same pattern takes other forms. Someone who can assign roles may be able to assign one to their own account. An administrator scoped to one office may be able to widen an assignment from that office to the whole organization. Where access depends on attributes, as described in Deciding what someone can do, a profile field such as department may be editable by the person it describes. If a rule allows payroll exports for anyone whose department is Payroll, a self-service profile page has become a permission screen.

Each of these works because the system answered a narrower question than the one that mattered. It asked whether this person may edit roles, or edit their profile, and not what this person will be able to do after the edit. The records show the difference to anyone who looks: a role edit or assignment where the account making the change is also the account that benefits, or an attribute change followed shortly by access the account has never used before.

Indirect routes

Escalation does not need a self-edit. More often the path runs through something the attacker controls that is connected to something more powerful. Groups are the most common link. When a role is assigned to a group, whoever controls the group's membership controls who holds the role. Group owners are often ordinary team members, chosen because they know who belongs on the team, not because anyone meant to give them administrative power.

Nesting lengthens the chain. A group can be a member of another group, and a role can include another role. Each link may be reasonable on its own, added years apart by different people, yet the combined result is something nobody decided. The diagram shows a configuration like that. A member of the finance team owns a small group created to administer one finance application. At some point that group was placed inside a broader IT operations group for convenience, and the operations group holds the User administrator role.

Following the arrows shows the problem. The finance team member can add any account, including one an attacker controls, to the finance group, and that account then holds user administration through the nesting. Nothing on the path is a flaw in the software. It is the configuration read as a whole, and it only becomes visible when someone works out the effective permissions instead of looking at one assignment at a time.

Accounts that are not people are links too. A service account or an integration with administrative rights does its work with a credential such as a client secret. Whoever can manage that credential can act as the integration, and the integration may hold far more than the person managing it. An application owner who adds a new secret to an integration that can manage users has, in effect, granted themselves user management. The same move lets an attacker keep access after the original account is cleaned up, as How attackers stay in explains.

Limits on who can grant what

Each of these routes closes with a rule about who can grant what, enforced by the service that makes the change. The first is a delegation limit: an account can grant only permissions it holds itself and is allowed to pass on. A help desk lead who may assign the help desk role cannot use that ability to hand out user administration, because it is not theirs to give. Administering roles safely works through this limit in detail, including how it applies to role edits as well as assignments.

The second separates defining a role from deciding who holds it. People who edit what a role permits should not be able to assign it to themselves, and nobody should add permissions to a role they currently hold without a second person approving. Editing a role changes the access of everyone who holds it, so the service should check the edit against every current holder, not only against the person making it.

Groups need the same treatment. If a group carries a privileged role, adding a member is granting that role, so only someone who could grant the role directly should control the membership. Nesting a group, or including one role in another, deserves the same check, made against the effective result. For grants that reach administrative permissions, many organizations also require a second administrator's approval, which turns a quiet self-promotion into a request someone else has to read.

Refused attempts belong in the records alongside the changes that succeed, with the account that asked, what it tried to grant and why it was refused. An ordinary account trying to give itself more is rarely an accident. The following exercise shows role and group records from made-up configurations. In each one, find the path up.

account usr_2207 (accounts payable clerk)
  member of:  ap-team
  owner of:   expense-tool-admins

group expense-tool-admins
  roles:      Expense tool administrator
  member of:  it-operations

group it-operations
  roles:      User administrator

account usr_3150 (finance systems lead)
  roles:  Finance reviewer, Finance role editor

role Finance reviewer
  permissions:  invoices.read, payments.view
  holders:      usr_3150, usr_3188, usr_3201

role Finance role editor
  permissions:  edit finance roles, add any permission

application payroll-sync (service account)
  roles:        User administrator
  credentials:  1 client secret
  owners:       usr_4410

account usr_4410 (payroll analyst)
  roles:  Payroll viewer

policy payroll-export
  allow if:  department == "Payroll"
             and sign-in method is phishing-resistant

profile page (self-service)
  editable by the user:  display name, phone, department

Checking on every request

Some routes need no configuration mistake at all. Imagine that Cedar's administration console shows a Reset sign-in methods button only to help desk staff. Hiding the button keeps the screen tidy, but pressing it still sends a request to the console's server. If the server accepts that request from any signed-in account, anyone who sends it directly can reset methods, with or without the button. The service that performs an action has to check the permission itself, as Deciding what someone can do explains.

The request also names its target:

POST /admin/users/usr_1042/methods/reset HTTP/1.1
Host: admin.cedar.example
Cookie: session=EXAMPLE_SESSION

Changing usr_1042 to an administrator's identifier changes the target, not the person asking. The server has to check that this caller may act on that particular account. A policy might let help desk staff reset methods for ordinary employees while requiring a stronger process for administrators, and the server enforces that distinction on the identifier it receives, whatever the screen offered.

The check also needs current information. If an application decides once at sign-in and keeps the answer in a session or a long-lived token, a role removed at 10:00 may keep working until that session ends. Checking current assignments on each request, or keeping any cached decision short, means that removing access actually removes it. When the information needed to decide is missing, such as an unknown permission or a policy service that cannot be reached, the safe answer is to refuse.

Accounts that already hold administrative power need protection of their own, which Protecting privileged access covers.