Advertisement
Guest User

Untitled

a guest
Nov 4th, 2015
982
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 2.13 KB | None | 0 0
  1. method 1 on OS < win 8.1>
  2. retf with 0x33 and address on stack which has next gadgets in 64bit asm.
  3. Then use gadgets to perform ZwProtectVirtualMemory or ZwWriteVirtualMemory by finding them in Import Table of NTDLL. (too much work)
  4. Now the author can do that since he is using CVE-2015-0311 and has vector object to read whole memory.
  5. He finds Flash DLL base from vector object header. then IAT of flash from Base Address.
  6. Then Ntdll.dll address from IAT, then subtracts 0x1e0000 to get ntdll x64.
  7. Then gets EAT of PE32+ and grabs address for ZwProtectVirtualMemory and puts that in ROP chain.
  8. this is how he defeated ROP checks.
  9. Then have a payload which is on 64bit Assembly and retn into that, since EMET has no hooks in WOW64 mode 64bit ntdll copy its all good.
  10. Pitfall -> your product will catch it if you guard the ImportDescriptorTable of flash and probably ntdll base or put HW bp on that
  11. Even before the POC gets the gadgets.
  12. <i dont know why EAF+ is not catching his POC, maybe malfunctioning on WOW64? (i have seen such cases)>
  13.  
  14. method 2 for all OS's, you dont need to do things with flash because you may trigger EAF+.
  15. EMET doesn't hook fs:[0xc0] long mode jump.
  16. construct a ROP chain on flash*.ocx
  17. Put params on stack, find a gadget which gets you fs:[r32], get value of fs:[0xc0] and retn into it. Its still 32bit code and contains a jump to 0033:address. If you jump into that via params of ZwProtectVirtualMemory, you basically bypassed ROP checks, which are the most difficult. When it returns your payload is RWX and you defeated ROP checks, now you can transition into x64 CPU mode.
  18. Its pretty easy to do that from shellcode.
  19. Pitfall -> your method is hardcoded with syscall no in eax. if you can read the syscall no and value of ecx reliable without triggering EAF+, then you can forget hardcoding part.
  20.  
  21. The basic principle is, EMET already has issues with EAF, EAF+ on WOW64. And they dont work properly, thus if you can read whole process memory its pretty much a win. But going this long won't be feasible because even if you only target 64bit systems, its just not good enough to say that your exploit only needs x64 environment. =)
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement