Chapter Eight: Tips for Specific Systems

fred:j5P8TtXXrfbQo:406:101:owner:/home/fred:/bin/tcsh

Table 8.1: Excerpt from UNIX /etc/passwd password file

The fields in a UNIX password file are described below. Note that a blank space in the password field allows logging in without a password and a blank space in the shell field will prevent logging in on some systems. The password file is protected by a series of UNIX file permissions, which make it readable by everyone but writable only by the systems administrator. The systems administrator in UNIX is called "root" and has a userid of "0", but because UNIX uses numeric userid numbers any userid with the userid of "0" will automatically have root system privileges.

Table 8.2: Entries in the UNIX password file explained

Because of the possibility of a dictionary attack on the /etc/passwd file, many versions of UNIX support "password shadowing", where the real password is kept in another file which is not readable by normal users, e.g. /etc/shadow, and the password field in /etc/passwd is replaced by another symbol, e.g. "x". To access a shadow file there are a variety of tools available to the cracker floating around on the Internet, or the cracker just gets root privileges to read it.

If a cracker find a weird password file, which looks like this "+::0:0:::", then the system runs Network Information Service (NIS), and the password is stored on an NIS server. Getting the password file is then a simple matter of using ypcat to ask the NIS server for the password file, but note that NIS can give out the password file to anyone who queries it with a valid NIS domain name.

File Permissions

In UNIX, file permissions work by assigning three sets of three bits to each file. If a user does an "ls -l", they will get long directory output giving a list of the file attributes, owner, size and name of file. Here's an example of a file and directory.

Table 8.3: What all the fields given by a "ls -l" mean in UNIX

The permissions field reads like this when expanded. Each bit in each field allows either the user, a member of the group or anyone in the "world" to read, write or execute a file. So what about the "s" in the example above? What does that mean?

Table 8.4: The permissions field showing how bits map onto permissions

In UNIX, certain programs and services need to run at the highest possible privilege level to work, otherwise they won't run. In order to allow normal users to run programs that they would otherwise need to be root to run, there is a special bit, called the Set User ID (SUID) bit which will set the program to the correct userid before running. The holy grail of the UNIX cracker is the SUID shell, because if a cracker creates an SUID shell as a normal user it will set their user ID to be root when they run it, and give them control over the whole system. How did that SUID 0 shell get there? If anyone who has paid attention earlier in the book looks at the other files inside the directory, they might get a hint, because the SUID shell was created while testing stuff for this book.

Setting the permissions involves using the UNIX "chmod" command to change the bit settings on each of the three fields and, because each field is three bits, it is convenient to use the octal form to set and unset the permission bits of the file. The example below shows how the user bits are set using "chmod ", and where the octal-number ranges from 100-700, and the corresponding file permissions on the user field. Thinking in binary/octal helps to understand UNIX file permissions, so if a user wants to make their file world and group readable and allow themselves permission to edit it, they will use "chmod 644" to get permissions "-rw-r--r--".

Table 8.5: Example of file permissions in binary and octal format

Logfiles

Logfiles used for tracking logins are stored in a binary format, and cannot be written by a text editor, so crackers need to get hold of one of the many log editors floating around the Internet. These enable them to remove the entries that were placed into the logs when they cracked the remote system. The location of the logfiles vary - the table below lists their location for LINUX - but crackers need to find out where those logged are kept for other systems also. Note that btmp is not enabled on all systems. Although logging bad login attempts is good, it enables a possible DoS attack where repeated bad logins will cause the file to grow until it fills the file system.

Table 8.6: Important UNIX system logfiles

UNIX Tools

Here are a list of some of the tools that anyone might find useful when hacking, and securing UNIX systems. It is not an exhaustive list, but it covers most of the commonest types of tools used when working with UNIX. All of these tools are currently available on the Internet, and anyone who searches will find many more. If you are a systems admin and you find these tools in someone's "home" directory, then is time to call them in and have a little chat with them, and try and find out what they are doing with them.

Table 8.7: UNIX Tools

Windows NT is Microsoft's flagship product, coming in both workstation and server versions and designed for providing file, print and other remote services to small and large corporations. Windows NT can be found all over the Internet running Microsoft's web server Internet Information Server (IIS), MS-SQL and Exchange mail server. There have been a large number of hacks and security holes found both in NT, IIS and also web server extensions designed for use by Frontpage, so creating a secure NT site requires a goodly amount of work. Although NT doesn't support many of the services provided by UNIX, it relies heavily on RPC to run program code on the server and, when configured to use TCP/IP, can be scanned just like any TCP/IP host to find out what services are running.

Networking

NT supports TCP/IP and also supports IPX/SPX, but the core protocols for NT are the same as those used by Win3.1 and Win95, NETBIOS and NETBEUI. NETBIOS (Network Basic Input/Output System) was created by IBM as a method of linking network hardware with the network operating system, allowing client software to access other resources on the LAN. NETBIOS uses NETBIOS names to identify network resources on a LAN and clients advertise services by broadcasting their own NETBIOS information and the name of any services they offer on boot up. If any other host is already offering services with the same name, it broadcasts its own information indicating the name is in use, and the later client gives up. If no other host complains, then the NETBIOS name will be registered on the network. Each name can be up to 15 characters long, with a 1 byte suffix used by NT to identify NETBIOS services.

NETBIOS provides two forms of communication, the session-orientated connection which is a reliable connection with flow control and error connection, rather like TCP in TCP/IP, and it also provides an unreliable datagram service similar to UDP in TCP/IP. NETBEUI is the enhanced version of NETBIOS which extends the normal functions of NetBIOS and runs under the ETHERNET_802.2 frame type.

NT, Win95 and Win3.1 all use Server Message Blocks (SMB) to allow access to shared directories, the registry, shared printers and other services. SMB messages can be any one of four types. Session Control SMBs are used for network redirection, making it appear that services on host C are running on host A. File SMBs are used to read and write files and provide a network filing system for NT. Printer SMBs are used to control remote printers, place or remove print jobs in the printer queue, etc. Finally Message SMBs are used by the system or by programs to send or broadcast messages across the LAN.

Password Security

To understand where passwords and security information is kept in NT it is vital to understand the concept of the "registry". The registry is a single system database that stores settings and information about a computer in the same way that Win3.1 used INI files to store information. The main difference between the registry and INI files is that the registry is a hierarchical tree-like structure which is divided into five groups called "keys" and then further subdivided into groups called "hives". Here are the five primary keys in the registry, along with a description of the kind of information that is stored there.

Table 8.8: The NT registry contains five keys

The most important key, from the point of view of the hacker, is the HKEY_LOCAL_MACHINE key which contains five hives, of which the most important is SAM. The Security Accounts Manager (SAM) hive contains specific information about user and group access in the NT domains on the LAN. The security hive contains the security policy for the local machine, including specific user rights for that machine. To explore the registry, hackers and systems administrators use either of the two Microsoft supplied tools, REGEDIT.EXE and REGEDT32.EXE, which allow any user with sufficient permissions to add, delete or modify any values in the registry.

Getting at the passwords in the SAM registry hive isn't as simple as grabbing a UNIX passwd file, but the principle remains the same. Anyone with the correct permissions can dump hash codes from the NT registry - server operators, backup operators and power users can all view and dump the required files from the registry. Anyone with physical access to the machine can also get hold of the required files.

If the NT server in question is using NTFS, which is supposed to be safer than FAT32, then it is a simple matter to boot from a DOS floppy and mount the NTFS hard drive using a program called NTFSDOS (*doh*). A cracker without NTFSDOS will learn about how NT performs backups and repairs, and use backup programs which can read and restore the registry to the standard NT repair disk. Once a cracker has a copy of the SAM hive, then they need to get a list of the password hash files, using a copy of utilities like SAMDUMP and PWDUMP, or expanded from the compressed backup files created by RDISK. Now the cracker has the password hash files from the registry it's time for them to go and get a copy of NTCRACK, or l0phtCRACK, and run a dictionary attack against the password hash files. If a cracker wishes to run a brute force attack, then they might choose to attack Exchange server or IIS, as neither of these programs log failed logins, in common with many email and web daemon services.

Figure 19: The NT logon process

The NT logon process consists of nine steps involving several elements of the NT system before it allows access to the desktop, but it all starts with the userid and password given to the logon process.

1. The user presses CTRL-ALT-DELETE to wake up the system.
   
2. he user enters a userid and password.
   
3. The Security Authority runs the authentication package.
4. The authentication package checks the local user account database and, if it isn't there, forwards the request to a remote server.
5. Once the account is validated, SAM returns the user's security and group ID.
6. A logon session is created by the authentication package and passes both the logon session and the security IDs to the security subsystem.
7. If the security subsystem rejects the logon, the session is deleted, an error is flagged and a new logon process is started. If the logon is accepted, an access token is created containing the security IDs and returned to the logon process with a success flag.
8. The logon session then calls the Win32 subsystem to create a process and attach the access token to that process.
9. The Win32 subsystem will then start the desktop if an interactive session is required.

Table 8.9: The NT validation process

Windows NT is designed so that there are multiple authentication packages which can be used with NT, enabling replacement of the provided authentication package with something stronger if required. The biggest problem with Windows NT is the sheer number of lines of program code, as well as the number of interacting library routines, operating system routines and other authentication subsystems. Owing to this complexity, NT has attracted some of the finest hackers as they test NT authentication to the max. Despite this attention, NT vulnerabilities are patched or "hot-fixed" as soon as they are discovered, and the patches and hot-fixes rolled into the next service pack. Finding NT machines with exploitable vulnerabilities often means looking for machines where the service packs haven't been applied, or applied incorrectly, so that otherwise fixed security holes are still present.

File Permissions

Inside NT, files and directories are just objects, and an Access Control List (ACL), controls access to the object being accessed. Each user and group has a Security Identifier (SID), and when a user attempts to access an object the access is checked against a list of access-control entries inside the ACL. Here are a list of the flags controlling ACL for files and directories. They are pretty self explanatory, and a user can set them using the NT programs GRANT, REVOKE and SETOWNER to set or unset flags to modify the access control entries inside the ACL.

Table 8.10: NT file and directory permissions

Note that there are ways and means of bypassing the file system access control lists. For example, using NTFSDOS to mount an NTFS partition under DOS will allow a cracker to do more things because DOS has a smaller set of possible file permissions. Similarly, if a cracker uses SAMBA to provide access to SMB file systems under UNIX or LINUX, then they can do very many interesting things that directly access the NT file system, and completely bypass the ACL features of NTFS in doing so.

Logfiles

Each "special" file has a logfile associated with it. Sometimes these are just backups of the main file, so sam.log is a backup of the sam file. If a cracker is attempting a password attack, they grab SAM not SAM.LOG, and if they can't get those they can get the files from WINNT\repair. It is likely the passwords have changed since installation, but a cracker could still find a legitimate password, or even find that some systems systems could still have the default password on the GUEST account.

Table 8.11: Some common NT logfiles

NT Tools

There are fewer tools available for NT than there are for UNIX, but it is catching up fast. Here are some of the tools currently available on the Internet, but no doubt there are new tools being written even now. Anyone interested in NT security should read all the NT security FAQs, have a look at some of the tools listed here, and when they have finished with those they should try writing some of their own. As I said, NT is a huge amount of code, and there is no way they're getting all the bugs out of it Real Soon Now, so any systems administrator will be kept busy securing these systems. If you are a systems administrator who finds these tools in a users file space, then you might want to ask them the reason why.

Table 8.12: A few of the NT hacking and cracking tools available on the Internet

Novell Netware Network Operating System (NOS) can be found in business, schools and universities across the planet. The success of Novell was to offer simple PC file and print services at a time when PCs were just taking off. This was in the days before the public got wind of the Internet and TCP/IP protocols, so Novell cleaned up with their product at the time, creating a de-facto standard for large and small businesses alike.

Networking

Early Novell was not TCP/IP based, in fact only recently has Novell begun to support TCP/IP as a "native" networking format. Novell's protocol stack was based on the five-layer Open Data Link (ODI) model, rather than the four-layer model of TCP/IP. It was designed from the outset to support as many network devices as possible by dividing the Data Link Layer into two sublayers, the Multiple Link Interface Driver (MLID), and the Link Support Layer (LSL).

Figure 20: Novell's ODI model uses five layers instead of TCP/IP's four

By using the LSL, software writers are able to concentrate on passing packets up the stack to the LSL, which provides a consistent interface from which any other transport protocol can take packets. The lower levels of the stack do not need to know about which protocol gets which packet and the higher levels of the stack do not need to know about which MLID is carrying packets sent down from the stack, as it all takes place at the LSL level.

The most fundamental difference between Novell and TCP/IP is the choice of Ethernet frame type. Whereas TCP/IP uses a frame type called ETHERNET_II, Novell uses types called ETHERNET_802.2 in early versions of Netware, and ETHERNET_802.3 for later versions. If you are a systems administrator setting up a Novell client, or a network packer sniffer, you will need to find out which frame type the server is using before being able to connect or see any packets.

Figure 21: Comparison of ETHERNET_II and ETHERNET_802.3 frame types

Within these Ethernet framing types, Netware uses two protocols, Internet Packet eXchange (IPX), and Sequenced Packet eXchange (SPX). Note that the "Internet" part of IPX has nothing to do with the TCP/IP "internet", but refers to the more general concept of "internetworking". IPX is roughly equivalent to UDP in that it provides an unreliable, connectionless datagram service, meaning that any error correction must be done at a higher level of the ODI protocol stack.

Figure 22: IPX packet structure

SPX is roughly equivalent to TCP, in that it provides a connection-based service which is built on top of the unreliable, connectionless IPX protocol. The SPX protocol looks after establishing connections, flow control, error correction and closing connections.

Figure 23: SPX packet structure

Netware encapsulates data in a similar way to TCP/IP, with each layer adding or stripping headers from data passing up and down the ODI stack.

Figure 24: ODI stack used by Netware

Password Security

When a user logs in to a Netware server, the file LOGIN.EXE is transferred to the client computer and then run. Early versions of Netware would send the password across the LAN in cleartext format, but later versions encrypt the password before sending it, so any cracker needs to know what version of Netware is running before they attempt to "sniff" passwords from the LAN. When packet signatures are used to prevent abuse, there are three packet exchanges between client and server. The client starts by sending a request for a login key, and the server generates a random value and returns it to the client. The client then sends a request for the userid, looks up the userid in the bindery and sends it back to the client. The client then matches the userid to the entered password, sends the result to the server which checks that what the client has sent matches the userid and password from the bindery and grants access.

Early versions of Netware kept passwords as part of the "bindery", a system database used to store information about the network resources and users that is used by Netware programs. Each file server on a network system has its own bindery, and thus has its own database for users and network systems.

In early versions of Netware, the bindery was stored in files on the SYS: volume under the SYSTEM directory, and were called NET$OBJ.SYS, NET$PROP.SYS, and NET$VAL.SYS. These files need to be protected using the file access control flags, as they can read, passwords extracted as a 128 bit object from the bindery, and then turned back into plain text.

With the arrival of Novell's Network Directory Services (NDS), the bindery has been phased out. NDS is designed to make network administration easier by providing a distributed hierarchical database which can hold any object within the network, and allows for administering those objects from any location just by logging onto the NDS "tree". The NDS files are stored under the hidden directory SYS:_NETWARE and are called VALUE.NDS, BLOCK.NDS, and ENTRY.NDS.

The length of Netware passwords can be set by the supervisor to be up to 127 characters long, but typically get set to between 6-10 characters. The supervisor can control password ageing, forcing users to change their passwords every few weeks, and can also prevent users from reusing old passwords by requiring unique passwords. This stops users changing the password after the password expires and immediately changing the password back. The supervisor can also restrict logins by preventing users from logging in at certain times, force them to use certain computers to login, and prevent multiple logins from the same user. Finally, Netware provides an intruder detection and lockout feature which prevents repeated password guessing by freezing the account after a number of wrong guesses. This feature should not be applied to the supervisor or admin password, however, as making Netware lock out the systems administrator by a number of incorrect password attempts would be an easy, and effective, DoS attack on the Netware server.

File and Object Permissions

Netware uses a system of file permissions that is more complicated than the UNIX file system, but it is still simple to understand. A user who has rights over a file is called a "trustee", and trustee rights can be granted to anyone who owns a file. In addition to this, trustee rights can be assigned to files on the basis of group membership. Netware also has a system of "inherited rights masks", which can be applied to directories and acts as a filter to remove rights that a user would normally have higher up the directory tree. Rights to directories for all users are initially set by the supervisor or admin using one of the many admin tools, e.g. FILER, but ordinary users can change rights on their directories or files using GRANT to allow rights, and REVOKE to remove them. Here is a list of standard Netware file permissions.

Table 8.13: Netware file permissions

Netware Directory Services (NDS)

Recent versions of Netware that use the NDS treat a file as an object in the NDS tree so, apart from file rights deriving from the file system, every object in the NDS tree has similar possible rights. There are many objects in NDS, the idea being to provide an overall view of an organization's networking infrastructure with all possible objects within that infrastructure capable of being represented and administered.

Table 8.14: Type of NDS tree objects

The NDS tree contains "leaf" objects for servers, printers, users, filing systems, groups and more abstract objects, called "container objects", for grouping objects together as a single entity. All objects in the NDS can have trustee rights associated with them, and NDS has two types of rights, "object" rights to perform operations on the NDS tree structure itself, and the "property" rights to perform operations on the object in that tree.

Table 8.15: Netware NDS object rights

This can be useful in a large organization, where trustee rights can be assigned to administrators of servers and printers based locally, while retaining control of the NDS tree as whole and preventing trustees from one part of the NDS tree changing or damaging parts for which they are not directly responsible. Note that if anyone has admin rights to the whole of an NDS tree, it is entirely possible to create a user with the same rights over the NDS tree as the "real" admin and then turn off the "browse" right, and no-one, not even the "real" admin, will be able to see the admin equivalent user. This is useful for white hats who want to be able to have an admin backdoor in case of lost password or intruder lockout, but it is also useful for black-hats to install backdoors into the NDS tree to enable easy re-entry. Having learnt this technique, I often wonder how many otherwise secure Netware servers have hidden users in this way, and I would be interested to hear from any Netware administrators who can give an estimate of Netware servers that have been compromised, as well as ideas for spotting and combating this clever use of NDS permissions.

Table 8.16: Netware NDS property rights

Logfiles

Netware does extensive logging, so the admin needs to be aware of where the logs are kept. Most of the Netware logs are manipulated by special tools, e.g. AUDITCON, but some are in human readable format and can be edited, by anyone with the correct privileges. Once again, it is the supervisor or admin's job to check the logs occasionally, and also to set maximum sizes for the logs so they don't grow indefinitely and crash the system by filling up the SYS: volume. Storing files which can be of arbitrary s