Shellcode+SYSENTER = CALC (SP3)

[JMC31337]

First, thank you for understanding what i was saying and my bad for not being more "systematically correct"

 

1)

"no, it's always [edx]."

well, SYSENTER will always hit the [edx] address just how it works, but we could load the same address into [eax] and jmp or call... 

 

2)

"I want to stress again that execution *never* continues after the sysenter"

well again i guess i didnt "systematically and correctly" explain that: just thought you implied it would never get to that RET after sysenter does whatever ... 

 

3)

"4012e3 *happens* to point after the sysenter - but you can use any other address in its place"

yup this is true; and i had to do that in order to avoid sysenter running twice over since my esp was left at sysenter, thus calling another sysenter after the first finished

 

onward with the next steps!

Edited December 5, 2013 by JMC31337

[deepzero]

well, if you understand all that i really dont see what the problem is?

 

sysenter == jmp [edx]

 

 

What are the next steps?

[JMC31337]

Likewise....

As a warm-up, use SYSENTER to load up NTDLL or even ntoskrnl in user space

Grab this modded up code at rohitab http://www.rohitab.com/discuss/topic/38798-kernel32-getprocaddress-loadlibraryex-winexec-notepad-calc/ and mod it up some more

So it can iterate thru ntoskrnl or ntdll for:

RtlEqualUnicodeString then it can get the Unicode UNC path for a test.txt file

use SYSENTER to ZwCreate file... Without the need for all those typedefs that Dev-C++ and others make you use to call ZwCreatefile.... That's my warmup

Ultimately I'm gonna use SYSENTER to load ntoskrnl real fast n nice, then try to get up into the kernel space ... Hopefully through one of the hundreds of drivers (a lil sarcasm) ... that software makes you install

Edited December 6, 2013 by JMC31337

[Nemo]

So i guess this might be able to be used to elevate privileges maybe

[JMC31337]

So i guess this might be able to be used to elevate privileges maybe

 

Dunno yet.. But let's go off the path for a second and riddle me this:

 

If we know that a damn good 0-day exploit can be sold on the black market for upwards of 5-100 grand 

1) Where would you take a 0-day if you found one?  

Microsoft ? surely not, those industry people arent your friends they just know how to pretend

 

2) Government?

Absolutely not! They're (U.S. Govt) already trying to take over the world and spy on everyone

 

post it here?  sure of course, why not; everything else that "would be " leading up to an exploit is already up here

 

 

What would you do with a 0-day?  and where would you go with it?

 

Thats a lot of questions in a lil reply but, for good reason

Edited December 6, 2013 by JMC31337

[deepzero]

please, explain again where you smell an exploit,i really dont see it.

 

 

and where would you go with it?

 

Unless you know a serious broker or have connections to "end users", you will want to go to ZDI - Zero Day Initiative.

[JMC31337]

"ZDI"  ??

 

"Interested researchers provide TippingPoint with exclusive information about previously un-patched vulnerabilities they have discovered. TippingPoint collects background information in order to validate the identity of the researcher for ethical and financial oversight. TippingPoint validates the issue in its security labs and makes a monetary offer to the researcher. If the researcher accepts the offer, he/she will be paid promptly"

 

So i gotta give up the goods before i get any offrers??  naaa i dont think so .. and ill tell ya straight up my background sucks...

 

Secondly,

GOOGLE "loadlibrary ntoskrnl exploit"

 

and thats the processes and steps it takes to actually make an exploit .. but you gotta loadlibrary ntoskrnl first (at least for those types of exploits)

 Nemo was right; very well could be one after we start throwing shit at the kernel...

 

There exist many exploits presently within all of our systems, but you cant see them yet, can you?

Until you hear about it and see PoC ...  right now we (i use the term loosely) have the first step towards a way to play with the kernel

 

And the longest journey, begins with the first step... But im not here to preach im here to hack

Edited December 6, 2013 by JMC31337

[kao]

Consider the amount of knowledge and understanding you've demonstrated so far - you're more likely to fly to the moon than to create "a damn good 0-day exploit".

Just saying..

And no, you don't have any first step towards a way to play with kernel. But you're too ignorant to understand that.

[mrexodia]

you're more likely to fly to the moon

LOL

whats the point of this topic?

[JMC31337]

They dont have a point theyre trying to get me pissed.. aint gonna work 

 

My point is, yea we can use all of this to play with the kernel its called fuzzing (and actually i posted a fuzzing tool that was created in an earlier thread)  Just havent gotten to the point of IoDevice Driver communication yet

And yea i can play with that ntoskrnl.exe no problem.. of course as of right now i can only use the ZwCreateFile from NTDLL and not NTOSKRNL.EXE

 

But i have no problems loading up that kernel and running a RuntimeLibrary Unicode String API ...

 

Just working on this NTOSKRNL ZwCreateFile which is crapping out at a TSS(i think its TSS)  mov fs,bx opcode

 

and shhhh... the point of this topic was just to have a good time with shellcode, then certain "haters" thought they'd make a name for themselves by coming at me...

 

However, since i got started as trying to use SYSENTER for the only "go-somewhere" CALL i came across this beautiful Dev-C++ friendly source from a chinese hacker:

 

http://blog.csdn.net/wangningyu/article/details/5249462

 

see all of those TYPEDEFS?

just trying to use sysenter and no typedefs...

 

RtlInitUnicodeString = (RTLINITUNICODESTRING)GetProcAddress (hNtDll,"RtlInitUnicodeString"); 

can actually be ran from ntoskrnl.exe instead of NTDLL ... one of the few i have found to actually not crap out on me

 

if i try to use the ntoskrnl.exe version of ZwCreateFile

i end up at:

CPU Disasm

Address   Hex dump          Command                                  Comments

0048C4D6    B8 25000000     MOV EAX,25

0048C4DB    8D5424 04       LEA EDX,[ESP+4]

0048C4DF    9C              PUSHFD

0048C4E0    6A 08           PUSH 8

0048C4E2    E8 EAA2FFFF     CALL 004867D1

 

then follow along to:

CPU Disasm

Address   Hex dump          Command                                  Comments

004867D1    6A 00           PUSH 0

004867D3    55              PUSH EBP

004867D4    53              PUSH EBX

004867D5    56              PUSH ESI

004867D6    57              PUSH EDI

004867D7    0FA0            PUSH FS

004867D9    BB 30000000     MOV EBX,30

004867DE    8EE3            MOV FS,BX                                ; Modification of segment register

 

 

and CRAP OUT! but ntdll works fine..

 

 

thats the point here experts!

to have a good time

Edited December 7, 2013 by JMC31337

[cypher]

IMHO ferrie, kao and deepzero are right:

 

There is nothing special about this code. Only thing it does is obfuscating "jmp [edx]" by using "sysenter". Its not avoiding Win32 APIs (hardcoded API address is not avoiding the API...) and its definitely not using NT kernel stuff directly.

 

This is a dead end. There is no glitch or whatever here that could be escalated or whatever. Its just standard behavior that even is documented...

[JMC31337]

Lol
Let's go back to my first post on this topic:Quote myself once again and sound like a broken record:Its NOTHING SERIOUS!I just wanted to play with SYSENTERStop coming at me and start going at the system.. I'm gonna keep doing what im doingI mean take a look at Z0mbies Int 2eh syscall virus: that thing is a nightmare waiting to happen using syscall
I don't think it's an exploit but it's bad ass

 

And yes, you're absolutely right about hard-coded addresses.. Ill take care of all that in the end.. for now its just hard-coded for testing purposes ...

Edited December 7, 2013 by JMC31337

[JMC31337]

Sysenter is pretty cool in that it wont pop that alert saying your system crashed send Microsoft you're crash dumps

 

 

just closes out on an access violation...

 

 

int main()

{

asm("SYSENTER");

}

 

 

in and out.. anything else as a 1 liner and MCSFT pops the crash dump alert asking about whats going on

Edited December 8, 2013 by JMC31337

[mrexodia]

Sysenter is pretty cool in that it wont pop that alert saying your system crashed send Microsoft you're crash dumps

in and out.. anything else as a 1 liner and MCSFT pops the crash dump alert asking about whats going on

I'm fully convinced now...

edit: also try this, it might be exploitable (?) http://codepad.org/XvqKijeG

Edited December 8, 2013 by Mr. eXoDia

[JMC31337]

Vista or Win7?   I dont know what a send to microsoft crash dump messagebox looks like on those machines;

Is your image the equivalent of one, or something else ? 

 

Ill play with your codepad post in more detail a lil later.. as it stands at first glance this is what I get on this SP3 machine:

(14e0.1690): Access violation - code c0000005 (!!! second chance !!!)

eax=c0000005 ebx=00004000 ecx=77c61ae8 edx=7c90e514 esi=0143f796 edi=0143f6ee

eip=7c97e860 esp=77c61aec ebp=0022ff78 iopl=0         nv up ei pl zr na pe cy

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

ntdll!NlsMbOemCodePageTag+0x7b8:

7c97e860 0000            add     byte ptr [eax],al          ds:0023:c0000005=??

0:000> !load msec

0:000> !exploitable

Exploitability Classification: EXPLOITABLE

Recommended Bug Title: Exploitable - User Mode Write AV starting at ntdll!NlsMbOemCodePageTag+0x00000000000007b8 (Hash=0x000f5570.0x000f1370)

 

User mode write access violations that are not near NULL are exploitable.

CPU - main thread, module ntdll

 

EAX C0000005

ECX 77C61AE8 msvcrt.77C61AE8

EDX 7C90E514 ntdll.KiFastSystemCallRet

EBX 00004000

ESP 77C61AEC msvcrt.77C61AEC

EBP 0022FF78

ESI 0012B3FC

EDI 7C901000 ntdll.RtlEnterCriticalSection

EIP 7C97E860 ntdll.7C97E860

 

CPU Stack

Address   Value      ASCII Comments

77C61AEC   FFFFFFFF

 

 

 

 

 

and if i change it to:

 

expoilt=main;

asm("mov edx,_expoilt)");

asm("sysenter");

return 0; 

 

says this:

(11b4.17d0): Access violation - code c0000005 (!!! second chance !!!)

eax=c0000005 ebx=00004000 ecx=00401290 edx=7c90e514 esi=0143f796 edi=0143f6ee

eip=83e58955 esp=00401294 ebp=0022ff78 iopl=0         nv up ei pl zr na pe cy

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

83e58955 ??              ???

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 @ 0xffffffff83e58955 (Hash=0x6e05193a.0x7505193a)
Access violations at the instruction pointer are exploitable if not near NULL.

the table being:

CPU Stack

Address   Value      ASCII Comments

00401294   E48308EC  

00401298   0000B8F0  ..

0040129C   C0830000  ..

004012A0   0FC0830F  

004012A4   C104E8C1       ; ASCII "?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????"...

004012A8   458904E0  E

004012AC   FC458BFC  E

004012B0   00046BE8  k.

004012B4   0106E800  .

004012B8   05C70000  ..

004012BC   00404010  @@.

004012C0   00401290  @.   ; Entry point of procedure

CPU - main thread

 

EAX C0000005

ECX 00401290 Entry point of procedure

EDX 7C90E514 ntdll.KiFastSystemCallRet

EBX 00004000

ESP 00401294 Syspop.00401294

EBP 0022FF78

ESI 0012B3FC

EDI 7C901000 ntdll.RtlEnterCriticalSection

EIP 83E58955

 

 

 

And lastly using both methods with SYSENTER does not pop the MCSFT wants your crash dump box

Edited December 9, 2013 by JMC31337

[deepzero]

you do realize exploitable refers to code execution in the context of the process (no kernel privilege escalation), right? Since you are executing your own code already, that is quiet useless.

 

 

There is also nothing special about the exception - it's a standard Access Violation.

Edited December 9, 2013 by deepzero

[JMC31337]

its the only way

 

edx,esp

sysenter

 

anything else and SYSENTER clobbers that stack .. and those NOP SLEDS are needed to avoid the SYSENTER double loop crash n burn and we NOP SLED since we cant "hard-code" addresses

 

"call [_ll]\n"   is there for testing purposes of the variable .. itll be changed to sysenter later

//http://www.cnblogs.com/cfas/archive/2013/05/31.html

/*

Typedef	Definition

CHAR	char

PSTR or LPSTR	char*

PCSTR or LPCSTR	const char*

PWSTR or LPWSTR	wchar_t*

PCWSTR or LPCWSTR	const wchar_t*

*/
#define DWORD unsigned long

#define WORD unsigned short

#define BOOL unsigned long

#define PSTR const char*

#define PWSTR wchar_t*

#define PCSTR const char*
DWORD sys;

DWORD ll;   //LoadLib mem address

DWORD k32;  //kernel32 base address

DWORD ntdllx; //ntdll base address

PWSTR NTOSKRNL=L"ntsokrnl.exe";

//char *xnt = "ntoskrnl.exe";

PWSTR  file = L"\\??\\C:\\testXXX.txt";

DWORD getproc;

char *non_paged_memory;
int main()

{

asm("push ebp");                       //setup a new stack frame

asm("mov esp,ebp");                    //setup a new stack frame

asm("xor eax,eax");                    //clear eax register

asm("xor ebx,ebx");                    //clear ebx register

asm("xor ecx,ecx");                    //clear ecx register

asm("xor edx,edx");                    //clear edx register
//GET k32 BaseAddr

asm(

"mov esi, dword ptr fs:[0]\n"          //standard way for use to walk the TEB/PEB table

"lodsd\n"                              

"cdq\n"

"lodsd\n"                              //looking for the kernel32.dll base address

"@base_loop:\n"                        //k32 holds the GetProcAddress API           

"dec eax\n"                                       

"cmp dword ptr [eax], 0x00905a4d\n"

"jnz @base_loop\n"

);
asm(

"mov _k32,eax"                         //now we have our variable _k32 holding the base address

                                       //of the kernel32.dll

);
asm(

"mov   edi,dword ptr _k32\n"                       // k32 = edi = eax = Kernel32 BaseAddress

    "mov   eax,dword ptr [eax + 0x3C]\n"          // offset to start of PE header

    "mov   edx,dword ptr [eax + 0x78 + edi]\n"  // IMAGE_EXPORT_DIRECTORY--->RVA

    "add   edx,edi\n"                           // IMAGE_EXPORT_DIRECTORY--->VA  = edx

"mov   ecx,dword ptr [edx + 0x18]\n"          // ecx = NumberOfNames

    "mov   ebx,dword ptr [edx + 0x20]\n"          // ebx = AddressOfNames

    "add   ebx,edi\n"

"_Index:\n"

    "dec   ecx\n"                               // ecx --- NumberOfNames ???? ---- ????????

    "mov   esi,dword ptr [ebx + ecx * 4]\n"   // Name -- RVA

    "add   esi,edi\n"

    "cmp   dword ptr [esi],0x50746547\n"    //PteG

    "jnz   _Index\n"

    "cmp   dword ptr [esi + 0x04],0x41636f72\n" //Acor

    "jnz   _Index\n"

    "cmp   dword ptr [esi + 0x08],0x65726464\n" //erdd

    "jnz   _Index\n"

    "cmp   word  ptr [esi + 0x0C],0x7373\n" //ss

    "jnz   _Index\n"

    "mov   ebx,dword ptr [edx + 0x24]\n"          // AddressOfNameOridinals --- ?????

    "add   ebx,edi\n"

    "mov    cx, word ptr [ebx + ecx * 2]\n"

    "mov   ebx,dword ptr [edx + 0x1C]\n"         // ebx = AddressOfFunctions

    "add   ebx,edi\n"

    "mov   eax,dword ptr [ebx + ecx * 4]\n"

    "add   eax,edi\n"

"mov _getproc, eax\n"  //API ADDRESS TO GetProcAddress -> getproc variable
     "pop ebp\n"       //clean up

     "mov ebp,esp\n"    //clean up our stack

     "mov edi,eax\n"    //edi held our k32 base address

                        //so now it holds the value of eax

                        //eax = getproc  edi now = getproc

     "push 0x00\n"        //00000000  ....

     "push 0x41797261\n"   //41797261  aryA

     "push 0x7262694C\n"  //7262694C  Libr

     "push 0x64616F4C\n"  //64616F4C  Load

     "push esp\n"         //esp now points to the loadlibraryA API ASCII that we just set on the stack

     "push _k32\n"        //push the k32 base address

"call get_eip\n"                        //we need to know where we are at 

                                        //so we get our current EIP position

                "add edx,0x18\n"         //add the edx = eip + 0x18 so that we may end up in a NOP SLED

                                         //without this we sysenter loop

               "push edx\n"              //this is our sysenter return to stack address
               "lea ebp,[esp+0x1C]\n"    //make sure our EBP points to the prior stack frame

                                         //RETURN from Xsys.00401290 to Xsys.004011E7

                                         //completely seperate of the sysenter return we just pushed

               "push [_getproc]\n"       //push the GetProcADdress API

               "mov edx,esp\n"           //SYSENTER requires us to use this esp into edx

                                //here the esp holds our GetPRoc API that we just pushed to stack

                                //now edx holds the API address and needs to in order for sysenter

                                         //to call it correctly

               "pop ebp\n"      //remove that extra pushed GetProcADdress API value from the stack
               "sysenter\n"              //call the GetProcAddress

"nop\n"

"nop\n"

"nop\n"

"nop\n"

"nop\n"

"nop\n"                    //NOP SLED!!!!

"nop\n"                    

"nop\n"

"nop\n"

"nop\n"

"nop\n"

"nop\n"

"mov _ll,eax\n"        //STORE the LoadLibarary Mem Address into variable ll

"add esp,0x10\n"  //cleanup

"push 0x0000004C\n"    //0000004C  L...

"push 0x4C442E4C\n"   //4C442E4C  L.DL

"push 0x4C44544E\n"   //4C44544E  NTDL

"push esp\n"        //esp points to our NTDLL.DLL that we just pushed onto the stack

"call [_ll]\n"     //call the loadlibrary APi to load up ntdll.dll
"mov _ntdllx,eax\n"   //EAX after the call will now hold the ntdll base address set _ntdllx = to eax

                      // [_ntdllx] = 7c90000   [_k32] = 7c80000

"add esp,0xC\n"       //clean

"mov ebp,esp\n"       //clean
"ret\n"   //breakpoint for debugging purposes

"ret\n"   //easy to find a double ret in olly

);

//our basic get EIP method

asm       

(

"get_eip:\n"

"mov edx, [esp]\n"

"ret\n"

);
}

RtlInitUnicodeString then load up ZwCreatefile and my point will be made (that i can use the SYSENTER "go-somewhere trick" to do everything i need

Edited December 11, 2013 by JMC31337

[JMC31337]

I do like the obfuscation of sysenter (you all were right about that obfuscation)

differences between the two:

CPU Disasm

Address   Hex dump          Command                                  Comments

00401367  \. /FF22          JMP DWORD PTR DS:[EDX]                   ; kernel32.GetProcAddress

CPU Disasm

Address   Hex dump          Command                                  Comments

00401367  |.  0F34          SYSENTER

 

 

But the real issue lately with this asm in gcc is that anything done in gcc with asm is concidered a virus by some AV products...

a simple int main {   asm("sysnter"); }   when i tried to see what gmail would say, the exe was called a virus and its not.. upsetting that asm is being called viral.... not that it really matters i'd use C# if i had to write my next virus...

 

 

but this whole sysenter thing got me thinking:

 

How do (or how would) virtual systems treat SYSENTER; Such as :DeepFreeze, VmWare and SandBoxie??

 

Like every other opcode?

 

I noticed that certain VMWARE drivers can be exploited allowing you to bypass the virtualized environment... 

Which is why i wanted to sysenter later on and load up a driver that way i can throw shit at the kernel

 

 

Another side idea i thought about:

 

To create an exe with read write execute mapped sections.. and try to symlink the exe's "driver code" into the kernel .. then use the same exe to pass data thru the symlink into the kernel (driver)   wondering if it can all be done with one file... instead of having to use DDK to create a sys file and DLL to run data into the kernel and dropping those files onto disk

 

going back to the rootkit i wrote awhile back:

OpenSCManager seems to load a driver and we create the service CreateService

IntPtr scHandle

 its just a pointer to a handle.. maybe virualalloc some memory holding our sys driver and pass it off as a handle

virtualallocex some more memory with an embedded dll (if its neccessary ) and pass it off as another handle.. 
 

An exe binded with a sys driver            ...........   one thing and one step at a time

Edited December 12, 2013 by JMC31337

[Peter Ferrie]

If you have privileges to load a driver, then you already have privileges to control everything on the system without the need for any exploit. You are already admin at that point.

[JMC31337]

I see...

So what happens when I'm at a public terminal system and I plug my android into the computer via USB, and the computer goes to install the necessary drivers for me to browse my scard?

It'll pop a window saying contact admin security disabled bla bla message

And yet, I can still use my sdcard without that driver that windows originally went to install

I've had it do that for flash drives too, but I can always still browse my files

[Teddy Rogers]

Probably because they default to the industry standard protocol to be compliant. The drivers are likely for accessing custom features and firmware...

 

Ted.

[JMC31337]

yea thats what i was figuring when i went back to ponder that. So is it possible to say that we could create a driver device "standard" and load it up? since even in a limited user account setting it is getting loaded?

 

And this may be a lil off topic (since I need to finish that ZwCreateFile) : 

If we can use command.com in a limited user setting to access windows' terminal, and further head into system32, could we not create our own "rootkit" HAL.DLL?

 

Their is a checksum verification process but...

Edited December 14, 2013 by JMC31337

[Teddy Rogers]

The drivers will be default system drivers that are already installed with Windows. SuperSpeed USB3.0 drives, for example, are not directly supported in Windows 7 but the drive is still accessible because the hardware is compliant to the USB standard (and backward compatible)...

 

Ted.

[deepzero]

If we can use command.com in a limited user setting to access windows' terminal, and further head into system32, could we not create our own "rootkit" HAL.DLL?

 

 

you dont have write access to %windir%.

[JMC31337]

you dont have write access to %windir%.

 

ohh, just i remember that i was usually able to delete hal.dll and cause a BSOD on next reboot when its deleted

guess a limited user account wont let anyone delete anything in windir... have to keep testing that another time

Edited December 15, 2013 by JMC31337