System Security Capabilities and Uses (Some Things To Look Out For) Glenn C. Everhart (Everhart@star.enet.DEC.Com, Everhart@GCE.Com) Digital Equipment Corp. System SecurityCapabilities and Uses Securing A System Facets: Authentication (being sure a user is who he says he is) Access Control (What the user may do) Audit (Record keeping in case "something happens") ...all in accordance with a policy and security model. (Dominant security model is military.) Authentication: OpenVMS, UNIX, WNT all use passwords for local system. Networks pose a threat; knowing your user over a large area is vulnerable to many problems. - 2 - System SecurityCapabilities and Uses Threat: (a short list of general types) Wiretaps (including ethernet "hardware assisted tap") (also Tempest types, for completeness) Untrustworthy hosts Untrustworthy protocols Untrustworthy programs Wiretaps: Ethernet packet grabbers are the most common wiretap class threat. Countermeasures: TDR (to find unauthorized taps) routers (keep traffic off wires where it isn't needed) Use of FDDI (which has no promiscuous mode) Specialty boxes like DESNC - 3 - System SecurityCapabilities and Uses Untrustworthy hosts: Any host with a dishonest person who can control it. C spoof addresses or protocols. Many attacks on IP exist routing level. DECnet host names can be forged: Countermeasures: For DECnet, node SEND and RECEIVE passwords for each node (and default access NONE; set access for each machine.) Kerberos or similar authentication suites NOTE HOWEVER that published TCP attacks exist which threaten even Kerberos traffic if someone in the middle can sniff the net between two point trying to use it. - 4 - System SecurityCapabilities and Uses Untrustworthy protocols: Many common protocols like NIS (YP), NFS, have holes which permit anyone who can access them to gain access. The X windows protocols can be particularly vulnerable (depending on transport and authentication options.) Freely available programs can connect to an server and ask it to report keyboard events. ANY acces the node (if tcp/ip) means all key strokes can be read (passwords...). X has no built in security; OS is expe do it. Note again that TCP/IP reports only source mach DECnet reports machine and user, a bit better. It has reported that NetBEUI allows NO security control under - 5 - System SecurityCapabilities and Uses Know Your System Limitations. Remember that NT, OpenVMS, UNIX are only C2 certified standalone systems; NOT on a net. Many protocol pro have been reported (e.g. no security in MS Access, at one time, NT Netware implementation doesn't ask for pa for nonexistent accts). Systems that have been around longer have fewer proble (For some details on MS OSs, http://www.c2.org/hackmso among other sites.) Microsoft is working on a crypto b authentication hierarchy system. Also, various other s protocols exist for authentication, file sharing, etc. the ones below are most commonly used. A little detail on some of these. - 6 - System SecurityCapabilities and Uses NFS (Network File System) NFS is "the" filesharing method in UNIX. Used also in OpenVMS Vulnerability #1: NFS checks its authorization to move data only at open, and do not check the integrity of the transfer. Anyone who ca trick TCP/IP into routing through them (or who can sen data fast enough on a LAN) can corrupt files. This has been used to insert Trojan horses in critical files, corrupting even critical Kerberos code. Note that DECnet FAL transfers have an end to end CRC which pr this, and DECnet+ has an option to do end-end checksum on everything. NFS authentication is usually via UNIX style" IDs which requir all systems to have the same ID (number) to name mappi - 7 - System SecurityCapabilities and Uses (from a recent vmsnet.networks.tcp-ip.multinet article:) Access to files via NFS is via UNIX-style UID/GID. An NFS clie learn the UID/GID that a user is supposed to use by (1 local file which contains username (such as passwd on or the NFS configuration information on (e.g.,) a Mult client), or (2) by sending a username/password to a PC server, which authenticates the username/password and with the UID/GID. Now, if someone with lots of time on their hands (a student, l say their NFS client enough, they'll eventually find s of causing NFS to emit any UID/GID they wish. Exact me are left as an exercise for the reader. The "solution" setup mount restrictions, so only "trusted" NFS c cert mountpoints (directory trees). Countermeasures: Cryptographic authentication options and systems, to handle authentication. Securing data really requires encrypti any part of the data travels over untrusted wires. Eth are very frequently not trustworthy. Some protocols have optional authentication which is not widel Try AFS (or DCE/DFS), which were designed for much stronger security. NIS (See D. Hess, D. Stafford, U. Pooch, Texas A&M NIS (formerly Yellow Pages) is a protocol that propagates user ID to number mappings (and others) around a net and do authentication. NIS is based on RPC (Remote Procedure Call. RPC authenticatio defaults to none. It may use "UNIX" authentication or (which encrypts timestamps). - 8 - System SecurityCapabilities and Uses NIS config files are world readable, since NIS doesn't alter the maps. Client security can be very poor. Any machine on the net can pretend to be the NIS server (easy if UDP is used for transport, as is usually done). The NIS server need only beat the real one to the draw and claim anyone is a legitimate, privileged user on anoth With the "R" utils this can get any access a client allows to user (for example). The client can't find out. Since EVERYTHING tends to use NIS, this means all authenticat gets broken. Even breaks DES (since the server is wher keys come from). Countermeasures: Kerberos is stronger. - 9 - System SecurityCapabilities and Uses DNS (Domain Name System) Many TCP/IP programs use authentication by name, not I address. The DNS does this mapping. It's distributed. The problem is that one can fake being a DNS server, a cache is used to store DNS names. Current algorithms can be lied to, and one DNS response can "piggyback" e extra info so the IP to name AND the name to IP maps c be corrupted at one time in the local DNS cache. This name based authentication can be compromised, and any "distributed trust" authenticated only in this way can defeated. Defences: No generic defenses exist. If the DNS code would prefe authoritative cache data over non-authoritative, and caches didn't replace old data with any new data, the attack would be harder. Crypto DNS systems may help. Someday. - 10 - System SecurityCapabilities and Uses Note also that attacks on most IP protocols exist and been reported years ago. Some just haven't gotten into wild yet. The recent spate of SYN attacks, mailbots, cancelbots, etc. is the tip of the iceberg. Be very careful what you trust off your machine. Again this is TCP/IP specific. DECnet, for example, has othe issues with people faking nodenames, and you fight tha by ALWAYS using link passwords for access (and set def access to none). This sort of attack is most common in TCP/IP in part b of its ubiquity and wide source availability. - 11 - System SecurityCapabilities and Uses Untrustworthy programs: This refers to programs with covert behavior, particul "Trojan horse" apps that do secret things whe ar run with privs. Countermeasures: KNOW YOUR SOURCES !!! This is not a panacea for all se problems, but makes vandalism much less likely. Someth like Internet Explorer, for example, is very complex a has been reported to have bugs able to disclose anythi its machine, though this was doubtless not the authors Run in a nonprivileged environment, and use tools like SET WATCH (shows file accesses tried), FTS (on VAX) to what system services are used (and fake $setpr optiona or system service intercept by Brian Schenkenberger (s sigtapes) which is suitable for $setprv, $gettim, and intercepts fo selected processes. Watch for $getjpi, $ calls to set privs, or ask why $gettim may be called. hard cases, DISM32 or similar tools can be used to rec MACRO-32 if on VAX. ($Getjpi priv read or $gettim bomb Try to arrange never to run untrusted code under a priv'd process. An access ACE and an audit listener mailbox c can be built to attempt to enforce this. (A pre-activa checker is better still.) Authentication of scripts for tampering is a good idea if you can do it. In OpenVMS, Network-1 has a tool. Run a checker periodically to look for tampered with code. W stop access, but will tell you about it before you're for long. Polycenter has one. UNIX tools at CERT help Limit what unknown programs can do. The subsystem facility of OpenVMS can limit a program's access if se - 12 - System SecurityCapabilities and Uses right. A 3rd party product can further limit access by privs, time, image, user, location, and "trustworthine rating" and prevent accidental privilege grants and ch file corruption. With such a system in place, files protected cannot be accessed by Trojan code, since the Trojan code cannot be given privs to do damage. Know the capabilities of your system. - 13 - System SecurityCapabilities and Uses User Authentication: The key to system access is to have an identity the system knows. * Passwords when interactive. (Challenges, secure channels...) USE the "evasion" features in your system if you have them. USE password policy model and checkers to be sure passwords are strong. Pick good pass-phrases; do not force frequent change (becomes algorithmic or is written down). * Some distributed trust mechanisms exist. Examples: * DECnet proxies, "R" utilities EXTREME care in proxy access with privs Use FAL$LOG=1/disable=8 (DECnet IV) * "R" utilities (trusted users or hosts) EXTREME care in this for anyone who can become superuser, system, or administrator (UNIX, OpenVMS, - 14 - System SecurityCapabilities and Uses * Routing information (network firewalls). Several CERT advisories about this. Some documented IP attacks still exist that have not yet been seen in the wild. Trust hosts sparingly. * Most systems assume programs run under a user's name are to be treated as agents of that user. For the most part OpenVMS, UNIX, and NT check user access, not user/program. Extended checking software features can be helpful with the most critical data. The "military model" is inadequate for control of "insiders" and does not encode "need to know". Only username is generally used, but location, program used, priv level, time, and various other info exists, could be used to specify what's allowed. * Automatically downloaded software (Java, ActiveX, etc.) needs an extended definition of security. The OpenVMS "subsystem" facility begins to address this. (The 3rd party "Safety" tool "paranoid mode" goes further.) MANY holes have been reported in Java (see Dean, Felto Wallach, Princeton Univ. CS dept. 1996). The issue is an automatically downloaded app cannot sensibly be cal "agents" of the user running a web browser. To provide security, ActiveX attempts to ensure that the sender's identity is known. This (if do-able) makes virii less likely, but does not mean that a program might not be to copy or alter data on a machine. Thus the ActiveX s helps the common "PC" problem but not the commercial security major issues. From the Java FAQ: Q: Won't digital signatures solve all the problems? A: No, they'll only help a little. Digital signatures let you - 15 - System SecurityCapabilities and Uses who wrote an applet, but they don't decide if you can the author. Nor do they help you decide how secure the author's work is ag things like information theft using it. (Recall the IE holes in a complex package may allow misuse even from best known sources.) - 16 - System SecurityCapabilities and Uses Java holes in implementation have been reported. However, deep problems exist, among them: * There is no formal security policy for Java. * There is no logging of security events in Java. * There is no trusted computing base. * There is no single line of defense, but security fun are spread all over the code. * The bytecode verifier is impossible to check for sec * Java is a language and a security barrier. The polic for these two objectives are not the same. * At least a few covert channels exist which can be us send information or subvert the Java security system. It seems likely that a rework of Java would be needed to provi a secure technology. Javascript is also vulnerable. The stronger the underlying OS's abilities to guard your data, you are using tools like Java or ActiveX, if those too used. OpenVMS can be set up more robustly than most. - 17 - System SecurityCapabilities and Uses The most common security threat: "Social Engineering" (i.e., plain old deception of humans) is a serious threat. (Watch someone type a password, or get a password changed over the phone or print & mail a document...) Some forms of these threats can be helped where clerks are duped, IF the clerks are themselves limited in how they can get information. Education and auditing are needed too. Responses To Threats: * Educate your users. * Idle account reuse Clean out all residues of accounts (includimg ACEs) promptly. NT user ID is never reused. (DISUSERing an acct can be better sometimes detect attempts at reuse.) * Spoofing or untrustworthiness of something on another machine. Authenticators can be added for some of access, to ensure you're dealing with the user and machine you think. The better ones encrypt their traff They can also be use permit safe access by category to you need to share internally but not all over. Firewal internally can be very helpful if community topology a * Weak default protections Run checkers like COPS or any of several on the sigtapes for OpenVMS, or the Polycenter too, to test. (The WNT security FAQ is on the OpenVMS/LT sigtape Volume protections to isolate classes of users work like mandatory controls. If someone cannot access the volume, they can't get any file on it. Virtual disks help here. On OpenVMS you can - 18 - System SecurityCapabilities and Uses use volume ACLs to isolate volumes from, say, network access. If information is private, use a cryptodisk, and for safety keep the key value locked in a safe. (You might get run ove by a truck, after all.) - 19 - System SecurityCapabilities and Uses Access Control: Access control means the facilities the system uses to control who gets what access to what objects. OpenVMS, UNIX, and WNT all rely on a user name which becomes a magic cookie. * In UNIX and WNT, a user can belong to many groups (sometimes limited to a fixed maximum number like 8 or Access to objects can be as the user, or as a group me * OpenVMS allows a user to hold many rights identifiers (as many a desired). Access can be as the user or as a hol an identifier. * Both OpenVMS and WNT have notions of privileges which bypass security checks; details are different and some WNT privileges are relevant to certain utilities only. UNI a single privilege, "Superuser" for all functions. Ope UNIX have notions of specially-trusted applications (i with privilege or with suid/sgid privilege). (OpenVMS "install with identifier" notion, the subsystem facili File Access: * File access in OpenVMS and UNIX can be specified with a "UIC" shorthand (descended from pdp10 Monitor conventi giving a user or group number. OpenVMS and some modern UNIX versions also support ACLs. * WNT has no "UIC" heritage but inherits the MSDOS file protection scheme in addition to its ACLs. This overri ACL protections if present. * OpenVMS allows files in a directory to have a default ACL - 20 - System SecurityCapabilities and Uses copied to files as they are created. WNT allows defaul in parent directories as well as a default user ACL. O does not have a default per-user ACL. File ACLs in WNT be inherited from parent directory OR user default. * WNT allows some limited "SYSTEM" ACL entries to exist for limited purposes (i.e., audit). OpenVMS has the no protected ACE which may also be hidden. These OpenVMS are fully general, not only for auditing. - 21 - System SecurityCapabilities and Uses * Major difference: OpenVMS stores security information with the file (in the header, actually). WNT stores it sepa in a "registry". OpenVMS approach means the security information comes "along for the ride" during file access. Thus access is fast. When trying to remove a user, removing all ACLs that mention that user can be a chore. (Tools on the SIG tapes exi WNT approach makes management easier. Cache can attempt to reduce overhead of lookup of security information. Where a file has no security information, its ancestors are examined. Thus only one ACL might cover a large part of a volume, many directory levels deep. * Access controls: UNIX: Read, Write, Execute, SUID, SGID OpenVMS: Read, Write, Execute, Delete, Control WNT: Read, Write, Execute, Delete, Control, TakeOwners, Read-A - 22 - System SecurityCapabilities and Uses * Impersonation services exist in both systems, for use by trusted servers. Capabilities are generally similar * Correct setup rules of thumb, OpenVMS OR WNT: Back up data often enough and GUARD the BACKUPS Protect what is important most carefully Be sure default accesses correspond to policy Important Differences of Detail between OpenVMS and WNT * Registry vs. security info with object * ACLs only, with inheritance and user defaults, vs. ACLs and * Details of ACLs and privileges differ * WNT default if no ACLs are present is completely open * WNT also defaults to a "guest" account requiring no prior authentication at all. - 23 - System SecurityCapabilities and Uses Audit * OpenVMS and WNT have facilities for audit of security related events. * OpenVMS facilities are well developed * Problem of audit is volume of data. * Several products exist to use the "listener mailbox" of OpenVMS Audit to report suspicious actions in c to real time. * Audit can tell when the horse leaves the barn and what is going on. This is only useful for some threats * Pattern matching in console input watchers can also respond to snooping for info around the system. * A "security patrol" is worth having if you can. Keep audit trails, offsite if possible. Keeping audits on write-once configurations worth thinking about. - 24 - System SecurityCapabilities and Uses Conclusion: * Know and control your user population and its permissions * Avoid untrusted protocols * Check your security against local policy with tools, commerc or free * "Walk the beat" to look for strange things * Set up access permissions, especially on critical data, to allow only what is needed for people to do their jobs * Consider resetting default permissions if they are too loose for your policy. - 25 - System SecurityCapabilities and Uses - 26 -