제 5 장 어플리케이션 점검 방법
제1절 웹 어플리케이션 보안 점검 도구
1. 웹 취약점 스캐너
웹 취약점을 점검하기 위해서는 우선 자동화 스캐너 도구를 통해 일반적으로 알려진 취약점들을 점검해 보아야 한다. 스캐너 도구를 이용한 점검은 기존에 잘 알려진 취약점, 디렉토리 리스팅 취약점이나 백업파일 존재 여부 등 단순 작업이지만 수동으로 점검했을 때 시간이 오래 걸리는 취약점들을 점검 해준다. 또한 수동점검 때 놓칠 수도 있는 취약점들을 찾아주기 때문에 수동점검 전에 자동화 도구를 이용한 점검이 꼭 필요하다.
● 공개용
아래와 같은 공개용 웹 스캐너와 공격 도구가 존재하며 스캐너들은 상용에 비교해 기능면에서 많이 뒤떨어지지만 유용한 취약점 정보들을 얻을 수 있다. 그리고 Ad와 NBSI는 SQL Injection 전문 공격 도구이며 윈도우즈 IIS 기반 asp 스크립트를 사용하는 서버 점검에 활용하는 것도 좋은 방법이다. (NBSI 등과 같은 중국산 공격툴은 DB에 특정 table 및 유저를 생성하거나, 시스템에 악성 코드를 주입하므로 점검 후에 반드시 제거하도록 한다.)
다운로드 : http://www.cirt.net/nikto/nikto-current.tar.gz
http://downloads.sourceforge.net/paros/paros-3.2.13-win.exe?modtime=1155077924&big_mirror=0
https://www.sensepost.com/restricted/wikto_v1.63.1-2279.zip
http://www.0x90.org/releases/absinthe/Absinthe-1.4.1-Windows.zip
2. 웹프록시 도구
4년 전에는 웹 프록시 기법을 사용해 공격하는 것은 고급 해커들 사이에서 사용하는 고급 기술이었지만 최근에는 이러한 기술을 자동화 해주는 도구들이 많이 등장해 일반 사용자들도 쉽게 점검이 가능하다.
● Internet Explorer(이하 IE) 설정
프록시 도구를 사용하기 위해서는 먼저 IE 세팅이 필요하다. 이 설정은 원격 프록시 서버를 설정하는 방법과 거의 유사하다.
* IE -> 도구 -> 인터넷옵션 -> 연결 -> LAN설정 -> 프록시서버
아래 그림과 같이 프록시 서버를 로컬호스트(localhost)와 점검 도구인 Paros에서 사용하는 포트인 8080 포트로 설정을 하면 Paros 점검 툴을 이용해 HTTP Request, Response 값들을 가로채 데이터 위변조가 가능하게 된다.
● 프록시 자동화 도구 Paros 사용법
홈페이지 : http://www.parosproxy.org
다운로드 : http://downloads.sourceforge.net/paros/paros-3.2.13-win.exe?modtime=1155077924&big_mirror=0
관련 파일을 설치하기 전 JRE(Java Run Time Environment) 1.4가 설치되어 있어야 하며 클라이언트 측으로 전달되는 데이터들을 모두 캡쳐하기 위해서는 아래와 같이“Trap” 탭에 관련된 세팅을 해준다. 이후 특정 페이지를 중간에서 캡쳐하고자 할 때 앞서 했던 IE Proxy 설정을 하게 되면 캡쳐된 결과를 확인할 수 있고 위변조 후“Continue”를 클릭하면 웹서버, 클라이언트와의 통신을 계속 할 수 있게 된다.
3. 쿠기 조작 프로그램(Cooxie Toolbar)
홈페이지 : http://www.diodia.com/cooxietoolbar.htm
다운로드 : http://www.diodia.com/Ddt24Setup.exe
Cooxie Toolbar는 웹브라우저에 툴바 형태로 설치되며 쿠키를 조작할 때 유용하게 사용 할 수 있는 도구이다. 프록시 도구를 사용하기 위해 IE에서 따로 프록시를 설정할 필요 없이 아래에서 보는 것처럼 손쉽게 프록시를 설정할 수 있게 도와준다.
제2절 SQL Injection 점검
일반적으로 웹 어플리케이션은 사용자에 정보를 입력하는 사용자 로그인 정보 입력란 이라든가 게시판 조회란, 게시판 게시물 번호 등 같이 사용자에게 입력, 조회 할 수 있는 인터페이스를 제공한다. 웹 어플리케이션 사용자 인터페이스의 정보는 데이터베이스에 접근할 수 있는 쿼리문으로 전달되는데 공격자는 이렇게 전달되는 쿼리문을 조작하여 데이터베이스를 조회, 조작할 수 있으며 시스템 까지도 장악할 수 있게 된다.
1. 점검대상
● 로그인 폼
● 게시판 글 조회란
● 게시판 글, 상품목록 URL
● 회원가입 페이지 id 조회란
● 우편번호 조회란 등
● MS-SQL 확장 프로시저
2. 점검방법
● 로그인 폼 점검
SQL Injection 취약점 점검 첫 번째 대상은 로그인을 위한 아이디, 패스워드를 입력란부터다. 먼저 아이디 입력란부터 점검을 해야 하는데 아래에 ①처럼 먼저 ´문자열을 입력해서 오류 페이지가 발생하는지 점검한다. 0x80040E14에러가 발생한다면 취약점이 존재하는 것으로 소스를 수정할 필요가 있다.
만약 취약점이 존재하더라도 에러페이지가 발생하지 않도록 해 취약점을 확인할 수 없는 경우가 있으므로 ②번과 같이 아래 표에 있는 문자열들을 입력해 아이디 검사를 우회할 수 있는지 점검해야 한다. 다음은 패스워드 입력 부분을 점검하는데 아이디 테스트처럼 ´를 입력하는 것부터 같은 순서로 하되 ③번과 같이 본인이 알고 있는 아이디나 추측되는 아이디를 함께 아래 표와 같은 인젝션 문구를 입력해 패스워드를 모르고도 로그인이 되는지 확인해야 한다.
공격에 사용될 문자열들은 아래와 같다.
● 게시판 글 URL 조회
게시판 URL에 DB 쿼리문을 조작할 수 있는 Single Quotation 문자인 ´를 입력해서 오류페이지가 발생하는지 점검해야 한다. 아래 그림 key_id=joke´와 같이 DB 조회에 사용되는 게시판 명을 나타내는 값에는 반드시 ´를 붙여 에러메시지가 나타나는지 점검해야 한다. 아래는 bbs_no=1 글 순서 값에 ´문자를 입력해 오류메시지를 확인하는 그림이다.
● 기타
DB를 통해 조회해야 되는 인터페이스 즉 게시판 글 조회란, 회원가입 id 조회란, 우편번호 조회란 등에 모두 Single Quotation 문자인 ´를 입력해서 0x8004E14와 같은 에러가 발생하는지 점검해야 한다.
제3절 XSS (Cross Site scripting) 공격 점검
자바스크립트처럼 클라이언트 측에서 실행되는 언어로 작성된 악성 스크립트 코드를 웹페이지, 웹 게시판 또는 이메일에 포함시켜 이를 열람한 사용자 컴퓨터에서 악성 스크립트가 실행되게 하고 사용자의 개인정보 등을 유출시키는 공격이다.
1. 점검 대상
● 게시판 (제목, 작성자, 메일주소, 글 입력 란)
● 모든 조회 폼
● URL
2. 점검 방법
● 게시판
게시판에 HTML 사용이 가능하다면 다음과 같은 자바 스크립트를 입력해 악성 스크립트 문자열 필터링을 수행했는지 점검해야 한다. 게시판에 글 입력 폼뿐만 아니라 제목, 이메일 등을 입력하는 곳에도 점검이 필요하다.
입력스크립트: <script> alert“( test”); </script>
만약 작성자, 메일 주소 같은 경우는 입력 글자 수 제한이 걸려 있는 경우가 많다. 이러한 경우는 Proxy를 사용해서 관련 자바스크립트를 삭제하거나 HTML input 태그에서 제공하는 maxlength가 존재 하는데 관련 값을 조정한 후 스크립트를 입력한다.
● 모든 조회 폼
아래와 같이 검색할 수 있는 모든 입력란도 점검이 필요하다.
● URL 점검
URL을 보면 GET 메소드로 넘어가는 파라미터들 사이에 XSS 스크립트를 삽입해 쿠키, 세션 값을 유출 시키거나 정상 사이트 링크처럼 보이지만 피싱 사이트로 유도하도록 할 수 있다. 점검 방법은 아래와 같다.
http://www.hacking.com/common/pop_print.jsp?title=<script>alert“( test”);</script>
● 우회 방법 점검
이미지 삽입을 통한 XSS 공격
<IMG SRC=“javascript:aler‘t(XSS’);”>
<IMG SRC=javascript:aler‘t(XSS’)>
<IMG SRC=JaVascRiPt:aler‘t(XSS’)>
UTF-8 유니코드 인코딩
<IMG SRC=javascript&#
58;alert('XSS')>
세미콜론 없는 Long UTF-8 유니코드 인코딩
<IMG SRC=javasc ript:al& #0000101rt('XSS')>
세미콜론 없는 Hex 인코딩
<IMG SRC=javascript:alert('XSS')>
문자열 사이 Tab 문자열 입력 (인코딩된 TAB 문자열 입력 포함)
<IMG SRC=“jav ascript:aler‘t(XSS’);”>
<IMG SRC=“jav	ascript:aler‘t(XSS’);”>
<IMG SRC=“jav
ascript:aler‘t(XSS’);”>
<IMG SRC=“jav
ascript:aler‘t(XSS’);”>
이외 다양한 방법 존재
INPUT태그를 이용한 삽입
<INPUT TYPE=“IMAGE”SRC=“javascript:aler‘t(XSS’);”>
BODY태그를 이용한 삽입
<BODY BACKGROUND=“javascript:aler‘t(XSS’)”>
<BODY onLOAD=aler‘t( XSS’)>
Link, Style 태그를 이용한 삽입
<LINK REL=“stylesheet”HREF=“http://ha.ckers.org/xss.css”>
<STYLE>@impor‘t http://ha.ckers.org/xss.css’;</STYLE>
제4절 파일업로드 공격
첨부파일 업로드 기능을 악용하여 웹 쉘 (WebShell)과 같은 해킹 프로그램을 업로드한 후, 이를 실행하여 웹서버 권한을 획득하는 공격방법이다. 이 공격이 성공하게 되면 시스템을 장악할 수 있기 때문에 기본적인 테스트부터 우회 방법까지 여러 가지 수단과 방법을 통해 점검을 시도해봐야 한다.
1. 점검 대상
- 게시판 첨부파일 기능
2. 점검 방법
아래와 같은 스크립트 파일을 작성하여 게시판 파일 업로드 기능을 제공하는 곳에 파일이 업로드가 되는지 확인하여야 한다.
● cmd.php
● cmd.asp
● cmd.jsp
위와 같은 기본적인 스크립트 확장자 외에 아래와 같이 파일 확장자를 변경해서 테스트해야 한다.
asp : html, htm, asa, hta
php : inc, html, shtml, cgi, pl, php3, php4
쉽게 테스트 할 수 있는 방법은 앞서 기술된 웹쉘 확장자를 html이나 위의 파일명으로 변경하고 업로드해 스크립트를 실행해 본다.
웹쉘 파일이 업로드가 돼서 게시판에 등록되면 업로드된 파일을 실행하면 스크립트가 실행되는 경우도 있지만 거의 대부분은 다운로드 되게 된다. 링크 속성을 통해 전체적인 경로를 확인해서 직접 URL을 IE 주소 부분에 입력하고 실행해야 한다.
- 우회 공격
확장자 변경
우선 홈페이지 스크립트를 확인한 후 관련 웹쉘 스크립트 파일 업로드를 시도하고 필터링을 지원할 경우 필터링 대상이 되지 않는 jpg 확장자를 중간에 넣은 파일명 “( cmd.jpg.jsp”)으로바꿔업로드를시도한다. 이와같이테스트하는경우는가끔개발자들은 확장자 검사를 파일명 앞에서부터 시작하는 실수를 범해 이를 공격하기 위해서다.
또한 개발자들이 소문자 파일 확장자를 체크하는 실수를 이용하기 위해 확장자를 jSp,Jsp, aSp, Asp 등 대문자로 변경해 테스트를 시도해야 한다.
클라이언트 측 필터링 제거
업로드 우회 또 다른 방법으로 필터링 자바 스크립트가 클라이언트 측에서 구동되는 취약점을 공격하기 위해 서버에서 클라이언트로 HTML 소스가 넘어오기 전에 필터링 부분을 수정해 공격을 시도한다.
웹 해킹 도구인 Paros를 통해 서버에서 클라이언트로 넘어오는 페이지들을 모니터링 하고 그중에 업로드 확장자 체크하는 코드 부분을 수정해 웹쉘 업로드를 시도한다.
아래는 Paros를 이용 클라이언트 측 소스에 필터링 하는 코드를 변경하는 그림이다.
제5절 쿠키 값 변조 공격
웹 서버에서 사용자 측에 생성하는 쿠키를 이용해 웹 프록시와 같은 도구를 이용하여 조작해 다른 사용자로 변경하거나 관리자로 권한 상승하는 공격을 할 수가 있다.
1. 점검 대상
- 쿠키
2. 점검 방법
● 쿠키에 존재하는 id 변경
보안에 취약한 사이트의 경우 쿠키에 존재하는 사용자 계정명이나 등급을 저장하고 이를 신뢰하기 때문에 이를 조작하여 타 사용자 또는 관리자로 권한 상승을 할 수 있으며 인증을 우회 할 수도 있다. 아래 그림은 관리자 계정으로 자주 사용되는 admin이나 webmaster를 로그인 인증 부분에 넣어 존재하는지 확인한 후에 원래 아이디 값을 관리자 계정으로 변경시켜 권한 상승 시키는 화면이다.
● 쿠키에 따른 코드 값 변경
그림과 같이 특정 필드 값이 사용자의 index값을 가지는데 이 값만을 통하여 사용자를 구분하는 경우 쉽게 인증 우회가 가능하다.
편집용 도구(직접 변경해도 관계없음)를 사용하여 위의 값을 변경하면, 아래의 그림과 같이 자신의 원하는 사용자로 인증이 가능하다.
● 간단히 인코딩 되는 경우
아래 쿠키 값은 앞의 코드 값 경우와 마찬가지로 MEMBER_ID, MEMBER_NO 값이 세션을 구분하고, 사용자를 구분하고 있다. 이 경우는 MEMBER_ID에 MEMBER_NO값이 맞는 값을 넣어야만 권한 상승이나 인증 우회할 수 있다.
이러한 기본적인 과정은 앞의 경우와 동일하나 직접 index값이나 문자를 사용하지 않고,
base64로 인코딩하여 쿠키에 저장하였다.
● 쿠키의 필드 값이 여러 개일 경우
이런 경우 공략하기가 쉽지 않다. 너무 많은 필드 값이 사용되고 있기 때문에 어떤 값들에 의해 세션을 구분하고 사용자들을 구분하는지 확인하기가 쉽지 않다. 우선 아래의 그림을 보면 너무 많은 필드 값이 존재 하므로 가장 관련이 깊을 것 같은 cacUID, cacID 두개의 값을 갖고 공략한다.
여기서 유효한 값은 대부분 식별자, 아이디, 비밀번호 등의 값들이 사용됨으로 적절히 조합해보아야 한다. 주의할 점은 적절치 못한 필드 값을 변조할 경우, 세션이 손상되는 경우가 발생할 수도 있다. 그림에서는 cacUID, cacID를 동시에 변경해 주어야 admin 권한으로 권한 상승 될 수 있다.
제6절 웹 프록시를 이용한 취약점 점검
웹 프록시 도구는 최근 해킹 공격에 가장 활발히 사용되고 있는 도구로 클라이언트가 요청한 HTTP Request, Response 정보를 중간에 도구를 통해 가로채 필터링을 우회하거나 서버에 전송되는 데이터를 조작해 허가되지 않는 곳에 정보를 훔쳐보거나, 쓰기 등이 가능하다.
1. 점검 대상
- 게시판
- 인증
2. 점검 방법
● 권한이 없는 게시판 글쓰기
게시판에는 공지사항, 자유게시판 등 여러 가지가 존재하지만 각기 기능에 따라 권한이 분류되어 일반 사용자는 공지사항 게시판에 글 내용 확인은 가능하지만 쓰지는 못하게 되어 있다. 대부분 권한 없는 게시판에 사용자가 글을 쓰려 하면 권한 확인 후 일반 사용자에게는 글을 작성할 수 없도록 인터페이스를 제공하지 않는 게 일반적인 방식이다. 하지만 공격자는 권한이 있는 일반 자유게시판 글 작성하고 나서 전송되는 HTTP Request를 프록시로 가로채 미리 알아낸 공지사항 게시판의 URL로 변경하여 글을 등록 할 수도 있다.
● 권한이 없는 게시판 글 읽기, 수정
개발자의 실수로 게시판의 권한 검사를 Get 메소드에 넘어오는 인자 값(ex. idx, u_id)등을 통해 권한 체크하는 경우가 있다. 이러한 경우는 인자 값을 조작하여 권한이 없는 게시판의 글을 읽을 수 있는지 점검해야 한다.
● 기타
몇몇 잘못 설계된 홈페이지들은 아이디, 패스워드 길이 제한이나 잘못된 주민번호 검사하는 코드를 클라이언트 측의 자바스크립트로 검사하는 경우가 많다. 이러한 경우 Proxy 도구를 통해 클라이언트 측으로 전송되는 코드를 수정하거나 또는 웹서버로 전송 되는 데이터 중에서 관련 내용을 조작할 수 있게 된다.
아이디, 패스워드 길이 제한 우회
아래 그림과 같이 웹서버에서 클라이언트 측으로 전송되는 응답을 가로채서 관련 스크립트를 제거해서 우회할 수 있다.
잘못된 주민번호 입력
다음은 회원가입 페이지에서 완료를 해 웹서버에 POST로 전송되는 데이터를 중간에 가로채 주민등록번호를 변조 하는 화면이다.
제7절 파일 다운로드 공격
홈페이지 상에서 파일 열람 또는 다운로드를 위해 입력되는 경로를 체크하지 않을 때 웹서버의 홈 디렉토리를 벗어나서 임의의 위치에 있는 파일을 열람하거나 다운로드 받는 공격이다.
1. 점검 대상
- 디렉토리 탐색
2. 점검 방법
자료실에 올라간 파일이나 웹에서 파일을 다룰 때 파일명을 적절하게 체크하지 않아 공격자가‘../’와 같은 파일명 앞에 상위 디렉토리로 올라가는 문자를 입력해‘../../../../../../etc/passwd’와 같이 시스템의 중요한 파일을 다운받을 수 있는지 점검해야 한다. 또한 개발자들이 흔히 사용하는 DB 접속 설정 파일을 다운로드 받거나 특정 파일들을 다운로드 받는데 활용될 수 있는지도 점검해야 한다.
보통 파일을 다운 받을 때 전용다운로드 프로그램을 이용해 다음과 같이 입력한다.
http://www.domain.com/bbs/download.jsp?filename=테스트.doc
그러나 여기서 테스트.doc 대신 다음과 같이 시도하면 /etc/passwd를 다운로드 받을 수 있다.
http://www.domain.com/bbs/download.jsp?filename=../../../../../../etc/passwd
또한 해당 어플리케이션의 주요 파일들을 다운받아 어플리케이션의 구조를 파악하여 취약점을 찾아내거나 데이터베이스 접속 정보를 담고 있는 파일을 다운로드 받을 수 있다.
http://www.domain.com/bbs/download.jsp?fname=upload_ok.jsp
http://www.domain.com/bbs/download/jsp?fname=../include/dbconn.inc
제8절 미등록 확장자
웹서버는 해당 엔진에서 해석해야 되는 확장자를 사전에 등록시켜 놓아야 한다. 기본적인 확장자(asp, jsp, php)들은 모두 등록을 하지만 개발자의 편의나 분류의 목적으로 .inc, .php, .txt 등과 같은 예외적인 확장자를 사용하는 경우가 다수 있다. .inc와 같은 확장자를 갖는 파일들은 데이터베이스 접속 정보를 담고 있는 경우가 많아 공격자가 이러한 파일을 유추해 요청할 경우 일반 텍스트로 모든 정보가 노출되게 된다.
1. 점검 대상
- 미등록 확장자 파일 (.inc)
2. 점검 방법
아래 표는 개발자들이 설정파일들을 위치시키는 디렉토리와 DB 접속 설정을 하는 파일명을 정리한 것이다.
이 두 가지를 결합해서 DB 설정파일을 유추해 볼 수 있고 아래와 같이 파일이 존재할 경우는 관련 설정 내용을 모두 확인할 수 있다.
확인된 DB 정보를 통해 원격에서 DB에 직접 접속이 가능하고 관련 데이터 확인 가능한지 검사도 해야 된다.
제9절 불필요한 파일 존재
일반적으로 관리자는 홈페이지 상에서 작은 수정을 위해 기존 홈페이지 파일의 원본을 임시로 저장할 수 있다. 이 같은 경우
1. 점검 대상
- 백업파일
2. 점검 방법
불필요한 파일들을 점검할 수 있는 가장 편한 방법은 웹 취약점 스캐너를 실행시켜 결과를 확인하는 것이다. 대부분의 스캐너들은 메인페이지에 속한 링크들을 계속 따라가며 파일명에 .bak 나 .old 등 백업 파일명을 붙여 실제 존재하는지 검사하기 때문에 수동으로 점검하는 것보다 훨씬 시간을 줄일 수 있다. 또한 일반적으로 개발자들이 흔히 사용하는 테스트 페이지들을 찾아내는 노력도 필요하다.
제10절 디렉토리 리스팅 취약점
디렉토리 리스팅 취약점은 잘 못된 서버 설정으로 인해 발생하는 취약점으로 현재 브라우징 하는 디렉토리의 모든 파일들을 사용자에게 보여 주게 된다. 공격자는 이러한 취약점을 이용 파일들을 확인할 수 있고 DB 접속과 관련된 설정파일이라든가 백업 파일들을 확인할 수 있다.
1. 점검 대상
- 디렉토리
2. 점검 방법
디렉토리 리스팅 취약점 점검은 먼저 메인 페이지를 접속 후 메인 페이지가 존재하는 디렉토리를 시작으로 메인 페이지에 존재하는 링크를 따라가며 각 디렉토리를 차례로 점검해야 한다. 또한 링크는 존재하지 않지만 쉽게 예측 가능한 test, admin, manager 등도 점검해야 한다. 하지만 위 과정을 수동으로 하기엔 많은 시간이 소요되기 때문에 자동화 취약점 스캐너 툴을 이용해 쉽게 점검하는 방법이 있다.
- 메인 페이지 확인
http://hacking.com/main/main.asp
- 메인 페이지 폴더 디렉토리 리스팅 확인(이후 링크에 존재하는 디렉토리 모두 점검)
http://hacking.com/main/
- 쉽게 예측 가능한 디렉토리들 확인
http://hacking.com/admin/, _admin등
http://hacking.com/test/
http://hacking.com/manager/
제11절 기타
개발자나 웹서버 관리자는 본인들의 편의를 위해 원격 DB 관리자 로그인 인터페이스를 웹으로 구성해 놓거나 심지어는 인증 절차 없이 접근할 수 있도록 되어 있다. 외부에서 IP를 이용한 접근 제어를 하거나, 인증을 시용하도록 해야 한다.
/phpMyAdmin/
출처 : 
조회 : 32,906
