슬랙스킷 (Slackskit)
슬랙스킷(Slackskit)은 슬랙을 이용하는 악성코드를 통칭하여 부르는 말이다. 하지만, 아직까지 공식적으로 불려진 적이 없다. 최근에 커피를 마시다가 hojinpk의 조언과 함께 만든 이름이기 때문이다. 슬랙스킷은 새로운 악성코드는 아니다. 이미 슬랙을 이용하는 악성코드는 많이 나왔지만, 악성코드 명칭은 은닉 장소보다는 대부분 행위에 기반하여 붙이는 경향이 있다. 루트킷(Rootkit), 부트킷(Bootkit) 처럼 말이다.
슬랙 공간의 활용은 이미 포렌식 분야에서는 오래된 주제이다. 하지만, 악성코드의 변천사를 보면 이미 지난 기술을 활용할 정도로 너무 늦게 활용되고 있다. 그럴 수 밖에 없는 것이 현재의 은닉 기술로도 충분한데 새로운걸 만든 필요는 없기 때문이다. 백신업체들이 현재의 은닉 기술을 완벽하게 대응한다면 또 다시 새로운 영역으로 옮겨갈 것이다.
갑자기 슬랙스킷에 대해서 이야기하는 이유는 이전부터 관심을 가지고 있었지만, 최근에 연구를 집중해보려고 하는 분야이기 때문이다. 그리고 악성코드가 나온 이후에 대응하기보다는 악성코드가 활용할 장소를 미리 살펴보고 방법도 연구해본다면, 악성코드가 악명을 떨칠 때, 급한 단발성 대응보다는 큰 대응 프레임워크를 가지고 가볼 수 있지 않을까 하는 거창한 생각때문이다.
그렇다면 간단하게 슬랙스킷의 변천사를 살펴보자.
ADS (Alternate Data Stream)
ADS는 굳이 따지자면 슬랙 공간이라고 할 수는 없다. 파일시스템의 정상적인 구조이고, 운영체제의 많은 부분에 활용되고 있기 때문이다. 하지만, 많이 사용하지 않는 공간을 이용한다는 의미에서 슬랙스킷에 포함시켜 보았다. ADS를 활용한 유명한 악성코드로는 2005년 12월 초에 처음 나온 Rustock 이다. Rustock는 커널 스팸메일러로 2006년 7월까지 총 4차례의 버전 업데이트가 이루어진 다형성 바이러스이다.
MBR 슬랙
MBR 슬랙은 초기 트랙 당 섹터 수가 63섹터일 때, MBR이 기록되는 트랙은 MBR의 안정성을 위해 MBR만 사용하도록 구성해 놓았다. MBR은 보통 1섹터만 사용하기 때문에 나머지 62섹터는 그냥 빈 공간으로 저장매체에 존재한다(디스크 방식의 경우에만). 이 62섹터의 MBR 슬랙 공간이 악성코드에 의해 활용되기 시작했다. 2008년 초부터 많이 발생한 MBR 루트킷에 의해 많이 활용되는데, 보통 MBR 슬랙 공간에 코드를 올려 놓고 MBR 부트 코드를 조작하여 올린 코드로 점프하도록 구성을 하곤 한다.
시스템 예약 공간 (8MB, 동적디스크 설정 정보)
2009년 말에 처음 등장한 TDL3는 저장매체 마지막 부분의 8MB 공간을 사용한다. 이 공간은 저장매체를 동적디스크로 변경할 때 필요한 설정정보를 저장하기 위해 운영체제가 예약해둔 공간이다. 운영체제 설치 시 저장매체를 포맷해보면 아무리 최대로 파티션을 잡아도 잡히지 않는 8MB 공간이 있을 것이다. 이 공간이 동적디스크 설정 정보를 저장하기 위해 예약해둔 공간이다. TDL3, 4에서는 이 공간을 이용해 악성코드를 감염시킨다.
앞서 살펴본 슬랙 공간 외에도 많은 슬랙 공간이 존재한다. 살펴본 것은 대표적으로 나름 유명했던 악성코드가 사용했던 공간이다. 물론, 다른 슬랙 공간도 많이 사용됐지만 악성코드 변천사에서 큰 역할을 수행하지 못한 안타까운(?) 결과로 주목받지 못한체 지나가버렸다.
악성코드가 슬랙 공간을 사용하는 이유는 무엇일까? 가장 큰 이유는 백신을 우회하여 자신을 잘 숨길 수 있기 때문이다. 백신은 파일 단위의 탐지 기법을 많이 쓴다. 하지만 슬랙은 파일시스템의 구조에서 낭비되는 공간이므로 파일 단위의 탐지 기법으로는 탐지해내기 어렵다. 그리고 현실적으로 파일시스템에 존재하는 수많은 슬랙을 다 검사하는 것은 백신의 성능도 문제지만, 배보다 배꼽이 더 큰 경우이다. 이 때문에 의심되는 일부 슬랙을 검사하거나 알려진 악성코드가 사용했던 부분만 검사하는데 그칠 수 밖에 없다.
그렇다면 악성코드가 활용할만한 슬랙 공간은 어떤 것들이 있을까?
파일 슬랙(램 슬랙 + 드라이브 슬랙)
파일 슬랙은 클러스터를 사용하는(리눅스는 블록) 특성 때문에 논리적인 데이터를 저장매체에 쓸 때, 물리적으로 크기가 잡혀버려서 낭비되는 공간이다. 이 공간도 일반적으로 접근할 수가 없기 때문에 악성코드에 의해 활용될 수 있다. 파일 슬랙의 강점은 대부분의 슬랙은 API로 접근하기 어렵기 때문에 저장매체를 열고, 파일시스템을 해석하여 슬랙을 찾아야 한다. 하지만 파일 슬랙은 파일 뒷부분에 낭비되는 공간이기 때문에 간단히 해당 파일의 물리적 위치를 API로 얻은 다음, 쉽게 원하는 코드를 삽입하거나 가져올 수 있다.
파일시스템 슬랙, 볼륨 슬랙
파일시스템과 볼륨 슬랙도 구조 상의 문제점으로 인해 낭비되는 공간이다. 이 부분도 현재 저장매체의 파티션 구조나 클러스터 크기를 알고 있다면 쉽게 해당 위치에 원하는 코드를 삽입하거나 가져올 수 있다. 슬랙에 대해서 좀 더 세부적인 설명을 원하면 다음을 참고하자.
http://forensic-proof.com/archives/363
이외에도 파일시스템에 낭비되는 공간은 매우 많다. 다음 링크에서 “파일시스템 포렌식 분석” 슬라이드를 살펴보면 좀 더 자세히 알 수 있다.
http://forensic-proof.com/archives/2424
아직까지 슬랙의 활용성이 많이 때문에 쉽게 새로운 분야로 넘어가지는 않겠지만, 다음 대상은 무엇이 될까? 다음은 아마도 이런 부분이 은닉 장소가 될 것이다.
HPA & DCO 영역
HPA(Host Protected Area)나 DCO(Device Configuration Overlay)는 ATA 기반의 저장매체에서 저장매체에 일정 영역을 특수 목적(시스템 진단 유틸리티, 시스템 복구 영역 등)으로 이용해보고자 벤더들의 요청으로 ATA-4, ATA-6에서 추가된 기능이다. 이 영역은 파일시스템 수준의 영역이나 운영체제 수준의 영역이 아니다. ATA는 저장매체 인터페이스를 이르는 말이다. 말 그대로 장치의 규격이기 때문에 이 영역을 악성코드로 활용하면 운영체제 단에서 쉽게 접근할 수가 없다.
백신의 악성코드 대응 방안은 우선 감염된 근원을 찾아 해당 코드를 분석한 후, 감염시킨 정보들을 다시 원래로 복원시키는 것이다. 하지만, HPA, DCO에 코드를 숨긴다면 증상은 있지만, 증상을 발생시킨 근원(코드)를 찾지 못하기 때문에 대응에 어려움이 발생할 수 있다. 물론, 이 영역을 이용한 악성코드도 해외에서는 발견됐다는 얘기는 있다. 다만, 악성코드 변천사에서 아직 큰 역할을 못했을 뿐이다. 사람이나 악성코드나 이름을 날리려면 뭔가 큰일을 해야만 하니깐 말이다. HPA, DCO에 대한 추가적인 정보는 다음을 참고하기 바란다.
http://forensic-proof.com/archives/284
EFI BIOS 영역
MBR 구조에서는 파티션의 섹터 수를 지정하는 바이트 수가 4바이트라서, 2TB(2^32 * 512) 이상의 파티션은 만들 수가 없다. 즉, 2TB 이상의 저장매체가 나와도 MBR 구조를 사용하면 2TB 밖에 못쓰게 된다는 것이다. 이런 문제점을 해결하고자 나온 구조가 GPT(GUID Partition Table)이다. GPT 구조는 EFI BIOS가 장착된 메인보드를 구입하게 되면 경험해 볼 수 있다. 현재 최신의 메인보드는 대부분 EFI BIOS가 장착되어 출시되고 있다. GPT에 대해서도 자세한 내용을 원하면 다음 링크의 “파일시스템 -MBR, GPT” 슬라이드를 확인하자.
http://forensic-proof.com/archives/2424
해당 슬라이드에서 GPT 구조를 살펴보면 MBR과 다르게 부트 코드가 들어가는 영역이 없다. 그렇다면 어떻게 부팅이 될 것인가? GPT의 부트 코드는 EFI BIOS 내에 존재한다. 그렇다면, MBR에서 GPT로 넘어가면 부트킷은 없어지는 것인가? 아마도 그 때가 되면 EFI BIOS를 공격하는 악성코드들이 많이 나올 것이다. 현재도 BIOS를 공격하는 악성코드들이 없는 것은 아니지만 영향이 크지 않기 때문에 아직 빛을 발휘 못하고 있다.
다음 세대에 악성코드가 주로 노릴 은닉 장소는 어디가 될까? 그때가서 대비하기 보다는 사전에 연구해본다면, 실제 악성코드에 의해 큰 문제가 발생했을 때 제대로 된 대응 방안을 내 놓을 수 있지 않을까?
Categories
- 0×01 News (15)
- 0×02 Fundamentals (11)
- 0×03 Data Forensics (8)
- 0×04 Storage Forensics (12)
- 0×05 File System Forensics (31)
- 0×06 Windows Forensics (17)
- 0×07 *nix Forensics (1)
- 0×09 Web Forensics (5)
- 0x0A Virtual Forensics (5)
- 0x0B Forensic Challenges (15)
- 0x0C Forensic Education (8)
- 0x0D EnCase (12)
- 0x0E Forensic Tools (8)
- 0x0F Slides (24)
addressing artifacts BIOS boot code boot process challenge Cluster Codegate cookie Data Carving Data recovery DC3 DCO defcon ENCASE EnCE encoding EnScript exFAT FAT File System Forensic Challenge FTK GUID hardware hidden partition history imaging Live Forensics mbr network ntfs padocon process RAID Recycle Bin SCSI signature Slack slide timeline timestamp virtual forensics WDFS writeup
WP Cumulus Flash tag cloud by Roy Tanck requires Flash Player 9 or better.
What I'm Doing...
- 허니넷 워크샵이 페이스북 본사에서 열리네요. 게다가 페이스북 후원까지... https://t.co/8kzO7uuT 6 hrs ago
- RT @AhnLab_SecuInfo: 월간 안 2월호가 발간되었습니다. http://t.co/rAXqDXcT 이번 호에서는 2011년 악성코드 통계 분석, 루트킷 완전 해부, 포렌식 분석 기술 등이 포함되어 있으니 참고 하세요 #krsec 14 hrs ago
- 볼륨 섀도우 복사본(VSC) 소개에 이은 두번째 글입니다. http://t.co/hAXFkXjX 1 day ago
- More updates...


