Security vulnerability - Zappa s3 event settings do not limit execution of lambda function to s3 resources within a specific account.

[anettleship]

I wish to specify a condition matching a specific aws account number in the resource based policy for a lambda function from the zappa_settings.json file, to close off a vulnerability in the stock Zappa s3 event settings to ensure that only resources in my account can invoke my function. Is this possible?

I'm following this section of the readme to schedule an s3 event trigger for my lambda function https://github.com/zappa/Zappa#executing-in-response-to-aws-events. I wish to set a condition which limits the s3 bucket that triggers the event to one with my aws account number (apparently it's possible to squat someone else's s3 bucket name and trigger events in someone else's account, and our organisation guides this as a secure solution). I need to set the account number in the Resource-based policy of the lambda function.

Accordingly, I specify the following in my zappa_settings.json:

{
"dev": {
        ...
        "events": [{
            "function": "myservice.handler",
            "event_source": {
                  "arn":  "arn:aws:s3:::my-bucket",
                  "events": [
                    "s3:ObjectCreated:*" // Supported event types: http://docs.aws.amazon.com/AmazonS3/latest/dev/NotificationHowTo.html#supported-notification-event-types
                  ]
               }
            }]
    }
}

This results in the following resource based policy:

{
  "Version": "2012-10-17",
  "Id": "default",
  "Statement": [
    {
      "Sid": "XXXXXXXX",
      "Effect": "Allow",
      "Principal": {
        "Service": "s3.amazonaws.com"
      },
      "Action": "lambda:InvokeFunction",
      "Resource": "arn:aws:lambda:eu-west-1:000000000000:function:mylambdafunction",
      "Condition": {
        "ArnLike": {
          "AWS:SourceArn": "arn:aws:s3:::my-bucket"
        }
      }
    }
  ]
}

I wish to set the additional condition to limit to my aws source account as follows:

{
  "Version": "2012-10-17",
  "Id": "default",
  "Statement": [
    {
      "Sid": "XXXXXXXX",
      "Effect": "Allow",
      "Principal": {
        "Service": "s3.amazonaws.com"
      },
      "Action": "lambda:InvokeFunction",
      "Resource": "arn:aws:lambda:eu-west-1:000000000000":function:mylambdafunction",
      

        "Condition": {
        "StringEquals": {
          "AWS:SourceAccount": "000000000000"
        },


        "ArnLike": {
          "AWS:SourceArn": "arn:aws:s3:::my-bucket"
        }
      }
    }
  ]
}

I can do this manually in the aws console, but it is overwritten by Zappa each time I update or schedule the function.

Is there a way to set this condition from the zappa_settings.json?

I've tried adding the condition to my event source, but though this does not throw an error, it does not reflect in the aws console:

{
"dev": {
        ...
        "events": [{
            "function": "myservice.handler",
            "event_source": {
                  "arn":  "arn:aws:s3:::my-bucket",
                  "events": [
                    "s3:ObjectCreated:*" // Supported event types: http://docs.aws.amazon.com/AmazonS3/latest/dev/NotificationHowTo.html#supported-notification-event-types
                  ],
                  "Condition": {
                        "StringEquals": {
                        "AWS:SourceAccount": "000000000000"
                        }
                 }
            }]
    }
}

I've also tried specifying the arn of the event source to include the account number.
...
"event_source": { "arn": "arn:aws:s3::000000000000:my-bucket",
...

This reflects the account number in the aws console resource-based policy, but throws the an error when I call zappa schedule, and the s3 trigger breaks.

Your Environment

• Zappa version used: 0.53.0
• Operating System and Python version: Mac OS Cataline, Python 3.8 running in a virtual environment using Pipenv
• The output of pip freeze:
• argcomplete==1.12.3
  attrs==21.2.0
  boto3==1.18.48
  botocore==1.21.48
  certifi==2021.5.30
  cfn-flip==1.2.3
  charset-normalizer==2.0.6
  click==8.0.1
  durationpy==0.5
  future==0.18.2
  hjson==3.0.2
  idna==3.2
  iniconfig==1.1.1
  jmespath==0.10.0
  kappa==0.6.0
  packaging==21.0
  pep517==0.11.0
  pip-tools==6.3.0
  placebo==0.9.0
  pluggy==1.0.0
  py==1.10.0
  pyparsing==2.4.7
  pytest==6.2.5
  python-dateutil==2.8.2
  python-slugify==5.0.2
  PyYAML==5.4.1
  requests==2.26.0
  s3transfer==0.5.0
  six==1.16.0
  text-unidecode==1.3
  toml==0.10.2
  tomli==1.2.1
  tqdm==4.62.3
  troposphere==2.7.1
  urllib3==1.26.7
  Werkzeug==0.16.1
  wsgi-request-logger==0.4.6
  zappa==0.53.0

[anettleship]

I've done some digging around. It looks like we rely on Kappa, and Kappa doesn't support specifying the Source Account yet. Also, even if Kappa did implement the SourceAccount parameter, Zappa would not be able to support this without first resolving issues with Kappa 0.7.0:

Miserlou/Zappa#684

It looks like someone tried and failed to do this 3 years ago.

Miserlou/Zappa#1518

Do I understand correctly that even if Kappa did implement the SourceAccount parameter when calling AddPermission, Zappa would not be able to support this until the other issues surrounding Kappa 0.7.0 are resolved?

How likely are we to update to Kappa 0.7.0? From the Kappa side, I don't believe adding this would be a heavy lift, and it closes off a potential vulnerability.

---

Further notes and references:

I can see how we would set the AWS Account ID if we were using the aws cli add-permission command using the --source-account parameter:

From here: https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html

aws lambda add-permission --function-name my-function --action lambda:InvokeFunction --statement-id s3-account
--principal s3.amazonaws.com --source-arn arn:aws:s3:::my-bucket-123456 --source-account 123456789012

They also mention the vulnerability.

For Amazon S3, however, the source is a bucket whose ARN doesn't have an account ID in it. It's possible that you could delete the bucket and another account could create a bucket with the same name. Use the source-account option with your account ID to ensure that only resources in your account can invoke the function.

Looking at the AWS Lambda API Reference, AddPermission supports the parameter "SourceAccount": "string" in the request, so adding this is feasible.

From Zappa's side, it looks like we're using Kappa to schedule the aws lambda event, and that we're pegged to kappa==0.6.0 due to some issues with kappa 0.7.0.

Looking at Kappa, I don't believe the latest version 0.7.0 supports a parameter to specify the Source Account. There's no detail in the docs about specifying Source Account that I can see and if I've correctly located Kappa's implementation of AddPermission, the parameter is not implemented currently.

[anettleship]

Updated title to clarify issue.

[anettleship]

OK, this is a duplicate of this issue - #1039

And clearly I've not understood how we use add-permission, it doesn't appear to rely on Kappa.

Issue fixed in this repo: https://github.com/bruceduhamel/Zappa2 >v0.53.3

Account ID is now applied by default, with no further configuration necessary.

New problem, I'm not getting v0.53.3 when I run pip install zappa.

Zappa -v shows...
0.53.0

Also, what's the deal with the Zappa repo not referring to Zappa2?

Someone undeprecated Zappa and now we're out of sync...

#1045

https://github.com/zappa/Zappa
does not include this fix:

Zappa/zappa/core.py

Line 2960 in faa7f47

Create permissions to link to an event.

https://github.com/ghostmaster-ai/Zappa2
however this does:
https://github.com/ghostmaster-ai/Zappa2/blob/06f547b38ebcda947e0673a3684e9eb659f16ba4/zappa/core.py#L2961

Closing this, will create a new post to ask folks about the schism.