Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Berkeley Software Distribution wikipedia , lookup
Process management (computing) wikipedia , lookup
Plan 9 from Bell Labs wikipedia , lookup
Spring (operating system) wikipedia , lookup
Distributed operating system wikipedia , lookup
Copland (operating system) wikipedia , lookup
Mobile operating system wikipedia , lookup
GOOD PRACTICE GUIDE GENERAL ADVICE ON SECURING OPERATING SYSTEMS JULY 2007 Abstract This paper provides a technical overview of general operating system security. It also provides guidance on what practical steps can be taken to improve the security of an organisation’s operating systems, regardless of which particular product and version they have chosen to run. Disclaimer Reference to any specific commercial product, process or service by trade name, trademark, manufacturer, or otherwise, does not constitute or imply its endorsement, recommendation, or favouring by CPNI. The views and opinions of authors expressed within this document shall not be used for advertising or product endorsement purposes. To the fullest extent permitted by law, CPNI accepts no liability for any loss or damage (whether direct, indirect or consequential and including, but not limited to, loss of profits or anticipated profits, loss of data, business or goodwill) incurred by any person and howsoever caused arising from or connected with any error or omission in this document or from any person acting, omitting to act or refraining from acting upon, or otherwise using, the information contained in this document or its references. You should make your own judgement as regards use of this document and seek independent professional advice on your particular circumstances. General Advice on Securing Operating Systems CONTENTS 1 Key points ............................................................................................................................. 3 2 Operating system components .......................................................................................... 4 3 4 5 2 2.1 Kernel ....................................................................................................................... 4 2.2 Interface to firmware .................................................................................................. 4 2.3 Input/output .............................................................................................................. 5 2.4 Memory and disk protection ...................................................................................... 5 2.5 User interface ............................................................................................................ 5 Common attack vectors and countermeasures ............................................................... 5 3.1 Network attack .......................................................................................................... 6 3.2 Local attack .............................................................................................................. 8 3.3 Authentication ......................................................................................................... 11 3.4 Viruses .................................................................................................................... 12 3.5 Access control ........................................................................................................ 13 3.6 Auditing ................................................................................................................... 17 Sources of further guidance ............................................................................................. 20 4.1 Security lockdown guides ........................................................................................ 20 4.2 Security tools .......................................................................................................... 20 References .......................................................................................................................... 21 General Advice on Securing Operating Systems 1 Key points • This document is a guide which provides advice on improving operating system security. The advice in this document is generic and can be applied to both open and closed source operating systems. • The guide is aimed at technical and non-technical members of IT Security teams. • This guide is not a substitute for a detailed lockdown guide for a particular operating system. Instead it looks at generic security trends across operating systems and provides general advice on improving the security standards. • The document contains: o o o • Operating system security is a very important part of an organisation’s overall IT security approach. Regardless of which operating system is used, certain steps should be followed to ensure a minimum level of protection, as described in this paper: o o o o o o 3 An introductory section which defines the term “operating system” (OS) and describes the principal components of an OS. A section covering the key attack vectors relevant to operating systems, and suggested countermeasures to mitigate attacks carried out via these vectors. A section listing of sources of further advice. All operating systems should have their network services reviewed and any services that are not required should be disabled. Any services that are required should have the latest security patches applied in accordance with an organisational patching policy. Access to the services should be limited to the minimum number of remote users wherever possible. The same steps should be applied to all programs and processes that run locally on a machine. Any applications that are not required to be running on the operating system should be disabled. Then the latest security patches should be applied to the remaining applications and the underlying operating system. A lockdown guide, specific to the operating system being used should be obtained and followed. While it may not be necessary to implement all of the lockdown guides recommendations, for usability reasons, they should be followed as closely as possible. Consider further strengthening operating system security through the use of third party products such as anti-virus solutions and personal firewalls. A strong authentication policy should be put in place on the machine. This should be effective at preventing unauthorised users attempting to log onto the system. This should be supported by an audit program that will detect any such unauthorised access or attempted access. General Advice on Securing Operating Systems 2 Operating system components Wikipedia [1] defines an operating system as: “a computer program that manages the hardware and software resources of a computer. At the foundation of all system software, an operating system performs basic tasks such as controlling and allocating memory, prioritising system requests, controlling input and output devices, facilitating networking, and managing files. It also may provide a graphical user interface for higher level functions. It forms a platform for other software”. Historically, operating systems, like many other aspects of computer science, were not designed with security in mind. However, as the industry has moved on and attacks against operating systems have become more widespread, vendors have become increasingly aware of the importance of operating system security. To understand the various attacks and countermeasures presented in the next section, it is first necessary to provide a high level overview of the components that make up an operating system. 2.1 Kernel The kernel is the central and most important component in an operating system. It provides the interface via which the computer’s hardware (e.g. memory, processors and input/output devices) are controlled and accessed. “The most important program in the [OS] is called the kernel. It is loaded into [memory] when the system boots and contains many critical procedures that are needed for the system to operate. The other programs are less crucial utilities; they can provide a wide variety of interactive experiences for the user — as well as doing all the jobs the user bought the computer for — but the essential shape and capabilities of the system are determined by the kernel”. [2] The kernel is also responsible for scheduling and multi-tasking. It determines which processes should be run and with which priority. From a security perspective, this is the most crucial component of an operating system as it is the interface to all system resources. If an attacker can convince the kernel to run their code with the highest level of privilege then they will have full control over the entire computer system. 2.2 Interface to firmware The term “firmware” refers to computer programs embedded in hardware, usually read-only memory (ROM) or other forms of non-volatile memory. It provides the means by which hardware devices such as disk drives, memory, sound cards and video cards can be controlled. The OS function known as “interface to firmware”, or “device management”, is the means by which data is fed to (and from) the firmware on the computer’s various hardware devices. The 4 General Advice on Securing Operating Systems operating system must be able to ensure that all of these device can interact with one another. It is important that from a security perspective that hardware and firmware do not perform functions which could compromise system resources. 2.3 Input/output Closely linked to the interface to firmware function is the requirement for the operating system to interpret input and output from user I/O devices such as the keyboard and mouse. These take input from the user and convert it into data which the operating system interprets. The operating system then takes this data and outputs the results to another device such as the computer monitor or a printer. From a security perspective, allowing users to interact with the operating system increases the likelihood that the operating system will receive unexpected input or process it in an incorrect manner. Similarly, allowing users to attach their own I/O devices to the computer system (e.g. USB keys) provides a further channel for attackers to communicate with the operating system. The risks of an uncontrolled user I/O policy are examined in detail later in this guide. 2.4 Memory and disk protection Every operating system has functions that determine how memory is allocated to the various applications and operating system functions that run on the system. From a security perspective it vitally necessary for operating systems to have some form of built-in memory protection: “Memory protection is a system that prevents one process from corrupting the memory of another process running on the same computer at the same time”. [1] Many attacks, such as buffer overflow attacks, are designed to bypass this protection. The attacker may attempt to get a vulnerable piece of software to execute their exploit code with its own level of privilege. 2.5 User interface It is through the user interface that the operating system actually interacts with the user. Almost all operating systems now use graphical user interfaces (GUIs). These typically run different applications in different windows, where each windowed application is a separate process and may have different privileges with regard to the underlying operating system (although this may not be immediately apparent to the user). 3 Common attack vectors and countermeasures The threats to an OS are varied and depend on both the environment that the operating system is running in and the role that the operating system is used for. For example, if the operating system is installed on a stand-alone workstation that is never connected to a network, then it is not at risk from network attack. By contrast, the OS might be hosting an Internet facing web server, which would greatly increase the risk of the server coming under remote attack. 5 General Advice on Securing Operating Systems This paper will now look at some of the common attacks that operating systems have to face and will then present countermeasures that can mitigate against these attacks. It is for the reader to determine (via a risk assessment) whether the attack vectors discussed are applicable and the extent to which countermeasures need to be implemented. Risk managers also need to consider the balance between security and usability, since security measures such as locking down system services may also have an impact on functionality. 3.1 Network attack 3.1.1 Network attack vectors Network attacks can be sub-divided into two distinct categories, namely attacks exploiting TCP/IP stack vulnerabilities and those that exploit operating system and application network services. Figure 1 - Network attack categories The first category of attack, exploiting the TCP/IP stack, concerns the implementation of the operating system’s networking components. As a typical example, the so-called ‘ping of death’ attack involves a malicious user sending a malformed ping packet to the target computer, causing the computer to crash. Many operating systems, including Solaris, Windows and Linux, were vulnerable to this attack before subsequent versions of the software corrected the vulnerability. More modern denial of service (DoS) attacks include SYN attacks (so called because they involve one or more attackers sending repeated SYN packets to the target machine, but never completing a full TCP connection). However, these attacks have a relatively low impact on the operating system unless the operating system is running a high visibility service, such as a big corporate website. Attacks in the second category, relating to vulnerabilities in operating system or application network services, tend to be more serious and have a higher impact. Most operating systems offer, by default, a large number of services over the network to other users. Even servers that have undergone some basic hardening usually need to have several services running, often for maintenance purposes. The first step a remote attacker needs to take is to establish exactly what services are running on the target operating system. This is accomplished through the use of a tool called a port scanner. The attacker can then attempt to run exploit code against any service that they believe to be vulnerable. 6 General Advice on Securing Operating Systems The exploit code may perform any number of tasks. However, the attacker is initially likely to mount an attack that will grant him administrator level privileges (‘root’ under UNIX or ‘system’ under Windows), and hence allow the attacker to execute arbitrary code. Attack class Typical vulnerability classes Attack or outcome TCP/IP stack vulnerabilities • faulty implementation/design of TCP/IP stack • “ping of death” • SYN flooding • other denial of service attacks OS and application network services • buffer overflow • faulty logic • no authentication service • faulty access control • specific application vulnerability classes (e.g. SQL injection for www service) • privilege escalation • custom code execution • access to additional systems Figure 2 - Summary of network attacks 3.1.2 Network attack countermeasures The first and most basic countermeasure against OS and application network attacks is to minimise the services that are running. The more services are available, and hence ports that are open, the more likely it is that the attacker will find a port that is vulnerable to a remote attack. The solution therefore is to disable all services running on the operating system that there is not a business requirement for keeping open. More modern operating system tend to have fewer services available by default than older versions. Some come with a built-in software firewall, which provides further defences (as will be discussed later). Security administrators can run port scanners themselves to identify which ports are open and then make informed decisions as to whether the services are necessary for the day to day running of the business. When all unnecessary services have been disabled, the second step is to ensure that the remaining services are as well protected as possible from attack. This is achieved by applying security patches, in accordance with an organisational patch management strategy. It is important to remember that while some of the services will be patched when the operating system itself is patched, other applications may need patches that are only available direct from the manufacturer. These third party applications should be patched to the same level as the operating system, because if these applications are exploited then the whole operating system may be exploited. For more detailed guidance on patch management, see the Good Practice Guide on this subject [3]. 7 General Advice on Securing Operating Systems The third and final step that can be taken to reduce the risk to the operating system from remote attack is to use a firewall. Traditionally, a firewall is a separate network device that segments off the network connections between network devices. The installation, configuration and positioning of firewalls is outside the scope of this guide, and requires a high level of computer security experience. In recent years, however, so called “personal firewalls” have become available. A personal firewall is a software program that runs on the operating system and filters the network ports so that ports which are not required by the business are not accessible to remote users. Personal firewalls have their limitations, and indeed some have been found to contain vulnerabilities themselves. Even so they add another layer of defence that can be introduced to the operating system to mitigate the risk of remote attack. 3.2 Local attack Operating systems need to not only be secured from remote attack, but also from local attack. According to the CSI/FBI Computer Crime and Security Survey [4], 75% of companies cited employees as a likely source of hacking attacks. It is also important to note that there is far more operating system exploit code for local attacks than for remote, as local attacks are not reliant on services being exposed to the network. The best way of limiting the risks posed by local users is to follow a lockdown guide for the operating system that is being used. These guides will be tailored to the specific operating system and will detail exactly how to lock down the system to limit local attacks and prevent such attacks occurring. These guides are the best resource for securing an operating system, and this document is not intended to be used as a substitute. Instead, it provides an overview of the types of attacks that are applicable to all operating systems, and the countermeasures to deal with them. 3.2.1 Local attack vectors There are three distinct attack vectors available to users with local access to the machine, as illustrated in Figure 3. Figure 3 - Local attack categories 8 General Advice on Securing Operating Systems These attack classes are explored in more detail in the following table: Attack class Typical vulnerability classes Attack or Outcome OS attacks • buffer overflow • faulty logic • unnecessary privileges • poor configuration • security by obscurity • authentication service exposed • privilege escalation • custom code execution • installation of spyware • interception of confidential information • brute force attacks on credentials Application attacks • buffer overflow • faulty logic • poor configuration • privilege escalation • “phishing” attacks Physical attacks • running custom code and vulnerability exploit code • capturing keystrokes • installation of spyware • access to confidential HDD information • access to password files. • access to internal HDD • ability to attach external devices (e.g. USB keys, physical key sniffer). • ability to alter system configuration (e.g. BIOS access). Figure 4 - Summary of local attacks Firstly, we will examine the risks of attacks against the operating system itself. Local users who wish to attack or misuse an operating system usually have a considerable advantage over remote attackers, in that they already have a legitimate user account on the target machine. The number of attacks that these users can perform is also greatly influenced by the privileges that they have on the underlying operating system. Users with administrative privileges can perform serious damage to an operating system, intentionally or otherwise. Users with low-level privileges present a lower a level of risk, although it should be noted that many legacy operating systems provide all users with high levels of privilege by default. Finally, even users with low levels of privilege may be able to install ‘spyware’ software on the machine, allowing them to intercept the credentials of other users and hence escalate their privileges. Because there are considerably more local exploits than remote exploits known in the public domain, if a local user is able to load exploit code onto the operating system it is highly likely that they will be able to run this code in order to exploit operating system vulnerabilities and hence raise their privileges. This risk extends to local applications that run on the operating system. An OS may grant an application a high level of privilege for business reasons. If a malicious user can use 9 General Advice on Securing Operating Systems one application (“application A”) to call another application (“application B”, for example a command shell), then it is possible that application B might be given the privileges of application A rather than the user (whose privileges may not be as high). Finally, there is the threat posed by physical attacks. Having physical access to a machine can aid an attacker considerably. With access to local I/O devices such as the CDROM and USB ports, an attacker can upload their own software or even boot their own operating system (from within which they have access to the machine’s underlying file system). 3.2.2 Local attack countermeasures If the operating system is to be deployed and used by a large number of users then a lockdown guide should be obtained and system specific countermeasures should be put in place. The lockdown should limit the amount of access that users have over the operating system, by ensuring that features which could be powerful if misused are curtailed for all users bar administrators. The specifics of actually performing a system lockdown cannot be reproduced in this guide, as the steps that need to be taken vary considerably between operating systems. However, there are a number of specific guides that are available which should be investigated further if it is determined that a lockdown is required. The primary defence against local exploits is again to ensure that the latest security patches and hot-fixes are applied to both the operating system and the applications that run on top of it, in accordance with the organisational patch management policy. Additionally, a review should be performed on user accounts on the operating system, to ensure that users only have the minimum rights that they need to be able to perform their duties. The number of accounts with administrative privileges should be kept at the absolute minimum. Newer operating systems allow for considerable granularity in the assignment of permissions and these features should be taken advantage of wherever possible. The most effective way to stop users introducing unknown media onto an operating system is to limit which users have permission to access I/O devices. For example, if the purpose of the machine on which the OS is installed is to act as a web server in a machine room, then there may be no requirement for the USB ports on the server to be enabled. Likewise, unless there are valid business reasons to allow users to install their own software from CD ROM or to access data in this manner then the CD/DVD drive should be disabled, or at least restricted to certain users. 10 General Advice on Securing Operating Systems 3.3 Authentication The means by which users authenticate to the operating system is another area where security is paramount. Authentication is the means by which users tell the operating system who they are and what rights they have over the system. Therefore, successful attacks on an authentication mechanism can give the attacker a high level of privilege to cause further compromises. 3.3.1 Authentication attack vectors A user can attempt to upgrade their OS privileges by obtaining the access credentials (such as the logon password) for another user who has greater privileges. This can be achieved by a range of methods, including guessing, taking advantage of user negligence, or (if the operating system has a weak password policy) by conducting a brute force attack on the password file to decrypt the password. The risk of brute force attacks is increased if users are able to login remotely, because an attacker is able to conduct the attack with less risk of being observed. Additionally, there may be vulnerabilities associated with the protocol that users authenticate to the system with. For example, if users connect to a remote server using a protocol such as telnet, they may be unaware that all the traffic that they transmit to the machine is passed over the network in clear-text. If an attacker is monitoring the traffic then these credentials can be intercepted and used by the attacker to gain local user, or potentially even administrative, access to the machine. 3.3.2 Authentication countermeasures In order to protect against brute-force attacks, ensure that a good password policy is in place for all accounts on the machine. The password policy should lock out accounts when an incorrect password has been entered on a number of successive occasions. The only account that it is not possible to have this lockout applied to is the administrative account. If possible the username of this account should be renamed – so that attackers need to know both the administrative username and the correct password. Likewise regular monitoring of the system logs should be conducted to ensure that excessive log-in attempts are not being made (auditing and accounting is discussed in more depth in a subsequent section of this document). For extra security, organisations may wish to consider introducing a second factor of authentication. The use of system which requires a token (such as a smartcard) or a biometric device (such as a fingerprint scanner) as well as a password can add to the overall level of security. 11 General Advice on Securing Operating Systems 3.4 Viruses Computer viruses and computer worms pose a serious threat to operating system security, and due to the fact that they can be introduced to the system either locally or remotely, they are discussed separately. A computer virus is a program which distributes copies of itself, often without the permission or knowledge of a user. A worm is a virus that can reproduce and run independently. The most common way that viruses and worms get onto an operating system is through user action, usually unintentionally. 3.4.1 Virus/worm attack vectors Viruses can get onto the system in a number of ways. The first is by being imported from CD, USB or floppy disk. The risk is considerably increased if users are allowed to import their own files. Likewise, if the operating system hosts an email program that receives messages from the internet, then a virus could be imported by a user receiving and opening an executable from an unverified source. Computer worms travel across network connections and so they exploit the same type of program or service that a remote attacker would, as discussed in the network attack vectors section above. For example, the MS BLASTER worm exploited a vulnerability in the Windows NetBIOS service to propagate and spread across the Internet. 3.4.2 Countermeasures The installation of anti-virus software is widely perceived as the solution to the virus and worm threat. Certainly this software plays its part. However, it is not a complete solution: the CSI/FBI Computer Crime and Security Survey [4] showed that although 99% of companies use antivirus software, 82% of them were hit by viruses and worms. Additional countermeasures can and should be taken to protect against viruses and worms. Because a worm exploits the same vulnerabilities as a remote attacker, the same defences discussed in the network countermeasures section will prevent the attack and spread of the worm. Likewise, worms and viruses take advantage of vulnerabilities in application or operating system code in order to execute or propagate. By ensuring that the operating system and all of the applications running on it all have the latest security patches applied, the threat from viruses and worms is reduced even further. Similarly, some viruses do not rely on system vulnerabilities at all, but on the fact that the user running the virus may have a high level of control over the underlying operating system. By ensuring that users do not have unnecessarily high privileges, as discussed in the local attack countermeasures section, this risk can be reduced. It is also important to educate users in the risks posed to the operating system by viruses and worms. This 12 General Advice on Securing Operating Systems should both reduce the risks (for example by educating users not to run executable code they receive from an unverified source) and improve the effectiveness of any recovery process (by ensuring that all users know who to contact, what to do and what not to do in the event of a virus or worm infecting their system). As with many of aspects of computer security, the best defence is defence in depth. User training and awareness should be enough to prevent viruses entering the operating system. Having a frequently updated anti-virus package will catch any lapses in the user training. Should this fail as well, well patched applications and operating systems should still be resilient to the actions of the virus. 3.5 Access control Prior to the widespread adoption of computers, it was common for confidential information to be locked away. Authorised staff were granted access for the purpose of reading, writing or altering the confidential material. The key holder would usually have been a trusted individual (such as the bank manager in a bank). Sometimes two or more individuals would have separate keys that worked together in an effort to mitigate internal threat through collaboration. Based on the needs of businesses, and particularly the access control mechanisms required by the military, a number of corresponding access control security principles have been formed for the computing environment. These include: • The principle of least privilege: provide only those permissions to a user as are necessary for them to undertake a particular business function and no more. • Need to know: only those individuals that need to know information in order to perform a particular business function should be permitted access to that information. • Fallback to no access: in the event of any problem (such as the appearance of an unauthenticated user or a user who does not appear in the access control list), the system will default to denying all access to the object. This “fail closed” approach can be contrasted with the “fail open” approach which is the norm in safety critical systems. • Accountability: all access attempts are monitored and subsequently audited. The task of ensuring that certain data is appropriately available to the authentic owners (or authorised parties), and not to those who do not have permission, now generally falls to the operating system. Even applications written on top of the operating system will generally rely upon the access control mechanisms provided by the OS. Access control refers to this problem and is usually modelled to consist of access control policies and access control mechanisms. Access control presumes that appropriate identification and authentication of a user has been achieved. It is not simply files that may require access control on a computer system – access to devices, processes and so on may also need to be protected. The notion is therefore that objects need to be subject to access control, where an object could be a file or a hardware device. The 13 General Advice on Securing Operating Systems object needs to have a unique name (for referencing) and a set of valid operations. Example operations for a file may be read, write and execute. 3.5.1 Access control models The access control policy (ACP) specifies exactly who does, or does not, have access to a particular object, whilst the access control mechanism is responsible for implementing this. A number of different criteria may be set within an access control policy: some common examples are shown in the figure below. Roles Based on a job assignment or business function. A particular role necessitates a particular level of access. Groups An administrative convenience for managing groups of users that require the same level of access to an object. Physical/logical location E.g. where a service is only available from console. Time of day Some services should only be authorised during a particular time slot. Transaction type Some services types should not be permitted to particular users – e.g. financial transactions above a particular amount. Figure 5 - Access control criteria There are a number of ways of modelling access from a subject to an object. Discretionary access control (DAC) enables the owner of the resource to specify which objects can access specific resources, i.e. the user can grant access at their discretion. The user is the owner of any file that they create. The most common implementation of a DAC is through access control lists (ACLs), which are dictated by the owners. The DAC model is that typically found within Unix systems. Mandatory access control (MAC) removes some of the freedom associated with DAC. Although users have some control over specifying who may access their files, the operating system makes the final decision. MAC is usually implemented in conjunction with security labels: users are assigned a security clearance and objects are assigned a security marking. The operating system must mediate access to objects that have a marking higher than the accessing user’s clearance. Role based access control (RAC or RBAC) uses a centrally administered set of controls to determine how users interact with objects. Administrators of a system will put the user into a role and then specify what that role is permitted to do. Within each model there has to be a way of specifying the access policy. An access control matrix is a table of users and objects, indicating what actions individual users can take upon individual objects. Access control matrices are often used with DAC models where the access rights can be assigned to the users (the capability model) or to the 14 General Advice on Securing Operating Systems objects (the ACL model). A capability table specifies the access rights that a subject possesses pertaining to specific objects. A capability table differs from an ACL because the user is bound to a capability table whereas the object itself is bound to an ACL. 3.5.2 Models in practice Unix introduced a simple model of file permissions in the 70’s which has proven to be quite effective and easy to understand. In recent times, Unix has added a modern approach to file permissions using ACLs, but very few organisations have adopted this because of its complexity. In the original Unix model, each file has three categories of user: User (u), Group (g) and Other (o). Any user can be a member of any number of groups. Each file has an owner and group attribute, and a set of flags (shown below) for each of the categories: • • • read write execute Note that a limitation of this model is that a file can only be a member of one group at a time. The main limitation of the Unix model is that ordinary users do not have the right to make their own groups. There are ways around this, but Unix has not introduced a standard solution to the problem. “Secure” or “trusted” versions of Unix are available that implement broader policies and models which can include MAC, RAC and the removal of the superuser (root). These include the National Security Agency’s Security Enhanced Linux [11], Sun’s Trusted Solaris [12] and Hewlett Packard’s Trusted HP-UX [13]. In the Microsoft Windows NT line of operating systems (including Windows XP), the OS grants or denies privileges based on an ACL. Windows attaches access-control lists (prioritised allow and deny by groups) comprising up to 30 different privileges for operations on about 15 different kinds of objects. For example, on a service object one can have the privilege to choose what application is run to effect the service (e.g. what graphics program is used to open a graphics file). Although Windows access control is fine-grained and expressive, software developers can have difficulty in evaluating the consequences of the access-control configurations that they choose for their software and services. 15 General Advice on Securing Operating Systems 3.5.3 Vulnerability classes Unix The most significant access control vulnerability class within Unix systems arises from the setuid concept. setuid and setgid (short for “Set User ID” and “Set Group ID”, respectively) are Unix access right flags that can be assigned to files and directories. They are mostly used to allow users on a computer system to execute binary executables with temporarily elevated privileges to perform a specific task. For example, a normal user does not have access to the system password file, but still needs to be able to change their password. This is done by granting the passwd executable the setuid privilege. When the program runs it will run with the privileges of root and therefore be able to access the password files. Any mechanism by which a user can subvert a setuid executable can be used to execute code as root. The buffer overflow is the classic path through which this is achieved, with the buffer overflow payload containing code to spawn a shell with root privileges. Windows A recent research paper from Princeton University [5] provides some interesting insights into the access control model provided by MS Windows, and illustrates possible escalation paths that are known to have been successfully exploited by hackers: Figure 6 - Privilege escalations in Windows from different vendors. Dashed lines indicate that the problem had been fixed by patches at the date of publication 16 General Advice on Securing Operating Systems The following table explains these vulnerability classes and escalation paths in more detail. Services Several vendors poorly apply the Windows access control model to their services; a common mistake is to assign the SERVICE CHANGE CONFIG permission indiscriminately to services. The Windows XP documentation states “…because this grants the caller the right to change the executable file that the system runs, it should be granted only to administrators.” But that warning fails to explain clearly that permission to configure a service allows both setting the executable and selecting the account under which the service runs, e.g., change the run-as account to Local System. From Local System, all things are possible. Registry Some registry keys store sensitive information like the path to the executable acting as a user’s shell, the library to be loaded by a program, the identity of an operating system object etc. If an adversary can overwrite the contents of a sensitive key with the path of their library or executable, they could cause their code to be executed. The standard configuration of AOL includes a registry entry binding the name of a DLL file (which, in some circumstances, is loaded and executed by the AOL software). The access permissions permit any user to write this entry; the attacker can substitute the name of their own DLL and wait for some other AOL user to execute it. Power users There are many privilege-escalation paths from Power Users to Local System. 3.6 Auditing The auditing capabilities within an operating system are usually at least partly designed as a security control. From a security perspective auditing is a control that is primarily detective, but its very existence is likely to have a deterring effect on potential attackers. Auditing can ensure that users are accountable for their actions, verify that security policies are enforced and, importantly, provide a trail of actions that can be used to investigate security incidents. During the transition from large scale single-vendor software systems to COTS solutions, many would say that audit event reporting was diminished in importance, with COTS providers disclaiming liability for security performance. A general focus on security over the past few years, driven by increased network exposure, has increased the awareness for auditing as a direct or indirect security control. It looks likely that government regulations (notably US legislation mandating corporate and enterprise auditing requirements) and business compliance requirements such as Sarbanes-Oxley [6] will prompt a degree of standardisation and development of the auditing infrastructure. 17 General Advice on Securing Operating Systems 3.6.1 What is the operating system auditing function? Accountability is tracked through recording user, system and application activities. The recording is done through auditing functions and mechanisms within an operating system or application. Audit trails typically contain information about operating system activities, application events and user actions. A good system security policy should describe what actions and events are to be audited and logged. This will probably be based upon the outcome of a system risk assessment, legislative requirements and requirements of the disaster recovery policy. Archiving and storage of non-live logs will also need to be considered. One of the problems faced by some system auditing solutions is their centralised and multipurpose nature. Security events are often lumped in with system events making for a huge amount of material. Additionally this is often rotated or cleared by default periodically. This can make mining for relevant information difficult and so needs to be considered before an incident occurs. How, exactly, will information be extracted and pieced together? Are there logging options that can be configured in advance to simplify this task? OS level auditing will probably need to be supplemented with auditing from applications that have security relevance. Individual security logs from applications, stack traces for errors and so on can provide a level of detail regarding applications security events that is simply unavailable at the OS level. Regardless of how OS level auditing is performed, the function itself must be protected: it needs to be kept confidential, its integrity must be preserved and the logging service must be available when required. Exactly how this is achieved depends upon the individual solution. Inevitably, a network-wide auditing solution takes more consideration than a solution focussed on individual servers, however the latter is less likely to scale efficiently. 3.6.2 Logging in Windows and Unix systems In Windows and Unix systems, applications and components submit free-form text messages to system logging facilities. Under Unix this is typically the syslog process and in Windows the System, Security and Application event logs. Additionally applications that terminate unexpectedly may produce a core dump under Unix or trigger the default debugger under Windows. Java applications often fall back to the standard Java logging facility log4j. All of these facilities can work on a per system basis or can provide centralised logging on a network basis. The fundamental problem with such free-form event records is that each application developer individually determines what information should be included in an audit event record, and the overall format in which that record should be presented to the audit log. This variance in formatting among thousands of instrumented applications makes the job of parsing audit event records by analysis tools difficult and error prone. Such domain and application specific parsing code included in analysis tools is also difficult to maintain, as changes to event formats inevitably work their way into newer versions of the applications over time. 18 General Advice on Securing Operating Systems 3.6.3 The future of OS-level auditing Auditing software such as the open source OpenXDAS project [7] has begun appear in response to new legislation and business compliance requirements to provide a more structured alternative to free-form text audit logging. According to the OpenXDAS site, both US companies and those centred in the EU are rapidly adopting standards including ISO9001 that require computer audit trails necessary to minimise the danger of civil litigation and legal prosecution. The XDAS specification defines a well-considered event format for security related events, an event taxonomy with event types that cover most security-related event scenarios, and a standardized API for event submission and management. Development work continues on the syslog software [8] (which is also available for MS Windows), although the rate of development does not seem to mirror that of the XDAS specification. Windows Vista has introduced a new eventing model [9][10] in which event descriptions contain more data and also include event information in XML format, making it easy to expose events data to management tools. Other features include the ability to launch tasks triggered by specific events and to customize the event viewer display. 19 General Advice on Securing Operating Systems 4 Sources of further guidance 4.1 Security lockdown guides The National Security Agency (NSA) have released detailed lockdown guides for: Apple Mac OS X Apple Server Operating Systems Microsoft Windows XP Microsoft Windows 2000 Microsoft Windows Server 2003 Sun Solaris 8 Sun Solaris 9 These can be downloaded at http://www.nsa.gov/snac/downloads_os.cfm?MenuID=scg10.3.1.1 The Center for Internet Security (CIS) has issued a range of publicity about lockdown configurations: http://www.cisecurity.com If you prefer to use a free operating system, NSA have also released Security-Enhanced Linux. This builds a number of security enhancements into the Linux kernel. Details on this project can be found at: http://www.nsa.gov/selinux/ Microsoft have also released their own lockdown guides for their operating systems: Windows XP http://www.microsoft.com/technet/security/prodtech/windowsxp/secwinxp/default.mspx Windows 2000 http://www.microsoft.com/technet/security/prodtech/windows2000/win2khg/default.mspx Windows 2003 http://www.microsoft.com/technet/security/prodtech/windowsserver2003/w2003hg/sgch00. mspx 4.2 Security tools There are a number of security tools that system administrators may wish to consider to check the security of their operating system. Tools include port scanners, such as nmap, which will determine what services the operating system offers to the network, through to tools such as Cain and John which can be used to test the password strength of accounts on the operating system. A comprehensive list of the top 100 most popular security tools (as voted for by nmap users) can be found at: http://sectools.org. This list was last updated in 2006. 20 General Advice on Securing Operating Systems 5 References [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] 21 Wikipedia, http://en.wikipedia.org/wiki/Main_Page Understanding the Linux Kernel (3rd edition), D. Bovet & M. Cesati, O’Reilly, 2005. Good Practice Guide – Patch Management, http://www.cpni.gov.uk/docs/re-2006102400719.pdf, October 2006. CSI/FBI Computer Crime and Security Survey 2003. http://www.reddshell.com/docs/csi_ fbi_2003.pdf “Windows Access Control Demystified”, S. Govindavajhala and A. W. Appel, January 2006. www.cs.princeton.edu/~sudhakar/papers/winval.pdf “Sarbanes Oxley for IT security?”, http://www.theregister.co.uk/2005/05/03/sarbanes_ oxley_for_it_security/ OpenXDAS http://openxdas.sourceforge.net/ “Security Issues in Network Event Logging (syslog)”, http://www.ietf.org/html.charters/ syslog-charter.html “Windows events”, http://msdn2.microsoft.com/en-us/library/aa964766.aspx “Windows Vista Product Features for IT professionals”, http://technet.microsoft.com/enus/windowsvista/aa906027.aspx SE Linux home page, http://www.nsa.gov/selinux/ Trusted Solaris home page, http://www.sun.com/software/solaris/trustedsolaris/ Description of the HP-UX Trusted System, http://docs.hp.com/en/B2355-90121/ch01. html