We are happy to announce that Vesta is back under active development as of 25 February 2024. We are working on v1 candidate and expect to engage more with the community over the coming months. We are committed to open source, and we encourage contributors to help us build the future of Vesta.
Got 10 VestaCP servers exploited
Re: Got 10 VestaCP servers exploited
I think that we can throw away theory that Vesta repo is compromised.
This is why:
I know MANY datacenters (one of them hosts 30% of all dedicated servers in a world) where NONE of Vesta servers got hacked.
Also, ZERO servers that are physically located in my country got hacked.
Bad guy simply scanned only IP rangs that is known to him - which mean that we didn't have malware bot that is already installed on our servers - because that bot will probably try to connect to hacker - and all servers in all IP rangs will be affected in that case.
He probably found a way to inject malicious code through /api/ and that's it.
This is why:
I know MANY datacenters (one of them hosts 30% of all dedicated servers in a world) where NONE of Vesta servers got hacked.
Also, ZERO servers that are physically located in my country got hacked.
Bad guy simply scanned only IP rangs that is known to him - which mean that we didn't have malware bot that is already installed on our servers - because that bot will probably try to connect to hacker - and all servers in all IP rangs will be affected in that case.
He probably found a way to inject malicious code through /api/ and that's it.
Re: Got 10 VestaCP servers exploited
while this is all reasonable, still as long as no one is able to replicate the attack and tell about every single vector involved, that's sadly just another guess and no satisfiying assurance for future security.dpeca wrote: ↑Thu Apr 12, 2018 9:48 amI think that we can throw away theory that Vesta repo is compromised.
This is why:
I know MANY datacenters (one of them hosts 30% of all dedicated servers in a world) where NONE of Vesta servers got hacked.
Also, ZERO servers that are physically located in my country got hacked.
Bad guy simply scanned only IP rangs that is known to him - which mean that we didn't have malware bot that is already installed on our servers - because that bot will probably try to connect to hacker - and all servers in all IP rangs will be affected in that case.
He probably found a way to inject malicious code through /api/ and that's it.
Re: Got 10 VestaCP servers exploited
but then there is still the question HOW could it deal with the api, when the firewall blocks access to it.dpeca wrote: ↑Thu Apr 12, 2018 9:48 amI think that we can throw away theory that Vesta repo is compromised.
This is why:
I know MANY datacenters (one of them hosts 30% of all dedicated servers in a world) where NONE of Vesta servers got hacked.
Also, ZERO servers that are physically located in my country got hacked.
Bad guy simply scanned only IP rangs that is known to him - which mean that we didn't have malware bot that is already installed on our servers - because that bot will probably try to connect to hacker - and all servers in all IP rangs will be affected in that case.
He probably found a way to inject malicious code through /api/ and that's it.
im not the only one who got hacked with closed ports.
i guess it has something todo with modules like roundcube, if its not the rep.
thats the only things thats left over which makes sense for all configurations that got infected.
it has to be a similarity across everyone...
Re: Got 10 VestaCP servers exploited
Maybe, through /api/, he just ''altered'' roundcube PHP file, because roundcube is on known path (/usr/share/roundcube/)
Then he gets in via roundcube PHP file.
And if you didn't in php.ini disabled PHP functions like exec() and shell()... that way he has all permissions to run anything under ''admin'' privileges (if domain is in admin account).
Or maybe roundcube is just his way to mask real source of entrance.
Second question is - how 8083 port has been disabled?
Via firewall?
Or you just stopped vesta-nginx service?
On my servers - even I did
... vesta was started again after auto-update-vesta-cron (after update) :(
Also, when you update vesta manually, it will be started automatically too.
That way Vesta could start by itself on any server after last v19 update...
But if you disabled 8083 port in vesta-firewall, then I really don't have explaination how you are hacked...
Then he gets in via roundcube PHP file.
And if you didn't in php.ini disabled PHP functions like exec() and shell()... that way he has all permissions to run anything under ''admin'' privileges (if domain is in admin account).
Or maybe roundcube is just his way to mask real source of entrance.
Second question is - how 8083 port has been disabled?
Via firewall?
Or you just stopped vesta-nginx service?
On my servers - even I did
Code: Select all
systemctl stop vesta
systemctl disable vesta
chmod -R a-x /usr/local/vesta/nginx/sbin
Also, when you update vesta manually, it will be started automatically too.
That way Vesta could start by itself on any server after last v19 update...
But if you disabled 8083 port in vesta-firewall, then I really don't have explaination how you are hacked...
Re: Got 10 VestaCP servers exploited
If so, this means that VestaCP has a tremendous security hole, which allows an intruder to bypass all sanity checks and change an arbitrary file in the system.
There are much more easy ways to get into the system if you can modify any file owned by root.
BTW, I have not checked this myself, but isn't Vesta stuff separated from the rest of the world? I mean, no other software should be run as admin, unless explicitly configured to do so by the system administrator. `admin` is able to elevate its privileges by running passwordless `sudo`, and if any third party software runs as `admin` because it was configured so by Vesta, this is a huge security risk.
Re: Got 10 VestaCP servers exploited
yea, thats exactly what i want to find out before i can start the vesta service again.dpeca wrote: But if you disabled 8083 port in vesta-firewall, then I really don't have explaination how you are hacked...
and i hope we soon get some information that they could retrive from the poll.
i have the server running with disabled vesta service and disabled phpmyadmin+roundcube on vesta release 20
for 2 days now. ports are still protected by the firewall. no more hack and no suspicious logs in nginx or elsewhere.
Re: Got 10 VestaCP servers exploited
https://roundcube.net/news/2018/04/11/s ... date-1.3.6
but i'm not sure how this can be exploited on Vesta servers, since 'archive' plugin is not activated by default, you must enable it manually by modifying config.inc.php .
but i'm not sure how this can be exploited on Vesta servers, since 'archive' plugin is not activated by default, you must enable it manually by modifying config.inc.php .
Re: Got 10 VestaCP servers exploited
https://github.com/serghey-rodin/vesta/ ... nc.php#L35dpeca wrote: ↑Thu Apr 12, 2018 2:57 pmhttps://roundcube.net/news/2018/04/11/s ... date-1.3.6
but i'm not sure how this can be exploited on Vesta servers, since 'archive' plugin is not activated by default, you must enable it manually by modifying config.inc.php .
Unfortunately it is included in the default settings.
Re: Got 10 VestaCP servers exploited
interesting thing that it's not enabled on Debian.
https://github.com/serghey-rodin/vesta/ ... c.php#L378
https://github.com/serghey-rodin/vesta/ ... c.php#L380
https://github.com/serghey-rodin/vesta/ ... c.php#L380
also for ubuntu:
https://github.com/serghey-rodin/vesta/ ... c.php#L380
actually, it's clearly the same file for debian 7, 8, 9 and ubuntu...
https://github.com/serghey-rodin/vesta/ ... c.php#L378
https://github.com/serghey-rodin/vesta/ ... c.php#L380
https://github.com/serghey-rodin/vesta/ ... c.php#L380
also for ubuntu:
https://github.com/serghey-rodin/vesta/ ... c.php#L380
actually, it's clearly the same file for debian 7, 8, 9 and ubuntu...
Re: Got 10 VestaCP servers exploited
And as I understand, this can only manipulate with IMAP, for example to delete your emails from inbox... it's not arbitrary code execution.