Issue is ‘a design feature, not a bug’
Amazon Web Services (AWS), has claimed that a partial data ‘leak’ in an API, discovered by a security researcher, is not a bug but is “expected behavior”.
On July 9, Arkadiy Tetelman, head of application and infrastructure security at Chime, released details of the issue in a blog post, which he said could be used to obtain “partial AWS account IDs for any CloudFront website”.
Amazon CloudFront is used to deliver applications, content, and APIs to customers with low latency and high transfer speeds. The e-commerce giant released a set of new APIs for the platform on July 8 to detect conflicts and to shift CNAMES as long as source distribution is in the same account.
According to Tetelman, one of the APIs will return a partial AWS ID and Cloudfront distribution ID when they are associated with a domain name to allow clients to manage AWS accounts serving traffic.
“In CloudFront, a domain alias can only be associated with a single distribution globally across all AWS accounts, and for companies that have a lot of assets it can be difficult to track down which account owns a given domain – this API helps solve that problem,” the researcher noted.
Read more of the latest news about security vulnerabilities
To prevent accidental information leaks, the cloud services provider requires a valid TLS certificate for the domain receiving a query.
However, Tetelman says it is possible to “bypass” these restrictions because AWS Certificate Manager (ACM) allows the import of certificates without a valid, private key.
If a public certificate for a domain is acquired, as private keys contain copies of the public key, it could then be possible to circumvent AWS’ security mechanism, the researcher said.
In a potential attack scenario, a random, private key is generated, the precomputed public key parameters on this private key are then updated to impersonate the target public certificate, and this is then imported.
Tetelman says that ACM only checks precomputed values, and this lack of true validation could mean that by creating a “valid” TLS certificate and submitting this to a CloudFront setup, partial account ID information could be obtained.
The same issue was reported to Amazon in 2018, but the company said that his report was not a “security concern” and was “expected behavior”.
“The import process checks to see that the attributes match up – if you edit them as described, they appear to match and so can be imported,“ Amazon told the researcher.
“They will fail in use though as it is not a valid public/private key combination, which is not only expected but desired.”
Tetelman says there has since been “back and forth” communication, but Amazon has declined to fix the issue – which may now be more of a concern with the introduction of the new API, at least in terms of OSINT and information-gathering purposes.
Speaking to The Daily Swig, the researcher said that the real-world impact is realistically low, although it may hamper Amazon’s existing protections against subdomain takeover attacks.
READ Get the message: Orgs without vulnerability disclosure policies failing to address researchers’ warnings
“Still, I wish Amazon would fix it just because this vulnerability so strongly breaks my expectations,” Tetelman commented.
“It was clearly also a surprise to Amazon CloudFront engineers who assumed that having a TLS certificate imported into ACM meant that you own the private key for that certificate and built two use cases that depended on that behavior.
“I worry that if it’s not fixed even more vulnerabilities will be introduced on top of this false assumption.”
An AWS spokesperson told The Daily Swig that account IDs are not secrets, whether visible in full or only partially.
The spokesperson said that if an AWS customer creates a public Amazon machine image, the account ID is published to the world by design.
Account IDs are random numbers, and knowing an account ID does not hold any value, they said, adding that the number alone is not enough to gain access to account information or to be otherwise actionable.
YOU MAY ALSO LIKE HTTP request smuggling vulnerability in Apache Tomcat ‘has been present since 2015’