안녕하세요 Retain0 입니다. 이번 시간에는 " DVWA " 라는 취약한 웹 애플리케이션을 통한 CSRF 공격을 해보도록 하겠습니다.
CSRF(Cross Site Request Forgery) 이란
-
XSS(Cross Site Script)와 유사한 형태의 공격이며 차이점은 서버 측의 취약점을 공격하여 공격자가 원하는 행동을 하게끔 시키는 것의 차이가 있습니다. 사이트 간 요청 위조라고도 하며 자신의 의지와는 다르게 공격자가 의도한 행동을 스스로 하게끔 해서 특정 웹페이지를 보안에 취약하게 하거나, 수정, 삭제, 자동 패스워드 변경, 자동댓글 등을 하게끔 하는 공격입니다. 이것은 웹 어플리케이션 에서 정상적인 경로와 비정상적인 경로의 요청을 서버가 구분을 하지 못해서 발생하는 취약점이라고 보시면됩니다.
-
과거 2008년 옥션의 개인정보 유출사건에서 관리자가 CSRF 공격을 당해 관리자 계정 및 고객정보가 유출당한 사건
※ XSS(Cross Site Script) 는 클라이언트 측 대상으로 자바스크립트를 실행시키는 것
보통 메일, 게시판에 악성 링크가 삽입된 형태로 공격이 되는데 이러한 공격으로 사용자의 패스워드가 공격자가 지정해둔 패스워드로 변경되게끔 시도할 수가 있습니다.
① Low
(사진 1)을 보시면 패스워드를 변경하는 폼이 보이실 겁니다. 여기서 retain0라는 패스워드를 바꿨다는 가정하에 진행해보겠습니다.
(사진 2) 패스워드 변경 직후 프록시로 잡은 모습입니다.
(사진 1)에 있는 패스워드 변경 페이지의 소스코드를 활용하여 간단한 피싱사이트를 만들어 클릭하게끔 유도해야 하기에 (사진 3) 에있는 소스코드 부분을 긁어오도록 하겠습니다.
(사진 4) welcome to my blog를 작성하여 초대장 형태로 문구를 작성할 것입니다. 그 후 이 소스를 클릭하는 사람들은 모두 " hacked "라는 패스워드로 자동변경되게끔 할 수 있습니다. 패스워드가 자동으로 변경되는 문구를 숨기기 위해 " hidden "이라는 필드를 사용해야 합니다.action 부분은 해당 csrf 폼 부분을 복사해서 가져온 것입니다.
(사진 5) 수정을 끝마쳤으니 txt로 작성했던 파일을 " html " 형식으로 바꿔두도록 하겠습니다.
(사진 6) 해당 소스를 수정함으로 만든 악성 페이지입니다. 테스트를 위해 gmail 계정을 사용해서 스스로에게 한번 보내 본 후 열람을 해보도록 하겠습니다.
(사진 7) 검정 박스로 되어있는 " 여기 "라는 링크에는 공격자의 주소/forgery.html 가 삽입된 상태이기에 이러한 메일을 클릭하게 될 시 자동으로 패스워드가 변경이 되게 됩니다. 만일 실전으로 악용하게 된다면 의심이 전혀 가지 않을만한 사이트로 변조해서 배포될 것이며 링크를 클릭 시 공격자에게도 알림이 가게 되어 변경된 패스워드를 통해 바로 추가 악의적인 수행을 하게 될 것입니다.
링크를 클릭 후 프록시도구를 통해 확인해 본 결과 패스워드가 공격자가 원하는 형태로 변경되어있는 것을 확인할 수가 있습니다.
② Medium
(사진 1) Low 레벨의 방식을 그대로 해본 결과 That request didn't look correct 문구가 뜨며 실패한 것을 확인할 수 있습니다.
(사진 2) 소스코드를 확인해 본 결과 검정 박스 부분에 REFERER 헤더를 검사하는 것을 확인할 수 있습니다.
- REFERER 헤더는 어떠한 요청이 전송될 때 이전에 어떤 경로로 요청이 되었었는지 웹브라우저가 자동으로 설정해주는 헤더 즉 REFERER 주소가 실제 서버 주소와 동일한지 비교해 실제 사용자가 정상적인 경로로 요청한 것인지 확인해줍니다.
Low 레벨에서는 공격자의 주소를 통해 CSRF 공격을 수행했지만 마치 정상적인 서버인 거처럼 동일하게 서버 주소를 사용하여 공격하면 REFERER 헤더의 역할을 우회할 수 있게 됩니다.
(사진 11) 우선 해당 악의적 인사이트를 웹 프록시 도구를 통해 잡아보도록 하겠습니다.
(사진 11)의 악의적인 사이트를 웹 프록시 도구로 잡은 후 (사진 12)처럼 대상 서버 주소를 적어 REFERER 참조를 해주도록 하겠습니다. 이렇게 될 경우 정상적인 사이트로 간주하기 때문에 REFERER 헤더의 필터링을 쉽게 우회가 가능하게 됩니다.
③ High
(사진 14) 어떤 정책을 적용했는지 확인하기 전에 우선 retain0로 패스워드를 변경하는 것을 프록시 도구를 통해 확인을 해보도록 하겠습니다.
(사진 15) 검정 박스를 보시면 패스워드 변경 시 user_token 값이 같이 발급된 것을 확인할 수가 있습니다. 전 단계에서는 공격전과 후의 PHPSESSID(세션 ID) 가 동일하게 재사용되었지만 지금은 세션ID 재사용을 막기 위해 변경 또는 이벤트 발생 시에도 user_token 값을 새로 발급해주기에 전 과는 다른 방법으로 접근해야 합니다.
(사진 16) 우선 Stored XSS 취약점을 발견했다는 가정하에 진행하도록 하겠습니다. 실전에서는 다양한 사용자들이 클릭하게 하기 위해 각종 이벤트, 사은품, 공지사항 필독 등과 같이 다양한 방법을 통해 접근할 것입니다. 또한 CSRF 기법을 사용하여 악의적인 스크립트가 담겨있을 경우 게시판을 열람하기만 해도 자동으로 패스워드가 변경될 것입니다.
(사진 17) 소스코드 안에서는 외부 서버 주소 + user_token 값을 재활용할 수 있는 문구들이 들어가 있습니다. 사진을 보시면 function req1 , function req2 즉 총 2번의 요청을 보내는데 req1 은 이벤트 시 발생하는 user_token 값을 요청하며 req2는 user_token 값을 뽑아내어 해당 토큰을 마지막 요청에 함께 보내도록 해줍니다.
(사진 18) 사용자가 이러한 게시판을 클릭하는 순간 공격자가 원하는 형태로 패스워드가 변경이 되고 (사진 17)의 alert 부분에 적힌 found the token이라는 메시지와 함께 쿠키값을 도출시키게 해 줍니다. 지금은 테스트이기에 자신의 pc화면에 값이 그대로 나오지만 실전에서는 무슨 일이 발생했는지 인지하기 어려우며 도출된 쿠키값은 공격자에게 전달되도록 할 것입니다.
※ 입력 폼에 최댓값 길이가 정해져 있다면 " 개발자 도구 " 에서 최대 입력값을 수정하고 작성해주면 됩니다.
◆ 대응방안
(사진 20)을 보시면 패스워드를 변경하기 전 기존의 패스워드를 재입력하는 폼이 생긴 것을 확인하실 수가 있습니다. CSRF에 대해 방어하기 위해 좋은 대응방안이며 이렇게 된다면 공격자는 사용자의 기존 패스워드를 알고 있지 않은 이상 CSRF 공격을 성공시키기 어려워집니다. 또한 CAPTCHA 기능을 추가해서 변경 시 인증 또는 식별을 한 번 더 하는 것이 좋습니다.
'IT Security > DVWA(Damn Vulnerable Web App)' 카테고리의 다른 글
| [DVWA] insecure CAPTCHA (0) | 2020.04.23 |
|---|---|
| [DVWA] File Upload Vulnerability (0) | 2020.04.21 |
| [DVWA] File inclusion (0) | 2020.04.20 |
| [DVWA] Command Injection (0) | 2020.04.18 |
| [DVWA] Brute Force Attack (1) | 2020.04.17 |
