Trojan horse Downloader.Generic.ML

[James Egan]

Deduce the whole original 26 hex char key or just that particular packet?
How much time/effort does it take a competent hacker to get the whole 26 hex
char key and have full immediate access to the WiFi net?

It depends on the volume of your wireless output. The airsnort FAQ (as
above url) will give you an idea of how long it could take to find
yours.

I'll have a look at WPA. Is WPA secure outside an NSA effort?

Apart from having better encryption, it deals with some of the flaws
of WEP eg. changing keys every few minutes and using proper hash
authentication instead of crc based.

It's not perfect but it's much better than WEP if used with a long
master key.


Jim.

 

[kurt wismer]

Don't pay too much attention to the size of the key. You don't need to
know the wep key to decrypt a packet if you know the cipher stream
used to encrypt it. The initialisation vector used to generate cipher
streams is only 24 bits (16-17 million possible streams) and is sent
in the clear with the packet.

??? wep always uses rc4 so you always know the stream cipher used to
encrypt...

that's not the real issue though - the real issue is that with an output
feedback stream cipher (like rc4), if you encrypt 2 messages (packets)
with the same key (wep key + initialization vector) you can cancel out
the key by XORing the 2 encrypted messages together... to keep this
condition from happening you should change the wep key before the
initialization vector has a chance to go through every possible value -
but as has been shown not too long ago, the initialization vector can be
forced through all possible values in a matter of minutes with properly
crafted traffic...

so to ron: it's not a matter of breaking a 26 character hex key, it's
actually no more difficult than getting the device to cycle between all
possible 24bit initialization vectors... that's a much smaller number of
possibilities and is easily accomplished in minutes...

 

[kurt wismer]

Again, the false positive assertion seems to be in grave doubt.

lets save some time - zvi is an anti-virus
developer/designer/vendor/what-have-you... if he says that something
he's analyzed isn't a virus/worm/trojan then it probably isn't...

 

[Ron Reaugh]

lets save some time - zvi is an anti-virus
developer/designer/vendor/what-have-you... if he says that something
he's analyzed isn't a virus/worm/trojan then it probably isn't...

NO, I simply followed his own logic and assertions which proved to be
circular. His definitions are also parochial. Any expert should be able to
express his views or opinions in plain logic without resorting to arcana.
That's especially in this case which has very special properties. His own
analysis included the assertion c:\null "isn't benign".

 

[Zvi Netiv]

[...]

That file may be a malware related file, but it itself is not malware
(it is not executable and as such is not a threat) and any scanner that
detects it as such is wrong (but some would do so purposefully to get
better scores in AV comparative tests - like detecting boot sector
viruses in "files" like .bak backup files..

Based on the NULL sample inspection:

The file has a PE structure (Mark Zbikowsky's marker, 16 bit EXE stub, PE
extended header and sections) but it isn't directly executable.

Again, the false positive assertion seems to be in grave doubt.

Not according to industry standards. It's "false" because it isn't malware and
is a false *positive* because it isn't what the erring scanners claims it to be.
The only way for it to be a true positive is if it the file contained the
Qdown.s Trojan, incarnated.

You said it DID CONTAIN a reference to c:\null and that implies something
uninvited.

Windows constantly writes uninvited stuff to your drive, which doesn't make it
malware. The real world isn't only black or white, Ron, it's mostly gray over a
large scale.

Regards, Zvi

 

[Ron Reaugh]

[...]
That file may be a malware related file, but it itself is not malware
(it is not executable and as such is not a threat) and any scanner that
detects it as such is wrong (but some would do so purposefully to get
better scores in AV comparative tests - like detecting boot sector
viruses in "files" like .bak backup files..

Based on the NULL sample inspection:

The file has a PE structure (Mark Zbikowsky's marker, 16 bit EXE stub, PE
extended header and sections) but it isn't directly executable.

Again, the false positive assertion seems to be in grave doubt.

Not according to industry standards. It's "false" because it isn't malware and
is a false *positive* because it isn't what the erring scanners claims it to be.
The only way for it to be a true positive is if it the file contained the
Qdown.s Trojan, incarnated.

My standard and any resonable standard would include the case where I was
warned of nefarious activity involving this file. Apparently that happened.

Windows constantly writes uninvited stuff to your drive, which doesn't make it
malware. The real world isn't only black or white, Ron, it's mostly gray over a
large scale.

YES, and this case clearly falls on the side of AVG having done its assigned
job. It apparently did not give a false warning. I suspect that you'll
find that what's accepted in the industry as a false positive is when a
totally innocuous file from an innocuous source is flagged and reported by
the anti-virus program. Apparently that did not happen in this case.

 

[Zvi Netiv]

So not being a "32 bit executable" means what exactly? How many different
forms of executables are there? What about a DOS 6 device driver?

That means that the file won't execute when directly loaded, with one of the
Windows' executable extensions, e.g. exe, com, scr, pif, bat, vbs, ... etc. As
for a DOS driver, forget it, it doesn't have the structure for that, not even
close to.

Relevance?

The highest.

That it isn't by your findings a "32 bit executable" and therefore a false
alarm does NOT follow logically. The detection did coincide with some
nefarious virus like activity and was therefore NOT a false alarm. That the
detection did coincide with a file that seems to contain code further seems
to suggest that it's not a false alarm.

If you are that knowledgeable and know the answers to your questions, then why
asking them? You can't ask questions, and at the same time set the terms of the
answer should be.

That conflicts with your assertion that the detection was a false alarm.


"it isn't one and won't execute "...."The code"...are opposite statements.
Whether the code gets executed depends entirely or what/who loads the code
and then jumps to the entry point. In this arena the definition of an
executable or virus code needs to be very precise. Whether it runs by
entering it's name at the DOS prompt isn't relevant.


The opposite appears to be the case although c:\null may be just a part of
the overall trojan or an intentional misdirection.

You seem starting to comprehend.

All the entries there are one of the following two:
NUL=C:\WINDOWS\TTFCACHE
C:\WINDOWS\SYSTEM\CP_28605.NLS=C:\WINDOWS\SYSTEM\TBMA0B0.TMP

The second appears ~15:1 over the first. Both appear multiple times.

You don't specify the date of the Wininit.bak file. The content doesn't seem
related to the subject.

Qdowas2.dll isn't found by Find on this W98se system nor is it found a on
similarly configured other nearby W98se system I tried
OK.

SO, why did AVG suddenly trigger(find it)?

I don't know, you don't know, and repeating the question won't get you the
answer. The way to know is to replicate the event in a controlled setup, and
under surveillance.

Check all files was NOT turned
on and I wasn't doing any kind of explorer window on c:\ or anywhere else.

I gave the two as examples, and you made them the rule. You won't get to the
bottom of this if you won't relax that stiffness and open your mind to
possibilities that aren't in your predefined checklist.

An action that you claim AVG wouldn't have noticed.

If the creation of NULL was originated from the outside (of your PC), then no,
AVG wouldn't detect it, nor anything else, The only way to capture the creation
of the NULL file is a trap set to capture that specific event.

Regards, Zvi

 

[Zvi Netiv]

[...]

Relax, the file isn't a real Trojan nor a Trojan at all (just code> fragments of
what may have been part of anything else, like an installer, or attempted
malware) and it isn't the first time that several AV are in "agreement" on a
false positive, nor the last.

Careful parsing of your posts/assertions lead one to see that it is a self
contradictory circle on this. The strong evidence is that it was NOT a
false positive by a logical definition of 'positive'. Someone in this
thread said "A systematic approach, will." I couldn't agree more.

The beauty of logic is that you can prove with whatever you like. Suit yourself
if it makes you happy.

So AVG could have been newly updated that day(6/15 I think) to look for this
C:\NULL behavior which it believes is a detectable symptom of nefarious
activity:a positive.

No such user activity occurred proximate to this incident.

I mentioned folder viewing by Explorer as an example, out of tens of activities
that could have caused access to the file. Here is one more that people don't
pay attention to: Background file indexing ... and the list goes on.

HUH, the detection DID occur. It happened in real time and NOT scan time at
a moment that seems NOT to coincide with any usual virus time system
activity.

Your reluctance to accept won't bend the rules of science. The AVG
detection didn't occur at the time of the NULL file creation. Everything else
is irrelevant.

It's initial detection was in real time on I think 6/15.

What proof do you have?

The file's date was 5/5/5.

Non sequitur.

That doesn't pass logical muster. I parse that statement to mean that there
was NO FALSE positive in this case.

Call it what you like, as long as we understand each other that the sample
doesn't execute (i.e. a negative, in common terminology), and isn't the Qdown.s
Trojan (i.e. false, in common terminology).

Seems NOT. AVG warned me about something unwanted. AVG apparently was NOT
crying wolf. The fact that AVG seems to have worked outside the range of
your experience isn't relevant.

Frankly, you begin to tire me.

Regards, Zvi

 

[Zvi Netiv]

"Zvi Netiv" <support@replace_with_domain.com> wrote in message

My standard and any resonable standard would include the case where I was
warned of nefarious activity involving this file. Apparently that happened.

"Nefarious" can't be quantified, nor qualified as false or true, therefore
cannot serve as classification criterion in a standard.

If you insist on resolving that issue, then wait a couple of months and resubmit
the sample to a www.VirusTotal.com online inspection and see what changes
compared to the current results. If the sample is a true positive, as you
claim, then the great majority of scanners should then detect it with its
correct name.

If OTOH it's a false positive, as I claim, then you will get more or less the
same results as the current ones.

[...]

YES, and this case clearly falls on the side of AVG having done its assigned
job. It apparently did not give a false warning. I suspect that you'll
find that what's accepted in the industry as a false positive is when a
totally innocuous file from an innocuous source is flagged and reported by
the anti-virus program. Apparently that did not happen in this case.

If you think that your AV performed as expected, then be happy.

As for the definition of a false positive, you are in barren solitude.

Regards, Zvi

 

[kurt wismer]

kurt wismer wrote:
[snip]

that's not the real issue though - the real issue is that with an output
feedback stream cipher (like rc4), if you encrypt 2 messages (packets)
with the same key (wep key + initialization vector) you can cancel out
the key by XORing the 2 encrypted messages together... to keep this
condition from happening you should change the wep key before the
initialization vector has a chance to go through every possible value -
but as has been shown not too long ago, the initialization vector can be
forced through all possible values in a matter of minutes with properly
crafted traffic...

apparently this is the naive approach - the real method involved in the
most recent demonstrations uses additional tricks to cut down the amount
of traffic that needs to be collected...

it's still all done with publicly available tools, though...

 

[Zvi Netiv]

Zvi Netiv wrote:

[snip]
What prevented Integrity Master, and checkers in the same category (e.g. CRC,
MD5, etc.), from becoming widely used in AV, are the following reasons:

1. Plain integrity ("plain" here refers to the processing of the entire file,
not to the method used) is useless for AV purposes as it's unable to
discriminate between legitimate changes and malware related changes.

as malware can make arbitrary changes, processing the entire file is
required... if you're only worried about parasitic infection then sure,
for some types of files you may only need to check a subset of the
entire file, but integrity checkers aren't *just* for detecting that
sort of thing...

Malware doesn't make arbitrary changes, full stop. That's a fallacy that has
been nurtured by ignorance, fools (e.g. Lambdin, with his unsolicited CRCs), and
AVers that had an interest that users assimilate that nonsense.

of course we've had this disagreement for a good long time now... you
feel integrity checkers should behave like your product but your product
has been highly specialized/optimized for detecting infection... plain
integrity checkers detect a broader range of changes and, correctly or
incorrectly, leave the interpretation of those changes up to a
non-autonomous agent also known as the user (which is the real reason
the non-technical majority never adopted them)...

You are actually saying the same thing, but from a different angle: Users were
incapable to tell on base of the plain integrity change whether it was caused by
virus or was benign.

there are those who feel that programmatically restoring
infected/corrupted objects to their original state is a losing
proposition... some anti-virus vendors (like sophos) don't offer virus
disinfection for most file infecting viruses because of this philosophy...

Again, part of the above is propaganda, that was cultivated by interested
parties. The fact is that DOS objects, all types, were recovered through
integrity methods to their *exact* original state, to the byte, including the
time and date stamp. The restored file would even occupy the same exact
location on the hard drive, that it occupied before it was infected. Several
products like NAV's inoculation, Eliashim's PIC, and Thunderbyte's Tbclean
performed just as well as IV in restoring infected DOS files. The advantage of
IV on the above was its better false positives rejection. Eventually, this was
one of the reasons the integrity module lost importance in the above products
(the other reasons are the advent of the Windows infectors, also known as PE
infectors, and the orientation of the producers to scanners).

Your above assertion became true with the appearance of PE infectors.
Disinfection of a PE object by scanner does never restore it to its exact pre
infected state. It has nothing to do with malware modifying the file
"arbitrarily" (malware doesn't do that), but with the complexity of the PE file
structure and reverting the changes made to. Theoretically, *only* restoration
from a suitable integrity signature can assure full recovery of PE objects, but
as said, the signature file to do that will be prohibitively large. That's why
we ended with real-time integrity monitoring only for PE file in our on-access
module, and recovery for 16 bit objects only (in the offline module, not on
access).

while the average joe may certainly prefer a magic bullet (and there are
plenty of examples of people expressing exactly that), i'm not about to
penalize a technology for failing to be a panacea - i'd rather penalize
a proponent of it for falsely leading users to believe it is a panacea...

I hope that you don't point to me as I never made such claim. Which didn't
prevent professional bashers from pretending that I did.

plain integrity checkers are purely detective mechanisms... they do not
prevent and they do not restore, but they are (when used properly)
practically infallible at detecting change...

Let's extend the above now: Real-time AV optimized integrity checkers can
detect an infection and block execution of that object. When implemented
properly, real-time integrity monitoring is nearly infallible at detecting viral
changes in monitored files.

Regards, Zvi

 

[Gabriele Neukam]

On that special day, Ron Reaugh, ([email protected]) said...

That it isn't by your findings a "32 bit executable" and therefore a false
alarm does NOT follow logically. The detection did coincide with some
nefarious virus like activity and was therefore NOT a false alarm.

Why do you insist that this file is *actively* malign? It might be the
remnants of what happened in another place, and was left instead of
being cleared after action (installaion? be it for good or evil
purposes). I had leftovers of stuff, mostly in C:\windows\temp all the
time, but a bad coder might use C:\null instead and then fail to remove
it properly.

Or the file is a "cookie", belonging to another program which you still
haven't detected or meanwhile removed. It could be anything. AV
scanners don't only alert on active malware. I once copied a portion of
an infectious mail into a newsgroup posting, it was along the lines

Content-Type: audio/x-wav;
name="message.scr"

(this example is taken from a worm I received just a few days ago;
obviously there are stil many IE 5.x without SP2 out there, so that it
would work)

Guess what happened: a virus scanner (not to be named here) screamed
"dangerous content" and even spammed it into the news group. Other
regulars got amused about this, and quoted my lines. And the AV
screamed again, in spite of the quotation characters.

How good/bad is your AV program, to tell the difference?


Gabriele Neukam

(e-mail address removed)

 

[Art]

kurt wismer wrote:
[snip]

that's not the real issue though - the real issue is that with an output
feedback stream cipher (like rc4), if you encrypt 2 messages (packets)
with the same key (wep key + initialization vector) you can cancel out
the key by XORing the 2 encrypted messages together... to keep this
condition from happening you should change the wep key before the
initialization vector has a chance to go through every possible value -
but as has been shown not too long ago, the initialization vector can be
forced through all possible values in a matter of minutes with properly
crafted traffic...

apparently this is the naive approach - the real method involved in the
most recent demonstrations uses additional tricks to cut down the amount
of traffic that needs to be collected...

it's still all done with publicly available tools, though...

Gaining access to the router setup, I suppose. Then disabling the
router's firewall. But then what? What if only connection sharing and
no print/file sharing is involved? In my case, the hacker would find a
hardened OS with no open ports, no services running, and no known
vulnerabilities to exploit He might also have a sw firewall behind the
router to deal with.

Art

http://home.epix.net/~artnpeg

 

[Ron Reaugh]

That means that the file won't execute when directly loaded, with one of the
Windows' executable extensions, e.g. exe, com, scr, pif, bat, vbs, ... etc. As
for a DOS driver, forget it, it doesn't have the structure for that, not even
close to.

DUH and why do you think I brought it up?

The highest.


If you are that knowledgeable and know the answers to your questions, then why
asking them? You can't ask questions, and at the same time set the terms of the
answer should be.

The only terms I set are that the answers be logically self consistent.

 

[Ron Reaugh]

Call it what you like, as long as we understand each other that the sample
doesn't execute (i.e. a negative, in common terminology), and isn't the Qdown.s
Trojan (i.e. false, in common terminology).

I never of course claimed any of the above. What I claim and you seem to
support is that AVG warned me about something nefarious going on ragarding
the not benign file c:\null. AVG did its job therefore to regard its
performance in this situation as a 'alse positive' is inaccurate.

I was hoping for some greater insight into what may have happened in my case
rather than having the incident brushed off as a false positive which
clearly it was NOT!

 

[Ron Reaugh]

On that special day, Ron Reaugh, ([email protected]) said...


Why do you insist that this file is *actively* malign? It might be the
remnants of what happened in another place, and was left instead of
being cleared after action (installaion? be it for good or evil
purposes). I had leftovers of stuff, mostly in C:\windows\temp all the
time, but a bad coder might use C:\null instead and then fail to remove
it properly.

ALL very true. The fly in that ointment is that AVG chose that moment
unrelated to anything seemingly going on suddenly to find that file. A file
that seems not to contain some arbitrary fragments but something "not
benign".

Maybe it just found the smoke from the smoking gun but apparently it did
find a shooting.

 

[Arthur Hagen]

ALL very true. The fly in that ointment is that AVG chose that moment
unrelated to anything seemingly going on suddenly to find that file.
A file that seems not to contain some arbitrary fragments but
something "not benign".

And just what criteria have been used to determine that it's "not
benign"? Please be very specific.

Maybe it just found the smoke from the smoking gun but apparently it
did find a shooting.

No, it found smoke and shouted "Gun, Gun!". The smoke might just as
well have come from a barbecue.

 

[Roger Wilco]

the

I never of course claimed any of the above. What I claim and you seem to
support is that AVG warned me about something nefarious going on ragarding
the not benign file c:\null. AVG did its job therefore to regard its
performance in this situation as a 'alse positive' is inaccurate.

I was hoping for some greater insight into what may have happened in my case
rather than having the incident brushed off as a false positive which
clearly it was NOT!

Since 5/5/05 is "Cinco de Mayo" maybe you should ask the Mexican
authorities about it...PLONK!

 

[James Egan]

Gaining access to the router setup, I suppose. Then disabling the
router's firewall. But then what? What if only connection sharing and
no print/file sharing is involved? In my case, the hacker would find a
hardened OS with no open ports, no services running, and no known
vulnerabilities to exploit He might also have a sw firewall behind the
router to deal with.

Spoofing an approved mac address will probably also be required to
gain LAN access but assuming that is sucessfully accomplished, that
should give access to the router's web interface. However, its admin
password is not known by the hacker at this stage and like all your
other pc's there's no way into them.

Though your files might be safe (for the time being at least) there is
still a listener on the network capable of picking up your "in the
open" username/password combinations like pop3 email accounts or maybe
when you ftp some new pages up to your website. And, of course, you
might eventually access the router via. it's web interface. All these
are plain text and there are plenty of tools available to list them
all.

If the hacker gains access to the router, there is no point switching
the firewall off because it isn't doing anything.


Jim.

 

[Art]

Spoofing an approved mac address will probably also be required to
gain LAN access but assuming that is sucessfully accomplished, that
should give access to the router's web interface. However, its admin
password is not known by the hacker at this stage and like all your
other pc's there's no way into them.

My admin password is 12 characters in length. Even if a somewhat
longer one is allowed, it seems with processing speeds what they are
now, a brute force approach might not take long to crack it.

Though your files might be safe (for the time being at least) there is
still a listener on the network capable of picking up your "in the
open" username/password combinations like pop3 email accounts or maybe
when you ftp some new pages up to your website. And, of course, you
might eventually access the router via. it's web interface. All these
are plain text and there are plenty of tools available to list them
all.

I live way out in the boonies, about fourteen miles from the small
city of Harrisburg. Hard for me to imagine hackers with high gain
antennas roaming rural areas They say such antennas may work
up to four miles away.

But no doubt the general wireless security situation is the pits.
Most people I've talked to about it seem like they couldn't care less.

Art

http://home.epix.net/~artnpeg