SSRF - Lab (5)

Bypassing SSRF filters via open redirection

이번에 살펴볼 SSRF attack은 redirection을 활용한 공격이다.

어떤 종류의 필터이든지 간에 open redirection 취약점을 악용함으로써 필터 기반의 방어가 때때로 우회될 수 있다고 한다.

 

앞에서 살펴본 Lab에서 stockApi를 사용하는 걸 볼 수 있었다.

stockApi는 사용자의 요청을 처리하기 위해서 한 서버가 시스템 내부의 또 다른 서버에게 보내는 요청이라 생각하면 된다. 

 

filter를 사용하더라도 백엔드 시스템 내에서 보내는 http requets가 redirection을 허용한다면 

filter는 우회될 수 있다. 

 

/product/nextProduct?currentProductId=6&path=http://evil-user.net

예를 들어 현재 상품 페이지에서 다음 상품 페이지로 이동하는 request에 대해 

path parameter를 위와 같이 조작한다면 

 

http://evil-user.net

다음 상품이 아닌 http://evil-user.net 주소로 redirection 된다.  

 

이처럼 filter가 적용된다 하더라도 redirection 기능까지 통제하지는 못하기 때문에 

공격자가 원하는 경로로 redirection 되도록 API 값을 악용할 수 있다. 

 

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://weliketoshop.net/product/nextProduct?currentProductId=6&path=http://192.168.0.68/admin

API 값으로 들어온 url이 허용되는 도메인을 포함하는 검사한 다음에 url로

백엔드 request가 처리되면서 redirection이 일어나게 된다. 

 

위의 값을 토대로 보자면 post request가 처리된 결과, 192.168.0.68이라는 내부 경로로 이동하게 되는 것!

 

---

** POST Method로 만들어진 packet은 사용자의 요청에 따라 재고를 확인하기 위해 전송된 packet이다.

(client → server)

 

그 안에 작성된 stockApi는 사용자의 요청을 처리하는 과정에서 필요한 데이터(상품 재고)를 

얻기 위해 서버 측 시스템 내부에서 동작할 내용을 작성한 값이다. (server → server)

 

즉 서버가 서버에게 보내는 요청으로 server side request인데 

이를 공격자가 위조함으로써 정보를 빼내거나 어떤 기능을 실행시키는 등 악용하는 것이기 때문에 

server side reqeust forgery인 것이다. 

 

 

Lab - SSRF with filter bypass via open redirection vulnerability

이번 Lab의 목표를 먼저 정리해보자!

:) carlos 계정을 삭제하는 것이 최종 목표

:) filter를 우회하기 위해 redirection 취약점을 이용할 것

:) admin panel은 192.168.0.12:8080 경로로 접근할 수 있음

 

원하는 경로로 접근하기 위해서는 값을 어떻게 위조할 지에 대해 생각해봐야 한다. 

일단 Lab에 들어가 아이템을 하나 클릭해보면 

하단 좌측에 재고를 확인하는 버튼과 하단 우측에 return to list | nest product 버튼이 보인다.

 

 

아마 next product 버튼을 누르면 이동할 경로 값이 parameter로 전달될 거 같아 확인해 보니

다음 상품의 아이디와 경로가 parameter로 전달되는 GET request가 만들어지는 걸 알 수 있다. 

여기서의 path parameter를 이용해 경로를 설정하면 될 거 같다. 

 

 

위에서 설명했듯이 packet header 정보와 stockAPI는 사용되는 목적이 다른 값이다.

 

GET Method에 path를 조작해서 보낸다고 하더라도 이는 client가 server에게 요청하는 값으로 전달되기 때문에

서버 입장에서는 외부 사용자가 내부 주소로 접근하고자 하는 행위로 해석할 것이다.

 

따라서 SSRF 공격을 수행하기 위해서는 stockAPI 값을 위조해야 한다.

 

재고 확인 버튼을 눌러보면 stockApi가 사용되는 packet을 얻을 수 있다.

작성된 내용은 "/produect/stock/check?productId=2&storeId=1"

 

사용자가 재고를 확인해 줘!라고 버튼을 누르면 서버 내부에서는 상품 & 상점 ID로 재고를 확인하는 듯하다. 

 

next product 버튼을 눌렀을 때 얻은 값에 path를 수정해서 넣어줬다.

 

과연 결과는..?!?!

 

왜인지 모르겠지만 원하는 결과가 나오지 않은 건 확실하다.

그래서 currentProductId 값을 제외하고 path 값만 넣어보았다.

 

접근하고자 하는 경로는 http://192.168.0.12:8080/admin

 

 

이번엔 성공적으로 admin panel page를 출력했다!!

이젠 Lab의 목표대로 carlos 계정을 삭제해 보자.

 

출력된 페이지에서 carlos - Delete 버튼을 누르면 어떤 url을 작성해야 하는지 얻을 수 있을 것이다.

이전 Lab에서 이미 했기 때문에 여기서는 패-스

 

carlos 계정을 삭제하라는 url을 만들어 보내면

 

결과적으로 carlos 계정이 삭제된 걸 볼 수 있다.