Open farhan1211 opened 4 months ago
C:\Users\scorpidius\CVE-2023-24871\lpe\exploit\x64\Debug>bthlpe_master.exe [ - Step 1 - ] [] Checking if Bluetooth radio exists. [+] Success. [] Granting app packages access to the payload dll. [+] Success. [] Granting everyone access to the JuicyPotato executable. [+] Success. [] Finding a reference string to harness in the external module. [+] Success. [] Finding a chained pointer to a 8-bit 1 in the external module. [+] Success. [] Deploying the harness DLL. [+] Success. [] Writing Juicy Potato command line into harness. [+] Success. [] Injecting payload DLL into StartMenuExperienceHost.exe. [+] Success. [*] Verifying that the payload DLL is injected. [+] Success.
[ - Step 2 - ] [+] Crashing bthserv to reset heap layout. [] Triggering payload (size = 514) through target process. [+] Success. [] Waiting for payload DLL. [+] Success. [+] Waiting 3000ms. [+] Success. [] Triggering RCE with spraying. [] Attempt 1 [] Spraying StateMachineEngine objects. [] Deploying RCE payload to bthserv [] Triggering payload (size = 619) through target process. [+] Success. [] Waiting for payload DLL. [+] Success. [] Triggering sprayed objects. [+] Success. [] Waiting for harness to load. [-] Harness loading failed. [] Attempt 2 [] Spraying StateMachineEngine objects. [] Deploying RCE payload to bthserv [] Triggering payload (size = 619) through target process. [+] Success. [] Waiting for payload DLL. [+] Success. [] Triggering sprayed objects. [+] Success. [] Waiting for harness to load. [-] Harness loading failed. [] Attempt 3 I am using is windows 21h2 (os build 19044.1288)
I would recommend checking if the service (bthserv) is crashing during those attempts to trigger the exploit, to do that you can attach any debugger to the process and see if an exception pops up.
k_RetryCount
or tinker with k_InitialSprayCount
, k_PostSprayCount
or k_FreeCount
because the spraying may not be working as intended. another possibility is that one of the objects we're using in the exploit has a different memory layout on older builds like that one. in this case, you'll need to figure out what's different and change the code to overwrite the proper things yourself. you could also try with a newer build (end of 2022 for example)Windows.Internal.Bluetooth.dll!BthLELib_ADValidateEx
and see if it's being triggered. if it's being triggered and the crash is not happening, then the vulnerability is most likely patched (you could run the poc from this repo to verify/confirm). if it's not being triggered at all, then you may need to debug why.can you provide me with the iso file that you used to recreate this exploit, it would be really helpful.
I just grabbed this iso (19044.1288) and the exploit worked from the first attempt. Are you on 32-bit or 64-bit? I don't see any reason why it wouldn't work for you but it does for me. I used Hyper-V to test, clean installation and I didn't change anything.
I am on 64-bit machine
I have tried with the iso file that you have provided me with, but it is still not working. Have made any changes in the code before committing it?
I cloned the repo, compiled Release 64-bit target and tested against the 64-bit version of the build. Works as expected, though you have to turn off Windows Defender as it will quarantine the modules. Check your protection history as it's quite possible that defender is blocking the exploit.
sup, guys. i also had the problem with loading harness and exploit working on VMWare VM, but it worked on first try, when i used a physical machine.
https://drive.google.com/file/d/10x33uhRShbRJHa3SW29WvUrH-yw-VUmX/view?usp=drive_link
I have provided you with the video of my failed exploit. If you can figure out, where am I going wrong, then please let me know.
you're not doing anything wrong. there seems to be a problem with how the bthserv service restarts when ran inside of a vmware VM. If I had to guess, it has something to do with their virtual bluetooth driver. since the exploit first crashes the service in hopes of restarting it, and the service is not successfully restarted, the exploit attempt doesn't end up working.
I managed to (kinda) solve it by manually restarting bthserv from task manager and running the exploit afterwards, but in most cases even this results in the service being stuck forever (or for a long period of time). One other thing I did was connect a bluetooth dongle and redirect it into the VM instead of using the default controller that comes with the laptop. Maybe that helped it work too, but I'm not sure.
I'm not too keen on investigating what exactly is happening, but you could always try the exploit in a Hyper-V VM (although you'll need a third party program to redirect your USB/bluetooth controller) or on a physical machine (which is unfortunate).
So, you used Hyper-V to recreate the exploit?
yes, but there's no native support for bluetooth/usb redirection so I had to use a third-party program, such as USB redirector. It's shareware but there's a free 15-day trial so you should be able to test it out if you want to use Hyper-V. there's a chance that other usb/bluetooth sharing solutions work too, but I didn't try.
is it necessary to use a Bluetooth dongle for the exploit or the machine Bluetooth also could just work fine?
Nevermind, it worked finally🥳🥳🥳. Thank you for helping me out.
can you paste the output of the program? which version of windows are you running?