Skip to main content

Insecure Network Communication

This page currently covers:

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​

Explanation & Prevention​

Training​

Insecure SSL/TLS protocol version​

This rule detects usages of insecure SSL/TLS protocol versions in the Python SSL Module and pyOpenSSL. Specifically, protocol versions that are not:

  • TLSv1.2
  • TLSv1.3
  • DTLSv1.2
  • DTLSv1.3

Several highly publicized and exploitable flaws exist in all versions, except the ones listed above.

Option A: Use a secure TLS protocol version​

It is recommended to enforce TLS 1.2 as the minimum protocol version. Avoid downgrading attacks by disabling insecure versions such as SSL 3.0.

  1. Go through the issues that GuardRails identified in the PR/MR.

  2. Replace insecure SSL/TLS protocol versions with TLSv1.2 or TLSv1.3.

    context = SSL.Context(SSL.TLS_SERVER_METHOD)
    #Insecure example
    context.set_min_proto_version(SSL.TLS1_1_VERSION)
    context = SSL.Context(SSL.TLS_SERVER_METHOD)
    #Secure example
    context.set_min_proto_version(SSL.TLS1_2_VERSION)

  3. Test it

  4. Ship it 🚢 and relax 🌴

Fixing Certificate Validation​

About Certificate Validation

What is Improper Certificate Validation?​

Improper certificate validation refers to a security vulnerability where a system fails to properly verify the authenticity of a digital certificate presented by a remote party during a communication. This can lead to the acceptance of forged or malicious certificates, allowing attackers to perform various attacks such as man-in-the-middle attacks or impersonation attacks.

Proper certificate validation is crucial for maintaining the security of SSL/TLS encrypted communication and ensuring the confidentiality, integrity, and authenticity of data exchanged over the network.

Check out these videos for a high-level explanation:

  • Weak certificate validation

  • Improper certificate pinning

What is the impact of Improper Certificate Validation?​

Improper certificate validation can lead to a range of security threats, including:

  • Man-in-the-middle attacks: Attackers can intercept communication between two parties and read or modify the data exchanged between them.
  • Data breaches: Attackers can gain unauthorized access to sensitive information or sensitive systems, leading to data breaches.
  • Malware distribution: Attackers can use fake digital certificates to distribute malicious software or infect systems with malware.

Overall, improper certificate validation can undermine the security of encrypted communication and compromise the confidentiality, integrity, and authenticity of data exchanged over the network.

How to prevent Improper Certificate Validation?​

To prevent improper certificate validation, it is important to follow security best practices, such as:

  • Use trusted certificate authorities: Only trust digital certificates issued by well-known and trusted certificate authorities.
  • Verify certificate chains: Verify that the certificate presented by the remote party is valid and issued by a trusted certificate authority. Verify the entire certificate chain, including intermediate certificates.
  • Check certificate revocation status: Check the revocation status of the certificate presented by the remote party to ensure that it has not been revoked.
  • Use certificate pinning: Implement certificate pinning to ensure that the communication only occurs with the exact certificate or certificate authority specified.
  • Keep software up to date: Keep software and security protocols up to date, as new vulnerabilities and security patches are regularly released.

Overall, proper certificate validation is crucial for maintaining the security of encrypted communication, and following these best practices can help prevent improper certificate validation and mitigate related security risks.

References​

Taxonomies​

Explanation & Prevention​

Training​

Certificate verification disabled (HTTPX)​

Not verifying the SSL/TLS certificate can result in attackers intercepting the connection and having full control of the network traffic.

Rule-specific references:

Option A: Enable Certificate Verification (HTTPX)​

Enable the certificate verification.

  1. Replace verify=False with verify=True
  2. Test it
  3. Ship it 🚢 and relax 🌴

Certificate verification disabled (Requests)​

Not verifying the SSL/TLS certificate can result in attackers intercepting the connection and having full control of the network traffic.

Rule-specific references:

Option A: Enable Certificate Verification (Requests)​

  1. Go through the issues that GuardRails identified in the PR/MR

  2. Replace the following code sample which has verify=False in it:

    import requests
    # this is the vulnerable line
    requests.get('https://www.openstack.org/', verify=False)

    with the following:

    import requests
    # Ensure that you have a valid certificate.
    # get free certificates at https://letsencrypt.org/
    requests.get('https://www.openstack.org/', verify=CONF.ca_file)

  3. Test it

  4. Ship it 🚢 and relax 🌴

Deprecated SSL Socket Wrapper​

The function 'ssl.wrap_socket()' is deprecated since Python 3.7. It creates an insecure SSL socket without server name indication or hostname matching.

Rule-specific references:

Option A: Use SSLContext.wrap_socket()​

Since Python 3.2 and 2.7.9, it is recommended to use the SSLContext.wrap_socket() instead of ssl.wrap_socket().

  1. Look for instances of ssl.wrap_socket()

  2. Replace them with ssl.SSLContext.wrap_socket()

    import ssl

    sock = socket.socket(
        socket.AF_INET,
        socket.SOCK_STREAM | socket.SOCK_NONBLOCK))

    context = ssl.SSLContext(ssl.PROTOCOL_TLSv1_2)
    context.verify_mode = ssl.CERT_REQUIRED
    context.check_hostname = True
    context.load_default_certs()

    s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    ssl_sock = context.wrap_socket(s, server_hostname='www.verisign.com')
    ssl_sock.connect(('www.verisign.com', 443))

  3. Test it

  4. Ship it 🚢 and relax 🌴

Insecure HTTPSConnection version​

Rule-specific references:

Option A: Confirm the use of the secure version for HTTPSConnection​

The HTTPSConnection API has changed often even in minor Python releases. Python versions before 2.7.9 and 3.4.3 don't verify SSL certificates by default.

  1. Go through the issues that GuardRails identified in the PR/MR

  2. Verify that HTTPSConnection is used:

    # Three possible patterns are:
    httplib.HTTPSConnection(...)
    http.client.HTTPSConnection(...)
    six.moves.http_client .HTTPSConnection(...)

  3. Confirm that you are using a Python version greater than 2.7.9 and 3.4.3, otherwise use secure alternatives such as create_default_context()

  4. Test it

  5. Ship it 🚢 and relax 🌴

Host key verification disabled (Paramiko SSH)​

Using AutoAddPolicy and WarningPolicy in set_missing_host_key_policy would allow malicious actors to intercept communication between the SSH client and the SSH server.

Specific References:

Option A: Use RejectPolicy​

Use RejectPolicy instead of AutoAddPolicy and WarningPolicy in set_missing_host_key_policy function.

  1. Locate the vulnerability: set_missing_host_key_policy(paramiko.client.AutoAddPolicy) and/or set_missing_host_key_policy(paramiko.client.WarningPolicy).

    from paramiko import client

    ssh_client = client.SSHClient()
    ssh_client.set_missing_host_key_policy(client.AutoAddPolicy)
    ssh_client.connect(hostname=HOST, port=PORT, username=USER)

  2. Replace paramiko.client.AutoAddPolicy and/or paramiko.client.WarningPolicy with paramiko.client.RejectPolicy

    from paramiko import client

    ssh_client = client.SSHClient()
    ssh_client.set_missing_host_key_policy(client.RejectPolicy)
    ssh_client.connect(hostname=HOST, port=PORT, username=USER)

  3. Test it

  4. 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​

Training​

Plaintext protocols​

Plaintext protocols provide no encryption and protection against MITM attacks.

Option A: Don't use insecure protocols​

  1. Go through the issues that GuardRails identified in the PR/MR
  2. Identify affected lines contain a reference to FTP, or Telnet
  3. Replace them with secure alternatives such as SSH instead of Telnet
  4. Test it
  5. Ship it 🚢 and relax 🌴

Plaintext FTP connection (ftplib)​

The File transfer protocol (FTP) does not provide encryption for its communications.

Rule-specific references:

Option A: Use SSH File Transfer Protocol (SFTP)​

SSH file transfer protocol (SFTP) runs over SSH, providing the confidentiality and authentication that SSH offers.

  1. import the pysftp module
  2. Use pysftp.Connection(host, username, password=password) instead of ftplib.FTP(host, username, password).login()
  3. Refactor the ftplib commands to the according pysftp commands.
  4. Test it
  5. Ship it 🚢 and relax 🌴

Option B: Use of TLS Context​

Use of TLS with FTP provides sufficient confidentiality and authentication.

  1. import the ssl module
  2. Replace instances of ftplib.FTP(host, username, password) with ftplib.FTP_TLS(host, username, password, context=ssl.create_default_context())
  3. Test it
  4. Ship it 🚢 and relax 🌴

Plaintext SNMP connection (pysnmp)​

The Simple Network Management Protocol (SNMP) may send network traffic in plaintext. Using it with noAuthNoPriv and authNoPriv is insecure.

Rule-specific references:

Option A: Encrypt SNMP traffic​

Use SNMP with the right parameters to encrypt the network traffic.

  1. Explicitly set the parameter authKey and privKey of the UsmUserData function

    secure = pysnmp.hlapi.UsmUserData(user, authKey=authKey, privKey=privKey)

  2. Test it

  3. Ship it 🚢 and relax 🌴

Insecure SNMP version (pysnmp)​

SNMP version v1 and v2c community strings are unencrypted and sent in clear text which is insecure for public and internet-facing devices.

Rule-specific references:

Option A: Do not use version v1 and v2c​

Use SNMP v3 instead of v1 and v2c.

  1. Replace CommunityData(...) with UsmUserData(...) with the appropriate parameters.
  2. Test it
  3. Ship it 🚢 and relax 🌴
Last updated on by Stefan Streichsbier