Vesta Control Panel - Forum

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

Prime wrote: Sun Apr 08, 2018 12:41 pm Can you check the read/write rights for the folder?

lukapaunovic wrote: Sun Apr 08, 2018 12:40 pm I'm in rescue I'm not crazy to boot hacked system up lol

Falzo wrote: Sun Apr 08, 2018 12:47 pm @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...

stat /usr/share/roundcubemail/*