Tests

[tijldeneut]

Hi, I would be glad to verify the CVE-2021-21974.py PoC on multiple ESXi hosts, I have many of them running on VMware Workstation.
These include the actual ESXi builds described in the script, but they do not seem to work (even after running multiple times), maybe something to do with the fact that I use VMware Workstation and not Fusion?

[tijldeneut]

FYI, very nice research and writeup.
Your twitter handle in the header has a small typo ;-)

[straightblast]

Hi, That's odd, because I also tried against VMware Workstation as well, and it seems fine. How is it failing? Was it able to leak the address or its output already looked weird before that? Where is the typo? lol.

…

On Wed, May 26, 2021 at 1:29 AM Tijl Deneut ***@***.***> wrote: Hi, I would be glad to verify the *CVE-2021-21974.py* PoC on multiple ESXi hosts, I have many of them running on VMware Workstation. These include the actual ESXi builds described in the script, but they do not seem to work (even after running multiple times), maybe something to do with the fact that I use VMware Workstation and not Fusion? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGBX6EHDUOKGJSVL7274MMTTPSWPHANCNFSM45ROXMNA> .

[tijldeneut]

Hi,
Yes, it seems some of the SLP commands are failing to get a response, I have a brand new desktop and the first response about 16 bytes of b'x02\x02\x00\x00' data are being received after the output "exploit failed".
I'll try to take a screenshot and tee the output to assist, maybe it's because of an AMD CPU? I'm using Workstation 16.1.1

The typo is in your twitter handle, it says @staight_blast instead of straight_blast (a missing 'r') ;-)

[tijldeneut]

This is running the scripts with some try catches added (because SLP service requests s.send() commands seem to fail after some time):
https://imgur.com/a/hB0WNX5

I've reset the target ESXi between each attempt. I'll try to get an output log file with debug set to True

[straightblast]

Okay, so what I see is that the SLP clients are all called out of order. They're supposed to be called in sequential order. try tweaking the timer variable by increasing its size to see if that will fix the problem

…

On Wed, May 26, 2021 at 10:11 AM Tijl Deneut ***@***.***> wrote: This is running the scripts with some try catches added (because SLP service requests s.send() commands seem to fail after some time): https://imgur.com/a/hB0WNX5 I've reset the target ESXi between each attempt. I'll try to get an output log file with debug set to True — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGBX6EFJARY4BKV6K7LNGH3TPUTU5ANCNFSM45ROXMNA> .

[tijldeneut]

The clients are threaded and seem to be started in the right order, but indeed maybe the proposed 0.3 or 0.4 is too fast.
I've played with the timer (bumping T up to 1), but I'll try to do that some more.

In the mean time I have a nice wireshark log. The first 6 packets are the result of the check_slp script. (https://github.com/HynekPetrak/CVE-2019-5544_CVE-2020-3992/blob/main/check_slp.py)

exploit-esxi-14320388.zip

Edit: added the full command output, it does seem to suggest timing issues. Would it still work without the threading? I don't seem to remember race conditions being an issue in the writeup, so it would take longer, but might work better without it?
alloutput.txt

[straightblast]

So i looked at the output log, while each client appears to be running in sequential order, the responses from each request are out of sync, ex. client 1 should send and recv before client 2 kicks in. The recv are coming back late in your case.

…

On Wed, May 26, 2021 at 11:06 AM Tijl Deneut ***@***.***> wrote: The clients are threaded and seem to be started in the right order, but indeed maybe the proposed 0.3 or 0.4 is to fast. I've played with the timer (bumping T up to 1), but I'll try to do that some more. In the mean time I have a nice wireshark log. The first 6 packets are the result of the check_slp script. ( https://github.com/HynekPetrak/CVE-2019-5544_CVE-2020-3992/blob/main/check_slp.py ) exploit-esxi-14320388.zip <https://github.com/straightblast/My-PoC-Exploits/files/6548768/exploit-esxi-14320388.zip> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGBX6EFWHWVONARPGNWFMDLTPU2CJANCNFSM45ROXMNA> .

[tijldeneut]

Almost there I think, changing T to 2 seconds allows them to run in order and get to the "Exploit Deployed", but it seems to fail on the actual payload (broken pipe). I'm testing the shortest shell in the file (create file in tmp).
newlog.txt

I'll try to tweak timings as a single run of the script takes a couple minutes every time now.

Other considerations:
ESP offset is important per ESXi version, as running it without the '1' fails on ESXi b14320388. I'll try debugging on other hosts once I have a working version.
It is also important to not use a "factory reset" version of ESXi as this actually returns no data leaks on client 26, it must be rebooted several times and preferably have some configuration (user passwords etc ...)

[straightblast]

Thanks for the information, it is good to know the PoC still requires some tweaking before it can be weaponized :)

…

On Thu, May 27, 2021 at 5:33 AM Tijl Deneut ***@***.***> wrote: Almost there I think, changing T to 2 seconds allows them to run in order and get to the "Exploit Deployed", but it seems to fail on the actual payload (broken pipe). I'm testing the shortest shell in the file (create file in tmp). newlog.txt <https://github.com/straightblast/My-PoC-Exploits/files/6553946/newlog.txt> I'll try to tweak timings as a single run of the script takes a couple minutes every time now. Other considerations: ESP offset is important per ESXi version, as running it without the '1' fails on ESXi b14320388. I'll try debugging on other hosts once I have a working version. It is also important to not use a "factory reset" version of ESXi as this actually returns no data leaks on client 26, it must be rebooted several times and preferably have some configuration (user passwords etc ...) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGBX6EFCZ3EOX473LTMQE3LTPY3ZZANCNFSM45ROXMNA> .

[tijldeneut]

Thanks for the information, it is good to know the PoC still requires some tweaking before it can be weaponized :)
…
On Thu, May 27, 2021 at 5:33 AM Tijl Deneut @.***> wrote: Almost there I think, changing T to 2 seconds allows them to run in order and get to the "Exploit Deployed", but it seems to fail on the actual payload (broken pipe). I'm testing the shortest shell in the file (create file in tmp). newlog.txt https://github.com/straightblast/My-PoC-Exploits/files/6553946/newlog.txt I'll try to tweak timings as a single run of the script takes a couple minutes every time now. Other considerations: ESP offset is important per ESXi version, as running it without the '1' fails on ESXi b14320388. I'll try debugging on other hosts once I have a working version. It is also important to not use a "factory reset" version of ESXi as this actually returns no data leaks on client 26, it must be rebooted several times and preferably have some configuration (user passwords etc ...) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGBX6EFCZ3EOX473LTMQE3LTPY3ZZANCNFSM45ROXMNA .

Indeed, I just hope I can figure out the broken pipe's.
Everything else is perfectly doable

[uf4te]

Thanks for the information, it is good to know the PoC still requires some tweaking before it can be weaponized :)
…
On Thu, May 27, 2021 at 5:33 AM Tijl Deneut @.***> wrote: Almost there I think, changing T to 2 seconds allows them to run in order and get to the "Exploit Deployed", but it seems to fail on the actual payload (broken pipe). I'm testing the shortest shell in the file (create file in tmp). newlog.txt https://github.com/straightblast/My-PoC-Exploits/files/6553946/newlog.txt I'll try to tweak timings as a single run of the script takes a couple minutes every time now. Other considerations: ESP offset is important per ESXi version, as running it without the '1' fails on ESXi b14320388. I'll try debugging on other hosts once I have a working version. It is also important to not use a "factory reset" version of ESXi as this actually returns no data leaks on client 26, it must be rebooted several times and preferably have some configuration (user passwords etc ...) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGBX6EFCZ3EOX473LTMQE3LTPY3ZZANCNFSM45ROXMNA .

Indeed, I just hope I can figure out the broken pipe's. Everything else is perfectly doable

Hello, sorry to bother you. I encountered the same problem as you mentioned. When T was adjusted to 2, it showed [*] exploit deployed, but in the last few requests, it would show: BrokenPipeError: [Errno 32] Broken pipe, and the shell command did not seem to be executed successfully. I don't quite understand this. Could you tell me how you deal with this problem?

[uf4te]

I tried adjusting T to 1.5 seconds, and this time it executed successfully without any errors before [*] exploit deployed, including the mentioned BrokenPipeError: [Errno 32] Broken pipe, which seems to be closely related to the value of T. I also tried 0.3, 0.4, 1, 2, etc., but all failed.

[GulperCatfish]

@uf4te I tried setting T to 1.77 and got struct error, while 1.78 got broken pipe error.