🇰🇷 한글 설명
Dify 1.15.0 이전 버전에는 인증된 콘솔 사용자가 SSRF 보호를 우회해 내부 서비스와 클라우드 메타데이터 엔드포인트에 임의의 HTTP 요청을 보낼 수 있는 취약점이 있습니다. Squid 프록시 설정이 출처(source) ACL만 정의하고 목적지 차단 규칙이 없으며, make_request() 함수가 목적지 IP를 독립적으로 검증하지 않기 때문입니다.
💡 쉬운 설명
로그인한 사용자가 Dify 서버를 중계기처럼 써서 회사 내부 시스템에 몰래 접근할 수 있는 문제입니다. 클라우드 서버라면 인증 정보까지 빼갈 수 있어 위험합니다.
🇺🇸 원문 (English)
Dify before 1.15.0 contains a server-side request forgery vulnerability that allows any authenticated console user to bypass SSRF protections and issue arbitrary HTTP requests to internal services and cloud metadata endpoints due to the Squid proxy configuration only defining source ACLs without destination deny rules and the make_request() helper performing no independent destination IP validation. Attackers can use endpoints such as GET /console/api/remote-files/<url>, POST /console/api/remote-files/upload, the HTTP Request workflow node, website crawl, or document import from URL to reach internal components like the sandbox, internal APIs, and PostgreSQL, and on AWS deployments read IAM credentials from the instance metadata service, with the HTTP Request node further enabling POST, PUT, and DELETE writes to internal services relying on network isolation for authorization.
📍 영향받는 시스템
Dify 1.15.0 미만 버전 (AWS 등 클라우드 배포 환경에서 특히 위험)
⚔️ 공격 벡터
인증된 콘솔 사용자가 remote-files, HTTP Request 노드, 웹사이트 크롤링 등을 이용해 내부 IP나 169.254.169.254 메타데이터 주소로 요청을 보냄
🛡️ 대응 방법
Dify를 1.15.0 이상으로 업그레이드하고, 프록시에 내부 대역 대상 목적지 차단 규칙을 추가
🔧 검증 코드
출력된 이미지 태그나 패키지 버전이 1.15.0 미만이면 취약한 것이며, 결과가 없으면 이 호스트에 Dify가 설치되어 있지 않은 것입니다.
docker images --format '{{.Repository}}:{{.Tag}}' 2>/dev/null | grep -i dify; dpkg -l 2>/dev/null | grep -i dify; grep -rhoE 'version[^0-9]*[0-9]+\.[0-9]+\.[0-9]+' /opt/dify /srv/dify 2>/dev/null | head -n 3