Many customers utilize the SMB (Server Message Block) protocol in their production environments. SMB has become a reliable file and print sharing resource protocol for RHEL deployments in many infrastructures through the Samba project, allowing greater usage of shared and cross platform resources. There is a new man-in-the-middle vulnerability, named “badlock,” that targets any implementation of Microsoft’s Local Security Authentication and Security Account Manager remote protocols.
This specific vulnerability targets SMB client-server communication while the server is acting as a domain controller. Most commonly, a domain controller will be implemented by Microsoft Active Directory. Enterprises may also implement a domain controller via Samba services, distributed and supported within Red Hat Enterprise Linux or Red Hat Storage products, or through other SMB-compliant implementations.
Identifying risk in your infrastructure
Generally you start off any response plan by identifying affected systems in your infrastructure. In the case of badlock this would be any system running as a domain controller or connected to a vulnerable shared resource via the SMB protocol, which are implemented via the samba packages in RHEL.
First you want to remediate any domain controllers in your environment. If an attacker is able to compromise this infrastructure, they will have the credentials to access any client to that domain controller. You should immediately focus on upgrading these servers, or if necessary, disabling the service until you have time to patch. The next priority would be any servers with samba configured as a file or print server as they store credentials as well. Lastly, any samba clients should be patched to complete your remediation against these attacks. Insights will make this easier by identifying any samba servers and any samba clients in your environment.
Other related vulnerabilities, rated from Moderate to Critical and described in the Red Hat Customer Portal Vulnerability Response are also fixed with these patches.
Getting started with Red Hat Insights monitoring
We built the Insights service to provide proactive response to new and upcoming threats to your infrastructure. Your active Red Hat subscription comes with ten entitlements to the Red Hat Insights service for free so you can begin monitoring and diagnosing your infrastructure right now. Visit the Getting Started Guide at https://access.redhat.com/insights/getting-started to begin evaluating the Insights service for RHEL 6 and RHEL 7 through Red Hat Satellite, CloudForms, or direct via the Customer Portal. To monitor a larger infrastructure please contact your account team for a larger scale evaluation entitlement.
Executing your response plan with systems management tools
As we’ve written about previously on the Insights blog, you have multiple options to tackle the response plan.
If you are a Satellite customer, make sure you sync your Satellite server to get the latest packages. Once you have the latest packages, your new deployments out of the Red Hat standard channels will have the fix; for any deployments out of custom channels, make sure to copy the updated package over to those channels. For existing systems, you need to deploy the package everywhere and restart each server or at least those network services which are vulnerable.
Ansible / Ansible Tower
The Ansible posting about this vulnerability as well as generated playbooks for use is here.
If you are a CloudForms customer your appliances can audit your environments and validate that the patches have been applied. Similar to the Insights service, CloudForms can provide a policy based compliance check which can be used to verify software and configuration of servers and validate security requirements. First update your appliance to the latest version by logging into the appliance as the root user and running # yum update or following the steps in the CloudForms documentation.
Please see the CloudForms blog for detailed information on how to determine vulnerability with CloudForms.
You can also use Red Hat Access Labs to test your systems vulnerability for the badlock attack.
-For up to date information from Red Hat on the badlock vulnerability please visit: https://access.redhat.com/security/vulnerabilities/badlock
-The badlock vulnerability was first reported via http://badlock.org/
-Microsoft’s information regarding their Windows security subsystem