For nearly two years, I’ve been playing online poker on the GGNetwork platform via the 7XL skin site. I believe it’s a fun platform to play on, and there’s usually plenty of activity on the web. Those of you who have read my prior Cardplayer Lifestyle pieces know that I have strong feelings about cyber security in general and gaming security in particular. This essay is the outcome of a detailed technical examination of the GGNetwork gaming protocol that I did over around 30 hours (net). My results have now been confirmed by Hank Nussbacher, a fellow cyber security specialist, as noted at the end of this post.
Prior to beginning my inquiry, I had a lot of “WHAT IF?” questions running through my head. I had entirely believed the GGNetwork to be safe by all criteria, but I had grounds to fear that their security method was defective. Before I go on to discuss the nature of my inquiry and my results, I want to be quite clear:
I do not believe I was cheated in a GGNetwork game or competition. This post is not intended to be a rant against online poker, but rather to highlight certain security and privacy concerns that operators may have overlooked while creating their systems. The major goal of this post is to show what and why online game security should look like.
Configuration of a network
Let’s start with the network configuration and some thoughts on how online poker businesses are likely to structure their operations:
Server side – The server side of the program is in charge of both the “Back Office” operation and the actual online poker game. When players connect in, the server must recognize them, enable them to choose a table, enter a tournament, deal the cards, and control the game flow. Most likely, an operator will distribute all server-side duties among many servers. For example, one server will manage lobby operations and login, another server would handle money transactions, and numerous more servers will handle game operations, sharing the burden of the games among themselves.
Client – The client side is the software that we all use on our PCs, Macs, and mobile devices. The GGNetwork software or one of its skin sites is referred to here (like 7XL).
Protocol – A protocol is a collection of rules and messages (format) that the client and server must follow in order to “speak to and understand each other” in any client-server architecture. The software designers/programmers establish the protocol. Thus, if the server gives two cards to the player, it will send a message across the network informing the client that these are the cards being dealt to the player for that specific hand. Protocols exist to create order in the communication pandemonium that is the internet, which is a mash-up of numerous sub-networks and many other servers that connect with each other at any one moment.
My little home lab setup included the following components:
A standard client computer that runs the 7XL (GGNetwork) software.
A Sniffer is a computer that listens in on the conversation between my poker client and the servers.
A router that allows my network and the internet to communicate with one another.
Tables are being tapped
The names of the servers to which the client is attempting to communicate were the first item I noticed throughout my study. Each server on the internet has a “IP address,” but since most people don’t remember IP addresses, we assign the servers names. These are known as domain names (for example, CNN.com), and the first thing I did was map the domain names that the client is attempting to discover in order to communicate with the servers.
I just tapped the client communications to do this. Once my tap was activated, I discovered multiple servers that the client is communicating with, as well as various domain names and IP addresses. I won’t go into detail about all of the names I noticed, but the one I opted to look into was tables-ggn.live, which resolved to the IP address: 172.65.231.214
I filtered the tap data after starting to tap communication between my client and the server to display just communication arriving from this address to my client and going from my client to this address.
When I clicked to open a game table, the client began communicating with this server, and I immediately noticed that the communications between the client and the server were not fully encrypted, allowing me to read clear text messages containing my online poker screenname (“The Hacker”) as well as my real name (Ezra Eddie Harari) as registered on the 7XL platform.
I had no idea why my actual name displayed there, but the first issue I uncovered was that the server transmits my client the registered screen name and real name of each player who uses the table’s chat function:
Image I: A screenshot from my Sniffer computer showing an information packet to the conversation with the phrase “Hello World” and my screenname and true name.
When one of the players or observers is conversing, this message is delivered to all players and spectators at the table.
I was astonished that the communications between the client and the table server were not encrypted, and I was even more surprised to see my actual name with my screen name inside the packet, since the client never displays the real names of chatters.
This first observation prompted a slew of doubts in my mind about the network’s gaming security. The fact that the chat chats are not encrypted and that the “additional data” of my true identity is communicated to all of the players and spectators at the table indicated to me that my inquiry would yield more strange results.
Remember that each packet sent or received by my client travels a long distance through the internet, and that any middleman anywhere in the world (e.g., internet service provider [ISP] or telephone company) who participates in routing communications between my client and the table server can see this message. As a result, I decided to use the protocol to try to understand more about what was going on during the game, i.e., to thoroughly investigate the dialogue between the server and the client.
The onus is on you to take action.
Looking at the transmitted packets, I found a pattern of resemblance among the packets, specifically:
The value of the first four bytes was connected to the size of the data included inside the packet.
The value of the following four bytes varied from packet to packet, but I kept observing multiple distinct values.
Based on my past knowledge in the cyber security industry, I deduced that this was a “Message type:” code, which informs the client about the sort of data included inside this packet. Another 4 bytes continued accumulating with each packet, and I assumed it was a message ID or some type of timestamp.
I grabbed every form of communication I could find and attempted to decipher the data contained inside it. I discovered that because the communications were not encrypted and there was no “trust” relationship between my client and the table game server, I could perform MiTM (Man in the Middle) attacks against the client, allowing me to see and change the communications between the server and the client without the client knowing.
For example, I noticed that the message type 0XAF0F0000 (Hexadecimal value) means: player action, and that the server utilizes this message to inform the client of which player acted and what action was taken. This would cause the client to update the user interface, informing the players about who acted and what action was performed.
Image 2: A sample “activity packet.” The action code is located at offset 0x47 (marked in green).
Here’s a brief guide to deciphering the code: 0x1 means check, 0x2 means call, 0x3 means bet (first in), 0x4 means raise, and 0x5 means fold.
When the action includes data, the packet will contain extra data. If the value is 0x3 (“bet”), the amount of the bet will appear a few bytes following the action code.
A Basic Exploitative Play
At this point, I realized that not only was the conversation not encrypted, but the player’s actions were also not encrypted – and so potentially vulnerable to manipulation. “What if I act as a man in the middle and modify the packet received from the server before it reaches my client?” I reasoned. Will the customer demonstrate the true action? Would it notice if the package had been tampered with? Or will it display the action I’ve maliciously chosen to feed it?
Because this isn’t a completely technical post, and its objective is to discuss my experiments and therefore strive to enhance the security of the GGNetwork, I’ll leap to the conclusion without going into detail about how I carried out my MiTM attack: I was able to modify the packet and (falsely) inform the customer that a player had folded his hand when, in reality, he was betting.
Keep in mind that I am not arguing that this may influence the result of the hand since the server “knows” the true action and chooses who the winner is. However, I could conceivably trick a player into believing that the activity on the table transpired differently than it really did. Furthermore, any attacker with access to the client network (which is tough, but picture a dorm of college kids all playing GG on the same Wifi network) might do it with little effort.
This suggested to me that not only is the game played over a non-encrypted (clear text) communications channel, but that no validation is performed by the client to guarantee that data received from the server is indeed from the server and has not been tampered with. An attacker that targets a specific player may also get MITM capabilities remotely. There are numerous forms of attacks in which an attacker acquires this capacity while not being on the same network as the client.
You can only play the cards that are handed to you.
Playing with client visibility was entertaining, but not yet lucrative. It would be foolish to modify the game flow, since after a few hands, players would likely discover that there are significant disparities between what is going on in the hand and the result of the hand. For example, if I “forced” a player to fold in my test setting and he still won the pot, I’m sure this would have triggered some red lights.
As a result, learning that the acts are not encrypted is eye-opening (mostly for building accurate poker bots without the need to do heavy image processing).
I was curious whether I could examine the client-server conversations and figure out what cards were being dealt.
I discovered that message type 0x45110000 really delivers the cards to the player at the start of the hand. It only sends the client the cards of the specific player (not all player cards); but, it sends them in plain sight (clear text) so that anybody on the local network can comprehend what they are and actually “SEE” the other players’ hole cards.
In other words, the ISP and any other service provider that processes packets on their route to the ultimate destination may simply filter those packets, allowing them to view the players’ identities and cards in real time. Someone on the user’s network might quickly tap his cards using a simple MiTM approach, and hackers could get such capacity remotely if they were targeting a particular player.
The cards are represented by a number between 0 and 51 (0x0 to 0x33 in hex), with 0x0 representing the deuce of clubs, 0x1 representing the deuce of diamonds, and so on.
Here are two screenshots of the hand, as well as the packet that carried the data:
Image 3: 0x45110000 (message type) in purple, and at the bottom in green, 02=number of cards dealt, 0x2b = Queen of spades, and 0x21= Ten of diamonds.
Image 4 was captured at an Omaha table. The message code 0x4511000 appears again in purple. The 0x04 (in green) represents the number of cards handed to the player, while the 0x0C represents the 6 of spades. 0x16 represents the 7 of hearts. 0x05 represents the 3 of diamonds while 0x13 represents the 5 of clubs.
Conclusions
In this essay, I revealed that there are significant gaps in game security inside the GG Network architecture.
Because there is no encryption on the game channel, anybody on a player’s network (Wifi / Wired) and any uplink provider may observe the player cards in real time or affect the game flow for a particular player he can watch.
There are various circumstances in which the online poker game might be influenced remotely if the interactions between the client and the game server are not encrypted.
The job of delivering a data packet from point A to point B over the internet involves many different firms and employees. Any of these firms may see whose person is playing in real time and what cards the player has at any given moment.
Finally, experienced hackers who are after a specific player may attain this skill remotely in a variety of methods.
Hank Nussbacher, a fellow cyber security specialist, agreed.
Despite Eddie’s major security concerns with the GGNetwork, I will continue to play on the site since my worry is not of an ISP but of someone on my Wifi network. In addition, I only play for small stakes.
Even though my home network is closed and wired, and my wife’s Wifi network is secure, I would not want to play on the GGNetwork platform when staying in a hotel or visiting a university campus.
End-to-end encryption would be the greatest and clearest method for swiftly eliminating this sort of security vulnerability.
Hank Nussbacher has over 30 years of cyber security expertise and can’t pick between tournament poker and cyber hacking.
The GGNetwork Cyber Security Team Reacts
Editor’s Note: I’ve been working on this piece for many weeks, and I’ve had several talks with Eddie and Hank to guarantee its correctness. Eddie has personally shown the particular weaknesses mentioned in this post, and I have observed his ability to properly identify other players’ hole cards while watching GGNetwork data.
Prior to the publishing of this article, we contacted GGNetwork officials with our responsible disclosure, seeking to help them in discovering and correcting the weakness in order to better secure their network and safeguard gamers. Eddie, Hank, and I were ecstatic that they had resolved the concerns within two weeks of our contacting them, and we would want to compliment them — particularly their cyber security staff — on a job well done.
The GGNetwork Cyber Security team responded as follows:
We prioritized connection and speed above everything else due to the worldwide nature and scope of our business. To accomplish this aim, we used several third-party services, such as CloudFlare’s ARGO tunneling, to discover the optimum route from all destinations and expedite packet delivery.
While ARGO supports SSL, we have decided not to use it in our protocols since it requires additional handshake before the connection is created. This extra handshake would disproportionately harm gamers with weak network access. We also did not encrypt our packets since end-to-end encryption would incur the same overhead that an SSL protocol would. While this may result in possible concerns such as the one mentioned in the article, we concluded that this is a low priority for the following reasons:
This is an edge case: as stated in the article, in order to benefit from the manipulation, the attacker would require access to the particular WIFI network (or local network) as well as knowledge of the players that are playing on that specific WIFI network (or local network). As a result, we found that, although the vulnerabilities exist, they are not a priority since an attacker is unlikely to benefit from such acts.
Our security staff watches gaming around the clock, aided by automatic tools and notifications, and will raise alarms if there is any questionable behaviour. If such edge situations had occurred, we would have recognized them and quickly applied the patch to correct the problem (which was ready to ship).
We have not discovered such manipulation to far, but we have published a patch to add SSL to all of our communication protocols to increase security. We also worked with CloudFlare to improve this procedure in order to reduce the effect of the patch.
Furthermore, to discover and resolve potentially serious security problems, we conduct frequent assessments with approved and renowned third-party security businesses such as Everspin.global or DQS. The most recent such tests were performed three months ago, and no server-side vulnerabilities were discovered.
Our security measures were aimed towards preventing service outages. We have invested significant development efforts and cash to prevent service interruptions caused by DDoS assaults (which sadly took our competitor’s services down numerous times last year) and brute force login/signup attempts. Moving forward, we will make further steps to guarantee that all parts of our services are safe so that our gamers may play with confidence.
Please also read this op-ed, which explains why Cardplayer Lifestyle chose to publish Eddie’s story.
Source: cardplayerlifestyle.com
