Post-Boot Startup
After Windows Vista boots, additional drivers, services, registry entries, and other "autorun" programs are loaded. The networking components are loaded. Initially, a smaller, temporary, network stack is loaded, enough so that Windows can initiate a DHCP request (if enabled), and use a few other basic services (such as DNS to locate other core network services and hosts). During this phase, inbound network traffic is limited to a few essential services. This is to prevent malware from attacking Windows Vista before Windows Firewall and IPsec are loaded. The Network Location Awareness service is used to identify any network topology changes, like a mobile laptop needing a new DHCP-provided IP address because it is connecting to a new network. Eventually Windows Firewall is fully loaded, and the temporary network stack is replaced with a permanent version.
Applying Security Policy
During this time, Windows also loads any predefined computer security policies. When the computer first boots, the PC's computer-centric Local Security Policy (gpedit.msc) settings are loaded, if there are any values. These settings apply to the computer itself, and consequently, all users of the computer.
If the computer is joined to a domain, the computer will log on to a domain controller and provide its computer account password. After authenticating, a secure SMB channel is established between the computer and the domain controller. Any computer-specific domain group policy objects, or GPOs are then applied in the following order: site-level, domain-level, and then any organizational unit-(OU-) level GPOs.
When a user logs on to the computer, user-specific Local Security Policy settings are applied, if any. After the user authenticates to the domain, user-specific GPO settings are applied, following a similar order as used for computer-specific policies. Figure 1 summarizes the Local Security Policy and GPO-application order.
Name Resolution
Windows uses both DNS and NetBIOS name resolution. During the startup process and ongoing operations, Windows is constantly performing name-to-IP address resolution. Contrary to popular belief, it isn't all DNS. The Domain Name System (DNS) service resolves DNS client queries converting DNS names to IP addresses. Windows uses DNS to resolve Internet name queries, and also for queries looking for DNS registered hosts and Active Directory services.
For example, DNS is used when Windows is booting to find a domain controller for the computer to log on. The NetLogon service sends DNS queries to the primary DNS server looking for Service Resource (SRV) records. SRV DNS records indicate which IP host is a domain controller, global catalog server, and so on. When a domain controller's IP address is found, the workstation will then connect to the domain controller's LDAP service on port 389 to enumerate other important information.
Most DNS client queries follow a set path (as shown in Figure 2). When a client needs to resolve a DNS name to an IP address (say for Internet browsing, for example), the DNS client service (called the DNS resolver in DNS technical circles) will first check the local DNS cache. The DNS cache is an area in memory that stores just resolved DNS names. If Windows has recently (within minutes) resolved a particular DNS name, it can quickly pull the resolution information out of the cache, and not have to perform a full DNS query.
If the DNS answer is not in the local cache, the DNS client will then check the computer's local HOSTS file. The HOSTS file contains static DNS resolution entries. In Windows NT-class computers, the HOSTS file is located in \%Windir%\System32\Drivers\Etc. It can be modified by administrators only.
Be aware, however, that if an administrator adds entries to the HOSTS file, Windows Defender, the built-in anti-spyware tool in Windows Vista, will flag it as a potential intrusion. Modifying the HOSTS file is a favorite trick of spyware to make users go to Web sites other than the ones they intended to go to.
If the HOSTS file does not resolve the DNS query, the DNS client sends a resolution request to the first DNS server located in its TCP/IP properties tab (or as provided by DHCP). The DNS server then takes it upon itself to resolve the query, or forwards the request to another server. Either way, the DNS server normally sends the answer to the DNS query to the DNS client, which then passes it along to the original requesting application.
NetBIOS Name Resolution Is Often Required
DNS as a primary name resolution service (outside of Internet queries only) was first introduced in Windows 2000. Prior to Windows 2000, Windows almost always used NetBIOS name resolution to find private host addresses and services. NetBIOS name resolution can be accomplished using a broadcasted NetBIOS name resolution query or by sending a query request to a participating Windows Name Service (WINS) service or WINS proxy.
Many administrators mistakenly believe that NetBIOS name resolution no longer occurs or believe that WINS is no longer needed on today's Windows networks. This is not always true. Windows frequently uses NetBIOS name resolution as its first and primary name resolving method. All Windows computers require a NetBIOS name, and Active Directory cannot even be installed on a file server without giving the Active Directory domain a NetBIOS name.
Frequently, Windows will look for a given resource using its NetBIOS host name first, and if not found, fall back to DNS. Other times, older versions of Windows and legacy applications, will only use NetBIOS name resolution. NetBIOS name resolution follows a path similar to DNS client resolution, but instead uses a HOST file replacement called LMHOST, and WINS servers instead of DNS servers (if WINS is enabled). In most enterprise scenarios, if the PC cannot reach a WINS server, it then falls back and sends a broadcast query (called hybrid mode). Understanding the potential requirement for Net-BIOS name resolution is important to the security administrator.
User Profiles
When a user successfully logs on, his user profile is loaded. A user profile normally contains the user's customized desktop settings, background picture selection, and many application settings (for Internet Explorer, Outlook, and so on). If a user uses EFS or has PKI digital certificates, they are often stored in their profile. A user's Document's directory can also be stored there, although it tends to slow down logons and logoffs as the directory grows larger.
Profiles can be stored locally, or stored on a referenced Windows network drive. Network profiles are also known as roaming profiles, because they can be applied to every PC the user logs on to. If the profile is stored on the network, when the user logs in the user's roaming profile will be copied down to the local hard drive and be applied to the computer. When the user logs off, the user's profile will be copied back up to the network drive. By default the user's network profile will be left on the local drive, but you can configure Windows to delete the local profile to increase security.
Actually, the process is a bit more complicated than what we've already discussed. Any new user's profile is created using the Default User profile from the first computer the user logs onto. It is the template from which all other profiles on the local computer are made.
Before the user's personal profile is applied during a logon event, Windows applies the All User profile. Whatever settings are in this shared profile are applied to the computer first and merged into all the logged on users of the computer. The user's personal profile then overlays the All Users profile, and any conflicts are usually won by the user's profile (unless a mandatory shared profile is enforced).
Prior to Vista, the All Users profile was stored in \Documents and Settings\ All Users folder. In Vista, the All Users profile is stored in \Users\Public. Administrators have Full Control to the Public folder. For backward compatibility with legacy applications, Windows has several symbolic links that end pointing to \Users\Public. First, the symbolic link \Documents and Settings, points to \Users. The \Users\All Users profile points to \ProgramData, but in a confusing mix, \ProgramData and its subdirectories point to \Users\Public. Table 1 lists some of the related symbolic links.
Table 1: Vista Symbolic Links
 Open table as spreadsheet
|
FOLDER\SYMBOLIC LINK
|
REDIRECTS TO
|
|
\Documents and Settings
|
\Users
|
|
\Documents and Settings\All Users
|
\Users\Public
|
|
\ProgramData\Desktop
|
\Users\Public\Desktop
|
|
\ProgramData\Documents
|
\Users\Public\Documents
|
|
\ProgramData\Favorites
|
\Users\Public\Favorites
|
|
\ProgramData\Start Menu
|
\ProgramData\Microsoft\Windows\Start Menu
|
|
\ProgramData\Templates
|
\ProgramData\Microsoft\Windows\Templates
|
The end result of all the interaction between the Default User, the All Users, and personal user profiles (networked or local) is that malicious code has many places to hide, and more places to search for passwords and private encryption keys, if it was successful in exploiting Windows. A conscientious forensic explorer needs to be aware of how profiles interact and where things are stored.
Services
Windows Vista comes pre-installed with over 130 different services, depending on the features installed and activated. Over 75 services are turned on by default, and new software can be installed to create more. Administrators often wonder how a service is different than a regular application.
Services can be activated and executed by Windows when it starts up without needing to have a user logged on. Each service logs on the local computer (or network) and runs in a predefined user account context. Most services run in the Local System (or System) security context. This account is the most powerful account in Windows. If an attacker buffer overflows a service running in the System context, the attacker may gain System privileges and permissions and completely control the system. The reason this is a "may" and not a "will" is that, in Windows Vista, even services that run as LocalSystem are restricted in certain ways.
Windows attempts to limit the widespread effectiveness of buffer overflow, and other privilege escalation attacks, by installing (and allowing) services to run in many logon service contexts beside System. Microsoft provides the less privileged Local Service and Network Service service accounts for services needing limited access to the local system and/or network.
The Local Service account has permissions and privileges similar to an authenticated user on the local machine, but accesses network resources as the anonymous null session user. The Network Service account accesses local resources as if it were a member of the Authenticated Users group (like the Local Service account), but accesses network resources with the credentials of the local computer account (which is always more than the anonymous null session account).
If any of the three default service accounts are used with a service, the administrator does not need to choose or enter a password. Windows chooses long and complex passwords automatically for these accounts and changes them on a regular basis. Accordingly, because there is no known password, it is difficult to log on to a Windows computer using these service accounts.
Any user or computer account can be used as a service account, but it must be assigned the Logon as a Service right. This right allows the service to interact with the Service Control Manager (SCM) and allows the service to start without waiting for an interactive user to logon. If a custom service account (i.e., not Local System, Local Service, or Network Service) is used, a valid logon name and password must be provided. The service account password is then stored locally on the computer in protected form. Windows Vista protects service account passwords more than prior versions of Windows. In previous versions, a local attacker with administrative privileges could run a malicious utility and extract service account logon names and passwords. Windows Vista disables those current attack tools.
Windows Vista does much more than previous versions of Windows to limit attacks against default services. Each service was reviewed to remove potential buffer overflows. If a service is interrupted by a malicious program, the service has a better chance at self-recovering, or if it cannot ward off the attack, shutting down or restarting.
Microsoft reviewed each default service's needed permissions and assigned the least privilege permissions needed to do the job. The SCM does a quick run time privilege review on services getting ready to start, and removes all unnecessary privileges and permissions from the service during the start process. Many services are assigned the Restricted token, which significantly limits what other objects the service can access, and many others are marked as write-restricted (meaning they cannot modify other Windows resources). Services can also be network restricted using Windows Firewall and IPsec. The idea is that if the service does get successfully attacked, the service is less likely to allow full system access.
One last final caution when configuring new services: Each service running in the Local System context can be enabled to allow the service to interact with the desktop (see Figure 3).
This is required for services that must interact directly with a logged in user. Any information an enabled service displays on the desktop, will appear on the interactive user's desktop too. This could reveal sensitive information or allow the logged on local user to manipulate the service to gain higher privileges.
Windows Vista allows (as XP Pro does as well) programs and commands to be run when services fail. This feature can be used to send an e-mail or network message to the Help Desk or administrator to warn of an anomaly. In Figure 4, the open source SMTP program Blat (http://www.sourceforge.net/projects/blat) is being used to send an e-mail message along with the number of times the service failed.
|
