CSRF공격

오늘은 CSRF 공격에 대해 배워보겠습니다.

CSRF는 Cross Site Request Forgery 의 약자로 사이트 간 요청 위조로 해커들이 피싱을 활용하여 사용자 모르게 패스워드를 변경하거나 하는 공격기법입니다. 피싱이라는 것은 사회 공학 기법 중 하나로 이메일이나 게시판을 이용해 은행이나 대기업인 척 하면서 사용자들을 낚는 것 입니다. 옥션 해킹 사건에서 이용된 공격이기도 합니다. 

 

CSRF 공격 단계

 

1. 정상 접송 및 로그인

2. 해커의 피싱 (ex : 클릭하여 보안 강화 바랍니다.)

3. 패스워드 변경 요청 (사용자도 모르게 패스워드 변경)

4. 변경된 패스워드로 접속

 

피싱만 하면 난이도 자체는 쉬운 공격에 속합니다. 하지만 피싱을 당할때 사용자가 로그인이 되어 있어야합니다. 요즘 같은 경우 많은 탭에 로그인이 된 상태에서 사용하기 때문에 CSRF 공격에 당하기 쉽습니다. 그러므로 사용자 입장에서 CSRF 를 예방하기 위해서는 모르는 태그를 클릭하지 않고 로그아웃 하는 습관을 가지는 것이 좋습니다. 

 

 

 

이제 CSRF 실습을 시작하겠습니다. 버프스위트를 준비해주시고 보안단계를 'LOW'로 해주시고 CSRF 탭으로 가주세요.

비밀번호를 변경하는 화면

일단은 비밀번호를 변경하는 과정에 대해 알아보겠습니다.

 

패스워드를 normal 로 바꾸고자 하는 작업입니다. password_new 와 password_conf 가 normal로 두번 세팅 되어있습니다. Change 파라미터도 세팅되어 있습니다. 만약 다른 링크를 눌렀을 때 이 요청이 전달되면 패스워드가 변경될 수 있습니다. 필요조건은 로그인 되어 있는 상태여야 한단 겁니다. 그 이유는 로그인 되어 있어야 세션 쿠키 값이 요청에 자동으로 포함되기 때문입니다. 세션 쿠키 값이 포함되어있어야 사이트가 '로그인 되어 있으니 변경해도 괜찮겠군 '하면서 패스워드를 변경해주기 때문입니다. 

 

일단 이 상태를 하이라이팅 해봅니다. 

 

먼저 터미널에 'wget https://raw.githubusercontent.com/SecuAcademy/webhacking/master/csrf.html' 를 입력해여 예제 파일을 다운로드 받습니다. 

 

직접 깃허브에 들어가서

csrf.html 을 누르고 Raw 를 누른 후 url 을 복사하셔도 됩니다. 

 

터미널에서 '/opt/lampp/htdocs/' 로 옮겨 줍니다. 이 폴더로 가면 웹으로 접근할 수 있습니다.  'cp'는 파일을 위치대로 복사해주는 리눅스 명령어 입니다. csrf.html 파일을 살펴보겠습니다.

코드를 확인해보면 자바스크립트에 Ajax 기법을 이용하여 방금 프록시 히스토리에서 본 거처럼 url 와 파라미터를 똑같이 구성합니다. 단 password_new=hacker&password_conf=hacker 이렇게 되어있는데 공격에 성공하면 패스워드가 이렇게 바뀌게 됩니다.  아래 부분에는 링크를 누르면 클릭을 하면 요청이 dvwa 로 전송이 되도록 돼 있습니다. 보통 csrf 시연을 할 때 'html' 폼을 사용합니다. 이러면 공격 성공 이후에 패스워드 변경 페이지로 전송되기 때문에 사용자가 파악할 수 있습니다. 실제로 해킹때는 Ajax를 사용하여 사용자를 완벽하게 속일 수 있습니다. 

 

 

자 이제 메일로 피싱을 해보겠습니다. 반드시 본인의 이메일로 해야지 남의 이메일로 피싱을 해서는 안됩니다!

이 링크를 삽입시킵니다. 

메일을 보내서 확인해보면

이걸 또 클릭해보면 'Done'이라는 화면창이 뜨는데 dvwa 로 들어가서 로그아웃 후 다시 (admin,password) 나(admin,normal) 이 쳐지지 않고 (admin,hacker)로 바뀐 것을 볼 수 있습니다. CSRF 공격에 성공한 겁니다.

 

done 화면창이 떴을 때 요청과 그전에 하이라이트 했던 요청과 비교를 해보겠습니다. Ctrl 로 둘 다 선택한 후 

send to Comparer(requests)를 누릅니다. 

 

Comparer 탭에 가시면 두개의 리스트가 있습니다. 오른쪽 밑 'words'를 누르면 밑의 화면처럼 다른 점을 분석해줍니다. 

 

보시면 거의 동일하고 쿠키 값이 동일한 걸 볼 수 있습니다. 방금 전에 말했듯이 쿠키 값이 동일하면 사이트에선 의심을 하지 않습니다. 그 외에도 Referer 이나 Origin 부분이 다릅니다. 모두 현재의 요청이 어디서 시작되었는지 알려주는 헤더입니다. 정상적인 요청에선 localhost 고 왼쪽은 127.0.0.1(해커 사이트라고 가정) 인 거를 보면 됩니다. Origin 헤더도 Referer과 비슷하지만 CORS 라는 접근제어에 관련된 헤더입니다. 

 

 

 

자 이제 미디엄 단계로 가보겠습니다.

똑같이 피싱을 누르고 click 을 눌렀을 때

response의 render 로 가시면 화면을 볼 수 있는데 내려보면 패스워드 변경에 실패한 것을 볼 수 있습니다. 

소스코드를 보겠습니다.

 

보면 HTTP_Referer 변수가 있는데 이게 referer header 를 검사하는 겁니다. Referer 는 이전 어떤 경로로 부터 요청되었는지를 알려주기 위해 웹브라우저가 기본으로 설정하는 헤더입니다. 해커가 자기 사이트를 이용해서 CSRF 를 하게되면 위에서 '127.0.0.1'설정한 거 처럼 해커의 사이트 주소가 referer에 저장되게 됩니다. 개발자는 이 값을 사이트와 동일한지 확인함으로서 csrf 공격을 대응할 수 있습니다. 하지만 이는 완벽하지 않습니다. 만약 공격이 웹사이트 내에서 공격하게 되면은 우회할 수 있습니다. csrf.html 을 생각해보면 자바스크립트로 요청을 보냈죠? 만약 웹페이지에서 어떤 경로에서 html 을 실행할 수 있다면 referer 헤더에 동일 웹사이트의 주소가 입력되기 때문에 이 대응이 무용지물의 될 수 있습니다. 

또 한가지의 문제점은 'eregi' 라는 함수를 쓰고 있는데 이는 앞에 문자열이 뒤에 문자열에 포함되어 있는지  검사하는건데 이 경우에는 서버 주소가 referer 헤더내에 포함되어 있는지 확인하는 겁니다. 하지만 이 같은 경우 정말 포함만 되면 되기 때문에 쉽게 우회할 수 있습니다. 

 

 

터미널에서 csrf.html 이름을 csrf_localhost.html 로 하나 더 복사해줍니다. 그리고 

이렇게 수정해주고 클릭을 누릅니다.

프록시 히스토리에서 요청을 확인해보겠습니다.

Referer 에 localhost 가 포함된 것을 볼 수 있습니다. 이때의 response의 render을 확인해보겠습니다.

 

패스워드가 변경되었습니다.

 

로그아웃하고 확인해보면 패스워드가 hacker로 변한 것을 알 수 있습니다. referer 헤더를 비교할 경우에는 앞에서 부터 정확하게 비교를 해줘야합니다. 앞에처럼 포함 관계로 검사를 한다면 쉽게 우회할 수 있습니다. 

 

 

 

 

 이 공격에 HIGH 단계에서는 CSRF 뿐만 아니라 XSS 공격 실습을 함께 쓰기 때문에 나중에 포스팅을 새로 하겠습니다. 감사합니다!

 

공격대응법을 알고 싶으시다면 다음 포스팅을 클릭해주세요ㅎㅎ

 

https://com24everyday.tistory.com/35

CSRF 공격대응