변수 하나에 "../../../"를 넣었더니, 서버가 클라우드 내부망 문을 열어줬다

2026-08-31 · ##ssrf ##cloud-metadata ##vimeo ##open-redirect

변수 하나에 ”../../../“를 넣었더니, 서버가 클라우드 내부망 문을 열어줬다

분류: Bugbounty · 웹·서버 · SSRF [정보성]

덱. 2019년, 보안 연구자 Harsh Jaiswal은 Vimeo의 API 콘솔이 서버 쪽에서 대신 요청을 보내주는 기능을 분석하다가, URL 경로의 일부로 취급되는 파라미터에 경로 순회(path traversal) 문자열을 넣을 수 있다는 걸 발견했습니다. 이 결함은 오픈 리다이렉트와 이어 붙여져 서버 쪽 요청 위조(SSRF)로 이어졌고, 최종적으로는 Vimeo가 올라가 있던 클라우드 인프라의 메타데이터 서비스까지 건드릴 수 있는 수준까지 갔습니다. 원문에 따르면 초기 임시 조치 보상 100달러에 이어 영구 수정 확인 후 4,900달러가 추가 지급돼, 합계 5,000달러가 지급됐습니다.

리드

서버가 사용자 대신 다른 곳에 요청을 보내주는 기능은 어디에나 있습니다. 미리보기 생성, 웹훅 검증, 외부 API 프록시 같은 것들입니다. 문제는 “어디로 보낼지”를 결정하는 값의 일부라도 사용자가 조작할 수 있을 때 시작됩니다. 서버가 요청을 보낼 대상을 화이트리스트로 제한했다고 안심해도, 그 제한이 URL 구조 전체가 아니라 특정 파라미터 하나에만 걸려 있다면, 그 파라미터를 경유해 제한을 우회하는 경로가 생깁니다. 이번 사례는 그 경로가 얼마나 멀리까지 이어질 수 있는지(외부 웹 요청에서 시작해 클라우드 인프라 자격 증명까지)를 보여주는 사례입니다.

핵심 사실 요약

Vimeo의 API Playground는 사용자가 입력한 값을 서버 쪽에서 조합해 https://api.vimeo.com/users/{user_id}/videos/{video_id} 같은 형태의 요청을 대신 보내주는 기능이었습니다. 엔드포인트(uri) 자체는 화이트리스트로 막혀 있었지만, user_id·video_id처럼 경로 안에 그대로 삽입되는 변수 값은 검증되지 않았습니다.
연구자는 video_id 자리에 ../../../를 넣어 URL 경로를 위로 거슬러 올라갔습니다. https://api.vimeo.com/users/1122/videos/../../../attacker는 파싱되면서 https://api.vimeo.com/attacker가 됐고, 이 방식으로 원래 화이트리스트에 없던 api.vimeo.com의 다른 엔드포인트에까지 도달할 수 있었습니다.
다음 문제는 “여전히 api.vimeo.com 안에 갇혀 있다”는 것이었습니다. 연구자는 이 요청 기능이 HTTP 30x 리다이렉트를 그대로 따라간다는 걸 확인하고, api.vimeo.com에서 vimeo.com으로 리다이렉트시키는 엔드포인트를 콘텐츠 탐색으로 찾아냈습니다. 그리고 vimeo.com에는 임의 URL로 리다이렉트되는 별도의 오픈 리다이렉트 결함이 있었습니다.
두 결함을 경로 순회 하나로 이었습니다: video_id에 ../../../m/(오픈 리다이렉트 경로)?url=https://attacker.com을 넣으면, 서버는 이를 api.vimeo.com 내부 리다이렉트 엔드포인트로 해석 → vimeo.com의 오픈 리다이렉트로 재이동 → 최종적으로 공격자 서버로 요청을 보냈습니다. 서버 쪽에서 임의 외부 주소로 요청을 보낼 수 있는 SSRF가 완성된 순간입니다.
Vimeo 인프라가 Google Cloud 위에 있다는 걸 알고 있던 연구자는 곧바로 클라우드 메타데이터 API(metadata.google.internal)를 조준했습니다. 이 엔드포인트는 그 인스턴스가 사용하는 서비스 계정의 접근 토큰을 반환하도록 설계돼 있는데, 원래는 내부 네트워크에서만 호출되는 걸 전제로 합니다. SSRF를 거치면 외부에서도 이 토큰을 받아올 수 있었습니다.
확보한 토큰의 권한 범위(scope)를 확인해 보니 compute(컴퓨트 인스턴스 관리)·logging.write·devstorage.read_write·monitoring이 포함돼 있었습니다. 연구자는 이 토큰으로 인스턴스 메타데이터에 자신의 SSH 공개키를 등록하는 API 호출까지 성공시켜, 컴퓨트 인스턴스 단에서 원격 코드 실행에 준하는 접근 권한을 확보할 수 있음을 증명했습니다. 실제 SSH 포트는 내부망에만 열려 있어 최종 접속까지는 가지 못했다고 원문은 밝히고 있습니다.
연구자에 따르면 이 리포트는 초기 100달러 임시 조치 보상 이후 영구 수정 확인 시점에 4,900달러가 추가로 지급돼 합계 5,000달러가 지급됐습니다(원문 타임라인: 1월 28일 최초 발견·트리아지·임시조치 100달러 → 1월 30~31일 영구 수정 → 2월 1일 4,900달러 추가 지급). ⚠️미확인 — 이 사례는 2019년 공개된 오래된 disclosure로, 이 초안에서 Vimeo·HackerOne 측의 별도 확인 기록을 1차출처로 재검증하지 않았습니다.

짧은 논평

이 사례는 SSRF가 “그냥 서버가 내부 IP에 요청을 보내는 버그” 정도로 끝나지 않는다는 걸 보여줍니다. 클라우드 위에서 도는 서버라면 SSRF의 진짜 종착지는 애플리케이션이 아니라 그 서버가 올라간 인프라 자체의 자격 증명입니다. 메타데이터 엔드포인트가 인증 없이 토큰을 내어준다는 전제 자체가, 애초에 “이 요청은 신뢰할 수 있는 내부에서 왔다”는 가정 위에 서 있기 때문입니다. 경로 순회로 화이트리스트를 뚫는 기법은 저희가 다른 글에서도 짚는 필터 우회의 전형입니다 — 검증이 URL 문자열 자체가 아니라 “파싱 결과가 어디를 가리키는지”를 봐야 하는 이유입니다. 리다이렉트를 그대로 따라가는 서버 쪽 요청 기능은 화이트리스트 하나만으로는 안전을 보장하지 못한다는 것도 함께 남는 교훈입니다.

References / 참고자료

Harsh Jaiswal, “Vimeo SSRF with code execution potential” — 이 글이 재구성한 원 분석. 경로 순회를 통한 SSRF 발견 과정과 클라우드 메타데이터 익스플로잇을 다룸. https://infosecwriteups.com/vimeo-ssrf-with-code-execution-potential-68c774ba7c1e

이 글은 위 원 분석을 우리 관점에서 다시 쓰고 짧은 논평을 더한 정보성 초안입니다. 특정 문장·요청 페이로드·스크린샷을 그대로 옮기지 않았으며, 작동하는 재현 절차는 싣지 않았습니다. ⚠️미확인 표시 항목은 발행 전 독립 팩트체크에서 확증·정정되어야 합니다.