Tuesday, April 18, 2017

MS17-010 (SMB RCE) Metasploit Scanner Detection Module

Update April 21, 2017 - There is an active pull request at Metasploit master which adds DoublePulsar infection detection to this module.

During the first Shadow Brokers leak, my colleagues at RiskSense and I reverse engineered and improved the EXTRABACON exploit, which I wrote a feature about for PenTest Magazine. Last Friday, Shadow Brokers leaked FuzzBunch, a Metasploit-like attack framework that hosts a number of Windows exploits not previously seen. Microsoft's official response says these exploits were fixed up in MS17-010, released in mid-March.

Yet again I find myself tangled up in the latest Shadow Brokers leak. I actually wrote a scanner to detect MS17-010 about 2-3 weeks prior to the leak, judging by the date on my initial pull request to Metasploit master. William Vu, of Rapid7 (and whom coincidentally I met in person the day of the leak), added some improvements as well. It was pulled into the master branch on the day of the leak. This module can be used to scan a network range (RHOSTS) and detect if the patch is missing or not.

Module Information Page

Module Source Code

My scanner module connects to the IPC$ tree and attempts a PeekNamedPipe transaction on FID 0. If the status returned is "STATUS_INSUFF_SERVER_RESOURCES", the machine does not have the MS17-010 patch. After the patch, Win10 returns "STATUS_ACCESS_DENIED" and other Windows versions "STATUS_INVALID_HANDLE". In case none of these are detected, the module says it was not able to detect the patch level (I haven't seen this in practice).

IPC$ is the "InterProcess Communication" share, which generally does not require valid SMB credentials in default server configurations. Thus this module can usually be done as an unauthed scan, as it can log on as the user "\" and connect to IPC$.

This is the most important patch for Windows in almost a decade, as it fixes several remote vulnerabilities for which there are now public exploits (EternalBlue, EternalRomance, and EternalSynergy).

These are highly complex exploits, but the FuzzBunch framework essentially makes the process as easy as point and shoot. EternalRomance does a ridiculous amount of "grooming", aka remote heap feng shui. In the case of EternalBlue, it spawns numerous threads and simultaneously exploits SMBv1 and SMBv2, and seems to talk Cairo, an undocumented SMB LanMan alternative (only known because of the NT4 source code leaks). I haven't gotten around to looking at EternalSynergy yet.

I am curious to learn more, but have too many side projects at the moment to spend my full efforts investigating further. And unlike EXTRABACON, I don't see any "obvious" improvements other than I would like to see an open source version.


  1. Hello,
    not clear to me if EternalBlue original exploit works against SMBv1 and SMBv2, is it agnostic actually and the vulnerability is present whatever the SMB version is ?
    Restricting anonymous accesses to IPC shares can also mitigate the trick ?


    1. EternalBlue technically only needs SMB1, but for Windows versions that support SMB2 it uses both SMB1 and SMB2, I am guessing they found out this technique is more reliable. Windows XP version only uses SMB1.

      There are two types of "anonymous" access. One is an "anonymous" login, and another is blank user/password. You'll have to block both. I have no idea what settings are needed.

  2. So disabling administratives shares for Windows clients in a domain might be a workaround. Another way : https://serverfault.com/questions/679148/should-anonymous-access-to-the-ipc-share-be-allowed-on-windows-2008-r2 . Disabling SMBv1 does not resolve the whole pb. Thanks for your help zerosum (btw ref to nine inch nails? ;))

  3. Hi,

    First of all thanks a lot for the great write-up on both eternalblue and doublepulsar. I was wondering if you could share a network trace taken while SMBv1 exploit (eternal blue) is used to better understand the network activity behind and blog it?

    Many thanks,

  4. Hi,

    First of all, Thanks for posting nice content about eternalblue.

    I have some questions about "make_smb_trans_ms17_010", Especially packet.

    1. Why did you set 'ParamCountMax', 'DataCountMax' to '0xffff'?
    Is there some meaning?

    (your code. smb_ms17-010.rb, line is 217, 218)
    pkt['Payload'].v['ParamCountMax'] = 0xffff
    pkt['Payload'].v['DataCountMax'] = 0xffff

    because I saw this contents, I had the question.

    MaxParameterCount (2 bytes): This field SHOULD be set to 0x0006.
    MaxDataCount (2 bytes): This field SHOULD be set to the number of bytes that the client attempts to peek from the named pipe.

    2. Why does smb server reply "STATUS_INSUFF_SERVER_RESOURCES",
    When send 'PeekNamedPipe' with fid 0.

    Is the vulnerability related with "PeeknamedPipe" subcommand?

    I have tried finding reason. but It's not easy..
    I couldn't find "PeekNamedPipe" in eternalblue exploit code.

    How can you know this way checking by "PeekNamedPipe" with FID 0?
    Why is It related with vulnerability?

    Please help me...

    you know, My English skill is crap..
    So, you can feel I'm rude. but I don't want that.
    Please know about it :)

    1. 1. In this case the MaxParameterCount and MaxDataCount are not really important, but do need to be something other than 0. So I just set all the bits.

      2. Basically the simplest way to explain it is they added some new "auth" checks before the PeekNamedPipe function ever gets called at all. There's a few other code paths that could be used, but that one does the trick.

    2. Thanks for replying :)

      Oh! so they return "STATUS_ACCESS_DENIED"?

      hmmm.. Do you know what is "FID 0"?

      Is "FID 0" just invalid FID?
      Or Is it some special Fid? like always used/reserved by smb server.

      I thought that, "Fid 0" is always used by smb server(or something). It has very very big size. So If I request "peeknamedpipe" with fid 0, smb server return "STATUS_INSUFF_SERVER_RESOURCES".

      Please advise.