Server Side Request Forgery
Server Side Request Forgery, 이하 SSRF는 공격자가 취약한 애플리케이션에서 서버 대신 내부 혹은 외부 리소스에 리퀘스트를 보내게 만드는 웹 취약점이다. 데이터 노출, 내부 시스템에 비허가 접근, 혹은 서비스 중단을 야기할 수 있다.
이 단계에서는 몇 SSRF 예시 공격을 통해 SSRF 취약점을 어떻게 인식하고 어떻게 입력규칙을 우회할지를 알아보자.
SSRF는 OWASP Top 10에 선정될 정도로 자주 일어나는 공격 기법이다
SSRF는 공격자가 선택한 리소스를 추가하고 HTTP 리퀘스트를 조작하는 것을 가능하게 한다.
이 공격이 성공하면 아래 결과가 발생 가능하다.
- 무단 영역 접근
- 고객, 조직 데이터 접근
- 내부 네트워크로 확장 가능
- 토큰, credential 유출
SSRF에는 두 타입이 있는데, 하나는 데이터가 공격자의 화면에 반환되는 레귤러 타입이고, 다른 하나는 공격자의 화면에 반환되지 않는 블라인드 타입이다.
예를 살펴보자
공격자는 website.thm의 웹서버에 예상 리퀘스트를 보내 서버가 수신하도록 요청하고 빨간색 url 부분에 웹사이트가 정보를 얻기 위해 가져올 url을 입력한다.
빨간색 영역은 공격자 마음대로 정할 수 있다.
공격자는 경로 탐색을 통해서 경로를 제어하고 /api/user 페이지에 접근할 수 있다.
website.thm이 ../을 받으면 디렉터리를 상위로 이동해서 리퀘스트의 stock부분을 제거하고 /api/user에 접근하는 리퀘스트를 만든다.
이 공격에서는 리퀘스트가 전송되는 서버의 하위 도메인을 제어한다.
&x=로 끝나는 페이로드는 나머지 경로가 공격자 URL 끝에 추가되는 것을 막고, 파라미터 ?x=로 변환하는데 사용된다.
원래의 리퀘스트에서 공격자는 선택한 서버를 요청하도록 웹서버를 강요할 수 있다.
이렇게 한다면 공격자가 지정한 도메인으로 전송되는 리퀘스트 헤더를 잡을 수 있다.
api.website.thm에 인증된 인증정보나 API Key가 포함될 수도 있다.
http://website.thm서버에 http://server.website.thm/flag?id=9 리퀘스트를 받도록 조작해서 url을 작성해보자.
서버는 내가 보내고 싶은 리퀘스트 뒤에 추가적인 url을 붙여서 받고 있다.
마지막에 &x=을 붙여서 보낸다면 내가 보내고 싶은 url을 보낼 수 있는 것이다.
그렇다면 어떻게 SSRF 취약점을 찾아낼 수 있을까
- url의 파라미터에 전체 url이 입력된 경우
- 입력 양식의 숨겨진 필드가 있는 경우
- hostname만 있는 부분 url이 있는 경우
- 경로만있는 부분 url이 있는 경우
위 예시들은 악용 가능성이 높은 경우이고, 작동하는 페이로드를 찾으려면 여러 시도가 필요하다.
블라인드 SSRF를 사용하는 경우 requestbin.com이나 직접 만든 HTTP 서버, 혹은 Burp Suite의 Collaborator 클라이언트를 이용해서 요청을 모니터링해야 한다.
공격자가 요청을 보내도록 할 수는 있지만, 그 결과가 보이지 않기 때문에 성공했는지 실패했는지를 알기가 어렵기 때문이다.
애플리케이션에 리퀘스트하는 리소스가 특정 규칙을 만족하는지 확인하게 할 수 있다. 블랙리스트(Deny List)와 화이트리스트(Allow List)를 이용하는 것이다.
Deny List
거부 목록이라고도 하는 Deny List는 목록에 등재되거나 특정 패턴과 일치하는 리소스를 제외한 모든 리퀘스트를 허용한다.
다시말해 특정 리소스를 블랙리스트에 등록하는 것이다.
애플리케이션은 민감한 엔드포인트, IP주소 혹은 도메인 등의 public 접근을 막고 다른 위치에 대한 접근은 허용할 수 있다.
특정 엔드포인트 중 하나는 로컬호스트이다.
로컬호스트는 서버 성능 데이터나 민감한 정보가 포함될 수 있기 때문에 127.0.0.1같은 도메인은 목록에 등록한다.
대체 로컬호스트 참조나 로컬호스트 DNS 레코드를 가진 하위 도메인을 사용해서 목록을 우회할 수도 있다. (0, 0.0.0.0, 0000, 127.1, 127...*, ...)
또 클라우드 환경에서 배포된 서버의 메타데이터가 포함된 IP주소에 대한 접근은 차단하는 것이 좋다.
공격자는 169.254.169.254를 가리키는 DNS 레코드를 사용해 자신의 도메인에 하위 도메인을 등록해 우회할 수 있기 때문이다.
Allow List
허용 목록인 Allow List는 특정 패턴과 일치하지 않는 모든 요청을 거부한다.
파라미터에 url이 사용된다면 "모든 url 파라미터는 반드시 http://website.thm으로 시작한다"라는 규칙을 만들 수 있다.
해서 http://website.thm.attackers-domain.thm과 같은 하위 도메인을 생성한다면 위 규칙을 우회할 수 있다.
Open Redirect
오픈 리다이렉션은 웹 사이트 방문자를 다른 웹 사이트 주소로 자동 리다이렉션하는 서버의 엔드포인트이다.
예를 들어http://website.thm/link?url=https://tryhackme.com이라는 링크는 광고나 마케팅을 위해서 클릭 수를 집계하는데 쓰인다.
website.thm이 자동으로 https://tryhackme.com으로 보내주는 것이다.
그런데 이 url규칙은 엄격하지만 SSRF 취약점이 있다고 가정한다면 공격자가 원하는 url로 리퀘스트를 날릴 수 있다.
https://website.thm/fetch?url=https://website.thm/link?url=http://attacker.com과 같이 서버의 규칙에 따르지만 결국 http://attacker.com으로 리퀘스트를 날리게 되는 것이다.
