Got 10 VestaCP servers exploited

[darkworks]

i have not heard anyone bypassed Google Authenticator. its looks safe to me , also its not about perfect security , it add security layer , it slow down attackers a bit , better than nothing.

No, sorry, I disagree. That's maybe marginally useful for a situation where someone already has your password, and is now trying to log in to your account. For the type of exploit that happened here, Google Authenticator, along with fail2ban would be useless. There were no attempts to log in, the password was irrelevant. This was an exploit – a targeted way to gain access to a system which only requires 1 try.

And if it's not about perfect security, why put more road blocks in my way as a user as well? That's just inconvenience without benefit.

there is nothing like perfect Security , but it does not mean people should stop using password or other security measures , its like cat and mouse game , we try to protect our selves as much possible but that does not mean that we are safe , so try we must instead of opening gates removing barriers

[ivcha92]

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?

The above two questions will sort few things. I will post my report once I will have answers. Also if anyone need any help to clean the server or migration ping me. Cleaning will be free :)
Regards

1) No
2) YES using key

[ivcha92]

Finally got OVH to enable my server. I've mounted rootfs and checked for files modifed in last 7 days

find -L / -mtime -7

To check for suspicious files and got this:

Modified -

Code: Select all

/etc/crontab

Removed line 
*/3 * * * * root /etc/cron.hourly/gcc.sh

Added Files from exploit removed all of them from rescue mode

Code: Select all

/etc/cron.hourly/gcc.sh
/etc/rc.d/init.d/svbdpzgysd
/etc/rc.d/init.d/hrxcpaewve
/etc/rc.d/rc0.d/K90hrxcpaewve
/etc/rc.d/rc1.d/S90svbdpzgysd
/etc/rc.d/rc1.d/S90hrxcpaewve
/etc/rc.d/rc2.d/S90hrxcpaewve
/etc/rc.d/rc2.d/S90svbdpzgysd
/etc/rc.d/rc3.d/S90svbdpzgysd
/etc/rc.d/rc3.d/S90hrxcpaewve
/etc/rc.d/rc4.d/S90svbdpzgysd
/etc/rc.d/rc4.d/S90hrxcpaewve
/etc/rc.d/rc5.d/S90svbdpzgysd
/etc/rc.d/rc5.d/S90hrxcpaewve
/etc/rc.d/rc6.d/K90hrxcpaewve
/usr/bin/rmymidyjsm
/usr/bin/hrxcpaewve
/usr/bin/rqmiuecmlncd 
/usr/lib/libudev.so
/lib/libudev.so

Also added http auth

Modifed /usr/local/vesta/nginx/conf/nginx.conf

Enabled Access Log

Code: Select all

access_log          /usr/local/vesta/log/nginx-access.log main;

Generates user file for http auth

Code: Select all

sudo sh -c "echo -n 'admin:' >> /usr/local/vesta/nginx/conf/.htpasswd"
sudo sh -c "openssl passwd -apr1 >> /usr/local/vesta/nginx/conf/.htpasswd"

Enabled Http Auth in Server section in /usr/local/vesta/nginx/conf/nginx.conf

Code: Select all

auth_basic		"Restricted Content";
auth_basic_user_file	/usr/local/vesta/nginx/conf/.htpasswd;

Scanned With ClamAV RKHunter and chkrootkit everything looks clean now

I've completely closed 8083 port. And gonna run the server with vesta service disabled. I also disabled archive and zipdownload plugins in roundcube. Gonna wait to get to the bottom of this issue before enabling vesta again

[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

[rmjserver]

Blocking the port 8083 and stopping vesta service will help a little bit. But Chinese IP addresses are continuously trying to connect to our servers via SSH I ran netstat -natp and it showed multiple chines IP addresses trying to connect via ssh. The best way to prevent it is to change ssh port and optionally keep it blocked via firewall when not in use.After changing ssh port, those all Chinese IP addresses got disappeared.

[Messiah]

Stop speculating about Roundcube being the issue.

Who knows. I've tried to install vestacp at clear Debian 8 few hours ago and so this:

Code: Select all

E: Unable to locate package roundcube-core
E: Unable to locate package roundcube-mysql
E: Unable to locate package roundcube-plugins
E: Unable to locate package vesta-php
E: Unable to locate package vesta-ioncube
Error: apt-get install failed

Why roundcube disappeared from repos simultaneous with vesta-php?

We are all speculating until VestaCP developers will not publish the final solution or somebody will not publish the hack code itself. In any case we are flooding here. This way forum will became as popular as Facebook soon.

P.S. no Telegram Bot API or Google auth, please. It's sh*t. Password protection is enough, I always increase the password length.

[arktex54]

Thankfully I had port 8083 limited to 3 IPs on the VestaCP and DigitalOcean firewall. It is interesting that my firewall allows all ports for 1 IP and DO blocked that, also.

[SS88]

Thankfully I had port 8083 limited to 3 IPs on the VestaCP and DigitalOcean firewall. It is interesting that my firewall allows all ports for 1 IP and DO blocked that, also.

DO were trying to mitigate the attack. Many of my DO servers were taken offline by DO and they were not even compromised.

[darkworks]

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

[kandalf]

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