Got 10 VestaCP servers exploited

[crackerizer]

lukapaunovic,

is your server up and running? May I access your log files?

[lukapaunovic]

I'm in rescue I'm not crazy to boot hacked system up lol

[Prime]

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

Can you check the read/write rights for the folder?

[StudioMaX]

Can you check the read/write rights for the folder?

owned by root:root, permissions 755

[sandy]

I'm in rescue I'm not crazy to boot hacked system up lol

lol and host doesn't allowed it too.

[lukapaunovic]

Precisely

[Falzo]

@lukapaunovic I also strongly doubt that roundcube is involved here. if the attacker/bot checked the website he might have automatically tried the roundcube url and therefore an entry in the session table of the rc db has been made.

I did not find anything in the usual webserver logfiles that gave reason to believe into some entry point outside of the vesta service itself.

sadly the vesta-nginx is set to send all of its own access log to /dev/null by default (see /usr/local/vesta/nginx/conf/nginx.conf). so there is no possibility left to see what might have happened there or what call/url was used for the exploit.

trying to figure more, but most likely without a honeypot which has especially that logging turned on for vesta getting infected, there will not be much information left to work with.

for the changes to the runlevels: I also saw the S90update links to a small script in init.d withe content posted above. there is no /tmp/update on my boxes though. also the timestamp of the S90update files are 2nd and 5th april, so does not exactly match any pattern. highly suspicious though...

[lukapaunovic]

Yes if I was on PC I would make Honeypot with Python and fake Vesta login page.
That way I could monitor requests. But I'm on vacation.
And I barely did anything. So far I backup servers, reinstall, prepend vestacp block in iptables then I install Vesta and restore and stop the service and allow access only to my ip.

[sandy]

@lukapaunovic I also strongly doubt that roundcube is involved here. if the attacker/bot checked the website he might have automatically tried the roundcube url and therefore an entry in the session table of the rc db has been made.

I did not find anything in the usual webserver logfiles that gave reason to believe into some entry point outside of the vesta service itself.

sadly the vesta-nginx is set to send all of its own access log to /dev/null by default (see /usr/local/vesta/nginx/conf/nginx.conf). so there is no possibility left to see what might have happened there or what call/url was used for the exploit.

trying to figure more, but most likely without a honeypot which has especially that logging turned on for vesta getting infected, there will not be much information left to work with.

for the changes to the runlevels: I also saw the S90update links to a small script in init.d withe content posted above. there is no /tmp/update on my boxes though. also the timestamp of the S90update files are 2nd and 5th april, so does not exactly match any pattern. highly suspicious though...

okay your reply convence me to check furthur and found no issue with roundcube
run this command to check the file stats (when those are modified) :

Code: Select all

stat /usr/share/roundcubemail/*

[crackerizer]

Since I'm likely to be hacked again. I will investigate this scenario, the executable file is posted through Roundcube and is run with one of vulnerability in Vesta core. So I will start Vesta service again with log enabled. Hopefully, it is hacked again.