You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 14, 2019. It is now read-only.
The action signature scheme MIG uses protects the most important fields of the Action JSON file. Agents verify those fields to make sure that a trusted investigator has issued the action.
In particular, the signature covers the action.target fields that contains the target string used to sent the action to selected agents. The target fields is expanded into a list of agents by the scheduler, then each agent receives a Command JSON file which includes the signed action and some other fields.
The signature does not cover the command JSON file because commands are created later in the process and agent-specific.
Moreover, agents themselves do not verify that action.target and cannot verify that an action was truly targeted at them or not. That decision is made by the scheduler.
Put together, these two issue allow for an attacker to take a signed action and craft a command file targeted at an agent that was not originally meant to be.
This is currently mitigated using RabbitMQ's access controls which:
authenticate the scheduler with a username and password
implement ACLs to limit publication to agents queues to an authentication scheduler user
But rabbitmq is fragile and directly exposed to the internet. We should provide an additional layer of security to prevent a rabbitmq compromise from putting agents at risk.
The proposed solution is to add a second signature, this time on the Command envelope, that contains:
Command ID
Agent ID and Queueloc
Action ID and Signature
The fields above would be signed by the scheduler itself using its own scheduler key.
Upon reception of a command, an agent:
verifies the command signature using the scheduler's public key
verifies that the agent.queueloc field of the command equals its own queueloc field (ensure that command it targeted to itself)
verifies the action signature and ACLs
This protocol would prevent a command reuse and add an extra layer of security behind RabbitMQ's ACLs.
The text was updated successfully, but these errors were encountered:
The action signature scheme MIG uses protects the most important fields of the Action JSON file. Agents verify those fields to make sure that a trusted investigator has issued the action.
In particular, the signature covers the action.target fields that contains the target string used to sent the action to selected agents. The target fields is expanded into a list of agents by the scheduler, then each agent receives a Command JSON file which includes the signed action and some other fields.
The signature does not cover the command JSON file because commands are created later in the process and agent-specific.
Moreover, agents themselves do not verify that action.target and cannot verify that an action was truly targeted at them or not. That decision is made by the scheduler.
Put together, these two issue allow for an attacker to take a signed action and craft a command file targeted at an agent that was not originally meant to be.
This is currently mitigated using RabbitMQ's access controls which:
But rabbitmq is fragile and directly exposed to the internet. We should provide an additional layer of security to prevent a rabbitmq compromise from putting agents at risk.
The proposed solution is to add a second signature, this time on the Command envelope, that contains:
The fields above would be signed by the scheduler itself using its own scheduler key.
Upon reception of a command, an agent:
This protocol would prevent a command reuse and add an extra layer of security behind RabbitMQ's ACLs.
The text was updated successfully, but these errors were encountered: