8 ms·

No, he was found guilty for using those credentials to connect to the database. I can’t speak for German law, but at least in the UK this would be an open-and-s

No, he was found guilty for using those credentials to connect to the database. I can’t speak for German law, but at least in the UK this would be an open-and-shut case, it’s a clear violation of the Computer Misuse Act. 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.

a_dabbler 3y ago
Sounds to me like the database credentials were embedded in the application so presumably the application would log in to the vendors server as an intended action. Does this mean all the vendors users must be charged with hacking also?
- HL33tibCe7 3y ago
  The clue’s in the name: “misuse”.
  - dzhiurgis 3y ago
    Is there evidence he misused the data or the server? Did he download all the data and sold to third parties, spammed the hell out of existing users or anything like that? How is verifying the credentials misuse?
    - HL33tibCe7 3y ago
      He didn’t just “verify the credentials”. He was in the database making queries, viewing private data.
      - feanaro 3y ago
        "Viewing" private data for purposes of verification of the issue. How about you just don't ship passwords in the application like some negligent troglodyte?
      - dzhiurgis 3y ago
        How do you find out it was private data without viewing it first? How is that misuse of data if you just view it?
        hnbad 3y ago
        Extracting credentials from a piece of software to manually connect to a server without authorization in order to go spelunking is clear-cut misuse regardless of what data you find on the server.
        the_why_of_y 3y ago
        The customer who hired this consultant was authorized to read that data because it was their data, not the vendor's; it was just stored on the vendor's server.
        hnbad 3y ago
        He was authorized to read that data. He was not authorized to freely access the server the data was stored on, or to extract the credentials from the software. This is an obvious difference that matters. 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.
malka 3y ago
Or you just could go the whole other way. Don't report. Sell.
- ipaddr 3y ago
  I wish more people would go the other way. Companies should hire people fulltime to find and report bugs.
from-nibly 3y ago
But turning on the app "uses" those credentials. so were all of their consumers guilty of hacking too? 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.
- HL33tibCe7 3y ago
  Sorry but you’re wrong. In the eyes of the law this is very clear cut. Morally is another question of course.
  - cortesoft 3y ago
    Is there no mens rea requirement in Germany?
    - hnbad 3y ago
      Mens rea is a factor in the severity of a crime. Also the prosecution argued that mens rea was established by his act of opening the software in a text editor to look for plaintext strings (which they incorrectly described as "decompiling" apparently). 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.
lcnPylGDnU4H9OF 3y ago
> research like this > 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.
- quickthrower2 3y ago
  Everyone coder in Germany should unionize and go on a password strike. Refuse to do any part of your job that requires authentication unless you have a signed written statement verified by a lawyer as to the scope and use of the access. And then only use that level of access. Can you fix this bug? Sure, I'll be chilling on this sofa while you get me my access.
nikeee 3y ago
I'm not sure whether it's that easy. AFAIK he had a customer that wanted him to investigate why the customer's system was flooded with some data. He ran the connector to some other service that the data seemingly originated from and observed a connection being opened to a remote MySQL server in plain text in his firewall. He took a look at this and saw that the credentials used were equal across all tenants of the MySQL DB. So it wasn't just his' customer's data that was exposed, it was the data of all tenants. AFAIK he then created some hashes of user data and exported this, so he could report this to the authorities and give users the ability to check whether they were listed in the system that had to be considered compromised. The DB exposed data of around 700k end users. He also contacted the company that runs that DB about this issue. 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.
- hnbad 3y ago
  So what you're saying is not only did he access the database without authorization, he also exfiltrated their customers' data and processed that? 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.
  - nikeee 3y ago
    > he also exfiltrated their customers' data and processed that? 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.
    - hnbad 3y ago
      Okay, then he only exfiltrated the hashes. Hashing on the server still constitutes processing though.
AtNightWeCode 3y ago
INTENT is the keyword for most laws. If the intent here was to check the security it is 100% legal within EU. Don't know about UK. I guess the guy poked around.
- oytis 3y ago
  The current German law says something different currently. Getting access to data by overcoming protection is a crime. It doesn't matter what you wanted to do with this data if anything at all. I've read current government had some plans to fix it, but they have a lot to do at the moment.
mpeg 3y ago
I wouldn't say it's so clear, if you read the article it seems like the developer was investigating an issue and found the database credentials, assumed the database connection was single-tenant (or that the user would be limited by permissions) as the software was connecting directly to it, and used them. When they realised they had access to more data than intended, they disconnected from it. 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.

a_dabbler 3y ago

Sounds to me like the database credentials were embedded in the application so presumably the application would log in to the vendors server as an intended action. Does this mean all the vendors users must be charged with hacking also?

HL33tibCe7 3y ago
The clue’s in the name: “misuse”.
- dzhiurgis 3y ago
  Is there evidence he misused the data or the server? Did he download all the data and sold to third parties, spammed the hell out of existing users or anything like that? How is verifying the credentials misuse?
  - HL33tibCe7 3y ago
    He didn’t just “verify the credentials”. He was in the database making queries, viewing private data.
    - feanaro 3y ago
      "Viewing" private data for purposes of verification of the issue. How about you just don't ship passwords in the application like some negligent troglodyte?
    - dzhiurgis 3y ago
      How do you find out it was private data without viewing it first? How is that misuse of data if you just view it?
      - hnbad 3y ago
        Extracting credentials from a piece of software to manually connect to a server without authorization in order to go spelunking is clear-cut misuse regardless of what data you find on the server.
        the_why_of_y 3y ago
        The customer who hired this consultant was authorized to read that data because it was their data, not the vendor's; it was just stored on the vendor's server.
        hnbad 3y ago
        He was authorized to read that data. He was not authorized to freely access the server the data was stored on, or to extract the credentials from the software. This is an obvious difference that matters. 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.

malka 3y ago

Or you just could go the whole other way. Don't report. Sell.

ipaddr 3y ago
I wish more people would go the other way. Companies should hire people fulltime to find and report bugs.

from-nibly 3y ago

But turning on the app "uses" those credentials. so were all of their consumers guilty of hacking too? 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.

HL33tibCe7 3y ago
Sorry but you’re wrong. In the eyes of the law this is very clear cut. Morally is another question of course.
- cortesoft 3y ago
  Is there no mens rea requirement in Germany?
  - hnbad 3y ago
    Mens rea is a factor in the severity of a crime. Also the prosecution argued that mens rea was established by his act of opening the software in a text editor to look for plaintext strings (which they incorrectly described as "decompiling" apparently). 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.

lcnPylGDnU4H9OF 3y ago

> research like this > 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.

quickthrower2 3y ago
Everyone coder in Germany should unionize and go on a password strike. Refuse to do any part of your job that requires authentication unless you have a signed written statement verified by a lawyer as to the scope and use of the access. And then only use that level of access. Can you fix this bug? Sure, I'll be chilling on this sofa while you get me my access.

nikeee 3y ago

I'm not sure whether it's that easy. AFAIK he had a customer that wanted him to investigate why the customer's system was flooded with some data. He ran the connector to some other service that the data seemingly originated from and observed a connection being opened to a remote MySQL server in plain text in his firewall. He took a look at this and saw that the credentials used were equal across all tenants of the MySQL DB. So it wasn't just his' customer's data that was exposed, it was the data of all tenants. AFAIK he then created some hashes of user data and exported this, so he could report this to the authorities and give users the ability to check whether they were listed in the system that had to be considered compromised. The DB exposed data of around 700k end users. He also contacted the company that runs that DB about this issue. 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.

hnbad 3y ago
So what you're saying is not only did he access the database without authorization, he also exfiltrated their customers' data and processed that? 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.
- nikeee 3y ago
  > he also exfiltrated their customers' data and processed that? 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.
  - hnbad 3y ago
    Okay, then he only exfiltrated the hashes. Hashing on the server still constitutes processing though.

AtNightWeCode 3y ago

INTENT is the keyword for most laws. If the intent here was to check the security it is 100% legal within EU. Don't know about UK. I guess the guy poked around.

oytis 3y ago
The current German law says something different currently. Getting access to data by overcoming protection is a crime. It doesn't matter what you wanted to do with this data if anything at all. I've read current government had some plans to fix it, but they have a lot to do at the moment.

mpeg 3y ago

I wouldn't say it's so clear, if you read the article it seems like the developer was investigating an issue and found the database credentials, assumed the database connection was single-tenant (or that the user would be limited by permissions) as the software was connecting directly to it, and used them. When they realised they had access to more data than intended, they disconnected from it. 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.