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...