bug(aws): vpc peering route table with unrestricted cidr false-positive

[Szakalakamaka]

It seems that the issue may stem from the query found at this link, which likely scans every AWS route. Consequently, it may flag route tables associated with Internet Gateway (IGW) and NAT Gateway configurations, which are expected to have 0.0.0.0/0 blocks, as instances of "VPC Peering Route Table with Unrestricted CIDR." This leads to false-positive findings across all VPCs by default.
Expected Outcome

Expected Behavior

Ideally, the vulnerability detection should only occur for route tables specifically designated for VPC peering.
Current Behavior

Actual Behavior

Despite not utilizing VPC peering, the detection of "VPC Peering Route Table with Unrestricted CIDR" persists.
Steps to Recreate the Issue

Steps to Reproduce the Problem

1. Utilize the Terraform public VPC module to establish a VPC devoid of any VPC peering.
2. Verify that KICS identifies "VPC Peering Route Table with Unrestricted CIDR."

Specifications

• Version: v1.7.13
• Platform: AWS

[gabriel-cx]

Hi @Szakalakamaka ,

Thank you for your inputs!
We asked our AppSec team to check your point of view; We will update you asap.

(APPSEC-2449)

[gabriel-cx]

Hi @Szakalakamaka ,

Our AppSec team is requesting the following:
It's possible for you to provide us a specific example (a simple sample) where you show what you expect and what you are getting? Like this they can properly analyze your suggestion.

Thank you again.

[tnt-anthony-williams]

Judging by the example code you are trying to stop people adding a 0.0.0.0/0 route via a peer connect (which I do not think will work anyway as the peer connect only routes ips within the vpc cidr ranges), but this alert is being triggered if any route in the same route table as a peer connect is for 0.0.0.0/0.

This triggers KICS:

  route {
    nat_gateway_id = aws_nat_gateway.ngw.id
    cidr_block     = "0.0.0.0/0"
  }

  route {
    cidr_block                = 10.10.0.0/16
    vpc_peering_connection_id = aws_vpc_peering_connection.peer.id
  }

even though the route is not tied to the peer connect.

[ArturRibeiro-CX]

Hi @Szakalakamaka @tnt-anthony-williams,
Thanks for you answers so far!

During my evaluation, I conducted testing across different versions of KICS to assess the presence of false positives (FPs).

KICS Versions Tested:
Versions 1.7.11 to 1.7.13 (as per your latest reports).
Version 2.0.1 (latest version of KICS).

Test Files:
The file you provided above on your latest comment.
Additional test file provided below .

resource "aws_nat_gateway" "ngw" {
  allocation_id = "eipalloc-12345678"
  subnet_id     = "subnet-12345678"
}
 
resource "aws_vpc_peering_connection" "peer" {
  vpc_id        = "vpc-12345678"
  peer_vpc_id   = "vpc-87654321"
  peer_region   = "us-west-2"
  auto_accept   = true
}
 
resource "aws_route" "nat_gateway_route" {
  route_table_id = "rtb-12345678"
  nat_gateway_id = aws_nat_gateway.ngw.id
  cidr_block     = "0.0.0.0/0"
}
`
resource "aws_route" "vpc_peering_route_restricted" {
  route_table_id             = "rtb-87654321"
  vpc_peering_connection_id  = aws_vpc_peering_connection.peer.id
  cidr_block                 = "10.10.0.0/16"
}
 
resource "aws_route" "vpc_peering_route_unrestricted" {
  route_table_id             = "rtb-87654321"
  vpc_peering_connection_id  = aws_vpc_peering_connection.peer.id
  cidr_block                 = "0.0.0.0/0"
}

Testing Results:
Versions 1.7.11 to 1.7.13:
No false positives detected in the file provided or the additional test file.
Version 2.0.1:
Similarly, no false positives observed in either test file.

Conclusion:
We weren't able to reproduce the False Positive detected while performing the tests on the latest KICS version or previous ones. Could you please provide more information or a suitable test case for us to tackle the FP issue?

Thanks for the information provided so far and for your patience!

[tnt-anthony-williams]

This simple file triggers the false positive:

resource "aws_route_table" "art_nat_gw_out" {
  vpc_id = aws_vpc.av_xxx.id

  route {
    nat_gateway_id = aws_nat_gateway.ngw01.id
    cidr_block     = "0.0.0.0/0"
  }

  route {
    cidr_block                = "10.0.0.0/24"
    vpc_peering_connection_id = aws_vpc_peering_connection.avpv.id
  }

}

KICS run:

 Scanning with Keeping Infrastructure as Code Secure v2.0.1


Preparing Scan Assets: Done                                                                                                 
Executing queries: [---------------------------------------------------] 100.00%



Resource Not Using Tags, Severity: INFO, Results: 1
Description: AWS services resource tags are an essential part of managing components. As a best practice, the field 'tags' should have additional tags defined other than 'Name'
Platform: Terraform
Learn more about this vulnerability: https://docs.kics.io/latest/queries/terraform-queries/aws/e38a8e0a-b88b-4902-b3fe-b0fcb17d5c10

	[1]: ../../path/vpc.tf:1

		001: resource "aws_route_table" "art_nat_gw_out" {
		002:   vpc_id = aws_vpc.av_xxxx.id
		003: 


IAM Access Analyzer Not Enabled, Severity: LOW, Results: 1
Description: IAM Access Analyzer should be enabled and configured to continuously monitor resource permissions
Platform: Terraform
Learn more about this vulnerability: https://docs.kics.io/latest/queries/terraform-queries/aws/e592a0c5-5bdb-414c-9066-5dba7cdea370

	[1]: ../../path/vpc.tf:1

		001: resource "aws_route_table" "art_nat_gw_out" {
		002:   vpc_id = aws_vpc.av_xxxx.id
		003: 


VPC Peering Route Table with Unrestricted CIDR, Severity: HIGH, Results: 1
Description: VPC Peering Route Table should restrict CIDR
Platform: Terraform
Learn more about this vulnerability: https://docs.kics.io/latest/queries/terraform-queries/aws/b3a41501-f712-4c4f-81e5-db9a7dc0e34e

	[1]: ../../path/vpc.tf:4

		003: 
		004:   route {
		005:     nat_gateway_id = aws_nat_gateway.ngw01.id



Results Summary:
CRITICAL: 0
HIGH: 1
MEDIUM: 0
LOW: 1
INFO: 1
TOTAL: 3

[ArturRibeiro-CX]

Hi @Szakalakamaka @tnt-anthony-williams ,

We have merged the PR that addresses the false positive issue you reported. This should resolve the problem as described. However, if you encounter any further issues, please feel free to re-open this issue or create a new one if necessary.

Thank you for your contribution and feedback!