Re: WaPo writes about vulnerabilities in Supermicro IPMIs

[Brandon Martin <lists.nanog () monmotha net>]

On 08/15/2013 09:00 PM, Jay Ashworth wrote:
> Presumably, everyone else's are very religious as well.
>
> Is anyone here stupid enough not to put the management interfaces behind
> a firewall/VPN?
>
>    
> http://www.washingtonpost.com/blogs/the-switch/wp/2013/08/14/researchers-figure-out-how-to-hack-tens-of-thousands-of-servers/
>
> And should I be nervous that Usenix pointed me *there* for the story,
> rather than a tech press outlet?

Unfortunately that article is somewhat light on the technical details, 
but AFAIK, SuperMicro has fixed most of the egregious implementation 
issues, like the one that let you bounce spam off the SSH server without 
even authenticating, and the remainder are mostly mitigated by properly 
configuring the IPMI to ensure Anonymous and whatnot is disabled, 
passwords are not at the default, etc.  Sadly, the default configuration 
is still grossly insecure, of course, and the thing will do everything 
it can to hop onto the same network you plug the primary NIC into.

In general, the thing seems to be designed by the lowest cost bidder who 
didn't take security into account at all and probably has no idea as to 
the security implications of their decisions.  I wouldn't be surprised 
in the slightest if the thing is still riddled with buffer overflows, 
etc. that could allow an actual targeted attack to bypass a proper 
configuration.

The documentation they (SuperMicro) ship is also atrocious and basically 
amounts to nothing more than "change the ADMIN password" in terms of its 
security recommendations, which isn't even all that effective: the 
Anonymous IPMI user can, by default, launch the SOL.

FWIW, the "IP access control" features do (probably) work reasonably. 
They just drop what you'd expect straight into the INPUT chain of 
iptables on the embedded Linux system on which all this stuff runs. 
There's probably a race during startup where some stuff is running 
before the rules are applied, but that would lower your attack surface a 
lot and should, barring a Linux kernel bug (and figure the kernel on 
this thing is probably hacked up), be effective once the rules are in place.

As to why people wouldn't put them behind dedicated firewalls, imagine 
something like a single-server colo scenario.  Most such providers don't 
offer any form of lights-out management aside from maybe remote reboot 
(power-cycle) nor do they offer any form of protected/secondary network 
to their customers.  So, if you want to save yourself from a trip, you 
chuck the thing raw on a public IP and hope you configured it right. 
This is certainly not a great idea, and it's definitely not my 
preference, and I would never recommend somebody do it, but I'm sure it 
happens.  If you've got enough resources to build a "real" network to 
which the box is hooked up, which should be the case in pretty much ANY 
other scenario, then you have no excuse for not putting the thing on a 
dedicated/restricted management network, of course.

It would be really nice if SuperMicro would offer some options to do 
things like completely disable the IPMI and only allow e.g. SSH/SOL or 
iKVM (which needs work, itself) access, since I suspect that's all most 
people are using in scenarios like the above, and the IPMI is one of the 
most arcane and difficult to secure parts of the BMC software (while 
also being one of the most powerful in terms of datacenter automation).
--
Brandon Martin