New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug]: efs_not_publicly_accessible check based on misunderstanding? #3913
Comments
@sergargar @jfagoagas @n4ch04 You've worked on this check over the years. I'd be grateful for your input here! Sidenote: the issue template does not work for these kinds of bug reports. |
Hi @rieck-srlabs! This check looks if the EFS is public within AWS, not in the internet, which means that can be accessed by any AWS principal. This check does not apply to the internet-exposed category. |
Hi @sergargar, thanks for your response! It is my understanding that (misconfigured) public EFS resources are not accessible within all of AWS though, but only if network access is explicitly allowed via the mount point's security group. Public IPs cannot be assigned to mount points. I think an attacker from another AWS account would have to have VPC peering to their own VPC in place, which seems to me to be unrealistic. Is my understanding incorrect here or is this a risk only for AWS principals from the same account that already have network access? |
Hi @rieck-srlabs , you are right, I have just talked to AWS Support and they confirmed that the EFS would only be accessed to any principal within the VPC. So we will have to change the metadata as well as the severity. What do you think @jfagoagas ? |
Thank you for reaching out to AWS support and following up on this! |
Steps to Reproduce
This issue concerns the
efs_not_publicly_accessible
check. The bug report concerns the validity / usefulness of the check itself, not its implementation.Expected behavior
The (potential) problem
I don't understand the issue flagged by the
efs_not_publicly_accessible
check.The check flags file systems that either
*
.It flags non-conforming resources with critical severity and suggests such resources are publicly accessible.
Important
I believe the severity rating and associated risk is incorrect and results from a misunderstanding.
Accessing EFS resources
My understanding of EFS is as follows: file systems are only accessible through dedicated mount points or via AWS Transfer Family:
Mount points: Mount points are dedicated resources that need to be created and assigned a VPC. Mount points can never have a public IP and are therefore never available over the Internet. Clients can only connect to and mount a file system if they have network access to the mount point, which is restricted to VPCs. With a public file system policy (or without a file system policy at all), EFS relies on UID / GID supplied by NFS clients. This is an inherent issue in NFS and not AWS specific. It has little to do with file system policies in AWS.
AWS Transfer Family: For public EFS resources, no access via AWS Transfer Family is possible.
Searching online for more information regarding public EFS systems, I found
So what?
Reading the rule's critical risk (
EFS accessible to everyone could expose sensitive data to bad actors
) suggests to me that public EFS resources are akin to publicly accessible S3 buckets. However, this is not the case, as access over the Internet is never possible.Based on this,
From my understanding, the only bad actors that sensitive data could be exposed to are internal actors with preexisting access that abuse NFS protocol flaws, similar to users with overprivileged policy assignments.
I'd love to know more about this check and know what I might have gotten wrong above. Please let me know if your understanding differs here and what your reasoning is as to how public EFS file systems are accessible to everyone.
Actual Result with Screenshots or Logs
not relevant
How did you install Prowler?
Cloning the repository from github.com (git clone)
Environment Resource
not relevant
OS used
not relevant
Prowler version
Prowler 4.1.0 (You are running the latest version, yay!)
Pip version
pip 24.0
Context
No response
The text was updated successfully, but these errors were encountered: