When will the security hole be fixed that allows a worm to disable NOD32?

When I attempt to download the NOD32 plugin from http://www.bootcd.us/BartPE_Plugins_Commercial.php I get the following message: "The requested URL /files/011203-nod32.abc was not found on this server." Anyone else have this problem?

 

Yep. I am having the same problem. There is another member here who offered me his plugin for NOD32 back in May. I guess I should have taken him up on the offer. Now I finally have some time to make a boot CD and the NOD32 plugin seems dead. I sent him an instant message but he hasn't been here in a couple of months so I don't know if he will see it. Maybe the 404 error is just temporary and we will be able to tomorrow download the plugin.

 

Hi Pollux, yes I was aware of this, and acknowledged it in my above letter to Eset when I said “I realize that your competitors subject their customers to the same security flaw”.

Hahaha, hehehe, etc. No disrespect intended, but I thought it was pretty evident from my letter to Eset that the fix I’m advocating goes far beyond a mere signature update. As what about the next AV killing worm that doesn’t have a signature yet, and the one after that, and the one after that. I’m referring to the worms that are able to avoid detection by “advanced heuristics”--which is obviously not “advanced” enough to detect all unknown malware.

What I’m proposing is something unique to the AV software industry--an AV program that users can rely on to work ALL of the time, rather than just until the next unknown worm comes along and secretly disables it. Because newbies who don’t know about Process Guard shouldn’t have to reformat their hard drive or spend $75 at a repair shop every time some kid decides to play with nasty worms.

So my position is simply that a million dollar AV program shouldn’t come without a lock, period. Eset should provide a lock themselves, designed specifically to keep hackers from surreptitiously shutting down their program. Once they’ve got such a lock, and publicize the disadvantages of not having one, I can envision all of the other AV companies being boycotted until they develop locks of their own. And they may even lose their customers permanently, if Eset can keep NOD32 running smoothly.

What AV companies are doing now is no different than a storage company promoting high security storage rooms with a 24 hour armed guard. They advertise “advanced motion detection, state of the art surveillance cameras covering every foot of the facility”, etc. But what they hide in the fine print of the contract is that their guard shack doesn’t even have a lock on the door. So all it takes for their heavily promoted security to be circumvented is a burglar sneaking in while the night shift guard is making his rounds, and dropping some strong sleeping pills into his water bottle.

I understand that AV programs are useless against new malware that escapes heuristics detection, and that this ridiculous vulnerability will exist until “advanced heuristics” is a LOT more advanced. But my position is that the AV companies have the ability, as DiamondCS has demonstrated, to keep unknown malware from surreptitiously disabling their programs. But yet, they have thus far shown no interest in providing their customers with this common sense protection.

And this is incomprehensible to me, since any new undetectable worm can leave their customers with ZERO protection against all of the malware they DO have signatures for. I mean, just how much more ludicrous could this situation be? The reality is that there’s simply NO excuse for such a massive security hole. Because if you’re going to charge people annual fees to protect them against 100,000 known viruses, etc., fix your program so a kid with a new worm can’t come along and shut it down without the users knowledge!! Because like DiamondCS says on their web site, “Security software can only protect you if it hasn't been terminated or modified“.

Umm, what you’re overlooking is that the above links are NEW news to the people who haven’t seen the articles yet. You know… the millions of people who go online each week for the first time, and have no idea that I.E. has more holes in it than Swiss cheese. Obviously, many of these people will find their way to Wilders Security and will be grateful for my contribution, even though the stories have been covered in other forums already. As they may not be retired yet, and thus will not have enough time to browse through every forum on this site. So the forum I posted the news in may be their only exposure to it.

Ummm, I wasn’t aware I was doing that. The people I was in contact with are very intelligent, yet they believed censorship had been utilized in an attempt to quash this issue ‘before it got out of hand’. So naturally, I assumed that some of the dozens of other people who were looking forward to a response from Eset regarding my letter might be harboring the same beliefs, following the sudden closure of the thread in question. And my personal experience with Wilders Security has been that they do not engage in financially motivated censorship, or any other type of censorship for that matter.

Being a Wilders supporter, I simply felt the need to dispel any such erroneous beliefs, which is the only reason I touched on the subject of censorship. For proof they weren’t playing the censorship game by closing that thread, suspicious people only need to look as far as this thread. As it wasn’t deleted--and it hasn’t been closed yet.

 

Hi Marcos, no that's not the security hole I'm referring to. Please see my post to pollux, as that should clear up the misunderstanding.

 

Yes, well, I suppose inquiring minds are waiting to hear more about this:

Especially since Blackspear seems to have provided evidence to the contrary.

pollux

 

If I recall, Blackspear was trying to install NOD on an already infected machine. If that virus/worm process was designed to deal with anti-virus software, and had been set up as a system service, I don't think you could ever guarantee that NOD or anything else could not be killed when subsequently installed. When an unknown virus controls the OS before the anti-virus is installed, I think you would need to boot from an uninfected OS to have a reasonably secure installation.

At this point, somebody from Eset should be chipping in, "And here's how to create a boot cd with the most recent Eset signatures...". I would hope.

 

I agree Eset should be responding as to how we can get a NOD32 plugin for BARTPE as the only one that I can find is giving a 404 error. Not much point in creating a boot CD if I can't put NOD32 on it. Yeah, I can put McAfee's Stinger on it easily enough, but I want to put NOD32 on it also.

I have been asking for an easy way to make a boot CD with NOD on it for a very long time.

 

Unlike the chicken and the egg, we know what comes first with malware and signatures. When heuristics fail, the malware obviously has to precede the signatures. And in this age of extremely fast spreading viruses and worms, millions of people can be infected before there's a signature available. So clearly, updating your signatures on a daily basis is not a viable solution to the stealth circumvention of AV programs.

 

I believe this is what you're looking for: http://www.911cd.net/forums/index.php?showtopic=5344

If it's not, please send me a private message so we can keep this thread on topic. As we don't want it shut down before Eset has ample opportunity to respond to it. Because in the eyes of all the prospective customers who happen across this thread in the future, the avoidance/skirting of this thread's topic by Eset will speak much louder than words. But if the thread is closed prematurely, they'll obviously have a legitimate excuse for not responding to it.

 

Well said pollux... I know my inquiring mind is definitely waiting to hear more!

 

Maybe, maybe not.

According to my read, the installation of NOD32 was to a compromised system. There are few guarantees of anything in that scenario - there are simply too many unknowns. This is a situation in which offensive measures really need to be available, and AV's, by their nature, are defensive beasts.

The launch of malware within a protected environment, and having it kill a targeted process is a lot different than installing a new application into an already compromised environment and expecting it to perform aggresive cleanup action. I'd need a lot more information on the particulars of the system/malware/ensemble of processes active before drawing any conclusions either way.

Would I like an AV to be able to handle this? Of course. Is that a reasonable expectation when even the ultimate fidelity of the install is possibly in question? In my opinion, no.

Blue

 

I'm not affiliated with NOD, but as stated the NOD32 Kernel is not killable (at least installed on a non-compromised machine.) This thread made me wonder, so I downloaded DCS' Advanced Process Termination, and indeed none of the methods would kill it. Try it for yourself! Now if it did kill the UI I don't think you would see the same warning windows asking you what to do to get rid of the worm, but it will still block access to it, etc. Maybe Eset could shed some light as to what would happen in this scenario?

 

Hi Blue, I think Pollux is just wanting Marcos to elaborate on his “The NOD32krn process is unkillable” statement period. As you have to admit that it’s rather comical for a company representative to respond to a thread like this with a simple five word denial, if that is in fact intended to be Eset’s official position on this issue. It kind of reminds me of a fleeing bank robber shouting to witnesses in the parking lot “I didn’t rob the bank”, and expecting them to just take his word for it.

When Marcos made his now infamous “unkillable” claim, Blackspear reported “I had a virus/worm in my store the other day, we installed Nod32 and updated it, everytime we start a scan it "killed" Nod32, brought it to it's knees”.

My position is that it doesn’t make any difference whether a virus/worm is already on your computer when you install an AV, or whether you get it AFTERWARDS. As either way, it has the same effect. In other words, if it’s a new virus/worm that escapes heuristics detection, then it’s like the AV doesn’t exist, which means it can do anything to your OS that it could do if you didn’t have an AV installed at all. (Provided that it was programmed to limit it’s ‘processes’ to whatever can avoid heuristics detection.)

And I don’t think there are any scenarios in which it’s acceptable for an AV program to be “killed” by the malware that IT’S suppose to kill. As that sounds like consumer fraud to me. You spend your hard earned money on software and annual fees to kill viruses/worms, only to have a kid with a free worm kill your costly PROFESSIONAL killer. I mean, how logical is that? The AV programs should be able to hold their own--fully prepared to defend themselves against 'sneak attacks by a camouflaged enemy'.

As the AV companies know they're putting their programs into battlefields to fight well armed opponents. But the reality is that they’re sent into battle without so much as a flak jacket, and can thus be picked off by unknown snipers over and over. Which in my book, makes the programs more like smoke and mirrors, rather than serious protection that you can count on. It’s kind of like a 1960’s soldier in a Vietnam jungle being put on sentry duty at night without any weapons to defend himself.

And again, security newbies shouldn’t have to pay expensive medical bills for their computers every time their unarmed AV program gets picked off. In fact, I foresee a huge class action lawsuit sometime in the future to recover all of those medical expenses from the AV companies. Now I know I shouldn’t be preaching, especially to a moderator, but before I shut up, here’s some additional “evidence to the contrary”, to refute the “unkillable” claim made by Eset‘s representative:

http://www.trendmicro.com/vinfo/virusencyclo/default5.asp?VName=WORM_RBOT.JZ&VSect=T

It’s a link to a Trend Micro report, regarding a worm named “WORM_RBOT.JZ” that was discovered on Jun. 29, 2004. And the technical details state “This worm terminates the following processes”, and “NOD32.EXE” is one of the numerous programs on that list.

I learned about this link from a moderator in another thread, and although I’m sure Eset has a signature for it now, the issue is that it’s evidence to refute the claim made by Marcos that NOD32 is “unkillable”. And since Trend Micro is an unbiased third party, it’s obviously a no-brainer as far as which company has the most credibility in this matter.

And since “where there’s smoke there’s fire”, I’m sure if I had the time, I could find dozens of other similar reports fairly easily. The bottom line is that NOD32 is just as "killable" now as it has been in the past. It's just a sitting duck waiting for the next unknown AV killing worm/virus to come along.

 

I don't believe there is a current AV that can guarantee it is 100% not killable for all future threats on a Windows machine. Also guarantee it is not killable if a machine is already infected. I also don't think any of the AVs could guarantee, in the future, 100% protection from being compromised for all new threats while running Windows.

 

I guess the 'programmer' for the worm described in my above post is just a little more clever than the DCS programmers.

 

Has it not crossed your mind that the kernel is nod32krn.exe, not nod32.exe?

 

I think one point that you are missing is that NOD32.exe is the on-demand scanner, not the kernel. As long as nod32krn.exe is there, you still have recourse. This protection is also new to the latest version of NOD, so the short answer to your question of when they are going to respond to this kind of attack is that they already are responding.

 

Nope. Microsoft isn't promoted as a security program, so security newbies have no illusions that it will protect them from viruses/worms. They know they have to buy a separate AV program for that.

I wouldn‘t either--that‘s why I keep my confidential files on a Mac that‘s NEVER connected to the Internet. But then we aren’t security newbies who believe their AV programs will remain on guard at all times.

Agreed.

That’s what I’m waiting for, but they don’t seem to be in too big a hurry to show up.

 

My position is that they should at least have the same protection from being killed that Process Guard offers--as that's a whole lot better than the current ZERO protection.

 

Looks like they are working on it.


https://www.wilderssecurity.com/showthread.php?p=255144#post255144

https://www.wilderssecurity.com/showthread.php?p=255187#post255187

 

Good post Blue, as the system was already infected, I did not have a concern, and as stated, Nod32 did clean it off when slaved..

Cheers

 

Has it not crossed your mind that the Trend Micro typist may have simply omitted some programs by mistake, particularly since that was such an extraordinarily long list? Or perhaps he/she intentionally took some shortcuts. Could you have prepared that list without making some mistakes?

 

The fact that this post:

so blatantly contradicts this one:

makes me wonder if he's done his homework (such as downloading NOD32, Process Guard, or Advanced Process Termination to get a grasp on exactly what he's talking about, or maybe tried to get some insight from security/technical experts not affiliated with any, but knowledgable about, AV products), or even has a desire to get to the truth of the matter rather than just manipulate facts to confuse those that don't know better. Combine the lack of factual information with the tone of inquiry, and I wouldn't expect Eset to jump in here at all. The point is moot at this time as they had already addressed it at the time the thread was started.

(hint: the fact that the nod32krn.exe can't be killed by any of the methods provided by APT shows that they HAVE implemented protection equal to that of PG.)

Or perhaps he just never really set his sights any higher than The Enquirer.

 

Trend Micro did not make a mistake. The worm disables the scanner, nod32.exe not the kernel, nod32krn.exe. Just as Process Guard failed to kill the kernel as Notok explained.