ggRock Security

This article is intended to outline main security concerns that we believe should be taken into consideration when planning the integration.

About

There are two main ways in which ggRock can be exposing the infrastructure it's being placed into: Network ports required and utilizing ggRock app to execute malicious commands given access to ggRock UI and API backend.

Network ports

This is the list of all ports required by a regular ggRock installation.

Additionally we configure port forwarding on ggRock server (we use it as the default gateway for client PCs that forwards Internet/external traffic to the main gateway in LAN). In such configuration all ports, that should be forwarded to internet/external networks, should also be opened in local firewall.

Recommended mitigation steps

It is recommended to set up an external VPN that would be IP-whitelisted for any remote access into the network that has ggRock in it. Alternatively, if remote access to ggRock app is not required - it's best to leave it only accessible via LAN.

ggRock Application

ggRock Application is a set of Linux scripts, Python scripts and a C# .NET Core application, packaged together and tightly interconnected.

All closed-source code (excluding ggrock-linux-configurator) is encrypted and obfuscated. That has been done for both security and DRM purposes.

Application itself is protected with an Identity system with a single admin account that gates all Application functionality. However, even with Administrator access, ggRock has no intended or know to us unintended ways of executing remote code execution that could be utilized for nefarious means.

Recommended mitigation steps

Out of abundance of caution we recommend to follow password best practices for ggRock Administrator account, utilize non-elevated user for Debian server administration whilst not sharing root credentials.