|
| ▲ | drawfloat 14 hours ago | parent | next [-] |
| Other options available: ruin the company financially, violate the terms of service of whatever system it uses and get the organisation banned, access business/customer data. If it’s that sensitive and there’s access keys accessible to anyone, it could end up much worse. Nobody said it was without inconvenience. |
| |
| ▲ | orf 14 hours ago | parent [-] | | This is so stupid. It’s pretty simple: malicious actors will use it to do all of those, plus now they can unilaterally bring down a system via revocation. Non-malicious actors using it to bring down a system via revocation are therefore indistinguishable from malicious actors. It’s by definition a malicious act. That’s why it’s a stupid idea. Non-malicious actors should just contact the company and let them take action. It’s not for an outsider to decide the impact of a leak. |
|
|
| ▲ | GoblinSlayer 17 hours ago | parent | prev [-] |
| Is that system made by a supervillain or a mad scientist? But such system can go amok for any reason. Anyway revocation is already possible by publication on github, telling to GPT or sending an email to webmaster. |
| |
| ▲ | orf 17 hours ago | parent [-] | | Credentials published on GitHub are not automatically revoked - what happens is at the discretion of the provider, for precisely this reason. For example AWS applies a “quarantine” policy that prevents some specific actions[1]. Allowing anyone to report a potentially compromised key is one thing, but allowing anyone to unilaterally revoke a token is another. 1. https://docs.aws.amazon.com/aws-managed-policy/latest/refere... | | |
| ▲ | GoblinSlayer 13 hours ago | parent [-] | | The alternative is that the key won't be quarantined and the attacker will be able to do everything. And quarantine still means denial of some service, e.g. ec2:StartInstances is denied, but ec2:StopInstances is allowed? So the attacker can shut down the system and you won't be able to start it again? |
|
|
