Rely on squadParams for privilege management

[Cheitan 33]

I recently discovered, thanks to @Lou Montana, the A3 command squadParams. It has the ability to display Unit's informations, such as name, tag, image, email, etc (thanks again Lou for that 😍). As a Unit's name is unique, I wonder if relying on this is safe, for attributing privileges to players.

 

For example, I've designed a quick Zeus slot management with the extremely useful CBA_fnc_registerChatCommand. When a player type #zeus request, he is automatically assigned to a curator (provided that there is an available curator, otherwise the player is prompted with a warning). Similarly, using #zeus release automatically unassign the player from his previous curator.

 

For now, there is no kind of "security check". Anyone knowing how the command works is able to get Zeus access (yes, even you, dear reader !). I now want to make sure that only members of my team are able to access Zeus, and that no guest is able to do so, even if he knows the command. As often stated, security through obscurity is no security at all. One way is to store server-side a list of steam IDs (assuming that such an ID cannot be faked...), and make the Zeus request handler check this list in order to allow Zeus privilege. But this way is not very flexible : if a new player joins the team, we need to update the mission file. Another way to do so is to enable file patching on the server and to keep the Steam ID list in a file out of the mission folder. But file patching has its own flaws, and it still need a server root access to modify the file in case of a new member.

 

The final way I just found is to rely on squadParams : if the player is a member of my team, then he should be granted with Zeus privilege. Considerations are as follow :

- Unit Name must be unique on BI's side (let's assume that it is absolutely secured).

- Check must be performed on the server, as we cannot assume a mission file is secure on client side.

- There is NO KIND OF LOCAL STORAGE for squadParams, as local storage could be altered a way or another.

 

I browsed every A3/Launcher folder that I know, including AppData, etc. I found some kind of local storage for units, but only the team's picture is stored. I can make the guess that squadParams is able to do a sort of HTTP request on-the-fly when called. Such a request is done at game start in order to download the squad picture, which is then stored client-side aiming at avoiding big network messages later on. But the remaining intels are not stored, because the total volume of data is considered to small to make a significant difference between local storage and online request.

 

If my guess is right, we can assume that relying on squadParams for privilege management is safe. Of course, to be perfectly honnest, any kind of network proxy should be able to detect and modify on-the-fly any call to the distant database in order to make it display the wanted value, but it's kind of a "very" advanced attack for a ridiculously stupid goal : gaining a temporary Zeus access... Not to mention the fact that game's network traffic might be encrypted, at least for such a call to a HTTP service, which, if it is, will make this attack inoperative.

 

Is anyone able to (in)validate my guess ? I admit I'm not curious enough to kick off my own network security tools just to perform such a small check... Even if doing so might eventually be quicker than writing down this long message 🙄

[pierremgi 4898]

Why not getplayerUID ?

[Cheitan 33]

15 hours ago, Cheitan said:

One way is to store server-side a list of steam IDs (assuming that such an ID cannot be faked...), and make the Zeus request handler check this list in order to allow Zeus privilege. But this way is not very flexible : if a new player joins the team, we need to update the mission file. Another way to do so is to enable file patching on the server and to keep the Steam ID list in a file out of the mission folder. But file patching has its own flaws, and it still need a server root access to modify the file in case of a new member.

As stated here, relying on such an ID require to update the mission file or the server file containing UIDs, in case of a new player joining the team.

[mrcurry 505]

@Cheitan

You can always try creating a unit with the same name and see if it works but a squad.xml can always be faked easy enough. After all the official way was to do it manually long before Units came around. 

 

For your purpose though its probably good enough to check against the squadparams as an admin can kick and ban anyone who decide to hack it.

 

Your main worry is preventing a casual player from messing up the game for the rest. Any dedicated attacker can be dealt with by admins. The value of what you're trying to protect is simply not worth the effort of that level of security. 

[Cheitan 33]

Yep I know this is going too far ^^ To be honnest, it's only a matter of curiosity.

 

I wonder if having a squadXML fills the squadParams the same way than a Unit... If it's strictly the same, then it can be faked indeed. However, creating a new Unit with the same name is apparently impossible. I tried quickly, and as soon as you enter the name, there is a check performed by the website to verify that the name is available. If not, further steps are locked. But I don't know about the security level of such a service, maybe it can be attacked in a way or another to duplicate Unit's name.

 

Anyway, if squadXML cannot be differenciated from Unit via squadParams, it's indeed not a very secured way of attributing sensitive privileges. But for Zeus it's good enough.

[lsd 147]

I use the following to pick up a players clan/squad tag from the squad xml, it's written to work locally but could easily be worked a server check if you can identify the unit calling the chat command.

if (count (squadParams player) > 0) then {
	if (toUpper ((squadParams player) # 0 # 0) == "YourSquadNameHereInUppercase") then {
		*** DO STUFF ***
	};
};

 

[Dedmen 2714]

On 6/21/2019 at 7:46 PM, Cheitan said:

I wonder if relying on this is safe, for attributing privileges to players.

If you check on serverside then probably.
On clientside a client can redirect the squad xml address to his own server. Or he could even make his own squad xml and make it look like yours, you couldn't detect that with squadParams.

 

On 6/21/2019 at 7:46 PM, Cheitan said:

- Unit Name must be unique on BI's side (let's assume that it is absolutely secured).

It's not, and it's not secured at all.

 

On 6/21/2019 at 7:46 PM, Cheitan said:

I found some kind of local storage for units, but only the team's picture is stored.

That's just cache.

 

On 6/21/2019 at 7:46 PM, Cheitan said:

I can make the guess that squadParams is able to do a sort of HTTP request on-the-fly when called

No, it's done when player joins the server.

 

On 6/21/2019 at 7:46 PM, Cheitan said:

Not to mention the fact that game's network traffic might be encrypted

Yes, but game traffic is not squad xml lookup.

 

On 6/21/2019 at 7:46 PM, Cheitan said:

at least for such a call to a HTTP service

If the player configured a https url to his squad xml, it will be encrypted.

 

On 6/22/2019 at 11:05 AM, Cheitan said:

However, creating a new Unit with the same name is apparently impossible.

You are talking about Arma 3 Units. squadParams comes from squad xml and Arma 3 Units happens to offer one for each unit, but you can also get a different squad xml from anywhere else, or just make your own.

 

A player can just make his own squad xml (with your unit name and stuff) and link it in his player profile (there are free squadxml hosting sites) and your script with squadParams wouldn't have any way to know where the data actually came from.

 

 

 

TLDR; no you can't rely on that.

[sarogahtyp 1108]

you could create a chat command for admins to be able to store a new steam uid in a database (if u use one) or in servers mission namespace. this way you avoid editing the mission file or unlocking file patching

[Cheitan 33]

Thanks @Dedmen, very exhaustive answer !

 

@sarogahtyp that's a very good idea O_o such a command would only be accepted by the server if it's called by an already registered player, or by a loggedAdmin. Excellent !

Edited June 29, 2019 by Cheitan
typo