Dangerous Defaults

Dangerous Defaults # 3 - Rules overwriting each other

Terraform has an interesting quirk. Security groups can be defined inline using 2 different methods. Like in Ghostbusters, you should never cross stream. Mixing methods might be valid but it causes unexpected security settings. CoGuard is the only IaC scanner that identifies the overwritten rules sets.

Albert Heinle
Written by
Albert Heinle

We have a series of articles looking at common misconfigurations and dangerous defaults we’ve seen in the wild. 

Configuration settings can create security gaps that expose applications and their data to cyberattack and possible breach. Many of the configurations happen because dev, infrastructure and operations teams do not change the default configuration of the device, application or provider during installation. We are on the hunt for common configuration settings in the wild and trying to help teams find their configurations and set appropriate/intential values. 

Next up, Terraform and firewall rules, particularly on AWS and Azure.

Firewall rules overwriting each other

How you define security groups for AWS with Terraform matters. The Terraform documentation defines the interaction between rules that will be overwritten. 

You should not use the aws_vpc_security_group_egress_rule and aws_vpc_security_group_ingress_rule resources in conjunction with an aws_security_group resource with in-line rules or with aws_security_group_rule resources defined for the same Security Group, as rule conflicts may occur and rules will be overwritten.

There need to be checks ensuring that these conflicting definitions are not made at all. These should be caught in your IaC Terraform files by your friendly neighbourhood IaC static analyzer (you’ve embedded in your CI/CD pipeline, right?).

Example Terraform for AWS VPC

resource "aws_security_group" "allow_tls" {
  name        = "allow_tls"
  description = "Allow TLS inbound traffic"
  vpc_id      = aws_vpc.main.id

  ingress {
    description      = "TLS from VPC"
    from_port        = 443
    to_port          = 443
    protocol         = "tcp"
    cidr_blocks      = [aws_vpc.main.cidr_block]
    ipv6_cidr_blocks = [aws_vpc.main.ipv6_cidr_block]
  }

  egress {
    from_port        = 0
    to_port          = 0
    protocol         = "-1"
    cidr_blocks      = ["0.0.0.0/0"]
    ipv6_cidr_blocks = ["::/0"]
  }

  tags = {
    Name = "allow_tls"
  }
}

resource "aws_vpc_security_group_egress_rule" "example" {
  security_group_id = aws_security_group.allow_tls.id

  cidr_ipv4   = "10.0.0.0/8"
  from_port   = 443
  ip_protocol = "tcp"
  to_port     = 443
}

Test Environment

  • CoGuard CLI version 0.2.14
  • KICS version 1.7.9-alpine (Docker)
  • Snyk version 1.1203.0

All tests were done on the above file using macOS and linux versions. 

Summary Results

Severity CoGuard Snyk KICS
Total 2 1 3
High 1    
Medium      
Low 1 1 1
INFO     2

Because the Terraform file is a valid file it does not trigger a lot of configuration errors. All three tools identify issues with the AWS Security Groups. CoGuard identifies the mixing of AWS security group definitions. 

CoGuard Results

$ coguard folder ./

          XXXXXXXXXXXK
      xXXXXXXXXXXXXXXXXXXl
    XXXXX.            ;XXXXO       .XXXXXXXXXX     oXXXX        XXXXc       xXXXX'       'XXXXXXXXXXXXO     XXXXXXXXXXX;
  lXXXx    lXXXXXXXX,    0XXX;   cXXXXXXXXXXXXXX.  oXXXX        XXXXc      :XXXXXX       'XXXXXXXXXXXXXXX.  XXXXXXXXXXXXXX'
 dXXX.  .XXXXXx  0XXXXX    ...  dXXXX'      cXXXX. oXXXX        XXXXc     .XXXXXXX0      'XXXX'      OXXXX  XXXXo     .XXXXk
;XXX   xXXX    do   .XXXc      'XXXX,              oXXXX        XXXXc     XXXX.oXXXd     'XXXX'      ,XXXX. XXXXd       XXXXd
0XXl  ;XXk     ,,     KXX.     lXXXXoXXXX        XXXXc    OXXXl  0XXX:    'XXXX'     .XXXXk  XXXXd       lXXXX
XXX:  oXX: cll.  ,ll: oXX;     oXXXX    .XXXXXXXXo oXXXX        XXXXc   oXXXO   .XXXX.   'XXXXXXXXXXXXXX;   XXXXd       lXXXX
OXXo  ;XXO     do     KXX.     cXXXX.   .XXXXXXXXo oXXXX        XXXXc  ;XXXX     :XXXX   'XXXXXXXXXXXXl     XXXXd       xXXX0
;XXX.  oXXX    ,,   .XXX:      .XXXXo        XXXXo lXXXX       .XXXX: .XXXXXXXXXXXXXXXO  'XXXX'   .XXXXd    XXXXd      ,XXXX;
 oXXX.   XXXXXX:lXXXXXK   ;XXX: .XXXXX.      XXXXo  XXXXX     .XXXX0  XXXXx        XXXXo 'XXXX'    .XXXX0   XXXXd    .XXXXX,
  cXXXO    ;XXXXXXXX.    XXXX'    xXXXXXXXXXXXXXX.   kXXXXXXXXXXXXd  kXXXX         ,XXXX:'XXXX'      XXXXK  XXXXXXXXXXXXXl
    KXXXX;            lXXXXx         'XXXXXXX           cXXXXXX;    lXXXX,          dXXXXlXXXX'       KXXXX XXXXXXXXK
      oXXXXXXXXXXXXXXXXXX:
          OXXXXXXXXXXd
    
SCANNING FOLDER blog-examples-firewall
Found file /AWS-Firewall-Rules-Example.tf
Found configuration files for terraform in non-standard location.
SCANNING OF blog-examples-firewall COMPLETED
Scan result: 2 checks failed, 1 High/0 Medium/1 Low (🔧 0 candidates for auto-remediation)
 X Severity 5: terraform_aws_no_mix_network_security_group_rules (affected files: ./AWS-Firewall-Rules-Example.tf for service terraform)
Documentation:  The AWS provider for Terraform allows the definition of network
security rules both inline in a `aws_security_group` resource, as
well as in a `aws_vpc_security_group_egress_rule` resource.
However, in the current version of Terraform, mixing is not
recommended, since it can lead to rules being overwritten.
Remediation: Ensure that you either always define network
security rules using the `egress` directive within
`aws_security_group` resource definitions, or separately as
`aws_vpc_security_group_egress_rule` resource, but do not mix
both approaches.   Source: https://registry.terraform.io/provider
s/hashicorp/aws/latest/docs/resources/security_group
 X Severity 1: terraform_aws_no_unused_security_groups (affected files: ./AWS-Firewall-Rules-Example.tf for service terraform)
Documentation:  When defining a security group for EC2-instances, we also expect
it to be used.  Remediation: For every resource of type
`aws_security_group`, ensure that it is referenced at least in
one `aws_instance` resource under `security_groups` or
`vpc_security_group_ids`.   Source: https://registry.terraform.io
/providers/hashicorp/aws/latest/docs/resources/instance
Scan result: 2 checks failed, 1 High/0 Medium/1 Low (🔧 0 candidates for auto-remediation)

Snyk Results

$ snyk iac test --report --org=927c4fe6-f615-45ae-97f8-954e44413e8d

Snyk Infrastructure as Code

✔ Test completed.

Issues

Low Severity Issues: 1

  [Low] AWS Security Group allows open egress
  Info:    The inline security group rule allows open egress. Open egress can be
           used to exfiltrate data to unauthorized destinations, and enable
           access to potentially malicious resources
  Rule:    https://security.snyk.io/rules/cloud/SNYK-CC-TF-73
  Path:    resource > aws_security_group[allow_tls] > egress
  File:    AWS-Firewall-Rules-Example.tf
  Resolve: Set `egress.cidr_blocks` attribute to specific ranges e.g.
           `192.168.1.0/24`

-------------------------------------------------------

Test Summary

  Organization: d-U5bKD53qopZ7jyVZGLXF3N
  Project name: blog-examples-firewall

✔ Files without issues: 0
✗ Files with issues: 1
  Ignored issues: 0
  Total issues: 1 [ 0 critical, 0 high, 0 medium, 1 low ]

-------------------------------------------------------

Report Complete

KICS Results

docker run -t -v ~/src/blog-examples-firewall:/path checkmarx/kics:latest scan -p /path/AWS-Firewall-Rules-Example.tf -o "/path/"

    .0MO.      
    OMMMx      
    ;NMX;      
     ...           ...              ....     
WMMMd     cWMMM0.  KMMMO      ;xKWMMMMNOc.     ,xXMMMMMWXkc.
WMMMd   .0MMMN:    KMMMO    :XMMMMMMMMMMMWl   xMMMMMWMMMMMMl
WMMMd  lWMMMO.     KMMMO   xMMMMKc...'lXMk   ,MMMMx   .;dXx 
WMMMd.0MMMX;       KMMMO  cMMMMd        '    'MMMMNl'       
WMMMNWMMMMl        KMMMO  0MMMNoMMMMMMMXkl.  
WMMMMMMMMMMo       KMMMO  0MMMX .ckKWMMMMMM0.
WMMMMWokMMMMk      KMMMO  oMMMMc              .     .:OMMMM0
WMMMK.  dMMMM0.    KMMMO   KMMMMx'    ,kNc   :WOc.    .NMMMX
WMMMd    cWMMMX.   KMMMO    kMMMMMWXNMMMMMd .WMMMMWKO0NMMMMl
WMMMd     ,NMMMN,  KMMMO     'xNMMMMMMMNx,   .l0WMMMMMMMWk, 
xkkk:      ,kkkkx  okkkl        ;xKXKx;          ;dOKKkc    


Scanning with Keeping Infrastructure as Code Secure v1.7.9


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

Files scanned: 1
Parsed files: 1
Queries loaded: 1045
Queries failed to execute: 0

------------------------------------

Security Group Rule Without Description, Severity: INFO, Results: 1
Description: It's considered a best practice for all rules in AWS Security Group to have a description
Platform: Terraform
Learn more about this vulnerability: https://docs.kics.io/latest/queries/terraform-queries/aws/68eb4bf3-f9bf-463d-b5cf-e029bb446d2e

	[1]: ../../path/AWS-Firewall-Rules-Example.tf:15

		014: 
		015:   egress {
		016:     from_port        = 0


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/AWS-Firewall-Rules-Example.tf:23

		022: 
		023:   tags = {
		024:     Name = "allow_tls"


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/AWS-Firewall-Rules-Example.tf:1

		001: resource "aws_security_group" "allow_tls" {
		002:   name        = "allow_tls"
		003:   description = "Allow TLS inbound traffic"



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

Results saved to file /path/results.json
Generating Reports: Done      
Scan duration: 16.755121508s

Conclusion

CoGuard was the only analyzer to identify the risk associated with mixing inline network security rules. 

All of the configurations are valid. They pass a syntax check and a validity check. There are unique circumstances as related to the structure for AWS and Azure in mixing security group definitions. CoGuard is able to identify a possible risk related to the mixed uses age of aws_security_group and aws_vpc_security_group_egress_rule. While this might seem pedantic, it is possible that different developers working on the same infrastructure codebase at different points in time might each use the different but valid network security rules. 

The role of the static analyzer is to detect:

  • security vulnerabilities,
  • performance issues,
  • non-compliance with standards,
  • And the use of out of date programming constructs.

And alert the teams to possible conflicts and risk. So that decisions can be made about the method and actual network security definitions. 

Get started for free

At CoGuard, we believe that static analysis is an incredibly useful tool for developers, operations and security teams. As teams adopt cloud native applications, security and configuration requires new insights across cloud configurations, containers, applications and firewalls. You can get started for free today. 

pip3 install coguard-cli
coguard folder ./

Photo credit: Diogo Fagundes on Unsplash

Explore a test environment

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Check out and explore a test environment to run infra audits on sample repositories of web applications and view select reports on CoGuard's interative dashboard today.