Tag Archives: SMB

Badlock: What You Need to Know

Yesterday as scheduled the Samba project and Microsoft made available their security updates to resolve the issue that was previously announced and named “Badlock.”

Why Should These Issues Be Considered Important?
While this issue is important (it affects a lot of Windows version from Server 2008/Vista up to and including Windows Server 2016/Windows 10), it’s severity was exaggerated in it’s announcement last month. Microsoft have assigned it an important severity rather than critical. They have done so since it is an elevation of privilege (EoP) (defined) issue that would allow an attacker to increase their privileges (which would allow them to cause even more harm) once they have already exploited another vulnerability to become present on your device in the first instance.

This vulnerability could allow an attacker to listen/analyse the traffic on your network; this technique is known as a man-in-the-middle-attack (MITM, defined). If your login credentials happened to be within the traffic the attacker gathers and analyzes there is a possibility they could obtain the unencrypted username and password used to access your device/account upon that device (even though your sensitive information is encrypted). Further discussion of this issue is available here.

How Can I Protect Myself from These Issues?
Updates from the Samba project and Microsoft are available to resolve this security issue. Please download and install them as soon as possible if you are affected by this issue.

Update: 13th April 2016:
Further information and advice for mitigating the Badlock issue is provided by US CERT in this vulnerability note. The Samba project also discusses its updated software releases in this release news post.

While there are no known issues with these updates at this time, as always I would recommend backing up the data on any device for which you are installing updates in order to prevent data loss in the rare event that any update causes unexpected issues.

Thank you.

Pre-Announcement of Samba (SMB/CIFS) Security Update

Update: 13th April 2016:

Further details as well as updates to resolve the Badlock issue are discussed in a more recent blog post.

Thank you.

Original Post:
Earlier this week an announcement was made by SerNet (a Samba consulting company who set up the Badlock website) that a critical security update would be made available on the 12th of April to address a vulnerability in the SMB/CIFs protocol (defined below) that is the basis of the open source Samba project. The 12th of April is the well-known second Tuesday of the month known as Update Tuesday (or Patch Tuesday) when Adobe, Microsoft and others commonly make available security updates on a scheduled basis.

Some advice that you can follow to better prepare for this update being made available is described in this SANS blog post as well as this very informative and practical InfoWorld article. Further background on this announcement can be found here.

I will publish another blog post on or very soon after the 12th of April to provide the appropriate information for you to address this vulnerability in a timely manner.

Thank you.

What is the SMB/CIFS protocol?
The Server Message Block (SMB) protocol is also referred to as the Common Internet File System (CIFS) is an application layer (layer 7 of the OSI model) protocol that allows the sharing of printers but mainly provides file access/transfer in a Microsoft network using mapped network drives. Further features of SMB/CIFS are detailed in this Sophos blog post.

Samba is an open source (the source code (human readable code) is free to view and edit by the wider IT community) application that provides the above mentioned network services across Linux/Unix and Microsoft servers/clients.

Redirect to SMB Flaw

Last week a new means of exploiting a previously unpatched flaw was discovered in the Microsoft SMB (Server Message Protocol). At the time of the announcement of this flaw and at the time of writing, no security advisory from Microsoft has been published.

If an attacker can intercept communications between a client and a legitimate server (i.e. a man in the middle (MITM) attack); the attacker can send the client a specifically crafted URL beginning with file:// The client system can then be re-directed (using HTTP redirect) to provide the clients authentication credentials to a malicious SMB server. These credentials could then be cracked using a brute force password attack (since the passwords are hashed and salted) in order to obtain credentials for the genuine server.

Recommended mitigations for this attack are to block outbound TCP ports 139 and 445 (used for SMB connections) from the outbound firewall on your network. This will allow SMB traffic within your network to work as normal will blocking attempts to perform redirects to external SMB servers. You can also block these ports on any of the host devices (endpoints) within your network. The most effective means of blocking these ports using the Windows Firewall and Group Policy are referenced (page 14) in the following white paper (created by Cylance, the organisation which discovered this new exploit). Further mitigations are detailed in the above mentioned white paper and at the following pages:

SPEAR – Redirect to SMB

US CERT Vulnerability Note VU#672268

Since SMB uses TCP ports 139 and 445 you can use these ports to locate any suspicious traffic on your network using Wireshark. For any host device (e.g. server, laptop etc.) that you wish to monitor, try to capture traffic using Wireshark as close as possible to the host device of interest or install Wireshark on the host device (if possible/permitted). You could also use a simple packet capturing tool such as tcpdump installed on the host device of interest.

In order capture traffic as close as possible to the host device you could capture traffic at a network switch closest to the host of interest. This can be done by installing a Test Access Port (TAP) in between the switch and the host or connecting directly to the switch if that switch supports port spanning. Using a TAP is preferable since link-layer traffic will also be included in the capture.

Once you have captured traffic you can check for suspicious traffic using one or all of the following display filters:

Where ip address below is any host that you wish to check if an attempt to access that host using the SMB protocol has taken place. The ip.dst declaration means that traffic is coming from a host on your network to another host device on your network and is attempting to communicate with that host. Replace (ip address) with the IP address (without the parenthesis/brackets) you wish to monitor:

ip.dst==(ip address) && tcp.srcport==139
ip.dst==(ip address) && tcp.srcport==445

An example of the result from one of the above filters is shown in the screenshot below:



You can also use the Statistics->Conversations window to narrow down traffic coming from another host to a host device of interest using the TCP tab, selecting a port column that contains Microsoft-DS traffic and choosing Apply as Filter->Selected A <- Any (as shown in the screenshot below):


While the above TCP ports should not normally be exposed from inbound traffic, it is also good practice to ensure that these ports are not accessible from outside your network. A simple test for this is to visit the ShieldsUP website from a device that you wish to test. From the tabs at the top of the page choose, Services -> ShieldsUP. Read the short terms and conditions page, if you agree to it, click Proceed. Within the white text box located on the page, enter

139, 445

I.e. 139 and 445 separated with a comma. Press the Enter key (Carriage return) on your keyboard. The ShieldsUP service will then test the above ports for exposure. If all goes well, you should see a page similar to that pictured below:

Copyright (c) 2014 Gibson Research Corporation. SpinRite, ShieldsUP,
NanoProbe, and any other indicated trademarks are registered trademarks of Gibson Research Corporation, Laguna Hills, CA, USA.

If these ports are found to be open, please use a firewall; either a network firewall or a firewall installed on the host device to block these ports from inbound connections/traffic.

At this time it is unclear if this flaw will be patched. Since it also effects software from AVG, Adobe, Apple, Box, Symantec and many others, it is likely it will be resolved in the near future. Until that time the above mentioned mitigations will protect you from this flaw.

Thank you.