Vesta Control Panel - Forum

StudioMaX wrote: Sun Apr 08, 2018 11:54 am A bit more info:
My /etc/cron.hourly/gcc.sh file was modified on 04.04.2018 16:25:00

I've analyzed the modified /var/lib/mysql/roundcube/session.ibd file, which was modified at the same time on 04.04.2018 16:24:56

In SQL dump of this "session" table from "roundcube" database I found new session at the same time:

Code: Select all

INSERT INTO `session` (`sess_id`, `changed`, `ip`, `vars`) VALUES
('ajhkl541vskuji31ss3tadl7gc',	'2018-04-04 16:24:54',	'119.82.29.17',	'dGVtcHxiOjE7bGFuZ3VhZ2V8czo1OiJlbl9VUyI7dGFza3xzOjU6ImxvZ2luIjtyZXF1ZXN0X3Rva2VufHM6MzI6ImZ5blJ2SlpPZ1VoeTFNUDZ6c0FWUk4yZXZ6YWNHdlhrIjs=');

119.82.29.17 - looks like attacker's or bot's IP

But interesting is that the same IP address was figured in other session from 2018-03-24 23:02:01

Code: Select all

INSERT INTO `session` (`sess_id`, `changed`, `ip`, `vars`) VALUES
('1a6f1ft5oo732eju8p6mldlag1',	'2018-03-24 23:02:01',	'119.82.29.17',	'dGVtcHxiOjE7bGFuZ3VhZ2V8czo1OiJlbl9VUyI7dGFza3xzOjU6ImxvZ2luIjtyZXF1ZXN0X3Rva2VufHM6MzI6InJhQ1M4Z2hYME01YkJ2M1F6akt6SWJTeHVCY1E3dFA2Ijs=');

All other tables in "roundcube" database were empty (since I do not use Roundcube).

I installed Vesta on the new server on 24.03.2018 0:00:51, so the bot detected it in less than a day.

crackerizer wrote: Sun Apr 08, 2018 12:21 pm One of my VPS at OVH got exploit this morning. I did reinstall the os and restored all accounts from my remote backup. I'm now monitoring any change in /etc with inotify. From the information I read here, it seems like all created executables have to be done with root access. The exploit has to be more than just bugs in Roundcube which is run under www-data user. My speculation.

lukapaunovic wrote: Sun Apr 08, 2018 12:22 pm I'm cheering it's not roundcube cuz another server didn't got hacked again with disabled Vesta. I'm still keeping this hacked server mounted in rescue until sergehey is back. I truly hope he will be back my client is insisting on puting sites back up

Prime wrote: Sun Apr 08, 2018 12:20 pm Then I think we can eliminate the theory that Roundcube is the fault here.

[root@mail /]# lsof -p 985
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
update 985 root cwd DIR 182,178001 4096 786628 /usr/share/roundcubemail
update 985 root rtd DIR 182,178001 4096 2 /
update 985 root txt REG 182,178001 625611 659895 /tmp/update
update 985 root 0u CHR 1,3 0t0 3390808082 /dev/null
update 985 root 1u CHR 1,3 0t0 3390808082 /dev/null
update 985 root 2u CHR 1,3 0t0 3390808082 /dev/null
update 985 root 3u IPv4 1473993150 0t0 UDP *:42651
update 985 root 4u IPv4 1473990633 0t0 UDP *:36423
update 985 root 69r FIFO 0,8 0t0 188493315 pipe
update 985 root 70w FIFO 0,8 0t0 188493315 pipe
update 985 root 71r FIFO 0,8 0t0 188493316 pipe
update 985 root 72w FIFO 0,8 0t0 188493316 pipe
update 985 root 77r CHR 1,9 0t0 3390808086 /dev/urandom

Prime wrote: Sun Apr 08, 2018 12:24 pm

lukapaunovic wrote: Sun Apr 08, 2018 12:22 pm I'm cheering it's not roundcube cuz another server didn't got hacked again with disabled Vesta. I'm still keeping this hacked server mounted in rescue until sergehey is back. I truly hope he will be back my client is insisting on puting sites back up

Mine isn't hacked either and I've been running VestaCP enabled all the time since this was discovered. Seems like certain IP-ranges may have been targeted more than others this time around.

StudioMaX wrote: Sun Apr 08, 2018 12:24 pm

Prime wrote: Sun Apr 08, 2018 12:20 pm Then I think we can eliminate the theory that Roundcube is the fault here.

Then why "/tmp/update" was launched from the working directory of Roundcube?

Code: Select all

[root@mail /]# lsof -p 985
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
update 985 root cwd DIR 182,178001 4096 786628 /usr/share/roundcubemail
update 985 root rtd DIR 182,178001 4096 2 /
update 985 root txt REG 182,178001 625611 659895 /tmp/update
update 985 root 0u CHR 1,3 0t0 3390808082 /dev/null
update 985 root 1u CHR 1,3 0t0 3390808082 /dev/null
update 985 root 2u CHR 1,3 0t0 3390808082 /dev/null
update 985 root 3u IPv4 1473993150 0t0 UDP *:42651
update 985 root 4u IPv4 1473990633 0t0 UDP *:36423
update 985 root 69r FIFO 0,8 0t0 188493315 pipe
update 985 root 70w FIFO 0,8 0t0 188493315 pipe
update 985 root 71r FIFO 0,8 0t0 188493316 pipe
update 985 root 72w FIFO 0,8 0t0 188493316 pipe
update 985 root 77r CHR 1,9 0t0 3390808086 /dev/urandom

sandy wrote: Sun Apr 08, 2018 12:25 pm

Prime wrote: Sun Apr 08, 2018 12:24 pm

lukapaunovic wrote: Sun Apr 08, 2018 12:22 pm I'm cheering it's not roundcube cuz another server didn't got hacked again with disabled Vesta. I'm still keeping this hacked server mounted in rescue until sergehey is back. I truly hope he will be back my client is insisting on puting sites back up

Mine isn't hacked either and I've been running VestaCP enabled all the time since this was discovered. Seems like certain IP-ranges may have been targeted more than others this time around.

yes on same sub-nets, agree with you

lukapaunovic wrote: Sun Apr 08, 2018 12:34 pm Does anyone have any idea what I can perform on this hacked server to find attack source I tried everything I can't pinpoint it

top -c