7

We have a multi-user enterprise training application built using the Unity game engine and are discussing the security implications of adding a Windows Defender Firewall rule globally opening an application specific port for that application on the systems where it is run. Due to the architecture of the application the set of executable paths is not known at install time so we haven't figured out a better way to whitelist just the required port on just the executables we need than globally opening the required port.

The application is run under a non-admin account and is installed with an installer that doesn't currently require any elevated privileges. It doesn't do general disk IO, it only reads its own data files and writes out logs to hard coded locations. The systems the application runs on are not on the corporate domain and are not used for any other purpose (they should not have any sensitive data stored on them).

There is some concern about the security implications of globally opening a port. It seems to me that the real world risks are quite low. We can choose a port which is not used by any other applications or services running on the machine so the only real risk would be someone figuring out a successful remote privilege escalation attack on the application itself while it was running (a risk that is somewhat inherent to a multiplayer / multiuser game-type application). I may be missing some potential security implications here however. I'm interested to hear people's thoughts on how big a security issue this really is in practice.

  • 3
  • What are your other layers of defense? Is all of the communication within your network? Restricted VLAN? Does not on the corp domain mean not the same network? Also, are you just deploying an .exe or do you have build/deployment script which could set the firewall rules for you? – Eric G Feb 1 '18 at 18:20
  • @EricG The app needs to communicate with other clients and matchmaking servers which are potentially out on the public Internet. The system running the app would usually be connected to the corporate network (but could be guest WiFi at a conference or customer site etc.) but only for an Internet connection, it would not be logged on to the corporate domain. We use Squirrel as an installer for the app but Squirrel does not support elevated installer permissions we would need to set firewall rules, we're open to using a different installer if necessary. – mattnewport Feb 2 '18 at 1:27
8

The risk of opening a port is that the listening application can be exploited. This means that, for instance, if a Unity zero-day is found these systems would be at risk. Only half 6 months ago a remote code execution bug was found in the Unity Editor (CVE-2017-12939). Note this affected the editor, not the games created by it. New security bugs are discovered all the time, thus any application listening through an open port could potentially be attacked.

Make sure that the port is only opened for the specific application, to prevent the port from being open for other applications that you might install in the future.

If you're paranoid and want to reduce the risk, there are a few options.

Do you need a listening port?

If you build the application in a way that only the servers are listening and the clients initiate the connections, you don't need to open a port (unless you also have an outbound firewall on those clients). This also saves you the hassle of having to forward ports manually on NAT devices in your network.

Create a minimal priviledged user account for the application

You mentionioned that your application only needs read-only rights on a few files in a specific folder. you could create a new user account on the systems you install the application on, and give it priviledges to only that folder. If you do this, make sure the application is run using that user account. This means that if an attacker exploits the application, he will have more troubles to escalate priviledges. This however takes a lot of extra work and is only for the truely paranoid.

  • 1
    I wouldn't call it a small risk. Video games are designed very poorly in general and are macroed to hell and back. I imagine security is an afterthought. – forest Feb 7 '18 at 15:00
  • @forest after some more research I found out that the Unity editor had a remote code execution bug which was patched 5 months ago proving your point, I don't have time to edit my answer at this moment but I will do so later this evening – Snappie Feb 7 '18 at 18:00
3
+100

I agree with your analysis.

Starting from the top, opening a port means that arbitrary (potentially malicious) traffic can and will be routed to the process listening on that port. You are guaranteeing that this game will be the only thing that could ever be listening on that port.

We can choose a port which is not used by any other applications or services running on the machine

So the attack scope is the game application, as you point out:

the only real risk would be someone figuring out a successful remote privilege escalation attack on the application itself while it was running

So the question boils down to: how much do you trust a game application to be designed with security in mind, and properly handle all possible malformed inputs to that port? Personally, I would not trust that very much. @Snappie's answer confirms this.

Since we don't trust the application to be hardened, we need to treat it as "potentially compromised" and sandbox it appropriately. Ask yourself "if this box got totally pwned and was completely under the control of an attacker, what damage could it do?". It sounds like you're already thinking in the right direction, so yay, good job!

The systems the application runs on are not on the corporate domain and are not used for any other purpose (they should not have any sensitive data stored on them).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.