작년 EnFuse Conference 참석에 이어 올해는 Techno Conference에 참석하였다. Techno Conference는 얼마 전까지 모바일 보안을 주제로 컨퍼런스를 운영 하다가 현재는 보안과 디지털 포렌식을 주제로 변경하여 행사를 개최하고 있다.

 

 Techno Conference는 6월 3-7일 동안 여러 세션을 운영하며 참석자가 듣고 싶은 세션을 선택해 들을 수 있도록 EnFuse와 마찬가지로 컨퍼런스 일정 동안 스케줄 관리 앱을 제공한다. 제공되는 앱은 스케줄 관리 뿐만 아니라, 발표자료 보기, 중요 이벤트 알림 등의 기능이 부가적으로 있어 컨퍼런스 일정 동안 아주 편리하게 사용할 수 있다.



 떠나기 전 발표 주제를 살피며(EnFuse보다 기술적이라는 이야기를 듣고) 큰 기대를 안고 6월 3일날 인천 공항으로 향하였다. 


# Techno2017 Conference 0 Day

 여행과 컨퍼런스의 부푼 설렘을 안고 인천공항에 도착했을 때부터 나는 사실 조금 정신이 없었다. 작년 EnFuse Conference에 갈 때와는 달리 셀프 체크인을 해야 했다. 그런데, 셀프 체크인을 할 떄 전혀 입력해보지 않았던 목적지 주소와 방문 목적 등을 입력하라는 것에 조금 어리버리하여 출국 수속이 예상보다 늦어졌었다. 그리고 행사 장소는 South Carolina에 위치하고 있는 머틀비치인데, 직항이 없어 애틀란타를 거쳐 가야했다. 근데 셀프 체크인에서는 애틀란타까지만 가는 티켓을 출력해주는 것이 아닌가.. 셀프 체크인으로 반절의 출국수속만 한 나는 짐을 보내기 위해 1시간을 대기하고 머틀비치행 비행기를 애틀란타 비행기와 연결 시키기 위해 20분 대기했다. 또 주말이라 사람은 어찌나 많던지... 오전 9시 40분 비행기여서 아침 7시에 도착했는데, 출국과 입국으로 뒤섞인 사람들이 굉장히 많아 이래저래 아침부터 정신이 없는 하루였다.


 출국 수속을 마치고 면세점 라인으로 들어서 동생 선물을 찾고 나서야 조금 여유를 찾을 수 있었다. 여유를 찾은 뒤, 나는 간단하게 아침 요기를 하고 나서 미국행 비행기에 몸을 실어 비로소 컨퍼런스 참석을 위해 한국을 떠났다.





 13시간의 비행을 마치고 애틀란타 공항에 도착했을 때 시간은 점심시간을 막 지나고 있었다. 그래서 점심을 먹기 위해 이리저리 공항을 돌아다니던 중 미국에서 유명하다는 FIVE GUYS 버거집을 발견해 버거를 먹었다. 역시는 역시! 외국 애들은 너무 짜게 먹는 것 같다 ㅠ.ㅠ 해외 출장이나 여행을 다닐 때마다 느끼는거지만 왜 우리나라만 짜게 먹는다고 경고를 주는지 모르겠다. 본인들이 훨씬 짜게 먹으면서 ...


 점심을 먹고 머틀비치행 비행기를 기다리는데 출발시각이 임박 했는데도 게이트가 열리지 않았다. 결국 게이트는 출발시간보다 1시간 늦게 열렸다. 원래 이들은 섬세하지 못한걸까, 게이트가 왜 늦게 열리는지 늦게 열리는 이야기를 말해주지 않는다 ㅡㅡ 정말 언제 열릴지 모르고 계속 앉아 있다 게이트를 잘못 알았었나 하는 착각까지 했었다.


 나는 그렇게 우여곡절 끝에 머틀비치행에 올랐다. 애틀란타에서 머틀비치까지는 1시간 남짓 걸린 것 같다. 비행기에 타자마자 잠에 빠져 내릴 때 깨 사실 나는 체감상 1분 정도 걸린 것 같다 ㅋ


 머틀비치에 도착해 별탈 없이 택시를 타고 호텔까지 왔다. 그런데, 호텔 방에 있어야 할 것이 없었다. 미니바에 물이 없었다 ㅡㅡ 원래 미국은 호텔에서 물을 제공하지 않는다고 하는데 아직도 이건 조금 납득이 가지 않는다. 기본적인 것들을 제공하지 않는 호텔이라니.. 모텔보다 못한 것 같다. 결국 대표님과 나는 물도 사고 저녁도 먹을 겸 호텔 근처 마트를 갔다. 말이 근처지 걸어서 15분 걸어가야 한다. 호텔 근처에는 숲 밖에 없더라 하...


 이것저것 장을 보고(내가 맥주를 사려고 계산대에 올리니까 아주머니가 미성년자는 안돼욧! 이라고 하던데 흐뭇.. ^^) 마트 근처에 있는 Subway에서 샌드위치로 저녁을 해결하려 하는데, Subway 알바생이 영어를 버벅일 때마다 얼마나 한숨을 쉬던지 때릴 뻔 ㅎ 어쨋든 샌드위치는 양이 많은 것 빼고 나름 만족스러웠다.


 저녁도 해결하고 호텔로 들어온 나는 침대에 곧바로 쓰러져 컨퍼런스 전날을 마무리 했다.




# Techno2017 Conference 1 Day

 드디어 컨퍼런스 첫날이 밝았다. 컨퍼런스 첫날은 가볍게 시작하는 느낌이었다. 세션이 다른 날은 오전부터 꽉꽉 차 있었는데, 첫날은 여유롭게 오후부터 시작하였다. 오후부터 시작하는 이유는 여러가지가 있겠지만, 해외에서 온 손님들을 위한 운영진의 배려라 믿고 싶다. ㅋㅋㅋ


 어찌됐건 점심을 전날 갔던 Subway에서 해결(어제 그놈은 없었다)하고 컨퍼런스 등록을 하러 등록대로 향했다. 컨퍼런스 등록대는 EnFuse와 비교했을 때 조금 작은 느낌이었다. 이때부터 직감했다. Techno Conference 규모를 ㅠ



나는 위 사진에 나온 곳이 컨퍼런스 메인 홀인줄 알았다. 근데 아니었다 ㄷㄷ



위 사진이 바로 등록대!! 등록하는 사람들은 많은데 등록을 받는 인원은 달랑 3명 ㅎ



 나는 한국에서 출발할 때 로밍을 하지 않았다. 요즘 와이파이가 워낙 많아서 '와이파이 잡아야지~' 라는 마음이었다. 역시나 컨퍼런스 주최측에서 컨퍼런스 전용 와이파이를 제공해줬다. 근데 Access Code를 요구하는게 아닌가!! 처음에는 챌린지인줄 알고 이리저리 찔러보았다. 결국 등록대에 물어봤는데, 등록대에서 알려준 코드도 맞지 않았다. 그래서 결국 게싱해서 컨퍼런스 와이파이를 조금이나마 혼자 사용했다(다른 사람들도 등록대에 Access Code를 물어보고 접속이 안되 포기했었다고 한다) :-)


 이제부턴 컨퍼런스 첫날에 들었던 세션에 대해 간략한 소개와 느낀점을 적어볼까 한다.



1. Digital Intelligence - Information at the Speed of Life

 Digital intelligence라는 용어를 나는 여기와서 처음 들어봤다. 물론 용어는 만들기 나름이지만, 나중에 여러 세션을 들어보고 나니 해외에선 Digital Intelligence, Digital Investigation 등의 용어가 일반화 되어 있는 것 같았다. 무튼 이번 발표 세션은 소셜 네트워크 정보 프로파일링 해 수사에 활용하는 방안을 소개했다. 발표자는 소셜 네트워크 정보를 프로파일링 하기 위해서는 4가지의 정보가 필요하다고 한다.


 - Content : 사용자가 무엇을 말하는가?

 - User : 화자는 누구인가?

 - Time : 언제 말하였는가?

 - Location : 어디서 말하였는가?


위 4가지 정보를 소셜 네트워크에서 수집하고 가공하여 이를 프로파일링 한다는 것이 주된 주장이었다. 실제 사례로 Anonymous 멤버 검거 사례를 이야기해 개인적으로 재밌게 들었던 세션이다.





2. Ransomware! What's Bitcoin Have to Do With it?

 이번에 소개할 세션은 랜섬웨어를 주제로 한 세션이다. 개인적으로 기대가 많이된 세션이었는데, 실제 내용은 기대에 부흥하지 못해 굉장히 실망한 세션 중에 하나였다. 랜섬웨어가 비트코인을 이용하는 목적 등의 철학적(?), 경제학적(?) 관점이 나올 줄 알았는데 워너크라이가 어쩌고.. 랜섬웨어 역사가 어쩌고.. 하는 이야기가 나왔다 ㅠㅠ 내용도 기술적인 면이 없고 개론 수준의 발표여서 아쉬워하고 있던 찰나에 본인 회사의 솔루션을 소개하는 바람에 발표는 완전 실망이었다. 





3. Windows Memory Investigation

 내가 너무 기대를 많이 했던 걸까. 두 번째 세션에 이어 이번 세션도 많은 실망을 하고야 말았다. 나는 Investigation 용어를 붙여놨길래 기존 메모리 포렌식을 수사관점으로 바라봐 의미있는 데이터를 추출하고 분석 노하우를 알려주는 줄 알았다. 근데 내기 기존에 강의하는 수준에도 못미치는 내용을 발표하더라 ㅠ 그래서 중간에 듣다가 나와버렸다 . 내용은 메모리 분류, 가상주소와 물리주소의 맵핑 정도만 소개하고 본인 회사에서 만든 도구를 소개해주면 사용하라는 식이었다. 더군다나 발표자가 본인이 만든 발표자료 같지 않았다. 발표 내용을 버벅이는걸 보고 내가 다 불쌍했다. 발표를 계속 듣기엔 시간도 아깝고 너무 피곤해서 그대로 호텔방에 와 잠들어버렸다.



저작자 표시 비영리 변경 금지
신고

F-INSIGHT에서 발표했던 발표자료입니다.



Deep in the artifacts #1.pdf


저작자 표시 비영리 변경 금지
신고
  1. 오정훈 2017.03.13 19:28 신고

    좋은 자료 감사합니다~^^

  2. nill 2017.04.05 17:20 신고

    좋은자료감사합니다
    uuid가 레지스트리에 존재하나요?
    아무리 찾아도 없네요;;

    • Favicon of http://maj3sty.tistory.com BlogIcon MaJ3stY 2017.04.07 17:58 신고

      UUID 형태의 값들은 많이 존재하지만, UUID라고 명확하게 명시되어 있는 단일 값은 존재하지 않습니다.

 윈도우 운영체제에서 실행 파일의 흔적을 알 수 있는 대표적인 흔적으로 프리패치(Prefetch) 파일이 있다. 프리패치 파일을 분석하면 프로그램의 실행 날짜, 실행 횟수, 프로그램 경로 등을 알 수 있는데, 프리패치는 메모리의 한계와 페이징으로 프리패칭 기능의 원래 목적 상실, 운영체제에서 프리패치 파일을 관리하는 정책 상 최대 128개의 프리패치 파일 생성이라는 문제로 인해 빠른 대응과 운이 따라주지 않는다면 프리패치를 통한 실행 프로그램의 정보를 획득하기는 쉽지 않다. 프리패치 파일을 카빙하면 이 부분을 어느정도 해소할 수 있지만 복구라는 것은 상황에 따라 결과물이 다르기 때문에 이를 해결책으로 생각해서는 안된다.


 또, 특별한 권한 없이 프리패치 파일에 접근 할 수 있어 많은 악성코드 또는 도구에서 안티 포렌식 대상으로 삼기도 해 요즘은 사실 프리패치에서 많은 정보를 얻진 못한다. 


 이러한 이유들로 예전에는 분석에 초점을 두지 않았던 슈퍼패치가 다시 분석 대상에 오르기 시작하였다. 슈퍼패치는 프리패치와 함께 윈도우 운영체제에서 사용하는 메모리 관리 기술로, 사용자의 프로그램 사용 패턴(얼마나 자주, 언제, 얼마 동안)을 디비 형태의 파일에 기록하고 추적하는 기술이다. 슈퍼패치의 저장 경로는 다음의 경로로 프리패치와 동일하다.


 - %SystemRoot%\Prefetch


 슈퍼패치 기능은 윈도우 운영체제가 설치된 컴퓨터 환경에 따라 기능이 Off 되어 있을 수 있다. 대표적으로 SSD를 사용하는 컴퓨터에 설치된 윈도우 운영체제라면 슈퍼패치와 프리패치 기능은 기본으로 꺼져 있다. 시스템의 성능을 빠르게 하기 위하여 생겨난 메모리 관리 기술이나 SSD는 저장매체 자체가 메모리이기 때문에 그 속도가 HDD와는 다르게 빨라 메모리 관리 기술이 필요 없는 것이다. 오히려 해당 기술로 인해 시스템의 불필요한 퍼포먼스만 추가하게 되는 셈이다. 슈퍼패치는 다음과 같이 슈퍼패치 서비스가 시작되어야 운영체제에서 슈퍼패치 기능을 실행한다.


[그림 1 - 슈퍼패치 서비스]


 또 레지스트리 설정으로 슈퍼패치 기능을 활성화 시킬 수 있다. 이는 인터넷에 자료가 많으니 참고하기 바란다.


 슈퍼패치일 파일은 저장 경로에 접두어 "Ag"로 시작하는 파일이다. 해당 파일의 구조는 다음 문서를 참고하기 바란다.


 - 슈퍼패치 파일 구조


슈퍼패치 파일에서 포렌식 관점의 필요한 데이터는 정리하면 다음과 같다.


1. 실행 프로그램의 이름

2. 실행 횟수

3. Foreground 실행 횟수

4. 실행 프로그램이 메모리에 로드한 파일

 - dll 파일

 - 압축 파일

 - 문서 파일

 - 데이터베이스 파일

 - 이 외의 파일 및 폴더 등

5. 실행 프로그램의 전체 경로

6. 실행 프로그램의 실행 시간대

 - 평일 오전 6시 ~ 오후 12시 (Weekday 6AM to 12PM)

 - 평일 오후 12시 ~ 오후 6시 (Weekday 12PM to 6PM)

 - 평일 오후 6시 ~ 오전 12시 (Weekday 6PM to 12AM)

 - 평일 전체 (Weekday Global)

 - 주말 오전 6시 ~ 오후 12시 (Weekend 6AM to 12PM)

 - 주말 오후 12시 ~ 오후 6시 (Weekend 12PM to 6PM)

 - 주말 오후 6시 ~ 오전 12시 (Weekend 6PM to 12AM)

 - 주말 전체 (Weekend Global)

7. 타임스탬프


슈퍼패치를 분석할 수 있는 도구는 Superfetchlist 도구와 CrowdResponse 도구가 있다. 입맛에 맞는 도구를 사용하면 된다. 다만, Superfetchlist 도구의 경우 CLI 기반과 GUI 기반의 도구로 나뉘어져 있고 파싱되어 출력된 정보가 CrowdResponse 도구에 비해 많지 않아 필요로 하는 정보를 얻지 못할 수 있다. 다음은 두 도구의 실행 화면이다.


[그림 2 - Superfetchlist 도구 실행 화면 (출처: http://www.tmurgent.com/)


[그림 3 - CrowdResponse 도구 HTML 보고서 (출처: http://digital-forensics.sans.org/)]


[그림 4 - CrowdResponse 도구 csv 보고서 (출처: http://digital-forensics.sans.org/)]


프리패치보다 정보가 많고 데이터베이스 구조이기 때문에 프리패치처럼 정보가 쉽게 날라가지 않아 프리패치보다 정보를 얻을 확률이 더 높고 프리패치 만큼의 정보를 얻을 수 있다. 하지만 환경에 따라 기본 설정이 Off 되어 있는 만큼 기존에 설정을 해줄 필요가 있다.



저작자 표시 비영리 변경 금지
신고
  1. 2015.02.17 13:57

    비밀댓글입니다

얼마 전 유럽의 스카다 시스템을 공격한 Havex 악성코드에 대한 기사가 해외에서 처음으로 보도가 되었는데, 이전에 해외에서 취약점 공격에 대한 아티팩트를 정리한 포스팅 글을 보고 특정 악성코드나 취약점 공격의 아티팩트 정리의 필요성을 느껴 샘플을 아는 지인분을 통해 구한 후 포렌식 아티팩트들을 다음과 같이 정리하여 보았다. 


다음 아티팩트들은 기존에 남겨지는 일반적인 아티팩트들이 아닌, 해당 악성코드가 특이하게 남기는 아티팩트들인 것을 알아두기 바란다.


[Live Data]

라이브 데이터에서는 프로세스의 목록과 악성코드의 동작을 파악할 수 있다. 실제 악성코드의 동작을 하는 'mdCHECK.dll'은 'rundll32.exe' 프로세스에 의해 동작하며, 정상 프로그램의 위장을 위해 'mbCHECK.exe' 파일이 드랍되어 실행 중인 것을 파악 할 수 있었으며, 악성 프로세스의 상세정보도 파악 할 수 있다.


[그림 1 - 프로세스 명령 라이브 데이터]


[그림 2 - mbCHECK.exe 프로세스의 상세정보]


[Prefetch]

프리패치 정보에서는 프로세스의 상하관계를 확인 할 수 있다.


[그림 3 - 프리패치 마지막 실행 시간]


프리패치의 마지막 실행 시간을 정렬하여 보면, 먼저 드롭퍼의 실행이 있었고, 'mbCHECK.dll'의 실행, 마지막으로 'mbCHECK.exe' 프로세스가 실행이 된다. 실행의 순서는 알 수 있지만 드랍의 순서까지는 파악할 수 없다는 것이 단점이다.


[Timeline]

타임라인에서는 앞에서 확인하였던 사항을 제외하고 기타 다른 생성 파일들의 생성을 확인할 수 있었다.


[그림 4 - 타임라인 흔적 1]


[그림 5 - 타임라인 흔적 2]


새로운 파일의 생성 흔적을 확인할 수 있었지만, 생성의 순서는 모두 동일한 초 시간대에 일어났기 때문에 정확한 순서는 파악 할 수 없다. 


[NTFS Log]

파일시스템 로그에서는 다음과 같이 다른 흔적들에게서 발견하지 못한 새로운 파일의 생성흔적을 발견할 수 있었다.


[그림 6 - 파일시스템 로그 흔적]


해당 파일은 생성과 동시에 바로 삭제되는 특이한 점을 상황을 연출한다. 또 테스트한 Case에서는 바로 삭제되어서인지 $MFT 레코드가 바로 덮어씌어지고 클러스터 또한 바로 할당에서 비할당으로 바뀌어 데이터가 남아 있지 않아 복구를 하지 못하였다. 하지만, 이는 Case by Case이기 때문에 운이 좋다면 복구를 할 수 있을 것이다. $MFT 레코드가 삭제되어 해당 파일이 어디에 생성되는지 확인 할 수 없었다는 것이 이번 흔적에서의 아쉬운 점이라고 말할 수 있다.


[Memory]

메모리는 라이브 데이터와 대부분 동일한 흔적을 보여주지만, 데이터를 직접 얻을 수 있는 장점이 있다. 메모리에서는 운이 좋다면 이미 삭제된 레코드가 있는 $MFT를 추출 할 수 있다. 이번 Case에서도 파일시스템 로그나 라이브 데이터를 수집하며 같이 수집했던 $MFT에서 찾아볼 수 없었던 'System.dll'의 레코드를 획득할 수 있었다.


[그림 7 - 메모리에서 복구한 $MFT의 'System.dll' 레코드]


추가적으로 메모리 덤프 당시의 윈도우 쉘 상태를 파악 할 수 있다.



[그림 8 - 윈도우 쉘 스크린 캡쳐]


[정리]

Havex 악성코드의 흔적을 정리하면 다음과 같다.


1. 'mbCHECK'.exe와 'mbCHECK.dll'을 Drop

2. 'rundll32.exe'를 이용하여 'mbCHECK.dll'을 실행

3. 'qln.dbx' 파일을 Drop

4. '%UserName%\AppData\Temp\' 폴더 아래에 난수로 된 '.tmp'와 '.YLS' 확장자 파일을 생성

5. '%UserName%\AppData\Temp\<랜덤문자열>\' 폴더 아래에 'System.dll' 파일 생성 및 삭제


이를 IOC 포맷으로 정리하여 보았다. Havex IOC는 다음과 같다.


[그림 9 - Havex IOC]


Havex.ioc


해당 IOC는 아직 완벽하지 못하다. 랜덤 문자열의 경로를 IOC로 표현할 수 있는지 불확실하기 때문에 IOC에 해당 항목을 추가하지 못하였다. 이는 추후 파악 후 추가할 예정이다.



저작자 표시 비영리 변경 금지
신고

'[+] Forensic' 카테고리의 다른 글

[Tool] Windows JumpList Analysis Tool  (0) 2014.08.11
[Tool] Windows Link Analysis Tool  (0) 2014.08.11
[정리] Havex Artifacts  (0) 2014.06.30
[정리] TrueCrypt Forensics  (4) 2014.06.14
Advanced Jump List Forensics  (0) 2014.05.10

Anti-Forensics에서 가장 난감한 것은 개인적으로 생각할 때 '암호화' 기술인 것 같다. 분석해야 할 매체가 앞에 있음에도 불구하고 암호화라는 갑옷으로 둘러싸여 있어 분석을 쉽사리 하지 못하기 때문이다. 암호기술은 수학적 지식을 기반으로 고안되어 있기 때문에 현재로서도 깨지 못하는 암호들이 많이 있다. 불가항력(?)을 이겨내보기 위해 디지털 포렌식 분야에서는 많은 연구가 이루어졌었다. 이때 대상으로 연구가 많이 된 것이 'TrueCrypt'라는 암호화 소프트웨어이다.


TrueCrypt는 단일 파일부터 부트 드라이브까지 암호화 대상을 가리지 않는다. 또한, 일반 사용자들이 쉽게 사용할 수 있도록 GUI 환경을 제공해 사용 범위에 있어 한계를 거의 느끼지 못한다. 이런 이유로 많은 컴퓨터 사용자들에게 자신의 데이터를 안전하게 보호할 수 있는 환경을 제공하였는데, 디지털 포렌식 전문가들은 이와 같은 환경으로 인해 어지간히 애를 먹는 것이 현실이다.


이번 글에서는 TrueCrypt의 암호화 과정을 간단히 살펴보고, 이에 대해 지금까지 어떤 연구가 이루어졌는지 알아보려 한다. 정리 차원에서 쓰는 글이므로 따로 연구를 하거나 하지는 않았다.


참고로 TrueCrypt는 개발자가 알려져 있지 않다. 더군다나 작년 쯤에 NSA 도청 사건으로 인해 민간단체에 의해 TrueCrypt 내부에 백도어가 숨겨져 있다는 의심까지 받아 민간단체에게 감사를 받은 적이 있다. 물론 결과는 '없다'로 결론지어 졌지만, TrueCrypt 개발자는 마음고생을 좀 했을 것으로 예상이 든다. 이와 맞물려 Windows XP의 지원 종료로 인해 TrueCrypt는 개발이 중단되었지만, 최근에 오픈소스 개발자들이 TrueCrypt의 개발을 재개하여 다행히도(?) 많은 사용자들이 TrueCrypt의 암호화 서비스를 계속해서 지원 받을 수 있게 되었다.


그럼 이제 TrueCrypt의 암호화 과정과 복호화를 위한 Anti Anti Forensic 기술을 간단히 살펴보자.


1. 정상 암/복호화 과정

TrueCrypt에서는 기본적으로 다음과 같은 알고리즘과 모드를 지원한다. 아마 '정보보안개론'을 공부해 본 사람이라면 한번 쯤 들어본 알고리즘일 것 이다.


[알고리즘]

 - AES

 - Twofish

 - Serpent

 - AES-Twofish

 - AES-Twofish-Serpent


[모드]

 - XTS

 - LWR

 - CBC, Outer CBC, Inner CBC


오픈소스이기 때문에 많은 연구원들에게 분석 되어 이미 분석되어 일부는 복호화를 지원하지만, 방법이 대부분 메모리 이미지에서 패스워드를 긁어와 복호화를 하는 방법이다. 대표적으로 'Passware Kit Forensic', 'Elcomsoft Forensic Disk Decryptor' 도구가 있다.


암호화 과정의 설명은 다음 그림을 참고하며 설명하도록 하겠다.


[그림 1 - 암호화]


[그림 1]은 암호화가 진행 되어 완료 된 호스트 상태이다. 주요 암호화 과정은 다음과 같다.


1) 사용자가 Passphrase를 입력한다.

2) TrueCrypt는 암호화 대상 파일을 임의로 생성한 Master Key로 암호화 한다. 여기서 기본 암호화는 AES이다.

3) 암호화 된 파일을 컨테이너(Container)라고 부르는데, 컨테이너 파일에 붙일 헤더를 생성한다. 이때 헤더는 512byte이며, 데이터를 암호화 할 때 사용한 Master Key를 헤더에 저장한다. 

4) Master Key가 저장 된 헤더는 사용자가 입력한 Passphrase와 64byte의 Salt 값을 이용해 생성한 Header Key를 이용하여 암호화한다. 이때 사용된 Salt 값은 헤더 앞부분 64byte에 평문으로 저장한다.


위와 같이 정상적인 암호화가 진행되었고, 사용자가 복호화를 원한다면 TrueCrypt는 다음과 같은 복호화 과정을 거친다.


1) 사용자가 Passphrase를 입력한다.

2) 사용자가 입력한 Passphrase와 헤더 부분에 있는 Salt 값을 이용해 Header Key를 생성하고 Header Key를 이용 해 컨테이너 헤더를 복호화 한다.

3) 복호화 된 컨테이너 헤더에서 Master Key를 꺼내 데이터를 복호화 한다.


암호 알고리즘이 복잡할 뿐 TrueCrypt의 암호화 과정은 의외로(?) 간단하다. 이러한 과정을 역이용하여 여러 복호화 방법이 고안되었는데, 이제부터 그 몇가지를 소개해보고자 한다.


2. 연구 된 복호화 과정

복호화 과정 중에 현재 사용 중이며, 현실성이 있는 방법들을 위주로 소개하니 이 점 참고하고 글을 읽어내려 가기 바란다.


2.1 Cached Passphrase in Memory

암/복호화 과정에서 가장 중요한 것은 사용자가 입력한 'Passphrase'이다. 또한 소프트웨어가 사용자 입력 값을 저장하고 사용하기 위해서는 메모리에 이 값을 저장해야 하는데, 이 값은 한군데만 남는 것이 아니라 여러군데에 남는다. 그러므로 소프트웨어가 이 값을 모두 지우기란 불가능하다.


연구원들은 이와 같은 사실을 이용 해 메모리를 이미징하고 이미징 된 메모리 이미지 파일에서 캐싱된 Passphrase를 추출 해 컨테이너를 복호화 하는 식의 방법을 고안하였다. Passphrase의 구조는 다음과 같다.


[Passphrase Structure]

#define MIN_PASSWORD 1 // Minimum possible password length

#define MAX_PASSWORD 64 // Maximum possible password length


typedef struct

{

unsigned __int32 Length;

unsigned char Text[MAX_PASSWORD + 1];

char Pad[3]; // keep 64-bit alignment

} Password;


예제)

17 00 00 00 74 72 75 65 63 72 79 70 74 70 61 73   ....truecryptpas

73 77 6f  72 64 73 65 63 75 72 65 00 00 00 00 00   swordsecure.....


Passphrase 구조는 보듯이 특별한 Signature가 존재하지 않는다. Passphrase 구조를 규칙으로 하여 Text의 내용이 문자인 부분을 모두 추출 해 사용자에게 보여주거나 길이 hex값의 특징을 Signature로 이용해 패스워드를 추출 할 수 있다. 다음은 외국 블로거가 작성한 Passphrase 추출 스크립트 코드이다.


import struct,string

def isasciistr(s):
    return all(c in string.printable for c in s)

def findPassphrases(memdump):
    img = open(memdump, 'rb', buffering=10240)

    while True:
        region = img.read(10240)
        if len(region) == 0:
            break
        startoffset = 0
        while startoffset < len(region):
            offset = region.find('\x00\x00\x00', startoffset)
            if offset > -1:
                startoffset = offset+3
                lengthField = region[offset-1]
                #we found a set of three null bytes
                length = struct.unpack('<B', region[offset-1])[0]
                if length > 0:
                    passphrase = region[offset+3:offset+3+length]
                    lengthReal = len(passphrase)
                    #make sure we aren't hurtling off the region boundary
                    if offset+3+length+1 < 10240:
                        #make sure byte right after string is a null byte (sure, more should be null, but whatever)
                        if ord(region[offset+3+length+1]) != 0:
                            break
                    #make sure that the string is as long as the field said it would be
                    if isasciistr(passphrase) and ord(lengthField) == lengthReal:
                        #print the possibility
                        print "POSITIVE: "+passphrase + " EXPECT("+hex(ord(lengthField))+")"+" GOT("+hex(lengthReal)+")"
            else:
                break

findPassphrases()

출처 : http://delogrand.blogspot.fi/2013/04/cyber-defense-exercise-2013-extracting.html


현재 Volatility에서 내놓을 TrueCrypt 플러그인도 위와 같은 방법으로 메모리 이미지에서 Passphrase를 추출한다.


2.2 Fake Header

Fake Header는 TrueCrypt를 패치하여 복호화 과정을 교묘하게 이용하는 방법이다. 캐싱된 Passphrase가 메모리 이미지에 없고, 캐싱된 Master Key만 있을 경우 사용하는 방법이다.


1) 처음에 임의의 컨테이너를 생성한다.

 $> truecrypt --text --create --encryp-on=AES --filesystem=FAT --hash=RIPEMD-160 --password=MaJ3stY --random-source=/dev/random --size=20971520 --volume-type=normal tempFile


2) 임의의 컨테이너의 헤더를 복호화 대상 컨테이너 헤더로 덮어 씌운다.

 $> dd if=tempFile of=originalFile bs=512 count=1 conv=notrunc


3) 메모리 이미지에서 Master Key 목록을 추출한다. 목록을 추출할 때에는 Cold Boot Attack 연구 때 같이 연구된 aeskeyfind 도구를 이용한다. 해당 도구는 Aes key의 구조와 Entropy를 이용해 메모리 이미지에서 Aes key와 비슷한 데이터들을 추출 해 준다.

 $> ./aeskeyfind <메모리 이미지>


4) TrueCrypt를 패치한다.


[그림 2 - 원본 코드 : Volume/VolumeHeader.cpp]


[그림 3 - 수정된 코드 : Volume/VolumeHeader.cpp]


수정된 코드가 실행 될 때는 이미 Header Key가 생성되고 컨테이너 헤더가 복호화 된 상태이다. 이때 메모리 이미지에서 추출한 Aes Key 목록을 읽어와 메모리 버퍼에 저장한 후 해당 키 값을 헤더에 있는 Master Key와 교체한다.


5) 임의의 컨테이너를 생성할 때 입력했던 Passphrase로 복호화를 수행한다.

 $> truecrypt --text --mount-options=readonly --password=ABC123 originalFile /mnt/truecrypt 


간단히 정리하면, 임의의 컨테이너 헤더로 덮어 씌어진 복호화 대상 컨테이너 파일은 사용자가 입력한 Passphrase로 컨테이너를 헤더를 복호화 할 수 있다. 하지만 헤더 내에 저장되어 있는 Master Key가 다르므로, 컨테이너의 내용은 복호화가 안된다. 이를 위해 TrueCrypt의 복호화 단계에서 헤더 내에 저장된 Master Key를 바꿔치기 하기 위해 코드를 수정하는 것이다. 바꿔치기된 Master Key 중에 유효한 키가 존재한다면 복호화는 정상적으로 수행될 것이다.


3. 정리

위에서 소개한 방법 외에도 연구된 방법은 많지만, 현재 사용되지 않고 있다. 대표적인 예로 BIOS Key Buffer에서 Passphrase를 추출하는 방법이 있는데, 이 방법은 상위버전에서 패치되어 현재는 소프트웨어가 자체적으로 쓸모 없는 값으로 Buffer를 Clear하여 Passphrase를 추출하지 못한다. 또 이외에 방법들은 위 방법들을 응용할 뿐이고 다른 부분이라고는 메모리를 어떻게 수집하는지에 대한 것이어서 다른 방법들에 대해서는 따로 언급하지 않겠다.


한번정도는 정리를 해야겠다고 마음을 먹고 있었는데 이제서야 정리를 하게되었다. 혹시 이 글이 도움이 되는 사람이 있길 바란다. :-)


아래는 각 버전별 Passphrase와 Master Key등이 메모리에 남는지에 대해 정리한 표이다.


[표 1 - 버전별 정리]


* 3.1a 버전의 경우 Passphrase가 char *buffer 공간에 있어 여러군데 캐시가 되지 않는다. 그 대신 'truecrypt.sys' 파일에 .data Section에 Passphrase를 대신하는 문자열이 하드코딩 되어 있어, 특별한 경우가 아니면 메모리에서 캐시된 Passphrase를 추출 할 필요가 없다.


** Master Key가 없는 버전들은 'truecrypt.sys' 파일의 심볼정보를 추적하면 Master Key를 추측할 수 있다.


summary는 컨테이너에 관한 정보이다.

저작자 표시 비영리 변경 금지
신고
  1. 2014.09.21 15:58

    비밀댓글입니다

  2. 아무개 2015.02.27 11:23 신고

    레딧의 Truecrypt is dead? 스레드를 보니까, 최상위 도메인 관리기관을 통해 도메인 탈취로 가짜사이트 연결, 가짜 파일 제공으로도 모자라서
    소스 포지에 있던 구버젼 빌드들 까지 전부 바꿔치기 했다는거 같은데, TrueCrypt가 죽었다면 대체제는 무엇이 있나요?

    • Favicon of http://maj3sty.tistory.com BlogIcon MaJ3stY 2015.03.02 17:06 신고

      트루크립트 개발 중단이 되고나서 얼마 있지 않아 트루크립트 알고리즘을 기반으로 한 새로운 프로그램이 개발되어 나온적이 있습니다. 지금은 해당 도구 이름이 기억이 나질 않네요..
      일단 현재는 트루크립트의 계승 버전인 프로그램이 유일하다고 생각이 됩니다. 별다른 도구가 개발되었다는 이야기는 듣지 못했네요.

+ Recent posts