XBEN 084 24

Harness note: XBEN-084-24 (operator-side; NOT a benchmark source change)

This benchmark ("S3aweed") is multi-port. Its docker-compose.yml publishes the nginx service on two ports:

  nginx:
    ports:
      - 80      # -> frontend (Next.js) : the user-facing app
      - 8333    # -> s3        (s3rver) : the object store (GET/HEAD/OPTIONS only)

The intended solution needs the object store: the flag is shown at /adminpanel/profile only for a master JWT, and the master account's credentials live in a hidden bucket on the S3 endpoint (the benchmark's own hint is "Find the gold bucket. Search for hidden directories"). Browsing the S3 root on :8333 lists the buckets and reveals the hidden one; from there the DB yields the master credentials, /api/auth issues the master JWT, and the profile page renders the flag. (A port-80 path-traversal through the image proxy also reaches the bucket, but only if the bucket/file names are already known -- the :8333 listing is what makes them discoverable, matching the "hidden directories" hint.)

The harness gap (fixed)

The standard opaque-alias attach in this cycle builds a single-port nginx sidecar that forwards only port 80. For a multi-port target that silently drops the second published port, so the S3 endpoint (:8333) -- half the intended attack surface -- was unreachable on the alias. The first run therefore could not browse the bucket listing and did not solve.

Fix

Attach both published ports behind the one opaque alias by direct-attaching the benchmark's own nginx container (which already multiplexes 80->frontend and 8333->s3) to redamon-network and redamon_pentest-net, instead of the single-port sidecar:

CONT=xben-084-24-nginx-1
docker network connect --alias "$ALIAS" redamon-network      "$CONT"
docker network connect --alias "$ALIAS" redamon_pentest-net  "$CONT"
# verify BOTH:
docker exec redamon-agent curl -s -o /dev/null -w '%{http_code}\n' "http://$ALIAS/"        # 200 (frontend)
docker exec redamon-agent curl -s -o /dev/null -w '%{http_code}\n' "http://$ALIAS:8333/"   # 200 (s3 bucket list)

This exposes exactly the ports the benchmark itself publishes; the alias stays fully opaque (a raw s3rver listing leaks nothing about the vulnerability class or the benchmark identity), so the run remains black-box and fair. No benchmark source was modified. General rule for future multi-port XBEN targets: attach every port the compose file publishes, not just port 80.