Newsgroups: bit.listserv.edi-l
Date:         Tue, 25 Aug 1992 16:04:58 -0700
From:         Bill Laidley <WLAIDLEY@BCSC02.BITNET>
Subject:      Viruses, worms, wildlife & EDI

 I was recently asked to explore viruses, worms, etc. and how they might affect
 EDI. This note is a summarization of my findings. By way of warning - this is
 not pleasant reading.

 Table of contents:

    1. Summary
    2. Definitions
    3. The EDI environment
    4. Network exposures
    5. EDI Transaction exposures
    6. A worst case scenario


 Section 1: Summary
 -------------------------------------------------------------------------------
 1. The best protection for worms appears to be using a VAN (which runs on a
 different computer platform and operating system than either of the trading
 partners) as an intermediary.

 2. Since mini and m/f operating systems have security built in they are less
 vulnerable to viruses, but they also tend to be direct connected to networks,
 so they are more vulnerable to worms. PC's are very vulnerable to viruses, and
 are by far the most common platform for EDI. PC users tend to be less careful
 with their systems.

 Bombs and trap doors are not covered in this paper, as they are only a concern
 when they have been placed in your software by the developers.

 3. The new 841 X12 transaction has the potential to provide a means for
 viruses to behave more like worms- actively moving from machine to machine.
 The 841 transaction is not in common use yet, and we need to think about the
 implications before it becomes common. Using a VAN (point 1) will not prevent
 the spread of these new viruses.

 Data sent via other EDI transactions is generally in printable character form-
 only the element and segment delimiters may be non-printable. This restriction
 makes it hard to carry or hide binary data in the bulk of EDI transactions,
 although not impossible.



 Section 2: Definitions
 -------------------------------------------------------------------------------
 The following definitions have been adapted from the book 'Computer Security
 Basics' published by O'Reilly & Associates, Inc.

 A VIRUS is a code fragment that attaches itself to an executable program, thus
 modifying the program. It is only active when the program it is attached to
 runs . They reproduce by infecting other programs. A virus might start
 reproducing immediately, or it may lie dormant for some time, until it's
 triggered by a particular event. Viruses are usually destructive once
 triggered. They are possible on all computers, but they are most common on
 personal computers where the operating system does not have the security
 functions built in to prevent them from reproducing. They rely on users to
 move the infected programs from computer to computer as a means of spreading.

 A WORM is an independent executable program. It reproduces by copying itself
 from computer to computer, over a network. Worms usually do not destroy data,
 however they can use large amounts of network resources as they spread. The
 Internet worm is a good example. Worms are possible on all computers, but are
 most 'effective' on multi- tasking/multi-user systems where they run
 constantly in the background, or use the operating system to invoke them on a
 regular basis. They use known gaps in opera ting system security to move from
 computer to computer.

 A TROJAN HORSE is a code fragment that hides inside a program and performs a
 disguised function. It is a popular technique for hiding a virus or worm.

 A BOMB is a type of trojan horse used to release a virus, a worm, or some
 othersystem attack. It's either an independent program or a piece of code
 that's been plante d by a system developer or a programmer. A bomb works by
 triggering some kind of unauthorized action when a particular date, time, or
 condition occurs.

 A TRAP DOOR (also known as a BACK DOOR) is a mechanism that is built into a
 system by its designer. The function of a trap door is to give the designer a
 way to sneak back into the system, circumventing normal system protection.
 Unlike a logic bomb, which explodes in someone else's system, a trap door
 gives the original designer a secret route into the software.

 Bombs and trap doors are not covered in this paper, as they are only a concern
 when they have been placed in your software by the developers.



 Section 3: The EDI environment
 -------------------------------------------------------------------------------
 EDI software runs in three environments- PC's, minicomputers and mainframes.
 The following numbers are very approximate and have been calculated by me from
 information supplied as part of the EDI Group's Principles of EDI course (the
 information was supplied to the EDI Group by software vendors as part of a
 survey). The numbers serve mostly to provide a sense of proportion of the
 operating environments where EDI is used.

    DOS PC EDI installations: 18,000 87%

    Minicomputer EDI installations: 2,500 12%

    Mainframe EDI installations: 250 1%

 Since minicomputer and mainframe operating systems have security built-in they
 are less vulnerable to viruses. They also tend to be direct connected to
 networks, so they are more vulnerable to worms.

 PC's are very vulnerable to viruses, and are by far the most common platform
 for EDI. Generally PC users tend to be less careful with their systems, i.e.
 making regular back- ups and screening for viruses frequently.



 Section 4: Network exposures
 -------------------------------------------------------------------------------
 The worm must be able to run on both the sending and receiving systems for
 active propagation. While this is possible on direct connects with similar
 machines (mini to mini), it is less likely with dissimilar machines (PC to
 mini). I'm not aware that there are any machines which run dissimilar
 operating systems which are binary compatible. Itis possible for a common
 interpreted language to run on multiple platforms. REXX is a prime example-
 the core of REXX will run under VM, MVS, OS/400, Unix, OS/2, MS-D OS, and
 whatever they call the operating system for an Amiga (however REXX is not a
 part of the operating system in the Unix, MS-DOS and Amiga environments so
 itmay not be available). The input/output component of REXX is implementation
 and operating system specific, so it's a little less threatening. The best
 protection for worms appears to be using a VAN (which runs on a different
 computer platform and operating system than either of the trading partners) as
 an intermediary. Worms do not tend to run on PC's although it is technically
 possible, particularly in a LAN environment.

 Even where the network is connecting dissimilar hosts you could have a form of
 'passive' propagation- the virus or worm rides the EDI message. Since the
 virus would not know where it was going or the kind of host at the
 destination, it would be hit or miss as a means of propagation (which is
 standard for all worms). For this technique to work the virus would have to
 understand EDI syntax. If, for example, it overwrote the ISA segment the
 transaction would likely be rejected by the VAN because it would not be able
 to identify the destination. The new 841 EDI transaction has the potential to
 be an ideal vehicle for viruses and worms to move to new machines.



 Section 5: EDI transaction exposures
 -------------------------------------------------------------------------------
 The new EDI transaction 'Specifications/technical information' (841 - in
 version 030020 of the X12 standard) has the potential to be a vehicle for
 transmitting viruses and worms.

 Quoting from the X12 standard:

 "This transaction set can be used to transmit specifications or technical
 information between trading partners. It can be used to allow EDI trading
 partners the ability to exchange a complete or partial technical description
 of a product, process, service, etc. over the same path as any other EDI
 transaction. The detail area can includ e graphic, text, parametric, tabular,
 image, spectral, or audio data. A transmission includes identification
 information to assist the receiver in interpreting and utilizing the
 information included in the transaction.

 Further action as a consequence of the receipt and initial processing of the
 specification or other technical data may or may not require human
 intervention. The transmission and receipt of data may require private
 agreement between trading partners to automate the receipt of the data."


 The 841 is intended to allow trading partners to exchange CAD drawings, CNC
 programs for machinery, etc. These files are binary data, not character data
 and are sent in the BIN (binary data) segment. The size of the binary file
 data is in the BIN01 element, the actual file data is in the BIN02. The BIN02
 has a maximum length of 999,999,999,999,999 bytes. The other key segment in
 the 841 transaction is the EFI (electronic format identification). This
 segment provides various types of information, the most important being the
 file name (EFI11) which is up to 64 characters long. This allows adequate
 space to specify drive and path information with the file name, which may
 cause problems. In the PC environment an example would be 'C:\DOS', which is
 typically where the PC operating system utilities reside on disk. It also
 applies to any computer platform where there are common standards (official or
 otherwise) for the location of specific files.

 The standard does not define how the EDI translator will handle the binary
 file data. There are two approaches- a manual process or an automated process.
 With the manual process the receiving trading partner must look at the
 information received with the binary data, which would be in a holding file,
 and decide what to do with it - to receive it using the filename supplied, to
 rename it, to reject the transaction entirely, or possibly to have the EDI
 translator call a virus scanning program to test the binary file data. If the
 process is automatic, the translator will receive the data, extract the
 filename and use that name to store the binary data.

 The danger in the automatic process is that a virus could be developed that
 uses EDI to propagate itself via the 841 transaction. The information required
 to send an 841 to all of your trading partners is available in several forms
 in most EDI software (for example - in the trading partner profiles, or direct
 from existing X12 formatted transactions in your logs), so the virus could
 prepare a batch of 841 transactions that would be sent with your business
 transactions when you next connect to the VAN or to your trading partner
 direct. The new 841 X12 transaction has the potential to provide a means for
 viruses to behave more like worms- actively moving from machine to machine.
 Because a virus using these techniques would require a knowledge of where to
 look for the trading partner information, plus where and how to store the 841
 transactions created it seems likely that the virus would have to be
 customized for each EDI translator. This means that the software with the
 large install bases are the most probable targets.

 The 841 transaction is not in common use yet, and EDI users need to think
 about the implications of viruses before usage becomes common.

 Data sent via other EDI transactions is in printable character form- only the
 element and segment delimiters may be non-printable characters. This
 restriction makes it hard to carry or hide binary data in the EDI
 transactions, although not impossible.



 Section 6: A worst case scenario
 -------------------------------------------------------------------------------
 The scenario I'm about to describe will, with luck, never occur. It is
 possible though.

 Someone with a technical knowledge of EDI develops a grudge against a large
 company which uses EDI, and is the hub in a large number of EDI trading
 relation ships. The company could use any of the possible EDI environments,
 although I suspect that they would likely be using a minicomputer or mainframe
 to allow integration to their applications (just in time inventory, MRP II,
 accounts payable...). Most of the trading partners are smaller firms, which
 use PC's for EDI. No efforts have been made to restrict the types of
 transactions that are sent, or the source of the transactions. The person with
 a grudge uses 'The Little Black Book of Viruses' to develop the virus (this
 book exists- and is available in bookstores today). The person would then send
 it to all of the trading partners, or just a few. By developing the virus so
 that it propagates for 1 to 2 months first it would spread to many companies
 using PC's for EDI before triggering. Once triggered it would wipe the hard
 drive on the PC that is used for EDI. The end result- the hub company could
 send EDI transactions, but none of its trading partners would be able to
 receive, so they would not be shipping goods as fast as they could with EDI.
 The hub company's production would drop drastically until all of the trading
 partners were restored. The cost of the lost business would easily run to the
 millions.

 Regards, Bill Laidley
 EDI Expert Team
 BC Systems Corp. Vancouver (604) 660-9705
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU