Skip to content
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

Closed
rieck-srlabs opened this issue May 2, 2024 · 5 comments · Fixed by #3917
Closed

[Bug]: efs_not_publicly_accessible check based on misunderstanding? #3913

rieck-srlabs opened this issue May 2, 2024 · 5 comments · Fixed by #3917
Assignees
Labels
bug provider/aws Issues/PRs related with the AWS provider severity/medium Results in some unexpected or undesired behavior. status/awaiting-reponse Waiting response from Issue owner

Comments

@rieck-srlabs
Copy link
Contributor

rieck-srlabs commented May 2, 2024

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

  1. have no file system policy, or
  2. that have a public file system policy with a principle as *.

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

  • this additional resource. It looks like it is based directly on Prowler's rule and provides no additional information.
  • The related AWS documentation, which does not indicate direct security risks associated with "public" EFS resources and highlights primarily usability issues to keep in mind.
  • This SO post supports my understanding from above.

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,

  1. the severity rating of critical seems too high to me, and
  2. the risk statement is misleading and confusing.

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

@rieck-srlabs rieck-srlabs added bug status/needs-triage Issue pending triage labels May 2, 2024
@rieck-srlabs
Copy link
Contributor Author

rieck-srlabs commented May 2, 2024

@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.

@sergargar sergargar self-assigned this May 3, 2024
@sergargar sergargar added status/waiting-for-revision Waiting for maintainer's revision severity/medium Results in some unexpected or undesired behavior. provider/aws Issues/PRs related with the AWS provider and removed status/needs-triage Issue pending triage labels May 3, 2024
@sergargar
Copy link
Member

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.
However, I think we should improve the explanation in the check's metadata.

@sergargar sergargar added status/awaiting-reponse Waiting response from Issue owner and removed status/waiting-for-revision Waiting for maintainer's revision labels May 3, 2024
@rieck-srlabs
Copy link
Contributor Author

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?

@sergargar
Copy link
Member

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 ?

@sergargar sergargar linked a pull request May 3, 2024 that will close this issue
@rieck-srlabs
Copy link
Contributor Author

Thank you for reaching out to AWS support and following up on this!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug provider/aws Issues/PRs related with the AWS provider severity/medium Results in some unexpected or undesired behavior. status/awaiting-reponse Waiting response from Issue owner
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants