
Supermicro server BMCs left exposed to remote attack by any USB device - GiulioS
https://secalerts.co/article/supermicro-server-bmcs-left-exposed-to-remote-attack-by-any-usb-device/67ea5a84
======
Deimorz
Blogspam of [https://eclypsium.com/2019/09/03/usbanywhere-bmc-
vulnerabili...](https://eclypsium.com/2019/09/03/usbanywhere-bmc-
vulnerability-opens-servers-to-remote-attack/) (and submitter does nothing but
spam links to secalerts.co)

~~~
dmix
Is flagging appropriate in these situations? Or just wait until dang reroutes
it?

~~~
Deimorz
I always flag as a way to try to get the mods' attention. I'm pretty sure my
flags are de-weighted or even disregarded at this point though, because I flag
for all sorts of reasons (which is the problem with having no way of being
more specific about why I'm doing it).

------
tedivm
BMC's (or the equivalent for whatever vendor you are using) should never be
exposed to the internet- they shouldn't even be on the same network as the
rest of the server. Generally speaking I put them on a completely separate
network that has to be VPN'd into explicitly. Having BMC access is as close to
having physical access as you can get without actually touching the machine.

~~~
bpchaps
There's a major, major hosting company whose server IPMIs all had an internet
IP and used a default password for an unreasonably long time. I'm honestly not
sure how this company is still around.

~~~
akersten
Can you please name and shame, or at least link to a news article about this?

I'm going to be a little blunt, but the pattern of "there's a well-known
company that's done something bad, you probably use their products, but I
can't tell you what company because [I don't want to be deposed in a libel
lawsuit / I want to feel intellectually superior]" is _really_ long in the
tooth, and doesn't add value to the discussion other than to pique everyone's
paranoia.

~~~
bpchaps
Eh, screw it. It was Rackspace. I worked there, and was told this by a senior
member of the infrastructure staff in a one on one. It was was fixed before I
got there. They still have similarly bad security flubs.

------
HeWhoLurksLate
Is anyone getting flashbacks to _" The Big Hack"?_

It feels like maybe Bloomberg knew of _something_ but got the wrong root
cause- it seems a lot more likely for someone to sneak in a slightly-
reprogrammed BMC than change board layouts /etc., especially considering just
how much _control_ BMC's have.

Yikes.

~~~
Animats
That was my concern. All it would take is a built-in IPMI password. For extra
credit, a built-in IPMI password that wasn't listed if you list IPMI
passwords.

So I search for "IPMI password", and get this.[1]

"On modern Supermicro IPMI interfaces the default login/ password is:"

    
    
        Login: ADMIN
        Password: ADMIN
    

That's convenient. Well-documented, too. Is that enabled by default?

[1]
[https://forums.servethehome.com/index.php?resources/supermic...](https://forums.servethehome.com/index.php?resources/supermicro-
ipmi-default-login-and-password.1/)

~~~
monocasa
FWIW, the implant they were describing could absolutely change a default
password in the bitstream. That'd be really neat because you could swap out
the flash and still be screwed.

------
altmind
If these security reports are valid, this may affect not only Supermicro, but
other vendors too. From the top of my head, Asus and Gigabyte workstation
motherboards also carried AST2400 based BMCs, and theirs ipmi web interface
looked very similar(if not totally the same) to supermicro's.

------
wilhil
BMCs are scary as hell... even for people who say they isolate them, you also
need to do a full audit as many come with rubbish default settings.

For example, Dell's default config on BMC/Idrac (at least 4-5 years ago when I
tested) do not have brute force prevention and by default utilising a special
CLI program, you can logon to a DRAC from the host OS.

Therefore, if a host got compromised, even if Idrac is on a different network,
you could in theory bruteforce from the host credentials and jump/attack the
management network.

FYI, for Dell, the command to disable this behaviour was racadm config -g
cfgRacTune -o cfgRacTuneLocalConfigDisable 1

and it took quite a while to figure this out...

~~~
EB66
> by default utilising a special CLI program, you can logon to a DRAC from the
> host OS ... Therefore, if a host got compromised, even if Idrac is on a
> different network, you could in theory bruteforce from the host credentials
> and jump/attack the management network.

I'm not sure about a DRAC, but for standard BMC units on Dell/SuperMicro
servers I am not aware of anyway that you can actually log into the BMC from
the host OS.

You can certainly use tools like ipmicfg to reset passwords or configuration
on the BMC unit from the host OS, but I don't know of any way that you could
actually drop into the command prompt for the BMC and launch an attack on the
management network.

As long as you have the BMC on a private IP in an entirely independent network
(accessible only via VPN), then a utility like ipmicfg wouldn't help you break
into it.

