3달차 2주차 과제는 다음 4가지와 같다.
- 수업 내용 정리
- CSRF 문제풀이 (Write-Up 정리)
1번 복습 내용은 "스터디 정리" 카테고리에 기록해두었다.
따라서 2번 과제부터 정리하였다.
1. CSRF : CTF문제 풀기
[GET Admin 1]
| 주어진 문제는 다음과 같다. |
|---|
 |
| 과정 설계 |
|---|
| 1. 계정을 탈취하기 위해서는 비밀번호를 공격자가 원하는 값으로 지정해야 한다. 따라서 비밀번호 변경 페이지에서 CSRF가 있는지 확인한다. |
| 2. 비밀번호 변경 페이지의 데이터 전송방식에 GET 방식이면 링크 전달, POST 방식이면 XSS취약점 연계로 CSRF를 수행한다. |
| 3. 이용자가 링크에 접근하여 비밀번호 변경 요청을 보낸것이 확인되면, 해당 계정으로 로그인하여 계정을 탈취한다. |
| (1) CSRF 취약점 확인 |
|---|
 |
| ○ 로그인 > 마이페이지 > 비밀번호 변경 |
 |
| ○ 패킷을 살펴보면 인증정보 없이, 비밀번호 변경 요청이 전송되고 있다. 즉, CSRF 취약점을 의심해볼 수 있다. |
 |
| ○ 또한 GET 방식으로 바꾸어서 요청을 전송하여도, 정상적으로 처리 된다. |
| (2) 대상에게 해당 링크 전달 |
|---|
| 비밀 번호 변경요청이 GET 방식으로도 가능한 것을 확인하였다. 따라서 비밀번호 변경 요청 URL을 대상에게 전달하여 비밀번호가 변경되도록 한다. |
 |
| ○ 실행결과, 대상이 공격을 눈치챘다. |
| (3) CSRF 공격 강화 |
|---|
| ○ 링크를 방문시 CSRF 공격이 눈치채게 된다. ● 따라서 눈치를 채지 못하도록 공격 방식을 강화하고자 한다. |
| 먼저 해당 링크를 방문해보았다. |
 |
| ○ 정보 수정 페이지로 직접 이동되어, 정보 수정 알림 스크립트가 실행되고 있다. |
| ● 따라서 다른 방식으로 해당 링크에 접근하도록 하고자 한다. |
 |
| ○ 공지사항 > 게시글 작성 페이지에서 내용 입력칸에 iframe 의 속성으로 해당 URL을 요청하도록 하였다. |
 |
| ○ 실행결과, 추가한 iframe이 보여지고 있다. 따라서 해당 iframe이 보이지 않도록 하고자 한다. |
 |
| ○ iframe 의 style 속성을 "display:none" 으로 해주어 iframe이 보이지 않게 해주었다. |
 |
| ○ 실행결과, iframe은 보이지 않지만 회원 정보 수정 알림이 표시되고 있다. 따라서 해당 알림도 표시되지 않도록 하고자 한다. |
 |
| ○ iframe의 sandbox 속성을 None으로 해주어 자바스크립트가 동작하지 않도록 해주었다. |
 |
| ○ 실행결과, 정상적인 게시글처럼 보여지게 된다. |
 |
| ○ 요청을 살펴보면, 해당 게시글로부터 비밀번호 변경요청이 전송되고 있다. |
| (6) CSRF 공격을 수행하여 계정 탈취 |
|---|
 |
| ○ 관리자가 해당 게시글에 방문하였다. 즉, 작성한 스크립트에 따라 해당 계정에 비밀번호가 123으로 변경되게 된다. |
 |
| ○ 아이디와 변경된 비밀번호로 로그인을 하여 계정 탈취 |
 |
| ○ 로그인에 성공하여 flag가 출력되었다. |
[GET Admin 2]
| 주어진 문제는 다음과 같다. |
|---|
 |
| 과정 설계 |
|---|
| 1. 계정을 탈취하기 위해서는 비밀번호를 공격자가 원하는 값으로 지정해야 한다. 따라서 비밀번호 변경 페이지에서 CSRF가 있는지 확인한다. |
| 2. 비밀번호 변경 페이지의 데이터 전송방식에 GET 방식이면 링크 전달, POST 방식이면 XSS취약점 연계로 CSRF를 수행한다. |
| 3. 이용자가 링크에 접근하여 비밀번호 변경 요청을 보낸것이 확인되면, 해당 계정으로 로그인하여 계정을 탈취한다. |
| (1) CSRF 취약점 확인 |
|---|
|
| ○ 로그인 > 마이페이지 > 비밀번호 변경 |
 |
| ○ 패킷을 살펴보면 인증정보 없이, 비밀번호 변경 요청이 전송되고 있다. 즉, CSRF 취약점을 의심해볼 수 있다. |
| (2) XSS 취약점 확인 |
|---|
| 비밀번호 변경 요청을 살펴보면 POST 방식으로 데이터를 전달하고 있다. 따라서 링크 전달 방식은 불가하므로, XSS취약점과 연계하기 위하여 XSS취약점을 확인한다. |
 |
| ○ 공지사항 > 글쓰기 페이지에서 글 제목과 본문에 스크립트를 삽입한다. |
 |
| ○ console.log() 가 실행되는 것을 보아 제목과 내용 입력칸 모두 XSS취약점이 존재한다. |
| ● 따라서 둘중 입력칸의 넓이가 넓은 내용 입력칸의 XSS 취약점을 이용하여 CSRF 공격을 수행하도록 한다. |
| (3) CSRF 요청 스크립트 작성 |
|---|
 |
| ○ form 태그를 통해 비밀번호 파라미터 작성후 XSS 취약점을 통해 요청을 전송하도록 작성 |
 |
| ○ 실행결과, Referer(게시글)에서 비밀번호 변경 요청이 전송되는 것을 확인할 수 있다. |
| (4) 대상에게 게시글 링크 전달 |
|---|
 |
| ○ 링크 방문 결과, 공격을 눈치챔. |
| (5) CSRF 공격 강화 |
|---|
| ○ 작성한 게시글에서 CSRF 공격을 눈치채지 못하도록, 요소를 하나씩 수정하고자 한다. ● 먼저 기존에 작성한 게시글을 살펴보자. |
 |
 |
| ○ 게시글을 클릭하였는데, 회원 정보 수정 알림이 뜨면서 페이지도 마이페이지로 이동이 되어버린다. |
| ● 따라서 게시글 내에서 요청은 보내되, 알림이나 페이지 요청은 보이지 않도록 설계한다. |
| ○ 이는 iframe을 활용한다. |
 |
| ○ iframe을 추가하여, form태그로 인한 요청의 결과를 iframe에게 보내도록 함으로써 현재 페이지에는 영향이 없도록 작성하였다. |
 |
| ○ 실행결과, 페이지 이동은 없었으나 추가한 iframe이 게시글 내용에 보이고 있다. 이 또한 보이지 않도록 다시 작성한다. |
 |
| ○ iframe의 style 속성을 "display:none"으로 하여 표시되지 않도록 설정한다. |
 |
| ○ 실행결과, iframe 창은 보이지 않으나 여전히 회원 정보 수정 알림창이 표시되고 있다. |
| ● 알림창이 표시되지 않도록 iframe 속성을 다시 설정한다. |
 |
| ○ iframe 의 sandbox 속성을 "" 으로 지정함으로써 자바스크립트가 동작하지 않도록 해주었다. |
 |
| ○ 실행결과, 정상적인 게시글처럼 보이게 된다. 그러나 해당 게시글로부터 비밀번호 변경 요청이 전송되게 된다. |
 |
| ○ 해당 게시글로부터 비밀번호 변경 요청 전송 |
| (6) CSRF 공격을 수행하여 계정 탈취 |
|---|
 |
| ○ 관리자가 해당 게시글에 방문하였다. 즉, 작성한 스크립트에 따라 해당 계정에 비밀번호가 123으로 변경되게 된다. |
|
| ○ 아이디와 변경된 비밀번호로 로그인을 하여 계정 탈취 |
 |
| ○ 로그인에 성공하여 flag가 출력되었다. |
[GET Admin 3]
| 주어진 문제는 다음과 같다. |
|---|
 |
| 과정 설계 |
|---|
| 1. 계정을 탈취하기 위해서는 비밀번호를 공격자가 원하는 값으로 지정해야 한다. 따라서 비밀번호 변경 페이지에서 CSRF가 있는지 확인한다. |
| 2. 비밀번호 변경 페이지의 데이터 전송방식에 GET 방식이면 링크 전달, POST 방식이면 XSS취약점 연계로 CSRF를 수행한다. |
| 3. 이용자가 링크에 접근하여 비밀번호 변경 요청을 보낸것이 확인되면, 해당 계정으로 로그인하여 계정을 탈취한다. |
| (1) CSRF 취약점 확인 |
|---|
 |
| ○ 로그인 > 마이페이지에서 정보를 수정하여 패킷을 살펴보았다. |
 |
| ○ 입력한 파라미터 외에 csrf_token 값을 같이 전달하고 있는 것을 확인할 수 있다. |
 |
| ○ csrf_token 값이 잘못된 경우, 요청이 처리되지 않는것을 확인할 수 있다. |
| ● 그렇다면, csrf_token 값은 어디에서 발행되는지 살펴보았다. |
 |
| ○ 마이페이지에 방문할때, 보이지 않는 input 태그의 value 값으로 csrf_token 값을 할당받는것을 확인할 수 있다. |
| ● 따라서, CSRF 요청을 보낼때 해당 토큰값도 추출하여 같이 보내도록 해야 한다. |
| (2) XSS 취약점 확인 |
|---|
| ○ 정보 수정 요청의 데이터 전송 방식이 POST방식이므로 링크 전달 방식의 공격기법은 불가능하다. ● 따라서 XSS취약점을 연계하여 CSRF 공격을 수행하도록 하여야 한다. |
 |
| ○ 공지사항 > 글쓰기 페이지에서 제목과 내용 입력칸에 스크립트를 작성한다. |
 |
| ○ 실행결과, 제목과 내용에서 모두 스크립트가 실행되며 XSS 취약점이 존재하는 것을 확인하였다. |
| ● 여기서는, 내용 부분의 XSS 취약점을 연계하기로 한다. |
| (3) XSS 1단계 - csrf_token 값 가져오기 |
|---|
| 먼저 마이페이지에 접근하여 csrf_token 값을 가져오는 XSS 스크립트를 작성하도록 하고자 한다. |
 |
| ○ 개발자 도구를 통해 csrf_token 값이 있는 태그를 확인한다. |
| ● 접근할 DOM 객체는 name 속성값이 csrf_token인 input 태그 값이다. |
 |
| ○ DOM 객체 접근을 통해 가져올 데이터가 정상 출력되는 것을 확인하였다. |
 |
| ○ 게시글의 XSS 취약점을 통해, csrf_token 값을 가져오는 스크립트를 작성 |
 |
| ○ 실행결과, 데이터 추출 정상 동작 확인 |
| (4) XSS 2단계 - 비밀번호 변경 요청 스크립트 작성 |
|---|
 |
| ○ (3)과정에서 작성한 csrf_token 값을 가져오는 스크립트와, GET Admin 2번에서 작성하였던 비밀번호 변경 요청을 합친다. |
| ● 이때 가져온 token값을 input태그(name="csrf_token") 의 value 값으로 설정한 후 요청을 전송한다. |
 |
| ○ 게시글 내용 확인 결과, 정상적인 게시물처럼 보이지만 비밀번호 변경 요청이 보내지게 된다. |
 |
| ○ 패킷을 살펴보면, 작성된 게시글로부터 비밀번호 변경 요청이 전송되며, 가져온 csrf_token 값이 세팅된 것을 확인할 수 있다. |
| (5) CSRF 공격을 수행하여 계정 탈취 |
|---|
 |
| ○ 관리자가 해당 게시글에 방문하였다. 즉, 작성한 스크립트에 따라 해당 계정에 비밀번호가 123으로 변경되게 된다. |
|
| ○ 아이디와 변경된 비밀번호로 로그인을 하여 계정 탈취 |
 |
| ○ 로그인에 성공하여 flag가 출력되었다. |
이렇게 두번째 과제인 'CTF 문제 풀기' 과제가 완료되었다.
