Security Widgets on the SIG Tapes I. "Safe Hex" * Know your sources! > Sig tapes have known contributors AND central points of contact to report suspicious behavior. > DECUS library answers the phone too! > Ditto many national repositories. > A BBS you use REGULARLY and read messages on is far safer than one you use rarely. * Check other information sources. Internet mail/news, DECUServe, DCS, etc. may have covert behavior reports. * Check out code as well as you can yourself before using. > Examine source code > "STRINGS" and similar searches of executables > Bear Systems' "SMON" utility or the like if available. > Turn on VMS code to show what files are opened (see internet message areas on sig tapes). Turn on alarms and find out what files an image opens...perferably on an isolated microvax. * REPORT YOUR FINDINGS! Let others know of anything odd you see OR SUSPECT! (DECUS phone number: 508 480 3418. My office phone: 215 354 7610.) Put it on usenet/internet! II. Widgets (on the SIG tapes unless otherwise mentioned): Your colleagues have provided numerous security related programs. A. Auditing Tools: * Password checkers: [vax89a2.nieland.checkpass] Joe Meadows' GUESSIT (F89) * Meadows' UAF report tool (much finer grain than Authorize) * BRWSR/QNDXR - use to do more intelligent searches of logs of all sorts. Easy, lightning fast. (Another utility, written to find concordances, also has usefulness in this way.) * CRC tool ('88): compute CRC of files. A bit harder to fake than checksum, and MUCH harder to fake both a checksum and CRC. * Utilities to do checksums of collections of files and report changed ones exist on the tapes. They are preset to look in sys$system and sys$manager at critical files, and at others. Idea is to allow changes to be detected in any sensitive files. B. Hole Avoiders: * Privilege on demand utility (that LOGS its usage) * BECOME * Tools to record/reset hashed passwords * Watchdog, Gollum, Autolog and the like - idle terminal process killers * Terminal lock programs * Finger (i.e., instead of TELL or the like) C. "KGB" Tools * P, Observ, Watch, Force - watch other terminals and/or force input onto them (even from a batch file in the case of Force). > Side effect: Use with PHOTO to record sessions at the cost of extra processes. > Side effect: Use with BOSS (also) to allow monitoring without giving up terminal. (BOSS is a wonderful way to turn any terminal into a quasi-workstation!) * PHOTO - record sessions. Install in sylogin for network logins, untrusted accounts, etc. WATCH can observe the pseudo terminal EVEN THOUGH it can't watch the RTAn: devices, so you gain ability to do instant as well as delayed monitoring. * Ethernet monitors: Ethermon looks like one of the most capable. Several have appeared, allow recording of selected Ethernet traffic. (VERY CPU intensive!) (I've suggested an ethernet-encrypting software driver to steal Ethernet driver entries and encrypt DECnet traffic as a workaround for some of this vulnerability. Needs work though; the "Shortcut" decnet interface causes difficulty.) * SDA hacks (DEC component of VMS) allow one to look inside people's terminal input buffers. * Bruce Ellis' utility to show what files a process has open. (Show dev/files/nosys useful at times also.) D. "Do It Yourself, Handyman Special" Tools: Examples of kernel code are available on many tapes. * Special kernel ASTs in another process (to do stuff like resetting another process' prompt for example, or examining another process' default directory). * Breaking into various data pathways within VMS. * How to steal driver entry points and live. * Example user written debuggers. (SMON is implemented as a user debugger; allows tracking system services an image uses. Also allows one to lie to an image about what a service returns. Sys services are just VMS procedures, can be faked in any language.) * How to make any image debuggable or nondebuggable without relink. * Example drivers and ACPs. Other useful network tools exist for things like a distributed user name/address/phone book, remote show sys, etc. etc. These reduce temptation to just allow remote executed command files to be done over DECnet. E. Cryptographic Tools * DES utilities and other file encrypt/decrypt packages. Wide circulation; crypters have appeared on VAX and RSX SIG tapes since the late 1970s. * Cryptodisks. > First cryptodisk I know of was on the Fall 1978 RSX SIG tape. Worked under RSX11D or IAS; I wrote it. Used XOR or a DES-"like" algorithm. User hooks could let the driver reject I/O on basis of username, terminal, program trying to do I/O, date/time, or other criteria. The DES type algorithm was almost uselessly slow but strong. > VE: driver for RSX11M/M+ had a "lock VE:" feature and encrypted homeblock. Until recently RSX needed an ACP to handle driver encryption. > FDDRV on S89 and F89 VAX SIG tapes is a VMS driver that has a cryptodisk "host" (uses a process to do all I/O, so also is a remote disk, a file disk, a memory disk, and more.) Uses XOR algorithm with VERY long key or can plug in your own. No special "builtin" locks, but the host process can be added to easily to filter access. (Note: Bear Systems' driver has many extra filter options including one to mousetrap illegal access.) > Protects data against access even by privileged users (esp. after hours!). Vulnerable to KGB tools, but only while data in use. > Note the advantages of DEVICE ACLs on all sorts of virt. disks. F. Tools I'd Like To See: Problem: Ethernet monitors (esp. on PCs) can watch all traffic, including passwords etc., usually with vendor supplied software. * Software driver to encrypt Ethernet traffic. > Steal Ethernet driver entries. When anything tries to send a packet, if protocol and dest fields are in "to be crypted" list, encrypt the data before passing it on. On receipt, decrypt whatever's in "to be crypted" list of protocols/hosts. > Could be used for DECnet or LAT or whatever. > Use FAST, simple algorithm; designed to slow down PC based ether monitors, not NSA. (MOVTC instr.?) > Refined schemes could change keys often since this would be transparent to everything above. Problem: Allowing world read files and default access is too broad. Sharing files across a company SHOULD be possible without necessarily exposing them to every potential outsider on your net. * Identifier propagators across DECnet. Propagate some identifiers like FOREIGN, NONEMPLOYEE, TWIT that RESTRICT file access. > Can do with mods to FAL.COM plus some images that get identifiers out of current kernel space and stuff into current process' space. > Must have list of "trusted" nodes so that "untrusted" nodes get all the IDs. > Allows ACLs to modify "world" access so that files can be more readily shared with people you WANT to share them with. III. Final observation: If I wanted to write a Trojan program and if I had a way to distribute it anonymously, I'd build a VMSINSTALlable package. The installed code would be totally harmless, and the VMSINSTAL procedure would do all the dirty work. We need a way to see what VMSINSTAL will do to our systems before letting it rip. Meanwhile, programs like STRINGS, SEARCH, and BRWSR, and typing / printing the files are our only way to tell ahead of time what may happen.