In my previous post I narrated my adventure trying to get a memtest running on Excelsior — at the end I was able to run it through a modified JNLP, and one more open port. I was suggested to look into one particular Java application from Supermicro that does not require using the JNLP at all, and instead installs as a client, giving access to more features such as the SOL and generic IPMI control…
Unfortunately it seems like the installer (InstallShield for Linux, written in Java — what the heck?) is extremely picky as to which JRE it find and which one it wants, so I haven’t been able to even test it. But at least I got some details going.
I basically listened with Wireshark to what’s going on with the JNLP; the interface uses four combined interfaces, between the browser and Java: port 80, 443, 5900 and 623. The first two are the HTTP/HTTPS interfaces (the JNLP downloads the JARs from HTTPS even thought hey are available on HTTP as well); the third is the VNC/RFB default port, while the fourth is the one that I haven’t understood yet. It’s some kind of USB over IP protocol, and seem to send raw USB data over the wire, standing to the USBC/USBS instances in the trace, but at the same time it doesn’t seem like it’s using it at runtime, as I see no traffic on that port after I connect the ISO file.
The RFB protocol used seems to be the standard one using TightVNC extensions for authentication — I guess they actually used TightVNC’s code for it. The problem with the authentication is that for whatever the reason, it’s not a clear user/password auth. Instead it uses some hash or unique identifier, which changes each time I connect to the web interface — I’m not sure if it’s a hash, it’s definitely not an OTP (as I can start multiple instances of the javaws applet without having to re-download the JNLP), or just a nonce-based authentication, but it’s used both as user and as password.
Edit: actually I had a hunch while looking into it and I confirmed that what it uses is the same SID saved as a cookie after my login on the web interface. Now if I could get the iKVM viewer to work on my system and I could see how that one connects…
The USB over IP protocol is interesting as well; it doesn’t seem to use a standardised port, and Wireshark has no clue as to what’s going on there. As I said I can see USBC and USBS as literals within the traffic as well as the data for the ISO and some other not-well-explained things — I’ll have to work more on that, possibly with smaller files, and without the RFB in the trace.
Does anybody else have clues about this kind of protocols? For what I can tell the firmware for my board’s IPMI contains a copy of Linux (this is what nmap said as well), but I see no released sources for it, nor an offer for them on the zip file I downloaded. I wonder if I should just mail SuperMicro to ask them about it.
Okay, hron actually gave me the link to where there is a standalone copy of IPMIView2: ftp://ftp.supermicro.com/ut… and this one does not require an installer at all, nor it requires JavaWS. Unfortunately, it’s far from perfect as it requires the IPMI port (623, the same used by the USB-over-IP protocol of Virtual Media!) to be present on the given address with no way to override (it can be overridden by hacking the JNLP on the WebStart version).More importantly this requires me to use the UDP communication rather than the TCP one — which makes it unusable behind an SSH gateway. I think I’ll put a temporary stop on this until I’m back in LA where I can use UDP just fine, and then will resume the work. This is going to become interesting because it means that if we want to write an open-source console we need to have interfaces for VNC as well as IPMI. Too bad that it’s hard to use SSH tunneling for UDP although one could try building a proxy that uses SCTP (so you only have one service, one port, and then it’s muxed into the multiple-ports used by the BMC itself).
Quite interesting firmware file… If one were to take a closer look at /bin/usb and /bin/ikvmserver. There is also some custom modules in /bin/module, like ikvm_vmass.ko used by /bin/usb.Would these modules be covered by GPL?
Regarding mailing SuperMicro to ask them about the code I do think you will go very long. The IPMI firmwere is made by ATEN (http://www.aten.com/IPMI.htm) and they have not been very helpful in the past to say atleast…
Yes I know the firmware is from ATEN.Yesterday I did mail SuperMicro reminding them that they are not in compliance with GPL, and that the fault is on them *even though ATEN is the one producing the firmware*. Today is a holiday in the US so I don’t expect an answer, maybe they’ll answer in the next few days at least with some kind of boilerplate.If I don’t see any effort on their side I’ll see to involve some more people. There is busybox in there and they have been very hard on license violators before.
Well, hopefully it should not be that much of a boilerplate answer, http://www.softwarefreedom….
Hi,did you get any response from Supermicro?In particular in the light of some security vulnerabilities, source code and build instructions for the IPMI firmware and the whole iKVM client would be useful…http://www.heise.de/newstic… (in German)http://fish2.com/ipmi/ (Dan Farmer)https://community.rapid7.co… (HD Moore)CheersAlex
http://www.softwarefreedom….Supermicro has agreed to appoint an Open Source Compliance Officer within its organization to monitor and ensure GPL compliance.I wonder if it would be useful to reach out tho the Compliance Officer.
After poking around a bit I found the encryption functions (named *Cryto*) in libiKVM64.jnilibnm libiKVM64.jnilib | grep Cryto | c++filt0000000000014de0 T RFBKMCryto::SW_AES_CBC(int, int, unsigned char*, int, unsigned char*, unsigned char*, unsigned char*)0000000000014d30 T RFBKMCryto::SW_AES_ECB(int, int, unsigned char*, int, unsigned char*, unsigned char*)0000000000013d70 T RFBKMCryto::aes_decrypt(aes_context*, unsigned char*, unsigned char*)0000000000012dd0 T RFBKMCryto::aes_encrypt(aes_context*, unsigned char*, unsigned char*)00000000000127d0 T RFBKMCryto::aes_set_key(aes_context*, unsigned char*, int)0000000000012640 T RFBKMCryto::SetCipherKey(char*, int)00000000000127c0 T RFBKMCryto::aes_gen_tables()0000000000012700 T RFBKMCryto::RFB_AES128_EventCryto(unsigned char*, unsigned char*)0000000000017020 S RFBKMCryto::FSb0000000000017820 S RFBKMCryto::RSb0000000000018020 S RFBKMCryto::RCON00000000000127b0 T RFBKMCryto::DeCryto(char*, char*, int)0000000000012650 T RFBKMCryto::EnCryto(char*, char*, int)0000000000012590 T RFBKMCryto::RFBKMCryto()00000000000125c0 T RFBKMCryto::RFBKMCryto()00000000000125f0 T RFBKMCryto::~RFBKMCryto()0000000000012620 T RFBKMCryto::~RFBKMCryto()0000000000012630 T RFBKMCryto::~RFBKMCryto()000000000000bd50 T RMCryto::SetCipherKey(char*, int)000000000000bd70 T RMCryto::DeCryto(char*, char*, int)000000000000bd60 T RMCryto::EnCryto(char*, char*, int)000000000000bd00 T RMCryto::RMCryto()000000000000bd10 T RMCryto::RMCryto()000000000000bd20 T RMCryto::~RMCryto()000000000000bd30 T RMCryto::~RMCryto()000000000000bd40 T RMCryto::~RMCryto()000000000001db40 S typeinfo for RFBKMCryto000000000001d578 S typeinfo for RMCryto000000000001c0e0 S typeinfo name for RFBKMCryto0000000000016f02 S typeinfo name for RMCryto000000000001db00 S vtable for RFBKMCryto000000000001d540 S vtable for RMCrytolibiKVM64.jnilib can be extracted from iKVM__V1.69.21.0×0.jar.pack.gz (Downloaded by launch.jnlp)So, yeah. They use a crypto style nobody else does.Thanks for nothing Supermicro.If you can, you’re better off enabling SOL (serial over lan) and setting up a console port for redirection. That way you can have full text access without needing the VNC viewer at all.
I recently noticed the strings USBC and USBS in the protocol used with their current Xeon boards (specifically, an X10SRH-CLN4F), so it seems the protocol hasn’t changed.With this board, it’s an option to share a local device – drive, partition, etc – a feature I find much more useful. Or I would, if they didn’t place so many silly restrictions on it!It’ll only allow you to select a block device… and filters out some for reasons I haven’t discovered. If you plug in a USB stick, it might allow you to share any of the partitions but not the entire device… frustrating if you hoped to boot from the device, or if your stick lacks partitions!The underlying code will work fine with regular files, but tricking it requires work: from the dropdown, choose a device you won’t be using soon (ex: /dev/sdh). Before clicking the “plug in” button, rename (as root) /dev/sdh, and copy or symlink the fs image as /dev/sdh. Now, once you click the “plug in” button, your remote system will be able to read (I didn’t test writing) the fs image.I’m considering reversing their protocol and writing my own app that will work with fs images, but keep hoping to find someone else’s work on the subject. Do you know of anyone who has made progress?
Whoops!After posting, I searched for USBS and USBC. Turns out they’re signatures used in USB Mass Storage (for example, see the .pcap attached to the last comment on https://bugs.wireshark.org/….If it’s really passing USB data with little or no modification, this might not be too hard to figure out.For analysis, I think I might use gopacket (https://godoc.org/github.co… to extract USB data from the IP packets, rewriting as a USB packet capture. I could then use wireshark to analyze it.Something else that might be useful is http://usbip.sourceforge.net/ , assuming that this is similar to that protocol.
Got my hands over a supermicro X10DRL-i and things aren’t much better in 2018