AWS-0102 is triggered for NACL rule **denying** access to/from all ports

[majacannavo]

IDs

AVD-AWS-0102

Description

When a VPC's NACL contains an entry like

{
    "CidrBlock": "0.0.0.0/0",
    "Egress": false,
    "Protocol": "-1",
    "RuleAction": "deny",
    "RuleNumber": 32767
}

that denies access from all ports, it triggers AWS-0102: Network ACL rule allows access using ALL ports.

Reproduction Steps

1. Define an AWS VPC with specific NACL rules that allow access via only certain port ranges for both ingress and egress. Then the Entries list will include 
{
    "CidrBlock": "0.0.0.0/0",
    "Egress": false,
    "Protocol": "-1",
    "RuleAction": "deny",
    "RuleNumber": 32767
}
and 
{
    "CidrBlock": "0.0.0.0/0",
    "Egress": true,
    "Protocol": "-1",
    "RuleAction": "deny",
    "RuleNumber": 32767
}, 
even though all other entries contain specific port ranges.

2. With the AWS CFN template declaring this resource in your filesystem, scan using trivy config --exit-code 1 --severity MEDIUM,HIGH,CRITICAL .

3. Notice that AVD-AWS-0102 is triggered. Notably there are multiple lines highlighted as problematic, and none of them actually include the value of the PortRange field in the NACL definition.

Target

Filesystem

Scanner

Misconfiguration

Target OS

No response

Debug Output

I am scanning company proprietary code and can't share this. However, I think I might know where the bug is in the trivy code. Line 42 of trivy-checks/checks/cloud/aws/ec2/no_excessive_port_access.go reads:

if rule.Action.EqualTo("allow") && rule.Protocol.EqualTo("-1") || rule.Protocol.EqualTo("all") {

when it should read 

if rule.Action.EqualTo("allow") && (rule.Protocol.EqualTo("-1") || rule.Protocol.EqualTo("all")) {

The missing parentheses may be causing the false positives since if rule.Action is equal to "deny" but rule.Protocol is equal to "all" then the statement will evaluate as true.

Version

Version: 0.52.2

Checklist

• Read the documentation regarding wrong detection
• Ran Trivy with -f json that shows data sources and confirmed that the security advisory in data sources was correct

[nikpivkin]

Hi @majacannavo !

Thanks for the report. Indeed, for the following Terraform configuration the rule "AVD-AWS-0102" is triggered:

resource "aws_network_acl_rule" "bar" {
  rule_number    = 200
  egress         = false
  protocol       = "all"
  rule_action    = "deny"
  cidr_block     = "0.0.0.0/0"
}

But this is only valid for terraform configuration, since in CF "all" is an invalid value for the protocol.

But I'm a little confused by the steps for reproducing it. You say to create a configuration that allows traffic for a specific set of ports and give an example of a deny rule for all ports. Your configuration looks good and the rule shouldn't be triggered.

cat main.json
{
  "Resources": {
      "MyNACL": {
          "Type": "AWS::EC2::NetworkAcl",
          "Properties": {
              "VpcId": "vpc-1122334455aabbccd",
              "Tags": [
                  {
                      "Key": "Name",
                      "Value": "NACLforSSHTraffic"
                  }
              ]
          }
      },
      "InboundRule": {
          "Type": "AWS::EC2::NetworkAclEntry",
          "Properties": {
              "NetworkAclId": {
                  "Ref": "MyNACL"
              },
              "RuleNumber": 100,
              "Protocol": -1,
              "RuleAction": "deny",
              "CidrBlock": "0.0.0.0/0"
          }
      },
      "OutboundRule": {
          "Type": "AWS::EC2::NetworkAclEntry",
          "Properties": {
              "NetworkAclId": {
                  "Ref": "MyNACL"
              },
              "RuleNumber": 100,
              "Protocol": -1,
              "Egress": false,
              "RuleAction": "deny",
              "CidrBlock": "0.0.0.0/0"
          }
      }
  }
}%

trivy conf main.json
2024-06-25T13:26:23+07:00       INFO    Misconfiguration scanning is enabled
2024-06-25T13:26:24+07:00       INFO    Detected config files   num=1

[nikpivkin]

Created #7006

[majacannavo]

Hi @nikpivkin , thanks for your response! Here's the full list of NACL entries (with exact port numbers redacted -- some are single ports and some are ranges) -- hopefully this is enough to reproduce the issue.

{
    "NetworkAcls": [
        {
          ...
            "Entries": [
                {
                    "CidrBlock": "0.0.0.0/0",
                    "Egress": true,
                    "PortRange": {
                        "From": xx,
                        "To": xx
                    },
                    "Protocol": "6",
                    "RuleAction": "allow",
                    "RuleNumber": 20
                },
                {
                    "CidrBlock": "0.0.0.0/0",
                    "Egress": true,
                    "PortRange": {
                        "From": xx,
                        "To": xx
                    },
                    "Protocol": "6",
                    "RuleAction": "allow",
                    "RuleNumber": 30
                },
                {
                    "CidrBlock": "0.0.0.0/0",
                    "Egress": true,
                    "PortRange": {
                        "From": xx,
                        "To": xx
                    },
                    "Protocol": "6",
                    "RuleAction": "allow",
                    "RuleNumber": 40
                },
                {
                    "CidrBlock": "0.0.0.0/0",
                    "Egress": true,
                    "PortRange": {
                        "From": xx,
                        "To": xx
                    },
                    "Protocol": "6",
                    "RuleAction": "allow",
                    "RuleNumber": 60
                },
                {
                    "CidrBlock": "0.0.0.0/0",
                    "Egress": true,
                    "Protocol": "-1",
                    "RuleAction": "deny",
                    "RuleNumber": 32767
                },
                {
                    "CidrBlock": "0.0.0.0/0",
                    "Egress": false,
                    "PortRange": {
                        "From": xx,
                        "To": xx
                    },
                    "Protocol": "6",
                    "RuleAction": "allow",
                    "RuleNumber": 20
                },
                {
                    "CidrBlock": "0.0.0.0/0",
                    "Egress": false,
                    "PortRange": {
                        "From": xx,
                        "To": xx
                    },
                    "Protocol": "6",
                    "RuleAction": "allow",
                    "RuleNumber": 30
                },
                {
                    "CidrBlock": "0.0.0.0/0",
                    "Egress": false,
                    "PortRange": {
                        "From": xx,
                        "To": xx
                    },
                    "Protocol": "6",
                    "RuleAction": "allow",
                    "RuleNumber": 40
                },
                {
                    "CidrBlock": "0.0.0.0/0",
                    "Egress": false,
                    "PortRange": {
                        "From": xx,
                        "To": xx
                    },
                    "Protocol": "6",
                    "RuleAction": "allow",
                    "RuleNumber": 50
                },
                {
                    "CidrBlock": "0.0.0.0/0",
                    "Egress": false,
                    "PortRange": {
                        "From": xx,
                        "To": xx
                    },
                    "Protocol": "6",
                    "RuleAction": "allow",
                    "RuleNumber": 60
                },
                {
                    "CidrBlock": "0.0.0.0/0",
                    "Egress": false,
                    "Protocol": "-1",
                    "RuleAction": "deny",
                    "RuleNumber": 32767
                }
            ],
            "IsDefault": false,
        ...
        }
    ]
}

[simar7]

thanks @majacannavo we will take a look and get back to you.

[simar7]

@majacannavo are you still able to repro this issue on the latest (v0.53.0) Trivy build?

[majacannavo]

It no longer seems to be an issue -- thanks! Did you make another fix or just that first one?

[nikpivkin]

@majacannavo Only this #7006

[majacannavo]

Looks like it worked! I wonder if maybe there was some sort of conversion happening from -1 to all during the scan that was triggering the bug... but regardless it seems to be fixed -- thanks for your quick response on this!