TRACE

Name이 CodeEngn일 때 Serial을 구하는 문제이다.

잘못된 Serial 값을 입력하면 위 그림과 같은 창이 뜬다.

PEiD로 패킹여부를 먼저 확인했다. 확인한 결과, UPX로 패킹되어 있는 것을 알 수 있었다.

따라서 UPX 툴을 사용해 먼저 언패킹 시켜주었다.

그 결과, 프로그램에 사용된 문자열들이 보였다.

성공 문자열이 있는 곳으로 가 코드를 확인해 보겠다.

CMP로 EAX와 ESI 값을 비교한 후 JNZ 분기문을 통해서 성공/실패 문자열이 가는 곳이 나뉘어 진다. 

따라서 CMP 문이 있는 곳에 BP를 걸고 실행을 했다.

CodeEngn, 1234를 입력하고 BP를 건 곳까지 실행했을 때,

EAX에는 우리가 입력한 1234가 HEX 값으로 저장되어 있다는 것을 확인할 수 있었다.

따라서 ESI에 있는 값도 확인한 결과, 10진수로 76193이라는 값이라는 것을 알았다.

성공~

알맞은 키를 입력하면 풀리는 문제인 것 같다.

(enter[i] ^ (i % 2)) == serial[i]

이게 주요 코드인 듯 싶다.

우리가 입력한 enter 값과 (i%2)를 XOR 연산하여 serial 값과 비교하고 있다.

A^B=C 라면 A=B^C 라는 속성을 가지기 때문에

enter[i] = (i%2) ^ serial[i] 이 된다.

이렇게 소스코드를 짜면 아래와 같은 flag 값이 나온다.

OEP를 찾고 Stolenbyte까지 찾는 문제이다.

OEP를 찾는 문제이므로 패킹되어있을 가능성이 아주 높다.

PEiD로 확인해본 결과, UPX로 패킹이 되어있다. UPX로 패킹되어 있는 실행파일은 간단하게 upx 툴을 이용하여 언패킹이 가능하다.

언패킹된 실행 파일을 다시 OllyDBG에 올렸더니 

MessageBox 함수에 들어갈 인자가 모자름을 단번에 알 수 있었다.

결과는 예상대로 깨진 문자열이 나온다.

이는 unpacking시 문제가 됐을 가능성이 있으므로 unpacking 되지 않은 파일의 POPAD 명령어 부분을 확인해보았다.

POPAD 이후 스택에 적재되는 세 개의 값을 확인할 수 있었다.

OEP로 점프하는 구간에 BP를 걸고 실행시켰더니

MessageBoxA 함수 호출에 필요한 인자들이 스택에 PUSH 됨을 알 수 있고,

이를 통해 PUSH 되는 인자들이 StolenByte 임을 확인했다.

Unpacking 했던 실행 파일에서 Ctrl+E를 통해 코드 수정을 하였다.

부족한 인자를 완성 시키고 실행시켰더니 그림8과 같이 정상적으로 실행됨을 확인할 수 있다

10.exe는 Name에 알맞는 Serial을 적는 실행파일이다.

OEP 관련 문제들은 패킹과 연관이 되어있을 가능성이 높기 때문에 PEiD에 10.exe를 올려보니 Aspack으로 패킹되어있는 것을 알 수 있다.  

Aspack은 UPX와 비슷하게 처음에 PUSHAD를 통해 레지스터의 값을 넣고 디코딩 한 후 POPAD를 한다고 한다.

UPX로 패킹되어 있는 실행파일의 OEP 구하는 방법은 아래 글 참고!

https://these-dayss.tistory.com/53?category=957855

처음에 예상대로 PUSHAD 명령어가 있다. 

PUSH 명령어 실행 후 스택에 Break Point를 건다.

BreakPoint를 건 곳까지 실행하면 [그림 6]과 같이 POPAD 후, JNZ 구문에 의해 분기가 일어난 후 특정주소(00445834)를 PUSH 하는것을 알 수 있다. 이 주소가 바로 OEP 주소라고 할 수 있다.

OEP 주소로 이동해보니 디버거가 OPCODE를 제대로 인식하지 못하고 있다. 이런 경우, 덤프를 해줘야한다고 한다.

OllyDump 툴을 사용하여 OEP를 수정한 후 덤프를 떠준다.

(Immunity Debugger는 따로 덤프 툴이 없어서 OllyDBG로 변경)

해당 주소를 찾아가보면 OPCODE는 75 55 임을 확인할 수 있다.

다짜고짜 password를 묻는다

처음에 그냥 실행해봤고

예상대로 Sorry~ 문자열이 나왔다.

실행하자마자 텍스트를 확인해봤다

[마우스 오른쪽]-[Search For]-[All referenced text strings]를 통해 확인이 가능하다

DonaldDuck이라는 문자열이 눈에 띄어서 Username이라고 짐작했다

BP를 건 후 [F9]키로 실행해주었다

Username과 Password를 입력하라고 하여서 

Username에 DonaldDuck, Password 자리에 1234를 적어주었다

그러고 나니 003E1008 위치에 DonaldDuck이 뜨는 것을 확인할 수 있었다

우리가 만난 첫 번째 분기문에선

우리가 입력한 Username의 첫 번째 자리와 0x00(NULL값)을 비교한다는 것을 알 수 있다

우리는 Username에 값을 입력했기 때문에 

JNE 명령어로 인해 003E1030 주소로 바로 이동하게 된다

다음으로 만난 CMP 문이다

CMP EAX, DWORD PTR DS:[ECX] 부분에서 우리가 입력한 password값과 ecx값을 비교하고 있다

HEX 창에서 ECX 주소로 가보니 0088228F라는 값이 적혀있다

이는 16진수이므로

10진수로 바꿔주면 8,921,743이 된다

password가 8921743일 것이라고 예상할 수 있다

앞에서 예상은 했지만 입력한 Username과 'DonaldDuck' 문자열을 비교하는 구문이 있는 것을 확인할 수 있다.

따라서 Username이 DonaldDuck이라는 것이 확실해졌다

Name이 CodeEngn 일때 Serial이 무엇인지 맞추는 것이다

EP Section이 올바르게 나오고 컴파일 환경도 나오는 것을 보니 패킹이 되어있지 않은 실행파일이라고 판단했다

아직 아무것도 모르는 상태이기에 

Hello 라는 문자열을 적었고

예상대로 Fail 창이 떴다

코드를 쭉 내려보다가 lstrcmpA라는 함수가 보였다.

lstrcmpA 함수는 Window32 API로, 두 문자열의 대소 관계를 비교하나
일반적으로 두 문자열이 같은지 다른지를 비교할 목적으로 많이 사용한다.
단순히 문자열의 동등성 여부만 판단할 경우는 리턴값이 0인지 아닌지만 점검하며 대소 관계를 판단할 때는 리턴값의 부호를 점검하면 된다.
영문자를 비교하는 경우 대소문자도 비교하므로 대소문자 구분없이 비교하려면
CharUpper 등의 함수로 모두 대문자로 바꾼 후 비교하거나 아니면 lstrcmpi 함수를 사용해야 한다.

여기에 내가 입력했던 Hello 문자열과 어떤 숫자를 비교하는 걸 확인했고

이를 그대로 넣어주니 succeeded 메시지가 떴다

◎ 퍼저? 퍼징을 수행하는 도구

◎ 퍼징? 소프트웨어 보안 테스트 기법으로, 프로그램에 무작위 데이터를 입력하여 오류를 분석하고 취약점을 파악

- 인터페이스나 프로그램에 일부러 부적절한 데이터나 랜덤 데이터를 주입시켜 시스템 마비를 유발하는 것. 이 과정에서 메모리 유출이나 문서로 기록되지 않은 반응들, 디버그 절차, 코드 입력실패 등이 발생할 수 있는데 이걸 잡아내는 게 목적이다.

◎ 특징

1. 입력값의 무작위성 ; 랜덤 숫자, 랜덤 텍스트, 키보드 및 마우스 이벤트 등

2. 단순 신뢰기준 ; Crash, Hang 시 실패로 간주하며 그 외는 통과시킴

3. 자동화 ; 자동화된 툴(Fuzzer)을 통한 무한 반복 테스트 가능

◎ 장단점

장점 : 알려지지 않은 취약점을 사전에 탐지할 수 있다 / Zero-Day 공격에 대응할 수 있다

단점 : 무작위성에 의존한다 / 단순한 결함 탐지 위주로 심각한 취약점을 찾아내긴 어렵다.

◎ 테스트 분야

- 웹 브라우저, 응용 프로그램, 네트워크 프로토콜, 파일 포맷, 메모리, 커널 등

◎ 방법

1) 퍼저 실행

2) 영향력의 범위와 시스템 마비 현상 확인

(한 프로그램에서 취약점을 찾고 싶다면 대상 바이너리와 시드파일 즉, 이미지 파일들이 필요)

3) 왜 그런 현상들이 발생했는지 조사

4) cmin 프로세서 시작

5) 1~4의 과정 반복

◎ 퍼징을 위한 input data를 어떻게 정하는지에 따라 두 가지 방식으로 나뉨

1. Mutation

- Mutation (Dumb Fuzzers) : 변이 기반 퍼징

- 주어진 입력 값을 마구잡이로 이리저리 바꿔가면서 새로운 입력 값을 만들어 냄

(데이터의 특정 영역의 값들을 임의로 바꿔치기(replacing)하거나 추가(appending)함)

- 데이터 형식이나 구조에 대한 명확한 이해가 어려울 때 사용한다.

- Mutation 기법 중 하나인 Bit Flipping은 특정 비트를 일정한 주기 또는 무작위로 바꿔버리는 것

2. Generation

- Generation (Intelligent Fuzzers) : 파일의 포맷(형식)이나 프로토콜(규약)을 이해하고 그것에 맞추어 적절한 input을 생상하는 방식

- 밑바닥부터 철저히 구현해야 함

- 대표적인 Smart 퍼저는 Peach Fuzzer 이다.

◎ 관련 기사 : https://www.boannews.com/media/view.asp?idx=75607

- 요약 : 보안 전문가들이 흔히 사용되는 윈도우용 퍼징 프레임워크 윈AFL(WinAFL)을 50일 동안 사용하여 어도비 리더(Abode Reader) 프로그램에서 53개의 새로운 취약점들을 찾아냈다.

퍼징은 귀찮은 방법이라 보안 전문가들이 대게 기피하는 방법이지만 인공지능을 탑재한 자동화 기술을 접목시키면 효과적인 취약점 발굴 방법이 될 수 있다.

◎ 퍼저의 구성요소

1. TestCase Generator : 타켓 프로그램에 삽입할 입력을 만듬

2. Logger : 퍼징을 돌리는 중에 버그 분석에 필요한 정보를 기록

3. Worker : 주어진 입력으로 예기치 않은 동작을 인식

4. Server/Master : 1,2,3을 컨트롤하고 상호작용 관리

◎ 퍼징 구현 예시 : https://blog.naver.com/stop2y/221108894553

StolenByte

▶ 패킹된 바이너리를 언패킹할 때의 과정을 방해하기 위한 방법으로, 프로그램의 일부 바이트를 별도의

영역에서 실행되게 하여 OEP를 다른 위치로 가장하고 덤프를 쉽게 하지 못하도록 구현한 기법

▶ 패커가 패킹을 진행할 때, 원본 코드 중 일부를 다른 곳으로 이동 시킨 코드로써, 주로 EP 위의 몇 줄의 코드이다

 ※ 올바른 프로그램을 얻기 위해서는 패킹 과정에서 떼어진 StolenByte를 함께 복원해야 덤프가 성공적으로 이루어진다

unpacking 후 디버거로 열었을 때, 처음에 NOP로 덮어진 부분이 눈에 띄었다.

첫 번째로 실행되는 MessageBoxA 함수에 전달할 인자가 부족함을 알 수 있었고

이를 실행했을 때, 온전하지 못한 글자들과 함께 결과가 보여짐을 확인할 수 있었다.

이를 통해 부족한 인자들이 문제와 연관있음을 예측했다.

unpacking 시 stolenbyte 문제가 생긴다는 것을 깨달은 후,

다시 원본 실행 파일에서 POPAD 부분을 찾아갔다.

(POPAD 찾는 방법은 아래를 확인)

2021.04.07 - [Study/Reversing] - CodeEngn Challenge : Basic RCE L06

그리고 POPAD 이후 스택에 적재되는 세 개의 값을 확인할 수 있었다.

OEP로 점프하는 구간에 BP를 걸고 실행시켰더니

MessageBoxA 함수 호출에 필요한 인자들이 스택에 PUSH 됨을 알 수 있고,

이를 통해 PUSH 되는 인자들이 StolenByte 임을 확인했다.

따라서 stolenbyte는 6A0068002040006812204000 이다.

문제에서 packing이 된 실행파일이라는 것을 알려주고 있다.

+) PEiD는 파일의 PE 정보로 패킹, 암호화, 컴파일에 사용된 프로그램을 찾아준다.

실행파일을 올려 확인해 보니 UPX 프로그램으로 패킹됐음을 유추할 수 있다.

<Packing & UnPacking 설명 참고>

더보기

패킹(packing)은 "실행 압축"이라고 표현할 수 있다.

실행 파일 내부에 있는 코드를 압축하여 평소에는 코드를 압축한 상태로 저장하고 있다가

파일을 실행하면 메모리에서 압축을 해제 시킨 후 파일을 실행시키는 기술이다.

 

장점

1. 파일의 크기를 줄일 수 있다.(전 후 3~4배의 차이가 있다)

2. 크래커의 리버싱으로부터 보호할 수 있다.

 

---

언패킹(unpacking)은 말 그대로 패킹을 푸는 것이다.

특히 UPX Compressor를 사용하는 경우는 아래의 상황이다.

- UPX 기준 설명

1. 운영체제의 Loader가 실행파일을 메모리에 올린다

2. Packing된 파일은 Unpacking Code 시작부분이 Entry Point이다.

3. EP에서 프로그램이 시작된다.

4. Packing된 파일은 Unpacking Code 영역에 들어있다.

5. Unpacking Code는 패킹된 데이터를 하나씩 읽어 압축을 풀고 Empty Space(빈 공간)에 원래 데이터를 저장한다.

6. 모든 코드가 Unpacking 되었다면 Original Entry Point(OEP)에서 프로그램이 다시 시작된다.

 

즉, OEP는 Unpacking 되기 이전 실행파일의 시작점이다

<UPX로 패킹된 실행파일을 unpacking 하는 방법>

1. upx 프로그램의 -d 옵션 사용

-d 옵션을 사용하면 패킹된 파일을 언패킹한 후 덮어 씌울 수 있다.

그 후 디버거에 올려서 실행하면 바로 OEP를 알 수 있다.

2. PUSHAD/POPAD 명령어 찾기

- UPX는 실행 파일 압축 프로그램으로 함수를 계속 진행하면 OEP에 도달할 수 있다.

UPX는 PUSHAD와 POPAD를 활용해 언패킹한다.

PUSHAD는 범용 레지스터의 값들을 스택에 저장하며, POPAD와 짝을 이루어서 사용된다.

코드의 PUSHAD가 진행되면 범용 레지스터의 값들을 EAX, ECX, EDX, EBX, ESP, EBP, ESI, EDI 순서로 스택에 저장한다.

POPAD는 스택에 저장된 레지스터 값들을 다시 레지스터에 입력한다.

보통 POPAD 밑에 점프문이 있으며 이 점프문 주소에 해당하는게 OEP인 경우가 많다.

① PUSHAD를 지나 마지막 레지스터 값(EDI)이 스택에 저장되었을 때,

② 그 스택부분에 BP(Break Point)를 걸면

③ POPAD에서 마지막 레지스터(EDI)를 복구시킨 후 정지된다. (스택 BP 사용시 해당 스택의 데이터가 접근 되는 시점에 브레이크가 잡히게 된다.)

④ 마지막으로 , POPAD가 끝난 후 진행되는 코드를 진행하면 원본 시작 코드로 진입할 수 있다.

각 레지스터에 값이 저장되어 있고 마지막으로 PUSH 되었던 EDI의 주소로 가 스택에 저장된 값을 확인한다.

이 점프문 주소(00401360)에 해당하는 게 OEP 이다.

문제는 OEP 뿐만이 아니라 Serial 값을 찾도록 요구하고 있다.

따라서 이 실행파일을 unpacking 한 후 다시 분석해보았다.

잘못된 값을 입력했을 때 GUI 모드로 'Wrong serial!'이라는 문자열이 떴기 때문에 

프로그램에 사용된 문자열들을 확인한다.

'You got it' 이라는 문자열 코드가 있는 부분을 선택해 주변을 살펴보았다.

CMP 문과 JMP문이 사용된 것으로 보아 내가 입력한 값과 정답 serial 값을 비교해 

성공인지 실패인지를 가려내어 결과를 보여주는 것으로 보인다.

JMP문에 [F2]키를 사용해 BP를 걸고 [F9]키를 사용해 실행한다.

내가 입력한 값이 어디론가 PUSH 되고 있다.

아마 그 다음에 나오는 "AD46DFS547"이라는 값과 비교하여 결과가 나뉘는 것 같다.

따라서 정답 serial 은 "AD46DFS547" 이라고 유추 가능하다.

분석 패킷 : http-fault-post.pcap

초기 3방향 핸드셰이크가 끝나면 클라이언트(24.4.97.251)는 웹서버(216.23.168.114)로 HTTP 패킷을 보낸다.

여기서 사용된 POST 메소드는 URI /flashmail.asp 와 HTTP/1.1의 HTTP 버전을 지정한다.

POST 요청을 통해 보내진 데이터를 확인하려면 HTML Form Encoded 부분을 보면된다.

구체적으로 어떤 에러 메시지를 주는지 확인하기 위해 

와이어샤크의 Export Objects 기능을 이용하여 403 응답을 보내는 페이지를 저장한 후 확인해보았다.

403.1 에러로 실행 액세스가 금지된 것임을 확인할 수 있었다.

더보기

- 여러 403 하부 오류 코드

사진 출처 : 나무위키 namu.wiki/w/403%20Forbidden