5 ms·

The author of the article removed the disclosure timeline before this was posted to HN. The disclosure timeline was something around 5 business days before the

The author of the article removed the disclosure timeline before this was posted to HN. The disclosure timeline was something around 5 business days before the author posted this article. Extremely unprofessional and irresponsible. EDIT: Original timeline can be found at https://web.archive.org/web/20170116061303/https://finnwea.com/blog/stealing-passwords-from-mcdonalds-users https://web.archive.org/web/20170116061303/https://finnwea.c... 24 Dec 2016 17:27:56 GMT Reported the vulnerability to McDonald's via Twitter multiple times (no response). 28 Dec 2016 21:28:39 GMT Reported the vulnerability to McDonald's NL via mcdonalds.nl (they couldn't help). 28 Dec 2016 21:36:12 GMT Requested disclosure assistance on HackerOne (no response). 30 Dec 2016 13:04:32 GMT Reported the vulnerability to McDonald's via phone (they would contact me ASAP). 05 Jan 2017 23:31:42 GMT Public disclosure.

cocoa19 10y ago
What are your thoughts on what a professional and responsible disclosure time is?
- btreesOfSpring 10y ago
  Google in their "Disclosure timeline for vulnerabilities under active attack,"[0] states 60 days for disclosure for discovered security vulnerabilities and seven days for critical, currently known in-the-wild security bugs under active exploit. [0] https://security.googleblog.com/2013/05/disclosure-timeline-for-vulnerabilities.html https://security.googleblog.com/2013/05/disclosure-timeline-...
- EdHominem 10y ago
  Yeah, and it's absolutely uncorrelated to what the company feels comfortable with. Maybe 24h? If you can't respond and mitigate within that time frame you aren't operating on internet time. > From policy quote in sibling post: "[...] currently known in-the-wild security bugs under active exploit." Nonsense. Every bug you discover could have been discovered by an attacker, and attackers are constantly scanning. If the bug is in release software you have to assume it's known and being exploited. btw, for the downvoters - I know I speak the truth because I've worked dev in an internet-security company, and in security in a major cloud company. We can turn patches (or mitigations) out in hours and have them canaried and live in 24h. This is absolutely doable and should be expected. This months nonsense is when the company doesn't want to fix the bug. What it takes is the institutional will to disable a feature you bill for until you secure it. When a $millions/day loss is on the table you find that obstacles evaporate. If a company tries to keep their vulnerabilities under wraps there wouldn't be this cost, and thus no will to fix it, in an ever-worsening spiral.
- DonaldFoss 10y ago
  Much more than 12 days. Below is a copy/paste of a recent security vulnerability timeline: 2015-12-14 | me > dotCMS | 8 SQL injection vulnerabilities 2015-12-14 | dotCMS > me | they were planning fixes in upcoming release, estimated to beginning of 2016 2016-03-16 | dotCMS | dotCMS version 3.3.1 release (CVE-2016-4040 still not fixed) 2016-04-07 | me > dotCMS | what is the situation with reported vulnerabilities? 2016-04-07 | dotCMS > me | CVE-2016-4040 will be fixed in 3.5, which is estimated to be out in mid-April 2016-04-19 | dotCMS | dotCMS version 3.5 release 2016-05-10 | dotCMS | dotCMS version 3.3.2 release 2016-10-31 | me | Full Disclosure on http://security.elarlang.eu http://security.elarlang.eu Source: http://seclists.org/fulldisclosure/2016/Nov/0 http://seclists.org/fulldisclosure/2016/Nov/0 This timeline from first report to full disclosure was 10.5 months. Note that I did not go looking for a long timeline, this was the first item when I Googled "CVE disclosure timeline." --Donald
bruno207 10y ago
>Extremely unprofessional and irresponsible. Agreed, especially considering the timing with Christmas and New Years holidays, they probably could not get the word down to their engineering team.
- EdHominem 10y ago
  > >Extremely unprofessional and irresponsible. > Agreed How ungrateful. Someone puts in free work to make the world safer by fixing someone else's problems and they're a jerk because they didn't pamper them enough in the process. > considering the timing with Christmas and New Years holidays, they probably could not get the word down to their engineering team. Then this serves as a notice that they need to be able to - in about 15m, 365 days a year. Reality calling. fwiw, fixing a problem like this is almost always trivial. Not making the product bullet-proof, but simply disabling logins or whatever is needed to keep it from being exploited until it can actually be fixed. A change of mindset (and stopping blaming the researchers) is all it takes to go from a many-month patch cycle to shipping mitigations inside of 12h. Can you imagine a real engineer complaining about warnings, for instance that their bridge supports were crumbling, and how the discoverer didn't go through the reporting process.
  - hanspeter 10y ago
    > Can you imagine a real engineer complaining about warnings, for instance that their bridge supports were crumbling, and how the discoverer didn't go through the reporting process. In your example the engineer should then proceed to blow up the bridge all while road users are still on it.
    - EdHominem 10y ago
      I imagine they'd block it off and not let anyone drive on it. Or you know, murder. Maybe you're right.
jat850 10y ago
Not the author, but it was absolutely, definitely not removed before this article appeared on HN. It may have been removed afterwards, but when I read this article last night that timeline was there. It was even discussed elsewhere in this thread. No comment on the timeline itself.
dmix 10y ago
It was 12 days from his first attempt. It sounds like he had some trouble reporting it. Looks like he never received a call back so he decided to release it to the public. The timeline reads like he did it out of some spite. It would be frustrating to go through all of this free highly specialized work and not find someone who cares at McDonalds. But I'd at least give it a bit more time. Especially considering his first attempt at contact was around Christmas...
- DonaldFoss 10y ago
  I've worked with the McDonald's web team before. They do care about performance and security. I reverse engineered an undocumented (to them) protocol for a game system in order to write tests for it--which was really, super fun to watch run. McDonald's uses 3rd parties for most of their main development work. In the case above, the developers were in Australia, while McDonald's is in US Central Time and I was in US Eastern time. When I reported problems and provided suggestions, they usually had a conference call with McDonald's, the Aussie devs, and my team within 12 hours. If it was a weekend, it was Monday night. McDonald's core team takes this very seriously. The difference here was that I had all the right phone numbers and am known to them. I was working for a well known publically traded company, which carried weight by itself. I don't know that if I didn't have the right contacts, hadn't been to their HQ and met with the VP/IT and Director of Online, would they have taken what I said seriously? Secondly, this was the US Christmas and New Year's holidays. They were running a skeleton crew. As Adrian Cockcroft, former lead cloud architect at Netflix, once said, the time Netflix is the most stable is Christmas and New Year's because there aren't any engineers around. With all that, they need to take this as a wake-up call and have a security response system, even if they contract a 3rd party for that also. There must exist, or this is a nifty startup idea, 3rd party firms that go through security@company.com emails, including the reams of spam, and there should be an optionally anonymous security problem reporting form with a captcha to get information such as this to the right people. Lastly, 12 days is extremely short under any circumstance. While I'll admit that it can be extremely frustrating to not get a response, I believe 30-days should be the minimum time before first notification and publication with details. If a security firm wants PR for finding the problem, the post that there IS a problem first and wait the full 30-days from initial contact attempts before disclosing the details. --Donald

cocoa19 10y ago

What are your thoughts on what a professional and responsible disclosure time is?

btreesOfSpring 10y ago
Google in their "Disclosure timeline for vulnerabilities under active attack,"[0] states 60 days for disclosure for discovered security vulnerabilities and seven days for critical, currently known in-the-wild security bugs under active exploit. [0] https://security.googleblog.com/2013/05/disclosure-timeline-for-vulnerabilities.html https://security.googleblog.com/2013/05/disclosure-timeline-...
EdHominem 10y ago
Yeah, and it's absolutely uncorrelated to what the company feels comfortable with. Maybe 24h? If you can't respond and mitigate within that time frame you aren't operating on internet time. > From policy quote in sibling post: "[...] currently known in-the-wild security bugs under active exploit." Nonsense. Every bug you discover could have been discovered by an attacker, and attackers are constantly scanning. If the bug is in release software you have to assume it's known and being exploited. btw, for the downvoters - I know I speak the truth because I've worked dev in an internet-security company, and in security in a major cloud company. We can turn patches (or mitigations) out in hours and have them canaried and live in 24h. This is absolutely doable and should be expected. This months nonsense is when the company doesn't want to fix the bug. What it takes is the institutional will to disable a feature you bill for until you secure it. When a $millions/day loss is on the table you find that obstacles evaporate. If a company tries to keep their vulnerabilities under wraps there wouldn't be this cost, and thus no will to fix it, in an ever-worsening spiral.
DonaldFoss 10y ago
Much more than 12 days. Below is a copy/paste of a recent security vulnerability timeline: 2015-12-14 | me > dotCMS | 8 SQL injection vulnerabilities 2015-12-14 | dotCMS > me | they were planning fixes in upcoming release, estimated to beginning of 2016 2016-03-16 | dotCMS | dotCMS version 3.3.1 release (CVE-2016-4040 still not fixed) 2016-04-07 | me > dotCMS | what is the situation with reported vulnerabilities? 2016-04-07 | dotCMS > me | CVE-2016-4040 will be fixed in 3.5, which is estimated to be out in mid-April 2016-04-19 | dotCMS | dotCMS version 3.5 release 2016-05-10 | dotCMS | dotCMS version 3.3.2 release 2016-10-31 | me | Full Disclosure on http://security.elarlang.eu http://security.elarlang.eu Source: http://seclists.org/fulldisclosure/2016/Nov/0 http://seclists.org/fulldisclosure/2016/Nov/0 This timeline from first report to full disclosure was 10.5 months. Note that I did not go looking for a long timeline, this was the first item when I Googled "CVE disclosure timeline." --Donald

bruno207 10y ago

>Extremely unprofessional and irresponsible. Agreed, especially considering the timing with Christmas and New Years holidays, they probably could not get the word down to their engineering team.

EdHominem 10y ago
> >Extremely unprofessional and irresponsible. > Agreed How ungrateful. Someone puts in free work to make the world safer by fixing someone else's problems and they're a jerk because they didn't pamper them enough in the process. > considering the timing with Christmas and New Years holidays, they probably could not get the word down to their engineering team. Then this serves as a notice that they need to be able to - in about 15m, 365 days a year. Reality calling. fwiw, fixing a problem like this is almost always trivial. Not making the product bullet-proof, but simply disabling logins or whatever is needed to keep it from being exploited until it can actually be fixed. A change of mindset (and stopping blaming the researchers) is all it takes to go from a many-month patch cycle to shipping mitigations inside of 12h. Can you imagine a real engineer complaining about warnings, for instance that their bridge supports were crumbling, and how the discoverer didn't go through the reporting process.
- hanspeter 10y ago
  > Can you imagine a real engineer complaining about warnings, for instance that their bridge supports were crumbling, and how the discoverer didn't go through the reporting process. In your example the engineer should then proceed to blow up the bridge all while road users are still on it.
  - EdHominem 10y ago
    I imagine they'd block it off and not let anyone drive on it. Or you know, murder. Maybe you're right.

jat850 10y ago

Not the author, but it was absolutely, definitely not removed before this article appeared on HN. It may have been removed afterwards, but when I read this article last night that timeline was there. It was even discussed elsewhere in this thread. No comment on the timeline itself.

dmix 10y ago

It was 12 days from his first attempt. It sounds like he had some trouble reporting it. Looks like he never received a call back so he decided to release it to the public. The timeline reads like he did it out of some spite. It would be frustrating to go through all of this free highly specialized work and not find someone who cares at McDonalds. But I'd at least give it a bit more time. Especially considering his first attempt at contact was around Christmas...

DonaldFoss 10y ago
I've worked with the McDonald's web team before. They do care about performance and security. I reverse engineered an undocumented (to them) protocol for a game system in order to write tests for it--which was really, super fun to watch run. McDonald's uses 3rd parties for most of their main development work. In the case above, the developers were in Australia, while McDonald's is in US Central Time and I was in US Eastern time. When I reported problems and provided suggestions, they usually had a conference call with McDonald's, the Aussie devs, and my team within 12 hours. If it was a weekend, it was Monday night. McDonald's core team takes this very seriously. The difference here was that I had all the right phone numbers and am known to them. I was working for a well known publically traded company, which carried weight by itself. I don't know that if I didn't have the right contacts, hadn't been to their HQ and met with the VP/IT and Director of Online, would they have taken what I said seriously? Secondly, this was the US Christmas and New Year's holidays. They were running a skeleton crew. As Adrian Cockcroft, former lead cloud architect at Netflix, once said, the time Netflix is the most stable is Christmas and New Year's because there aren't any engineers around. With all that, they need to take this as a wake-up call and have a security response system, even if they contract a 3rd party for that also. There must exist, or this is a nifty startup idea, 3rd party firms that go through security@company.com emails, including the reams of spam, and there should be an optionally anonymous security problem reporting form with a captcha to get information such as this to the right people. Lastly, 12 days is extremely short under any circumstance. While I'll admit that it can be extremely frustrating to not get a response, I believe 30-days should be the minimum time before first notification and publication with details. If a security firm wants PR for finding the problem, the post that there IS a problem first and wait the full 30-days from initial contact attempts before disclosing the details. --Donald