16

I've casually googled for explanations on how exactly the EternalBlue exploit works but, I suppose given the media storm about WannaCry, I've only been able to find resources that at best say it's an SMB exploit. I get that there was a bug in Microsoft's implementation of the SMB protocol, but what I'd like to know is exactly what kind of payload had to be crafted in order to exploit Microsoft's security flaw, and what did Microsoft do wrong that left Windows vulnerable to such an attack? Even a (reputable) link to some source code would be more than I've been able to find thus far.

wdmssk
  • 31
  • 1
  • 4
butallmj
  • 281
  • 1
  • 2
  • 5
  • 2
    https://www.endgame.com/blog/wcrywanacry-ransomware-technical-analysis and https://github.com/RiskSense-Ops/MS17-010/blob/master/exploits/eternalblue/ms17_010_eternalblue.rb – julian May 16 '17 at 20:52
  • This is handcraft exploit for Windows 7/Windows 2008 which also has the in-depth explanation how its work. https://gist.github.com/worawit/bd04bad3cd231474763b873df081c09a – Pandora May 24 '17 at 07:48
  • https://security.stackexchange.com/questions/155769/find-smbv1-status-with-nmap/158896#158896 – SDsolar May 27 '17 at 16:55

1 Answers1

16

There's an exploit for EternalBlue in Metasploit explained here:

There is a buffer overflow memmove operation in Srv!SrvOs2FeaToNt. The size is calculated in Srv!SrvOs2FeaListSizeToNt, with mathematical error where a DWORD is subtracted into a WORD. The kernel pool is groomed so that overflow is well laid-out to overwrite an SMBv1 buffer. Actual RIP hijack is later completed in srvnet!SrvNetWskReceiveComplete.

I'm not an expert and don't understand ruby too well, but from what I understand DWORD is twice as long as WORD, which would let you write to memory by sending a large buffer. The kernel memory is organized (groomed) while the data is being written, so that the payload being transmitted makes sense once the RIP pointer is hijacked and pointed to the overwritten memory, which will then be read and executed.

You can see the source code here.

As far as what was done wrong, there should have been a subtraction from DWORD to DWORD or from WORD to WORD. Having the difference in sizes is what allowed memory to be overwritten.

EDIT: Checkpoint did an amazing write-up explaining all 3 bugs related to this exploit, what I understood from the ruby code I read is only bug 1/3 (bug A in Checkpoint's write-up), if you want to go a lot deeper, check it out.

Daniel V
  • 443
  • 3
  • 12
  • BYTE (8), WORD (16), DWORD (32), QWORD (64), XMMWORD (128), YMMWORD (256), ZMMWORD (512)... These are all just ways to refer to the size of the data in a register. – forest Mar 28 '18 at 02:26