Friday, January 30, 2009

More on the browser hijack

I ran Symantec Endpoint on it again this morning and it finally identified what this was. They call it a Bloodhound.PDF.3 which was discovered and added to their definitions on Dec 18. Symantec calls the infection rate low 0-2 sites, but based on the comments I've had here it's higher than that. I submitted the zipped up acr442b.tmp file to them. It was definitely the infection vector because it went through that old Reader 7.1. Lesson: update your Adobe Acrobat Reader.

Also, to all those following my analysis, please be careful when messing around with svchost.exe because there is a real one and a fake one. The real one lives in system32 and the fake one lives in system32\drivers. This is especially important when you are going through the registry. There are references to the real one and references to the fake one, so BE CAREFUL.

Thank you all for your great comments.

Wednesday, January 28, 2009

A run-in with Defender-Review browser hijack malware

WARNING: this is long and technical.

It was about 6:30 last night when my son said "That's wierd, mom's computer just rebooted". I asked him if he did it and he said no, he was in the middle of playing one of his online games. I thought uh-oh, not now -- I'm just way too busy.

(update: I was running AVG free version 8 on this machine at the time and it did not see this.)

When it rebooted, all looked normal except for a supposed Windows Firewall Message that it had blocked an attempt by Win32.Zafi.B to talk out through the firwall. The Keep Blocking and Unblock buttons were grayed out and a third button was there -- it said something about fix it -- so I clicked it and like magic, IE7 opened up viewing Defender-Review [.] com where it tried to tell me that I had viruses and I had to buy their AV software to fix it.

So I immediately unplugged the network cable. Next I went to another computer on another network and did research on the supposed virus and the web site that popped up. The virus was an old email virus from 2004. Little chance of that happening because we use Pegasus on that machine and I don't allow attachments to be opened. And email was scanned on the way in.

So I focused on the web site - I wondered "is their marketing budget so low that they have to resort to hijacking to get people to come to their site?". I quickly learned enough through Google to see that it was a browser hijack. Oh, by the way, this was the first hour wasted.

Next I tried the basics. I opened Firefox and it wouldn't open on the desktop. It appeared in Task Manager, but did not open the first time. I killed it and tried until it eventually appeared with a strange message about blocking and to click on some links -- view source showed that it was an embedded window in the original. And NetScanTools Pro's URL Grabber pulled in the text portion of URLs without a problem -- it is completely safe. OK, definitely browser hijacking.

So I next launched msconfig. As soon as I went to the Startup tab it started blinking rapidly and the computer went through the fastest shutdown I've ever seen. Now I was mad.

I restarted it and went into Safe Mode. I started msconfig and carefully examined the Startup section (I knew they had to use this) and found what I was looking for--an out of place entry with an apparently random exe name (I've seen this method before):
(checked box) xpsdg6420222 -- "C:\Documents and Settings\%username%\Application Data\Google\xpsdg6420222.exe" 2 -- Software\Microsoft\Windows\CurrentVersion\Run

I immediately UNCHECKED it, pressed OK and went to that FAKE Google directory and removed the EXE and a DLL that was with it -- sorry I can't remember the exact name of the DLL -- I think it was mjkdpl.dll. They both had no versioning or authoring resources and Google toolbar is not installed.

Then I searched for that filename with regedit and found one instance of it. I didn't write down where -- sorry!

Next I rebooted and I now had control of the browsers. But wait! that's not all: the next morning I did more research and found that there may be more "droppings" -- kind of like the elk poop in our yard -- on the computer.

So I searched the hard drive for all files created yesterday and sorted by time so I could see the ones created when the problem was first noticed. I found several. I noticed that 3 minutes before a group of strange files (all had no versioning resources) there was one 2MB file called acr442b.tmp. While viewing it in notepad, I saw "pdf" at the beginning. Maybe a coincidence, maybe not. That computer had Acrobat Reader 7.1 on it. So I uninstalled it and installed reader 9. The old version might have been the infection vector, but it also could have been a clicked on popup -- I can't get an 11 year old to remember.

Back to the file list. I found and removed these:

C:\Documents and Settings\%username%\Local Settings\Temp\acr442b.tmp
C:\Documents and Settings\%username%\Application Data\Adobe\usanaz.exe (21kb)
C:\Documents and Settings\%username%\Application Data\AdobeUM\manol.exe (13kb)
C:\Documents and Settings\%username%\Application Data\AppleComputer\xerks.exe (1kb)
C:\Documents and Settings\%username%\Application Data\Corel\rasim.exe (16kb)
C:\Documents and Settings\%username%\Application Data\Cyberlink\gdi32.dll (12kb)
C:\Documents and Settings\%username%\Application Data\Help\kernell32.dll (10kb -- note the extra 'l' in kernel -- a dead giveaway)

Note: I did not find sinashi.exe, msclock.exe, netsk.exe as some sites have reported -- probably a versioning issue. I even searched again for them in Safe Mode.

I also found but could not remove this one because it was 'in use':
C:\Windows\System32\drivers\svchost.exe (48k)

Now I'm PO'd again because svchost.exe DOES run as part of the operating system, but that's not where its supposed to be located. It should be in System32, not down in drivers and it should be 14K. Be sure to leave the svchost.exe that is in C:\Windows\System32 alone. It's part of the operating system. The one down in "drivers" has to go.

OK, back to Safe Mode. Now I opened regedit to search for all instances of "drivers/svchost.exe". I found these places:
(this runs it at startup)
HKCU/Software/Microsoft/Windows/CurrentVersion/Run/svchost.exe c:\windows\system32\drivers\svchost.exe
HKCU/Software/Microsoft/Windows/Shell/Noroam/MUICache/%SystemRoot%\system32\drivers\svchost.exe
(these poke a hole in Windows Firewall for their malicious svchost to send data)
HKLM/System/ControlSet001/Services/SharedAccess/Parameters/FirewallPolicy/DomainProfile/AuthorizedApplications/List %windir%/system32/drivers/svchost.exe:*:Enabled:svchost
HKLM/System/ControlSet002/Services/SharedAccess/Parameters/FirewallPolicy/StandardProfile/AuthorizedApplications/List %windir%/system32/drivers/svchost.exe:*:Enabled:svchost

It was not in CurrentControlSet which was wierd.

Then I deleted C:\Windows\System32\drivers\svchost.exe.

Then I rebooted normally and temporarily installed Symantec Endpoint Protection 11 and scanned the whole machine. Nothing. I also installed Malware Bytes Anti-Malware -- 6 minor cookie things which were apparently unrelated.

I think I got it all. I hope this helps someone else remove this trash that illegally took control of our PC. I am a programmer and an MS user since DOS 3.1, so I'm well aware of some of these tricks and knew where to look. If I were an average non-technical user, I would have been hosed because no scans caught it. As it was I wasted 3 hours on this.

I'm going to try and Knoppix up and running off a boot CD so my son can play his online games without worries. Try your stupid hijacking tricks against that. And try selling your software the way we sell ours: by being innovative (legally) and providing good value for your customers.

Friday, January 23, 2009

Pinging a MAC Address

Twice in the last month I've picked up the phone to answer a presales tech support call and I had to gently answer this question: "Can your software help me find my laptop? someone stole it, but I know it's MAC address. Your software has something called ARP Ping. I want to use it to ping my lost laptop!"

What they really wanted was to do some kind of trace or ping to the laptop's MAC address and get a response back if it happened to be online somewhere on the internet. Since our software has ARP Ping, they thought it could be used to ping their computer's MAC address. I had to go through an explanation where I basically told them that although their MAC address may be (or may not be) unique, the system of routing packets on the internet has no way to sending a packet to the MAC address of their lost laptop. I told them that the MAC address is a hardware address of the ethernet card and it is only used within the local network (on his side of his DSL router). The packets leaving his network through the router are on a higher level protocol and do not retain the MAC address of the devices on his side of the DSL router. That's the simple explanation. I told them next time they buy a laptop to get software that periodically "phones home" like LoJack.

The more detailed explanation has to do with how packets are transmitted on a network. To send a packet between two computers on the same ethernet network you need two types of addresses: Layer 2 (L2) -- the OSI model link layer and Layer 3 (L3) -- the OSI model network layer. L2 addresses are local in scope which means that two devices may have the same L2 address (this does happen) as long as they are not on the same network segment or subnet. An L3 address must also be unique within the scope of the network it is connected to. On an ethernet network a MAC address is a L2 address and an IPv4 address is L3.

In order to deliver a packet between two computers on an ethernet network, L2 addresses need to be mapped to L3 addresses. This mapping can be either dynamic (usual method) or static. The ARP protocol (RFC 826) is used to build and maintain this mapping. It is a simple protocol intended to find the L2 hardware address of a device given a known L3 IP address on an (usually but not limited to ethernet) network. A device does this by sending an ARP Request packet to all the devices on the network segment asking for the L2 address given a known L3 address.

A typical ARP conversation looks like this:
"All devices! (255.255.255.255) -- who has IP address 192.168.1.29? My IP address is 192.168.1.44 and my MAC address is 00:11:22:22:33:ef" (ARP Request)
"Device 192.168.1.29 replies -- I do! I do! and my MAC address is 00:22:44:66:ab:cd" (ARP Reply)

Now the ARP cache on each device has the IP address and MAC address of the other and they can exchange packets. Each device keeps a transient ARP cache locally showing those mappings based on previous packet exchanges.

When you need to send a packet to an IPv4 address outside your network segment, it sends them through the Default Gateway or router. How does your computer know when to send a packet through the gateway? by looking at the destination IP address and subnet mask . When your computer sees that the packet has to leave the network segment, it finds the L2 and L3 address of the gateway/router, then sends the packet there. The router sees that the IP address is not for the local network segment and uses its routing table to forward it on to the next network. The IP packet does not retain the network L2 address of your computer once it goes through the router just as ARP Request packets are not sent through the router. The networks on the other side of the router will most likely have different L2 Link Layer addresses that are not necessarily MAC addresses as you know them.

So back to the original question: can ARP Ping be used to send a packet to some MAC address outside your network?

No. Because ARP Ping is simply sending the normal ARP Request packet while monitoring the timing. If you try to send a strange ARP Request packet with the destination IP address 0.0.0.0 in it but containing a valid local destination MAC address, it won't work because no computer on your segment will respond. The ARP service on all the listening computers is looking for the IP address of the device that received it, not a MAC address. When the ARP packet hits the router, it is ignored if it does not have the IP address of the router in it. And similarly, if you send a packet with IP 0.0.0.0 and a random MAC address, it too will not leave your network.

Tuesday, January 20, 2009

Managed Switch Port Mapping Tool v1.96 Released

Yes, this was done on Inauguration Day -- new government, so a new version -- why not?

The highlights of this release are:
1. SNMP settings are now individually retained and set for each device IP address.
2. XML spreadsheet export significantly enhanced so that when you import it into Microsoft Excel or OpenOffice Calc, you see the same thing as you saw in the results grid.
3. XML import of previously saved results now works correctly.
4. User interface changes to the left control panel.
5. Internal database format changes necessary for version 2.0.

OK, so what about 2.0? can't tell you yet. Why? It will be out before summer.

Oh, and also in this release is the a cool thing to help out the first time user. When you first run the program the Help File opens up to the Getting Started section. This section has been significantly revised so that new users can understand what they need to do to use the program. It is and is not a simple program to use. Once you understand what is required by the program, it works well.

In case you are wondering what on earth I'm talking about...have you ever looked in a wiring closet and seen all the same color gray cables attached to a switch? Have you ever wondered how you are supposed to trace those cables back to computers in the next room? The Managed Switch Port Mapping Tool communicates with an SNMP managed switch to find out what devices are connected to its physical ports and map out those connections. The results are presented in an easy to understand spreadsheet format. Learn more about it here.

Friday, January 16, 2009

Next Switch Port Mapper Version almost ready

1.96 is almost ready. I've almost finished the documentation -- quite a few changes there especially in the new expanded "Getting Started" section.

The biggest thing about this version is the change from global setting of the SNMP parameters to individualized settings saved for each SNMP device. That way one can use SNMP v1 and another can use SNMP v2c or maybe even be on a non-standard port number -- whatever. Another significant change is in the look of the left side control panel. It's more organized now and hopefully easier to understand. The final significant change is in the XML export. It now conforms better to the XML standards Microsoft uses for Excel. After all the results are in a spreadsheet. The column widths are correct and the font is now supplied. It just plain looks better when you import it into Excel. If you don't have Excel, that's not a problem -- it also works with OpenOffice 3's Calc. It imports in just fine if you select the MS Excel 2003 XML import filter.

Look for it early next week. And one more thing, this is probably the last 1.x version. The internal and visible changes made in 1.96 were necessary to support the new cool things coming in 2.0...

Thursday, January 15, 2009

Windows 7 Calculator

Unbelievable. I started looking around in Win7 Beta and found that for the first time since Windows 98 and NT4, (and possibly earlier) someone was assigned to work on improving Calculator. OK, so what...

The standard and scientific modes have both undergone minor facelifts with some of the buttons renamed and grouped better. But the big changes are the addition of two new modes: Programmer and Statistics. Obviously I'm drawn to the Programmer mode because I need to see bits in my work with packets in NetScanTools Pro. There is a cool binary display below the normal display where you can easily visualize what's in the bytes. Changes to this have been long overdue and I will definitely be using the Programmer mode once I jump by development machine from XP to Windows 7.

Wednesday, January 14, 2009

Windows 7 knows it is in a Virtual Machine

Today I did a Windows Update on Win7beta to get Tuesday's patches from Microsoft. There was at least one.

Then I saw a link in the start menu for games. Cool. So I opened it up and saw the usual games plus three that I don't recall seeing the past: Internet Checkers, Internet Backgammon and Internet Spades. I'll be trying those out soon. What was more interesting for me was the area on the right where it said "This computer's Performance Information has not been created."

OK, so let's create it -- I clicked on "Rate this computer", then again on the "Rate this computer button" on the next page and got a somewhat surprising message "Unable to run an assessment inside a virtual machine. WinSAT can not obtain accurate measurements inside of a virtual machine. Please try again running directly on the native hardware." DARN! -- but cool nevertheless. It knew it was running inside Virtual PC 2007. Maybe I should find a spare hard drive to put this on in another machine...

Monday, January 12, 2009

NetScanTools (TM) Pro 10.80 on Windows 7 Beta

Installation of the full version of NetScanTools Pro on the new Windows 7 Beta went smoothly. The main files installed OK and since the Visual C++ 2005 runtimes are not included in the operating system, our installer launches the runtime installer. Then it launches the WinPcap 4.02 installer. WinPcap also installs OK. Whew!

One thing I was very concerned about was the operation of WinPcap on this operating system. So the first thing I tried was the ARP scan of our subnet because it uses WinPcap to create the ARP packets. It worked! another BIG sigh of relief!

So I went ahead started testing all the other functions. Everything worked fine until I got to the Network Statistics tool. Just like when we first tested on Vista -- it FROZE -- obviously Microsoft changed something. I'll find it. I have to install the 2005 compiler and source on the beta, then step through it to find the offending function call. Not too hard -- usually. If you run into this, you have to open up the registry editor and clear the currentView key under HKEY_CURRENT_USER\Software\NWPS\NetScanTools Pro 10\CommonDataEntry. Then you can restart the program without it locking up again. Just don't try to use the Network Statistics tool.

All the other functions worked fine. I saw no other problems whatsoever. So the transition from Vista to Windows 7 should be fairly quick for NetScanTools Pro.

Installing Windows 7 Beta on Virtual PC 2007

Yes, it worked. In a word: painless. I had no problems installing the new Windows 7 Beta (build 7000) on Virtual PC 2007 sp1. I assumed that Win7 was closest in architecture to Vista, so I selected a Vista configuration and bumped the Virtual Machine memory up to the required 1GB. I left the default max virtual hard drive size at 64GB. The host OS is Vista 64 on a quad core 8GB machine. I "captured" the ISO install file located on a network drive on another machine, then rebooted the virtual machine and installation proceeded from there.

Things I noticed about installation: less user interaction required to get it installed. Yes, there was the usual location and time stuff, but there was less other stuff. And it only rebooted once to complete the installation which was great. I did ask for the product key which I was given before I downloaded it and it did the product activation automatically. Whether all this simplicity remains in the RTM version, we'll just have to see.

Windows 7 Observations: some user interface changes -- more glowing things like icons and bars. The start menu button glows when your cursor hits it. The layout of the start menu is a bit cleaner as is the Windows Explorer layout. The start menu does look fairly much unchanged other than small appearance changes. Everything is where it was in Vista. The taskbar is bigger -- approximately twice as high and the programs are shown as icons without their names. This appears to be a departure from earlier OS's. Maybe some of you will notice that the default background screen is a fish -- not just any fish, but a betta -- you know, a play on the word BETA. I think it should be a active background with the fish moving around. What a cool timewaster that would be.

Another biggee is less and I mean way less of those annoying UAC messages "are you sure you are sure you are sure...". I was able to open the registry editor without a big argument from the operating system -- nice!

Another thing that is on every window titlebar is the "Send Feedback" link. I guess they want feedback, but since I've only used it for an hour, I'll hold off.

So far, I like what I see!

Friday, January 9, 2009

Windows 7

The announcement of the public release of the Windows 7 beta was a couple days ago and already news articles are calling Windows Vista "much-maligned" with users experiencing "many problems" with it. The push to get the next release of Windows out really comes as no surprise.

The end user acceptance of Vista seems low after two years. I say this based on visitor logs of our websites and also our own user polls during product registrations. XP is still the dominant operating system seen in our website logs at a rate of 75%-78% of all Windows OS visitors. Vista is running about 15%-20% with the other old Windows operating systems down in the noise. This data comes from two sites looking at the last couple months. This represents a small increase in the Vista numbers from what I reported in October and it does show a couple percentage points drop in the XP numbers. These kinds of numbers are probably behind the push to get Windows 7 out -- reminds me of Windows ME.

While I haven't actually got my hands on the Windows 7 beta yet, I do want to try it out soon. I hope it will load into MS Virtual PC 2007 for testing. Hopefully none of our software breaks this time and our code changes will be minimal -- there were so many code changes required for Vista.

Thursday, January 1, 2009

Happy New Year!

Happy New Year!

Hopefully 2009 will be better than 2008 was. I will be in the office on Jan 2. We return to normal business on Monday, Jan 5.