3 ms·

If you've ever tried to take apart Cloudflare's various session cookies, MITMed scripts sent for "high integrity" pages (or when in "super bot-fight" mode), etc

by derefr 3y ago

If you've ever tried to take apart Cloudflare's various session cookies, MITMed scripts sent for "high integrity" pages (or when in "super bot-fight" mode), etc., you'll have observed that it's basically running a web-worker to heuristically do browser-integrity checking. That is, Cloudflare is trying to run a series of tests that real browsers operated by users pass, but which headless browsers operated by bots will fail. These range from pretty simple things that check that the browser is actually a browser rather than a raw HTML parser (e.g. "draw an image on a <canvas>, export it to PNG, hash the PNG, compare to an expected result"); to things that check for low-effort headless-browsing techniques like the one you get by default using Puppeteer in a Lambda/Cloud Function (e.g. "do we have the weirder fonts you'd expect to exist on a consumer OS, but which these default batteries-included container images don't bother to bake in"); to things that work really hard to detect the "scent of humanity" through the browser (e.g. "before the user activated the integrity-check prompt, did we record a sequence of 'extraneous' mouse movements and key events that look like a human making individualized mistakes on their way to completing the form, and don't look like a recorded capture of such similar to other ones we've seen recently.") If you're getting caught in a verification loop, it's because you're using a browser or device or extension that obscures/disables enough of these heuristics that Cloudflare can't get proof positive that you're a person rather than a bot — and so, under whatever settings the site-owner has it set at, it will just keep trying to get that proof, rather than telling you you've failed and been blocked. (Why? Because telling a bot they've failed tells them that they should stop trying something that's not working and instead — in the words of Star Trek technobabble — "rotate their shield frequency" before trying again.)

johnklos 3y ago
How does that explain blocks that happen to less common browsers and/or less common platforms?
- derefr 3y ago
  Heuristics are about optimizing between false positives and false negatives. Many headless-browser stealth techniques involve rotating between the signatures and reflected metrics of real — but niche and/or ancient — User-Agents. (For some reason, the developers of these stealth systems think that variety beats commonality. Maybe it makes sense if they're specifically trying to overcome Apache mod_security's signature-based UA blocking or something.) It turns out that when you actually see one of these UAs in your server logs, it's far more (99.99%) likely to be a stealthed bot that picked that UA out of a bag, than it is to be an actual niche/ancient UA. In the case of the niche UAs, this is a tragedy of the commons. In the case of the ancient UAs, though, there's no downside to blocking them entirely — because if the traffic is going through Cloudflare at all, then you're already requiring of the client a minimum version of TLS that the real old UAs can't even speak. So the only things actually saying they're that old device — but managing to get through an HTTP request at all — are stealthed bots.
  - runnerup 3y ago
    > Many headless-browser stealth techniques involve rotating between the signatures and reflected metrics of real — but niche and/or ancient — User-Agents I work in this space and we just use fingerprints we collect from actual users over the previous month. The hardest work is: 1) reverse-engineering the javascript of the CAPTCHA/fingerprinting solutions so that we can collect and encapsulate the fingerprints correctly in a way that looks native to cloudflare/recaptcha/etc, and 2) Training AI models to solve the captchas well enough. Sounds like most of the people you catch are using ancient user-agents. But I doubt most of the people you want to catch are.
    - derefr 3y ago
      I mean, when I'm talking about stealth techniques, I'm not talking about what I'm seeing in my own server logs, but rather about what I find built into various bits of, ahem, "anti-detect software for affiliate marketing" tech that I dredge up from fraud Telegram groups, carding marketplaces, etc. that the attackers I do catch seem to frequent. (Gotta stay five steps ahead!) I suppose there are verticals where the data is so valuable, and the garden around it so walled-in, that you could build a whole IT business with a custom scraping stack just around extracting that data to then resell it. (I presume that's the business you're in.) But for most verticals, the "attackers" you'll see in your logs aren't people building a data-broker business, and so aren't building their own secret-sauce anonymity from scratch; rather, they're end-users who want to do an end-run around your rate-limits, commit promotion fraud, etc., and so want to buy anonymity as a product, script-kiddie style. And "anonymity as a product", sold publicly (rather than through high-value contracts) tends to suck. It's script-kiddies buying from script-kiddies, with no real engineering in sight. > I work in this space and we just use fingerprints we collect from actual users over the previous month. Are you sure you're not in a citogenesis cycle? How sure are you that some of those "real users" aren't your peers' stealthed bots, who in turn picked up those fingerprints from unknowningly observing other stealthed bots in their logs, who...
      - runnerup 3y ago
        > Are you sure you're not in a citogenesis cycle? How sure are you that some of those "real users" aren't your peers' stealthed bots, who in turn picked up those fingerprints from unknowningly observing other stealthed bots in their logs, who... Doesn't matter, they work (at least when used in combination with high-quality proxy IP's). If they stopped working I'd do something else. We only apply hard science when absolutely needed, otherwise it's mostly wire and duct tape holding things together -- ruthless focus on creating business value. We definitely only sell this via high-value contracts, so you're probably mostly correct there. Though puppeteer-stealth deserves at least a quiet shout-out for not completely sucking. That said, we do pay attention to a lot of the research in the field, even if we only apply the absolute bare minimum needed to create business value. Eric Wustrow[0] at UC Boulder does really, really good work in an adjacent space, and we've found some his papers/software to be helpful, as well as those of some of the colleagues he works most closely with. I don't think he'd love our applications of his research, but our technological needs dovetail well with the needs of the anti-censorship research that he works on. If you were interested in the degree of "citogenesis", I think that's something that academic researchers like Wustrow et. al would be very well-positioned to investigate. Highly recommend any of their papers, they make front page of HN surprisingly often. 0: https://ericw.us/trow/ https://ericw.us/trow/
megous 3y ago
From the PoV of the user it just looks like the website is broken. No exception in the console, contant reload looping of the same page, etc.
alex7734 3y ago
> Why? Because telling a bot they've failed tells them that they should stop trying something that's not working In my humble opinion if your bot is stuck in a CloudFlare loop for 10 minutes that's a pretty strong signal that something's not working...
- shadowgovt 3y ago
  While I'm inclined to agree, it's an old rule-of-thumb to give a potential attacker as little information as possible so they have to do the legwork to get un-broken. (I yearn for a world where auth challenge failures give proper error messages so I can figure out why my regular, human-used authentication channels aren't working).
- derefr 3y ago
  Keep in mind that a bot will be picking some permutation of its stock library of UA+metrics info, and generating truly-random values for other more continuously-valued parameters (e.g. timing between actions), to try to find a combination that satisfies a backend integrity-check. A "try again" just means "you haven't succeeded yet." If that's all you get, you're getting zero bits of new information — so you can't do anything other than to assume it was your timing that looked weird, and keep trying. (And you might be dealing with even more noise, e.g. trying to have the bot calibrate itself toward a very low human-tuned request rate limit, where above-rate-limit responses look no different than integrity-fail "try again" responses.) Suddenly getting a (maybe permanent) hard-fail, meanwhile, means that you said something the integrity-checker really didn't like. Presuming you have a lot of IP addresses to send requests from, you can then do many experiments to bisect the difference between a hard-fail and soft-fail, and use that to blacklist values from your UA+metrics library. It's free entropy!

by derefr 3y ago

johnklos 3y ago

How does that explain blocks that happen to less common browsers and/or less common platforms?

derefr 3y ago
Heuristics are about optimizing between false positives and false negatives. Many headless-browser stealth techniques involve rotating between the signatures and reflected metrics of real — but niche and/or ancient — User-Agents. (For some reason, the developers of these stealth systems think that variety beats commonality. Maybe it makes sense if they're specifically trying to overcome Apache mod_security's signature-based UA blocking or something.) It turns out that when you actually see one of these UAs in your server logs, it's far more (99.99%) likely to be a stealthed bot that picked that UA out of a bag, than it is to be an actual niche/ancient UA. In the case of the niche UAs, this is a tragedy of the commons. In the case of the ancient UAs, though, there's no downside to blocking them entirely — because if the traffic is going through Cloudflare at all, then you're already requiring of the client a minimum version of TLS that the real old UAs can't even speak. So the only things actually saying they're that old device — but managing to get through an HTTP request at all — are stealthed bots.
- runnerup 3y ago
  > Many headless-browser stealth techniques involve rotating between the signatures and reflected metrics of real — but niche and/or ancient — User-Agents I work in this space and we just use fingerprints we collect from actual users over the previous month. The hardest work is: 1) reverse-engineering the javascript of the CAPTCHA/fingerprinting solutions so that we can collect and encapsulate the fingerprints correctly in a way that looks native to cloudflare/recaptcha/etc, and 2) Training AI models to solve the captchas well enough. Sounds like most of the people you catch are using ancient user-agents. But I doubt most of the people you want to catch are.
  - derefr 3y ago
    I mean, when I'm talking about stealth techniques, I'm not talking about what I'm seeing in my own server logs, but rather about what I find built into various bits of, ahem, "anti-detect software for affiliate marketing" tech that I dredge up from fraud Telegram groups, carding marketplaces, etc. that the attackers I do catch seem to frequent. (Gotta stay five steps ahead!) I suppose there are verticals where the data is so valuable, and the garden around it so walled-in, that you could build a whole IT business with a custom scraping stack just around extracting that data to then resell it. (I presume that's the business you're in.) But for most verticals, the "attackers" you'll see in your logs aren't people building a data-broker business, and so aren't building their own secret-sauce anonymity from scratch; rather, they're end-users who want to do an end-run around your rate-limits, commit promotion fraud, etc., and so want to buy anonymity as a product, script-kiddie style. And "anonymity as a product", sold publicly (rather than through high-value contracts) tends to suck. It's script-kiddies buying from script-kiddies, with no real engineering in sight. > I work in this space and we just use fingerprints we collect from actual users over the previous month. Are you sure you're not in a citogenesis cycle? How sure are you that some of those "real users" aren't your peers' stealthed bots, who in turn picked up those fingerprints from unknowningly observing other stealthed bots in their logs, who...
    - runnerup 3y ago
      > Are you sure you're not in a citogenesis cycle? How sure are you that some of those "real users" aren't your peers' stealthed bots, who in turn picked up those fingerprints from unknowningly observing other stealthed bots in their logs, who... Doesn't matter, they work (at least when used in combination with high-quality proxy IP's). If they stopped working I'd do something else. We only apply hard science when absolutely needed, otherwise it's mostly wire and duct tape holding things together -- ruthless focus on creating business value. We definitely only sell this via high-value contracts, so you're probably mostly correct there. Though puppeteer-stealth deserves at least a quiet shout-out for not completely sucking. That said, we do pay attention to a lot of the research in the field, even if we only apply the absolute bare minimum needed to create business value. Eric Wustrow[0] at UC Boulder does really, really good work in an adjacent space, and we've found some his papers/software to be helpful, as well as those of some of the colleagues he works most closely with. I don't think he'd love our applications of his research, but our technological needs dovetail well with the needs of the anti-censorship research that he works on. If you were interested in the degree of "citogenesis", I think that's something that academic researchers like Wustrow et. al would be very well-positioned to investigate. Highly recommend any of their papers, they make front page of HN surprisingly often. 0: https://ericw.us/trow/ https://ericw.us/trow/

megous 3y ago

From the PoV of the user it just looks like the website is broken. No exception in the console, contant reload looping of the same page, etc.

alex7734 3y ago

> Why? Because telling a bot they've failed tells them that they should stop trying something that's not working In my humble opinion if your bot is stuck in a CloudFlare loop for 10 minutes that's a pretty strong signal that something's not working...

shadowgovt 3y ago
While I'm inclined to agree, it's an old rule-of-thumb to give a potential attacker as little information as possible so they have to do the legwork to get un-broken. (I yearn for a world where auth challenge failures give proper error messages so I can figure out why my regular, human-used authentication channels aren't working).
derefr 3y ago
Keep in mind that a bot will be picking some permutation of its stock library of UA+metrics info, and generating truly-random values for other more continuously-valued parameters (e.g. timing between actions), to try to find a combination that satisfies a backend integrity-check. A "try again" just means "you haven't succeeded yet." If that's all you get, you're getting zero bits of new information — so you can't do anything other than to assume it was your timing that looked weird, and keep trying. (And you might be dealing with even more noise, e.g. trying to have the bot calibrate itself toward a very low human-tuned request rate limit, where above-rate-limit responses look no different than integrity-fail "try again" responses.) Suddenly getting a (maybe permanent) hard-fail, meanwhile, means that you said something the integrity-checker really didn't like. Presuming you have a lot of IP addresses to send requests from, you can then do many experiments to bisect the difference between a hard-fail and soft-fail, and use that to blacklist values from your UA+metrics library. It's free entropy!