수안이의 컴퓨터 연구실

출처 : 시스템 로그 분석 (해킹 피해와 보안 추적의 결정적 파일) - 안성철
(안성철님께 허락을 구하지는 않았고, 삭제를 요청할 시 바로 삭제 조치 하겠습니다.)


1. 해킹 피해 시스템 분석 절차

1.1 시스템 침입 흔적 조사 방법
특별한 장소 또는 행위로부터의 접속에 대한 로그 파일을 조사한다.

• last, syslog, 프로세스 로그와 그 밖에 다른 로그 파일을 조사한다.
• access-log, xferlog 등 주요 서버의 로그 파일을 조사한다.
• 방화벽 또는 라우터에 의한 로그 기록이 있을 경우 조사한다.
• 유닉스에서 기본적으로 제공하는 로그 파일들을 조사한다.
• /var/adm/messages 콘솔 상에 있는 정보
• /var/adm/utmp(x) 현재 로그인 한 사용자 정보
• /var/adm/wtmp(x) 사용자의 로그인, 로그아웃
• 시스템의 shutdown, start up 정보를 조사한다.
• /var/adm/lastlog 사용자의 최근 로그인 관련 정보
• /var/adm/acct 사용자의 command 정보
  

예) 시스템 공격에 따른 각종 로그 예

imap/ipop 공격 로그 : message 로그 파일

mscan 공격 로그 : secure 로그 파일

statd 공격 로그 : message 로그 파일

WWW 관련 공격 로그 : access-log 로그 파일

setuid, setgid 파일을 조사한다.

• 침입자는 종종 추후에 루트 권한으로 접속하기 위해 /bin/sh 또는 /bin/time 과 같은 백도어 파일을 남겨둔다.
• 다음의 방법으로 setuid, setgid 파일을 찾는다.

NFS/AFS 마운트 시스템에서는 다음과 같은 명령어를 이용한다.
[Test: /]find / -user root -perm -4000 -print -xdev

• setuid 파일을 찾는 다른 방법으로 각각의 파티션에 대해 적용하는 ncheck가 있다.

시스템의 바이너리 파일 변경 여부를 조사한다.

• 침입자는 /etc/inetd.conf가 참조하는 다음과 같은 파일들을 변경한다.
  login, su, telnet, netstat, ifconfig, ls, find, du, df, libc, sync 등
• 백업된 초기 파일과 현재의 파일을 비교하기 위한 유닉스의 sum 명령어는 트로이 목마 프로그램에 의해 거짓 정보를 나타낼 수 있으므로 다음 프로그램을 사용한다. cmp, MD5, Tripwire 등 다른 암호화 검사 유틸리티들 인가받지 않은 프로그램 및 네트워크 모니터링 프로그램의 사용을 조사한다.
• 침입자는 사용자의 계정과 패스워드 정보를 얻거나, 자신의 존재를 숨기거나, 또 다른 시스템을 공격 하기 위해 다양한 프로그램 피해 시스템을 설치하여 사용한다.

cron과 at.으로 수행되는 모든 파일을 검사한다.

• 침입자는 보통 cron과 at 명령으로 수행되는 파일들에 백도어 프로그램을 남겨둔다. 그러므로 이러한 프로그램으로 수행되는 파일들을 쓰기금지로 설정한다.

인가받지 않은 서비스를 조사한다.

• /etc/inetd.conf를 조사하여 인가받지 않은 추가되거나 변경된 서비스를 조사한다. 특히 쉘을 수행 할 수 있는 /bin/sh나 /bin/csh를 조사한다. /etc/passwd 파일을 조사하여 변경된 부분이 있는지 확인한다.
• 추가된 계정, 패스워드의 생략, uid(0로의)의 변경여부를 확인한다.

시스템과 네트워크 설정 파일의 인가받지 않은 항목을 조사한다.

• /etc/hosts.equiv, /etc/hosts.lpd와 모든 .rhosts 파일에 '+' 항목이 있는지 조사해서 제거한다.
  시스템에 숨겨지거나 '.' 으로 시작하는 특이한 파일이 있는지 조사한다.
• ls 명령어로 보이지 않는 파일을 조사한다.

일반적으로 '.xx' 파일이나 '.mail' 파일이 침입자에 의해 이용된다. 지역 네트워크의 모든 시스템을 조사한다.

1.2 침입자의 출발지 분석
침입자의 출발지는 어떻게 확인할 수 있을까? 정확하게 위치를 추적하기는 힘들더라도 개략적인 위치는 시스템에서 제공하는 명령어로도 확인할 수 있다. 이러한 정보를 확인하기 위해서는 다음과 같은 명령어를 이용하여 정보를 검색하면 된다.

• who, w : 사용자 및 사용자의 컴퓨터 확인
• last : 사용자들의 로그인/로그아웃 일시 기록 확인
• lastcomm : 사용자들의 시스템 명령 및 프로세스 기록 확인
• netstat : 네트워크 접속 현황 확인
• snmpnetstat : 네트워크 관리 시스템에서의 현황
• 라우터 정보 : 라우터의 라우팅 및 접속 등의 현황 확인
• /var/adm/messages : 전자우편 송수신 현황 기록 확인(많은 침입자들이 자신의 시스템으로 전자 우편 송신)
• syslog : 시스템 로그 확인(다른 시스템으로도 로그를 보낸다)
• wrapper 로그 : 외부 시스템 접속 차단 프로그램의 연결

시스템의 모든 사용자에게  finger를 하여 어디서 왔는지 점검


1.3 ethernet sniffer로 다른 시스템에 어떻게 침입하는지를 모니터링 하는 것이 좋다.
xinetd나 tcp_wrapper는 외부에서의 모든 접속에 대해 로그를 남길 수 있으며, 침입자가 로그를 수정하거나 지울 수 없도록 이 로그들을 다른 시스템에 옮겨두는 것이 바람직하다. 적절한 대책을 세우기 전에 침입자가 ethernet sniffer로 다른 시스템에 어떻게 침입하는지를 모니터링 하자.

1.4 외부로부터 접속하는 시스템들을 막고 특히, 침입자의 접근을 막기 위해 네트워크를 중지시킨다.
하지만 만약 침입자가 눈치 챈다면 당신의 시스템에서 "rm -rf /"를 실행하여 모든 정보를 지울 수 있다.

1.5 시스템 실행 파일의 변경 유무를 점검하는데, 특히 백도어 프로그램으로 잘 이용되는 다음 프로그램들을 중점 점검한다.

• /bin/login
• 모든 /usr/etc/in.* files (예 : in.telnetd)
• /lib/libc.so.* (on Suns)
• inetd에서 호출되는 모든 것

기타 잘 교체되는 것으로서는 다음과 같은 것이 있다.

• netstat : 정보를 감추게 한다.
• ps : 프로세스를 감추게 한다(예 : Crack).
• ls :  디렉토리를 감춘다.
• ifconfig : 이더넷에 대한 promiscuity mode를 감춘다.
• sum : sum을 수정하지 않고도 실행 파일의 체크썸을 올바르게 위장 할 수 있으므로 더 이상 교체하지는 않는다.

따라서 sum 값을 믿어서는 안된다. 파일의 실제 수정 시간을 알기 위해서는 "ls -lac"를 사용한다. /etc/wtmp를 점검하여 시스템 시간을 알아내고 CD나 테이프의 원본과 비교하거나 MD5 체크썸이 이전의 체크썸과 다른지 비교하며, 흔히 오프라인으로 저장된 미리 만들어진 체크썸과 cmp 명령으로 비교한다. 아울러 흔히 사용되는 백도어로서 /bin/time 과 같은 setuid 프로그램인데, 이들은 일반 사용자가 root로 실행할 수 있게 해준다. 이런 프로그램을 찾기 위해서는 다음 명령을 이용하면 된다.


하다보면 OS 전체를 다시 설치해야 될지도 모른다. Tripwire 보안도구는 관리자 몰래 실행 파일을 수정하거나 inetd.conf와 같은 시스템 파일의 수정을 발견할 수 있도록 도와준다.

1.6 모든 사용자의 .rhosts, .forward등을 점검한다. 만약 .rhosts가 "+"를 가지고 있으면 어떠한 시스템에서도 패스워드 체크없이 접근할 수 있다. COPS는 다음과 같은 체킹 스크립트를 가지고 있다.


의심스러운 모든 파일의 생성 및 수정 시간을 점검하는데 다음을 이용한다.


이것은 이틀 전에서 하루 이후에 수정된 파일을 찾아준다. 모든 .login, .logout, profile, .cshrc들도 적어도 수정일 및 시간 등을 점검하며, .rhosts 파일이 잠궈진 것은 없는지, news, sundiag, sync 등의 계정에 대한 쉘이 보다 안전을 위해 "/bin/false"로 되어 있어야 하며 "/bin/sh" 등으로 되어 있어서는 안된다.

또한 ".", ".." 등의 디렉토리가 없는지 점검하는데 대부분 /tmp, /var/tmp, /usr/spool/* 나 공개적으로 쓰기 할 수 있는 디렉토리에서 많이 발견된다.

1.7 NFS가 외부로 널리 공개된 것은 아닌지 점검한다.
NFSwatch는 NFS 트랜잭션에 대해 로그를 만들어 주며, "showmount -e"를 하여 올바른 NFS 구성을 점검할 수 있도록 한다. 256 바이트를 넘긴 경우에 nfsd는 버그를 가지고 있으며, 또한 여러분이 마운트하고 있는 시스템에 대한 점검도 중요하다. 가능한 "nosuid" 플래스를 사용한다.

1.8 시스템 취약점이 있는지 점검하는 리스트
원하지 않는 프로세스가 없는지, "rpcinfo -p"를 이용하여 점검한다. hosts.equiv 에 "+"가 없는지 점검한다. tftp를 사용하지 않는가, 사용하기를 원한다면 "-s" 플래그를 사용한다. 이 경우는 대부분 디스크 없는 워크스테이션을 위한 경우인데, 적절하게 NFS를 이용할 수 있다. 이것을 root로 실행하지 않도록 하며, /etc/inetd.conf에서 다음과 같이 바꾼다. tftp dgram udp wait nobody /usr/etc/in.tftpd in.ftpd -s /tftpboot 혹은 원치 않는 곳에서의 접근을 막기 위해 tcp_wrapper에서 tftpd에 한 부분을 고치고 모든 접속 상황을 로그로 남긴다.

tfp dgram udp wait nobody /usr/etc/tcpd in.tftpd -s /tftpboot 혹은 /etc/hosts.allow에서 정의된 곳에서만 접근할 수 있도록 조정한다. crontab과 at-vobs를 점검한다. 침입자가 남긴 모든 것을 정리했다고 생각한 후 이것이 어떤 작업을 할 수 있다. rc.boot, rc.local(SYSV : /etc/rc?.d/*)나 기타 시스템 시작 시 실행 파일들을 점검한다.

가장 좋은 방법은 오프라인으로 저장했다가 주기적으로 점검하는 것이며, sendmail.cf, hosts.allow, at.allow, at.deny, cron.allow, hosts, hosts.lpd 등의 시스템 구성 파일들을 점검한다. "aliases"는 메일 확장을 위한 것인데, "uudecode" 등과 같은 것을 가지고 있을 수 있다. inetd.conf 와 /etc/services 파일에서 침입자가 추가한 불법 프로그램 서비스가 있는 지 점검한다. 현재 가지고  있는 모든 로그 파일(pacct, wtmp, lastlog, sulog, syslog, authlog 등)들을 다른 안전한 곳으로 옮긴다. /tmp/* 파일들을 먼저 살펴 본 후 재시동(Reboot)한다.

/etc/passwd 파일의 여분 파일을 가능한 디스켓 등으로 저장한 후 su 및 passwd 프로그램이 백도어가 아님을 확인한 후 root 패스워드를 바꾼다. 만약 침입자가 su나 passwd 백도어를 설치하였다면 /etc/passwd 파일의 패스워드 부분을 모두 "*"로 바꾼다.

또한 침입자가 패스워드 파일을 가지고 있다면 모든 사용자들의 패스워드를 알아낼 가능성이 있으며, 장시간 사용하지 않는 사용자의 패스워드를 바꿀 수도 있다. NIS 서버에서는 단순히 /etc/passwd 뿐 아니라 NIS 맵에 해당하는 것들도 점검해야 한다. 익명 FTP나 다른 네트워크 서비스 시스템들이 적절하게 구성되어 있는지 점검한다. inetd를 다시 설치하고, 콘솔만이 "secure" 단말로 정의하여 다른 단말에서 root로 로그인할 수 없도록 한다. hosts.equiv, .rhosts, hosts.lpd에 "#"이 있는지 점검한다. 만약 침입자가 "#"을 기계이름으로 정의하였다면 누구나 신뢰하는 호스트로 정의된다. 마지막으로 침입자에 대한 경각심을 늦추지 않는다.

2. 침해사고 분석 방법

2.1 관리자 관점에서의 분석
위의 예와 같이 침입자는 다양한 방법을 이용하여 시스템에 침입하여 불법작업을 수행한다. 관리자는 이러한 침입자의 행동을 모니터링 하는 것은 쉽지 않지만 침해사고가 발생할 경우 시스템이 가지고 있는 여러 로그기록을 이용하여 침입자 확인, 침입 방법, 침입자의 출발 호스트 등의 정보를 얻을 수 있다.

그리고 침입자들이 이용하는 웹 서버, imapd 등 서비스 취약점을 이용한 공격도 서버들이 기록하는 로그 기록을 분석할 수 있는 것이다. 여기에서 유닉스 기반의 시스템에서 제공되는 로그 정보 점검에 대해 예를 들어 설명하겠다.

■ 시스템 로그 파일
유닉스 시스템에는 다양한 로그 정보를 가진 파일과 관련 명령어들이 있다. 먼저 시스템 내의 로그 파일은 주로 /var/adm 디렉토리에 존재하게 되는데 필요에 따라 파일의 위치를 변경할 수 있다. /var/adm/ 파일들은 /var/adm/messages, /var/adm/utmp(x), /var/adm/wtmp(x), /var/adm/lastlog, /var/adm /logining, /var/adm/acct 등이 제공된다.

로그 파일	보유 정보
/var/adm/messages	콘솔 상에 있는 정보
/var/adm/utmp(x)	현재 로그인 한 사용자 정보
/var/adm/wtmp(x)	사용자의 로그인, 로그아웃, 시스템의 shutdown, start up
/var/adm/lastlog	사용자의 최근 로그인 관련 정보
/var/adm/acct	사용자의 command 정보

유닉스의 기본 로그 파일들이 가지고 있는 정보를 살펴보면 다음과 같다. /var/adm/wtmp(x)는 시스템 사용자의 접속 정보를 알 수가 있는 파일이다. 이는 last 명령어를 이용하여 정보를 볼 수 있는데 그 예는 다음과 같다.


위의 경우 userone은 평소 xxx.xxx.147.46 네트워크에서 접근을 하는데 비해 비정상적인 시간대에 dialup77.xxx.xxx.xxx 호스트에서 접근한 사실을 알 수가 있다. 이는 userone의 비밀번호가 누출이 되어 이상한 호스트에서 접근한 것을 알 수가 있는 것이다.

syslog 데몬을 이용하여 시스템 접속 오류 등에 대한 로그를 설정하였을 경우 messages 파일을 점검함으로써 불법적인 접근 시도가 있었는지도 살펴볼 수 있다. 이 역시 시스템 사용사으이 오류를 포함한 외부로부터의 불법적인 접근 등을 검사할 수 있다.


위의 경우는 외부로부터 named 버그를 이용하여 시스템에 침입하기 위한 침입자에 의해 named 데몬이 재시동되는 것을 알 수 있다. 이와 같이 다양한 로그 정보들을 검토함으로써 외부로부터의 불법적인 접근 시도 또는 접근 사실을 알 수 있다.

■ 주요 서버의 로그 정보 분석

- 웹 서버의 로그 정보 분석
관리자는 웹 서버의 로그 파일인 Access log나 error log 파일을 점검함으로써 외부 침입 자가 시스템 내의 중요 파일을 가져갔는지 알아보아야 한다. 주로 access_log, error_log 등은 /var/adm/httpd/logs와 같은 디렉토리에 존재하며, 이는 httpd 설치 시 사용자에 따라 설정할 수 있다. 다음은 xxx.xxx.com 으로부터 http 서버 phf 버그를 이용하여 패스워드 파일을 가져간 예이다.


- IMAPD, POPD 로그 정보 분석
다음은 최근 개인 전자우편 관련하여 많이 사용하고 있는 Imapd(Popd)를 이용하는 방법이다. 이 방법은 데몬에 많은 데이터를 보내 버퍼오버플로우를 발생시켜 새로운 쉘(Shell)을 실행하는 방법으로써 /var/adm/messages 파일에서 알 수 있다.

다음 사례는 xxx.xxx.198.78 호스트에서 시스템의 Imapd로 접근한 내용을 보여주고 있다.


아래 표에서는 위에서 언급한 해킹 방법들로 해커들이 공격했을 경우에 어떠한 시스템 로그나 서버 로그를 점검해야 하는지를 요약해 놓았다.

해킹 방법	utmp wtmp	access_log	messages	news log	su log	secure log	spooler log	syslog	비고
SPAM relay								O
popd			O			O
imapd			O			O
named			O
innd				O			O
identd			O
phf/php 등 CGI		O
portscan									모니터링
mscan			O
su 시도			O		O
원격 login 시도	O		O			O
원격 ftp 시도	O		O			O
서비스 거부									모니터링

2.2 공격자 관점에서의 분석
시스템 관리자 관점에서 분석한 침해사고의 시스템 점검을 통해 얻어지는 결과물에 대해서도 얻을 것이 많지만 경험이 많은 침입자의 경우 일반적으로 로그들은 삭제하고 가는 일이 많기 때문에 해커의 관점에서 시스템 침입시 하는 행동들을 예측하고 그 흔적을 알아내어 시스템이 남기는 정상적인 로그 이외의 해킹 흔적들을 찾아야 한다.

■ 트로이 목마(trojan horse)와 백도어 프로그램 점검
백도어 프로그램이란 일명 뒷구멍이라고 해서 해커들이 임의의 시스템을 해킹한 후 해킹한 시스템에 흔적 없이 다시 들어오려할 때 주로 사용한다. 해커들이 설치하는 프로그램은 원격 접근을 위한 백도어 프로그램 뿐 아니라 내부 사용 흔적을 감추기 위해서, 또는 일반 사용자가 쉽게 관리자(root)가 되기 위해서 기존 프로그램과 이름은 동일하지만 프로그램 내부동작은 침입자의 의도를 만족하는 기능을 갖게 된다.

다음은 실제 해킹을 당한 피해 시스템을 점검하면서 발견된 사례를 보도록 하자.

- .rhosts, /etc/hosts.equiv 백도어 프로그램


- 백도어로 이용된 서버데몬(inetd 이용)
- 시스템 분석 시 발겨된 백도어 프로그램 구성 사례
해커들은 백도어 프로그램이 숨겨야 할 정보들을 다음과 같은 구성 파일을 만들어 저장하기도 한다. 물론 이 구성 파일은 관리자나 사용자가 찾기 어려운 위치에 만든다.


- ps 명령에서 감추고 싶은 파일들을 등록
[Test: /]more ps.
2 .linsniffer
2 pepsi
2 smurf

- 발견된 트로이 목마 쉘(Trojaned Shell)백도어
rc 파일이나 .cshrc, .profile 파일에 백도어용 코드를 삽입하고, 쉘을 숨겨놓는다.



- /etc 디렉토리에 위치한 쉘

■ 백도어 디렉토리 점검
해커들은 자신이 공격한 시스템에 백도어를 유지하거나 새로운 공격을 시도하기 위하여 일반적인 방법으로는 보이지 않는 디렉토리를 생성한다. 숨겨져 있는 디렉토리를 찾이 위해서는 우선 해커들의 손이 닿지 않은 깨끗한 "ls" 프로그램이 필요하다. 숨겨져 있는 디렉토리는 스페이스 문자나 탭키, ... 등 특수키의 혼용으로 일반적인 "ls" 명령으로는 잘 보이지가 않는다.

전체 파일 시스템에 대하여 find 명령을 이용한 스크립트를 작성하여 백도어 디렉토리를 찾는다. 주로 파일 개수가 아주 많거나 사용자가 자주 이용하지 않는 위치에 백도어 디렉토리가 존재한다.
[Test: /]ls /var/spool/at/spool/.h/
exploits pen regs.h~ ts2
ipw.c reg.tgz screen ts2.c
ircbnc.c regq.h~ screen-3.7.4.tar.gz tt
login regr.h~ ssh-1.2.20 web

■ 각종 서버 원격 취약점 점검
호스트에 서버(데몬)로 인하여 해커들은 침입의 발판되므로 모든 서버들에 대하여 해커들의 원격 침입이 있었는지 알기 위해 관리자는 취약성 여부를 확인한 후 해킹 가능성을 추측할 수 있다. 시스템의 messages 로그는 주요 서버들의 접근 흔적을 따로 유지하고 있다.


- <popd/imapd>


- <statd>


- <httpd>

Paul Litwin │Fred Hutchinson Cancer Research Center 수석 프로그래머


ASP.NET 및 Microsoft SQL Server과 같은 강력한 데이터베이스 서버의 고급 서버측 기술을 통해 개발자는 동적인 데이터 중심 웹 사이트를 매우 쉽게 만들 수 있습니다. 하지만 ASP.NET 및 SQL의 기능은 SQL 주입 공격이라는 너무나 일반적인 공격 방식을 알고 있는 해커들에게도 쉽게 악용될 수 있습니다.


SQL 주입 공격에 대한 기본 개념은 다음과 같습니다. 사용자가 텍스트 상자에 텍스트를 입력할 수 있도록 웹 페이지를 만들고 이러한 텍스트는 데이터베이스에 대한 쿼리를 수행하는 데 사용됩니다. 해커는 이러한 텍스트 상자에 쿼리의 특성을 변경하여 백엔드 데이터베이스에 침입하거나 데이터베이스를 손상시킬 수 있는 잘못 형성된 SQL 문을 입력합니다. 어떻게 이런 일이 가능할까요? 몇 가지 예를 통해 이러한 방법에 대해 설명하겠습니다.


SQL 문의 변환

여러 ASP.NET 응용 프로그램에서는 그림 1에 표시된 것과 같은 폼을 사용하여 사용자를 인증합니다. 사용자가 BadLogin.aspx의 Login 단추를 클릭하면 사용자가 폼의 텍스트 상자 컨트롤에 입력한 값과 UserName 및 Password가 일치하는 Users 테이블에 있는 레코드 수를 계산하는 쿼리를 실행하여 cmdLogin_Click 메서드가 사용자를 인증하도록 시도합니다.


대부분의 경우 폼은 정확히 의도된 대로 작동합니다. 사용자는 Users 테이블에 있는 레코드와 일치하는 사용자 이름 및 암호를 입력합니다. 동적으로 생성된 SQL 쿼리를 사용하여 일치하는 행의 개수를 검색합니다. 그런 다음 사용자를 인증하고 요청된 페이지로 리디렉션합니다. 잘못된 사용자 이름 및/또는 암호를 입력하는 사용자는 인증되지 않습니다. 하지만 이 경우에도 해커가 UserName 텍스트 상자에 겉보기에는 잘못된 것이 없는 다음과 같은 텍스트를 입력하여 유효한 사용자 이름 및 암호를 알지 못하더라도 시스템에 침입할 수 있습니다.

' Or 1=1 --

해커는 잘못 형성된 SQL을 쿼리에 주입하여 시스템에 침입합니다. 이 경우의 해킹은 다음과 같이 사용자가 입력한 고정 문자열 및 값의 연결을 통해 실행 쿼리가 형성되기 때문에 작동됩니다.

string strQry = "SELECT Count(*) FROM Users WHERE UserName='" + txtUser.Text + "' AND Password='" + txtPassword.Text + "'";

유효한 사용자 이름인 "Paul"과 암호 "password"를 사용자가 입력하는 경우 strQry는 다음과 같이 됩니다.

SELECT Count(*) FROM Users WHERE UserName='Paul' AND Password='password'

하지만 해커가 다음을 입력하면

' Or 1=1 --

쿼리가 다음과 같이 됩니다.

SELECT Count(*) FROM Users WHERE UserName='' Or 1=1 --' AND Password=''

이중 하이픈은 SQL에서 주석의 시작 부분을 나타내므로 쿼리는 다음과 같이 됩니다.

SELECT Count(*) FROM Users WHERE UserName='' Or 1=1

식 1=1은 테이블의 모든 행에 대해 항상 True이고 다른 식이 포함된 True 식 or'd는 항상 True를 반환합니다. 따라서 User 테이블에 적어도 하나 이상의 행이 있다고 가정할 경우 이 SQL은 항상 0이 아닌 레코드 개수를 반환합니다.


일부 SQL 주입 공격에는 폼 인증이 포함되지 않습니다. 폼 인증과 관련한 SQL 주입 공격에 필요한 사항은 동적으로 구성된 일부 SQL과 트러스트되지 않은 사용자 입력이 있는 응용 프로그램입니다. 정확한 조건만 주어진다면 이러한 공격으로 인한 피해 범위를 해커의 SQL 언어 및 데이터베이스 구성에 대한 지식 수준으로만 제한할 수 있습니다.


이제 BadProductList.aspx에서 가져온 그림 2에 표시된 코드를 살펴 보십시오. 이 페이지는 Northwind 데이터베이스의 제품을 표시하고 사용자가 txtFilter라는 텍스트 상자를 사용하여 제품 결과 목록을 필터링하도록 할 수 있습니다. 마지막 예에서와 같이 이 페이지는 실행 SQL이 사용자가 입력하는 값으로 동적으로 생성되기 때문에 SQL 주입 공격에 당할 가능성이 높습니다. 이러한 특정 페이지는 약삭빠른 해커가 공격하여 기밀 정보를 훔치고, 데이터베이스의 데이터를 변경하고, 데이터베이스 레코드를 손상시키고, 심지어는 새로운 데이터베이스 사용자 계정을 만들 수도 있기 때문에 해커에게는 천국과도 같습니다.


SQL Server를 포함한 대부분의 SQL 호환 데이터베이스는 메타데이터를 sysobjects, syscolumns, sysindexes 등의 이름으로 일련의 시스템 테이블에 저장합니다. 즉, 해커는 이러한 시스템 테이블을 사용하여 데이터베이스에 대한 스키마 정보를 확신하고 추가적인 데이터베이스 손상을 위한 도움을 얻을 수 있습니다. 예를 들어 다음과 같이 txtFilter 텍스트 상자에 입력된 텍스트는 데이터베이스에서 사용자 테이블의 이름을 확인하는 데 사용될 수 있습니다.

' UNION SELECT id, name, '', 0 FROM sysobjects WHERE xtype ='U' --

UNION 문은 해커가 한 쿼리의 결과를 다른 쿼리로 분할할 수 있도록 하기 때문에 해커에게 특히 유용합니다. 이러한 경우 해커는 데이터베이스의 사용자 테이블 이름을 제품 테이블의 원래 쿼리로 분할합니다. 여기에 사용된 방법은 단지 열의 개수와 데이터 형식을 원래의 쿼리와 일치시키는 것 뿐입니다. 이전 쿼리는 Users라는 테이블이 데이터베이스에 있음을 나타낼 수 있습니다. 두 번째 쿼리는 Users 테이블에 있는 열을 노출시킬 수 있습니다. 해커는 이러한 정보를 사용하여 txtFilter 텍스트 상자에 다음을 입력할 수 있습니다.

' UNION SELECT 0, UserName, Password, 0 FROM Users --

이 쿼리를 입력하면 그림 3에서와 같이 Users 테이블에 있는 사용자 이름 및 암호를 노출시킵니다.



SQL 주입 공격은 또한 데이터를 변경하거나 데이터베이스를 손상시키는 데에도 사용될 수 있습니다. SQL 주입 해커는 txtFilter 텍스트 상자에 다음을 입력하여 첫 번째 제품의 가격을 $18에서 $0.01로 바꾸고 이러한 사실을 다른 사람이 눈치채기 전에 일부 제품을 재빠르게 구매할 수 있습니다.

'; UPDATE Products SET UnitPrice = 0.01 WHERE ProductId = 1--

이러한 해킹은 SQL Server에서 세미콜론이나 공백을 사용하여 구분된 여러 SQL 문을 함께 입력할 수 있도록 허용하기 때문에 가능합니다. 이 예에서 DataGrid는 아무 것도 표시하지 않지만 업데이트 쿼리는 성공적으로 실행됩니다. 이러한 같은 기술을 사용하면 DROP TABLE 문을 실행하거나 새로운 사용자 계정을 만들고 이 사용자를 sysadmin 역할에 추가하는 시스템 저장 프로시저를 실행할 수도 있습니다. 이러한 해킹은 모두 그림 2에 표시된 BadProductList.aspx 페이지를 사용하여 가능합니다.


동일한 해킹 기회


SQL 주입 공격은 SQL Server에만 국한된 문제가 아닙니다. Oracle, MySQL, DB2, Sybase 등의 다른데이터베이스에서도 이러한 종류의 공격을 받을 수 있습니다. SQL 주입 공격은 SQL 언어에 다음과 같이 강력하고 유연한 여러 기능이 포함되어 있기 때문에 가능합니다.


이중 하이픈을 사용하여 SQL 문에 주석을 포함시킬 수 있는 기능
여러 SQL 문을 함께 입력하고 이를 일괄 처리로 실행할 수 있는 기능
SQL을 사용하여 표준 시스템 테이블 집합으로부터 메타데이터를 쿼리할 수 있는 기능


일반적으로 데이터베이스에서 지원되는 SQL 언어의 기능이 강력할수록 데이터베이스에 대한 공격 가능성도 높아집니다. 따라서 SQL Server가 주입 공격의 일반적인 대상이 되는 것입니다.


SQL 주입 공격은 ASP.NET 응용 프로그램으로만 제한되지 않습니다. 기존의 ASP, Java, JSP 및 PHP 응용 프로그램도 모두 같은 위험이 있습니다. 실제로 SQL 주입 공격은 데스크톱 응용 프로그램에 대해서도 수행될 수 있습니다. 예를 들어 이 문서에 대한 다운로드 파일(이 문서의 맨 위에 있는 링크로 제공)에 SQL 주입 공격을 받을 수 있는 SQLInjectWinForm이라는 Windows Forms 응용 프로그램 예제를 포함되어 있습니다.


SQL 주입 공격 방지를 위한 한 두 개의 핵심 방법을 쉽게 설명할 수도 있지만 이 문제에 대해서는 계층적 방식을 사용하는 것이 가장 좋습니다. 이러한 방식에서는 일부 취약성으로 인해 보안 방식 중 하나가 무효화되더라도 계속해서 보호 상태를 유지할 수 있습니다. 권장되는 계층은 그림 4에 설명되어 있습니다.




모든 입력에 대한 검사 수행


그림 4에 나열된 첫 번째 원칙은 매우 중요한 것입니다. 모든 사용자 입력은 악의적인 것으로 간주하십시오! 데이터베이스 쿼리에서 검사되지 않은 사용자 입력을 사용해서는 안됩니다. 특히 RegularExpressionValidator 컨트롤과 같은 ASP.NET 유효성 검사 컨트롤은 사용자 입력의 유효성을 검사하기 위한 훌륭한 도구입니다.


유효성 검사에 대한 기본적인 두 가지 방식은 문제가 있는 문자를 허용하지 않거나 적은 수의 필수 문자만 허용하는 것입니다. 하이픈과 작은따옴표와 같은 문제가 되는 일부 문자를 쉽게 허용하지 않을 수도 있지만 이 방법은 두 가지 이유로 인해 적합하지 않을 수 있습니다. 첫 번째, 해커에게 유용하게 사용되는 문자를 놓칠 수 있으며, 두 번째 잘못된 문자를 표현하는 방법이 여러 가지일 수 있습니다. 예를 들어 해커는 작은따옴표를 이스케이프 처리하여 유효성 검사 코드에서 놓치도록 만들거나 이스케이프 처리된 따옴표를 데이터베이스에 전달하여 일반적인 작은따옴표 문자와 동일하게 취급되도록 할 수 있습니다. 더 나은 방법은 허용 가능한 문자를 식별하고 해당 문자만 허용하는 것입니다. 이러한 방식에는 더 많은 작업이 필요하지만 입력에 대해 보다 세밀한 제어가 가능하며 보다 안전합니다. 어떤 방식을 사용하던 간에 일부 해킹에는 많은 수의 문자가 필요하므로 입력에 대한 길이를 제한할 수 있습니다.


GoodLogin.aspx(다운로드 코드에서 제공)에는 두 개의 일반 식 유효성 검사 컨트롤이 포함되며, 이 중에서 하나는 사용자 이름에 대한 컨트롤이고 다른 하나는 암호에 대한 컨트롤입니다. 또한 여기에는 4-12개의 숫자, 알파벳 문자 및 밑줄로 입력을 제한하는 다음과 같은 ValidationExpression 값이 포함되어 있습니다.

[\d_a-zA-Z]{4,12}

사용자가 텍스트 상자에 잠재적으로 손상될 가능성이 있는 문자를 입력하도록 허용해야 할 수 있습니다. 예를 들어 사용자 이름의 일부로 작은따옴표(또는 어포스트로피)를 입력해야 할 수 있습니다. 이러한 경우 정규 식이나 String.Replace 메서드를 사용하여 각각의 작은따옴표를 두 개의 작은따옴표로 바꾸면 작은따옴표를 안전하게 렌더링할 수 있습니다. 예를 들면 다음과 같습니다.

string strSanitizedInput = strInput.Replace("'", "''");


동적 SQL 방지

이 문서에서 설명하는 SQL 주입 공격은 모두 동적 SQL의 실행을 기반으로 합니다. 즉, 사용자가 입력한 값과 SQL을 연결하여 생성되는 SQL 문입니다. 하지만 매개 변수가 있는 SQL을 사용하면 해커가 SQL을 코드에 주입할 수 있는 가능성이 크게 줄어듭니다.


그림 5의 코드는 매개 변수가 있는 SQL을 사용하여 주입 공격을 방지합니다. 매개 변수가 있는 SQL은 사용자가 임시 SQL을 사용해야 하는 경우 뛰어난 성능을 보여 줍니다. 이러한 방식은 IT 부서에서 저장 프로시저를 믿지 않거나 버전 5.0까지 이를 지원하지 않은 MySQL과 같은 제품을 사용하는 경우에 필수적입니다. 하지만 가능하다면 추가 기능에 대해 저장 프로시저를 사용하여 데이터베이스에 있는 기본 테이블에 대한 모든 권한을 제거하여 그림 3에 표시된 것과 같은 쿼리를 만들 수 있는 가능성을 제거해야 합니다. 그림 6에 표시된 BetterLogin.aspx는 procVerifyUser라는 저장 프로시저를 사용하여 사용자에 대한 유효성을 검사합니다.



최소 권한으로 실행

BadLogin.aspx 및 BadProductList.aspx에서 보여진 잘못된 구현 방법 중 하나는 sa 계정을 통해 연결 문자열을 사용한다는 점입니다. 다음은 Web.config에서 발견할 수 있는 연결 문자열입니다.

<add key="cnxNWindBad" value="server=localhost;uid=sa;pwd=;database=northwind;" />


이 계정은 로그인 생성과 데이터베이스 삭제 등 거의 모든 작업을 수행할 수 있는 System Administrators 역할로 실행됩니다. 말할 필요도 없이 응용 프로그램 데이터베이스 액세스에 대해 sa(또는 고급 권한이 있는 계정)를 사용하는 것은 매우 잘못된 생각입니다. 대신 제한된 액세스 계정을 만들고 이를 사용하도록 하는 것이 훨씬 좋습니다. GoodLogin.aspx에 사용된 계정은 다음과 같은 연결 문자열을 사용합니다.

<ADD key="cnxNWindGood" value="server=localhost;uid=NWindReader;pwd=utbbeesozg4d; database=northwind;" />


NWindReader 계정은 db_datareader 역할에 따라 실행되며 이 역할은 데이터베이스에 대한 테이블의 읽기로 액세스를 제한합니다. BetterLogin.aspx는 저장 프로시저와 WebLimitedUser 로그인을 사용하여 상황을 더욱 향상시켜 줍니다. 이 로그인에는 해당 저장 프로시저를 실행하는 권한만 포함되어 있으며 기본 테이블에 대해서는 어떠한 권한도 없습니다.


기밀 정보를 안전하게 저장하기

그림 3에 표시된 SQL 주입 공격은 Users 테이블의 사용자 이름과 암호를 노출시킵니다. 이러한 종류의 테이블은 일반적으로 폼 인증을 적용하는 경우에 사용되며 대부분의 응용 프로그램에서 암호는 일반 텍스트로 저장됩니다. 더 나은 방법은 데이터베이스에서 암호화된 암호 또는 해시된 암호를 저장하는 것입니다. 해시된 암호는 암호를 해독할 수 없기 때문에 암호화된 암호보다 안전합니다. 해시에 salt(암호화 방식으로 안전한 임의 값)를 추가하여 해시된 암호의 보안 성능을 더욱 높일 수도 있습니다. BestLogin.aspx에는 사용자가 입력한 암호를 SecureUsers 테이블에 저장된 암호의 salt로 지정된 해시된 암호와 비교하는 코드가 포함되어 있습니다(그림 7 참조). 해시된 퍼즐에 대한 또 다른 측면은 AddSecureUser.aspx에서 볼 수 있습니다. 이 페이지를 사용하면 salt로 지정되어 해시된 암호를 생성하고 이를 SecureUsers 테이블에 저장할 수 있습니다. BestLogin.aspx 및 AddSecureUser.aspx는 모두 그림 8에 표시된 것과 같이 SaltedHash 클래스 라이브러리의 코드를 사용합니다. Jeff Prosise가 만든 이 코드는 System.Web.Security 네임스페이스의 FormsAuthentication.HashPasswordForStoringInConfigFile 메서드를 사용하여 암호 해시를 만들고 System.Security.Cryptography 네임스페이스의 RNGCryptoServiceProvider.GetNonZeroBytes 메서드를 사용하여 16바이트의 임의 salt 값(Convert.ToBase64String을 사용하여 문자열로 변환할 겨우 24 문자가 됨)을 만들 수 있습니다.


SQL 주입 공격과 직접 관련되지는 않지만 BestLogin.aspx는 연결 문자열의 암호화라는 또 다른 최선의 보안 구현 방법을 보여 줍니다. 연결 문자열은 포함된 데이터베이스 계정 암호가 들어 있는 경우 BestLogin.aspx에서와 같이 특히 중요하게 보호되어야 합니다. 데이터베이스에 연결하려면 연결 문자열의 암호를 해독해야 하기 때문에 연결 문자열은 해시할 수 없습니다. 그 대신 연결 문자열을 암호화해야 합니다. 다음은 Web.config에 저장되어 있고 BestLogin.aspx에서 사용되는 암호화된 연결 문자열을 보여 줍니다.

<ADD key="cnxNWindBest" value="AQAAANCMnd8BFdERjHoAwE/ Cl+sBAAAAcWMZ8XhPz0O8jHcS1539LAQAAAACAAAAAAADZgAAqAAAABAAAABdodw0YhWfcC6+ UjUUOiMwAAAAAASAAACgAAAAEAAAALPzjTRnAPt7/W8v38ikHL5IAAAAzctRyEcHxWkzxeqbq/ V9ogaSqS4UxvKC9zmrXUoJ9mwrNZ/ XZ9LgbfcDXIIAXm2DLRCGRHMtrZrp9yledz0n9kgP3b3s+ X8wFAAAANmLu0UfOJdTc4WjlQQgmZElY7Z8" />

BestLogin은 그림 9에서와 같이 SecureConnection 클래스로부터 GetCnxString 메서드를 호출하여 cnxNWindBest AppSetting 값을 검색하고 이를 다음 코드로 암호 해독합니다.

string strCnx = SecureConnection.GetCnxString("cnxNWindBest");

순서대로 SecureConnection 클래스는 호출을 Win32 DPAPI(데이터 보호 API)로 래핑하는 DataProtect 클래스 라이브러리(여기에 표시되지는 않지만 이 문서의 다운로드에 포함되어 있음)를 호출합니다. DPAPI의 다양한 기능 중 하나는 사용자를 위해 암호화 키를 관리하는 것입니다. DataProtect 클래스 라이브러리 및 이 라이브러리를 사용할 때 고려해야 하는 추가 옵션에 대한 자세한 내용은 Microsoft 패턴 및 연습 가이드 중 하나인 "보안적인 ASP.NET 응용 프로그램 작성: 인증, 권한 부여 및 보안 통신 (영문)"을 참조하십시오.



EncryptCnxString.aspx 페이지를 사용하면 시스템 특정 암호화된 연결 문자열을 만들어서 구성 파일에 붙여 넣을 수 있습니다. 이 페이지는 그림 10에 표시되어 있습니다. 물론, 암호화하거나 해시해야 하는 기밀 정보에는 암호 및 연결 문자열 외에도 신용 카드 번호 및 해커에게 노출될 경우 위험할 수 있는 기타 모든 정보가 포함됩니다. ASP.NET 2.0에는 암호 해싱 및 연결 문자열 암호화를 단순하게 만들어 주는 여러 기능이 포함되어 있습니다.


안전한 실패

런타임 예외를 적절하게 처리하지 못할 경우에도 해커는 이를 악용할 수 있습니다. 따라서 모든 프로덕션 코드에 예외 처리기를 포함시키는 것이 중요합니다. 또한 처리된 예외 및 처리되지 안은 예외는 항상 해커에게 도움이 될 수 있는 정보를 최소한으로만 제공해야 합니다. 처리된 예외의 경우 오류 메시지에서 원래 사용자에 대한 유용성과 악의적인 해커에게 너무 많은 정보를 제공하지 않는 보안성 간의 균형을 맞추어야 합니다.


처리되지 않은 예외의 경우에는 컴파일 요소(Web.config 파일)의 디버그 특성을 False로 설정하고 customErrors 요소의 모드 특성을 On 또는 RemoteOnly로 설정하여 해커에게 최소한의 정보만 표시되도록 해야 합니다. 예를 들어 다음을 보십시오.

<COMPILATION <br defaultLanguage="c#">debug="false" /> <CUSTOMERRORS <br mode="RemoteOnly">/>

RemoteOnly 설정은 localhost로부터 사이트에 액세스하는 사용자에게는 유용한 오류 메시지를 제공하고 원격 위치로부터 사이트에 액세스하는 다른 사용자에게는 예외에 대한 어떤 유용한 정보도 노출시키지 않는 일반적인 오류 메시지를 제공하도록 보장합니다. 로컬 사용자를 포함한 모든 사용자에게 일반 오류 메시지를 표시하도록 하려면 On 설정을 사용하십시오. 프로덕션 환경에서는 Off 설정을 절대로 사용하지 마십시오.


결론

SQL 주입 공격은 보안 시스템에 침입하여 데이터를 훔치거나, 변경 또는 삭제할 우려가 있기 때문에 응용 프로그램 개발자가 신중하게 다루어야 하는 문제입니다. 사용하는 ASP.NET 버전과는 관계없이 이러한 공격에는 너무나 쉽게 취약해질 수 있습니다. 실제로 ASP.NET을 사용하지 않는 경우에도 SQL 주입 공격에 쉽게 당할 수 있습니다. Windows Forms 응용 프로그램과 같이 사용자 입력 데이터를 사용하여 데이터베이스를 쿼리하는 모든 응용 프로그램은 잠재적으로 주입 공격의 대상이 될 수 있습니다.


SQL 주입 공격으로부터 자신을 보호하는 방법은 그렇게 어렵지 않습니다. 모든 사용자 입력에 대한 유효성을 검사 및 확인하고, 동적 SQL을 절대로 사용하지 않고, 최소 권한으로 계정을 사용하고, 해당 기밀 정보를 해시 또는 암호화하고, 해커에게 유용한 정보를 제공하지 않도록 거의 정보를 표시하지 않는 오류 메시지를 제공하는 응용 프로그램은 SQL 주입 공격을 매우 효과적으로 방지할 수 있습니다. 여러 계층의 공격 방어 방법을 사용할 경우 하나의 방법이 실패하더라도 계속해서 보호 상태를 유지할 수 있습니다. [주입 공격 취약성에 대한 응용 프로그램 테스트 정보는 측면 메뉴에 있는 "주입 공격 테스트"를 참조하십시오.]


제공 : DB포탈사이트 DBguide.net

출처명 : 한국마이크로소프트