'악성코드분석'에 해당되는 글 9건

1. 레나튜토리얼 1번 문제 분석

[그림 1-1] 코드 분석 - 1

먼저 GetModuleHandleA는 모듈 핸들을 호출할 때 쓰이는 함수다. 두번째로 LoadIconA는 아이콘을 호출할 때 쓰이는 함수이며 LoadCursorA는 커서를 호출할 때 쓰이는 함수다. A는 아스키 값을 의미하는데 이 부분에선 각 함수가 어디에 쓰이는지 파악해야 한다.

[그림 1-2] 코드분석 - 2

CreateFileA 함수쪽 라인에 BP를 건다. BP를 걸었기 때문에 실행시켜도 CreateFileA 함수 라인에서 멈추게 된다. 파일이 생성되면서 그에 따른 인자값들이 전달되는데 Mode=OPEN_EXISTING은 만약 어떤 파일이 존재하면 연다는 의미다. 현재 코드 흐름으로 봐선 Keyfile.dat 파일이 존재하면 연다는 의미로 추측해볼 수 있다.

[그림 1-3] 코드분석 - 3

F8을 눌러 실행해보면 EAX 값과 -1을 비교하는 구문이 있다. 레지스터에선 EAX 값은 FFFFFFFF로 표시된다. 컴퓨터엔 -1이라는건 존재하지 않기 때문에 FFFFFFFF로 표시되는 것이다. 아직 여기선 EAX 값에 대해 알 수는 없는 상태다.

[그림 1-4] 코드분석 - 4

비교 구문에서 다시 F8을 눌러 실행해보면 제로 플래그 구문이 실행되고 Z 값이 1이면 MessageBoxA 함수를 실행하고 있는 상태다.

[그림 1-5] 코드분석 - 5

제로 플래그가 1인 상태에서 한번 더 실행하면 뭔가 종료를 알리는 메시지 경고창이 출력된다. 

[그림 1-6] 코드분석 - 6

코드를 재실행 한 후 제로플래그를 0으로 변환한 후 실행하면 ReadFile 함수가 있는 라인으로 점프하게 된다. 단 여기서 CreateFileA 함수가 정상적으로 실행되었다는 가정하에 진행해야 한다.

[그림 1-7] 코드분석 - 7

ReadFile 함수에서 F8을 눌러 실행해보면 EAX와 EAX를 비교해서 테스트한다. 이 때 테스트는 EAX 값이 00000000임을 확인하기 위함이다.

[그림 1-8] 코드분석 - 8

F8을 두번 눌러 실행한 후 제로플래그가 1인지 확인한다. 

[그림 1-9] 코드분석 - 9

JMP 함수에서 제로 플래그가 1인 상태에서 F8을 실행하면 해당코드로 이동된다. 현재 코드를 실행하면 Text 내용이 담긴 메시지 박스가 출력되며 Key File이 없으면 프로그램이 종료된다.

[그림 1-10] 코드분석 - 10

코드를 재실행해서 JNZ까지 실행한 후 제로 플래그를 0으로 바꾼다. JMP 함수 바로 아래에 나오는 코드들은 Keyfile이 있어야 실행이 되는건데 제로플래그를 0으로 바꾸면 JMP 함수를 우회할 수 있다.

[그림 1-11] 코드분석 - 11

실행 결과 KeyFile이 존재할 때 출력되는 메시지 경고창이 담긴 코드로 점프되었다. 이는 JMP 함수의 제로플래그 값을 바꿔 KeyFile 우회가 가능한 불법프로그램임을 알 수 있다.

1. 어셈블리어란?

CPU의 기계 언어와 1:1 매칭이 되는 저급 언어의 일종이다. 어셈블리어 명령 하나가 기계어와 매칭이 된다고 해서 1:1 구조라고 일컫는다. 어셈블리어는 사람이 읽기 쉽게 기계어에서 변환이 된 언어라고 볼 수 있으며  CPU에 접근할 수 있고 주로 하드웨어쪽과 소통하기 위해 쓰이는 경우가 많다.

2. 어셈블리어 명령어 기초

[표 1-2] 어셈블리어 기초

※ 참고: 2020년 국가인적자원개발컨소시엄 침해대응 과정 교재

https://wooeong.tistory.com/entry/리버싱-기초-지식-어셈블리어Assembly

가장 많이 사용되고 기초적인 어셈블리어다. 리버싱을 할 때도 기초적인 어셈블리어를 숙지하고 있어야 분석이 되는 경우가 많다.

3. 조건 분기 종류 및 특징

[표 1-3] 자주 쓰이는 조건 분기문

※ 출저: https://wooeong.tistory.com/entry/리버싱-기초-지식-어셈블리어Assembly

리버싱을 할 때 가장 많이 쓰이는 조건 분기문을 추려 정리한 것이다. JZ, JE는 자주 등장하는 명령어기 때문에 잘 숙지해놓는 것이 좋다.

4. 어셈블리어의 자료형 

[표 1-4] 어셈블리어의 자료형 참고

※ 출저: https://wooeong.tistory.com/entry/리버싱-기초-지식-어셈블리어Assembly

리버싱을 하거나 악성코드 분석을 할 때 자주 보이는 것들 중 하나가 자료형들이다. 부호가 없는 표현이며 모두 기초적인 부분이니 잘 참조하면 좋다.

5. 함수 호출 및 리턴 주소 구조

[그림 1-2] 함수 호출 구조

※ 사진 출저: 보안프로젝트

먼저 push 함수를 통해 값들이 스택에 계속 쌓인다. HelloFunction 함수 호출 시 뒤에서부터 값들을 스택에서 하나씩 불러온다. 그렇게 스택에서 불러온 값들을 아래에 있는 로직으로 전달해서 최종 값을 산출하게 되는 것이다. 여기서 중요한 것은 스택에 대한 이해다.

1. 올리디버거

- 올리 유스척이 개발한 x86 디버거로 무료

- 사용 편의성과 기능 확장을 위한 플러그인도 탑재 되어 있음

- 보통은 32비트 환경에서 동작하지만 64비트 환경에서도 동작이 가능하게 됨

- 1.1과 2.0이 출시되었지만 1.1은 64비트 디버깅이 잘 되지 않아 2.0과 사용해야함

- 2.0도 버그가 존재해서 안정적이지는 않음

- 1.1이 계속 리버서들이 쓰는 이유는 다양한 플러그인이 계속 지원되고 있기 때문임

- 그래서 이뮤니티 시큐리티에서 Olly dbg 1.1 베이스를 구매해 Immunity 디버거로 재포장함, 재포장함으로써 가지는 장점은 다음과 같음

* 파이썬 인터프리터의 추가

* 익스플로잇 개발자에겐 최적화됨

* 올리디버거 자체 버그가 패치됨

2. 올리디버거 인터페이스 

[그림 1-1] 올리디버거 구조

올리디버거는 CPU 명령어 화면, 레지스터 창, 메모리 덤프 창, 스택창으로 크게 4가지로 구분된다. 

- CPU 명령어 화면의 맨 왼쪽은 주소를 나타내며 두번째는 머신 코드, 세번째는 어셈블리어가 나타난다. 머신 코드는 CPU가 읽을 수 있는 코드이며 어셈 블리어는 인간이 읽을 수 있게 번역된 코드다. 보통 분석을 할 땐 어셈 블리어와 주소를 보며 분석을 하게 된다.

- 레지스터 창은 맨 우측에 표현되어 있으며 레지스터, 플래그에 대한 정보를 보여준다. 이는 프로그램을 실행시켰을 때 CPU 내부의 레지스터 안에 저장된 정보를 보여주는 것이다.

- 메모리 덤프 창은 왼쪽 하단에 위치해 있으며 말 그대로 메모리에 관련된 내용 및 주소 등을 볼 수 있다.

- 스택 창은 오른쪽 하단에 위치해 있으며 PUSH가 되면 스택 데이터가 계속 쌓이고 POP이 되면 스택 데이터가 빠지게 된다. 이 부분을 통해 원하는 주소의 스택 영역 값들을 확인할 수 있다.

3. 올리디버거 코드 실행 옵션 정리

[표 1-1] 자주 쓰이는 올리디버거 옵션

1. CPU가 사용하는 레지스터 종류(32비트)

2. 올리디버거를 활용한 레나 1번 문제 간단 분석

[그림 1] 올리디버거 실행

올리디버거 실행 후 레나튜토리얼의 reverseMe 파일을 불러온다. 만약 올리디버거에 파일을 불러오게 되면 어셈블리어 형태로 나타난다. 

[그림 2] 코드 분석 - 1

현재 시작 메모리 주소를 보면 00401000이며 PUSH에 0을 넣고 함수를 호출하고 있다. LoadIconA에 PUSH 4, PUSH EAX가 있는 것으로 보아 인자가 2개가 필요하다. 아래 LoadCusorA도 PUSH 7F00, 0이 있어 인자가 2개가 필요함을 파악할 수 있다.

[그림 3] 코드 분석 - 2

CreateFileA 함수는 총 7개의 인자가 필요하며 파일 생성 함수임을 알 수 있다. 또한 MessageBoxA 함수는 총 4개의 인자가 필요하며 메시지 박스 함수 임을 알 수 있고 ExitProcess는 모든 프로세스가 종료되는 함수다.

[그림 4] 코드 분석 - 3

프로그램 하단의 메모리 주소 덤프 값에서 주소, 아스키 값을 알 수 있다. 현재 프로그램이 실행되기 전의 스택 값을 확인해보면 0012FFC4다.

[그림 5] 코드 분석 - 4

F8을 눌러 코드를 실행하면 스택 주소 값은 0012FFC0으로 변환되고 EIP 값도 00401002로 변환되었음을 볼 수 있다.

[그림 6] 코드 분석 - 5

F8을 눌러 코드를 한번 더 실행하면 스택 주소 값은 0012FFC4로 다시 복귀되며 스택 값도 7C816037로 정리된다. 또한 00401007의 메모리 주소가 실행 됨에 따라 EAX로 전달되어 MZP라는 데이터를 반환하고 있다.

1. UPX(Ultimate Packer for executables)

- 여러 운영체제에서 많은 파일 포멧을 지원하는 오픈 소스 실행 파일 압축 프로그램

- 압축 및 해제 모두 가능함

2. 패킹 관련 사항

* UPX0, UPX1, .rsrc 총 3가지로 구성됨

* Section UPX0 : 메모리에 로드된 후 압축코드가 해제 될 공간

* Section UPX1 : 압축코드가 저장되는 공간

3. UPX 언패킹

upx 프로그램을 사용해서 MsgBox.exe 파일을 언패킹을 시도한다. 언패킹에 성공하면 기존 파일 사이즈가 많이 줄어 들었음을 알 수 있다.

PEView 프로그램에 언패킹된 파일과 언패킹 되지 않은 파일을 올려서 비교해보면 벌써 내용이 달라졌다는 것을 확인할 수 있다. 여기서 중점적으로 봐야할 것은 SECTION .rdata 부분인데 원본 파일에서는 존재하지만 언패킹된 파일에선 존재하지 않는다. 

이번 실습은 MP3 플레이어 컨버터를 이용한 Exploit을 한다. 최종적으로 올리디버거를 이용해 계산기를 출력하는게 목표다.

* 컨버터 실습 *

모나를 실행시켜 !mona pattern_create 10000을 입력해서 패턴을 만든다.

만들어준 패턴을 보기 위해 immunity Debugger 아이콘 오른쪽을 클릭해 properties를 실행시켜 find target을 실행시켜 모나를 실행시켜 만든 pattern을 찾는다. 패턴을 찾은 후 10000개의 문자열을 복사한다.

계산기 소스에 payload에 20000 + 옆에 문자열들을 붙여 넣는다. 이름은 test라고 저장한다.

mp3 컨버터로 test를 실행시켜주면 오버플로우가 발생하게 된다. debug버튼을 눌러 올리디버거와 연결시킨다.

올리디버거를 실행시키면 EIP에 34754833이라고 나오면 정상이다. 이 값을 복사한다.

모나를 실행시켜 offset 뒤에 복사한 값을 붙여넣어서 실행시키면 포지션은 6071이라는 값이 나온다. 최종적으로 만들려는 버퍼 길이는 26071이 된다.

\x90은 사실상 아무것도 하진 않는다. 하지만 주소값을 buf쪽에 전달하는 역할만 한다. RET가 주소값을 리턴시키면 \x90을 거친 후 buf라는 곳으로 주소값이 전달되어 계산기가 실행되게 된다. 

test1을 mp3컨버터로 실행시켜보면 스택쪽을 보면 주소값을 어디로 리턴시켜줄지 찾아야 되는데 일단은 90909090으로 반복되는 부분 거의 끝에 해당하는 값을 찾는다. 오버플로우가 나지 않는 선에서 스택값을 찾아야 한다.

0x00FFD80값으로 바꿔주고 test2로 저장한다.

test2를 MP3 컨버터를 활용해서 실행시켜보면 계산기가 화면과 같이 실행된다. 이처럼 오버플로우를 이용하고 offset값을 찾아 RET를 잘 이용해주면 이런식으로 프로그램을 실행할 수 있다.

BOF 기초에서는 어디서 오버플로우가 나는지 알고 실습을 했었는데 이번에는 아예 모르는 상태에서 어디서부터 오버플로우가 발생하는지 알아보는 실습이다.

먼저 올리디버그에 접속해서 just in time debugging을 클릭해서 사진과 같이 2개만 활성화 시켜준다.

그리고 Immunity Debbug를 열어서 mona를 실행시켜 !mona pattern_create 120을 입력해준다. 보통 패턴은 100이 넘어갈때 많이 발생하니 120정도면 딱 적당하다.

Immunity Debbug 아이콘 오른쪽을 클릭해 find target을 눌러 만든 패턴에 대해 열고 문자열들을 그대로 카피해준다.

그리고 cmd창을 열어 지난번에 만들었던 BOF를 열어 그대로 문자열들을 붙여넣어주면 오버플로우 메시지가 나오게 된다. 여기서 Debug를 눌러준다.

그렇게 되면 EIP에 41366441이라는 숫자가 뜨게 되는데 이 EIP값을 그대로 복사해준다.

그리고 mona를 실행시켜 !mona pattern_offset  뒤에 방금 복사한 숫자를 붙여넣어 실행시켜 주면 된다. 실행결과를 보면 position 108이라고 메시지가 나와 있는데 여기서부터 오버플로우가 발생한다는 의미이다. 이런식으로 offset을 찾아서 어디부터 오버플로우가 발생할 수 있는지, 취약점이 발생할 수 있는지 정확하게 알 수 있다.

이번엔 간단한 BOF실습이다. 인터넷에 돌아다니다 보면 코드가 많이 떠다닌다. 일단 C언어로 BOF를 작성했다.

버퍼에 100개이상이 채워지면 오버플로우가 발생하게 되는 코드이다. 이 코드를 실행시켜 준다.

그리고 cmd창을 띄워서 실행시켜보면 A가 100개가 정확히 들어갔을 때는 오류메시지가 나오지 않지만 그 이상을 넘어갔을시엔 사진과 같은 오류가 발생했다. 현재 DDDD까지 채워져 스택프레임이 초과된 상태이다. 그리고 Debug를 눌러보면 올리디버거로 연결이 된다.

이런식으로 올리디버거 결과값을 보면 레지스터 값에 EIP값이 전부 DDDD로 덮였음을 볼 수 있다. 현재 이 스택프레임은 DDDD로 전부 덮여버린 상황이다. 4444444는 DDDD를 의미하며 아스키코드로 D는 44이다. 이렇게 버퍼오버플로우가 발생하게 되면 RET취약점이 바로 발생할 수 있기 때문에 strcpy와 같은 C언어 코드는 되도록이면 피하는 것이 좋다.