침해대응 & CERT 13 주차. 웹 모의해킹 실습(2)

CSRF

Cross-site request forgery (CSRF)는 공격자가 사용자로 하여금 그들이 의도하지 않은 작업을 수행하도록 유도하는 웹 보안 취약점이다. 이를 통해 공격자는 서로 다른 웹사이트가 서로와 소통하는 것을 방지하는 same origin policy (SOP)를 부분적으로 우회할 수 있다. 만약 공격 당한 사용자가 애플리케이션에서 특별 권한(예: admin)을 보유했었다면 공격자는 애플리케이션의 모든 데이터와 기능을 사용할 수 있다.

 

CSRF 발생 조건

1. 유의미한 action : 애플리케이션 내에 공격자가 사용자에게 유도하고자 하는 의도가 존재한다. 이는 사용자의 접근 권한, 혹은 비밀번호 등의 사용자 특징적 정보를 변경하는 action을 의미한다.
2. Cookie 기반 session handling : 하나 이상의 HTTP 요청과 사용자를 식별하기 위한 session cookie가 존재한다.
3. 예측 불가능한 요청 매개변수는 없다 : Action을 수행하는 요청에 공격자가 결정하거나 추측할 수 없는 값을 가진 매개변수가 존재하지 않는다.

---

실습

1. CSRF 실습 준비 상태

 

2. 비밀번호 변경 HTTP 통신을 BurpSuite로 포착

 

3. 웹 무료 CSRF PoC 실행

 

비밀번호 변경 HTTP 요청 Contents에 대해 CSRF PoC를 실행한다.

• BurpSuite : Generate CSRF PoC - PortSwigger
• 무료 웹 PoC : Hacktify CSRF PoC Generator

 

4. CSRF PoC를 html 형태로 저장

전달되는 매개변수 중 비밀번호 값을 수정하고 html 형태로 저장한다. (예시. 'this_is_hacked:p')

 

5. CSRF PoC html 실행 화면

CSRF PoC html을 대상이 실행 중인 웹 브라우저 환경에서 실행한다.

 

6. 결과 확인

 

비밀번호가 변경되어 사용자는 더 이상 기존 비밀번호로 접속이 불가능하다.

---

대응 방안

최근 성공적으로 CSRF 취약점이 발견되고 공격 당한 경우는 보통 목표 웹사이트나 피해자의 브라우저, 아니면 둘 모두에 배포된 anti-CSRF 조치를 우회하는 것이다. 이에 대한 가장 일반적인 대응 방법은 다음과 같다.

1. CSRF 토큰
   • CSRF 토큰은 고유하고, 비밀이며, 예측불가능한 값으로, 서버 사이드 애플리케이션에 의해 생성되고 클라이언트와 그 값을 공유한다.
   • Form을 제출하는 것 같은 민감한 action을 실행할 시, 클라이언트는 반드시 올바른 CSRF 토큰을 요청에 포함해야 한다. 이로써 공격자는 유효한 요청을 작성하기 더욱 어려워진다.
2. SameSite Cookie
   • SameSite란 브라우저 보안 mechanism으로, 웹사이트의 쿠키가 다른 웹사이트에서 비롯된 요청에 포함될 때를 결정하는 것이다. 민감한 action을 수행하는 요청은 일반적으로 인증된 session cookie를 요구하기 때문에, 적합한 SameSite 규제는 공격자의 cross-site aciton 시도를 예방할 수 있다.
   • 2021년 이후로, Chrome은 `Lax` SameSite 규제를 기본 값(default)으로 강제하고 있다.
3. Referer-based 유효값 검사
   • 일부 애플리케이션은 HTTP Referer 헤더를 사용하여 CSRF 공격에 대한 방어를 시도하는데, 이는 애플리케이션 도메인에서 비롯된 요청을 검증하는 방식으로 동작한다. 이는 CSRF 토큰 유효성 검사보다는 덜 효과적이다.

---

File Inclusion

파일 삽입 취약점 (File Inclusion)은 공격자 웹 서버에서 파일을 삽입하고 실행하도록 허용하는 웹 애플리케이션 취약점으로, 민감 정보 유출 및 시스템 공격을 초래한다. 해당 취약점은 파일 경로 등 사용자 입력이 (애플리케이션 내 파일 삽입 기능에 사용되기 전에) 적절히 검증되지 않아 발생한다.

 

파일 삽입 취약점은 아래의 두 가지 유형이 대표적이다.

Local File Inclusion (LFI)

LFI는 대상 서버에 이미 존재하는 파일을 대상으로 한 파일 삽입 공격으로, URI 경로 내 'include'문에 대한 적절한 검증이 이뤄지지 않았을 때 발생하기 때문에, 파일명을 매개변수로 취하는 script를 면밀히 살펴야 한다.

# LFI 취약 URI 예시
http://vulnerable_host/preview.php?file=example.html

 

위의 예시는 공격자가 매우 쉽게 공격 경로를 파악할 수 있는 LFI 취약점으로, 서버 내에 존재하는 임의 파일을 삽입해볼 수 있다.

 

# LFI 공격 예시
http://vulnerable_host/preview.php?file=../../../../etc/passwd

# LFI 공격 결과
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
alex:x:500:500:alex:/home/alex:/bin/bash
margo:x:501:501::/home/margo:/bin/bash
...

 

이처럼 서버에 존재하는 디렉터리 이름과 경로를 입력하여 서버 내부 정보를 쉽게 탈취할 수 있다.

 

Remote File Inclusion (RFI)

RFI는 애플리케이션에 구현된 취약한 삽입 절차를 공격하여 외부 서버(공격자 서버 등)의 원격 파일을 삽입하는 공격이다.

 

해당 취약점은 웹 페이지가 삽입되어야 할 파일명을 입력받지만 적절히 검증되지 않아 외부 URL이 입력될 경우 발생한다.

 

대부분의 예시들은 취약한 PHP script를 다루지만, JSP, ASP 같은 언어들도 주로 사용될 수 있다는 걸 명심해야 한다.

# 원격지 웹쉘 경로 : 
http://192.168.10.5/hacker/webshell.php

 

FI 발생 조건

1. 사용자 입력값 의존성 : 해당 취약점의 핵심은 어떤 파일을 삽입할지 결정할 때, 애플리케이션이 사용자 입력값 (예: GET/POST 매개변수, URLs, cookie, HTTP header)에 의존한다는 것이다.
2. 입력값 검증 미진 : 애플리케이션 입력값에 대한 검증 및 명료화가 미진한 경우 취약하다.
3. 파일 삽입 mechanism : 해당 취약점은 동적 파일 삽입 mechanism에서 보통 비롯된다. (예: PHP 같은 스크립팅 언어)

---

실습

Local File Inclusion

1. 시작 화면

URI 명에 filename 등 디렉터리/파일명이 직접적으로 작성될 경우, LFI 공격에 취약할 가능성이 높다.

 

2. LFI 시도 결과

Linux OS의 대표적인 폴더 '/etc/passwd'를 입력하여 그 내용이 출력되는 걸 확인 가능하다.

 

 

Remote File Inclusion

LFI 실습 내용처럼 URI에 파일명 혹은 디렉터리 경로가 포함된 링크에 미리 준비한 공격자 외부 서버 URL (예시. http://attacker_site/malicous_page)를 삽입한다.

---

대응 방안

1. 엄격한 입력값 검증 : 오직 사전정의되고 안전한 파일 경로만 처리할 것을 보장한다.

# LFI 입력값 검증 예시
<?php include($_GET['file'].".php"); ?>

# RFI 입력값 검증 예시
$incfile = $_REQUEST["file"];
include($incfile.".php");

 

1. Whitelisting : 허용된 파일 확장자와 위치만을 whitelist에 저장한다.

<?php
// Whitelist approach
$allowed_files = ['home', 'about', 'contact'];
$file = $_GET['file'] ?? 'home';

if (in_array($file, $allowed_files)) {
    include($file . ".php");
} else {
    include("error.php");
}
?>

 

1. Content-Security-Policy (CSP) 사용 : Document가 로드할 수 있는 리소스를 제한하는 데 사용되며, 주로 Cross-site scripting(XSS) 공격에 대한 보호 방책으로 사용된다.

---

참고 출처 

 - What is CSRF (Cross-site request forgery)? Tutorial & Examples | Web Security Academy

 - All labs | Web Security Academy

 - Using Burp to Test for Cross-Site Request Forgery (CSRF) - PortSwigger

 - WSTG - Stable | OWASP Foundation

 - WSTG - Stable | OWASP Foundation