4 ms·

> Just because something is connected to the public internet doesn't mean that you can hack it. I never said or implied that. All I said is, because all of my

> Just because something is connected to the public internet doesn't mean that you can hack it. I never said or implied that. All I said is, because all of my conduct involved publicly accessible components of their web application, I never exceeded authorized access. Which means that the CFAA's clause about "unauthorized access" in particular does not apply, since none of my packets exceeded or bypassed an authentication or authorization control on their web app. > Most homes are accessible from public roads, that doesn't mean you are allowed to climb through any open window that you see. A better analogy is knocking on someone's door, only to discover it swings open, then walking away. And then getting charged with breaking and entering for their failure to shut their door, and then paying for damages for leaving a muddy footprint on their exterior welcome mat. > You used a vulnerability to hack into some server associated with the FBI, I don't see any ambiguity here. I won't argue that I'm fully without blame. The mistake I made during all of this was, upon discovering they were running an outdated version of DotNetNuke (right click > view source; not exactly something I had to go out of my way to detect), I panicked. And to assuage my own anxiety, I tested the file upload to confirm that it was real. That was the mistake that let them prosecute me at all. And it's a mistake I have learned from: In the years since, I have never sent a packet with security implications to another network even for projects with a public bug bounty. I constrained myself henceforth to reviewing source code and reverse engineering, since that doesn't involve sending packets over a network and invoking a law that was written before the concept of a public network existed. (And that law being problematic is my entire point in this discussion, not appealing for amnesty in the opinions of HN users. Anyone who decides to hate me won't be the first.) Even if I knew not to do that then, I still would have informed them of their vulnerability as soon as it was discovered. Because that was the right thing to do.

MaximumYComb 7y ago
Is obfuscation a type of authorisation? If you knowingly exploited a vulnerability to access a non-standard URL then it's pretty obvious you shouldn't have been there. This isn't you navigating to a websites home page, the information I've found reads the following for CVE-2008-6541: >Access Complexity Medium (The access conditions are somewhat specialized. Some preconditions must be satistified to exploit)
- CiPHPerCoder 7y ago
  > Is obfuscation a type of authorisation? No. And even if you tried to argue that, the exploit was public on exploit-db for years, and therefore the expected security from the broken obfuscation is zero bits; so in this case, it would not count. More pertinent: > Authentication Not required (Authentication is not required to exploit the vulnerability.)

MaximumYComb 7y ago

Is obfuscation a type of authorisation? If you knowingly exploited a vulnerability to access a non-standard URL then it's pretty obvious you shouldn't have been there. This isn't you navigating to a websites home page, the information I've found reads the following for CVE-2008-6541: >Access Complexity Medium (The access conditions are somewhat specialized. Some preconditions must be satistified to exploit)

CiPHPerCoder 7y ago
> Is obfuscation a type of authorisation? No. And even if you tried to argue that, the exploit was public on exploit-db for years, and therefore the expected security from the broken obfuscation is zero bits; so in this case, it would not count. More pertinent: > Authentication Not required (Authentication is not required to exploit the vulnerability.)