Snort 분석(WEB-CLIENT Malformed PNG detected sRGB overflow attempt)

Snort 설치 다음 단계는 탐지로그 분석. 참고로 최대한 다양한 유형의 탐지로그(오탐)를 경험하기 위해서는 Snort.org에서 다운로드 받은 룰 전부 활성화, 즉 주석(#)을 제거한 후 Snort를 운영하는 것이 좋다.

첫번째 분석 사례는 모 인터넷 서점 사이트에 접속하는 과정에서 발생한 'WEB-CLIENT Malformed PNG detected sRGB overflow attempt'.

유형별로 다양한 룰 파일이 존재하기 때문에 검색이 필요하다. 검색 결과 'web-client.rules'라는 파일에 기록된 룰임을 알 수 있다.

최강의 텍스트 에디터 VIM을 이용해서 해당 룰 파일을 열어보자. 유사한 룰들이 많은데 모두 PNG 파일의 chunk(분할 인코딩 전송 방식) 타입(hIST, tRNS, pHYs, sPLT, sBIT, bkGD, tIME, zTXt, iTXt, cHRM, tEXt, sRGB, iCCP)별 버퍼 오버플로우 공격 탐지 룰.

• 관련 자료

• web-client공백malformed공백png공백detected공백\w\{4}
• \w\{4} 는 4개의 문자를 의미하는 VI 정규표현식
• \w{4} 는 4개의 문자를 의미하는 PCRE 정규표현식

해당 룰의 상세내역은 다음과 같다.

alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any 
(msg:"WEB-CLIENT Malformed PNG detected sRGB overflow attempt"; 
flow:established,to_client;        

• TCP 세션이 성립된 트래픽 중 Client(Syn을 보낸)로 향하는

flowbits:isset,http.client.png; 

• 사전에 'http.client.png'로 명명된 세션 트래픽에서
• 해당 세션을 추적하는 룰이 별도 존재함

content:"sRGB"; 

• 'sRGB' 문자열 검사

byte_test:4,>,3000,-8,relative; 

• 이전 문자열 검사가 끝난 지점(relative)부터 특정 위치의 byte를 찾아서 값이 3,000보다 큰지 검사

metadata:policy security-ips drop; 
reference:bugtraq,18385; 
reference:cve,2006-0025; 
reference:url,www.microsoft.com/technet/security/bulletin/ms06-024.mspx; 
classtype:attempted-user; 
sid:6692; 
rev:4;)

해당 룰은 2006년에 발표된 마이크로소프트 Windows Media Player의 PNG 파일 처리 취약점(MS06-024)을 이용한 공격을 탐지한다. 그리고 'flowbits' 옵션을 이용해서 사전에 추적중인 특정 세션 트래픽만을 검사한다.

사전에 특정 세션 트래픽만을 추적해주는 룰이 있다는 얘기인데 그 룰도 찾아보자. 다음은 정규표현식의 '부정형 후방탐색' 옵션을 사용해서 'isset,'으로 시작하지 않는 'http.client.png' 문자열을 검색한 결과.

• \(isset,\)\@<!http\.client\.png
• \(패턴1\)\@<!패턴2 는 ‘패턴1’로 시작하지 않는 ‘패턴2’를 찾아주는 VI 정규표현식
• (?<!패턴1)패턴2 는 ‘패턴1’로 시작하지 않는 ‘패턴2’를 찾아주는 PCRE 정규표현식

해당 룰은 단순히 네트워크상에서 PNG 파일 전송을 감시할 뿐이지만, PNG 파일 전송이 발생한 세션 트래픽을 추적함으로써 이후 다른 룰을 통해 다양한 방식으로 추가 검사를 할 수 있게 해준다.

alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any 
(msg:"WEB-CLIENT PNG file transfer"; 
flow:established,to_client; 

• TCP 세션이 성립된 트래픽 중 Client(Syn을 보낸)로 향하는

content:"|89|PNG|0D 0A 1A 0A|"; 

• 헥사값 '89'로 시작하고, '0D0A1A0A'로 끝나는 문자열 'PNG' 검사

flowbits:set,http.client.png; 

• 문자열 검사가 성공하면 'http.client.png'로 명명 후 해당 세션 트래픽 추적

flowbits:noalert; 

• 경보, 즉 탐지로그는 발생시키지 않음

classtype:protocol-command-decode; sid:6688; rev:5;)

이제 분석을 해보자. 다음은 '-l c:\snort\log' 옵션에 의해 저장된, 탐지로그 원본 패킷을 wireshark로 실행한 결과.

와이어샤크에서는 텍스트 분석이 불편하기 때문에 정확한 분석을 위해서는 '패킷 Bytes' 영역을 텍스트로 복사해야 한다.

'sRGB' 문자열 검사 후, 검사가 끝난 지점(relative)부터 -8byte를 이동, 해당 지점부터 4byte의 값이 3,000보다 큰지 비교해보자.(content:"sRGB"; byte_test:4,>,3000,-8,relative;)

16진수를 10진수로 변환한 결과 3,000보다 무조건 크다. 해당 룰은 정상적으로 동작했다. 그렇다면 공격인가? 해당 룰이 chunck 타입별 버퍼 오버플로우 공격을 탐지하기 위해서는 chunck 데이터의 길이를 검사해야 하며, chunck 데이터의 구조는 다음과 같다.

다음 그림은 정상적인 PNG 파일 전송 트래픽이다. 'tEXt'라는 chunk 타입이 사용되었으며, chunk 데이터 길이는 25byte이다.

해당 룰은 chunk 타입만이 아닌, 단순 문자열로 사용된 'sRGB'까지 검사하면서 정상적인 chunk 데이터 길이 영역 검사에 실패하고 있다. 즉 해당 탐지로그는 오탐이다.

나머지 관련 룰들도 비슷한 상황일 것이다. 단순 문자열이 아닌, chunk 타입으로 사용된 문자열만을 검사할 수 있도록 룰 수정이 필요하지만 딱히 좋은 아이디어가 떠오르지 않는다.-_-

보안취약점을 근거로 복잡한 옵션을 반영하여 제작된 해당 룰은 공격을 탐지할 수는 있으나, 공격보다 더 많은 오탐 역시 발생 가능함이 확인되었다. 공격을 탐지하는 룰을 만들기는 쉽지만, 오탐이 적은 룰을 만드는 것은 매우 어렵다.

그리고 그 오탐은 (공격을 탐지하고 있음에도) 결국 룰을 양치기 소년으로 만들어 버린다. 룰 작성 시 목적을 명확히 하고, 룰이 목적에 맞게 동작하는지 항상 살피는 자세가 반드시 필요한 이유가 되겠다.

관련글

• Snort 분석(WEB-CLIENT Malformed PNG detected sRGB overflow attempt 분석 - 2nd)