Hello LowEndTalk Providers,
Please make sure to check your SuperMicro IPMI and related BMCs, and this most recently disclosed exploit is just one of many issues core to the management interface we all take for granted in controlling our physical assets.
As was explained on cari.net some time ago, any IPMI found on a series X9 or older motherboard from SuperMicro may be vulnerable to an exploit which can reveal the [b]plaintext passwords[/b] of [b]all users[/b].
Numerous other exploits are also found on these X9 and older BMC units, the worst of which can be used to install back-doors that [b]survive a complete host Operating System reinstall and firmware update.[/b]
IPMI and BMC devices should never have public addresses to begin with, but if you must; make sure that you are not allowing connections to these devices on ports other than those specifically designed for their functions, 80/443 ; 623 ; and 5900 for the web interface, media interface, and iKVM respectively.
Please note that in situations in which multiple customers are on the same private network, the issue is just as dear as if the IPMI were placed on a public network. Proper ACLs should be in place to prevent customers from connecting to each-other's IPMI devices, such as the use of VLANs.
If you are not yet implementing an http://ift.tt/1pBSQiG network, then you should be. Many providers here on LowEndTalk have networks which currently contain vulnerable devices, and should seek options of dealing with this issue immediately.
Testing Vulnerable Devices
You can check if a device is vulnerable by issuing the following command:
nc -z -w5 $IP 49152
A possibly vulnerable device will return the following:
Connection to 10.0.0.254 49152 port [tcp/*] succeeded!
While a device that is not vulnerable will not return anything after 5 seconds.
Once a possibly vulnerable device has been identified, one should note that this port shares common usage with other protocols, and could be a different device or system/software listening on the given address. The following command can be used to confirm the vulnerability:
wget "$IP:49152/PSBlock" -O /dev/null -T 3 -t 1 -nv
A vulnerable device will return a line such as:
2014-06-22 19:29:10 URL:10.0.0.254:49152/PSBlock [10240/10240] -> "/dev/null" [1]
Patching Vulnerability
First, if the IPMI device was accessible to the public network, you should remove this access. If you have physical access to the infrastructure in question, steps should be taken to ensure that the ports used for IPMI connectivity are VLAN'd and ACL'd off of the public network, and should be access only through a privileged VPN or other Out of band management network.
Secondly, you should check your firewall and network logs to see if access to any devices you control may have been leaked, this is a very important step; as otherwise you would not know the extent of the breach.
Third, you should flash the firmware of the IPMI device with the latest blob available from SuperMicro, or from your SuperMicro authorized reseller/dealer, and reset it to factory defaults. You should then manually re-configure the device.
If you are unsure of what version of blob to use, ask your SuperMicro authorized reseller/dealer; they should be well aware of this exploit and be able to guide you in the installation of this required update.
If your device does not yet have a newer blob available, you should consider keeping the IPMI device offline or unplugged until a suitable blob to patch this exploit is available for your hardware.
A temporary shield against this particular issue can be carried out on Cisco routing equipment with commands similar to the following:
access-list xxx extended deny tcp yy.yy.yy.yy zz.zz.zz.zz any eq 49152
access-list xxx extended permit ip any any
access-group xxx in interface inside
Where xxx is a free access ID, and yy.yy.yy.yy is the IPMI device IP address, or IPMI device range; and zz.zz.zz.zz is the applicable subnet mask for the range you wish to apply this rule. This specifically blocks only the port 49152, and should not be considered a full solution in any case.
As always, you should follow security best practices and update all software found on your machines, and run scans such as maldet to make sure that no malicious software has been implanted whilst the exploit was around.
You can perform a maldet scan by following these steps:
cd /opt
wget http://ift.tt/1wkr1gW
tar -xvf maldetect-current.tar.gz
cd maldetect-*
./install.sh
At this point, you should drop into a terminal multiplexer, script, or screen session; as the scan can take several hours, and a disconnect from SSH would otherwise interrupt the scan. We suggest the use of screen as it is very easy to use. Simply type screen to enter a screen.
Once you are in your screen, simply type the following to scan your root partition:
maldet -a /
http://ift.tt/1dvHQ0Z
0 comments:
Post a Comment