Jump to content

[9x/Me] Surviving Without a Virus Scanner


Queue

Recommended Posts

Tiny Personal Firewall download links v2.0.14 and v2.0.15 and v2.0.15a (the last v2)...

...and the v2 Users Guide, in .pdf and a partial version history! ;)

... and two alternative links for Kerio Personal Firewall v2.1.5: link1 or link2

BTW, do any of you have any experience with Spybot - Search and Destroy's "Tea Timer"? I have been using SSD for a long time now but never did install Tea Timer... It's a system integrity checker of some kind, isn't it?

[...]It's the free version of System Safety Monitor. It's no longer supported or being developed, but then neither is 98. It is the most effective option I've ever seen for controlling applications and their activities on a 9X system. [...] It takes some time and planning to go through the details, but with a well thought out strategy, a 9X system can be made very close to bulletproof, and at no cost.

I think it's warranted to repost here a working link for direct download of the System Safety Monitor v2.0.8.583-free.

Edited by dencorso
Link to comment
Share on other sites


BTW, do any of you have any experience with Spybot - Search and Destroy's "Tea Timer"? ... It's a system integrity checker of some kind, isn't it?

Tea Timer can sort of be described as the spyware equivalent of a resident AV. It's primarily a signature based blacklisting tool. I used to run SpyBot many years ago, but strictly as a manual scanner. I had other resident "anti-" software at the time, too much in fact, and didn't want to risk its conflicting with the rest of the detection software.

My feeling is that it's very difficult to defend against a trojan customized especially to your machine. Maybe one could fake that one is running WinXP or Vista and then hope that this customized trojan won't work under Win98.

There are many, many trojans that will run on 9X systems. They're no more difficult to write than their NT counterparts. There's toolkits available that can make custom trojans for most any OS that AVs won't detect. One of them is actually sold as commercial software, with updating and support. Check out MPack.

The deception techniques and software you're asking about would only be useful against sites that try to identify your OS, browser, state of patching, etc, and only against certain methods. Browser headers, javascript, Java, Flash, ActiveX, probably Silverlight, etc can all be used for those purposes to varying degrees. I'm not aware of any software that's specifically designed to deceive malicious sites. That said, there is software that does this to varying degrees. The K-Meleon browser can spoof the user agent and is very configurable in what it will allow (flash, java, JS, etc). The more I use this browser, the more I like it. There's extensions for FireFox and SeaMonkey that can do the same thing. The best tool I know of would be Proxomitron. Using pattern matching, it can rewrite web pages on the fly, including javascript. It's only limitations are the users knowledge of html and scripting languages, which are required for writing good, specific filters. That said, the default filters are pretty good. Sidki still maintains a set. If you can find them, the old JDList filters were very good. Anyone wanting to learn how to write good filters should examine that set. I still have a copy if anyone wants it.

By far, the best way to defend against a custom trojan, or any malicious code that an AV doesn't detect is the default-deny security policy. Custom made or "off the shelf", a trojan is a process. A rootkit installer is a process. Infecting a system requires code to be executed, aka a running process. It can be a free-standing process like keylogger.exe, install.exe, and similar. It can be a DLL that's executed by RUNDLL32.EXE or another system process, It can be malicious code that's injected into a legitimate process, an option which still requires a process to initiate it. Any method that can enforce a process whitelist will defeat the first group, as long as the user doesn't choose to allow it. The whitelist is also partially effective against the 3rd method, injection, provided a separate process is used to initiate it. HIPS software can defeat malicious injection/hooking as well as the malicious use of system processes like RUNDLL32. I got a bit extreme on my system regarding RUNDLL32.EXE after it was used to defeat my defenses, which were more conventional at the time. When operating in what I've defined as "User Mode," RUNDLL32.EXE is not allowed to run at all. It's not needed for normal usage.

Rick

Link to comment
Share on other sites

Well, let's see whether I can sum up where we've got so far...

We can:

1) Set up a strong default deny system (by using, say, Tiny or Kerio, SSM, Proximonitron and perhaps a router firewall). Add to it web resources like Virus Total and HouseCall and a sensible backup/imaging strategy and we're independent from the resident AV scanner industry's whims;

2) Jump from resident AV scanner to resident AV scanner until the very last of them drops 9x/ME, and then we think about what to do...;

3) Burrow our heads in the sand and hope for the best?

Edited by dencorso
Link to comment
Share on other sites

Internet Explorer has long held the title of the most attacked and exploited software for a few reasons.

1, It has long been the most common browser on the web.

2, Thanks primarily to its integration into the 9X operating system, successfully exploiting the browser usually gave the attacker the ability to execute their code on the OS.

Unlike Internet Explorer, the alternate browsers (FireFox, SeaMonkey, Opera, K-Meleon) are not an integral part of the operating system. In addition to having fewer exploitable vulnerabilities, when they are found, they don't result in remote code execution nearly as often. When applications are integrated into the operating system, their vulnerabilities become the operating system's problems. In their quest for complete ease of use and user convenience, Microsoft integrated everything together. Yes, it made everything very convenient. It also made everything vulnerable to any weakness found in any component. Convenience for the user usually results in convenience for malicious code. Integrating web applications into the operating system effective makes the operating system targetable from the web.

This problem is not limited to Microsoft applications being integrated into Windows. This integration also exists between the browser and other user software. Example, PDF files on websites are usually opened in a browser window. Likewise, a PDF file can contain a link to a website. When used with their "as installed" settings, the PDF software will be allowed to launch the browser and direct it to the specified site. Very convenient for both the user and the malicious code writer. On a PC using the most common software brands, malicious code in a PDF file can use that integration to gain control of the browser, and if that browser is part of the OS, the code in the PDF can run code on the operating system too. The convenience brought by the integration of user applications with each other or with the operating system lowers your systems overall resistance to attack. Vendors are constantly patching vulnerabilities in user software that allows these kinds of attacks, and malware writers keep finding more. It's an unending cycle of penetrate, patch, update, but not for the 9X user. During the constant patching process, 9X support gets dropped, forcing 9X users to either accept software with exploitable vulnerabilities or try to find replacements. The problem is that most of the replacements are doing the same thing. Quite often the 9X user has one choice, use an application with known vulnerabilities to open unknown and potentially malicious content.

As bad as that sounds, it's actually normal usage for everyone. There's unknown and unpatched bugs in all software. No application that opens unknown content is truly attack proof. It's a simple fact that the users security policy needs to acknowledge and address. Since we can't prevent user software from being vulnerable to malicious code, the question becomes:

"How do we prevent a compromised application from being used to compromise the operating system?"

For this problem, any software that has internet access, that is directly started by software with internet access, opens web content, or opens files from outside or unknown/untrusted sources is considered the attackable surface. This includes the browser, media player, PDF reader, IM software, P2P applications, office software and others. A large part of the solution lies in the dis-integrating or separating the exposed and vulnerable applications from each other and from the operating system itself. The attackable surface needs to be as isolated as possible from the operating system components and from applications that are not part of the attackable surface in order to prevent the malicious code from gaining access to the more critical parts of the system. Part of this is accomplished via configuration of the individual applications and of the OS. The rest of this isolation is achieved with the policy editor and security software. On NT systems, users have a wide selection of security software available, some of which is quite ingenious and very effective. One option I'm very impressed with is SandBoxie. Except for complete virtual systems, it's one of the best tools available for isolating the attackable surface. Host Intrusion Protection Systems (HIPS) are some of the most powerful tools made for enforcing a default-deny security policy and preventing malicious code from running in the first place.

The problem facing 9X users is that the majority of these options don't run on a 9X system, with one powerful exception. The free version of System Safety Monitor (SSM) is the one Host Intrusion Protection System I know of that is completely compatible with 9X systems. It does require the installation of the Visual C++ 6.0 run-time components, which should have been installed on all updated 9X systems. Like Windows 98/ME and many of the applications 9X users have to run, SSM is no longer being supported and developed. It's sad when financial viability decides the fate of software and operating systems more than quality and performance. I'll also apologize now if some of this sounds like an advertisement or product promotion, but I know of no other 9X compatible software that gives the user this level of power and control over their system. I wish I did, and if anyone is aware of a similar 9X compatible program, I'd very much like to know about it and test its abilities.

SSM can be viewed as a rule based firewall that controls applications/processes and their activities instead of internet traffic. Like the policy editor, it can build and enforce an application whitelist with some very important improvements:

  1. It verifies the MD5 of executables before allowing them to execute.
  2. The path to the executables is part of the rules. If an executable is moved or copied to another location, SSM will treat it as an unknown.
  3. SSM treats user applications, system executables, installers, and malware the same. System processes are not automatically whitelisted, save for kernel32.dll, internat.exe, and SSM's own processes. I'm not certain why internat.exe is whitelisted unless it's used by SSM for multiple language support.
  4. When operating in its "paranoid" setting, SSM lets the user specify what other applications/processes each process is allowed to launch (parent) or be launched by (child). It's the equivalent of making a separate process whitelist for each executable.
  5. SSM makes it easy to define separate user and administrative modes with vastly different permissions, and makes it easy for the administrator to switch between the modes.
  6. SSM modules monitor and protect the important registry keys, the important .ini files, the users startup folders, and key Internet Explorer settings. All of these can be tailored to the users specific needs.
  7. SSM also has a switchable "window filter" module that compares window titles or captions to a user defined blacklist. If the title bar containing the match is a user application, SSM will terminate it. If the match is a system folder or dialog such as the control panel or folder options dialog, SSM will close it. This "window filter" module is effective for controlling users access to key areas of the system such as the system folder, control panel, or folders containing another users name. It can prevent a user from accessing specific documents such as anything with "diary" or "budget" in the name. It also works with the browser, making it a useful parental tool when it's configured to filter words like "sex". The only limit is your imagination.
  8. SSM can maintain separate rulesets and window filter sets for each user on multi-profile PCs. The correct ruleset is loaded when the user logs in.
  9. At 3.2MB, SSM is much smaller than any AV. It's also extremely light. At this moment, it's using 3.3MB of memory on my PC. It's processor usage is also light, under 1% most of the time with short, higher spikes when applications are launched or engaged in other monitored activity.
  10. Unlike the policy editor, SSM can be temporarily disabled, shut down, or prevented from automatically starting with Windows if the administrator chooses.

Again, I apologize if this looks like an advertisement, but by empowering the user to this extent, SSM makes it possible to safely use 9X systems, even with no AV support and limited software choices. That said, a couple things need to be made absolutely clear. SSM does not differentiate between processes. It makes no decisions or recommendations. It will allow or block exactly what you tell it to, even if it's harmful to your system. It is solely up to you, the system administrator, to decide what should and should not be allowed. SSM is only as good as the ruleset it enforces. Writing secure rules requires that the user/administrator understands what the different processes are for, which ones are necessary for normal usermode operation, which ones should available only to the administrator, and which ones each process should be allowed to start. Your knowledge and the security policy you build is what will ultimately protect your system, not SSM and your other security software. They are merely tools that enforce your policy. It's also extremely important that the configuration of your operating system and user software matches the rules enforced by SSM, your firewall, and other security software you're running. I realize that this statement sounds incredibly obvious, but most users including the more security conscious don't start with a plan or security policy. They install what they consider to be the best security apps, then start trying to plug all the known holes and vulnerabilities. Even when they want to set up a default-deny policy, they concentrate on items to be blocked instead of specifying what is to be allowed. The result is a piecemeal approach that usually has gaps, overlooked applications and situations, and conflicts between the rules in the security apps and the configuration of the user software. A well thought out security policy covers a lot of details and situations that are part of normal operations. Without a policy or plan as a guide, it's almost guaranteed that details and applications will be overlooked.

Rick

Link to comment
Share on other sites

You are contradicting yourself here. You can't blame somebody if its not safe anywhere. And change the word P2P with "internet" and its also a valid statement.

No, I'm not contradicting myself. Browsing the web doesn't mean downloading tons of executables from unknown sources. The web of HTML documents, images, CSS, and JavaScript. When you download an executable from the web, you do so from a trusted source. With P2P, all the sources are untrusted and unknown.

So when you download an executable from the web, you do so from a trusted source? That's quite an assumption. You said in another thread that most people don't know what an operating system is and I agree with you. But they do know what can be trusted?? No way. If that was the case we wouldn't see spyware or rogue virusscanners so much. People click on "yes" somewhere and they download and execute something and they don't even know.

As for P2P, I'll admit that never using it is most save. And yes sources are all unknown but not always untrusted. There are different protocols and also matters a lot what you download. The last time I used bittorent was to download Ubuntu 9.04. I never worried :) , but people who like the latest (cracked) games, leaked beta OSs or movies promising Obama and Oprah doing very interesting athletics together are more at risk off course. Between this black and white there's a large grey area which is not necessarily bad if you use some sense. Like you always should.

Link to comment
Share on other sites

As long as you have some good hardware, (that is, meet recommended specs) upgrading to a supported OS would be a wise choice.
Myself, I doubleboot Win 98SE with Win XP SP3, so I can always scan both OSes from XP... but I don't think it's a solution I can seriously advocate as a general one. On the other hand, it's great because I can use one OS to fix the other and vice-versa. Edited by dencorso
Link to comment
Share on other sites

2, Thanks primarily to its integration into the 9X operating system, successfully exploiting the browser usually gave the attacker the ability to execute their code on the OS.

This wasn't a critical factor; because any executable code run on Win9x essentially counts as privileged, any successful remote execution exploit allowed a compromise of the OS. IE remote execution exploits are no more (or less) dangerous than those of any other application on Win9x.

Good post otherwise. =D

Queue

Link to comment
Share on other sites

True, but with alternate browsers, only a few of the vulnerabilities can be used for remote code execution. Many of them were denial of service and "data capture" problems. With IE6, remote code execution vulnerabilities were common.

Regarding the NETBIOS ports, 137-139, these ports are still probed regularly from the web. My Smoothwall logs show at least a dozen of them every day on these ports, coming from all over. Access to the ports can be blocked with a firewall, but if your setup doesn't require them to be open for file sharing on a local network, it's better to close them completely. Closing them by configuration is more secure than blocking them with a firewall. A firewall can fail. There's a fair amount of malware that attacks AVs and firewalls. There's always the possibility of a software conflict. There's code that attacks routers. I seem to remember one that used Flash and UPnP. Blocking an open port with a firewall is patching over a vulnerability. Closing the port is eliminating that vulnerability entirely.

The method for closing those ports can be found at http://www.grc.com/su-bondage.htm. The site recommends installing the NetBEUI protocol before unbinding TCP from the network client to keep the client from disappearing from view. It's not necessary to do this unless you have a need for it. Even though the network client might not be visible, it's still there and is working properly. I've unbound TCP from the network clients on every 9X system I have. A port scan on any of them with the firewall shut off shows no open ports, and they all work fine.

Firewalls should be used to regulate traffic on ports opened by software or a service that you need. Ports are opened by applications and services that need to receive incoming connections. Trojans also open ports. If you have open ports, don't just patch them with a firewall. Find out what is opening them. Decide if this is something you need or if the application/service actually needs it to perform the tasks you want done. If you don't need it, shut it down, disable that service, etc. If it is necessary configure the firewall to restrict the traffic on that port to the specific app/service that needs it, and only to the IP range that app/service needs to function. Do not allow unrestricted inbound access to an open port. If you have an open port but can't find the service or application that's listening on that port, chances are you have a trojan hiding on your system.

Rick

Link to comment
Share on other sites

Since we're now at the Malware sub-forum, I'll dwell somewhat offtopic. The default XP firewall is also designed to block incoming attacks only. Can the Tiny Personal Firewall (the Tiny User's Guide says: 98/2k/ME/NT) or Kerio be used in XP also? And, if so, is it needed or wise to deactivate the XP firewall once the third party is up and working? I ask this because it'd be nice to be able to port the configurations I'll be developping for 98SE to XP as they are, or just with minor adjustments. Please advise.

Edited by dencorso
Link to comment
Share on other sites

I haven't tried Tiny on anything but 98. I run Kerio 2.1.5 on 2K here and have installed it on XP with no problems. Some users have reported problems when "hibernate" is used on XP. I can't confirm or deny this. It is better to deactivate the XP firewall if installing Kerio. It does nothing that Kerio doesn't do as well. I'm not aware of it conflicting with Kerio, but it is unnecessary duplication. Kerio does create its own default rules when first started. The rules for XP include "permit" rules for services which are way too permissive.

I ask this because it'd be nice to be able to port the configurations I'll be developping for 98SE to XP as they are, or just with minor adjustments. Please advise.

If I'm understanding you correctly, you want to build the ruleset on 98 for use on XP? If the rules are limited to items such as DNS, DHCP, ICMP, networking rules, etc, that will work fine. Blitzenzeus did that at Castle Cops. If you try to include system executables and applications, you'll have problems. The rules in Kerio and Tiny include the path to the executable. Kerio checks the MD5 for the executable every time it connects. I believe Tiny does too. Those will be different. I'm pretty sure that Tiny can't import rulesets. I don't know if it would work if you shut Tiny down and replaced it manually. Kerio can import rulesets. I have edited XP rulesets on my 98 box. That's not a problem. The problem starts when something tries to establish a connection because all the rules will be wrong for that OS. You'd have to manually edit all the paths, then have Kerio recheck all the paths and MD5's. IMO, that would be more work than making a new ruleset.

The rule creation interface on Kerio and Tiny is very well designed. If you're familiar enough with internet protocol to write firewall rules, their interface design makes it easy. On these firewalls, you can write individual rules as needed on the fly. Once you get used to them, you can make a ruleset in very little time.

Rick

For those not familiar with configuring Kerio or writing firewall rules, there's a forum thread at Wilders that covered Kerio in detail. The configuration described in the thread is for XP, but the principles apply to all versions of Windows.

How to Optimize Security in Kerio 2.1.5.

Edited by herbalist
Link to comment
Share on other sites

So when you download an executable from the web, you do so from a trusted source? That's quite an assumption. You said in another thread that most people don't know what an operating system is and I agree with you. But they do know what can be trusted?? No way. If that was the case we wouldn't see spyware or rogue virusscanners so much. People click on "yes" somewhere and they download and execute something and they don't even know.

Well, duh. But we are not average users.

Link to comment
Share on other sites

Why do I dislike real-time (active, resident, they have many names) virus scanners? They hurt computer performance. They don't protect you from new threats. They incorrectly detect programs as being ''infected'' when they're actually not.
Well having scripts DISABLED is definetly a good idea if you dont have one.. (Regardless of the OS) Most sites that try and hurt someone rely on scripts to move there stuff on your computer,if you have scripts DISABLED,thier stuff is less likely to function... (99% of all sites will work 100% w/o scripts)

I usually have them disabled if i can... (Stuff loads MUCH FASTER (Quite understandable))

You are right though,AV's mostly bog down your computer and depening on how much ram you have,the effect is moreless noticed more or less........

Edited by Dude112
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...