Hole from a hosting provider or how to get access to a remote (not active) account

Thank you Elasticweb

Prehistory

I have one site, transferred from this hosting long before the discovery of the vulnerability, developed by two different companies, whose names I will not name for inexplicable understandable reasons. The site has undergone significant changes, both in the interface structure and in moving to another management system (a significant moment in this story ).

He lives his own site with his life, does not bother anyone, when suddenly I receive requests for a specific directory, with a frequency of exactly 1 minute, from the same ip. Plus, rare requests from different ip, aimed at finding the administrative panel of the site. Of course, I blocked the ip, but he continued to insist on his.



After reviewing the logs of errors and visits, I decided to check what kind of ip is and who owns it. With short manipulations, I find out that the ip belongs to Elasticweb, a hosting provider, which had the previous version of the site, but the account was inactive and abandoned.
')
Without thinking twice, I decided to call their technical support and find out what the matter was, who the author of the requests was and how long it would last (it lasted more than 12 hours ). Unfortunately, I did not find the phone numbers on the website of this company or in open sources, which made me write a tick in technical support.

Outset

The first thing that struck me was the unwillingness of support to sort out the situation in detail and simply close the ticket, after literally the first message.



Since I had suspicions about who could be behind this act, I decided to check with technical support about a specific account (the one on which the site was once located ). After a short wait, in fact, for quite a long time , I received an answer that indeed, all the manipulations were carried out from this account, but access to the account can be obtained via the email address specified in the account.



I decided to contact the previous developer and get information on account access from him, and I received a definite answer that the account was deleted due to non-payment of hosting.

After some explanations with technical support on the topic “There is no access because”, it turned out that the account seems to be deleted for non-payment and there is no access to it, but it still exists and continues to work as a backup version (which completely contradicts the previous answers).
I decided to clarify how it could be that the account was deleted, there is no access to it from the Web version, but still someone could set the task to Cron.



Poryskav in the stories of correspondence, found access to the FTP of this hosting, to this account.
What the hell is not joking, I thought, and launched an FTP client.

What was my surprise when I saw the contents of the root directory and files with backup on the screen? To say that I was surprised, to say nothing. With the allegedly deleted account and the lack of access to it, in some miraculous way, I received the entire contents of the account and was able to safely transfer it to my computer. After analyzing the last recorded logs, it turned out. that not only FTP works, but SSH is open and through this vulnerability Cron was launched.



I wrote another request to tech support, I received a very interesting answer. According to the hoster, the previous developer installed the Cron task after they deleted everything, they don’t see any problem and close the ticket.

To paraphrase, you get the following:

• We know that we have a hole that allows you to connect to a blocked, unpaid and inactive account, manipulate it and get quite a working result. But we will not do anything with it, because therefore. Understand yourself, and we close the ticket and do not want to listen to you anymore.

Actually on this communication with technical support was completed, and the ticket was forcibly completed.

Cause and investigation

Based on this story, I found out for myself the following:

1. When transferring the site, changing the owner, developer or just changing the hoster - be sure to change all accesses, passwords, directory names, set access to the control panel by IP or the like, and even better change the management system if there is a possibility. It was the change of the management system that provided me with the protection of my data, because on the way the attacker turned to, the last hosting contained a configuration file, and possibly a wired remote access shell, which the last developer left.
2. Do not trust the hoster in a word. Check for vulnerabilities yourself, read reviews and make backups! The last point is obvious, but not all do it.
3. Choose a hoster with at least SSH access for a certain time when you need it. Put different data for FTP, SSH, sFTP and other accounts, believe it is this approach that will help not only to save the data, but also to determine from which account the manipulations were made, if any.

PS This article by no means aims to belittle anyone's rights. Everything described above was the place to be, as I would like to warn everyone who reads this article. Be careful, let us come back with you!