devopsy.kinsta.cloud

Category: Traceable Breach Analysis

  • 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!

  • Modern AppSec and Supply Chain Attacks – Three Challenges

    Modern AppSec and Supply Chain Attacks – Three Challenges

    The recent news about the SolarWinds breach has focused on the difficulty and challenges a supply chain attack presents.   In the case of what Microsoft is calling “solorigate,” the attackers modified a dll deep inside a trusted application, which was then deployed into over 18,000 enterprises and government organizations, where it would then create a live back door for the attacker to exploit. The Microsoft Threat Intelligence Center (MSTIC) recently published details about how the SolarWinds attack worked and attempted to avoid detection.

    Supply Chain Attacks and API Security 

    In this specific case, the exploit targeted a traditional, legacy application as part of SolarWinds Orion, an IT inventory management and monitoring application. The attack was the result of extensive planning and resources, which appear to be the work of a state actor. The immediate focus must be on mitigation of the current attack. Still, it is also essential to understand that supply chain attacks like this should be considered in the future as modern cloud-native applications become the norm.

    The evolution of cloud-native and modern applications where the functionality is decomposed into microservices, each running independently of each other, presents several new challenges for security and IT professionals to address. Specifically, the underlying application programming interfaces (APIs) introduce new attack surfaces where API security is paramount.  The OWASP API project has enumerated 10 critical API level threats that are substantially more important in the era of modern, cloud-native applications.

    These three trends – microservice proliferation, application change and porous perimeters – create an environment where attacks can flourish and where IT and security teams need to consider revisiting their application security practices and controls.

    Microservice Proliferation

    Inherent in adopting a cloud-native architecture, one characteristic is the decomposition of the monolithic architecture into atomic services. Microservices enable business application teams to operate more efficiently and innovate. This approach also results in a compounding of the number of independent services, where each microservice is a potential source for the injection of a supply chain attack. In the case of microservices, rather than compromising an entire system, an attacker has more opportunities.

    The challenge facing defenders is how to manage the proliferation of hundreds or thousands of new microservices, each with its unique code base and API calls, between services? On one hand, traditional web application firewalls (WAFs) can play a role, attempting to protect the edge, but on the other hand, WAFs do not account for the underlying complexity of the web application and microservices. One key question to ask is, will their rule-based approach adequately detect and prevent this kind of threat?

    Continuous Application Change

    Speed and rate of application improvements and enhancements have accelerated as teams adopt DevOps practices of continuous delivery and continuous deployment. Business expectations of faster delivery and reduced cycle time have naturally led IT teams to embrace and adopt DevOps practices of CI/CD, which, when adopted, lead to significantly shorter cycle times between changes. The industry has seen remarkable improvements in delivery speed; organizations have gone from quarterly releases to weekly and even hourly changes – sometimes, even faster. For example, a team at Goldman Sachs releases every few minutes and Netflix releases thousands of times per day.
    ‍
    In a traditional application where new code is delivered lethargically, it might have been possible to keep up with the pace of change and mitigate security threats. However, in the age of microservices and cloud-native applications, it is unrealistic to maintain full awareness of the application’s state and associated microservices.  Change is happening too fast and at too many internal points for a security leader to adequately manage their risk profile.

    Relatively Porous Perimeter

    Because applications are no longer monolithic installations that reside behind a defense-in-depth fortress, they are much harder to protect. Indeed, the principles of zero-trust are essential when designing and managing modern applications. The reality is that for every microservice (both internal and external), there is a library of interfaces that enable the microservices to communicate with each other (internally), with third-party service providers (externally) and with end users through an established UI.

    Additionally, how many of your applications have a “call home” feature where they communicate health and usage data with their vendor? While many vendors use this information to improve the quality of their service, it is also another potential threat vector to consider.

    The web application firewall and traditional approach to security provide only a degree of protection, as the nature of modern applications encourages the use of SaaS services, third-party services and other resources in the interest of faster delivery. This complicates the challenge of delivering a secure application as well as monitoring it as it is running.

    Suggestions to Address API Security

    We’re still early in the cycle of the SolarWinds breach, and the aftermath will be extensive and expensive, as will the lessons learned as the damage is measured. However, one thing remains true. The threats continue to evolve, which means that security professionals (strike that) IT professionals (because security is everyone’s responsibility) need to renew our focus and commitment to delivering secure, reliable and trustworthy applications.

    There is no perfect protection or 100% secure approach; instead, it is a question of how to establish layers of defense where each layer of security reduces the overall risk exposure. Ultimately, you want to have the ability to:

    • Prevent the risks in the first place (software supply chain and zero-trust architecture) and
    • Detect and react to adversaries who may be attempting to exploit your systems.

    Specifically, here are several recommendations to improve your security posture and lower your exposure:

    1. Invest in processes and tools to help validate your supply chain. A “trust, but verify” approach is critical in the development stages. You should look at tools like Sonatype and others that can help reduce the risks in your software supply chain.
    2. Adopt a zero-trust approach to the design and implementation of microservices.
    3. Maintain awareness and insight into the current state of your APIs and your present risks (too many organizations cannot keep up with the pace of DevOps change).
    4. Augment your perimeter with processes and practices to have “zero-trust, but verify” in production. You need to observe the behavior of each of your microservices and detect anomalous behavior between your microservices.
    • Should microservice A be communicating with microservice B?
    • Is the data flow between microservice A and microservice B typical?
    • Are there suspicious behaviors or patterns that indicate anomalous behavior?

    Traceable.ai helps you detect and react to threats to your cloud-native and modern applications where API security is now mission-critical. If you’re interested in learning more about how you can improve visibility into your modern applications and your overall security posture, the best way to start is to view a quick recorded demo of Traceable.ai.