Jul 172014
 

XViewerThe first release of XViewer is now available, providing TK-IP101 users with a way to still manage their installations using modern Java versions and operating systems without any blocker bugs and crashes. I have created a static page about it [here] including downloads and the statements required by TRENDnet. You can also see it on the top right of this weblog. This is the first fruition of TRENDnet allowing me to release my modified version of their original KViewer under the GPLv3 license.

As requested, all traces of TRENDnet and their TK-IP101 box have been removed from the code (not that there were many anyway, as the code was reverse-engineered from the byte code) on top of the rename to XViewer. In time, I will also provide my own documentation for the tool.

Since I am no Java developer, you shouldn’t expect any miracles though. Also, if anyone would be willing to fork it into yet another, even better version of the program, you’re of course welcome to do so!

Happy remote monitoring & managing to you all! :)

Edit: Proper documentation for SSL certificate creation using a modern version of [XCA] (The X certificate and key management tool) and about setting up and using XViewer & XImpcert has now also been made [available]!

Jul 162014
 

XViewer logoIn my [last post] I have talked about the older TRENDnet TK-IP101 KVM-over-IP box I got to manage my server over the network even in conditions where the server itself is no longer reachable (kernel crash, BIOS, etc.).

I also stated that the client software to access the box is in a rather desolate state, which led me to the extreme step of decompiling the Java-based Viewer developed by TRENDnet called KViewer.jar and its companion tool for SSL certificate imports, Impcert.jar.

Usually, software decompilation is a rather shady business, but I did this as a TRENDnet support representative could not help me out any further. After reverse-engineering the software, making it compatible with modern Java Runtime environments and fixing a blocker bug in the crypto code, I sent my code and the binary back to TRENDnet for evaluation, asking them to publish the fixed versions. They refused, stating that the product was end-of-life.

In a second attempt, I asked the guy for permission to release my version of KViewer including the source code and also asked which license I could use (GPL? BSD? MIT?). To my enormous surprise, the support representative conferred with the persons in charge, and told me that it had been decided to grant me permission to release KViewer under the GNU General Public License (GPL), as long as all mention of TRENDnet and related products are removed from the source code and program.

To further distinct the new program from its original, I renamed it to “XViewer”, and its companion tool to “XImpcert”, as a hommage to my server, XIN.at.

KVM host:port

The former KViewer by TRENDnet, that works up to Java 1.6u27

XViewer

XViewer, usable on JRE 1.7 and 1.8

Now, I am no Java developer, I don’t know ANYthing about Java, but what I did manage to do is to fix all errors and warnings currently reported by the Eclipse Luna development environment and the Java Development Kit 1.7u60 on the source code. While my version no longer supports Java 1.6, it does run fine on Java 1.7u60 and 1.8u5, tested on Windows XP Professional x64 Edition and CentOS 6.5 Linux x86_64. A Window closing bug has been fixed by my friend Cosmonate, and I myself got rid of a few more. In addition to that, new buttons have been added for an embedded “About” window and an embedded GPLv3 license as suggested by TRENDnet.

On top of that, I hereby state that I am not affiliated with TRENDnet and that TRENDnet of course cannot be held liable for any damage or any problems resulting from the use of the modified Java viewer now known as XViewer or its companion tool XImpcert. That shall be said even before the release, as suggested to TRENDnet by myself and subsequently confirmed to be a statement required by the company.

In the very near future, I will create a dedicated site about XViewer on this weblog, maybe tomorrow or the day after tomorrow.

Oh and of course: Thanks fly out to Albert from TRENDnet and the people there who decided to grant me permission to re-release their viewer under the GPL! This is not something that we can usually take for granted, so kudos to TRENDnet for that one!

Jul 112014
 

TK-IP101 logoAttention please: This article contains some pretty negative connotations about the software shipped with the TRENDnet TK-IP101 KVM-over-IP product. While I will not remove what I have written, I have to say that TRENDnet went lengths to support me in getting things done, including allowing me to decompile and re-release their Java software in a fixed form under the free GNU General Public license. Please [read this] to learn more. This is extremely nice, and so it shall be stated before you read anything bad about this product, so you can see things in perspective! And no, TRENDnet has not asked me to post this paragraph, those are my own words entirely.

I thought that being able to manage my server out-of-band would be a good idea. It does sound good, right? Being able to remotely control it even if the kernel has crashed and being able to remotely access everything down to the BIOS level. A job for a KVM-over-IP switch. So I got this slightly old [TK-IP101] from TRENDnet. Turns out that wasn’t the smartest move, and it’s actually a 400€ piece of hardware. The box itself seems pretty ok at first, connecting to your KVM switch fabric or a single server via PS/2, USB and VGA. Plus, you can hook up a local PS/2 keyboard and mouse too. Offering what was supposed to be highly secure SSL PKI autentication via server+client certificates, so that only clients with the proper certificate may connect plus a web interface, this sounded really good!

TRENDnet TK-IP101

TRENDnet TK-IP101

It all breaks down when it comes to the software though. First of all, the guide for certificate creation that is supposed to be found on the CD that comes with the box is just not there. Also, the XCA software TRENDnet suggests one should use was also missing. Not good. Luckily, the software is open source and can be downloaded from the [XCA SourceForge project]. It’s basically a graphical OpenSSL front end. Create a PEM-encoded root certificate, PEM-encoded server certificate and a PKCS#12 client certificate, the latter signed by the root cert. So much for that. Oh, and I uploaded that TRENDnet XCA guide for you in case it’s missing on your CD too, its a bit different for the newer version of XCA, but just keep in mind to create keys beforehand and to use certificate requests instead of certificates. You then need to sign the requests with the root certificate. With that information plus the guide you should be able to manage certificate creation:

But it doesn’t end there. First I tried the Windows based viewer utility that comes with its own certificate import tool. Import works, but the tool will not do client+server authentication. What it WILL do before terminating itself is this:

TK-IP101 IPViewer.exe bug

TK-IP101 IPViewer.exe bug

I really tried to fix this. I even ran it on Linux with Wine just to do an strace on it, looking for failing open() calls. Nothing. So I thought… Why not try the second option, the Java Viewer that goes by the name of KViewer.jar? Usually I don’t install Java, but why not try it out with Oracles Java 1.7u60, eh? Well:

So yeah. What the hell happened there? It took me days to determine the exact cause, but I’ll cut to the chase: With Java 1.6u29, Oracle introduced multiple changes in the way SSL/TLS worked, also due to the disclosure of the BEAST vulnerability. When testing, I found that the software would work fine when run with JRE 1.6u27, but not with later versions. Since Java code is pretty easily decompiled (thanks fly out to Martin A. for pointing that out) and the Viewer just came as a JAR file, I thought I’d embark on the adventure of decompiling Java code using the [Java Decompiler]:

Java Decompiler decompiling KViewer.jar's Classes

Java Decompiler decompiling KViewer.jar’s Classes

This results in surprisingly readable code. That is, if you’re into Java. Which I am not. But yeah. The Java Decompiler is pretty convenient as it allows you to decompile all classes within a JAR and to extract all other resources along with the generated *.java files. And those I imported into a Java development environment I knew, Eclipse Luna.

Eclipse Luna

Eclipse Luna

Eclipse Luna (using a JDK 7u60) immediately complained about 15 or 16 errors and about 60 warnings. Mostly that was missing primitive declarations and other smaller things that even I managed to fix, got rid even of the warnings. But the SSL bug persisted in my Java 7 build just as it did before. See the following two traces, tracing SSL and handshaking errors, one working ok on JRE 1.6u27, and one broken on JRE 1.7u60:

So first I got some ideas from stuff [posted here at Oracle], and added the following two system properties in varying combinations directly in the Main class of KViewer.java:

public static void main(String[] paramArrayOfString)
{
  /* Added by the GAT from http://wp.xin.at                        */
  /* This enables insecure TLS renegotiation as per CVE-2009-3555  */
  /* in interoperable mode.                                        */
  java.lang.System.setProperty("sun.security.ssl.allowUnsafeRenegotiation", "false");
  java.lang.System.setProperty("sun.security.ssl.allowLegacyHelloMessages", "true");
  /* ------------------------------------------------------------- */
  KViewer localKViewer = new KViewer();
  localKViewer.mainArgs = paramArrayOfString;
  localKViewer.init();
}

This didn’t really do any good though, especially since “interoperable” mode should work anyway and is being set as the default. But today I found [this information on an IBM site]!

It seems that Oracle fixed the BEAST vulnerability in Java 1.6u29 amongst other things. They seem to have done this by disallowing renegotiations for affected implementations of CBCs (Cipher-Block Chaining). Now, this KVM switch can negotiate only a single cipher: SSL_RSA_WITH_3DES_EDE_CBC_SHA. See that “CBC” in there? Yeah, right. And it got blocked, because the implementation in that aged KVM box is no longer considered safe. Since you can’t just switch to a stream-based RC4 cipher, Java has no other choice but to drop the connection! Unless…  you do this:

public static void main(String[] paramArrayOfString)
{
  /* Added by the GAT from http://wp.xin.at                             */
  /* This disables CBC protection, thus re-opening the connections'     */
  /* BEAST vulnerability. No way around this due to a highly restricted */
  /* KLE ciphersuite. Without this fix, TLS connections with client     */
  /* certificates and PKI authentication will fail!                     */
  java.lang.System.setProperty("jsse.enableCBCProtection", "false");
  /* ------------------------------------------------------------------ */
  /* Added by the GAT from http://wp.xin.at                        */
  /* This enables insecure TLS renegotiation as per CVE-2009-3555  */
  /* in interoperable mode.                                        */
  java.lang.System.setProperty("sun.security.ssl.allowUnsafeRenegotiation", "false");
  java.lang.System.setProperty("sun.security.ssl.allowLegacyHelloMessages", "true");
  /* ------------------------------------------------------------- */
  KViewer localKViewer = new KViewer();
  localKViewer.mainArgs = paramArrayOfString;
  localKViewer.init();
}

Setting the jsse.enableCBCProtection property to false before the negotiation / handshake will make your code tolerate CBC ciphers vulnerable to BEAST attacks. Recompiling KViewer with all the code fixes including this one make it work fine with 2-way PKI authentication using a client certificate on both Java 1.7u60 and even Java 1.8u5. I have tested this using the 64-Bit x86 VMs on CentOS 6.5 Linux as well as on Windows XP Professional x64 Edition and Windows 7 Professional SP1 x64.

De-/Recompiled & "fixed" KViewer connecting to a machine much older even than its own crappy code

De-/Recompiled & “fixed” KViewer.jar connecting to a machine much older even than its own crappy code

I fear I cannot give you the modified source code, as TRENDnet would probably hunt me down, but I’ll give you the compiled byte code at least, the JAR file, so you can use it yourself. If you wanna check out the code, you could just decompile it yourself, losing only my added comments: [KViewer.jar]. (ZIPped, fixed / modified to work on Java 1.7+)

Both the modified code and the byte code “binary” JAR have been returned to TRENDnet in the context of my open support ticket there. I hope they’ll welcome it with open arms instead of suing me for decompiling their Java viewer.

In reality, even this solution is nowhere near perfect. While it does at least allow you to run modern Java runtime environments instead of highly insecure older ones plus using pretty secure PKI auth, it still doesn’t fix the man-in-the-middle-attack issues at hand. TRENDnet should fix their KVM firmware, enable it to run the TLSv1.2 protocol with AES256 Galois-Counter-Mode ciphers (GCM) and fix the many, many problems in their viewer clients. The TK-IP101 being an end-of-life product means that this is likely never gonna happen though.

It does say a lot when the consumer has to hack up the software of a supposedly high-security 400€ networking hardware piece by himself just to make it work properly.

I do still hope that TRENDnet will react positively to this, as they do not offer a modern replacement product to supersede the TK-IP101.