5 ms·

Critical vulnerabilities in 6 AWS services disclosed at Black Hat USA

55 points by noctarius 2y ago

jmisavage 2y ago
For those who don't have the time to read the entire thing. The “Shadow Resources” attack vector, which has since been addressed by AWS, stemmed from the automatic generation of S3 buckets by various AWS services, including: - CloudFormation - Glue - EMR - SageMaker - ServiceCatalog - CodeStar
- filleokus 2y ago
  One interesting snippet is: > [...] the researchers note that their findings demonstrate the importance of treating potential identifiers, such as AWS account IDs, as secrets Which seems to be pretty opposite to the prevailing opinion, at least in some circles. For example the comments here [0] about how to get the account ID for an arbitrary S3 bucket, where many said it was essentially a nothing burger, similar to IP's or emails. Regardless of who is correct, I think it's a telling example of the "dangers" with identifiers that are kinda-public-kinda-private. I'm guessing at least part of the root cause of this bug are AWS engineer's not thinking about the fact that account ID's aren't fully private. [0]: https://news.ycombinator.com/item?id=39512896 https://news.ycombinator.com/item?id=39512896
chuckadams 2y ago
I was expecting some obscure bug in signature verification or something but nope it’s a basic tempfile attack, the sort most of us learned how to avoid in shell scripts decades ago.
- normie3000 2y ago
  Sadly I've barely been writing shell scripts for multiple decades, so needed to look this up. > If an attacker pre-creates the file with relaxed access permissions, then data stored in the temporary file by the application may be accessed, modified or corrupted by an attacker. https://owasp.org/www-community/vulnerabilities/Insecure_Temporary_File https://owasp.org/www-community/vulnerabilities/Insecure_Tem...
  - throwaway2016a 2y ago
    I've coded a ton of shell scripts over the years and never actually considered this nor has anyone I know ever intentionally[1] put protections for it in their scripts so I think the original comment may be overestimating when they say "most of us" With that said, I definitely ill be looking out for this in the future. [1] I have unintentionally protected against this by using unique names for my temp files.
jay-barronville 2y ago
I’m surprised it took AWS ~4 months to fully resolve the vulnerabilities…
- noctarius 2y ago
  Not sure I'm really surprised. As far as I know, AWS hasn't been the fastest in resolving issues. I just remember the "S3 Bucket - We Charge You For Unauthorized Requests" issue a few months ago
- minkles 2y ago
  It has been 3 years since I reported a problem in one of their services and they still haven't found anyone who seems to even be able to understand the problem.
  - jay-barronville 2y ago
    If it’s been 3 years since you reported a vulnerability, they’ve done nothing, and you can confirm the vulnerability still exists, you should tell the public about it since you’ve done your part as far as responsible disclosure is concerned—the public should know.
    - underlogic 2y ago
      I don't get this responsible disclosure. Responsible to whom exactly? It takes leverage from security researchers who have risked their valuable time. Now the companies with lax security can dictate their pay, if any, through bounties while threatening them not to discuss their findings. It's corrupt
      - ls612 2y ago
        “Wouldn’t it be a shame if we charged you with felonies under the CFAA. Now be a good little boy and shut up about our vulnerable systems.” That’s basically the logic at play here, covered in an Orwellian veneer of “responsibility”.
      - 2y ago
arianvanp 2y ago
Though Amazon has protection against confused deputies for Principals , even within an account (every principal has a unique ID, and is account scoped), it doesn't have the same for Resources. And s3 buckets are not scoped to an account and their ARN is global and doesn't contain the account id. For the same reason i advice anybody to always use random suffixes (easily done in Terraform with name_prefix) when generating bucket names.
- hypeatei 2y ago
  > And s3 buckets are not scoped to an account Never used AWS, but how does it handle auth for data plane operations then?
  - noctarius 2y ago
    It handles authentication on a request basis (which was its own issue just a little while ago): https://www.infoq.com/news/2024/05/aws-empty-s3-bucket-billing/ https://www.infoq.com/news/2024/05/aws-empty-s3-bucket-billi...
deleted 2y ago
[deleted]
flerchin 2y ago
Treating accound IDs and hashes as a secret is a tall order. Nearly an antipattern.

55 points by noctarius 2y ago

For those who don't have the time to read the entire thing. The “Shadow Resources” attack vector, which has since been addressed by AWS, stemmed from the automatic generation of S3 buckets by various AWS services, including: - CloudFormation - Glue - EMR - SageMaker - ServiceCatalog - CodeStar

filleokus 2y ago
One interesting snippet is: > [...] the researchers note that their findings demonstrate the importance of treating potential identifiers, such as AWS account IDs, as secrets Which seems to be pretty opposite to the prevailing opinion, at least in some circles. For example the comments here [0] about how to get the account ID for an arbitrary S3 bucket, where many said it was essentially a nothing burger, similar to IP's or emails. Regardless of who is correct, I think it's a telling example of the "dangers" with identifiers that are kinda-public-kinda-private. I'm guessing at least part of the root cause of this bug are AWS engineer's not thinking about the fact that account ID's aren't fully private. [0]: https://news.ycombinator.com/item?id=39512896 https://news.ycombinator.com/item?id=39512896

chuckadams 2y ago

I was expecting some obscure bug in signature verification or something but nope it’s a basic tempfile attack, the sort most of us learned how to avoid in shell scripts decades ago.

normie3000 2y ago
Sadly I've barely been writing shell scripts for multiple decades, so needed to look this up. > If an attacker pre-creates the file with relaxed access permissions, then data stored in the temporary file by the application may be accessed, modified or corrupted by an attacker. https://owasp.org/www-community/vulnerabilities/Insecure_Temporary_File https://owasp.org/www-community/vulnerabilities/Insecure_Tem...
- throwaway2016a 2y ago
  I've coded a ton of shell scripts over the years and never actually considered this nor has anyone I know ever intentionally[1] put protections for it in their scripts so I think the original comment may be overestimating when they say "most of us" With that said, I definitely ill be looking out for this in the future. [1] I have unintentionally protected against this by using unique names for my temp files.

jay-barronville 2y ago

I’m surprised it took AWS ~4 months to fully resolve the vulnerabilities…

noctarius 2y ago
Not sure I'm really surprised. As far as I know, AWS hasn't been the fastest in resolving issues. I just remember the "S3 Bucket - We Charge You For Unauthorized Requests" issue a few months ago
minkles 2y ago
It has been 3 years since I reported a problem in one of their services and they still haven't found anyone who seems to even be able to understand the problem.
- jay-barronville 2y ago
  If it’s been 3 years since you reported a vulnerability, they’ve done nothing, and you can confirm the vulnerability still exists, you should tell the public about it since you’ve done your part as far as responsible disclosure is concerned—the public should know.
  - underlogic 2y ago
    I don't get this responsible disclosure. Responsible to whom exactly? It takes leverage from security researchers who have risked their valuable time. Now the companies with lax security can dictate their pay, if any, through bounties while threatening them not to discuss their findings. It's corrupt
    - ls612 2y ago
      “Wouldn’t it be a shame if we charged you with felonies under the CFAA. Now be a good little boy and shut up about our vulnerable systems.” That’s basically the logic at play here, covered in an Orwellian veneer of “responsibility”.
    - 2y ago

arianvanp 2y ago

Though Amazon has protection against confused deputies for Principals , even within an account (every principal has a unique ID, and is account scoped), it doesn't have the same for Resources. And s3 buckets are not scoped to an account and their ARN is global and doesn't contain the account id. For the same reason i advice anybody to always use random suffixes (easily done in Terraform with name_prefix) when generating bucket names.

hypeatei 2y ago
> And s3 buckets are not scoped to an account Never used AWS, but how does it handle auth for data plane operations then?
- noctarius 2y ago
  It handles authentication on a request basis (which was its own issue just a little while ago): https://www.infoq.com/news/2024/05/aws-empty-s3-bucket-billing/ https://www.infoq.com/news/2024/05/aws-empty-s3-bucket-billi...

deleted 2y ago

[deleted]

flerchin 2y ago

Treating accound IDs and hashes as a secret is a tall order. Nearly an antipattern.