First, I've heard of this...

However, when it comes to NT servers, it shouldn't be that simple... unless of course someone messed up and gave Admin rights to everybody...

Well, I've hard of shared folders viruses....but I haven't looked into the specifics of these 2. Basically if the share was left with EVERYONE access that anyone and anything can access those files and do whatever they llike. So if for instance someone shared "C:'" as "IMOPENIMOPEN!". Then ANYTHING could modify this directory. Now anything can be written to this directory and be modified.

To REALLY secure NT systems you should disable the "SERVER" service on all workstations. This Server allows users to share out files/printers. With it disabled there can be no sharing and users MUST go through the server to share their files. I've been wanting to do it on my network for some time but like most things I want to do it requires alot of Politics...and unfortunately I am low on the totem pole.

Leolo wrote:

Since all our computers were running Windows 2000, I wondered how in the world can a virus infect all active processes?? […]
Show full quote

Since all our computers were running Windows 2000, I wondered how in the world can a virus infect all active processes??

Weren't NT-based systems supposed to protect running processes from meddling with each other?

How can I remove the virus from memory without killing all running processes??

I thought that NT-based systems were secure, but if Sophos are correct in their statements then I'm afraid they are just another bad joke from M$ 🙁

Regards.

It may sound strange, but it *is* possible to attach to a running process and then modify its memory areas, etc. This is exactly what debuggers do in a Windows NT/2000 machine and also in Unix boxes.

Anytime you debug a C/C++ program you are developing with Visual C++ on Windows 2000 you are actually attaching a debugger to a running process. The debugger can browse memory areas to watch variables, stop the program, set breakpoints, whatever. The same is true if you are debuggin with gcc and gdb in a Linux box, so it´s not something invented by Microsoft.

Attaching a debugger to a running process is something that can can usually be done only by admin/root or by the process owner. However, Windows NT and Windows 2000 had a security flaw where anyone could do this. If anyone wants the details, try this security bulletin from MS: http://www.microsoft.com/technet/security/bul … in/MS02-024.asp

Regards,

Originally posted by MajorGrubert However, Windows NT and Windows 2000 had a security flaw where anyone could do this.

Odd. I thought this security issue was only on XP, due to Microsoft not wanting a support nightmare due to all the older programs that presume they will have admin-level access.

Kind of figured NT/2000 would still be secure due to them not being aimed at the "general consumer".

Nicht Sehr Gut wrote:

Odd. I thought this security issue was only on XP, due to Microsoft not wanting a support nightmare due to all the older programs that presume they will have admin-level access.

Kind of figured NT/2000 would still be secure due to them not being aimed at the "general consumer".

Actually, the ability to attach a debugger to a running process is not necessary for any "normal" program to work. Only debuggers should benefit from this. It should not be a compatibility issue.
I do not use Windows XP at home so I never had a chance to investigate if it gives any unusual admin privileges for regular users, but I'll take a look at this and come back to tell the results.

Regards,

Thanks a lot for all this info!

I didn't know that debuggers could attach to processes. That's very interesting, and perhaps it's the method that Elkern.C uses to infect all processes in memory.

However, I was able to remove the virus from memory using a tool distributed freely by Symantec:

http://securityresponse.symantec.com/avcenter … moval.tool.html […]
Show full quote

http://securityresponse.symantec.com/avcenter … moval.tool.html

The W32.Klez Removal Tool:

* Terminates all the processes associated with W32.Klez@mm or W32.Elkern.
* Deletes the services of W32.Klez@mm.
* Removes the registry entries created by W32.Klez@mm.
* Detects all types of W32.Klez@mm and W32.ElKern infections and repairs the repairable files.
* Innoculates the W32.Elkern.4926 repaired files to prevent re-infection

It's true that their tool is able to identify and terminate the virus (it worked for me perfectly). But I wonder how did they do it?

Can you kill threads inside a process without killing the process itself?

Gosh, I've always thought that I could remove any virus from memory just by looking at all the active processes and then killing the one corresponding to the virus. But it seems that my little "trick" is of no help with viruses like Elkern.C.

Although I recognized all the active processes (I see them everyday and they are always the same), I had no idea that they were carrying a hidden virulent thread inside them!!

Up to now I've had a very false sense of security 🙁 Time to change my mind...

Thanks again people,
Regards.

Originally posted by MajorGrubert Only debuggers should benefit from this. It should not be a compatibility issue.
I do not use Windows XP at home so I never had a chance to investigate if it gives any unusual admin privileges for regular users,

Wasn't referring to the Debugger/Attachment portion of the thread, but rather the security levels within the OS.

XP, by default, treats everyone as an Administrator. This is true in the Home version, and apparently in XP-Pro. By giving everyone full access, that keeps programs from bombing out, which is what would happen if they were denied resources due to a lack of security-clearance (pardon my layman's terms phraseology).

Leolo wrote:

Thanks a lot for all this info!

It's true that their tool is able to identify and terminate the virus (it worked for me perfectly). But I wonder how did they do it?

I believe this virus uses the security flaw to attach to some process that is running with a security context from Administrator or LocalSystem. After that it can register itself as a service or a device driver, making it a lot harder to detect and remove it. As you can read on Symantec's site, you need to reboot the computer in Safe Mode to prevent the virus from loading before you try to remove it.

Gosh, I've always thought that I could remove any virus from memory just by looking at all the active processes and then killin […]
Show full quote

Gosh, I've always thought that I could remove any virus from memory just by looking at all the active processes and then killing the one corresponding to the virus. But it seems that my little "trick" is of no help with viruses like Elkern.C.

Although I recognized all the active processes (I see them everyday and they are always the same), I had no idea that they were carrying a hidden virulent thread inside them!!

Up to now I've had a very false sense of security 🙁 Time to change my mind...

This is the tricky part: as soon as the virus gets installed as a device driver it can hijack some "hooks" inside the kernel and be called from several different processes.

Finally, I didn't have enough time for a good research on this during the weekend, but if you're interested I can look for some good links on this subject and post them later.

Regards,

Nicht Sehr Gut wrote:

Wasn't referring to the Debugger/Attachment portion of the thread, but rather the security levels within the OS.

XP, by default, treats everyone as an Administrator.

You are absolutely right. This means there are a lot of potencial security threats on XP that would not impact a regular user on NT or 2000, but it's the price you pay for compatibility and some simplicity (i.e, not having to log on as Administrator to install a new program or to run some games).

Regards,

Originally posted by MajorGrubert ...potencial security threats on XP that would not impact a regular user on NT or 2000, ...

And yet Leolo says that his servers were running 2000. Does this mean that his server admins removed a layer of security by giving everyone admin-level access (that wasn't there by default)?

Nicht Sehr Gut wrote:

And yet Leolo says that his servers were running 2000. Does this mean that his server admins removed a layer of security by giving everyone admin-level access (that wasn't there by default)?

I am not sure if I undertood your question correctly, so I wiil try to answer it in two ways.

If we are speaking in general terms, the answer is yes, you lose several security controls when you give administrative rights to all your users. If you make all the users members of the Administrators group you will no longer prevent them from changing system files, some sections of the registry and similar stuff.

Otherwise, if we are talking specifically about the virus outbreak mentioned by Leolo, the infection could have started by a "trojan" program that exploited some security flaw that allows regular users to run code with elevated privileges. This can happen even inside a well-managed network where the administrators enforce good rules of security. Since a malicious program run by a regular user could infect the entire network, you need to educate your users and remember: do not take candy from strangers. Of course, if all the users in Leolo's network had admin rights, things got a lot easier for the virus.

Regards,

Hello,

Well, to be honest, I feel very embarrased about the virus outbreak, it was clearly my fault 🙁

All the client PCs have their local hard drives shared with "full control" priviledges, but only the Domain Admins can access them. Normal users can't see those shares.

However, I had to install a local printer in one of the client PCs, so I logged in using my admin account in order to install its drivers.
Needless to say, it was precisely that computer which was infected, and the virus quickly spread through the other clients because it had full access to their hard drives 🙁

Nevertheless, I'm still wondering what is the exact method that Elkern.C used to infect processes in memory.

I've read the MS security bulletin mentioned by MajorGrubert, but I'm not sure that the virus uses that vulnerability, since all our computers were running Windows 2000 SP3, and SP3 is supposed to have included a fix for that.

Moreover, the Klez.H virus was present only in the computer where I had to install the printer. Strangely enough, the rest of the computers were infected only by the Elkern.C virus. Maybe Klez.H doesn't spread through network shares??

People, thanks for your comments, I appreciate it a lot.
Regards.

Originally posted by MajorGrubert If we are speaking in general terms, the answer is yes, you lose several security controls when you give administrative rights to all your users.

Yes, I knew that.

... if we are talking specifically about the virus outbreak mentioned by Leolo,

Yes, that's what I was referring to...

...the infection could have started by a "trojan" program that exploited some security flaw that allows regular users to run code with elevated privileges. This can happen even inside a well-managed network where the administrators enforce good rules of security.

Hrmm. I can certainly see that is possible, it's just that the general info I've heard about Linux was that it was much more secure from virus attacks due to the restrictive security it has. Just seemed odd that it would be this damaging if secure access was in place.

Now, having read Leolo's new post, he's apparently confirmed that there was a security "hole".

Hey Leolo, you want us to delete this thread so your Boss doesn't see it? *heh*

Nicht Sehr Gut wrote:

Hrmm. I can certainly see that is possible, it's just that the general info I've heard about Linux was that it was much more secure from virus attacks due to the restrictive security it has. Just seemed odd that it would be this damaging if secure access was in place.

The general belief is that Linux is more secure than Windows NT/2000/XP. Actually, their security is similar in several aspects, and the actual security you get is affected by your settings and your practices.
Linux and Unix sysadmins are usually very conscious about security, but eventually these systems are affected to bugs in some applications (if you know a Unix/Linux admin, ask him about BIND).
Meanwhile, there is a large (should I say huge) number of Windows machines being used by regular users with little security concern, ready to be infected by the next virus. Add this to the number of security flaws found in Internet Explorer and you end up if a large number of infections happening all the time.

Going back to the original question that started this thread, I went looking for some info about Elkern.C and Klez.H and learned that the first one is the actual virus and the second one is the carrier trojan. Elkern.C infects executable files (as a virus usually does) and also tries to load itself inside other running processes. This is done through the AppInit_DLLs registry value (see article Q197571 on MS), a feature in Windows that allows a DLL to be installed and then loaded by (almost) all the programs you run on the console. This allows the virus to actually become part of all runiing processes whithout showing up as a separate one. Very useful for a virus, as you can see.

Regards,

Originally posted by MajorGrubert ...their security is similar in several aspects, and the actual security you get is affected by your settings and your practices.
Meanwhile, there is a large (should I say huge) number of Windows machines being used by regular users with little security concern, ready to be infected by the next virus...

That seems to be a pretty good synopsis of the situation.

quote: -------------------------------------------------------------------------------- Originally posted by MajorGrubert ...the […]
Show full quote

quote:
--------------------------------------------------------------------------------
Originally posted by MajorGrubert ...their security is similar in several aspects, and the actual security you get is affected by your settings and your practices.
Meanwhile, there is a large (should I say huge) number of Windows machines being used by regular users with little security concern, ready to be infected by the next virus...
--------------------------------------------------------------------------------

That seems to be a pretty good synopsis of the situation.

Agreed
Usually people running unix like OSes are more interrested in the workings and protocols of a pc. Therefore they are more concerned with security and such as they know more and like to stay in control.

This is one of the reasons that you neeeeeeed a virus scanner. And not just ANY virus scanner. You need PC-cillin. Well okay, maybe not, but it's really inexpensive and the BEST out of the major players (Trend Micro, Symantec, McAfee).

Odd. I thought this security issue was only on XP, due to Microsoft not wanting a support nightmare due to all the older programs that presume they will have admin-level access.

Kind of figured NT/2000 would still be secure due to them not being aimed at the "general consumer".

Actually, the security issue was for Win NT, 2000, and XP. There are security updates on the Windows website though that take care of this.

I've found the best way to prevent a shared-folder virus is take no crap from anyone, share no drives, and firewall everything...

Snover wrote:

This is one of the reasons that you neeeeeeed a virus scanner. And not just ANY virus scanner. You need PC-cillin. Well okay, maybe not, but it's really inexpensive and the BEST out of the major players (Trend Micro, Symantec, McAfee).

I've had serious trouble with McAffee and Norton Antivirus taking up all my memory and crashing my computer. I like the level of safety Norton gives, but it's getting ridiculous... Norton has secured my computer from being used even by me...

Any suggestions?