Bola Idor on Docker

BOLA/IdOR (Broken Object Level Authorization / Insecure Direct Object Reference) vulnerabilities in Docker environments typically emerge through API endpoints that expose container, image, or volume identifiers without proper authorization checks. Docker's REST API and CLI tools create numerous attack surfaces where object identifiers like container IDs, image names, or volume names can be manipulated.

# Vulnerable Docker API endpoint example
curl -X GET http://docker-host:2375/containers/json

The Docker daemon's HTTP API (when exposed) often lacks proper authentication and authorization. An attacker who gains network access can enumerate containers and then manipulate object references:

# Enumerate all containers
curl http://docker-host:2375/containers/json

# Access another user's container logs (BOLA/IdOR)
curl http://docker-host:2375/containers/alice-container/logs?stdout=1

Container orchestration platforms like Docker Compose and Docker Swarm introduce additional BOLA/IdOR risks. Service discovery mechanisms and shared networks can allow lateral movement between containers:

# docker-compose.yml with exposed API
version: '3'
services:
  app:
    build: .
    ports:
      - "8080:80"
    environment:
      - DOCKER_HOST=tcp://docker.sock:2375

Volume mounts present another Docker-specific BOLA/IdOR vector. When containers share volumes without proper access controls, one container can access another's data:

# Shared volume without isolation
docker run -v shared-data:/data --name app1 alpine sh -c "echo 'app1 data' > /data/info.txt"
docker run -v shared-data:/data --name app2 alpine sh -c "cat /data/info.txt"  # BOLA: reads app1's data

Registry API endpoints are particularly vulnerable. Docker registries expose image layers and manifests that can be enumerated and accessed without proper authentication:

# Enumerate repositories
curl http://registry:5000/v2/_catalog

# Access image layers without authorization
curl http://registry:5000/v2/library/nginx/blobs/sha256:abcd1234

Detecting BOLA/IdOR vulnerabilities in Docker environments requires both network-level scanning and API endpoint testing. The Docker daemon's API must be tested for authentication bypass and object reference manipulation.

# Check if Docker API is exposed without TLS
curl -I http://localhost:2375/_ping

middleBrick's Docker-specific scanning identifies BOLA/IdOR vulnerabilities by testing API endpoints with manipulated object references:

{
  "endpoint": "http://docker-host:2375/containers/json",
  "test": "BOLA/IdOR",
  "status": "vulnerable",
  "severity": "high",
  "description": "Container enumeration without authentication",
  "remediation": "Enable TLS and authentication for Docker daemon"
}

Network exposure testing is critical for Docker environments. Exposed Docker APIs on public networks create immediate BOLA/IdOR risks:

# Scan for exposed Docker APIs
nmap -p 2375,2376,5000,8080 

# Test API access
curl -s http://target:2375/version | jq '.ApiVersion, .Os, .Arch'

Volume mount analysis helps identify BOLA/IdOR risks in shared storage scenarios. Tools can detect containers with overlapping volume mounts:

# List containers with volume mounts
docker ps -q | xargs docker inspect --format '
{{.Name}}: {{range .Mounts}}{{.Name}}:{{.Source}}:{{.Destination}} {{end}}'

Registry API scanning tests for BOLA/IdOR vulnerabilities in image distribution:

# Test registry access without authentication
curl -s http://registry:5000/v2/_catalog
curl -s http://registry:5000/v2/library/nginx/tags/list

middleBrick's black-box scanning approach tests these endpoints without requiring credentials, simulating an attacker's perspective:

{
  "scan_type": "docker_api",
  "tests_performed": 12,
  "bola_idor_tests": 4,
  "exposed_endpoints": ["/containers/json", "/images/json", "/volumes/json"],
  "recommendation": "Restrict Docker API access to localhost and enable authentication"
}

Remediating BOLA/IdOR vulnerabilities in Docker environments requires a defense-in-depth approach. Start with Docker daemon configuration to prevent unauthorized API access:

# Secure Docker daemon with TLS and authentication
dockerd --tlsverify --tlscacert=ca.pem --tlscert=server-cert.pem --tlskey=server-key.pem

Network-level controls are essential. Restrict Docker API access to localhost and use firewall rules:

# systemd drop-in for Docker
mkdir -p /etc/systemd/system/docker.service.d
cat > /etc/systemd/system/docker.service.d/override.conf << 'EOF'
[Service]
ExecStart=
ExecStart=/usr/bin/dockerd -H fd:// -H tcp://127.0.0.1:2375
EOF

Volume mount isolation prevents BOLA/IdOR through shared storage. Use unique volume names and avoid sharing volumes between untrusted containers:

# Isolated volumes with unique names
docker volume create --name app1-data
docker run -v app1-data:/data --name app1 alpine sh -c "echo 'app1 data' > /data/info.txt"

# Different volume for app2
docker volume create --name app2-data
docker run -v app2-data:/data --name app2 alpine sh -c "cat /data/info.txt"  # Fails: no access

Registry authentication prevents BOLA/IdOR in image distribution. Configure Docker Content Trust and authentication:

# Enable Docker Content Trust
export DOCKER_CONTENT_TRUST=1

# Configure registry with authentication
docker run -d -e "REGISTRY_AUTH=htpasswd" -e "REGISTRY_AUTH_HTPASSWD_REALM=Registry Realm" \
  -e "REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd" \
  -v /path/to/auth:/auth \
  registry:2

Application-level authorization checks prevent BOLA/IdOR in containerized applications. Implement proper access controls in your application code:

# Python example: proper authorization checks
from flask import Flask, request, jsonify
import docker

app = Flask(__name__)
client = docker.from_env()

@app.route('/containers//logs', methods=['GET'])
def get_container_logs(container_id):
    user_id = get_current_user_id()
    container = client.containers.get(container_id)
    
    # Check if user owns this container
    if not container_is_owned_by_user(container, user_id):
        return jsonify({'error': 'Unauthorized'}), 403
    
    return jsonify({'logs': container.logs()})

middleBrick's remediation guidance provides specific fixes for Docker BOLA/IdOR vulnerabilities:

{
  "finding_id": "docker_bola_idor_001",
  "title": "Unauthenticated Docker API access",
  "severity": "high",
  "docker_remediation": "Configure Docker daemon with --tlsverify and restrict API access to localhost",
  "code_example": "dockerd --tlsverify --tlscacert=ca.pem --tlscert=server-cert.pem --tlskey=server-key.pem",
  "risk_score": 85
}