Perl 5 MySQL Interface Vulnerability

Perl 5 database interface for MySQL package (DBD::mysql) has received an important patch to address a vulnerability found in the encryption configuration.

Threat ID:: CC-1522
Category:: Spyware, Exploit
Threat Severity:: Medium
Threat Vector:
Published:: 13 July 2017 12:00 AM

Report a cyber attack: call 0300 303 5222 or email [email protected]

This content has been archived

This article no longer conforms to NHS Digital's standards for cyber alerts, and may contain outdated or inaccurate information. Use of this information contained in this page is at your own risk

Summary

Perl 5 database interface for MySQL package (DBD::mysql) has received an important patch to address a vulnerability found in the encryption configuration.

Threat details

DBD::mysql allows an application written in the Perl programming language to easily integrate with a MySQL database.

The flaw is found within the encryption configuration. Secure Socket Layer (SSL) was expected to be enforced for connections to the database, however, SSL was found to be optional and therefore connection to the database could be completed without encryption in place. The unencrypted connection leaves the data vulnerable to a Man in the Middle (MitM) attack.

BACKRONYM and Riddle are two previously discovered vulnerabilities mentioned which could be used in this instance.

BACKRONYM: A MitM attacker intercepts the connection and downgrades the data into clear text. The data can be either collected or edited.

Riddle: A MitM attacker intercepts the login credentials of a user connecting to the server in clear text. The attacker would then be able to log in to the server with the same privileges as that user.

This threat can be easily mitigated due to the availability of patches, and also by using the principle of least privilege and ensuring data is regularly backed-up.

Remediation steps

Type	Step
	Ensure packages have been updated on all affected devices Ensure MySQL user only have to databases required for the role intended and create additional users for different projects to mitigate the impact a leak could have. Ensure data is security backup up to ensure a destructive breach can be recovered from and all sensitive information is securely encrypted to ensure a data leak’s impact is mitigated. Consider upgrading SNMP to version 3 where possible. Ensure devices are using the latest version of SNMP (UDP port 161), SNMPv3, where possible. If SNMPv1, v2 or v2c must be used, ensure they are not publicly reachable. Segregate SNMP traffic using a separate management network, with data transferred independently of other traffic. If SNMP traffic must be transmitted alongside standard network traffic it should be encrypted. Where possible, dedicated management ports should be used. Ensure network community strings are not left with default settings. When configuring community strings implement strong password policies and ensure the strings are not public. SNMPv3 provides authentication and encryption capabilities through the authPrivUser-based Security Model (US) specification. Ensure that this is implemented on SNMP enabled devices. If devices are unable to support authPriv, the alternative authNoPriv specification can be used to provide some level of improved security. Implement extended access control lists (ACL) to prevent unauthorised devices or accounts from accessing SNMP enabled devices. Access to devices with higher SNMP permissions should be strictly controlled.

Type

Step

Ensure packages have been updated on all affected devices
Ensure MySQL user only have to databases required for the role intended and create additional users for different projects to mitigate the impact a leak could have.
Ensure data is security backup up to ensure a destructive breach can be recovered from and all sensitive information is securely encrypted to ensure a data leak’s impact is mitigated.
Consider upgrading SNMP to version 3 where possible.
Ensure devices are using the latest version of SNMP (UDP port 161), SNMPv3, where possible. If SNMPv1, v2 or v2c must be used, ensure they are not publicly reachable.
Segregate SNMP traffic using a separate management network, with data transferred independently of other traffic. If SNMP traffic must be transmitted alongside standard network traffic it should be encrypted. Where possible, dedicated management ports should be used.
Ensure network community strings are not left with default settings. When configuring community strings implement strong password policies and ensure the strings are not public.
SNMPv3 provides authentication and encryption capabilities through the authPrivUser-based Security Model (US) specification. Ensure that this is implemented on SNMP enabled devices. If devices are unable to support authPriv, the alternative authNoPriv specification can be used to provide some level of improved security.
Implement extended access control lists (ACL) to prevent unauthorised devices or accounts from accessing SNMP enabled devices. Access to devices with higher SNMP permissions should be strictly controlled.

Last edited: 17 February 2020 11:37 am