보안정보

전문화된 보안 관련 자료, 보안 트렌드를 엿볼 수 있는
차세대 통합보안관리 기업 이글루코퍼레이션 보안정보입니다.

SSRF 취약점을 이용한 공격사례 분석 및 대응방안

2022.12.06

2,790

01. SSRF 개요

서버 측에서 위조된 HTTP 요청을 발생시켜 직접적인 접근이 제한된 서버 내부 자원에 접근하여 외부로 데이터 유출 및 오동작을 유발하는 공격을 SSRF(Server Side Request Forgery)라고 한다. 공격형태만 보면 위조된 HTTP 요청(Request Forgery)를 이용한 공격이기 때문에 CSRF(Cross Site Request Forgery)와 유사하다고 볼 수 있으나 공격자의 공격이 발현되는 지점이 서버 측(Server Side)인지 클라이언트 측(Client Side)인지의 여부에 따라서 공격 형태가 구분될 수 있다. CSRF가 사용자의 웹 브라우저를 하이재킹하여 사용자로 하여금 악성 요청을 수행하게 만든다면, SSRF는 접근이 제한된 내부환경에 추가 공격(Post-Exploitation)이 가능하기 때문에 공격의 영향도가 높아질 수밖에 없다.

[표 1] CSRF와 SSRF공격의 차이점 비교

최근 발생한 클라우드 호스팅 제공 업체의 자격 증명 획득에 SSRF취약점이 악용된 사례에서도 알 수 있듯이, SSRF공격은 외부의 공격지점(Attack Surface)을 통해 서비스 제공자가 의도하지 않은 내부 시스템(도메인 및 IP등 이용)에 접근하기 때문에 공격의 피해를 최소화하기 위해서는 SSRF의 발생 원인에 대한 이해 및 웹 애플리케이션 구성에 따른 대응전략이 필요하다. 이에 따라 이번 호에서는 SSRF 취약점의 원리와 대응 방안에 대해서 자세하게 살펴보고자 한다.

02. 사례 분석을 통한 SSRF 취약점 영향도 분석

웹 애플리케이션 개발 환경이 클라우드 인프라를 기반으로 MSA형태로 변화하면서 시스템 간 연계 및 사용자 권한부여 등으로 인해 개발 인프라의 아키텍처가 복잡해지면서 보안 이슈가 지속적으로 증가되었다.
국제 웹 보안분야 비영리단체인 OWASP에서는 이러한 변화의 흐름을 반영하여 ‘OWASP TOP 10 2021’에 A04:2021 Insecure Design, A08:2021 Software and Data Integrity Failures, A10:2021 Server-Side Request Forgery(SSRF)의 3개의 신규항목을 새롭게 추가하였다. 수년간 부동의 1위 자리를 유지하고 있던 A01:2017 Injection취약점의 자리를 A01:2021 Broken Access Control 취약점이 차지하면서 웹 보안 분야에서 중요한 요소는 단순히 입력 값에 대한 미검증보다는 비정상적인 접근의 통제 가능 여부로 변화되었다는 것을 알 수 있다.

[그림 1] OWASP TOP 10 2021 변경 사항 (출처 : OWASP)

이러한 보안의 관점을 반영한 항목이 바로 A10:2021 Server-Side Request Forgery(SSRF)이라고 할 수 있다. 2019년 고객 이름, 주소, 사회보장번호, 신용점수 등이 포함된 1억 6천만 명의 사용자 데이터가 유출된 사건이나 Microsoft Exchange Server(CVE-2021-26855), ProxyShell Exploit 등 대규모 보안 사고의 원인이 SSRF와 연관됨에 따라 SSRF를 활용한 보안 사고 사례를 분석하여 근본적인 공격의 메커니즘을 이해하는 것이 중요하다. 이에 따라 SSRF를 활용한 공격 사례를 분석한 공격 시나리오인 [그림 2]를 통해 공격 유형별 공격 요소들을 보다 상세하게 분석해 보고자 한다.

[그림 2] SSRF 취약점을 이용한 공격 시나리오

[그림 2]는 공격 대상의 환경(On-Premise 및 Cloud)에 따라 SSRF 취약점이 발생하거나 활용할 수 있는 공격 시나리오라고 할 수 있다. 포트 정보 및 서비스 정보 탈취, 내부 데이터 탈취, 클라우드 Metadata 파일 탈취, Credential 탈취 등에 SSRF가 활용될 수 있으며 공격 시나리오별로 [표 2]와 같은 공격 방법이 적용되게 된다. [그림 2]를 토대로 공격 유형 2번(CASE1)과 공격 유형 3번(CASE2)의 경우에는 공격 유형을 토대로 실제 발생한 사고 사례를 매핑하여 분석해 보고자 한다.

[표 2] SSRF 취약점을 활용한 공격 시나리오

1) CASE1 : CVE-2021-26855 공격시나리오

중국 APT그룹 ‘HAFNIUM’이 미국 내 산업시설을 공격하기 위한 목적으로 사용한 CVE-2021-26855은 Microsoft Exchange Server의 SSRF 취약점을 활용한 대표적인 공격 사례다. SSRF 취약점을 통해 HTTP 연결을 생성하고 별도의 인증 과정 없이 사용자 권한으로 Exchange Server에 접근하여 Exchange 주소록 등 Exchange Server에 저장된 데이터 접근 및 탈취가 가능해지게 된다.

공격 과정을 보다 자세히 살펴보면 SSRF를 하기 위해서는 HTTP Request Header의 프로퍼티 중 Cookie에 Value 값으로 ‘X-BEResource’가 필요하다. 스크립트나 이미지와 같은 정적 리소스에 별도의 인증 없이 접근하기 위해서는 입력 값 검증기능이 미흡한 ‘X-BEResource’를 통해 접근이 가능해진다.

공격자인 ‘HAFNIUM’은 HTTP Request Header의 Cookie 프로퍼티에 [그림 3]과 같이 autodiscover를 요청하는 SSRF 공격 구문을 삽입하여 내부 서버에 자동 검색 요청을 보내 사용자의 LegacyDN을 탈취했다.

[그림 3] X-BEResource 쿠키 변조를 통한 사서함 유출
(출처 : blogs.keysight.com, a_look_at_the_proxyl-IlFt.html, 2021/03/16)

그 후 탈취한 LegacyDN을 이용해 사용자의 SID를 검색하기 위해 MAPI 자원에 요청을 전송했다.

[그림 4] X-BEResource 쿠키 변조를 통한 SID 유출
(출처 : blogs.keysight.com, a_look_at_the_proxyl-IlFt.html, 2021/03/16)

마지막으로 취득한 SID를 이용, ‘/ecp/proxyLogon.ecp’ 엔드 포인트에 요청을 보내 공격자와 내부 서버에 유효한 세션을 활성화했다.

[그림 5] X-BEResource 쿠키 변조를 통해 내부 서버와 HTTP 연결 수행(출처 : blogs.keysight.com, a_look_at_the_proxyl-IlFt.html, 2021/03/16)

CVE-2021-26855 취약점 자체만으로는 내부 서버와 연결하는 수준으로 진입 점을 생성할 뿐인 취약점이지만 해당 취약점은 CVE-2021-27065와 같은 다른 Exchange Server 취약점과 연계되면 심각한 서버 손상이 발생할 수 있어 높은 CVSS 위험도 점수를 받게 되었다.

2) CASE2 : Capital One 공격 시나리오

2019년 SSRF 공격으로 인해 미국 금융 기관 ‘캐피탈 원(Capital One)’에서 미국과 캐나다에 걸쳐 약 1억 600만 명의 해킹 피해자가 생기는 사건이 발생하였다. 공격자는 약 140,000개의 사회 보장 번호와 약 80,000개의 은행 계좌 번호 등을 탈취하여 개인정보 유출로 인한 2차 공격의 위험성을 높였다. 다음은 Capital One에서 발생한 사건과 동일한 공격 시나리오를 보여준다.

[그림 6] S3 버킷 URL 입력 매개변수 노출
(출처 : application.security, server-side-request-forgery-in-capital-one)

공격자는 CapitalOne의 홈페이지에 로그인 후 자신의 신용카드 이미지를 본인이 원하는 이미지로 변경할 수 있는 페이지에 접근하여 신용카드 이미지를 변경했을 때 URL에 AWS S3 버킷 관련 입력 매개변수가 전달되고 있음을 확인했다.

[그림 7] ‘url’ 변수에 존재하는 SSRF 취약점
(출처 : application.security, server-side-request-forgery-in-capital-one)

AWS S3 버킷 링크를 전달하는 ‘url’ 변수에 공격자는 외부 이미지 리소스의 URL 주소를 삽입하였고 해당 이미지가 로드되어 카드 이미지에 적용된 것을 확인했다. 이를 통해 공격자는 해당 변수에 SSRF 취약점이 존재하고 있고 AWS 클라우드를 사용하고 있음을 확인했다. 이는 백엔드의 카드 디자인 기능 소스 코드에 취약성이 존재함으로써 발생했다.

[그림 8] 카드 디자인 기능의 취약 소스코드
(출처 : application.security, server-side-request-forgery-in-capital-one)

[그림 8]은 SSRF 취약점이 발현되는 소스코드로, L4번의 queryString 변수에서 S3 버킷 URL을 ‘url=‘ 변수에 할당 후 L8번에서 storageService.load 기능을 이용, ‘url’ 매개 변수를 통해 S3 버킷에서 미리 보기 이미지를 다운로드하게 된다. 마지막으로 L14번에서 HttpGet 함수를 이용, 이미지 파일 검색을 위해 Java 기능을 호출하는데 여기서 ‘url’에 대한 사용자 입력 값 유효성 검사가 이루어지지 않고 있어 SSRF 취약점이 발생하고 있음을 확인할 수 있다.
공격 과정으로 다시 나아가 최종적으로 공격자는 데이터 탈취를 위해 [그림 7]에서 발생한 SSRF 취약점을 악용하여 [그림 9]와 같이 AWS 클라우드 메타 데이터인 ISRM-WAF-ROLE 파일의 내용을 요청하였다.

[그림 9] AWS IAM Role 탈취 시도
(출처 : application.security, server-side-request-forgery-in-capital-one)

ISRM-WAF-ROLE 요청 결과 공격자는 AWS에 접근할 수 있는 AccessKey와 Token의 자격증명을 성공적으로 탈취했으며 [그림 10]과 같이 탈취한 자격 증명으로 AWS에 접근하여 내부 데이터를 탈취했다.

[그림 10] 탈취한 자격증명으로 AWS 접근 및 S3 버킷 탈취
(출처 : application.security, server-side-request-forgery-in-capital-one)

CapitalOne 시나리오의 경우 사소한 기능의 SSRF 취약점으로 인해 상당한 피해를 입은 CASE이다. 우리는 이러한 CASE들을 분석하고 SSRF 취약점이 발생하지 않도록 대처하여 이 같은 피해가 더 발생하지 않도록 막아야 할 것이다.

03. SSRF 공격 상세 분석

1) SSRF 취약 환경 구성

SSRF 취약점이 발현되어 공격에 성공하기 위해서는 DMZ 역할을 수행하는 외부 웹 서버, 공격자 PC와 통신이 되지 않는 타깃의 내부 망 서버가 존재해야 하며 사용자가 전달한 URL 데이터를 가공하여 이미지 등을 제공하는 기능에 SSRF 취약점이 존재해야 한다. SSRF 공격을 위한 환경 구성으로 VMware를 활용하여 DMZ 웹 서버 1대, 내부 망 서버 1대를 구축하며 로컬 PC에서 공격을 수행한다. [그림 11]은 모의 SSRF 공격 환경의 구성도이다.

[그림 11] SSRF 공격 환경 구성도

외부 망에서는 공격자 PC와 DMZ 웹 서버가 통신이 가능하며 내부 망에서는 DMZ 웹 서버와 bee-box 서버가 통신이 가능하다. 또한, SSRF 공격을 통한 내부 bee-box 서버 데이터 탈취를 위해 공격자 PC와 bee-box 서버는 서로 통신이 불가능하도록 환경을 구성했다. 또한, SSRF 취약 환경을 위해 DMZ 웹 서버에 XVWA(Xtreme Vulnerable Web Application) 환경을 구축(http://192.168.16.142/xvwa/), XVWA 내 File Inclusion 취약 파라미터를 통해 내부 bee-box 서버에 대한 SSRF 공격을 수행할 수 있도록 구성했다. (원활한 공격 작업 진행을 위해 공격자가 내부 bee-box 서버의 존재 여부를 확인했으며 내부 망 아이피 대역에 대한 정보를 탈취한 상황으로 가정한다.)

2) SSRF 공격 과정

가장 먼저 내부 망에 존재하는 서버의 ip주소를 찾기 위해 SSRF 취약점을 이용한다. [그림 12]를 보면 DMZ 웹 서버의 XVWA 페이지 내 File Inclusion 취약 파라미터가 존재하며 해당 파라미터에서 SSRF 공격을 수행할 수 있다.

[그림 12] XVWA 페이지의 File Inclusion 취약 파라미터 ‘file’

SSRF 취약 파라미터 ‘file’에 대해 내부망 아이피 대역에 대한 Brute Force 공격을 수행하고 웹 프록시 도구를 이용하여 Response의 Content-Length 값을 확인, 실제 존재하는 내부 서버의 아이피인지 여부를 확인한다.

[그림 13] 내부망 주소 존재 여부에 대한 Content-Length

[그림 13]에서 존재하지 않는 서버의 Content-Length 값은 ‘8991’이나 존재하는 서버의 Content-Length 값은 ‘9033’인 것을 확인하여 내부 서버의 존재 여부를 확인했다. 추가적인 공격을 진행하기 전 SSRF 공격의 특성을 증명하기 위해 [그림 14]에서 공격자 PC에서 내부 서버(10.10.10.10)와 통신 여부 확인 결과 해당 서버에 접근이 불가능함을 알 수 있다.

[그림 14] 공격자 PC에서 내부 서버로의 접근 불가능

알아낸 내부 서버 IP 주소에서 포트 스캐닝 작업을 수행하면 [그림 15]에서 22번 포트를 요청했을 때 페이지에 SSH 관련 정보가 노출되는 것을 확인할 수 있으며 해당 포트가 열려있다는 것을 알 수 있다.

[그림 15] 내부 서버 22 포트 접근 시 SSH 정보 노출

이처럼 공격자 PC에서 접근이 불가능한 내부 서버에 대한 포트 스캐닝이 SSRF 공격을 통해 가능한 것을 확인했다. 추가적인 정보 수집을 위해 [그림 16]에서 서브도메인 무작위 대입 공격을 수행하고 웹 서버 내부 파일을 탈취하는 작업을 수행한다.

[그림 16] 서브 도메인 무차별 대입 공격 수행

내부 서버의 웹 페이지에 서브 도메인 무작위 대입 공격을 수행하고 Content-Length 값을 비교, 반환 값이 다른 서브 도메인 명이 확인되며 이에 접근이 가능한 것을 확인할 수 있다. [그림 17]에서 phpmyadmin 페이지를 요청했을 때 admin 로그인 페이지에서 버전 정보가 노출되는 것을 확인할 수 있다.

[그림 17] phpmyadmin 페이지에서 버전 정보 노출

또한, [그림 18]에서 drupal 디렉터리 내 텍스트 파일인 robots.txt 파일을 요청한 결과 파일 내용이 DMZ 웹 서버에 그대로 노출되는 것이 확인됐다.

[그림 18] robots.txt 파일 조회

포트 스캐닝과 내부 서버 데이터 탈취를 통해 얻은 정보에는 서비스 버전 정보가 존재했다. ssh와 phpMyAdmin의 버전 정보에 대한 알려진 취약점을 검색하고 이를 공격하는 것은 그리 어렵지 않은 일이다. [그림 19]는 OpenSSH(v4.7p1)와 phpMyAdmin(v2.11.3)의 CVE 취약점을 보여준다.

[그림 19] OpenSSH(CVE-2010-4478), phpMyAdmin(CVE-2008-7252) 취약점 (출처 : cvedetails)

그렇다면 이와 같은 SSRF취약점이 발현되는 원인이 무엇일까? 그에 대한 해답은 [그림 20]의 file 파라미터를 처리하는 구문에서 답을 찾을 수 있다.

[그림 20] file 파라미터로 인한 SSRF 취약점 발현구문

[그림 20]의 소스코드 분석결과 L9번에서 $file 함수를 사용자 입력에 대한 유효성 검사를 진행하지 않고 그대로 실행하여 SSRF 취약점이 발생하고 있음을 알 수 있다. 이처럼 SSRF 공격 수행 시 공격자 PC가 내부 망에 네트워크로 연결되지 않아도 내부 망과 연결된 외부 서버를 통해 내부 망에 존재하는 서버에 대한 공격이 가능한 것이 증명되었다.

위의 테스트 환경에서의 SSRF 공격 작업은 정보 노출 및 내부 서버 파일 접근에 대한 위험을 유발했지만 그 외에도 파일 다운로드, 서비스 거부 공격(DoS) 등 추가적인 위협이 존재할 수 있으므로 외부와 직접적으로 연결되지 않은 내부 서버라고 해서 보안에 소홀해지지 않도록 유의해야 할 것이다.

04. SSRF 공격 대응 방안

SSRF 공격에 대응하기 위해서 네트워크 단과 애플리케이션 단에서 보안 조치를 취할 수 있다. 강력한 보안을 위해 두 종류의 대응 방안을 모두 수립할 것이 권고된다. 이전에 나왔던 SSRF 공격 시나리오를 기반으로 대응 방안을 수립 하는 것은 좋은 방법 중 하나이다.

1) 네트워크 기반의 SSRF 대응방안

먼저 네트워크 계층 기반의 대응 방안을 수립해야 한다. SSRF 공격의 구조를 파악해 보면 내부 서버와 연결된 DMZ망의 웹 서버가 사용자와 통신을 하는 과정이 존재하므로 발생하며 이런 상황에서 SSRF 취약점이 존재할 경우 내부 서버의 데이터 탈취 우려가 존재한다. 이때 탈취되는 데이터가 민감하거나 중요한 데이터라면 SSRF 공격의 파급력이 높아지게 된다. 그렇기 때문에 중요한 데이터는 DMZ망의 웹 서버와 연결되지 않은 고립된 내부 서버에 저장하는 것이 중요하다.

또한, URL 스키마 방식을 http, https만 허용하여 내부 파일에 접근하거나 ftp, ldap과 같은 특정 서비스에 접근하는 요청을 차단해야 한다. 요청을 처리하는 서버와 중요 정보가 있는 내부 서버를 분리하여 SSRF 공격 성공 시 중요 정보를 탈취할 수 없게끔 처리하고 http의 요청만 가능하도록 설정하게 되면 공격을 받게 되어도 그 피해를 완화할 수 있다.

[그림 21] SSRF 공격 대응을 위한 내부망 서버 분리

또한, Snort와 같은 침입 모니터링 시스템을 배치하고 SSRF 탐지 정책을 반영하여 웹 서버와 내부 서버 사이의 트래픽을 탐지, SSRF 공격을 모니터링 함으로써 SSRF 공격을 실시간으로 탐지하고 차단하여 신속하게 대응할 수 있는 시스템을 구축하는 것도 중요하다. [그림 22]는 SSRF 공격 탐지가 가능한 Snort Rule 중 하나의 예시이다.

[그림 22] 이글루코퍼레이션 CTI SSRF 취약점(CVE-2019-9621) 탐지 정책

모니터링 작업을 통해 SSRF 모의 침투 시나리오에서 발생하는 공격을 대부분 차단하거나 탐지하여 신속한 대응을 할 수 있다. 위와 같은 방식으로 네트워크 단에서의 SSRF 공격에 대한 완화 조치를 수행할 수 있으며 더 강력한 보안 환경 구축을 위해 아래에 소개되는 애플리케이션 단의 보안 조치도 고려해야 한다.

2) 애플리케이션 기반의 SSRF 대응방안

SSRF 취약점 보안 조치 시 애플리케이션에서 사용자 입력을 받는 기능에 대한 시큐어 코딩 작업 또한 중요하다. 본 문서에서는 정규표현식을 이용하여 화이트리스트를 등록함으로써 사용자 입력 값에 제한을 두는 방법을 소개하겠다. [그림 23]은 사용자에게 화이트리스트에 등록된 도메인(igloo.co.kr)을 포함한 이미지 URL을 입력 받아 해당 이미지를 화면에 출력해주는 단순한 기능을 수행하는 JSP 코드이다.

[그림 23] SSRF 취약점이 존재하는 form.jsp 및 action.jsp

form.jsp는 사용자에게 이미지 URL을 입력받는 페이지이며 action.jsp는 URL을 받아 화면에 이미지를 출력해 주는 페이지다. 여기서 SSRF 취약점은 L14, L20번에서 사용자 입력 값의 유효성을 검증하지 않아 발생하게 된다. 공격자는 이미지 URL을 입력하는 폼에 내부 서버의 데이터에 대한 요청을 웹 서버에 전송하거나 화이트리스트 등록 도메인(igloo.co.kr)이 아닌 다른 외부 도메인의 이미지 URL을 삽입할 수 있다. 이를 막기 위해서는 사용자 입력 값이 화이트리스트에 등록된 주소와 연관되지 않은 경우 모두 차단하는 작업을 진행해야 한다. [그림 24]는 정규 표현식을 이용해 시큐어코딩 작업을 진행한 소스 코드이다.

[그림 24] 정규표현식을 이용한 시큐어코딩

L8~L17 라인을 보면 form.jsp에서 사용자 입력 값의 유효성을 검증하는 스크립트가 추가되었다. L10에서 정규표현식을 이용해 주소에 igloo.co.kr이 포함되지 않는 경우 에러를 반환하도록 구현되었다. 즉, image.igloo.kr과 같은 주소는 정상적으로 전송되나 image.hacking.kr과 같은 주소는 에러가 반환된다. 구현한 유효성 검증 기능은 L22에서 ‘submit’ 버튼을 클릭하여 요청 전송 시 L9의 ‘checkForm()’ 함수를 실행함으로써 정상 실행되며 위와 같은 방식으로 애플리케이션 단에서 SSRF 공격을 효과적으로 차단할 수 있다. [그림 24] 소스 코드는 Pseudo code이므로 서버 운영 상황에 따라 유효성 검사 로직에 대한 적절한 변경 작업이 요구된다.

추가적으로, 애플리케이션 단에서 사용자 입력 값에 대한 유효성 검사를 진행하는 경우 공격자의 우회 공격에 대한 우려가 존재하므로 서버 운영의 효율성을 고려하여 네트워크 보안과 병행하여 보안 조치를 취해야 한다.

05. 마무리

SSRF 취약점은 외부의 공격자와 통신이 직접적으로 연결되지 않는다고 해서 보안을 소홀히 하는 경우가 많아 이를 공격자가 악용하여 큰 피해를 입을 수 있다. 최근 웹 어플리케이션 개발환경이 클라우드 인프라 기반 MSA형태로 변화함에 따라 위협이 증가하여 그 동향에 대한 주시가 필요한 취약점이므로 보안 점검을 통해 서버에 SSRF 취약점이 존재하는지 점검하고 네트워크와 애플리케이션 단 모두 대응 방안을 수립할 것을 권고한다.

06. 참고자료

[1] OWASP TOP 10 – SSRF
https://owasp.org/Top10/A10_2021-Server-Side_Request_Forgery_%28SSRF%29/
[2] MITRE – SSRF CVE
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=ssrf
[3] ITWorld - 서버를 속여 공격한다" SSRF 공격의 동작 방식과 대처법
https://www.itworld.co.kr/howto/211794
[4] PortSwigger - Server-side request forgery (SSRF)
https://portswigger.net/web-security/ssrf
[5] hahwul - SSRF (Server-Side Request Forgery)
https://www.hahwul.com/cullinan/ssrf/
[6] me2nuk - SSRF Gopher Protocol을 이용하여 MySQL 주입
https://me2nuk.com/SSRF-Gopher-Protocol-MySQL-Raw-Data-Exploit/
[7] A look at the ProxyLogon Microsoft Exchange vulnerability (CVE-2021-26855)
https://blogs.keysight.com/blogs/tech/nwvs.entry.html/2021/03/16/a_look_at_the_proxyl-IlFt.html
[8] Capital one Scenario
https://application.security/free-application-security-training/server-side-request-forgery-in-capital-one