[TryHackMe] CSRF

TryHackMe - "CSRF". Write-up + Extra Study!

출처: https://tryhackme.com/room/csrfV2

CSRF

 

[1]  Overview of CSRF Attack

CSRF (Cross-site Request Forgery)

- 사용자가 로그인 상태를 악용해, 사용자 대신 요청을 보내는 공격

- 브라우저가 인증 정보 관련 쿠키를 자동으로 포함한다는 점을 악용

 

[1-1] CSRF 공격 흐름

1. 웹 애플리케이션의 요청 형식 파악

2. 사용자에게 악성 링크 전송 → 클릭 유도

3. 브라우저가 자동 포함한 쿠키를 포함해 공격자가 요청 전송

4. 서버가 정상 사용자의 요청으로 인색 → 요청 수행

 

[1-2] CSRF의 영향

- Unauthorized Access - 사용자 권한을 통한 계정 변경 등의 비인가 행동

- Exploiting Access - 사용자 신뢰를 악용한 보안 신뢰성 약화

- Stealthy Exploitation - 브라우저의 정상 동작을 이용하여 공격 탐지 어려움

 

 

 

---

[2]  Types of CSRF Attack

[2-1] Traditional CSRF

- form 제출을 통해 상태를 변경하는 동작 state-changing actions에 집중

1. 로그인한 사용자에게 악성 링크 및 메일, form 전달

2. 사용자가 클릭

3. 브라우저가 자동으로 쿠키를 포함한 요청 전송

4. 서버가 정상 요청으로 인식 → 금액 송금, 계정 정보 수정, 이메일 변경 등을 수행

 

[2-2] XMLHttpRequest CSRF

- 전체 페이지 request-response 사이클 없이 동작이 수행될 때 발생

- XMLHttpRequest 또는 Fetch API를 이용한 asynchronous(비동기) 서버 통신을 사용하는 최신 웹 애플리케이션에서 흔히 발생

1. 로그인한 사용자에게 악성 페이지 접속 유도

2. 악성 페이지 접속 시, JavaScript가 AJAX 요청 생성

3. 브라우저가 자동으로 쿠키를 포함한 요청 전송

4. 서버가 정상 요청으로 인식 → 이메일 전달 설정 변경 → 공격자 주소로 메일 전달

 

[2-3] Flash-based CSRF

- Adobe Flash Player의 취약점을 악용한 공격

- 현재는 거의 사라짐 (Adobe Flash Player의 서비스 종료)

1. 사용자가 악성 사이트의 Flash 콘텐츠 실행

2. 악성 .swf 파일을 자신의 웹사이트에 업로드

3. Flash가 쿠키를 포함한 요청을 피해 사이트로 전송

4. 서버가 정상 요청으로 인식 → CSRF 공격 성공

 

 

 

---

[3]  Basic CSRF - Hidden Link / Image Exploitation

Hidden link / Image Exploitation

- 인지하기 힘든 0x0 픽셀 이미지나 링크를 웹페이지에 삽입하는 공격

- 이미지의 src 또는 링크의 href 속성에 공격 URL을 삽입

 

[3-1] Hidden Link / Image Exploitation 실습

1)  피해자 로그인 상태

 - 피해자는 메일 (mailbox.thm)을 확인하고, 은행 계정 (mybank.thm)에 로그인함

 - 피해자는 항상 은행 (mybank.thm)에 로그인한 상태 유지

[보충 설명] "GB82MYBANK5698" username으로 로그인한 계정은 피해자 Josh의 계정이 아닌 공격자의 계정입니다.

 

 

2)  mybank.thm 취약점

 - 공격자 자신의 은행 (mybank.thm) 계정을 통해 취약점 확인

 → 송금 시 요청 검증을 위한 추가적인 파라미터가 없음을 확인

 → URL만으로 송금 가능

 

 

3)  악성 링크를 포함한 이메일 전송

 - 피해자의 클릭을 유도하는 이메일 전송 (경품 당첨!)

 - "Click Here to Redeem" 버튼을 누르면, 은행 송금 페이지 링크로 연결됨

 

 

4)  공격 성공 여부

 (4-1) 피해자가 은행 (mybank.thm)에 로그인을 안 한 상태

 = 은행 송금 페이지로 이동을 하더라도, 로그인이 안되어 있어 로그인 창으로 이동

 

 (4-2) 피해자가 은행 (mybank.thm)에 로그인을 한 상태

 = 쿠키에 있던 로그인 정보를 통해 공격자에게 자동 송금 완료

 

 (4-3) 은행 (mybank.thm) 사이트에 검증을 위한 별도의 CSRF 토큰이 존재

 = 서버가 CSRF 토큰이 포함되지 않음을 확인 → 송금 이루어지지 않음

 

 

 

---

[4]  Double Submit Cookie Bypass

CSRF token

- 요청 출처를 검증하기 위한 hidden parameter

- 고유한 예측 불가능한 값

 

Double Submit Cookie 기법

- 쿠키 값과 hidden form 필드 값이 일치하는지 확인하는 검증 장치

 

[4-1] Double Submit Cookies 작동 흐름

1. Token Generation

 - 사용자가 로그인 or 세션 시작 시, 서버가 고유한 CSRF 토큰 생성

 - cookie와 web form의 hidden field 두 가지 형태로 사용자 브라우저에 전달

 

2. User Action

 - 사용자가 hidden CSRF 토큰이 포함된 form 작성

 

3. Form Submission

 - 쿠키에 포함된 토큰과 form 데이터에 포한된 토큰을 서버로 전송

 

4. Server Validation

 - 서버가 cookie의 CSRF 토큰과 form 데이터의 토큰이 일치하는지 확인

 

[4-2] Double Submit Cookie 우회 방법

Session Cookie Hijacking (MITM 공격)

- CSRF 토큰의 보호가 약함 → 악성코드, 네트워크 sniffing 등으로 토큰 탈취

 

Same-Origin Policy 우회

- 부모 도메인에 쿠키 설정이 가능한 공격자의 subdomain으로 요청 보내도록 유도 

 

XSS 취약점 악용

- XSS 취약점을 활용해 cookie 또는 CSRF 토큰 탈취

 

CSRF 토큰 예측

- 토큰의 생성 과정에 개입 및 생성 패턴 단순 → 토큰을 추측하거나 변조

 

Subdomain Cookie Injection

- 공격자의 subdomain을 통해 사용자 브라우저에 위조된 cookie 주입 → 서버가 정상 cookie로 인식

 

[4-3] Reversing Token generation + Subdomain Cookie Injection

1)  CSRF 토큰 분석

 - 공격자 계정으로 은행 (mybank.thm) 사이트의 토큰 분석

 - 비밀번호 변경 form에 CSRF Token 존재함

 = 브라우저 cookie에 `csrf-token`과 `PHPSESSID` 존재함

[보충 설명] 피해자 Josh의 쿠키는 [3-1] 실습에서 자동 송금되었을 때, 자동 로그인된 화면에서 f12 (개발자 도구)에 들어가 확인할 수 있습니다.

 

 

2)  가짜 비밀번호 변경 form 생성

 - `csrf-token`가 Base64로 인코딩되었음을 확인 →CyberChef로 디코딩 → 디코딩 결과가 계좌번호 → 예측 가능

 - 이를 통해 CSRF 토큰 생성

 - 공격자 사이트 (attacker.mybank.thm)에 CSRF 토큰이 포함된 가짜 비밀번호 변경 form 생성

[보충 설명] 현재 공격자의 사이트 `attacker.mybank.thm`은 은행 사이트인 `mybank.thm`의 subdomain입니다. 현재 예시에서는 공격자가 DNS/서버 설정 권한을 통해 새로 만든 케이스입니다. XSS 취약점 등을 이용하거나 기존에 방치된 subdomain을 장악하여 사용할 수도 있습니다.

 

 

3)  피싱 메일 전송

 - "비밀번호 변경 필요" 등의 메일을 보내 클릭 유도

 

 

4)  Cookie Injection + Auto Submit

 - auto-submit(자동 전송) 코드 때문에 링크를 누르는 순간 비밀번호 변경 form이 자동 전송됨

 - 같은 도메인 계열임을 이용해 subdomain인 `attacker.mybank.thm`에서 `mybank.thm`에 쿠키를 주입 및 설정

[보충 설명] 링크 클릭 후, 나오는 비밀번호 자동 기억 팝업 창에서 변경된 비밀번호를 확인할 수 있습니다

 

 

5)  공격 성공

 - Form token과 Cookie token이 같아 서버가 정상 요청으로 판단 (둘다 공격자가 만든 토큰)

 - 피해자의 비밀번호를 변경해 계정 탈취 성공

 

 

 

---

[5]  Samesite Cookie Bypass

Samesite Cookie

- cross-site 요청 시, 브라우저 쿠키의 전송 여부를 결정

- cross-origin 데이터 유출, CSRF, XSS 방어에 효과적

 

 

[5-1] SameSite 속성의 3가지 값

1. Lax

 - 적당한 수준의 보호

 - cookie는 top-level naviagtion(링크 클릭)이나 안전한 HTTP 메서드 (GET, HEAD, OPTIONS)에서 전송됨

 - cross-origin POST 요청에는 쿠키가 포함되지 않음 → CSRF 공격 방어

 - 외부 사이트의 GET 요청에는 쿠키가 포함

[보충 설명] top-level navigation = 브라우저 주소창이 바뀌는 이동 실습에서는 "https://mybank.thm/logout.pnp" 페이지, 즉, 아예 다른 페이지로 이동하며 주소창 URL이 변경됩니다. 이러한 상황이 top-level navigation 입니다. GET 요청 = 페이지 이동, 링크 클릭 POST 요청 = 데이터 전송

 

2. Strict

 - 가장 강력한 보호

 - 같은 origin(사이트)의 요청에만 쿠키 포함

 

3. None

 - 모든 요청에 쿠키 포함 = same-site와 cross-site 요청 모두에서 쿠키 포함

 - HTTPS 환경에서 Secure 속성이 있어야 안전 → 암호화된 연결에서만 전송되도록 함

 

 

[5-2] SameSite=Lax 쿠키 환경 CSRF Exploit

1)  SameSite 속성 확인

 - [4-3] 에서 변경한 비밀번호로 Josh 계정 로그인

 - `logout` 쿠키의 SameSite 속성 확인

 = `logout` cookie의 SameSite 속성은 Lax

 → top-level navigation GET 요청에는 cookie 보냄 = CSRF 가능

 

 

2)  피해자의 은행 사이트 로그아웃 유도

 - 피해자는 새 비밀번호를 몰라 재로그인 불가 → 공격자가 계정 통제

 - 링크 클릭을 유도하는 메일 전송

 = "Survey Link" 클릭하는 순간, 피해자는 은행 (mybank.thm) 사이트에서 로그아웃 됨

[보충 설명] "Survey Link"를 클릭하면, 브라우저가 `mybank.thm/logout.php" 라는 로그아웃 페이지로 이동합니다. 이는 GET 요청이기 때문에, SameSite=Lax 속성인 logout 쿠키가 같이 전송됩니다. 같이 전송된 logout 쿠키 때문에 서버는 정상 요청으로 인식하여 피해자가 은행 사이트에서 로그아웃됩니다.

 

 

3)  피해자 계정 차단하기

 - `isBanned` 쿠키가 "true" → 피해자 계정 차단

여기서 logout 쿠키 값도 변경할 수 있습니다!

 = POST 요청으로 `isBanned=true` 갱신

 - 쿠키가 최근 2분 내에 생성 및 수정 → 일시적으로 `SameSite=None`처럼 동작 → 일시적으로 POST 요청 가능

 

 

4)  공격 성공 여부 파악

 - Test Scenario - LAX+POST! 메일의 "Test Attack - Successful" 버튼을 눌러 피해자 계정의 차단 여부 확인

 

 

 

---

[6]  Few Additional Exploitation Techniques

[6-1] XMLHttpRequest Exploitation

- 공격자가 사용자 몰래 사용자가 로그인한 웹사이트로 AJAX 요청을 보냄

- 기존의 form 제출 역할을 JavaScript AJAX 요청으로 수행

- SOP (Same-Origin Policy)는 응답 읽기를 막는 정책이라 JS를 읽을 수 없어 cross-origin 요청 금지를 우회함

 

[6-2] Same Origin Policy (SOP) and Cross-Origin Resource Sharing (CORS) Bypass

- 사용자의 브라우저를 속여 현재 접속한 사이트가 아닌 다른 웹사이트로 요청을 보냄

- CORS 정책 = 허용된 origin에서만 요청 허용

- `header('Access-Control-Allow-Origin: *')` 로 인해 모든 origin의 요청을 허용하면서 취약점 발생

[보충 설명] `Access-Control-Allow-Origin: *` = 어떤 origin (도메인)에서 요청이 와도 허용 `Access-Control-Allow-Credentials: true` = 쿠키/세션을 포함한 요청도 허용 → 절대 이 둘을 같이 사용하면 안됩니다

 

[6-3] Referer Header Bypass

- HTTP 요청 시, `Referer` 헤더에는 현재 요청 직전에 방문한 페이지 URL이 포함됨

→ Referer가 우리 도메인과 일치할 때만 요청 허용하는 웹사이트들 존재함

- Referer 헤더는 브라우저 확장 프로그램, privacy tool, Referer를 생략하는 meta tag 등으로 변경 및 제거 가능

→ `Referer`만으로는 CSRF 방어 불충분

 

 

---

[7]  Defence Mechanisms

[7-1] Pentesters / Red Teamers

- CSRF Testing = 비인가 요청을 실제로 실행 → CSRF 취약점 존재 확인

- Boundary Validation = 입력값 검증 및 CSRF 토큰 존재/검증 여부 확인

- Security Headers Analysis = CORS, Refere 등 보안 Header 설정 점검

- Session Management Testing = 세션 토큰이 안전하게 생성/전송/검증 되는지 확인

- CSRF Exploitation Scenarios = 이미지 태그, 숨겨진 요청 등 다양한 공격 시나리오 테스트

 

[7-2] Secure Coders

- Anti-CSRF Tokens = 예측 불가능한 토큰 적용

- SameSite Cookie Attribute = `Strict` 또는 `Lax`로 설정하여 cookie 전송 제한

- Referrer Policy = Referer 정보 제한 및 신뢰된 요청만 허용하게끔 설정

- Content Security Policy (CSP) = 신뢰된 스크립트만 실행되도록 설정

- Double Submit Cookie Pattern = cookie와 요청 파라미터 토큰 비교로 검증

- CAPTCHA 적용 = 자동 공격 방지

 

 

 

---

[TryHackMe] CSRF. Finish!