WaPo writes about vulnerabilities in Supermicro IPMIs
lists.nanog at monmotha.net
Fri Aug 16 02:18:02 UTC 2013
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?
> 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
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).
More information about the NANOG