You can like that or not, but if you’re in the position to be doing research like this, you really ought to know the basics of the law.
> His crime: he was tasked with looking into a software that produced way too many log messages.
The developer wasn't doing security research. It sounds like they just had a bug they were looking into. Connecting to the database and realizing what it is to immediately disconnect and report it responsibly shouldn't be something that comes with punitive measures. As another commenter pointed out, this incentivizes people to sell this knowledge to others who will actually "misuse" it.
Can you fix this bug? Sure, I'll be chilling on this sofa while you get me my access.
What's the difference. MAYBE I could see this as a violation of the ToS but It's a far cry from "hacking".
Having a password doesn't mean they were trying to keep people out. They shipped the password.
That's like going into a building and they HAND YOU a keycard, and say don't go anywhere you aren't supposed to. And then it's actually a master key. How do you even know that it's going to let you into places you aren't supposed to go.
I have creds to googles services but it only gives me access to MY stuff.
Morally is another question of course.
It's hard to see his behavior as merely negligent when he knew the server he was connecting to didn't belong to his client (even if he thought it only had his client's data on it) and used credentials he only found by analyzing the software itself. I don't think he had malicious intent but it can easily be called reckless behavior.
Remember that he wasn't testing the software for security issues. He was hired by a user of the software to find out why it had undesired behavior (producing too much log output). He discovered the security issue accidentally while already illegimately accessing the software provider's servers.
To add to the pile of strained analogies: imagine you have stored things in a self-storage warehouse and the company that runs the place has given you a token fob to hand the receptionist whenever you want to access your stuff. The fob can easily be opened to allow replacing the battery. You decide to open the fob yourself and find a keycode inside of it. Outside business hours you go to the warehouse and enter the keycode yourself because you want to check on your stuff. But once inside you find that all the storage containers are ajar and have no locks and anyone with one of the token fobs could use the keycode printed inside of it to access anyone else's stuff if they visit outside business hours and use the keycode themselves.
You can argue you just wanted to access your stuff but by opening the fob (viewing the software file in an editor), noting down the keycode (copying the credentials), visiting outside business hours (opening a manual database connection) and then entering the building to find your storage container (running queries yourself) you have clearly crossed a line even if you didn't intend to access anyone else's stuff.
Basically there are two separate things at play here:
- The contractor analyzed the software in a primitive way to find a connection string to a server not operated by his client and decided to try it out and go spelunking despite knowing it was operated and owned by a third party.
- While doing so he found out that the connection string allowed him to gain access to other customers' data and a lot of end user data he didn't expect to be in that database, which he reported to the software company as a security issue.
The software company was clearly negligent and may have run afoul of privacy laws, risking a fine. But the contractor also gained illegal access to a computer system and used that access to go spelunking. The latter is what the court case is about.
And if you went somewhere you're not supposed to and found out it's a master key by trying it in those places you're not supposed to access, you'd be accused of trespass.
It's okay to argue that the punishment is excessive or that the law should factor in malicious intent more but the law is pretty clear and his behavior wasn't innocent white hat hacking even if he meant no harm.
> MAYBE I could see this as a violation of the ToS but It's a far cry from "hacking".
Maybe? How about definitely. He didn't use the app for its stated purpose, he extracted the credentials and then used them manually. That's a clear ToS violation at least. That this isn't a sophisticated hacking attack doesn't mean it is legal. You can argue it should be but it's easy to see why it isn't even if you just consider property law.
Actually the only problem with the law in my eyes is that it doesn't distinguish very well between malicious abuse (i.e. abuse with the intent to cause damage or impact security) and non-malicious abuse (e.g. building an unauthorized third-party client) and that it doesn't have special provisions to protect security research akin to whistleblower laws.
Hard no. That analogy fails because all the contractor needed to type was `SHOW DATABASES` which would be the same as looking around and seeing everyone else's stuff just sitting around in piles, completely unsecured.
If you rented a storage room and the place was so lazy as to use one key for all the doors, that would be one thing, but in this case the storage facility used the same key for all the doors and also completely lacked interior walls to separate people's stuff into individual rooms.
No, what the contractor needed to do was extract those credentials, create a manual connection and manually execute arbitrary queries. Not one of these three steps is part of how the database was meant to be used (i.e. specifically through the use of the software).
Also, again: I'm not arguing that the company's security practices were in any way acceptable. But that doesn't mean what the contractor did was in any way authorized behavior. That you can doesn't mean you're allowed to.
The vendor of that connector then issued a new client that used TLS, which he also circumvented to show that the issue is still valid. He is also accused of decompiling the client software to obtain the password. IIRC, he instead claimed to just have opened the file in notepad.
Yeah, my sympathies just evaporated. He crossed a line when he used the credentials he didn't have legitimate access to. But then he kept running. At that point how he exactly gained access to the credentials is almost irrelevant.
AFAIK he did not mention if he created the hashes using the DB or locally. I suspect that he used a built-in function of MySQL to hash the data on the server.
I can't break into an AWS data center to access my data, even if I they didn't have any security and I knew exactly where my data is stored. Not because I could be seeing other people's data but because I'd be trespassing.
I have done exactly the same thing in similar circumstances – I had a desktop software vendor that we had issues with, saw the config files stored database credentials in plaintext and connected to it. In my case, the database was single tenant for our company so I managed to get what I wanted done.
Surely intent must come into play when it comes to applying the law in cases like this? It doesn't seem like the developer had any intent to access a restricted system.
I've read current government had some plans to fix it, but they have a lot to do at the moment.