We are happy to announce that Vesta is back under active development as of 25 February 2024. We are working on v1 candidate and expect to engage more with the community over the coming months. We are committed to open source, and we encourage contributors to help us build the future of Vesta.
All VestaCP installations being attacked Topic is solved
Re: All VestaCP installations being attacked
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
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...
Re: All VestaCP installations being attacked
I designated IP to log on to SSHD, closing 8083 ports, but receiving notification is using DDOS.
I installed only two days.
I installed only two days.
Re: All VestaCP installations being attacked
@Admin of VestaCP
I'm a great supporter of VestaCP. Ever since 2014 when I first started using it. I've been promoting it too at the Forums I'm posting at. PLEASE can you do some damage control with all of these threads that aren't serving VestaCP well.
1. Can you PLEASE change the heading of this thread as it is not accurate and it puts a BAD reflection on VestaCP with our hosts. Our hosts see a 17-page thread with "ALL VestaCP installations being attacked" and they don't even want to read further to check what it's about - it is very damning for VestaCP.
The truth is NOT ALL VPSs with VestaCP panel have been attacked. Mine haven't been attacked. Like a small number have been hacked if one really reads through all of the posts, and a larger issue has been made out of it making it look worse than it really is. I don't downplay what has happened, but not moderating these comments may create a situation where hosts - who don't really know VestaCP - and don't care as they don't have time to read through 17 pages of discussion - will ban VestaCP from being used on their servers. Also, there's an issue of confidentiality here that is being breached to the detriment of VestaCP as your evil doers get to read all of the insides and will now be able to find more holes - like they did with the April reports.
FACTS:
1. VestaCP is not the only vulnerable panel around. ALL panels are vulnerable.
2. The responsibility for sorting out the issue shouldn't be by shutting VestaCP down and out - but for those hosts to cooperate with VestaCP to find out where the vulnerability lies. Hosts like Digital Ocean are great as at least I've seen posts from Digital bringing in some reason, but other hosts should cooperate too to help VestaCP sort out the problem. Instead of asking members who don't know how to effectively communicate their problems to the Admin at VestaCP, why not go to the hosts direct and deal with the issue PRIVATELY, CONFIDENTIALLY, and EFFECTIVELY, and that way get the hosts to be on VestaCP's side.
I'm a great supporter of VestaCP. Ever since 2014 when I first started using it. I've been promoting it too at the Forums I'm posting at. PLEASE can you do some damage control with all of these threads that aren't serving VestaCP well.
1. Can you PLEASE change the heading of this thread as it is not accurate and it puts a BAD reflection on VestaCP with our hosts. Our hosts see a 17-page thread with "ALL VestaCP installations being attacked" and they don't even want to read further to check what it's about - it is very damning for VestaCP.
The truth is NOT ALL VPSs with VestaCP panel have been attacked. Mine haven't been attacked. Like a small number have been hacked if one really reads through all of the posts, and a larger issue has been made out of it making it look worse than it really is. I don't downplay what has happened, but not moderating these comments may create a situation where hosts - who don't really know VestaCP - and don't care as they don't have time to read through 17 pages of discussion - will ban VestaCP from being used on their servers. Also, there's an issue of confidentiality here that is being breached to the detriment of VestaCP as your evil doers get to read all of the insides and will now be able to find more holes - like they did with the April reports.
FACTS:
1. VestaCP is not the only vulnerable panel around. ALL panels are vulnerable.
2. The responsibility for sorting out the issue shouldn't be by shutting VestaCP down and out - but for those hosts to cooperate with VestaCP to find out where the vulnerability lies. Hosts like Digital Ocean are great as at least I've seen posts from Digital bringing in some reason, but other hosts should cooperate too to help VestaCP sort out the problem. Instead of asking members who don't know how to effectively communicate their problems to the Admin at VestaCP, why not go to the hosts direct and deal with the issue PRIVATELY, CONFIDENTIALLY, and EFFECTIVELY, and that way get the hosts to be on VestaCP's side.
Re: All VestaCP installations being attacked
I installed Vesta at the beginning of August. The panel already included the fix for the previous vulnerability. This time, after being hacked, I blocked the requests to the Vesta port and disabled the Vesta service until the issue is solved. All seems ok for now. It's maybe relevant to say that I don't use a private key to connect, as I use a password, but I store it securely and encrypted.
Re: All VestaCP installations being attacked
eduzro, thanks
Our team working under this problem. All news will be in this topic
Information about bug fix will be in the forum header and Update section
Our team working under this problem. All news will be in this topic
Information about bug fix will be in the forum header and Update section
Re: All VestaCP installations being attacked
I feel that some core code is not public, for everyone's safety.
And the website of phpMyAdmin is fixed and can be bursting.
And the website of phpMyAdmin is fixed and can be bursting.
Re: All VestaCP installations being attacked
All code is public, you can see it on github, also you can download the vesta installation packages from repo and extract them on your own. That is, what open source is :). Expect the softacoulus extension, there is some ioncube protected code in it.
What can be bursted at phpmyadmin?
Re: All VestaCP installations being attacked
sorry for the delay, I have been quite busy but finally found the time again to check on it more.
I have been looking for a pattern and to see why only a few installations were affected. obviously there were some with vesta service running, some not and as written above it might even be dependant on whether the admin account had ssh access enabled or not.
assuming this is the case here, a potential attacker would need to get his hands on the password...
to see if some files of vesta might have been tempered with like in the last hack I compared all vesta related files on the server which showed the login tries in auth.log with an older one where I did not see something like that.
I found the debian installer script to differ in one line! The script that I used to install the server with login attempts has one additional line (809) like
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
so obviously the servername and password are send via GET request to some kind of script under vestacp.com ???
what is that for and where or why are the passwords of vesta installations sent to? are they getting stored somehow or is this not intentional?
if the initial password that get's set during the installation is send out to whomever I think it's no surprise that they got leaked or lost or this even is again a hack on the source files of vesta...
however, I downloded the original installer again and the specific line is not in it anymore - which makes me guess, that the devs already know about it?
anyone care to clarify?
I have been looking for a pattern and to see why only a few installations were affected. obviously there were some with vesta service running, some not and as written above it might even be dependant on whether the admin account had ssh access enabled or not.
assuming this is the case here, a potential attacker would need to get his hands on the password...
to see if some files of vesta might have been tempered with like in the last hack I compared all vesta related files on the server which showed the login tries in auth.log with an older one where I did not see something like that.
I found the debian installer script to differ in one line! The script that I used to install the server with login attempts has one additional line (809) like
Code: Select all
codename="$codename:$(echo $vpass:$servername | base64)"
Code: Select all
# Sending install notification to vestacp.com
wget vestacp.com/notify/?$codename -O /dev/null -q
what is that for and where or why are the passwords of vesta installations sent to? are they getting stored somehow or is this not intentional?
if the initial password that get's set during the installation is send out to whomever I think it's no surprise that they got leaked or lost or this even is again a hack on the source files of vesta...
however, I downloded the original installer again and the specific line is not in it anymore - which makes me guess, that the devs already know about it?
anyone care to clarify?
Re: All VestaCP installations being attacked
I'm a bit discouraged by the lack of attention to this post by core team.
I just switched to Vesta, and now I am concerned I made a mistake.
I was about to buy plugins but, everything is on hold.
What is the status of this?
I just switched to Vesta, and now I am concerned I made a mistake.
I was about to buy plugins but, everything is on hold.
What is the status of this?