R7-2019-39 | CVE-2019-5648: LDAP Credential Exposure in Barracuda Load Balancer ADC (FIXED)

This post describes CVE-2019-5648, a vulnerability in the Barracuda Load Balancer ADC. A malicious actor who gains authenticated, administrative access to a Barracuda Load Balancer ADC can edit the LDAP service configuration of the balancer and change the LDAP server to an attacker-controlled system, without having to re-enter LDAP credentials. These steps can be used by any authenticated administrative user to expose LDAP credentials configured in the LDAP connector over the network to the themselves.

CVE-2019-5648 is categorized as CWE-522 (Insufficiently Protected Credentials), and has a base CVSSv3 score of 8.7 (High).

Patches for CVE-2019-5648 have been distributed as security updates through the Barracuda patch management system. No user action is required unless security updates have been intentionally disabled. The patches will also be included in firmware version 6.5, which is scheduled for release in April 2020. As a general practice, users should periodically visit the Advanced -> Firmware Update page to ensure that the most recent firmware is installed.

Barracuda Load Balancer product description

The Barracuda Load Balancer ADC (hardware model 440Vx) is a high-performance load balancer intended to optimize and accelerate application delivery, as well as provide DLP and other security mechanisms. It can be deployed on-premises or in AWS, and is commonly used to build out scalable application infrastructure by a variety of organizations. More information about the device is available on Barracuda’s website.

Vulnerability disclosure credit

This issue was discovered by Steve Campbell (@lpha3ch0). It is being disclosed in accordance with Rapid7’s vulnerability disclosure policy.

Exploiting the Barracuda Load Balancer vulnerability

The default admin credentials for Barracuda Load Balancer ADC devices are user ‘admin’ and password ‘admin’. If these are not changed during deployment, an attacker with network access to the device can easily log in to the device admin console. From there, they can edit the LDAP connector configuration (Advanced -> Admin Access Control -> External Authentication Services -> Edit), change the IP address to an attacker-controlled system, turn off encryption, and log out of the admin console.

Next the attacker can start netcat listening on port 389/TCP on a system they control using the IP address configured in the LDAP connector above. At this point, when any credentials are entered into the Barracuda login form (valid or not), the load balancer will send the plaintext username and password for the account configured in the LDAP connector to the attacker’s system. This is shown in the figure below:

Impact of CVE-2019-5648

This vulnerability allows an attacker with network and administrative access to the load balancer to gather unencrypted valid LDAP credentials, which they can leverage in further attacks. The risk for further attack is much higher if the LDAP connector is configured to connect with an Active Directory Domain Controller, as this could result in the attacker gaining access to the Active Directory Domain Controller using valid credentials captured from network traffic. Note that there is no technical requirement for connecting via a highly privileged LDAP account, and administrators should avoid this if at all possible to decrease their exposure.

Firmware v6.2.0.006 (2017/11) was used in testing for this disclosure. Barracuda states that firmware versions prior to 6.5 were affected by CVE-2019-5648. Note that per Barracuda Networks Sunset Policy, the version this issue was discovered in is no longer supported for security patches.

Vendor Statement

Barracuda Networks appreciates the efforts, collaboration and support of the security research community. Individual researchers wishing to report findings related to Barracuda physical or virtual appliances can submit them through our bounty program at Bugcrowd. Institutional researchers can reach the Barracuda security team directly at [email protected]. We would like to express our appreciation for the professionalism of the Rapid7 team’s disclosure process.

Remediation

Administrators should ensure that their Barracuda Load Balancer ADC is on either a 6.3.x or 6.4.x version so that the patch can be applied through Barracuda’s automated security patching system. Ensure that you have not intentionally disabled the security update system (see Advanced -> Energize Updates -> Security Definitions). No other user action is required to remediate this issue. Please note that due to a known UI bug, the Latest and Current Installed Version fields may not reflect the actual state of patching of your device.

Additionally, since this vulnerability requires an authenticated admin user session to exploit, users should keep in mind that general security best practices recommend that (1) administrators ensure the administrative passwords for their Barracuda Load Balancer ADC devices are changed from the shipped defaults to a random secure value, and that (2) administrators consider configuring their Barracuda Load Balancer ADC devices with an LDAP account having the minimal needed permissions. More information on these configurations can be found in ​Barracuda’s documentation​.

Finally, administrators should update their Barracuda Load Balancer ADC devices to the latest firmware versions as they become available. Version 6.5 will ship with the patch for CVE-2019-5648.

Vulnerability Disclosure Timeline

• August 2019: Issue discovered by Rapid7
• Wednesday, Sept. 11, 2019: Initial disclosure to Barracuda
• Wednesday, Sept. 11, 2019: Initial response from Barracuda; assigned internal ID BNSEC-8552
• Tuesday, Oct. 8, 2019: Barracuda acknowledged vulnerability, remediation underway
• Wednesday, Oct. 23, 2019: Disclosed to CERT/CC; assigned internal ID VU#122091
• Wednesday, March 4, 2019: Patch released by Barracuda
• Thursday, March 5, 2020: Public disclosure via publication of this blog post

Update (Mar 5, 2020): The first version of this post mentioned that the device under test ships with a default administrator password. While this was true as of the 6.2.x versions of the firmware, this has not been true since at the 6.4.x release.