Why?

While these containers were initially designed to support the Burp Suite container, they do not depend on the Burp container. In other words, the VNC containers can be used generically to provide an auxiliary VNC service to any other container.

Here are some advantages provided by their design:

• No need to install a VNC client on your local machine.
• Password-protected connection, with one password for full remote control, and another for viewing only.
• Default TLS with self-signed certificates.
  • Custom certificates can be configured through Docker volumes and/or the SSH container.
• No root access required.
• Configurable viewing resolution.
• A single novnc_client container can be used to connect to multiple novnc_server containers.

noVNC client

dockerfile

FROM httpd:latest

RUN apt-get update \

 && apt-get upgrade -y

RUN apt-get install --no-install-recommends -y openssl

RUN apt autoremove -y

COPY ./entrypoint.sh /root/

COPY --chown=daemon:daemon ./noVNC/ /usr/local/apache2/htdocs/

EXPOSE 443/tcp

ENTRYPOINT ["/bin/bash", "/root/entrypoint.sh"]

• Copy entrypoint.sh and noVNC’s files to the container.
• Expose port 443 and set entrypoint.sh to execute when the container runs.

entrypoint.sh

#! /bin/bash

mkdir -p ${HOME}/share

[[ -f ${HOME}/share/novnc_client.crt && -f ${HOME}/share/novnc_client.key ]] || \

    openssl req -x509 -nodes               \

    -out    ${HOME}/share/novnc_client.crt \

    -keyout ${HOME}/share/novnc_client.key \

    -subj "/CN=novnc_client.$(hostname)"

…

Custom certificates can be pre-loaded through a Docker volume mounted on /root/share, or through an active SSH container before running this container.

…

chmod 400 ${HOME}/share/*

chown -R 1000:1000 ${HOME}/share

cp -s ${HOME}/share/novnc_client.crt /usr/local/apache2/conf/server.crt

cp -s ${HOME}/share/novnc_client.key /usr/local/apache2/conf/server.key

…

…

# Enable TLS, per https://hub.docker.com/_/apache2.

sed -i                                                 \

    -e 's/^#\(Include .*httpd-ssl.conf\)/\1/'          \

    -e 's/^#\(LoadModule .*mod_ssl.so\)/\1/'           \

    -e 's/^#\(LoadModule .*mod_socache_shmcb.so\)/\1/' \

    /usr/local/apache2/conf/httpd.conf

exec /usr/local/bin/httpd-foreground

Building and running

To build the container, simply:

1. Ensure the current directory is where the dockerfile resides
2. Execute sudo docker build -t novnc_client:latest .

Note the trailing ., which just represents the current directory.
-t novnc_client:latest tags the build so we can reference it when running the container, as outlined below.

The --mount options should match the Docker volumes and directories you’ll be using with your own containers, if not the Burp and noVNC ones discussed in this article.

A complete example, with definitions for all containers discussed in this series as well as interactive build and run scripts, is present at github.com/elespike/burp_containers.

noVNC server

dockerfile

FROM debian:buster-slim

RUN apt-get update \

 && apt-get upgrade -y

RUN apt-get install --no-install-recommends -y \

    fluxbox           \

    openssl           \

    websockify        \

    x11vnc            \

    xterm             \

    xvfb

RUN apt autoremove -y

…

…

RUN groupadd oracle && mkdir /home/oracle     \

 && useradd -s /bin/bash -g oracle oracle     \

 && cp /etc/skel/.bashrc /home/oracle/.bashrc \

 && echo "cd ~/share" >> /home/oracle/.bashrc

…

Note line 19: for convenience, it will cause the current directory to be ~/share upon login.

…

COPY ./entrypoint.sh /home/oracle/

EXPOSE 5900/tcp

ENTRYPOINT ["/bin/bash", "/home/oracle/entrypoint.sh"]

• Copy entrypoint.sh to the container.
• Expose port 5900 and set entrypoint.sh to execute when the container runs.

entrypoint.sh

#! /bin/bash

_shell=""

_home="/home/oracle"

mkdir -p ${_home}/share

[[ -f ${_home}/share/websockify.pem ]] || \

    openssl req -x509 -nodes              \

    -out    ${_home}/share/websockify.pem \

    -keyout ${_home}/share/websockify.pem \

    -subj "/CN=novnc_server.$(hostname)"

…

Custom certificates can be pre-loaded through a Docker volume mounted on /home/oracle/share, or through an active SSH container before running this container.

…

passwdfile="${_home}/share/vncpass.$(hostname)"

# Generate passwords for full access and view-only access.

head -c 24 /dev/urandom | base64 >  ${passwdfile}

head -c 24 /dev/urandom | base64 >> ${passwdfile}

chmod 400 ${_home}/share/*

chown -R oracle:oracle ${_home}

chown    oracle:oracle /tmp/.X11-unix

…

…

resolution="1600x900"

while [[ -n ${1} ]]

do

    [[ ${1} =~ --[0-9]{3,4}x[0-9]{3,4} ]] && resolution=${1:2}

    [[ ${1} == "--shell" ]] && _shell="& exec /bin/bash -i"

    shift

done

export X11VNC_CREATE_GEOM=${resolution}

export DISPLAY=:20  # this is the first display attempted by "x11vnc -create"

…

One item of note is _shell="& exec /bin/bash -i". This sets up the --shell argument. When present, it will cause the container to execute x11vnc as a background process and, by means of exec, replace the current process with /bin/bash, dropping the container into an interactive shell.

…

_chroot="chroot --userspec=oracle:oracle / env HOME=${_home}"

${_chroot} websockify -D                 \

    --cert ${_home}/share/websockify.pem \

    --ssl-only 0.0.0.0:6080 127.0.0.1:5900

exec ${_chroot} /bin/bash -c "x11vnc    \

    -create -localhost -shared -forever \

    -passwdfile ${passwdfile}           \

    -afteraccept 'fluxbox &' ${_shell}"

Let’s explore how that last command causes the container to…

Run as a normal user

Here’s what that looks like without the --shell argument:

exec
 |__chroot
     |__env (now running as 'oracle:oracle')
         |__bash
             |__x11vnc (becomes parent process)

And with the --shell argument:

exec
 |__chroot
     |__env (now running as 'oracle:oracle')
         |__bash
             |__x11vnc (in background)
             |__exec
                 |__bash (becomes parent process)

Building and running

To build the container, simply:

1. Ensure the current directory is where the dockerfile resides
2. Execute sudo docker build -t novnc_server:latest .

Note the trailing ., which just represents the current directory.
-t novnc_server:latest tags the build so we can reference it when running the container, as outlined below.

The --mount options should match the Docker volumes and directories you’ll be using with your own containers, if not the Burp and noVNC ones discussed in this article.

A complete example, with definitions for all containers discussed in this series as well as interactive build and run scripts, is present at github.com/elespike/burp_containers.