Got 10 VestaCP servers exploited

[wildwolf]

There are few things I want to know if someone can please reply
1) The hacked server were running ssh on port 22 ?
2) Allow root to login were on?

No to both :-)

[lukapaunovic]

Stop speculating about Roundcube being the issue.
That can't be true. If it was, many panels using it would be exploited too.
Besides, all installations which were hacked were running latest roundcube version.
Those people stating like: I had blah blah number of installations blah blah without and blah blah with Roundcube is also nonsense.
because the hacker is going through IP range, probably subnets, and not all servers are on the same subnet nor each subnet has the same amount of IPs. even within the same provider. Hacker is probably scanning smaller ranges.

Also, whoever claims that passed variable, without even single quotes, directly on the end of a bash syntax is not an security issue is out of his mind.
Try to get such statement on unix.stackexchange.com and see what happens

ya possible roundcube can be issue , my server hit from china a lot of ip address , but its safe , because i have changed urls of phpmyadmin and roundcube , so maybe that's why am safe

I reinstalled vesta 10 minutes after the server was hacked and I stopped the service and I didn't get hacked again.

AS of speculation in regards to REPO, vesta staff has CHECKED the repo and repo is SAFE.

[wildwolf]

I don't think it was the repo - I had installations that were made 3 months ago and last updated in Jan 2018 suddenly get exploited around mid-day on Saturday 7th April.

As far as I can tell, Vesta tries to update itself automatically.

Code: Select all

# crontab -l -u admin
MAILTO=email@hidden
CONTENT_TYPE="text/plain; charset=utf-8"
15 02 * * * sudo /usr/local/vesta/bin/v-update-sys-queue disk
10 00 * * * sudo /usr/local/vesta/bin/v-update-sys-queue traffic
30 03 * * * sudo /usr/local/vesta/bin/v-update-sys-queue webstats
*/5 * * * * sudo /usr/local/vesta/bin/v-update-sys-queue backup
10 05 * * * sudo /usr/local/vesta/bin/v-backup-users
20 00 * * * sudo /usr/local/vesta/bin/v-update-user-stats
*/5 * * * * sudo /usr/local/vesta/bin/v-update-sys-rrd
10 3 * * * sudo /usr/local/vesta/bin/v-update-sys-vesta-all

/usr/local/vesta/bin/v-update-sys-vesta-all: The function of updating all vesta packages

Code: Select all

# Starting update loop
for package in vesta vesta-nginx vesta-php vesta-ioncube vesta-softaculous; do
    $BIN/v-update-sys-vesta "$package"
done

v-update-sys-vesta updates packages from Vesta's repositories.

So if you had this cron job on, your server *could* download the compromised version.

[wildwolf]

AS of speculation in regards to REPO, vesta staff has CHECKED the repo and repo is SAFE.

It is safe now, but was it safe several days ago?

Those who run CentOS and have auditd installed, you can run

Code: Select all

aureport -x

to see what commands were run bu the server (does NOT show commands run by root unless auditd is configured to do so) or

Code: Select all

ausearch  -m USER_CMD -i | grep -v -- '----'

to see the command line as well. On all compromised servers I was unable to find anything suspicious :-(

[lukapaunovic]

AS of speculation in regards to REPO, vesta staff has CHECKED the repo and repo is SAFE.

It is safe now, but was it safe several days ago?

YES, that's exactly what they checked ... LOL

[lukapaunovic]

also, the Password variable in API was written to /tmp
and virus does appear to be in temp, it was resting for over a month until it activated

systemd-private-bab3623b0b0a419abb1d8894d719d904-httpd.service-aceQDx
systemd-private-bab3623b0b0a419abb1d8894d719d904-named.service-H1orys

inside each was tmp folder with update executable virus in it

[fedekrum]

Hi Vesta staff !! I suppose you are having a hard one today.
Tired, sleepy, anxious, working hard.
I just want to thank you for the effort an I still think the project is excelent.
You need guts to start a project like this and get to the point you got.
You will get out of this stronger an with more experience.
Monsters like Microsoft, paid linux distributions, Oracle had the same problems before.

My best wishes for you !!

[Gluek]

But after the update to 0.9.8-20 anyone have been hacked? Or this update is solving the problem?

Got hacked on DO, then migrated to another provider, new clean VDS with fresh Vesta install just got 100% CPU load with 5k iops disk and 400 mbit net - so I even can't login via ssh. Rebooted... Now trying to detect what was wrong. P.S. ssh only with keys, no root login.

[kobo1d]

even after you clean the trojan, your system is still infected from what i see.
systemd (process 1) still creates supicious files under /tmp while all other directories are still clean.
but this is speculating now

[lukapaunovic]

also, the Password variable in API was written to /tmp
and virus does appear to be in temp, it was resting for over a month until it activated

systemd-private-bab3623b0b0a419abb1d8894d719d904-httpd.service-aceQDx
systemd-private-bab3623b0b0a419abb1d8894d719d904-named.service-H1orys

inside each was tmp folder with update executable virus in it

https://stackoverflow.com/questions/304 ... through-ng