In 2008, in Poland, a guy was accused of breaking past security of a computer system, by putting "' or 1=1" in an input field of a website. He was acquitted, and the court famously stated that "you can't break past something that doesn't exist".¹ Ideally, this kind of logic should work in other countries; but I'm not very optimistic.
That makes for a good soundbite, but it's not actually useful. You could say that about any exploit: if you get past security using it, security didn't exist, but you're still potentially doing something worth criminalizing.
I think a better solution would be to legally protect anyone that's honestly reporting a vulnerability; make companies liable for those vulnerabilities; offer a failsafe reporting mechanism to the government in place of the company, in case they just ignore it; and guarantee that reporting a vulnerability can't ever be used against you in any kind of criminal or civil trial.
> You could say that about any exploit: if you get past security using it, security didn't exist, but you're still potentially doing something worth criminalizing.
Criminalizing the act of exploiting someone's shitty security reminds me of how banks transfer the responsibility for their failure to properly vet the identity of someone they loan money to by calling it "identity theft."
If you design a website that solicits people to submit personally identifiable information, you should be the one held accountable when that information is vulnerable, and especially when it is utterly trivial to access it (such as in this case).
If someone steals a bunch of Social Security numbers using SQLI on an insecure website and sells them on the black market, should the intruder be held criminally responsible? Yes, in my book.
That's entirely on top of the website operator. There should be some liability there, IMO, but it's unclear to me how much.
Though I wouldn't mind a world where all personal data is viewed like a form of radioactive waste to be avoided at all costs, it's not obvious that that's what our legal system should encourage.
> That's entirely on top of the website operator. There should be some liability there, IMO, but it's unclear to me how much.
The minimum companies need to do is notify the affected consumers. I think we can all agree on this.
> Though I wouldn't mind a world where all personal data is viewed like a form of radioactive waste to be avoided at all costs, it's not obvious that that's what our legal system should encourage.
From a market perspective, as long as PII has intrinsic black-market value, people will want it. The government could tax the amount of PII a company might store, say, but the black-market wouldn't pay the tax, anyway.
Removing value from PII would mean removing convenience for the sake of security. So I can't get loans/credit card applications online anymore, etc.
If you are storing the property of others behind your door and you fail to properly secure the door you bear responsibility for that negligence aside and apart from the guilt of the thief.
Right. I have an analogy I prefer in many of the cases where there is a clear smell of gross negligence, which does seem to be most.
Consider if a bank that takes safety deposits has accidentally given open access to their vault to the street and none of their employees or customers seem to have noticed. You will get people oblivious, you'd imagine you'd get thieves in there, but you may get people just poking their head in in sheer wonder. Then you're going to get people who are slightly more curious as to how this bewilderment came to be.
I have been that latter person on two occasions. Once when a friend was restoring an e-commerce site from a backup (including customer details) and didn't initially see what was wrong with the backup being publicly accessible until I pointed out there was a link to it where the home page might once have been.
The second involved a university network outsourced to a multinational engineering firm; a DHCP server; Windows Vista's DHCP client; the DHCP broadcast bit and a power outage. I can't remember the specifics but I realised that I could restore connectivity to people who had mysteriously lost it by responding to their DHCP requests after relaying them to the real DHCP server and repeating the response as a broadcast. I was naturally cautious and gained permission from the laptop owners. I only realised the implications of what I could have done to everybody affected on the network after the fact.
If anybody ever wants a real-world example of how a MITM attack can be carried out by somebody other than a network admin, consider what would happen if your DHCP server didn't respond in the expected way and the client was waiting for a broadcast.
It is only recently that I realise how exposed I was. I had no ill intent, but was merely seeking a better understanding of the world as opportunities arose. The latter experience is deeply important on a personal level as it turned coding from something vaguely interesting but too difficult to do anything useful into something more like a microscope, telescope or oscilloscope to me.
The problem is that intent is hard to measure. In the mock trial that plays out in my head from time to time, was I poking my head around or casing the joint? I believe that the evidence could have pointed to either.
at the same time, it's possible for the website to do absolutely everything right and still lose a lot of information.
one reasonable solution is just to say tough luck, it's still your fault, and then every company dealing with sensitive information buys data-breach insurance, with the insurance company helping to vet and improve their systems and processes if they want. this arrangement is pretty common and i could imagine it becoming legally mandatory.
even if there's a real unavoidable zero day, still hold the company liable, make them use their insurance, and then let the insurance company sue whoever is really at fault to recover their losses.
>Criminalizing the act of exploiting someone's shitty security reminds me of how banks transfer the responsibility for their failure to properly vet the identity of someone they loan money to by calling it "identity theft."
"but you're still potentially doing something worth criminalizing."
I had a bit of a think about this. We have an input field, something that invites anything that one might type into it. The input field might constrain what is typed in and the programme behind it might decide to believe the content or not.
Does the input field make it clear that it considers some sorts of input as invalid? I can't recall seeing any login related field that specified its input requirements - that is sometimes part of the "security"(through obscurity) of such things.
IT related security as it relates to logins might be unfairly compared to a front door and keys and other physical security devices. However, few of us have access to enough steel and concrete and other fancy materials for physical security to make this comparison stand. We do have access to wealth of IT security which is freely available. It is bloody complicated but freely available. You do need to be able to sift the good advice from the bad but it is available.
The final bit of the puzzle revolves around responsible disclosure. This is not something you see in the world of safes and front doors. It is an established industry practice in IT, in an industry that is very, very young but one which moves very, very quickly.
Even if the login fields specify that unauth. access is naughty I would argue that given that the tools are freely available and that any reasonably competent developer should be able to sanitise input, then you can't complain if someone types in complete crap.
IT is still discovering Engineering but it has so many more resources for instruction and guidance than bridge builders and boiler makers had in the early days and it moves so fast. Do you have any idea how dangerous steam trains were in the early days? Steam is a bloody powerful thing under pressure. Do you have any idea about resonance and concrete cancer? IT is still having its Tacoma Narrows and ... hah ... Millenium Bridge (hard found lessons can be ignored to this day) things happen.
I'm no lawyer but I suspect the world of m'learned friends will catch up eventually. Until then we will read of silliness like this.
However, few of us have access to enough engineers and security experts and other fancy computer wizards for digital security to make this comparison not stand. We do have access to the legal system which is freely available.
Typically the main thing in anti-hacking laws is intent more than actual actions. So if a person by accident causes the system to fail, then they are not guilty, but if they intentionally input something that breaks things then they are guilty. These can be technically very similar events, but legally worlds apart. And if your input is 'or 1 = 1 then that is fairly strong indicator about your intent.
Your intent could be simply to find out whether you want to trust the website with your own information. Merely attempting an SQLI or an IDOR doesn't mean you have intent to download other users' information for your personal gain.
The question of intent would be about the access only (i.e. "did you intend to access data without authorization"), and does not extend to further motives of why you would be doing such access.
What I didn't put in my comment above was that a sufficiently competent engineer might be considered negligent if they failed to allow for say people typing any old rubbish in.
Have you ever jumped up and down on a bridge or other structure? You probably weren't deliberately testing its strength, just idly messing around. You certainly didn't want it to fail (but what if it did?) I'll put money on it that you have done this at some point in your life because we all have at some point.
Were you a hacker? Are you a criminal? What makes adding 'or 1=1' a hack/crack and mucking about? and at what point is it criminal to not be able to filter out crap on input?
The difference between jumping on bridges and SQLi is that at least in these parts of the world I would find it absurd to think that bridge would really fall by jumping on it; on the other hand anyone trying out SQLi knows that it can actually succeed, even with a quite high chance.
Also we have building codes etc that regulate construction work, which gives me such confidence on bridges etc, but there is not equivalent for computers. Maybe there should be (that is another discussion) but that does not affect people doing things today.
Furthermore, even in case of criminal negligence (/lack of due diligence or something along those lines) two wrongs do not make a right; abusing such negligence can still be illegal too.
"Also we have building codes etc that regulate construction work" by that statement I'll assume American.
Are you familiar with this: https://en.wikipedia.org/wiki/Millennium_Bridge,_London ? (also see Tacoma Narrows for the classic example - wind loading, rather than people but resonance is resonance). Bridges do fail when people jump up and down on them or at least cause resonance based effects by simply walking in lock step.
You might be unfamiliar with resonance, which is a right bugger to deal with but Sir NF and co designed a bridge which was a suspension(ish) job but looked flat. It looks lovely but I recall looking at it and having misgivings (easy to say now). To me it screamed transverse loading, which isn't the normal thing that an IT bod shouts about.
"Also we have building codes etc that regulate construction work ... but there is not equivalent for computers." - My point exactly. There should be, and then perhaps m'learned friends could then get involved to debate the matter with something to work with. At the moment it is bollocks.
If a person is alive, and invites people over, but does not frisk them. Is he not invited someone to stab him to death?
At some point there is reasonable expectation. On all websites worth their salt, input fields are labeled. An input field is not an open invitation to hack the system and bypass it's actual use.
Also, haven't people learned by now that debugging other people's systems can either be rewarded or punished? It's not worth it unless the company has very publicly stated a hack me invitation and reward system.
The analogy to front doors and keys is much more fair than you give it credit for. Do you walk around the neighborhood trying doorknobs to see if they're open? So don't try to exploit a site uninvited.
It was just that: an analogy, and a bad one. In the physical world you don't have Google knocking on the door and taking copies of your photo albums and the contents of your address books, filing cabinets and in return making you look at adverts. You can of course deploy a baseball bat (uBlock etc) for some small, conciliatory, relief at the ads but your data is no longer yours. Its not even the commons, to benefit us all. Your data is simply part of a bloody great marketing machine. Quite an efficient one.
Is https://www.shodan.io/ criminal? They twiddle the doorknobs in everyone's neighbourhood but at least they tell you what they are up to.
I don't understand where you fall on this. Where will the burden of responsibility fall (the 1=1 troll or the people who created the software)? Are you saying that in the same way there are licensed steam union people and inspectors the same will be true of software?
> I think a better solution would be to legally protect anyone that's honestly reporting a vulnerability; make companies liable for those vulnerabilities; offer a failsafe reporting mechanism to the government in place of the company, in case they just ignore it; and guarantee that reporting a vulnerability can't ever be used against you in any kind of criminal or civil trial.
This would also very useful for more generalised whistle-blowing too..
For general SQL injection attacks I can kinda buy the idea "you can't break past something that doesn't exist", but in this case specifically the SQL injection was used to break a login form. The login form definitely both existed and is something I'd consider security measure.
A contrived analogy, but it feels like acquitting a burglar because instead of picking the lock he just smashed the door in.
A better analogy could be he was going to pick the lock and found the door wasn't even closed.
In either case, the intent of the individual was obviously to get into the system without their knowledge. Which sadly means they have the right to prosecute him in most legal systems.
I like this, but imagine the door is open and you call out and nobody is home. Is it wrong to walk through the door and investigate this concerning situation? Even without an explicit invitation?
Either way, if the intent of the individual is malicious then a judge would most likely rule against them.
Your house and car locks are likely easily picked so anyone breaking into your car or home likewise shouldn't be found guilty of anything. All that security theater is fictitious so therefore laws against violating it shouldn't have any basis.
I'm not defending the Sentinel in any way, but maybe the author could've avoided downloading other people's passport information. An alternative way to confirm the vulnerability would have been to only access their own data from private mode or through VPN. That way they could prove that the vulnerability exists without getting implicated in an unauthorized access charge.
That's a great thought! I can see exactly how you got there. Surely the author could have proven their point just as effectively while still respecting all the privacy of others, right? Clearly Sentinel is a professional organization that would have responded appropriately!
What's unfortunate about this scenario is that it shows a company reacting in fear. We can see denial, minimization, legal threats, and attempts to silence. These are the signs of an immature organization that cannot be trusted to react professionally to the sort of approach you wisely describe.
Consider. I am a reasonable person under a lot of stress, betting a lot on technologies I don't fully understand or control. Some rando claims my technology is incredibly reckless with a lot of people's personal information, and their proof is that they can view their own docs. Of course they can see their own docs - that's the point! There's no issue here at all...
Does that sound like a plausible scenario to you? Because it's painfully realistic to me. There's a reason I use an identity that's difficult to trace to my legal self when reporting vulnerabilities to companies that I can't trust the maturity of.
Telegram is not the organization in question here - they were just named as a medium for communication about the organization that had the vulnerability.
This is why America is still behind in cyber security and cyber warfare. Instead of rewarding people like this and/or hiring them into the NSA, we punish them.
We have a long history of hiring thieves/hackers in professional security. Actually, for these guys a highly publicized criminal trial in which they serve time is just good marketing.
This was true when Law Enforcement had no idea what was going on. It is NOT true today, and thinking you'll get an employment deal is foolish.
If you need proof, go ask https://twitter.com/MalwareTechBlog what happened to him after kicking WannaCry in the teeth shortly after it became a big deal.
I wouldn't worry if I was the OP. By the way cryptocurrency and ICOs are progressing the odds are greater that they will be in handcuffs before the white hat.
I feel like people ought to be able to sue companies that store their private information in such insecure ways. Maybe that'd flip the balance on these gross cases.
Sigh. The old "expose the incremental primary ID of the record in the URL" thing again?! Shouldn't this be taught as a 'no no' in WebDev 101?
Happens at the top of the chain too, I remember back in 1999/2000 when the Australian government released their website to enable online registration of businesses for in new GST (Goods & Services Tax), it was discovered within a day that anyone could simple trawl through the site and increment the ID at the end of the URL to view the business (and bank) details of every single one of the thousands of business that had registered.
In fact, IIRC, someone wrote a script that trawled through the site and obtained the information for thousands of registrants and put it into a spreadsheet which he emailed to the Australian Tax Office as his evidence. I believe instead of being rewarded, he was reprimanded and warned for doing do.
someone wrote a script that trawled through the site and
obtained the information for thousands of registrants
Pro Tip for avoiding getting sued when you report a vulnerability: Tell them you made two accounts and managed to access one from the other, so you've proved the vulnerability without seeing any other customers' data.
If you download more private data than you need, you're liable to activate someone's oh-shit-is-he-blackmailing-us sense, sending them scrambling to defend themselves.
Don't just tell them you did, but actually create two accounts and only access your own data. Don't try to access others' data. When changing IDs try to stick to ones you know you own on other accounts. If you're lazily trying the ID "1" and it works, or for example you find a /list endpoint which outputs everyone's data, then stop there and report immediately before doing any further testing.
Financial companies are unlikely to be receptive to unsolicited penetration testing and more likely to come down hard because of a need to demonstrate compliance, the same goes for any healthcare related sites. There's a reason you rarely see them popping up on lists of bug bounty programmes.
> Shouldn't this be taught as a 'no no' in WebDev 101?
It kind of is, kind of isn't. Security approaches I have witnessed were always very cargo-culty. People were aware of the OWASP top 10 and the like and applied best practice recommendations they have read somewhere and were even written into internal project guidelines. But security was not applied holistically.
For example passwords are passed off to a library that used scrypt properly. But hand-rolled session management used regular string comparison for the token, which obviously is unsafe.
Similarly parameterized SQL queries were used instead string processing because that's the rule in the project documentation. But there were no rules about lucene queries and boom some devs started to do string processing on the queries again.
And every time I have to fight to get sane password policies. In one case they wanted to block copy&paste events in the login forms "for security reasons", but that would have made things more difficult for people who actually use password managers.
Of course not everyone is like that, it just that the 1-2 people who would know to spot such things are often tied up in organizational overhead and then things slip through reviews.
The "attack" (meh) is similar to weev's AT&T hack https://en.wikipedia.org/wiki/Weev#AT&T_data_breach but crucially, I think, OP can demonstrate good intent. (Or at least it doesn't seem that OP demonstrated bad intent. Weev downloaded lots of information and called journalists).
OTOH Sentinel Chain might have obligations regarding data breach (depending on where they are based) and they look Real Dumb right now. This might explain some of their aggressive response.
One of the reddit comments makes the (reasonable) point that OP (u/notarealhacker, presumably not a security pro) could have validated insecure access to just their own data from within some pristine sandbox environment. That's fair enough but when I see reports from actual security folks that IMHO go too far in this respect (the DJI bounty mess http://www.digitalmunition.com/WhyIWalkedFrom3k.pdf comes to mind) it seems hard to make that argument against a non-expert who appears to have acted in good faith.
It's not clear to me what jurisdiction @narh is in but here's to hoping a lawyer can mount a Good Samaritan defense if it comes to that.
I am surprised that people still report bugs when there isn't an official bug bounty/bug reporting program in place that explicitly promises to avoid legal action against anyone who reports while following the rules of the program.
When there's no such program in place you either move on or do your best to disclose as publicly and anonymously as possible (tip to journalists or, worst case, open a new twitter account while behind 7 proxies).
What exactly is a security professional? I'm CREST accredited - do I count? Perhaps. I'm quite handy in the ways of IT (been doing it for 25+ years) That does not have the same cachet as my Civil Engineering quali. that is accredited but not time served. I would probably still be trusted to design a (very small!) bridge or dam or road section. I can survey proficiently etc. In short I could probably still design stuff that people would be willing to put their lives on the line with.
What gives people the sense that a pro. is in charge of something in IT? IT buggered it up early on with "industry" qualis. MS with their MSCEs and all the other worthless crap.
We lurch from snag to snag. It is bloody ridiculous.
We need Engineers with a capital E to stand up and get a fucking grip.
1. Be proactive in the police investigation including with the prosecution. Help them to understand that lack of security does not mean you violated their security.
2. You're not dragging these guy's name through the mud hard enough. That should have been in the title of this post.
3. Now that the hack has been exposed to the public, you might as well tell everyone as far and as wide as possible. It's your duty to tell people their identities are at risk, and provide contact details so people can complain about their exposed personal data being leaked on the web.
Assuming the poster is telling the truth, and they only accessed a couple other download IDs to prove their point, then they will likely be ok. But if the poster instead wrote a quick script to wget incrementally to see how high they could go, then they have gone beyond simply verifying the vulnerability.
I recall a similar case where the person who found a vulnerability in a banking site was shocked that legal recourse was threatened. They were later shown to have enumerated all possible account details.
> I recall a similar case where the person who found a vulnerability in a banking site was shocked that legal recourse was threatened. They were later shown to have enumerated all possible account details.
That still leaves us in the position where they were better off stealing the details but keeping quite about the vulnerability. We really need to move to a point where there are zero disincentives to disclosure.
That bank deserves everything they get next time there is a problem.
A metaphor for you: If an individual finds that a door is unlocked, they should feel the right to search the whole house and catalog all the person's belongings?
I fully agree that there should be zero disincentives to RESPONSIBLE disclosure. Fully copying down a database, for example, to prove that there is weak authentication would not be responsible disclosure and opens the data to significantly more risk than the vulnerability alone did.
I made a comment in a similar that if you are going to do any door knocking make sure you understand the legal ramifications.
Also before you are going to blame the company their hands might be tied the PoC for the issue was accessing personal information which likely includes financial information and identity verification of other people.
It’s quite possible that it’s their legal obligation to report this to the authorities and likely also was the CYA legal advice given to them by their legal team.
Like sure you may think you did the right thing but the person who’s info you’ve downloaded might think differently.
While Sentinel is handling this in an extremely amateurish way, the way this was handled by the person reporting the bug also was done quite poorly.
1) He should have attempted to access his own data via an alternative method. He could do this via an incognito session and a proxy, or just tell them he checked with a different machine, etc. Or, at bare minimum, stopped after the first time. Instead, after the first check, he proceeded to download at least one and potentially two sets of people's information that he knew was intended to be confidential. After already confirming that this was broken. This isn't the right way to go about it.
2) This was discussed in a public communication medium when there was little time given for Sentinel to handle it. Public disclosure to force action is a valid strategy, but almost all professional security researches provide time for the company to resolve the issue, rather than doing it within a day.
3) The CEO's report that only 21 people were affected might be totally accurate - webserver access logs would make it quite simple to determine how many people had their data viewed by users other than themselves. Thousands of people being vulnerable does not mean thousands of people were affected by someone other than themselves viewing their data.
Primarily due to how 1) was handled, he 100% should be speaking with the relevant authorities. He now has confidential information about 2-3 individuals he should not have. If that information is used for fraudulent purposes, he should be on the radar of the authorities. He shouldn't be charged with anything just for having seen it, but we cannot let reporting a vulnerability be a get-out-of-jail-free card, otherwise you could exploit something for profit, and then report it, and have nothing happen. If he had only verified this happened with his own personal data, there would be no need for this, but that isn't how he handled it.
By no means am I defending Sentinel, we need to make sure that we also inform people on how to handle security issues like this /responsibly/ and without causing even more damage.
I could be mistaken, but it sounds like they messaged an admin, and did not publicly disclose it. (Other than messaging someone else about it?)
Honestly, it sounds like the person here isn't highly familiar with vulnerabilities or disclosure. They probably saw the ID and thought "huh I wonder if I can change that" and then tried two different numbers there. As you state, they should have stopped after one, but they probably didn't expect it to even work the first time.
His story has now changed - prior to the edit, he was directly linking to the telegram history and saying 'You can verify what I said about things here'
The person reporting the bug is not a professional bug hunter, he is a user.
About 1) - an incognito session wouldn't have had any impact on the situation. It's still the same IP the request comes form. Or a proxy? He's a user, not a security expert.
3) He didn't dispute that 21 people were affected. He disputed the number of 2000, because he tried numbers over 6000 - and since the id is apparently just an increment (which in itself is already a problem) the number is likely to be false.
From my POV he didn't do anything wrong. He noticed a possible bug, verified it and notified the company.
Quite on the contrary - if he _had_ used a proxy and the authorities would've started an investigation to follow all requests it would've looked a lot worse for him.
> The person reporting the bug is not a professional bug hunter, he is a user.
I am aware. This is why I said we need to make sure to attempt to inform people on how to handle these responsibly.
> an incognito session wouldn't have had any impact on the situation. It's still the same IP the request comes form. Or a proxy? He's a user, not a security expert.
An incognito session would mean he is not using his previous session to gain access. Authentication is more frequently tied to a session than an IP address - this is why you are still logged into HN if you change from your home network to a public wifi, or turn on a VPN.
He previously provided a link to a telegram chat specifically with 'You can verify what I said in the chat here'. He has since edited the post and is now claiming differently.
> He didn't dispute that 21 people were affected. He disputed the number of 2000, because he tried numbers over 6000 - and since the id is apparently just an increment (which in itself is already a problem) the number is likely to be false.
He disputed both.
>From my POV he didn't do anything wrong. He noticed a possible bug, verified it and notified the company.
Your POV is dangerous. I am not saying he needs to be blamed, but this is quite clearly the incorrect way to handle a data breach and we should educate people on how to do it better.
> Quite on the contrary - if he _had_ used a proxy and the authorities would've started an investigation to follow all requests it would've looked a lot worse for him.
Not if he only accessed his own data, which is part of my point. When looking for security holes or verifying they work you should /NEVER EVER/ purposefully access the data of anyone else. In some cases this is unavoidable - bugs can leak random data, you can't always set up a reproduction environment, etc - but in this case it was totally avoidable.
He should not be prosecuted. He should be educated. Everyone else should also be educated. The point isn't to berate him. He should be in contact with the authorities because he now has access to privileged information, and for all parties' good they need to be aware of who has access to that data so they know who they should speak to if it is used maliciously.
> An incognito session would mean he is not using his previous session to gain access. Authentication is more frequently tied to a session than an IP address - this is why you are still logged into HN if you change from your home network to a public wifi, or turn on a VPN.
Yes, that you were aiming at the authentication session hadn't come to my mind as the vulnerability was access without authorization. In the case of a private session or proxy he'd still require a spam mail, create a separate account etc.pp. to just test this explicitly.
> He previously provided a link to a telegram chat specifically with 'You can verify what I said in the chat here'. He has since edited the post and is now claiming differently.
That is indeed bad.
> He disputed both.
>> Later, The CEO, Roy Lai, confirms 'only' 21 people of 'over' 1000 were affected. I tried a fileId of over 6k and it works so you do the math, there were definitely more than 2k.
Unless he edited that as well he disputed the total, not the part.
> [...]
I concur, what seems to actually have happened is quite worse than the version I read.
>This is why I said we need to make sure to attempt to inform people on how to handle these responsibly.
Yup, just tack that onto the ever-growing list of security stuff to teach users. How's the level of security knowledge among the general population coming along, by the way?
It being a difficult task doesn't mean it isn't necessary. People have eventually learned, over time, all sorts of things that weren't particularly intuitive at first. The general population is now well aware that smoking is bad for you, even though it took literally hundreds of years to get to that point.
The sarcasm isn't even particularly witty, because no one is under any illusions that this is an easy task.
And fundamentally he did the most important thing: told them about it. They seem to have got the message that they needed to shut this thing down ASAP. It seems highly unlikely from the nature of the alleged negligence that they found this unauthorized access for themselves in the way they give the impression of.
The reddit post has been edited recently and takes away most of the content, but from the emails it definitely looks as if their "compliance team" is trying to scare.
My own personal experience having received many very scary letters is that it tends to be the ones that look the most terrifying that turn out to be the least to be feared, but there are definitely exceptions to this.
In any case, their message to the victims of their alleged negligence states that there was no malicious intent and should make any civil consequences rather difficult.
Most likely the KYC laws themselves forced Sentinel to report this case. If he admitted in writing he accessed another user's confidential documents, that constitutes a data breach. Pretty sure Sentinel has to report that in order to comply with the regulations.
The result should be that all vulnerabilities in this corporation's system should be sent anonymously to the public. They have shown manifest malice and contempt for security at multiple levels, so no kindness should be shown to them again.
As this is a shady coin offering, the veil should be pierced. The same discourtesy should be shown to future corporations run by the same people.
84 comments
[ 3.3 ms ] story [ 152 ms ] thread¹ http://prawo.vagla.pl/node/8154 (in Polish, sorry!)
I think a better solution would be to legally protect anyone that's honestly reporting a vulnerability; make companies liable for those vulnerabilities; offer a failsafe reporting mechanism to the government in place of the company, in case they just ignore it; and guarantee that reporting a vulnerability can't ever be used against you in any kind of criminal or civil trial.
Criminalizing the act of exploiting someone's shitty security reminds me of how banks transfer the responsibility for their failure to properly vet the identity of someone they loan money to by calling it "identity theft."
If you design a website that solicits people to submit personally identifiable information, you should be the one held accountable when that information is vulnerable, and especially when it is utterly trivial to access it (such as in this case).
If someone steals a bunch of Social Security numbers using SQLI on an insecure website and sells them on the black market, should the intruder be held criminally responsible? Yes, in my book.
That's entirely on top of the website operator. There should be some liability there, IMO, but it's unclear to me how much.
Though I wouldn't mind a world where all personal data is viewed like a form of radioactive waste to be avoided at all costs, it's not obvious that that's what our legal system should encourage.
The minimum companies need to do is notify the affected consumers. I think we can all agree on this.
> Though I wouldn't mind a world where all personal data is viewed like a form of radioactive waste to be avoided at all costs, it's not obvious that that's what our legal system should encourage.
From a market perspective, as long as PII has intrinsic black-market value, people will want it. The government could tax the amount of PII a company might store, say, but the black-market wouldn't pay the tax, anyway.
Removing value from PII would mean removing convenience for the sake of security. So I can't get loans/credit card applications online anymore, etc.
Consider if a bank that takes safety deposits has accidentally given open access to their vault to the street and none of their employees or customers seem to have noticed. You will get people oblivious, you'd imagine you'd get thieves in there, but you may get people just poking their head in in sheer wonder. Then you're going to get people who are slightly more curious as to how this bewilderment came to be.
I have been that latter person on two occasions. Once when a friend was restoring an e-commerce site from a backup (including customer details) and didn't initially see what was wrong with the backup being publicly accessible until I pointed out there was a link to it where the home page might once have been.
The second involved a university network outsourced to a multinational engineering firm; a DHCP server; Windows Vista's DHCP client; the DHCP broadcast bit and a power outage. I can't remember the specifics but I realised that I could restore connectivity to people who had mysteriously lost it by responding to their DHCP requests after relaying them to the real DHCP server and repeating the response as a broadcast. I was naturally cautious and gained permission from the laptop owners. I only realised the implications of what I could have done to everybody affected on the network after the fact.
If anybody ever wants a real-world example of how a MITM attack can be carried out by somebody other than a network admin, consider what would happen if your DHCP server didn't respond in the expected way and the client was waiting for a broadcast.
It is only recently that I realise how exposed I was. I had no ill intent, but was merely seeking a better understanding of the world as opportunities arose. The latter experience is deeply important on a personal level as it turned coding from something vaguely interesting but too difficult to do anything useful into something more like a microscope, telescope or oscilloscope to me.
The problem is that intent is hard to measure. In the mock trial that plays out in my head from time to time, was I poking my head around or casing the joint? I believe that the evidence could have pointed to either.
The question of liability is a whole other issue.
one reasonable solution is just to say tough luck, it's still your fault, and then every company dealing with sensitive information buys data-breach insurance, with the insurance company helping to vet and improve their systems and processes if they want. this arrangement is pretty common and i could imagine it becoming legally mandatory.
even if there's a real unavoidable zero day, still hold the company liable, make them use their insurance, and then let the insurance company sue whoever is really at fault to recover their losses.
Mitchell and Webb did a great sketch calling out exactly this: https://www.youtube.com/watch?v=-c57WKxeELY
"Sounds a bit more like a bank robbery..."
I had a bit of a think about this. We have an input field, something that invites anything that one might type into it. The input field might constrain what is typed in and the programme behind it might decide to believe the content or not.
Does the input field make it clear that it considers some sorts of input as invalid? I can't recall seeing any login related field that specified its input requirements - that is sometimes part of the "security"(through obscurity) of such things.
IT related security as it relates to logins might be unfairly compared to a front door and keys and other physical security devices. However, few of us have access to enough steel and concrete and other fancy materials for physical security to make this comparison stand. We do have access to wealth of IT security which is freely available. It is bloody complicated but freely available. You do need to be able to sift the good advice from the bad but it is available.
The final bit of the puzzle revolves around responsible disclosure. This is not something you see in the world of safes and front doors. It is an established industry practice in IT, in an industry that is very, very young but one which moves very, very quickly.
Even if the login fields specify that unauth. access is naughty I would argue that given that the tools are freely available and that any reasonably competent developer should be able to sanitise input, then you can't complain if someone types in complete crap.
IT is still discovering Engineering but it has so many more resources for instruction and guidance than bridge builders and boiler makers had in the early days and it moves so fast. Do you have any idea how dangerous steam trains were in the early days? Steam is a bloody powerful thing under pressure. Do you have any idea about resonance and concrete cancer? IT is still having its Tacoma Narrows and ... hah ... Millenium Bridge (hard found lessons can be ignored to this day) things happen.
I'm no lawyer but I suspect the world of m'learned friends will catch up eventually. Until then we will read of silliness like this.
However, few of us have access to enough engineers and security experts and other fancy computer wizards for digital security to make this comparison not stand. We do have access to the legal system which is freely available.
It is readily available but sadly we have to disagree on what "freely" really means.
Have you ever jumped up and down on a bridge or other structure? You probably weren't deliberately testing its strength, just idly messing around. You certainly didn't want it to fail (but what if it did?) I'll put money on it that you have done this at some point in your life because we all have at some point.
Were you a hacker? Are you a criminal? What makes adding 'or 1=1' a hack/crack and mucking about? and at what point is it criminal to not be able to filter out crap on input?
Also we have building codes etc that regulate construction work, which gives me such confidence on bridges etc, but there is not equivalent for computers. Maybe there should be (that is another discussion) but that does not affect people doing things today.
Furthermore, even in case of criminal negligence (/lack of due diligence or something along those lines) two wrongs do not make a right; abusing such negligence can still be illegal too.
Are you familiar with this: https://en.wikipedia.org/wiki/Millennium_Bridge,_London ? (also see Tacoma Narrows for the classic example - wind loading, rather than people but resonance is resonance). Bridges do fail when people jump up and down on them or at least cause resonance based effects by simply walking in lock step.
You might be unfamiliar with resonance, which is a right bugger to deal with but Sir NF and co designed a bridge which was a suspension(ish) job but looked flat. It looks lovely but I recall looking at it and having misgivings (easy to say now). To me it screamed transverse loading, which isn't the normal thing that an IT bod shouts about.
He (Sir Norman Foster) had a part to play in this beauty amongst others: https://en.wikipedia.org/wiki/Millau_Viaduct#/media/File:Via... - the WP article does not really do it justice at a glance.
"Also we have building codes etc that regulate construction work ... but there is not equivalent for computers." - My point exactly. There should be, and then perhaps m'learned friends could then get involved to debate the matter with something to work with. At the moment it is bollocks.
At some point there is reasonable expectation. On all websites worth their salt, input fields are labeled. An input field is not an open invitation to hack the system and bypass it's actual use.
Also, haven't people learned by now that debugging other people's systems can either be rewarded or punished? It's not worth it unless the company has very publicly stated a hack me invitation and reward system.
Is https://www.shodan.io/ criminal? They twiddle the doorknobs in everyone's neighbourhood but at least they tell you what they are up to.
This would also very useful for more generalised whistle-blowing too..
A contrived analogy, but it feels like acquitting a burglar because instead of picking the lock he just smashed the door in.
In either case, the intent of the individual was obviously to get into the system without their knowledge. Which sadly means they have the right to prosecute him in most legal systems.
Would he have been better off asking them first?
Either way, if the intent of the individual is malicious then a judge would most likely rule against them.
What's unfortunate about this scenario is that it shows a company reacting in fear. We can see denial, minimization, legal threats, and attempts to silence. These are the signs of an immature organization that cannot be trusted to react professionally to the sort of approach you wisely describe.
Consider. I am a reasonable person under a lot of stress, betting a lot on technologies I don't fully understand or control. Some rando claims my technology is incredibly reckless with a lot of people's personal information, and their proof is that they can view their own docs. Of course they can see their own docs - that's the point! There's no issue here at all...
Does that sound like a plausible scenario to you? Because it's painfully realistic to me. There's a reason I use an identity that's difficult to trace to my legal self when reporting vulnerabilities to companies that I can't trust the maturity of.
Consider Kevin Mitnick for example.
If you need proof, go ask https://twitter.com/MalwareTechBlog what happened to him after kicking WannaCry in the teeth shortly after it became a big deal.
If only there was a government protection agency in charge of investigating them... Oh, never mind: https://www.reuters.com/article/us-usa-equifax-cfpb/exclusiv...
Happens at the top of the chain too, I remember back in 1999/2000 when the Australian government released their website to enable online registration of businesses for in new GST (Goods & Services Tax), it was discovered within a day that anyone could simple trawl through the site and increment the ID at the end of the URL to view the business (and bank) details of every single one of the thousands of business that had registered.
In fact, IIRC, someone wrote a script that trawled through the site and obtained the information for thousands of registrants and put it into a spreadsheet which he emailed to the Australian Tax Office as his evidence. I believe instead of being rewarded, he was reprimanded and warned for doing do.
If you download more private data than you need, you're liable to activate someone's oh-shit-is-he-blackmailing-us sense, sending them scrambling to defend themselves.
Financial companies are unlikely to be receptive to unsolicited penetration testing and more likely to come down hard because of a need to demonstrate compliance, the same goes for any healthcare related sites. There's a reason you rarely see them popping up on lists of bug bounty programmes.
It kind of is, kind of isn't. Security approaches I have witnessed were always very cargo-culty. People were aware of the OWASP top 10 and the like and applied best practice recommendations they have read somewhere and were even written into internal project guidelines. But security was not applied holistically.
For example passwords are passed off to a library that used scrypt properly. But hand-rolled session management used regular string comparison for the token, which obviously is unsafe. Similarly parameterized SQL queries were used instead string processing because that's the rule in the project documentation. But there were no rules about lucene queries and boom some devs started to do string processing on the queries again. And every time I have to fight to get sane password policies. In one case they wanted to block copy&paste events in the login forms "for security reasons", but that would have made things more difficult for people who actually use password managers.
Of course not everyone is like that, it just that the 1-2 people who would know to spot such things are often tied up in organizational overhead and then things slip through reviews.
OTOH Sentinel Chain might have obligations regarding data breach (depending on where they are based) and they look Real Dumb right now. This might explain some of their aggressive response.
One of the reddit comments makes the (reasonable) point that OP (u/notarealhacker, presumably not a security pro) could have validated insecure access to just their own data from within some pristine sandbox environment. That's fair enough but when I see reports from actual security folks that IMHO go too far in this respect (the DJI bounty mess http://www.digitalmunition.com/WhyIWalkedFrom3k.pdf comes to mind) it seems hard to make that argument against a non-expert who appears to have acted in good faith.
It's not clear to me what jurisdiction @narh is in but here's to hoping a lawyer can mount a Good Samaritan defense if it comes to that.
When there's no such program in place you either move on or do your best to disclose as publicly and anonymously as possible (tip to journalists or, worst case, open a new twitter account while behind 7 proxies).
What exactly is a security professional? I'm CREST accredited - do I count? Perhaps. I'm quite handy in the ways of IT (been doing it for 25+ years) That does not have the same cachet as my Civil Engineering quali. that is accredited but not time served. I would probably still be trusted to design a (very small!) bridge or dam or road section. I can survey proficiently etc. In short I could probably still design stuff that people would be willing to put their lives on the line with.
What gives people the sense that a pro. is in charge of something in IT? IT buggered it up early on with "industry" qualis. MS with their MSCEs and all the other worthless crap.
We lurch from snag to snag. It is bloody ridiculous.
We need Engineers with a capital E to stand up and get a fucking grip.
IT is still young as a discipline. This is an emerging example of "industry practice".
2. You're not dragging these guy's name through the mud hard enough. That should have been in the title of this post.
3. Now that the hack has been exposed to the public, you might as well tell everyone as far and as wide as possible. It's your duty to tell people their identities are at risk, and provide contact details so people can complain about their exposed personal data being leaked on the web.
I recall a similar case where the person who found a vulnerability in a banking site was shocked that legal recourse was threatened. They were later shown to have enumerated all possible account details.
That still leaves us in the position where they were better off stealing the details but keeping quite about the vulnerability. We really need to move to a point where there are zero disincentives to disclosure.
That bank deserves everything they get next time there is a problem.
I fully agree that there should be zero disincentives to RESPONSIBLE disclosure. Fully copying down a database, for example, to prove that there is weak authentication would not be responsible disclosure and opens the data to significantly more risk than the vulnerability alone did.
Also before you are going to blame the company their hands might be tied the PoC for the issue was accessing personal information which likely includes financial information and identity verification of other people. It’s quite possible that it’s their legal obligation to report this to the authorities and likely also was the CYA legal advice given to them by their legal team.
Like sure you may think you did the right thing but the person who’s info you’ve downloaded might think differently.
1) He should have attempted to access his own data via an alternative method. He could do this via an incognito session and a proxy, or just tell them he checked with a different machine, etc. Or, at bare minimum, stopped after the first time. Instead, after the first check, he proceeded to download at least one and potentially two sets of people's information that he knew was intended to be confidential. After already confirming that this was broken. This isn't the right way to go about it.
2) This was discussed in a public communication medium when there was little time given for Sentinel to handle it. Public disclosure to force action is a valid strategy, but almost all professional security researches provide time for the company to resolve the issue, rather than doing it within a day.
3) The CEO's report that only 21 people were affected might be totally accurate - webserver access logs would make it quite simple to determine how many people had their data viewed by users other than themselves. Thousands of people being vulnerable does not mean thousands of people were affected by someone other than themselves viewing their data.
Primarily due to how 1) was handled, he 100% should be speaking with the relevant authorities. He now has confidential information about 2-3 individuals he should not have. If that information is used for fraudulent purposes, he should be on the radar of the authorities. He shouldn't be charged with anything just for having seen it, but we cannot let reporting a vulnerability be a get-out-of-jail-free card, otherwise you could exploit something for profit, and then report it, and have nothing happen. If he had only verified this happened with his own personal data, there would be no need for this, but that isn't how he handled it.
By no means am I defending Sentinel, we need to make sure that we also inform people on how to handle security issues like this /responsibly/ and without causing even more damage.
Honestly, it sounds like the person here isn't highly familiar with vulnerabilities or disclosure. They probably saw the ID and thought "huh I wonder if I can change that" and then tried two different numbers there. As you state, they should have stopped after one, but they probably didn't expect it to even work the first time.
About 1) - an incognito session wouldn't have had any impact on the situation. It's still the same IP the request comes form. Or a proxy? He's a user, not a security expert.
2) He did report it to Sentinel directly over non-open communication channels: https://www.reddit.com/user/notarealhacker/comments/7vpfdl/i... This is also clear from the text, I don't know where you got that from.
3) He didn't dispute that 21 people were affected. He disputed the number of 2000, because he tried numbers over 6000 - and since the id is apparently just an increment (which in itself is already a problem) the number is likely to be false.
From my POV he didn't do anything wrong. He noticed a possible bug, verified it and notified the company. Quite on the contrary - if he _had_ used a proxy and the authorities would've started an investigation to follow all requests it would've looked a lot worse for him.
I am aware. This is why I said we need to make sure to attempt to inform people on how to handle these responsibly.
> an incognito session wouldn't have had any impact on the situation. It's still the same IP the request comes form. Or a proxy? He's a user, not a security expert.
An incognito session would mean he is not using his previous session to gain access. Authentication is more frequently tied to a session than an IP address - this is why you are still logged into HN if you change from your home network to a public wifi, or turn on a VPN.
> He did report it to Sentinel directly over non-open communication channels: https://www.reddit.com/user/notarealhacker/comments/7vpfdl/i.... This is also clear from the text, I don't know where you got that from.
He previously provided a link to a telegram chat specifically with 'You can verify what I said in the chat here'. He has since edited the post and is now claiming differently.
> He didn't dispute that 21 people were affected. He disputed the number of 2000, because he tried numbers over 6000 - and since the id is apparently just an increment (which in itself is already a problem) the number is likely to be false.
He disputed both.
>From my POV he didn't do anything wrong. He noticed a possible bug, verified it and notified the company.
Your POV is dangerous. I am not saying he needs to be blamed, but this is quite clearly the incorrect way to handle a data breach and we should educate people on how to do it better.
> Quite on the contrary - if he _had_ used a proxy and the authorities would've started an investigation to follow all requests it would've looked a lot worse for him.
Not if he only accessed his own data, which is part of my point. When looking for security holes or verifying they work you should /NEVER EVER/ purposefully access the data of anyone else. In some cases this is unavoidable - bugs can leak random data, you can't always set up a reproduction environment, etc - but in this case it was totally avoidable.
He should not be prosecuted. He should be educated. Everyone else should also be educated. The point isn't to berate him. He should be in contact with the authorities because he now has access to privileged information, and for all parties' good they need to be aware of who has access to that data so they know who they should speak to if it is used maliciously.
Yes, that you were aiming at the authentication session hadn't come to my mind as the vulnerability was access without authorization. In the case of a private session or proxy he'd still require a spam mail, create a separate account etc.pp. to just test this explicitly.
> He previously provided a link to a telegram chat specifically with 'You can verify what I said in the chat here'. He has since edited the post and is now claiming differently.
That is indeed bad.
> He disputed both. >> Later, The CEO, Roy Lai, confirms 'only' 21 people of 'over' 1000 were affected. I tried a fileId of over 6k and it works so you do the math, there were definitely more than 2k.
Unless he edited that as well he disputed the total, not the part.
> [...]
I concur, what seems to actually have happened is quite worse than the version I read.
6000 is over 1000. 10000 is over 1000.
If anything the CEO would want to increase the second number. 21 out of 1000 is a worse ratio than 21 out of 10000 :)
Yup, just tack that onto the ever-growing list of security stuff to teach users. How's the level of security knowledge among the general population coming along, by the way?
The sarcasm isn't even particularly witty, because no one is under any illusions that this is an easy task.
The reddit post has been edited recently and takes away most of the content, but from the emails it definitely looks as if their "compliance team" is trying to scare.
My own personal experience having received many very scary letters is that it tends to be the ones that look the most terrifying that turn out to be the least to be feared, but there are definitely exceptions to this.
In any case, their message to the victims of their alleged negligence states that there was no malicious intent and should make any civil consequences rather difficult.
As this is a shady coin offering, the veil should be pierced. The same discourtesy should be shown to future corporations run by the same people.
http://webcache.googleusercontent.com/search?q=cache:6ZVRmK2...
http://archive.is/j2Ucu
http://archive.is/LLyDe
http://archive.is/QNwiL