Determining the Accessibility of Objects

The next step in determining whether your resources are vulnerable as a result of weak permissions is to determine whether they are accessible to an attacker. A lot of the resources in the Windows operating system require you to be logged on to the machine to attack them, but certain objects are accessible remotely. These resources are the ones that attackers target first because they can remotely connect to the machine and take advantage of the weak permissions.

Remotely Accessible Objects

As mentioned, these objects are the ones you should be most concerned about because they allow an attacker to access them remotely and create a harmful exploit. The securable objects that are accessible remotely are these:

  • Windows services

  • DCOM objects

  • Files

  • Registry keys

  • Named pipes

Windows Services

Anything you can do with a service locally, you can also do remotely, such as start, stop, and change the configuration of the service. Services are interesting to an attacker because they generally run as a higher-privileged account. If your application installs a service, make sure you adhere to the following rules of secure service implementation:

  • Enable the service only if it is absolutely needed.  Critical services that are necessary for your application to run should be started by default. By automatically enabling a service for your application, your attack surface increases .

  • Always run the service with the least privileges.  As mentioned earlier, you should not run an application with an account that has more privileges than needed. This principle also applies to services.

A service can run as a local or domain account, and three built-in system accounts in the Windows operating system allow a service to access resources and objects. The following system accounts are listed in order of permission from low to high:

  • Local Service account  The Local Service account has reduced privileges, much like the ones of an authenticated user account. Any services that run as Local Service that connect to a network resource use the anonymous credentials. The actual account name is NT AUTHORITY\LocalService.

  • Network Service account  The Network Service account is like the Local Service account, but accesses network resources using the credentials of the computer account. The actual account name is NT AUTHORITY\NetworkService.

  • Local System  The Local System account is the most powerful of the three built-in service accounts. It has full access to the computers resources, including the directory services if the service is running on a domain controller. A service running as this account has access to network resources like any other domain account. The actual account name is NT AUTHORITY\System.

Unfortunately, because of the number of installed services that increase a systems attack surface, even a flaw exploited in a service running as Local Service or Network Service can lead to elevation of privileges to Local System through chaining multiple security vulnerabilities. To prevent this type of attack, it is better to run your service as an account that has limited access; however, this is not always possible or desirable.

Also, if you use a domain or local account as the service identity, the credentials can be retrieved in clear text using tools that dump the LSA secrets. Generally, this situation might not be a huge concern if you own the machine or the domain it might be in. However, imagine that an organization sets up each workstation and runs backup software as a domain administrator account. In such a case, the local user with administrator rights on the workstation will be able to dump the domain administrators account information.

Make sure you thoroughly test your service for security vulnerabilities that could lead to compromise. Dont ever let It runs as Local Service, which cant really do anything be an excuse for not fixing a security flaw.

When dealing with services, not only should you consider the account the service runs as, but also the rights granted when accessing the service. If an application uses the OpenService , EnumServicesStatusEx , or QueryServiceLockStatus API to create a handle to a service, it can open the service with the access rights such as SERVICE_ALL_ACCESS, SERVICE_ALL_STOP, SERVICE_ALL_START, and so forth. If the application intended only to start or stop the service, there is no reason that it should grant additional access rights because doing so can lead to an EoP attack.

You can also use ObjSD to observe the ACLs set on a service. In particular, you should question any service that has the ChangeConf, WDac, or WOwn rights set on it because this could lead to an EoP attackand a remote EoP, at that.

In fact, Microsoft Security Bulletin MS06-011 ( http://www.microsoft.com/technet/security/bulletin/ms06-011.mspx ), released on March 14, 2006, addresses weak ACLs in several Windows services that could lead to elevation of privilege.

For more information about Windows services in general, refer to http://msdn.microsoft.com/library/en-us/dllproc/base/services.asp .

DCOM Objects

Several applications, including Microsoft Internet Explorer and Microsoft Office Word, use DCOM, which enables the application to be remotely controlled. Although this technology allows constructing applications on a distributed computing environment, it also enables an attacker to potentially exploit software that doesnt set proper permissions on its DCOM objects.

DCOM has a lot of security features, but very few security bugs because it has decent permissions by default. To use the DCOM object, you need permissions to the remote box and DCOM permissions to use the object. Thus, DCOM objects are exploitable really only when they are not properly configured or not tested . The Windows operating system has good defaults in DCOM objects that do not have custom permissions, so you should make sure your objects arent less secure than the default permissions provided by the platform. You can use tools such as Dcomcnfg.exe, which is included in the Windows operating system, to examine the permissions on your DCOM objects.

At the Black Hat Windows Security 2003 briefings, SecurityFriday ( http://www.securityfriday.com ) gave a good presentation that is worth reading if your application uses DCOM; the presentation can be found at http://www.blackhat.com/presentations/win-usa-03/bh-win-03-securityfriday/bh-win-03-securityfriday.ppt .

Locally Accessible Objects

Some objects are available only when a user is logged on to the system, either at the desktop or a terminal server session. Kernel objects, such as mutexes and semaphores, are all local, and an attacker must be logged on to the system to exploit a flaw. Some people believe these objects are not accessible across sessions, meaning you cant attack another user currently logged on to the same machine. This claim is not true. You can access the named object by specifying the session number. For example, if there is a shared section called ShimSharedMemory that session 4 uses, you can access the session using \Sessions\4\BaseNamedObjects\ ShimSharedMemory.

Sometimes, the idea of local EoP attacks is dismissed because people might believe such an attack requires an attacker to have physical access to the machine, the entire machine, or just part of the machine, such as a computer kiosk. The reasoning is if an attacker has physical access to the machine, there are worse problems to consider than a local EoP. Although this excuse might be valid in some cases, it is simply a lazy approach to application security. A user should not be able to take advantage of an applications weak permissions to elevate permissionsperiod. Also, it is important to realize that a user doesnt always have to have physical access to a machine to log on to it; the attacker could use a terminal server to access the machine, and this would still be considered a local attack because the attacker must be logged on to the machine to pull off the attack.

On February 8, 2005, Microsoft released Security Bulletin MS05-012 ( http://www.microsoft.com/technet/security/Bulletin/MS05-012.mspx ), which discussed an EoP attack enabled by a vulnerability that existed in the way the Windows operating system and programs accessed memory when processing Component Object Model (COM) structured storage files and objects. Using this attack, an attacker, who had to be logged on to the machine, could take complete control of the system.



Hunting Security Bugs
Hunting Security Bugs
ISBN: 073562187X
EAN: 2147483647
Year: 2004
Pages: 156

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net