What about security researchers scanning for their research? What about scanners that notify you?
Should hack-back be legal?
11–17 of 17 posts
Re: Should hack-back be legal?
#12- you don't know "who" you hit. The case in TFA is still rather simple (just send the "hack" as the response), but you will still most likely hit some residential proxy and nuke some random person instead of the responsible actor - (this is not too related to TFA but a point in discussions about hack-backs on a state-actor level) unless you're doing a very simple "attack", you need to have some sort of vuln ready to perform any kind of hack-back. Which leaves the ethical dilemma that actors are now motivated to keep vulnerabilities available, thus making the world more unsafe. And once you have used your vulnerability, your "enemy" probably knows it as well.
Re: Should hack-back be legal?
#13> Legitimate use cases, including security research, web archiving, and search engine crawling, can be distinguished from credential scanning by scope and target: no valid automated process needs to probe arbitrary third-party servers for .env or .git files. What about security researchers scanning for their research? What about scanners that notify you?
Re: Should hack-back be legal?
#14I think you’re fine, which hacker is going to go to the police about it?
If the hacker is any good, they'll be using other people's machines. this means that you could be triggering legal fun™
Re: Should hack-back be legal?
#15> Legitimate use cases, including security research, web archiving, and search engine crawling, can be distinguished from credential scanning by scope and target: no valid automated process needs to probe arbitrary third-party servers for .env or .git files. What about security researchers scanning for their research? What about scanners that notify you?
Namely, that if "common sense" is enough to prevent someone from suffering any injury from a booby trap even when they do trigger it, then it's not really a "booby trap" in the classical definition. It's just an object with dangerous edge-cases.
In the literal booby-trap case, you might picture, say... a garden hose.
It would be hard to imagine someone being harmed by "normal" use of a garden hose. Most ways to engage with it wouldn't result in any harm. You could turn it on, maybe get a bit wet or lashed if the hose whips around as it stiffens. Point it at yourself and use it to wash yourself clean. Maybe point it in your mouth and choke.
The only clear way to harm yourself with a garden hose, would be to put the hose in your mouth and then turn it on. And then to not remove the hose when you begin to feel very, very uncomfortable.
And that's very silly! Why would you do that? You could have stopped drinking from the hose at any time!
A garden hose has a dangerous edge-case: the water stream is infinite, and the hose fits in your mouth, and the internal stomach capacity of a human is finite. But it's an absurd dangerous edge-case. Nobody with common sense would encounter this edge-case. So a garden hose is not a booby trap. And an abandoned house with a garden house connected to a water supply, is not a booby-trapped house.
See what I'm getting at here?
You can give up and stop streaming (/ parsing / building-up-your-in-memory-ADT-from) an HTTP response that "just keeps going and going" at any time. And any vuln-scanning client programmed by someone with some common sense (e.g. a professional security researcher) would have that common sense built into it. So a 1TB .env-file HTTP response is not a booby trap.
And yet, of course, it will catch (and break) those "special" clients, built by people with no software-engineering common sense, i.e. script kiddies. But it's not your fault that some people have built deranged software that goes around wrapping its mouth around strangers' garden hoses!
Re: Should hack-back be legal?
#16Re: Should hack-back be legal?
#17> Legitimate use cases, including security research, web archiving, and search engine crawling, can be distinguished from credential scanning by scope and target: no valid automated process needs to probe arbitrary third-party servers for .env or .git files. What about security researchers scanning for their research? What about scanners that notify you?
Another approach would be not to make the files 1 TB in size, but only about 50 MB, while distributing them collectively. This would spread responsibility across many participants and reduce the individual burden of liability. If many users offered such files, automated scanners or bots would effectively end up cluttering themselves with useless data, without any single participant impacting the system to a degree that could be framed as deliberate destruction. [...] A possible safeguard for legitimate scanners would be to operate only within defined time limits or request quotas. In contrast, uncontrolled or unrestricted scanners would gradually overwhelm themselves with this distributed noise.