VIRUS-L Digest Wednesday, 24 Jul 1991 Volume 4 : Issue 129

VIRUS-L Digest Wednesday, 24 Jul 1991 Volume 4 : Issue 129

Today's Topics:

HighMemory(Re:long & technical) (PC)
Re: long and technical (PC)
Re : multiple compressions with Pklite (PC)
re: Multiple compression
Conflicting comments
double compression
re: SECURE.COM (PC)
Anti-Virus software recommendation sought
Info sources for PC viruses wanted. (PC)
Fprot & DOS5.0 (PC)
How do managers protect networks?
Philosophy, comments & Re: long and technical (PC)
CARMEL TntVirus, A Trojan suspect. (PC)
New Devil's Dance?
Re: virus for sale
NSAi announces Computer Security Connection

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed. Contributions should be relevant, concise,
polite, etc. Please sign submissions with your real name. Send
contributions to [email protected] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks). Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list. Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [email protected].

Ken van Wyk

----------------------------------------------------------------------

Date: Mon, 22 Jul 91 13:34:12 +0300
>From: [email protected] (Vasili Bykov)
Subject: HighMemory(Re:long & technical) (PC)

In his article [email protected] (Keith Rohrer) writes:

>>Scanner sets INT 01 ( single-step ) on itself and calls some function of
>>INT 13, setting TF simultaneously. A handler of interrupt 01 traces the
>>addresses through which the execution passes( until it returns to the
>>scanner ). It is sure that BIOS INT 13 handler resides somewhere between
>>segment adresses 0C000h and 0FFFFh. As soon as the execution gets into
>>this region, a scanner stores current address and later use it as an entry
>>point of INT 13 handler.
>>
> Yeah, but what if I have an infected program (whose infection
>traps INT 13) in high memory? On my machine, for one, I've got disk
>BIOS at CC00 and everything from D000 to EFFF is high RAM...
> The advantage one *does* have in such a setup as originally
>mentioned is that you can
>just find the "real" BIOS INT13 handler location *once*, then remember
>it for that machine.

The article I wrote was too concise and the idea of it appeared to be
a bit ambiguous. I think I should explain in more details:

Using such a technique (tracing addresses during INT 13h execution) you
cannot guarantee that the address you find is the same as the one which
is set by BIOS during POST. If you have some card installed, its
firmware can re-install INT 13 on itself during ROM-scan. In such a
case the address you get is the entry point of this firmware's routine.

So the only thing you can guarantee is: this code is situated above
0C00h and below 0FFFFh memory segment (or some other values which you
choose). MAY THIS CODE BE A PART OF SOME VIRUS?

[] In case of trivial PC without high memory the answer is *NO*,
surely. For those machines anything you have above 0A000h
segment is either video data or some ROM routines. It is
unlikely that you bought a card with virus and installed it
into your PC.

[] Well, so what if you have a high RAM ? I say, "No, in 9999
cases of 10000 it is not a virus too." The reason is the
principles of high memory organization.

If you have expanded memory, that is a memory above 0A000h segment, but
within 1 megabyte address space, you should follow Lotus-Intel-Microsoft
convention named EMS (Expanded Memory Specification) in order to
handle it. You must use EMS memory driver to do so. Usually this memory is
used for keeping huge amounts of data like spreadsheets. Some code may
be placed there too. But it *MUST NOT* be a code which handles
interrupts. Expanded memory is bankable, that is its total amount may
be (and usually is) greater than the address space it occupies. In such
a case only some part of this memory resides in address space. In order
to access your data you should first tell EMS driver to place them in
memory, to be sure that the data located where you think they are. So
if you set interrupt address to code located in expanded memory, a
situation when an interrupt occurs but a bank where virus resides is
switched off the memory space, will result in a system crash. So
expanded memory is not the best place for a virus.

If you have extended memory, that is a memory above 0FFFFh segment, you
can use it only in protected mode of 80286/386/486 processor using
their segment selectors mechanism. MS DOS runs in real processor mode,
and you cannot reach code there via real mode's interrupt table.

Surely, some buffer code may be provided which resides in lower memory,
catches interrupts, switches into protected mode or tells EMS driver to
place bank with code into memory space, and gives control to virus
itself. But if you take into account that different computers have
different high memory configuration, your virus should be extremely
intelligent in order to work properly with any of them. A virus of size
about 20 or 30 Kbytes is not the best one. It would not hide for long.

That's why I suggest that a code in high memory address space is not a
malicious one.

Vasya. :)

- --
- -|- Vasili Bykov -|- Moscow -|- [email protected] -|-

------------------------------

Date: Mon, 22 Jul 91 12:46:40 -0400
>From: padgett%[email protected] (A. Padgett Peterson)
Subject: Re: long and technical (PC)

>From: "Mark Aitchison, U of Canty; Physics" <[email protected]>

>By the way, the original poster suggested that the original int 13
>vector should be restored, if the bootup checking program found a
>problem. It is better to rewrite the correct boot sector (using the
>known, clean, int 13 address), and then force a cold boot. There is
>toom much chance of some other interrupt (e.g. the timer) being
>intercepted, in which case the virus might be able to re-install
>itself after being "cleaned" from int 13.

While this is a good solution, once given the fact that a PC may be
infected, I would not trust anything that system does. e.g. Could you
trust the keyboard ? For this reason, DiskSecure was designed to lock
up the system with a terse warning message, forcing a cold boot from a
"recovery" floppy (nice to see that Central Point Software picked up
this technique for PCTools 7.0)

Consequently, a cold boot from a write-protected floppy should be the
first action followed by verification of the infection, analysis of
the charactoristics, and concluded with virus removal and
reverification.

Padgett

Note to DiskSecure users: If McAfee's VSHIELD is in use, it will
detect the odd boot sector used on the maintenance disk (used to boot
bare for cranky software and defragmenting), flag it as an "unknown
boot sector virus" and refuse to allow a warm boot.

Personally, this is the kind of "false positive" I like since DS has
many of the traits I would be suspicious of on a floppy, but if
VSHIELD is in use, a cold boot or other modification is necessary to
use the maintenance disk.

------------------------------

Date: Mon, 22 Jul 91 14:24:25 -0400
>From: Dmitri Schoeman <[email protected]>
Subject: Re : multiple compressions with Pklite (PC)

Someone inquired about how to achieve multiple compressions, and since
it is such a trivial method to impliment I feel that it adds no threat
to the computer world to explain it. Pklite and Lzexe both create
temporary files on disk with the "compressed" code. If the
"compressed" code is larger than the original code it will erase the
temp file, and I am sure we are all aware of the non-permancy of the
erase command, so either by using one of the Norton utilities or, I
imagine DOS 5.0 the file can be unerased and renamed as an EXE file.
If one wishes to not allow PKlite to uncompress, or to compress the
file multiple times with PKlite, one can change the first occurance of
the letters PK(lite) which will prevent pklite from recgonizing the
file, but will still allow correct excution. One thing which I was
unable to check, due to my virus free enviornment is if this method
will hide a virus. It is a possiblity that, depending on the
compression scheme, the file would not be changed sufficiently to hide
the search strings, however if they rely on the location of the string
they might be fooled. Can anyone verify if the code is sufficiently
changed by the above method?

- -----Dmitri Schoeman [email protected]

------------------------------

Date: Mon, 22 Jul 91 15:00:44 -0400
>From: padgett%[email protected] (A. Padgett Peterson)
Subject: re: Multiple compression

Since this shows no inclination to dieing out on V-L, it may
be of interest to clear the air. However, I am reluctant to post this
openly lest it give people ideas.

Simply, it is very possible to multiply compress files. I have
started with EXEPACK, then gone to LZEXE, thence to PKLITE. Order is
unimportant however it does take some "fiddling" between stages to
ensure that each program succeeds.

While such a process provides no gains in size (the result
often turns out larger than the original), it does give single-pass
signature scanners fits. Consequently, there is probably some slight
chance of a trojan using such a technique to transmit a virus or other
malicious software.

The answer, of course, is for scanners to use a recursive
technique for unravelling files and it would be relatively easy to
check. Eternal Vigilance and all that.

Padgett

------------------------------

Date: Mon, 22 Jul 91 15:16:40 -0400
>From: padgett%[email protected] (A. Padgett Peterson)
Subject: Conflicting comments

I just realized that in the last few days that I made two
seemingly conflicting comments reguarding when you can trust a PC.

In issue 128, the statement was made that given knowlege of
the "clean" paths to the hardware, software could be written that
would allow disinfecting an infected machine "on the fly".

Later, a response was posted to another comment that you must
boot cold from an infected floppy before trust is possible even if a
clean Int 13 (disk access) path is known.

The two are not really in conflict since the first presupposes
a knowlege base that does not exist at the moment. Without this
knowlege base, the second comment holds true. ("In theory vs In
practise").

Padgett

"What I said is not necessarily all of what I was thinking"

------------------------------

Date: Mon, 22 Jul 91 13:15:02 -0700
>From: [email protected]
Subject: double compression

- -=-=-=-=
>From: [email protected] (Fridrik Skulason)
Subject: Re: multi-compression

[email protected] writes:
>Let's say I have an EXE that I've run through LZEXE. PKLITE, regardless of
>version will do a test on the file to see if the file is smaller after the
>compression is added. Since the file's already compressed, PK won't make the
>file any smaller, and will crash off, and inform the user that it can't
>compress the file.... leaving the file untouched.

Ah, but what if you first use a compression program which is not as
good as LZEXE or PKLITE. Try for example to compress a program with
EXEPACK - PKLITE is often able to compress them still further...
- -=-=-=

Your point well taken. Without checking the doc files, I'd be at a
loss to tell you at what point the software makes the choice of not
bothering with the file.

I was of the idea that LZEXE, at least would cough any EXEPACK file
up. before even attempting to compress it. Unsure on this point, and
about PKL's ability in this area. BTW, I understand Phil has another
version of PKL out... 1.16, I think.

On MY BBS's, I've taken the stance that I will not accept, as uploads,
files that have been treated with PKLite, LZEXE, or EXEpack... for a
couple reasons:

1: Such files, once treated with PKL, LZEXE, or PACK, are never as
small as files that have been treated by an archiver alone, such as
LZH, ARJ or even PKZIP. This reason alone would be enough, as far as
I'm concerned even as large as the systems are, disk space is at a
premium, as is user line tine.

2: I'm taking no chances of anything hiding inside such files.
Granted, I'm more or less convinced that the chances are pretty small
of something ever happning in this area.... a point which I've spoken
on here just recently. Just call it an instinctive move. I get
worried about things I can't check on, I guess.

Understand, I like the idea of using PKL or what have you, on files
that can use it... once the file in question has been checked for
virus contaminants, (Indeed, I use myself, after checking each file)
but I've taken a stand against distributing files treated with such as
PKL.

While in theory, the genre of compression tools such as the PKL, LZEXE
and PACK are great, and could serve well, in light of virus
considerations and in light of the added phoneline time involved in
transferring files treated with LZ, etc, I can't see accepting such
files.

------------------------------

Date: Mon, 22 Jul 91 22:14:00 +0000
>From: William Hugh Murray <[email protected]>
Subject: re: SECURE.COM (PC)

>There has been some discussion in comp.sys.novell about a new "virus"
>called SECURE.COM which opens up and damages netware binderies.
>No-one has seen it themselves yet, everyone has heard about it, so it
>may be another "urban legend". It is likely that if it does exist
>someone in this group will have heard of it, or be CERTAIN that it
>does not exist.

SECURE.COM exists. It is not a virus. Rather, it is a password guessing
program. It is not widespread and never will be. Nonetheless, it is an
example of a program that exploits weak system implementations. However,
it exploits implementation, not design, weakness. Properly used, the
security features implemented in NetWare are more than adequate.

Be certain that minimum password length is set to at least 5 (five) and that
"intrusion detection" is set "on." After that you can forget SECURE.COM.

Would God that there were such a simple defense for Jerusalem-B.

____________________________________________________________________
William Hugh Murray 203-966-4769
Information System Security 203-326-1833 (CELLULAR)
Consultant to Deloitte & Touche 203-761-3088
Wilton, Connecticut email: [email protected]
[email protected]
MCI-Mail: 315-8580
TELEX: 6503158580
FAX: 203-966-8612
Compu-Serve: 75126,1722
21 Locust Avenue, Suite 2D DASnet: [DCM1WM]WMURRAY
New Canaan, Connecticut 06840 PRODIGY: DXBM57A

------------------------------

Date: 22 Jul 91 23:19:28 +0000
>From: [email protected] (David Ivens)
Subject: Anti-Virus software recommendation sought

We are considering purchasing a site licence for Virus Buster from
Leprechaun Software.

It looks a very good package.

Any advice?

------------------------------

Date: 23 Jul 91 00:23:37 +0000
>From: [email protected] (Rajan Ramaswamy)
Subject: Info sources for PC viruses wanted. (PC)

greetings fellow hackers,

i would like to get some information about viruses for the
ibm-pc being the unix/c type myself, i don't know where to
start. ideally i would like the following information,
- -- a document describing principles used by known pc viruses
- -- source code to some viruses/worms, if available
- -- source code or description for writing a virus scanner
any language is probably ok.

thanks in advance,

rajan ramaswamy

------------------------------

Date: Mon, 22 Jul 91 19:31:36 -0700
>From: Steve Clancy <[email protected]>
Subject: Fprot & DOS5.0 (PC)

I recently received a reply from the user on our BBS who had the
original problem with FPROT and DOS5.0 Here it is.

Msg #: *3521 Security: 0 MAIN
From: ARTHUR MCCREARY Sent: 07-20-91 18:54
To: SYSOP Rcvd: 07-22-91 16:43
Re: COMMENT

Steve, I tried all the suggestions and the one that works is placing
the device driver f-driver.sys as the last entry in my config.sys.
Thanks to you and every one for their help. Arthur

- ---------------------------------------------------------------------

My thanks as well.

- -- Steve Clancy

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
% Steve Clancy, Biomedical Library % WELLSPRING RBBS %
% University of California, Irvine % 714-856-7996 300-2400 24hrs %
% P.O. Box 19556 % 714-856-5087 300-9600 24hrs %
% Irvine, CA 92713 U.S.A. % [email protected] %
% % [email protected] %
%.....................................................................%
% "As long as I'm alive, I figure I'm making a profit." %
% -- John Leas, 1973 %
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

------------------------------

Date: Mon, 22 Jul 91 21:02:00 -0600
>From: Peter Lenhart <[email protected]>
Subject: How do managers protect networks?

Hi,

I am writing a research paper on how to protect networks against virus
infection. I have some real good information already, but I would be
indebted to anyone who feels like they might offers some more ideas.
I would like to thank anyone in advance who might send me suggestions.
Feel free to post or to e-mail them to me. Thanks.

Peter

=============================================================================
Internet: [email protected]
=============================================================================

------------------------------

Date: Mon, 22 Jul 91 21:16:06 -0700
>From: [email protected]
Subject: Philosophy, comments & Re: long and technical (PC)

In a recent VIRUS-L posting, A. Padgett Peterson wrote:

> The simplest answer to the dilemma is to separate
> into two tasks:
>
> 1) Determine the BIOS entry points for interrupts needed to
> authenticate the system.
>
> 2) Authenticate the system.
> The easiest way to do this is to accomplish (1) during
> the BIOS load before DOS (or any other O/S) has had a chance
> to muddy the waters. Since at BIOS time, a PC is a fully
> functioning computer, it is posible to retrieve the pointers
> to essential elements (Interrupts 0-1Fh) and store these values
> in an accessable location, possibly encrypted.

One problem that may occur is that of BIOS-shadowing. We can no longer
assume that the BIOS is in ROM at the time that it is executed. Many
machines now copy it to faster RAM. It is possible that a virus might
intercept the BIOS call inside the BIOS itself rather than in the
interrupt table.

Relying on such an infection mechanism would limit the viability of
the virus in today's world, but as the 1M chip becomes more and more
standard, the percentage of machines that have BIOS modifiable during
execution will go up.

Fritz Schneider ([email protected])

------------------------------

Date: 23 Jul 91 08:33:12 +0000
>From: [email protected] ( Mr S. Rahim )
Subject: CARMEL TntVirus, A Trojan suspect. (PC)

I got hold of Carmel Antivirus package through a bulletin board. After
having installed it on the harddisk two weeks ago, I began to have
problems. This included EXE and COM files which were working before
Carmel came on the PC. Some files hang up while others refuse to run.

When TntVirus is activated, I performed a scan of the memory with
McAffee Scan V80, and it reported that P1 Related virus was active in
memory. Another file relating to the package when run, SCAN revealed
that Brain was active in memory.

The possibilities which arose with the indetification by Scan were
that either Carmel software was using signatures to be resident in
memory which were the same as those viruses. I tried to infect a COM
and EXE file but there was no increase in file size not the date of
modification. However during this process a directorying of the root
directory revealed that an AUTOEXEC.$$$ file had been created in the
past few minutes. I deleted that file but it appeared back again.

I am leaving this question open for discussion. Is this a work of a
trojan?

Sajid Rahim

- --
============================================================================
Internet: [email protected]
- ----------------------------------------------------------------------------

------------------------------

Date: Tue, 23 Jul 91 07:01:57 -0400
>From: [email protected]
Subject: New Devil's Dance?

Does anyone have any hard evidence about the message displayed upon an
attempted soft reboot when devil's dance is resident? I've been
experimenting here with a version that has a different message (and
seemingly different actions) than those I've read about elsewhere.
Most of the popular scanners seem to recognize it as Devil's Dance.
Thanks for any info you can provide...

Charles

------------------------------

Date: Tue, 23 Jul 91 13:07:00 +0000
>From: Sanford Sherizen <[email protected]>
Subject: Re: virus for sale

Thanks to Bill Murray for raising the issue of a virus for sale. This
is not a new situation. About two years ago, I found out that someone
was selling copies of the Pakistani Brain virus. I called him and
asked how I could get a copy. He said that it was only available to
sys ops and computer security people. He asked whether I was one or
the other and I told him that I was. After that vigorous
authentication check, I was told to send a certified check (no
personal checks allowed) for $50 and I would get "the virus, source
code, and antidote on a disk (NOT infected)". I decided to forgo the
opportunity.

I have been told that under U.S. law, sale of this and other viruses
appears to be legal. However, if the seller claims it is a virus and
it is only a harmless substitute, it can be considered as mail or wire
fraud and therefore a federal violation.

Next? "Shoppers, in aisle 3, there is a special on our generic virus."

Sandy

------------------------------

Date: Mon, 22 Jul 91 12:12:36 -0400
>From: [email protected] (Kyle Myers)
Subject: NSAi announces Computer Security Connection

National Security Associates, Inc. (NSAi) has brought the
Computer Security industry a long awaited tool " a worldwide network
with the world's largest and most current compilation of Computer
Security information. It is a powerful tool because it is current, it
spans all platforms and Security disciplines and it has a growing
wealth of information " all accessible with a local phone call and a
Keyword search!
The system, called the Computer Security Connection (CSC)), gives
access to: 20-25 news articles per week entered from 190+
publications; Law and computer crime; Virus information databases;
shareware; personalities and experts conducting Forums; a restricted
database of Hacker activities and "products"; Vendors of products and
services with E-mail connection; Incident reports; the "Rainbow
Series"; Back issues of ISPNews, Contingency Journal (more to come);
Events Calendar; Bibliography; Planning help for new configurations;
and more, all ReSearchable by Keyword queries!
Current and back issues of texts such as VIRUS-L (of course!),
Computer Underground Digest and CERT Alerts available on the Internet
are now included in CSC) " and on CSC) they are ReSearchable by
Keyword queries!
NSAi is a private company whose charter is to collect and
disseminate only Computer Security information " objectively " without
political ties, vendor pressure or bureaucracy. Its Board of Advisors
plays an active role in providing policy input and is made up of
representatives from: Johnson & Johnson, SRI International, ISSA, I-4,
Eastman Kodak, Boeing, Mellon Bank, MIS Training Institute, Bank of
America, as well as experts in Viruses, Cryptography and Privacy "
many of whom will conduct Forums on their respective expertise.
Special interest groups and organizations now have a medium to hold
conferences and meetings in their own "Conference Rooms" and have all
their input categorized and ReSearchable.
CSC) will invoice you for the $30.00 registration fee and
$12.50 per hour of access time.
To gain access to CSC send your name, title, organization,
address and phone number to mbrsvcs @ incomsec.org OR FAX this
contact information to 703-758-8338.

------------------------------

End of VIRUS-L Digest [Volume 4 Issue 129]
******************************************

Downloaded From P-80 International Information Systems 304-744-2253