Tag: container

During a container cluster assessment I noticed Heketi beeing used as a rest endpoint to manage GlusterFS volumes. As this was a white-box test I had been given read access to all relevant configuration files. The heketi config looked interesting, because I saw that authentication was disabled (this was the default setting) and heketi uses SSH to distribute calls to other systems. Therefore, an SSH key was configured as part of the configuration process.

A snippet of the config file looked like this:

  "executor": "ssh",

  "_sshexec_comment": "SSH username and private key file information",
  "sshexec": {
    "keyfile": "/etc/heketi/heketi_key",
    "user": "user",
    "port": "22",
    "fstab": "/etc/fstab",
    "sudo": true
  },

I reviewed the publicly accessible API documentation for heketi and probed it simultanously. Of course, no authentication on an infrastructure service like this is an issue in itself, because of denial of service possibilities.

Even more interesting was that I found a request where I am able to inject OS commands on hosts chosen within the request:

{
     "zone": 1,
     "hostnames": {
         "manage": [
             "127.0.0.1"
         ],
         "storage": [
             " || touch /tmp/vuln"
         ]
     },
     "cluster": "[.. removed ..]"
}

https://github.com/heketi/heketi/blob/master/docs/api/api.md#add-node

This issue made it possible to inject arbitrary OS commands on a system (example: 127.0.0.1), which is accessible using the configured heketi SSH key. This issue was even exploitable from within a pod / container on the cluster, which basically lets an attacker escape the container to one of the underlying hosts.

The issue has been discretely reported to Red Hat and a fixed version was released.

CVSS v3: 8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)

CVE-2017-15103: https://access.redhat.com/security/cve/CVE-2017-15103