See how gravitl compares to other vendors in security performance
Netmaker is a platform for creating and managing virtual overlay networks using WireGuard. Prior to versions 0.8.5, 0.9.4, and 010.0, there is a hard-coded cryptographic key in the code base which can be exploited to run admin commands on a remote server if the exploiter know the address and username of the admin. This effects the server (netmaker) component, and not clients. This has been patched in Netmaker v0.8.5, v0.9.4, and v0.10.0. There are currently no known workarounds.
Use of Hard-coded Cryptographic Key in Go github.com/gravitl/netmaker prior to 0.8.5,0.9.4,0.10.0,0.10.1.
Netmaker makes networks with WireGuard. Prior to version 0.15.1, Improper Authorization functions lead to non-privileged users running privileged API calls. If someone adds users to the Netmaker platform who do not have admin privileges, they can use their auth tokens to run admin-level functions via the API. This problem has been patched in v0.15.1.
Impact A Mass assignment vulnerability was found allowing a non-admin user to escalate privileges to admin user.
Patches Issue is patched in 0.17.1, and fixed in 0.18.6+.
If Users are using 0.17.1, they should run "docker pull gravitl/netmaker:v0.17.1" and "docker-compose up -d". This will switch them to the patched users
If users are using v0.18.0-0.18.5, they should upgrade to v0.18.6 or later.
Workarounds If using 0.17.1, can just pull the latest docker image of backend and restart server.
References Credit to Project Discovery, and in particular https://github.com/rootxharsh , https://github.com/iamnoooob, and https://github.com/projectdiscovery
Impact An IDOR vulnerability was found in the user update function. By specifying another user's username it is possible to update the other user's password.
Patches Issue is patched in 0.17.1, and fixed in 0.18.6+.
If Users are using 0.17.1, they should run "docker pull gravitl/netmaker:v0.17.1" and "docker-compose up -d". This will switch them to the patched users
If users are using v0.18.0-0.18.5, they should upgrade to v0.18.6 or later.
Workarounds If using 0.17.1, can just pull the latest docker image of backend and restart server.
References Credit to Project Discovery, and in particular https://github.com/rootxharsh , https://github.com/iamnoooob, and https://github.com/projectdiscovery
Impact Hardcoded DNS key usage has been found in Netmaker allowing unauth users to interact with DNS API endpoints.
Patches Issue is patched in 0.17.1, and fixed in 0.18.6+.
If Users are using 0.17.1, they should run "docker pull gravitl/netmaker:v0.17.1" and "docker-compose up -d". This will switch them to the patched users
If users are using v0.18.0-0.18.5, they should upgrade to v0.18.6 or later.
Workarounds If using 0.17.1, can just pull the latest docker image of backend and restart server.
References Credit to Project Discovery, and in particular https://github.com/rootxharsh , https://github.com/iamnoooob, and https://github.com/projectdiscovery
Netmaker makes networks with WireGuard. Prior to version 1.5.0, the user update handler (PUT /api/users/{username}) lacks validation to prevent an admin-role user from assigning the super-admin role during account updates. While the code correctly blocks an admin from assigning the admin role to another user, it does not include an equivalent check for the super-admin role. This issue has been patched in version 1.5.0.
A user assigned the platform-user role can retrieve WireGuard private keys of all wireguard configs in a network by calling GET /api/extclients/{network} or GET /api/nodes/{network}. While the Netmaker UI restricts visibility, the API endpoints return full records, including private keys, without filtering based on the requesting user's ownership.
Netmaker makes networks with WireGuard. Prior to version 1.5.0, the Authorize middleware in Netmaker incorrectly validates host JWT tokens. When a route permits host authentication (hostAllowed=true), a valid host token bypasses all subsequent authorization checks without verifying that the host is authorized to access the specific requested resource. Any entity possessing knowledge of object identifiers (node IDs, host IDs) can craft a request with an arbitrary valid host token to access, modify, or delete resources belonging to other hosts. Affected endpoints include node info retrieval, host deletion, MQTT signal transmission, fallback host updates, and failover operations. This issue has been patched in version 1.5.0.