[Bugbounty Study] #Dropbox _ SSRF

# SSRF (Server Side Request Forgery) _ \$4,913

medium.com/techfenix/ssrf-server-side-request-forgery-worth-4913-my-highest-bounty-ever-7d733bb368cb

SSRF (Server Side Request Forgery) worth $4,913 | My Highest Bounty Ever !

SSRF란?
Server-Side Request Forgery의 약자로 Server Side에서 이루어지는 요청을 변조해 공격자의 의도대로 요청 자체를 변경할 수 있는 공격

정상적인 흐름 : A 사이트에 이미지가 출력될 때, 해당 이미지는 B 사이트에서 응답받아 보여준다.
SSRF 공격 : 이미지 데이터를 받기 위한 B 사이트로의 요청을 중요 정보를 다루는 내부 서버로의 요청으로 조작하여 중요한 데이터를 출력하여 얻을 수 있다.

[예방 방법]
- 사용자 입력 값 검증
- 화이트리스트 방식의 필터링

[참고]
- https://medium.com/naver-cloud-platform/ssrf-공격의-피해-사례와-대응-1-d0be4b12d10a
- https://medium.com/naver-cloud-platform/ssrf공격의-피해-사례와-대응-2-883d08eeb8bb

 

원작자의 말에 의하면, Dropbox Bug Bounty Program이 괜찮다고 한다. (빠른 응답, 괜찮은 보상)

 

그래서 Dropbox Bug Bounty Program의 대상 중 하나인 HelloSign을 타겟으로 삼았고,

메인인 app.hellosign.com의 버그 헌팅을 시작하였다.

 

해당 사이트에는 Dropbox, GDrive, BOX, OneDrive, EverNote의 문서를 import 시키는 기능이 있는데,

이 부분에서 SSRF가 발생할 것이라고 거의 확신한 채로 살펴보았다.

 

Dropbox Import request의 file_reference 파라미터를 변경하였더니 404 페이지를 얻었고,

이를 보면 해당 포인트가 SSRF 보호 기법이 적용되어 있다고 추측할 수 있다.

 

OneDrive Import request를 살펴보니 아래와 같았다.

 

GET /attachment/externalFile?service_type=O&file_reference=MYONEDRIVEFILELINKHERE&file_name=FILENAME.ANYTHING&c=0.8261955039214062 HTTP/1.1
Host: app.hellosign.com
Connection: close
Accept: application/json
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.111 Safari/537.36
X-CSRF-Token:
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: REDACTED
Accept-Encoding: gzip, deflate
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8,hi;q=0.7
Cookie:REDACTED

 

OneDrive request의 service_type=O이고, Dropbox request의 service_type=D으로 두 요청은 다르다.

따라서, OneDrive request의 file_reference 파라미터를 원작자의 링크로 변경하였더니, ping을 받았다.

이후, HelloSign을 통해 원작자의 페이지의 내용을 포함한 PDF를 생성하였다.

(이는 SSRF 공격이 가능하다는 것을 의미한다.)

 

SSRF 공격을 이용하여 중요 데이터를 얻기 위해 아래와 같은 방법을 시도하였다.

 

- localhost 자료를 얻기 위해 whatismyipaddress.com 를 이용 클라우드 서비스 탐색
- AWS/EC2 사용하고 있는 것 발견
- http://169.254.169.254/latest/ 데이터 얻기 시도 (404)
- http://127.0.0.1 데이터 얻기 시도 (404)

 

공격을 성공시키기 위해 다른 방법을 찾아보았고,

Hackerone Hacktivity의 한 리포트에서 303 Redirect를 이용한 SSRF 보호 기법 우회 방법*을 알게 되었다.

[참고] https://hackerone.com/reports/247680

 

원작자는 본인의 서버에 아래 코드를 호스팅 하였고,

 

<?php header('Location: http://169.254.169.254/latest/meta-data/', TRUE, 303); ?>

 

access_keys, tokens 등 민감한 정보를 포함한 AWS Instance (Metadata)를 얻는 데 성공하였다.

 

---

HTTP Redirect를 이용한 SSRF 보호 기법 우회 방법*

HTTP Redirect 란, A URL로 요청하였을때, 3xx의 응답메세지 및 Location 등 헤더 등에 명시된 B URL로 요청하는 것이다. 해당 방법은 SSRF 보호 방법으로 Redirect 처리를 하지 않은 채로 URL 패턴이나 도메인 정보를 검증할 때, 우회할 수 있는 방법이다.

 

예를 들어,

타겟 서버에서 공격자의 서버로 요청은 가능하나, 내부 서버로의 요청이 불가능한 경우에 내부 데이터를 얻는 방법은 아래와 같다. (내부 서버 URL 패턴이 필터링되어 있다고 가정한다.)

 

- 공격자의 서버에 HTTP Redirect 코드 호스팅
  <?php header('Location: http://127.0.0.1/data'); ?>
- 타겟 서버에서 공격자의 서버로 요청
  (내부 주소가 아니기 때문에 필터링되지 않는다)
- 검증 후 Location 헤더에 의해 http://127.0.0.1/data로 요청
- 내부 페이지에서 정보를 담은 응답

 

[참고]

vickieli.medium.com/bypassing-ssrf-protection-e111ae70727b

Bypassing SSRF Protection

www.hahwul.com/2019/02/22/bypass-ssrf-protection-using-http-redirect/

Bypass SSRF Protection using HTTP Redirect