🇰🇷 한글 설명
Headroom의 LLM 프록시에서 x-headroom-base-url 헤더를 통해 공격자가 임의의 업스트림 목적지를 지정할 수 있는 취약점이 발견되었습니다. 이 취약점은 루프백, 링크 로컬 또는 RFC 1918 주소에 대한 검증이 없어 내부 서비스 및 클라우드 메타데이터 주소에 접근할 수 있게 하며, 인증 헤더가 그대로 전달되어 데이터 유출 위험이 큽니다.
💡 쉬운 설명
프록시 서버의 설정 오류로 인해 공격자가 내부 네트워크나 클라우드 관리 정보에 몰래 접근할 수 있는 보안 구멍이 있습니다. 특히 인증 정보까지 공격자가 지정한 곳으로 전달될 수 있어 매우 위험합니다.
🇺🇸 원문 (English)
Headroom's LLM proxy lets a client choose the upstream destination with the x-headroom-base-url request header. _resolve_openai_upstream_base in headroom/proxy/handlers/openai.py accepts the header value, requires only that it parse with an http or https scheme and a hostname, and returns it for use as the upstream base; _select_passthrough_base_url in headroom/providers/proxy_routes.py reads the same header for the passthrough routes. No check rejects loopback, link-local, or RFC 1918 destinations, and because the component is a proxy the upstream response is returned to the caller, so the request reaches internal services and cloud metadata addresses and their responses are disclosed. The Authorization header accompanying the request is forwarded unchanged to the caller-designated host. The pip console script binds 127.0.0.1 by default, but the reference docker-compose.yml ships --host 0.0.0.0 with published ports and no required HEADROOM_PROXY_TOKEN, which the server itself warns about at startup, so a deployment following the shipped compose exposes the affected data-plane routes to the network without authentication.
📍 영향받는 시스템
Headroom LLM proxy (Docker Compose 기본 설정 사용 시)
⚔️ 공격 벡터
x-headroom-base-url 헤더에 내부 IP 또는 클라우드 메타데이터 주소를 삽입하여 요청 전송
🛡️ 대응 방법
업스트림 목적지에 대한 화이트리스트 검증을 도입하고, HEADROOM_PROXY_TOKEN을 설정하여 인증을 강제하며, 호스트 바인딩을 제한해야 합니다.
🔧 검증 코드
명령어 실행 시 내부 주소(127.0.0.1)로의 요청이 차단되지 않고 응답이 반환되면 취약한 상태입니다.
curl -I -H 'x-headroom-base-url: http://127.0.0.1' http://localhost:PORT