Mar 152018
Windows 2000 + Let's Encrypt logo

[1] 1.) Introduction

There has been an issue with my [stoneage server]German flag (which is also hosting this weblog) that has been bugging me for quite a while now: I’ve been scared of the time when other server operators and software developers would start to seriously disable ancient SSL/TLS ciphers such as SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA and SSL_RSA_WITH_3DES_EDE_CBC_SHA, or in other words: SHA1, RC4 and 3DES. The services are actually made of both non-free as well as free services that are using several different cryptographic libraries such as different OpenSSL versions but also WinSSL CryptAPI / schannel. Naturally it’s the latter which is presenting the biggest issue: The CryptAPI of Windows 2000 Server is ancient. And while it can do at least TLS v1.0, the ciphers have been becoming the true burden. Unfortunately (?!), some services on do require some form of widely accepted encryption.

Some of the servers do have interchangeable OpenSSL libraries – so you can just swap those .dll files for an upgrade – while others do not. Some from the latter category can be backported to / recompiled for Windows 2000 to upgrade OpenSSL, like I’ve been [able to do] for the UnrealIRCd IRC server. Some however can not.

And then there are services which are using Windows SSL or in other words the CryptAPI / schannel. Those are the most inflexible of the pack.

Another problem is that self-signed certificates such as the ones I’ve been using have also become increasingly problematic. Most client software like web browsers in particular, but also email clients, IRC clients and others keep pestering their users quite a bit when being presented with such an “untrustworthy” SSL certificate. They really want one signed by a fully trusted certificate authority (CA) or an intermediate CA. The best solution for that problem right now is to get a Let’s Encrypt[2] certificate, as it’s free and well-trusted. Only reason I haven’t done that so far is that it needs automatisms (=ACME client software) in place to remain manageable.

I wanted to solve both issues in one fell swoop.

2.) The trigger

eMail logoThen again, you know how people are – they tend to act only when something bad has already happened. In the tradition of that (bad) behavior I’ve chosen to act only where the problem at hand was truly easy to solve. After I’ve managed to compile a modern enough OpenSSL library, I’ve just swapped it on the spot where possible, but I haven’t touched the more problematic services, where such a thing is not doable.

However, there has been a serious issue recently when mail server operators started to beef up their cryptography across the board. It seems there are some updates being rolled out about now which block the ancient ciphers and/or protocols I mentioned in the introduction.

The truly serious part is that seemingly, all mail servers who encounter another that does feature STARTTLS on SMTP port 25, but has no secure ciphers to offer just drop the connection on the spot without generating any error. The mail will not be delivered, but no delivery error will be returned to the sender either! It’s truly a case where the eMails just “disappear” without anyone ever noticing a problem at first. To make matters worse, there was no way to disable just STARTTLS for SMTP with my server software. It’s either no SSL/TLS at all or fully enabled STARTTLS on all plain eMail ports.

See this log to get an idea (remote host names have been replaced with “” and IP addresses as well as security-relevant data have been masked here):

expand/collapse log file

The most interesting part is clearly at the bottom, where it says “SSL negotiation successful (TLS 1.0, 2048 bit key exchange, 168 bit 3DES encryption)”. 3DES is the best Windows 2000 can do by itself, and it looks as if the remote server would accept the implementation just fine. But what happens next is that the remote machine just drops the connection, and that’s it!

The remote side who sent the eMail (that was myself from my account at work actually) never got any delivery failure notification, and after asking other people about it, it was just the same. As said, the mails just vanish!

I also talked to the operator of the mail gateway at work, and he said he didn’t see anything in the logs either, other than that the connection was just being dropped. Pretty stupid to not generate a proper error here, if you ask me.

Well, that was enough of a reason to act! eMails just disappearing is completely unacceptable after all!

3.) What can you do?

I thought about this issue in the past already, and one of my ideas was to use something like [BlackWingCats’] kernel API extensions for Windows 2000 (“KernelEx”). The issue with that is though, that it’s modifying large parts of the operating system, and it’s very incompatible to my German version, wrecking half of the system upon installation during my tests in a VM. So that idea went down the drain pretty fast.

Very recently however, I got the idea that maybe I could use [stunnel] to solve the cipher problem. It’s basically a port mapper wrapping plain text protocols up in SSL/TLS. It’s a program coming from the Linux/UNIX world, but it also works on Windows. On top of that, it miraculously runs on Windows 2000 as well, even in its newest version bundling modern OpenSSL 1.0.2.

Additionally, I thought I’d once again try to get some Let’s Encrypt ACME client to work on Windows 2000 for certificate issuing and renewal, even though I failed to get any of them working before.

3a.) Let’s Encrypt configuration via ZeroSSL

ZeroSSL bannerSince we need an SSL certificate for stunnel anyway, let’s cover this part first. For ease of use, I chose ZeroSSLs’ [Crypt::LE] Perl tool. I didn’t like their [web-based configuration] too much, as they’ll be issuing your private key for you on their servers.

Generally, when dealing with cryptography and trust concepts, I wouldn’t recommend anyone other than yourself generate and use your private key, so that’s one reason why I chose their Perl tool instead. Plus, you can’t automate the certificate renewal process with some web tool, but you can with Perl.

If you don’t have Strawberry Perl installed on your machine, you can still rely on their [Windows binaries] as well. Those are basically just and the necessary Perl parts wrapped in an le32.exe file. Crypt::LE also supports ActiveState Perl, but the free Strawberry Perl should be preferable, if you’re choosing that path.

Unfortunately, if you choose to use the .exe version, it won’t run on Windows 2000 out of the box, as it calls the WinSock 2.0 function freeaddrinfo(), which is only available on Windows XP and newer. For an easy fix, you can use a modified WS2_32.dll WinSock library found in the dllfiles\ subfolder of this [winsock2_getaddrinfo.rar] archive by [Martin Brenner]German flag, if you choose to trust the DLL.

If you do, just put it next to le32.exe, and make sure you launch the program only while sitting within the installation folder of le32.exe itself. Do not overwrite your system-wide %WINDIR%\system32\WS2_32.dll, you don’t need to do that, and you shouldn’t either!

As said, if you don’t trust the hack for the binary, you need to install Strawberry Perl and follow the instructions for the compilation & installation of Crypt::LE from their website.

3a1.) Ok, I have the tools, now what?

I won’t cover the process of using Crypt::LE, as there is an excellent manual [right here at ZeroSSL]! There is one thing that needs to be said though: You need an openssl.exe for the initial certificate request and key generation part. There is one bundled with stunnel in the subdirectory bin\ of its installation folder, you can just use that.

But before you start with it on a cmd terminal, you’ll need to tell OpenSSL where to look for its configuration file. Say you’ve installed stunnel in %PROGRAMFILES%\stunnel\, then run the following command before starting to work with OpenSSL:

SET "OPENSSL_CONF=%PROGRAMFILES%\stunnel\config\openssl.cnf"

This sets %OPENSSL_CONF% to the file name of the OpenSSL configuration, and OpenSSL will automatically parse that environment variable. Adjust paths as necessary, then follow ZeroSSLs’ manual to get your first Let’s Encrypt certificate(s)!

3b.) stunnel

stunnel on Windows 2000

stunnel on Windows 2000

If you’ve been following this article, you’ll already have stunnel installed by now. On Linux & UNIX, stunnel is just a command line tool and/or xinetd service, but on Windows, you also get a bit of a GUI and a tray icon with it. You’ll still have to configure it by editing its config\stunnel.conf configuration file with your favorite text editor however.

Say you wanted to protect a web server on port 80 by adding HTTPS on port 443 for it. The corresponding configuration entry in that configuration file would look like that (here: with separate key file not stored directly within the certificate):

accept  = 443
connect = 80
cert    = mydomain.pem
key     = mydomain.key

stunnel will listen on port 443 with implicit TLS for you, and then redirect the traffic to port 80 on the same machine. To a web browser connecting to, it’ll look like just another TLS-enabled web server.

The same goes for other implicit SSL/TLS services such as SMTPS, IMAPS, POP3S, etc.

The exception of course are explicit SSL/TLS implementations using the STARTTLS command. One classic example for that would be SMTP on port 587, which is typically STARTTLS-enabled. To make that work, stunnel has to emulate parts of the specific protocol to secure, so support for this is rather limited. Currently, stunnel supports the following network protocols for explicit STARTTLS:

  • CIFS (SMB, Samba, older implementation)
  • CONNECT (Client only)
  • IMAP (as per RFC 2595)
  • NNTP (as per RFC 4642)
  • POP3 (as per RFC 2449)
  • SMTP (as per RFC 2487)
  • SOCKS (versions 4, 4a and 5)

To use it, you’d need to configure the service as follows, this example is for SMTP with STARTTLS on port 587, mapping it to your local, unencrypted SMTP server:

accept   = 587
connect  = 25
cert     = mydomain.pem
key      = mydomain.key
protocol = smtp

Now if present, switch off your existing SSL/TLS services first (like make your web server stop listening to port 443), and then fire up the stunnel program and everything should work. You can also install it as a system service on Windows by the way, it’s very easy: stunnel -install.

Together with a properly requested and signed Let’s Encrypt certificate this will give any ancient server things like TLS v1.2 with AES256-GCM-SHA384 and any modern client will trust your certificate implicitly, as most vendors have by now added the ISRG CA certificates to their CACert bundles. Even Microsoft trusts them by now.

4.) Really putting it all together

Let's Encrypt logoEven if you’ve managed to do all of this manually, it won’t solve the problem forever. Let’s Encrypt certificates have a lifetime of just 90 days, so you will have to renew them pretty often. That can be done with just a batch script launching Crypt::LE as well as doing the rollout of the certificates and relaunch of the servers, so that they can re-read the certificates and key files.

Here’s an example script for stunnel and some other hypothetical servers that accept certificate files in different configurations. It assumes that you’re using Crypt::LE together with Strawberry Perl. As you can see, aside from Perl and Crypt::LE you won’t need anything else, as the rest can be done with regular Windows cmd builtins and the NetShell:

expand/collapse certificate-renewal.bat
  1. :: Renew our certificate if it expires within the next 30 days, put HTTP
  2. :: challenge files in C:\MyHTTProot\.well-known\acme-challenge\ and return
  3. :: code 42 if there was a renewal
  4. --------------------------------------------------------------------------
  5. SET "PERLBIN=C:\StrawberryPerl\perl\bin\perl.exe"
  6. SET "LE=C:\StrawberryPerl\perl\bin\"
  7. "%PERLBIN%" "%LE%" -renew 30 -generate-missing -unlink -live -legacy ^
  8.  -key "C:\MyCerts\my-account-key.key" -csr "C:\MyCerts\my-cert-request.csr" ^
  9.  -csr-key "C:\MyCerts\mydomain-key.key" -crt "C:\MyCerts\mydomain-cert.cert" ^
  10.  -domains "," -issue-code 42 ^
  11.  -path "C:\MyHTTProot\.well-known\acme-challenge\"
  13. :: Check whether there was a renewal, and roll out certs + restart servers
  14. :: if so, otherwise just terminate
  15. :: -----------------------------------------------------------------------
  16. IF %ERRORLEVEL% EQU 42 (
  17.   :: stunnel for servers with old cryptographic implementations, this requires
  18.   :: a domain+intermediate certificate bundle with a separate private key file
  19.   TYPE "C:\MyCerts\mydomain.cert" > "%PROGRAMFILES%\stunnel\config\mydomain.pem"
  20.   ECHO. >> "%PROGRAMFILES%\stunnel\config\mydomain.pem"
  21.   TYPE "C:\MyCerts\" >> "%PROGRAMFILES%\stunnel\config\mydomain.pem"
  22.   :: They key needs copying only once
  23.   :: COPY /V /Y "C:\MyCerts\mydomain.key" "C:\Server\stunnel\mydomain.key"
  25.   :: A server that needs domain certificate, intermediate CA cert and key all
  26.   :: separately
  27.   COPY /V /Y "C:\MyCerts\mydomain.cert" "C:\Server1\sslconf\"
  28.   :: They key and intermediate certificate need copying only once
  29.   :: COPY /V /Y "C:\MyCerts\" "C:\Server1\sslconf\"
  30.   :: COPY /V /Y "C:\MyCerts\mydomain.key" "C:\Server1\sslconf\"
  32.   :: A server that needs domain and intermediate certificates in one bundle, but
  33.   :: the private key as a separate file, like stunnel
  34.   TYPE "C:\MyCerts\mydomain.cert" > "C:\Server2\sslconf\mydomain.pem"
  35.   ECHO. >> "C:\Server2\sslconf\mydomain.pem"
  36.   TYPE "C:\MyCerts\" >> "C:\Server2\sslconf\mydomain.pem"
  37.   :: They key needs copying only once
  38.   :: COPY /V /Y "C:\MyCerts\mydomain.key" "C:\Server2\sslconf\"
  40.   :: Yet another server, that needs both certificates and your private key all
  41.   :: in one bundled file
  42.   TYPE "C:\MyCerts\mydomain.key" > "C:\Server3\sslconf\mydomain.pem"
  43.   ECHO. >> "C:\Server3\sslconf\mydomain.pem"
  44.   TYPE "C:\MyCerts\mydomain.cert" >> "C:\Server3\sslconf\mydomain.pem"
  45.   ECHO. >> "C:\Server3\sslconf\mydomain.pem"
  46.   TYPE "C:\MyCerts\" >> "C:\Server3\sslconf\mydomain.pem"
  48.   :: Restart all services to reload the certificate and key
  49.   :: ------------------------------------------------------
  50.   :: Restart stunnel
  51.   net stop "stunnel"
  52.   net start "stunnel"
  54.   :: Restart Server 1
  55.   net stop "Server 1 system service name"
  56.   net start "Server 1 system service name"
  58.   :: Restart Server 2
  59.   net stop "Server 2 system service name"
  60.   net start "Server 2 system service name"
  62.   :: Restart Server 3
  63.   net stop "Server 3 system service name"
  64.   net start "Server 3 system service name"
  65. )
  67. :: All done!

Now you can automate the process by creating a job in Windows task scheduler to launch that certificate-renewal.bat like every 20 days or so. The script will of course vary quite a bit depending on your environment and your services, so take it only as a rough guide.

And that’s how you get Let’s Encrypt certificates and modern cryptography up and running on an 18 years old Windows operating system, for what it’s worth. :roll:

5.) Bonus information

You can actually use stunnel in client mode as well. Say you’re using Windows 2000 Pro as your client operating system (*cough*) and your software is so old and insecure, that some remote server at say won’t talk to you anymore. Just run stunnel on your client on demand, with a per-host configuration such as this:

client = yes
accept = localhost:9999
connect =
CAfile = ca-certs.pem

Open up your web browser, surf to https://localhost:9999, and stunnel’ll redirect you to that server, which will now see a secure clientside SSL implementation. Only thing is that you might need to create an exception in your browser, because the host names don’t match between what you entered in the address field and what’s in the remote servers’ certificate, but no way around that.

And now, time for some cold beer! Beer Smilie

[1] The “Let’s Encrypt Radiant Lock” design mark is a trademark of the Internet Security Research group and is licensed under the CC-BY-NC 4.0. All rights reserved.

[2] The “Let’s Encrypt®” word mark is a trademark of the Internet Security Research group. All rights reserved.

Jul 282017 logo

1.) Introduction

Of course you could say: “If you’re going to use Russian software, that’s what you’d have to expect!”. But yeah. I’ve actually used tools written by Russian developers before, and they used to be very slim and fast, so I thought, why not give it a shot. Background is that I’ve finally ditched my ancient Nokia E72 “smart phone” based on Symbian 9.2 / S60 3rd, which has become almost unusable because of its lack of modern SSL ciphers (most websites won’t let you connect anymore) and because of its Skype and ICQ clients being banned from their respective servers.

So I finally went ahead and got myself an Android 7.1.1 device, the Blackberry KEYone, my second attempt at using the OS (first was a Motorola Milestone 2 with Android 2.1, a failure because of many reasons).

Anyway, I had to find an eMail app that would let me do two things:

  1. Display and send everything as plain text (I hate HTML mails and find them pretty insulting to be honest)
  2. Allow me to connect to mail servers which support only older SSL/TLS protocols and ciphers (I’ve got no choice here)

2.) The email client on Android

2a.) The app itself

So, I tested a lot of clients, one of which was [], a pretty high-ranked email app (4.6/5) with more than 10 million installs out there. Superficially, it looks just like pretty much any other email client, because there are likely readily available Android libraries for implementing email clients: client ad

An image directly from the Google play store, showing the apps’ GUI (click to enlarge)

So they advertise it with slogans like “ideal application for any mail” and “add all your email boxes in one application”. Actually, it’s ideal for just one thing: To hand over all your email accounts and emails to a Russian company and with it the Russian government – because in Russia, companies have to yield to the government and grant it full access to user accounts and data by default.

I guess free Russian developers and actual Russian software companies have to be treated very differently!

What I did was to enter my own email account credentials in the app to be able to fetch my emails via IMAP. I found that the client does not meet my personal requirements (no way to force plain text email), so after my quick test, I just uninstalled the app.

2b.) What the app does without you noticing

However, by that time, the app had already leaked my account credentials to certain and servers ( is a part of the bigger group), which had now started to log into my account from Russia – periodically checking all my email boxes and downloading every single message stored on my own server. Let’s have a look at the logs!

Here is their first connection attempt, coming from ( as well as the second one from (

Tue 2017-07-25 14:59:27: Session 5554; child 3; thread 1232
Tue 2017-07-25 14:59:26: Accepting IMAP connection from []
Tue 2017-07-25 14:59:27: SSL negotiation successful (♡)
Tue 2017-07-25 14:59:27: --> * OK ♡ IMAP4rev1 ♡ ready
Tue 2017-07-25 14:59:27:  1 OK LOGIN completed
Tue 2017-07-25 14:59:27:  1 OK LIST completed
Tue 2017-07-25 14:59:27:  * BYE IMAP engine signing off (no errors)
Tue 2017-07-25 14:59:27: --> . OK LOGOUT completed
Tue 2017-07-25 14:59:27: IMAP session complete, (2654 bytes)
Tue 2017-07-25 14:59:27: ----------
Tue 2017-07-25 15:00:04: ---------- Partial transcript, remainder will follow.
Tue 2017-07-25 15:00:04: Session 5556; child 4; thread 3588
Tue 2017-07-25 14:59:28: Accepting IMAP connection from []
Tue 2017-07-25 14:59:28: SSL negotiation successful (♡)
Tue 2017-07-25 14:59:28: --> * OK ♡ IMAP4rev1 ♡ ready
Tue 2017-07-25 14:59:28:  1 OK LOGIN completed
Tue 2017-07-25 14:59:28:  * CAPABILITY ♡
Tue 2017-07-25 14:59:28: --> 2 OK CAPABILITY completed

You might have guessed it, the ♡ marks things I cut from the logs for privacy reasons. Guess I got a bit too creative. ;) Anyway, this was only the beginning. Later, some mail collector servers from the IP range 185.30.17*.** (collector* started to log in and download all my emails from all my folders! Here’s just a small excerpt from the commands issued with one of my archive folders serving as an example – most of the stuff has been cut out to make it more concise:

Tue 2017-07-25 14:59:29:

All of those are just the remote commands issued to my server. Note that in IMAP4, UID FETCH <UID> BODY.PEEK[] at the bottom is an actual message download. Needless to say, there were thousands of those going unchecked, because it took me 3 days to discover the leak. And I only discovered it coincidentally too. So by that time they had long downloaded all my emails from my own server to Russia. If you’re not running your own mail server, you wouldn’t even notice this.

So if you just happened to enter your AOL, Yahoo, gmail or Hotmail accounts, you’d never see those Russian servers accessing those accounts remotely!

3.) This can’t be ok, can it?

This behavior is completely unacceptable and has been reported to Google as it is borderline regarding Googles’ own privacy policy:

Privacy Policy & Secure Transmission

If your app handles personal or sensitive user data (including personally identifiable information, financial and payment information, authentication information, phonebook or contact data, microphone and camera sensor data, and sensitive device data) then your app must:

  • Post a privacy policy in both the designated field in the Play Console and from within the Play distributed app itself.
  • Handle the user data securely, including transmitting it using modern cryptography (for example, over HTTPS).

The privacy policy must, together with any in-app disclosures, comprehensively disclose how your app collects, uses and shares user data, including the types of parties with whom it’s shared.

Prominent Disclosure Requirement

If your app collects and transmits personal or sensitive user data unrelated to functionality described prominently in the app’s listing on Google Play or in the app interface, then prior to the collection and transmission, it must prominently highlight how the user data will be used and have the user provide affirmative consent for such use.

First of all, the mail collectors drop down to cryptographic ciphers even I wouldn’t use anymore when asked to do so. I mean, it sounds hypocritical coming from me (because I’m actually using very old ciphers too, as I’m out of options on my ancient server), but they do fall back to what’s by no means “modern cryptography”. Also, the leaking of account credentials and data to Russian servers and the continuous use of said data even after the user has stopped using services is not mentioned anywhere while installing or using the app, not that I could see at least.

I most definitely didn’t give my consent to having the app use my data like this – I wasn’t presented with an EULA during the installation or use of the software. Also, the (Russian…) email they had sent me after accounts were set up in the app didn’t show an EULA or privacy statement either. It’s even worse considering [’s history] in terms of handling that information.

None of this is new either, see e.g. [this Reddit] (MyMail is from – as said, a part of the Group).

Well, I started to look around and found a [user agreement] online. The interesting part is point 4.1.3:

4.1.3 In addition to the registration procedure on the Internet Service specified in clause 4.1. the user may be granted the right to register through using its data (login and password) of the e-mail box registered at the third person’s resource.

Irrespective of using any method of registration on the Internet Service the User’s password used to visit the Internet Service shall be beyond the reach of Mail.Ru.

Now that part is a bit problematic. The “third person’s resource” is clearly your own mail account on some other server. So like my email account on my own server. The question is, what exactly does it mean when they say that the users’ password shall be “beyond the reach of Mail.Ru”? Guess they’d mean my actual plain text password, right?

Well, no matter if they use hashes with <-- 2 authenticate CRAM-MD5, or instead just plain text <-- 1 LOGIN ♡@♡.♡ ♡♡♡♡♡♡, they do have my password stored away on their servers as clear text (probably on some encrypted file system? But still.). I wouldn’t call that “beyond the reach of” anymore.

I guess I could have misread the user agreement (that I wasn’t even presented with!) somewhere, but it doesn’t seem to me as if they’d be following their own rules regarding privacy?!

If you’re using the app I can only advise you uninstall it if you haven’t done so already and to change all account passwords ever entered in the application to stop the Russian collector servers from logging into your accounts and “stealing” your email even after app deinstallation.

On a side note: Since K-9 Mail isn’t exactly right for me either, I settled with [R2Mail2], which is being developed in Austria by the company [RundQuadrat]. I’ve been talking with its developer over the last few days, and he seems a like a nice family guy. I do like the client, as it has an impressive feature list, let’s just name a few:

  • Manually configurable SSL/TLS cipher list, you can pick which ciphers you want or don’t want to use, including the option to support a few deprecated ciphers.
  • Data oriented encryption with either S/MIME, or even PGP and PGP/MIME for emails and also arbitrary files (a small tool for file encryption is embedded in the client).
  • Support for Microsoft Exchange servers
  • Option to stop syncing in the background, so a full shutdown of the app is possible with ease.
  • Full plain text support, so you can force all messages to be displayed and sent in plain text only.
  • The client itself can be password protected and can be instructed to store all local data in encrypted form.
  • Extremely configurable: Reply/Forward Prefixes, host name use in EHLO command, notification LED color ( :roll: ), IPv4/IPv6 preference, Certificate store access & configuration, peak day/time option to boost synchronization, sync grouping with other apps to save battery, local email pruning and many, many other things.

It does come at a price though, as it costs 4.80€. But if you want a seriously powerful and I’d say more trustworthy email application for Android, you might give this a shot. Otherwise, maybe just go with the free K-9 mail app if you want plain text and don’t need to rely on mail servers with antiquated SSL/TLS implementations.

But no matter what, stay away from and MyMail!

Update, 2017-12-30:

Thanks to a notification from [Bier.jpg]German flag I have now learned, that the testing password used to probe the and MyMail services (in context of writing this article) has been leaked to the Internet!

The corresponding data has been presented to the public on the Chaos Communication Congress (34C3) of the corresponding Chaos Computer Club (CCC), in the context of its [Can I Haz Passw0rds?] project. The leak website will be offline soon enough, but you can continue to access the password database on the [Tor network] after the Congress has ended (Open that link in the [Tor Browser]). Since my original, former true password has not been leaked, this must have happened some time after 2017-07-25.

Additionally to the two leaks that I attribute to and MyMail, there was also a third one with the same, temporary password. I’ve used it to continue my tests of all kinds of Android eMail applications, but unfortunately, I can’t be sure who the third culprit might have been. :( The only two Apps I’m sure couldn’t have been responsible are [K-9 Mail] and the Austrian program [R2Mail2], as those have only been fed real passwords, and they’re not supposed to leak them off-device anyway.

So much for that! :roll:

PS.: I cannot exactly prove, that two of the three leaks are from and MyMail, but given their handling of passwords and their history of repeated, massive password database leaks, I’m pretty sure that they were involved in this as well.

Jun 292017
Microsoft Security Essentials logo

Recently, I ran into another issue on my old Windows XP x64 machines, and on regular XP and Windows Vista boxes as well. Microsofts’ Security Essentials software – let’s just call it MSSE – stopped updating itself. Even more problematic was the fact that manual updates wouldn’t work anymore either. It would download the new definitions, but not install them. With no error messages to be found anywhere, I had no idea what to do. Ok, on XP x64, MSSE was never supported to begin with (the last 64-bit version 4.4.304.0 for Vista works though), but the problem also showed up on supported systems, maybe because of their EoL status.

Strangely though, sometimes it would work out of the blue, but mostly, it seems to be broken. This is specifically bad right now, because very recently, the Microsoft Malware Protection Engine that MSSE and many other Microsoft security products are based on has had some critical bugs resulting in potential remote code execution exploits (at the highest privilege levels). By just scanning a file – e.g. an attachment of an email – the code inside would be run and evaluated by the MMPE, and during that phase, the code could “break out” into the system, infecting it with god knows what.

So, updates are really important right now, or the security tool you may rely upon to protect you at least a little bit may become the most dangerous thing on your old XP x64, PosReady2009 XP or Vista box, and not just there but on more modern systems as well (The Windows Defender on Windows 7+ uses the same MMPE).

What I did was to download the full update pack mpam-fe.exe from Microsoft [here], and install it manually. Interestingly, this worked just fine. Based on that, I wrote a very simple little batch script, that automates the process. Only drawback: It relies on one external tool, namely wget.exe, needed to download the package from Microsoft. Sadly, Windows doesn’t seem to have a command line tool to do that on its own. You can get wget by installing [GNU on Windows], a collection of free UNIX command line tools built for Windows.

Once wget.exe is in your users’ search path, you can use the task scheduler to automate the launch of the following updater script (just save it as a .bat file somewhere):

  1. @ECHO OFF
  2. :: Fetch the most current AV definitions (%TEMP% doesn't need 
  3. :: to be quoted, because it returns a short path anyway):
  4. wget.exe --no-check-certificate -O %TEMP%\mpam-fe.exe ""
  5. :: Install them, wait for 120 seconds, then delete the installer:
  6. %TEMP%\mpam-fe.exe
  7. CHOICE /C:AB /D:A /T:120 >NUL 2>&1
  8. DEL /F %TEMP%\mpam-fe.exe
  9. :: And we're done.
  10. EXIT

I have no idea why the regular way of updating MSSE breaks on some systems, but now that I’ve been running the above script on my machines every night, MSSE is staying up to date pretty nicely. Ah yes, one thing: In case your system is 32-bit and not 64-bit, you need to change the URL being called by wget. Just replace the HTTP variable arch=x64 with arch=x86 in that script, and it’ll download the 32-bit version of mpam-fe.exe!

Also note that you can actually abort the 120 second wait by maybe accidentally pressing either A or B in the above example, because the delay is implemented in a weird way using CHOICE, since Windows XP doesn’t have a native sleep or wait command. If you want to prevent such accidents, you can make CHOICE use stranger characters that you would never be able to enter accidentally, like this for example:

  1. CHOICE /C:©® /D:® /T:120 >NUL 2>&1

And with that you can keep older machines using MSSE a tiny little bit more secure in case the auto-update breaks for you as well.

Nov 222016
FreeBSD IBM ServeRAID Manager logo

And yet another FreeBSD-related post: After [updating] the IBM ServeRAID manager on my old Windows 2000 server I wanted to run the management software on any possible client. Given it’s Java stuff, that shouldn’t be too hard, right? Turned out not to be too easy either. Just copying the .jar file over to Linux and UNIX and running it like $ java -jar RaidMan.jar wouldn’t do the trick. Got nothing but some exception I didn’t understand. I wanted to have it work on XP x64 (easy, just use the installer) and Linux (also easy) as well as FreeBSD. But there is no version for FreeBSD?!

The ServeRAID v9.30.21 manager only supports the following operating systems:

  • SCO OpenServer 5 & 6
  • SCO Unixware 7.1.3 & 7.1.4
  • Oracle Solaris 10
  • Novell NetWare 6.5
  • Linux (only certain older distributions)
  • Windows (2000 or newer)

I started by installing the Linux version on my CentOS 6.8 machine. It does come with some platform-specific libraries as well, but those are for running the actual RAID controller management agent for interfacing with the driver on the machine running the ServeRAID controller. But I only needed the user space client program, which is 100% Java stuff. All I needed was the proper invocation to run it! By studying IBMs, I came up with a very simple way of launching the manager on FreeBSD by using this script I called (Java is required naturally):

  1. #!/bin/sh
  3. # ServeRAID Manager launcher script for FreeBSD UNIX
  4. # written by GAT.
  5. # Requirements: An X11 environment and java/openjdk8-jre
  7. curDir="$(pwd)"
  8. baseDir="$(dirname $0)/"
  10. mkdir ~/.serveraid 2>/dev/null
  11. cd ~/.serveraid/
  13. java -Xms64m -Xmx128m -cp "$baseDir"RaidMan.jar \
  14. -jar "$baseDir"RaidMan.jar $* < /dev/null >> RaidMan_StartUp.log 2>&1
  16. mv ~/RaidAgnt.pps ~/RaidGUI.pps ~/.serveraid/
  17. cd "$curDir"

Now with that you probably still can’t run everything locally (=in a FreeBSD machine with ServeRAID SCSI controller) because of the Linux libraries. I haven’t tried running those components on linuxulator, nor do I care for that. But what I can do is to launch the ServeRAID manager and connect to a remote agent running on Linux or Windows or whatever is supported.

Now since this server/client stuff probably isn’t secure at all (no SSL/TLS I think), I’m running this through an SSH tunnel. However, the Manager refuses to connect to a local port because “localhost” and “” make it think you want to connect to an actual local RAID controller. It would refuse to add such a host, because an undeleteable “local machine” is always already set up to begin with, and that one won’t work with an SSH tunnel as it’s probably not running over TCP/IP. This can be circumvented easily though!

Open /etc/hosts as root and enter an additional fantasy host name for I did it like that with “xin”:

::1			localhost xin		localhost xin

Now I had a new host “xin” that the ServeRAID manager wouldn’t complain about. Now set up the SSH tunnel to the target machine, I put that part into a script /usr/local/sbin/ Here’s an example, 34571 is the ServeRAID agents’ default TCP listen port, shall be the LAN IP of our remote machine hosting the ServeRAID array:

ssh -fN -p22 -L34571:

You’d also need to replace “mysshuser” with your user name on the remote machine, and “” with the Internet host name of the server via which you can access the ServeRAID machine. Might be the same machine or a port forward to some box within the remote LAN.

Now you can open the ServeRAID manager and connect to the made-up host “xin” (or whichever name you chose), piping traffic to and from the ServeRAID manager through a strongly encrypted SSH tunnel:

IBM ServeRAID Manager on FreeBSD

It even detects the local systems’ operating system “FreeBSD” correctly!


IBM ServeRAID Manager on FreeBSD

Accessing a remote Windows 2000 server with a ServeRAID II controller through an SSH tunnel, coming from FreeBSD 11.0 UNIX

IBM should’ve just given people the RaidMan.jar file with a few launcher scripts to be able to run it on any operating system with a Java runtime environment, whether Windows, or some obscure UNIX flavor or something else entirely, just for the client side. Well, as it stands, it ain’t as straight-forward as it may be on Linux or Windows, but this FreeBSD solution should work similarly on other systems as well, like e.g. Apple MacOS X or HP-UX and others. I tested this with the Sun JRE 1.6.0_32, Oracle JRE 1.8.0_112 and OpenJDK 1.8.0_102 for now, and even though it was originally built for Java 1.4.2, it still works just fine.

Actually, it works even better than with the original JRE bundled with RaidMan.jar, at least on MS Windows (no more GUI glitches).

And for the easy way, here’s the [package]! Unpack it wherever you like, maybe in /usr/local/. On FreeBSD, you need [archivers/p7zip] to unpack it and a preferably modern Java version, like [java/openjdk8-jre], as well as X11 to run the GUI. For easy binary installation: # pkg install p7zip openjdk8-jre. To run the manager, you don’t need any root privileges, you can execute it as a normal user, maybe like this:

$ /usr/local/RaidMan/

Please note that my script will create your ServeRAID configuration in ~/.serveraid/, so if you want to run it as a different user or on a different machine later on, you should recursively copy that directory to the new user/machine. That’ll retain the local client configuration.

That should do it! :)

Dec 252015

NFC logoAnd here we have another NFC-enabled banking card for contactless payment, this time it’s a VISA credit card issued by [Card Complete Austria]. Might I add, this is one of the few companies which also still leisurely prints the full credit cards’ numbers on their invoices, which are then being sent out via regular postal mail, clearly showing off what those letters are on the envelope. Good Job, Card Complete, especially your reply regarding the matter, telling me that “it’s okay, no need to change that”! bash

In any case, I’ve written about this whole NFC thing before in much greater detail, [see here]! That article will show you the risks involved when working with potentially exploitable NFC cards, which mostly pose a data leaking problem. But you may wish to read the comments there as well, especially [this one here]. This shows that VISA cards tend(ed?) to be extremely vulnerable up to the point where a person walking by close enough to your wallet could actually draw money from your credit card without you noticing.

I have no idea whether this security hole still exists in todays’ NFC-enabled VISA cards, but I’m no longer gonna take that risk. Especially not since I don’t even need the NFC tech in that (or any other) banking card. Once again, we’re just gonna physically destroy the induction coil that powers the NFC chip in the card and which also operates as its antenna. Since I’m lazy, I didn’t do the “poor mans’ x-ray” photos this time (you can see how to do that in the first NFC post), just before and after pictures:

So, before:

As you can see, there are already signs of use on this card. Yeah, I’ve been lazy, running around with an NFC enabled VISA for too long already. Time to deal with it then:

Finding a good spot for my slightly oversized drilling head wasn’t so easy on this card, because the card numbers, signature field, magnetic strip and other parts like the hologram where in the way. But in the end I managed to drill a hole in about the right spot. Because of the heavy image editing you can’t see it, but I did damage the first of my credit cards’ numbers, but only slightly, so it should still be o.k., just a bit of paint that came off.

So, once again: You’re not welcome in my wallet, so bye bye, NFC!

Jun 302015

NFC logoNFC – or “near-field communication” technology is a now-booming system for sending and receiving small chunks of data over very short distances. You may have heard about modern cellphones supporting the system to read information from small tags – in essence chips you stick onto something to provide local, small pieces of information. This can serve augmented reality purposes for instance, in a sense at least, providing metadata about objects anywhere in the world.

It’s nowadays also being used for payment though, both in conjunction with smartphones and their active NFC chips as well as debit/credit banking cards and their integrated, passive NFC circuitry.


  1. NFC basics
  2. NFC-capable banking cards
  3. Using a modern Android phone to fetch data from a banking card
  4. The theft issue
  5. Modern cards may be more close-lipped
  6. Killing NFC for good

1.) NFC basics

So there are connections between active chips (say: phone to phone) as well as active-passive ones, in which case the active side (a phone, an electronic cashier) will talk to the passive one. In the latter case, the active chip will generate an electromagnetic field which reaches a copper coil embedded in the passive device or tag, creating enough inductive voltage to power that passive NFC chip.

According to information that can be found on the web and in some specifications, the range should be about 20cm with data transfer rates of 106kbit/s, 212kbit/s or 424kbit/s, and in some non-standard cases 848kbit/s. That’d be 13.25kiB/s, 26.5kiB/s, 53kiB/s or 106kiB/s respectively. The time to build up a connection is around one tenth of a second. There are NFC range extenders [like this one] for active chips however, which can boost the range up to almost 1 meter! And that’s were the alarms start ringing in my head.

Now, why is any of that dangerous to begin with? Because it’s being used for payments and because there may be a significant information leaking issue with some of those banking cards.

2.) NFC-capable banking cards

First of all, I’d like to thank two of my colleagues, which shall remain anonymous, for providing a.) a fully affected debit card and b.) a NFC-capable Android smartphone.

Let’s take a look at our affected card (click to enlarge images, as usual):

A PayPass-based NFC-capable debit card

A PayPass-based NFC-capable debit card, see that PayPass logo?

Now this is not my own card, so I didn’t have unlimited access to it. Since my own cards – both debit and credit – were not NFC-capable yet, I simply ordered a new one from my bank. There are other people on the web who used CT/X-Ray like [here] or [here] to visualize the internals of such cards, but I wanted a cheap solution that every layman can copy easily. As a matter of fact, any bright light (even a cellphones LED flash, when used as a torch) is sufficient, see here:

NFC coil visualized by normal light

The NFC coil on my new card, visualized by normal light, in this case a Sigma EVO X halogen lamp used for riding mountain bikes at night. This is a stitched image assembled from 11 individual photographs. And yes, I left my given name in the clear there. wink

For more clarity, see the next image:

Here I emphasized the coil a bit, so you'd know what to look for

Here I emphasized the coil a bit, so you would know what to look for

Now this coil has two functions: First – as mentioned above – it provides inductive voltage and with it up to 15mA of power to run the NFC chip and potentially some flash memory. Second, it also is the NFC chips’ antenna to properly receive the signal on NFCs 13.56MHz radio frequency spectrum. So, how about we talk to that chip a little ourselves, now shall we?

3.) Using a modern Android phone to fetch data from a Banking card

A Frenchman named [Julien Millau] luckily has developed an Android app called “Banking card reader NFC (EMV)”, which you can find on [Google Play] for free, including the source code as it’s licensed under the [Apache License, v2.0]. There are other apps too, tailored towards cards with local features (I’ll get to those later), but this is a good, generic one.

So what you’ll need is an NFC-capable Android smartphone, that app, and some banking card with NFC enabled. If you’ve got a chatty one on top of things, you can do this:

The basic card info might not look like much, as it’s supposed to show only the cards serial number. Some cards – like this one here – however give you the bank account number instead! Nice one. So this is our information leak #1.

As you can see on the other two images, the card also features some flash memory, holding a very interesting transaction log. By sending hexadecimal commands of the form 00 B2 NN 5C 00 to the card, where NN equals the log entry number, we can get a nice transaction log including amounts paid. So 00 B2 01 5C 00 would get log entry #1, 00 B2 08 5C 00 gets #8, 00 B2 0E 5C 00 gets #14 and so on. After decoding, you get the date and amount of money spent for each transaction, and that includes both NFC transactions and normal full-contact transactions, where you put your card into a real chip reader and enter your pin.

So no matter how you pay, it will be logged on such cards. And that log can be read. Given that NFC is completely pinless, we can just fetch such data without any authentication or encryption holding us back! That’s leak #2. Again, keep in mind that there are those range boosters for active NFC chips! If I put a powered NFC patch kit on my Android phone, in a worst-case scenario I could just walk by you and potentially fetch your transaction logs and bank account number!

Now that did raise a few eyebrows, which is why some banks have reacted to the issue, like my own bank too. But first, to another problem:

4.) The theft issue

Besides leaking information, there is another problem: As said, NFC access is pinless. It’s used for 25€ micropayments mostly, limiting the damage somewhat. Typically, you’ll get 3-5 payments before you have to plug the card back into an ATM or electronic cashier and re-authenticate it using the pin, after which you’ll get another 3-5 contactless payments activated. So with 5 usable payments, you can lose 125€, should your card be stolen. But it doesn’t end there.

In my own country, Austria, we also have an offline cash replacement technology called [Quick]Austrian Flag. With that, you can basically charge your banking card and carry the charge around like real cash. It’s being used for machines where online connections are economically unfeasible, like cigarette vending machines or pay and display machines, where you buy tickets for car parking. The maximum charge for Quick amounts to 400€ total.

Thing is, should you ever choose to charge the full amount, this triggers an activation of Quick-over-NFC! This is actually intentional, so that’s what you have to do to get to that feature, contactless offline payments. The real problem is, that with Quick-over-NFC, all limits are gone, which is confirmed [here]Austrian Flag. So a thief could just waste the entire charge of the card at his hearts’ content, upping the potential worst case loss to a full 525€! Holy hell, that does actually hurt already! Even if you call your bank and get the card locked due to theft, that money is still gone due to the offline nature of Quick. Just like real cash. So better hold on to your card, if you’ve already got that feature activated and money charged onto it!

But let’s get back to the data leak issue again:

5.) Modern cards may be more close-lipped

Banks aren’t entirely ignorant to the problem and related critizisms received, so some of them actually did try to improve the situation. When trying to read my brand-new card from Bank Austria for instance, what we get is this:

First of all, this newer card doesn’t give away my bank account number, but really just the serial number. That takes care of leak #1 to at least some degree. Secondly, the card doesn’t seem to have a transaction log anymore. At least it doesn’t hand one out using known commands. It can of course still be used for NFC payments using [PayWave] or, as it is in my case, [PayPass] and Quick, if activated. But yes, this is more secure, at least when considering the info leak.

But what if I just want to lock it down for good, once and for all?

We can never be sure that there really is no transaction log after all. Maybe we just don’t know the necessary commands. Plus, there still is the micropayment issue.

Now, some banks give you the option to deactivate the feature at your local branch bank, sometimes for free. Volksbank here does this for instance. Not sure how this works and whether it’s really final though. Others may give you the option to send you a NFC-free card, as my bank does. That is if you do know about it and proactively order one for 14€… By default they’d just send you a fully NFC-capable one before the old one expires.

Some banks do neither of the two. Which is why you may want to handle things yourself.

6. Killing NFC for good

Remember that poor mans’ X-Ray from above? All we need to do is to cut the copper coil to fully disable all NFC functionality. I used a microdrill for this, which may be slightly dangerous for the chip due to fast static charge buildup, but it worked fine in my case. You can also use a manual drill or even melt your way through with a soldering iron. Just make sure to not pick a spot that sits within the cards magnetic strip! In any case, we mark the spot first:

A red X above the NFC "wave" logo marks the spot

A red X above the NFC “wave” logo marks the spot. Notice that this card shows both the PayPass and that NFC wave logo.

A few seconds later, my cards’ NFC feature has effectively been dealt with. Tests with both Android phones and actual electronic cashiers have shown that yes, it’s truly gone. All the other full-contact functions like cash withdrawal and payments have also been tested and still work absolutely fine!

Universal Solution™: If it bugs you, just drill a hole in it!

Universal Solution™: If it bugs you, just drill holes in it ’till it’s dead!

So that’s it, no more contactless payments, no more reading information out of the card wirelessly, no more Quick-over-NFC (which only concerns Austrian people anyway, but yeah). Just make sure that the edge of the hole is properly deflashed, so your card won’t get stuck in any ATMs or whatever.

So, all of the good things are still there, and all of what I consider to be the bad things are now gone! Finally, I can put my tin foil hat off again.

Ah yes, tin foil! Before I forget it, another colleague of mine also tried to shield his card using tin foil instead. And indeed, that seems to be sufficient too, in case you don’t wanna physically modify your card. You can even buy readily-made shielded card sleeves to protect you from unauthorized NFC accesses, like [this one here].

I do prefer the final solution instead, but it’s up to you, the option to do it temporarily instead is there also.

So, stay safe! :)

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,

KVM host:port

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


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!



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

public static void main(String[] paramArrayOfString)
  /* Added by the GAT from                        */
  /* This enables insecure TLS renegotiation as per CVE-2009-3555  */
  /* in interoperable mode.                                        */
  java.lang.System.setProperty("", "false");
  java.lang.System.setProperty("", "true");
  /* ------------------------------------------------------------- */
  KViewer localKViewer = new KViewer();
  localKViewer.mainArgs = paramArrayOfString;

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                             */
  /* 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                        */
  /* This enables insecure TLS renegotiation as per CVE-2009-3555  */
  /* in interoperable mode.                                        */
  java.lang.System.setProperty("", "false");
  java.lang.System.setProperty("", "true");
  /* ------------------------------------------------------------- */
  KViewer localKViewer = new KViewer();
  localKViewer.mainArgs = paramArrayOfString;

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.

May 292014

Truecrypt LogoJust recently, I was happily hacking away at the Truecrypt 7.1a source code to enhance its abilities under Linux, and everybody was eagerly awaiting the next version of the open source disk encryption software since the developers told me they were working on “UEFI+GPT booting”, and now BOOM. Truecrypt website gone, forum gone, all former versions’ downloads gone. Replaced by a redirection to Truecrypts SourceForge site, showing a very primitive page telling users to migrate to Bitlocker on Windows and Filevault on MacOSX. And told to just “install some crypto stuff on Linux and follow the documentation”.

Seriously, what the fuck?

Just look at this shit (a snippet from the OSX part):

The Truecrypt website now

The Truecrypt website now

Farther up they’re saying the same thing, warning the user that it is not secure with the following addition: “as it may contain unfixed security issues”

There is also a new Truecrypt version 7.2 stripped of most of the functionality. It can only be used to decrypt and mount anymore, so this is their “migration version”. Funny thing is, the GPG signatures and keys seem to check out. It’s truly the Truecrypt developers’ keys that were used for signing the binaries.

Trying to get you a screenshot of the old web site for comparison from the WayBackMachine, you get this:

Can't fetch from the WayBackMachine

Can’t fetch from the WayBackMachine. Access denied.

Now, before I give you the related links, let me sum up the current theories as to what might have occurred here:

  • has been attacked and compromised, along with the SourceForge Account (denied by SourceForge administrators atm) and the signing keys.
  • A 3-letter agency has put pressure on the Truecrypt foundation, forcing them to implement a back door. The devs burn the project instead.
  • The Truecrypt developers had enough of the pretty lacking donation support from the community and just let it die.
  • The crowdfunded Truecrypt Audit project found something very nasty (seems not to be the case according to auditors).
  • Truecrypt was an NSA project all along, and maintenance has become tedious. So they tell people to migrate to NSA-compromised solutions that are less work, as they don’t have to write the code themselves (Bitlocker, Filevault). Or, maybe an unannounced NSA backdoor was discovered after all. Of course, any compromise of commercial products stands unproven.

Here are some links from around the world, including statements by cryptographers who are members of the Truecrypt audit project:

If this is legit, it’s really, really, really bad. One of the worst things that could’ve happened. Ever. I pray that this is just a hack/deface and nothing more, but it sure as hell ain’t looking good!

There is no real cross-platform alternative, Bitlocker is not available to all Windows users, and we may be left with nothing but a big question mark over our heads. I hope that more official statements will come, but given the clandestine nature of the TC developers, this might never happen…

Update: This starts to look more and more legit. So if this is truly the end, I will dearly miss the Truecrypt forum. Such a great community with good, capable people. I learned a lot there. So Dan, nkro, xtxfw, catBot/booBot, BeardedBlunder and all you many others whose nicks my failing brain can not remember: I will likely never find you guys again on the web, but thanks for all your contributions!

Update 2: Recently, a man called Steve Barnhart, who had contact with Truecrypt auditor Matthew Green said, that a Truecrypt developer named “David” had told him via email, that whichever developers were still left had lost interest in the project. The conversation can be read [here]!

I once got a reply from a Truecrypt developer in early 2013, when asking about the state of UEFI+GPT bootloader code too…

I just dug up that email from my archive, and the address contained the full name of the sender. And yes, it was a “David”. This could very well be the nail in the coffin. Sounds as if it was truly not the NSA this time around.