Exploit-DB #39121
Description: KiTTY Portable 0.65.0.2p (Windows 7) - Local kitty.ini Overflow (Wow64 Egghunter)
Type: local
Platform: windows
Date: 2015-12-29
Author: Guillaume Kaddouch

Exploit:
# Exploit Title: KiTTY Portable <= 0.65.0.2p Local kitty.ini Overflow (Wow64 Egghunter Win7)
# Date: 28/12/2015
# Exploit Author: Guillaume Kaddouch
# 	Twitter: @gkweb76
#	Blog: http://networkfilter.blogspot.com 
#	GitHub: https://github.com/gkweb76/exploits
# Vendor Homepage: http://www.9bis.net/kitty/
# Software Link: http://sourceforge.net/projects/portableapps/files/KiTTY%20Portable/KiTTYPortable_0.65.0.2_English.paf.exe
# Version: 0.65.0.2p
# Tested on: Windows 7 Pro x64 (FR)
# Category: Local

"""
Disclosure Timeline:
--------------------
2015-09-18: Vulnerability discovered
2015-09-26: Vendor contacted
2015-09-28: Vendor answer
2015-10-09: KiTTY 0.65.0.3p released : unintentionally (vendor said) preventing exploit from working, without fixing the core vulnerability
2015-10-20: KiTTY 0.65.1.1p released, vendor fix, but app can still be crashed using same vulnerability on another kitty.ini parameter
2015-11-15: KiTTY 0.66.6.1p released, seems fixed
2015-12-28: exploit published

Description :
-------------
A local overflow exists in kitty.ini file used by KiTTY portable. By writing a 1048 bytes string into 
the kitty.ini file, an overflow occurs that makes Kitty crashing. At time of the crash, EIP is 
overwritten at offset 1036. As all DLLs are ALSR and DEP protected, and rebased, we can only use 
kitty_portable.exe addresses, which start with a NULL. Successful exploitation will grant an
attacker a reverse shell on Windows 7 Pro x64.

Win7  -> Code Execution

Instructions:
-------------
- Run exploit
- Launch KiTTY

Exploitation:
-------------
As EDX register points to our buffer, it seems like using a return address pointing to a 
JMP EDX instruction would do the trick. However this is not the case, because of the address containing
a NULL byte, our 1048 bytes buffer is truncated to 1039 bytes, and an access violation occurs before EIP could be
overwritten:

EAX = 00000041
00533DA2     0000           ADD BYTE PTR DS:[EAX],AL <---- Access violation when writing to [EAX]
00533DA4     00             DB 00

Increasing our initial buffer by 4 bytes (1052 bytes) gives us another crash,
but neither EIP nor SEH are overwritten. We end up with another memory access violation, which although looking
like a deadend, is in fact exploitable:

ECX and EBX points to our buffer
EDX and EDI are overwritten by our buffer

EDI = 41414141
764F8DD2   8917             MOV DWORD PTR DS:[EDI],EDX <---- Access violation when writing to [EDI]

Although we do not have control over the execution flow (EIP), we have at least control of the value written to EDI
at offset 1048. We can write a valid memory address into EDI, allowing the program to continue 
its execution. One such address is the address ESP points to on the stack: 0x0028C4F8.
Let's take a closer look to the code executed:


764F8DB8   BA FFFEFE7E      MOV EDX,7EFEFEFF			<-------- (3) JMP back here
764F8DBD   8B01             MOV EAX,DWORD PTR DS:[ECX]
764F8DBF   03D0             ADD EDX,EAX
764F8DC1   83F0 FF          XOR EAX,FFFFFFFF
764F8DC4   33C2             XOR EAX,EDX
764F8DC6   8B11             MOV EDX,DWORD PTR DS:[ECX]
764F8DC8   83C1 04          ADD ECX,4
764F8DCB   A9 00010181      TEST EAX,81010100
764F8DD0   75 07            JNZ SHORT msvcrt.764F8DD9

764F8DD2   8917             MOV DWORD PTR DS:[EDI],EDX  <------- (1) We start HERE
764F8DD4   83C7 04          ADD EDI,4
764F8DD7   EB DF            JMP SHORT msvcrt.764F8DB8   <------- (2) jump back above

1) Value from EDX is copied to the stack where EDI points to, then EDI is incremented and points to next address
2) The execution jumps back at the beginning of the code block, overwrites our source register EDX with 7EFEFEFF,
overwrites EAX with 41414141 (ECX point to our buffer), restore EDX with 41414141, increment ECX pointing to our
buffer by 4, pointing to our next buffer value, and starting all over again. Also there is a very interesting instruction 
following this code:

764F8DD2   8917             MOV DWORD PTR DS:[EDI],EDX    <------- We are HERE
764F8DD4   83C7 04          ADD EDI,4
764F8DD7   EB DF            JMP SHORT msvcrt.764F8DB8
764F8DD9   84D2             TEST DL,DL
764F8DDB   74 32            JE SHORT msvcrt.764F8E0F
764F8DDD   84F6             TEST DH,DH
764F8DDF   74 15            JE SHORT msvcrt.764F8DF6
764F8DE1   F7C2 0000FF00    TEST EDX,0FF0000
764F8DE7   75 16            JNZ SHORT msvcrt.764F8DFF
764F8DE9   66:8917          MOV WORD PTR DS:[EDI],DX
764F8DEC   8B4424 08        MOV EAX,DWORD PTR SS:[ESP+8]
764F8DF0   C647 02 00       MOV BYTE PTR DS:[EDI+2],0
764F8DF4   5F               POP EDI
764F8DF5   C3               RETN							<------- We want that !

This code block happily copies our entire buffer chunk by chunk to the stack, and is later followed by a RET instruction.
If there could be a way to copy our buffer on the stack and make ESP pointing to a predictable part or our buffer, the RET would
give us the control of the execution flow.

When the copy operation is finished, the code crashes again and this time EIP is overwritten with 41414141, and ESP
has the address 0x0028C500 pointing toward the near begining of our buffer (offset 8). The RET has been reached, wonderful :-)

However, we cannot write a usable address here to jump somewhere else as a NULL byte would truncate our entire buffer and no 
crash would occur... The goal here would be to find the correct address to put into EDI so that ESP will point to the end
of our buffer, where we will be able to use another address, containing a NULL, to jump somewhere else and
take back control of the execution flow. However our buffer is already terminated by a NULL byte address for EDI.

1) We cannot make ESP points anywhere in the middle of our buffer, as we can only use addresses containing a NULL
2) We cannot add another valid NULL containing address at the end of our buffer, as a st