Clients can execute malicious commands#2769

I don’t know exactly how it is done, but I’ve recently experienced incidents where connected clients were able to:

• Impersonate other players by sending chat messages which appear to have been sent by other players
• Delete objects from the table without a badge (promotion) and with server player permissions (eg. Context permissions) being toggled off
• Enable no-gravity on all objects (EDIT: possibly just moving all objects in a way that resembles as if the objects have no gravity)
• Move objects around even if LUA scripts should prevent picking up those objects (returning false from OnPlayerAction). The objects also move in a clearly robotic fashion eg. Brownian (random) movement, elipsoid movement, slow drifting into the sky, constant acceleration in a uniform direction, etc..
• Pull cards from a locked and uninteractable deck
• Enable the “Flip Table” button for all connected clients, however clicking the button and clicking “Yes” in the confirmation doesn’t actually result in the table flipping.
• Cause all other connected clients to have their Tabletop Simulator application freeze and/or crash, requiring a task-kill to exit the app. Possibly a DoS attack caused by exploiter sending many RPCs to connected clients?
• Clone items on the table without promotion and while LUA OnPlayerAction() should prevent it

EDIT: I have also seen evidence that the above actions are possible even without being fully connected to the game server.

There are probably other capabilities which I haven’t seen, those are just those I have witnessed.

I suspect the malicious actors are doing this with a modded client, probably injecting custom C# code into the Tabletop Simulator game client. The real issue is that there are no security checks to make sure that clients executing these actions actually have the rights/permissions to do so.

There most certainly are permission checks for all these things. Or else this would be a very common issue. In addition to our own permission checks, we’re also using Steam’s networking which has its own authentication on top, particularly for chat.

We’d need to see some evidence of this taking place.

Injecting C# code would be extremely unlikely. 99.9% of the reports we receive of this sort of abuse are a result of the server itself running someone else’s Lua code. Say for example, you’ve loaded someone else’s objects into your game, those objects can have scripts attached. Those scripts are able to send and receive HTTP/web requests. and they’re run on the server. A malicious user can communicate with their own web infrastructure via these scripts. Essentially this could allow someone to remotely execute any of the APIs documented at https://api.tabletopsimulator.com/

The important things to keep in mind:

1. Don’t load mods/objects from untrusted third-parties into your server.

2. Even if this situation does arrise. The malicious user is simply able to execute regular Tabletop Simulator Lua APIs that run in Tabletop Simulator’s Lua sandbox. They most certainly don’t have arbitrary remote code execution. They’re not able to run C# code, and they can’t change or access any files on your computer outside of Tabletop Simulator.

To be more specific about “injecting C# code”, what I mean is that it is possible to modify the client at runtime and be able to send spoofed events ie. send a TAB “ping” as a another color. Basically the malicious actor runs a modified TTS client that allows them to send network requests that spoof other players or actions. It is possible to modify the TTS client at runtime using libraries like Harmony.

I have first-hand experience with the spoofed TAB “ping” as I was able to create a plugin that did just that a few years back. I dug around but could not find the old code, however if its really needed I could try to re-create the injection plugin but I’m not sure if I would remember how. I can try though if that would help.

I don’t suspect an RCE like affecting the actual computer running TTS, but clients being able to do Tabletop Simulator stuff like deleting all the objects on the table is game-breaking.

You can certainly could inject your own local DLL (locally, on your own computer) that would permit different behavior. This is for example how the Lua debugger (https://github.com/tts-community/moonsharp-tts-debug) works. However, if you’re a client and do this, you’re still only able to communicate with the game server via TTS’ networking protocol. The protocol has permission checks built in.

The ping event for example has Permission.Owner, which means that the “pointer” (in game cursor) owner, or the server itself, are the only ones capable of generating a ping on behalf of another player. BUT since the game server player runs the game, they’re the trusted host for all communication, they most certainly COULD make it look like a ping comes from another player — if they’ve modified Tabletop Simulator locally on their machine (EDIT: There’s no good reason to do that though, it’s already possible via scripting, see below.)

However, clients cannot pretend to perform actions on behalf of other clients. Only the server has that capability. The most likely explanation for this behavior is that the host accidentally loaded a script that a malicious person was using to execute TTS scripting commands. There is for example a command that permits the server to ping on behalf of another player: https://api.tabletopsimulator.com/player/instance/#pingtable

Your denial of this is crazy and a reason why many of us are leaving tabletop simulator for other games where devs actually actively maintain their game that we paid for. I host public lobbies and this is also happening to me, users that are in grey are spoofing other players in chat and deleting objects etc, this is absolutely not a script that the host “accidently” loaded, this is happening in many lobbies. You need to actually monitor what is going on in the lobbies. I know you think that it’s impossible to do anything like this, but CLEARLY this is happening to many of us hosts. This issue has only started happening since the latest update.

I didn’t deny this is happening, I said we need evidence that there’s an exploit at play. It’s a serious claim that warrants attention to detail.

We’re not claiming TTS is immune to issues. I even went as far as to explain in detail that there is a very real problem users face with hosting TTS games.

However, the list of symptoms given thus far correspond 1-to-1 with exposed scripting APIs. I would expect vastly different (more henious) symptoms if an arbitrary exploit were in play.

However, this report currently reads identically to reports made in the past, where the problem has repeatedly turned out to be due to a host running third-party scripts. Don’t get me wrong, that in itself is a very real problem. We’ve had many discussions about how to mitigate the issue without hampering modding capabilities. We also actively report host/servers involved in such activities.

Upon receiving this report, it was flagged to me by a Berserk team member, and I investigated. Quite literally going through the permissions code, specifically looking at the methods corresponding with chat and players pings. To suggest we’re not taking this seriously when I’m spending my Christmas eve communicating about this issue is frankly insulting, and factually nonsense.

I need to be able to rule out the obvious causes before I jump to conclusions. Even if we do assume there’s a problem I need something to go off of. I already did the basic analysis. To go deeper, I need more info.

Do you have any logs, I have steam ID’s of the people doing it?

Also thank you for your fast responses!

I’ve experienced a few more incidents which I think are related:
The observed effect is that all connected clients have their Tabletop Simulator app freeze/crash, requiring a task-kill to exit the TTS app.

Based on my experience with the chat-impersonation exploit causing hitches and short freezes when receiving a large quantity of chat messages, I suspect this attack has a similar mechanism; by sending connected clients many RPCs at once, the exploiter(s) are able to execute a sort of “denial-of-service” attack on connected clients.

Thanks, do you have evidence of the players that are causing these issues?

@Knil are you asking for Steam IDs?

Added a new capability to the first post:

• Cloning items on the table without promotion and while LUA OnPlayerAction() should prevent it

I have a LUA script on my table that prevents Player.Action.PickUp via the OnPlayerAction hook and sends a warning message to the player who tried to pick up; recently when experiencing an attack, bystanding players reported seeing the warning message.

Not sure if this helps in your investigation, but this leads me to believe that the exploit picks up items in “other players names” if that makes sense.