Zabbix authorizes actions through user roles (what UI/API features a user may use) and user-group permissions (which host groups a user may read or write). These are commonly configured too broadly: service and operator accounts are given the Super-admin role, or user groups are granted write access to hosts and the permission to create items and run scripts, far beyond what their purpose requires. The consequence for an attacker is leverage: compromising even a low-value account can yield full configuration and code execution if that account was over-privileged. So the effective privilege of any obtained account must be checked rather than assumed, and over-permissioned non-admin accounts are a quiet path to the same outcomes as the admin.
Z=https://<target>/zabbix/api_jsonrpc.php; H='Content-Type: application/json-rpc'
# what can this account actually do? (role features + host-group permissions)
curl -sk $Z -H "$H" -d '{"jsonrpc":"2.0","method":"role.get","params":{"output":"extend"},"auth":"'"$TOK"'","id":1}'
curl -sk $Z -H "$H" -d '{"jsonrpc":"2.0","method":"usergroup.get","params":{"output":"extend","selectRights":"extend"},"auth":"'"$TOK"'","id":1}'
# test the high-value capabilities directly: can you create a script or an item?
Exploitation notes#
- Check effective privilege, not the account name: an over-privileged operator or service account may have Super-admin or script/item-creation rights, which is the same as admin for reaching code execution.
- The key capabilities to test are script management (server RCE via scripts) and item write on hosts (agent RCE via items);
role.get/usergroup.getreveal whether the account holds them. - Over-broad host-group write access also lets an attacker add hosts and interfaces pointing at systems they control, or reconfigure monitoring to harvest more credentials.
- This weakness makes lower-value credentials (easier to obtain) as useful as the admin; prioritise enumerating each obtained account's real rights.