Symmetry Systems would like to extend their appreciation and thanks to the Axonius security team for their professionalism and assistance in ensuring their customers were fully aware of the updated guidance.
In this blog post, we describe how over the last six months, the Symmetry Systems Research Team has found excessive wildcard S3 permissions for third-party security vendors to be common throughout our customer environments. Our ongoing monitoring of data operations proved that the breadth of these permissions are almost never necessary. One of these third parties was Axonius, a leading cybersecurity asset management vendor. A review of their current AWS adapter documentation indicates that Axonius currently does not request this elevated permission, so we dug a little deeper into this seemingly endemic issue and found that they had proactively reduced the permissions being requested in the last six months.
The use of wildcard permissions flies in the face of least privilege and Zero Trust, but time and time again, we see organizations granting third parties access to wildcard permissions. We don’t often see third parties proactively reducing the permissions they request. It’s time for every other vendor to follow this example from Axonius.
Claude Mandy, Chief Evangelist, Symmetry Systems
What Is Cybersecurity Asset Management?
Cybersecurity asset management tools like Axonius’ platform have rapidly grown in importance, as they attempt to solve two common problems plaguing organizations—a lack of visibility and the ability to control entropy over time. Customers appreciate the ease of implementation, speed in providing a comprehensive view of all assets within an organization’s network, and the ability to quickly identify emerging gaps in coverage and other potential security risks.
The ease of implementation comes as a result of a vast array of integrations and adapters that are incredibly well documented by Axonius covering over 600 different technologies.
Axonius Adapters: 601 Tools. One Unified View.
Source: https://www.axonius.com/adapters
In every one of our customers with Axonius installed, we found that the read-only Axonius account had been provisioned with S3:Get* to all S3 resources.
This wildcard permission when applied to all S3 resources grants broad permissions to S3, allowing any account with this permission to perform any operation for S3 that begins with Get. Most of these Get* Permissions (Refer to Note 1) and operations are relatively benign and would be expected for a cybersecurity asset management solution gathering information about the security configuration of their customer’s S3 buckets.
However, it also provides Axonius with the permission to successfully perform S3:GetObject to all data stored in a S3 bucket by our customer. We were quickly able to confirm to our customers that no operations of this sort had been performed by the Axonius account outside of certain cloudtrail S3 buckets. While it was reassuring that no operations had been performed, our customers were taken aback by the level of access that Axonius had.
While Axonius wasn’t the only vendor with this wildcard permission, our investigation became a lot more interesting when we looked at what permissions Axonius indicated they needed.
What AWS S3 Permissions Does Axonius Indicate They Need?
As a first step, we looked at Axonius’s documentation. The quality of Axonius’s documentation for their adaptors and permission requirements is both world class and publicly available. This made it easy to confirm that their *current* documentation did not require this broad wildcard permission.
Axonius even provides example IAM policies in JSON to speed set up. We confirmed that the permissions in the JSON policies mapped to the above summary. https://docs.axonius.com/docs/connecting-aws-adapter-using-iam-user
It was further confirmed that the IAM policy required for their Cloud Asset Compliance module didn’t require this level of wildcard S3:get permissions.
https://docs.axonius.com/docs/aws-adapter-configuration-for-cloud-asset-compliance
The S3:Get permissions in these example policies seemed significantly more in line with what operations we were observing within our customers, but we were still at a loss as to why a disparity existed between what our customers had provisioned and what Axonius seemed to be asking. Why had this level of permission been granted to an external vendor account if they weren’t asking for it?
What We Found When We Went Way Back
Our initial hypothesis was naturally that perhaps Axonius had recently changed their set of required permissions. Inspired by Kelly Shortridge, Senior Principal, Product Technology at Fastly and her recent blog on When Something Disappears from the Internet, we tried to see if we could see any differences in the cached version of the website.
Crawling through the Axonius documentation on The Wayback Machine, however, we quickly found what we had suspected—an IAM policy indicating their original request for S3:Get* permissions to be granted. A full extract of the original IAM policy is included in Note 2 for interested readers.
https://web.archive.org/web/20220706201526/https://docs.axonius.com/docs/amazon-web-services-aws
Recommendations for Current Axonius Customers
For any non-Symmetry Systems customers currently utilizing Axonius with integration to AWS, we encourage you to review Axonius’s latest IAM policy requirements and adjust your policies accordingly and as soon as practical. As part of our engagement with Axonius prior to disclosure, Axonius confirmed that they had further:
- Reviewed and tweaked their AWS adapter documentation for extra clarity.
- Shared with customers a CloudFormation template to make it easier to configure the AWS adapter securely.
- Notified customers about the updated AWS permissions guidance.
More importantly, you should also review every other third-party vendor account in your environment for wildcard permissions and validate their needs against their activity. Something to keep in mind is that third-party vendors may provide a single policy for their tool that meets all their use cases, regardless of which portions of the tool you buy.
If you want to learn more about how Data Security Posture Management (DSPM) does this out of the box or see a leading DSPM solution in action, please reach out. We’d love to show you how DataGuard can help drastically reduce the third party risk to data and your attack surface by reducing the permissions provided to third parties.
Lessons Learned
This investigation highlights how certain wildcard permissions can introduce third-party risk with serious implications for supply chain risk and data security.
It also highlights how having complete visibility requires understanding both:
- What data you have in your environment, AND
- What activity is happening to the data.
This level of understanding is essential to be able to rightsize permissions and take quick remedial action.
It also highlights that most vendors do want to do the right thing. Axonius has recognized that their initial permission requests were too broad, and as a result, actively reduced the amount of privilege they requested sometime over the last six months. While this timeframe coincides with our highlighting of these issues to our customers, we can’t claim to be the impetus behind this, but commit to engaging proactively with other vendors that we identify using wildcard permissions.
Note 1: List of S3:Get* permissions identified:
- GetBucketAccelerateConfiguration
- GetBucketAcl
- GetBucketAnalyticsConfiguration
- GetBucketCors
- GetBucketEncryption
- GetBucketIntelligentTieringConfiguration
- GetBucketInventoryConfiguration
- GetBucketLifecycle
- GetBucketLifecycleConfiguration
- GetBucketLocation
- GetBucketLogging
- GetBucketMetricsConfiguration
- GetBucketNotification
- GetBucketNotificationConfiguration
- GetBucketOwnershipControls
- GetBucketPolicy
- GetBucketPolicyStatus
- GetBucketReplication
- GetBucketRequestPayment
- GetBucketTagging
- GetBucketVersioning
- GetBucketWebsite
- GetObject
- GetObjectAcl
- GetObjectAttributes
- GetObjectLegalHold
- GetObjectLockConfiguration
- GetObjectRetention
- GetObjectTagging
- GetObjectTorrent
- GetPublicAccessBlock
Note 2: Original Axonius IAM policy from 28 June 2022
Source: https://web.archive.org/web/20220706201526/https://docs.axonius.com/docs/amazon-web-services-aws
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Sid”: “VisualEditor0”,
“Effect”: “Allow”,
“Action”: [
“ec2:Describe*”,
“iam:GenerateServiceLastAccessedDetails”,
“iam:Get*”,
“iam:List*”,
“iam:GenerateCredentialReport”,
“ecs:Describe*”,
“eks:Describe*”,
“eks:List*”,
“ecs:List*”,
“ec2:Get*”,
“es:List*”,
“elasticloadbalancing:Describe*”,
“ssm:Get*”,
“ssm:List*”,
“ssm:Describe*”,
“rds:List*”,
“rds:Describe*”,
“s3:List*”,
“s3:Get*”,
“cloudtrail:Get*”,
“cloudtrail:List*”,
“cloudtrail:Describe*”,
“cloudfront:List*”,
“cloudfront:Get*”,
“Workspaces:Describe*”,
“Workspaces:List*”,
“Lambda:Get*”,
“Lambda:List*”,
“apigateway:Get*”,
“route53:Get*”,
“route53:List*”,
“organizations:Describe*”,
“organizations:List*”,
“waf:GetWebACL”,
“waf:ListWebACLs”,
“waf-regional:GetWebACL”,
“waf-regional:GetWebACLForResource”,
“waf-regional:ListWebACLs”,
“wafv2:GetWebACL*”,
“wafv2:GetWebACLForResource”,
“wafv2:ListWebACLs”,
“acm:DescribeCertificate”,
“dynamodb:ListTables”,
“dynamodb:DescribeTable”,
“dynamodb:ListGlobalTables”,
“dynamodb:DescribeGlobalTable”,
“dynamodb:DescribeGlobalTableSettings”,
“inspector:List*”,
“inspector:Describe*”
],
“Resource”: “*”
}
]
}
Share this entry