5 ms·
Good luck getting this adopted. A couple of months ago I was trying to responsibly disclose the complete exposure of every customer's name, email address, phone
by dsacco 9y ago
Good luck getting this adopted. A couple of months ago I was trying to responsibly disclose the complete exposure of every customer's name, email address, phone number and the last four digits of their credit card to a public QSR company that allows online orders. It was straightforward enough that I found it passively while trying to login.
It took over a week of me searching the website for a security page, trying to contact support on Twitter, emailing security addresses that turned out to be undeliverable, looking through my network for a contact, etc. Someone with a better network than me finally put me in touch with the right person in the security org, and the first response I received was, essentially, "Are you trying to sell us something? This seems manipulative. Why didn't you email our [undeliverable] address?"
As far as I'm aware, the vulnerability still hasn't been resolved. Here are the problems I see:
1. I don't know if this is a good implementation of this idea in the first place - how does this handle liability? I agree with what tptacek mentioned in this thread already: this seems underspecified, and companies looking to adopt this will want to have specific assurances with regards to liability and what's allowed. What exactly does "Disclosure Type: Full" mean?
2. If a company is not already in the tech trendy group that like to host security pages and use bug bounties, this is probably not even going to be on their radar. What is different about this that will appeal to them? How do you get a large, faceless organization which regards its security organization as more of a risk/compliance/continuity division than a technical software security division to adopt this standard?
To be clear, as someone who has gone through this song and dance several times, I absolutely would like to see improvements. But I don't know that this is the best way to do it. A more realistic standard might be a central tracker that maintains a list of key security contacts and their email addresses at various organizations. There are already lists like this floating around on GitHub, but they tend to be extremely out of date. Other than that it would be helpful to try and standardize a /security.html page with details about who and where to contact (instead of, say, a page that assumes every customer looking for a security contact mistakenly believes their accounts have been "hacked").
- freedomben 9y agoThis is utterly maddening. I had a similar experience, except that at first they didn't believe me regarding the vulnerability. I basically said, "cool, I'm glad it's not a problem, so when I release the deets and write up a blog post you have nothing to worry about ;-)" After they finally acknowledged the problem they started treating me like I was a criminal who attacked them. I strictly follow responsible disclosure, but it's crap like that that makes me want to reconsider sometimes.
- theyregreat 9y agoYup. They often claim you’re “malicious” to cover their incompetent butts. This is why reporting should be: - end-to-end encrypted with a brand new, limited-time GPG key - use a disposable email service - make up an alias - send from public WiFi at a coffeeshop some distance away that doesn’t have corporate CCTV - Don’t bother with Tor or a VPN because it advertises “suspicious behavior” across network hops that maybe/are monitored/logged If you volunteer information about your identity, it can be easily misused to attack you in a myriad of legal, professional, social media and other dirty-tricks ways.
- slipstream- 9y agoIMO, the problem with disclosure is one of the biggest problems with infosec right now...
- graystevens 9y agoAgreed regarding trying to get the information in front of the right people, or even just into the company. Recently been trying to contact 20-30+ companies regarding public exposure of private data, and I’ve had a real spectrum of results... Some had a bug bounty/disclosure program, and fixed it within minutes. Some had CERTs... who never acknowledged the email. Some didn’t have any public contact methods, so had to hunt for them via google. Some acknowledged the issue, removed the private data but didn’t fix the actual ‘hole’... On the whole, I spent more time trying to find contacts for websites, than actually finding the issue(s).
- akavel 9y agoHmm; I wonder, maybe in such case contacting some kind of national office which has the power to fine companies for breaching personal data protection laws could be an answer?
- theyregreat 9y agoAlso, a lot of companies/orgs deny vulnerabilities exist or even “shoot the messenger.” Reporting is often an inconsistent, chaotic gamble, which pushes more people to either not report the issue, give up or go black hat to monetize their findings.
- hannob 9y ago> Good luck getting this adopted. A couple of months ago I was trying to responsibly disclose the complete exposure of every customer's name, email address, phone number and the last four digits of their credit card to a public QSR company that allows online orders. It was straightforward enough that I found it passively while trying to login. If I may give a hint: Sometimes a good way to handle such issues is going through the media. (I've handled such things in the past, you can mail me if you want, but I don't want to see this as self-advertisement. I guess there are plenty of other Journalists covering IT security who are willing to handle such issues as well.)
- mgkimsal 9y agoI had 2 instances of this sort of thing back in ... 99 or 2000. One in particular was a pretty explicit disclosure in Ameritech's online phone bill viewer. (I think this was 2000?) ameritech.net/viewmybill.do?foo=bar&x=y&sessionid=xpq82947wrwd&billid=8394810 Change billid to 8394811... you're seeing someone else's bill. Tried to contact Ameritech for a couple of days... got nowhere. Had a friend with connections at a major news network, and sent some example links (should have sent screenshots?), but he waited too long to click and the session id had timed out, and he wrote back and said to stop wasting his time. I ended up connecting with some consumer advocate with a passion against ameritech - he owned 'fuckameritech.com' and he posted details of my exploit (although... without naming me as the reporter - still not sure if I should have pressed for that or not), and he contacted a bunch of Chicago-area media... and... something like 45 minutes after he posted that day their entire 'customer portal' was down for about 4 days. When it came back up, the new URL was something like ameritech.net/viewmybill.do?foo=bar&x=y&sessionid=xpq82947wrwd&billid=8628AWIEQIUASDASPDQKLMCLKALMCNMQWEOUGI8761238762139ewrdsfEIURHFDSKJBDOSIDSKJBFNBOIKJDNSFKJNSDFISODSOFU8321270r75123670124sfsdhlbhfuasbyrlewcbhrdkjsfhdsfer78984y32hrfdj....etc The bill ID was now something like 500+ characters long - probably a hash of something, but not as easily randomly guessable. IIRC, some versions of either netscape or IE had troubles with URLs that were that long, so whatever I was using I needed to switch to a different browser. If you're the guy who ran fuckameritech, thanks for helping get that out. :)
- kseifried 9y agoIt doesn't handle liability, and really nothing does other than the company in question doing the right thing (e.g. running a bug bounty via a well known third party and signing legal docs, or making public statements backed with documents. Also Occams razor, a lot of websites are hell to navigate and find the security reporting contact information. Why not make it super easy?