The Lucrative Economics of API Hacking

OK. It’s time to fess up. I have been staring far too long at my laptop screen, trying to figure out the right title for this article. Should I be saying lucrative or ludicrous? By the time you are done reading this, maybe you can tell me.

Introduction

The impetus of this article comes from a recent video Ben (aka Nahamsec) posted on YouTube about the fact he made $100,000 in two months of hacking. It’s a rather impressive feat, even after you find out that at the end of the two months he had to take a month off due to burnout and a lack of motivation.

By his own admission, Ben mentions he had to give up all his free time to do it and that it wasn’t very healthy. That’s a familiar feeling many hackers have when charging hard like this.

I’ve talked about how to make money hacking on bug bounty programs before, so I won’t regurgitate what I’ve already said. But what Ben demonstrates is the hit-and-miss of bug bounty hunting and the toll it takes on you when it comes to inconsistencies in income.

At a recent BSides event here in Vancouver, I attended a talk by Wesley Wineberg (aka w–), where he covered his experience over the past ten years of bug bounty hunting. An interesting stat he shared from his own experience is the fact he’s had to report over 1,500 bugs across the projects he’s participating in to put food on the table.

That’s a lot of work.

I have massive respect for Ben and Wesley. But they both work too damn hard looking for vulnerable web applications and infrastructure to be paid peanuts by vendors for their skill level. Ben mentioned he was averaging between $800 and $2,000 for each of the vulnerabilities he found. One outlier was that of an SSRF vulnerability that he turned into a critical RCE which netted him a bounty of $12,000 that he split with Alex Chapman.

I’m not afraid of work. But I do believe that the economics of API security testing is far more lucrative than what these guys are seeing. They deserve to be earning those five-figure bounties on crit vulns. And API hacking can lead to finding more of those.

Let me explain.

The business of bounty hunting

So there are two main areas of thinking when it comes to bug bounties. The first is that you can invest a lot of time in your recon to “search wide“, finding new or obscure assets of a company that other hackers will miss. It’s common to see advice from leading bug bounty hunters that they want to participate in programs that have a huge scope that allow them to find new targets fast and find the low-hanging fruit before anyone else does.

The other methodology is to “dig deep”; you invest your time researching how the application works in much greater detail and look for more complex bugs that demonstrate more impactful critical vulnerabilities.

The latter methodology is the camp most API hackers fall into. When you hunt for security concerns in an API endpoint there is a lot of effort that goes into understanding the platform, resources, methods, functionality, and implementation of the API. You have to get deep into the API documentation and will usually have to build your own rogue API documents to get complete coverage of the internal APIs that probably aren’t documented properly anyways.

That investment in understanding the environment serves you well into the future. A typical API vulnerability like missing or weak authorization checks gives direct access to sensitive data which can lead to higher criticality and ultimately higher payouts. I’ve shown you how to use popular Burp extensions like Autorize to find these sorts of authorization issues in APIs before.

API security is much like enterprise security in that it needs a layered approach. Yet typical runtime protection in API gateways and API management systems do little to properly protect APIs. If an API is allowing access directly to or from the Internet, it may be a clean attack vector to gain access to loads of services and data that developers didn’t intend for you to access directly.

But how is that any different than any web app target you might be able to test? Let’s get into that.

Why hacking APIs is so lucrative

According to Akamai research, 83% of all web traffic is now API calls.

Digital experiences are driven by APIs. Developers are accessing more data from external sources from within their software and bad actors are taking notice.

And that makes sense. APIs are designed for machine-to-machine communications. They are stateless and typically use tokens to validate requests. This makes API calls easy to replicate, manipulate, and exploit. And more importantly, traditional appsec vulnerability scanners simply aren’t up to the task of finding API security issues this way.

Why typical appsec scanners don’t work

If you listen to the marketing of appsec vendors, they can enable developers to find security issues in their code by having their static application security testing (SAST) tools piece together how the app runs and how the data flows work. But these tools often miss more complex vulnerabilities (or worse yet report false negatives) because they simply cannot trace the depth and complexity of API execution and remote calls, varying object encoding, and object property validation. Even if the SAST tool can consume an OpenAPI specification document, it’s rare that the documentation is up to date and properly maps the data schema and response codes clearly enough to be able to trace the API calls end to end. Especially if developers implement 3rd party APIs that are foreign to the codebase.

Remember, APIs typically use JSON and/or XML objects to represent data that is (de)serialized differently based on the language, platform, and framework. By the time new API attacks are understood and vendors adapt to support any given framework, it’s already moving into a legacy state.

Of course, some of these vendors will say they solve this through dynamic application security testing (DAST). By sending active HTTP requests containing attacks and monitoring the responses back from the server, they can detect clear evidence of a vulnerability if it succeeds. The problem here is that in API attacks, you can’t be sure if an error response code from the server relates to a common attack pattern being tripped upon or if the API endpoint just broke.

What’s worse here is that most DAST tools simply can’t invoke API endpoints because there is no easy way for them to know how to generate well-formed requests and then tamper with the payload data to manipulate the business logic to cause failure. Even if they can consume the API documentation to understand the data schema, they simply can’t know how the API is going to respond. This is why DAST tools like BurpSuite’s active scanner or OWASP ZAP can’t usually find critical vulnerabilities in the APIs it does detect.

A real world example – The Optus Data Breach

In 2022, the telecommunications company Optus suffered a data breach that exposed the personally identifiable information of over 9.8 million customers. Some say it was one of the worst data breaches ever reported in Australia, exposing about 40% of the country’s population to risk.

The breach occurred due to several vulnerabilities in an API of Optus’ customer management system, which allowed unauthorized access to customer data. The API in question had no authorization protection on the endpoint, used predictable incrementing customer IDs, and was directly accessible from the Internet.

The attackers exploited this to gain access to customer names, addresses, phone numbers, email addresses, and dates of birth. Additionally, around 2.1 million customers had their driver’s licenses and/or passport details exposed in the breach.

The Optus data breach serves as a reminder of the importance of proper cybersecurity measures, particularly in industries that handle sensitive customer information. They HAD vulnerability scanning tools in-house. But they didn’t catch these security issues and sensitive data was exposed.

It also highlights the need for regular pentesting of API software and systems that are actually deployed.

What’s interesting in the OPTUS breach is that all of the API attacks fall under some of the top API vulnerability classes defined in the OWASP API Security Top 10:

• API1:2019 Broken Object Level Authorization – The fact the attackers could predictably guess each customer ID and access it directly even though they shouldn’t be able to demonstrate BOLA
• API3:2019 Excessive Data Exposure – Why the API did not properly encrypt sensitive information like PII and expose it all in the data objects for the endpoint shows too much data was being exposed when it wasn’t necessary.
• API4:2019 Lack of Resources & Rate Limiting – The fact the attackers could dump almost 10 million records from the system without alarm bells going off signals a potential lack of resource & rate limiting.

This is just one example. Every month the news is littered with stories about organizations that don’t protect APIs that consumers are relying on. In fact, according to some reports, most enterprise IT practitioners do not feel completely confident in their organization’s ability to reduce API security issues such as unauthorized access, data privacy, compliance risk, and security threats.

Yet these same organizations continue to adopt APIs at a staggering rate. Which is good for you as an API hacker.

Digital transformation projects drive API adoption

According to a report by Salt Labs (the research division of Salt Security), 59% of respondents now manage over 100 APIs, and 25% manage more than 500. And it just keeps growing. 27% of organizations are saying they have more than doubled their API count over the past year. Another quarter said their API numbers increased by 51%-100%.

This makes sense. Companies are leveraging APIs to deliver services that customers expect. Heck, there is always an app for that if you ask some developers. The rapid adoption means API security typically isn’t being built in, which is allowing attacks against the software as it’s a prime target for the most impactful access to business logic flaws and data.

And this is an opportunity for you.

Why API adoption is a great opportunity for API hackers

Let me share some other interesting stats from the Salt Labs report:

• 94% of respondents have experienced security problems in production APIs
• Only 19% are confident they have an accurate inventory of their APIs
• 48% update their API documentation less than twice a year, even though they deploy far more frequently than that.
• Only 18% of security teams are very confident they understand which APIs expose PII data
• Only 23% of the security teams believe their existing security approaches are effective at preventing API attacks

Let’s put this in perspective. APIs are getting hacked. Documentation is lacking and far behind the enormous amount of API endpoints that are being exposed by the apps and infrastructure being used. Companies aren’t confident they know where sensitive PII may be leaking and don’t believe they have a handle on the API security they need to defend against all these attacks.

Talk about a target-rich environment.

So, how can this be so lucrative for API hackers? Stop fretting about fighting over those low-severity bug bounties. Why chase down dozens of XSS issues on the front end when you can directly attack the backend and find those authorization issues or excessive data exposure leaks that typically have a much higher criticality rating?

Even better, why fret about bug bounties at all when you can offer a higher-value service that will pay you far more consistently and far more lucratively?

Instead of counting on the hit-and-miss of bug bounty programs to find these types of vulns, you can offer API pentesting services to help these businesses secure APIs by working with security teams to test their software regularly. Many organizations aren’t ready to have their own red teams in-house, which leaves a huge opportunity for API hackers to deliver value on a continuous or consistent basis.

This is what I do. I offer services to my clients to help them find and fix API vulnerabilities before their adversaries do. As I invest the time to learn about their environment, I work with their DevOps team to send me clear signals when a new API is released or an existing API is updated.

Gawd I love automated CICD pipelines and JIT event processing.

This lets me monitor their endpoints for changes and focus on the areas that are most at risk as they move APIs into staging environments. It costs them less than having FTE offensive security engineers on staff, and I get to decide when I work on testing their changes. It’s not time-boxed, and we have a clear definition of what is in scope to make sure I don’t waste time on areas I have no business accessing (yet).

The results? I don’t normally talk about money. But I can say with confidence I didn’t have nearly as much stress or work anywhere as hard as Ben or Wesley did. But I probably made more. And that included a nice week-long cruise to Alaska where I didn’t even open my laptop. In fact, here is what I was looking at last week:

I don’t say that to impress you but to impress upon you that everyone has their own way of getting there. Ben and Wesley can hack circles around me, there is no doubt. They find way more vulns than I do. But what I do find usually pays better. That’s the very nature of the lucrative economics of API hacking.

Conclusion

So, did I pick the right title? Hopefully, you can see why I chose lucrative and not ludicrous.

API adoption is only going to increase as businesses move their digital transformation initiatives forward. That means more APIs being exposed on the public Internet in need of pentesting services or bug bounty hunting. You don’t have to be a genius or work harder than everyone else to make this lucrative for yourself. All you need to do is invest time into understanding how your target works and then dive deep into the security of it knowing that if your adversaries get there first, it might cost your client much more than what they paid you testing it.

Like what you are reading? Then consider following my work and subscribing to the API Hacker Inner Circle newsletter.

The post The Lucrative Economics of API Hacking appeared first on Dana Epp's Blog.

*** This is a Security Bloggers Network syndicated blog from Dana Epp's Blog authored by Dana Epp. Read the original post at: https://danaepp.com/the-lucrative-economics-of-api-hacking