제1절 윈도우 사고분석
최근 윈도우 서버나 개인 사용자 PC를 겨냥한 해킹뿐 아니라 웜, 바이러스, 봇을 통한 해킹사고 또한 급증하고 있어 관리자나 사용자들을 위한 윈도우 침해사고 분석 기술이 요구되고 있다.
윈도우 사고분석에 있어 포렌식 측면에서 봤을 때 피해시스템에 영향을 주지 않고 필요한 정보를 얻어야 한다. 하지만 그렇게 하기 위해서는 전문적인 포렌식 기술과 도구들이 있어야 하므로 본 가이드에서는 라이브(live)에서 직접 피해시스템을 쉽고 빠르게 분석 할 수 있는 방법에 대해 알아보도록 한다.
1. 초기분석
침해사고를 정확히 분석하기 위해서는 현재 구동중인 프로세스 정보나 네트워크 상태 정보 등 휘발성 증거를 수집해야 한다. 그리고 현재 피해시스템의 상황을 빠른 시간 안에 파악할 수 있는 방법이 필요하므로 윈도우 커맨드에서 실행되는 명령어들을 이용해 프로세스, 네트워크, 로그인 정보들을 수집해야 한다. 분석자는 이러한 정보들을 이용해 최대한 빨리 시스템의 변경내용이나 공격자의 흔적을 파악해야 한다.
가. 시스템 시간 확인
모든 시스템들이 시간을 동기화 시켜놓지 못하기 때문에 각 시스템별로 운영되는 고유의 시간이 있다. 이러한 시간이 파악되어야만 시스템 로그 시간을 연관 지어 확인 할 수 있다. 또한 공격자들은 관리자들의 분석에 혼란을 주기위해 시스템 시간을 변경해 놓는 경우가 있으므로 시스템 현재 시간을 확인해야 한다.
‘date’와‘time’은 cmd.exe 프로그램에 내장되어 있고 시스템 시간을 기록하는데 사용한다. 그리고 uptime은 시스템의 부팅 시간 정보를 보여주는 명령어로 사고 시간을 결정하는데 필요하기 때문에 중요한 정보이다. 도구는 'http://www.sysinternals.com'에서 무료로 다운받을 수 있다.
나. 시스템 정보 사고분석을 위해서는 피해시스템의 기본적인 정보가 필요하다. psinfo는 OS의 기본정보 및 보안 업데이트 정보 등을 제공하며 설치된 소프트웨어 정보 또한 알려준다. 이러한 보안 업데이트 정보는 시스템 취약점을 통해 어떻게 공격했는지에 대한 정보를 얻을 수 있기 때문에 최종 업데이트 날짜를 확인해야 한다.
아래 그림은 psinfo 명령어를 통해 시스템의 정보를 확인한 화면이다.
다. 프로세스 정보 확인 대부분의 윈도우즈 시스템들은 많은 실행 프로세스들을 가지고 있다. 이러한 프로세스 중에는 공격자가 실행시켜놓은 악성프로그램이 실행되고 있거나 흔적이 남아 있을 수 있으니 자세히 확인해 볼 필요가 있다. 관심 있게 확인해 봐야 될 프로세스 정보는 다음과 같다.
- 실행 프로세스명
- 프로세스 실행파일 위치
- 프로세스 커맨드 라인
- 프로세스 실행시간
- 프로세스가 참조중인 DLL 및 파일
프로세스를 점검할 수 있는 도구로는 pslist가 있다. 이 도구는‘http://www.sysinternals.com’에서 다운 받을 수 있으며 현재 구동중인 프로세스 목록을 출력해준다. 옵션을 하지 않으면 프로세스가 실행된 시간을 자세히 확인할 수 있는데 이러한 시간은 또한 uptime에서 확인했던 부팅시간 이후에 악성프로그램이 언제 실행되었는지 확인 가능하다. -t 옵션을 사용하면 프로세스를 트리구조로 어떤 프로세스에서 실행되었는지 확인할 수
있다.
위 명령어 실행결과에서 보면 백도어 프로그램인 rsmss가“winlogon-services”의 자식프로세스로 실행된 것을 확인할 수 있어 윈도우 서비스에 의해 실행된 것을 확인할 수 있다. at.job이라는 악성프로그램 같은 경우는 윈도우에서 흔히 보지 못한 프로그램이 실행되고 있어 어렵지 않게 찾아낼 수 있지만 정상 파일처럼 위장하여 악성프로그램을 실행하는 경우가 있으므로 실행파일 위치를 찾아서 정상 프로그램의 위치와 맞는지 확인해야 한다.
또한 프로그램들이 사용하는 동적라이브러리 (DLL, Dynamic Link Libraries)정보를 수집해야 한다. 악성 프로그램은 시스템 DLL 뿐만 아니라 자체 제작한 DLL을 사용할 수도 있으므로 자세한 점검이 필요하다. listdlls은 모든 프로세스가 사용하고 있는 DLL 정보를 보여주고, 경로, 사이즈, 버전까지도 알 수 있다. 아래 그림은 정상적인 프로그램처럼 위장한 악성프로그램인 TaskDaemon.exe 프로그램을 listdlls로 확인한 화면이다. 이 악성프로그램은 자체 제작한 TaskDaemonRT.dll 등을 사용하는 것을 확인할 수 있다.
또한 악성프로그램들은 자신들의 실행과 관련된 설정파일들이 있고 특히 악성 봇 프로그램 같은 경우 설정파일에 있는 서버에 접속을 하고 명령어들을 실행하기 때문에 자세한 조사가 필요하다. 프로세스들이 어떠한 파일들을 참조하고 있는지 확인할 수 있는 방법은 ‘http://www.sysinternals.com’에서 제공하는 handle 프로그램을 이용해서 확인할 수 있다.
라. 네트워크 정보 확인 현재 피해시스템 네트워크 정보, 서비스를 열고 있는 응용프로그램 정보, 서비스에 연결되어 있는 세션 정보 등은 공격자의 흔적을 추적 할 수 있는 중요한 역할을 한다.
“netstat -an”명령어를 통해 프로토콜 상태, IP 기반 네트워크 연결 정보 등을 확인해서 현재 열려 있는 포트와 포트에 연결되어 있는 IP 정보를 확인해야 한다. 아래 명령어 수행결과에서 보면 시스템이 사용하지 않는 26103 포트가 LISTENING 상태로 열려 있는 것을 확인할 수 있다.
이와 같은 26103포트에 telnet이나 nc로 접속하여 어떤 응용 어플리케이션이 구동중인지 확인해야 한다. 확인 결과 윈도우 command를 실행할 수 있게 해주는 백도어 포트임을아래 그림처럼 확인할 수 있었다.
위의 26103 백도어 포트를 열고 있는 프로세스를 확인해야 하는데 fport 라는‘http://
www.foundstone.com’에서 제공한 명령어를 사용하여 다음과 같이 확인할 수 있다.
해킹 사고가 발생하면 네트워크 인터페이스 카드(NIC)가 promisc 모드로 동작중인지 확인해야 한다. 공격자는 스니핑 공격을 통해 시스템으로 송수신되는 모든 네트워크 트래픽을 모니터링 할 수 있는데 이 경우에 네트워크 인터페이스 카드가 promisc 모드로 동작하게 되므로 반드시 점검이 필요하다.
마. 사용자/그룹 확인
공격자에 의해 추가된 사용자나 그룹이 없는지 다음과 같은 명령어로 확인한다.
바. 공유, 로그인 정보 확인 시스템에서 제공되는“net”명령어를 사용해 현재 시스템에 공유된 정보, 현재 로그인되어 있는 사용자 정보를 확인해야 한다. 그리고 NBT(Net bios)에 연결된 정보가 있는지 nbtstat 명령어를 사용해 확인할 필요가 있다. 또한 시스템의 감사 정책이 설정되어 있다면 ‘http://www.foundstone.com’에서 제공하는 ntlast 명령어를 통해 로그인/로그오프에 대한 성공 실패 여부를 확인할 수 있다.
사. 분석 스크립트 앞서 설명한 프로그램들을 하나씩 실행해 분석 할 수도 있지만 초기분석을 효율적으로 수행하기 위해서는 휘발성 데이터를 빠르게 수집해서 분석해야 한다. 빠르게 수집하고 분석하기 위해서는 배치파일로 위의 명령어를 수행하고 결과는 파일로 저장해야 한다.
아. 자동화 도구 자동화된 스크립트의 사용 이외에도 윈도우 피해시스템 초기 분석을 위해 앞서 설명한 공개용 도구를 이용해 정보를 자동으로 수집해 주는 도구를 사용할 수 있다. 그중에서도 수집된 정보를 아래 그림처럼 브라우저로 확인할 수 있는 기능을 제공하는 WFT(Windows Forensic Toolchest) 사용을 추천한다. 사용방법은 다음과 같다.
- 먼저 WFT와 분석에 필요한 명령어들을 다운받는다.
- 명령어“wft.exe”를 실행한다.
- 시스템에 따라 5분 정도 기다리면 index.html 파일이 생성된다.
- index.html 파일을 열어 관련정보를 확인한다.
※ dd 명령어를 수행하다 프로그램이 끝나는 경우가 발생할 수 있으므로 관련 실행 부분을 wft.cfg 파일에서
주석 처리해 준다. 또한 hfind, streams 명령어 수행시간이 상당히 길어질 수 있기 때문에 이 부분도 주석
처리하길 권장한다.
- 다운로드 :
http://www.foolmoon.net/security/
WFT 도구에서 사용한 명령어는 다음과 같다.
- 기타 도구
WFT외 공개된 자동화 도구는 다음과 같다.
· Biatchux(F.I.R.E)
http://biatchux.dmzs.com/ · IRCR(Incident Response Collection Report)
http://packetstormsecurity/Win/IRCR.zip2. 루트킷 점검 루트킷(RootKit)이란“시스템에탐지되지않도록하는코드, 프로그램의집합”,“ 시스템관리자 권한을 획득하기 위한 프로그램”이라 할 수 있다. 최근 윈도우 해킹동향은 공격에 성공한 후 시스템에 다운로드 된 악성프로그램(Bot, 백도어 등)파일 및 실행된 악성 네트워크, 프로세스 정보를 숨기기 위해 루트킷을 연동하고 있다.
가. 루트킷 기능 대부분의 루트킷은 사용자 모드와 커널 모드의 루트킷으로 구분할 수 있다. 사용자 모드는 파일 교체 즉 특정 프로세스에 사용한 DLL 파일들을 교체하거나 IAT(Import Address Table) 후킹, API 엔트리 패치 방법들을 사용해서 원하는 정보를 숨기는 루트킷들이다. 하지만 커널 모드 루트킷은 윈도우 운영체제 레벨인 윈도우 Native API(ntdll.dll, Kernel32.dll, User32.dll 등) 커널 드라이브와 Win32 응용프로그램 간의 데이터를 조작함
으로써 공격자의 흔적을 감춘다.
이러한 루트킷들의 기능은 다음과 같다.
- 프로세스/스레드 감추기
- 프로세스 보안설정 변경 및 제거
- 파일/폴더 감추기
- 레지스트리/서비스 감추기
- 네트워크 정보 감추기
- 스니핑 및 시스템 제어
현재까지 외부에 공개된 루트킷들은 다음과 같으며 최근 피해시스템에서 발견된 것들은 대부분 아래 루르킷들의 변종이라 볼 수 있다.
나. 루트킷 탐지
루트킷을 탐지하기 위한 방법으로 시스템에 설치되어 있는 안티바이러스 프로그램을 이용할 수도 있겠지만 커널 레벨 까지 검사를 하는 프로그램은 극히 드물다. 또한 루트킷은 악성 프로그램이나 공격자의 흔적을 숨기고 있으므로 이러한 숨겨진 정보를 통해 중요한 정보들을 찾아낼 수 있으므로 반드시 전문 프로그램을 활용해야 한다.
아래 표는 루트킷 탐지 전문 프로그램의 기능을 분석한 표로써 분석자에게 적절한 프로그램을 찾아서 분석하면 된다.
다. IceSword 도구를 사용한 탐지 IceSword는 개인이 개발한 프리웨어 도구로 기능이나 사용자를 위한 인터페이스 측면에서 가장 쉽게 사용할 수 있게 구현되어 있다.
* 다운로드 :
http://www.blogcn.com/user17/pjf/index.html - 프로세스 검사
아래 그림을 보면 실제 피해시스템에서 숨겨진 프로세스를 찾은 화면이다. 숨겨진 root.exe의 실행경로를 통해 악성프로그램들의 홈 디렉터리인“c:\winnt\at2.job\”을 확인할 수 있다. 이 디렉터리는 루트킷에 의해 숨겨져 있으므로 IceSword 도구의“File”을 통해 확인해야 한다.
- 네트워크 점검
다음 그림은 fport 명령어를 통해선 103번 포트의 백도어를 확인할 수 없지만 IceSword 네트워크 정보를 확인하면 루트킷에 숨겨진 백도어 포트를 확인할 수 있다.
- 서비스 점검
대부분의 커널 루트킷들은 서비스로 모듈을 로딩하게 되므로 루트킷을 실행하는 서비스를 숨기게 된다. 아래 그림은 루트킷에 의해 숨겨졌던 서비스를 검출한 화면이다. 이 서비스를 Disable로 하고 Stop으로 상태를 변경해서 시스템을 재부팅하면 루트킷이 실행되는 것을 막을 수 있다.
- 숨겨진 레지스트리/파일 검사
IceSword로 숨겨진 레지스트리를 찾을 경우 수동으로 점검해야 하는 불편함이 있으므로 루트킷에 의해 숨겨진 파일과 레지스트리를 자동으로 찾아서 검출해 주는“Anti-Rootkit” 도구로 확인할 수 있다.
3. 상세분석
가. 레지스트리 분석
윈도우 레지스트리는 시스템이 운영되는데 필요한 정보를 담고 있다. 설치된 소프트웨어 정보부터 환경설정, 임시 저장값까지 시스템에 거의 모든 정보를 담고 있으므로 사고분석에 있어 공격자의 중요한 흔적을 찾을 수 있다.
- 시작 프로그램
아래 레지스트리 목록은 윈도우 시작 시 자동으로 실행하는 프로그램을 등록하는 레지스트리들이다. 공격자들은 악성프로그램을 등록하여 시스템 재부팅 시 자동으로 실행되도록하므로 자세한 분석이 필요하다.
윈도우 시작과 관련된 레지스트리 정보는 sysinternals에서 제공하는 Autoruns 프로그램을 통해 아래와 같이 확인할 수 있다.
아래 레지스트리 키들은 디폴트로 %1%* 값을 갖는데 이들을“server.exe %1%*”로 변경할 경우 exe, com, bat, hta, pif 파일들의 실행 시 매번 server.exe 파일을 자동으로 실행되도록 할 수 있다.
위와 같은 레지스트리들은‘http://www.diamondcs.com.au’에서 제공하는“Autostart Viewer”를 통해 확인할 수 있다.
- 공격자가 남긴 레지스트리 정보 수집
· 최근 사용한 문서 목록
HKCU\Software\Microsft\windows\CurrentVersion\Explorer\Recentdocs
· 터미널 서비스 접속 목록
HKCU\Software\Microsft\Terminal server Client\Default
· 설치된 소프트웨어 목록
HKCU\Software\
· 열어본 파일 목록
HKCU\Software\Microsft\windows\CurrentVersion\Explorer\ComDlg32\OpenSaveMRU
나. 자동실행 점검
- 서비스 점검
공격자는 윈도우 서비스에 자신의 악성프로그램을 등록 시켜 시스템이 재부팅 되더라도 해당 서비스 (등록된 악성프로그램)을 자동으로 재시작할 수 있다. 이러한 방법은 대부분의 공격자들이나 악성프로그램들이 행하고 있는 유형이기 때문에 분석자는 반드시 서비스를 점검할 필요가 있다.
악성 프로그램을 실행하는 서비스를 예상할 수 있는 방법은 다음과 같다.
· 생소한 이름의 서비스
· “Description”내용이 비어있는 서비스
· “Description”내용이 영문인 서비스
하지만 대부분의 공격자 프로그램이 정상적인 서비스 이름으로 가장하고 있기 때문에 찾기 쉽지는 않지만, 현재 시작된 서비스 항목이 어떤 것이며 실행파일 경로가 올바른지 확인해야 한다. 다음은 악성프로그램이 관리자가 혼동하도록 주로 사용하는 서비스명이며 실제 서비스명과 유사하다.
· Backup System
· Remote Administrator Service
· System Spooler Host
· Windows Management Drivers
· Universal Serial Bus Control Components
다음 그림은 공격자에 의해 등록된 서비스를 시스템에서 제공하는“관리도구-서비스”에서 확인한 화면이다.
Autoruns는 현재 구동중인 서비스와 실행된 프로그램을 한눈에 확인할 수 있는 기능을 제공하며 아래 그림은“Services”탭을 실행해 백도어 관련 서비스를 확인한 화면이다. 아래 백도어 관련 서비스는 설명 부분이 비어 있어 쉽게 찾을 수 있다.
- 스케쥴된 작업 확인
시스템은 필요한 작업을 원하는 시간에 예약할 수 있는 기능이 존재 한다. 공격자들은 이러한 기능을 이용해 시스템이 재부팅 되더라도 악성 프로그램이 시작될 수 있도록 할 수 있으므로 점검이 필요하다.
Autoruns의 Scheduled Tasks 기능을 통해 쉽게 확인할 수 있다.
- 자동시작 폴더 점검
윈도우의 재시작 시 이 폴더 안에 있는 모든 프로그램들은 자동으로 실행된다. 윈도우에서 이러한 자동 시작 폴더는 다음과 같다.
· C:\Documents and Settings\Administrator\시작 메뉴\프로그램\시작프로그램
· HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\ShellFolders
Autoruns의 Logon 기능을 통해 쉽게 확인 가능하다.
- Winlogon Notification DLL
Winlogon Notification DLL은 NT 서비스에 비해 적은 코드만으로 구현이 가능하며 안전모드에서도 원하는 코드의 실행이 가능한 장점이 있다. Winlogon.exe에서 발생하는 이벤트 핸들러를 작성하여 Logon, Logoff, Startup, Shutdown, Startscreensaver, Stopscreensaver 등의 이벤트가 발생할 때마다 원하는 코드를 실행할 수가 있다. 관련 레지스트리는 다음과 같다.
※ Troj/Haxdoor-DI 악성프로그램 예
arprmdg0.dll에 의해 삽입된 코드를 동작시키기 위해 아래 레지스트리가 생성된다.
Autoruns의 Winlogon 기능을 통해 점검 할 수 있으며 설명부분이 비워져 있거나 생소한 이름의 dll이 실행되었는지 확인이 필요하다.
다. 이벤트 로그분석 공격자의 흔적 및 활동 정보를 찾아내기 위해서는 로그분석이 필요하다. 윈도우 시스템에서는 하드웨어, 소프트웨어 및 시스템 문제를 이벤트로그에 저장하므로 이벤트 뷰어를 통해 확인이 필요하다.
· 관리도구 -> 이벤트 뷰어
· 실행 -> eventvwr.msc
하지만 공격자는 자신들의 흔적을 지우기 위해‘ClearEvent’같은 프로그램들을 이용해 이벤트 로그를 모두 삭제할 수도 있기 때문에 만약 어떠한 로그도 남아있지 않다면 공격자가 흔적을 지운 것으로 이해해야 한다.
아래 표는 이벤트 점검 시 주의 깊게 살펴봐야 할 것들이다.
라. MAC time 분석 대부분의 파일시스템은 모든 디렉터리나 파일과 관련된 다음과 같은 시간 속성을 갖는다.
- mtime : 파일을 생성 및 최근 수정한 시간
- atime : 최근 파일을 읽거나 실행시킨 시간
- ctime : 파일 속성이 변경된 시간
이러한 시간 정보를 mac time 이라 하며 분석을 통해 공격자가 파일 시스템에서 어떠한 행동을 했는지에 대해 판단 할 수 있는 정보를 제공한다.
· 해킹시점으로 mtime, atime 검색
· 검출된 악성코드 mtime, atime 검색
위와 같은 정보로 검색 후 시간대를 중심으로 정렬해서 시간 흐름에 따라 어떠한 파일이 생성, 수정, 실행됐는지를 분석해야 한다. mac time은 윈도우즈 기능 중“파일 및 폴더 찾기”기능을 통해 확인할 수 있고 점검 방법은 아래 그림과 같다.
· 위치 : 시작-검색-파일 및 폴더-검색옵션-날짜
해킹 발생 날짜를 기준으로“마지막 엑세스 파일”을 검사하게 되면 해킹 발생 후 실행됐던 파일들을 검색할 수 있다.
아래 그림은 발견된 백도어파일 rsmss.exe의 mtime을 통해 윈도우-파일찾기 기능에서 그때 실행됐던 파일들을 조사한 결과 악성프로그램들을 찾을 수 있었다.
마. 침입방법 분석 공격자가 어떻게 시스템에 침입할 수 있었는지에 대한 분석 또한 피해시스템 분석에서 매우 중요하다. 관리자들은 이러한 해킹 원인분석을 하지 않고 사고에 따른 조치만 취하게 되면 이후에 또다시 같은 취약점으로 해킹을 당할 수 있기 때문에 원인 분석을 통해 반드시 패치를 수행해야 한다.
윈도우즈 서버에서 해킹사고가 발생할 수 있는 경우는 크게 다음과 같이 분류할 수 있다.
- 윈도우 취약점
· 시스템 취약점 (보안 업데이트 미실시)
· 패스워드 취약점
· 잘못된 공유설정
- 웹 어플리케이션 취약점
· SQL Injection
· 파일업로드 등
- MS-SQL 취약점
· 디폴트 패스워드 사용
· 패치 미실시
먼저 시스템에 어떤 어플리케이션이 운영 중인지 확인해야 한다. 하지만 대다수의 해킹사고는 시스템 보안 업데이트 미 실시로 인한 윈도우 취약점이나 웹 서비스 공격을 통해 발생한다.
웹 서비스가 구동 중인 경우는 해킹 발생 시점에 발생한 로그 분석을 통해 공격 여부 및 방법을 대부분 확인할 수 있다.
· IIS 로그 위치 : C:\WINNT\system32\LogFiles\W3SVC1
윈도우 취약점의 경우는 최종 보안 업데이트 날짜를 파악 하는 게 중요하다. 최종 보안 업데이트 이후 발표됐던 취약점 중 리모트에서 공격 가능한 취약점이 있었는지 파악하고 관련 서비스가 오픈 되어 있는지 확인해야 한다.
Microsoft에서 제공하는 Microsoft Baseline Security Analyzer를 이용하여 보안 패치상태, IIS, SQL 보안 상태를 점검할 수 있다.
바. 인터넷 임시파일 분석 인터넷 익스플로러를 통해 특정 사이트에 접속하게 되면 관련 사이트의 페이지는 임시파일에 저장되며 접속한 흔적이 히스토리에 남으며 또한 사용되었던 쿠키도 디스크에 저장한다. 이러한 임시파일들을 통해 공격자가 방문한 특정 사이트들을 확인할 수 있다.
임시 인터넷 객체는 사용자가 인터넷을 사용하다 다운받은 ActiveX 프로그램들이 저장된 저장소이다. 임시 인터넷 파일은 사용자가 방문한 사이트 페이지들이 다운로드된 장소이며 열어본 페이지는 사용자가 접속했던 사이트 명들이 히스토리로 저장되어 있다.
위와 같은 인터넷 임시파일들은 indexview를 통해 쉽게 확인할 수 있다. 이 프로그램은 Cookie, Internet 임시파일, History 3가지 형태로 보여준다.
· 다운로드 :
http://exits.ro/dwl/IndexView.exe
4. 해킹프로그램 분석
가. 분석환경 구성 분석을 위해서 최소 2개 이상의 서버를 가상으로 구동시키는 물리적 서버가 필요하다.
- [서비스 제공] 가상서버
· 가상 네트워크가 일반 네트워크처럼 동작할 수 있도록 Samba, HTTP, FTP 등의 서비스를 제공하는 가상서버를 하나 구축한다.
· 해킹프로그램을 분석하다 보면 특정 URL에 접속한다든가 특정 주소로 메일을 보내고 특정 사이트의 IRC 봇에 접속하므로 서비스 구축이 필요하다.
· 서버 OS를 리눅스로 구성하는 것은 테스트하는 악성프로그램에 의해 공격받거나 감염되는 것을 최소화 하기 위해서다.
- [피해 대상] 가상서버
· 해킹프로그램을 실행하는 서버를“피해대상”서버라 한다.
· 해킹프로그램을 실행했을 때 시스템 파일과 레지스트리에서 발생하는 내용을 확인하기 위하여 모니터링 하는 프로그램이 설치되어야 한다.
· 해킹프로그램 테스트 후 다시 이전 상태인 초기설정으로 복구할 수 있어야 한다.
※ Snapshot 기능 활용
나. 분석 방법 ① SysAnalyzer 도구 사용
· 다운로드 :
http://labs.idefense.com SysAnalyzer 도구는 악성코드가 시스템에서 구동되는 동안에 주어진 시간에 이후에 변경된 정보를 수집, 비교, 분석 보고해 주는 자동화된 툴이다. SysAnalyzer의 주된 임무는 지정된 시간에 걸쳐 시스템의 스냅샵을 비교하는 작업을 수행한다.
· Delay : 스냅샵 전.후 사이의 값 지정
· Sniff Hit : HTTP 접속 및 IRC접속 정보를 확인
· Api Logger- 분석 바이너리에 인젝션 되는 DLL에서 호출되는 API 목록
· Directory Watcher- 모니터링 시점에 생성되는 모든 파일 확인
SysAnalyzer는 비교된 스냅샵을 통해 실행된 악성코드에 다음과 같은 정보를 얻을 수 있다.
· 실행된 프로세스
· 악성코드에 의해 오픈된 포트
· explorer.exe나 Internet Explorer에서 로드된 DLL
· 커널에 로드된 모듈
· 변경/생성된 레지스트리 키
다음은 해킹프로그램이 HTTP 사이트와 IRC Bot 채널에 접속한 정보를 Sniff_Hit 프로그램이 캡쳐한 화면이다.
② Malcode Analysis Pack
· 다운로드 :
http://labs.idefense.com Malcode Analysis Pack은 악성코드들을 조사하는데 유용한 도구들을 포함하고 있는 유틸리티이다.
이 패키지가 포함한 유틸리티들은 다음과 같다.
· ShellExt : 문자열 확인 기능 및 MD5로 암호화 기능 제공
· socketTool : TCP 클라이언트 모니터링 프로그램
· MailPot : 메일 서버 캡쳐 프로그램
· fakeDNS : 악성프로그램이 접속하는 도메인을 다른 곳으로 유도하기 위해 사용하는 스푸핑 미니 DNS
서버 프로그램
· Sniff_Hit : HTTP, IRC, DNS 스니퍼
· sclog : 악성코드에서 사용하는 쉘코드 분석 도구
· IDCDumpFix : 패킹 프로그램 언패킹 할 때 사용하는 보조 도구
· Shellcode2Exe : 인코드된 쉘코드로 변환하는 php 스크립트 프로그램
· GdiProcs : 숨겨진 프로세스 탐지에 사용
- fakeDNS
fakeDNS 프로그램은 VMware 환경의 외부 네트워크와의 통신을 차단하고 내부망을 통하여 악성 프로그램을 분석하는 환경에 매우 유용한 프로그램이다. 일부 IRC봇 프로그램은 dns 쿼리를 보내 접속이 되지 않는 경우 실행을 끝마치는 경우가 있는데 이럴 때 이 프로그램을 통해 [서비스제공] 가상 서버로 유인해서 실행할 수 있다. DNS 쿼리를 모두 자신의 127.0.0.1로 설정하거나 가상서버로 지정하여 트래픽을 유도 할 수 있다.
- MailPot
공격자는 해킹 후 스팸 메일을 유포하는 프로그램을 통해 대량의 메일들을 발송하곤 한다. 이러한 스팸메일을 확인하기 위해 MailPot 프로그램을 활용한다. 이 MailPot 프로그램은 fakeDNS 프로그램과 연동해 자신이 원하는 곳으로 유인해 아래와 같이 전송된 메일을 확인한다.
③ 다양한 모니터링 프로그램 활용
제2절 리눅스 사고 분석
1. 개요 최근 리눅스 시스템에 대한 사고가 줄어들고 있는 경향을 보이고 있지만, 이는 리눅스 시스템의 활용도 자체가 낮아졌다는 것을 뜻하는 것은 아니다. 본 절에서는 리눅스 피해 시스템에 대한 정보수집 등의 초기 분석단계부터 로그분석과 상세분석 단계에 대해 알아보도록 한다.
2. 기본정보 수집 해당 시스템 운영자 면담 또는 시스템에서 제공되는 명령어 등을 이용하여 다음과 같은 기본 정보를 수집한다.
- 운영체제 종류 및 커널 버전
- 사용용도
- 운영 중인 서비스
- 네트워크 접속 현황
- 보안 패치 적용 현황
- 네트워크 구성 형태 및 보안 장비 운영 현황
3. 휘발성 정보 수집 리눅스 시스템에는 분석당시에만 존재하고, 시스템 리부팅 등을 통해 정보가 삭제될 수 있는 다양한 휘발성 정보가 존재한다. 휘발성 정보는 프로세스 상태, 네트워크 상태, 사용자 로그인 상태 등이 있으며, 사고분석 시 이러한 휘발성 정보를 우선적으로 검출하여야 한다.
● 프로세스 확인하기 : ps -ef
ps는 process를 확인해 주는 것으로, process 실행자∙ PID∙실행 일시∙프로세스명 등을 보여준다.
의심스런 PID를 찾는데 위의 예에서는 PID 316을 의심해볼 수 있으며, 어떤 프로세스인지 확인한다.
● lsof(List Open File)
lsof는 System에서 돌아가는 모든 process에 의해서 open된 파일들에 대한 정보를 보여주는 프로그램이다. 공격당한 시스템에 ps가 변조되어 있을 경우에는 ps로는 공격자가 구동한 process 정보를 제대로 볼 수 없는데 이럴 경우에는 lsof로 확인할 수 있다.
● netstat -an
netstat는 현재 시스템의 네트워크 연결상태를 알려주는 명령어로 어떤 포트가 열려있는지 발신지 주소는 어떻게 되는지 등을 확인할 수 있다.
● nmap -sT -p 1-65535
nmap(network mapper)은 네트워크 보안을 위한 유틸리티로, 대규모 네트워크를 고속으로 스캔하는 도구이다. 스캔 타입으로 -sT는 tcp scanning의 가장 기초적인 형태로 connect() 함수를 사용해서 모든 포트에 대해 스캔하는 방식을 의미하고, -p 는 점검하고자 하는 포트를 지정하는 옵션이다.
ps, lsof, netstat, nmap 등을 통해 시스템의 상황을 파악하고, 공격자의 단서를 찾으며 세부사항을 살펴서 어떠한 기능이나 역할을 하는 것인지 확인해본다.
● fuser
만일 netstat로 프로세스를 확인할 수 없는 경우, nmap과 fuser를 사용하여 어떤 프로세스에서 포트를 열었는지 확인할 수 있다. fuser는 현재 사용 중인 파일 또는 소켓이 사용하는 프로세스를 확인하는 명령어로 열려있는 포트와 해당 포트를 사용 중인 프로세스 확인을 통해 백도어 등의 악성 프로그램 구동 여부를 확인할 수 있다.
● 접속자 확인
w, who등의 명령으로 접속자를 확인한다.
-“ w”는utmp를참조하여현재시스템에성공적으로로그인한사용자에대한 snapshot을 제공해주는 명령으로 해킹 피해시스템 분석시에 반드시 확인해 보아야만 한다. 왜냐하면 현재 시스템 분석 중에 공격자가 같이 들어와 있을 경우 자신이 추적당하는 것을 눈치채고 주요 로그를 지우거나 아예 포맷팅을 해 버릴 수도 있기 때문이다.
- 물론, 정상적인 로그인 절차를 거치지 않고 백도어를 통해 시스템에 접근했을 경우에는 실제 공격자가 시스템에 로그인해 있음에도 불구하고 보여지지 않는다.
-“ w”의결과어떤사용자들이어디에서로그인해들어와있는지알수있고, 그리고 그 사용자들이 어떤 작업을 하고 있는지 보여준다.
- 사고 분석시에 공격자를 규명하기 위해 특히 주의 깊게 봐야 할 부분들은 아래와 같다.
· 접속한 사용자 계정이 모두 정상적인 사용자들인가?
· 접속출처가 정상적인 위치인가? 특히, 내부 IP주소 이외에서 접속하였거나, 국외 IP주소에서 접속한 경우는 의심할 필요가 있다.
· 사용자들의 행위가 정상적인가? scan 도구를 실행하고 있거나 타 시스템을 대상으로 서비스거부공격을 하고 있는지 살핀다.
4. 상세분석
가. 패스워드 파일 분석
● /etc/passwd파일에서 uid=0인 계정(관리자 권한을 가진 계정)이 있는지를 확인한다.
예) 불법계정이 추가된 /etc/passwd파일
...
blah1::0:0::/tmp:/bin/bash
user1:x:0:0::/home/user1:/bin/bash
● 또한 새로 생성된 계정이나 패스워드가 없는 계정도 점검하여 본다.
나. 로그 파일 분석 침해사고 피해가 발생한 시스템의 로그는 100% 신뢰할 수 없게 된다. 하지만 대부분의 사고에서 공격관련 로그와 함께 침입 후 진행된 작업의 흔적들이 로그에 남게 되므로 로그분석을 통해 사고원인을 파악하는데 많은 도움을 얻을 수 있다.
● 로그파일의 생성일자 및 변경일자 확인
- 외부의 공격자는 공격으로 인해 생성되는 시스템 및 접속로그 등을 삭제하는 경우가 많다. 로그의 내용 중 일부를 삭제하거나 변경할 경우, 해당 로그파일의 수정일자가 변경되게 되므로 변경일자 확인을 통해 확인한다. 또한 로그 삭제 프로그램을 이용해 로그를 삭제하는 경우, syslog 데몬이 재시작 되는 로그가 남기도 한다.
● 주요 로그파일
- utmp, wtmp
해당 파일에는 현재 시스템에 로그인한 사용자나, 과거에 로그인했던 사용자의 정보가 저장되게 된다. 따라서 시스템 분석 시에 꼭 확인해야 하는 로그파일이나, passwd 파일에 등재되어 있는 계정을 이용해 정상적으로 시스템에 로그인했을 때에만 로그가 생성되게 된다.
- messages
많은 정보를 포함하고 있는 로그파일로서, 시스템 장애에 대한 정보와 더불어 공격으로 인해 남게 되는 많은 유용한 정보 또한 messages 파일에 남는 경우가 많다. 동작 중인 서비스에 대한 버퍼 오버플로우 공격의 경우, 특히 messages 파일에 그 흔적이 남게 되므로 사고 분석 시, messages 파일을 필히 확인하도록 한다.
예) RPC.STATD 공격 시의 messages 로그
messages.2:Mar 30 03:37:02 www statd[136]: attempt to create “/var/statmon/sm/;echo “ingreslock stream tcp nowait root /bin/sh sh -i” >>/tmp/bob ; /usr/sbin/inetd -s /tmp/bob &”messages.2:Mar 30 23:36:20 www statd[124]: attempt to create“ / v a r / s t a t m o n / s m / / ../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../.
./../../../../../../../../../../../../../..../../../../../../../../../../../../../../../../../../../../../../../../..
/.././../../../../..../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../
../../../../../../../../../../../../tmp/.nfs09 D H $ $ $ $ O * * * * # # P *` c 6 ) # # ; # XbinXsh tirdwr
●웹 로그
최근 많은 침해사고들이 웹 취약점을 이용한 것으로 확인되었다. 웹 취약점에 대한 공격은 주로 중국 해커에 의한 것으로 확인되고 있으며, 중국 해커 대부분은 공격을 위해 제작한 프로그램을 이용 공격을 한다.
- access_log 확인
<로그 예제>
211.252.***.*** - - [07/Nov/2006:10:05:02 +0900]“ GET /goodstore.htm HTTP/1.1” 200 1738“ -”“Mozilla/4.0 (compatible; Google Desktop)”
· Host (도메인 또는 IP 주소) <예제부분 211.252.***.*** >
: 해당 웹 서버에 접속한 IP 주소를 나타낸다.
· Identification <예제부분 - >
: 사용자의 이름을 표시하는 곳으로서, 일반적으로 하이픈(-)으로 표시된다.
· User Authentification <예제부분 - >
: 패스워드가 표시되는 부분으로 사용자 인증이 사용된 경우에 표시된다. 일반적으로 하이픈(-)으로 표시된다.
· Time Stamp <예제부분 [07/Nov/2006:10:05:02 +0900]>
: 사이트 방문자가 접속한 시간이 나타나는 부분이다. +0900은 GMT(그리니치 표준시)를 의미한다.
· HTTP Request 필드 <예제부분 GET /goodstore.htm HTTP/1.1>
: 사용자가 접속한 방식(GET, POST)와 접속한 해당 파일, 접속에 사용된 HTTP 버전을 알수 있다.
· Status 코드 <예제부분 200>
: 사용자가 요청한 내용이 처리된 상태를 나타낸다. 세부적인 Status 코드는 아래 표와 같다.
· Transfer Volume <예제부분 1738>
: 호출된 파일의 용량을 나타낸다. 데이터가 없는 경우 하이픈(-) 또는 0으로 나타난다.
- 공격 로그
공격으로 인해 남게 되는 로그는 여러 유형이 있을 수 있다. 본 문서에서는 '05년 홈페이지 변조에 많이 이용되었던 국내 공개용 게시판 공격 시 남게 되는 로그를 살펴보도록 한다. PHP Injection 기법을 이용한 공격은 대부분 아래와 같은 형태의 로그를 남기게 된다.
· 제로보드 공격로그 예제
: 다음 로그는 제로보드 취약점 중, print_category.php 파일의 취약점을 이용해 공격한 access_log의 예제이다.
① 최초, 외부 사이트의 URL을 이용해, 피해 시스템에서 id 명령 실행을 통해, 취약점 존재여부와 웹 서버 구동 권한을 확인하고 있다.
② 그 후, 시스템 접속을 위해 백도어 프로그램(r0nin)을 피해시스템에 업로드 하고 있다.
③ 업로드한 백도어에 실행권한을 부여한 후, 백도어 프로그램을 실행하고 있다.
· 테크노트 공격로그 예제
: 다음 로그는 테크노트 취약점을 이용한 공격 시 access_log에 남게 되는 로그이다.
공격에 이용된 취약점은 다르지만, 로그 상으로 확인되는 공격과정은 제로보드와 매우 유사한 것을 확인할 수 있다.
① 테크노트의 구성파일인 main.cgi 파일의 취약점으로 인해 웹 브라우저 상에서 바로 시스템 명령의 실행이 가능한 것을 확인할 수 있다. wget 명령을 이용해 외부의 사이트로부터 백도어 프로그램(rootdoor)을 다운로드 하고 있다.
② 다운로드 한 백도어 프로그램에 실행권한을 부여한 후 실행하고 있다.
다. 루트킷(Rootkit) 확인
공격자는 자신의 행동을 숨기기 위해 정상적인 프로그램들을 대신하도록 바이너리 파일들을 변조시키는 경우가 많다. 예를 들어 ls를 바꿔치기해서 ls를 실행시켜도 공격자가 만든 파일이 보이지 않도록 하는 것이다.
주로 많이 변조되며 루트킷에 포함되어 있는 프로그램으로는 ls, ps, netstat, login, top, dir, du, ifconfig, find, tcpd 등이 있다.
시스템 프로그램의 파일크기, 생성시간, 변경시간등을 확인한다. /bin또는 /usr/bin에 가서 #ls -alct|more로 확인했을 때 다른 프로그램이 기본적으로 깔린 시간과 틀리게 변경된 것이 있는지 트로이잔으로 자주 변조되는 ls, ps, netstat등의 파일사이즈는 똑같은 OS, 버전의 다른 시스템의 프로그램과 비교하여 변조 여부를 확인한다.
리눅스의 경우 rpm -V fileutils 명령어로 무결성 검사를 할 수 있다. 명령결과가 예를들어 S,5 .../bin/ls 로 나타난다면 파일크기 파일 내용이 변조됐다는 의미이다.
솔라리스의 경우“fingerprint”를 제공하고 있으며 아래의 사이트에서 md5 프로그램을 다운받아 설치하고 검사하고자 하는 파일의 checksum 값을 만들어 이를 비교해 봄으로써 파일의 변조유무를 알수 있다.
http://sunsolve.Sun.COM/pub-cgi/show.pl?target=content/content7 strace 명령을 통해 시스템 콜을 추적할 수 있다. 트로이잔으로 변경된 시스템 프로그램과 정상적인 시스템 프로그램을 strace 명령어를 이용해 비교해 변조유무를 확인할 수 있다.
예를 들어 공격을 당한 시스템을 분석했을 때 ps가 아래와 같이“/usr/lib/locale/ro_RO/uboot/etc/procrc”파일을 참조하는 것을 볼 수 있었으며, 이 파일은 공격자가 숨기고 싶은 프로세스명을 /usr/lib/locale/ro_RO/ uboot/etc/procrc에 나열하고 있었고 이런 경우 ps명령으로는 해당 프로세스가 보이지 않게 된다.
그러므로 strace명령어를 이용해 위의 예에서처럼 시스템 명령의 변조유무와 숨기고자하는 파일들이 들어있는 위치 등을 파악할 수 있다.
라. 기타 해킹 관련 파일 조사 공격자가 피해 시스템에 들어와 어떤 작업을 했는지를 분석한다. 혹 다른 시스템을 스캔하거나 공격도구를 설치하였는지, irc서버를 설치하였는지, 로그를 삭제하였는지, 스니퍼프로그램을 설치하였는지 등을 조사한다.
아래의 명령어는 최근에 수정되거나 새롭게 생성된 파일을 찾는 명령어로 공격자가 시스템 파일의 변조를 숨기기 위해 시간을 수정하는 경우가 있으므로 이러한 경우에 대비하여 inode 변경시간을 점검한다.
예) 최근 10일동안 수정되거나 새롭게 생성된 파일을 찾아서 /var/kisa/cime10.out에 저장하라는 명령
#find / -ctime -10 -print -xdev >/var/kisa/cime10.out
setuid를 가지는 실행 프로그램은 실행도중에 슈퍼유저(root)의 권한을 가지고 실행되므로 find를 이용하여 setuid나 setgid 파일이 있는지 확인한다.
#find / -user root -perm -4000 -print>suidlist
#find / -user root -perm -2000 -print>sgidlist
숨겨둔 파일 찾기 : 보통 공격자가 자주 해킹과 관련된 파일을 가져다 놓는 디렉터리는 /usr,/var,/dev,/tmp가 있으며 이런 디렉터리에 이상한 파일이 존재하지는 않는지 조사 한다.
또한 공격자들은 주로“.”나“..”로 시작하는 디렉터리를 만들어 사용하는 경우가 많으므로 (이는 관리자가 아무런 옵션없이 ls 명령어를 사용할 경우 보이진 않으므로) 다음의 명령으로 숨겨진 디렉터리가 있는지 점검해본다.
예) # find /-name "..*" -print 또는
# find /-name ".*" -print
예) 일반적으로 /dev밑에는 MAKEDEV등과 같은 device관리 파일외에의 일반파일이 있으면 안되므로 device관리 파일외에 일반파일이 검색되는지 확인한다.
#find /dev -type f -print
시스템이 부팅될 때 같이 수행되도록 /etc/rc.d 디렉터리(rc.sysinit, rc.local), rc0.d~rc6.d 디렉터리에 넣는 경우가 많으므로 이를 확인한다.
제3절 네트워크 사고 분석
1. 사고 유형별 수집 데이터
침입 사고나 네트워크 공격이 발생했을 경우, 네트워크 관리자들이 발생 현황을 파악하고 증거 분석을 위해서 여러 가지 정보를 수집해야 한다. <표 3-7>은 네트워크에서 발생하는 다양한 사고의 종류와 해당 사고가 발생한 경우에 수집해야하는 정보들이다.
위 <표 3-7>에서와 같이 대부분의 사고나 공격이 발생하는 경우, 그 원인과 발생지를 찾기 위해서 네트워크 트래픽 정보와 패킷은 반드시 수집하여 분석해야 한다. 네트워크 트래픽 정보는 MRTG와 같은 공개 소프트웨어나 네트워크 관리에 사용되는 많은 NMS(Network Management System), 보안을 위하여 사용하는 방화벽, IDS 등에서 수집할 수 있으며, 라우터나 스위치의 간단한 명령어만으로 확인할 수도 있다. 또한 명확한 원인 분석을 위하여 필요한 실제 네트워크 패킷들은 공개 프로토콜 분석기인 Ethereal이나 편리한 사용자 인터페이스를 제공하는 다양한 전문 분석기를 사용하여 간단하게 수집 및 분석할 수 있다.
네트워크에서 수집할 수 있는 주요 정보는 대역폭 사용량, 트래픽을 대량으로 발생시키고 있는 IP 주소, 침입을 위하여 내부의 사용자나 서버의 IP 주소나 TCP/UDP 포트를 스캐닝하고 있는 IP 주소, 프로토콜 (TCP/UDP 포트)별 사용 현황, 라우터나 스위치의 포트별 트래픽 발생 현황 등과 같은 통계 데이터와 실제 데이터를 송수신하고 있는 패킷들이다.
2. 프로토콜개요 네트워크에서 수집한 패킷들은 많은 IP와 TCP/UDP 헤더 정보를 포함하고 있기 때문에 패킷들을 명확하게 분석하기 위해서는 TCP/IP 헤더에 대한 이해가 필요하다. <그림 3-38>은 IP 헤더에 포함되는 정보이다.
IP 헤더의 일부 필드는 네트워크 공격이나 침입에 사용된다.
● Flag (3 bits)
- Bit“ 0”: 일반적으로0으로설정
- Bit“ 1”: 0이면큰패킷에대한조각이며, 1이면조각을허용하지않는것이다.
- Bit“ 2”: 0이면해당패킷이마지막조각이며, 1이면마지막이아니다.
- 이 필드는 Ethernet에서 전송할 수 있는 1518bytes의 이하의 패킷을 강제로 작은 조각으로 분리해서 전송하는 경우에 사용한다. 즉, 대상 시스템의 전송 계층이 아닌 IP계층에서 패킷을 모두 모아야 상위 계층으로 전달하게 된다. 보안 장비에서 전송 계층의 헤더만 검색하는 경우에는 막을 수 없게 하는 방법으로 사용되기도 한다.
● Time to Live (8 bits)
- 일반적으로 TTL이라고 하며, 해당 패킷이 전송과정에서 통과할 수 있는 최대 라우터개수를 나타낸다.
- 해당 패킷의 전송 수명을 제한하는 것이며, 송신 시스템에서 특정 값으로 설정되어 라우터를 통과할 때마다 하나씩 감소한다.
- 이 필드의 값이“0”에 도달하였을 때에 해당 패킷은 버려지고, 송신 시스템에게 ICMP 프로토콜을 사용하여 전송하는 과정에서 에러가 발생하였음을 통보하게 된다.(무한 라우팅 루프를 방지)
- 내부적으로 시스템 간의 테스트 (local test)를 위하여“1”로 설정된 패킷을 송신하기도 하지만, 내부의 시스템에서 라우터와 네트워크를 공격하기 위하여 강제로“1”로 설정하기도 한다.
● Protocol (8 bits)
- IP 계층(네트워크)의 상위 계층(전송)에 있는 프로토콜을 표시한다.
- ICMP (1), TCP (6), UDP (17)
- 0부터 255까지의 값을 갖지만, 255는 사용하지 못하게 예약되어 있다. 전송 계층의 프로토콜을 해석하지 못하여 전송 계층의 헤더를 해석하는 장비에서 오류가 발생하도록 공격하는 패킷에서 255로 사용하기도 한다.
<그림 3-39>는 전송 계층인 TCP의 헤더이다. TCP 헤더는 시스템과 네트워크를 연결해주는 가장 중요한 계층이기 때문에 가장 복잡하고 공격이나 침입을 파악하기 위하여 주요 필드는 반드시 이해하고 있어야 한다. 대부분의 분석 자료에서 살펴보면, 네트워크 웜(worm),Dos 공격 및 침입 포트 또는 공격 패턴을 설명하기 위하여 많이 인용하는 헤더이다.
침입이나 공격 패킷들을 분석하기 위해서는 다음 TCP 필드들을 살펴보아야 한다.
● Source Port (16 bits)
- 0 ~ 65535까지 정의할 수 있으며, 해당 패킷을 보내는 시스템에서 할당한 논리적인 포트이다. 즉, 해당 패킷에 대한 응답을 받는 시스템의 포트이다.
● Destination Port (16 bits)
- 0 ~ 65535까지 정의할 수 있으며, 해당 패킷을 받는 시스템에서 할당한 논리적인 포트이다.
- 이 두 포트 번호가 상대적으로 서로 일치하면, 한 세션으로 인식된다.
- 네트워크를 통하여 특정 어플리케이션을 공격하는 경우에는, 이 포트가 해당 어플리케이션에서 사용하는 서비스 포트이다. 대부분 한 포트만 공격하지만, 최근의 네트워크 웜들은 여러 개의 포트를 동시에 공격하는 경우도 있다.
● Sequence Number (32 bits)
- 송신자가 전송하는 데이터의 TCP 세그먼트 번호이다.
- 번호는 초기 접속 과정에서 할당되어 전송되는 데이터 세그먼트의 크기만큼 증가한다. 즉, TCP 헤더 다음에 포함되어 있는 데이터 바이트 수만큼 증가한다.
- TCP 헤더 다음에 데이터가 포함되어 있지 않은 경우에는 증가하지 않는다. 즉, Ack
패킷의 경우에는 데이터가 포함되어 있지 않기 때문에 몇 개의 Ack 패킷들에 할당되
어 있는 번호가 같게 된다.
● Acknowledgement Number (32 bits)
- 송신자가 해당 패킷을 수신하는 호스트로부터 다음에 받아야 하는 패킷의 TCP 세그먼트 번호이다. 즉, 해당 패킷을 수신한 호스트에서는 이 번호가 할당되어 있는 패킷으로 응답한다.
● Control Bits (6 bits)
- TCP 세그먼트의 목적, 즉 해당 패킷의 용도를 표시한다. 각 필드가“1”로 설정되면, 해당 패킷은 설정된 용도를 위하여 전송되는 것이다.
- URG (Urgent Pointer Field): 긴급을 전달이 필요한 패킷임을 표시한다.
- ACK (Acknowledgement): 이전 패킷에 대한 응답 패킷임을 표시한다.
- PSH (Push): 해당 세그먼트를 메모리에서 재합성하지 말고 어플리케이션에게 바로 전달해야 하는 세그먼트임을 표시한다.
- RST (Reset): 해당 세션을 강제로 종료함을 표시한다.
- SYN (Synchronize): 초기 접속을 시작하는 경우에 사용된다. 이 플래그가 설정된 패킷에는 초기 Sequence Number와 TCP Window 크기가 명시되어 있다. <그림 3-40-A>는 TCP 세션 시작을 위하여 송수신
되는 패킷들의 흐름이다.
- FIN (Fin): 세션 종료를 위한 패킷임을 표시한다. <그림 3-40-B>는 TCP 세션 종료시점에서 송수신되는 패킷의 흐름이다.
● Window (16 bits)
- TCP에서 데이터의 송수신 과정을 원활하게 하기 위하여 사용되는 버퍼의 크기이다.
초기 접속하는 과정에서 운영체제나 어플리케이션에 따라 다른 크기로 할당된다.
- 데이터 세그먼트를 수신하는 호스트에서는 해당 세그먼트를 버퍼에 누적하는 경우에, Window 크기를 감소시켜서 송신하는 호스트에게 통보해야 하여 데이터 송신을 늦추고, 누적된 세그먼트들을 처리했을 경우에는 다시 Window 크기를 초기화 한다.
- 네트워크 시스템이나 특정 호스트를 공격하기 위하여 많은 패킷들을 송신하는 일부 네트워크 웜의 경우에는 TCP Window가 일정한 크기로 고정되어 있다. 때문에 웜의 특징을 설명할 때에 종종 TCP Window 크기를 명시하기도 한다.
3. 패킷 수집 및 디코드
가. 측정 구간 외부의 침입이나 공격을 확인하기 위하여 트래픽과 패킷을 수집해야 하는 위치는 목적에 따라서 다르겠지만, 가장 우선적으로 <그림 3-41>와 같이 라우터와 가까운 위치에서 수집해야 한다. 또한 방화벽을 사용하고 있고, 방화벽에서 IP 주소를 공인에서 사설로 바꾸어 주는 NAT 기능이 동작하고 있다면, 방화벽 앞과 뒤에서 동시에 측정하는 것도 좋은 방법이다. IP주소는 바뀌지만, 같은 시간대에 생성된 세션을 찾아서 동일한 패킷들로 분석할 수 있다.
IP 주소를 변조하여 네트워크를 공격하는 최근의 네트워크 웜을 찾아서 분석하기 위해서는 내부 네트워크의 전 구간이 측정 대상이 되며, 특히 백본이나 주요 액세스 스위치들의 포트 트래픽과 CPU 상태를 동시에 관찰해야 한다. 대부분의 네트워크 공격들이 외부에서 특정 시스템이 과도한 트래픽을 발생시켜서 라우터나 방화벽 또는 백본 스위치에 영향을 주기보다는 내부에 있는 호스트가 서로를 공격하도록 하는 DDos (Distributed Dos) 방법을 사용하고 있다.
나. 패킷 수집
대부분의 프로토콜 분석기에는 기본적으로 캡쳐 옵션들을 설정하여 패킷을 버퍼나 파일로 저장하는 방법을 제공한다. 만약 패킷의 헤더 정보만 분석에 필요하고, 실제 사용자들의 데이터가 필요하지 않은 경우에는 모든 패킷들의 시작부분에서 일정 크기만큼만 캡쳐하는기능도 제공한다.
파일로 저장하는 기능에는 일정 개수의 파일을 항상 유지하도록 하는 기능이 있으며, 일정 개수만큼 생성되는 파일에는 항상 최근의 패킷들만 포함되도록 하는 기능도 (Ring Buffer) 유용하게 사용할 수 있다. 즉, 언제 어떤 사고가 발생할지 알 수 없는 상황에서 항상일정 시간동안의 트래픽 정보와 패킷을 보관하고 있으면, 사고가 발생해도 명확한 원인을 분석할 수 있다.
패킷을 수집하여 파일로 저장할 때, 파일의 크기는 24~32 MBytes로 설정하는 것이 좋다. 파일 크기를 너무 크게 설정하면, 향후에 다시 분석기에서 해당 파일을 읽어 들여서 저장되어 있는 모든 패킷들을 분석하는데 많은 시간이 필요하게 된다. 저장되는 파일의 개수는 패킷을 수집하는 구간에서 발생하는 트래픽과 패킷 저장이 필요한 시간을 계산하여 설정한다. 즉, 패킷을 캡쳐하는 동안 파일 하나가 생성되는데 몇 분이 필요한지 파악하면, 원하는 시간동안의 모든 패킷들을 캡쳐하기 위해서는 몇 개의 파일이 생성되어야 하는지 계산할 수 있다.
다. 트래픽 통계 관찰 트래픽 통계는 NMS나 주요 시스템의 내부 명령어를 사용하여 언제든지 관찰할 수 있으며, 패킷이 캡쳐된 시간동안의 트래픽 통계도 분석기에서 간단하게 살펴볼 수 있다. 침입에 대한 분석을 하기 위해서는 침입을 탐지하는 시스템의 로그와 침입 대상이 된 시스템의 로그를 함께 관찰하는 것이 좋다. 공격이나 비정성적인 트래픽에 대해서는 시스템에서 제공하는 통계나 분석기에서 제공하는 통계만으로 간단하게 관찰할 수 있다.
● MAC 주소별 트래픽 통계: 사용자들이나 서버들이 연결되어 있는 액세스 스위치 구간에서는 호스트별 MAC 주소를 확인하여 트래픽 발생 상태를 관찰할 수 있다. 하지만, 라우터나 백본 구간에서는 호스트의 MAC을 확인할 수 없기 때문에 중요한 의미를 갖지 못한다.
● IP 주소별 트래픽 통계: 침입이나 공격은 IP를 기반으로 발생하기 때문에 IP 주소별로 모든 트래픽 통계를 분리하여 관찰할 필요가 있다. 만약 네트워크에서 웜이 활동하거나 DDos가 발생하고 있다면, 내부 IP 주소에서 전송하는 패킷 개수가 수신하는 패킷 개수보다 훨씬 많아지게 된다. 또한 패킷 개수에 비하여 송수신되는 바이트 수가 매우 적다는 것을 발견할 수도 있다.
● TCP/UDP 세션별 트래픽 통계: 세션별 트래픽 통계에서는 어느 세션이 서버에서 몇분 동안 작업을 했으며, 어느 정도의 패킷이나 데이터가 송수신 되었는지를 확인할 수 있다. 외부 IP 주소가 서버에 접속하여 무언가 작업을 하거나 데이터를 올리는 경우에는 서버에서 수신한 bytes 수가 더 많을 수도 있다. 대부분의 분석기에는 세션별 트래픽 통계에서 제공하는 IP 주소와 TCP/UDP 포트 번호들을 참조하여 필터를 정의할 수 있으며, 정의된 필터로 해당 세션에 대한 패킷들을 추출할 수 있는 기능을 제공한다.
특정 구간에서 일정 시간 동안 모든 패킷을 캡쳐하면 디코드 화면에 표시되는 패킷들이 무수히 많기 때문에, 필터를 구성하여 관련성이 있는 패킷들만 추출하는 것이 중요하다. 분석기에서는 통계 자료를 기반으로 필터를 정의하는 방법에 대해서 익숙할 수 록 원하는 패킷들을 신속하게 추출할 수 있게 된다.
라. 패킷 디코드 프로토콜 분석기들의 다양한 필터를 사용하여 원하는 패킷들을 추출한 후, 상세하게 분석하기 위해서는 분석기의 디코드 화면을 이해하고 칼럼들을 분석에 적합하도록 구성해야 한다. 패킷 분석에 필요한 디코드 화면과 칼럼 구성은 아래 <그림 3-46>과 같다.
대부분 프로토콜 분석기들의 디코드 화면은 유사하다. 먼저 상단 화면에서는 캡쳐된 패킷들의 목록과 간단한 정보를 표시하며, 중간 화면에서는 상단 화면에서 선택한 한 패킷의 계층별 프로토콜 헤더 정보를 표시한다. 하단 화면에서는 선택한 패킷에 포함되어 있는 실제 내용을 16진수와 ASCII 코드로 표시한다. 다음은 패킷 목록을 표시하는 상단 화면에서 패킷을 관찰하기 위해 필요한 칼럼들이다.
● Time (Relative Time): 기준이 되는 패킷을 0.00초로 하여 다음 패킷들이 캡쳐되기까지의 시간을 의미한다. 즉, 1번 패킷이 기준 패킷이라고 하면 2, 3, 4번까지 캡쳐된 시간을 표시한다. 각 패킷들의 Delta Time을 합한 것이다. 이시간은 1초 동안의 몇 개의 패킷이 네트워크에서 발생했는지 또는 특정 패킷까지 몇 초가 걸렸는지를 계산하기 위해서 사용된다.
● Delta Time: 바로 이전 패킷과 해당 패킷 사이의 시간 간격을 의미한다. 위 <그림 3-46>에서 보면, 2번 패킷 다음에 3번 패킷이 캡쳐된 시간이 0.06초이다. 이 시간은 패킷들이 얼마나 짧은 또는 긴 시간 간격으로 발생했는지를 확인하기 위해서 사용된다.
● Abs. Time (Absolute Time): 각 패킷이 캡쳐된 실제 시스템의 시간이다. 이시간은 실제 사고가 발생한 시간에 캡쳐된 패킷을 찾기 위해서 참조하며, 실제 분석에 필요한 것은 아니다.
● Source: 해당 패킷을 송신한 호스트의 주소이다. IP 또는 MAC 주소로 표시할 수 있다.
● Destination: 해당 패킷을 수신하는 호스트의 주소이다. 마찬하기로 IP 또는 MAC 주소로 표시할 수 있다.
● Length: 해당 패킷의 실제 크기이다. MAC 계층의 CRC를 포함하여 표시하기도 하지만, CRC를 제외한 나머지 크기로 표시하기도 한다.
● Protocol: 해당 패킷의 어플리케이션 포트이다. 서버의 TCP/UDP 포트를 근거로 표시된다.
● Information: 해당 패킷에 포함되어 있는 송수신 포트, 패킷의 용도 및 어플리케이션에 대한 간략한 설명이다. 각 패킷의 Seq, Ack 번호 및 TCP Window의 크기도 표시된다.
4. 공격형 트래픽의 특징
공격형 트래픽은 네트워크에 과부하를 발생시키거나 특정 어플리케이션의 서비스를 중단 시키는 형태가 있다. 몇 년 전까지만 해도 어플리케이션의 서비스를 중단시키는 코드를 서버에 삽입하는 (Buffer Overflow) 공격이 많았다. 하지만 최근 몇 년 전부터는 유입되는 네트워크 웜들은 서버뿐만 아니라 네트워크 전체에 과부하를 발생시키는 트래픽을 발생시키고 있다.
가. 특정 서버만을 공격하는 패턴 Web, E-mail, DNS 서버와 같은 주요 어플리케이션 서버만을 공격하는 트래픽은 다음과 같은 특징을 가지고 있다.
● 많은 데이터를 전송하는 것처럼 패킷의 크기가 크거나 불규칙하다.
● 해당 서버에서 인식하지 못하는 코드를 전송한다.
● 해당 서버에서 처리할 수 없을 정도의 많은 요청을 보낸다.
● 서버에서 허용되지 않는 문장을 사용하여 요청 패킷을 전송한다.
나. 네트워크에 과부하를 발생시키는 공격 패턴 네트워크에 과부하를 발생시켜서 스위치나 방화벽 또는 라우터에 영향을 주는 트래픽은 간단하게 찾을 수 있지만, 가장 어려운 문제는 이러한 트래픽을 발생시키는 호스트를 찾는 것이다. 많은 웜이나 공격이 IP 주소를 변조하기 때문에 발생지를 찾기 어려워지고 있으며, 때문에 이러한 트래픽이 발견되면, 각 스위치의 포트 상태를 점검해야 한다.
● 불특정 IP 주소를 순차적으로 사용하여 한 IP 주소를 대상으로 같은 형태의 패킷을 송신한다.
● 특정 IP 주소에서 불특정 다수의 IP 주소를 대상으로 순차적으로 같은 형태의 패킷이 발생한다.
● 1초에 송신하는 패킷의 개수가 수백 ~ 수 만개까지 발생한다.
● 한개 또는 몇 개의 TCP 포트를 대상으로 SYN 패킷을 전송한다.
● 발생하는 패킷의 크기가 작다.
● 패킷의 개수가 수신보다 송신이 매우 많다. (100 ~ 1000배 이상)
<그림 3-48>의 패턴을 보면, 여러 IP 주소가 순차적으로 바뀌면서 한 IP 주소에 TCP 80포트 SYN 패킷을 전송하고 있다. 또한 패킷을 전송하는 시간은 Delta Time을 참조하면, 짧게는 0.00001초에서 길게는 0.00014초 밖에 차이나지 않는다.
<그림 3-49>의 패턴을 보면, 한 IP 주소가 여러 IP 주소들의 다중 TCP 포트에 대해서 SYN 패킷을 전송하고 있다.
5. 침입형 트래픽의 특징
침입하려는 대상을 알고 있는 상태라면, 접속이 가능한 포트를 검색한 후에 접속을 시도하기 위하여 여러 가지 방법이나 도구를 사용한다. 하지만, 대상을 모르고 있다면, 먼저 네트워크를 통하여 접속이 가능한 IP 주소와 포트를 검색한 후에 접속을 시도한다. IP 주소와 포트를 검색하는 과정에서 발생하는 트래픽의 특징은 아래와 같다.
● 해당 IP 주소에서 송신한 패킷 개수와 수신한 패킷 개수가 비슷하다.
● 일반적으로 검색 과정에서는 실제 데이터 송수신이 발생하지 않기 때문에 송수신한 바이트 수도 비슷하다.
● 패킷 가운데 RST이나 login Failure가 포함된 패킷이 많다.
● 검색하려는 IP 주소 또는 포트가 순차적으로 바뀐다.
다음 <그림 3-51>는 네트워크에 연결되어 있는 호스트의 IP 주소를 검색하는 패턴이다. IP 주소를 검색하는 방법으로 가장 많이 사용되는 명령어가 Ping이다. Ping 명령어를 이용하여 Echo request를 전송하면, 네트워크에 연결되어 있지 않는 호스트에서는 응답이 없지만, 연결되어 있는 호스트에서는 Echo Reply로 응답하기 때문에, 가장 간단한 방법으로 사용된다.
<그림 3-52>은 TCP 포트를 검색하는 패턴이다. 한 IP 주소의 TCP 포트에 대해서 순차적으로 SYN 패킷을 전송하고 있으며, 대상 호스트에서 해당 포트로 접속을 거부하는 경우에는 RST 패킷이 발생하고 있다. 하지만, 만약 TCP 7(echo), 9(discard)번 포트인 경우에 대해서는 SYN ACK 패킷이 발생하여 접속이 가능함을 알려주고 있다.
제4절 데이터베이스 사고 분석
1. Data, 데이터베이스, DBMS
가. 데이터와 정보 데이터란 정보작성을 위하여 필요한 자료를 말하는 것으로, 이는 아직 특정의 목적에 대하여 평가되지 않은 상태의 단순한 사실에 불과하다.
정보란 데이터를 추출, 분석, 비교 등 가공절차를 통해 원하는 결과를 얻기 위하여 어떤의사결정이나 행동을 취했을 때 의미를 가지는 데이터를 정보라고 부른다.
나. 데이터베이스 한 조직의 여러 응용시스템이 공유(shared)하기 위해 최소의 중복으로 통합(Integrated), 저장(Stored) 된 운영(Operational) 데이터의 집합을 가리킨다.
다. DBMS 데이터를 통합적으로 생성, 저장 및 관리하는 시스템 소프트웨어 패키지를 말하며, 우리가 흔히 알고 있는 MS-SQL, Oracle, Informix, DB2 등이 여기에 속한다.
2. My-SQL
My-SQL은 세계적으로 가장 널리 쓰이고 있는 대중적인 DBMS이다. My-SQL 말고라도 MS-SQL 같은 소규모DB, 또 ASP와 연동하여 쓰이는 MS-SQL 등 많은 다른 SQL이 있긴 하지만 My-SQL이 공개 소프트웨어라는 이점 때문에 다른 SQL들을 압도하고 있다. 우선 My-SQL은Linux, Apache, PHP 등과 같이 Open Source를 지향하는 Application과 환상적인 조화를 이루고 있다. 전 세계적으로 인터넷상에서 가장 많은 비중을 차지하는 서버는 Linux로서 PHP와 My-SQL의 연동은 Linux 서버의 일반적인 구성이라고 할 수 있다. 그러한 이유로 Hacker에게 가장 많은 Target 이 되는 목표이기도 하다. My-SQL 서버가 침해사고에 노출이 되었다고 의심될 경우에는 필요한 점검 절차를 알아보도록 하자.
가. 관리자 아이디를 Default로 사용하고 있는가? My-SQL 보안에 가장 중요한 것은 디폴트 설치시 설정되지 않은 채 비어있는 데이터베이스 관리자 패스워드를 변경하는 것이다. My-SQL의 관리자인 root는 실제 Linux(또는 Unix)시스템의 root 사용자와는 관계가 없다. 다만 그 이름이 같을 뿐이다. 따라서 침해사고 발생시 가장 먼저 해야 할 일이 바로 My-SQL 데이터베이스의 root 사용자 패스워드를 Default 상태로 운영하지 않았는지 점검하는 것이다. 이유는 My-SQL의 root라는 관리자 패스워드는 누구나가 알고 있는 사실이기 때문이다. 따라서 관리자 계정을 root가 아닌 다른 계정으로 바꾸는 것이 안전하다. 디폴트로 설정되는 관리자 계정(root)을 무차별 대입 공격이나 사전대입 공격 등으로 추측해 내기 어려운 이름으로 변경한다. 변경해 두면 설사 공격을 당하더라도 공격자는 패스워드뿐 아니라 계정정보도 추측해 내야 하기 때문에 공격은 더 어려워진다.
● 점검 사항
아래와 같은 방법으로 root 계정에 대한 점검을 수행하며, root 계정을 admin 계정으로 계정명을 바꾸는 예이다.
나. 패스워드가 설정하지 않은 DBMS 계정이 존재하는가? 패스워드가 설정되어 있지 않은 DBMS계정이 존재할 경우 인가되지 않은 일반사용자가 DBMS에 불법접속이 가능하므로 DBMS에 저장되어 있는 주요 데이터들의 파괴, 변조 등의 위험성이 존재한다.
특히“가”의 경우처럼 root 의 패스워드가 설정되지 않을 때는 누구나 My-SQL 의 root권한으로 접속 가능하다.
● 점검 사항
패스워드 설정 Table 점검방법은 다음과 같다.
위와 같이 root의 경우 패스워드가 설정되지 않은 경우 일반유저도 데이터베이스를 root 권한으로 접속 가능해 진다.
- 패스워드가 설정되지 않았을 때 접속 예시
# mysql -u root -p
mysql>
● 대응 방법
패스워드가 설정되지 않은 사용자에 대해 패스워드를 설정한다.
- 방법1. mysql>UPDATE user SET password=password‘( new-password’)
mysql>WHERE user =‘ user_name’
mysql>flush privileges;
- 방법2. mysql>SET PASWORD for user_name=password‘( new_password’);
- 방법 3. $My-SQLadmin u username password new-password
다. Remote에서 My-SQL 서버로의 접속이 가능한가? 먼저 My-SQL이 디폴트로 리스닝하는 3306/tcp 포트를 차단해 데이터베이스가 로컬로 설치된 PHD 어플리케이션에 의해서만 사용되게 한다. 이유는 3306/tcp 포트가 My-SQL 통신포트라는 사실은 누구나 다 알고 있는 사실이기 때문에, 3306/tcp 포트를 리스닝하지 못하게 하면 다른 호스트로부터 직접 TCP/IP 접속을 해서 My-SQL 데이터베이스를 공격할 가능성이 줄어든다. 그러나 mysql. socket 을 통한 로컬 커뮤니케이션은 여전히 가능하다.
● 대응 방법
3306/tcp 포트를 리스닝하지 못하게 하려면 /chroot/mysql/etc/my.cnf의 [mysqld] 부분에 다음을 추가한다.
skip-networking
데이터 백업 등의 이유로 데이터베이스로 원격에서 접속해야만 하는 경우 아래와 같이 SSH 프로토콜을 사용한다.
$ ssh mysqlserver /usr/local/mysql/bin/mysqldump -A > backup
라. My-SQL 계정을 이용한 접속이 가능한 상태인가? My-SQL DB를 Install 하면 자동으로 서버에 My-SQL이라는 계정이 생성된다. 따라서 서버관리자들이 My-SQL 계정에 대한 관리가 소홀한 점을 이용하여 이 계정으로 서버에 불법으로 침투하는 경우가 종종 발생한다.
● 점검 사항
$ more /etc/passwd
My-SQL:x:60004:102::/export/home/My-SQL:/bin/sh
현재 My-SQL이라는 계정으로 외부에서 Login 가능하다.
● 대응 방법
/etc/passwd 파일에서 /bin/sh를 bin/false로 변경한다. 이는 My-SQL 사용자 계정을 이용한 remote Login 금지하는 옵션이다.
마. 각 시스템사용자들의 DB들에 대한 권한설정은 올바른가? 필요 이상의 권한인 어플리케이션 사용 유저에게 부여되어 있을 경우 외부의 침입자는 획득유저 권한 획득 후 DBMS를 컨트롤 할 수 있는 권한이 주어지므로, 필요 이상의 권한의 부여를 지양해야 한다.
● 점검 사항
아래의 경우에는 test, test＼_%, ccrco 라는 3종류의 데이터베이스 가 설정되어 있다. 특히 test, test＼_% DB는 모든 호스트의 모든 시스템 사용자에 의해 사용 가능하도록 설정되어 있음을 확인할 수 있다.
또한 ccrco DB는 localhost의 시스템의 root 유저에 의해서만 사용 가능한 상태이다.
관리 목적의 사용을 위하여 root / mysql 계정이외에 관리목적의 계정을 만들어서 현재의 root의 권한을 부여하여 이용하고, root 사용자의 권한은 모두 revoke 시키는 것이 원칙이다.
● 대응 방법
test, test＼_% DB는 모든 호스트의 모든 사용자에 의해 사용 가능한 상태이므로 불필요한 권한을 Revoke시켜야 한다.
mysql> UPDATE db SET Update_priv =‘ N’ WHERE db =‘ test’
mysql> flush privileges;
만약 test, test＼_% DB가 불필요한 DB라면 아래와 같이 실행하여 데이터베이스를 삭제하는 것이 안전하다.
mysql> DROP 데이터베이스 db_name
바. 데이터베이스내의 사용자별 접속/권한 설정은 올바른가? 데이타베이스에 대한 적절한 권한 설정이 되어 있지 않은 경우 dba가 아닌 사용자가 중요 테이블에 대한 조작을 할 수 있으므로 각 User 별 데이터베이스권한 설정이 적절하게 이루어져야 한다. 특히, 일반 사용자에게 File_priv, Process_priv 권한이 주어질 경우 해커에 시스템 침입의 대상이 되어질 수 있다.
● 점검 사항
user 테이블 현황 점검방법은 다음과 같다.
위의 결과에서는 외부 호스트인 (203.xxx.xxx.237, 47, 52, 66)에서 root사용자로 로그인해 모든 작업이 가능한 상태이다. 또한 localhost에서는 ccrco와 root가 로그인하여 모든 작업이 가능한 상태이다.
● 대응 방법
ccrco 계정이 일반 운영용 계정이라면 특성에 따라 권한 설정을 조정할 것이 바람직하다. 또한 localhost에서 root 사용자는 모든 권한을 revoke시키고 다른 이름의 DBA계정을 만들어 사용하도록 해야 한다. 그리고 remote Login시 root사용자가 아닌 다른 사용자로 Login 하고 접근할 때 접근권한을 최소화할 것이 좋다.
다음은 절대 일반 사용자나 remote 사용자에게 주어져서는 안 되는 권한들을 설명한 내용이다.
- File_priv : 파일에 대한 권한
- Process_priv : 쓰레드 정보를 볼 수 있으며, 쓰레드를 중지 시킬 수 있는 권한
- Shutdown_priv : My-SQL 서버의 실행을 중지 시키는 권한
이외에 불필요한 권한은 revoke 시켜야 한다.
다음은 root 계정이 203.xxx.xxx.237 서버에 대한 Process_priv 서버에 대한 권한을 revoke 시키는 방법이다.
mysql> UPDATE user SET Process_priv =‘ N’ WHERE host =‘ 203.xxx.xxx.237’ AND User =‘ root’
사. 안정적인 My-SQL 버전을 사용하고 있는가? 3.22.32 미만의 버전에서는 사용자 인증처리 부분에서 버그 보고된 바 있다. 따라서 권한을 가지지 않은 일반인도 My-SQL의 모든 권한을 가지고 접근할 수 있다. 자신이 운영하고 있는 My-SQL DB의 버전을 점검해 보도록 하자.
● 점검 사항
위의 경우에는 안정적인 3.23.55 버전을 사용하고 있다.
● 대응 방법
대응방법은 간단하다. 가장 안전한 상태의 최신 버전을 다운받아 사용할 것이 가장 좋다.
아. My-SQL의 데이터 디렉터리는 안전하게 보호되고 있는가? My-SQL은 테이블의 데이터를 파일 형태로 관리한다. 이 파일은 My-SQL 데이터 디렉터리라고 불리는 디렉터리에 저장되는데, 이 디렉터리의 권한을 잘못 설정할 경우, 서버의 일반 User가 My-SQL의 모든 데이터를 삭제해 버리는 경우도 있다. 또는 서버를 해킹한 해커에 의해서 My-SQL 데이터를 삭제해 버리는 사고도 발생한다.
이는 My-SQL의 로그파일도 마찬가지이다. My-SQL의 경우에는 Update 로그 파일이나 일반적인 로그파일에는 사용자가 패스워드를 바꾸려고 하는 쿼리도 기록된다. 따라서 로그 파일의 퍼미션이 부적절하여 DB 권한이 없는 User가 My-SQL Log 파일에 접근하여 DB 패스워드가 노출되는 경우가 발생한다.
뿐만 아니라 지정된 옵션 파일(my.cnf, my.cnf)들에 대한 접근통제도 마찬가지이다. My-SQL 관리자는 여러 옵션을 옵션파일에 지정하여 관리를 쉽게 할 수 있으며, 이 옵션 파일들에는 root를 비롯한 일반 사용자들의 패스워드가 들어 있는 경우도 있다. 따라서 옵션파일은 관리자나 해당 사용자만이 읽고 쓸 수 있도록 한다.
● 점검 사항
위의 예는 디렉터리의 permission이 적절하게 설정되어 있는 경우이다.
또한 에러로그(v480.err)만 생성되며 permission이 정상적으로 설정되어 있는 경우이다.
● 대응 방법
해당 디렉터리는 chmod 명령어를 이용하여 My-SQL 그룹 및 소유자만 사용할 수 있게 permission을 변경해야 한다.
해당 옵션 파일들에 대한 설정은 오직 소유자만이 읽고 쓸 수 있도록 설정한다.
#chmod 700 /etc/my.cnf
#chmod 700 DATADIR/my.cnf
#chmod 700 $HOME/my.cnf
3. MS-SQL
MS-SQL은 잘 알려진 바와 같이 Microsoft 사에서 만든 Windows 기반에서 운영하는 데이터베이스를 가리킨다. 최근에는 SQL Server 2005가 출시되었으나, 아직까지 시중에는 SQL Server 2000이 주종을 이루고 있다. Windows 계열의 서버에서는 데이터베이스 시장의 약 80% 정도를 MS-SQL DB가 점유하고 있는 것으로 Microsoft에서는 발표하고 있다. 따라서 MS-SQL DB를 중심으로 가장 일반적인 데이터베이스 Application 취약점을 한 가지 알아보자. 본 고는 MS SQL Server 2000을 기준으로 작성되었다.
일반적으로 기업에서 운영하는 상업적 목적의 Web 서버들은 Back-end 단에 DB서버와 연동이 되어 있고, DB 서버로부터 Web서버 인증이나 운영에 필요한 중요 Data 정보를 가져오도록 구성되어 있다. <그림 3-53> 참조
MS-SQL DB와 Web 서버와 연결하여 운영한다고 가정할 때 Web 서버에는 DB서버와의 연결정보가 담겨있는 파일 (conn.asp)이 존재하고, 그 파일에는 DB 커넥션을 위한 다음과 같은 환경정보가 담겨져 있다.
- DB서버의 IP 주소 또는 Host Name
- DB서버 접근 계정 (ID)
- DB서버 접근 패스워드 (Password)
따라서 불법적인 침입자가 Web서버의 계정을 획득하였을 경우 DB 서버까지 점령하는 것은 전혀 문제가 되지 않는다. MS-SQL 서버 접속프로그램인 sqlpoke.exe와 같은 파일을 업로드하여 웹 서버에서 획득한 DB접근 계정과 패스워드를 이용하여 서버 내부에 접근할 수 있다. MS-SQL서버의 Default 계정인‘sa’계정은 서버 내부에 administrator권한으로 명령을 전달할 수 있는 계정이다.
위와 같이 net user 명령을 이용하여 Remote에서 DB서버 내부에“hack”이라는 내부계정을 생성한 결과이다. 이와 같이 <그림 3-54>에서 보는 것과 마찬가지로 점령된 웹 서버를 통하여 우회침투 경로로 DB서버까지 접근이 가능하다는 것을 알 수 있다.
그렇다면 이러한 취약점을 어떻게 방어할 것인가?
의외로 간단하다. DB 서버와 웹 서버를 연동할 때‘sa’계정을 이용하면, 웹 서버가 침투를 당할 경우 보안상 취약할 수밖에 없다. 따라서 administrator 계정이 아니라 일반 DB서버 계정을 생성하여 웹 서버와 연동시키는 것이 하나의 방법이다. 이럴 경우 DB서버의“sa”계정은 Administrator 권한이 없기 때문에 여러 가지 제약을 가지게 된다. 그러나 이 경우에도 DB서버의 Data들을 불법적으로 조회하는 것은 막지 못한다.
최근 가장 많이 이용되고 있는 SQL Injection 공격의 경우, 웹 사이트가 Injection 도구에 의해 침입을 받았다면 DB에 해당 툴을 암시하는 테이블이나, 이용자 계정 정보가 남아있게 된다. 또한 IIS 웹로그에도 로그 기록이 남기 때문에 이를 통해서도 침입 흔적을 확인할 수 있다. 여기서는 DB 쪽만 살펴보도록 하자.
가. 패스워드가 설정되지 않았거나 단순한 패스워드를 사용하는 계정이 있는가? 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 웹로그도 생성한다.
그러면 MS-SQL 서버가 침해사고에 노출이 되었다고 의심될 경우에는 다음과 같은 절차를 거처 점검해 보자.
가. 계정의 패스워드 중 빈 패스워드나 약한 패스워드가 존재 하는가? 패스워드가 설정되어 있지 않을 경우 user 만 알면 누구나 DB에 접속할 수 있게 된다. 특히 sa 계정에 대해 패스워드가 설정되어 있지 않은 경우가 비교적 많다. 이럴 경우 시스템 권한의 업무를 악의적인 사용자가 실행할 수 있게 된다.
● 점검 사항
1. 프로그램 MSSQL 쿼리어널라이져 실행
2. 메인 DB를“MASTER”로 설정
3. QA에서“Select name, password from syslogins”입력 후
4. 결과 값이 Null 이면 패스워드 없음
단, Builtin\계정명의 경우 NULL이 정상이다.
● 대응 방법
패스워드가 없는 계정을 발견하면, 특수문자가 포함된 추측하기 힘든 패스워드를 생성하도록 한다. 특히 Windows 인증을 요구하도록 구성된 서버에서도 sa 계정은 항상 까다로운 패스워드를 사용해야 한다는 것은 기본으로 지켜야할 수칙이다. 계정의 패스워드 지정방법은 다음과 같다.
1. 서버 그룹을 확장하고 서버를 확장.
2. 보안을 확장하고 로그인을 클릭.
3. 상세내용 창에서 마우스 오른쪽 단추로 클릭하고 속성을 클릭.
4. 패스워드 입력란에 새 패스워드를 입력
나. guest 계정이 비활성화 되어 있는가? guest계정은 특별한 로그인 계정으로 이 계정을 데이터베이스에 지정함으로써 SQL 서버의 정상 사용자 모두가 데이터베이스에 액세스하게 허락하는 경우가 종종 있다. 이는 당연히 MS-SQL 서버의 보안에 치명적인 결과를 가져온다.
● 점검 사항
1. SQL Server의 Enterprise Manager 실행
2. 해당 데이터베이스 사용자 선택
3. 우측에 guest 계정이 있는지 점검
● 대응 방법
위의 방법대로 점검시 guest 계정이 발견되면 guest 계정을 삭제하면 된다.
1. SQL Server의 Enterprise Manager 실행
2. 해당 데이터베이스 사용자 선택
3. 우측에 guest 계정 우측버튼 클릭 삭제 클릭
다. public 데이터베이스 역할이 부여되어 있는가? 모든 데이터베이스 사용자들의 표준 역할로서 사용자는 public 역할의 권한과 특권을 계승 받고, 이 역할은 그들의 최소한의 권한과 특권을 나타낸다. 따라서 public 데이터베이스 역할에 권한이 설정되어 있으면, 인가를 받지 않은 사용자도 모든 작업을 할 수 있는 취약점 발생한다.
● 점검 사항
1. SQL Server의 Enterprise Manager 실행
2. 해당 데이터베이스 등록정보 사용권한
3. Public에 어떤 권한이 체크되어 있는지 확인
● 대응 방법
Public DB 역할에 부여된 권한을 Revoke 시키면 해결된다.
1. SQL Server의 Enterprise Manager 실행
2. 해당 데이터베이스 등록정보 사용권한
3. Public에 할당된 권한을 Revoke 시킴
라. SYSADMIN으로 그룹의 사용자를 인증된 사용자만으로 제한하고 있는가? sysadmin(system administrators)의 역할은 SQL서버와 설치된 데이터베이스에 대해서 완전한 관리 권한을 필요로 하는 사용자를 위해 만들어 진 역할로서 이 역할의 구성원은 SQL서버에서 모든 작업을 수행할 수 있어, 이 역할에 인증되지 않은 사용자 있어서는 안 된다.
● 점검 사항
1. SQL Server의 Enterprise Manager 실행
2. 보안 서버역할 우측 화면에서 system administrators를 더블 클릭
3.“ 일반”탭에있는구성원을확인
마. 방화벽에서 SQL Server 포트를 차단했는가? SQL Server 포트는 Default 가 TCP/1433, TCP/1434 이다. 즉 SQL Server를 운영하고 있는 사실을 알고 있는 해커라면, 방화벽에서 1433, 1434 포트가 OPEN 되어있다는 것을 알고 있는 것이나 마찬가지란 뜻이다. 실제로 인터넷에 노출된 MS-SQL 서버를 모니터링 해보면 1433, 1434 포트를 Target으로 수많은 Scan 공격과 웜으로 인한 유해 트래픽이 끊임없이 공격을 시도하는 것을 발견할 수 있다. 따라서 SQL Server를 설치할 때 통신 Default Port를 임의의 다른 포트로 설정하여 운영한다면, 보안수준이 향상될 것이다.
바. 가장 최신의 서비스 팩을 설치한다. 서버 보안 개선을 위한 가장 효과적인 조치는 SQL Server 서비스 팩을 최신의 패치로 업그레이드하는 것이다. SQL Server의 서비스 팩은 다음 사이트에서 다운로드 할 수 있다.
- MS-SQL 2000
http://www.microsoft.com/korea/sql/downloads/2000/sp4.asp - MS-SQL 2005
http://www.microsoft.com/downloads/details.aspx?familyid=cb6c71ea-d649-47ff-9176-e7cac58fd4bc&displaylang=en 또한 공개되는 모든 보안 패치를 설치해야 한다. 새 보안 패치를 전자 메일로 통지 받으려면 Microsoft의 제품 보안 통지 페이지에서 신청하면 된다.
사. 마지막으로 Microsoft Baseline Security Analyzer(MBSA)로 서버를 점검해 본다. MBSA는 SQL Server 및 Microsoft SQL Server 2000, 2005 Desktop Engine(MSDE 2000, 2005)을 비롯한 여러 Microsoft 제품에서 자주 볼 수 있는 보안상 취약한 구성을 검사해 주는 도구이다. 이 프로그램의 실제 기능은 현재 사용 중인 윈도우가 해야 할 보안패치를 최신으로 유지하고 있는지, 사용자가 보안상 약점이 될 만한 설정을 사용 중인지를 스캔한 결과를 보여주는 것이다. 그래도 이 정도 툴로도 기본적인 취약점은 점검이 가능하다. 이 도구는 로컬 또는 네트워크에서 실행할 수 있으며, SQL Server 시스템에 다음과 같은 문제
가 없는지 테스트한다.
1. 지나치게 많은 sysadmin 구성원이 서버 역할을 수정한 경우
2. sysadmin 이외 역할에 CmdExec 작업 작성 권한이 부여된 경우
3. 패스워드가 비어 있거나 지나치게 평범한 경우
4. 인증 모드가 허술한 경우
5. 관리자 그룹에 너무 많은 권한이 부여된 경우
6. SQL Server 데이터 디렉터리의 액세스 제어 목록(ACLs)이 정확하지 않은 경우
7. 설정 파일에 일반 텍스트 패스워드 sa가 있는 경우
8. guest 계정에 너무 많은 권한이 부여된 경우
9. 도메인 컨트롤러 역할도 하는 시스템에 SQL Server가 실행되는 경우
10. Everyone 그룹의 구성이 잘못되어 특정 레지스트리 키에 대한 액세스가 허용되는 경우
11. SQL Server 서비스 계정 구성이 잘못된 경우
12. 서비스 팩 및 보안 업데이트가 없는 경우
Microsoft는 MBSA 2.0 버전을 무료 다운로드로 제공하고 있으며, 다음 사이트에서 다운로드 할 수 있다.
http://www.microsoft.com/technet/security/tools/mbsa2/default.mspx 자. 마지막으로 SQL Server 연결에 대한 감사를 수행한다. SQL Server는 시스템 관리자의 검토를 위해 이벤트 정보를 기록할 수 있다. 최소한 SQL Server에 대한 연결 실패를 기록하여 이를 정기적으로 검토해야 한다. 가능하면 이 로그는 데이터 파일이 저장되는 드라이브와 다른 하드 드라이브에 저장한다.
● 대응 방법
SQL Server의Enterprise Manager로 연결 실패를 감사하려면
1. 서버 그룹을 확장한다.
2. 서버를 오른쪽 단추로 클릭하고 속성을 클릭한다.
3. 보안 탭의 감사 수준에서 실패를 클릭한다.
이 설정이 적용되려면 서버를 종료했다가 다시 시작해야 한다.
출처 : 한국정보보호진흥원
