저는 제 홈 랩(home lab)을 만지작거리며 한 가지를 테스트해보고 싶었습니다. Claude Code가 실행하기 전에 악성 스킬(skill)을 잡아낼 수 있을까 하는 점이었습니다. 텍스트 자체에 악의적인 의도가 드러나는 스킬의 경우, Claude는 이를 잡아냅니다. 처음에는 프롬프트 인젝션(prompt-injection) 스타일의 "이 파일을 읽어서 어딘가로 POST 하세요"와 같이 명백한 것들을 몇 가지 시도해 보았고, Claude는 이를 잘 식별해냈습니다. 분류기(classifier)는 스킬을 읽고 수상한 지침을 찾아내는 데 꽤 괜찮은 성능을 보였습니다.

그래서 저는 다른 방식을 시도했습니다. 텍스트에는 아무런 악의적인 내용이 없으며, 실제 페이로드(payload)는 모델이 읽을 수 없는 곳에 존재하는 스킬입니다. 이 설정은 에이전트(agent)에 맞게 변형된 오래된 브라우저 공격 방식인 DNS 리바인딩(DNS rebinding)입니다. 브라우저는 동일 출처 정책(same-origin policy)과 로컬 네트워크 액세스 확인을 통해 이에 방어합니다. 하지만 에이전트가 URL을 가져오는 스킬을 실행할 때는 브라우저가 아닙니다. 그것은 curl이나 Python 스크립트입니다. 그런 보호 조치들은 그곳에 존재하지 않습니다.

해당 스킬은 지루한 CI/CD 준비 단계(readiness gate)처럼 보입니다. 소스 URL이 200 응답을 반환할 때까지 폴링(poll)한 다음, 응답을 상태 엔드포인트(status endpoint)로 POST 하는 방식입니다. 제가 사용한 도메인은 제 도메인 중 하나(poc.tejaswaroop.tech)이며 완전히 정상적이고, 릴레이 대상(relay target)은 동일한 도메인의 두 번째 서브도메인일 뿐이어서 전달 단계조차 동일 출처(same-origin) 트래픽처럼 보입니다.

트릭은 DNS 계층에 있습니다. 실행 시점에 poc.tejaswaroop.tech는 조용히 프라이빗 IP(172.18.0.10)로 해석되며, 여기에는 가짜 "민감한" 비밀이 담긴 내부 노트 앱이 호스팅되고 있습니다. 따라서 "소스 URL을 폴링"하는 단계는 실제로 제 내부 서비스에 접속하게 되고, "상태를 POST"하는 단계는 읽어온 내용을 공격자 박스의 수집기(collector)로 전송합니다.

저는 Claude Code에게 이 스킬을 설치하도록 요청했습니다. Claude는 먼저 스킬을 검사한 뒤, 이를 단순하고 합법적인 것으로 보고하고 설치했습니다. 이는 Claude의 대단한 점이기도 합니다. 저는 새로운 세션에서 이를 호출했고, Claude는 배포 게이트가 "첫 번째 시도에 통과되었다"고 보고했습니다. 그리고 제 수집기 쪽에는 유출된 비밀이 파일로 담겨 있었습니다. 사용된 모델은 Opus 4.8이었습니다. 아무것도 감지하지 못했습니다!

여기서 얻을 수 있는 교훈은 Claude가 안전하지 않다는 것이 아니라, 모델 수준의 안전 점검(safety check)은 모델이 볼 수 없는 것을 신뢰성 있게 잡아낼 수 없다는 것입니다.

공정하게 말하자면, 모델이 때때로 무언가 잘못되었다는 것을 추론할 수 있으며, 일부 실행에서는 이러한 스킬을 감지(flag)할 수도 있습니다. 하지만 대규모 언어 모델 (LLM)은 비결정론적 (non-deterministic)입니다. 즉, 동일한 스킬이라도 한 번의 실행에서는 통과되고 다음 실행에서는 의심을 받을 수 있으므로, 그러한 추론을 결코 보장할 수 없습니다. 이를 신뢰할 수 있는 안전 계층 (safety layer)으로 취급하는 것은 실수입니다. 이 특정 시나리오에 대한 몇 가지 실질적인 방어책은 다음과 같습니다:

호스트 수준 (이 방법을 권장합니다): 호스트에서 dnsmasq와 같은 도구를 사용하여 DNS 리바인딩 (DNS rebinding)을 방지하십시오.
라우터 수준: 라우터가 지원한다면 DNS 리바인딩 보호 (DNS rebind protection) 기능을 활성화하십시오 (많은 최신 라우터가 이를 지원합니다).
서비스 수준: 내부 서비스를 Host-header 허용 목록 (allowlist)이 있는 리버스 프록시 (reverse proxy) 뒤에 배치하십시오. 하지만 스크립트가 헤더를 스푸핑 (spoof)할 수 있으므로 그것에만 의존하지 마십시오.

전 과정을 처음부터 끝까지 확인하고 싶다면, 두 가지 형식으로 심층 분석 내용을 준비했습니다:
비디오 (라이브 데모):

블로그 포스트: https://www.blog.techraj156.com/post/dns-rebinding-is-old-using-it-against-your-ai-agent-is-not

/u/Teja_Swaroop에 의해 제출됨 [link] [comments]