1 / 52

UNIX Security

UNIX Security. These slides were prepared by Mr Campbell Wilson School of CSSE Campbell.Wilson@infotech.monash.edu.au. History . UNIX was never supposed to be secure. Security compromises convenience.

ellema
Download Presentation

UNIX Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. UNIX Security These slides were prepared by Mr Campbell WilsonSchool of CSSECampbell.Wilson@infotech.monash.edu.au

  2. History • UNIX was never supposed to be secure. • Security compromises convenience. • Originally, UNIX machines used only by researchers who often needed to modify the operating system itself.

  3. Security – Is it an issue? • Security in terms of not letting processes/users interfere with each other was always an issue in UNIX. • Security in terms of “preventing unauthorized access” is not always viewed as important (academic viewpoint vs commercial viewpoint?)

  4. Security – What are we protecting? “It makes no sense to put a bank vault door on a cardboard house protecting an orange” – Jerry Schiller, MIT Network Manager

  5. UNIX (and Windows) • Imagine a house with 100 doors. • Each door has a lock which is easyto break if you know how. • You may not even know where all the doors are. • The house is on a public street. • There are 100 doors so there is the flexibility to access the inside of the house from different places. • Would you store valuable information in this house?

  6. Legality • Unauthorized access to data stored on computer systems is considered a crime in many jurisdictions. • Most often the legal penalty would apply to the person or persons who gained the unauthorized access.

  7. The superuser • The account with UID 0 on a UNIX system. • Usually, the account name for this account is root. • The superuser can effectively do anything within the system. • Superuser password is the most valuable password in the system.

  8. Basic superuser account precautions • Observe all the normal password precautions. • Don’t share the superuser password outside the administrative group. • Restrict superuser logins to the console terminal (usually the default in UNIX). • Restrict use of the su command.

  9. File access controls • directory based • a file for each user on access objects • access control list based • a list for each user on access objects • access control matrix • capability • a unforgeable token/ticket for access certain objects • procedure-oriented (info. hiding)

  10. Basic file security -rw-rw-r-- 1 root sys 1344 Jul 2 22:57 /etc/vfstab Group Owner -rwxrwxrwx Owner permissions -rwxrwxrwx Group permissions -rwxrwxrwx Other permissions

  11. Basic file security • Important system files must have appropriate file permissions • e.g:-r--r--r-- 1 root other /etc/passwd-r-------- 1 root sys /etc/shadow-rw-r--r-- 1 root sys /etc/profile drwxr-xr-x 18 root sys /usr • A finer granularity of file permissions can be achieved with access control lists (ACLs), e.g. AIX, HP-UX. • NFS does not natively support ACLs.

  12. Integrity management • Is achieved by • prevention • detecting change

  13. Prevention • By placing controls – such as software, hardware, file system and operating system controls. • By having immutable and append-only files • immutable files are those that cannot be modified once the system is running (suitable for system programs such as login, passwd) and append-only files to which data can be appended, but in which the existing data cannot be changed(suitable for log files)

  14. Detection change • Comparison of files with a (good) backup copy. • the backup copy has to be in a protected mode. • comparison has to be performed byte-by-byte and hence time consuming process (especially for large files – such as database files) • once an authorised change is detected, replace the altered version with the comparison copy, thereby restoring the system to normal.

  15. Detection change • Checklists and metadata • Store only a summary of important characteristics of each file and directory and use this information for comparison. • e.g. of summary information – time stamps (last read/modified, file protection modes,link count using ncheck etc) • Running this kind of detection change as a cron job may not be a good idea!

  16. Detection change • Checksum and signatures • changes can be made in such a way that the checklists and metadata may not change and hence the previous method may fail. • e.g. setting the clock backwards, perform the changes and the set the clock forward • CRC checksums – useful only when there are few bits of change and they are generated by well known polynomials. • generate a signature using a one-way hash function (such as MD5).

  17. Tripwire • In practice one need not generate digital signature on the content of each of the file. • e.g. We need to know if the owner or protection of /etc/passwd file is changed, but we do not care about the size or checksum because we do expect the contents to changewhile we should be concerned if the contents of /bin/login is altered. • tripwire is a package that allows to configure the files, directories that need to be monitored using MD algorithms.ftp://coast.cs.purdue/edu/pub/COAST/Tripwire

  18. Auditing and Intrusion Detection • After establishing the protection mechanism, you need to monitor the system. • Monitoring is a process of auditing. • Audit trail is carried with the help of log files, however log files itself is vulnerable to security threats (after all they are also files in the system!)

  19. Location of log files • usually in /var/adm • The useful files are:acct or pact – records commands run by every useraculog – records of dial-out modemslastlog – logs each user’s most recent successful login time, and possibly last unsuccessful login toomessages – records output to the system’s console and other messages generated from the syslog facilitysulog – logs use of the su commandutmp – records each user current login (may be in /etc directory)wtmp– provides a permanent record of each time a user logged in and logged out. Also records system shutdowns and startupsvold.log– logs errors encountered with the use of external media, such as tapes, floppy drives, etc.xferlog– logs FTP access

  20. swatch – a log file tool • A perl program to monitor log files. • Available from ftp://sierra.standford.edu/swatch or ftp://coast.cs.purdue.edu/pub/tools/swatch

  21. Managing log files • Plan to backup log files • Review periodically the log files (may be daily or more often) • Apply filters so that you do not get bored seeing the log messages • Don’t trust logs completely!! – they can be altered or deleted by intruder • Plan to install software which can add security to the operating systems controls (such as tcp wrappers).

  22. SUID and SGID • When you execute a process in UNIX, the process does not run under your “real” user id = UID = the number in /etc/passwd • Processes run under your “effective” user id. • Normally, the EUID and UID are equal.

  23. passwd is SUID and SGID SUID and SGID • There are some situations where EUID and UID differ. • E.g. How does a user change their own password?-r--r--r-- 1 root other /etc/passwd -r-------- 1 root sys /etc/shadow-r-sr-sr-x 3 root sys /usr/bin/passwd

  24. SUID and SGID Security • Imagine this scenario:User A leaves their terminal logged in and unattended.User B comes to their terminal and types:$ cp /bin/sh /home/userb/sh.a$ chmod 4755 /home/userb/sh.a • What is the security issue here?

  25. SUID and SGID Security • SUID root programs are particularly vulnerable to attack. • If it is possible to subvert the program in some way, then root access can be gained. • A very well known method of such subversion is the buffer overflow. • Buffer overflow vulnerability results from bad coding practices on the part of the original programmer of the SUID root program!

  26. Buffer Overflow Hundreds of Buffer Overlflow vulnerabilities have been documented in various versions of UNIX Not restricted to UNIX, Windows and other operating systems can also be vulnerable.Writing a buffer overflow attack requires some knowledge of the stack architecture for the particular hardware (e.g. Intel stacks implemented in a different way from SPARC stacks) kill_sntsd.plThere is a remotely exploitable buffer overflow in the simple network time sync daemon present on RedHat 6.1. adredirasp.txtMicrosoft BackOffice component adredir.asp contains a buffer overflow. dmail27q.txtNetwin DSMTP Server v2.7q contains a remotely exploitable buffer overflow. kdesud.txtKDE kdesud present in Mandrake 7.02 (Air) has a buffer overflow allowing you to gain gid 0. innd222over.txtThe news server innd 2.2.2 has a remotely exploitable buffer overflow. cgatepro.txtCommuniGatePro 3.1 for Windows NT contains a buffer overflow. chkperm.txtSolaris 2.x chkperm contains a buffer overflow. winamp.txtNullsoft Winamp 2.10 contains a buffer overflow in its handling of playlist files allowing execution of arbitrary code. Exploit included. icqover.txtICQ Version 99b 1.1.1.1 contains a buffer overflow. qpop3.txtQpopper <= 3.0beta29 contains a buffer overflow that allows authenticated users to execute arbitrary. ex_sdtcm_convert.cSparc Solaris 7 sdtcm_convert buffer overflow exploit.freebsdover.txtBuffer overflows exist in fts, du, and find in FreeBSD 2.2.7/2.2.8. netwaretts.txtThere is a buffer overflow in the Transaction Tracking System (TTS) built into Novel Netware. ex_lpset.cExploit for buffer overflow in Solaris x86 lpset. ex_admintool.cExploit for buffer overflow in Solaris x86 admintool. ex_dtprintinfo.cExploit for buffer overflow in Solaris x86 dtprintinfo. netbuf.cExploit for TCP buffer overflow mbuf panic in FreeBSD-2.x and IRIX. smbval.txtThe SMB authentication library smbvalid.a contains many buffer overflows. iis4over.txtRetina vs. IIS4, Round 2 - IIS4 SP3 Option Pack 4 are vulnerable to remote buffer overflows. EXPLOIT INCLUDED.ftpd.txtRemote buffer overflows in various FTP servers leads to potential root compromise. (ProFTPD 1.2.0pre1 and Wuarchive ftpd (2.4.2-academ[BETA-18])). slmail3.1.txtSLMail 3.1 contains yet another buffer overflow. pine410.txtPine 4.10 contains a buffer overflow exploitable by remote users. wsftpserver.txtWS FTP Server Version 1.0.1.E/1.0.2.E contains buffer overflows. smashdu.txtDigital Unix 4.0x contains many buffer overflows since it now has an executable stack, where older version didn't. lpc.txtLinux /usr/bin/lpc version 4.0.3 contains a buffer overflow. (It ships with SuSE 5.2) win98explorer.txtMicrosoft Windows 98's explorer has a buffer overflow when handling long filenames. mailmax.txtMail-Max SMTP server for Windows 95/98/NT Remote Buffer Overflow Exploit tetrix.txtTetrix 1.13.16 has a buffer overflow in its hostname handling. automount.txtLinux 2.0.36+ automount allows normal user to gain root access via a kernel buffer overflow. klogd.txtLinux klogd 1.3-22 buffer overflow. sshkerb.txtSSH 1.2.26 contains a buffer overflow in its client kerberos code. nsover.txtNetscape x86 Linux buffer overflow exploit. zgvover.txtzgv 3.0 that ships with Redhat 5.1 contains a buffer overflow. bashover.txtExploit for the buffer overflow in bash's PS1 for Linux x86 systems. winproxy.txtWindows Proxy servers WinGate and StarTech contain buffer overflows. dslip203.txtDslip 2.03's allocslip which runs setuid has a buffer overflow. slmail3.txtSLMail 3.0.2421 contains a buffer overflow. smrex.cBuffer Overflow for Sunos 4.1 sendmail - execs /usr/etc/rpc.rexd. (See Phrack 53) csmproxy.txtCSM Proxy 4.1 contains a buffer overflow in its FTP service. eggdrop137.txtEggdrop the popular IRC bot contains many buffer overflows. mutt.txtThe e-mail reader Mutt 0.93 contains a buffer overflow in the Content-type field. netscapemail.txtThe Netscape 4.05 mail reader contains a buffer overflow when dealing with attachments. aim.txtBuffer overflow in AOL Instant Messenger. rsi-uucpd.txtBuffer overflow in the uucpd daemon when it records wtmp information. ufsrestore.cSparc Solaris 2.4, 2.5, 2.5.1, 2.6 ufsrestore buffer overflow. pinebug.txtPine 3.96 has a remotely exploitable buffer overflow. mailxploit.cExploit for a buffer overflow in the mailx present in Solaris 2.5.1, 2.6, Debian GNU/Linux, and Redhat Linux. qpop.cQualcomm Popper 2.2 and 2.4 (POP3 Server) buffer overflow. lynx28.txtLynx 2.8 built in mailer buffer overflow. dip3.3.7o-exp.cdip 3.3.7o buffer overflow exploit for Linux. msgchk.cExploit for the buffer overflow found in the suid msgchk of RedHat 5.0. kde.cKDE klock buffer overflow exploit using environment variables. ADMw0rm-v1.tgzRemote expoit for the buffer overflow present in some versions of bind. xosview.txtBuffer overflow in suid xosview which ships with RedHat 5.1. (Now includes exploit) namedsploit.cAnother named buffer overflow. This one works on many bind version for both FreeBSD and Linux. appleshareAppleShare IP Mail Server buffer overflow. sol26ufsSolaris 2.6 x86 buffer overflows in ufsdump and ufsrestore. kppp.txtThe kppp application that comes with KDE has a root exploitable buffer overflow. mdaemon.cThere is a buffer overflow in the MDaemon Windows 95/NT SMTP server. Vendor Patch (SP2) slmail26SLMail 2.6 and IMail 4.03 Buffer Overflow resulting in a DoS and more. war_ftpd.txtThere is buffer overflow in the Windows warftpd than cause it to crash. (Includes exploit) exchange5.txtMicrosoft Exchange Server v5 buffer overflow Vendor patch. sliplogin.cBuffer overflow in BSDI's sliplogin allowing root access. solaris-ping.cSparc Solaris 2.5 and 2.5.1 root exploit for ping (buffer overflow). imaps.tar.gzServeral different versions of the remote imapd buffer overflow exploit. evil-term.cThis is the remote buffer overflow termcap exploit for BSDI BSD/OS 2.1. sunos-ovf.tar.gzThis program is designed to test buffer overflows on SunOS 4.1.x boxes. mount-ex.cAll Linux versions are vulnerable to this buffer overflow attack on suid mount.

  27. Buffer Overflow – The problem void function(char *str) { char buffer[16]; strcpy(buffer,str); } void main(){ char string[256]; int i; for( i = 0; i < 255; i++) string[i] = 'A'; function(string); }

  28. Buffer Overflow void function(char *str) { char buffer[16]; strcpy(buffer,str); } void main(){ char string[256]; int i; for( i = 0; i < 255; i++) string[i] = 'A'; function(string); } string pushed onto stack

  29. Buffer Overflow void function(char *str) { char buffer[16]; strcpy(buffer,str); } void main(){ char string[256]; int i; for( i = 0; i < 255; i++) string[i] = 'A'; function(string); } return address pushed onto stack

  30. Buffer Overflow buffer[16] (local variable) pushed onto stack void function(char *str) { char buffer[16]; strcpy(buffer,str); } void main(){ char string[256]; int i; for( i = 0; i < 255; i++) string[i] = 'A'; function(string); }

  31. Buffer Overflow Segmentation Fault Segmentation Fault Segmentation Fault Segmentation Fault Segmentation Fault Segmentation Fault void function(char *str) { char buffer[16]; strcpy(buffer,str); } void main(){ char string[256]; int i; for( i = 0; i < 255; i++) string[i] = 'A'; function(string); }

  32. Buffer Overflow Attack • Instead of writing ‘A’ past the allocated local buffer and into the rest of the stack, write data into the stack such that: • The return address is replaced by an address which points to a bit of code written by the attacker (which can also be written onto the stack) • This code may, for example, spawn a shell. • If the original program was SUID root, this will be a root shell!

  33. Buffer Overflow Attack • If no patch is available from O/S vendor to fix the vulnerability, then at least remove SUID root permissions from the program in question.

  34. Trusted hosts • UNIX allows hosts to trust another. • If host A trusts host B, then a user who has the same user name on B and A can access resources on A from B without a password. • Implemented using .rhosts and /etc/hosts.equiv • rlogin, rsh, rcp

  35. Trusted hosts - advantages • Password cannot be sniffed because it is not transmitted. • Users can log in once and then subsequently move to any machine in the trusted network. • Convenience.

  36. Trusted hosts - disadvantages • If one host is compromised (e.g. boot B to single user mode then change to any user you like), then the other host is also compromised – read that user’s files on A. • Even if B cannot be booted to single user mode without a password, can physically replace B with another machine. • Trusted hosts uses IP address authentication. • Vulnerable to IP spoofing.

  37. NFS • Network File System • Developed by Sun Microsystems • Supported by most UNIX systems • Allows remote access to local file systems

  38. NFS example (Solaris) Host ANFS Server Network /files NFS calls NFS calls mount –t nfs A:/files /mnt/files Host B share -F nfs -o rw=B,root=B /files

  39. NFS Security Considerations • Export only to trusted hosts • Export only those parts of the filesystem which require remote access • Export read-only unless writing absolutely required • Be very careful mapping root on the server to root on the client. • Remove group write permissions for exported files and directories. • Be careful exporting user home directories

  40. NFS Security Considerations • Do not allow users to log into NFS server. • Do not accept incoming NFS call requests on non-privileged ports. • Use Secure NFS. • Don’t use NFS! (Is it absolutely necessary?)

  41. Threats to Availability • “Denial of Service” attacks • Probably more of a threat when carried out via the network than on the local machine alone. • Not UNIX specific

  42. TCP/IP Service Security • UNIX provides a wide range of services which can be used to provide network functionality. • These services are normally provided by programs (daemons) which are bound to a specific port. • Services either started by /etc/rc* scripts or when needed by inetd.

  43. TCP/IP Service Security • Ports < 1024 are privileged (trusted) ports. • A program must be euid root to send or receive on these ports. • UNIX specific – therefore should not be considered trusted on heterogeneous networks.

  44. Some Particular Services • ftp (TCP port 20, 21) • password send as clear text • If anonymous ftp is used, make sure it is set up properly to restrict access. • Be very careful allowing anonymous users to upload files – legal ramifications of storing suspect files.

  45. Some Particular Services • telnet (TCP port 23) • password send as clear text • session hijacking

  46. Some Particular Services • SMTP (TCP port 25) • Simple Mail Transfer Protocol • Usually a program called sendmail takes care of the delivery and reception of email. • sendmail is a very complex program. • The history of sendmail is a sad one in terms of security! • Current version is 8.12.0, it is particularly important with sendmail to keep up with bugfix releases. • Check configuration of sendmail very carefully or consider using a more basic mail program.

  47. An aside - email • Email is not a secure mode of communication. • Easily intercepted and read. • If you wanted to write a message to someone and you would be concerned if an intermediary read the message, you would not write it on the back of a postcard and send it through many post offices on its way to its destination. This is about the same level of security of email. • Encrypt the message if you don’t want anyone else to read it!

  48. Some Particular Services • finger (TCP port 79) • Gives out information about who is logged on and from where. • This information can be valuable to potential intruders. • Consider disabling finger.

  49. Some Particular Services • http (TCP port 80) • Hypertext transfer protocol • Security of web servers is another large topic in its own right. • Some broad issues (out of many) • Allowing listings of directories on the web server • CGI scripts • Encouraging users to send uuencoded passwords via forms which are easily sniffed and decoded

  50. Countering Intrusion • Detection: • Check log files regularly! • Use ps, w, netstat to watch activity on the system. • Use the sum command (or similar) to check for changes to important system binaries or other files, e.g: sum /bin/loginsum /bin/su • Note any unexpected events in the system (e.g. reboots, failed logins, su attempts etc)

More Related