🔴 [Security] Docker Registry v2 Exposed + k8s ELB Hostname Leaked in Public DNS

[k4w1992-lgtm]

🔴 HIGH: Docker Registry v2 Exposed + k8s Infrastructure Leaked

Summary

registry.together.ai resolves to an AWS k8s ELB hostname, exposing a Docker Registry v2 API and revealing internal infrastructure details.

Evidence

Docker Registry v2 Exposed:

$ dig registry.together.ai A
registry.together.ai. 300 IN CNAME k8s-default-together-d2ba62fb4e-1435681072.us-west-2.elb.amazonaws.com.
44.224.112.109
44.253.75.128
54.148.242.0

$ curl -skI https://registry.together.ai/v2/
HTTP/2 401
docker-distribution-api-version: registry/2.0
www-authenticate: Bearer realm="https://api.together.ai/v1/registry/token",service="registry.together.ai"

$ curl -sk https://registry.together.ai/v2/_catalog
{"errors":[{"code":"UNAUTHORIZED","message":"authentication required"}]}

$ curl -sk https://registry.together.ai/
HTTP/2 200
cache-control: no-cache

Token Endpoint Leaked:

https://api.together.ai/v1/registry/token?service=registry.together.ai

Impact

1. Docker Registry v2 exposed — Container image registry accessible on public internet
2. Token endpoint URL leaked — https://api.together.ai/v1/registry/token reveals authentication flow
3. k8s cluster name revealed — k8s-default-together from ELB hostname
4. AWS region revealed — us-west-2
5. ELB naming convention leaked — Reveals k8s service naming pattern
6. Potential container enumeration — If auth is bypassed, all container images could be listed

Recommended Fix

1. Remove registry.together.ai DNS record from public zone
2. Use internal DNS zones for k8s services
3. Restrict ELB access to VPC/internal networks only
4. Add WAF/auth layer in front of Docker Registry
5. Use AWS PrivateLink or VPC endpoints for internal registries

Evidence Gist

https://gist.github.com/k4w1992-lgtm/55cac0090c1394b4ec7d263bab8c3854