Author: Inon Shkedy

  • The Shopify Breach: Why Authz Exploits Slip by Most Security Defenses

    The Shopify Breach: Why Authz Exploits Slip by Most Security Defenses

    What Happened

    As part of a bug bounty, the security researcher Uzsunny found a critical vulnerability on the Shopify platform. The vulnerability allowed the attacker to assign himself as a “collaborator” to any store on Shopify without approval from the store’s manager. Collaborators have full access to perform any action on the store, including reading customers’ data, changing inventory and more.

    Technical Details

    The Shopify Partners Program allows experts to connect with Shopify store managers and provide them services such as design and web development. A single expert can be a collaborator on different stores.

    The process of requesting “collaborator” access to an existing store contains three steps:

    1. The expert enters the store URL.

    2. The store manager receives an email about the access request.

    3. Once the store manager approves the request, their browser sends an API call to:

    This API call approves the access request by the expert and converts him to a “collaborator.”

    The problem: The code did not validate that the API call was triggered by a store manager. In fact, any user could call the API endpoint and approve the access request, even if they don’t have the right privileges.

    Using this technique, Uzsunny managed to “log in to any store with full permissions.” For his troubles, Uzsunny received a $20,000 bounty from Shopify, which reported: “We tracked down the bug to incorrect logic in a piece of code that was meant to automatically convert an existing normal user account into a collaborator account.”

    Why Can’t Current Security Solutions Detect It?

    The exploit in step #3 looks simple and requires only a single HTTP request: “POST /admin/settings/account/approve/<id>.” Authorization exploits usually look legit from a WAF/RASP perspective; they don’t contain suspicious payloads or characters, weird HTTP headers or abnormal structure. In fact, if the same exact HTTP call was sent by a different user who is a store manager it would be completely legit.

    In order to understand authorization exploits, a much broader context is needed. It’s simply not enough to look at a single HTTP request.

    How Traceable Solves the Problem

    Our approach to detecting API attacks is very different. In a nutshell, we observe the data that passes through the API and the microservices of the app. We then use our machine learning algorithms to discover the application’s business logic. We get full visibility into the users and their roles, the API endpoints they communicate with and the resources the endpoints interact with behind the scenes. Now we can create a baseline understanding of a legit user’s flow through the system.

    The visibility into users helps us understand that the client is actually a guest user, and the visibility into the API helps us to recognize that the endpoint is an admin endpoint that should be used only by store managers. Then we can simply block malicious abnormal activity.

    With this approach, we can detect the most sophisticated and subtle API attacks, including broken function-level authorization (BFLA).

    Interested to learn more?

    Watch our recorded demo and see Traceable Defense AI in action!

  • Why Was Facebook Vulnerable to an Authentication Exploit?

    Why Was Facebook Vulnerable to an Authentication Exploit?

    What Happened:

    As part of a bug bounty program, the AppSecure cybersecurity research team found a vulnerability on the authentication mechanism of Facebook. It gave them the ability to potentially gain full control of the social media giant’s more than 1 billion users. The team won a $15,000 bounty for its discovery.

    This vulnerability was found on a niche API, which reminds us that in many cases the most interesting bugs don’t exist on main APIs but on secondary ones that have fewer protection mechanisms in place.

    Anand Prakash, CEO of AppSecure and who was credited with finding the bug, explained what he found: “This gave me full access to other user accounts by setting a new password. I was able to view messages, their credit/debit cards stored under their payment section, personal photos, and other private information.”

    Even though the vulnerability was discovered in 2016, similar weaknesses have been discovered — and in many cases exploited — ever since. Here is a closer look at the Facebook case and lessons to be learned in modern application development.

    Technical Details

    The vulnerability exploited the password recovery mechanism on Facebook. The steps of the process were:

    1. The user starts the “forgot password” process by using their email address.
    2. Facebook sends a text message with a temporary 6-digit secret token to the user.
    3. The user enters the received temporary code, and the browser sends an API call to “POST facebook.com/recover/as/code/” with the secret token.

    Facebook had implemented an anti-brute force mechanism on this API that blocked the user after 10 failed attempts. However, during their research, the AppSecure team found that the same API endpoint existed on different API hosts, under “beta.facebook.com” and “mbasic.beta.facebook.com.” These API hosts didn’t implement the anti-brute force mechanism, allowing the attacker to easily iterate through the secret token and reset the victim’s password.

    Why Current Security Solutions Can’t Detect It

    Keeping track of your APIs it’s not an easy task. Modern organizations might have dozens or even hundreds of API hosts for different environments, regions, or versions. Each API host can expose multiple API endpoints that are related to authentication processes including login, forgot password, and one-time login link. Many security solutions in the market focus on protecting your main APIs and don’t have enough visibility into the less common or less used APIs (such as Facebook’s beta API in the example above). Sophisticated attackers choose to target those niche APIs.

    How Traceable Solves the Problem

    Traceable AI monitors all APIs including the different environments, versions, and regions. For each API host, we automatically and manually detect the authentication endpoints that your APIs expose (including login, forgot password, etc).

    This granular understanding of the API structure allows us to set very strict protection for your most sensitive assets.

    Interested to learn more?

    Watch our recorded demo and see Traceable Defense AI in action!

  • The Uber API Authorization Vulnerability

    The Uber API Authorization Vulnerability

    What Happened

    In September 2019, a critical bug was discovered on Uber API, which allows merchants, service providers and others to offer ride-sharing services to customers. Uber had exposed a vulnerable application programming interface (API) endpoint that allowed attackers to steal valuable data, including personally identifiable information (PII) records and authentication tokens of riders and drivers. The leaked authentication token could be used to perform a full account takeover.

    Luckily for the company, the vulnerability was discovered before harm could be done. But the case is an example of where traditional security systems can fail to find potential threats because they lack the business context for the application’s logic. Let’s take a closer look at what happened and the implications.

    Technical Details

    When a new Uber driver joins the platform through a referral link, their browser communicates with the API host  “bonjour.uber.com”. The registration process triggers an API call to the API endpoint of:

    POST /marketplace/\_rpc?rpc=getConsentScreenDetails

    The API receives the “userUuid” parameter from the client and returns details about the user. This information is used to populate the consent screen on the client-side:

    As part of a legit flow, the user should send only his own user ID.

    The API endpoint is susceptible to two types of API vulnerabilities:

    • BOLA (Broken Object Level Authorization). Because the program didn’t validate that the client who sent the request had access to the user represented by the user ID parameter, the client could access data of other users by changing the user ID.
    • Excessive Data Exposure. The API response contains a large JSON object with all the user’s details. The API returned this information, even though the client didn’t use it.

    Why Current Security Solutions Can’t Detect This

    When we look carefully at the exploitation flow, we find the attack involved a very subtle change in the API call, replacing one user ID with another. In order to detect such a small change in the traffic, a deep understanding of the business logic of the app is required.

    Current security solutions in the market lack that understanding, usually acting on the context of a single HTTP request. They don’t deeply understand important components of the application that are required to detect BOLA and other authorization vulnerabilities.

    How Traceable AI Solves the Problem

    The Traceable Defense AI approach to detect API attacks is very different than other security solutions. In a nutshell, it observes the data as it is passes through the API and the microservices of the app. It then uses machine learning algorithms to discover the application’s business logic, providing full visibility into the users and their roles, the API endpoints they communicate with, and the resources that the endpoints interact with behind the scenes.

    This methodology allows Traceable to create a baseline of what a legitimate user’s flow looks like, and hence to detect the most sophisticated and subtle API attacks, including BOLA.

    Interested to learn more?

    Watch our recorded demo and see Traceable Defense AI in action!