The popularity of freemium, free-trial, and pay-as-you-go app marketing has provided API attackers with an almost effortless way to bypass much of today’s perimeter security. Cyber attackers prey on weaknesses in Know Your Customer (KYC) policies to gain authenticated access to application APIs, and Runtime API monitoring is a critical attack surface management (ASM) tool to monitor and protect the APIs these attackers want to exploit.
Over the past decade, many, if not most, organizations have adopted web and mobile applications as a core aspect of their strategy to interface with customers, members, citizens, and other end users. Invested heavily in this strategy, organizations are very motivated to provide easy and straightforward access to its products and/or services. Unsurprisingly, this has led to marketing teams enticing users with a flood of freemium, free-trial, cheap-value-premium, and email-only sign-ups to spur the onboarding of as many users as possible. Despite security teams’ efforts to establish comprehensive zero-trust initiatives, these fast and free campaigns beg a key question: who is being onboarded?
Strong “know your customer” (KYC) validation is not always a top priority for marketing teams. And there is heavy pressure on development teams to support broad, fast, low-friction user onboarding efforts. Unfortunately, that means that a new customer could very well be an attacker using a stolen credit card to gain 30 days (or more!) of full, authenticated access to your application’s APIs.
Adding to this concern is the sad truth that application security designs often provide any authenticated user with a baseline level of authorization to most aspects of the application, without regard to the level of KYC due diligence that was used in establishing the account. So a free trial account based on only a valid email often has the same level of authorization and access as someone who presented a credit card or even a government issued ID.
How scary is it that a fake email account may be all an attacker needs to establish a “recon perch” behind your perimeter defenses where they can observe and access services typically hidden behind your web application firewall (WAF), identity and access management (IAM), and gateway? Don’t assume that the presentation of a credit card or government-issued ID eliminates the KYC risk either; both can be stolen and/or hijacked. Buying an ID off the dark web is probably much easier for an attacker than brute-forcing their way past your WAF, IAM, and gateway. Which is why becoming an authenticated attacker is often both the “fast path” as well as the “path of least resistance.”
This issue of authenticated (and virtually anonymous) attackers also impacts application attack surface from a zero-trust standpoint. It’s common in organizations for upstream zero-trust efforts to focus on account takeover prevention, multi-factor authentication (MFA), or biometric validation. Obviously, the primary goal is to establish a secure chain of AUTHZ/AUTHN validation processes, but what if that validation is anchored by an authorized attacker?! It’s common to see a zero-trust architecture or ZTNA (zero-trust network access) diagram that never addresses KYC elements prior to account creation, never treating KYC as part of the chain of trust. The irony is that many zero trust initiatives “trust” that the KYC process is strong and robust - a poor assumption in many cases.
Once an attacker has authenticated into their account, they can begin to reconnoiter all the API endpoints in an application. They can perform various actions as a “user” to see how application processes flow across API endpoints, building a target list and noting key sequences and relationships. They can often also get a very clear understanding of the data structures and objects that are commonly used by the application’s APIs. From their privileged sniper’s nest, the authenticated attacker can essentially create an accurate application profile with key APIs, data objects, and patterns all clearly identified. Additionally, by spending a little time acting as a “normal customer” they can establish a profile that will make their follow-on attacks appear less suspicious and more like a new customer having problems.
Another important benefit of this high-quality attack reconnaissance for the attacker is that basic-access user accounts often provide enough information to enable them to make educated guesses as to what API endpoints are used to access more advanced services. Sometimes marketing has requested app designs to allow users a “temporary upgrade” to be enticed by an application’s more advanced features. Accepting these offers helps attackers gain clearer understanding of the application’s scope and map more of its attack surface.
Once a preliminary application attack surface map has been constructed by the attacker, they can begin probing sensitive areas with attacks that can cause response leaks. By sending poorly formed data objects that generate API response “leaks,” they may expose “east-west” services, such as application platform details, further extending the API attack map. They can also easily begin exploring the app for “broken object-level authorization” (BOLA) vulnerabilities to exploit. The majority of recent headline grabbing API breaches can be traced back to fundamental BOLA failures. An authenticated attacker has the perfect position to understand what data objects they have access to as a user, and how they can possibly access those same objects belonging to other users.
Traditionally, ASM has relied heavily on penetration testing to identify the externally accessible assets that essentially define an attack surface. With modern applications, it becomes much more difficult to identify a “perimeter” to be probed. The distinct security perimeters that WAFs, IAM, and gateways establish (preliminary to API access) are an effective model in most cases, but as pointed out above, an authenticated attacker offers a unique security challenge for ASM models. For modern applications the attack surface has morphed to include application logic made accessible to authenticated users via APIs.
To address this new section of the enterprise attack surface, runtime API security monitoring is a critical tool to help identify vulnerabilities and attacks unique to specific APIs. By monitoring all API HTTP/HTTPS transactions at runtime, enterprises can discover a comprehensive inventory of API endpoints for all their applications across multiple gateways and networks. They can understand which of these are currently under common attacks (that have somehow bypassed their WAF/gateway) and use detailed header and payload information to investigate suspicious calls against API endpoints. In other words, this approach enables a best-practices approach to API attack surface management:
By taking a best-practices approach to API attack surface management that aligns with existing processes and methodologies, you’ll have the means to support a fast, orderly and effective expansion of attack surface management to more completely include the organization’s applications generally and the underlying APIs specifically.
While marketing does what it’s been asked to do, drive as many users onto the application as possible, it’s free and pay-as-you-go tactics don’t mean you have to allow attackers to have free run. By unmasking authenticated attackers, you secure your applications and reduce the risk of becoming one of the many companies whose BOLA vulnerabilities made recent news headlines. Considering KYC as part of the chain of trust and deploying API runtime discovery and monitoring are two critical ways that security can update its best practices for stronger API attack surface management.
If you would like to discuss attack surface management and how runtime API monitoring can help identify previously unseen vulnerabilities from authenticated attackers, let us show you how with a demo.
