Description
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.