prowler
prowler copied to clipboard
prowler-cloud
Added check for dependency confusion in codeartifact
Context
A recent feature has been released to mitigate against dependency confusion in AWS CodeArtifact. More can be read here:
- https://aws.amazon.com/blogs/devops/tighten-your-package-security-with-codeartifact-package-origin-control-toolkit/
- https://zego.engineering/dependency-confusion-in-aws-codeartifact-86b9ff68963d
Description
I've included this check in extras as I don't expect most prowler users to want to run it only people specifically interested in checking for this issue.
License
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
Please let me know if any changes are required to improve this check. I'm not a very experienced prowler user so apologies in advanced if I'm not following any best practices
Hi @congon4tor, thank you for your contribution! The check looks great, we will review it shortly and let you know if some changes are necessary.
Hi @congon4tor, I added some changes to your check, thank you for your contribution. However, there are some packages that returns ORIGIN_TYPE=None. Please, contemplate this case, if you need help let us know.
Hi @sergargar thanks for your changes. What kind of packages are you experiencing ORIGIN_TYPE=None? From what I see in AWS docs it should always be INTERNAL or EXTERNAL.
originType -> (string) Describes how the package version was originally added to the domain. An INTERNAL origin type means the package version was published directly to a repository in the domain. An EXTERNAL origin type means the package version was ingested from an external connection.
https://docs.aws.amazon.com/cli/latest/reference/codeartifact/describe-package-version.html It could be a mess up on my code. If you can provide some more details I'll try to fix it
Hi @congon4tor, I created a package in CodeArtifact to test this check and in some cases the Origin information is not returned using the CLI. This is what I'm getting for a package I created:
As you can see, there is no origin info, that is what I was referring to.
I see, how did you create that package I'll try to replicate it. I've tested this in an org with over 50k package versions (pip, mvn and npm) and I've never seen this happen before
I created a pypi package and uploaded it using twine. In this documentation you can see in steps 5 and 6 how I did it. It's strange that you did not face this issue with all of that packages though.
I found a package that also has no origin info this is how it looks like in the AWS console.
It is slightly different from your example
I think the only option is either to default to considering unknown origins as internal or external. Currently they are getting treated as external which could miss vulnerable packages. Defaulting to internal might raise false positives
My python test packages were pushed to codeartifact in the same way you did it. I might be able to get in touch with someone from AWS's code artifact development team to see if they can help figure this out
I just heard back from AWS: There are two things here. The fact that originType is UNKNOWN is expected for packages that were added to CodeArtifact before we released the feature in July. This is because the service was not tracking the origin of packages prior to this. On the 2nd point where the output of describe-package-version is not returning any origin information is weird and looks like a bug. I will create a ticket for my team and ask the relevant engineers about it.
In the unkown case should we raise it as a vulnerable package? Or is there a textwarning we can use for that kind of situation?
For the no origin info I think we should give AWS some time to look into it
Thank you for this information @congon4tor, it is really helpful!!
I would treat unknown package as internal, but let's see what AWS says about this bug because in my package there is no PUBLISH or UPSTREAM information.
AWS believe this is probably due to you AWS CLI version you will need to be using at least v2.7.16. Let me know if that fixes it for you and I'll add a warning in the code
They are right, I tried it again with the latest version and it works! Thank you. However, there is no need to verify the AWS CLI version since in Prowler's README we indicate that the latest version of the CLI is required.