Win98 vulnerability?

[herbalist]

I think I made several very simple proofs of concepts of it. I'll dig them up and upoload them if someone's interested.

I'd be interested to check them out when you have the time.

IMO, trying to identify and defend all the potential autostart locations individually is futile. Instead if identifying all the registry keys that can be used, I overwrite the entire registry at boot, along with the startup files; autoexec.bat, config.sys, win.ini, the startup folders, and others. To the best of my knowledge, I've covered them save for the boot records. That won't be added to this batch file. I don't think it's necessary to go that far on each restart. Another startup location I didn't see mentioned is the system scheduler. On mine, the built in scheduler is disabled and blocked by SSM rules. Attempts to start it are logged.

Those 9X rootkits led me to make an additional change in my setup. I've long used SSM as the prime enforcement of the default-deny policy. On 9X systems, SSM is loaded via HKLM....Run. If a rootkit of that type used an autostart location that SSM didn't cover, the code would execute before SSM loaded and escape detection. I moved SSM's autostart to the RunServices key. With the earlier loading, it catches the rootkits activity before it can hide. The only problems I've encountered by doing this is that it's no longer possible to have separate rules for each user. It can also interfere with the startup process if you don't have the rules finished for the involved processes. Most likely, the startup batch file would defeat most all such malware by removing their autostart entries, but given a choice I'll have 2 or more layers of defense for all possibilities when I can do it. AFAIC, if malicious code has managed to execute, the damage is already done. If malicious/unknown code can't execute, there's nothing to write those startup entries.

I got burnt once by some type of (official?) malware that escaped being detected by 3 AVs, granted itself internet access through the firewall, initiated the dialup connection, and deleted itself afterwards. The firewall logged the event completely but did nothing to prevent it. I had the help of an expert and we went through my system with every tool available, and found nothing. This, combined with the events and circumstances of that time tells me who did it, but I can't actually prove it. Fortunately, the data I believe they were after was encrypted by Scramdisk. The amount of outbound traffic last logged by the firewall matched the size of the encrypted archive, 28+MB. IMO, it's well beyond coincidence. I wish I had known about SSM at that time. I would have had my proof.

Needless to say, after that incident, I wiped my drives with DBan, switched to the default-deny policy enforced by single purpose software from overseas sources, and treat all software as vulnerable or worse.

Rick

[Multibooter]

BTW, under Win98SE, when you run Autoruns v9.13 [digitally signed 25-Feb-2008] then click on -> Help -> Help, then on the first item "Autoruns" in the list of contents, autoruns.exe tries to call home to origin-codecs.microsoft.com [65.55.13.243], port 80-TCP.

2 days ago Autoruns v9.13 only tried to call come to the above IP, and I had repeated it quite a few times. Today, autoruns.chm tries to call home only to 64.4.52.169, port 80 - TCP.

What is the last version of Autoruns/autoruns.chm [file modification date 14-Dec-2007] which doesn't call home?

File hippo only goes back to Autoruns v8.53 of 10-Jul-2006. When checking the mule, the oldest version seen, with autoruns.chm in it, is v5.01 of 10-Sep-2004. This old v5.01 calls home to the same IP as v9.13. With both versions, whenever one selects Autoruns -> Help -> Help, autoruns.exe tries to call twice. Whenever one double-clicks on autoruns.chm, hh.exe tries to call home twice.

The next lower version checked, v4.32 of 26-Jun-2004, did not have a menu selection ->Help -> Help and did not come with a .chm file, and did not call home either. So sometime between June and September 2004 the calling-home-feature was added, possibly starting with Autoruns v5.00. Maybe other software also had such a feature added after summer 2004. Autoruns v4.32 already detects webcheck.dll (but Autoruns v1.2 of 29-Sep-2000 does not).

Since it's only a .chm file, it should be possible to identify what kind of information is being transmitted, probably nothing really important.

Edited May 6, 2009 by Multibooter

[Queue]

I went ahead and cracked open the CHM file. It was made using Adobe RoboHelp. The first page (Autoruns_Help.htm) loads a JavaScript file (ehlpdhtm.js) that appears to provide compatibility for all major browsers that existed at the time of its creation (it's a big script at 123 KB) for some sort of popup display support (possibly unused in the Autoruns help file, but included since it was made with a help authoring tool). However, I haven't actually located what within the help file (presumably somewhere in the JavaScript file) is making a remote internet connection.

Queue

[Drugwash]

Maybe it's HH.EXE itself performing the call. Have you tried any other chm file to see if it has similar behavior?

[Queue]

I have tons of CHM files on my computer, most do not try and connect to the internet. Every Sysinternals CHM file I tried, did.

I'm not a paranoid person and I don't believe there's anything malicious about what the Sysinternals help files are doing; if you don't trust them, delete the CHM files.

Queue

[Multibooter]

I haven't actually located what within the help file (presumably somewhere in the JavaScript file) is making a remote internet connection.

Have you checked whether the IPs came from the html/js files, or whether they came from a Win opsys file/registry?