이것저것

1. 정보 수집

• 실행하면 위와 같은 메시지를 출력하고 종료되는 실행파일이다.

• PEiD를 이용하여 해당 바이너리의 패킹 여부를 확인한다.

• UPX 패킹된 바이너리임을 확인할 수 있었다.

• upx 리눅스 유틸리티를 이용하여 언패킹을 진행

• 언패킹된 바이너리

2. 분석

• IAT 테이블을 살펴보니 다음과 같이 command line을 읽어오는 함수가 존재했다.

• 따라서 해당 바이너리를 정상 작동시키기 위해선 command line의 실행 인자를 전달해줘야 할 것이라고 추측이 가능하다.

• GetCommandLine 함수 직후에 특정 반복문이 존재하고 해당 반복문은 Command line으로부터 읽어들인 문자열을 edx 레지스터가 1바이트씩 이동하여 마지막 바이트를 가리키도록 한다.

• 이후 AL 레지스터에 [EDX-5] 위치의 1 바이트를 옮기고 해당 값을 스택에 넣는다.

• AL 레지스터에 0x20의 값을 넣고 스택의 최상단과 비교한다.

• 즉 EDX-5 위치가 0x20(공백문자)와 일치한지를 비교한다.

• 이후 일치하지 않을 0x004012FC 주소로 점프하며 해당 주소는 다음과 같이 MessageBox API를 호출하며 처음 출력되는 메시지가 출력된다.

• 따라서 해당 출력문을 피하기 위해선 [EDX-5]가 공백문자여야 하므로 파라미터는 다음과 같이 뒤에서 5번째 문자가 공백문자인 4글자의 파라미터가 전달되어야 한다.

  C:\Users\Desktop\FSC_Level2.exe asdf

• 인자로 "asdf"를 전달하고 해당 조건을 만족시키도록 하고 해당 분기문에 bp를 걸고 나머지를 분석한다.

• 이후 또 다시 비교문과 해당 비교문이 만족하지 않을 경우 비정상 종료 루틴에 빠지는 부분을 발견했다.

• 해당 위치에서 EAX에 0x6578652E(".exe")를 넣고 해당 값을 스택의 최상단에 있는 값과 비교한다.

• 해당 위치로 오기까지 스택의 최상단에 어떤 값이 위치하는지 확인하기 위해 백트레이싱을 수행한다.

• 인자로 전달한 0x66647361("asdf")을 0x5528566D과 xor 연산을 수행한 결과를 EAX에 저장한다.

• EAX에는 0x334C2501이 저장됨

• AH(0x25)와 BH(0xC0)를 XOR 연산을 수행하여 0x334CE50C이 EAX에 저장된다.

• 이후 해당 값을 0x6578652E(".exe")와 비교하여 일치하지 않을 경우 실패 루틴으로 진입한다.

• 따라서 0x6578652E의 값에 일련의 과정을 역연산해주고 나온 값을 파라미터로 전달할 경우 성공 루틴으로 진입이 가능하다.

• 0x6578652E의 세 번째 바이트인 0x65와 0xC0를 xor한 결과인 0x6578A52E

• 해당 값을 0x5528566D와 xor한 결과 = 0x3050F343

• 확인한 결과 실행할 때마다 ebx의 값이 변함

• ebx의 값을 설정하는 코드를 찾아본 결과 다음과 같이 entry 포인트에 존재

• 그러나 해당 지점에 bp를 걸고 실행해도 해당 부분은 실행되지 않음

• 원래대로라면 ebx에 고정된 값인 0으로 초기화되고 xor 연산에 영향을 주지 않아 "C3P0"가 정답이 되어야 하는데 안티디버깅 기법이 있는 것으로 볼 수 있음

• 실행 과정에서 ebx를 강제로 초기화하고 인자를 "C3P0"로 전달할 경우 정상적으로 플래그가 출력됨

정리

• PEP와 OEP : Packing entry point, Original entry point

• PEP 코드 실행 도중 디버거 사용 유무를 탐지하여 사용중일 경우엔 다른 OEP에서 시작하도록 하는 기법이었음

• 해당 문제에서는 TLS(Thread Local Storage) callback을 이용한 기법을 사용함

• TLS Callback이란 프로세스가 만들어질 때 메인 쓰레드가 초기화되기 전에 가동되는 코드

    

• PE header를 참조한 결과 해당 TLS 코드가 0x4070DC 번지에 존재함

• TLS callback 함수에 존재하는 디버거 탐지 코드 (IsDebuggerPresent())

• 따라서 디버거가 붙을 경우에 xor ebx, ebx 구문을 피해서 ebx가 초기화되지 않도록 하여 정상적인 플래그 인증에 실패하도록 하고 디버거가 붙지 않았을 겨웅 xor ebx, ebx가 정상적으로 실행돼서 플래그 인증이 가능하다.

1. 사전 정보 수집

• 해당 바이너리를 실행할 경우 위와 같이 키를 입력하라는 메시지가 출력된다.
• 바이너리가 요구하는 키를 맞힐 경우 플래그가 출력되는 형식이라고 추측할 수 있다.
• 
• PEiD를 이용하여 확인해본 결과 해당 바이너리는 PEiD로는 알 수 없는 방법으로 패킹되었거나 패킹되지 않았음을 확인할 수 있다.
• 패커가 사용되었는지 확실히 하기 위해 IAT를 봐서 추가적으로 확인할 수 있다.
• 패커는 대부분 IAT를 망가뜨리기 때문에 PEView를 이용하여 해당 바이너리의 IAT를 확인했을 때 Import한 함수의 개수가 적으면 패킹이 되었을 것이라 의심해볼 수 있다.
• PEView를 이용하여 해당 바이너리의 IAT를 확인해본다.
• 
• 
  
• 해당 바이너리가 두 개의 dll로부터 충분히 많은 Import 함수가 존재하므로 패킹되지 않은 바이너리임을 알 수 있다.
• 추가적으로 해당 바이너리의 Image Base는 일반적인 EXE 파일이 가지는 0x400000 번지가 아닌 0x69000000이었다. 따라서 해당 주소부터 분석을 진행한다.

2. 분석

• 먼저 실패할 경우 출력되는 메시지부터 백트레이싱을 수행한다.
• 참조된 문자열들을 검색해본 결과 0x69001152번지에 해당 문자열이 있는 것을 확인했다.

• 해당 위치의 윗부분에 문자열을 입력받고 특정 문자열과 비교를 하는 stricmp 함수를 발견할 수 있었다.
• 해당 함수에 bp를 걸고 실행 시 어떤 문자열이 오는지 확인해본다.

• 
  
• 비교 대상 문자열은 "Asm07REC"이다.
• 해당 문자열을 입력하면 다음과 같이 플래그가 출력된다
• 

1. 메모리 포렌식

디지털 포렌식과 같은 범죄 수사를 위한 디지털 증거 수집에 있어서 메모리 포렌식은 매우 중요한 기술이다. 암호화된 파일이 실행 또는 읽기를 위해선 메모리에 올라가게 되는 이 때 데이터는 일반적으로 복호화 되어 메모리에 올라가게 된다. 메모리 덤프를 통해 메모리의 이미지를 얻으면 복호화 된 데이터를 확인하는 것은 물론 복호화 키 또한 얻을 수 있다.

브라우저 검색 기록, 메신저 사용 내역, 암호화된 문서 등을 준비하여 여러 흔적을 남겨두고, 메모리 덤프 이미지를 확보하여 실제 데이터 추출이 가능한지를 시도해본다.

2. 실험 대상 

2.1) Browser 사용 기록

브라우저를 통해 웹 사이트에 로그인한 사용자의 계정 정보를 메모리 덤프를 통해 추출할 수 있는지 여부를 점검하기 위해 여러 대상을 정하여 로그인 상태를 유지하였다. 가정한 시나리오는 사용자가 웹 사이트에 로그인하여 패스워드를 변경하여 변경 전 패스워드와 변경 후 패스워드를 메모리 영역에서 찾을 수 있는지 여부를 점검하기 위해 해당 시나리오를 각 사이트에서 각각 다른 패스워드로 변경했다. 대표적인 브라우저인 크롬 브라우저와 인터넷 익스플로러 브라우저에서 로그인 및 패스워드 변경을 수행하였고 대상 웹 사이트는 다음과 같다.

각 사이트에 로그인 한 계정의 ID와 패스워드는 모두 동일하며 각 사이트별로 다른 패스워드로 변경하여 어느 사이트의 패스워드를 메모리 덤프를 통해 얻은 메모리 이미지에서 찾아볼 수 있는지 점검한다. 메모리 덤프를 통해 얻은 메모리 이미지로부터 각 사이트에 로그인 한 계정 정보를 찾아볼 수 있는지 여부를 점검하기 위해 위와 같은 정보를 설정했다.

2.2) 문서 암/복호화 키 (HWP)

대표적인 워드 프로세서인 Microsoft의 MS Word와 Hancom의 HWP는 모두 문서를 암호를 이용하여 암호화하는 기능을 제공한다. 암호화 된 문서가 사용자의 컴퓨터에서 열린 경우 입력된 암화 및 복호화 키는 문서 작성 프로세스의 메모리 영역에 남아있다. 따라서 메모리 덤프 후에 분석 대상 워드 프로세서의 메모리 영역으로부터 해당 문서 파일의 암/복호화 키를 추출할 수 있을 것이라고 기대할 수 있다. 이번 과제에서는 HWP 파일에 임의의 암호를 설정하여 저장하고 해당 문서를 열어 두고 메모리 덤프를 진행하였다.

2-3) 메신저 사용 내역

 국내에서 대표적으로 사용되는 카카오톡 메신저와 그 외의 텔레그램, 네이트온 메신저를 모두 실행하여 로그인하고 대화 기록을 남긴다. 메모리 덤프를 통해 얻은 이미지에서 해당 메신저의 대화 내용 및 전송한 사진 등을 찾아볼 수 있는지 점검한다. 사전에 설정한 정보는 각 메신저 애플리케이션마다 다음과 같이 설정하였다.

3. 분석

3-1) 메모리 덤프

메모리 데이터의 일부 또는 전체를 다른 저장매체에 저장하는 행위를 일컬으며 시스템 오류를 디버깅하기 위한 목적 또는 프로그램의 실행 도중의 메모리에 존재하는 데이터를 추출하기 위해 수행한다. 메모리에는 디스크에서는 찾을 수 없는 복호화 된 파일 콘텐츠나 사용자의 패스워드, 프로세스의 임시 저장 데이터 등 메모리에서만 찾을 수 있는 정보가 존재하며 메모리 덤프를 통해서 이러한 정보를 추출할 수 있다. 또한 최근 유포되는 디스크에 코드를 남기지 않고 메모리에서 바로 실행되는 파일리스(fileless) 악성코드를 분석하기 위해서 사용할 수 있다. 디지털 포렌식과 같은 범죄 수사의 관점에서 증거수집을 위해 사용할 수 있다. 메모리 덤프 방법은 크게 네 가지로 볼 수 있으며 다음과 같다.

메모리 덤프 방법에 따라 위와 같이 크게 네 개의 방법으로 나눌 수 있으며 각 방법에 따라 덤프에 사용되는 도구 또한 차이가 있다. 

다음 표가 각 방법에 따른 사용 가능한 도구와 각각의 도구의 장단점을 나타낸다.

분석 대상이 윈도우 OS 환경의 메모리 데이터이므로 윈도우에서 작동하는 도구 중 DumpIt을 사용하여 메모리 덤프를 수행했다. 

실행 후 ‘y’ 버튼 입력을 통해 쉽게 메모리 덤프를 수행할 수 있다.

3-2) 분석

메모리 덤프를 통해 얻은 이미지를 Volatility, HxD, Memoryze 등의 분석 도구를 통해 분석을 수행한다.

메모리 덤프를 통해 얻은 이미지를 분석하여 정보를 추출하기 위해 먼저 Volatility를 이용하여 대상 시스템에 대한 정보를 파악했다.

Volatility는 이미지 파일을 자동 분석하여 이미지 파일로부터 위과 같이 대상 시스템의 정보를 보여준다. 

해당 기능을 통해 얻은 정보는 사전에 시나리오를 설정하여 이미지를 획득한 환경과 일치했다.

Volatility는 이미지 파일을 분석하여 실행되고 있던 프로세스 정보를 추출해준다. 

추출해주는 정보는 해당 프로세스의 이름, PID, PPID 등의 정보를 추출해준다.

사전에 설정한 정보가 IE 브라우저, Chrome, KaKaoTalk, Telegram, NateOn에 한정되어 있으므로 해당 프로세스들에 대해서만 분석을 수행한다.

3-2-1) 메신저 패스워드

먼저 HxD 에디터를 통해 문자열 검색으로 특정 데이터들을 검색하였다. 

Password 입력 형식으로 정의될 수 있는 문자열인 ‘password’를 검색한 결과 다음과 같이 몇몇 패스워드를 찾을 수 있었다. 

해당 메모리 영역의 전후 문자열들을 통해 카카오톡 로그인 정보임을 확인했다.

‘pass’ 문자를 검색한 화면이다. 해당 메모리 영역의 전 후 문자열 데이터를 분석한 결과와 해당 패스워드 문자를 통해 유추하면 해당 메모리 영역에서 추출한 데이터는 ‘페이스북’에 로그인 한 계정 정보임을 알 수 있었다.

3-2-2) 문서 복호화 키

메모리 영역에서 HWP 파일의 암/복호화 키 검색이 가능했으며 따라서 암호화 된 문서 파일을 읽는 도중 메모리 덤프를 수행하면 해당 파일을 암/복호화 할 수 있는 키를 메모리 영역에서 얻을 수 있음을 확인하였다.

3-2-3) 메신저 사용 내역

네이트온 메신저에서 남긴 대화 내용의 텍스트 부분을 메모리 영역에서 검색을 한 결과 UTF 인코딩 형식으로 찾아볼 수 있었다.

3-2-4) 브라우저 사용 내역

URL 기반으로 메모리 영역을 탐색하던 도중 다음과 같은 메모리 영역을 찾을 수 있었다. 해당 메모리 영역에선 네이버의 로그인 페이지 URL과 변경 전의 패스워드와 변경 후의 패스워드가 모두 노출되어 쉽게 추출할 수 있었다.