That single idea — intercepting the boundary between user space and kernel space — is the whole game for kernel-level rootkits, and it’s the subject of a paper I keep coming back to: A Methodology to Detect and Characterize Kernel Level Rootkit Exploits Involving Redirection of the System Call Table, written by John Levine, Julian Grizzard, and Henry Owen at Georgia Tech’s School of Electrical and Computer Engineering. It’s an older paper, built and tested against Red Hat 8.0 running kernel 2.4.18-14, and it looks at rootkits like KNARK, SuckIT, and zk. But the underlying reasoning — trust the hardware, not the software, when you’re hunting for a compromise — still holds up, and it’s worth walking through carefully, both on its own terms and against what Linux rootkits actually look like today.

What a Rootkit Actually Is (and Isn’t)

The paper opens with a definition worth restating because people get it wrong constantly: a rootkit does not get an attacker into a system. It keeps them in. A hacker needs root-level access before a rootkit can be installed. Once they have it, the rootkit’s job is to let them come back later without tripping any alarms, and to hide the evidence of their presence — files, processes, network connections — from the legitimate administrator.

The authors borrow a taxonomy from earlier work on Trojans by Thimbleby, Anderson, and Cairns, who split malicious masquerading software into four categories: direct masquerades (pretending to be a normal program), simple masquerades (pretending to be a plausible program that doesn’t actually exist), slip masquerades (using a name close enough to an existing one to fool a quick glance), and environmental masquerades (already-running processes that a user wouldn’t easily recognize as foreign). Kernel rootkits fall squarely into the first category — a trojanized version of a real system function, standing in for the original.

The Kernel Is the Real Target

Traditional binary rootkits swap out user-space utilities like ls, ps, or netstat with trojanized versions that lie about their output. That’s detectable, in principle, by comparing file hashes or checksums against a known-good baseline — which is exactly what file integrity checkers like Tripwire and AIDE were built to do.

Kernel-level rootkits sidestep that defense entirely by attacking a layer below any user-space binary: the system call table. Every request an application makes to the kernel — read a file, fork a process, allocate memory — goes through a system call, or sys_call. The kernel keeps a table of addresses in memory, one per system call, pointing to the actual function that handles the request. If an attacker can quietly redirect entries in that table, they control what the kernel tells every application on the system, without touching a single file that a checksum tool would notice.

flowchart LR
    A[User Application] -->|"sys_call(#N)"| B[System Call Table]
    B -->|normal system| C[sys_fork / sys_read / sys_execve ...]
    B -->|"rootkit redirects entry #N"| D[Attacker's Replacement Function]
    D -->|filters output, hides files/PIDs| E[Falsified Result Returned]
    C -->|honest result| F[Real Result Returned]

The paper describes two distinct techniques attackers used to pull this off on Linux 2.4:

1. Modifying individual entries in the system call table. A Loadable Kernel Module (LKM) — a legitimate Linux feature for extending kernel functionality at runtime without recompiling — is repurposed to overwrite selected addresses in the existing system call table with pointers to the attacker’s own functions. The table itself stays where it always was; only specific entries inside it point somewhere new. KNARK, released by CREED in 2001, is the paper’s example of this style.

2. Redirecting the entire system call table to a new location. This is subtler. Rather than editing the original table in place, the rootkit builds a brand-new table somewhere else in kernel memory — containing a mix of the attacker’s malicious replacements and the original, untouched addresses for anything it doesn’t care about — and then overwrites the pointer that the kernel uses to find the table in the first place. One way to do this on the target systems studied is by writing directly to /dev/kmem, the device file that exposes raw kernel memory. Crucially, this method leaves the original system call table completely intact. Anyone who checks the original table for tampering finds nothing wrong, because the kernel isn’t even looking at that table anymore.

Why This Beats Traditional Detection

That second technique is why kernel rootkits were such a headache for the tools available at the time. The paper walks through a live comparison, and it’s a genuinely useful case study in how a defense-in-depth mindset can still fail against the right attacker.

They tested a Red Hat 8.0 system, first clean, then infected with the SuckIT rootkit — a program developed by “sd” and “devik,” documented in Phrack 58, notable for patching the kernel on the fly without needing LKM support at all. Three detection tools were run against the infected system:

• chkrootkit, a signature-based shell script that checks system binaries and looks for known rootkit fingerprints, failed to detect SuckIT while it was actively running. It only caught traces of the rootkit after it had been uninstalled, because SuckIT’s file-hiding trick (renaming the real /sbin/init to a hidden filename and quietly substituting a lookalike) evaporated the moment the rootkit removed itself.
• AIDE (Advanced Intrusion Detection Environment), a file-integrity checker, noticed that attributes on /sbin/telinit had changed — but had no way to explain why, and gave no indication that the kernel itself, or the system call table, had been compromised. That’s the structural limit of any checksum-based tool: it tells you that something changed, never what kind of something.
• kern_check, a small Samhain Labs utility built specifically to compare the live system call table against the /boot/System.map file generated at kernel compile time, also missed SuckIT entirely — because SuckIT redirects the table pointer rather than editing the original table, and Samhain Labs themselves acknowledged the tool wasn’t built to catch that.

None of the three tools available at the time could reliably say “this system has a kernel rootkit, and here specifically is how it works.” That gap is exactly what the paper set out to close.

Querying the Hardware Instead of Trusting the OS

The methodology’s central trick is elegant: instead of asking the (possibly compromised) kernel where its own system call table lives, ask the CPU directly.

Every x86 system call passes through a specific interrupt — int $0x80 — and the processor’s Interrupt Descriptor Table (IDT) holds the true address of the routine that handles it. That IDT entry points to the system_call() function, and buried inside that function’s disassembled machine code is an indirect call instruction: call *sys_call_table(,%eax,4). That instruction contains, as literal encoded bytes, the actual address the kernel is using right now to look up system calls — regardless of what any file on disk claims that address should be.

The authors use the sidt x86 assembly instruction (the same trick SuckIT itself uses internally) to retrieve the IDT, walk to the system_call() entry point, and extract the operand of that call instruction directly from live kernel memory. That gives them the address the CPU is genuinely dereferencing on every system call — a ground truth that no amount of table redirection can hide, because the rootkit still has to funnel every syscall through this exact instruction to keep the system functioning normally.

sequenceDiagram
    participant CPU as CPU / IDT
    participant SC as system_call() function
    participant SCT as Live System Call Table
    participant Map as /boot/System.map

    Note over CPU: sidt retrieves IDT base
    CPU->>SC: Locate system_call() entry point
    SC->>SCT: Extract address from<br/>"call *sys_call_table(,%eax,4)"
    Note over SCT: This is the address<br/>the kernel actually uses
    SCT->>Map: Compare against compiled-in address
    alt Addresses match, but individual entries differ
        Note over Map: Rootkit modifies table in place
    else Addresses do not match at all
        Note over Map: Rootkit redirects to new table
    end

Once that live address is in hand, it gets compared against the address recorded in /boot/System.map, the symbol map generated when the kernel was originally compiled. The comparison produces one of two diagnostic outcomes:

• If the retrieved address matches /boot/System.map, but individual entries within the table point somewhere unexpected — a rootkit is modifying the original system call table in place (the KNARK-style attack).
• If the retrieved address does not match /boot/System.map at all — the entire table has been redirected to a new location in kernel memory (the SuckIT-style attack).

Either way, the analyst now knows not just that the system is compromised, but which class of kernel rootkit is responsible. The authors modified Samhain’s original kern_check utility to implement this comparison and ran it against a SuckIT-infected system, correctly flagging 25 redirected system calls and reporting the new table’s address in kernel memory — a result the original, unmodified kern_check was structurally incapable of producing.

A Mathematical Framework for “Is This the Same Rootkit?”

Detecting a compromise is only half the paper’s contribution. The other half is a framework for answering a more subtle question: once you’ve found a rootkit, is it one you’ve already seen, a modified version of one you’ve seen, or something genuinely new?

The authors build this on set theory. Let $p_1$ be the set of original, legitimate programs, and $p_2$ be the malicious replacement installed by the rootkit. Because a functioning rootkit must preserve all of the original program’s behavior while adding its own hidden capabilities, $p_1$ is necessarily a proper subset of $p_2$:

$$p_1 \subset p_2, \quad \text{since } p_1 \subseteq p_2 \text{ and } p_1 \neq p_2$$

The interesting object is the delta, written $\nabla$ — the set of elements present in $p_2$ but absent from $p_1$:

$$p_2 \setminus p_1 = p’ = \nabla$$

$\nabla$ is effectively the rootkit’s fingerprint: the specific added functionality — new hooked syscalls, backdoor triggers, hidden PID logic — that distinguishes the trojanized program from the legitimate one it’s impersonating. Once you have a $\nabla$ for a known rootkit, you can classify any newly discovered suspect $p_3$ against it:

• If $p_3 – (\nabla \cap p_3) = p_1$, then $p_3$ contains exactly the same added elements as the known rootkit — it’s the same exploit.
• If some but not all elements of $\nabla$ appear in $p_3$ (written $\nabla \in p_3$), it’s a modification of the known rootkit.
• If none of $\nabla$’s elements appear in $p_3$ (written $\nabla \notin p_3$), it’s classified as an entirely new rootkit.

The paper puts this to work on a genuinely interesting comparison: SuckIT versus a related rootkit called zk, whose own documentation admits it borrowed SuckIT’s kernel-patching approach. Running the modified kern_check against a zk-infected system showed the exact same 25 system calls being subverted as SuckIT — strong evidence of shared lineage. But zk’s uninstall command failed where SuckIT’s succeeded, which was the first real behavioral $\nabla$ between the two. Digging into zk’s source with grep for the string "password" turned up a hardcoded uninstall password — "kill me" — buried in client.c, something SuckIT’s own equivalent file didn’t contain. That password became a usable signature for identifying zk specifically, separate from SuckIT, even though the two share the bulk of their kernel-patching mechanics.

Why the System Call Table Method Eventually Stopped Being Enough

The paper is honest about its own limits, and reading it today, those limits map almost exactly onto how the Linux kernel evolved afterward. The authors note that kern_check already failed against the Linux 2.6 kernel, because 2.6 stopped exporting the system call table’s address via query_module specifically to prevent race conditions during dynamic replacement of syscall addresses by loadable modules. That single kernel change quietly broke an entire generation of detection tools built around comparing exported symbols.

That trajectory has continued for two decades. Direct writes to /dev/kmem — the technique SuckIT relied on — have been closed off entirely on modern Linux; /dev/kmem was removed from the mainline kernel years ago, and /dev/mem access to general kernel memory is restricted by CONFIG_STRICT_DEVMEM. Kernel module signing, Secure Boot chains, and Linux Security Modules make an unsigned, unverified LKM far louder and harder to load quietly than it was in 2003. According to recent security research from Elastic Security Labs, classic syscall-table-hooking LKM rootkits like Diamorphine (2016) and Reptile (2020) are still found in the wild — but attackers increasingly treat raw syscall table overwrites as a last resort rather than a first move, precisely because that technique is now well-instrumented and reliably flagged by tainted-kernel checks, /proc/modules auditing, and specialized LKM scanners.

Where the field has actually moved is toward attacking legitimate kernel instrumentation frameworks instead of the syscall table directly. eBPF — originally built for safe, verified packet filtering and performance tracing — lets a program attach to kprobes, tracepoints, and LSM hooks without loading a kernel module at all, which sidesteps module-signing defenses entirely. Rootkits such as PUMAKIT (documented in late 2024) and a 2025 in-the-wild implant called LinkPro use eBPF programs to intercept calls like getdents (to hide files and processes) and even to hide their own eBPF programs from introspection via sys_bpf. Some go further still, abusing io_uring — the asynchronous I/O interface introduced in Linux 5.1 — to batch operations in ways that generate almost no observable syscall events at all, which is what an experimental 2025 proof-of-concept called RingReaper demonstrated against tools that assume syscall-level tracing catches everything. And on the defensive side, a late-2025 ScienceDirect paper on a system called HKRD proposes using eBPF itself, defensively, to validate syscall table addresses continuously and catch direct kernel object manipulation — essentially the same “check the live address against the true one” instinct from the Georgia Tech paper, reimplemented with a modern, verifier-checked kernel framework instead of raw /dev/kmem access.

The throughline across all of this — 2004 to 2026 — hasn’t actually changed: a kernel rootkit has to funnel legitimate operations through some interception point to hide anything, and that interception point, however cleverly hidden, has to be reachable at the hardware or kernel-instrumentation level by anyone willing to go around the operating system’s own reporting mechanisms rather than trust them. What’s changed is which interception point attackers use, and how much cover modern kernel instrumentation gives them while doing it.

Practical Takeaways for Anyone Doing This Kind of Work Today

A few lessons from this paper are worth carrying forward regardless of which kernel version or hooking technique is in play:

• File integrity checkers tell you something changed, not what changed it. AIDE flagging /sbin/telinit in the paper’s SuckIT test is a perfect illustration — true, useful, and completely insufficient on its own. Pairing integrity monitoring with something that inspects live kernel state (or, today, host-based eBPF telemetry from tools designed for exactly this) closes that gap.
• Signature-based scanners are only as good as their signature database, and rootkits actively exploit that fact. chkrootkit missing SuckIT while it was running, then catching it only after uninstall, is a direct consequence of a rootkit author designing specifically around a known detector’s blind spots. The same dynamic plays out today between eBPF-based rootkits and eBPF-naive monitoring stacks.
• Prefer ground truth from hardware or a verified low-level source over anything the OS chooses to report. Querying the IDT directly, rather than trusting query_module or a userland utility, is the same instinct behind modern memory forensics approaches that read kernel structures out of a raw memory image rather than trusting a live, possibly-compromised OS to describe itself accurately.
• Behavioral deltas are durable signatures even when byte-level signatures aren’t. The zk-versus-SuckIT comparison in this paper — spotting a hardcoded password difference through source review rather than a static hash match — is conceptually close to the API-call-sequence approach used in behavior-based malware detection more broadly. If you’re comparing binaries for common ancestry, tools like hashdeep are a fast first pass for flagging exact matches, but genuine lineage analysis — the $\nabla$ concept from this paper — usually needs a deeper look with something like Autopsy or manual source-level review, exactly as the authors did when they grepped client.c for the string that gave zk away.
• Registry and configuration hive artifacts matter on the Windows side of this same problem. Kernel-mode rootkit concealment isn’t a Linux-only concern, and when an incident spans a mixed environment, offline artifact review — the same philosophy behind tools like chntpw for pulling data out of a Windows registry hive without trusting a live, possibly-compromised OS to hand it over honestly — follows the identical logic as querying the IDT instead of query_module: don’t ask a system that might be lying to describe itself.

Closing Thought

What makes this paper worth reading in 2026 isn’t the specific tools it built — kern_check for the 2.4 kernel is a historical artifact at this point, and neither SuckIT nor zk pose any real threat to a modern, signed, lockdown-mode kernel. What’s worth keeping is the underlying discipline: when you suspect a rootkit, don’t ask the operating system to grade its own homework. Find the one piece of ground truth the attacker cannot fake without breaking the very functionality they’re trying to preserve, and check that instead. Twenty years on, whether the interception point is a syscall table pointer, an eBPF program hooked into getdents, or a batch of disguised io_uring operations, that’s still the only reliable way to catch something that was specifically engineered to lie to you.

Reference

Levine, J., Grizzard, J., & Owen, H. (2004). A Methodology to Detect and Characterize Kernel Level Rootkit Exploits Involving Redirection of the System Call Table. School of Electrical and Computer Engineering, Georgia Institute of Technology.

The post Detecting Kernel-Level Rootkits Through System Call Table Redirection: A Look Back at a Foundational Methodology appeared first on Abdul Wahab Junaid.

Start With the Right Scope

The single biggest mistake I see is trying to threat model an entire complex system in one sitting. Scope sessions narrowly — a single service, a single new feature, a single significant architecture change. A focused thirty-minute session on one component produces more actionable output than a sprawling three-hour session trying to cover everything at once.

Build a Simple, Accurate Data Flow Diagram First

Every effective threat modeling session I’ve run started with a diagram, even a rough one drawn on a whiteboard: what are the components, where does data enter and exit, where are the trust boundaries. Skipping this step and jumping straight to “what could go wrong” tends to produce a scattered, incomplete list rather than a systematic one.

flowchart LR
    U[External User] -->|HTTPS| GW[API Gateway]
    GW -->|Auth check| AS[Auth Service]
    GW -->|Request| BE[Backend Service]
    BE -->|Query| DB[(Database)]
    BE -->|Call| EXT[Third-Party API]

Even a simple diagram like this immediately surfaces trust boundaries worth examining: the external user to gateway boundary, the backend to third-party API boundary, and the backend to database boundary each deserve their own focused threat analysis.

Involve the People Who Actually Build the System

Threat modeling run exclusively by a security team, disconnected from the engineers who wrote the code, consistently misses edge cases that only the implementers know about. The best sessions I’ve been part of had developers actively contributing — they know where the corners were cut, which third-party library behaves unpredictably, and which “temporary” workaround has quietly become permanent infrastructure.

Use a Consistent, Repeatable Methodology

Whether you choose STRIDE for fast, component-level analysis or PASTA for a deeper, risk-centric process on high-stakes systems, consistency matters more than which specific framework you pick. A team that reliably applies the same lightweight process every sprint will catch more real threats than a team that occasionally attempts an exhaustive process and then abandons it under deadline pressure.

Prioritize by Realistic Likelihood and Impact, Not Just Severity

Not every identified threat deserves equal attention. A theoretical vulnerability requiring insider access and three chained conditions is a very different priority than a straightforward, remotely exploitable authentication bypass. Rank threats by a genuine combination of how likely they are to be exploited in your actual environment and how much damage they’d cause if they were.

Turn Findings Into Trackable Work

A threat model that lives only in a meeting’s notes changes nothing. Every significant threat identified should turn into a backlog item with an owner, a priority, and a due date — tracked the exact same way you’d track any other engineering work, not filed separately where it’s easy to forget.

Revisit the Model as the System Changes

Architecture drifts. New integrations get added, old ones get deprecated, authentication mechanisms change. A threat model from a year ago describing a system that no longer exists provides false confidence. Set a cadence — triggered by significant architecture changes, and backstopped by a regular quarterly review — to keep models current.

flowchart TD
    A[Initial threat model created] --> B[Mitigations tracked and implemented]
    B --> C[System in production]
    C --> D{Significant architecture change?}
    D -->|Yes| E[Targeted re-review of affected components]
    D -->|No| F[Scheduled quarterly review]
    E --> B
    F --> B

Ground Threats in Real Attacker Behavior

Abstract, hypothetical threats are easy to dismiss under deadline pressure. Threats grounded in real-world attack patterns — informed by actual incident reports, threat intelligence, and known techniques — carry far more weight in prioritization conversations. My guide to <a href=”https://awjunaid.com/ethical-hacking/extended-penetration-testing-cheatsheet/” target=”_blank” rel=”noopener”>penetration testing methodology</a> is a useful reference for understanding how attackers actually chain reconnaissance, exploitation, and post-exploitation steps together in practice, which helps make threat modeling scenarios concrete rather than abstract.

Don’t Over-Engineer the Process

I’ve seen teams build elaborate, heavyweight threat modeling processes that collapse under their own weight the first time a deadline gets tight. A lightweight process that actually happens consistently beats an ideal process that gets skipped whenever the team is busy — which is, unfortunately, most of the time.

Common Mistakes That Undermine Threat Modeling

1. Scoping sessions too broadly, trying to cover an entire system in one sitting.
2. Skipping the data flow diagram and jumping straight to brainstorming threats.
3. Running sessions without the actual developers who built or maintain the system.
4. Identifying threats but never tracking mitigations as real, prioritized work.
5. Treating the threat model as a one-time artifact rather than a living document.
6. Prioritizing purely by technical severity without considering realistic likelihood or business impact.
7. Choosing an overly heavyweight process that the team can’t sustain consistently.

Best Practices Checklist

• Scope each session to a single component, feature, or significant change.
• Always start with a simple, accurate data flow diagram.
• Involve developers, not just security specialists.
• Use a consistent methodology appropriate to the system’s risk level.
• Prioritize by realistic likelihood and business impact.
• Track every meaningful finding as backlog work with an owner.
• Revisit the model on both a triggered and scheduled cadence.
• Ground scenarios in real attacker behavior and threat intelligence where possible.
• Keep the process lightweight enough to actually happen consistently.

FAQs

How do I get buy-in from a team that sees threat modeling as a waste of time? Start with a small, focused session on a real, current feature rather than an abstract exercise, and make sure at least one identified threat turns into a visible, appreciated fix — a concrete win builds far more buy-in than a theoretical pitch.

Should threat modeling happen before or after code is written? Ideally before, at the design stage, since it’s far cheaper to address a threat in architecture than to refactor code after the fact. That said, retroactive threat modeling on existing systems is still valuable and often overdue.

How detailed does a data flow diagram need to be? Detailed enough to clearly show trust boundaries and major data flows — a rough whiteboard sketch is often sufficient; you don’t need a polished, comprehensive architecture diagram to get real value.

What’s a realistic cadence for revisiting threat models? Trigger a targeted review whenever a significant architecture change happens, and backstop that with a scheduled review — quarterly is a common, sustainable cadence for most teams.

Conclusion

The frameworks matter less than the habits. Scoping sessions narrowly, starting with an accurate diagram, involving the people who actually build the system, and turning findings into tracked work are what separate threat modeling that genuinely shapes what gets built from threat modeling that becomes an ignored document. Keep the process lightweight enough to survive contact with a real deadline, and it’ll earn its place as one of the highest-leverage habits a security-conscious engineering team can build.

The post Threat Modeling Best Practices appeared first on Abdul Wahab Junaid.

A bug bounty program is an initiative in which a company invites ethical hackers to attack its products and service offerings to find security vulnerabilities. But how should you pick a program? And how should you prioritize their different metrics, such as the asset types involved, whether the program is hosted on a platform, whether it’s public or private, the program’s scope, the payout amounts, and response times

The State of the Industry

Bug bounties are currently one of the most popular ways for organizations to receive feedback about security flaws. Large corporations, like PayPal and Facebook, as well as government agencies like the US Department of Defense, have all embraced the idea. Yet, not too long ago, reporting a vulnerability to a company would have more likely landed a person in legal trouble than gotten them a reward.

In 1995, Netscape launched the first-ever bug bounty program. The company encouraged users to report bugs found in its brand-new browser, the Netscape Navigator 2.0, introducing the idea of crowdsourced security testing to the internet world. Mozilla launched the next corporate bug bounty program nine years later, in 2004, inviting users to identify bugs in the Firefox browser.

But it was not until the 2010s that offering bug bounties became a popular practice. That year, Google launched its program, and Facebook followed suit in 2011. These two programs truly kick-started the trend of using bug bounties to augment a corporation’s in-house security infrastructure.

The Rise of Bug Bounty Platforms

As bug bounties became a more well-known strategy, bug-bounty-as-a-service platforms emerged. These platforms help companies set up and operate their programs. For example, they provide a place for companies to host their programs, a way to process reward payments, and a centralized place to communicate with bug bounty hunters.

The two largest of these platforms, HackerOne and Bugcrowd, both launched in 2012. Following them, a few more platforms, such as Synack, Cobalt, and Intigriti, came to the market. These platforms and managed bug bounty services allow even companies with limited resources to run a security program. Today, large corporations, small startups, nonprofits, and government agencies alike have adopted bug bounties as an additional security measure and a fundamental piece of their security policies.

The term security program usually refers to information security policies, procedures, guidelines, and standards in the larger information security industry. In the context of bug bounties, the term program or bug bounty program refers specifically to a company’s bug bounty operations.

Today, tons of programs exist, all with their unique characteristics, benefits, and drawbacks. Let’s examine these factors to help you make an informed choice.

Asset Types: Choosing Your Attack Surface

In the context of a bug bounty program, an asset is an application, website, or product that a hacker can target. There are different types of assets, each with its own characteristics, requirements, and pros and cons. After considering these differences, you should choose a program with assets that play to your strengths, based on your skill set, experience level, and preferences.

Social Sites and Applications

Anything labeled social has a lot of potential for vulnerabilities because these applications tend to be complex and involve a lot of interaction among users, and between the user and the server. This first type of bug bounty program targets social websites and applications.

The term social application refers to any site that allows users to interact with each other. Many programs belong to this category: examples include the bug bounty program for HackerOne and programs for Facebook, Twitter, GitHub, and LINE.

• Vulnerability Potential: Social applications need to manage interactions among users, as well as each user’s roles, privileges, and account integrity. They are typically full of potential for critical web vulnerabilities such as:
  • Insecure Direct Object References (IDORs)
  • Information Leaks (Info leaks)
  • Account Takeovers
  These vulnerabilities often occur when many users are on a platform and when applications mismanage user information or when the application does not validate a user’s identity properly, allowing malicious users to assume the identity of others.
• Injection Flaws: These complex applications also often provide a lot of user input opportunities. If input validation is not performed properly, these applications are prone to injection bugs, like SQL Injection (SQLi) or Cross-Site Scripting (XSS).
• Recommendation for Beginners: If you are a newcomer to bug bounties, it is highly recommended that you start with social sites. The large number of social applications means you’ll have many programs to choose from. The complex nature of social sites means you’ll encounter a vast attack surface (all of the application’s different points that an attacker can attempt to exploit) with which to experiment. Finally, the diverse range of vulnerabilities that show up on these sites means you will be able to quickly build a deep knowledge of web security.
• Skill Set: The skills needed include the ability to use a proxy, like the Burp Suite proxy, and knowledge about web vulnerabilities such as XSS and IDOR. It’s also helpful to have some JavaScript programming skills and knowledge about web development. However, these skills aren’t strictly required to succeed as a hacker.
• Major Downside: Because of the popularity of their products and the low barrier of entry, social programs are often very competitive and have many hackers hunting on them. Social media platforms such as Facebook and Twitter are some of the most targeted programs.

General Web Applications

General web applications are also a good target for beginners. This category refers to any web applications that do not involve user-to-user interaction. Instead, users interact with the server to access the application’s features. Targets that fall into these categories can include static websites, cloud applications, consumer services like banking sites, and web portals of Internet of Things (IoT) devices or other connected hardware. Like social sites, they are also quite diverse and lend themselves well to a variety of skill levels. Examples include the programs for Google, the US Department of Defense, and Credit Karma.

• Level of Difficulty: In general, these tend to be a little more difficult to hack than social applications, and their attack surface is often smaller. If you’re looking for account takeovers and info leak vulnerabilities, you won’t have as much luck because there aren’t many opportunities for users to interact with others and potentially steal their information.
• Vulnerability Focus: The types of bugs you’ll find are slightly different. You’ll need to look for server-side vulnerabilities and vulnerabilities specific to the application’s technology stack. You could also look for commonly found network vulnerabilities, like subdomain takeovers.
• Skill Set: This means you’ll have to know about both client-side and server-side web vulnerabilities, and you should have the ability to use a proxy. It’s also helpful to have some knowledge about web development and programming.
• Accessibility: These programs can range in popularity. However, most of them have a low barrier of entry, so you can most likely get started hacking right away!

Mobile Applications (Android, iOS, and Windows)

After you get the hang of hacking web applications, you may choose to specialize in mobile applications. Mobile programs are becoming prevalent, as most web apps have a mobile equivalent nowadays. They include programs for Facebook Messenger, the Twitter app, the LINE mobile app, the Yelp app, and the Gmail app.

• Required Knowledge: Hacking mobile applications requires the skill set you’ve built from hacking web applications, as well as additional knowledge about the structure of mobile apps and programming techniques related to the platform. You should understand attacks and analysis strategies like:
  • Certificate Pinning Bypass
  • Mobile Reverse Engineering
  • Cryptography
• Setup Requirements: Hacking mobile applications also requires a little more setup than hacking web applications, as you’ll need to own a mobile device you can experiment on. A good mobile testing lab consists of a regular device, a rooted device (one for which you have admin privileges, allowing you to bypass mobile system’s safety constraints), and device emulators (virtual simulations of mobile environments run on your computer) for both Android and iOS.
• Competition: For these reasons, mobile applications are less popular among bug bounty hunters than web applications. However, the higher barrier of entry for mobile programs is an advantage for those who do participate, as these programs are less competitive, making it relatively easy to find bugs.

APIs

Application Programming Interfaces (APIs) are specifications that define how other applications can interact with an organization’s assets, such as to retrieve or alter their data. For example, another application might be able to retrieve an application’s data via HyperText Transfer Protocol (HTTP) messages to a certain endpoint, and the application will return data in the format of Extensible Markup Language (XML) or JavaScript Object Notation (JSON) messages.

• Focus Areas: Some programs put a heightened focus on API bugs in their bug bounty programs if they’re rolling out a new version of their API. A secure API implementation is key to preventing data breaches and protecting customer data. When testing APIs, you should focus on common API bugs like data leaks and injection flaws.
• Skill Set: Hacking APIs requires many of the same skills as hacking web applications, mobile applications, and IoT applications.

Source Code and Executables

If you have more advanced programming and reversing skills, you can give source code and executable programs a try. These programs encourage hackers to find vulnerabilities in an organization’s software by directly providing hackers with an open source codebase or the binary executable. Examples include the Internet Bug Bounty, the program for the PHP language, and the WordPress program.

• Hacking Methods: Hacking these programs can entail analyzing the source code of open source projects for web vulnerabilities and fuzzing binaries (testing software with massive amounts of unexpected or malformed inputs) for potential exploits.
• Required Skills: You usually have to understand coding and computer science concepts to be successful here. You’ll need knowledge of web vulnerabilities, programming skills related to the project’s codebase, and code analysis skills. Cryptography, software development, and reverse engineering skills are also helpful.
• Competition: Source code programs may sound intimidating, but they are diverse, offering many choices. Because these programs tend to require more skills, they are less competitive, and only a small proportion of hackers will ever attempt them.

Hardware and IoT

Last but not least are hardware and IoT (Internet of Things) programs. These programs ask you to hack devices like cars, smart televisions, and thermostats. Examples include the bug bounty programs of Tesla and Ford Motor Company.

• Specialized Skills: You’ll need highly specific skills to hack these programs: you’ll often have to acquire a deep familiarity with the type of device you’re hacking, in addition to understanding common IoT vulnerabilities. You should know about:
  • Web vulnerabilities
  • Programming
  • Code analysis
  • Reverse engineering
  • IoT concepts and industry standards such as digital signing and asymmetric encryption schemes
  • Cryptography, wireless hacking, and software development skills
• Barrier to Entry: Although some programs will provide you with a free device to hack, that often applies only to select hackers who’ve already established a relationship with the company. To begin hacking on these programs, you might need the funds to acquire the device on your own.
• Competition: Since these programs require specialized skills and often a device, they tend to be the least competitive.

Bug Bounty Platforms vs. Independently Hosted Programs

Companies can host bug bounty programs in two ways: through bug bounty platforms and on independently hosted websites.

• Bug Bounty Platforms: These are websites through which many companies host their programs. Usually, the platform directly awards hackers with reputation points and money for their results. Some of the largest bug bounty platforms are HackerOne, Bugcrowd, Intigriti, Synack, and Cobalt.
  • Platform Function: Bug bounty platforms act as an intermediary between hackers and security teams. They provide companies with logistical assistance for tasks like payment and communication. They also often offer help managing incoming reports by filtering, deduplicating, and triaging (the confirmation of vulnerability) bug reports. Finally, these platforms provide a way for companies to gauge a hacker’s skill level via statistics and reputation, allowing them to invite experienced hackers to their private programs. Some of these platforms also screen or interview hackers before allowing them to participate.
• Independently Hosted Programs: Many organizations host and manage their bug bounty programs without the help of platforms. Companies like Google, Facebook, Apple, and Medium do this. You can find their bug bounty policy pages by visiting their websites, or by searching “CompanyName bug bounty program” online.

As a bug bounty hunter, should you hack on a bug bounty platform, or should you go for companies’ independently hosted programs?

The Pros of Platforms

• Transparency: The best thing about bug bounty platforms is that they provide a lot of transparency into a company’s process, because they post disclosed reports, metrics about the programs’ triage rates, payout amounts, and response times. Independently hosted programs often lack this type of transparency.
• Logistics: You won’t have to worry about the logistics of emailing security teams, following up on reports, and providing payment and tax information every time you submit a vulnerability report.
• Reputation System: Bug bounty platforms often have reputation systems that allow you to showcase your experience so you can gain access to invite-only bug bounty programs.
• Conflict Resolution: Another advantage of bug bounty platforms is that they often step in to provide conflict resolution and legal protection as a third party. If you submit a report to a non-platform program, you have no recourse in the final bounty decision.

The Cons of Platforms

• Triagers: Some hackers avoid bug bounty platforms because they dislike how those platforms deal with reports. Reports submitted to platform-managed bug bounty programs often get handled by triagers (third-party employees who often aren’t familiar with all the security details about a company’s product). Complaints about triagers handling reports improperly are common.
• Loss of Direct Connection: Programs on platforms often break the direct connection between hackers and developers. With a direct program, you often get to discuss the vulnerability with a company’s security engineers, making for a great learning experience.
• Crowding: Public programs on bug bounty platforms are often crowded because the platform gives them extra exposure. On the other hand, many privately hosted programs don’t get as much attention from hackers and are thus less competitive.

Other Key Metrics: Scope, Payouts, and Response Times

What other metrics should you consider when picking a program, besides its asset types and platform? On each bug bounty program’s page, metrics are often listed to help you assess the program. These metrics give insight into how easily you might be able to find bugs, how much you might get paid, and how well the program operates.

Program Scope

First, consider the scope. A program’s scope, specified on its policy pages, defines what and how you are allowed to hack. There are two types of scopes:

1. Asset Scope: Tells you which subdomains, products, and applications you can hack.
2. Vulnerability Scope: Specifies which vulnerabilities the company will accept as valid bugs.

Crucial Rule: Assets that are listed as in scope are the ones you are allowed to hack. Assets that are listed as out-of-scope are off-limits to bug bounty hunters. Be extra careful and abide by the rules! Hacking an out-of-scope asset is illegal.

Typical out-of-scope vulnerabilities include: Self-XSS, Clickjacking, Missing HTTP headers and other best practices without direct security impact, Denial-of-Service attacks, and Use of known-vulnerable libraries/automated scanner results without proof of exploitability.

• Recommendation: Any program with large asset and vulnerability scopes is a good place to start for a beginner. The larger the asset scope, the larger the number of target applications and web pages you can look at, and you can often find obscure applications that are overlooked by other hackers. This typically means less competition. The larger the vulnerability scope, the more types of bugs the organization is willing to hear reports about, making it easier to find bugs because you have more opportunities and can play to your strengths.

Payout Amounts

The next metric you should consider is the program’s payout amounts. There are two types of payment programs:

1. Vulnerability Disclosure Programs (VDPs): These are reputation-only programs, meaning they do not pay monetary rewards for findings but often offer rewards such as reputation points and swag.
   • VDP Benefits: They are a great way to learn about hacking if making money is not your primary objective. Since they don’t pay, they’re less competitive, and so easier to find bugs in. You can use them to practice finding common vulnerabilities and communicating with security engineers.
2. Bug Bounty Programs: These offer varying amounts of monetary rewards for your findings. In general, the more severe the vulnerability, the more the report will pay.

• Payout Structure: Different programs have different payout averages for each level of severity. You can find a program’s payout information on its bug bounty pages, usually listed in a section called the payout table. Typically, low-impact issues will pay anywhere from $50 to $500 (USD), while critical issues can pay upward of $10,000. The bug bounty industry is evolving, and payout amounts are increasing for high-impact bugs (e.g., Apple now rewards up to $1 million for the most severe vulnerabilities).

Response Time

Finally, consider the program’s average response time. Some companies will handle and resolve your reports within a few days, while others take weeks or even months to finalize their fixes. Delays often happen because of the security team’s internal constraints (lack of personnel, delay in issuing security patches, lack of funds) or because researchers have sent bad reports without clear reproduction steps.

• Recommendation: Prioritize programs with fast response times. Rapid feedback from security teams will help you improve, especially when starting, because you’re likely to make mistakes (misjudging severity, writing unclear explanations, technical mistakes). Fast feedback will turn you into a competent hacker faster.

Public vs. Private Programs

Most bug bounty platforms distinguish between public and private programs.

• Public Programs: These are open to all; anyone can hack and submit bugs to these programs, as long as they abide by the laws and the bug bounty program’s policies.
• Private Programs: These are open to only invited hackers. Companies ask hackers with a certain level of experience and a proven track record to attack the company and submit bugs to it.

The Advantage of Private Programs

Participating in private programs can be extremely advantageous.

• Less Competitive: Private programs are a lot less competitive than public ones because of the limited number of hackers participating. Therefore, it’s much easier to find bugs in them.
• Faster Response Time: Private programs also often have a much faster response time because they receive fewer reports on average.

How to Get Invited to Private Programs

Companies send private invites to hackers who have proven their abilities. Getting invites to private programs isn’t difficult once you’ve found a couple of bugs. Different bug bounty platforms will have different algorithms to determine who gets the invites, but here are some tips:

1. Submit Valid Bugs to Public Programs: To get private invites, you often need to gain a certain number of reputation points on a platform, and the only way to begin earning these is to submit valid bugs to public programs.
2. Focus on High-Impact Vulnerabilities: These vulnerabilities will often reward you with higher reputation points and help you get private invites faster.
3. Complete Platform Challenges: On some bug bounty platforms, like HackerOne, you can also get private invites by completing tutorials or solving Capture the Flag (CTF) challenges.
4. Do Not Spam: Submitting nonissues often causes a decrease in reputation points. Most bug bounty platforms limit private invites to hackers with points above a certain threshold.
5. Be Polite and Courteous: Be polite and courteous when communicating with security teams. Being rude or abusive will probably get you banned from the program and prevent you from getting private invites from other companies.

Choosing the Right Program for Success

Bug bounties are a great way to gain experience in cybersecurity and earn extra bucks. But the industry has been getting more competitive. As more people are discovering these programs and getting involved in hacking on them, it’s becoming increasingly difficult for beginners to get started. That’s why it’s important to pick a program that you can succeed in from the very start.

Before developing a bug hunter’s intuition, you often have to rely on low-hanging fruit and well-known techniques. This means many other hackers will be able to find the same bugs, often much faster than you can. It’s therefore a good idea to pick a program that more experienced bug hunters pass over to avoid competition. You can find these underpopulated programs in two ways:

1. Look for Unpaid Programs (VDPs): Try going for Vulnerability Disclosure Programs (VDPs) first. Unpaid programs are often ignored by experienced bug hunters, since they don’t pay monetary rewards. But they still earn you points and recognition, which might be just what you need to get an invite to a private, paid program.
2. Go for Programs with Big Scopes: Picking a program with a large scope means you’ll be able to look at a larger number of target applications and web pages. This dilutes the competition, as fewer hackers will report on any single asset or vulnerability type.

Remember to go for programs with fast response times to prevent frustration and get feedback as soon as possible.

One last thing that can be incorporated into your decision process is the reputation of the program. If you can, gather information about a company’s process through its disclosed reports and learn from other hackers’ experiences. Does the company treat its reporters well? Are they respectful and supportive? Do they help you learn? Pick programs that will be supportive while you are still learning, and programs that will reward you for the value that you provide.

Choosing the right program for your skill set is crucial if you want to break into the world of bug bounties. This guide should have helped you sort out the various programs that you might be interested in. Happy hacking!

A Quick Comparison of Popular Programs

After you’ve identified a few programs that you are interested in, you could list the properties of each one to compare them. Below, let’s compare a few of the popular programs.

The post Not All Bug Bounty Programs Are the Same: Finding Your Target appeared first on Abdul Wahab Junaid.

The core common theme for most of the vulnerabilities covered here is that they don’t have a clear, direct path to exploitation that affects a company or its users. They generally fall into categories where they either:

• Only affect the attacker (the security researcher).
• Require other (more serious) vulnerabilities to be present before they can be exploited.
• In the case of leaked information, don’t give an attacker any actionable information to launch a meaningful attack.

This detailed article will cover the specific vulnerabilities that companies often exclude from bug bounty programs, including how they work and, critically, why they’re often not covered. It will also highlight some of the common themes in what makes a bug ineligible for reward consideration.

System Requirements for Analysis

Since this discussion largely focuses on vulnerabilities that should be excluded from a typical testing workflow, the only tool needed is a standard web browser. For example, a version like Chrome version 66.0.3359.139 will suffice for examining the concepts discussed.

DoS/DDoS – The Denial-of-Service Problem

Denial-of-Service (DoS) and Distributed Denial-of-Service (DDoS) are familiar strains of cyberattack to anyone who follows security news. Flooding a target with traffic that is indistinguishable from a legitimate surge of visitors remains a popular method for either taking down or crippling a web property. This is especially potent when combined with amplification attacks (attacks that increase the volume of malicious traffic) caused by hijacking other servers, spoofing connected services, or taking advantage of an internal performance flaw or bottleneck.

In 2018, the software development platform GitHub was hit by what was, at the time, the largest DDoS attack ever recorded (a record that was quickly broken just five days later), clocking in at a saturation rate of about 1.3 TBps (terabytes per second). One reason the attackers were able to achieve such a high throughput was because they relied on commandeering unsecured Memcached database servers.

Memcached is a general-purpose distributed memory caching system, which stores data and objects in RAM to speed up dynamic web applications.

The attackers were able to spoof a query packet, making it look like the target server was asking for data from the Memcached server. In response, the Memcached server would then batter the target server with data up to 50,000 times the size of the spoofed request. This technique, known as a Memcached reflection attack, drastically amplifies the attack traffic. GitHub, in particular, has been repeatedly targeted, with this incident being just the latest in a sustained campaign against the site.

If you look at GitHub’s bug bounty program, you’ll notice they call out DDoS attacks specifically—stating clearly that they do not allow them:

Don’t perform any attack that could harm the reliability/integrity of our services or data. DDoS/spam attacks are not allowed. (emphasis theirs)

Why DoS/DDoS is Typically Out-of-Scope

The reason DoS/DDoS attacks are typically out-of-scope is simple: they are often not the result of anything the victim did wrong. The company didn’t miscode the application or leave a critical application-layer vector open. Defending against these attacks requires an entire proactive security architecture, which involves redistributing the load across different networks and intelligently throttling/isolating malicious sources of traffic—it’s a network defense problem, not an application vulnerability problem.

The exception is when a DoS/DDoS attack is made more effective because it can leverage a specific security flaw that exists on the victim’s network. If, as a security researcher, you come across, for example, an unsecured NTP server (Network Time Protocol) that could be hijacked to amplify a DDoS attack, you should certainly report it. This would be a vulnerability that could be used to threaten the company’s network or another bystander’s network.

Important Note: You should not try to validate any vulnerabilities like this by leveraging them for increased bot traffic, even if you believe the traffic falls below the threshold of something that could damage the target’s infrastructure. The fact that DDoS prohibitions are so common is a clear sign of how seriously they are taken by bounty program operators.

Sandboxed and Self-XSS – Low-Threat Cross-Site Scripting Varieties

Self-XSS (Self-Cross-Site Scripting) is a variety of XSS that relies heavily on social engineering, which is the primary reason it is excluded from most bug bounty programs. Sandboxed XSS, a similar term for a related strain, is typically used to describe an XSS vulnerability that happens on a machine that is isolated from sensitive user data or operations. Since Self-XSS refers to the specific phenomenon of executing code within your own browser environment to make yourself vulnerable to an XSS attack, it also means that your XSS bug is isolated in terms of what information it can access.

For Self-XSS to take place, the attacker must manipulate the victim into executing the malicious code within their own browser context. This manual execution by the victim is what makes them susceptible to further exploitation by the attacker.

A Simple Self-XSS Scenario

A simple example of self-XSS in action would be as follows:

1. An attacker advertises a “hacking-kit-in-a-box”—something like, “H4x0rs l18e 1337!” (a common piece of jargon known as leetspeak, meant to appeal to a gullible user). The advertisement tells the victim that all they have to do is copy a specific code snippet and paste it into the developer console of their browser.
2. The victim, perhaps beautifully gullible, happily copies the code and pastes it into their console, imagining the digital terror of their wrath upon the web.
3. Instead of hacking someone else, the code they pasted into their console just exposed them to hackers. Any sensitive session cookies or other information available in their browser is now the property of a shadowy cabal of cyber-anarchists.

For an example of this in action, check out a historical write-up of a very similar scam that circulated on Facebook a few years ago. The scam also encouraged users to follow directions to hack any Facebook account, also asking them to copy and execute code in their developer console, and also resulted in the victim being hacked when they actually complied.

Further Reading Example: Facebook Self-XSS Scam: https://www.tomsguide.com/us/facebook-self-xss,news-19224.html

Because this particular bug, like so many of these un-rewardable, almost-vulnerabilities, requires either action outside the application context (such as a phone support worker initiating a change under the influence of social engineering) or other application-based vulnerabilities to be present and ripe for exploitation, it falls outside the scope of most bug bounty programs and is not eligible for a reward.

Even as companies write guides and issue warnings to avoid these kinds of scams, they are limited in terms of the preventative action they can take: there’s only so many ways to secure a house if the owner is intent on giving away their keys by executing malicious code themselves.

Non-Critical Data Leaks – What Companies Don’t Care About

Previously, during discussions about access control, security by obscurity, and data leakage, the different types of data that companies were not interested in rewarding were briefly covered. This included information like usernames, descriptive-but-not-sensitive error messages, different kinds of error codes, and so on.

Here are some other, specific examples of information that security researchers often report, but that companies very rarely pay for.

Emails

Emails are a piece of information many website operators try to deny to bots and automated agents crawling their site. One typical strategy is encoding email links as HTML entities to make them harder to collect. This means an email such as nessus@generalproducts.biz can be hidden as the following entity code:

nessus@generalproducts.biz

Unless a crawler is specifically expecting to detect and decode entities as part of its scraping process, this little obfuscation (the practice of making something obscure or unintelligible) trick can be surprisingly effective.

But if an email is exposed on a company site, it is usually meant to be a public-facing handle. Submitting a bug report about an exposed email like support@company.com or even reporting that you’ve deduced the employee email naming convention (e.g., lastname.firstname@company.com) does not meet the standard for a payout. There are too many extra steps beyond simply enumerating a company’s email username registry before the disclosure becomes an actual, high-impact vulnerability.

HTTP Request Banners

HTTP banners are an integral part of the protocol that stitches the entire web together. On common services, they can include encoding data, device information, general information about the nature of the HTTP request, and other data, which might be privy to many different types of devices.

All of that is to be expected as part of the service and does not constitute a leaked source of sensitive system information. This includes both information contained in the present banners as well as the “missing” security banners that some tools flag.

Known Public Files

This is simple: some files are designed to be accessible! Reporting on the configuration or availability of files such as robots.txt, wp-uploads, or sitemap.xml is not going to merit a payout—or probably even a response—because these files are intended to be public-facing.

Missing HttpOnly Cookie Flags

HttpOnly cookie flags are anti-XSS prevention devices. If a server-side process flags a cookie as HttpOnly, it cannot be accessed client-side (when the browser attempts to read the cookie using client-side script, it just returns an empty string). Every major browser supports HttpOnly cookies. But whatever their value, they are a safeguard, and their absence does not directly imply a vulnerability. If there’s no additional Cross-Site Scripting (XSS) vulnerability present, there is no issue.

Other Common No-Payout Vulnerabilities

In addition to the larger categories of bugs discussed that typically don’t merit a payout, there are also a lot of one-offs and miscellaneous would-be vulnerabilities you should try to avoid submitting. Keep in mind that these are in addition to previously-submitted vulnerabilities, which are ineligible for payout everywhere.

This example of Anonymous Form CSRF drives home a general point that is essential to remember: Attack scenarios modeling a critical attack are essential to making sure that your submission is rewarded.

Summary and Key Takeaways

This article has covered different types of security flaws that typically don’t rise to the level of a profitable vulnerability in the context of a bug bounty program. These include issues like DoS/DDoS, Self-XSS, and other types of attacks, as well as information that is commonly reported by scanners and penetration testing tools but that doesn’t necessarily interest bug bounty program operators.

Along with various miscellaneous out-of-scope vulnerabilities, the analysis of the common features that link these bugs together reveals a clear pattern: they are not high-impact on their own.

They are often excluded because:

• They require other, more serious exploits to be present.
• They have limited reach, often only affecting the attacker.
• They require social engineering or attacks on third-party services.

By understanding not only what bugs don’t get rewarded but why they aren’t valuable, you can now tune your own workflow to lower the noise in your reporting. This will help you build a penetration testing regimen that cuts down on time-wasting dead ends and focuses on the vulnerabilities that truly matter to the company and their users.

Questions and Further Analysis

1. Why are DoS/DDoS attacks typically out-of-scope?

Answer: Denial-of-Service (DoS) and Distributed Denial-of-Service (DDoS) attacks are typically out-of-scope because they are considered an availability issue, not a confidentiality or integrity issue.

• The CIA Triad: Security is often measured by the CIA triad:
  • Confidentiality: Keeping data secret.
  • Integrity: Preventing unauthorized data modification.
  • Availability: Ensuring systems are accessible.
• Bug Bounty Focus: Most bug bounties focus on flaws that compromise confidentiality (e.g., data theft) or integrity (e.g., taking over an account, changing data). While availability is critical, DoS attacks are often achieved through sheer brute force (flooding a server with traffic) rather than a unique, exploitable software “bug.” Defending against them is more about infrastructure scaling, rate limiting, and DDoS mitigation services (like Cloudflare) than fixing a specific line of code.

Scenario where a DoS-related bug would merit a reward:

If a researcher finds a logic flaw that causes a service to crash or become unresponsive with a single, low-resource request, it would often be in-scope. This is sometimes called “Low-Rate Denial of Service.”

• Example: Sending a specially crafted API request that triggers an infinite loop on the server, consuming 100% CPU with a single HTTP packet. This demonstrates a vulnerability in the application’s logic, not just network-level flooding.

2. What is Self-XSS? Why does it not usually merit an award?

Answer: Self-XSS (Cross-Site Scripting) is a vulnerability where the payload (the malicious script) can only be executed by the user themselves. It typically requires the user to paste malicious code into their browser’s developer console.

It’s not rewarded because:

• No Security Impact: It does not allow an attacker to compromise another user’s account or data. The victim is only “attacking” themselves.
• No Privilege Escalation: It cannot be used to escalate privileges or perform actions the user couldn’t already do manually.
• Social Engineering, Not a Technical Flaw: Exploiting it relies entirely on tricking the user, which is a human problem, not a technical software vulnerability. Bug bounties are for finding technical flaws in the application.

3. What’s the potential damage of leaving HTTP’s OPTIONS method enabled?

Answer: By itself, the OPTIONS method is harmless and is part of the HTTP standard for CORS (Cross-Origin Resource Sharing) preflight requests. The damage is in information disclosure.

• Reconnaissance: An attacker can use the OPTIONS method to “fingerprint” the server and discover which other HTTP methods are enabled (e.g., GET, POST, PUT, DELETE, TRACE).
• Attack Planning: Finding that powerful methods like PUT or DELETE are enabled gives an attacker a clear direction for further attacks. For example, if PUT is allowed, they might try to upload a malicious file.

The primary risk is leaking information that makes it easier for an attacker to plan a more serious attack.

4. Why don’t BEAST and other SSL vulnerabilities typically qualify for bug bounty programs?

Answer: Vulnerabilities like BEAST (Browser Exploit Against SSL/TLS) are usually out-of-scope for a few key reasons:

• Client-Side vs. Server-Side: BEAST is primarily a client-side attack. It exploits a weakness in the client’s browser (or TLS library), not a flaw in the configuration or code of the target server.
• Deprecated and Patched: BEAST is an old attack (from 2011) against TLS 1.0. Modern servers and browsers have long since mitigated it by supporting newer protocols (TLS 1.2, 1.3) and using different cipher modes.
• Infrastructure-Level Issues: These types of vulnerabilities are often related to the underlying web server (Apache, Nginx) or protocol implementation, not the unique application code that bug bounties are designed to protect. Program owners expect teams to keep their server TLS configurations up-to-date as a matter of standard hygiene.

5. What is Clickjacking?

Answer: Clickjacking (UI Redress Attack) is an attack that tricks a user into clicking something different from what they perceive. An attacker uses transparent or opaque layers to overlay a malicious button or link on top of a legitimate, hidden webpage.

• How it works: The victim sees a harmless-looking page (e.g., a game), but an invisible iframe containing their email account or bank website is positioned directly underneath the “Play” button. When they click “Play,” they are actually clicking the “Delete All Emails” or “Confirm Transfer” button on the hidden page.

6. What is Physical Testing?

Answer: In the context of bug bounties, physical testing refers to attempting to find security vulnerabilities through direct, physical interaction with a company’s assets.

This includes:

• Attempting to gain unauthorized physical access to corporate offices or data centers.
• “Shoulder surfing” (looking over someone’s shoulder for passwords).
• Plugging devices into corporate network jacks.
• Dumpster diving for sensitive documents.

This is almost always strictly out-of-scope for bug bounty programs due to the high legal and safety risks involved.

7. What makes a CSRF vulnerability out-of-scope?

Answer: Cross-Site Request Forgery (CSRF) forces a logged-in user to execute an unwanted action on a web application. Common reasons it might be considered out-of-scope:

• Lack of Security Impact: The action has no meaningful security consequence (e.g., changing your own profile theme from light to dark mode).
• Presence of Standard Mitigations: The application already uses anti-CSRF tokens, but the researcher found a way to bypass them. If the bypass is valid, it’s in-scope, but if the tokens are correctly implemented and unbypassable, there is no vulnerability.
• Self-Exploitation: The attack can only be performed against the attacker’s own account.
• Requires Extensive User Interaction: The exploit requires the victim to perform a complex, unlikely series of steps.

8. What are Dark Patterns?

Answer: As you defined, dark patterns are user interface and user experience design choices that deliberately trick or manipulate users into taking actions they might not otherwise take.

Examples:

• Confirmshaming: Using guilt to prevent a user from taking an action (“No thanks, I don’t want to save money”).
• Sneak into Basket: Adding additional products to your cart without your clear consent.
• Roach Motel: Making it very easy to sign up for a service but extremely difficult to cancel it.
• Privacy Zuckering: Tricking you into sharing more personal data than you intended.

While unethical, dark patterns are generally a business practice or design ethics issue, not a security vulnerability, and are therefore out-of-scope for bug bounties.

9. Why aren’t brute force-related vulnerabilities rewarded?

Answer: Brute force attacks (e.g., repeatedly trying passwords) are not considered a software vulnerability but rather a configuration or design flaw in the security controls.

Focus on Technical Flaws: Like DoS, a successful brute-force attack is often a matter of “brute force” rather than exploiting a technical weakness in the code itself. Program owners expect basic security hygiene like rate limiting to be in place.

Mitigation is Standard: The defense against brute-forcing is well-known and standard: implement strong rate limiting and account lockout policies.

Lack of Novelty: Finding that a login endpoint doesn’t have rate limiting doesn’t demonstrate a unique “bug”; it demonstrates a missing security control. Bug bounty programs are looking for novel flaws in the application logic.

Further Reading and Resources

You can find out more about some of the topics discussed in this article at the following links:

• Facebook Self-XSS Scam: Learn more about how social engineering was used in a Self-XSS scheme on Facebook.https://www.tomsguide.com/us/facebook-self-xss,news-19224.html
• GitHub DDoS Attack: Read the report on the massive DDoS attack that targeted GitHub.https://www.theregister.co.uk/2018/03/05/worlds_biggest_ddos_attack_record_broken_after_just_five_days/
• TLS/SSL Vulnerability Attacks: An in-depth discussion of TLS/SSL vulnerabilities and related attacks, including the BEAST attack.https://www.acunetix.com/blog/articles/tls-vulnerabilities-attacks-final-part/
• Detectify Labs on CSRF Logouts: A detailed argument for why the security industry should re-evaluate CSRF issues on logout functionality.https://labs.detectify.com/2017/03/15/loginlogout-csrf-time-to-reconsider/
• Dark Patterns: A resource dedicated to exposing and raising awareness of deceptive user interface design practices.https://darkpatterns.org

The post (Out of Scope) Vulnerabilities: Knowing What Not to Report in Bug Bounty Programs appeared first on Abdul Wahab Junaid.

Relative Path Overwrite (RPO) is an older, lesser-known vulnerability that still impacts a significant number of applications. This flaw typically allows an attacker to manipulate the browser’s interpretation of a relative path, forcing it to load a malicious file instead of the intended resource (like a stylesheet).

While RPO can sometimes be used for Cross-Site Scripting (XSS) or extracting sensitive data, the vast majority of cases can only be exploited for web defacement by injecting custom CSS. This vulnerability is often classified as a low-severity finding, but it is still interesting because it is frequently missed in security audits due to a lack of understanding regarding the exploit chain.

RPO Prerequisites and Mechanism

Before an RPO attack can be exploited, several specific application conditions must be met:

1. Reflected Input: A page must reflect the current URL, path, or Referer header in the HTML source of the response.
2. Quirks Mode Enabled: The HTML page must be missing the <!DOCTYPE> tag to enable the browser’s Quirks Mode.
3. Wildcard Path: The endpoint must have a wildcard path or “catch-all” routing, meaning a URL like example.com/vuln.php resolves to the same page as example.com/vuln.php/something/.
4. Relative Path Imports: The page must import resources (like stylesheets) using a relative path (e.g., <link rel="stylesheet" href="style.css">).

If all these requirements are met, an RPO exploit is highly likely.

Understanding Path Relative Links

To understand RPO, you must first know how browsers use path relative links to load content:

• Absolute Link (Full Path): <link rel="stylesheet" href="https://example.com/css/style.css"> (Uses the full URL.)
• Root-Relative Link: <link rel="stylesheet" href="/css/style.css"> (Starts at the root of the web directory /.)
• Relative Link (Current Directory): <link rel="stylesheet" href="style.css"> (Looks in the current directory for the file. If the URL is example.com/test/, it will look for the CSS file at /test/style.css.)

The RPO attack targets the relative link and manipulates the browser’s interpretation of the current directory.

Quirks Mode Explained

Quirks Mode was designed to gracefully handle poorly coded websites, which were common years ago. When Quirks Mode is enabled (by omitting the <!DOCTYPE> tag), the browser often ignores the Content-Type header of a file when processing it.

This is critical for RPO: if we pass an HTML file (with a Content-Type: text/html) to a link tag that expects a stylesheet, the browser in Quirks Mode will still try to parse the HTML file as if it is a CSS file. If Quirks Mode is disabled, the browser would block this action and throw an error.

The RPO Exploit Chain

The exploit requires confirming the conditions and then constructing a malicious URL.

Step 1: Confirming Reflection, Quirks Mode, and Wildcard Routing

First, examine the vulnerable code or manually inspect the page source.

The initial step is to determine if the application reflects the URL path in the HTML source. You can manually verify this by checking the source code after visiting a path like /home/okay/.

The reflection of the okay/ path is visible. We can also see that the <!DOCTYPE> tag is missing, confirming that the page is running in Quirks Mode. Next, we must confirm that /home/okay/ resolves to the same page as /home, which confirms the wildcard path routing.

Step 2: Manipulating the Relative Path

Because the <link> tag is using a relative path (style.css), when we change the URL to /home/okay/, the browser attempts to import the stylesheet from /home/okay/style.css.

However, due to the wildcard path routing, the URL /home/okay/style.css actually resolves and returns the content of the original HTML page (/home)!

[Image showing the URL structure where /home/okay/ resolves to the same page as /home, but the relative path changes to /home/okay/style.css]

As shown, the Link tag attempts to import its stylesheet from /home/okay/style.css. Because of the wildcard path after /home, this URL resolves to the same HTML source as /home. Since the response does not contain a <!DOCTYPE> tag, the browser has Quirks Mode enabled.

If Quirks Mode were disabled, the browser would receive the HTML content with a Content-Type: text/html and would throw an error when attempting to parse it as a stylesheet.

Step 3: Launching the CSS Injection

Since the Link tag is forced to accept the HTML output as CSS (due to Quirks Mode), and user-controlled input is reflected in that output (the path), an attacker can inject CSS commands that the browser will execute.

The malicious URL is crafted by appending the CSS payload to the path:

• Payload: %0A{}*{color:red;}/// (The %0A is a newline character, used to ensure the injection starts on a new line.)

This CSS payload forces all elements on the page (*) to have a red color.

[Image showing the result of the RPO attack where the font color is red due to CSS injection]

The injection of the CSS code successfully turns the page font red, confirming the target is vulnerable to RPO.

Summary and Conclusion

Relative Path Overwrite is an older, lesser-known vulnerability that still poses a threat. It is a complex attack chain requiring specific application conditions: path reflection, a relative resource link, wildcard routing, and the omission of the <!DOCTYPE> tag (enabling Quirks Mode).

While often classified as a low-severity finding, RPO can still be used to perform web defacements and, in rare cases, higher-impact attacks. It is a bug that many security professionals overlook.

You now have a few more sophisticated tricks up your sleeve! There are plenty of other techniques out there, and I recommend learning additional vulnerabilities. The more vulnerabilities you know how to exploit, the better your chances are of securing an application.

The post Relative Path Overwrite (RPO): Exploiting Path Confusion for Defacement appeared first on Abdul Wahab Junaid.

On-Site Request Forgery (OSRF) is an older vulnerability that often goes unrecognized. It is similar to Cross-Site Request Forgery (CSRF) in that an attacker can force a user’s web browser to make requests on the attacker’s behalf.

The key difference is the origin of the request:

• In CSRF, the malicious request is initiated from an attacker-controlled external site (e.g., attacker.com).
• In OSRF, the malicious request is initiated from the target application itself (e.g., target.com).

The root cause of this vulnerability is the application using unsanitized user-supplied input to construct an internal HTTP request or path used by the browser.

Understanding and Exploiting OSRF

When first encountering OSRF, it can feel very similar to Cross-Site Scripting (XSS) because it often involves injecting data into an HTML element.

Consider the following example of a vulnerable application. The goal for an attacker is to force the user’s browser to send a request to the sensitive endpoint /admin/add. This action is assumed to create a new admin user that the attacker could then use to log into the victim’s application.

The vulnerable code snippet shows that user input, passed via vuln_param, is used directly to create the src attribute of an image tag: <img src="images/{{vuln_param}}">.

If an attacker could break out of the single quotes here, it would be an XSS vulnerability. However, even if we assume the input is sufficiently sanitized to prevent XSS (i.e., we cannot break out of the quotes), OSRF may still be possible.

The attacker’s goal is to construct the following request in the user’s browser:

127.0.0.1/admin/add?username=ghost&password=lulz

This request is intended to create a new admin user named “ghost” with the password “lulz”.

Step 1: Path Traversal

Let’s look closely at how the vuln_param creates the final path for the image source. The path starts as images/.

What if an attacker were to input ../../ for the vuln_param?

• Original Path: /images/
• Input: ../../
• Resulting Path: /images/../../

The ../ characters are a path traversal technique that tells the server (or in this case, the browser resolving the path) to go back one directory.

• images/ is the current directory.
• ../ moves back from images/ to /.
• The second ../ moves back from / one more level, which often wraps around or simply resolves to the root directory (/).

[Image showing the browser resolving the path traversal input ../../ to the root path /]

By using path traversal, the browser sends a GET request to the path / instead of the intended /images.

Step 2: Targeting the Admin Endpoint

Now that the attacker can navigate up the directory structure, the next step is to target the sensitive admin endpoint.

The attacker sets vuln_param to: ../admin/add.jpg

• Original Path: /images/
• Input: ../admin/add.jpg
• Resulting Path: /images/../admin/add.jpg

This path resolves to /admin/add.jpg.

[Image showing the browser making a request to /admin/add.jpg]

The browser is now making a request to /admin/add.jpg. If the sensitive endpoint is accessible via a GET request and requires no CSRF token, we can proceed to add the user parameters.

Step 3: Injecting Parameters and Handling URL Encoding

The attacker now constructs the full payload to add the new user. The request is formed by appending parameters to the path:

• Input: ../admin/add?username=ghost&password=lulz

However, when sending multiple parameters via an injected URL, we must URL encode the ampersand (&) character as %26. If we do not encode it, the browser will assume the & belongs to the first resource request and won’t be passed as a full parameter string to the /admin/add endpoint.

Additionally, because the original code appends .jpg to the end of the input, the password in the URL would become password=lulz.jpg, which is not the desired password. To neutralize this unwanted suffix, the attacker can simply add a dummy parameter at the end:

• Final Payload (URL Encoded):http://127.0.0.1:5000/?vuln_param=../../admin/add?username=ghost%26password=lulz%26dummy_param=

This final payload successfully achieves the goal: it makes the user’s browser send a request to the /admin/add endpoint, causing the application to add a new user named “ghost” with the password “lulz”.

Since this request is initiated from the user’s browser while they are authenticated, it will contain all the user’s necessary authentication cookies, the application’s Origin header, and other relevant details, making it appear as a legitimate, authorized request.

Summary

If a security tester is able to control part of the URL path used to make an HTTP request within the target application, they likely have OSRF.

To confirm, try injecting the ../ characters, which should cause the browser or server to resolve the path one directory up. If path traversal is possible, you almost certainly have OSRF; you just need to find an interesting and sensitive endpoint to call.

OSRF is a relatively old vulnerability that is often overlooked. It’s surprisingly easy for developers to accidentally implement this vulnerability, and because it is often chained with the victim’s authentication context, it makes OSRF a fairly dangerous and high-impact bug.

The post On-Site Request Forgery (OSRF): A Forgotten Client-Side Attack appeared first on Abdul Wahab Junaid.

To understand Server-Side Template Injection (SSTI), one must first grasp the role of templates, and to understand templates, one should be familiar with the Model-View-Controller (MVC) design pattern. The MVC pattern is a software design pattern primarily used for developing user interfaces by separating an application into three interconnected parts.

As illustrated above, a user initiates a request to the Controller. The Controller then uses the Model to gather necessary information from the backend database. This information is passed back to the Controller. Next, the Controller passes the information to the View, which uses the data to update values in its structure. The final, updated View is then passed back to the Controller, which is subsequently sent to the user and rendered in the browser.

Templates and Template Engines

The View component is used to dynamically manipulate the HTML code and is normally implemented using templates. Templates allow a developer to have placeholders in their HTML code where dynamic variables can be passed in.

As seen on the fourth line in the example, there is a title tag holding the expression {{Title}}. This string will be replaced by whatever argument is passed to the template engine at runtime. This allows developers to easily reuse their code and separate logic from presentation.

A template engine enables you to use static template files in your application. At runtime, the template engine replaces variables in the template file with actual values, transforming the template into the final HTML file sent to the client.

One might question why a template engine is used to modify an HTML document when a simple format string operator could suffice. The reason is that template engines are much more powerful than a simple format string operator. Template engines can perform complex actions such as calling functions and methods, looping over variables, performing arithmetic, and much more.

As you will find out in the following sections, attackers can abuse template engines to perform all kinds of malicious actions. Server-Side Template Injection can be leveraged for Cross-Site Scripting (XSS), sensitive information disclosures, and even full remote code execution (RCE).

Python: Jinja2 Template Engine

Jinja2 is a popular template engine in Python and is frequently used in Flask and Django applications.

When testing for Server-Side Template Injection (SSTI) in a Jinja2 application, the following payloads are usually tried first to confirm vulnerability:

• {{7*7}} (Expected Output: 49)
• {{7*'7'}} (Expected Output: 7777777)

If the output 7777777 is displayed, you can assume the application is vulnerable and is likely using the Jinja2 or Tornado template engine.

Exploiting Jinja2 using MRO

To fully understand how to exploit this vulnerability, you first need to understand Method Resolution Order (MRO). MRO is the order in which Python looks for a method in a hierarchy of classes, and the MRO function can be used to list these classes.

To start, we can inspect the MRO of an empty string:

• '' .__class__.__mro__

This command will first search the string class for a method. If it’s not found there, it will search the root object class. For this attack, we only care about the root object class because we can use it to get a handle to all other classes used by the application. To get the root object, access the second index (index [1]) in the array:

• '' .__class__.__mro__[1]

Note: You can also use the __base__ method on an empty array or list to get this root object, as shown in the following command:

• [].__class__.__base__

The __subclasses__() method can be used to list all the subclasses of a class. By using this on the root object, we can get a handle to every class the application uses:

• {{[].__class__.__mro__[1].__subclasses__()}}

As you can see, all subclasses of the root object have been displayed. The next step is to look for something interesting that allows for system interaction. If we have access to the subprocess.Popen class, an attacker can leverage this class to execute commands on the server, as shown below:

• {{[].__class__.__mro__[1].__subclasses__()[-3]('whoami',shell=True,stdout=-1).communicate()[0] }}

If you are familiar with Python and the Popen method, you will see that this is simply using legitimate functionalities of Python to execute a system command. Note that you can also use the following command for code execution if the one above doesn’t work (this payload relies on accessing the os module from the application’s configuration):

• {{config.__class__.__init__.__globals__['os'].popen('whoami').read()}}

If you find SSTI in the Jinja2 template engine, the severity of the finding depends on what Python classes you have access to. If you don’t have access to any system command classes, code execution might be impossible (though not always). If you have access to the file class, you might be able to read/write files to the system. You must properly enumerate all the classes the root object has access to so you can figure out what capabilities you have.

Python: Tornado Template Engine

According to Google, Tornado is a scalable, non-blocking web server and web application framework written in Python. Tornado also has its own template engine which, like many others, is vulnerable to SSTI if implemented incorrectly.

Exploiting SSTI in the Tornado template engine is relatively easy compared to other engines. Looking at the Tornado template engine documentation, it mentions that you can import Python libraries directly into the template.

Any library available to Python is also available to the template engine. This means you can import a Python library and call its functions. This functionality can be abused to execute system commands, as shown below:

• {% import os %}{{ os.popen("whoami").read() }}
• {% import subprocess %}{{subprocess.Popen('whoami',shell=True,stdout=-1).communicate()[0]}}

[Image showing the ‘whoami’ command output after successful SSTI exploitation in Tornado]

As you can see, the whoami command was run on the server, and the output was displayed on the screen. Since we can import any Python library, the attacker is not limited to just executing shell commands; they can execute arbitrary Python code.

Ruby: ERB Template Engine

ERB is an Eruby templating engine used to embed Ruby code within a document. According to Google, “An ERB template looks like a plain-text document interspersed with tags containing Ruby code. When evaluated, this tagged code can modify text in the template.”

Note that ERB uses the following tags for embedding code:

• <% code %>: Used to execute Ruby code without returning a result (e.g., control flow).
• <%= code %>: Used to execute Ruby code and return (print) the results.

To test for SSTI in the ERB engine, use the following command:

• <%= 7 * 7 %>

As seen, the code was executed and returned the value of 49. This is a strong indicator that the server is vulnerable to Server-Side Template Injection. To test for code execution, simply run your Ruby code to execute a system command:

• <%= whoami %> (Uses backticks for command execution)
• <%= IO.popen('whoami').readlines() %>
• <% require 'open3' %><% @a,@b,@c,@d=Open3.popen3('whoami') %><%= @b.readline()%>
• <% require 'open4' %><% @a,@b,@c,@d=Open4.popen4('whoami') %><%= @c.readline()%>

[Image showing the ‘whoami’ command output after successful SSTI exploitation in ERB]

As shown, the whoami command ran, and the results were outputted to the screen.

Ruby: Slim Template Engine

According to Google, Slim is “a fast, lightweight templating engine with support for Rails 3 and later.” Like many other template engines, SSTI can arise when Slim is improperly implemented.

In terms of exploiting SSTI, the Slim template engine is very similar to ERB, but the syntax is different:

• #{code}

To execute a shell command, simply wrap your command in backticks:

• #{ \whoami` }`

Again, just like the ERB template engine, if vulnerable, an attacker can execute any Ruby command they want.

Java: Freemarker Template Engine

Freemarker is the most popular template engine for Java, making it a valuable target to understand.

As you can see, this vulnerability stems from concatenating user-supplied input with a template, just like every other template engine vulnerability. To test for SSTI vulnerability, use the following payload:

• ${7*7}

Similar to other template engines, to exploit this vulnerability, we are going to use an object to execute shell commands. The ?new() command in Freemarker can be used to instantiate classes, so all we need is a class that can execute shell commands.

The Execute class is available in Freemarker and can be used to execute shell commands. The documentation even mentions that this class can be used to run arbitrary code on the server. To use this class, we can run one of the following commands:

• <#assign ex = "freemarker.template.utility.Execute"?new()>${ ex("whoami")}
• [#assign ex = 'freemarker.template.utility.Execute'?new()]${ ex('whoami')}
• ${"freemarker.template.utility.Execute"?new()("whoami")}

[Image showing the ‘whoami’ command output after successful SSTI exploitation in Freemarker]

As demonstrated, the command whoami ran, and the output was displayed in the browser. From here, it would be trivial to run a command to execute a backdoor or any other malicious payload.

The post Server-Side Template Injection (SSTI): Exploiting the Backend View appeared first on Abdul Wahab Junaid.

Like web cache poisoning, Web Cache Deception (WCD) is an attack directed against the caching server. The goal of WCD is to trick the caching server into caching the sensitive, private information of other users. In specific scenarios, the exposed information can be used by an attacker to take over a victim’s account.

This exploit relies on two main conditions: path confusion and the fact that some caching servers are aggressively configured to cache requests that appear to be for static files.

Reminder: Web cache deception relies on a fundamental understanding of caching servers. Caching servers save the response to a user’s request and serve that saved response to subsequent users who call the same endpoint, improving performance and reducing server load.

Understanding Web Cache Deception

Web cache deception works by crafting a malicious URL that, when visited by a victim, causes the caching server to cache the private response and serve it to everyone, including the attacker.

Condition 1: Overriding Cache Control for Static Files

When a web application handles sensitive data, it typically instructs the caching server not to cache the response. For example, the endpoint /setting.php returns a user’s name, email, address, and phone number. Since the response relies on the user currently logged in, and each response will be different, it would not make sense to cache this page. Furthermore, for security reasons, you absolutely do not want an application caching pages with sensitive information.

The application achieves this by setting the Cache-Control header in the HTTP response:

As seen in the image above, the Cache-Control header is set to no-cache. This explicitly tells the caching server to not cache this page.

However, sometimes the caching server will make an executive decision to cache a page regardless of the response headers. This normally occurs when the caching server is configured to aggressively cache any page ending with a specific extension (such as .css, .jpg, .png, etc.). The caching server is configured to cache all static pages no matter what the response headers say.

Therefore, if an attacker were to request a URL like example.com/nonexistent.css while logged in, the caching server would cache this response, regardless of the actual content or the application’s Cache-Control header, simply because the URL path ends with the .css extension.

Condition 2: Path Confusion

Path confusion occurs when a web application loads the same resources or executes the same logic regardless of slight variations in the requested URL path. With the rise of large web applications and complicated routing tables, this flaw has been unintentionally introduced.

In modern web frameworks, there is often a catch-all path on the root directory. This means that any path after the initial / will essentially be passed to the same function or handler, often resulting in the same response.

In the scenario above, both the example.com/ and example.com/something URLs would be sent to the same catch_all function. While the example only prints the path, in a real-world application, the function would perform some task (like rendering the user’s account page) and return the HTML response.

The following image, taken from the white paper “Cached and Confused: Web Cache Deception in the Wild”, describes several techniques attackers use to achieve path confusion and trick the caching server.

Techniques for Causing Path Confusion:

1. Path Parameter: This occurs when additional path elements added to the request are still passed to the same backend function.
   • Application’s View: example.com/account.php (The application ignores the extra path element and renders the account page.)
   • Caching Server’s View: example.com/account.php/nonexistent.css (The caching server sees the .css extension and decides to cache the resource.)
2. Encoded Newline (%0A): This exploits the difference in how proxies and web servers parse characters. Some web servers stop reading a path after a newline character, but the caching server does not.
   • Application’s View: example.com/account.php
   • Caching Server’s View: example.com/account.php%0Anonexistent.css (The caching server sees the full path with the static extension.)
3. Encoded Semicolon (%3B): Some web servers treat semicolons (;) as parameter separators, while the caching server may not recognize this special meaning.
   • Application’s View: example.com/account.php (The server sees the semicolon and everything after it as a parameter for account.php.)
   • Caching Server’s View: example.com/account.php%3Bnonexistent.css (The caching server sees the full path as a separate resource.)
4. Encoded Pound (%23): Web servers often process the pound character (#) as an HTML fragment identifier and stop parsing the URL after that character, essentially ignoring it in the request sent to the backend. The caching server, however, may not.
   • Application’s View: example.com/account.php
   • Caching Server’s View: example.com/account.php%23nonexistent.css
5. Encoded Question Mark (%3F): Web servers treat question marks (?) as the start of URL parameters, while the caching server may treat the response differently.
   • Application’s View: example.com/account.php (The server sees ?name=valnonexistent.css as a query string for account.php.)
   • Caching Server’s View: example.com/account.php%3fname=valnonexistent.css

As you can tell, the key to these attacks is the difference in interpretation: the web server interprets a request one way (resulting in the user’s private page), while the caching server interprets it a different way (resulting in a cacheable static file).

Executing the Web Cache Deception Attack

The attack is executed by combining the two conditions:

1. The application has a sensitive, authenticated page, like an account setting page (/users/me).
2. The application routing is susceptible to path confusion, or the caching server is configured to ignore Cache-Control for static files.
3. The attacker crafts a malicious URL that exploits the path confusion and ends with a static extension, for example:http://example.com/users/me/profile.css

If a logged-in victim visits this URL, the web server sees the /users/me path and returns the victim’s private information (email, name, phone number, etc.). However, the caching server sees the .css extension and decides to cache the HTML response containing the victim’s private data.

Once the response is cached, the attacker can then simply visit the same URL (http://example.com/users/me/profile.css) and retrieve the cached response, which now contains the victim’s sensitive personal identifiable information (PII).

The post Web Cache Deception: Tricking the Caching Server to Expose Private Data appeared first on Abdul Wahab Junaid.

Compromising the authentication process will typically lead to Account Takeover (ATO) vulnerabilities, and depending on the accounts you take over, it could also lead to privilege escalation (gaining higher access permissions than intended). The following sections discuss some of the most common authentication methods and their pitfalls.

HTTP Basic Authentication

This is probably the most basic and easy to implement type of authentication. You can identify HTTP Basic Auth by the pop-up it displays in web browsers asking for a username and password.

The Pitfall: Base64 Encoding

After typing in your username and password, the authentication details are stored in an Authorization header as shown below:

Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

Note that the authorization header is just a Base64 encoded string of the username and password. Base64 is an encoding scheme used to represent binary data in an ASCII string format; it is not encryption.

If you were to decode the string dXNlcm5hbWU6cGFzc3dvcmQ= you would get:

username:password

That’s one of the biggest downfalls of using HTTP Basic Auth. Each time you send a request, your clear-text username and password are sent as a Base64 encoded authentication header, making it very susceptible to eavesdropping attacks if the connection is not secured with HTTPS.

JSON Web Token (JWT)

JSON Web Tokens (JWTs) are extremely popular among API endpoints as they are easy to implement and understand.

When a user attempts to log in, the system sends its credentials to the back-end API. The backend verifies the credentials and, if they are correct, it generates a JWT token. This token is then sent back to the user. After that, any subsequent request sent to the API will include this JWT token to prove the user’s identity.

A JWT token is made up of three parts separated by dots (.):

[HEADER]. [PAYLOAD] . [SIGNATURE]

Example Token:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

The token can easily be decoded using a Base64 decoder. Security professionals often use tools like jwt.io to inspect these tokens.

Anatomy of a JWT

1. Header: The first part of the token is the header. This is where you specify the algorithm (alg) used to generate the signature (e.g., HS256, RS256).
2. Payload: The second part of the token is the payload. This is where you specify the information used for access control (e.g., user ID, roles, expiry time). In the example above, the payload section has a variable called name, which is used to determine who the user is when authenticating.
3. Signature: The last part of the token is the signature. This value is used to ensure the token has not been modified or tampered with. The signature is created by concatenating the Base64-encoded Header and Payload sections (separated by a dot) and then signing this value using the algorithm specified in the header, along with a secret key.

If an attacker were able to sign their own key, they would be able to impersonate any user on the system since the backend will trust whatever information is in the payload section. There are several different attacks which attempt to achieve this, as shown in the below sections.

JWT Attack Methodologies

1. Deleted Signature (Signature Stripping)

Without a signature, anyone could modify the payload section, completely bypassing the authentication process. If you remove the signature from a JWT token and the modified token is still accepted by the server, you have successfully bypassed the verification process. This means you can modify the payload section to anything you want (e.g., changing the name value from john doe to admin) and it will be accepted by the backend, potentially signing you in as the admin user.

2. “None” Algorithm Attack

If you can tamper with the algorithm used to sign the token, you might be able to break the signature verification process. JWT supports a none algorithm (intended originally for debugging purposes). If the header is modified to specify the none algorithm, any JWT token will be valid as long as the signature is missing or empty.

Modified Header (Base64 decoded):

{"alg":"none","typ":"JWT"}

This attack essentially tells the server, “Don’t verify the signature.” This attack can be done manually or by using a Burp plugin such as “JSON Web Token Attacker.”

3. Brute Force Secret Key

JWT tokens will either use an HMAC (Symmetric) or RSA (Asymmetric) algorithm to verify the signature.

If the application is using an HMAC algorithm (like HS256), it uses a single secret key when generating the signature. If you can guess this secret key, you will be able to generate signatures, allowing you to forge your own tokens. This is often successful if the key is weak or common. There are several open-source projects that can be used to crack these keys, often by using dictionary attacks (list goes on for days, just search GitHub for the words jwt cracker):

• https://github.com/AresS31/jwtcat
• https://github.com/lmammino/jwt-cracker
• https://github.com/mazen160/jwt-pwn

4. RSA to HMAC Algorithm Confusion

This is a more sophisticated attack against JWTs that use RSA (Asymmetric) signature verification.

• RSA (e.g., RS256): Uses a private key to generate the signature and a separate public key for verification. The public key is typically available to the public.
• HMAC (e.g., HS256): Uses the same secret key for both signing and verifying the signature.

The Attack: An attacker changes the JWT header’s algorithm from an RSA type (e.g., RS256) to the symmetric HMAC type (e.g., HS256).

1. The attacker changes the alg in the header from RS256 to HS256.
2. The attacker uses the server’s public key (which is public information) as the secret key to sign their forged token.
3. When the server receives the token, the backend code reads the header and attempts to verify the token using the HS256 algorithm.
4. Because the server’s code was originally configured for RSA, during verification, it retrieves the public key (which is publicly known) to use for the verification process.
5. Since the attacker signed the token with the public key, and the server attempts to verify it with the public key (as a symmetric key), the token passes the verification check. The attacker has successfully impersonated any user.

The original header used the RS256 algorithm, but the attacker changed it to use HS256. Next, the attacker changed their username to admin and signed the token using the server’s public key. When this is sent to the server, it will use the HS256 algorithm to verify the token instead of RS256. Since the backend code was set up to use a public/private key, the public key will be used during the verification process, and the attacker’s forged token will pass.

Summary

JSON Web Tokens (JWTs) are a relatively new way to handle authentication and are relatively simple compared to older methods. However, even with this simplicity, there are several vulnerabilities that impact JWTs. If an attacker is able to forge their own token, it’s game over. This is why most of the attacks revolve around this methodology of token forgery.

The post Authentication Flaws: Compromising User Identity appeared first on Abdul Wahab Junaid.

For example, using ../ allows you to go one directory up from the current one.

🧭 Exploiting Directory Traversal

If you see an application utilizing user-supplied input to fetch files, you should immediately test to see if it’s vulnerable to directory traversal. This can be fairly easy to spot.

Identifying a Vulnerable Endpoint

A common indicator is a URL that uses a GET parameter to load a file:

• https://example.com/?page=index.html

In this example, there is a GET parameter called page which is used to load the contents of index.html. If improperly implemented, attackers can leverage the ../ technique to load any file they want.

The Attack Mechanism

In the application’s code, the GET parameter page is loaded into a variable, which is then used by a function to open and read the file’s contents to the page. If there are no additional checks (like removing the ../ characters or ensuring the path stays within an allowed directory), it can be exploited.

Proof of Concept (PoC)

To exploit this, an attacker provides a payload designed to move several directories up until the root of the file system is reached, and then specify the path to a known sensitive file.

By repeatedly using ../, you can traverse back up the file system hierarchy until you are at the root, and then access a sensitive file like the Linux user account information file:

../../../../etc/passwd

As you can see, the vulnerability was exploited to retrieve the /etc/passwd file from the operating system. In case you didn’t know, the /etc/passwd file is used to store information on each user account in a Linux system.

Summary

Directory traversal is an easy bug for developers to mess up if they aren’t thinking correctly when coding. If an application uses user-supplied input to interact with files on the system, there is a high chance the endpoint is vulnerable to directory traversal.

If you do find this vulnerability, make sure to look for sensitive files like:

• Configuration files (which may contain credentials or API keys)
• Application source code (to find other vulnerabilities)
• Files that could be overwritten (especially if the vulnerability is found in an upload functionality, potentially leading to Remote Code Execution).

The post Directory Traversal: Navigating the File System appeared first on Abdul Wahab Junaid.