Get a client workstation, own the domain.

Like the title? I thought you might. So you might be wondering what I mean by owning a domain by getting only one workstation? Is it even possible? Well, before this year it was very difficult to do. Now, it's way too easy and I will share the reasons why.

Let's talk about workstation security for a second. I would guess that most companies don't even worry about completely securing client workstations. In most companies that level of attention would take waaaaay too much time. Besides, compromising a workstation only gives a few key pieces of information. None of which are that useful for compromising a domain. Check it out:

1. You can crack any local account passwords on the box. Chances are slim but the password for the local adminstrator account may be the same as the password for the local administrator account on all of the other workstations. The chances are even slimmer but the password may be the same as that on servers.

2. You can dump the LSA secrets which reveals clear text passwords for accounts that are used to run local services on the machine. The chance that this will reveal anything on a client machine will be slim.

Lets be realistic though...your testing a fairly secure network here. You've compromised one workstation due to a default install of msde with a blank sa password. However, this is the only workstation that you've gotten into and you've already checked all the other machines in the domain. Where do you go from here?

Now, thanks to Arnaud Pilon, you have a chance using a new tool called CacheDump (http://www.cr0.net:8040/misc/cachedump.html). Let me give you a little background first.

When you log into Windows, it is kind enough to cache your password in the registry. This caching process can be disabled but by default it is enabled and for a good reason. Consider this...you have a laptop that you use at work. You log on to it using the username and password for your work domain. When you take your laptop home, even though you are not connected to the work domain you can still log into that laptop with the same username, password and domain. This is made possible by the password cache that is stored in the registry for your username. Nice functionality huh? Without it you would have to have a local user account to log in with and you would have to maintain two different passwords...one for your domain account and one for the local account. What a pain. So here is the classic case of security vs. functionality.

So a Windows machine will cache domain user account passwords, big deal right? This is a huge deal. Let's say that a domain admin logs into your workstation. He/She leaves behind a cached password for a very privileged account. Even worse, let's say you use Altiris or Microsoft SMS to remotely install and administer applications on client workstations. The whole purpose for using these products is to facilitate an application setup by giving it administrative privileges for a user who is not an administrator. So Altiris/SMS is logging into almost all of your machines using a very privileged account and the cached password hash is being left behind on every machine.

Now where were we...you've compromised one workstation and your stuck. What do you do now? You bust out CacheDump and run it as follows:

c:\cachedump (wow, complicated isn't it)

domadmin1:0E9A658F6132E709ED673458387E6892:work:work.comp.corp
entadmin1:19E8B953689EFBC3222ABC599F835856:comp:comp.corp

The output shows you the cached password hash for a domain admin account in your domain and an enterprise admin account in the parent domain. So you copy this information into a text file called hashs.txt and run a custom version of John and crack all the passwords as follows:

c:\john -format:mscash hashs.txt

It's only a matter of time now.

The game is changing. Now your workstations are just a important as your domain controllers and you member servers.

Want the tools discussed in this article?

CacheDump v1.1, diffs for John that include the mscash format, and how to build the custom version of John can all be found here:

http://www.cr0.net:8040/misc/cachedump.html

To dump LSA secrets I prefer Cain & Able which can be found here:

http://www.oxid.it/cain.html

Windows privilege escalation using Program.exe.

Let me first start out by saying that I love Windows. It must be the easiest operating system to learn and use. Unfortunately, it is also one of the easiest in which to find holes. One of my favorite past times is finding privilege escalation vulnerabilities in windows and windows applications. They exist everywhere. So I want to talk about a privilege escalation that exists in many of the Windows operating systems simply because of a misunderstanding of how Windows works.

First, some background information on how Windows launches applications:

1. Start, Run, C:\Winnt\system32\cmd.exe

This is pretty simple and straight forward...Windows will locate the file cmd.exe and launch it.

2. Start, Run, "C:\Program Files\WIDCOMM\Bluetooth Software\bin\btwdins.exe"

This is almost identical to the first. Windows will locate the file btwdins.exe (the default Bluetooth service executable that appears on most HP/Compaq SOHO machines) and launch it. However, note the use of the quotes in the path because of the spaces. In the old 8.3 notation this could be written as follows and the use of quotes would not be necessary.

C:\Progra~1\WIDCOMM\Blueto~1\bin\btwdins.exe

3. Start, Run, C:\Program Files\WIDCOMM\Bluetooth Software\bin\btwdins.exe

This may look the same as the previous example but the quotes are missing. This can be bad and I will discuss why further down but here is how Windows interprets this statement because of the spaces.

- Windows will try to locate and launch the file C:\Program.exe
- If that file does not exist Windows will try to locate and launch the file C:\Program Files\WIDCOMM\Bluetooth.exe
- If that file does not exist Windows will finally try to locate and launch the original intended file C:\Program Files\WIDCOMM\Bluetooth Software\bin\btwdins.exe

You might be thinking one of two things right now...wow or so what. Well let's say you are logged into a machine as a user with only local guest privileges. You can't do much but you want to try to interact with other process that are running with higher privileges so that you can manipulate them to elavate your privileges. So what runs with higher privileges...services. Most services in Windows run as LocalSystem which has basically god rights for the local machine.

Thinking back to the examples, what if I told you that Bluetooth was a service set to startup automatically with Windows and run under the context of LocalSystem. The path to the executable is C:\Program Files\WIDCOMM\Bluetooth Software\bin\btwdins.exe without the quotes. When Windows starts it will try to start the Bluetooth service automatically as LocalSystem but since there are no quotes around the path to the btwdins.exe file it will try to launch the following as LocalSystem first:

- C:\Program.exe
- C:\Program Files\WIDCOMM\Bluetooth.exe

So you could hack up your own Program.exe service or Bluetooth.exe service and place it in the location where Windows will accidentally run it. The service you create could simply create a new account and add it to the local Administrators group.

However, you can't do much as with your current guest privileges. The default permissions for the Program Files folder in Windows 2000 and above prevent a guest account from even entering the folder. So how are you supposed to plant your custom C:\Program Files\WIDCOMM\Bluetooth.exe file? You can't. But what about using the root of C:\ for a custom Program.exe file? You can...in Windows 2000 and below. In Windows XP and above the default permissions of Everyone - Full Control where removed (which was a smart move by Microsoft).

So plant your custom C:\Program.exe file that will create a new account and add it to the local Administrators group and restart the computer. Log in as the new admin account.

Want the tools discussed in this article?

http://reedarvin.thearvins.com/tools/EnumServiceExecutablePaths.zip

This is a simple PERL (http://www.activeperl.com/) script that you can run to enumerate the executable paths of all services. Just run it and look through the output for paths that have spaces and do not have quotes.

http://reedarvin.thearvins.com/tools/Program.zip

This is the custom Program.exe service file that can be used to add a new user and add that user to the local Administrators group. Just copy the Program.exe file and the runme.txt file to the root of C:\. Add as many commands as you would like Program.exe to run to the runme.txt file.