Team Vexillium
Security Advisory

Gadu-Gadu and Tlen IM's
Threat level:
Gadu-Gadu 7.7 [Build 3725], prior and later versions may also be affected. Tlen, prior versions may also be affected

NOTE: Described vulnerabilities and bugs are all half a year old, I do NOT guarantee they still exist or have been fixed.

Gadu-Gadu BUG #1 - Registration Token Protection Bypass

The script allowed users to register a number of UINs without any need to read the captcha content. Though the script had to be given the tokenid and tokenval parameters, these values weren't properly checked. If we replaced the original 16 byte tokenid value with some random piece of data and set tokenval to a null value, we were given a newly registered number, not even being asked to look at any token image.

Gadu-Gadu BUG #2 - Remote File Storage

This bug made it possible to remotely store files on an unsuspecting victim's computer. There were only two conditions - the victim must have had the attacker's UIN listed in his contacts and had to have the image-sending option enabled (image limit > 0kB). The size of file we wanted to send was restricted with the imagesize limit set by the victim - but we could easily divide a specific file so as to make every part of it smaller from the general limit. Once we sent a file, we could get it back, only if we knew the size and CRC32 checksum of the file.

All the sent files are put to "%GG_USER_PROFILE%\imgcache" directory. We sent the file using standard image-sending facility ( - gg_msg_richtext_image and gg_msg_image_reply structures were used.

File receiving process was possible to be done using gg_msg_image_request struct. Protocol specification claimed this kind of packet was used only after receiving a gg_msg_richtext_image structure, but if we sent it ourselves without waiting for any gg_msg_image_request, than the original client would send a response with the file content, or a packet indicating there is no file with given size/CRC32. A Proof of Concept program for this issue had been created.

Gadu-Gadu BUG #3 - User Status Information Disclosure

This issue was mostly based on BUG #3. If the user had some number listed in his contats, a person logged using this number was able to check if the user was offline or just had the Unvisible Status option enabled. It could be done by sending a GG_SEND_MSG packet with gg_msg_image_request structure inside. If the destination number responsed using gg_msg_image_reply, it must have been online (and just using the invisibility option).

Gadu-Gadu BUG #4 - Remote Outgoing Message Denial of Service

An attacker listed in the victim's contacts could make it impossible for the victim to communicate with other Gadu-Gadu users, by sending a GG_SEND_MSG packet containing a specially crafted gg_msg_image_request structure. Its definition looks like:

struct gg_msg_image_request { char flag; /* 0x04 */ int size; /* size */ int crc32; /* checksum */ };

If we appended some additional bytes after this structure, it was treated as data of the request for another image - sending 16 bytes after the 0x04 flag was interpreted as a double image request, 8 bytes for each. Gadu-Gadu client sent a separate response for every request, so when there were 5 integer pairs after 0x04, GG sent 5 msg packets.

Since the maximum message length was something like 2000 bytes, the attacker was allowed to send about 500 requests in one packet. Then, the victim's client tried to send a response packet for each integer pair - 500 messages in one moment. After receiving that amount of packets from one number in several seconds, the GG server disabled the ability to send messages to any users for some time.

Gadu-Gadu BUG #5 - Registration Token Protection Image Weakness

The gif image we were given by was indeed not so easy to be read by a computer program. However, its work could be made much easier because of a small thing - the palette in image header was filled in a very straightforward way... Noise's colors put first, then the first letter's colors, the second's and so on. What it means is that taking the RAW gif bytes (offsets of particular colors) could be used to get rid of the CAPTCHA background noise (curves,dots), tell the letters apart, and generally make the picture's structure analysis much simpler.

Tlen BUG #1 - Message Sendtime Spoofing

When one user sends a message to another, unavailable one, it is queued on the server which waits until the dest. user logs in. When he does, he receives the original message with a small appendix inside:

<x xmlns="jabber:x:delay" stamp="YYYYMMDDTHH:MM:SS"/>

The server itself is reponsible for adding this tag to the message BUT if one of the users does it, it isn't cut out from the message, so it is possible to make anybody think a message was sent the time we want him think.

Tlen BUG #2 - Mass User Request Denial of Service

Tlen supports many kinds of requests one user can send to others (subscription, alerts etc). Nor the communicator neither the server had any kind of protection that would stop sending big amounts of such requests. If the victim didn't have the proper options set, his computer could be made unable to work on, because of Tlen trying to create and display hundreds (thousands?) dialog boxes. Although it's a very simple method of causing DoS, it had been tested on several average computers and worked well, making the user reboot his OS.

Tlen BUG #3 - Long Status Denial of Service

There was a possibility to remotely disconnect a particular user from server, by setting a status with proper description. It's a fact that the length of desc. text cannot be as long as we only want, but the exploit takes advantage of the fact that when a 1 byte long ' character is sent to server, it is then transformed to 13 bytes long &amp;amp;#39; string, thus letting us send a 13 times longer text that the maximum is. After a long string made of ' chars was received by the client, some exception occured (no deeper analysis made) and the client reconnected. After this, server sent the description once more, one more reconnect and so on. The only condition was that the victim must have had the attacker's number in his contact list.


This document and all the information it contains is provided "as is", without any warranty. Author is not responsible for the misuse of the information provided in this advisory. The advisory is provided for educational purposes only. Permission is hereby granted to redistribute this advisory, providing that no changes are made and that the copyright notices and disclaimers remain intact.