By Simon Woodhead
As regular readers will know, we take security and privacy pretty seriously. You’ve seen our talks and research on VoIP fraud, discussions of infrastructure and even our book on telephony security.
Over the years, I’ve personally come to appreciate that security is one of those unusual fields where the more you learn, the more anxious you become. Unless you’re quivering in the corner of an underground Faraday cage, disconnected from everything, you probably have more to learn. Those who have any level of “comfort” around their security, are probably in denial.
Against that background, it was of no great surprise, but absolutely still alarming, to receive an email from a Security Researcher called Bob Diachenko advising of a vulnerability in the Simwood stack. Following a dialogue, it became clear that one of our former colleagues had installed a MongoDB instance in our lab with inadequate security. The lab is isolated and doesn’t contain production data so this wasn’t a concern. Or was it?
Frankly, a machine being in our lab is no excuse and we hold ourselves to a much higher standard. Yes, it is an isolated staging environment. Yes, colleagues of all skill levels have access to it to play and learn, and we want them to. Yes, looking around competitors, our lab is like Fort Knox by comparison to their production networks! Still no excuse, as we should be adhering to our production level standards for an area where things are developed to ultimately go into production, regardless of what others don’t do. Further, whilst we believe it is isolated (and it is even on a completely unique /24 not included in any of our production firewall rules), any lapse in lab security is relying absolutely on that being the case, which we shouldn’t.
This security researcher had used standard tools to discover the exposure without any actual “hacking” taking place. These tools are scanning the entirety of the internet and reveal lots about open (intentionally or otherwise) services. Those with malintent can use these as a search engine and can literally filter by specific exposures, e.g. open MySQL ports.
We do not want to be in the position others in our industry have found themselves, with an actual intrusion or data breach, and we view what perhaps others wouldn’t care about as having dodged a bullet. We need to raise the bar further. So, aside from further internal changes and more in the way of external auditing, we’re introducing a bug and security bounty (also linked in the footer of our website).
The intention here is to ensure that customers and researchers are encouraged to use any weaknesses they find constructively and are rewarded for doing so. Further, speaking to Bob and certainly looking at his blog SecurityDiscovery.com, being able to get hold of clueful people who can fix an issue seems to be a rare experience. Often researchers can be dismissed as clever sales people, or simply get stuck in a customer service mire. We want to avoid that and hopefully the bug bounty enables this – submissions go directly to our response team!
So why the blog? Well maybe you already know something we ought to know but, more likely, we hope you’re reading this and wondering about your own equipment and network. Hopefully we’ve shown nobody should feel safe and we all need to take this stuff more seriously, no matter how seriously we already take it.
