Got 10 VestaCP servers exploited

[dpeca]

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.

[Falzo]

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.

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.

[kobo1d]

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.

but then there is still the question HOW could it deal with the api, when the firewall blocks access to 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...

[dpeca]

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

Code: Select all

systemctl stop vesta
systemctl disable vesta
chmod -R a-x /usr/local/vesta/nginx/sbin

... 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...

[wildwolf]

Maybe, through /api/, he just ''altered'' roundcube PHP file, because roundcube is on known path (/usr/share/roundcube/)

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.

Then he gets in via roundcube PHP file.

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.

[kobo1d]

But if you disabled 8083 port in vesta-firewall, then I really don't have explaination how you are hacked...

yea, thats exactly what i want to find out before i can start the vesta service again.
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.

[dpeca]

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 .

[StudioMaX]

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 .

https://github.com/serghey-rodin/vesta/ ... nc.php#L35
Unfortunately it is included in the default settings.

[dpeca]

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...

[dpeca]

And as I understand, this can only manipulate with IMAP, for example to delete your emails from inbox... it's not arbitrary code execution.