Organizations heavily rely on networking and communications to meet the challenging requirements necessary to compete in the global market place (Tiensivu, 2008). All members of these organizations need to have constant access to files. This requires the ability to connect to the network wherever they may be and from any device that they have availed to them at the time.
In addition, some outside the vendor’s network will require the ability to interact smoothly with the key resources they require. Partners and clients may also desire to conduct quick transactions via the network (Tiensivu, 2008).
Given that most of these operations are very sensitive, using an insecure system is very scary for organizations depending on information systems. As a result, security remains a major component of system implementation. It is a critical success factor that must never be overlooked by an administrator.
This paper examines security implementation in Windows server 2008 operating system. Techniques used by Windows server 2008 to perform authentication, authorization and auditing are considered as well as strategies that may be used by attackers to weaken the security of this operating system.
Security is more important than ever in networking because of the constant threat of infiltration and exposure to the Internet (Tiensivu, 2008). It consists of processes, procedures, policies and technologies that are used to protect computer systems.
A successful navigation of security concerns relies on the knowledge of how to configure network access efficiently and provide the most secure yet accessible connection to an organization and its members (Tiensivu, 2008).
A secure operating system is able to identify individual users, grant access based on identities, and track user actions on a network environment. This always starts by a successful implementation of the AAA of security; authentication, authorization and auditing.
Authentication determines that a user is who he or she claims to be, authorization focuses on what the user is permitted to do within the network after authentication and auditing or accounting lets an administrator track network usage (Gibson, 2011). Figure 1 illustrates how the three security aspects unite to contribute to accountability and reliability of a system.
Authentication, Authorization and Auditing in Windows Server 2008
Regardless of which protocol or technical mechanism is used, all authentication schemes need to meet the same basic requirements of verifying that a user is who he or she claims to be. It involves verifying a digital signature on a file and authenticating user or computer identity.
Windows server 2008 ensures total system health by deploying settings for authenticated wireless and wired connections through Group Policy or by means of scripts (Tiensivu, 2008). In Windows server 2008, most from previous versions of Windows Servers have been improved or replaced with new updated features that allow the administrator to provide the highest level of efficiency and security.
These include but are not limited to Network Policy Server (NPS), Routing and Remote Access Server (RRAS) and Kerberos. In Windows server 2008, all these can be configured to utilize different methods of authentication (Tiensivu, 2008).
After a user is authenticated, he or she must be authorized to connect to the server. Used together with authentication, authorization assists in guaranteeing secure access to whatever content is available on the server (Gibson, 2011). File access in Windows server 2008 can guaranteed by using a secure file system such as New Technology File System (NTFS).
The server uses NTFS Access Control Lists (ACLs) and other available security features to allow permissions to be set on network resources. Unlike FAT or FAT 32 file systems, NTFS is more secure. NTFS also allows the use of encryption and this greatly enhances server security. Different encryption levels are described in table 1 (Gibson, 2011).
Auditing or Accounting
Although authentication and authorization help to eliminate illegal access to network hosts and resources, much more has to be done to detect and control any suspicious network activities. This vital role is accomplished by auditing. Auditing network activities enables an administrator to detect unauthorized accesses such as prohibited access to network resources, attempts to change user privileges, and unauthorized logon.
Usually, it is up to the administrator to decide what is to be audited. Similar to previous versions of Windows server, all security related events in Windows server 2008 are logged into the security log.
The events viewer is then used to view the logged events. The administrator can then investigate each of the issues logged and take the necessary steps to resolve them. Categories of events that may be logged in the event viewer are described in table 2.
According to Gibson (2011), it is important to ensure that the audit logs are available in the original form when needed. For this to happen, it is important to have the logs properly secured (Gibson, 2011).
Redirecting the Flow of a Running Process
Even though much has been done to secure Windows operating systems, attackers can still subvert the security features to do evil. It is possible, for example, for an attacker to conceal his or her presence and modify the very tools used by administrators to monitor network security (Anson & Bunting, 2007).
It is therefore imperative for administrators to think beyond the Windows Graphical User Interface (GUI) that hides from the regular user and even most administrators the details of what the operating system does behind the scenes. Security attacks in Windows operating systems may be explained by looking at how its security features are implemented.
For most operations, Microsoft provides a series of libraries of code that programmers can reference in their programs. These libraries of shared code are referred to as dynamic – link libraries (DLLs) and they save the programmer the trouble of rewriting code that already exists (Anson & Bunting, 2007). When running a process, the processor usually stores information about the DLL that the associated executable file requires.
During execution, the process is given an access token that identifies it to the rest of the system and quite often this token will be the same as the user account that started the process. In this way, a process can only do what the account that started the process is permitted to do.
If an administrator launched a program, the associated process would be capable of doing anything the administrator has the ability to do. It is this concept that the attackers take advantage of when they send programs to unsuspecting victims by email attachments or other similar means.
If a victim executes a program expecting it to be a game or some other useful program, the process that is created will have whatever rights and permissions the user has. Considering that a compiled executable file is not in the human readable form, it is always a difficult task for the end user to know exactly what the program will do.
The moment the user double clicks the executable file, the resulting process does what the attacker intended to happen, whether good or bad (Anson & Bunting, 2007). This explains why most email administrators will block executable files from being received by users in their networks.
Attackers will frequently send malicious software to users as they know that the human component is frequently the weakest link in the entire security chain. If an attacker can trick a privileged user into running malicious software on a machine inside the network, then the malware can be used to provide access to the otherwise protected system.
Increasingly, attackers are using sophisticated ways to deliver malicious software to users. They will undertake intelligent operations to determine information about a company or any other target. They will then craft emails that appear to come from the actual company employees, discussing subjects relevant to the users and with attachments that reflect the activities of the company.
Even though the attachments may do some little good, most of what is done is to install malicious software on the victim’s computer. The malicious software is then used to give the attacker a foothold within the victim company’s network (Anson & Bunting, 2007).
Details of How Redirecting the Flow of a Running Process Happens
Various approaches exist that allow an attacker to change the flow of a process execution. According to Anson and Bunting (2007), one of the techniques frequently used to perform redirection of running process is DLL injection. This enables the attacker to change the execution path from the direction it is originally following to the code that is meant to compromise the security of the system.
The execution of a process is normally accomplished by means of lightweight processes commonly known as threads. Instructions to be executed by a thread must be located in the address space of the process in which the thread is running. Threads will follow a set of instructions through various parts of the process’s memory space and in accordance with the different function calls made by the program (Anson & Bunting, 2007).
The flow of execution may go from the main part of the program, to a function defined within another part of the program, and then to a function contained in a DLL provided by Microsoft or in some cases, a third-party company.
The one thing that all these instructions have in common is that they all are copied into the memory address space of the process of which the thread is a part. If a thread attempts to execute an instruction in a part of memory that is outside the scope of its process’s memory space, the system will deny the attempt and in severe cases, it may even terminate the process.
Consider an attacker who has some compiled code that he or she would really like some privileged process on the victim system to run. Normally, the code is meant to do some sort of evil such as copying sensitive information, recording keystrokes, or any other malicious acts. From the explanation given earlier, the attacker must overcome two main challenges.
First, he or she must get a copy of the malicious or rogue instructions into the memory space of the privileged process. When a program is created, the operating system loads copies of all the DLLs on which the program depends into its memory space. Additionally, the operating system also supports various mechanisms for loading DLLs into the memory space of a process after the process is already created and running.
This makes it possible for many software security packages and other legitimate software to modify the behavior of a system in accordance with the user’s wants. Unfortunately, an attacker can also take advantage of the same mechanism to inject a rogue DLL into the memory space of an already running process.
This technique is what is referred to as DLL injection. Figure 2 shows a process that has had a rogue DLL maliciously injected into its address space and figure 3 shows how a DLL injection attack has been used to redirect the execution of a process.
Secondly, the attacker must redirect the flow of execution for some thread within that process from the instructions that it was supposed to be following to the rogue instructions that the attacker wants executed. As can be seen from figure 2, the attacker has injected code into the process but he or she still needs to get some thread inside the process to redirect its flow of execution and run the injected code.
For an attacker to inject a DLL into the memory space of a running process, he or she must have an account that has the appropriate permission to modify the target process. This can be done using a privileged service running on the victim system (Anson & Bunting, 2007). By exploiting a vulnerable service, the attacker gains the ability to get that service to perform some small task on his or her behalf.
Typically, the task is to start a new process in which the attacker can execute commands. It is possible for attackers to spawn a new thread within the victim process to run the rogue code, allowing the original process threads to continue running the original process instructions as shown in figure 4. Eventually, the system’s security is weakened and the attacker accomplishes his or her task.
Regardless of the challenges faced by administrators, efforts have to be made to ensure network safety. Besides just being familiar with the way Windows operating systems function, the administrator must develop interest in what really happens behind the scenes.
As has been demonstrated in this paper, those areas that are mostly ignored by administrators are the very ones that attackers are quite familiar with and use them to subdue the security of operating systems. Security must be taken seriously and nothing, however small it may be, should be ignored and administrators must be proactive rather than reactive.
Table 1: Remote Access Policy Encryption Options
|Basic||Uses IPSec 56 – bit DES or MPPE 40 – bit encryption|
|Strong||Uses IPSec 56 – bit DES or MPPE 40 – bit encryption|
|Strongest||Uses IPSec 56 – bit DES or MPPE 40 – bit encryption|
Table 2: Windows Event Viewer Log Types and Descriptions
|Application||Tracks events logged by programs|
|Security||Contains events such as valid and invalid logons|
|System||Keeps events logged by Windows system components|
|Directory Service||Keeps track of Active-directory events|
|DNS Server||Contains events related to the resolution of DNS names|
|File Replication Service||Tracks events logged during the replication process between domain controllers|
Figure 1: AAA of Security (Gibson, 2011)
Figure 2: A Rogue DLL has been injected into the address space of the victim process (Anson & Bunting, 2007)
Figure 3: A DLL injection Attack used to redirect process execution (Anson & Bunting, 2007)
Figure 4: A DLL injection attack takes advantage of multithreading to compromise system integrity
Anson, S. & Bunting, S. (2007). Mastering Windows Network Forensics and Investigation. Indianapolis, Indiana: John Wiley and Sons.
Gibson, D. (2011). Microsoft Windows Security Essentials. Indianapolis, Indiana: John Wiley and Sons.
Tiensivu, A. (2008). Securing Windows Server 2008: Prevent Attacks from Outside and Inside Your Organization. Burlington, MA: Syngress Publishing, Inc.