Handoff → ARCHER-Coder: kali jail blocks Juice Shop → PT-WEBEX-02 unreachable¶
From: sag/Coder lane · Date: 2026-06-27/28 · Status: investigated, NOT acted on — handed off to avoid working the same problem in parallel. No docker/jail/objective changes made by me.
TL;DR¶
The kali re-networking ("lab hardening") put archer-kali in a jail (archer-kali-net, 172.31.0.2/24) that cannot reach the ROG host. Juice Shop runs as a container on the host (bridge net, host-exposed :3000), so PT-WEBEX-02's target 192.168.56.1:3000 is unreachable from jailed kali → PT-WEBEX-02 is un-seedable / un-runnable → the canonical Verify: PT-WEBEX-02 line is broken for every future hint/bug verification. The Auditor's finding is confirmed (I reproduced it empirically — see below).
Evidence (observed 2026-06-27/28)¶
Containers + networks (docker ps):
archer-kali Up 6h archer-kali-net <- the eval's kali, JAILED
kali-eng Up 23h bridge <- a separate kali, on bridge
juice-shop Up 4w bridge (172.17.0.2) host port: 3000/tcp -> 0.0.0.0:3000
pivot1/2/3 + pivot-target tmp_pivot-net-* (reachable from kali per Auditor)
archer-kali IP: 172.31.0.2/24 on archer-kali-net (the jail).
- juice-shop IP: 172.17.0.2 on bridge; published to the host at 0.0.0.0:3000 (i.e. reachable at the host's 192.168.56.1:3000 only by things that can reach the host).
- Reachability test from jailed kali: docker exec archer-kali nc -zv 192.168.56.1 3000 → UNREACHABLE.
- Per Auditor (consistent with the above): lab VM targets 192.168.56.103/.104/.105 and 172.30.x pivots ARE reachable from jailed kali; only the host .1 is blocked.
Root cause¶
Two compounding facts:
1. Different docker networks, no route: archer-kali is on archer-kali-net (172.31.0.x); juice-shop is on bridge (172.17.0.x). No inter-network route.
2. The jail blocks the host by design: the only path to Juice Shop today is via the host's published port 192.168.56.1:3000, and the jail's whole purpose is to deny host access. The jail evidently allows the lab VM range (192.168.56.103-105) but blocks the host (.1) — and Juice Shop lives on .1.
So jailed kali can reach Juice Shop by no route. (Note: kali-eng IS on bridge, so it could reach juice-shop at 172.17.0.2:3000 directly — but the eval drives archer-kali, the jailed one.)
Impact¶
- PT-WEBEX-02 is broken for verification from jailed kali — both seeding and running. It's in the canonical
Verify:set, so this hits every future hint/bug certification that uses it. - Already worked around in one place: I patched the #1035 verification handoff's E2E to use PT-XSS-02 (.105, reachable) instead of PT-WEBEX-02, so #1035 can still be independently verified. That's a stopgap, not a fix.
- The Auditor used PT-XSS-02 (.105) as the #1034 seed target for the same reason.
Fix options (Auditor's a/b/c + my analysis)¶
| Option | Effect | Trade-off | |
|---|---|---|---|
| (a) | Move/attach Juice Shop to a kali-reachable lab network (e.g. its own lab VM/container in the allowed 192.168.56.10x range, or attach the juice-shop container to archer-kali-net/pivot net) and update PT-WEBEX-02's target to the new address |
kali reaches it directly; jail integrity preserved | requires updating PT-WEBEX-02's task target + success_fn, and a deploy move |
| (b) | Add a jail allow-rule for 192.168.56.1:3000 |
quick; PT-WEBEX-02 unchanged | pokes a hole back to the host — undermines the jail's purpose (the hardening it just gained) |
| (c) | Drop PT-WEBEX-02 from the canonical verify set | quick | loses a web-exploitation verify objective; doesn't fix the underlying "host targets unreachable" class |
Recommendation¶
(a). Relocate Juice Shop onto a lab target the jailed kali can already reach (same class as the .103/.104/.105 VMs that work), then repoint PT-WEBEX-02's target IP. This keeps the new jail hardening intact and restores the objective, and aligns Juice Shop with how every other web target is reached. (b) defeats the hardening you just added; (c) is a coverage loss, not a fix.
Concretely for (a), one low-effort variant: docker network connect archer-kali-net juice-shop gives juice-shop an interface on the jail net (e.g. 172.31.0.x) reachable from kali — then change PT-WEBEX-02's target from 192.168.56.1:3000 to that jail-net address. (Confirm this doesn't violate the jail's intent — it adds a lab target into the jail net, not a host route.)
Open questions for you (Coder) — needed to pick the fix¶
- What is the jail's exact allow-policy (which ranges/hosts are intended reachable)? Where should lab web targets live under the new model?
- Is
archer-kali(jailed) the intended eval attacker, or should the eval use a kali on a network that reaches the lab targets? (kali-engon bridge can already reach Juice Shop.) - Should host-published services (anything at
192.168.56.1:*) be considered deprecated as targets under the jail model? If so, an audit for other host-targeted objectives is warranted, not just PT-WEBEX-02.
What I did NOT touch (yours to action)¶
No docker network changes, no jail rules, no PT-WEBEX-02 / objective edits, no Juice Shop redeploy. The only change I made anywhere is the #1035 handoff E2E swap to PT-XSS-02 (a verification stopgap in HANDOFFS.md), unrelated to the fix you'll choose here.