Shulou(Shulou.com)06/03 Report--

This article introduces the relevant knowledge of "how to solve the problem invaded by Redis". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

The course of the event

In fact, this kind of attack method happened in 2015, when the security protection mechanism of Redis was relatively poor, and we can only rely on the operation and maintenance personnel to configure reasonably to ensure the security of the database. For a time, tens of thousands of Redis nodes around the world were attacked, and the above strange phenomenon occurred. All the data was emptied, leaving only a key called crackit, whose value is similar to a string of RSA public keys.

Later, it was verified that the attacker used the function of Redis dynamic configuration and data persistence to write his RSA public key to the / root/.ssh/authored_keys file of the attacked server, so that he could log in to the other party's root user directly with the private key and invade the other party's system.

The security protection of the occupied server is not very good, as follows:

The port of Redis is the default port and can be accessed from the public network.

Redis hasn't set a password yet.

The Redis process is started by the root user.

Each of the above points is dangerous, and together, it's really fatal. Not to mention that other people write the public key to your system, just connect to your database and delete it, and that's a lot to lose. So what is the specific process? let me briefly demonstrate it on the local loopback address.

Local demo

The default port for Redis snooping is 6379, and we set it to receive the connection of the network card 127.0.0.1, so that I can definitely connect to Redis locally, thus simulating the condition that "Redis can be accessed from the public network".

Now I am an ordinary user named fdl. I want to log in to the root user on my system with ssh. I want to enter the password of root. I don't know, so I can't log in.

In addition to password login, you can also log in using the RSA key pair, but you have to store my public key in root's home directory / root/.ssh/authored_keys. We know that the permission setting of the / root directory does not allow any other user to break into read and write:

However, I found myself having direct access to Redis:

If Redis is running as root, then I can manipulate Redis to write my public key to root's home directory. One way for Redis to persist is to generate a RDB file that contains the raw data.

With an evil smile, I emptied all the data in Redis, and then wrote my RSA public key to the database, where I added line breaks at the beginning and end to avoid damaging the public key string during the generation of the RDB file:

Command Redis to save the generated data file to the authored_keys file in / root/.ssh/:

Now that our RSA public key is included in root's home directory, we can log in to root through the key pair:

Take a look at the public key just written to root's home:

Garbled code is some kind of code of GDB file, but the public key in the middle is completely preserved, and the ssh login program actually recognizes this public key surrounded by garbled code!

At this point, with root permissions, you can do whatever you want.

Draw lessons

Although basically will not be subjected to this kind of attack (the new version of Redis does not have a password when the default does not open the extranet), but for the security of the system is everyone should pay attention to.

We toss about things ourselves and use a low-configuration CVM. In order to save trouble, we generally do not configure the firewall carefully. The database does not have a password or a simple password such as admin or root. Anyway, there is not much data. This is definitely not a good habit.

Now that our computer systems are getting better and better, every mature project is maintained by the best people, which should be technically unassailable, so the only thing that could go wrong is the people who use them.

Just like often seeing someone's QQ stolen, I believe that the person who stole the account certainly did not go to Tencent's database to steal the number. It must be that the owner of QQ had poor security awareness and entered his own account password in which phishing website, which led to the theft. I have never seen Wechat stolen, which may be the reason why Wechat weakens the password to log in and uses the QR code to scan the login. This should also be regarded as a kind of security consideration. After all, Wechat has a payment function.

The above scam for technical people, look at url, browsers analyze the network package is easy to identify, but you do not believe, most people really do not understand how to identify phishing sites and official websites. Just like I really didn't expect that in 2020, some people are still looking for this loophole in Redis, and there are still people who have been hit.

So back to the use of Redis database, security recommendations are clearly written on the official website. Let me briefly summarize it:

Do not use root users to start Redis Server, and be sure to set a password, and the password is not too short, otherwise it is easy to be cracked by force.

Configure the server firewall and Redis's config file to keep Redis out of contact with the outside world.

Use the rename function to disguise the dangerous command flushall to prevent the deletion of the database and the loss of data.

That's all for the content of "how to solve the problem invaded by Redis". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.