How I Bypassed a CAPTCHA Implementation Without Breaking a Sweat

Hey y'all, it's been a minute since I posted anything to do with web security. Well, you're in luck, because today I'm dropping something I've observed a couple of times in the wild and thought was worth writing about, because you might come across it too.

Heads up, it's not a blockbuster AI-discovered bug. Just a simple logical mistake made by developers when implementing CAPTCHA/reCAPTCHA.

So recently, I decided to take a look at an application I'd previously reported a valid bug in. And would you know it, these guys had actually fixed the issues I reported almost a year ago. Why this was interesting to me is that, many a time, you'd report a bug and get told it's a duplicate of something reported a decade ago, and you'd wonder, "How come you've spent years trying to fix this one bug, and it's still not fixed?"

Okay, I'm exaggerating a little. But kudos to these guys. The security team at the organization is clearly working for their salaries. I digress.

The bug I reported a while back was a rate-limiting flaw. It was actually one of the rare times that "lack of rate limiting" has ever gotten me anywhere with triage teams, where I demonstrated that even simple misconfigurations could have a significant business impact.

Not encouraging any DoS here, but one thing I realized a while back was that people hadn't been paying much attention to their emailing/notification functionality. They'd simply integrate the service into their application and decide that if it works, don't touch it.

As long as the app can notify clients, send password reset tokens, send activation links, and so on, nobody ever stops to think that these integrations could be abused, especially when they're left exposed to unauthenticated users.

This means bots can really hammer these integrations, and you know how important the ability to send bulk emails to clients and potential clients has become to businesses.

With email service providers being strict, one's domain can be blacklisted, throttled, have its spam score increased, or even have its subscription quota exhausted. If the service is self-hosted, the server's resources could be exhausted.

Businesses therefore need to view their emailing systems as high-value assets that deserve a good level of security. This includes any integrations as well.

So, with that TL;DR out of the way, let's get back to the bug I reported a couple of years ago or so.

The bug allowed an unauthenticated actor to hammer the emailing service integration until it reached a point where the service became unavailable. Other users would create accounts and not receive activation links, or try to reset a password (because passwords be leaving your brain the moment you create them) only to never receive the reset link, among other things.

The organization saw the impact of this and shipped a fix: CAPTCHA/reCAPTCHA.

Recently, I took another look at the implementation and thought, how could they have configured it? Did they implement it correctly? I knew they probably hadn't built it themselves and had likely used a third-party service, but how was user input being handled right before it even reached the third-party CAPTCHA service?

And hidden in there was the bug that allowed the entire implementation to be bypassed.

Thanks to the rather informative error messages returned by the API endpoints, I realized something very interesting: the application didn't enforce the expected data types and failed to validate whether the user-supplied input actually matched the expected data type.

Without taking you back to a data structures and algorithms class, we all know that most API endpoints usually expect parameter/attribute values to be strings.

Well, I thought to myself, especially after that famous GitBucket CVE came out a couple of years ago, where someone was able to supply two email addresses and somehow get the application to send the reset link to both of them.

With that in mind, I tried playing around with the first parameter: the email address.

This wasn't successful at first, as this field had some form of input validation in place that verified whether the value looked like an email address. This check was good to see, but it wasn't quite enough, because I was able to submit an array instead (one invalid and the next valid) and still received an email but that's not the focus of this writeup today.

Anyway, not getting much joy from the email field, I thought to myself, how about the next field, the long string containing the CAPTCHA challenge/response token?

What came to mind immediately was, "How is the backend logic verifying this? Okay, I know there's a third-party service, but how does the app implement the logic for checking its validity?"

That led me to a few hypotheses about the conditional statements that might be used.

if (recaptchaToken && !validateCaptcha(recaptchaToken))
 {
   return res.status(400).json({ error: "Suspicious activity detected" });
 }

if (recaptchaToken && !validateCaptcha(recaptchaToken))
 {
   return res.status(400).json({ error: "Suspicious activity detected" });
 }

Or, equivalently:

if recaptcha_token and not verify_captcha(recaptcha_token):
 return {"error": "Suspicious activity detected"}, 400

if recaptcha_token and not verify_captcha(recaptcha_token):
 return {"error": "Suspicious activity detected"}, 400

If you remember your logic gates correctly, you'll see what's wrong with this when it receives user input without type-checking it to ensure that it's strictly a string.

One can pass in Boolean values like true or false, or another falsy value such as null. Assuming a falsy value gets passed into these checks, the logic can behave in an unexpected way.

Instead of the application explicitly checking that the CAPTCHA token exists and is valid, the logic was relying on a condition that could be easily bypassed when the input was falsy. Remember, in JavaScript, null, false, an empty string among others are all falsy values.

So when the application received a falsy value, the first part of the condition failed, meaning the second part, which was supposed to validate the CAPTCHA token, was never executed. The application would then proceed with the request without actually verifying the CAPTCHA and trigger the notification functionality.

And there you have it. A CAPTCHA implementation that was supposed to prevent automated abuse, but could be bypassed because of a simple logical mistake. Sometimes, the problem isn't the third-party service you're integrating; it's how you implement the logic around it.

This prompted an email to my account without me having to go through CAPTCHA/reCAPTCHA over and over again.

The Fix

The recommended remediation was, of course, to implement strict type checking and user input validation, and to implement the CAPTCHA/reCAPTCHA functionality more robustly.

How so?

By validating that the token is both present and successfully verified before allowing the request to proceed:

if (!recaptchaToken || !validateCaptcha(recaptchaToken)) {
    return res.status(400).json({ error: "Suspicious activity detected…." });
}

if (!recaptchaToken || !validateCaptcha(recaptchaToken)) {
    return res.status(400).json({ error: "Suspicious activity detected…." });
}