Force agents to authenticate to the Island

[mssalvatore]

Summary

The island does not require any authentication from agents. This could allow sensitive information to be leaked to unauthorized actors (confidentiality), or allow a malicious actor to pollute Infection Monkey with falsified data (integrity). An authentication mechanism must be added to minimize these risks.

Goal

The goal of this effort is to authenticate agents communicating with the island.

Tasks

• Create mock OTP/Agent-Auth API endpoints #3076
• Implement OTP compliance on the Agent #3077
• Implement OTP/AgentAuthentication in the Island #3078
• Generate refresh token #3137
• Revoke tokens on logout #3138
• Log in on Island restart bug #3122

Expected dependency graph

Testing checklist

• OTP received, agent can use it to authenticate (this will get covered by BB tests, no changes needed)
• OTP timeout expired, OTP is no longer usable
• OTP got used, it's impossible to fetch another token with the same OTP
• Agent finished/got killed, the security token it used is now invalid
• Agent heartbeat timed out. The token is invalidated.

Details

There are three endpoints that expose users to security risk:

• POST /api/telemetry
• GET /api/monkey[/GUID] (<=v1.13.0)
• GET /api/propagation-credentials (unreleased)

There are other unauthenticated endpoints, but the above 3 are security concerns.

Confidentiality

• GET /api/monkey[/GUID] (<=v1.13.0)
• GET /api/propagation-credentials (unreleased)

The endpoints used to retrieve propagation credentials from the island are completely unauthenticated. Anyone who can send an HTTP GET to the island's API can extract credentials that could allow them to propagate around the network.

Integrity

• POST /api/telemetry

The endpoint that agents use to send information to the island is not protected by any authentication scheme. Anyone who can send an HTTP POST to the island's API can pollute Infection Monkey's reports with falsified data.

Proposal

The island can generate one-time passwords (OTPs) that agents can use to authenticate and acquire a JSON Web Token (JWT) or other reusable authentication credentials. The island must provide a new endpoint that will allow an authenticated client to request a OTP. OTPs should expire after a reasonable amount of time (e.g. 2 minutes). If clients are able to request an expiration time for their OTPs, the island should set an upper limit on the OTP's TTL.

On Linux, the OTP should be set in an environment variable and the agent should read this environment variable to retrieve the OTP. Passing the OTP via a command-line argument is not an acceptable solution, as other users on the system may be able to use simple mechanisms, such as the ps command, to recover the OTP.

On Windows, further research must be performed to determine the best way to protect the OTP.

Risks mitigated

Forcing agents to authenticate using a OTP prevents unauthorized entities from extracting sensitive data from the API or pushing falsified data into the API. By using mechanisms like environment variables to store the OTP, unauthorized users on multi-user systems will not be able to recover the OTP and authenticate to the island.

Risks accepted

If an account has been compromised and the agent is being run as the compromised user, a malicious actor may still be able to read the OTP via /proc/[PID]/environ. This would allow the attacker to race the agent process and attempt to authenticate to the API first. If successful, the attacker can extract sensitive information from the API. As a side effect, the agent would not be able to use the OTP and would shutdown (denial of service). This risk is acceptable. If an account has been compromised, there are a variety of tactics that an attacker could employ to intercept the OTP.

Optional mitigations

If the OTP is stolen, the attacker will have to race the agent in order to use it, or kill the agent process before it has a chance to use the OTP. The island could raise an alert to the user if it notices a OTP has been used more than once. This carries the risk of false positives, particularly with the Hadoop exploiter.

[mssalvatore]

After some internal discussions, we concluded that the above proposal mitigates the most significant risk, which is an unauthorized user within the network or the public internet accessing the Island. It provides only limited protection if nodes within the network are compromised, but that is risk we're willing to accept in the short term.

A caveat is that the JWT (or other token) acquired by the agents after using their OTPs should expire. I'll modify the above proposal and include this in the design.

In the future, the following modifications could help mitigate additional risks:

1. Associate the OTP and other tokens with an IP address.
2. Force all communication between an agent and the Island to follow the propagation path. That is, if the propagation path looks like Island -> A -> B -> C, then B can only communicate to the Island by B -> A -> Island, and C can only communicate via C -> B -> A -> Island.
3. Originate all connection requests (SMB, WMI, SSH, etc.) from the Island. Tunnel TCP traffic through the agents. In this way, protocols that are end-to-end encrypted (such as SSH) prevent the agents from ever reading the propagation credentials. Agents never need to request propagation credentials because all connection requests originate from the Island. This may be the best solution, but is not architecturally feasible at the moment. It only resolves the confidentiality concerns, but not the intergity concerns, which means it requires the OTP solution in tandem.
4. Request credentials immediately before use and delete them immediately after each use. This makes it harder to steal the credentials from a process's memory, but could significantly increase network chatter.

[VakarisZ]

Use environmental variables on windows as well (passing CMD parameter is also an option, but we should strive for a consistent interface between different agents).
Windows command can look something like cmd /V /C "set "OTP=S3cR3t_0tP" && monkey-windows.exe -s 192.168.56.1:5000"
Full discussion: #2137