4

I'm working on a presentation to give to high school computer science students where I work at as a volunteer. Part of the presentation is on local and network exploits. I am planning to talk about a story where years ago I was able to get root access by creating a program with an intentional buffer overflow, setting the setuid bit, and running a NOP slide to execute shellcode. When running this program on a modern OS or modern hardware, the exploit no longer works because of the NX bit. (I got this technique from the book "Hacking, the art of exploitation").

I also plan to talk about WannaCry ransomware. Referencing this FireEye link on WannaCry, they talk about that after the malformed packet was sent to SMBv1 on port 445, the software was able to run a NOP slide and then run shellcode.

So my question is, why was the NX bit (either from the OS or the CPU) unable to stop WannaCry from working?

Anders
  • 64,406
  • 24
  • 178
  • 215
Shaun Miller
  • 43
  • 3
  • The comments and answers on this page, and the links they provide, contain some good technical information on why Data Execution Protection (Microsoft's name for its OS tech that implements NX) and ASLR (which essentially makes DEP harder to bypass) didn't prevent the EternalBlue exploit from working on Windows 7: https://security.stackexchange.com/questions/161956/eternalblue-exploit-and-aslr – mostlyinformed Jun 02 '18 at 10:47
  • Note, however, that some security researchers have gotten the EternalBlue exploit to work (without the patch applied, of course) on versions of Windows all the way up through some releases of Windows 10. They have done so by taking advantage of various bypasses to mitigations like DEP and ASLR. Anti-exploitation mitigations like DEP & ASLR sometimes make creating a successful exploit for a vulnerability impossible, but often instead just make it a lot more difficult (ie. requiring much more expertise & effort). Though that effect is still somewhat valuable itself. – mostlyinformed Jun 02 '18 at 11:01

1 Answers1

2

WannaCry first triggered secondary SMB transactions, and then used bugs (uninitialized packet buffers) of srv2.dll to invoke buffer overruns.

NetApi32.dll is capable to bypass NX on some OS versions and service packs (ref, exploit).

peterh
  • 2,938
  • 6
  • 25
  • 31
  • I am not sure if srv2.dll even uses NetApi. This post is a strong guess in its current state. – peterh May 27 '18 at 23:56
  • 2
    Thanks @peterh; I see that the NX bit is not a foolproof way to stop this type of attack. I then asked myself, 'Is there a legitimate need to bypass the NX bit?', and a quick search indicate no such need. I found other sites showing how to bypass the NX bit by using a technique 'return to libc': [link1](https://sploitfun.wordpress.com/2015/05/08/bypassing-nx-bit-using-return-to-libc/), [link2](https://www.intelisecure.com/blog/vulnerability-development-buffer-overflows-how-to-bypass-non-executable-stack-nx/). Looks like then NetApi32.dll(or some other dll) had a bug allowing this exploit. – Shaun Miller May 28 '18 at 00:58
  • @ShaunMiller I think using software bugs to execute an already download file would bypass the NX without any problem. Btw, they've also utilized another bug to disable ASLR (address space layout randomization). Well... Microsoft isn't very strong in developing secure software. – peterh May 28 '18 at 01:03