10 - Server-Side Request Forgery (SSRF)

https://owasp.org/Top10/A10_2021-Server-Side_Request_Forgery_%28SSRF%29/

개요

OWASP Top 10 2021 중 10위로 올라간 Server-Side Request Forgery (SSRF) (서버 측 요청 위조) 이다.

• 발생 빈도는 낮은 편이지만, 탐지 및 대응 수단이 상대적으로 잘 갖춰지지 않아 공격 난이도와 피해 규모가 커 위험성이 높은 취약점이다.

SSRF란?

• 서버가 의도하지 않은 곳으로 요청을 보내도록 속이는 공격이다.
• 웹 애플리케이션이 사용자가 입력한 URL 또는 리소스 위치를 검증 없이 그대로 요청할 때 발생한다. 공격자는 이를 악용하여 내부 또는 외부의 의도치 않은 대상에 요청을 보낼 수 있다.
• 방화벽, VPN 등으로 보호되던 시스템도 SSRF 공격을 통해 우회될 수 있으며, 취약점의 심각성은 클라우드 서비스와 복잡한 인프라가 확산됨에 따라 커지고 있다.
• 최신 웹 애플리케이션은 사용자의 편리한 기능을 제공하고자 URL 입력이 일반적인 상황이 되었다. 이로 인해 SSRF 발생률이 증가하고 있다.

공격 시나리오 예시

• SSRF를 이용해 웹 앱 방화벽 뒤에 있는 시스템을 포트 스캔하거나, 내부 시스템의 열려있는 포트를 파악할 수 있다.
• /etc/passwd 와 같은 내부 파일에 접근하거나, 클라우드 메타데이터(서버 안에서만 접근 가능한 주소)를 요청해 인스턴스 관련 민감 정보를 탈취할 수 있다.

방지 방법

• 네트워크 계층
  • SSRF로부터 보호하기 위해 리모트 리소스 접근 기능(서버가 외부 주소(URL)에 접근하는 기능)을 분리된 별도 네트워크에서만 수행하도록 구성한다.
  • 방화벽 정책은 기본적으로 '모두 거부'로 설정하고, 꼭 필요한 통신만 예외적으로 허용한다. 또한, 방화벽이 허용/차단한 트래픽을 로그로 남기는 것도 중요하다.(A09 관련)
• 애플리케이션 계층
  • 사용자 입력 데이터는 모두 검증해야 하고, 화이트 리스트(허용할 목록을 미리 정해두고, 목록 외의 입력 데이터는 차단한다.) 기반으로 URL,도메인 등을 제한해야 한다.
  • 외부 또는 사용자 제공 입력을 서버 요청으로 바로 전달하는 동작은 중단하는 것이 안전하다.
  • HTTP 리디렉션 기능(요청한 URL이 다른 URL로 자동 이동하는 기능)은 비활성화 한다.
  • DNS 재바인딩 공격(정상적인 IP로 보이게 해놓고, 도메인 이름을 바꿔서 내부망으로 연겷되게 속이는 공격)이나 TOCTOU (검사 시점부터 사용 시점까지의 시간차 공격) 같은 기법에 철저히 대비해야 한다.
• 중요한 서비스가 돌아가는 프론트엔드 시스템과 다른 보안 관련 시스템은 같은 시스템에서 운영하지 말 것을 권장한다.
• 로컬 트래픽(예:localhost로의 접근)을 제한다.
• 보안 수준을 높히기 위해 VPN 기반의 안전한 환경에서 운영한다.

실습 환경

PortSwigger Web Security Academy - Lab: Basic SSRF against the local server

https://portswigger.net/web-security/ssrf/lab-basic-ssrf-against-localhost

문제 설명

이 랩의 내부 시스템에는 데이터를 가져오는 재고 확인 기능이 있다.
랩을 해결하려면 재고 확인 URL을 변경하여 관리자 인터페이스 http://localhost/admin에 엑세스하고 사용자 carlos를 삭제하시오.

공격 과정 요약

1. 랩에 접속하여 직접 URL창에 /admin을 입력하여 접속하였더니 관리자가 아니라 접속할 수 없다는 것을 알 수 있다.
   

2. 제품을 선택하고 '재고확인'을 클릭한다. Burp Suite에서 '재고확인 버튼 클릭' 요청을 가로채서 Burp Repeater로 보낸다. (Burp Repeater에서는 Proxy에서 잡은 요청을 복사해서 반복적으로 실험이 가능하다.)
   

3. 요청에서 stockApi 파라미터를 찾는다. stockApi는 웹 어플리케이션이 stock 정보를 다른 서버에서 가져오기 위해 사용하는 API주소를 지정하는 파라미터이다.
   문제에서 stockApi의 URL을 변경하여 관리자 인터페이스에 접근하라고 하였으니, stockApi 파라미터의 URL을 관리자 인터페이스인 http://localhost/admin 로 변경한다.

   

4. send를 누르면 Response에 HTML 코드가 뜨는걸 확인할 수 있다. 이를 읽어 사용자를 삭제할 수 있는 URL 정보를 찾는다.

    <div> 
      <span>wiener - </span> 
      <a href="/admin/delete?username=wiener">
        Delete
      </a>
    </div>
    <div>
      <span>carlos - </span>
      <a href="/admin/delete?username=carlos">
        Delete
      </a>
    </div>

   위의 코드에서 carlos의 계정을 삭제하기 위해서는 /admin/delete?username=carlos URL을 사용해야함을 알 수 있다.
5. stockApi 파라미터에 삭제 URL을 넣어서 send 하면 성공적으로 carlos 계정을 삭제할 수 있다.
   
   

발생한 보안 문제

• 사용자가 입력하는 stockApi 파라미터가 검증되지 않았다. 그 결과 localhost와 같은 내부에서만 접근 가능한 리소스에 접근하도록 서버를 속일 수 있었다. 즉, 서버가 공격자의 대리인이 되어 내부 네트워크에 접근이 가능하다.
• /admin은 관리자만 접근 가능하도록 외부 접근을 차단하였지만, SSRF 공격으로 뚫렸기에 유명무실해졌다.

배운 점

• SSRF 공격을 통해 외부 공격자가 내부 네트워크,서비스 등에 접근할 수 있게 된다면, 민감한 데이터 노출, 추가 공격 등으로 이어질 수 있어 위험함을 알게 되었다. 발생 빈도가 낮다고 해서 이에 대한 대비를 늦추면 안된다는 생각이 들었다.
• 사용자가 어떤 내용을 입력할지 모르기에, 신뢰하지 말고 입력 내용을 검증하는 과정은 반드시 필요함을 알게 되었다.
• 보안은 끊임없는 검증과 빈 틈을 만들지 않는게 중요하다고 다시 한번 느끼게 되었다.