웹 로그파일 분석 및 침해사고 분석 보고서

 

* 로그분석 팁

 

1) 소거법

- 특정 확장자가있는 로그를 제거한다.

- find 명령어를 사용해 분석한다.(find보다 더 강력한 findstr을 사용하는 것도 추천한다.)

<findstr 사용법>

 

2) 엑셀을 사용한 텍스트 나누기 및 필요한 필드만 골라보기

3) 필터작업

- 응답코드별로 색상을 지정한다.

- ex)응답코드 200과 500에 색상을 지정해 색상이 번갈아 나오는 경우 해킹 시도 가능성이 높은 로그다.

4) 전체 로그 파일에서 '의심 IP'만 보기(grep)

5) 분석과정

- 최초 접속 -> 과정(행위)/결과 -> 대응/보안 조치의 과정으로 진행이 된다.

 

* 실습

 

※ 실습은 침해사고가 이루어졌던 로그파일(web.log)을 대상으로 진행 하였다. 

1)

우선 로그파일의 크기가 556M인 것을 보고 대용량 편집기(gvim - 윈도우에서 리눅스의 vi/vim과 같은 환경에서 텍스트 편집이 가능)를 구해 로그파일을 열어보았다.

텍스트는 3,230,577줄의 로그를 포함하고 있었다. 소거법을 진행하기 위해 cmd에서 findstr 명령어(>findstr /m "확장자" web.log, >findstr /n /i "확장자" web.log)를 사용해 여러 확장자(.asp, .css, .swf, .gif, .jpg 등)를 찾아보았다.

그 중 .gif 확장자가 있는 로그가 너무 많은 양이 검출되어 50만줄의 로그가 검색이 되는 순간에 중단하고 바로 gvim으로 돌아가

vi 명령어(:g/.gif/d)로 .gif 확장자를 가진 로그만 없애보았고, 로그의 개수가 172,234줄로 확연히 줄어든 것을 보았다.

2)

간단히 보면 Windows의 IIS6을 사용하고 있었고 IIS 버전을 보았을 때 데이터 베이스는 SQL Server 2005일 가능성이 높다.

간소화된 로그파일을 엑셀 프로그램을 사용해 각 필드별로 나누어 보았다.

date: 조치가 발생한 날짜

time: 조치가 발생한 시간

s-sitename(서비스 이름): 클라이언트가 엑세스한 인터넷 서비스 및 인스턴스 번호

s-ip(서버 IP 주소): 로그 항목이 생성된 서버의 IP 주소

cs-method(메소드): 클라이언트가 수행하려고 한 조치(예: GET 메소드)

cs-uri-stem(URI 스템): 엑세스한 자원(예: Default.htm)

cs-uri-query(URI 조회): 클라이언트가 수행하려고 한 조회(있는 경우)

s-port(서버 포트): 클라이언트가 연결된 포트 번호

cs-username(사용자 이름): 서버에 엑세스한 인증 사용자의 이름. 여기에는 하이픈(-)으로 표시하는 익명의 사용자가 포함되지 않습니다.

c-ip(클라이언트 IP 주소): 서버에 엑세스한 클라이언트의 IP 주소

cs(User-Agent)(사용자 에이전트): 클라이언트에서 사용한 브라우저

sc-status(프로토콜 상태): HTTP또는 FTP 용어로 표시한 조치의 상태 코드

sc-substatus: HTTP또는 FTP 용어로 표시한 조치의 하위 상태 코드

sc-win32-status: Windows에서 사용하는 용어로 표시한 조치의 상태

자세한 사항은 여기에서 확인.

따라서 위의 로그사항을 보고 분석시 불필요하다고 생각 된 필드(cs-username, sc-substatus, sc-win32-status)를 제거해보았다.

 

3)

로그를 보다 편하게 분석하기 위해 응답코드 200과 500에 색상을 지정해 보았다.

200번과 500번의 응답코가 번갈아 나오는 것은 무언가 악의적인 행위를 시도했다고 볼 수 있기 때문에 더 주의해서 로그를 살펴보아야 한다.

 

4)

그 중 218.150.162.108의 IP를 가진 클라이언트가 보내는 파라미터에 데이터베이스 쿼리문이 있는것을 보았다.

그래서 218.150.162.108의 로그중에 파라미터가 존재하는 로그만 한번더 필터링을 해보았다.

3개의 필드에 대해 필터링을 거쳐보니 확실히 악의적인 행위를 하는 클라이언트라는 것을 확신할 수 있었다.

그 외에 다른 IP에서 특이한 행위는 보이지 않았다.

 

5)

이제 218.150.162.108의 IP만 필터링을 했더니 1851개의 로그만 남아 있는 것을 보았고, 최초 접속시간 부터 하나씩 조사를 해본다.

필터링 후 최상위 로그에 바로 index.asp에 접속을 하는 걸로 보아 최초 접속시간은 2007-03-03 19:50:38로 볼 수 있다.

 

 

사이트에 접속 후 로그를 보면 해커는 웹 사이트의 취약한 페이지를 찾고 있었던 것 같다.

특히 로그의 파라미터 부분에 SQL 구문이 보이는 것을 보니 SQL Injection 공격을 할 수 있는 페이지를 찾고 있었던 것 같다.

 

그 후 해커는 select, create, insert, drop 명령어 등을 통해 notice_read.asp가 취약한 페이지 인것을 확인하였고, 이 페이지를 이용해 SQL Injection 공격을 시도하였다.

해커는 처음 

CREATE TABLE [X_9800]([id] int NOT NULL IDENTITY (1,1), [ResultTxt]varchar (1024) NULL);

명령어를 사용해 테이블을 생성하고

insert into [X_9800](ResultTxt) EXEC MASTER..XP_CMDSHELL 'net user';

insert into [X_9800](ResultTxt) values ('g_over');exec master..sp_dropextendedproc 'xp_cmdshell'--

다음과 같은 구문을 수행하였다. 

윈도우 명령어인 'net user'를 사용하기 위해 MSSQL의 Master DB의 확장 프로시저를 이용한 흔적이 보였다. 

위 쿼리의 공격 결과로 해커는 웹서버의 계정을 확인할 수 있었다.

그 후 해커는 위와 같은 방법으로 ipconfig /all, ipconfig, netstat -an의 명령어를 사용했다.

그 후 xp_dirtree, xp_regread의 확장 프로시저를 사용하여 디렉토리와 읽고 레지스트리를 읽을 수 있게 테이블을 만들어 거기에 각각의 정보를 넣었다. 

그 후 웹쉘을 업로드하여 로그를 백업 받고 로컬 파일에있는 악성 down.VBs를 업로드 하는 것으로 보여지는 공격을 시도했다.

소거법부터 최초접속시간 까지는 쉬웠지만 뒤의 해커의 로그에서 파라미터 부분을 해석하는데 좀 어려웠다. 다음엔 공부해서 빨리 분석할 수 있도록하자.