Thin Clients Part II - Security Added

Late last week I took my little thin client computing concept a step further and added some security. My goal was to add at least one layer of security, if not two layers to this process. Like a smart card concept I wanted to have a physical token (the thumb drive itself) as well as a "secret PIN" which the user would need to supply. This might add a bit of time to the login process, but the security would be well worth it.

The New Process
We will still use an autorun.inf file which will allow the user to plug in the thumb drive and simply press enter for the default choice. The default choice, is to run a batch script which I have called "connect.bat". Here are those files.

autorun.inf
[autorun]
open=connect.bat
ACTION = LAB CONNECT

connect.bat
SET STARTRUN=%0
7za.exe e -oC:\TEMP -y RDPPACK.zip
REM COPY %0\..\*.* C:\TEMP
C:
cd C:\TEMP
start /normal ssh.bat
PING -n 8 127.0.0.1>null
start /normal RDP.bat
start /normal WAIT.bat

When connect.bat runs, it launches 7zip, which extracts a zip file to the c:\Temp directory. I used 7zip for a couple reasons: a) it's freely downloadable at http://www.7-zip.org, b) you can create password protected (encrypted) zip files with it, c) I had it installed and I all ready use it in other batch processes.

My zip file, RDPPACK.zip, is an archive which contains several other batch files. One of these batch files contains passwords so we protect the zip file by password protecting it when we create it.

My RDPPACK archive contains the following files:
labconnect.rdp - This is the file which contains RDP details such as IP and port number.
plink.exe - This is a free command line secure shell client for windows.
RDP.bat - Simple batch file to connect to the host using the settings in labconnect.rdp.
ssh.bat - This is a new batch file which uses plink.exe to open a secure shell session with our VirtualBox server.
WAIT.bat - This waits for the thumb drive to be removed, and then cleans up and kills things when that happens.

Once the zip is un-extracted (takes only a split second) we start up three other batch files simultaneously.

Here is the play by play. The user plugs in the thumb drive which runs connect.bat. This starts the file extraction which pauses momentarily and waits for the user to enter their password. In my examples I used a simple four digit "PIN Number". The files are extracted, and "ssh.bat" is launched.

ssh.bat
SET STARTRUN=%0
plink -ssh -L 13390:localhost:3390 -pw password username@10.0.46.55
EXIT

There are two items of bad news to mention here. One is that there is an EIGHT SECOND wait placed after this script runs. This is the unfortunate amount of time it takes for the secure session to be established. The other bad news is that the username and password are exposed here "in the clear". This could be hidden by putting an @ symbol in the batch script in front of that first line (keeping the command from being echoed to the user). But it will sill remain in the Temp directory while this script is running and a bad guy could find it. I would like to think that the user will not share the PIN number which revealed this information, and if their thumb drive was lost or stolen you could simply change this password on the server. So it's "pretty good" security in my book.

The plink syntax works like this: "-ssh" means to use the secure shell protocol, the "-L 13390:localhost:3390" will redirect connections that the host makes to itself on port 13390 to the server on port 3390, the "-pw password" would be this users password on the server, "username@10.0.46.55" would be the users username and the servers IP address. This means that we have created the user on the server, assigned them a password, enabled the secure shell daemon, and we are firewalled to disallow connections on port 3390. Yes, we do NOT want to allow connections to port 3390 from anybody. The only reason our remote users can do it is because they are sending these connections through the secure tunnel we established here. Clever, huh?

Once the secure session is established (we simply waited 8 seconds and assumed it's ready) we then run RDP.bat and WAIT.bat simultaneously.

RDP.bat
mstsc /f labconnect.rdp
EXIT

WAIT.bat
PING -n 10 127.0.0.1>null
GOTO CHECKEXIST

:CHECKEXIST
IF EXIST %STARTRUN% GOTO WAIT
GOTO KILLTASK

:WAIT
PING -n 3 127.0.0.1>null
GOTO CHECKEXIST

:KILLTASK
taskkill /f /im "mstsc.exe"
taskkill /f /im "plink.exe"
DEL /F C:\Temp\autorun.inf C:\Temp\connect.bat C:\Temp\labconnect.rdp C:\Temp\plink.exe C:\Temp\RDP.bat C:\Temp\ssh.bat C:\Temp\7za.exe
EXIT

RDP.bat will connect us up to the server. There were some changes made in the RDP file. That is, the client now connects to localhost:13390 instead of the server IP and port 3390.

WAIT.bat will start pinging itself in a loop, and wait for the drive to come disconnected. When that occurs, it will immediately end task on the terminal services connection, and then the secure shell tunnel. Afterward (and this is new) it does some cleaning up and deletes all that stuff that it left laying around in C:\Temp. The only thing which will remain is the WAIT.bat file itself. Which as you can see, presents no risk as it contains no passwords, etc.

Problems
I probably spent a couple of hours on this process over the span of a week. What was most frustrating was getting VirtualBox to cooperate with me. There are a few known issues with various VRDP elements. One is "authentication". Theoretically you can authenticate your VRDP sessions against a local user database on your VirtualBox server. This didn't work at all for me and after reading through a couple of forums I found that it doesn't work for anyone else either.

I am also having problems with my Windows clients when they connect to a VirtualBox at full screen. It seems that the windows get doubled up and don't display correctly. If you specify an exact window size in your RDP file such as 800x600, you will not have this problem. I went through the trouble of setting up a Windows VirtualBox server and found that the problem exists there as well. I have since opened up a Bug report with VirtualBox which I hope gets some attention.

Lastly, expect VRDP on VirtualBox to provide you with rather slow window refreshes. I would like to think that this is also something that the VirtualBox developers are improving as they have always been aware of this bug.

Hack on, and I hope that someone out there finds this information useful, at some point. ;-)

Thin Client Computing on the Cheap

Many, many years ago I was attending a trade show and I saw something really cool. There was a booth set up with a couple of screens which had card readers attached to them. You could insert one of their sample cards and a screen popped up running Windows and a couple of applications. When you removed the card, it was gone. You could then walk to one of the other terminals and insert the card - and there was what you were last working on (instantly). It was pretty neat, and the concept was simple. Running on the back end was a heavy duty server which was emulating a dozen or so Windows machines. The front end was a dumbed down Linux terminal which just connected the user to the virtual Windows machines by means of a remote connection protocol (RDP). There was a little more to it, such as strong certificate based security, but we won't tackle that just yet.

My plan today was to create a collection of virtual Windows machines, and a USB "key" which could connect me to one simply by inserting it to a workstation.

The Server: In my case, this was easy since I all ready have a Linux box running VirtualBox. If you want to create this environment, go on out to VirtualBox.org and get yourself a copy. Note that it's *FREE* to those who qualify (read the fine print). Also, there is an Open Source Edition which is free to everybody, but it lacks some key features like USB support (so avoid it for this discussion). Once you have VirtualBox you will want to create at least one workstation. This can be anything really. In my case, it was Windows XP. In the settings for that workstation you will want to go into Settings and then Remote Display. Enable remote display and set your port number (default will be 3389).

The Workstation: I am referring here to the "dumb terminal" that you will be using. This should be on the same network as the server (or there should be routing established between them). Nothing needs to be done special on this workstation. It should be running Windows for our discussion. In my case I am using Windows XP boxes.

Prepare an RDP File: This can be done on any Windows machine. Basically we just want to make a settings file that we can put on our Thumb Drive. To create this, get onto a Windows PC and click Start > All Programs > Accessories > Communication > Remote Desktop Connection. Enter your IP and port number like this SERVER:3395. If you used the default port of 3389, just enter the server name. You can specify all sorts of other info here if you want. Many of these settings have no bearing since you are connecting to VirtualBox, and not "Windows itself". When you are done, choose to save your settings. Save this right onto your thumb drive and call the file "connect.rdp".

The Thumb Drive (or Jump Drive): This is where all my work came in. You will need to create a couple of batch files on the root of the thumb drive. Here is what they are named, and what should go inside of them ....

autorun.inf - This will initiate your remote client upon plugging in the Thumb Drive.
[autorun]
open=connect.bat
ACTION = LAB CONNECT

connect.bat - This is required to launch the RDP session, and the "watcher".
SET STARTRUN=%0
COPY %0\..\*.* C:\TEMP
C:
cd C:\TEMP
start /normal RDP.bat
start /normal WAIT.bat

RDP.bat - This will launch the remote window and ultimately quit.
mstsc /f connect.rdp
EXIT

wait.bat - This will watch for the removal of the thumb drive. If it's removed, the remote session is closed within 3 seconds.
GOTO CHECKEXIST

:CHECKEXIST
IF EXIST %STARTRUN% GOTO WAIT
GOTO KILLTASK

:WAIT
PING -n 3 127.0.0.1>null
GOTO CHECKEXIST

:KILLTASK
taskkill /f /im "mstsc.exe"
EXIT

With all this in place, here is how it will work.

When you insert your thumb drive, Windows XP will find the autorun.inf file and use it to launch an "Autorun list" in Windows XP. All you should have to do here is press enter (for security reasons this choice cannot be made automatically). At that point, you should see a remote connection window pop up. This whole process takes a few seconds.

While you are remotely connected, there will be two Command Prompt windows lingering in the background. One is just running the RDP application. The other is running a watch on the thumb drive. If you watch it, you will see that the PC pings itself three times, sending the result to "nowhere". The reasoning behind this is to give the PC something to do to waste time. Windows XP does not have a sleep or wait method that you might use to waste time cycles. Every time it completes it's three pings, it will check for the existence of the drive letter being used by the thumb drive. Through some clever tricks involving the "%0" variable, we are able to determine this drive letter regardless of what was chosen when it was inserted. If the drive letter is gone, the batch process hunts down the RDP task and kills it, then ends that script by exiting. The other script which had been running the RDP task moves to the next line, which tells it to exit also. The result is, the remote connection window and all it's friend vanish almost the instant the the thumb drive is removed.

You will see that my scripts first copy themselves to C:\Temp before running. The reasoning behind this was that if the drive is removed while a batch script is running from it, the script will fail and leave a "Terminate Batch" prompt on the screen. A colleague noted that in a production environment you would probably want yet another batch file in this process which removes all these items from Temp once it's done running. But it's a work in progress.

Next, I will focus on adding some form of security to this process as there presently isn't any.

Poor Mans Low Level Format

On occasion I am asked to "blank out a device" or remove any data it contains. Usually this is because we are disposing of media or we are selling off equipment at the hospital which once may have contained a patients medical records. This seems to be an easy task, with a complicated solution. The goal is to "write zeroes" to the hard drive repeatedly. This is affectionately referred to as a low-level format.

Sure, there are utilities to perform this task. Some are free, while others and get quite expensive. I also seem to run into problems where certain utilities only work with certain drives (a Western Digital utility only works with Western Digital drives).

Enter the simple and free solution: Linux.

I have several different versions of Linux laying around. Old versions of Ubuntu, new versions of Xubuntu, you name it. So here is what I did.

1) Insert your live distribution of Linux, and boot to it (this may require changing BIOS options, or changing boot options).
2) Wait for the desktop to appear, or fail to appear. I was working with some bizarro medical machines today which failed to boot completely and instead dumped me into "BusyBox". BusyBox is like a small shell which can only execute very minimal commands. But this will do.
3) If you boot all the way to a graphical desktop you can either open a Terminal window, or press Ctrl+Alt+F1 to get a virtual terminal.
4) Enter this command: cat /dev/zero > /dev/sda (or /dev/hda for older IDE drives).
5) Wait for the error message, "No space left on device".

The error message is inevitable. We are simply running a contents list of an imaginary device called "zero" which is filled with an infinite amount of zeroes. Then we are redirecting that stream of zeros right into the hard drive device ignoring all boundaries, partitions, master boot records, etc. Eventually we strike the end of the drive and it tries to keep going, hence the error message.

If you want to follow the old "D.O.D. Standards" you will want to repeat this low level format at least 6 more times (if not 9 more). You can run this command repeatedly by separating your commands with semicolons. For example ...

cat /dev/zero > /dev/sda; cat /dev/zero > /dev/sda;cat /dev/zero > /dev/sda

... would perform three consecutive low level formats. Sure, you could write this into a shell script. But then we are talking about something quick and dirty here which you can do simply by booting whatever distribution of Linux you have laying around.

Disclaimer: A purist might say "That's hogwash Steve! That data is still retrievable by using a chemical separation process on the platters". To which I would say, "then take them home and prove me wrong". Yes, data could still theoretically be retrieved from these disks ... if you have a laboratory environment, or the money to pay someone retrieve it. If you are really paranoid, consider alternating between writing zeroes to the device, and writing random data to the device. This can just as easily be performed with ...

cat /dev/urandom > /dev/sda

They say that by alternating and randomizing the data that you write, recovery becomes all the more impossible.