This case study illustrates several issues I've raised before, as well as a few lessons, such as "there's no 'one problem per case' rule", "best practice isn't bullet-proof" and "one antivirus scanner isn't enough".
I was on site doing something else, when I was called to check out a problem with opening Word documents, which the user attributed to an encounter with a dubious diskette.
The first thing I noticed was that her PC wasn't showing file name extensions, contrary to the way I generally set up PCs...
"Hey, you can't see the file name extensions! Without that, you don't know what type of file you're about to open! That's dangerous!"
'No, that's OK; I can see the Word icon, so I know the files are Word documents'
This was followed by an explanation of why this can't be trusted, while she insisted it was OK, and 'was always like that'. I pointed to two files as an example; a pale (normally hidden) one called "Some file name" and a bold one also called "Some file name". I right-clicked on each, and sure enough, the hidden one was the .DOC while the visible one was an .SCR - so I wasn't too surprised when the setting to
not hide file name extensions would not "stick".
"You're malwared", I said, and after shutting down and setting CMOS to boot CD, I booted up the Bart CDRW I tend to have on me at all times. Bart would boot on this crusty old Win98SE system (333MHz, 64M RAM)... if only the 32-speed CD-ROM would read CDRW disks... so it's heigh-ho, back to base we go.
Who's stupid?As a geek, my first reaction was to consider the user foolish for trusting icons as an indication of file type. Then I thought; why should a user know that the most dangerous file types can set whatever icon they like, and that .scr files are raw code, and thus dangerous? Why doesn't the user interface clearly flag which files are code and which are data, as well as the type, and disallow any content to misrepresent itself? Why are file name extensions hidden by duhfault, anyway, and why are things still as brain-dead in Vista?
That's the problem with bad design - it never gets patched, because it "works as designed". We had years of MS Office macro and VB malware before that was fixed, years of Outlook and Outlook Express auto-running scripts in HTML "message text", and we still have Format in the middle of hard drive context menus while Backup, Check for errors etc. are buried under Properties, Tools. Stupidity is found not only in end users.
Best Practice can still failAs usual, I started work on the system with several hours in
MemTest86, to make sure the system was safe to run at all. Then I booted my Bart CDR, eyeballed SMART details in
HD Tune, did a surface scan of the 4G hard drive, and checked SMART details again; no change in SMART, no surface errors, OK. A ChkDsk confirmed the four file systems were OK, so I created a session base directory on one volume, and set that as Bart's Temp location. I could then shrink the Bart RAM disk as it's no longer needed for Temp, and create a pagefile on hard drive to relieve constraints imposed by 64M of RAM.
Then I started my antivirus scanning wizard and went about my other work. A while later, I see the second av scan is still stuck on the same file, so I run HD Tune again; it shows blank SMART details, and a surface scan picks up "one bad sector".
I immediately pull the mains, pull the hard drive into another PC, copy off everything from DOS mode using the LCopy from
Odi's LFN Tools, starting with the data set and carrying on until most stuff is backed up. I had hard failures on C:\Windows (bad disk) and the session subtree to which the Bart av wizard would have been logging the scans (file system corruption).
Next, I went in with DiskEdit, confirming bad clusters throughout the entire C:\Windows directory chain. Noting the cluster address of the Windows directory, I searched for subdirectories on C: (fortunately it's a small C:, not the whole hard drive) and ballpointed the . cluster addresses for all that had .. pointing back to the lost Windows directory. Then I created scratch directory entries in C:\ to point to these, and copied them off.
I then did a raw image copy of the fortunately-small C: volume in case I needed to recover more stuff later, and finally back in DiskEdit, I "erase-marked" the Windows directory so that scanners traversing the file system wouldn't fall into a pit of bad sectors.
Having got what I could off the stricken hard drive, I put it back in the PC it came from and got back to my Bart antivirus scanners etc.
Rungbu.AFour out of five of the initial "detect only" scans detected the same files as infected, but each called the virus something different. One called it a generic trojan, another called it SillyWorm, each with a high variant suffix. Only Sophos gave it the unique name of Rungbu.A, though their site only had a descriptive page for the
Rungbu.B variant. The sixth scanner was set to kill, and did; thereafter there was nothing for the remaining scanners to detect.
Reading the decription's Advanced page revealed this malware to be anything but "generic". It left the system tattoo'd so that I had to Regedit before I could stop Windows from hiding file name extensions.
We get annoyed when vendors don't patch known exploitable surfaces, and highly irate when there are ITW (in the wild) malware already exploiting those surfaces. Yet we've seen so many malware with double file name extensions such as README.TXT.pif, and these raw code file types can and do set their icons to match the faked file type.
But hey, not a problem; it "works as designed".
Re-entryFinding the plethora of vintage application disks for this PC would not be fun, so I decided to preserve the old installation instead. I called the site and asked them to find the disks if they could, in case I'd have to rebuild, then set out to fix the installation.
First, I partitioned a replacement hard drive (a used 40G, jumpered to act as a 32G in deference to the old PC's BIOS limitations) and copied everything to one of the logical volumes. Then I fresh-installed Windows 98, and copied that subtree to the logical volume as well. Next, I copied everything except the old Windows child subtrees into place, then finally identified and copied the recovered child subtrees over what was installed with Windows.
All of this was done from DOS mode, but I couldn't extract recovered registries etc. from the latest RB*.CAB from there, so I had to go back into Windows at this point. That crashed Explorer, so I set shell=Winfile.exe in System.ini, and from there I could Extract the registry files. Back to DOS mode to drop in these registry files, as well as older backed-up Vmm32.vxd and "Exit to DOS.pif", and now everything looks OK - though I'll try everything out in case there are needed files that are missing from the Windows base directory.
Duhfaults are foreverIt's a good thing the variant of Rungbu that infected this PC didn't also put "hide hidden and system files" into effect, and that we don't use Microsoft's duhfault settings. If we did, there would be no visible indication the system was malware'd; we'd see only one "Some Name" file, which would appear to "open" just fine (the malware code runs invisibly and then spawns and opens the original Word document). Unless someone tried to change the Explorer settings, and became puzzled when the changes didn't "stick", there's be no indication that anything was wrong.
And that means the companion malware files would have found their way into every data backup, too.
It's all very well saying "it's only the default setting; you can change it", but defaults are forever. These unsasfe defaults are all you get in "Safe Mode", will recur after "just" formatting and re-installing Windows, will be the baseline for every newly-created user account, may be re-asserted by domain servers or when account rights are limited, and will be what users see whenever they use arbitrary PCs elsewhere. Defaults should always be truly safe!
