Re: Why not a changeling?

[Michael.Wojcik () MERANT COM (Michael Wojcik)]

> -----Original Message-----
> From: Daniel Petzen [mailto:zuul () lls se]
> Sent: Monday, May 22, 2000 5:32 PM

>   I see your point. Where would a better hiding place for the scrambler be
> but in the OS? But are there OS:es which support reverseable key-based
> encryption?

I hate to keep rehashing this, but the point is that it doesn't have to be
in the OS.  There are a lot of Windows machines out there with WinZip.
WinZip, like most Zip implementations, supports encrypted
("password-protected") zip archives.  Popular Windows virus scanners, and
popular email virus scanners, are known to pass password-protected zip
archives unchecked (because they'd have to break the encryption to
decompress the archive, and while there are known techniques for breaking
the Zip encryption algorithm, it's computationally expensive).

Siegfried Gipp noted in another email message that simply compressing the
payload isn't sufficient.  That's correct, assuming the scanner understands
the compression format.  But password-protected zip archives are another
matter entirely.  You're using the Zip encryption algorithm to hide the
payload, not the compression; compression is completely beside the point.

And if the replication process includes generating a new password (as I
suggested in my original post on the subject last week), then there's no
handy signature for virus scanners to latch on to in the encrypted zip,
either.

Of course the key here is that the invariant part - the decryptor - is
already on the client system, as various people in this thread have been
suggesting.  My point is that the wheel is already not only invented but
mounted on the axle.

All you need to do is package the trojan in a password-protected zip, attach
it to an email message with text that includes the password, and use a
little social engineering.  Self-decrypting polymorphic trojans calling
OS-supplied symmetric encryption algorithms aren't necessary at this time.

This isn't exciting new virus technology - it's just attacking one of the
weak points in the system: the compromise between virus scanner vendors and
users that says they'll ignore encrypted archives, because the alternative
is to forbid them completely.

It's entertaining to speculate about clever new ways to sneak payloads past
defenses (and that's what VULN-DEV is for, after all).  But let's not forget
that there are ways which are known to work (remember a few weeks ago when
the source to Bubbleboy was distributed using this method on this very
list?) but haven't been widely exploited yet, and for which we have no
general defense.  (Yes, readers of this list are probably careful enough to
not get caught by ILOVEYOU.password-protected.zip.  Plenty of other people
aren't.)

I might point out that this technique is also similar to the practice of
disguising malicious HTML using URL-encoding escapes, as in any number of
documented browser vulnerabilities.  Again, you have a "decryptor" (the
URL-encoding decoder in the browser) available on the target already.

A little imagination should reveal several more of these.  It's not
difficult to convert a small DOS executable into a batch file using a hex
dump; the batch file recreates the executable using debug.exe and executes
it.  As long as the virus scanner signature file only contains the signature
for the original executable, it's not going to identify the batch file
variant.  Virus scanner vendors will quickly update their databases, of
course, so you'd want to first accumulate a library of a few hundred old
viruses, convert them all, and start sending them all out for maximum grief.
(Batch files have liberal formatting requirements, so vary them to make
invariants in the reconstruction system itself less likely.)

Michael Wojcik             michael.wojcik () merant com
MERANT
Department of English, Miami University