"서버를 속여 공격한다" SSRF 공격의 동작 방식과 대처법

서버 측 요청 위조(Server-Side Request Forgery, SSRF) 공격은 공격자가 서버를 속여 무단 요청을 보내도록 유도하는 수법이다. 공격 이름으로 짐작할 수 있듯, 원래 서버가 하는 요청을 공격자가 위조하는 것을 의미한다.
 

SSRF 공격의 정의

SSRF 공격은 사이트 간 요청 위조(Cross-Site Request Forgery, CSRF) 공격보다 훨씬 더 위험하다. CSRF 공격은 공격자가 사용자의 웹 브라우저를 하이재킹해 사용자를 대신해 무단 작업을 수행하는 방식이다. CSRF의 악의적인 활동은 클라이언트 측에서 진행되는데, 클라이언트는 일반적으로 개별 사용자 또는 공격 대상이 된 이들의 자산이다. 물론 공격을 받는 사람에게 웹 애플리케이션에 대한 관리자 권한이 있다면 전체 애플리케이션이 침해될 수 있으므로 CSRF도 위험해질 수 있다. 

반면 SSRF 공격은 중간에 사용자를 개입시킬 필요 없이 웹 서버 자체를 노린다. 공격자는 악성 HTTP 요청을 서버에 보내는 것만으로 백엔드에 지시해 악성 작업을 수행할 수 있다.

2019년 미국과 캐나다에 걸쳐 약 1억 600만 명의 사용자에게 영향을 미친 캐피털 원(Capital One) 데이터 침해 사건의 시작은 SSRF 취약점 악용이었다. 이때 침해된 데이터는 고객 이름, 주소, 연락처 정보, 생년월일, 미국 사회보장번호(SSN), 캐나다 사회보험번호(SIN), 신용 점수, 결제 내역, 자진 신고 수입 금액 등이었다. 

클라우드플레어(Cloudflare)의 에반 존슨을 포함한 많은 사이버보안 전문가가 이 사고를 SSRF 공격으로 규정했다. 2021년 3월에 공개된 마이크로소프트 익스체인지 제로 데이(CVE-2021-26855)와 최근 발견된 프록시셸(ProxyShell) 익스플로잇 모두 활발하게 악용되고 있는데, SSRF에 대한 결함이 그 원인이다.

SSRF의 공격 방식 

방문자가 웹 서버에 요청하거나 하이퍼링크를 클릭하면 방문자에게는 공개된 파일, 즉 public_html이나 www 폴더에 있는 파일이 제공된다. 비공개 폴더 또는 데이터베이스에 있는 파일은 일반적으로 서버 관리자와 같이 더 높은 권한이 있는 사람만 접근하도록 제한된다.

그러나 웹을 서핑하는 일반 사용자가 직접 접근할 수 있는 파일과 자산을 서버 자체가 접근할 수 있다. 예를 들어 방문자는 https://www.csoonline.com/uk/events와 같은 공개 URL을 손쉽게 요청할 수 있지만 '/etc/shadow' 또는 '/etc/passwd'와 같은 CSO 서버의 민감한 시스템 파일은 요청할 수 없다. 웹 서버는 이런 파일에 접근할 수 있을 가능성이 높다.

기본적인, 또는 논블라인드 SSRF

취약한 환경의 서버에서 실행되는 웹 애플리케이션도 이와 같은 파일에 대한 접근 권한을 가진 경우가 있다. 모든 SSRF 공격의 기본은 공개적으로 접근 가능한 웹 서버가 최종 사용자에게 속아 해당 서버에 있는 민감한 파일, 또는 원래 최종 사용자 접근이 제한되어야 할 시스템이나 작업에 대한 접근 권한을 제공할 수 있다는 데 착안한다.

예를 들어 shop.example.com의 취약한 전자상거래 사이트를 살펴보자. 이 사이트에서는 8개의 서버를 사용한다. 사용자는 shop.example.com을 방문해 상품을 둘러볼 수 있지만 제품 상세 정보는 다른 서버에 위치한다. 사용자에게는 서버에 직접 접근할 권한이 없지만 shop.example.com 서버에는 그 서버에 접근할 권한이 있다고 가정해 보자.

즉, 상품을 클릭하면 상점의 주 서버가 두 번째 요청을 보낸다. 간단히 설명하기 위해 다음과 같이 브라우저 주소 표시줄에 보이는 URL을 사용한 단순한 GET 요청이라고 가정하자. shop.example.com/?url=shop-server-2.example.com/product555/

이 URL로 이동하면 상품 #555에 대한 상세 정보가 제공된다. 만일 공격자가 자신은 http://shop-server-2.example.com/product555/에 직접 접근할 수 없지만 shop.example.com은 할 수 있다는 사실을 알고 있다면 상점의 주 서버를 중간 지대로 사용할 수단을 확보하는 셈이다. 이 웹 서버를 악용해 접근이 제한된 자산과 파일에 대한 접근 권한을 손에 넣을 가능성이 있다.

shop.example.com의 보안이 미흡하고 SSRF에 취약하다면 공격자는 간단히 shop.example.com/?url=file:///etc/passwd로 이동할 수 있고, 보호 수단이 갖춰져 있지 않은 취약한 서버는 민감한 /etc/passwd 파일의 내용을 반환할 가능성이 높다. 공격자의 목표가 무엇인지에 따라 이 URL을 수정해 localhost나 내부 IP 주소, 사용자 지정 포트 번호 등을 URL에 포함할 수도 있다.

이는 가능한 많은 SSRF 공격의 기본적인 예시 가운데 하나일 뿐이다. 앞서 설명한 시나리오는 공격자가 악의적 요청을 하고 그 결과 서버가 반환되는 데이터가 노출되는 '기초적인' 또는 논블라인드(non-blind) 방식의 SSRF를 보여준다. 이런 공격은 기밀 파일 및 자산에서 데이터를 빼내거나 특정 시스템 포트가 열려 있고 서비스를 실행 중인지 여부를 확인하고자 하는 위협 행위자에게 매우 효과적이다.

블라인드 SSRF

반면 블라인드(Blind) SSRF 공격은 반드시 데이터를 반환하는 것은 아니며, 그 대신 서버 백엔드에 무단 작업을 수행하는데 초점을 둔다. 블라인드 SSRF 공격에서 공격자는 데이터 유출보다는 예를 들어 서버의 무언가를 변경하거나, 파일을 수정 또는 삭제하거나 권한을 바꾸거나 그 외의 다양한 무단 작업을 실행하는데 초점을 두고 있다.

앞의 예시에서 URL을 수정해 shop.example.com/?url=http://example.com/some-very-large-file.png로 이동하도록 했다고 가정해 보자. 여기서 서버는 외부 서버에서 비정상적으로 용량이 큰 파일을 가져오기 위해 계속 시도한다. 이 요청은 shop.example.com의 웹 서버를 멈추게 하고 서비스 거부(DoS)로 이어질 수 있다. 가시적인 응답이나 데이터를 끌어내는 것이 아니라 서버를 대신해 유해한 작업을 수행하는데 초점을 둔다는 점에서 이 유형의 SSRF 공격을 '블라인드' SSRF라고 한다.

SSRF 취약점을 완화하는 방법

SSRF 결함을 완화하는 기본적인 방법은 내부 애플리케이션과 접촉하는 입력에 대해 사용자가 영향을 미치지 못하도록 하는 것이다. 내부 애플리케이션은 무조건적으로 입력을 신뢰하거나 정상적인 사용자로부터의 입력이라고 가정해서는 안 된다.

예를 들어 앞의 shop.example.com 예에서 애초에 서버가 file:/// URL을 수락할 이유가 없다. ftp:// 또는 slack:이나 skype:와 같은 애플리케이션별 URI 체계도 마찬가지다. 시스템은 HTTP 및 HTTPS와 같은 극소수의 프로토콜만으로 제한돼야 한다. 예시에서 나온 작업이 필요하다면 내부 서버에 대한 URL 매개변수를 클라이언트 측에서 전달하지 않아도 되는 더 나은 방법이 있다.

상품 번호만 전달하고(shop.example.com/?product=555) shop.example.com의 백엔드가 다른 서버, 백엔드에 하드코딩된 주소에서 상품 555의 상세 정보를 가져오도록 하는 방법이 있다. 이 방법을 실행하기에 앞서 숫자로 된 '상품' 매개변수에 대한 위생 조치를 수행하고 악성 데이터가 없는지 확인해야 한다.

두 번째로, 프로그램의 로직을 수정할 수 없고 URL이 절대적으로 필요하다면, 얼로우리스트(Allowlist)와 디나이리스트(denylist)가 해법이 된다. 예를 들어 오쓰(OAuth) 기반 로그인을 구현하는 일부 애플리케이션은 다른 URL 매개변수와 함께 요청 간에 '리디렉션(redirect) URL'을 제출하며 SSRF에 취약한 것으로 확인됐다.

얼로우리스트 또는 화이트리스팅(Whitelisting) 방식은 프로그램이 허용된 객체, 또는 이 예시의 경우 특정 위치에서만 접근을 허용해 프로세스의 보안을 높이므로 더 안전하다. 반면 디나이리스트 방식은 예를 들어 localhost 또는 127.0.0.1과 같이 선택된 특정 위치에 대해서만 접근을 거부하고 나머지는 모두 허용한다. 디나이리스트 방식에서는 교묘한 공격자가 예를 들어 HTTP 리디렉션, 난독화된 URL, DNS 리바인딩 등을 통해 우회로를 찾을 위험이 있고, 서버 관리자가 디나이리스트에 넣어야 할 것을 깜박 잊어 공격자가 이를 악용할 가능성도 현실적으로 존재한다.

대부분의 취약점이 그렇듯이 SSRF 결함도 아무것도 신뢰하지 않는 사고방식을 택해 입력을 검증하고 입력이 최종 사용자에 의해 영향을 받을 가능성을 최소화하면 막을 수 있다. 또한 얼로우리스트를 통해 작업을 위해 절대적으로 필요한 API와 내부 시스템에 대해서만 접근 권한을 부여하는 최소 권한(least privilege) 원칙을 채택하는 것도 SSRF 악용을 줄이는 효과적인 방법이다. editor@itworld.co.kr