3 ms·
> Looking at what types of data you had access to wasn't required. Downloading plaintext passwords of other people is probably too far. Impacted users may need
by Topfi 3y ago
> Looking at what types of data you had access to wasn't required. Downloading plaintext passwords of other people is probably too far. Impacted users may need to be notified about a breach. If needed, create an account of your own and target only that.
I'd argue that it was absolutely necessary to gauge the severity of this misconfiguration and furthermore, that Chattr.ai must contact every affected user, not MrBruh.
Their configuration allowed anyone to create an account and access plaintext passwords. There is no telling whether and how many outside of this disclosure have previously accessed this information and may intend to use it. This was negligence of the highest order, and it shouldn't be on the one finding and reporting this issue to rectify it.
- 8organicbits 3y ago> absolutely necessary to gauge the severity of this misconfiguration Possibly. But what's the legal basis that allows random external parties to make that determination? Report the leaked credential, and let the company assess impact. The problem is that pivoting to accessing user passwords may cause the companies to spend money notifying customers and harm their reputation. If they want to pursue legal action, those are clear damages. > Chattr.ai must contact every affected user, not MrBruh. Agreed, a pentester directly contacting impacted users would increase the risk legal gets involved. > There is no telling whether and how many outside of this disclosure have previously accessed this information Typically the company would review logs to determine that.
- Topfi 3y ago> [...] may cause the companies to spend money notifying customers and harm their reputation. I'm sorry, but I don't quite understand. Are you saying that you feel a company should not notify customers when exposing passwords in plaintext and furthermore, that this fact alone isn't harmful to their reputation? Not notifying customers, in my eyes, would destroy any semblance of reputation further. > Typically the company would review logs to determine that. Again, do you believe in the competence of someone storing passwords in plaintext? Logs may be incomplete; even a more competent organization that stores credentials following proper procedures and lost a db due to specific phishing rather than such a major screw-up would be expected to contact every customer and advise them to change their credentials, for very good reasons.
- 8organicbits 3y agoI'm not really commenting on the company side, but yes: plaintext passwords are bad, companies should notify customers when legally required, and I'd like companies to go further. Legally, bypassing security controls, using credentials that are not yours, and accessing data without authorization is a crime[1]. I see no indication that this blog post was authorized. Others should not consider this blog post as a good approach. Look instead to bug bounty programs and stay in-scope. Often that means creating your own account and avoiding other customer's data. While it doesn't make a good blog post, I still emphasize that the author should have reported the leaked credentials and stopped. [1] varies by jurisdiction, I'm not a lawyer, etc.
- Topfi 3y ago> [...] reported the leaked credentials and stopped. But, and this can be a significant differentiator from a legal standpoint in multiple jurisdictions[0], they did not use leaked credentials, nor did they circumvent any barriers. They used a publicly accessible endpoint to create their own, completely new user that just had access rights from the get-go. [0] Sticking solely with US examples, most notably United States v. Auernheimer which was in part overturned on jurisdictional issues, in part due to the following: "We also note that in order to be guilty of accessing “without authorization, or in excess of authorization” under New Jersey law, the Government needed to prove that Auernheimer or Spitler circumvented a code-or password-based barrier to access. See State v. Riley, 412 N.J.Super. 162, 988 A.2d 1252, 1267 (N.J.Super.Ct.Law Div.2009). Although we need not resolve whether Auernheimer's conduct involved such a breach, no evidence was advanced at trial that the account slurper ever breached any password gate or other code-based barrier. The account slurper simply accessed the publicly facing portion of the login screen and scraped information that AT & T unintentionally published."
- zilti 3y agoThat is not just negligence, that is stupidity on an order of magnitude that the responsible people should never again be allowed to work on a software project.
- 8organicbits 3y agoEvery company I've worked for, and every pentest contract I've done has found plaintext passwords or credentials stored somewhere they shouldn't. It's unfortunately very common.
- Topfi 3y agoCustomer credentials as in this example? I'll be totally frank, I'm having some trouble reconciling that with Article 34 of the GDPR and 1798.150 of the CCPA. Do none of these organizations have EU/CA customers or is the approach they take to laws the same as the one they employ for database security?
- 8organicbits 3y agoLess common with things that are directly "customer passwords", but common with other credentials and customer data. Those laws require reporting about breaches and I know I get notifications about breached data somewhat often. Keep in mind, a good first step to improving security is to hire a pentester. So pentesters have a unique view into companies that are trying to improve. Often the starting place is quite poor. When I leave those contracts, to my knowledge, they are all on track to fix these sorts of defects.