Cryptography

TeamSpeak 2 Session Hijacking

(c) Evonide

Hey folks, today I write about a (probably unknown) TeamSpeak 2 session hijacking vulnerability. TeamSpeak 2 is a voice-over-Internet Protocol (VoIP) software that was written in Delphi. Although there is already a newer version (TS 3) one can still find more than 1000 online TS 2 servers some of which are still used for voice communication and in addition we can always learn something even from software that is not “mainstream” anymore. Before we start let’s have an overview about what is possible by exploiting this vulnerability.

Known security issues

Over the time the following issues have been found:

  • 2010: Remote code execution (found by nSense):

    The vulnerability is caused due to an error when processing certain packets and can be exploited to corrupt memory by e.g. sending a specially crafted TS2T_VOICE_DATA_CELP_WINDOWS_5_2 packet. The vulnerability is confirmed in version 2.0.32.60 for Windows.

  • See CVE Details for about 4 further relatively boring issues.

Security concept

User groups

There are 6 possible user groups: Server Admin (SA), Channel Admin (CA), Operator (O), Voiced (V), Registered (R) and Anonymous. A user can be assigned to more than one group e.g. (R SA CA) (c.f. with screenshot above) and all groups have their own customizable permissions (e.g. SA rights normally invoke the right to kick a player from the server).

Binary protection

There are no security measures against reverse engineering except a UPX compression. The command ‘upx -d’ allows to decompress the binary in an instant. For this article we will refer to the upx-decompressed 2.0.23.19 server binary.

TeamSpeak 2 Protocol

Like many other VoIP softwares TS also uses a UDP based protocol. Since we focus on how to hijack a foreign session we need to filter out all relevant parts first. Once a client has connected most packets will contain the following header:

Regular TS 2 packet header
Class Function Session key Client id Sequence number Resend counter Fragment number CRC32
2 bytes 2 bytes 4 bytes 4 bytes 4 bytes 2 bytes 2 bytes 4 bytes
not relevant e.g. 0xAE01 for text messages authenticates a client number that gets incremented after each packet only relevant for big packets checksum

At this point it becomes obvious  that in order to impersonate someone we need the correct session key. In addition there is an annoying sequence number that also has to be correct (this is not obvious and makes brute-forcing the session key infeasible).

Session hijacking

Our first goal is to get the correct session key. A client gets a new session key after each new connection establishment. Another observation we make is that the session key is always only 3 bytes long. Let’s have a closer look into where this session key comes from.

Basic binary analysis

Some debugging with IDA and OllyDbg reveals the following function (found @004036BC).

To generate a new session key this function does two things:

  1. Update the number random_number.
  2. Use the parameter mul_param in combination with this random number for session_key generation.

Some debugging reveals that mul_param is always 0x00FFFFFF. If random_number is 0xAABBCCDD the session_key will thus become something like 0x00AABBCD (random_number is shifted by one byte and the multiplication leads to some changes in the last bits). This explains our observation that although there are 4 bytes reserved for the session_key it will always only occupy 3 bytes. To complete our overview the next thing we need to find out is how random_number is initialized. A scan for all referenced usages reveals the following function (found @004030D0).

This seems to be an internal Delphi function. Let’s look into its documentation.

The Randomize procedure is used in conjunction with the Random function. It repositions the random number generator in its sequence of 232 pseudo random numbers. Randomize uses the time of day as the seed for this repositioning, so should provide a reliable method of creating an unpredictable sequence of numbers, even if they are a part of a predetermined sequence.

This function is only called once the server is started in order to initialize random_number. Both functions have to do with the Delphi internal pseudorandom number generation that is a Linear congruential generator (LCG) and are used in a commonly known way to generate pseudo random numbers: 1) Setting a seed 2) Calling the random function. However it is known that using a Linear congruential generator is not secure for cryptographic usage since about 1987 [ref]. By the time I analyzed this issue I didn’t know these things and found out how to break this pseudorandom number generator (PRNG) on my own.

Breaking an LCG based PRNG

LCG setup

Let’s have a look at the mathematical definition of an LCG. An LCG is defined by the following recurrence relation:

X_{n+1}=\left( a*X_n + c \right)~~\bmod~~m

X sequence of pseudorandom numbers
X_{n} n-th random_number (X_{o} is called the seed)
a multiplier (in our case 134.775.813)
c increment (in our case 1)
m modulus (in our case we have GF(232) so it is 4.294.967.296)

Altogether Delphi and TS 2 use the following LCG:

X_{n+1}=\left( 134.775.813*X_n + 1 \right)~~\bmod~~2^{32}

Remember that our goal is to be able to make predictions about all generated session keys. This goal can be reached by finding X_{0} which allows us to compute the complete sequence. At this point we need to focus on what we are given. In addition to our own session_key we also know n (the number of already generated random numbers) because it corresponds to our client_id. The n-th session_key is a transformed version of X_{n}:

session\_key_{n}=X_{n}*2^{24}~~\bmod~~2^{32} (c.f.  generate_new_session_key source code).

Since this transformation mostly is a one-way function we loose information here. If we are given the n-th session_key it is thus impossible to retrieve its correct X_{n}. Luckily by connecting a second time and retrieving the (n+1)-th session key we can determine X_{n} exactly (having two consecutive session keys compensates this information loss). By retrieving X_{n} we can already predict all future session keys. However since we also want to get correct session keys for already connected users we still have to aim for X_{0}.

Seed computation

Surely one approach is to brute-force all 232 possible X_{0} and to each time check if the n-th generated number matches our X_{n}. Let’s not hesitate but think about a more elegant solution first. With some reflection we can reformulate our given problem to: X_{n}=\left( e\_multiplier*X_0 + remaining\_polynom \right)~~\bmod~~2^{32}

e_multiplier exponentiated multiplier (a^{n} where a is 134.775.813)
remaining_polynom a^{n-1} + a^{n-2} + ... + 1

By solving the equation for X_{0} we finally get:

X_{0} \equiv \left(X_{n} - remaining\_polynom \right) * e\_multiplier^{-1}~~\bmod~~2^{32}

We have to be careful with inverse numbers since we are in a GF (c.f. Modular multiplicative inverse). e\_multiplier^{-1} only exists, because the multiplier used by Delphi has some specific features. At this point I would like to thank my colleague Dario Weißer for his kind and insightful help regarding these cryptography issues. The following pseudocode can be used to deterministically retrieve the correct seed given only the sequence position n and its random number X_{n}.

By using an algorithm like this we can immediately get  X_{0} and compute the complete LCG sequence.

Final steps for hijacking

Consequently the things we need to do in order to hijack a specific session is:

  1. Connect to retrieve a session_key and a client_id n. Disconnect afterwards
  2. Connect again to retrieve another session_key.
  3. Use both keys to get the correct n-th random_number.
  4. Use the target’s client_id, n and the n-th random number to calculate the target’s session_key (using get_lcg_seed).
  5. Brute-force the correct sequence number by sending text messages as the “target” to our client. Once we receive a text message we know that we have found the correct session key and sequence number.

The puppet master

There are some interesting things we can do after having successfully hijacked a session. Two examples for such are:

  • Privilege escalation by granting server admin rights to one’s client
    Only possible if a server admin is allowed to give server admin privileges to other users (this is the case by default).
  • Voice hijacking
    Faking the voice’s origin becomes feasible, too. The best part here is that the target is not able to notice that it has been hijacked (there is no point for the server to send voice packets back to their origin).
Limitations

One major limitation is that we can’t receive packets that are directed to the hijacked target. Thus we can’t intercept text messages or voice packets that have been sent privately/only to this target.

At this point I suggest that you have a closer look at the video in the beginning again, most things should make sense now.

Some remarks

My favorite sentence of the Delphi documentation is “should provide a reliable method of creating an unpredictable sequence of numbers” (c.f. “randomize” documentation). Claiming to generate unpredictable numbers is NEVER a good idea… Keeping the same (vulnerable) PRNG algorithm for such a long time isn’t a good idea either.

Conclusion

In conclusion we can learn the following things:

  • Previous to generating any numbers please inform yourself about what PRNG algorithm you are really using and about how it has to be properly used.
  • Please stop using TeamSpeak 2 (why are there still so many servers up and running?) and move on to TeamSpeak 3 already…

References

About the author

Ruslan Habalov

Is dealing with Information Security issues for more than 10 years. Likes sophisticated challenges and is additionally interested in Artificial General Intelligence. [Read more...]

Add Comment

Click here to post a comment