Security.txt • Hacker News Board

Re: Security.txt

#121

Post by jph » Sat, Oct 07, 2017, 9:03 AM UTC

tptacek wrote: post #66

jph wrote: post #15

If you're considering this, please consider responsible disclosure steps. Here are ones I use with consulting clients. https://github.com/joelparkerhenderson/responsible_disclosur...

Please consider replacing the term "responsible disclosure" with "coordinated disclosure", and revise your steps accordingly. Non-coordinated disclosure isn't necessarily "irresponsible", and the suggestion that it is is frowned upon among serious testers, which are presumably the ones you want to attract with disclosure policy. And it's worth remembering that any kind of disclosure "policy" is a request for a favor…

Done. Thank you for the advice, and all your security work.

https://github.com/joelparkerhenderson/coordinated_disclosur...

If you have anything more you want in it, please let me know.

Re: Security.txt

#122

Post by hannob » Sat, Oct 07, 2017, 9:25 AM UTC

dsacco wrote: post #67

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…

> 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.)

Re: Security.txt

#123

Post by jpswade » Sat, Oct 07, 2017, 9:29 AM UTC

jph wrote: post #121

tptacek wrote: post #66

Earlier quoted context omitted.

Please consider replacing the term "responsible disclosure" with "coordinated disclosure", and revise your steps accordingly. Non-coordinated disclosure isn't necessarily "irresponsible", and the suggestion that it is is frowned upon among serious testers, which are presumably the ones you want to attract with disclosure policy. And it's worth remembering that any kind of disclosure "policy" is a request for a favor…

Done. Thank you for the advice, and all your security work. https://github.com/joelparkerhenderson/coordinated_disclosur... If you have anything more you want in it, please let me know.

Isn't responsible disclosure the aim here? I don't think substituting coordination for responsible is a sensible strategy for your project.

The coordination is inherit from the fact that they are honouring your disclosure policy. The word coordinated is redundant.

Objectively, it should be called a "security disclosure" policy.

Re: Security.txt

#124

Post by tomjen3 » Sat, Oct 07, 2017, 10:37 AM UTC

zaroth wrote: post #110

Canada wrote: post #107

Earlier quoted context omitted.

If I find a bug on my own I can do as I please with it. I have no obligation to inform the vendor. I can write an exploit and publish it, share it with my friends, or sell knowledge of it to whomever I please. The vendor has zero right to my work or to dictate what I do with it. There are few things more frustrating than dealing with a vendor that doesn't understand this. On the other hand, if I find something while…

The line is crossed if you attempt to market and sell it for illicit use, or a prosecutor thinks they can demonstrate that you did effectively that. See: recent case about the guy writing the remote system control software then became a popular hacking tool / RaT.

Just to clarify, he was not charged for writting the RAT, he was charged for maybe wanting to sell an exploit in some fashion, possibly to a third-party that wanted to sell it on.

IANAL: And the prosc has to prove that you intend or effectively did both market/sell and that it was for illegal use - selling information about an exploit in e.g Chrome is quite different if you try to sell it to the Chrome developers.

Re: Security.txt

#125

Post by clarry » Sat, Oct 07, 2017, 11:08 AM UTC

mad182 wrote: post #114

r3bl wrote: post #47

Earlier quoted context omitted.

> Also, Google has increasingly made it difficult to automate searches That's an understatement. Doing something as simple as inurl:"humans.txt" ...and consuming the first three pages showed me CAPTCHA. It was done via a browser, manually. Not all links were clicked.

Yep, I run across this often. Kind of funny that using a bit more advanced functionality instantly makes you suspicious.

A few years ago, my gmail account was suspended for suspicious activity after I sent two messages to verify that my own email server is working following some updates & configuration changes.

Since then, it's been hard to justify using gmail for anything serious.

Re: Security.txt

#126

Post by Canada » Sat, Oct 07, 2017, 12:43 PM UTC

chii wrote: post #120

Canada wrote: post #107

Earlier quoted context omitted.

If I find a bug on my own I can do as I please with it. I have no obligation to inform the vendor. I can write an exploit and publish it, share it with my friends, or sell knowledge of it to whomever I please. The vendor has zero right to my work or to dictate what I do with it. There are few things more frustrating than dealing with a vendor that doesn't understand this. On the other hand, if I find something while…

> If I find a bug on my own I can do as I please with it. only if your access to the vendor's systems wasn't precluded with an eula that you agreed to beforehand. I don't see company be stupid enough to not put in broad legal terms in the eula to prohibit this sort of penetration. But if you weren't given permission first (which may involve said eula) then that must mean you're accessing without permission - which is…

That argument doesn't hold up. If it did security researchers who publish findings in commercial products would all have been sued by now. Many countries have fair use exemptions to prevent copyright holders from engaging in the kind of abuse you describe.

Re: Security.txt

#127

Post by screwt » Sat, Oct 07, 2017, 1:15 PM UTC

Canada wrote: post #126

chii wrote: post #120

Earlier quoted context omitted.

> If I find a bug on my own I can do as I please with it. only if your access to the vendor's systems wasn't precluded with an eula that you agreed to beforehand. I don't see company be stupid enough to not put in broad legal terms in the eula to prohibit this sort of penetration. But if you weren't given permission first (which may involve said eula) then that must mean you're accessing without permission - which is…

That argument doesn't hold up. If it did security researchers who publish findings in commercial products would all have been sued by now. Many countries have fair use exemptions to prevent copyright holders from engaging in the kind of abuse you describe.

Yes - this does happen.

[1] https://www.cnet.com/news/dutch-chipmaker-sues-to-silence-se...

[2] http://www.eweek.com/blogs/security-watch/german-software-co...

[3] http://www.securityfocus.com/news/11259

[0] https://duckduckgo.com/?q=security+researcher+sued&t=ffsb&ia...

Re: Security.txt

#128

Post by mgkimsal » Sat, Oct 07, 2017, 1:51 PM UTC

hannob wrote: post #122

dsacco wrote: post #67

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…

> 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…

I 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. :)

Re: Security.txt

#129

Post by manigandham » Sat, Oct 07, 2017, 2:18 PM UTC

mzzter wrote: post #87

manigandham wrote: post #81

Earlier quoted context omitted.

You needed to contact 100k sites about security? Do you have more details on this? The example security.txt for this site currently has a twitter handle as the contact. How are you going to automate that?

One may want to notify many website owners at once that it’s a good time to apply a patch in response to a security vulnerability affecting a technology they are using. Ex: WordPress, node.js, MongoDB, etc.

There are 100s of millions of sites, who’s going to crawl all of them and send out alerts? How would you know what backend tech is being used?

Major risks and CVEs are already published in the appropriate news channels, which is far more efficient and effective.

Re: Security.txt

#130

Post by chii » Sat, Oct 07, 2017, 2:57 PM UTC

Canada wrote: post #126

chii wrote: post #120

Earlier quoted context omitted.

> If I find a bug on my own I can do as I please with it. only if your access to the vendor's systems wasn't precluded with an eula that you agreed to beforehand. I don't see company be stupid enough to not put in broad legal terms in the eula to prohibit this sort of penetration. But if you weren't given permission first (which may involve said eula) then that must mean you're accessing without permission - which is…

That argument doesn't hold up. If it did security researchers who publish findings in commercial products would all have been sued by now. Many countries have fair use exemptions to prevent copyright holders from engaging in the kind of abuse you describe.

> If it did security researchers who publish findings in commercial products would all have been sued by now.

they have the option - and some chose not to sue for either PR reasons and/or unlikely to recoupe anything from a researcher anyway, so rather not spend the cost.