Preample

This article is created for the challenge developers of Hacking-Lab who want to integrate an idocker into HL. Please read this first: Challenge Development

Introduction

Within HL, there are two types of Docker, which are launched by users of HL. On the one hand the web based Docker containers (idocker) and the TCP/UDP/Socket based containers (rdocker).

rdocker

The rdocker is suitable whenever the challenge provides any tcp/udp entpoint. Users of HL are directly communicating to the rdocker service. It is not required to define port-mappings in the docker-compose.yml. All services listening to the rdocker service will be exposed. No traefik label must be configured! Traefik is not in use with rdocker.

rdocker Example in HL RES editor

Use the following docker-compose.yml as an example of an idocker service.

services:
  ost-rdocker-test-hobo:
    image: REGISTRY_BASE_URL/ost-rdocker-test:stable
    hostname: 'hobo'
    environment:
      - "domainname=idocker.REALM_DOMAIN_SUFFIX"
    cpus: 1
    mem_limit: 128M

hobo

The value hobo will be replaced with the instance id of the newly created docker. It is just a placeholder. Do not change or remove any hobo entries. 😂

HL Docker Manager

This is a proprietary docker launcher of HL. This component will launch the vulnerable dockers for the users. Thus, the JSON file below gives the HL Docker Manager instructions on how to operate exactly when launching a docker.

{
  "name": "ost-rdocker-test",
  "type": "85ab3716-c5de-484d-b3ba-53cd5d985941",
  "dynFqdn": true,
  "fqdn": "",
  "expireTime": 60,
  "dockerType": "docker-compose",
  "singleton": false,
  "port": 22,
  "ipAccess": "direct",
  "protocol": "socket",
  "link": "tcp",
  "container": "REGISTRY_BASE_URL/ost-rdocker-test:stable",
  "containeryml": "85ab3716-c5de-484d-b3ba-53cd5d985941.yml",
  "vars": "",
  "network": "ost-rdocker-test",
  "egonetwork": true,
  "challengeType": "dynamicGN",
  "gnCreation": "docker-manager",
  "gnDeploy": "env",
  "goldNugget": "",
  "withCredentials": false,
  "dynUser": false,
  "dynPassword": false,
  "staticUsername": "",
  "staticPassword": ""
}

ipAccess

The setting ipAccess must be set to direct. Thus, the docker will become available on a public ip address.

protocol

The setting protocol must be set to socket. Thus, the HL Docker Manager knows the resource is directly accessible (without traefik)

port

The setting port is not really important. It will be the port shown to the user in the HL web app. Can be set to any value, the routing is not dependent on this value.

As you can see in the example, there is NO port mapping configured. The rdocker will expose any listening service (except those to 127.0.0.1)

Flag Generation

HL is very flexible with any kind of flag generation. The following line enforce the HL docker manager to create a flag and share it with an ENV variable

"challengeType": "dynamicGN",
  "gnCreation": "docker-manager",
  "gnDeploy": "env",

If you want to get the flag in a FILE, please use this sample

"challengeType": "dynamicGN",
  "gnCreation": "docker-manager",
  "gnDeploy": "file",

Lesson Learned

With this article you should have a better understanding of providing TCP/UDP based dockers to HL users. We urge you to use rdocker whenever you want to provide an ssh, telnet, ftp or any other socket based challenge. You can of course setup a web service too, but this is only recommended when providing a docker that has some TLS vulnerabilities. Otherwise, use the idocker to save public ip addresses

Examples of rdocker services

netcat listener on port 1234
ssh listener
ftp listener
any other non-web listener, of course

What is the difference to idocker?

The rdocker does not include a traefik load balancer. The rdocker is directly wired to a public ip address. Thus, whenever you are planning to create a socket based docker (TCP/UDP) you must switch to rdocker. Or if your docker provides a vulnerable https endpoint, you must use rdocker too, as with idocker the user will always see the traefic certificate.