🕒 Reading Time: 5 minutes UPDATE See our one year review here. After considering the matter for the past 6 months while continuing to work with Supermicro on the issues, I have decided to release the following to everyone. On 11/7/2013, after reading a couple articles on the problems in IPMI by Rapid7’s HD Moore (linked at the end), I discovered that Supermicro had created the password file PSBlock in plain text and left it open to the world on port 49152. If you take a look at the /nv directory, you will find the file IPMIdevicedesc.xml file; a file which was already known to be downloaded via the aforementioned port. You can quite literally download the BMC password file from any UPnP enabled Supermicro motherboard running IPMI on a public interface (reference link at the bottom of this article). This is not the only file that is vulnerable to this. All the contents of the /nv/ directory are accessible via browser including the server.pem file, the wsman admin password and the netconfig files. When I attempted to reach out to Supermicro , the standard response received was that the UPnP issue had already been patched with the newest IPMI BIOS version. However, flashing a system is not always a possibility. After my previous attempts to gain forward momentum with this issue had failed, and after getting the advice to release from several other security professionals, I reached out to one John Matherly (Shodan) and discussed with him what I had found. Being the awesome person that he is, he provided data on every host that was responding to a web request on port 49152 and the response to “GET /PSBlock”. I was blown away by the results (below): Total Hosts responding to web requests on port 49152: 9,867,259 Vulnerable Systems: 31,964 (Now keep in mind that not everything responding on port 49152 is a Supermicro product. As it turns out, many products use the embedded UPNP software by default, but let’s get through Supermicro first) This means at the point of this writing, there are 31,964 systems that have their passwords available on the open market. It gets a bit scarier when you review some of the password statistics. Out of those passwords, 3296 are the default combination. Since I’m not comfortable providing too much password information, I will just say that there exists a subset of this data that either contains or just was “password”. Besides flashing, there is another (albeit unsupported) temporary fix. Most of the systems affected by this particular issue also have their “sh” shell accessible from the SMASH command line. If you login to the SMASH via ssh and run the command “shell sh”, you can drop into a functional SH shell. From there you can actually kill all “upnp” processes and their related children, which provides a functional fix. That is of course until the system is completely disconnected from power and reconnected, during which the IPMI module will reboot. This is what I have done for our own systems that were unable to be permanently fixed at this time. After continual monitoring, I am satisfied with the results and there has not been any noticeable impact on functionality. So what are the rest of those IPs? Why are 9.8 million devices using port 49152, which is one port above the registered port range (1024-49151)? There are another 9,835,313 that have port 49152 open and are returning something from an HTTP GET request. It appears that many systems that employ an embedded Linux-based solution (i.e., home routers, remote management devices, and IP cameras) have varying iterations of the UPnP feature set installed. This causes them to broadcast their kernel and often times the hardware architecture. Take for instance this string from all vulnerable Supermicro BMC (Baseboard Management Controller) products: Linux/2.6.17.WB_WPCM450.1.3. The kernel version is 2.6.17, which was compiled for the Nuvoton’s WPCM450 chip. If you combine this knowledge with a search database for online devices, such as John Matherly’s interface located at shodanhq.com, embedded host identification becomes a breeze. Another very disturbing discovery was that a lot of systems are running older versions of the Linux kernel. Approximately 23,380 of the total hosts are running the 2.4.31.x kernel, another 112,883 are running the 2.4.30.x kernel, and 710,046 systems are running the 2.4.19.x kernel. The largest number of systems responding to an HTTP GET request were systems running under the banner of AT&T U-Verse with a total of 6,448,716. However, they do not broadcast any information, and they respond with the HTTP code “200 OK”. So what do we do? Is it our fault as consumers/businesses for trusting our vendors, or is it our vendors’ fault for ‘being human’? Short answer, none of the above, but the longer answer is a bit more complicated. Sure, a password should never be in plain text, and nor should any feature set be hardcoded into an embedded product if its features serve no functional purpose, but we do not live in a perfect world. Things have a way of slipping through the cracks, even by the most diligent of companies. Supermicro , to its credit, no longer employs the WPCM450 chips. With the release of their newer X10 series motherboards, they have replaced the aging WPCM450 BMC with the ASPEED AST2400 BMC product with a newer kernel version. It is time to call for stronger security of embedded platforms. With the advent of services like shodanhq.com, and research operations such as Rapid7’s Project Sonar, devices can no longer dwell amongst the anonymity of the nearly 4.3 billion IPv4 addresses. Recent findings on the above platforms have proven everything is visible. With the advent of IPv6 and the ‘Internet of Things’, we as both customers and vendors need to ensure the security of our networks and connected devices. To protect ourselves, I have found that the best solution is to keep informed and stay involved. If you find a vulnerability, reach out to the respective vendor first. If the vendor is unresponsive or does not share your urgency, there are organizations such as the US Department of Homeland Security’s Computer Emergency Readiness Team (US-CERT) and the MITRE Corporation who will assist. If they determine the issue does not meet their criteria for assistance, try subscribing to a security-minded mailing list and see if somebody there will assist you. As for the devices you have around your home or workplace, an interesting adventure is to search them and append the word “vulnerability”. You’ll be amazed by the results. As for staying informed, I personally suggest the use of packetstormsecurity.org and isc.sans.edu, as well as subscribing to the os-security mailing list. And finally, keep your device firmware up-to-date. Security is no longer something left to the professionals; it needs to be a part of our daily internet lives. Finally, I want to thank HD Moore (Rapid7), John Matherly(Shodan), Kurt Seifried(Red Hat), and Dan Farmer (fish2.com or trouble.org) for their support in this and making this possible. If you want more information regarding the history of IPMI vulnerabilities as whole, I strongly suggest you read the material located at Dan Farmer’s IPMI research page, found in the references section below. On the Supermicro side, the Sr. Product Manager Arun Kalluri has been an incredible resource in gathering information on what Supermicro has done in light of this issue, and has provided a link to other known issues in the BMC product (which is in the articles reference). I have contacted MITRE’s cve-assign group, who has also worked with Supermicro on this matter. To date, no CVE has been assigned. The team at Metasploit will be releasing a module for the PSBlock and wsman password retrieval shortly, so be on the lookout! I would love to hear your thoughts on this, so please leave a comment or shoot us an email! If you have any questions, concerns, or if you would like more information, please contact our security team at sirt@cari.net and we will get back to you shortly. Regards, Zachary Wikholm Senior Security Engineer Security Incident Response Team (CARISIRT) CARI.net sirt@cari.net Articles & Reference Material: https://community.rapid7.com/community/metasploit/blog/2013/07/02/a-penetration-testers-guide-to-ipmi https://community.rapid7.com/community/metasploit/blog/2013/11/06/supermicro-ipmi-firmware-vulnerabilities http://www.supermicro.com/FAQ/index.aspx?&se=16536&k=y http://www.supermicro.com/products/nfo/files/IPMI/CVE_Update.pdf http:/fish2.com/ipmi