Threat Model
A developer’s (admin) machine is compromised. If AWS credentials are in a keychain, it needs to be unlocked for an attack to work. If MFA is configured, and working correctly, the attacker must wait for a valid session to hijack. I.e. keychain and MFA can limit when the attack is possible, but if the system is fully compromised, and is in active use, the attacker is likely to get an opening. Keep in mind: without MFA, the attacker can steal the long lived credentials and use them from a different machine.
In the case of using instance profiles, this is equivalent to being able to execute arbitrary code on the system (any user can then obtain valid credentials). If the credentials are stored in, say, a file with root permissions, the attacker needs to be able to run as root.
The main reason to not access the secrets directly (e.g by installing the CLI) is to avoid the CloudTrail logging. In the case of being able to scan RAM for secrets this might be a desirable attack vector.
The attacker can read any/all secrets. This should be logged by CloudTrail (via KMS).
The attacker can read/write any secret, including deleting the Secrets Group.
The attacker can create new secrets.
Only certain information, i.e. the contained in the File format (version of file format), the Outer Payload Encryption Context (Region, Secrets Group Name) as well as other information written by the AWS Encryption SDK, including the KMS Key ARN, is unencrypted and readable by an attacker. The exposed information is signed and can therefore not be tampered with. Everything else is encrypted with AES-{128, 256} GCM, and padded, revealing very little about the contents of the file.
Denial of Service would render Strongbox useless.
As long as the attacker is unable to also get access to the encrypted secrets (e.g. compromise DynamoDB, an application node, etc), being able to decrypt DEK’s has limited utility. Of course, if the attacker can control KMS it is likely that they are able get access to DynamoDB as well, and then have full access to everything: read secrets or craft fake secrets.
The main line of attack to DynamoDB is Denial of Service. Deleting all entries, responding with garbage to the client, or simply overwhelming the service will all achieve this, without having to fully compromise the service. By having a fallback to File, DoS of DynamoDB can be mitigated at the risk of stale data.
For the following we will assume that the attacker can read any message in DynamoDB and craft responses to incoming requests. Depending on the requests crafted by the client we will see that the attacker can do various types of replay attacks (delivering Secret Entries that were valid at some point).
The Inner Payload is still encrypted, so the attacker can only read the metadata in the Outer Payload as well as the encryption context of the Inner Payload (which is unencrypted).
Because the exposed data is part of the signed encryption context, the attacker cannot tamper with any of the data without being detected by the client. An attacker is thus limited to replay attacks, producing Secret Entries that have been legal at some point (including old revisions of secrets).
The client will verify that the response matches the request after deserialization. This further reduce the replay attacks to match the query. If the query is unique in name and version, the attacker can only replay an older revision of that Entry. If the client asks for the latest active version, the attacker is free to choose any Entry that is active. Thus, not requiring a revision and version allows the attacker a larger degree of freedom. For the attacker to make use of this freedom he needs access to previously valid revisions, which is more likely when using Files as a backend (particularly if stored in a revision control system), rather than DynamoDB which stores the most recent version - the attacker would then have to monitor the the system for some time, backing up legal revisions as they are being made.
A full man-in-the-middle (MITM) is likely to provide similar capabilities as compromising DynamoDB itself, but might reveal less data to the attacker, i.e. no metadata other that what is available through the DynamoDB API, and it might be limited to replaying request made by the client, rather than doing arbitrary requests. The attacker can also choose to record the data being provided by the client, rather than trying to do anything actively.