Conficker/Downadup removal - safe mode gives bluescreen

This is the most useless way to make money that I know of: Fighting viruses. As if there aren't enogh real technical challenges to play with.

A customer was hard hit by the Conficker/Downadup virus the other day. The B variant didn't take too long to figure out how to remove, but a couple of the affected computers would not boot to safe mode, yielding the bluescreen of death (BSOD). No virus removal software I tried was able to detect the junk process causing this, so I had to research a little on my own.

Update 14.3.09: BitDefender now has a removal tool that they claim will also remove the .C variant. I haven't tested it though.

The Downadup.B and .C variants are well described at Symantec's and others' websites, so I won't repeat that. I'll just give a practical short work list that worked for me and left my customer's computers virus free:

Determining if you are infected by Downadup.B:
There's a couple of simple steps to give you a good indication of whether you are affected by the Downadup.B. One or more of these bullets indicate that you are infected:

• You are not able to browse to sites like www.symantec.com or www.microsoft.com. Other non-antivirus websites, like your local newspaper webpage works fine.
• You have several entries in Scheduled Tasks - like "at", possibly with a number behind
• The obvious one: Check your antivirus software logs to see if the virus has been identified

Quick cleaning of Downadup and securing from reinfection
Here's how I cleaned each computer and managed to keep it from being reinfected by other infected computers on the network (although they should all have been physically disconnected from the network):

• Physically disconnect each computer on your LAN
• Boot to safe mode without network support (if you get a bluescreen - see below)
• Change passwords of all local users that have "guessable" passwords - see list on Symantecs virus description page. Gotcha: The virus also guesses existing usernames on the system, even backwards or repeated two times, as possible passwords.
  
• Make sure Windows Firewall (or equivalent) is on
• Make sure you do not allow autorun from USB sticks etc. (see below)
  
• Run the removal tool from Symantec (or other tool of your choice)

If you want to remove manually, I found this description from Microsoft to be one of the most helpful if you want to manually remove or check that all traces are gone.

With all the above steps done, you are ready to connect to the LAN again and try to reboot into normal mode.

Booting to safe mode results in bluescreen
This means that things get a little tougher. Symantec did not have a removal tool for the Downadup.C virus when I needed it (Update: BitDefender has - see note above). In addition, the Downadup.B removal tool was killed the same instance you try to start it. Same goes for many antivirus packages etc..

To solve this, you need to find a clean donor computer with the same OS and probably as identical hardware as possible. Export the following regkey to a memory stick (that you have verified is clean before plugging it into your clean donor computer) or similar and run it on the infected computer:

HKLM\System\CurrentControlSet\Control\SafeBoot

Then quickly reboot into safe mode (F8 upon reboot), in the hope that the virus will not redelete the key before you manage to take down your system for reboot.

Removing the Downadup.C
You have now managed to boot into safe mode (F8 during boot). The virus is still there, you will need to look for it manually, unless there's a removal tool by the time you read this. On my two infected computers where I got bluescreen upon safe mode boot, I opened Windows Explorer in c:\windows\system32, sorted the files on date and looked for the most recent DLLs or EXE files I could find. There was only one DLL file created within the last week, and in both cases it was named a random set of characters. Going to properties, I verified that there was no Microsoft version information - hence, this file would most probably not be to my benefit. Just to make sure, I renamed the file extension to VIRUSSUSPECT and rebooted. The virus was gone, and I had the proof I needed to delete the file I first renamed.

Beware that the Downadup.C also weakens security that you do NOT get restored only by removing the virus DLL. Again, review the Symantec (or other) descriptions of the virus and take action accordingly.

Good luck, and good hunting!

ICS (Internet Connection Sharing) disturbed by VPN client software

Setup: [Computer]---[ICS Computer]---[Internet router]---Internet
The ICS Computer runs Vista, Computer runs Windows XP, Windows Server 2000 or any other.
The ICS Computer also has one or more VPN client software packets installed. In my case, the Checkpoint SecuRemote VPN client and AnchorFree HotSpot Shield were installed, but not running at the time where this problem occurred.

Problem: Computer can not browse websites, Skype will not log on, FTP to internet FTP servers will not work. Computer can however ping all destinations, local as well as internet addresses using DNS names or IP addresses.

Obviously, some (ICMP/ping and DNS requests), but not all of the network traffic is correctly passed through the ICS Computer. After having played around with disabling any firewall on Computer and ICS Computer without any improvement, i tried the following:

Solution: I removed the two software pieces known to create virtual network interfaces on the ICS Computer, hence the CheckPoint SecuRemote and AnchorFree HotSpot Shield had to go. Reboot, and voilla, it worked!

Prime suspect: Since the AnchorFree HotSpot Shield was still wanted on the system, I reinstalled it. ICS still works, bringing me to the strong assumption that the CheckPoint SecuRemote was the one that messed things up.

The Nerd's little blowout: I have been working with a variety of VPN software client solutions, like Cisco, CheckPoint, RSA etc.. In my experience, they all have in common that they in various forms deprive you of an unrestricted simultaneous access to other network segments that are normally accessible from your computer. Try connecting a VPN client and at the same time access your local LAN server. You have luck if it works. Try reaching two different remote sites over two different VPN clients at the same time, and you may even see the good old bluescreen of death. Try running ICS to let another computer connect to the internet on a computer where VPN client software is installed - you get ping and DNS and nothing else. Now THAT's why I'd rather have any VPN link over site-to-site VPN on dedicated VPN routers.

Tunnelling a subset of a routed subnet on a Juniper Netscreen

(This post assumes that you have a general knowledge of setting up a Juniper device for VPN tunnelling).

The following chain represents my setup:

(internet) --- [Internet router] --- [Juniper Netscreen] ---(LAN)--- [Router] ---(General 10.0.0.0/24 network segment)---

On the Juniper device*, this means that a route of 10.0.0.0/8 is pointing towards Router. In addition, a default route is pointing towards Internet router, allowing for comptuers on LAN (which has the Juniper device LAN IP set as their default gateway) to reach both the 10.x.x.x computers behind Router and to reach internet destinations.

Now I want to create a VPN tunnel over the internet to some other place, tunnelling to that place's internal network 10.10.10.0/24.

Problem: Because of the route of 10.0.0.0/8 is pointing towards [Router], even packets destined for 10.10.10.x-addresses are routed that way. Normally on a Netscreen device, having set up policies for the VPN traffic is enough to route through the tunnel, but routing entries seem to take presedence over policies.

Solution: Set a Metric higher than 1 (e.g. 10) for the 10.0.0.0/8 route. Then create a route of 10.10.10.0/24 pointing towards the [Internet router] IP address (this would be the same as your default gateway points to, of course a public IP address). The 10.10.10.0/24 route will by default receive a lower metric and therefore have priority over the 10.0.0.0/8 route.

Gotcha: Of course, this means that you will not be able to reach 10.10.10.x computers on the network behind Router. You literally can't have it both ways...

* I have done this on a Juniper Netscreen 5xp, but I would assume this would work on all Juniper devices, for instance the successor Juniper SSG.