Lock'n'load. History of vulnerabilities in the Counter Strike series - Part 2

Introduction

In this part of the article, we will thoroughly examine vulnerabilities found in various games of the Counter-Strike series. Over the years, numerous vulnerabilities have been discovered, each affecting the security of players in its own way.

Valve, the developer of the Counter-Strike series, actively supports a Bug Bounty program, offering rewards for finding and reporting vulnerabilities in their games. This initiative has allowed the identification of numerous security issues. We will review some of these vulnerabilities reported by security researchers through the Bug Bounty program.

Additionally, a significant number of vulnerabilities have been discovered and published by the community of enthusiasts and players. Forums and specialized websites have become platforms for discussing and analyzing security issues in Counter-Strike games. Many researchers also shared their findings through YouTube videos, demonstrating exploitation methods for these vulnerabilities.

However, it should be noted that the most serious and potentially dangerous vulnerabilities often remain hidden. They may be used privately by small groups of hackers and never become public knowledge. Additionally, Valve decides which vulnerabilities to disclose within the Bug Bounty framework publicly. Therefore, the most severe vulnerabilities may be known only to a very narrow circle of individuals.

GoldSRC engine: Counter-Strike 1.6

History of Creation

Counter-Strike 1.6 is an iconic game in the first-person shooter genre. Its history began in 1999 when enthusiasts Minh Le (Gooseman) and Jess Cliffe created a modification for Valve's Half-Life. The game quickly gained popularity due to its team-based tactics and realism.

In 2000, Valve noticed the success of the modification and proposed a collaboration, leading to the release of the commercial version of the game. Counter-Strike 1.6, released in 2003, became one of the most popular versions due to improved graphics, new maps and weapons, and enhanced gameplay mechanics. This version secured its status as a cult classic and became the standard for esports competitions for many years.

Counter-Strike 1.6 used GoldSrc, a game engine developed by Valve based on a modified Quake engine. Debuting in 1998 with Half-Life, it provided support for numerous subsequent games and modifications -Counter-Strike, Team Fortress Classic, and Day of Defeat.

Vulnerabilities

Publicly Disclosed Vulnerabilities

Although Counter-Strike 1.6 was released in 2003, there was almost no information about its vulnerabilities until the 2010s. This can be explained by several factors. Firstly, in the early 2000s, the internet was just beginning to develop, and access to information was limited. Secondly, enthusiasts and security researchers did not have reliable ways to report found vulnerabilities to Valve. Thirdly, the culture of information security and its popularization were in their infancy. These factors together led to the fact that information about Counter-Strike 1.6 vulnerabilities started appearing only with the growth of the internet and the development of security communities years after its release.

The first exploit I found is dated 2008, seemingly a DoS through login on no-steam Counter-Strike 1.6 servers.

However, most information about early vulnerabilities appeared around 2013 when Valve published the first SDK for Counter-Strike 1.6.

One of the first vulnerabilities reports said,  that sometimes the server crashes if you enter the command cl_setautobuy 12345678912345678912345678912345 in the console. While this doesn't show a direct security threat, it is likely related to buffer overflow.

An interesting vulnerability is described in this issue on GitHub. The user mentions a buffer overflow vulnerability related to parsing demo files. Length bytes are read into a 256-byte buffer without any boundary checks. If the length exceeds 255, other data on the stack will be overwritten.

Another buffer overflow vulnerability leading to code execution is well demonstrated in this report from HackerOne.

The vulnerability is in file extension checking, which is performed on the substring *.HL?, checking the entire file name rather than just its end. This allows bypassing the check by specifying a custom extension.

For example, when unpacking fakeresource.sav, the file name could be test.HL1.dll.

The .dll file will be unpacked and loaded into the client's memory, allowing arbitrary code execution.

Example of the exploit in the video:

Another example of RCE through buffer overflow is provided in this report.

The issue arises when allocating memory for certain game structures during client-server communication.

The first packet, svc_deltadescription, describes the memory structure for entities such as event_t and weapon_data_t, including the type and offset of fields. The next packet, processed by the DELTA_ParseDelta function, fills these structures upon receiving the corresponding packets. The problem is that this function does not check if the sum of field_offset and field_size exceeds the allocated memory boundaries for these structures, leading to a buffer overflow.

The researcher managed to find a ROP chain and achieve code execution.

Unfortunately, VALVE did not fully disclose this report, leaving only a brief summary.

Since it is impossible to describe all vulnerabilities in one article, I have compiled a small table of disclosed vulnerabilities from HackerOne.

Discussing buffer overflow vulnerability in CS 1.6 is incomplete without mentioning the article written by researcher Grant Hernandez.

The article is quite extensive, and if you are interested in this topic, I recommend reading it.

Grant started by fuzzing the engine through generating and loading various BSP files (game map files).

He automated the process, getting reports whenever the debugger noticed the `hl.exe` engine crashed with an error.

After several hours of fuzzing, he found more than 40 potential vulnerabilities, one of which led him to RCE.

The article describes in detail the process of finding the vulnerability, creating ROP chains using mona, and solving numerous problems during the exploit development.

The attack vector is quite simple:

1. The player connects to the server.

2. The server provides the player with a map file.

3. The player downloads and parses the map.

4. During parsing, malicious code is executed on the player's computer.

In the video, the player joins the map, and as proof of concept, the console opens.

39% of Servers Compromised

In 2019, DoctorWeb published an article investigating the activities of the Belonard trojan. The trojan infected players' devices and used them to promote its own game servers.

Owners of popular game servers often earn money by selling various privileges to players or advertising their servers. Some pay third-party companies for server promotion. However, Belonard resorted to illegal methods to promote its servers by infecting players' devices and using them to create a botnet.

The basis for this trojan was remote code execution (RCE) vulnerabilities in both official and pirated game clients. Using these vulnerabilities, the trojan infected players' devices, replaced the list of available servers with fake proxy servers, and redirected players to infected servers. Thus, when connecting to one of these servers, the player's device also became infected with the trojan.

Trojan.Belonard consisted of 11 components and acted differently depending on the client used. In the case of the official client, the trojan used an RCE vulnerability to infect the device. If the player used a pirated client, the trojan infected the device immediately upon launching the game. After infection, Trojan.Belonard downloaded additional modules onto the device to ensure its presence in the system and spread the trojan to other devices.

Trojan.Belonard.1, Trojan.Belonard.5, and other components ensured its installation and operation on the infected device. The trojan installed itself into the system, changed settings and files to hide its presence, and connected to a command server to receive further instructions and updates.

Trojan.Belonard created proxy servers on infected devices, which appeared with low ping and were at the top of the server list in the game client. This attracted other players who, by connecting to these servers, also became infected with the trojan. Thus, Belonard created a botnet that made up a significant portion of all CS 1.6 game servers. According to DoctorWeb analysts, about 39% of all servers were part of this botnet.

As noted by DoctorWeb researchers, the trojan contains an error that allows detecting fake game servers. Some of them can be identified by the name in the "Game" column. A fake server will have the string "Counter-Strike n", where n can be a number from 1 to 3.

DoctorWeb took measures to neutralize the trojan and stop its spread. In collaboration with the domain registrar REG.ru, they suspended the delegation of domains used by the trojan developer, interrupting the operation of most malware components. The Dr.Web virus database was also updated to detect all components of Trojan.Belonard.

Some materials used are sourced from the article by Doctor Web, Ltd.

RCON

RCON (Remote Console) deserves special mention as it is a tool for remote server administration, allowing administrators to execute commands on the server through the console. Using RCON, administrators can ban players, change maps, and perform other administrative tasks. Access to RCON is obtained through the game client's command line, where the RCON password is entered, and then commands are sent directly to the server.

In 2013, many servers were attacked using a vulnerability in RCON. Administrators on forums were puzzled about why their servers' names were changed to "www.raiz0.org".

Most attacks were likely conducted through simple brute force methods, but there were also more sophisticated exploits.

Here's one example:

In the future, patches and custom mods were released to close vulnerabilities in RCON.

An interesting vulnerability is related to the mapcyclefile function.

The CS 1.6 server has a map cycle function, i.e., automatic map changes at a specified interval. This function relies on the data from the file specified in the cvar mapcyclefile variable.

Any user with RCON access to the server can set this variable to an arbitrary value.

An attacker could do the following:

1. Set the cvar mapcyclefile through RCON.

2. Execute the listmaps command in their game console.

Example:

This vulnerability could lead to arbitrary file reading and writing, potentially resulting in RCE (Remote Code Execution).

Author: @mk1337

To enhance your company's security level, contact ONSEC.io team

Mail us at [email protected],
leave a request for a free consultation
or visit our website www.onsec.io
to learn more about our pentesting services and how we can help protect your game from cyber threats.