Firmware Vulnerabilities In Millions of Computers Could Give Hackers Superuser Status (arstechnica.com) 23
Researchers have warned that leaked information from a ransomware attack on hardware-maker Gigabyte two years ago may contain critical zero-day vulnerabilities that pose a significant risk to the computing world. The vulnerabilities were found in firmware made by AMI for BMCs (baseboard management controllers), which are small computers integrated into server motherboards allowing remote management of multiple computers. These vulnerabilities, which can be exploited by local or remote attackers with access to Redfish remote management interfaces, could lead to unauthorized access, remote code execution, and potential physical damage to servers. Ars Technica reports: Until the vulnerabilities are patched using an update AMI published on Thursday, they provide a means for malicious hackers -- both financially motivated or nation-state sponsored -- to gain superuser status inside some of the most sensitive cloud environments in the world. From there, the attackers could install ransomware and espionage malware that runs at some of the lowest levels inside infected machines. Successful attackers could also cause physical damage to servers or indefinite reboot loops that a victim organization can't interrupt. Eclypsium warned such events could lead to "lights out forever" scenarios.
The researchers went on to note that if they could locate the vulnerabilities and write exploits after analyzing the publicly available source code, there's nothing stopping malicious actors from doing the same. And even without access to the source code, the vulnerabilities could still be identified by decompiling BMC firmware images. There's no indication malicious parties have done so, but there's also no way to know they haven't. The researchers privately notified AMI of the vulnerabilities, and the company created firmware patches, which are available to customers through a restricted support page. AMI has also published an advisory here.
The researchers went on to note that if they could locate the vulnerabilities and write exploits after analyzing the publicly available source code, there's nothing stopping malicious actors from doing the same. And even without access to the source code, the vulnerabilities could still be identified by decompiling BMC firmware images. There's no indication malicious parties have done so, but there's also no way to know they haven't. The researchers privately notified AMI of the vulnerabilities, and the company created firmware patches, which are available to customers through a restricted support page. AMI has also published an advisory here.
now who has the IPMI on an public IPv4/6? (Score:2)
now who has the IPMI on an public IPv4/6?
Re: (Score:2)
I don't know! How do you test for that? My guess is that's impossible to block at the host firewall level since it is usually attached to the network interface thus before the OS and any firewall on the host. Can you block it on a border firewall separated from the host?
Re: (Score:2)
Yeah, host firewall would not do anything. I'd hope that cloud providers would have machines where the IPMI is attached to a dedicated Ethernet interface and not the same one used for normal traffic, and that said interface is on a dedicated LAN or VLAN separate from those that carry normal traffic.
I'd hope that. But I wouldn't bet on it.
Re:now who has the IPMI on an public IPv4/6? (Score:4, Interesting)
I don't know! How do you test for that? My guess is that's impossible to block at the host firewall level since it is usually attached to the network interface thus before the OS and any firewall on the host. Can you block it on a border firewall separated from the host?
I have seen IPMI networking configured at least 2 different ways: (1) dedicated IPMI LAN port; (2) piggyback IPMI traffic on another LAN port.
In my experience, option 1 is preferable over option 2 since dedicated IPMI LAN ports can be secured with firewalls, "jump boxes", access lists, and so on.
I don't know if option 2 be filtered since I have never configured that myself nor ever suggested to any customer. It just seems like a bad idea.
IPMI on a dedicated LAN port can be scanned with NMAP. A Supermicro motherboard running RedFish 1.0.1 firmware on the BMC (2400 model) reveals ports 22, 80, 443, and 5900 are listening; that's SSH, HTTP, HTTPS, VNC (used by iKVM feature).
Re: (Score:3)
There are two scenarios. In servers with a separate IPMI interface, put it on it's own VLAN and give it a non-routable address. If it shares it;s interface with the host, at least give IPMI a non-routable address.
People who should have access to it remotely log in to a separate host to work on the servers. That host should be well updated and maintained and should run only what it absolutely must to do it's job. It may or may not even have a DNS entry.
Your border firewall should already be blocking non-rout
Re: (Score:2)
My servers are bare metal servers hosted at a cloud provider. Someone else mentioned nmap scanning. Any howtos to scan with nmap you are aware of? Thanks for your answer!
Re: (Score:3)
IPMI is port 623. The problem would be that the BMC's IP address can't be the same as the server's
If you have root access, you could connect to IPMI over the local channel and check the IP settings.
Re: (Score:2)
Yes I have root access, how do I connect through the "local channel" please? Simply use 127.0.0.1 or what? Does it require any credentials I might not have (I have none for that)?
I also have access to the bios through KVM (keyboard video mouse) but I would need to take the servers down. That's a lot of hosts since the servers run a total of ~50 virtual machines (proxmox pve). Do some bios simply allow you to disable IPMI? My servers aren't monitored by the hosting provider since I installed my own OS throug
Re: (Score:2)
To connect to IPMI from the actual host, you need something like openipmi [sourceforge.io] or ipmitool [github.com]. Both are packaged with Debian and I would imagine that most Linux distros package at least one of them.
Re: (Score:2)
Thanks for the tip! I'll try those out!
Re: (Score:2)
Also, IPMI often uses ports other than 80/443, which makes blocking them a cinch.
Re: (Score:2)
Just because something isn't on a public address doesn't mean it's secure... Just because something is on a public address doesn't mean it's insecure.
It's quite easy to gain a pinhole foothold on a network (compromised device/account, misconfigured proxy or vpn etc) and then a misconfigured IPMI device gives you opportunity to take full control of an otherwise well configured server.
A bigger problem is people who don't realise IPMI is there. They setup their server using a mouse and keyboard, never even con
Re: Best detection method (Score:2)
Maybe - but unencrypted is never good - if your IPMI network is ever infiltrated, the attacker gets everything all at once at no cost to themselves. If it's encrypted, then at least they have some amount of work to do per-host (maybe not much, but it's non zero).
Fearmongering (Score:5, Informative)
Your BMC network should be in a segregated network. Preferably physically separated, if not, at least in a VLAN. That separated network should NOT be connected to the wide internet.
Some machines have the BMC network in the same integrated NIC of the mobo. In the olden times when 1Gbps was the fastest network speed, this was an issue. Nowadays, when 10Gbps is the minimum a decent server must have, one can consider the 1Gbps port as BMC/MAnagement only (i.e. you use the 1Gbps card as BMC only, and all the 10Gbps+ nics are the ones to do services)...
Sometimes, the airgap can be bridged by a machine used for remote access with the adequate protections. For example, in a past life, for mine you had to call a human to turn on the machine, and then log in with 2FA, in another life, you had to log in to a RAS, from there to the management machine, again with 2FA.
And this is not being paranoid, it has been the best practice for a loooong while.... so, whomever is following best practices, has very small risk, and everyone who is not following best practices deserves the hacking that's comming their way...
Having said that, and my comment not whitstanding: PATCH ASAP!!!!
Is IPMI only on servers (Score:5, Interesting)
Re: (Score:2)
The IPMI specification calls for discrete hardware, as it's an explicitly out-of-band system management solution.
There are alternative out-of-band management technologies such Intel's Active Management Technology (AMT) [wikipedia.org], which is integrated into their hardware, and is probably what you're thinking of. However AMT is not available on most client SKUs (only specific vPro Enterprise SKUs), and it needs to be explicitly enabled and c
Re: Is IPMI only on servers (Score:1)
It's almost only on server boards. Desktop class machines don't usually require that level of remote management.
Re: (Score:2)
I thought that IPMI hardware was also installed on desktop computer motherboards. If so, how exposed is it? Is there a way for the user to verify that it is not enabled?
IPMI costs more money than the alternatives. For servers in general and for server farms in particular, it makes sense.
But for desktops, other solutions are preferred, in the case of Intel it is called vPro, and I do not remeber the name for AMD.
HRE A PROFESSIONAL HACKER AND AVOID SCAM STORIES (Score:1)