Wednesday 27 September 2023

[Tips & Tricks] Docker FTW. Showing the POC using Docker.

in , , , ,  
 Using Docker to create your POC

Many times during our pentest engagements, we identified several issues related to the outdated software in used or a non-default misconfiguration that could lead to a significant impact. However, we could not able to create the proof-of-concept (POC) on the environment provided to us due to the following reasons, but not limited to:

  1. We have no direct access to the target as the exploit required access to the host. As an example, local privilege escalation exploit or it is just a host review assessment.
  2. There is a prerequisite in order to ensure the exploit works and we have no visibility on the configuration. As an example, a remote code execution (RCE) when a certain module is enabled.
  3. The customer is concern with the changes that might occur if the exploit is taking place.

The background

In a recent host review assessment we carried out for our first-time customer, we noticed that the host in-scope pretty much well-hardened even though the OS was quite old. From a discussion we had, the host has been repeatedly reviewed every year and it makes sense to see the current state of it looked pretty good.

However, there was something that caught our attention during the review. The kernel.yama.ptrace_scope was found to be set as 0.

At REHACK, we generally utilise several tools to perform the host review assessment. One of them is lynis. The tool identified the misconfiguration of the ptrace_scope:

- kernel.sysrq (exp: 0)       [ OK ]
- kernel.yama.ptrace_scope (exp: 1 2 3)      [ DIFFERENT ]
- net.ipv4.conf.all.accept_redirects (exp: 0)   [ OK ]

This misconfiguration could be neglected if the person conducted the review relies on the automatic scanning results as it does not show the result as a ‘vulnerability’ or similar. Hence, this kind of misconfiguration generally be ignored with the assumption that it is just a ‘best practice’ setting.

A quick Google search led us to these resources:

From the reading, the misconfiguration could allow privilege escalation by injecting process into the sudo tokens. The prerequisite for it to happen:

  • kernel.yama.ptrace_scope = 0
  • low privilege user is in sudoers and has password
  • gdb is enabled

All there requirements were there at time we reviewed the host!

The exploit looked promising at that time hence we informed to the customer. They were quite concern with the outcome of the exploit, hence we need to create our own environment to convince them and their management team.

The options

Now from our experience, we have the following options:

  1. Directly exploit the host > no permission from the customer.
  2. Boot up our virtual machine > possible, but may be time consuming
  3. Boot up from our Digital Ocean > possible, but may be time consuming and have cost
  4. Docker ftw!! > quick, easy to find images and disposable

Docker FTW!

We were glad that previously we had a read about tips and tricks using Docker for pentesters. One of the best reference that we read was from this blog by @ropnop:
https://blog.ropnop.com/docker-for-pentesters/

In the blog, he shared a quick way to find image and run it in an interactive shell. The commands were presented in aliases as the following:

alias dockershell="docker run --rm -i -t --entrypoint=/bin/bash"
alias dockershellsh="docker run --rm -i -t --entrypoint=/bin/sh"

function dockershellhere() {
    dirname=${PWD##*/}
    docker run --rm -it --entrypoint=/bin/bash -v `pwd`:/${dirname} -w /${dirname} "$@"
}
function dockershellshhere() {
    dirname=${PWD##*/}
    docker run --rm -it --entrypoint=/bin/sh -v `pwd`:/${dirname} -w /${dirname} "$@"
}

So, with the above aliases that already included in our shell, we simply located and enabled the Operating System similar to our target which was Ubuntu 18.04.

dockershell ubuntu:18.04

Once downloaded, we verified the version and added a new low privilege user, lowpriv

Next we installed the gdb tool and ensured the misconfiguration was similar.


With all the setup in place, now assuming an attacker able to access to this host as the lowpriv user (potentially via vulnerable application or other ways), the attacker could escalate the privilege into root without knowing the lowpriv's password.

Using the exploit from https://github.com/nongiach/sudo_inject, we demonstrated that to our customer.

Perfect. We got root :)

Explanation

When we showed this to the customer, they quite shocked with it and immediately wanted to plan for an urgent fix. But wait!! We explained to them correctly what actually happened.

The exploit could only works when the attacker could access the shell as the user with sudo access. Other than requiring gdb enabled, another important requirement for it to success is the user must performed the sudo something-something action first as to allow their session be stored temporarily.

At REHACK, we take consideration of the likelihood of the attack to happen before concluding the final risk of the issue. In this case, while the impact looks “Significant”, the likelihood probably “Rare” or “Complex”. We concluded this issue as “Medium”. It was fun considering this issue was previously ignored by the previous tests and we able to highlight the risk to the customer.

By default ptrace_scope is set as 1. We assumed that the setting was previously changed for some purposes which it was not been reverted back to 1. Some other suggestions also have been shared with them and they are happy with the end result.

References:

Bonus

Another issue that was also neglected was the sudo version used on the host. Most of the hosts that we reviewed, if the customers totally rely on their Linux’s package management tool, the sudo on their hosts potentially outdated. Give some times to review the version and see what exploits available for that version :)

Be thorough. RE:HACK.

Share: