Add module for CVE-2013-5065 #2755
Conversation
| [ 'URL', 'http://technet.microsoft.com/en-us/security/advisory/2914486'], | ||
| [ 'URL', 'https://github.com/ShahinRamezany/Codes/blob/master/CVE-2013-5065/CVE-2013-5065.cpp' ], | ||
| [ 'URL', 'http://www.secniu.com/blog/?p=53' ], | ||
| [ 'URL', 'http://www.fireeye.com/blog/technical/cyber-exploits/2013/11/ms-windows-local-privilege-escalation-zero-day-in-the-wild.html' ] |
There was a problem hiding this comment.
There was a problem hiding this comment.
agree, interesting one to add to the list, ok, let me make a commit :)
|
I don't have a Win2k3 SP2 box (yet), but WinXP SP3 looks good for me: |
|
I know this isn't supported on Windows XP SP2, but I thought I'd run the Am I right in thinking that we shouldn't see a failure like this with a call stack, but instead a message saying the system isn't vulnerable? |
|
|
||
| handle = open_device("\\\\.\\NDProxy") | ||
| if handle.nil? | ||
| fail_with(Failure::NoTarget, "\\\\.\\NDProxy device not found") |
There was a problem hiding this comment.
To avoid the callstack dump, would it be better to just return Exploit::CheckCode::Safe ?
There was a problem hiding this comment.
Isn't there a CheckCode::NoTarget or something for unsupported OSs etc?
There was a problem hiding this comment.
Agree my fault, for fail_with inside check, copy and paste side effects :\
|
I enabled the "Routing and Remote Access" service on my Windows XP SP2 machine, and the Maybe we should filter out SP2? Quick check of Win7: Looks good. Just FYI, yo! |
|
Honestly, didn't check XP SP2, but having into account the BSOD, looks like still it's using the use input data to access memory without bound checkings, and maybe still doing a dangerous call... maybe this time isn't just a 0x38 :) I can return a Detected CheckCode in case of XP < SP3. Will fix tomorrow morning :) thans @OJ for testing! |
|
|
||
| p = payload.encoded | ||
| print_status("Injecting #{p.length.to_s} bytes to memory and executing it...") | ||
| if execute_shellcode(p) |
There was a problem hiding this comment.
Isn't this just executing the shellcode in the current process? Which seems a bit pointless if we have already elevated the current process?
Ideally it should: start a new process, elevate that process and execute shellcode - leaving the current process intact.
Or if we cant do that: elevate current process but execute new shellcode in a new process?
Or: just elevate the current process but dont bother executing shellcode (although this breaks away from the Metasploit 'exploit' definition it is like getsystem).
|
@OJ and @Meatballs1 , ok, I'm going to use this solution: The original exploit purpose was get SYSTEM on XP systems after an Adobe sandboxed renderer exploitation, according to "http://blog.spiderlabs.com/2013/12/the-kernel-is-calling-a-zeroday-pointer-cve-2013-5065-ring-ring.html": So to avoid Adobe Reader sandbox from stop the exploitation, I'm going to elevate the current process, and execute the payload in new one :) Hope this approach makes all comfortable :) work in progress... |
|
@jvazquez-r7 if you call execute_shellcode and specify a PID argument it will cause the meterpreter session to crash when CreateThread is called. I've opened a PR #2750 to fix the issue but you will run into it if you change this exploit to inject into another process using execute_shellcode. Hope this heads up saves you debugging time. |
|
@zeroSteiner thanks, let me fix it on this pull request, by favoring the usage of Rex::Post::Meterpreter::Extensions::Stdapi::Sys::Thread over railgun :) (code stolen from old @Meatballs1's code indeed). If there is any reason to favor Railgun let me know, please, and I can revert :) |
|
Suits me :) |
|
I hit the following error when I use the run command from the meterpreter prompt. Something is broken: |
|
However, if I run it from the msf prompt, it works fine: |
|
mmmm lemme dig a little into the run_simple, I hope it isn't related to the module but lemme repro!!! |
|
It doesn't look like it's from your module, but something is broken indeed: |
|
@wchen-r7 ooom absolutely, looks like cmd_run is trying to run run_simple on the module: but only Post and Auxiliary define run_simple, while Local Exploits come from Exploit... so I guess local exploits can't be run through the run meterpreter command. I wasn't aware. Not sure if @jlee-r7 / others were aware of the thing. If there is something I should do in this pull request, feedback is super welcome! |
|
Also if you would like me to fill a bug or something else, please, let me know! nice catch! |
|
Yeah, looks like something we overlooked with the "run" command. So that means the run command won't work against all local exploits, either. Definitely a missing feature, but not caused by the module, so I'll go ahead and push this in. Thanks. |
|
Ticket for the above issue: |
|
coolio, thanks! Now time for me to handle #2758 ! |
Tested on Windows XP SP3 and Windows 2003 SP2 successfully.
Verification
DEMO