Daily Archives: April 22, 2015

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.