Blogspam of <a href="https://eclypsium.com/2019/09/03/usbanywhere-bmc-vulnerability-opens-servers-to-remote-attack/" rel="nofollow">https://eclypsium.com/2019/09/03/usbanywhere-bmc-vulnerabili...</a> (and submitter does nothing but spam links to secalerts.co)
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.
Is anyone getting flashbacks to <i>"The Big Hack"?</i><p>It feels like maybe Bloomberg knew of <i>something</i> 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 <i>control</i> BMC's have.<p>Yikes.
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.
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.<p>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.<p>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.<p>FYI, for Dell, the command to disable this behaviour was racadm config -g cfgRacTune -o cfgRacTuneLocalConfigDisable 1<p>and it took quite a while to figure this out...