70033.1271@CompuServe.COM (Steve Albrecht) (08/03/90)
In browsing through the April 1990 issue of Computers and Security,
Volume 9, No. 2, I read the following comments of Dr. Harold
Highland on the 4096 virus:
"This recently published computer virus is particularly
disturbing in that...checksum techniques likewise appear to
be useless, the virus `disappears' during the checksum
process..."
Can someone please elaborate on how the virus avoids the checksum
process, or perhaps direct me to more detailed information on this
virus?
In particular, does it avoid all checksum algorithms, or only
certain ones? How does it avoid detection from the checksum
operation?
Any help would be most appreciated.
Steve Albrecht
MIS Field Services
PLAN International
70033,1271@compuserve.comRADAI@HUJIVMS.BITNET (Y. Radai) (08/09/90)
Steve Albrecht asks about the following statement by Dr. Highland on the 4096 virus: > "This recently published computer virus is particularly > disturbing in that...checksum techniques likewise appear to > be useless, the virus `disappears' during the checksum > process..." > >Can someone please elaborate on how the virus avoids the checksum >process, or perhaps direct me to more detailed information on this >virus? > >In particular, does it avoid all checksum algorithms, or only >certain ones? How does it avoid detection from the checksum >operation? The virus "disappears during the checksum process" only in the sense that files infected by this virus do not appear to have been altered *IF THE VIRUS IS IN MEMORY WHEN CHECKSUMMING IS PERFORMED*. Didn't Dr. Highland mention this in his article? The same is true of some other viruses, incl. EDV and Number of the Beast (V512). From this it is obvious that the answer to your question whether it avoids *all* checksum algorithms is affirmative. But this is only under the above circumstances. The remedy is obvious: Instead of performing checksumming from your hard disk, do it only after cold booting from your original (write- protected) DOS diskette, with the checksum program and database also on a diskette. This will ensure that RAM is uninfected when the check- sum program is run. (At least it's much surer than depending on checks such as those advocated by Jim Molini and Chris Ruhl on this forum several months ago.) Y. Radai Hebrew Univ. of Jerusalem, Israel RADAI@HUJIVMS.BITNET (Note new address)
vail@tegra.com (Johnathan Vail) (08/10/90)
70033.1271@CompuServe.COM (Steve Albrecht) writes: In browsing through the April 1990 issue of Computers and Security, Volume 9, No. 2, I read the following comments of Dr. Harold Highland on the 4096 virus: "This recently published computer virus is particularly disturbing in that...checksum techniques likewise appear to be useless, the virus `disappears' during the checksum process..." Can someone please elaborate on how the virus avoids the checksum process, or perhaps direct me to more detailed information on this virus? Back when it was fun to hack with viral code I thought it would be necessary to avoid the checksum built into the .EXE header. The first approach was to compute a new checksum based on the entire new file. A better and more efficient way is to simple force the checksum of the actual added virus code be zero. That way, any checker will take the CS of the original file data and add it to the CS of the added virus code. This being zero it will result in the same CS as the original. This method will easily spoof checksums but not CRCs or LRCs. And I still don't know how to spoof a combination of these. I think that there are programs that will wrap around an executable and detect any changes made to itself. These can't be beat by the method described above. Probably what happens here is the the virus code gets executed first after being loaded. It then relocates itself and hides its tracks. Then it can pass control back to whatever program it has infected. The resulting load image is the same as it would have been without a virus. Just some random musings... jv [Ed. Unless I'm mistaken, the 4096 doesn't use this sort of mechanism to hide from checksums; it traps the interrupts that read files and disinfects files on the fly so that a checksum/crc/whatever actually sees the non-infected files.] The inability of snakes to count is actually a refusal, on their part, to appreciate the Cardinal Number system. -- "Actual Facts" _____ | | Johnathan Vail | n1dxg@tegra.com |Tegra| (508) 663-7435 | N1DXG@448.625-(WorldNet) ----- jv@n1dxg.ampr.org {...sun!sunne ..uunet}!tegra!vail
CHESS@YKTVMV.BITNET (David.M.Chess) (08/13/90)
To reply to some of Johnathan Vail's points:
- As you probably know (I couldn't quite tell from your posting!)
the checksum field in the header of EXE files is completely ignored
by the operating system, so a virus infecting an EXE file
doesn't have to worry about fixing it, or about leaving the
file's checksum unchanged (some viruses use the field as the
place to put their own self-id marker).
- Since the checksum field in the EXE header is ignored, the kinds of
checks that are useful in protecting against viruses are CRCs
performed by an anti-virus utility that looks for file
modifications. Since there are lots and lots of possible
CRCs, and a virus writer has no way of knowing in advance
which ones his virus will encounter, it's not really possible
to write a virus that makes modifications to a file in such a
way as to fool any significant number of different CRC checks.
(I agree that it's easy for a virus to fool a simple add-up-
the-words checksum in the way you describe, but those are
so insecure that no one uses them, as far as I know.)
- Programs that check themselves for virus infection generally
do it by examining themselves *on disk*, not by examining
the in-RAM copy, for just the reasons that you give; the virus
will generally fix the in-RAM copy to look normal before
passing control to the "host".
As Ken points out, the 4096 (and other "stealth" viruses) defeats CRC
checks (and other modification-detectors) that are run while the virus
is in memory, by "lying" to programs about the contents of files. As
Mr. Radai says, the best way to protect against this is to get the
machine into a trusted state before running the modification detector.
On the PC, this involves a cold boot from a trusted floppy; not
exactly convenient, but worth the trouble for critical systems...
DC