탐지패턴이 없는 로그가 있다. 그런데 가만 보니 아예 없는 건 아니고, URL 인코딩된 '%3A(:)' 패턴 때문에 검색식과 일치하지 않을 뿐이다.
정규표현식을 수정해보자. ':/'의 URL 인코딩 수준이 복잡한 바람에 최종 사용된 정규표현식도 좀 복잡해졌다.
- VIM : ^[^:?]\{-11,}\(:\|%\(25\|2525\)\{-}3a\)\(\/\|%\(25\|2525\)\{-}2f\)
- PCRE : ^[^:\/]{11,}?(:|%(25|2525)?3a)(\/|%(25|2525)?2f)
- PCRE 구조
 |
| regexper.com |
사실 그리 복잡한 구조는 아닌데 VIM의 예외처리 구문(\) 때문에 한없이 복잡해 보인다. 저 예외처리만 없어도 VIM 정규표현식이랑 친하게 지낼 수 있을 것 같은데(..)그런데 이럴 때 사용할 수 있는 아주 유용한 기능이 VIM에 숨어 있다. 바로 이름도 멋진 '매직(Magic)' 모드!
VIM 환경에서 기존에 예외처리가 필요했던 정규표현식을 예외처리 없이도 동작하게 만들어주는 기능.
다음은 매직 모드를 사용한 결과. 정규표현식을 작성할 때 최초 '\v' 구문을 붙여주면 VIM 환경에서도 마치 마법처럼 매우 심플(?)한 정규표현식 사용이 가능함을 알 수 있다.
그런데 사실 잘 안 쓰게 되는 기능이다. 몇 년을 눈 비벼가며 VIM 정규표현식을 사용해온 게 억울해서는 아니고, 항상 정규표현식을 작성하다가 '아차 매직 모드 쓸 걸' 하는 생각을 뒤늦게 갖게 된다.
습관이란 게 참 무서운 것 같다. 하지만 VIM 정규표현식을 접한 지 얼마 안됐다면 최초 '\v' 구문을 붙이는 습관을 통해서 정규표현식에 조금은 더 쉽게 다가갈 수 있을 것이다.
참고로 URL 인코딩은 '%' 기호와 16진수를 이용, URL을 표현하는 방식이며, (그래서 퍼센트 인코딩이라고도 함) 시스템마다 다른 문자열 해석으로 인한 오류를 막기 위해 사용하는 공통 표기 방식이라고 할 수 있다.
아스키코드 체계에서 문자 'A'에 대응하는 16진수는 '41'이므로 'A'를 URL 인코딩하면 '%41'이 되는 것.
':'의 16진수는 '3A'이므로 URL 인코딩하면 '%3A'가 된다. 그런데 이 '%'를 한 번 더 인코딩하면? '%'의 16진수는 '25'이므로 '%253A'.
이런 식의 중복 인코딩이 가능한데, 웹브라우저나 웹서버 종류 및 구현 방식에 따라 인코딩이 달라질 수 있으며, 공격자가 IDS의 탐지패턴을 우회하기 위해서 이런 인코딩 방식을 악용할 때도 종종 있다.
 |
| ':/'를 ':%2F'로 해석하는 구글 |
 |
| ':/'를 '%3A%2F'로 해석하는 네이버 |
결국
정규표현식 ':|\%(25|2525){-}3a'는 ':', '%3A', '%253A', '%25253A' 패턴 모두를 검사한다. 이제 텍스트 정규화를 통해 ':/' 패턴이 과연 쉘 환경변수로 사용됐는지 여부를 확인해보자.
탐지로그를 핵심 탐지패턴인 ':/'를 기준으로 텍스트 정규화한 결과는 다음과 같다. ':/' 패턴이 이중, 삼중으로 인코딩된 바람에 총 여섯 가지 패턴으로 표시되고 있음을 알 수 있다.
대충 봐도 대부분 'http://' 문자열의 일부라는 사실을 알 수 있지만, 뭔가 있어 보이는 보고서를 위해서라도 더 명확한 근거 자료가 필요하다. '패턴'과 연결되는 '패턴 전' 필드의 '끝 문자' 분포를 파악해보자.
참고로 필터 검색에 사용된 'http*'은 PCRE의 'http.*'과 같은 의미로 사용되는 (변형된) Windows 정규표현식(와일드카드)이다.
'사용자 지정 자동 필터' 기능을 이용한 결과 핵심 탐지패턴 ':/'는 전부 'http', 'https' 또는 'resource' 문자열 이후에 발생한다는 사실이 확인되었다. 결국 ':/' 패턴은 쉘 환경변수가 아니라 URL 등을 이용한 경로 패턴의 일부라는 얘기. 전부 오탐이라는 뜻이다.
'패턴 전' 필드를 '끝 문자' 기준으로 텍스트 정규화를 한 번 더 진행하면 패턴 발생 분포에 대한 더 세부적인 확인도 가능하다.
소개하는 사례들이 다 그렇지만 이번 사례 역시 데이터만 잘 정리하면 분석은 그다지 어렵지 않다는 사실을 알려주고 있다. 그런데 문제는 데이터 정리가 까다롭다(..) 다음 시간에는 확인된 패턴 발생 분포를 근거로 해당 룰의 오탐을 줄일 수 있는 방법을 찾아보자.
관련 글
탐지로그를 핵심 탐지패턴인 ':/'를 기준으로 텍스트 정규화한 결과는 다음과 같다. ':/' 패턴이 이중, 삼중으로 인코딩된 바람에 총 여섯 가지 패턴으로 표시되고 있음을 알 수 있다.
대충 봐도 대부분 'http://' 문자열의 일부라는 사실을 알 수 있지만, 뭔가 있어 보이는 보고서를 위해서라도 더 명확한 근거 자료가 필요하다. '패턴'과 연결되는 '패턴 전' 필드의 '끝 문자' 분포를 파악해보자.
참고로 필터 검색에 사용된 'http*'은 PCRE의 'http.*'과 같은 의미로 사용되는 (변형된) Windows 정규표현식(와일드카드)이다.
'사용자 지정 자동 필터' 기능을 이용한 결과 핵심 탐지패턴 ':/'는 전부 'http', 'https' 또는 'resource' 문자열 이후에 발생한다는 사실이 확인되었다. 결국 ':/' 패턴은 쉘 환경변수가 아니라 URL 등을 이용한 경로 패턴의 일부라는 얘기. 전부 오탐이라는 뜻이다.
'패턴 전' 필드를 '끝 문자' 기준으로 텍스트 정규화를 한 번 더 진행하면 패턴 발생 분포에 대한 더 세부적인 확인도 가능하다.
소개하는 사례들이 다 그렇지만 이번 사례 역시 데이터만 잘 정리하면 분석은 그다지 어렵지 않다는 사실을 알려주고 있다. 그런데 문제는 데이터 정리가 까다롭다(..) 다음 시간에는 확인된 패턴 발생 분포를 근거로 해당 룰의 오탐을 줄일 수 있는 방법을 찾아보자.
관련 글
댓글 없음:
댓글 쓰기