Insecure Network Communication

Securing TLS configuration

About Insecure TLS Configuration

What is insecure TLS configuration?

Insecure TLS (Transport Layer Security) configuration refers to the use of weak or vulnerable cryptographic algorithms or protocols in the configuration of TLS on a system or application.

TLS is used to secure communication channels between clients and servers. Insecure TLS configuration can lead to a range of security vulnerabilities.

Check out these videos for a high-level explanation:

• Weak Algorithms

• Weak Cipher Suites

What is the impact of insecure TLS configuration?

Insecure TLS (Transport Layer Security) configuration can have significant impacts on the security and privacy of communication channels between clients and servers.

Here are some of the potential impacts:

• Man-in-the-middle (MITM) attacks: Weak or outdated cryptographic algorithms can be exploited by attackers to intercept and modify data in transit between a client and server. This can enable attackers to steal sensitive data or manipulate communication channels to launch other attacks.
• Information disclosure: Insecure TLS configuration can allow attackers to gain access to sensitive data, such as login credentials or personal information, transmitted between the client and server. This can lead to data breaches or compromise of sensitive information.

How to prevent insecure TLS configuration?

To prevent insecure TLS (Transport Layer Security) configuration, several measures can be taken, including:

• Use strong cryptographic algorithms and protocols: Use strong cryptographic algorithms and protocols, such as TLS 1.2 or higher, and disable outdated or weak algorithms, such as SSLv2 and SSLv3. This can help prevent attackers from exploiting vulnerabilities in the encryption and authentication processes.
• Use appropriate key sizes: Use appropriate key sizes to ensure that the cryptographic keys used in the TLS communication are strong enough to resist attacks. Key sizes of 2048 bits or higher are recommended.
• Regularly update software and systems: Regularly update software and systems to ensure that the latest security patches are applied and known vulnerabilities are addressed.

References

Taxonomies

• OWASP Top 10 - A02 Cryptographic Failures
• CWE-327: Use of a Broken or Risky Cryptographic Algorithm

Explanation & Prevention

• OWASP: Transport Layer Protection Cheat Sheet
• WASC-04: Insufficient Transport Layer Protection
• POODLE (CVE Details)
• BEAST (CVE Details)
• CRIME (CVE Details)
• FREAK (CVE Details)
• BREACH (CVE Details)
• LOGJAM (CVE Details)

Related CVEs

• CVE Details: CWE-327

Training

• Secure Code Warrior: Weak TLS Algorithms
• Secure Code Warrior: Weak TLS Cipher Suites

Use strong Ciphers for ELB

ELB Predefined or Custom Security Policies must not use weak ciphers, to reduce the risk of the SSL connection between the client and the load balancer being exploited. That means the ELB Listeners must not have Policies that possess Ciphers that coincide with any of a predefined list of weak ciphers.

Rule-specific references:

• AWS ELB

Option A: Use a strong TLS cipher

The Properties.Policies of an AWS Load Balancer (AWS::ElasticLoadBalancing::LoadBalancer) must not coincide with any of a predefined list of weak ciphers.

1. Review the Load Balancer Properties.Policies to make sure known secure TLS ciphers are being used. The default value (if not visibly present) of Properties.Policies uses a known good TLS cipher

2. If an out-of-date (less than optimal) cipher is being used replace it

3. Locate the following vulnerable pattern:

   Resources:
       MyLoadBalancer:
           Type: AWS::ElasticLoadBalancing::LoadBalancer
           Properties:
             AvailabilityZones:
             - "us-east-2a"
             CrossZone: true
             Listeners:
             - InstancePort: '80'
               InstanceProtocol: HTTP
               LoadBalancerPort: '443'
               Protocol: HTTPS
               PolicyNames:
               - My-SSLNegotiation-Policy
               SSLCertificateId: arn:aws:iam::123456789012:server-certificate/my-server-certificate
             HealthCheck:
               Target: HTTP:80/
               HealthyThreshold: '2'
               UnhealthyThreshold: '3'
               Interval: '10'
               Timeout: '5'
             Policies:
             - PolicyName: My-SSLNegotiation-Policy
               PolicyType: SSLNegotiationPolicyType
               Attributes:
               - Name: TLS_RSA_NULL_SHA1
                 Value: ELBSecurityPolicy-TLS-1-2-2017-01
               - Name: DHE-DSS-DES-CBC3-SHA
                 Value: ELBSecurityPolicy-TLS-1-2-2017-01
             - PolicyName: My-SSLNegotiation-Policy2
               PolicyType: SSLNegotiationPolicyType
               Attributes:
               - Name: TLS_DHE_PSK_WITH_NULL_SHA256
                 Value: ELBSecurityPolicy-TLS-1-2-2017-01

4. Modify the config to something like the following:

   Resources:
       MyLoadBalancer:
           Type: AWS::ElasticLoadBalancing::LoadBalancer
           Properties:
             AvailabilityZones:
             - "us-east-2a"
             CrossZone: true
             Listeners:
             - InstancePort: '80'
               InstanceProtocol: HTTP
               LoadBalancerPort: '443'
               Protocol: HTTPS
               PolicyNames:
               - My-SSLNegotiation-Policy
               SSLCertificateId: arn:aws:iam::123456789012:server-certificate/my-server-certificate
             HealthCheck:
               Target: HTTP:80/
               HealthyThreshold: '2'
               UnhealthyThreshold: '3'
               Interval: '10'
               Timeout: '5'
             Policies:
             - PolicyName: My-SSLNegotiation-Policy
               PolicyType: SSLNegotiationPolicyType
               Attributes:
               - Name: Reference-Security-Policy
                 Value: ELBSecurityPolicy-TLS-1-2-2017-01

5. Test it

6. Ship it 🚢 and relax 🌴

Use a secure minimum protocol version

CloudFront Minimum Protocol version should be at least TLS 1.2.

Rule-specific references:

• AWS CloudFront Distribution ViewerCertificate
• AWS CloudFront Distribution

Option A: Use a secure ViewerCertificate Minimum Protocol Version

The cloudfrontdistribution.ViewerCertificate.MinimumProtocolVersion should be at least "TLSv1.1" but preferably more recent.

1. Review cloudfrontdistribution.ViewerCertificate.MinimumProtocolVersion. The minimum value should be "TLSv1.1" but preferably more recent

2. If the MinimumProtocolVersion value is not visible, be sure to set it to the most recent version that will work for you, or add CloudFrontDefaultCertificate with the value true. See the supported versions for the options available to you

3. Locate the following vulnerable pattern:

   AWSTemplateFormatVersion: "2010-09-09"
   Resources:
     cloudfrontdistribution:
       Type: AWS::CloudFront::Distribution
       Properties:
         DistributionConfig:
           CacheBehaviors:
             - LambdaFunctionAssociations:
                 - EventType: viewer-request
                   LambdaFunctionARN: examp
           DefaultCacheBehavior:
             LambdaFunctionAssociations:
               - EventType: viewer-request
                 LambdaFunctionARN: examp
           IPV6Enabled: true
           Origins:
             - CustomOriginConfig:
                 OriginKeepaliveTimeout: 60
                 OriginReadTimeout: 30
         Tags:
           - Key: name
             Value: example
         ViewerCertificate:
           CloudFrontDefaultCertificate: false
           MinimumProtocolVersion: SSLv3

4. Modify the config to something like the following:

   AWSTemplateFormatVersion: "2010-09-09"
   Resources:
     cloudfrontdistribution:
       Type: AWS::CloudFront::Distribution
       Properties:
         DistributionConfig:
           CacheBehaviors:
             - LambdaFunctionAssociations:
                 - EventType: viewer-request
                   LambdaFunctionARN: examp
           DefaultCacheBehavior:
             LambdaFunctionAssociations:
               - EventType: viewer-request
                 LambdaFunctionARN: examp
           IPV6Enabled: true
           Origins:
             - CustomOriginConfig:
                 OriginKeepaliveTimeout: 60
                 OriginReadTimeout: 30
         Tags:
           - Key: name
             Value: example
         ViewerCertificate:
           CloudFrontDefaultCertificate: true

5. Test it

6. Ship it 🚢 and relax 🌴

Option B: Use a secure Minimum Protocol version

1. Check that any cloudfrontdistribution (Type: AWS::CloudFront::Distribution) ViewerCertificate.MinimumProtocolVersion parameters are at least TLSv1.2_x (Ex: "TLSv1.2_2018", "TLSv1.2_2019", "TLSv1.2_2021")

2. Locate the following vulnerable pattern:

   AWSTemplateFormatVersion: 2010-09-09
   Resources:
     cloudfrontdistribution:
       Type: AWS::CloudFront::Distribution
       Properties:
         DistributionConfig:
           CacheBehaviors:
             - LambdaFunctionAssociations:
                 - EventType: string-value
                   LambdaFunctionARN: string-value
           DefaultCacheBehavior:
             LambdaFunctionAssociations:
               - EventType: string-value
                 LambdaFunctionARN: string-value
           IPV6Enabled: boolean-value
           Origins:
             - CustomOriginConfig:
                 OriginKeepaliveTimeout: integer-value
                 OriginReadTimeout: integer-value
           ViewerCertificate:
               AcmCertificateArn: String
               CloudFrontDefaultCertificate: true
               IamCertificateId: String
               MinimumProtocolVersion: "TLSv1.1_2016"
               SslSupportMethod: String
         Tags:
           - Key: string-value
             Value: string-value

3. Modify the config to something like the following:

   AWSTemplateFormatVersion: 2010-09-09
   Resources:
     cloudfrontdistribution:
       Type: AWS::CloudFront::Distribution
       Properties:
         DistributionConfig:
           CacheBehaviors:
             - LambdaFunctionAssociations:
                 - EventType: string-value
                   LambdaFunctionARN: string-value
           DefaultCacheBehavior:
             LambdaFunctionAssociations:
               - EventType: string-value
                 LambdaFunctionARN: string-value
           IPV6Enabled: boolean-value
           Origins:
             - CustomOriginConfig:
                 OriginKeepaliveTimeout: integer-value
                 OriginReadTimeout: integer-value
           ViewerCertificate:
               AcmCertificateArn: String
               CloudFrontDefaultCertificate: true
               IamCertificateId: String
               MinimumProtocolVersion: "TLSv1.2_2018"
               SslSupportMethod: String
         Tags:
           - Key: string-value
             Value: string-value

4. Test it

5. Ship it 🚢 and relax 🌴

Fixing Cleartext Transmission

About Cleartext Transmission

What is Cleartext Transmission?

Cleartext transmission, also known as plaintext transmission, refers to the process of transmitting data over a network or communication channel without encryption or other security measures that protect the data from interception or unauthorized access.

In cleartext transmission, the data is transmitted in plain, human-readable format, which means that anyone who has access to the communication channel can read, intercept, or modify the data without any difficulty.

Cleartext transmission can occur in various communication protocols, such as HTTP, FTP, SMTP, and Telnet, and can affect various types of data, such as login credentials, credit card information, personal data, and other types of sensitive information.

Check out these videos for a high-level explanation:

• Communication over cleartext protocol

• Unprotected transport of sensitive information

• Unprotected transport of credentials

What is the impact of Cleartext Transmission?

Cleartext transmission can lead to various security threats and risks, such as:

• Information disclosure: Cleartext transmission can expose sensitive or confidential information to unauthorized parties, such as passwords, credit card numbers, personal data, or other types of sensitive information.
• Man-in-the-middle attacks: Cleartext transmission can be intercepted by attackers who can eavesdrop on the communication channel, modify or steal the data, or impersonate the parties involved in the communication.
• Identity theft: Cleartext transmission can lead to identity theft, where attackers can use stolen personal data to assume the identity of victims and perform various malicious activities, such as financial fraud or unauthorized access to systems.
• Data tampering: Cleartext transmission can allow attackers to modify or inject false data into the communication channel, leading to data tampering, data corruption, or other types of malicious activities.

How to prevent Cleartext Transmission?

To prevent cleartext transmission, you can take the following steps:

• Use encryption: Encrypt sensitive data before transmitting it over any communication channel. Use encryption protocols such as SSL/TLS or HTTPS to ensure that data is encrypted in transit.
• Secure communication channels: Use secure communication channels such as SFTP, SSH, or VPNs to transmit sensitive data. These protocols provide encryption and authentication, which can help prevent unauthorized access and eavesdropping.
• Disable cleartext protocols: Disable cleartext protocols such as HTTP or FTP, and use only encrypted protocols such as HTTPS or SFTP to transmit sensitive data.
• Implement data validation: Implement data validation mechanisms to ensure that only valid data is transmitted. Validate user input and filter out any sensitive data before transmitting it.

References

Taxonomies

• OWASP Top 10 - A02 Cryptographic Failures
• CWE-319: Cleartext Transmission of Sensitive Information

Related CVEs

• CVE Details: CWE-319

Training

• Secure Code Warrior: Communication Over Cleartext Protocol
• Secure Code Warrior: Unprotected Transport of Credentials
• Secure Code Warrior: Unprotected Transport of Sensitive Information

ALB Listening on HTTP

All Application Load Balancers (ALB) should block connection requests over HTTP so that All traffic to and from Application Load Balancers is TLS encrypted.

Rule-specific references:

• Manage AWS Application Load Balancer

Option A: The value of Listeners should not be HTTP

For the AWS::ElasticLoadBalancing::LoadBalancer The value of Properties.Listeners.Protocol should not be HTTP but HTTPS. For the AWS::ElasticLoadBalancingV2::Listener The value of Properties.Protocol should not be HTTP.

1. Locate the following pattern:

   AWSTemplateFormatVersion: 2010-09-09
   Resources:
       MyLoadBalancer:
           Type: AWS::ElasticLoadBalancing::LoadBalancer
           Properties:
             AvailabilityZones:
             - "us-east-2a"
             CrossZone: true
             Listeners:
             - InstancePort: '80'
               InstanceProtocol: HTTPS
               LoadBalancerPort: '443'
               Protocol: HTTP
               PolicyNames:
               - My-SSLNegotiation-Policy
               SSLCertificateId: arn:aws:iam::123456789012:server-certificate/my-server-certificate
             Scheme: internal
       HTTPlistener:
           Type: "AWS::ElasticLoadBalancingV2::Listener"
           Properties:
               DefaultActions:
               - Type: redirect
               LoadBalancerArn: !Ref myLoadBalancer
               Port: 80
               Protocol: HTTP

2. Modify it to something like the following:

   AWSTemplateFormatVersion: 2010-09-09
   Resources:
       MyLoadBalancer:
           Type: AWS::ElasticLoadBalancing::LoadBalancer
           Properties:
             AvailabilityZones:
             - "us-east-2a"
             CrossZone: true
             Listeners:
             - InstancePort: '80'
               InstanceProtocol: HTTPS
               LoadBalancerPort: '443'
               Protocol: HTTPS
               PolicyNames:
               - My-SSLNegotiation-Policy
               SSLCertificateId: arn:aws:iam::123456789012:server-certificate/my-server-certificate
             Scheme: internal

3. Test it

4. Ship it 🚢 and relax 🌴

HTTP Port Open

The HTTP port (80) is open in a Security Group to the world. HTTPS which protects the integrity and confidentiality of transmitted data is the preferred option for HTTP traffic.

If you are transferring data of a sensitive nature then HTTPS should generally always be used. Sensitive data includes but is not limited to such items as:

• Personally Identifiable Information
• Login/authentication details
• Passwords, secret keys
• Credit card numbers

If you are not transferring any sensitive content, then besides concerns such as Search Engine Optimisation (SEO) and similar non-security related topics, Using HTTPS is less of an issue.

Rule-specific references:

• AWS EC2 Security Group

Option A: Consider closing HTTP ingress port (80)

All Security Groups (Those of Type: AWS::EC2::SecurityGroup) should not contain Properties.SecurityGroupIngress with port 80 open to the world. Either remove port 80 or significantly reduce the number of IP addresses that can access the Security Group.

1. Locate the following pattern:

   Resources:
     InstanceSecurityGroup:
       Type: AWS::EC2::SecurityGroup
       Properties:
           GroupDescription: Allow HTTP to client host
           VpcId:
             Ref: myVPC
           SecurityGroupIngress:
           - IpProtocol: tcp
             FromPort: 80
             ToPort: 80
             CidrIp: 0.0.0.0/0

2. Modify the config to something like the following:

   Resources:
     InstanceSecurityGroup:
       Type: AWS::EC2::SecurityGroup
       Properties:
           GroupDescription: Allow HTTP to client host
           VpcId:
             Ref: myVPC
           SecurityGroupIngress:
           - IpProtocol: tcp
             FromPort: 80
             ToPort: 80
             CidrIp: 192.168.0.0/16

3. Test it

4. Ship it 🚢 and relax 🌴