{"id":332,"date":"2017-07-27T14:40:58","date_gmt":"2017-07-27T14:40:58","guid":{"rendered":"http:\/\/securitycurve.com\/?p=332"},"modified":"2017-07-27T14:40:58","modified_gmt":"2017-07-27T14:40:58","slug":"how-i-learned-to-stop-worrying-and-love-the-vuln","status":"publish","type":"post","link":"https:\/\/securitycurve.com\/?p=332","title":{"rendered":"How I learned to stop worrying and love the vuln"},"content":{"rendered":"<p><img decoding=\"async\" class=\"alignright size-medium lazyload\" data-src=\"https:\/\/media1.giphy.com\/media\/ZN27DJIXfb1SM\/giphy.gif\" width=\"264\" height=\"267\" src=\"data:image\/svg+xml;base64,PHN2ZyB3aWR0aD0iMSIgaGVpZ2h0PSIxIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciPjwvc3ZnPg==\" style=\"--smush-placeholder-width: 264px; --smush-placeholder-aspect-ratio: 264\/267;\" \/>This morning the always-exceptional Mike Mimoso over at the ThreatPost posted <a href=\"https:\/\/threatpost.com\/vulnerable-radiation-monitoring-devices-wont-be-patched\/126967\/\">this article<\/a> about research being discussed at BlackHat today. \u00a0The research highlights vulnerabilities in various radiation monitoring apparatus &#8211; you know, the kind used at power plants (for safety), border crossings, container terminals, and the like.<\/p>\n<p>On a personal note, allow me to comment that from experience, I&#8217;m glad these protections exist and are in place. \u00a0From my consulting days, I did various assignments that are germane to the usage of these devices&#8230; these devices help offset some pretty nasty risk scenarios.<\/p>\n<p>Anyway, the backstory on this is that a vulnerability researcher at IOActive found some issues in that radiation monitoring equipment. \u00a0Generally, they can be attacked. \u00a0Specifically, he found a hardcoded username\/password in one (yikes), a hardcoded encryption key in another (well hey now) and radio-frequency attacks that another is susceptible to (also not good).<\/p>\n<p>A researcher finding issues like these isn&#8217;t particularly surprising. \u00a0And, while the issues do highlight what has to be some pretty loose software controls at these manufacturers, bugs happen. \u00a0I think we&#8217;re all pretty prepared to forgive that. \u00a0What is noteworthy are the vendor responses. \u00a0Specifically, there were three different vendors impacted &#8211; each one apparently provided a different excuse for why they don&#8217;t consider the issue worth addressing:<\/p>\n<ul>\n<li>One vendor alleged that their monitoring devices are only installed in secure locations, so the hard-coded username and password in the device source wasn&#8217;t an issue.<\/li>\n<li>Another argued that trying to a patch would break a critical communications protocol the devices use, so they really can&#8217;t address the radio-frequency vulnerabilities in the devices.<\/li>\n<li>The last one said they don&#8217;t see the hard-coded encryption key used to protect the firmware from being changed as a security problem.<\/li>\n<\/ul>\n<p>Each of these responses is terrible in its own special way. \u00a0In fact, in aggregate, this is like a playbook for exactly what <strong>not<\/strong> to do when responding to a vulnerability researcher that has found some issue in your product. \u00a0Why? \u00a0There are a few reasons:<\/p>\n<ul>\n<li><strong>It&#8217;s terrible PR<\/strong> &#8211; it makes the organization look completely uninformed about security generally and hardening their product specifically. \u00a0If you&#8217;re in the business of providing a security tool, looking like you&#8217;re completely ignorant on the topic isn&#8217;t a great marketing strategy.<\/li>\n<li><strong>Negligence arguments<\/strong> &#8211; The second is that it sets you up for future claims of negligence should anything go wrong. \u00a0Here&#8217;s the deal: if you know about some issue and you claim that you&#8217;re not going to fix it, you better be right. \u00a0If you didn&#8217;t know about it, erring is human. \u00a0If you know about it and plan to fix it, you&#8217;re taking action regardless of how glacially slow you might be in doing so. \u00a0If you know about it and do nothing? \u00a0Well, IANAL, but seems to me someone could claim that&#8217;s negligent.<\/li>\n<li><strong>It&#8217;s a challenge to attackers<\/strong> &#8211; &#8217;nuff said. \u00a0People who disagree with your &#8220;threat assessment&#8221; will likely want to prove you wrong&#8230; spectacularly and publicly.<\/li>\n<\/ul>\n<p>Look, here&#8217;s the deal. \u00a0Even if you&#8217;re evil, the right answer is still that you plan to fix the issue. \u00a0For example, let&#8217;s say that you&#8217;re Lucifer himself: you have absolutely no plan to address the issue and would prefer that the vulnerability researcher go pound sand. \u00a0What do you do? \u00a0Even in this case, the right answer is to acknowledge the issue, say thank you to the researcher and make nicey-nice, and then (once the pressure is off) you can take a million years to actually implement a fix. \u00a0Or never do. \u00a0For example, maybe you decide that the issue will be addressed in a &#8220;future firmware update&#8221; that just keeps getting delayed until the issue is OBE. \u00a0You get all the benefit of not fixing it, without impact to your business, marketing, or setting yourself up for future armchair quarterbacking.<\/p>\n<p>Let me be clear: I&#8217;m not recommending anybody do that. \u00a0I&#8217;m just saying that there&#8217;s a difference between &#8220;smart evil&#8221; and &#8220;blundering evil.&#8221; \u00a0Not fixing it and instead arguing that the problem doesn&#8217;t exist in the first place? \u00a0Never a good idea.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>This morning the always-exceptional Mike Mimoso over at the ThreatPost posted this article about research being discussed at BlackHat today. \u00a0The research highlights vulnerabilities in various radiation monitoring apparatus &#8211; you know, the kind used at power plants (for safety), border crossings, container terminals, and the like. On a personal note, allow me to comment [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_et_pb_use_builder":"","_et_pb_old_content":"","_et_gb_content_width":"","footnotes":""},"categories":[4],"tags":[114,126],"class_list":["post-332","post","type-post","status-publish","format-standard","hentry","category-security","tag-strangelove","tag-vulnerability-research"],"_links":{"self":[{"href":"https:\/\/securitycurve.com\/index.php?rest_route=\/wp\/v2\/posts\/332","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/securitycurve.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/securitycurve.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/securitycurve.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/securitycurve.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=332"}],"version-history":[{"count":0,"href":"https:\/\/securitycurve.com\/index.php?rest_route=\/wp\/v2\/posts\/332\/revisions"}],"wp:attachment":[{"href":"https:\/\/securitycurve.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=332"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/securitycurve.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=332"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/securitycurve.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=332"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}