I’m an API Hacker and Here’s How I Hack Everything from the Military to AI

I’m an API Hacker and Here’s How I Hack Everything from the Military to AI

Speakers: Katie, API Security Researcher, Technical Marketing at Traceable, YouTuber (Insider PhD)

Conference: RSAC 2024

YouTube: https://www.youtube.com/watch?v=9kSBsyLgFgY

Overview

In this candid and insightful talk, Katie, known online as Insider PhD, demystifies the world of API hacking, arguing that its perceived complexity is largely a myth. Far from requiring elite technical prowess or sophisticated zero-day exploits, she contends that the vast majority of impactful API vulnerabilities stem from "silly mistakes" and fundamental business logic flaws. Katie, an API security researcher and technical marketer at Traceable, shares her journey and demonstrates through real-world examples how she has uncovered critical vulnerabilities in systems ranging from military-affiliated applications to modern AI platforms, often with surprisingly little effort.

The talk challenges the conventional image of a hacker, positioning Katie as an "idiot" or "grandma" when it comes to highly technical exploits, yet highly effective due to her developer background and focus on application logic. This perspective is crucial because it highlights a pervasive blind spot in modern software security: the human element of oversight and flawed assumptions in development. By exposing these common pitfalls, the presentation serves as a powerful call to action for both developers and security professionals to re-evaluate their approach to API security, emphasizing collaboration, cultural shifts, and a renewed focus on foundational principles rather than an endless pursuit of advanced attack techniques.

Background

▶ Watch: API hacking is easy: just silly mistakes (0:00)

Katie's journey into cybersecurity was, by her own admission, largely accidental. Starting her career at the tender age of seven, building Neopets websites, she harbored an early passion for web development. This led her to pursue a Bachelor's degree in Computer Science, followed by what she describes as a period of job dissatisfaction that unexpectedly steered her towards a PhD in cybersecurity. Despite entering the field with minimal practical security knowledge – having never even heard of Burp Suite or seen an HTTP request in person – her developer's intuition proved to be her greatest asset.

Her breakthrough came at a HackerOne live hacking event where, leveraging her understanding of how APIs should be built, she found her first two vulnerabilities. She observed an API that adhered strictly to RESTful API standards, including the use of PUT or DELETE verbs, which she recognized as uncommon in real-world implementations. This deviation from typical, often messy, developer practices immediately signaled a potential flaw. Her comfort with JSON and an innate ability to "tune her brain into API hacking" by focusing on the application's logic rather than complex payloads or WAF bypasses became the cornerstone of her success. She emphasizes that API hacking is "not about specific payloads, necessarily. It's very much about thinking through the logic of an application." This fundamental insight forms the basis for understanding why many APIs are vulnerable: a large attack surface, hundreds of endpoints, and developers often cutting corners or misunderstanding security implications, leading to "a lot of little mistakes." Many developers, she points out, don't read RFCs (Requests for Comments) and often assume that undocumented APIs are inherently internal and therefore secure, a dangerous misconception.

Key Findings

▶ Watch: How developer knowledge led to first vulnerabilities (4:00)

Katie's central finding is that the most critical API vulnerabilities are not the result of sophisticated, cutting-edge exploits but rather stem from fundamental "tiny little mistakes" and business logic flaws. These issues, often overlooked by automated scanners and traditional penetration tests, can have catastrophic real-world impacts. She illustrates this through three compelling bug stories, each awarded a unique "competition prize."

Her "silliest bug," dubbed Take Off, involved an airport system designed to manage flyover requests. Instead of robust authentication, the system allowed users to access and edit critical runway information using only a last name. Katie discovered that by finding a last name associated with an airshow organizer (e.g., via LinkedIn), she could modify runway lengths. The potential impact was severe: altering runway specifications could lead to aircraft unable to land safely, resulting in fatalities. This vulnerability was a pure authorization bypass rooted in flawed application logic, not a technical exploit.

The "quickest bug," Quizzical, was found in a mobile quiz application within five minutes. Leveraging an Android emulator and Burp Suite to intercept traffic, Katie observed that the application, in an attempt to optimize network requests through batching, inadvertently sent the correct answers (isCorrect flag) along with the quiz questions in the same API response. This allowed her to easily determine the correct answer for every question, enabling an arbitrage opportunity to generate unlimited Amazon gift cards. Again, the flaw was in the application's logic and data handling, not a complex technical vulnerability.

Her "most complex bug," Supply Chain, involved a GraphQL API utilizing a new multipart form specification. While GraphQL itself is often intimidating to hackers due to its unique query language, Katie approached it methodically. She googled "GraphQL multipart form" to understand the specification, then intentionally caused errors to identify the backend technology (Java). By knowing the Java server and the specific component (Jackson Databind), she could search for known CVEs and vulnerabilities related to that version. The "complexity" lay in the investigative process and understanding the underlying components, not in exploiting a novel flaw. This demonstrated how even seemingly complex API structures can be broken down using common security research techniques and public information.

Across all three examples, the recurring theme is the exploitation of logical flaws, misconfigurations, and developer oversight, rather than intricate technical vulnerabilities.

Technical Deep Dive

▶ Watch: API hacking: logic over complex payloads (4:50)

The core of Katie's technical analysis revolves around identifying the subtle yet critical errors that plague API development, often leading to severe security vulnerabilities. She highlights several common categories:

1. Missing Authentication and Authorization: The "Take Off" airport system bug exemplifies this. The API endpoint responsible for accessing and modifying runway data lacked proper authentication, relying solely on a last name for access. Furthermore, there was no robust authorization check to ensure the user modifying the data had the necessary permissions. This is a classic Broken Object Level Authorization (BOLA) or Broken Function Level Authorization (BFLA) issue, where an API exposes functionality without adequately verifying the user's right to perform that action.

1. Business Logic Flaws: The "Quizzical" quiz app demonstrates how seemingly innocuous design choices can create significant vulnerabilities. The use of batching, a common optimization technique where multiple requests are combined into a single larger one to reduce network overhead and battery drain on mobile devices, was implemented incorrectly. By including the isCorrect flag directly within the question data sent to the client, the application's core logic was flawed, allowing clients to "cheat" the system without any sophisticated bypasses. This type of flaw is notoriously difficult for automated scanners to detect because it often appears as valid application behavior.

1. Missing Middleware and Access Control Checks: Katie provides clear Laravel code examples to illustrate common developer mistakes.

• Missing Middleware: She shows an API endpoint for managing "grades" (/api/grades) that implements standard CRUD (Create, Read, Update, Delete) operations. The vulnerable code snippet directly exposes these operations. The secure version includes middleware auth, a crucial line that ensures a user is logged in before any of these API actions can be performed. This middleware acts as a gatekeeper, verifying authentication at the request level. The absence of this single line creates an unauthenticated API, allowing anyone to perform actions intended only for authenticated users. She notes this is common in critical infrastructure like car manufacturers, industrial IoT, and railways.
• Missing if Statements for Authorization: Another Laravel example demonstrates a deleteUser function. The vulnerable code deletes a user and associated data based on the user ID of the currently logged-in user. The secure version adds a simple if statement: if ($user->isAdmin()). This single line enforces an administrator-level authorization check, preventing regular users from deleting critical data. Without it, any logged-in user could potentially delete other users or even themselves, leading to data loss or denial-of-service.

1. Undocumented and Internal APIs: A significant contributing factor to API vulnerabilities is the developer's assumption that an API, if undocumented or intended for internal use, is inherently secure and won't be discovered or misused externally. This leads to lax security controls, as the "internal-only" mindset often bypasses rigorous authentication and authorization checks, making these endpoints prime targets once discovered.

1. The Vast and Complex API Attack Surface: Katie emphasizes the sheer scale of modern API environments. A typical large company can have "hundreds of endpoints," each supporting "at least four different things you can do on that endpoint." This leads to an exponential growth in the attack surface, creating countless opportunities for small mistakes to become critical vulnerabilities. This complexity, combined with the flexibility APIs offer developers, often results in a trade-off where security is inadvertently neglected.

1. Challenges with Automated Testing: Traditional security tools, including vulnerability scanners and WAFs, often struggle with these types of logic-based flaws. Katie humorously suggests that a good API wordlist is "the dictionary" because API endpoints can be named in countless ways, incorporating mixed languages, different pluralizations, and idiosyncratic conventions. This makes comprehensive automated discovery and testing of business logic flaws extremely difficult, if not impossible, relying instead on human intuition and understanding of application context.

1. GraphQL Specifics: While often perceived as more secure due to its structured nature, GraphQL APIs present their own challenges. Katie notes that their "scary syntax" and requirement for custom queries often deter general web hackers, creating a false sense of security. However, as her "Supply Chain" bug showed, even novel GraphQL specifications can introduce vulnerabilities, and the process of exploiting them often involves standard security research techniques like identifying underlying components (e.g., Jackson Databind) and searching for known CVEs.

In essence, Katie's technical deep dive reveals that API security is less about finding zero-day exploits and more about meticulous attention to detail in development, rigorous adherence to security best practices, and a deep understanding of application logic and potential misuse scenarios.

Demo / Proof of Concept

▶ Watch: Story of the 'silliest bug': airport system (6:30)

While Katie's talk did not feature live, interactive demonstrations, she provided detailed narratives of her real-world exploits, effectively serving as descriptions of her proof-of-concept (PoC) steps for each vulnerability. These accounts were sufficiently specific to convey how the vulnerabilities were identified and how they could be exploited.

For the Airports system (the "silliest bug"), the PoC involved:

1. Identifying an API endpoint that allowed access to airport and runway information.
2. Discovering that this endpoint only required a user's last name for access, bypassing conventional authentication.
3. Obtaining a relevant last name (e.g., from public sources like LinkedIn, targeting individuals involved in airshows).
4. Submitting a request with the obtained last name to retrieve sensitive runway data.
5. Crucially, discovering that the same endpoint (or a closely related one) also permitted editing this runway data. The PoC would be to actually modify the runway length to an unsafe value, demonstrating the direct impact on flight safety.

For the Quizzical mobile app (the "quickest bug"), the PoC involved:

1. Setting up an Android emulator and configuring a proxy tool like Burp Suite to intercept all network traffic from the mobile application.
2. Playing the quiz game while observing the API requests and responses in Burp Suite.
3. Noticing that the API response for quiz questions included a specific flag, isCorrect, which explicitly indicated the correct answer.
4. Understanding that this allowed trivial determination of the correct answer for every question.
5. The PoC would then involve automating the submission of correct answers to accumulate rewards (Amazon gift cards) without genuine knowledge or effort, demonstrating the arbitrage potential.

For the Supply Chain GraphQL API (the "most complex bug"), the PoC involved:

1. Intercepting a multipart form request being sent to a GraphQL endpoint.
2. Recognizing the unusual syntax for a GraphQL multipart form.
3. Using search engines (Google) to find the specific GraphQL multipart form specification on GitHub.
4. Intentionally causing errors in the API requests to trigger server-side error messages, which revealed the underlying server technology (Java) and potentially specific component versions.
5. Identifying the vulnerable Java component (e.g., Jackson Databind) and its version.
6. Searching public vulnerability databases (e.g., CVEs) for known exploits related to that specific component and version. The PoC would then involve crafting an exploit based on the identified CVE, if applicable, to demonstrate code execution or data manipulation.

In each case, Katie provided enough detail for a knowledgeable audience to understand the technical steps and the logical progression from discovery to potential exploitation, even without a live on-screen demonstration.

Defensive Implications

▶ Watch: Silliest bug: accessing airport data via last name (8:00)

Katie's talk culminates in a powerful set of defensive implications, emphasizing that securing APIs is not merely a technical challenge but a cultural and procedural one. She outlines several key strategies for organizations to mitigate these "silly mistakes":

1. Reward Security Bug Fixes, Not Just Features Shipped: A fundamental shift in developer incentives is paramount. Current agile methodologies often reward developers solely for completing sprint backlog items and shipping new features quickly. Katie argues that fixing security bugs must be given equal priority and recognition. If addressing vulnerabilities, even in third-party integrations like OpenAI, isn't rewarded, developers will continue to prioritize speed over security.

1. Disincentivize Speed and Corner-Cutting: While speed is important, it should not come at any cost. Organizations need to establish a culture where corner-cutting, especially regarding security, is actively discouraged. It's about finding a balance, aiming for "good enough" security that prevents major incidents, rather than an unachievable 100% secure code.

1. **Work With Developers and Their Flow:** Security teams should avoid becoming the "department of no." Instead, they must integrate security practices seamlessly into the developer's existing workflow. This means understanding developer pain points, using their language, and providing solutions that don't add significant friction. Katie's anecdote about her developer partner finding security conferences "stressful" highlights the existing antagonism that needs to be overcome.

1. Foster a Testing Culture: Katie firmly believes that "everybody in this room can find a vulnerability." Encouraging a broader testing culture, where even non-technical staff are taught to think like hackers, can uncover unique perspectives and overlooked flaws. Her experience teaching her artist mother to use Burp Suite demonstrates that with the right guidance, anyone can contribute to identifying security issues.

1. Build Pipelines (CI/CD and Process): Automate security as much as possible. This includes integrating security testing into CI/CD pipelines so that code is automatically scanned and tested before deployment. Beyond technical pipelines, establishing clear vulnerability management processes is crucial. If a vulnerability is found, it should automatically create a ticket in a developer's existing system (e.g., Jira) with the same priority as other tasks, making it easy for developers to address without needing to "care about security at all" in the initial discovery phase.

1. Increase Developer Awareness and Education: While avoiding overwhelming developers, subtle integration of security knowledge is effective. Recommending security-focused newsletters like API Security IO or blogs like Nordic APIs (which often "sneak security in") can raise awareness. Encouraging developers to "think like a hacker" (as advocated by Casey John Ellis) and offering opportunities to attend security-aware conferences can also help foster internal security advocates. Katie likens this to "hidden vegetable security" – subtly integrating security into what developers already consume.

By implementing these strategies, organizations can move beyond a reactive, product-centric approach to security and cultivate a proactive, integrated security posture that addresses the root causes of API vulnerabilities: human error and misaligned incentives.

Key Takeaways

• API hacking is primarily about logic, not complex exploits: The most impactful API vulnerabilities often stem from "silly mistakes" and business logic flaws, not sophisticated technical bypasses or zero-days.
• Developer incentives drive insecurity: Current agile development models that prioritize speed and feature delivery over security lead to corner-cutting and the introduction of fundamental flaws like missing authentication middleware or authorization checks.
• Small errors can have catastrophic impacts: Seemingly minor oversights, such as requiring only a last name for critical system access or bundling quiz answers with questions, can lead to real-world dangers (e.g., flight safety) or significant financial fraud.
• Automated tools have limitations: Traditional vulnerability scanners and WAFs struggle to detect business logic flaws and unique API naming conventions, necessitating human intuition and "thinking like a hacker."
• Security requires a cultural and procedural shift: Effective API security demands rewarding security bug fixes, integrating security seamlessly into developer workflows, fostering a broad testing culture, and automating security into CI/CD and vulnerability management pipelines.
• The API attack surface is vast and growing: The sheer number of endpoints and potential actions creates an exponentially large attack surface, making comprehensive security challenging but critical.

About the Speaker(s)

Katie, also known by her online persona Insider PhD, is an API security researcher and a prominent voice in the cybersecurity community. She currently works in technical marketing at Traceable, a company specializing in API security. With a significant online presence, she boasts over 80,000 subscribers on YouTube, where she shares her insights and experiences in hacking.

Katie's academic background includes a Bachelor's degree in Computer Science and a PhD in Cybersecurity. Her career path is unique, having started in web development (notably making Neopets websites at a young age) and transitioning into cybersecurity somewhat accidentally after realizing she "hated her job" as a developer. She identifies as British and embraces an unconventional approach to hacking, describing herself as "not like other hackers" and emphasizing logic and simple mistakes over highly technical exploits. Her philosophy is that anyone, regardless of technical background, can find vulnerabilities if they understand application logic.