[ 보안 / 인젝션 공격 / 해킹 / 스크립트 / php / asp / jsp ] SQL injection 해킹 보안

[ 보안 / 인젝션 공격 / 해킹 / 스크립트 / php / asp / jsp ] SQL injection 해킹 보안

웹 관리자를 위한 응급처치법 - SQL Injection 해킹 보안

 

박상옥│호스트웨이코리아

 

몇 해 전부터 중국 해커들로부터 한국의 서버들이 해킹당하는 사례가 급격히 증가하고 있다. 이 같은 해킹 피해 사례가 외부로 알려지지 않은 경우가 많지만, 윈도우 환경에서 서버를 운영하는 국내 유수의 사이트들은 드러난 수치보다 훨씬 빈번하게 SQL Injection으로 인한 피해를 입어왔다.

필자의 실제 경험으로도 그렇다. 필자와 상담한 어느 고객의 경우 SQL Injection의 침입으로 참담한 피해를 감수해야 했다. 이 고객은 MS SQL의 시스템 관리자 계정으로 웹 사이트의 DB 연동을 수행했는데 이 과정에서 SQL Injection의 공격을 받아 시스템은 물론이고, 디스크에 저장된 데이터 모두를 잃고 말았다. 

당시 고객이 이용한 디스크는 73GB 용량의 SCSI 디스크였으나, 이것이 논리적으로 인식된 크기는 1TB에 달했다. 이를 로 레벨 포맷하고 나서야 정상적인 크기로 돌아왔지만, 이미 모든 데이터는 사라진 후였다. 이처럼 SQL Injection은 단순한 웹 변조 수준을 넘어 시스템과 디스크 장치까지 피해를 주고 있다.

 

웹서버 보안을 강화하자

 

지금부터는 자신이 관리하는 윈도우 시스템에 SQL Injection의 침입 흔적이 있는지를 확인하고, 웹서버의 보안을 강화하는 방법을 살펴보자. 

사실 SQL Injection으로 인한 피해는 프로그래머의 부주의에서 비롯된다고 해도 지나치지 않다. 따라서 SQL Injection으로 인한 피해를 예방하려면 다음의 3가지를 우선적으로 지켜야 한다.

①Sysadmin 권한의 계정으로 DB Connection을 하지 말자.
②입력폼 등에서 특수문자나 예외문자에 대한 Replace를 수행한다.
③저장 프로시저(Stored Procedure)를 이용한다.

SQL Injection 방지와 관련한 프로그래밍 자료는 다음 사이트(KISA)에서 다운로드할 수 있다(http://www.kisa.or.kr/news/2005/announce_20050427_submit.html).

 

SQL Injection의 3가지 기법

 

SQL Injection을 이용한 해킹은 시스템의 취약성에 따라 Authentication Bypass, OS call, Query manipulation 등을 조합해 이뤄진다.

 

■ Authentication Bypass 
주로 로그인 창에 적용되는 기법으로 이용자 아이디와 패스워드를 몰라도 로그인할 수 있게 해준다. 테이블의 첫 번째 Row 값을 써서 로그인하고, 만약 그것이 관리자 페이지라면 웹사이트 관리자로 로그인할 수 있다.

<화면1>Authentication Bypass를 써서 보안이 취약한 웹사이트에 로그인 할수 있다.

 

■ OS Call 
OS Call은 Sysadmin 권한 계정으로 DB 연동을 수행했을 때를 노린다. 마스터 DB의 확장 저장 프로시저에서 윈도우 시스템을 핸들링할 수 있는 확장 저장 프로시저들을 실행케 해주는 것이다. 

OS Call을 방지하기 위해서는 아래의 확장 저장 프로시저들을 쓰지 못하도록 Disable하거나, 확장 프로시저에 해당하는 DLL 파일을 삭제해야 한다. 그러나 이 역시 완전한 대비책은 못 된다. 삭제된 DLL 파일은 해커에 의해 재생성되거나, 업로드돼 이용될 수 있기 때문이다. 그러므로 해킹을 염려한다면 Sysadmin 권한 계정으로 DB 연동을 절대 수행하지 말아야 한다.

 

<화면2> OS Call은 확장 프로시저를 이용해 Admin 권한 계정을 생성하는 원리다.

■ Query Manipulation
아래 URL 주소와 같이 예외 처리를 하지 않은 사이트는 SQL Query를 조작할 수 있다.

http://www.somecompany.com/notice.asp?no=5 ;EXEC master. dbo.xp_cmdshell’ cmd.exe dir c:

 

 

Injection 자료의 수집

 

SQL Injection을 위한 데이터는 주로 웹 랭킹 사이트에서 수집된다. 특히 구글 해킹을 통한 admin 페이지 수집이 빈번한 것으로 알려져 있다. 일반적으로 admin 페이지들은 http:// website.com/admin을 이용하는 경우가 많은데 이런 데이터 수집 과정을 감안하면 이는 결코 바람직하지 않다. 또한 해당 사이트나 제품의 취약점을 찾아내주는 SQL Injection Tool도 침입을 위한 자료 수집에 많이 이용되고 있다. 이 도구들은 주로 중국에서 제작돼, 심지어 상용화되기도 한다.

 

<화면3> Googledock을 이용한 정보 수집

 

 

SQL Injection의 피해 확인

 

일반적으로 웹사이트가 Injection 툴에 의해 침입을 받았다면 DB에 해당 툴을 암시하는 테이블이나, 이용자 계정 정보가 남아 있게 된다. 또한 IIS 웹로그에도 로그 기록이 남기 때문에 이를 통해서도 침입 흔적을 확인할 수 있다. 

■ HDSI 툴에 의한 침입
HDSI 툴은 SQL Injection에 취약한 사이트의 DB를 조회하거나 시스템 명령어 등을 실행할 수 있게 해준다. DB에 T_Jiaozhu, jiaozhu, comd_list, xiaopan, Reg_Arrt 등의 테이블을 생성하므로, 이 테이블들의 존재를 확인함으로써 침입 여부를 알 수 있다.

 

■ D-SQL에 의한 침입 
DB에 D99_Tmp라는 테이블이 존재한다면 D-SQL을 써서 시스템 명령어를 실행한 것으로 볼 수 있다. 아울러 D99_Reg 테이블은 레지스트리 수정, D99_Tmp는 디렉토리 탐색, D99_CMD는 명령어 수행이 이뤄졌음을 각각 나타낸다. D-SQL은 또한 IIS 웹로그도 생성한다.

 

 

<화면4> HDSI 툴은 T_Jiaozhu, jiaozhu, comd_list, xiaopen, Red_Arrt 등의 테이블을 생성한다.

 

<화면5> D-SQL의 실행 모습

 

 

웹로그에서 확인하기

 

웹로그에서도 테이블과 관련한 Create나 Select 구문이 없는지를 확인해야 한다. 아울러 확장 저장 프로시저에 대한 로그가 존재하는지도 살펴본다. 웹로그에서 검색해봐야 할 문자열에는 XP_CMDSHELL, Net, user, Update, Insert, drop table 등이 있다.

 

<화면6> D99_Tmp, D99_Reg, D99_Tmp 테이블은 D-SQL의 침입을 의미한다.

 

웹서버 보안을 위한 체크 리스트

 

지금부터는 웹서버 보안을 위한 주요 체크 리스트를 소개한다. 다음의 내용을 자세히 살펴본 후 자신의 웹서버에 해당되는 부분을 찾아 적용해보자. 이 체크 리스트는 대부분 윈도우 2000 환경을 전제로 하고 있다.

 

■ Patches and Updates
먼저 최신 패치나 서비스팩을 적용했는지 여부와 정기적으로 MBSA를 써서 운영체제 및 애플리케이션 보안을 체크하고 있는지를 확인한다. 현재 2.0 버전이 출시돼 있고, 패치 정보와 윈도우 보안에 대한 가이드도 제공하고 있다. 정기적으로 MS가 제공하는 최신 패치 정보(http://www.microsoft.com/ technet/security/bulletin/notify.asp)를 받아보는 것도 큰 도움이 된다.

 

■ IISLockdown 
IISLockdown이 웹서버에 설치돼 운영되고 있는지를 살펴본다. IISLockdown은 웹서버 보호 과정을 대부분 자동화해주는 도구로 서버 용도나 유형에 따라 여러 보안기능을 해제하거나, 보호할 수 있는 이용자 템플릿을 제공한다. 또한 URLScan을 설치 및 구성했는지도 체크해야 한다. URLScan은 웹사이트 관리자가 서버에서 처리 가능한 웹 요청을 제한할 수 있는 ISAPI 필터로, 잠재적으로 유해할 수 있는 웹 요청을 서버에 도달하기 전에 차단해준다.

 

■ Services
불필요한 윈도우 서비스들을 disable로 설정했는지도 체크 포인트다. FTP, SMTP, NNTP 서비스 등이 필요치 않다면 설치하지 않는다. 특별한 경우가 아니라면 Telnet과 ASP .NET state service는 중지하는 것이 바람직하다.

 

■ Protocols 
WebDAV를 이용하지 않는다면 중지하고, 필요하다면 반드시 보안 설정을 수행한다. 보안 설정과 관련된 내용은 http:// support.microsoft.com/default.aspx?scid=kb;en-us;Q323470을 참고한다. NetBIOS와 SMB 포트(137, 138, 139, 445 포트)의 Disable 설정도 고려할 만하고, 윈도우 2000이라면 DoS 공격을 대비한 TCP/IP Stack의 강화가 필요하다. 보다 자세한 내용은http://support.microsoft.com/default. aspx?scid=kb;ko;315669를 참고한다.

 

■ Accounts
이용하지 않는 계정은 삭제하고, Guest 계정은 항상 disable로 설정한다. Administrator 계정은 암호 설정 규칙을 충실히 따른 후 Rename해 쓴다. 그러나 윈도우 2000의 경우 Administrator 계정을 Rename해도 완벽히 대비할 수 없다는 점을 유의해야 한다. 윈도우 2000의 관리자 계정은 500번 이하의 기본 SID 값을 가지는 탓에, 해커들이 액티브 디렉토리나 로컬 SAM을 이용해 이 SID 값을 아이디로 바꿔 계정을 공격할 수 있다. 이를 방지하기 위해서는 다음의 과정을 따른다. 

?U AD 환경이라면 그룹 정책 가운데 하나인 기본 도메인 정책을 수정한다.
‘컴퓨터 구성Windows 설정보안 설정로컬 정책보안 옵션’에서 익명 연결의 추가적인 제한을 ‘SAM 계정 및 공유 열거 허용 안 함’으로 선택한다.
?V AD 환경이 아니라면 시작-실행-gpedit.msc을 입력해 그룹정책을 적용한다.

■ Files and Directories
NTFS 파일시스템을 선택하고, 웹사이트의 루트 디렉토리는 SystemRoot 드라이브 외의 디렉토리에 위치시킨다. 아울러 웹로그 디렉토리는 SystemRoot 드라이브 및 웹사이트 루트 디렉토리 외의 볼륨에 두도록 한다. Everyone 그룹을 제거하고, Website Root 디렉토리에 IUSR_Machine 계정의 쓰기 권한을 주지 않는다. 
자료실 이용 등으로 익명의 계정이 업로드해야 한다면, 해당 웹서비스의 디렉토리 내에는 Script 실행 권한을 부여하지 않는다. 기본 웹사이트와 관리 웹사이트는 삭제하거나 중지한다.

 

■ Shares
불필요한 공유는 없애고, 파일 공유 생성 시 권한에 유의한다. Everyone Access는 되도록 쓰지 않는다.

 

■ Ports
SSL을 구성한다.

 

■ Registry
원격 레지스트리 연결을 제한하기 위해 Remote Registry Service를 중지한다. 198쪽에서 계속

정리 | 전도영 mir@imaso.co.kr

 

참고자료

ㆍ http://www.krcert.or.kr
ㆍ Microsoft - Checklist: Securing Your Web Server

 

툴 소개


웹 침입 차단을 위한 프레임 제공, Webknight 

Webknight는 공개 소프트웨어의 하나로 SQL Injection을 비롯해 여러 형태의 웹 공격을 차단하는 프레임을 제공한다. 웹사이트(http://www.aqtronix.com)에서 다운로드 해 이용할 수 있지만, 실제 서버에 적용하기 전에는 반드시 테스트 서버를 통한 점검이 이뤄져야 한다.

① 사이트(http://www.aqtronix.com/downloads/WebKnight/ 2004.02.01/WebKnight.zip)에서 다운로드한다.
② 압축을 해제하고, Setup 폴더 하위의 WebKnight.Msi를 실행해 설치한다.
③ IIS 웹서버를 Restart 한다.
④ 정상적으로 설치가 완료되면, <화면 7>과 같이 ISAPI Filters에 Webknight가 추가된다.
⑤ 기본 설치 폴더에서 C:Program FilesAQTRONIX Webknight Config.exe를 실행하면, 현재 설정을 볼 수 있다.



<화면 7> ISAPI Filters에 Webknight 추가



⑥ <화면 8>처럼 SQL Injection 관련 설정을 확인하고, 필요한 경우 수정한다. 
⑦ <화면 8>처럼 해당 Query가 2번 이상 요청되면 블로킹 웹사이트를 보여준다.
⑧블로킹 페이지를 수정할 때는 C:Program FilesAQTRONIX Webknightnohack.htm을 이용한다.

한편 무료 웹사이트 점검을 이용해 웹사이트의 취약점을 파악할 수도 있다. 한국정보보호진흥원이 마련한 웹 취약점 원격 점검 서비스(webcheck.krcert.or.kr)가 대표적이다. 이 사이트에 접속해 서비스를 신청하면 운영하는 웹사이트가 지닌 위험 요소를 쉽게 파악할 수 있다. 이외에도 많은 인터넷 데이터센터(IDC)들이 SQL Injection 무료 점검 서비스를 제공하고 있다. 



<화면 8> SQL Injection 관련 설정 확인

[ 원문 다운로드 ]

012.웹_관리자를_위한_응급처치법-SQL_Injection_.doc