By James Wootton
I started to construct this opinion piece with the flame of righteous justice dancing over my sword of indignation, ready to smite another researcher not subscribing to established responsible disclosure procedures. These are individuals who throw scraps to the army of ‘script kiddies’ eagerly waiting for their next feeding frenzy. Any vulnerability quickly becomes a major headache once it becomes embedded in a tool such as Metasploit, making the vulnerability easy to exploit by the unsophisticated masses.
So, what got my goat? The release of the latest D-Link router vulnerability. You know, the one where another vendor’s coding and quality practices have been questioned, received with the usual wailing and gnashing of teeth from the press; salivating as we head one step closer to the end of the world! In reality, this back-door faux pas actually occurred over three years ago, and has almost certainly been enjoyed by elements of the hacking community during that time.
In simple terms, the vulnerability seems to have been a cataclysmically senseless method of allowing software to update the configuration of the router automatically, without the need for such pesky things as usernames and passwords. One ‘tiny’ side-effect of this obfuscation allows an attacker to gain unauthenticated access to the configuration software of the router and the ability to modify it. This is bad, but before your state of shock leaves the rich tea biscuit dunked too long, there are mitigating circumstances.
The configuration software is only exposed to the internal interface of the router and safe from the reavers of the internet. But wait, before we all whoop, high five and declare “Good Job!”, it is safe only until someone clicks the tick box on the configuration page, exposing it to the internet. Alternatively, if one of your internal PC’s is compromised through the myriad of methods available to the wiley hacker, they could then leverage this, creating a much easier route into your network.
Having examined the evidence, I’m afraid I must extinguish the flames of righteous justice, and sheath the sword of indignation – on balance, the pointy finger of blame must firmly be levelled at the vendor for poor coding and security practices. Let’s examine the rights, the wrongs and in my opinion, what I suggest should have happened in the realm of responsible disclosure.
Firstly, I want to make it clear that I subscribe to the principles of responsible disclosure. A hardware or software vendor should be given the chance to recognize the error(s) of their ways and be provided with a grace period in which they can make amends through the creation and issue of a patch, or take other mitigating steps (and I mean real steps, not simply ‘spin’). Following this, there should be a period of time to allow customers and users to update and remove the vulnerability from their instance of the product. It is here that the vendor should be proactive and contact all customers and perhaps limited disclosure from the researcher, indicating the issue, but not the mechanics.
“But what of this case?”, I hear you cry!
Looking at the researcher’s website, there’s no doubt that his reverse engineering and commentary on the vulnerability are well thought out, going much further than the usual exposed utilities within the device’s firmware. In doing such a grand job, and letting the cat firmly out of the bag, he’s released yet another exploit into the realms of the script kiddie, sadly this one is so simple, it’ll take little thought from the average jack-the-lad to exploit. Score so far: –10 Researcher, 0 Vendor.
The vulnerability has been publicly discussed and a record of this has been available for over three years! This should have been sufficient time for the vendor to audit its code and review its software design lifecycle and should have decided that on the whole, leaving secure design to luck, or adopting a security through obscurity posture isn’t going to win you customers. Score so far: –10 Researcher, –10 for each year the vulnerability was present, –30 Vendor.
If a vendor chooses not to play ball, maintains radio silence, or refuses to acknowledge the vulnerability or overruns the grace period, then after fair warning, I believe they have forfeited their right to be treated as a responsible vendor and become fair game – hopefully being jolted into action by market forces. Existence of the vulnerability should be made public so that customers can make a judgement call as to whether they wish to continue their relationship with that vendor. In an ideal world, there would be the ability to declare a vendor negligent and hopefully open the way for criminal proceedings. Too heavy? I think not, what about safety critical systems or medical systems? I hope now you can see my point.
How much detail should the researcher reveal? Responsible disclosure would suggest that it should be just enough information to describe the issue without exposing the actual vulnerability – not always possible. In reality, I fear it depends upon just how much the researcher needs their ego massaging. It is here that it appears the lawyers are growing rich(er) because on the whole, the disclosure of vulnerabilities without prior contact seems to irk the vendor, whether they chose to acknowledge contact or not. There has to be a better method of arbitration available here.
The other side of the coin and one in my opinion vendors have got away with for far too long, is the condition of license and the appropriateness of the EULA. You, the consumer and user of the vast majority of software products have indemnified the vendors from all losses should the product not function as expected. Losses include revenue, data and probable side effects of Alien Invasion (the last, I added, but it wouldn’t surprise me; lawyers can be very tricksie!).
So in conclusion, an overzealous technical ego and failure to see ‘the bigger picture’ can leave responsible disclosure out to hang – along with the (at times innocent, as times not so) vendor and (always innocent) users.
Should any vulnerabilities discovered come as news to them, vendors really ought to be afforded the opportunity to rectify issues before the press and social media get involved – fair’s fair. However, in the case of D-link, three years was an ample amount of time to sort out its security. This complicates matters and illustrates a big problem – vendors are continuously shirking their responsibility when it comes to security because, for the most part, they can get away with it.
This leads me onto my next point – vendors can get away with it because we all (as consumers) let them. How many consumers go to the trouble of checking a vendors information security certifications before buying a product? Answer: not enough for the vendor to care. An academic and environmental activist called David Suzuki once said, “Our personal consumer choices have ecological, social and spiritual consequences. It is time to re-examine some of our deeply held notions that underlie our lifestyles.” I contend that in light of our rapidly and radically changing digital world, consumers lives have changed and as a consequence have become more vulnerable. It is time for them to exert their power – demanding more from vendors and in turn reducing their personal risk.
James Wootton is IRM’s Technical Director. Wootton has spent the past 20 years working in the information security industry. The majority of this time was spent working for CESG – The UK Government’s National Technical Authority for Information Assurance. He possesses an expert and unparalleled level of skill within the technical assurance field and is responsible for the successful execution and delivery of all of IRM’s consultancy services and managed network forensics tool, NetFACTS.