Burp Suite: Server-side vulnerabilities (Part 3): SSRF

SSRF(서버 측 공격 위조): Server-side request forgery는 웹보안 취약점 중 하나로, 공격자가 서버 측 앱이 의도하지 않은 위치로 요청을 보낼 수 있게 할 수 있다.

 

일반적으로 SSRF 공격에서는 조직 내부의 내부 전용 서비스에도 연결을 시도하게 만들 수 있다. (매우 치명적) 서버가 임의의 외부 시스템에 연결하도록 연결할 수도 있다. 이런 공격으로 Authorization credentials, 인증 정보 같은 민감한 데이터 유출도 가능

 

제일 흔한 공격이 application이 자기 자신, 즉 서버 내부에 http 요청을 보내도록 유도하는 것. 이때 loopback network interface를 활용한다. 루프백 주소는 127.0.0.1 (localhost)

 

예시로는 쇼핑몰 웹사이트의 재고 확인 기능을 제시했다.

서버가 백엔드 REST API에 재고 정보를 요청함으로써 동작하는데, 클라이언트와 아래와 같은 요청을 보냈다고 한다. 

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

stockApi=http://stock.weliketoshop.net:8080/product/stock/check%3FproductId%3D6%26storeId%3D1

 

위 URL에 요청을 보내고 응답을 받으면 사용자한테 재고 상태를 보여준다.

 

stockApi=http://stock.weliketoshop.net:8080/product/stock/check?productId=6&storeId=1 이건 POST /product/stock이 서버의 /product/stock 주소에 POST 방식으로 요청을 보내고, stockApi라는 파라미터를 보내고 있음. stockAPI라는 이름의 값을 이 주소로 줘!

 

근데 이때 공격자가 URL을 내부 주소로 바꾸면 어떻게 될까?

 

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118
stockApi=http://localhost/admin

 

stockApi를 localhost/admin으로 요청을 보냈다고 해보자. 이 응답은 공격자에게 그대로 반환될 것이다. 원래 admin 페이지는 관리자만 접근할 수 있어서 공격자가 직접 url을 입력해서 접속하면 접근이 안될 수 있어도 이 요청이 '서버 내부, localhost'에서 발생하면 애플리케이션이 이를 신뢰된 요청으로 간주해 인증 없이 관리자 기능을 노출 시킬 수 있게 된다!

 

여기서 잠깐.. REST API란..

REST는 API를 만들 때 자주 쓰는 설계 원칙 중 하나로 HTTP(웹 통신)의 기본 기능을 활용해서 아래와 같이 구성한다.

데이터 가져오기	GET	/product/1 (1번 상품 보여줘)
데이터 생성하기	POST	/product (새 상품 추가해줘)
데이터 수정하기	PUT	/product/1 (1번 상품 수정해줘)
데이터 삭제하기	DELETE	/product/1 (1번 상품 삭제해줘)

 

즉, REST API는 URL로 자원을 표현하고, GET, POST, PUT, DELETE 같은 메서드로 그 자원에 작업을 요청하는 방식

이런 내부에서 발생한 요청을 암묵적으로 신뢰하는 이유는 접근제어 검사가 애플리케이션 서버 앞단에 위치한 다른 구성요소에 구현되어 있을 수 있는데 이때 서버로 다시 연결이 이뤄지면 이 검사를 우회할 수도 있다. 또는 재난 복구 목적으로 애플리케이션은 서버 자체에서 접근하는 사용자에게는 로그인 없이 관리자 접근을 허용하도록 설계되어 있을 수도 있는데 이때 관리자가 자격 증명을 잃어버렸을 때 시스템을 복구할 수 있는 방법을 제공한다 (이때 시스템은 서버에서 직접 오는 요청이 완전히 신뢰할 수 있다고 가정함) 관리자 인터페이스는 메인 애플리케이션과는 다른 포트 번호에서 동작할 수 있고 일반 사용자들은 이 포트에 직접 접근할 수 없을 수도 있다.

 

>> 설명

1. 접근 제어가 프론트단에서만 이뤄지는 경우

애플리케이션 앞에 Reverse proxy나 WAF 같은 별도 구성요소가 접근 제어를 담당할 수 있다. 이 경우 애플리케이션 서버로 직접 연결이 발생하면 이 접근제어가 우회된다. 

2. DR을 위한 예외 처리

어떤 시스템은 비상 상황을 대비해 로컬에서 접근한 관리자 요청은 로그인 없이 허용하는 예외 규칙을 둘 수 있다. 관리자 계정이 잠겼을 때도 시스템 복구를 가능하게 하려는 목적으로 이때 시스템은 로컬에서 접속한 사용자는 무조건 신뢰한다!라고 가정함. 

3. 관리자 페이지가 별도 포트로 열려 있는 경우

일반 사용자는 접속 못하게 관리자 인터페이스를 8080이나 8443 같이 별도 포트로 열어두는 경우가 많음. 이 포트는 외부 네트워크에서 접근할 수 없게 차단되어 있으나 SSRF를 이용해 서버 자신이 내부 포트로 요청을 보내면 접근이 가능해짐. 

 

>> 8080, 8443 포트는 반드시 관리자 인터페이스용은 아니지만, 현업에서 관리자 페이지 또는 내부 백엔드 서버용으로 자주 쓰이는 포트라고 한다. 기본 포트(80/443)는 외부 노출되기 쉬우니 8080, 8443 같은 포트를 쓰면 일반 사용자 접근을 어렵게 할 수 있음
그리고 포트 기반 방화벽 설정이 용이함. 예: “8080 포트는 로컬 또는 VPN에서만 허용”, “8443은 사내망에서만 허용”
또는 개발·운영 분리 용도로도 쓰임 80/443은 사용자용, 8080/8443은 운영자/백오피스용으로 분리

예)

 

• http://example.com:8080/admin
  → 관리자 UI 접속
• https://192.168.0.10:8443/monitoring
  → 내부 IP + 보안 포트 → 서버 상태 모니터링 툴
• Spring Boot, Tomcat, Jenkins 등도 기본 HTTP 포트로 8080을 사용

 

실습

이 실습에서는 내부 시스템에서 데이터를 가져오는 재고 확인 기능이 있음. 재고 확인 요청의 URL을 http://localhost/admin으로 변경해서 관리자 페이지에 접근한 뒤, carlos라는 사용자를 삭제하는 것이 목표다.

 

/admin 페이지로 이동했더니 다음과 같은 오류가 뜬다.

 

 

 

product를 아무거나 눌러보면 아래에 check stock 버튼이있는데 이걸 눌러보자

 

burp suite 으로 캡처했을때는 다음과 같이 뜬다.

stockApi로 url 정보를 보내고 있다.

따로 url 인코딩안하고 그대로 넣어봤다.

 

성공!

 

대신 여기서 그냥 delete를 눌러버리면, 

이렇게 오류가 뜬다. delete user 에 대한 url 정보를 얻을 수 있으니..

http://localhost/admin/delete?username=carlos

 

다시 재공격하면 성공했다는 문구가 뜬다.

 

내부 백엔드 시스템을 노리는 SSRF 공격

사용자가 직접 접근할 수 없는 백엔드 시스템과 통신도 가능하다. 이런 시스템들은 보통 라우팅이 불가능한 사설 IP 주소(192.168.X.X)를 사용한다. 백엔드 시스템들은 네트워크 구조(토폴로지)에 의해 보호되고 있어 보안 설정이 상대적으로 느슨한 경우가 많다. 이런 내부 시스템들은 인증 없이도 접속 가능한 민감한 기능을 포함하고 있으며 해당 시스템과 통신할 수 있는 누구라도 이를 이용할 수 있게 된다. 

 

https://192.168.0.68/admin 주소와 같은 관리자 페이지가 존재한다고 가정해보자. 

 

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118
stockApi=http://192.168.0.68/admin

 

이렇게 공격이 가능해짐. 내부 네트워크 안의 ADMIN 페이지에 HTTP 요청을 보내는 것! 원래는 당연히 접근이 안되는 내부 관리 페이지를 이런식으로 우회해 열람하거나 조작이 가능해진다. 

 

실습

192.168.0.X 대역 내부 IP를 스캔해보자. 포트는 8080, Carlos 계정을 삭제하는 것이 목표다.

순서는 아까처럼 product에 들어가서 check stock을 클릭한 다음 해당 요청을 intruder로 보낸다. stockApi 파라미터는  http://192.168.0.1:8080/admin 로 바꿔주고, ip 어드레스의 마지막 octet 부분을 highlight 해서 add § 해준다.

payload 타입은 numbers로, options는 다음과 같이 1에서 255까지로 설정한다. step은 1로, 1씩 증가하면서 공격할 수 있게 설정함.

 

11의 크기가 조금 다르다. status code도 200으로 OK다.

 

Repeater로 보내보니 302 found 상태코드가 뜬다, proxy로 보내봤더니 문제가 풀렸다.

 

이 실습을 하고 나니까 이제서야 burp suite이 좀 익숙해지는 거 같다..