Anti SteamID 'Spoofing' Measures - Developers

[QUOTE=ColdFusion;24437762]Aren't the validation keys handled true the vac server(s) ? Like the servers we aren't really connected to.[/QUOTE] No. Although VAC secured servers are less vulnerable to ticket spoofing, ticket validation is handled separately by the steam backend. Servers can immediately detect tickets that have been tampered with (as each ticket is signed), but only the steam backend can detect ticket reuse (and it does a very bad job of it). The reason VAC happens to defend against the attack is that when connecting to the server that swaps the id out the client never tells the steam backend the server that it's really connecting to (because it doesn't know) leading to an eventual kick for never establishing a backend connection to VAC. End result is that you get kicked after about two minutes, which is still long enough to be dangerous. Even if the client did know what server it was actually connecting to, I highly doubt that it has the credentials necessary to establish that connection using somebody else's steamid. [QUOTE=grea$emonkey;24437853]Good work. I hope Valve fixes this for GMod soon.[/QUOTE] Unfortunately, I've started to lose faith in that happening. We'll probably look into making this into a nicer completely self-contained package since valve have shown little to no interest in fixing this despite having had the source code to a proof of concept for months. It's too bad, really.

but boided now you're not going to get any sales

I really hope someone can fix this, for now I'll use this. Also, so many -snips- in this thread.

Is there anything I can do?

[QUOTE=garry;24457157]Is there anything I can do?[/QUOTE] Beyond annoying valve day in and day out until they finally do something about it, there's not much else that can be done. Usually with something so potentially dangerous they'd have fixed it by now, but since this has little to no effect on their own games (provided a server is VAC secure) it's not something that they appear to have any interest in fixing. The only way that it really affects valve games is (potential) piracy--clients without a game would be able to join legitimate (but not VAC secured) servers by swapping their tickets out, but I don't think that this would move them to take action unless it was actually being done. The other problems that arise are more problems with third party things like admin mods that grant power based on steamid alone. Valve has been notified of this (and responded acknowledging it) with promises of taking action for (quite literally) months now. At this point I think the only chances of getting it fixed are to either bother them endlessly about it until they finally do something or simply publicly release everything required to do it on every game using the source 2009 engine. One solution hasn't worked yet and the other is unfair to everybody who either runs or plays on a server. The situation sucks. EDIT: And to make things even better the only solutions require messing around with steam internals at runtime, so it's less-than-ideal for inclusion in garrysmod.

@Garry: Could you not implement the check that is missing in GMod ? Even if the hook is meant to be in some engine code which you don't want to change, you could possibly just replicate what OPs code is doing so that all servers at least have this functionality.

PacSteamers :argh:

[QUOTE=yngndrw;24457551]Could you not implement the check that is missing in GMod ? Even if the hook is meant to be in some engine code which you don't want to change, you could possibly just replicate what OPs code is doing so that all servers at least have this functionality.[/QUOTE] There are two pretty good reasons for this to not be included in garrysmod: stability and false-positives. The best possible third-party fix requires messing with steam internals. The steam binaries are updated independently of garrysmod, so if garrysmod were to do this and the steam binaries were to be updated in a way that was incompatible with the fix, garrysmod would be completely unusable by anybody until it got updated. The other problem, false positives, is even more serious. One part of the problem is a flaw in the steam backend which causes it to fail to issue a deny callback in a reasonable amount of time. Since the deny callback can't be relied upon, we instead rely on timing the amount of time for an approval callback. When the ticket gets swapped out it never gets approved by the steam backend. Our fix works by requiring an approval callback within a timeframe of around 10 seconds which is pretty reasonable (it's usually less than 1), but there are things which can prevent the allow callback from ever being received. By default, nothing is done with the allow/deny callbacks (and these interfaces aren't exposed to the game, only to the engine), so failing to receive them hasn't really mattered. With this fix, it does matter, and although it IS an edge case, it's possible enough to make it unfit for inclusion in garrysmod. Allow callbacks will never be received when a server is disconnected from the backend (which happens quite frequently), so you have to either block everybody from joining or allow everybody to join in the absence of a connection, which is less-than-ideal. This is something that server operators should have to opt in for, and they should fully understand the potential consequences before doing so. [QUOTE=LinuX;24457696]PacSteamers :argh:[/QUOTE] They have absolutely nothing to do with any of this.

I can confirm that Serenity is back. Avaster will release it for sale in the next days... Edit: Some people already bought it...

So why is the check that you mentioned in your OP (Step 5) not included in GMod, when it is in other games with the same engine ? I'm just wondering what caused this to be left out, was it an update which was added to the SDK after GMod was started and never merged ? Also from what you're saying about the flaws of the system, does this mean that other Steam games also suffer this issue - I.e. They will only kick you after the approval callback, which would allow you to be "in" the server with somebody else's Steam ID for around a second ? I can see that being used to run admin commands and cause a whole range of other issues for those games. With this in mind, I'm very surprised that Valve isn't taking this seriously.

[QUOTE=yngndrw;24458385]So why is the check that you mentioned in your OP (Step 5) not included in GMod, when it is in other games with the same engine ? I'm just wondering what caused this to be left out, was it an update which was added to the SDK after GMod was started and never merged ? Also from what you're saying about the flaws of the system, does this mean that other Steam games also suffer this issue - I.e. They will only kick you after the approval callback, which would allow you to be "in" the server with somebody else's Steam ID for around a second ? I can see that being used to run admin commands and cause a whole range of other issues for those games. With this in mind, I'm very surprised that Valve isn't taking this seriously.[/QUOTE] Step 5 of the OP is incorrect. The callback is meant to be handled by the engine, but it is not. The source sdk does not contain the relevant steam interfaces (they're a part of steamworks) so it can't be handled by mod developers. Even for those mod developers who do have access to steamworks, without access to ISteamGameServer in the engine it won't do them much good. The reason that other games aren't as susceptible is that the client is kicked for not establishing a valid VAC connection. The callbacks in question (the gameserver allow/deny callbacks) are simply discarded by the source engine by default as near as we can tell. I'm unsure of how seriously this affects other steam games, I suppose it would depend on how the developer of the game handled the callbacks, but valve has chosen to ignore them in their own games. When a player connects, one of three things will happen: an approval callback will be received almost instantly (but will, very rarely, take around 10 seconds), a deny callback will be received after 2 minutes (maybe 5, I haven't been tinkering with it for a while), or no callback will ever be received (in the event of the connection to the steam servers not being active). The most effective option in my opinion is to simply require an approval callback within 2-3 seconds. This will result in legitimate clients occasionally being kicked during connect, but the second time around they'll usually make it in. It's a bit of a hassle but a lot better than dealing with spoofed steamids. With our solution as implemented, it's possible to be in the server for up to 10 seconds with a spoofed steamid, but that starts counting from the moment the connection is established prior to the client even beginning to load the map. Although this is more than enough time for administrative commands to be abused, those administrative commands weren't written or provided by valve and are probably not present on the majority of servers (garrysmod is the exception). The effect on the game itself is minimal; it's the effect on third-party code (such as administrative tools) which is crippling. Oh well, consider it a lesson on why you should use two-factor authentication as opposed to simply trusting the steamid. It's never been a bright idea, now the community is learning why.

[quote]Updates to Counter-Strike: Source, Team Fortress 2 and Day of Defeat: Source have been released. The updates will be applied automatically when your Steam client is restarted. The major changes include: Source Engine Changes (CS:S, DoD:S, TF2) The mat_hdr_level, r_rootlod, and r_waterforceexpensive settings are now saved in the user’s config file. [b]Fixed clients being able to connect to servers with spoofed SteamIDs.[/b] Fixed a bug where some video configurations could get reset by restarting the engine. Fixed materials compiled into a map not being loaded correctly if they're in the root materials folder. Fixed a case of uneven performance on multicore machines. Fixed point contents not respecting detail brushes. This fixes a bullet penetration bug in some community maps. Fixed clients being able to spam servers using the ai_set_move_height_epsilon, mission_show, and sv_querycache_stats commands. Audio fixes: Reduced overlap in the sound timing code. Fixed a case where audio could skip. Fixed voice communication getting corrupted while playing on a Mac. sv_pure 2 now protects the game_sounds files in the scripts directory.[/quote] [url=http://store.steampowered.com/news/4210/]Uh?[/url]

[QUOTE=Lexic;24459494][url=http://store.steampowered.com/news/4210/]Uh?[/url][/QUOTE] That was related to another, separate vulnerability in the authentication process that allowed a client to completely bypass steam authentication on any source server. The clients connecting with that exploit would receive a steamid assigned by the local game server instead of one provided by the steam backend and a signed application ticket. It was a source engine exploit and not a steam exploit as the one mentioned in this thread.

[QUOTE=ComWalk;24459547]That was related to another, separate vulnerability in the authentication process that allowed a client to completely bypass steam authentication on any source server. The clients connecting with that exploit would receive a steamid assigned by the local game server instead of one provided by the steam backend and a signed application ticket. It was a source engine exploit and not a steam exploit as the one mentioned in this thread.[/QUOTE] Oh.

Get it working to a reasonable degree on TF2, email Valve the source. If they haven't fixed it within two weeks, release the source.

It may be prudent to override the IsAdmin() and IsSuperAdmin() functions to return false until authentication is made, or to override them with a separate authentication scheme. Albeit this is a workaround, this is how I would do it on a public server until a patch goes up. [b]Edit:[/b] If this seriously has been going on since June, a supplement to the above fix would be for the server to maintain a list of authenticated IP addresses to SteamIDs. Whenever the Steam backend authentication comes through, the player's SteamID and IP address is added to the table. To allow administrative access [i]before[/i] Steam authentication, this table could be looked up by IsAdmin(). The same table could be used to determine authenticity of repeat-joiners. The only other concern is making sure not to ban a player by SteamID until their SteamID is verified (add an IsSteamAuthenticated() method) - until that authentication, it may be best to rely on IP bans.

No. It was fixed. This must be a new bug. Edit: That's why serenity is a new version now.

There [i]is[/i] a new serenity version, and it works 100%.

If it is still only an issue with authenticated SteamIDs, and we have a reliable function that returns true if (but not only if) the SteamIDs match, then I contend that we have just as reliable of a way to secure our servers by using that function. The swapped SteamID is a problem that leads to the following issues: -Admin access by unverified SteamID -Banning of players with unverified SteamID -Identification of players with unverified SteamID With the aforementioned function, the first two are easily fixed by a handful of function overrides and a table of verified SteamIDs to IP Addresses (dependent on administrative utlity). The last one is heavily gamemode/addon-dependent, however, but only affects gameplay - not administrative commands. Am I missing any other issues?

[QUOTE=T3h raps13r;24466935]There [i]is[/i] a new serenity version, and it works 100%.[/QUOTE] What did I just say? Edit: Just tell your admins to not join servers they don't know? They can only use SteamIDs from Players that joined their server before.

If Valve does respond, Valve is probably going to do one of two things: -Expose the validation callback -Make the server return STEAM_ID_PENDING for unvalidated clients They will most likely not have servers wait for validation before accepting a client as this would be seen as an aggressive form of DRM. So, the problem will fall to garry. Garry can do a number of things [i]after[/i] Valve takes action: -Do the aggressive DRM thing (blanket solution, much bickering will ensue) -Create some quasi-spectator mode for when players join, disallowing them much access to prevent the problem of identification by unverified SteamID (blanket solution, much bickering will ensue) -Create a new Lua binding ( IsSteamAuthenticated() or whatever ) and publicly announce it; but this leaves a significant period of time where servers are open to attack while a much larger audience is made aware of the security vulnerability (is this still a concern)? So, garry could implement a "blanket fix" once Valve responds...but I can't think of one that won't be intrusive. Thus, [b]the problem falls to the Lua scripters[/b] (user-level). Is there any way it could possibly not? (Not a rhetorical question) The only options in this category I can think of is exposing a binding like IsSteamAuthenticated(), or setting STEAM_ID_PENDING...of which, the former is more palatable, as some scripts would probably take STEAM_ID_PENDING as a valid identifier. If we can decide right [i]now[/i] that IsSteamAuthenticated() (or what have you) is the way to go, then we can be ready for the fix on day zero and minimize the added risk of increased publicity (albeit it has been on the forums since June - still, I didn't notice the thread until now; how many more?). So, perhaps a silent update could add a placeholder function. Admin mod writers could implement this function before the fix goes live. Server administrators could override this function with third-party code before the fix goes live. Everyone is happy, and we avoid the administrative "standards" of GMOD 9. In conclusion: if we agree that a user-level solution is the best solution, then the best thing we can do right now is standardize the way we check for authentication.

[QUOTE=Ideal-Hosting;24466910]No. It was fixed. This must be a new bug. Edit: That's why serenity is a new version now.[/QUOTE] It's a new version because the protocol changed from version 14 to 15 in the engine upgrade.

So it's the same bug? So it was fixed in 14 but the same bug is now non-fixed in V15?

[QUOTE=Ideal-Hosting;24469655]So it's the same bug? So it was fixed in 14 but the same bug is now non-fixed in V15?[/QUOTE] It was never fixed.

Serenity didn't work anymore, so it was fixed?

[QUOTE=Ideal-Hosting;24469788]Serenity didn't work anymore, so it was fixed?[/QUOTE] Serenity was written for version 14 of the protocol, it hadn't been updated until recently.

[QUOTE=Ideal-Hosting;24469788]Serenity didn't work anymore, so it was fixed?[/QUOTE] Its becouse the OLD serenity was using 14, the NEW one uses 15, its just a number that needed updateing Edit: NINJAAAAAADDDD And for the administrator mods, if a player is an admin, make them fill in a secret question or something, to ensure its them or check there ip

[QUOTE=Chrisaster;24469836]Serenity was written for version 14 of the protocol, it hadn't been updated until recently.[/QUOTE] Who updated it?

[QUOTE=IStanI;24470015]Who updated it?[/QUOTE] Probably OP. Also this fix seems to work still. [code]15:47:56 L 08/30/2010 - 14:47:42: "?g†.??????<1430><STEAM_0:1:25012594><>" disconnected (reason "SteamID validation failed (timeout)")[/code]

Regardless of this being patched or not I still gained from it lol In 2 day's I had reached my goal and bought a 700 dollar Nikon D5000 from the sales ;) [url]http://img638.imageshack.us/img638/1315/nikond50001600x1200.jpg[/url]