3 ms·

This is an interesting attack surface. Can you extend the risk out a bit? Assume that you have a vulnerable supermicro IPMI now exposed on a public interface.

This is an interesting attack surface. Can you extend the risk out a bit? Assume that you have a vulnerable supermicro IPMI now exposed on a public interface. It has no IP address, and is presumably issuing DHCP DISCOVERs in an effort to get an IP. How do you reach the IPMI device to exploit it? What additional access do you need to get there? Root on another device on that public network would do, you could forge the necessary DHCP responses to get it configured with an IP address of your choosing. Non-root on another device on that network might also work, if it fails DHCP and self-configures on a 169.254 address, assuming it does that. Is there an obvious way to exploit such an issue from beyond the public subnet?Every attack I can imagine would be blocked by either inbound firewalls, or a failure to reach the IPMI as an unexpected device on the public subnet. I suppose that it would be a possible risk if you have a DHCP server on that public subnet issuing IP addresses to all devices, but that seems like a larger risk anyways. Server networks should be static assigned or static DHCP in all cases.

michaelt 3y ago
Assume your network is not-entirely-trusted - like a college network where some curious students might be poking around and running network scans, and some others have malware on their computers. The expected network port is plugged in, so even if your switch is checking MAC addresses, everything is in order. Most networks use DHCP, so the IPMI picks up an IP address. A student finds it with their port scan.
- secabeen 3y ago
  Interesting. I never use DHCP pools / random allocation on server networks; everything there is static assignment on the host, or static DHCP with whitelisted MAC.
dilyevsky 3y ago
> This is an interesting attack surface. Can you extend the risk out a bit? Assume that you have a vulnerable supermicro IPMI now exposed on a public interface. It has no IP address, and is presumably issuing DHCP DISCOVERs in an effort to get an IP. How do you reach the IPMI device to exploit it? What additional access do you need to get there? I think you misunderstood the level of fucked up this really was. The BMC device sits on the north bridge and literally scoops up packets from the main NIC which means it can even be accessible from the internets (if you didn't firewall port 623). See [0] for an example how variation of this unfolded. [0] - https://www.zdnet.com/article/over-47000-supermicro-servers-are-exposing-bmc-ports-on-the-internet/ https://www.zdnet.com/article/over-47000-supermicro-servers-...
hsbauauvhabzb 3y ago
I unknowingly did this, I found a random ip exposing the interface, and used admin/admin to compromise it - I was very confused as I explicitly did not plug in the ipmi interface as I do not want it. I ended up using a PCIE nic, which ipmi does not auto bridge to.
johnklos 3y ago
There are plenty of cheap colos that do no filtering on their public networks. Some are saving money by putting a number of machines on a single ethernet segment, some are saving IPs by not having a /31 (or, much more often, a /30) for each client, and some both, so a compromised machine could easily run a DHCP server and scan any takers. You're right that no sensible network would forward packets to a misconfigured IPMI, though. That still leaves very real things that've happened - the IPMI switches to the public interface and can no longer be reached on the managed local interface, and then you're rebooting several times in hopes it'll switch back and making aliases on a public interface to see if you can talk to it on the public segment. It's not professional at all.

michaelt 3y ago

Assume your network is not-entirely-trusted - like a college network where some curious students might be poking around and running network scans, and some others have malware on their computers. The expected network port is plugged in, so even if your switch is checking MAC addresses, everything is in order. Most networks use DHCP, so the IPMI picks up an IP address. A student finds it with their port scan.

secabeen 3y ago
Interesting. I never use DHCP pools / random allocation on server networks; everything there is static assignment on the host, or static DHCP with whitelisted MAC.

dilyevsky 3y ago

> This is an interesting attack surface. Can you extend the risk out a bit? Assume that you have a vulnerable supermicro IPMI now exposed on a public interface. It has no IP address, and is presumably issuing DHCP DISCOVERs in an effort to get an IP. How do you reach the IPMI device to exploit it? What additional access do you need to get there? I think you misunderstood the level of fucked up this really was. The BMC device sits on the north bridge and literally scoops up packets from the main NIC which means it can even be accessible from the internets (if you didn't firewall port 623). See [0] for an example how variation of this unfolded. [0] - https://www.zdnet.com/article/over-47000-supermicro-servers-are-exposing-bmc-ports-on-the-internet/ https://www.zdnet.com/article/over-47000-supermicro-servers-...

hsbauauvhabzb 3y ago

I unknowingly did this, I found a random ip exposing the interface, and used admin/admin to compromise it - I was very confused as I explicitly did not plug in the ipmi interface as I do not want it. I ended up using a PCIE nic, which ipmi does not auto bridge to.

johnklos 3y ago

There are plenty of cheap colos that do no filtering on their public networks. Some are saving money by putting a number of machines on a single ethernet segment, some are saving IPs by not having a /31 (or, much more often, a /30) for each client, and some both, so a compromised machine could easily run a DHCP server and scan any takers. You're right that no sensible network would forward packets to a misconfigured IPMI, though. That still leaves very real things that've happened - the IPMI switches to the public interface and can no longer be reached on the managed local interface, and then you're rebooting several times in hopes it'll switch back and making aliases on a public interface to see if you can talk to it on the public segment. It's not professional at all.