2024-03-29 18:40 (금)
[강명훈-Snort 연재 강좌⑥] Snort 분석, 탐지로그 통해 공격자 동향 파악
상태바
[강명훈-Snort 연재 강좌⑥] Snort 분석, 탐지로그 통해 공격자 동향 파악
  • 길민권
  • 승인 2015.09.07 15:54
이 기사를 공유합니다

DELETED WEB-IIS header field buffer overflow attempt-두번째
지난 시간에 이어서 이제 본격적으로 분석을 해보자. 해당 룰은 헤더 필드의 구분자 조작 여부를 탐지하는 게 목적이다. 분석의 편의를 위해서는 헤더 영역만 추출할 필요가 있다. 어떻게?
 
웹 요청 트래픽은 'Request-Line(URI) + Header + Body' 구조로 이루어져 있으며, 그 중 Header 영역은 'rn(Carriage Return과 Line Feed, 0D0A)'으로 각 필드를 구분하는 여러 지시자(Directive)들로 구성되어 있다.

 
URI는 'HTTP 버전 정보(HTTP/1.1 또는 1.0)'를 표시한 후 끝나며, 헤더 영역의 지시자 정보는 '제목:공백값' 형식이라는 사실을 알 수 있다. 이제 URI 영역을 지워보자. 지우려면 먼저 찾아야 한다. 사용한 검색 명령어는 다음과 같다.
 
 

 
URI 영역을 삭제하면 'Header + Message-Body' 영역만 남는다.

 
가독성을 높이기 위해 남은 헤더 영역에서 지시자의 '제목:공백값' 형식을 '제목 |  :공백값' 형식으로 바꿔보자. 사용한 VI 치환 명령어는 다음과 같다.
 

 
 
최종 확인 결과 23개의 로그는 필드 구분자로 0D0A, 또는 0A를 사용한 2가지 유형으로 나뉘었으며, 00 패턴은 모두 0D0A0D0A(또는 0A0A) 이후, 즉 'Message-Body' 영역에서 발견되었다.



 
해당 룰의 개발자는 지시자 제목과 값의 구분자인 '3A(:)' 패턴 검사 후, 필드 구분자로 '0A(n)'가 사용되면 헤더 필드 구분자 조작 시도로, 헤더 영역에 쓰레기값인 '00'이 사용되면 버퍼 오버플로우 시도로 판단한 듯 하다. (검사 위치 및 순서 조건이 없어서 의도대로 동작하지는 않았음)
 
그러나 이미 확인했듯이 0D0A대신 0A가 사용되었다고 해서 구분자 조작 시도는 아니며, 헤더 영역의 쓰레기값 역시 나오지 않았다. 결국 해당 로그는 모두 오탐이다. 그런데 룰 수정이 필요할까? 워낙 오래된 취약점인데다, Snort도 버린 마당에 굳이?
 
'신호와 소음'에 이런 문구가 나온다.
 
'우리의 적이 우리의 어느 곳을 칠지 예측할 수 있는데, 바로 우리가 가장 예상하지 못하는 곳이다.' (644 페이지)
 
여기저기 될 때까지 찔러보는 공격자를 절대 무시하면 안 된다. 설령 패치 등을 통해 이미 취약점을 제거했다 하더라도 탐지로그를 통해 공격자의 동향을 파악함으로써 소위 '선제적 대응'이란 걸 하게 될 수도 있다.

 
검사 위치에 제한을 뒀으며, 해당 룰 개발자의 의도를 존중하는 차원에서 헤더 필드 구분자로 0A를 사용한 경우만 탐지하는 방향으로 수정했다. 공격을 탐지하지 못한다고 당장 실망할 필요는 없다. 오탐만 줄어도 반은 성공이며, 이후 로그 발생 양상에 따라 수정 가능성은 무궁무진하니까.
 
[글. 강명훈 <빅데이터 분석으로 살펴본 IDS와 보안관제의 완성> 저자 / kangmyounghun.blogspot.kr]
 
★정보보안 대표 미디어 데일리시큐!★
■ 보안 사건사고 제보 하기

▷ 이메일 : mkgil@dailysecu.com

▷ 제보 내용 : 보안 관련 어떤 내용이든 제보를 기다립니다!

▷ 광고문의 : jywoo@dailysecu.com

★정보보안 대표 미디어 데일리시큐 / Dailysecu, Korea's leading security media!★