Last week IBM released a security bulletin named "Unauthorized access exposure on IBM SAN Volume Controller and Storwize Family". It's about vulnerabilities in Apache Struts that could allow a person with access to the IP interface of a Storwize family product to gain 'superuser' rights on said machine. Being a superuser you can configure the machine and yes, with the sufficient amount of criminal energy you could even delete the whole configuration. Given the technical hurdles the risk of this vulnerability is very very low.
Well, an experienced administrator would say now: Yes, that happens from time to time. Where code is written, bugs must hide. Today's operating systems and applications contain multiple open source components. If such a component shows a vulnerability in a specific version, usually a lot of other products (also commercial ones) utilizing this component will be vulnerable, too. A fix will be written, updates have to be done. No surprises so far. Openssl, openssh, apache and many more components of many current OS'es and applications got their security patches over time and if there was any media coverage in the IT press about them at all, it was often only a reference to the security bulletins and advisories. So why should it be different this time?
But then I got aware of "rumors" around this topic and a growing concern about the risk of such security vulnerabilities and how they could impact a storage environment.
The same concern was forwarded to us in several problem records in the past when the IT of some companies was audited and the auditing tools found security holes on the management interfaces of some of the storage devices.
At first it sounds dangerous, but is that really the case?
As written above, the attacker needs IP connectivity to the management interface of the machine. And here comes the insight of the week:
It is NOT a good idea to make your storage product's management interface accessible to just everybody in the company! It is an even WORSE idea to expose it to the internet. REALLY!
I bet (my honor - I don't bet money, I'm just a poor support guy) that you won't find a storage product today that is intended to expose its management interface directly to possible attackers and none that is proven 100% safe. Gaining access to a storage device by using a security vulnerability is only one thing. But also think about social engineering, spear-phishing or just DDoS attacks. There are many ways to misuse just the plain existence of an exposed management LAN interface that has to cope with external requests. Performance impacts and machine reboots are very well imaginable results, too. Again: Don't do that!
And the internal threat?
There's always a risk that somewhere in your company there could be that frustrated guy that just want to see the world burn. If he's a storage admin, you have bad luck, but you don't need a security vulnerability for that. If he is from another team and by chance has access to the management LAN of your storage boxes in today's corporate IT world full of endpoint-managers, ACLs, boundary firewalls and asset and security management, it's most probably possible to track him down and find out who he is.
And if he fears no consequences anymore?
Well, then he could also go to the data center with a big hammer and just randomly smash some storage devices and servers. It might be a surprise, but IBM Storwize family products and the IBM SAN Volume Controller are not certified to be 'angry guy with a big hammer'-safe.
But I doubt that there will be a security bulletin for that special vulnerability :o)
Update Oct. 31st, 16:25:
I modified this article due to legal concerns with the previous version. The meaning and especially the recommendation is pretty much the same, though.