How a Privilege Escalation Led to Unrestricted Admin Account Creation in Shopify

In a privilege escalation attack, an attacker gains elevated rights, permissions, or entitlements beyond the intended level associated with their identity, account, or device. Systems are vulnerable to such attacks due to several factors, including bugs, human error, misconfigurations, system flaws, and inadequate access controls. There are two main types of privilege escalation:

1. Vertical privilege escalation: This occurs when an attacker elevates their privileges, such as a regular user gaining administrative rights or root-level access.
2. Horizontal privilege escalation: This occurs when an attacker maintains the same or similar level of privileges but in the context of a different user or account.

Almost every multi-account application takes a defense-in-depth approach to access control. Due to this layered security posture, according to the 8th Annual Hacker-Powered Security Report, the platform average for reported privilege escalation vulnerabilities only accounts for 2% of submissions. This low rate can be partially attributed to bug bounty program rules that require testing to cease after initial compromise. Additionally, privilege escalation is a broad category, and the exploitation of other vulnerability classes can result in an attacker acquiring elevated privileges.

However, when these attacks do occur, the consequences can be severe. If the vulnerability is systemic or an attacker obtains high-level privileges, they could compromise every account. Privilege escalation vulnerabilities can also allow attackers to bypass paywalls, such as in cases where subscription tiers are elevated. In extreme cases, attackers can completely hijack devices with the installation of malware or backdoors.

Even with the wide variety of defensive controls that mitigate the risk of privilege escalation attacks, exploitation still poses a constant threat that must receive the proper attention to detail to effectively counteract—as oversights in implementation can provide the exact attack vector needed.

Authentication

Authentication checks if a user is who they claim to be based on submitted identification parameters. 2% of all reports submitted to HackerOne were for improper authentication vulnerabilities, according to the Hacker-Powered Security Report.

Arguably the easiest way to gain a higher privilege level is via the exploitation of authentication processes.

There are numerous vulnerabilities that can be used to take over an account, such as:

• The use of weak or default credentials can provide an easy means of assuming a privileged identity.
   
• A lack of rate limiting can allow for an indefinite number of login requests to be sent until valid credentials or one-time-passwords (OTPs) are found.
   
• Multi-step authentication processes can contain business logic flaws, allowing critical steps to be skipped, such as the point at which a multi-factor authentication (MFA) token is provided.
   
• Attacks such as SQL injection can result in entire databases of valid credentials being leaked.
   
• Password reset functionality can also be flawed. For example, the same token can be issued to multiple requests if they are generated based on time or are sourced from a premade pool of valid ones.
   
• Validation processes can also be flawed. For example, a token may only be evaluated and used to protect a sensitive function if it is received by the server. In this scenario, simply excluding the token altogether may allow the access control to be bypassed, leaving the function exposed to unauthorized execution. Security issues can also arise in cases where tokens can be reused across different requests or areas of the application.

Regardless of the vulnerability, authentication exploits have the same end result – an attacker gaining direct access to a compromised account.

Role-Based Access Control

Role-based access control (RBAC) is a security measure that allows administrators to define which types of users are authorized to access specific resources or perform certain actions. The “roles” in RBAC refer to the set of assigned privileges granted to users. These roles can be assigned per individual user or to a specific group of users.

While RBAC provides a significant line of defense, there is no one-size-fits-all solution. Those responsible for defining roles must have a deep understanding of what certain users should be capable of. Without this awareness, roles may be overly permissive. Role definitions can even be influenced by user frustration and complaints. If a certain functionality is too restrictive, the security configurations protecting it may be relaxed to avoid friction or pain points.

Additionally, vulnerabilities can exist in how a user’s role is determined:

• Roles determined based on a client-side parameter such as a header can be arbitrarily changed.
   
• Hidden fields that rely on security-through-obscurity can also be discovered, which can lead to mass assignment attacks that result in privilege escalation.
   
• Weak obfuscation techniques, such as masking an access token with a common encoding conversion or the use of cryptographically insecure algorithms, can expose embedded values that determine a user’s role. Simple match-and-replace rules or reverse-engineering techniques could then be used to provide the desired value in place of the assigned one.

In a worst-case scenario, RBAC could be missing from an asset or endpoint entirely, allowing unrestricted access or function calls.

Reports of improper access control vulnerabilities represent 9% of all submissions to the HackerOne platform.

The Principle of Least Privilege

The principle of least privilege (PoLP) goes hand-in-hand with RBAC and is a security concept that advocates the idea that users and connected systems should only be given the permissions that are absolutely necessary – nothing more, nothing less. As an example, a user should only be able to access files belonging to them, while a manager who needs access to files across multiple users should be restricted to files within their team or those they are responsible for. If an attacker is able to access the files of other users, the application is vulnerable to insecure direct object reference, which accounts for 6% of all submitted reports.

However, in cloud environments, many privileges and actions are granted by default, and it takes explicit configuration to revoke them. These default capabilities apply to both user roles and cloud resources such as virtual machines. Without making changes tailored to the organization, privilege escalation attacks could result in bypassing network partitions or low-level users performing critical operations.

The Exploit

On June 27th, 2021, security researcher @stapia submitted a report describing a privilege escalation vulnerability they discovered on https://stocky.shopifyapps.com/. By sending a request directly to the /users/create_admin endpoint, a non-privileged user could create and login to an administrative account.

Steps to Reproduce

1. A non-privileged user account was created.

2. Once authenticated under this account, navigating to the /users/me endpoint would produce a request containing cookies and an authenticity token that were also compatible with the vulnerable endpoint.

3. This request was intercepted, the request line was changed to POST /users/create_admin HTTP/2, and the following body data was included:

4. Forwarding this request resulted in the successful creation of an administrator account. With administrative privileges, a user could update the inventory, stock, vendors, place purchase orders, etc., in the context of the organization’s Shopify account.

Protecting Against Privilege Escalation Attacks

In this example, Shopify issued a token that was valid across multiple endpoints. Had they scoped the token to be endpoint-specific, its use would not have been accepted for the /users/create_admin endpoint.

Generally speaking, privilege escalation attacks are the result of various security failures. It is vital to take a layered approach to defense and ensure proper implementation and configuration of the measures taken:

• Any generated tokens should be specifically scoped, use reliably secure obfuscation techniques, and be single-use.
• Follow basic password management practices, such as enforcing password strength and the use of MFA.
• Fully vet the authentication process for any weaknesses that allow an unreasonable amount of login attempts to be made.
• Sanitize and validate user input to defend against injection attacks.
• Perform a thorough review of the permissions assigned to roles at regular intervals, with updates made anytime changes are made to the application.
• Revoke roles for inactive users or groups to reduce the overall number of accounts that could be used as attack vectors.
• Permissions must be properly validated for every request, regardless of where the request originates from.

Conclusion

The efforts of @stapia resulted in a bounty of $1,600, and the Shopify team deployed a fix for the issue on August 25, 2021. When testing on programs, make sure to analyze the application for the security flaws discussed that could lead to an escalation of privileges.

See further examples of reports involving privilege escalation here.

This report highlights the importance of securing against privilege escalation attacks, especially in applications such as Shopify that deal with e-commerce environments and tools. Had a malicious attacker discovered this vulnerability before it was responsibly reported, the financial losses could have been substantial. With the power of crowdsourced security provided by HackerOne, this vulnerability was remedied quickly, and the safety of Shopify’s user base was improved.