volafunx 0.2 beta2 Release

뒤늦게 글을 올리네요. volafunx 0.2 베타2가 지난번에 릴리즈 되었습니다. 이번 버전의 특징은 다음과 같습니다.

도구 링크: volafunx 0.2 beta2

* 프로세스 목록 추출: 기존의 리스트 기반 추출에서 해시 테이블 기반 추출 기능 추가
* 프로세스 덤프를 프로세스 은닉 기능에 대응할 수 있는 해시 테이블 기반으로 수정
* 네트워크 정보 추출: 리스트 기반 추출에서 해시 테이블 기반 추출 기능 추가
* 네트워크 정보의 IP 출력 기능 추가

기존 프로세스 및 네트워크 정보 추출 기능은 루트킷이 리스트를 제거하는 기법을 통해 우회가 가능했었는데요. 문제를 보완하기 위해 또다른 탐지 방법인 해시테이블을 통한 검색을 추가하였습니다.

해시 테이블은 프로세스 및 네트워크 정보를 빠르게 수집하기 위해 캐시와 같이 섹터크기부터 클러스터 크기 정도의 영역에 각 프로세스 또는 네트워크 구조체의 커널 주소 영역을 int형 배열 형태로 정리해 둔 테이블입니다. 이에 커널 또는 콘솔 상의 몇몇 명령어들이 속도 향상을 목적으로 해당 명령어를 사용하는데요. volfunx 0.2 베타2에서도 이제 해당 정보를 추출하여 정보를 뽑아오도록 하였습니다.

그럼 이 정보로 프로세스나 네트워크 정보의 완전 무결성을 보장할 수 있냐고 물으신다면, 절반은 'yes'라고 대답하겠습니다.

왜 절반이냐면, 네트워크 정보는 보장할 수 있지만(시스템 콜 후킹을 하지 않았다는 전제하에..) 프로세스는 해당 기법을 우회하는 루트킷의 은닉 기법이 존재하기 때문입니다.

본래 bsd(뭐 리눅스도 동일할 겁니다.)는 작업 관리를 task 단위로 수행합니다. 즉 프로세스 관리 구조체인 proc는 실제 구동 후에는 크게 상관이 없게 되는 것이죠. 이에 프로세스를 최초 로드할 때 proc 구조체를 생성하고 난 후에는 task 정보를 스케쥴링에 이용한다고 생각하면 됩니다.

스레드 구조체로 관리할 수도 있다고 생각했는데, 이도 아닌 것으로 확인되었습니다. 적어도 bsd는 스레드에 대한 별도의 체인을 유지하고 있진 않으며, 각 proc 구조체에 있는 thread링크 체인은 해당 프로세스 내부의 스레드 체인만을 관리하고 있습니다. 커널 이미지 내의 thread0 또한 커널 프로세스의 스레드 시작 주소만을 저장하고 있기 때문에, 해당 정보를 이용해서는 모든 프로세스의 정보를 추출할 순 없게 되는 것이지요.

결론적으로 프로세스 은닉을 완벽하게 탐지하기 위해서는 task 구조체의 정보를 추출해야 합니다. 이를 위해서는 커널 이미지의 task_queue를 추적하는 방안을 생각하고 있습니다. 커널 이미지는 다 수의 task_queue를 배열로 관리하기 때문에, 해당 내용을 좀더 분석하면 좋은 결과를 얻을 수 있을 것이라 생각합니다.

네트워크 정보의 경우엔 네트워크 연결 및 전송을 해시테이블을 이용하여 수행하므로 루트킷에서 함부로 링크를 제거할 수 없습니다. 이에 현재로서는 별도의 업데이트의 필요성을 느끼지 않고 있습니다.

이제 슬슬 해당 작업을 시작해야 하는데, 다른 일들이 있다보니 아직은 시작하지 못하고 있네요. 우선 구글링 결과로는 해당 기법이 나와있지 않으니, 도구화해서 잘 증명하면 괜찮은 탐지 기술이 될 것 같습니다.

이로써 volafunx는 크게 2가지 일이 남았네요.

1. task기반 프로세스 은닉 탐지 기술
2. 프로세스 및 네트워크 정보 카빙 기술

사실상 이 정도만 구현되면, 그 다음 링크된 파일 추출 기술 같은 것은 천천히 구현해도 될 것 같습니다. 생각해둔 아이디어는 많은데 시간이 없네요. cowork할 시점이 다가오는 것 같습니다. :)

역시 일요일에 포스팅을 하니 좀더 여유있게 글을 쓸 수 있네요. 이제 다른 삽질을 하러 가봐야겠습니다. 좋은 저녁 되시길! :)

n0fate's Forensic Space :)