JMC31337 Posted December 5, 2013 Author Posted December 5, 2013 (edited) 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 Posted December 6, 2013 Posted December 6, 2013 well, if you understand all that i really dont see what the problem is? sysenter == jmp [edx] What are the next steps?
JMC31337 Posted December 6, 2013 Author Posted December 6, 2013 (edited) Likewise....As a warm-up, use SYSENTER to load up NTDLL or even ntoskrnl in user spaceGrab 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 warmupUltimately 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 Posted December 6, 2013 Posted December 6, 2013 So i guess this might be able to be used to elevate privileges maybe
JMC31337 Posted December 6, 2013 Author Posted December 6, 2013 (edited) 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 Posted December 6, 2013 Posted December 6, 2013 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 Posted December 6, 2013 Author Posted December 6, 2013 (edited) "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 Posted December 7, 2013 Posted December 7, 2013 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 Posted December 7, 2013 Posted December 7, 2013 you're more likely to fly to the moon LOL whats the point of this topic?
JMC31337 Posted December 7, 2013 Author Posted December 7, 2013 (edited) 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 yetAnd 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 ZwCreateFilei end up at:CPU DisasmAddress Hex dump Command Comments0048C4D6 B8 25000000 MOV EAX,250048C4DB 8D5424 04 LEA EDX,[ESP+4]0048C4DF 9C PUSHFD0048C4E0 6A 08 PUSH 80048C4E2 E8 EAA2FFFF CALL 004867D1 then follow along to:CPU DisasmAddress Hex dump Command Comments004867D1 6A 00 PUSH 0004867D3 55 PUSH EBP004867D4 53 PUSH EBX004867D5 56 PUSH ESI004867D6 57 PUSH EDI004867D7 0FA0 PUSH FS004867D9 BB 30000000 MOV EBX,30004867DE 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 Posted December 7, 2013 Posted December 7, 2013 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 Posted December 7, 2013 Author Posted December 7, 2013 (edited) LolLet'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 syscallI 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 Posted December 8, 2013 Author Posted December 8, 2013 (edited) 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 Posted December 8, 2013 Posted December 8, 2013 (edited) 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 Posted December 9, 2013 Author Posted December 9, 2013 (edited) 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 C0000005ECX 77C61AE8 msvcrt.77C61AE8EDX 7C90E514 ntdll.KiFastSystemCallRetEBX 00004000ESP 77C61AEC msvcrt.77C61AECEBP 0022FF78ESI 0012B3FCEDI 7C901000 ntdll.RtlEnterCriticalSectionEIP 7C97E860 ntdll.7C97E860 CPU StackAddress Value ASCII Comments77C61AEC 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 procedureCPU - main thread EAX C0000005ECX 00401290 Entry point of procedureEDX 7C90E514 ntdll.KiFastSystemCallRetEBX 00004000ESP 00401294 Syspop.00401294EBP 0022FF78ESI 0012B3FCEDI 7C901000 ntdll.RtlEnterCriticalSectionEIP 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 Posted December 9, 2013 Posted December 9, 2013 (edited) 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 Posted December 11, 2013 Author Posted December 11, 2013 (edited) its the only way edx,espsysenter 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 Posted December 11, 2013 Author Posted December 11, 2013 (edited) I do like the obfuscation of sysenter (you all were right about that obfuscation)differences between the two:CPU DisasmAddress Hex dump Command Comments00401367 \. /FF22 JMP DWORD PTR DS:[EDX] ; kernel32.GetProcAddressCPU DisasmAddress Hex dump Command Comments00401367 |. 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 CreateServiceIntPtr scHandle its just a pointer to a handle.. maybe virualalloc some memory holding our sys driver and pass it off as a handlevirtualallocex 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 Posted December 13, 2013 Posted December 13, 2013 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 Posted December 14, 2013 Author Posted December 14, 2013 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 messageAnd yet, I can still use my sdcard without that driver that windows originally went to installI've had it do that for flash drives too, but I can always still browse my files
Teddy Rogers Posted December 14, 2013 Posted December 14, 2013 Probably because they default to the industry standard protocol to be compliant. The drivers are likely for accessing custom features and firmware... Ted.
JMC31337 Posted December 14, 2013 Author Posted December 14, 2013 (edited) 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 Posted December 14, 2013 Posted December 14, 2013 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 Posted December 14, 2013 Posted December 14, 2013 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 Posted December 15, 2013 Author Posted December 15, 2013 (edited) 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
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now