Today I was tasked with configuring a digital encoder to connect back to our office securely over the Internet.  The encoder is nothing more than a box running a Windows XP EmbeddedOS.  Originally I wanted to utilize the AnyConnect Start Before Logon Feature Configuration, but I found that the embedded OS didn’t allow me to complete the java installation necessary for AnyConnect.  Rather than try and figure out where to locate a Windows XP Embedded installation CD, I figured it best to try and reproduce the feature utilizing Cisco’s vpnclient software version 4.8 and Windows batch scripting.

The client software installed without any hiccups and the service started properly after the initial reboot.  The key task at this point was to initiate the client software during the Windows start-up process.  To start, I created a batch file called ‘vpntest.cmd’ and placed it in the C:\ directory; here are the contents of ‘vpntest.cmd’:

:start
c:
cd “C:\Program Files\Cisco Systems\VPN Client”
vpnclient connect VPNTEST user cisco pwd CISCO

The main problem with using the batch file method is any end user can simply read the clear-text password in the command window or open up the file (if they know where to look).  I’m really not too concerned with the file location because I can copy it to the C:\Windows\System32 directory or any other protected system directory and normal end users won’t be able to access the contents without administrative privileges.

To get around this maximized window dilemma, I tried forcing the batch file to run minimized.  In order to do this I had to create a 2nd batch file, ‘launch.cmd’, that would call upon the 1st batch file, ‘vpntest.cmd’:

start “VPNTEST” /MIN /SEPARATE C:\vpntest.cmd

I’ve utilized this step before without any problems, but the problem with the embedded version of XP was it didn’t allow me to define any policies to lock the minimized windows in the task bar.  If you happen to be running Windows 2000/2003 server edition or your XP workstation is part of a domain, you will have the ability to lock down the local policy and keep the window minimized.

At this point, I’m basically back to square one where any user that logs onto the workstation can still maximize the running batch file window.  After googling around, I found that I could use a VBScript to try and hide the window.  I created ‘vpntest.vbs’ and placed it in the C:\ directory.  Here are the contents of my .vbs file:

Set WshShell = CreateObject(”WScript.Shell”)
WshShell.Run chr(34) & “C:\vpntest.cmd” & Chr(34), 0
Set WshShell = Nothing

Once the VBScript file was created, I updated my ‘launch.cmd’ to call upon the VBScript, ‘vpntest.vbs’:

START /MIN /WAIT CScript C:\vpntest.vbs //NoLogo

Now time for a reboot to test our 3 files.  Upon starting the encoding machine, I can see that ‘launch.cmd’ batch file runs during the Windows start-up session and appears to be loading a vpnclient session in the background.  The beautiful thing about this script is it even hides the task from the Task Manager.  If you run ‘ipconfig /all’, you should an IP address has been issued for your “Cisco Systems VPN Adapter”.

The obvious security problem is someone with Administrative rights who knows where to locate the file can still view the clear-text password.  Luckily enough for me, the end users I’m working with that are using the encoder workstation are somewhat mindless.  Just as a precaution, I’ll create a WebACL on the ASA to limit the network access of the vpnclient session.

Last Thursday, we celebrated Thanksgiving here in the US.  Aside from feasting on turkey and watching football all day, I celebrated my 1st year anniversary as an IE by studying up on the WEBVPN technology.  Before I begin, let me just say that the past 365 days since obtaining my number has been a great experience.  Having my digits opened so many consulting doors which allowed me exposure to many new environments and technologies.  Just thinking about another success story now makes me anxious and eager to finish up my Security track.  BTW, originally I had my Security lab scheduled for 12/10/2008, but a side contract had kept me quite busy forcing me to reschedule for 2009.  I’m now planning on taking the lab on 02/27/2009 at the San Jose location.  Worst case scenario is if I blow the attempt, I have another shot before the v3.0 changes come in affect.

In the past, I’ve implemented WEBVPN successfully on various devices such as the concentrator, router, and firewall.  Over the long weekend, I manage to lab up a few work-related scenarios.  I say work-related because shortly before the Thanksgiving holiday began, I was asked to allow Active Directory authentication through our WEBVPN portal.  I had configured NTLM authentication on the firewall which worked great, but now I needed to tie in a 2nd domain owned by a different group.  For the sake of this posting, just assume the authentication portion is working.  I promise to write more about it another time.

To properly test the WEBVPN authentication, I needed access to a Windows machine  Since there only a handful Apple and linux users, it made sense to test everything in a Windows environment.  Most all of my machines at home have been converted to linux; there are only 2 laptops left that are running MK3.  During my testing I was able to authenticate properly off the WEBVPN portal, but the sslclient package installation kept failing and wouldn’t produce any errors in the log.  I immediately started googling for dlls that may be missing in MK3 that would allow AnyConnect to install properly.  At first I couldn’t quite find anything that made sense, then I stumbled upon a forum article that talked about applications that used the “Smart Card” service for security.  The problem with MK3 or most nLite installations is people seem to remove the service completely.

To install the “Smart Card” service in MK3 or any nLite version, follow these steps:

1) Copy the following dlls from a working server with Windows 2003 Service Pack 2 to the C:\Windows\System32 subdirectory:

softpub.dll
wintrust.dll
dssenh.dll
rsaenh.dll
gpkcsp.dll
sccbase.dll
slbcsp.dll
mssip32.dll
cryptdlg.dll
initpki.dll

2) Open the registry and export the key to SCardSvr.reg:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SCardSvr

3) In your MK3 or nLite installation, import the SCardSvr.reg key

4) Reboot the machine and start the service

Once the service has been installed and is running, the sslcient installation can complete.  Searching for information for each of the dlls reveals that the last 3 contain the necessary security libraries that applications are referencing.  Aside from fixing AnyConnect package installation, it appears this exact dll list allows iTunes version 8.0.2.20 to run as well.

Recently, I was asked to allow linux client workstations access into our network via WEBVPN running on our ASA.  As of this writing, the only AnyConnect versions available on Cisco’s website for download were version 2.2.0133.  The only dependency that is required for the linux version of AnyConnect is the Java Runtime Environment.  Connecting to the WEBVPN with a Fedora v8 workstation was flawless (as it should be). The AnyConnect client installed without any errors and I was able to authenticate into our network.

Unfortunately, the behaviour was quite different when connecting with a Fedora v9 workstation. The AnyConnect client installed properly, but when it came time to authenticate my credentials, I encountered this error message:

The error is a bit misleading and doesn’t even relate to the actual problem — AnyConnect is unable to use the Network Security Service libraries. Googling around lead me to a few fixes for Ubuntu, but not for Fedora. The steps to correct the problem in Ubuntu are as follows:

ln -s /usr/lib/libnss3.so.1d /usr/lib/libnss3.so
ln -s /usr/lib/libplc4.so.0d /usr/lib/libplc4.so
ln -s /usr/lib/libnspr4.so.0d /usr/lib/libnspr4.so
ln -s /usr/lib/libsmime3.so.1d /usr/lib/libsmime3.so

In Fedora v9, the libraries are actually stored in a different directory.  Here’s the correct path to link your libraries:

ln -s /lib/libnss3.so /usr/lib
ln -s /lib/libnspr4.so /usr/lib
ln -s /lib/libplc4.so /usr/lib
ln -s /lib/libsmime3.so /usr/lib

Cisco has already identified this as a bug, CSCso89871, and plans on having the scripts corrected for the next version of AnyConnect.