Critical 1Cloud Server Vulnerability
We want to share our experience with 1cloud servers. We do not want to blame anyone, just want to put the problem on public display, so that 1cloud employees will have the motivation to conduct a detailed analysis of this problem.
It all started with the fact that the last months on the Windows 1cloud servers, we began to notice an abnormal load, but did not attach any special importance to this, since the Windows server was mainly used to perform various small tasks such as using the browser and any other programs, and especially there was a desire to find out what was there and how.
But the other day there was a very unpleasant and insulting situation on the part of 1cloud employees, which pushed us to publish this article. We have been using 1cloud servers for about 1.5-2x years, the rules for using servers have not been violated. I was unpleasantly surprised when I logged into my account and saw that all 40 of our servers were blocked with the note “Server is blocked by the administrator. Reason for blocking: brute force. ” I was going to write to the support and saw a new message from the technical support service, which said:
Due to an employee error or due to any problems with the server management system, all 40 servers were turned off instead of one problem one, and they were unavailable for 24 hours. From the support message was received as follows:
This is certainly an unpleasant situation, but it happens, I thought, and we began to understand the problem that caused the servers to be blocked. The servers did not automatically turn on, as we were promised, and I had to manually start all the servers, but this is minor compared to the main problem. Logged in to the server, and immediately noticed the oddity that ssh we connected the last time on August 20th, and various malicious files were uploaded to the server on the 21st and 22nd. As it turned out, during the creation of each server on 1cloud, some doubtful user “user” is added, in the folder of which a bunch of malicious files later appeared in the miner, including the xrig miner.
They started calling the support service, explained the situation, asked what user “user” was added to when creating the server and what malicious files were doing in its folders. The tech support employee tried to deny that the user “user” was added automatically when creating the server, and claimed that they had nothing to do with it. We created a new server for the test, on which the user “user” was also immediately present, but so far without malicious files, since the malicious software is injected into the server not immediately, but after a day or more. The tech support employee could not give a clear answer, from where the user “user” appeared on the newly created server by default.
It turned out to look at the logs, it turned out that someone, knowing the password, connected to the user “user”, and uploaded malicious files for mining and brute-force to the server. At once I would like to clarify that 1cloud clients are not given a password from the user “user”, moreover, the technical support officer persistently argued to me that even such a user was not on their servers and never had, although we saw such users on all servers throughout the entire period use of servers.
We believe, and everything indicates that one of the employees of 1cloud (I really hope that it is not a guide), began to do black deeds, installing miners and malicious software on the servers of their clients, for which, by the way, we pay money. In the first days after the creation of the server, someone connects to it through the user “user”, knowing his password, and gains control over your server. Perhaps this is a brute, you say, but no, unfortunately, the logs show that it is not a brute, namely, ordinary authorization without selecting passwords. Before logging into the server as user “user”, the logs show an attempt to connect user, admin, ubuntu, ubnt, test and osmc to one-time users, and then successfully authorize through user “user”.
One conclusion from this is that 1cloud servers are currently unsafe to use for hosting any important projects, since your data may be lost due to the fact that some mole has wound up in 1cloud, which has left a hole in the OS templates. At the moment, we managed to find out that this vulnerability is definitely present in the Debian 8 template, let the rest of the employees of 1cloud check themselves, we have already done enough to inform them about this vulnerability.
After lengthy telephone conversations with 1cloud, we could not get a clear explanation of what was happening. They reluctantly apologized to us and said that they would sometime be engaged in replacing the OS templates, and eliminate everything superfluous from them. The question is being imposed, guys, what extra you need to remove from OS templates? Do you completely spit on your customers? How was it possible to sell servers with a similar gap to thousands of clients who store terabytes of important data on these servers? Only one output –1cloud appreciates only profit, customer data does not represent any value for them! The guys from 1cloud, if you think that I'm wrong - prove me the opposite!
We are open to communication, dear employees 1cloud, if you have any questions - write a ticket. We are ready to discuss this situation, but only with someone competent, and not with an employee of the support team, who persistently tried to prove to us that you do not add any users with the name “user” when creating the server. We are also ready to provide all the necessary data to help end the sale of vulnerable 1cloud servers once and for all!
It all started with the fact that the last months on the Windows 1cloud servers, we began to notice an abnormal load, but did not attach any special importance to this, since the Windows server was mainly used to perform various small tasks such as using the browser and any other programs, and especially there was a desire to find out what was there and how.
But the other day there was a very unpleasant and insulting situation on the part of 1cloud employees, which pushed us to publish this article. We have been using 1cloud servers for about 1.5-2x years, the rules for using servers have not been violated. I was unpleasantly surprised when I logged into my account and saw that all 40 of our servers were blocked with the note “Server is blocked by the administrator. Reason for blocking: brute force. ” I was going to write to the support and saw a new message from the technical support service, which said:
Hello.
')
Anomalous network activity was detected from your IP 111.111.11.111 server: attempts to connect to a large number of arbitrary servers on port 22 (SSH)
The server may have been hacked. You need to quickly fix the problem.
If there is no response on this request, the server will be disconnected from the network.
Due to an employee error or due to any problems with the server management system, all 40 servers were turned off instead of one problem one, and they were unavailable for 24 hours. From the support message was received as follows:
Servers unlocked, they will turn on automatically. According to internal instructions, one problem server should have been disconnected, this incident will be investigated.
Please, in order to avoid such situations, respond to the appeal more quickly.
Also please report upon the elimination of problems with the server.
This is certainly an unpleasant situation, but it happens, I thought, and we began to understand the problem that caused the servers to be blocked. The servers did not automatically turn on, as we were promised, and I had to manually start all the servers, but this is minor compared to the main problem. Logged in to the server, and immediately noticed the oddity that ssh we connected the last time on August 20th, and various malicious files were uploaded to the server on the 21st and 22nd. As it turned out, during the creation of each server on 1cloud, some doubtful user “user” is added, in the folder of which a bunch of malicious files later appeared in the miner, including the xrig miner.
They started calling the support service, explained the situation, asked what user “user” was added to when creating the server and what malicious files were doing in its folders. The tech support employee tried to deny that the user “user” was added automatically when creating the server, and claimed that they had nothing to do with it. We created a new server for the test, on which the user “user” was also immediately present, but so far without malicious files, since the malicious software is injected into the server not immediately, but after a day or more. The tech support employee could not give a clear answer, from where the user “user” appeared on the newly created server by default.
It turned out to look at the logs, it turned out that someone, knowing the password, connected to the user “user”, and uploaded malicious files for mining and brute-force to the server. At once I would like to clarify that 1cloud clients are not given a password from the user “user”, moreover, the technical support officer persistently argued to me that even such a user was not on their servers and never had, although we saw such users on all servers throughout the entire period use of servers.
We believe, and everything indicates that one of the employees of 1cloud (I really hope that it is not a guide), began to do black deeds, installing miners and malicious software on the servers of their clients, for which, by the way, we pay money. In the first days after the creation of the server, someone connects to it through the user “user”, knowing his password, and gains control over your server. Perhaps this is a brute, you say, but no, unfortunately, the logs show that it is not a brute, namely, ordinary authorization without selecting passwords. Before logging into the server as user “user”, the logs show an attempt to connect user, admin, ubuntu, ubnt, test and osmc to one-time users, and then successfully authorize through user “user”.
Aug 20 03:46:59 debian8x64 sshd[1328]: Invalid user test from 219.135.136.144
Aug 20 03:46:59 debian8x64 sshd[1328]: input_userauth_request: invalid user test [preauth]
Aug 20 03:46:59 debian8x64 sshd[1328]: pam_unix(sshd:auth): check pass; user unknown
Aug 20 03:46:59 debian8x64 sshd[1328]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=219.135.136.144
Aug 20 03:47:02 debian8x64 sshd[1328]: Failed password for invalid user test from 219.135.136.144 port 1072 ssh2
Aug 20 03:47:02 debian8x64 sshd[1328]: Connection closed by 219.135.136.144 [preauth]
Aug 20 03:47:03 debian8x64 sshd[1330]: reverse mapping checking getaddrinfo for 144.136.135.219.broad.gz.gd.dynamic.163data.com.cn [219.135.136.144] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 20 03:47:03 debian8x64 sshd[1330]: Invalid user debian from 219.135.136.144
Aug 20 03:47:03 debian8x64 sshd[1330]: input_userauth_request: invalid user debian [preauth]
Aug 20 03:47:03 debian8x64 sshd[1330]: pam_unix(sshd:auth): check pass; user unknown
Aug 20 03:47:03 debian8x64 sshd[1330]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=219.135.136.144
Aug 20 03:47:05 debian8x64 sshd[1330]: Failed password for invalid user debian from 219.135.136.144 port 8178 ssh2
Aug 20 03:47:05 debian8x64 sshd[1330]: Connection closed by 219.135.136.144 [preauth]
Aug 20 03:47:06 debian8x64 sshd[1332]: reverse mapping checking getaddrinfo for 144.136.135.219.broad.gz.gd.dynamic.163data.com.cn [219.135.136.144] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 20 03:47:07 debian8x64 sshd[1332]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=219.135.136.144 user=root
Aug 20 03:47:09 debian8x64 sshd[1332]: Failed password for root from 219.135.136.144 port 14224 ssh2
Aug 20 03:47:09 debian8x64 sshd[1332]: Connection closed by 219.135.136.144 [preauth]
Aug 20 03:47:10 debian8x64 sshd[1334]: reverse mapping checking getaddrinfo for 144.136.135.219.broad.gz.gd.dynamic.163data.com.cn [219.135.136.144] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 20 03:47:10 debian8x64 sshd[1334]: Invalid user debian from 219.135.136.144
Aug 20 03:47:10 debian8x64 sshd[1334]: input_userauth_request: invalid user debian [preauth]
Aug 20 03:47:11 debian8x64 sshd[1334]: pam_unix(sshd:auth): check pass; user unknown
Aug 20 03:47:11 debian8x64 sshd[1334]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=219.135.136.144
Aug 20 03:47:13 debian8x64 sshd[1334]: Failed password for invalid user debian from 219.135.136.144 port 21466 ssh2
Aug 20 03:47:13 debian8x64 sshd[1334]: Connection closed by 219.135.136.144 [preauth]
Aug 20 03:47:15 debian8x64 sshd[1336]: reverse mapping checking getaddrinfo for 144.136.135.219.broad.gz.gd.dynamic.163data.com.cn [219.135.136.144] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 20 03:47:15 debian8x64 sshd[1336]: Invalid user osmc from 219.135.136.144
Aug 20 03:47:15 debian8x64 sshd[1336]: input_userauth_request: invalid user osmc [preauth]
Aug 20 03:47:15 debian8x64 sshd[1336]: pam_unix(sshd:auth): check pass; user unknown
Aug 20 03:47:15 debian8x64 sshd[1336]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=219.135.136.144
Aug 20 03:47:16 debian8x64 sshd[1336]: Failed password for invalid user osmc from 219.135.136.144 port 28516 ssh2
Aug 20 03:47:17 debian8x64 sshd[1336]: Connection closed by 219.135.136.144 [preauth]
Aug 20 03:47:18 debian8x64 sshd[1338]: reverse mapping checking getaddrinfo for 144.136.135.219.broad.gz.gd.dynamic.163data.com.cn [219.135.136.144] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 20 03:47:18 debian8x64 sshd[1338]: Invalid user ubnt from 219.135.136.144
Aug 20 03:47:18 debian8x64 sshd[1338]: input_userauth_request: invalid user ubnt [preauth]
Aug 20 03:47:18 debian8x64 sshd[1338]: pam_unix(sshd:auth): check pass; user unknown
Aug 20 03:47:18 debian8x64 sshd[1338]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=219.135.136.144
Aug 20 03:47:20 debian8x64 sshd[1338]: Failed password for invalid user ubnt from 219.135.136.144 port 34656 ssh2
Aug 20 03:47:20 debian8x64 sshd[1338]: Connection closed by 219.135.136.144 [preauth]
Aug 20 03:47:22 debian8x64 sshd[1340]: reverse mapping checking getaddrinfo for 144.136.135.219.broad.gz.gd.dynamic.163data.com.cn [219.135.136.144] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 20 03:47:22 debian8x64 sshd[1340]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=219.135.136.144 user=root
Aug 20 03:47:24 debian8x64 sshd[1340]: Failed password for root from 219.135.136.144 port 40882 ssh2
Aug 20 03:47:24 debian8x64 sshd[1340]: Connection closed by 219.135.136.144 [preauth]
Aug 20 03:47:25 debian8x64 sshd[1342]: reverse mapping checking getaddrinfo for 144.136.135.219.broad.gz.gd.dynamic.163data.com.cn [219.135.136.144] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 20 03:47:25 debian8x64 sshd[1342]: Invalid user admin from 219.135.136.144
Aug 20 03:47:25 debian8x64 sshd[1342]: input_userauth_request: invalid user admin [preauth]
Aug 20 03:47:26 debian8x64 sshd[1342]: Failed none for invalid user admin from 219.135.136.144 port 47736 ssh2
Aug 20 03:47:26 debian8x64 sshd[1342]: Connection closed by 219.135.136.144 [preauth]
Aug 20 03:47:27 debian8x64 sshd[1344]: reverse mapping checking getaddrinfo for 144.136.135.219.broad.gz.gd.dynamic.163data.com.cn [219.135.136.144] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 20 03:47:27 debian8x64 sshd[1344]: Invalid user test from 219.135.136.144
Aug 20 03:47:27 debian8x64 sshd[1344]: input_userauth_request: invalid user test [preauth]
Aug 20 03:47:27 debian8x64 sshd[1344]: pam_unix(sshd:auth): check pass; user unknown
Aug 20 03:47:27 debian8x64 sshd[1344]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=219.135.136.144
Aug 20 03:47:29 debian8x64 sshd[1344]: Failed password for invalid user test from 219.135.136.144 port 50546 ssh2
Aug 20 03:47:29 debian8x64 sshd[1344]: Connection closed by 219.135.136.144 [preauth]
Aug 20 03:47:30 debian8x64 sshd[1346]: reverse mapping checking getaddrinfo for 144.136.135.219.broad.gz.gd.dynamic.163data.com.cn [219.135.136.144] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 20 03:47:31 debian8x64 sshd[1346]: Accepted password for user from 219.135.136.144 port 56492 ssh2
Aug 20 03:47:31 debian8x64 sshd[1346]: pam_unix(sshd:session): session opened for user user by (uid=0)
Aug 20 03:47:33 debian8x64 sshd[1350]: reverse mapping checking getaddrinfo for 144.136.135.219.broad.gz.gd.dynamic.163data.com.cn [219.135.136.144] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 20 03:47:33 debian8x64 sshd[1350]: Accepted password for user from 219.135.136.144 port 60134 ssh2
Aug 20 03:47:33 debian8x64 sshd[1350]: pam_unix(sshd:session): session opened for user user by (uid=0)
Aug 20 03:47:35 debian8x64 sshd[1354]: reverse mapping checking getaddrinfo for 144.136.135.219.broad.gz.gd.dynamic.163data.com.cn [219.135.136.144] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 20 03:47:35 debian8x64 sshd[1354]: Accepted password for user from 219.135.136.144 port 4485 ssh2
Aug 20 03:47:35 debian8x64 sshd[1354]: pam_unix(sshd:session): session opened for user user by (uid=0)
Aug 20 03:47:38 debian8x64 sshd[1358]: reverse mapping checking getaddrinfo for 144.136.135.219.broad.gz.gd.dynamic.163data.com.cn [219.135.136.144] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 20 03:47:38 debian8x64 sshd[1358]: Accepted password for user from 219.135.136.144 port 9509 ssh2
Aug 20 03:47:38 debian8x64 sshd[1358]: pam_unix(sshd:session): session opened for user user by (uid=0)
Aug 20 03:47:42 debian8x64 sshd[1362]: reverse mapping checking getaddrinfo for 144.136.135.219.broad.gz.gd.dynamic.163data.com.cn [219.135.136.144] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 20 03:47:42 debian8x64 sshd[1362]: Accepted password for user from 219.135.136.144 port 15833 ssh2
Aug 20 03:47:42 debian8x64 sshd[1362]: pam_unix(sshd:session): session opened for user user by (uid=0)
Aug 20 03:47:43 debian8x64 sshd[1346]: pam_unix(sshd:session): session closed for user user
Aug 20 03:47:44 debian8x64 sshd[1366]: reverse mapping checking getaddrinfo for 144.136.135.219.broad.gz.gd.dynamic.163data.com.cn [219.135.136.144] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 20 03:47:44 debian8x64 sshd[1366]: Accepted password for user from 219.135.136.144 port 19619 ssh2
Aug 20 03:47:44 debian8x64 sshd[1366]: pam_unix(sshd:session): session opened for user user by (uid=0)
Aug 20 03:47:46 debian8x64 sshd[1370]: reverse mapping checking getaddrinfo for 144.136.135.219.broad.gz.gd.dynamic.163data.com.cn [219.135.136.144] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 20 03:47:46 debian8x64 sshd[1370]: Accepted password for user from 219.135.136.144 port 23935 ssh2
Aug 20 03:47:46 debian8x64 sshd[1370]: pam_unix(sshd:session): session opened for user user by (uid=0)
Aug 20 03:47:48 debian8x64 sshd[1374]: reverse mapping checking getaddrinfo for 144.136.135.219.broad.gz.gd.dynamic.163data.com.cn [219.135.136.144] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 20 03:47:49 debian8x64 sshd[1374]: Accepted password for user from 219.135.136.144 port 28277 ssh2
Aug 20 03:47:49 debian8x64 sshd[1374]: pam_unix(sshd:session): session opened for user user by (uid=0)
Aug 20 03:47:51 debian8x64 sshd[1378]: reverse mapping checking getaddrinfo for 144.136.135.219.broad.gz.gd.dynamic.163data.com.cn [219.135.136.144] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 20 03:47:51 debian8x64 sshd[1378]: Accepted password for user from 219.135.136.144 port 31735 ssh2
Aug 20 03:47:51 debian8x64 sshd[1378]: pam_unix(sshd:session): session opened for user user by (uid=0)
Aug 20 03:47:53 debian8x64 sshd[1383]: reverse mapping checking getaddrinfo for 144.136.135.219.broad.gz.gd.dynamic.163data.com.cn [219.135.136.144] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 20 03:47:53 debian8x64 sshd[1383]: Accepted password for user from 219.135.136.144 port 36097 ssh2
Aug 20 03:47:53 debian8x64 sshd[1383]: pam_unix(sshd:session): session opened for user user by (uid=0)
Aug 20 03:47:55 debian8x64 sshd[1388]: reverse mapping checking getaddrinfo for 144.136.135.219.broad.gz.gd.dynamic.163data.com.cn [219.135.136.144] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 20 03:47:56 debian8x64 sshd[1388]: Accepted password for user from 219.135.136.144 port 39885 ssh2
Aug 20 03:47:56 debian8x64 sshd[1388]: pam_unix(sshd:session): session opened for user user by (uid=0)
Aug 20 03:48:16 debian8x64 sshd[1350]: pam_unix(sshd:session): session closed for user user
Aug 20 03:48:19 debian8x64 sshd[1354]: pam_unix(sshd:session): session closed for user user
Aug 20 03:48:22 debian8x64 sshd[1358]: pam_unix(sshd:session): session closed for user user
Aug 20 03:48:25 debian8x64 sshd[1362]: pam_unix(sshd:session): session closed for user user
Aug 20 03:48:27 debian8x64 sshd[1366]: pam_unix(sshd:session): session closed for user user
Aug 20 03:48:29 debian8x64 sshd[1370]: pam_unix(sshd:session): session closed for user user
Aug 20 03:48:31 debian8x64 sshd[1374]: pam_unix(sshd:session): session closed for user user
Aug 20 03:48:34 debian8x64 sshd[1378]: pam_unix(sshd:session): session closed for user user
Aug 20 03:48:36 debian8x64 sshd[1383]: pam_unix(sshd:session): session closed for user user
Aug 20 03:48:38 debian8x64 sshd[1388]: pam_unix(sshd:session): session closed for user userOne conclusion from this is that 1cloud servers are currently unsafe to use for hosting any important projects, since your data may be lost due to the fact that some mole has wound up in 1cloud, which has left a hole in the OS templates. At the moment, we managed to find out that this vulnerability is definitely present in the Debian 8 template, let the rest of the employees of 1cloud check themselves, we have already done enough to inform them about this vulnerability.
After lengthy telephone conversations with 1cloud, we could not get a clear explanation of what was happening. They reluctantly apologized to us and said that they would sometime be engaged in replacing the OS templates, and eliminate everything superfluous from them. The question is being imposed, guys, what extra you need to remove from OS templates? Do you completely spit on your customers? How was it possible to sell servers with a similar gap to thousands of clients who store terabytes of important data on these servers? Only one output –1cloud appreciates only profit, customer data does not represent any value for them! The guys from 1cloud, if you think that I'm wrong - prove me the opposite!
We are open to communication, dear employees 1cloud, if you have any questions - write a ticket. We are ready to discuss this situation, but only with someone competent, and not with an employee of the support team, who persistently tried to prove to us that you do not add any users with the name “user” when creating the server. We are also ready to provide all the necessary data to help end the sale of vulnerable 1cloud servers once and for all!
Source: https://habr.com/ru/post/421131/
All Articles