Host Security

1
Host Security Basic Notions

• Applied Security

2
Host security measures

• Host-centric
• Tailored to host architecture
• Takes into account not only type of operating
  system but also configuration
• Comprehensive
• protect installed applications
• Complex, costly, protects single host

3
(No Transcript)
4
(No Transcript)
5
Secure host configuration

• Unix-like systems

6
Common Unix Configuration Weaknesses

• Password management issues
• weak passwords
• default passwords
• re-used passwords
• Exploitable services
• FTP/TFTP
• Sendmail
• other services

• Improper file and directory permissions
• Improper use of setuid
• Improper network file configuration
• Unpatched known vulnerabilities

7
Basic UNIX access control

• In Unix, there are three levels of access control
• Individual (user) Each user has a unique id
  (uid) in the system.
• Group All users by default belong to the user
  group (some distributions), or to a singleton
  group containing only that individual user.
• Users can belong to more than one group (most
  modern versions).
• Usually a group is defined for access control
  category. E.g
• root/wheel (general administration)
• www/web (web server administration)
• mail (mail server administration)
• adhoc groups can be used to facilitate
  collaboration such as directory and file sharing
• World (or all) The universe of all users.

8
File permissions

• File ownership Each file and directory in UNIX
  (including programs) is owned by a specific
  user, a specific group, and the world.
• To each level of ownership there is an associated
  set of permission values read, write and
  execute. These values can be true (permission
  granted) or false. Only the owner of a file (or
  the special user root) can change the file
  permission settings.Example
• drwxr-xr-x 11 brenodem brenodem 374 30 Aug
  1339 .
• Indicates that the file . (the current
  directory) is owned by user brenodem, who belongs
  to the singleton group brenodem. The directory
  was last modified on Aug. 30th at 1339. The
  user brenodem is granted read, write, and execute
  privileges to the file. The group and world are
  granted read and execute (but not write)
  privileges to the files.

9
Meaning of file permissions

• The meaning of permissions for files is clear,
  but can be complex for directories.
• For instance, if a world-accessible file is
  located deep within a directory structure, all
  the parent directories of the file must grant
  execute permissions to the whole world.
• This is because, in order to traverse a directory
  structure, UNIX executes cd on each directory
  (starting from the lowest common directory, for
  instance /home ). On the other hand, it is NOT
  necessary that the same directories be
  world-readable.
• If a directory is not readable by a principal,
  its contents cannot be listed. However, it may
  well contain files that are readable by that
  principal, and these can be opened if their name
  are known.

10
Proper file and directory permissions

• Any UNIX system contains several directories that
  are world executable, where most of the OS
  services reside
• /bin (commands)
• /etc (configuration files for the above)
• /usr (utilities and applications)
• /usr/local or /local (extra utilities and
  applications)
• These directories are not required to be world
  readable, only their content files need to be
  world readable. If the directories are not world
  readable (and owned by root) then only the system
  administrator will be able to have a global view
  of the system configuration and capabilities.
• These directories should be writable only by root
  to prevent the installation of programs without
  the administrators knowledge. In particular
  they must be owned by root.

11
Changing ownership and permissions

• The root user can change ownership and
  permissions on files at will.
• chown username filename
• In some distributions, a user may change
  ownership of its own files to other users.
• To change group ownership of a file, you must own
  the file and you must belong to the new group the
  file will be assigned to
• chgrp groupname filename
• To change permissions, you must be the files
  owner
• chmod ogau-rwx filename
• example chmod ogwx filename adds permissions to
  write and execute the file to both the file owner
  and file group owner.

12
Effective ID

• When a user tries to execute a program
• The UNIX system decides whether the user is
  authorized to execute (for instance, the user may
  belong the the file group owner, and the file may
  be executable by the group).
• When the program is initiated, its effective ID
  is set to the ID of the user (or program) calling
  it.
• For instance, if a utility program is owned by
  root (typical), but called by a regular user, the
  effective id of the running program will equal
  that of the caller (user), not root.
• This standard mechanism is not sufficient in some
  cases. For instance, the login program.

13
SUID

• The login program is invoked by regular users,
  but must have root privileges in order to access
  the protected password files (/etc/shadow), and
  to authenticate the user. (Effectively spawning a
  program under a particular user name even if
  called by another.)
• This is called a set user id program (suid).
  
• -r-sr-xr-x 1 root wheel 26756 16 Aug 1032
  /usr/bin/login
• Note the s in the list of privileges. That
  means that the caller (could be anybody, as the
  file is world executable) will spawn a program
  with the privileges of the group wheel (which can
  access the password file, and spawn programs
  (shell) under arbitrary user identities.)

14
Proper configuration of file permissions

• The system of file access permissions underscores
  most of the access control decisions of the UNIX
  operating system.
• It is a flexible mechanism that enables different
  configurations to accommodate different usage
  needs.
• Improper configuration of file and directory
  permissions can create serious vulnerabilities.
• The use of SUID programs is a powerful mechanism
  that should be utilized only when necessary. For
  instance, a fragile program with SUID permissions
  can be easily exploited to grant administrative
  privileges to an attacker.

15
RPC Utilities

• Most Unix systems include the RPC utilities suite
  for remote command execution
• rlogin (remote login)
• rsh (remote shell)
• rcp (remote copy)
• Two modes of authentication host-based and
  password-based

• RPCs originating at a trusted host (i.e., a host
  listed in /etc/hosts or /etc/hosts.allow or
  /etc/hosts.equiv), identified by network packet
  source address, are accepted and given uid equal
  to the claimed username.

• RPCs called from non-trusted computers must
  provide both username and password. (Both sent as
  cleartext over the network.)

16
Disabling RPC utilities

• The use of RPC utilities has been deprecated in
  favor of the ssh and scp programs, both built
  onto the SSH protocol, which provides encryption.
• For backward compatibility the SSH program
  supports host-based authentication. (This is
  stronger than in the RPC case, as hosts have SSH
  keys with which they can mutually authenticate
  their identities.)
• It is important to ensure that the configuration
  of the /etc/hosts files reflects the trust
  policies of your network, and that the RPC
  utilities are disabled whenever possible.

17
The UNIX password system

• Past and present

18
Early Unix Password System

• In early versions of Unix, the password was
  processed using a secure hash function derived
  from the DES cipher.
• The salt was restricted to 12 bits, resulting in
  4096 possible hash values for each password.
• Passwords were restricted to 8-character length.

• 8-character passwords converted into 56-bit DES
  keys
• Password shorter than 8 characters long padded w/
  zeros.
• Longer passwords truncated in some systems.
• Salt used to change the DES cipher, which is
  applied 25 times.
• Results stored in world readable /etc/passwd file

19
Unix crypt()
20
DES IP and FP stand for initial and final
permutations, respectively. F Round function E
Expansion function 32?48 bits, is changed on
crypt3() using the salt.
21
Old /etc/passwd file

• An entry in the /etc/passwd file has the
  following form
• NamePasswordUserIDPrincipleGroupGecos
  HomeDirectoryShell
• smithEp6mckrOLChF.100100John
  Smith/home/smith/usr/bin/sh
• guest2000/home/guest/usr/bin/sh
• An entry for password means that the account
  has been disabled, while an empty password means
  that password is not required for login!
• When shadow passwords are used, ! or x
  substitutes for the password.

22
New /etc/passwd file

• nobody-2-2Unprivileged User//usr/bin/false
• root00System Administrator/var/root/bin/sh
• daemon11System Services/var/root/usr/bin/fa
  lse
• smmsp2525Sendmail User/private/etc/mail/usr
  /bin/false
• lp2626Printing Services/var/spool/cups/usr/
  bin/false
• sshd7575sshd Privilege separation/var/empty
  /usr/bin/false
• qtss7676QuickTime Streaming
  Server/var/empty/usr/bin/false

23
/etc/shadow file

• Entries of the form
• smithjEp6mckrOLChF.101930999995
• Where the password is followed by
• The date when the password was last changed,
  measured in elapsed days since Jan. 1st, 1970.
• The number of days before the password can be
  changed again
• The number of days after which the password must
  be changed
• The number of days to warn user of an expiring
  password
• The number of days after password expires that
  account is disabled
• The number of days since January 1, 1970 that an
  account has been disabled
• A reserved field for possible future use

24
Other changes

• Since the introduction of shadow passwords, and
  the new crypt(), other modifications have been
  introduced, such as the use of MD5 passwords, and
  also Blowfish-encrypted passwords.
• Blowfish is an interesting choice The algorithm
  is very slow to change keys, making hashing
  password expensive (good for security).

25
Reading assignment for 01/16

• Use of a Taxonomy of Security Faults, by T.
  Aslam, I. Krsul, and E. H. Spafford
• M. Bishop and D. Klein, Improving System Security
  Through Proactive Password Checking,Computers and
  Security 14(3) pp. 233-249 (May/June
  1995)http//nob.cs.ucdavis.edu/bishop/papers/199
  5-cs/proact.pdf