I have been playing online poker on the GGNetwork platform via the 7XL skin site for over two years now. I think it is a very exciting platform to play on and there’s always tons of action on the site. Those of you who have read my previous Cardplayer Lifestyle articles over the years may know that I have very strong opinions on cyber security in general and gaming security in particular. This article is a result of a thorough technical investigation I have conducted over approximately 30 hours (net) into the GGNetwork game protocol. My findings have since been corroborated by my fellow cyber security expert Hank Nussbacher, as seen at the conclusion of this article.
The question that popped into my mind prior to starting this investigation was mainly a “WHAT IF?”. I had completely trusted the GGNetwork to be secure by all standards, but I had reasons to suspect something was flawed in their security approach. Before I continue to describe the nature of my investigation, and my findings, I want to make something exceptionally clear:
I do not think I was cheated in a game or a tournament on the GGNetwork. This article is not meant to be a rant about online poker, but rather to demonstrate some security and privacy aspects that operators may not have thought about when designing their platforms. The main purpose of this article is to demonstrate what online gaming security should look like and why.
Network setup
Let’s begin with the network setup and some points about how online poker operators are most likely to construct their operation:
Server side – The server side is the side of the software that is in charge of the “Back Office” operation as well as the actual online poker game. The server side has to identify the players when they log in, allow them to pick up a table, sit in a tournament, deal them the cards and manage the game flow. It is most likely that an operator will split all the server-side tasks to several servers. For example: the lobby operations as well as login will be handled by one server, the money transactions by another server and the game operations by several other servers that will share the load of the games among them.
Client – The client side is the actual software we all run on our PC / Mac / mobile devices. This refers to the GGNetwork software or one of its skin sites (like 7XL).
Protocol – Any client server model has a protocol, which is a set of rules and messages (format) that the client and server must obey in order to “talk to and understand each other.” The protocol is set by the software designers/programmers. Thus, for example, if the server deals two cards to the player, it would send a message over the network that will tell the client that these are the cards the player is being dealt for that particular hand. Since the internet is a mash of many sub-networks and many other servers that communicate with each other at any given time, protocols are there to establish order in the communication chaos.
My mini home lab setup consisted of the following:
- A normal client machine that runs the 7XL (GGNetwork) software.
- A Sniffer – this is a machine that taps communication between my poker client and the servers.
- A router that provides internet connectivity between my network and the internet.
Tapping the Tables
The very first thing I discovered in my investigation was the names of the servers that the client is trying to talk to. On the internet each server has an “IP address”, but most people do not remember IP addresses so we give the servers names. Those names are called domain names (e.g., CNN.com), and the very first thing I did was map the domain names that the client is trying to find in order to talk to the servers.
To accomplish that I simply tapped the client communications. Once my tap started, I found several servers that the client is talking to and thus several domain names and their IP addresses. I will not specify all the names I discovered, but the specific server name I decided to investigate was: tables-ggn.live and for me it resolved to the following IP address: 172.65.231.214
After beginning to tap communication between my client and the server, I filtered the tap data to show me only communication coming from this address to my client and going from my client to this address.
I found that the client starts talking to this server when I click to open a game table and I immediately noticed that the communications between the client and the server is not fully encrypted, meaning I could 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 did not understand why my real name appeared there but the first problematic issue I discovered was that the server sends my client the registered screen name and real name of any player who utilizes the chat function on the table:
Image I: Screenshot from my Sniffer machine illustrating the information packet to the chat, where the message is “Hello World” and the message contains my screenname and real name.
This kind of message is sent to every player at the table or even observing the table once one of the players or observers is chatting.
I was quite surprised that the messages between the client and the table server were not encrypted and even more surprised to see my real name alongside my screen name inside the packet, as the client never shows the real name of the players who chat.
This initial discovery I made immediately raised multiple questions in my mind regarding the network’s game security. Specifically, the fact that the chat communications are not encrypted and that the “extra data” of my real name is sent to all the players and observers at the table suggested to me that there would be other unusual findings in my investigation.
Bear in mind that each packet sent or received by my client travels a long route through the internet and that any middleman anywhere in the world (e.g., internet service provider [ISP] or telephone company) that participates in routing the communications between my client and the table server is able to see this message. I thus decided to take the protocol and attempt to learn more about what is going on throughout the game; i.e., deeply examine the conversation between the server and the client.
Action is on you
Looking at the packets sent, I noticed a similarity of patterns within the packet, specifically:
- The first 4 bytes’ value was correlated to the size of the data inside the packet
- The next 4 bytes’ value was changing from one packet to another, but I kept noticing the same several different values
From my previous experience in the cyber security field, I concluded that this was a “Message type:” code, which tells the client what kind of data is inside this packet. There was also another 4 bytes that kept increasing with each packet, and I thought it may be a message ID or some kind of a timestamp.
I took every type of message that I found and tried to decode the data inside of it. I found out that since the communications were not encrypted and there is no “trust” relationship between my client and the table game server, I could perform MiTM (Man in The Middle) attacks against the client that would allow me to see and change the communications between the server and the client without the client knowing that someone had been tampered with the information.
For example, I discovered that the following message type: 0XAF0F0000 (Hexadecimal value) means: player action and that the server uses this message to tell the client which player acted and what the action was. This would prompt the client to update the user interface, letting the players know which player acted and what action was taken.
Image 2: An example of an “action packet.” The action code is at offset 0x47 (marked in green).
Here’s a quick key to understanding the code: 0x1 = check, 0x2=call, 0x3=bet (first in), 0x4=raise, 0x5 = fold.
When the action contains data, additional data will be contained within the packet. For example, if the value is 0x3 (“bet”) then the amount of the bet will show a few bytes after the action code.
A Simple Exploitative Play
At this point I understood that not only was the chat not encrypted, but also the actions of the player were not encrypted – and thus theoretically open to manipulation. I asked myself “What if I would be a man in the middle and change the packet received from the server before it reaches my client? Would the client show the real action? Would it know the packet was tampered with? Or would it show the action I have maliciously decided to feed it with?
Since this is not a fully technical article and its goal is to share my experiments and thereby try to improve the security of the GGNetwork, I will jump to the conclusion without specifying how I carried out my MiTM attack: I was able to change the packet and (falsely) tell the client that a player had folded his hand when, in fact, his actual action was betting.
Bear in mind, I am not claiming that this can affect the outcome of the hand, as the server “knows” the real action and the server decides who the winner is. But I could theoretically manipulate a player to believe that the action on the table went differently than it actually went. Moreover, any attacker who has access to the client network (which is difficult, but imagine a dorm of college students all playing on GG via the common Wifi network) could accomplish this with near zero effort.
This indicated to me that not only is the game played on a non-encrypted (clear text) channel of communications, but that there is no validation done by the client to ensure that data received from the server is actually from the server and has not been tampered with. An attacker who targets a certain player could achieve MITM capabilities remotely as well. There are several types of attacks that can take place where an attacker gains this capability even if he is not on the same network as the client.
You can only play the cards you’re dealt
Playing games with the client visibility was fun, but not yet profitable. It would be stupid to change game flow, as after a few hands players would probably notice that there are several differences between what was going on in the hand and the outcome of the hand. For example, when I “forced” a player to fold in my test setup, and he would still win the pot, I would guess this would have raised some suspicious flags.
So the knowledge that the actions are not encrypted is eye-opening (mostly for building accurate poker bots without the need to do heavy image processing).
I wanted to see if I could look at the client-server communications and find out what cards are being dealt.
I found out that message type 0x45110000 is actually delivering the cards at the beginning of the hand to the player. It delivers only the cards of the particular player to the client (not all player cards); however, it delivers them in plain sight (clear text) where anyone on the local network can understand what they are and actually “SEE” the other players’ hole cards.
In other words, again, the ISP and any other service provider that processes the packets on their way to the final destination could easily filter those packets, see the players’ names and their cards in real time. Someone on the same network of the player could thus easily tap his cards with a simple MiTM technique and hackers could gain such capability remotely if they are targeting a specific player.
The cards are represented by a number between 0 – 51 (0x0 – 0x33 in hex) where the 0x0 = deuce of clubs, 0x1 – deuce of diamonds, etc.
Here are two screenshots of the hand along with the packet that delivered the data:
Image 3: Marked in purple: 0x45110000 (message type) and at the bottom in green 02=number of cards dealt 0x2b = Queen of spades and 0x21= Ten of diamonds
Image 4: Taken at an Omaha table. Again, in purple, the message code 0x4511000. The 0x04 (in green) is the number of cards dealt to the player, 0x0C is the 6 of spades 0x16 is the7 of hearts 0x05 is the 3 of diamonds and 0x13 is the 5 of clubs.
Conclusions
In this article I have demonstrated the fact that there are severe flaws in the game security within the GG Network infrastructure.
The fact that there is no encryption on the game channel allows anyone on a player’s network (Wifi / Wired) and any uplink provider to have the capability of viewing the player cards in real time or to manipulate the game flow for a specific player he is able to monitor.
By not encrypting the communications between the client and the game server, there are several different scenarios where the online poker game could be manipulated remotely.
Many different companies and personnel participate in the task of getting a data packet from point A to point B on the internet. Any of these companies is able to know which player is playing in real time and what the player’s cards are at any given time.
Finally, professional hackers who target a player can achieve this capability remotely in many different ways.
Corroboration from fellow cyber security expert Hank Nussbacher
Even though Eddie raises serious security issues with the GGNetwork, I will continue to play on the site since my fear is not via an ISP but rather someone on my Wifi network. Also, I only play for micro stakes.
My home network is closed and wired and my wife’s Wifi network is protected, yet I would not want to play via the GGNetwork platform when at a hotel or attending a university campus.
Implementing encryption end to end would be the best and cleanest solution to quickly put an end to this type of security flaw.
Hank Nussbacher has over 30 years of cyber security experience and is hard pressed to decide which he likes more – tournament poker or cyber hacking.
GGNetwork Cyber Security Team Responds
Editor’s Note: This article has been in the works for a number of weeks, and I’ve had multiple conversations with Eddie and Hank leading up to its publication, to ensure its accuracy. Eddie has demonstrated to me in person the specific flaws indicated in this article, and I have witnessed his ability to correctly identify the hole cards of other players when monitoring GGNetwork traffic.
Prior to this article’s publication, we approached representatives of the GGNetwork with our responsible disclosure, hoping to assist them in identifying and patching the flaw, in order to further secure their network and protect players. Eddie, Hank, and I were delighted that they fixed the issues within two weeks of our approaching them, and we would like to commend them — specifically their cyber security team — on a job well done.
The GGNetwork Cyber Security team sent us the following response:
Due to the global nature and reach of our service, we prioritized connectivity and speed above all. In order to achieve this goal, we have utilized various 3rd party services such as CloudFlare’s ARGO tunneling to find the best path from all endpoints and accelerate delivery of our packets.
While ARGO supports SSL, we have made a decision to not apply this to our protocols since it will require another handshake before the connection is established. This additional handshake would especially affect players with poor network connectivity. We also did not encrypt our packets since an end-to-end encryption would require the same kind of overhead that an SSL protocol would introduce. While this can cause potential issues like the one kindly pointed out in the article, we decided that this issue is of low priority because of the following reasons:
- This is an edge case: as pointed out in the article, the attacker would need to have access to the specific WIFI network (or local network) and knowledge of the players who are playing on that specific WIFI network (or local network) in order to profit from the manipulation. We therefore concluded that while the vulnerabilities are present, this was not of priority as an attacker will likely not profit from such actions.
- Our security team, assisted by automated tools and alerts, monitors gameplay 24/7 and will raise alarms on any suspicious activity. If such edge cases were to occur, we would have detected it and applied the patch to fix (which was ready to be shipped) the issue immediately.
We have not detected such tampering until this point, but have issued a fix to apply SSL to all our communication protocols to ensure further security. We have also collaborated with CloudFlare to optimize this process in order to minimize the impact of the fix.
Further, we perform periodic checks with authorized and reputable 3rd party security companies such as Everspin.global or DQS to detect and fix potentially problematic security issues. The last of such checks were carried out 3 months ago, and have not found any server-side vulnerabilities.
Our security efforts were focused on avoiding service downtime. We have spent considerable development resources and funds to avoid service disruptions from DDoS attacks (which unfortunately brought down our competitor’s services multiple times last year) and brute force login/signup attacks. Moving forward, we will put further efforts to ensure all aspects of our services are secure so that our players can play with a peace of mind.
Important Final Note: Please also read this op-ed, which explains why Cardplayer Lifestyle decided to publish Eddie’s article.
