1. 문제확인





Mommy told me to make a passcode based login system.

My initial C code was compiled without any error!

Well, there was some compiler warning, but who cares about that?


문제를 대충 해석해보면, 

엄마가 패스워드 넣는 로그인시스템을 만들어보라고 말했어~

내 초기 C코드는 에러없이 컴파일이 되었지!

뭐 워닝이 쫌있긴했는데 누가신경쓰겠냐? 라고 하고 있습니다.


우선 주어진 접속정보로 서버에 접속해서 passcode.c를 봐야겠네여



2. 문제 코드 분석


아래는 문제로 주어진 passcode.c에여


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
#include <stdio.h>
#include <stdlib.h>
 
void login(){
    int passcode1;
    int passcode2;
 
    printf("enter passcode1 : ");
    scanf("%d", passcode1);
    fflush(stdin);
 
    // ha! mommy told me that 32bit is vulnerable to bruteforcing :)
    printf("enter passcode2 : ");
        scanf("%d", passcode2);
 
    printf("checking...\n");
    if(passcode1==338150 && passcode2==13371337){
                printf("Login OK!\n");
                system("/bin/cat flag");
        }
        else{
                printf("Login Failed!\n");
        exit(0);
        }
}
 
void welcome(){
    char name[100];
    printf("enter you name : ");
    scanf("%100s", name);
    printf("Welcome %s!\n", name);
}
 
int main(){
    printf("Toddler's Secure Login System 1.0 beta.\n");
 
    welcome();
    login();
 
    // something after login...
    printf("Now I can safely trust you that you have credential :)\n");
    return 0;    
}



2-1) main()

프로그램 실행에 필요한 인자는 특별히 없어보이네여?

가장 먼저, Toddler`s Secure Login System 1.0 beta. 라는 문자열을 출력한 후

welcome, login을 순차적으로 호출 하고

Now I can safely trust you that you have credential :) 출력해주면 프로그램이 끝나고있어여


2-2) welcome()

welcome함수에서는 이름을 입력받기위해 char 배열 100바이트짜리가 하나 선언이 되어 있어여

enter you name : 에 맞추어 이름을 입력하면,

Welcome [입력한 이름]! 을 출력해줍니다. 여기서 %100s로 100바이트만 받는 다는 점만 인지해두세여


2-3) login()

login 함수에서는 패스워드를 입력 받고 인증에 성공하면 플래그를 읽어주는 의도로 만들고 싶었던 것 같은 소스를 볼 수 있어여

꼼꼼하신 분이라면 바로 이상한 점을 아실 수 있겠져? scanf에서 입력을 받는 변수에 &가 빠져있어여 ㅠㅠ

그리고 리눅스에서는 제대로 동작 하지 않는 것으로 알고 있는뎅, passcode1을 입력 받은 다음 입력버퍼를 날려주는 fflush()를 호출하고 있어여


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
void login(){
    int passcode1;
    int passcode2;
 
    printf("enter passcode1 : ");
    scanf("%d", &passcode1);
    fflush(stdin);
 
    // ha! mommy told me that 32bit is vulnerable to bruteforcing :)
    printf("enter passcode2 : ");
        scanf("%d", &passcode2);
 
    printf("checking...\n");
    if(passcode1==338150 && passcode2==13371337){
                printf("Login OK!\n");
                system("/bin/cat flag");
    }
 
    else{
        printf("Login Failed!\n");
        exit(0);
    }
}



원래 의도를 예상해서 코드를 수정해보면 이처럼 바꿔볼 수 있겠져?
scanf에서 변수를 저장할 때는 이렇게 해당 변수의 주소값을 인자로 넣어줘야돼여 아마 문제에서 언급했던 워닝은 여기서 났겠네여
게다가 패스워드를 입력받아 저장 하려고했던 passcode1과 passcode2는 초기화 과정을 거치고 있지 않기 때문에 garbage값이 들어 있을꺼에여
결과적으론 이 가비지 값을 주소로 읽어서 거기다가 입력값을 쓰게 될 꺼에여


3. 디버깅


3-1) main()


2-1) 에서 살펴봤듯이 별내용은 없어 보이네여 printf를 실행하기 위한 put을 각각 호출 하고, welcome과 login을 순차적으로 호출하네여?


움..참고로 이번에 알게된 건데 문제서버에서 peda를 사용하고 싶으면 gdb를 실행한 후 source /usr/share/peda/peda.py를 쳐주면 peda가 실행되여ㅠ 넘나 편한 것..


3-2) welcome()

여기서부턴 자세히 봐야 할 부분이 있어여

맨처음 함수 인트로에 해당하는 스택프레임 부분이 +0과 +1라인에서 이루어지고 있어여

바로 다음 +3라인에서는 소스에서 살펴봤던 login함수 내 지역변수인 name[100]을 위한 공간확보를 하고 있네여

0x88만큼 스택을 확보했으니까 dummy까지 합쳐서 136바이트를 확보한 것을 알 수 있져?



실행을 해서 확인을 해보도록 하져



welcome+9에 브레이크 포인트를 건 멈춘 모습이에여

ebp는 0xffb771e8, esp는 0xffb77160으로 (0xffb771e8 - 0xffb77160)0x88만큼 스택 공간이 확보되어있는 것을 확인해 볼 수 있어여

여기까지의 스택 상황을 한번 그려본다면 아래처럼 되겠져?


welcome+48에서 scanf을 호출해서 입력을 받고 welcome+68에서 print를 해주는 부분을 분석해서 정확한 더미부분과 name변수의 공간을

확인해 봅시당!

welcome+68에서 브레이크를 걸고 진행을 해보면,

0xffde9198에 입력한 값(저는 JSBach를 입력했어여)이 위치하고 있는 것을 알 수 있어여, 이 정보를 가지고 스택을 다시 그려보져


확보 된 0x88(136)사이즈가 이처럼 사용되고 있다는 것 까지 알아냈습니다. welcome에서 볼 수 있는 사항은 여기 까지구 login을 보면서

이 내용을 어떻게 써먹을 지! 확인을 해보면 되겠습니당



3-3) login()

login함수도 역시 스택프레임을 구성하는 것으로 시작하고있어여 그리고 passcode1과 passcode2를 위한 공간을 확보하고있져?

0x28만큼 확보하고 있네여 login+6에 브레이크를 잡고 자세히 한번 살펴봅시당



ebp가 0xffde9208이고, esp가 0xffde91e0기때문에 0x28(40바이트)만큼 공간이 확보된 것을 알 수 있습니다.

위와 같이 스택을 똑같이 그려보면?

요렇게 그려 볼 수 있겠져? 근데 잘보면 ebp가 welcome함수랑 똑같아여

welcome함수 콜 후에 바로 login함수를 콜 했기 때문에, 당연한 것일 수 있지만 이게 실마리입니다.


우선 0x28공간이 어떻게 구분되어지는지 확인을 해봐야겠져!

passcode1을 입력을 받는 login+34부분에 브레이크 포인트를 걸고 한번 봅시당


scanf에서 사용하는 첫 번째 인자인 %d가 스택 최상단에 있고, 바로 아래 passcode1가 있겠네여?

이 passcod1의 값을 어떻게 가져왔는지 scanf 호출 전(login+24, +27)을 보면 알 수 있어여


mov edx, DWORD PTR[ebp-0x10]            // edx에 ebp-0x10의 주소에 있는 값을 대입

mov DWORD PTR [esp+0x4], edx            // esp+0x4의 주소에 edx값을 대입


즉, ebp-0x10 -> 0xffde9208 - 0x10 = 0xffde91f8에 있는 값을 가져다가 쓴다는 게 되는거져

아까 welcome에서 봤던 스택 모습을 한번 더 볼까여?


ebp는 welcome과 login이 동일하게 0xffde9208을 쓰고있습니다.

그래서 ebp-0x10 의 위치라면! ebp로부터 16바이트가 떨어진 곳의 값이 되겠네여, 그럼...

name입력에서 끝 4바이트가 된다는 것을 알 수 있습니다.


요기까지 상황을 정리해보겠습니당!


1. scanf에는 메모리에 쓰고싶은 곳의 포인터를 넘겨준다.

2. 그런데 개발자가 실수로 & 기호를 빼먹어서 변수에 있는 값을 포인터로 사용하게되었다.

3. 그 변수에 있는 값은 앞의 함수에서 입력한 값의 영향을 받는다.


이름을 입력할 때 마지막 네 바이트에 입력하고 싶은 메모리 번지를 넣고 그 다음 scanf에서 값을 쓰면

원하는 메모리번지에 값을 넣을 수 있다! 라는 결론 까지 올 수 있습니다.


한번 확인한 사항이 맞는지 테스트 값을 넣어서 확인을 해보겠습니다.


입력값은 A가 96개 B 4개를 넣었습니다. 우리가 확인 한 대로라면 scanf의 두 번째인자에는 0x42424242가 들어가 있어야되여...



확인한 대로 잘들어가있네여 ㅠㅠ 


그런데 이걸 가지고 어떻게 익스플로잇 할 수 있을까여??

소스 상에서는 passcode1과 passcode2의 값이 모두 일치해야 조건을 만족하고 플래그를 읽어주는데...

결과부터 말씀드리면 passcod1을 입력받은 후 fflush함수를 호출 할 때 GOT의 주소를 바꿔줌으로써 플래그를 읽어볼 수 있습니다.


PLT / GOT가 무엇인지 자세히 알고 싶으신 분은 아래 링크를 참조 하세여!


PLT와 GOT 자세히 알기1

https://bpsecblog.wordpress.com/2016/03/07/about_got_plt_1/


PLT와 GOT 자세히 알기2

https://bpsecblog.wordpress.com/2016/03/09/about_got_plt_2/


[참조] https://bpsecblog.wordpress.com/


문제 풀이에 필요한 정도로만 간략히 설명을 드리자면

동적 라이브러리를 사용할 때 프로그램 내에 임포트한 라이브러리의 함수가 없기 때문에 (여기서는 fflush함수가 되겠습니다.)

해당 함수의 주소를 얻어 올 수 있는 테이블들입니다.


라이브러리 함수를 호출하게 되면 먼저 plt로 간 후, got로 점프를 뛰고 got에서 라이브러리의 함수 주소를 얻어오는 구조가 되겠습니다.


우리는 이 부분에서 fflush함수 호출 할 때, plt에서 got로 점프를 뛰는 부분의 주소를 login+127의 주소(system("/bin/cat flag"))로 바꾸어

익스플로잇을 시도해볼 수 있습니다.


그럼 수정해야 될 주소를 확인해 봅시당!

0x08048593 <+47>: call   0x8048430 <fflush@plt>


여기가 최초 plt테이블로 뛰는 부분이에여, 저 안에 가면 got로 점프 뛰는부분이 있을거에여


첫 줄에 바로 점프뛰는 부분을 보면 0x804a004로 점프를 뛰고 그 주소를 보니깐! got로 뛰어가고있는 모습을 볼 수 있네욥

여기서 우리가 바꿀 주소가! 바로 0x804a004에요, 여기다가 login+127의 주소인 0x080485e3을 넣어 줄꺼랍니다.



4. 페이로드 작성

작성해야될 페이로드를 프로토 타입으로 한번 보면 요렇게 될꺼에여

NOP 96개 + got로 뛰는 주소 + login+127의 주소


결과부터 보면 


(python -c 'print "\x90"*96+"\x04\xa0\x04\x08"+"134514147"') | ./passcode 이렇게 되겠습니다.


이제 찬찬히 또 뜯어봅시당


프로그램에 입력을 넣어 주는 부분은 파이썬을 사용했어여

NOP에 해당하는 \x90이 96개 들어갔습니당, 그리고 리틀엔디언 방식으로 주소를 때려박아야하니깐 한바이트씩 역순으로!

0x804a004 -> \x04\xa0\x04\x08이 되는거고여


그리고 scanf에서 포맷이 %d 즉, 정수형으로 받고있기 때문에~

0x080485e3을 십진수로 변환해준 134514147을 넣어줬어여


근데 뭐 이상한거 없으신가여? 제가 초보자여서 그런지 여기서 헤맸어여 ㅠㅠ

name[100]에 100바이트가 넘는 문자열을 입력하면 오버플로우가 안나나? 하는 생각을 했더랬져


제가 혹시 위에서 얘기했던 %100s 기억나시나요? 저렇게 사이즈를 정해줌으로써 딱 100바이트만 입력받고 100바이트이상 넘치는 문자열은

다음 인풋으로 넘어가더라고여..ㅎ;;;


그래서 정리해보면~


처음 이름을 입력하는 곳에 NOP + 0x804a004까지 들어가고 그 다음 passcode1을 입력하려고했던 로직에

0x080485e3이 입력이 되서 플래그를 읽을 수 있었습니다~







'Study > Pwnable' 카테고리의 다른 글

[HITCON Training] lab4 / return to library  (0) 2017.11.29
[HITCON Training] lab2 / shellcraft  (0) 2017.11.28
NX(No eXcutable) / ROP  (1) 2017.09.29
pwnable.kr / input / pwntools  (0) 2017.08.01
PEDA / pwnable.kr bof문제  (0) 2017.07.12

1. PEDA ?

Python Exploit Development Assistance for GDB 의 약자로써, 일반 GDB보다 바이너리 Exploit을 편리하게 할 수 있도록 다양한 옵션과 기능이 추가되어 만들어진 툴입니다. CTF대회같은 경우 시간절약이 중요하기 때문에 많이들 사용하시는 거 같습니다. 

저도 사용해보니 일단 알록달록해지는 UI와 디버깅 진행 할때마다 눈에 잘들어오는 stack 및 레지스트리 값 변화 등 보통의 gdb에 비해

아주아주 편리했습니다.


PEDA를 설치해본 결과 설치방법은 아래 링크가 가장 잘 설명이 되어있는 것 같습니다. 

설치 관련 블로그 링크 : https://hexa-unist.github.io/2015/02/25/PEDA-Introduction-Installation/



2. PEDA 기본 기능

모든 기능과 옵션을 본 글에서 다루기에는 어려움이 있어서... 상세한 내용은 2012년 BlackHat 발표자료를 첨부하였으니 살펴보시면 됩니다.


BH_US_12_Le_Linux_Interactive_Exploit_Development_with_GDB_and_PEDA_Slides.pdf


2-1) pdisas

gdb에서 disas 혹은 disassemble 로 사용했던 디스어셈블 기능의 확장판이라고 보시면 됩니다.

pdisas로 디스어셈블을 하게 되면 알록달록하게 하이라이팅 되어 비교적 가독성이 뛰어난 어셈블코드를 볼 수 있습니다.


아래 캡쳐를 보시면 확연히 비교가 됩니다.


disas func로 디스어셈블



pdisas func로 디스어셈블


2-2) stack 및 레지스트리 값 변화 확인

위 기능은 특별한 옵션을 주거나 명령을 통해 확인하는 것이 아니라, 브레이크 포인트를 걸고 디버깅을 하는 과정에서 바로 기능이 적용됩니다.



브레이크포인트를 걸고 실행을 하여 해당 위치에서 멈춘 화면입니다.

맨 위에는 각 레지스트리의 값과 해당 메모리에 어떤 값이 위치하고 있는지 해석도 나오고 있으며, 바로 아래에는 현재 브레이크 포인트가 어디에 멈추어져있는지(EIP 값이 얼마인지)를 나타내는 부분이 있고, 맨 아래에는 stack의 값 또한 바로 보여주고 있습니다.


2-3) find 명령어

find 명령어를 사용하여 특정 스트링을 검색 할 수 있습니다.

현재 프로그램에서 입력하는 곳에 "aaa"문자열을 입력한 상태였고, find명려어로 aaa를 서치한 결과입니다.



aaa라는 문자열이 heap과 stack에서 어디에 위치하고 있는지 표시해주고 있습니다.


2-4) 쉘코드 생성하기

BOF공격을 하기 위해 쉘코드를 찾으려고 여러 블로그를 뒤져보곤했는데, PEDA에선 각종 쉘코드를 제너레이트 해주는 기능이 있었습니다.

먼저 shellcode generate라고 입력하면 생성할 수 있는 shellcode의 종류를 보여줍니다.

위 캡쳐 화면에서 볼 수 있듯이 현재로써는 x86 쉘코드 밖에 지원이 되지 않는 것 같습니다.


직접 제너레이트 한 결과는 아래와 같습니다.



따로 쉘코드를 작성하거나, 블로그를 뒤져 찾아보지 않아도 되니 급할 때는 유용하게 사용 할 수 있을 것 같네요.



3) PEDA를 이용한 pwnable.kr bof문제 풀어보기


3-1) 문제 확인




문제 화면입니다.


Nana told me that buffer overflow is one of the most common software vulnerability. 

Is that true?


나나가 나에게 버퍼오버플로우가 가장 일반적인 소프트웨어 취약점이라고 말했는데 이거 실화냐? 라고 묻고있네요.

그리고 Download 링크가 두개가 있습니다. 하나는 c소스 파일이고 다른 하나는 c소스파일을 컴파일하여 생성된 바이너리인 것 같습니다.

wget으로 다 다운받아줍니다.


그리고 pwnable.kr 9000으로 돌리라고 하네요.


3-2) c소스파일 분석




메인함수에는 별 로직이 없네요.

func라는 함수에 헥사 값 0xdeadbeef라는 값을 전달하고 종료하고 있습니다.

bof를 유도 하는 로직은 func에 있는 듯 합니다.


func함수를 살펴보면 리턴 값은 없고, int형의 key라는 파라미터를 받고 있습니다. 

이 key값에는 메인함수에서 하드코드로 박혀있는 0xdeadbeef값이 전달이 되겠네요.


func함수의 바로 첫 라인에서는 overflowme라고 대놓고 선언되어있는 지역변수 char배열 32byte짜리 변수가 보입니다.

그리곤 overflow me : 라는 문자열을 출력하고 입력받은 값을 overflowme에 넣어주고 있습니다.

단순 gets함수로 받고 있기 때문에, 또 앞부분에서 size검사 부분이 없기 때문에 bof를 시킬 수 있는 포인트가 되며 

주석으로도 smash me! 라고 외치고 있는 것을 볼 수 있습니다.


아래 부분에서는 key 값이 0xcafebabe를 가지고 있는지 검사한 후 값이 일치하면 쉘을 넘겨 주고 있습니다.

위의 소스코드를 분석한 내용을 토대로 보면, func함수가 호출 되었을 때 stack의 모습을 예상해 볼 수 있습니다.





3-3) PEDA를 이용한 분석




main함수를 디스어셈블한 화면입니다. 함수 콜 직전에 0x0000063라인을 보면 mov로 esp에 함수 인자값을 대입하고 있는데,

간단히 push를 실행한 것과 동일하다고 보시면 되겠습니다.

그럼 func함수 호출부분에 브레이크 포인터를 걸고 실행하여 위의 내용이 맞는지 호출 전 스택의 상황을 살펴보도록 하겠습니다.



우리가 예상 한 것처럼 스택의 최상단에 func함수의 인자로 넣어준 0xdeadbeef가 위치하는 것을 확인할 수 있습니다.





si 명령을 통해 func함수 호출 직 후의 화면입니다. 함수 call을 하면서 다음 실행 명령 주소를 stack에 push한 것을 볼 수 있습니다.




func함수를 디스어셈블 한 화면입니다. 스택프레임 구성을 위해 ebp를 푸쉬하고있고, 지역변수인 overflowme[32]를 스택에 올리기위해 esp를 0x48 만큼 빼주고 있습니다. 정확히 32byte가 아니고, 0x48만큼인 이유는 컴파일러마다 약간의 사이즈 차이가 있기 때문이라고 하네요.


여기까지 분석한 스택의 상황을 그림으로 살펴보면 아래 처럼 되겠습니다.


더미가 overflowme[32]변수의 위에 위치할 지, 아래에 위치할 지 혹은 위 아래 나뉘어서 위치하고 있을 지는 직접 메모리를 들여다 보지 않아서 모르나, 둘이 합쳐 72byte(0x48)임은 어셈코드에서 알 수 있었고, 이에 따라 러프하게 개념적으로 위처럼 그려볼 수 있습니다. 

따라서 덮어써야할 내용은 

최소 44바이트(32byte + 4byte + 4byte + 0xcafebabe(4byte)) 부터 84byte(72byte + 4byte + 4byte + oxcafebabe(4byte))가 됩니다.

정확히 몇 바이트인지는 더 분석을 해봐야하겠네요.


입력값은 aaaaaaaa을 넣은 후 func+40에서 브레이크 포인트를 잡은 후 확인을 해보도록 하겠습니다.



esp(0xffffd1d0)에는 우리가 입력한 aaaaaaaa를 저장하고 있는 스택 내 overflowme[32]변수의 주소(0xffffd1ec)를 가르키고 있는 것을 볼 수 있습니다.



2-3) 에서 알아봤던 find명령어를 이용하여 aaaaaaaa가 위치한 스택 내 주소를 찾고, 0xdeadbeef가 위치한 스택 내 주소를 찾았습니다.

0xdeadbeef가 헥사값이라서 검색이 안될줄 알았는데 검색이 되어서 놀랐네요;

여하튼! 나온 주소 값의 차이는 0xffffd220 - 0xffffd1ec = 0x34(52) 임을 확인했습니다. 이 결과를 가지고 스택을 다시 그려보면

overflowme변수 위 아래에 더미가 껴있는 아래와 같은 형태로 그릴 수 있겠습니다.



3-4) exploit

결과부터 말씀드리면 exploit에 성공한 코드는 아래와 같습니다.


(python -c 'print "A"*52+"\xbe\xba\xfe\xca"';cat)|nc pwnable.kr 9000



먼저, python -c 'print "A"*52+"\xbe\xba\xfe\xca" 이 부분은 우리가 위에서 계산한 52바이트를 A라는 문자로 덮어버린 후

조작해야 할 헥사값 0xcafebabe로 만드는 문자열을 만드는 파이썬 구문입니다.

\xbe\xba\xfe\xca 처럼 역 순으로 문자열을 만든 이유는 엔디언 방식이 다르기 때문이고, 괄호와 세미콜론 + cat의 의미는

바이너리 실행 후 입력 값을 받는 형태를 맞춰주기 위함 입니다.

마지막으로 파이프로 연결한 후 문제에서 제시한 서버와 포트에 nc를 이용하여 전달하였습니다.



3-5) 결과



쉘이 실행 되었고 플래그값을 읽을 수 있음을 확인하였습니다 :)

'Study > Pwnable' 카테고리의 다른 글

[HITCON Training] lab4 / return to library  (0) 2017.11.29
[HITCON Training] lab2 / shellcraft  (0) 2017.11.28
NX(No eXcutable) / ROP  (1) 2017.09.29
pwnable.kr / input / pwntools  (0) 2017.08.01
pwnable.kr passcode  (5) 2017.07.31

1. Cycript

Cycript는 iOS에서 실행되고 있는 애플리케이션을 동적으로 수정하고 분석을 할 수 있게 해주는 SDK이다.

문법은 기본적으로 Objective-C / JavaScript를 혼합하여 사용 가능하다.

 


2. Cycript Hooking


2-1) view계층 확인하기

ex) UIApp.keyWindow.recursiveDescription()


view의 계층을 출력하여준다. NSLog로 출력하여 큰 화면으로 보면 아래와 같이 이쁘게 보인다.



2-2) subviews()

ex) UIApp.keyWindow.subviews()[index]


window는 하나 이상의 view를 가지며, view 역시 하나 이상의 view의 집합이다. 각 하위 view들의 접근은 subviews()[index]의 형태로 접근 가능하고, 2-1에서 확인한 계층을 참조하여 각 요소들을 찾을 수 있다.



2-3) _viewDelegate()

ex) UIApp.keyWindow.subviews()[2].subviews()[0]._viewDelegate()


_viewDelegate를 이용하여 해당 view의 controller에 접근 가능하다.


2-4) replacing existing objective-C methods

ex) Game2ViewController.prototype['recognizeAnswer'] 

= function() { NSLog(@"[JSACH]HOOKED"); return 1;}


target ViewController를 찾아 prototype배열에 후킹할 method에 접근하여 위와 같이 재정의해줌으로써 replacing가능함



참고) Cycript에서 사용하는 API나 문법, Trick들이 정리되어있는 링크

 

 - iOS Tricks

     http://iphonedevwiki.net/index.php/Cycript_Tricks


 - Cycript공식 홈페이지

http://www.cycript.org/


참고로 이 글은 Cycript 0.9.594버전을 기준으로 작성을 하였다.



3. 결과


3-1) 메서드 재정의


1
Game2ViewController.prototype['recognizeAnswer'] = function() { NSLog(@"[JSBACH]HOOKED"); NSLog(@"[JSBACH] return SUCCESSED"); return 1;}





3-2) 메서드 후킹 로그


3-3) 후킹 성공 결과




4. 후기

frida와 Logos 그리고 오늘 Cycript까지 정리하면서 처음에 계획했던 후킹 방법 세가지에 대해 모두 간단하게 겪어(?)보았다. 각 방법의 장단점이 어느 정도 감이 오는 것 같아서 매우 뿌듯하고 흡족스럽다!


개인적으로 생각하는 frida와 Logos, Cycript를 비교하면 이렇다고 생각한다.


 항목

Logos 

Frida 

Cycript 

설치의 편의성

하 

중 

상 

수정사항 반영의 편의성

하 

상 

상 

후킹 사항 유지력 

상 

하 

중 

 참조 자료의 양

중 

상 

하


4-1) 설치의 편의성

후킹하기 위한 각 툴들의 환경설치에 대한 평가 항목으로 선정해보았고, 개인적으로 소요된 시간과 환경의 까탈스러움 등을 고려하여 평가해보았다.


Logos의 경우 Mac사용자라면 간편한 편일 수 있으나, 본인은 Kali Linux에 환경을 설치하면서 꽤나 애를 먹었던 기억이 나서 낮은 '하'로 선정하였다.


Frida는 비교적 편리하게 설치하였으나, 단말에 Server Binary를 올려야하는 점과 Cycript만큼 간단하지 않았던 것같아(ㅎㅎ) '중'으로 점수를 매겼다.


Cycript의 경우 Cycia에서 패키지 설치만으로 모든 설치가 정상적으로 완료 되어 '상'으로 책정하였다.



4-2) 수정사항 반영의 편의성

후킹 코드 작성 중 수정사항이 생긴경우 재 반영하는 방법의 편의성에 대한 평가 항목이다.


Logos는 .deb파일을 재설치하고 Spring Board가 재시동되어야 하는 불편함이 있어 '하'가 되었다.


Frida의 경우 script를 종료 시킨 후 수정, 재실행의 과정이 있어야 하고.. 아무래도 Cycript만큼 간단하지 않았던것 같아 '중'으로 하였다.


Cycript는 후킹 script만 재정의 해주면 되므로 가장 간단하다고 판단하여 '상'으로 하였다.


4-3) 후킹 사항 유지력(?)

항목이름이 이상한거 같긴한데.. 적절한 명칭이 떠오르지않아서ㅠ... 한번 후킹 코드를 넣었을 때, 얼마나 유지가 되는지(?)에 대한 항목이다.


Logos는 한번 .deb설치가 되면 삭제가 될때까지 유지가 된다. 즉, 개발한 패키지를 한번 설치를 하고난 후 특별한 조치를 취하지 않아도 후킹코드가 유지된다. 가장 유지력이 좋다고 생각하여 '상'으로 책정하였다.


Frida는 후킹 script가 종료되기 전까지 유지가 되고, Cycript는 후킹 Process가 종료되기 전까지 유지 되므로 각각 '하'와 '중'으로 하였다.


4-4) 참조 자료의 양

비교 항목 중 가장 주관적인 항목으로 본인이 검색해 본 경험에 따라 그냥 매겼다.

아무래도 요즘 많이 떠오르고있는 Frida가 자료가 가장 많아 '상', Cycript와 Logos는 비슷 한것 같지만

Cycript가 예전 자료가 너무 많이나와서 사실상 볼 만한 자료가 거의 없었다. 따라서 더 애를 많이 먹었던 것 같아 '하'로 책정하였다.





다음 목표는 Logos를 이용하여 tsprotector와 비슷한 JB우회 패키지를 만들어 보고자 한다. 

fopen과 같은 file관련 API들, System call등을 후킹하여야 할 것으로 예상된다~


'Study > iOS' 카테고리의 다른 글

iOS Hooking#2(Frida)  (0) 2017.04.19
iOS Hooking#1(Logos)  (1) 2017.04.18
2장 iOS 해킹 기초 (1)  (0) 2016.06.18
자주쓰는 데이터형 변환  (0) 2016.06.01
[iOS/GCC] __attribute__((constructor)) / __attribute__((desstructor))  (0) 2016.05.13

1. Frida

Inject JavaScript to explore native apps on Windows, macOS, Linux, iOS, Android, and QNX.

[출처] https://www.frida.re/


Frida는 자바스크립트를 이용하여 Windows, macOS, Linux, iOS, Android와 QNX와 같은 다양한 플랫폼에서 후킹을 할 수 있는 플랫폼이다. 파이썬 틀에 인젝션할 코드를 자바스크립트로 작성하여 파이썬으로 실행 할 수 있다. 



2. Frida Hooking

iOS Hooking#1 에서 분석한 동일한 앱을 대상으로 진행을 하였으므로 앱 분석은 생략한다.


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
# -*- conding: utf-8 -*-
import frida
import sys 
 
PACKAGE_NAME = "kr.history"
 
#send실행 시 출력할 format정의
def on_message(message, data):
    try:
        if message:
            print("[JSBACH] {0}".format(message["payload"]))
    except Exception as e:
        print(message)
        print(e)
 
 
def do_hook():
 
    hook = """ 
    //Objective-C가 실행 가능한 환경인지 검사
    if(ObjC.available){
        //해당 attach된 프로세스의 메모리에 올라가있는 클래스들을 가져올 수있고,
        //아래 for문은 타겟 클래스가 존재하는지 검사했다.
        for(var className in ObjC.classes){
            if(className == "Game2ViewController"){
                send("Found our target class : " + className);
            }
        }
    
        //Hooking을 진행할 메서드 객체를 가져온다.
        var hook_method = ObjC.classes.Game2ViewController["- recognizeAnswer"];
        send("print hook_method : " + hook_method);
        
        Interceptor.attach(hook_method.implementation, {
        
            //onEnter는 후킹함수 진입 시 실행되며, args[0]에는 self객체가
            //args[1]에는 selector객체가 들어있어 접근 가능하며
            //args[2]에는 해당 함수의 매개변수들이 들어있다.
            //매개변수를 변경하고 싶다면 이곳에서 변경한다.
            onEnter: function(args){
                
                var receiver = new ObjC.Object(args[0]);
                send("Target class : " + receiver.$className);
                send("Target superclass : " + receiver.$superClass.$className);
                var sel = ObjC.selectorAsString(args[1]);
                send("typeof sel = " + typeof sel);
                send("Hooked the target method : " + sel);
            },
            //onLeave는 함수 종료전 처리를 할 수 있다.
            //retVal에는 원래의 return값이 들어있고, return값을 변경하고 싶다면
            //이곳에서 변경한다.
            onLeave: function(retVal){
                //오답 시 리턴 값
                var wrong   = -1;
                //정답 시 리턴 값
                var correct = 1; 
                //retVal은 Object객체이며, int값으로 사용하기 위해 toInt32()를 사용
                var orig_rtn = retVal.toInt32();
                if(-1 == orig_rtn){
                    send("answer is Wrong!! : " + orig_rtn);
                    send("answer is replaced!!");
                    //값을 변경하기위해 replace()를 사용하여 변경함
                    retVal.replace(correct);
                }
                else{
                    send("answer is Correct!! : " + orig_rtn);
                }
            }
        });
    }
    //Objective-C 실행 환경이 아닌 경우 로그 출력
    else{
        console.log("Objective-C Runtime is not available!");
    }
    """
 
    return hook
 
if __name__ == '__main__':
 
    try:
        #연결할 단말을 찾는다.
        device = frida.get_device_manager().enumerate_devices()[-1]
 
        #타겟으로 할 앱의 패키지명으로 단말에서 실행되고 있는 pid를 가져온다.
        pid = device.spawn([PACKAGE_NAME])
        print("[JSBACH] {} is starting. (pid : {})".format(PACKAGE_NAME, pid))
 
        #위에서 얻어온 pid에 attach한다.
        session = device.attach(pid)
        device.resume(pid)
 
        #후킹코드를 injection한다.
        script = session.create_script(do_hook())
        script.on('message', on_message)
        script.load()
        sys.stdin.read()
    except KeyboardInterrupt:
        sys.exit(0)



코드에 대한 설명은 주석으로 대체합니다.


3. 결과





4. 코드 작성하며 발생했던 사소한 문제점들

4-1) frida client / server간 버전 충돌 문제

frida --version / frida-server --version 으로 확인한 메이저버전이 다를 경우 frida가 제대로 동작하지 않는다.


4-2) 32bit 단말 문제

실습에 활용한 단말은 iPhone 5로 32bit 단말이였는데, Frida최신버전(9.1.27)버전에서 제대로 훜이 걸리지않음

-> 8.2.2버전으로 낮추어 설치하여 정상적으로 동작 (pip install frida==8.2.2)


4-3) retVal 값 format

onLeave에있는 retVal값을 toString()을 이용해 사용하면 헥사 값이 나온다. (위 예제에서는 오답인 경우 0xffffffff, 정답인 경우 0x1) 따라서 toInt32()함수를 이용해서 int로만들어 주었다.

0xffffffff를 parseInt()를 사용하여 출력하면 unsigned int형의 최대값인 4294967295가 출력되었다.


4-4) onEnter

onEnter에서 args에 접근하여 receiver와 receiver의 superclass를 출력할 때, 많은 예제코드에서 

$className이 생략되어있었는데, 타입 변환 에러가 나면서 제대로 출력되지 않았으며, frida API를 참조해서 

$className을 추가하여 해결함

[참조] https://www.frida.re/docs/javascript-api/#objc


4. 후기

Logos와 비교했을 때, 후킹 코드의 빌드나 설치가 별도로 필요 없어서 가볍다는 느낌이 들었다.

python과 JavaScript로 iOS후킹 코드를 짤 수 있다는 게 신기했고,

탈옥상태가 아닌 폰에서도 후킹이 가능하다는 점도 신기했다.

'Study > iOS' 카테고리의 다른 글

iOS Hooking#3(Cycript)  (3) 2017.05.06
iOS Hooking#1(Logos)  (1) 2017.04.18
2장 iOS 해킹 기초 (1)  (0) 2016.06.18
자주쓰는 데이터형 변환  (0) 2016.06.01
[iOS/GCC] __attribute__((constructor)) / __attribute__((desstructor))  (0) 2016.05.13

1. Logos

Logos is a component of the Theos development suite that allows method hooking code to be written easily and clearly, using a set of special preprocessor directives.


-[출처]http://iphonedevwiki.net/index.php/Logos


로고스는 Theos컴포넌트로 로고스를 이용하면 iOS 메소드 후킹 코드를 쉽고 깔끔하게 작성할 수 있다.

로고스를 이용한 후킹을 실습하기 위해 퀴즈앱을 대상으로 진행해보았다.


2. App Logic

2-1) 앱 실행 화면

앱은 퀴즈와 함께 해당 퀴즈 정답의 글자 수가 표시되고, 아래 글자를 클릭하여 정답을 맞추는 형식을 갖추고 있다.


2-2) iDA 정적 분석


Clutch를 이용하여 복호화한 Binary를 iDA로 열어 코드를 분석하면 위와 같은 코드를 발견 할 수 있는데, recognizeAnswer라는 메소드의 결과 값에 따라 congratulationViewVisible여부를 결정 하는 것을 알 수 있다.


recognizeAnswer메소드의 내용은 다음과 같다.


위 코드에서는 조금 잘렸는데, v2는 Game2ViewController의 self객체이고, answer_nospace의 길이가 0이 아니면 answer_nospace의 길이만큼 while문을 돌면서 userAnswer와 answer_nospace를 한글자씩 비교한다.

그 후 모두 매치하면 v15를 1로 만들고 매치하지 않으면 break한 후 v15를 -1로 만드게 되고 이 v15값을 리턴한다. 즉 유저의 정답과 문제의 정답을 비교하여 정답인 경우 1을 리턴하고, 오답인 경우 -1을 리턴하는 메서드임을 알 수 있다. 


2-3) Class-dump

2-2에서 확인한 Game2ViewController의 멤버변수나 메서드들을 Class-dump로 확인해 보았고, 우리가 주시해야하는 것들 부분만 발췌하였다.

answer_nospace는 앱에서 가지고있는 (분석한 결과 앱내 DB에서 조회해오는 값) 정답에 해당하는 변수이고, userAnswer는 유저가 입력한 답안 변수이다.



recognizeAnswer메서드는 멤버변수 값들로만 리턴 값을 정할 수 있으므로 특별한 Input값은 필요하지 않은 형태로 존재함을 확인 할 수있다.



3. Logos Hooking

위 분석 결과를 바탕으로 recognizeAnswer를 후킹하여 어떤 답안이 입력되든 정답처리가 될 수 있도록 Logos를이용한 후킹코드를 작성해 보았다.


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
#import <UIKit/UIKit.h>
#import <Foundation/Foundation.h>
  
@interface Game2ViewController : UIViewController{
} 
  - (int)recognizeAnswer;
@end
%hook Game2ViewController
- (int)recognizeAnswer{
    int ret = %orig;
    int correct = 1;
    NSLog(@"[JSBACH]recognizeAnswer is Hooked\n"); 
    if(-1 == ret){
         NSLog(@"[JSBACH]answer is Wrong!! : %d", ret);
    }    
    else{
         NSLog(@"[JSBACH]answer is Correct!! : %d", ret);
    }
 
    return correct;
}
%end



@interface Game2ViewController : UIViewController{

}


- (int)recognizeAnswer;

@end


후킹 타겟으로 하는 클래스/인터페이스와 해당 메서드의 form을 정의해준다.

우리가 후킹할 Game2ViewController는 UIViewController의 sub이므로 Game2ViewController : UIViewController부분이 있고, class-dump의 결과에서 확인했던 것과 같이 - (int)recognizeAnswer 메서드 형태로 정의해준다.


%hook Game2ViewController 후킹할 클래스/인터페이스를 지정하고 %end로 후킹코드의 끝을 내준다.

%orig는 원래 메서드의 리턴값을 가져올 수 있으며, argument가 존재하는 경우에는 %orig(arg1, arg2, ...)형식으로 호출 가능하다.


여기서는 본래의 리턴값을 가져와서 정답/오답여부를 로그로 표출하고, 무조건 정답처리 할 수 있도록 코딩하였다.



3. 후킹 결과



정상적으로 후킹 되어 로깅이 되고있는 모습이다.



원래 정답은 비파형 / 세형이지만 아무 값이나 오답을 입력한 후 테스트 하였고 정답처리가 됨을 확인하였다. :)



4. 후기

Logos를 이용해서 트윅제작, 시스템콜 후킹, UI버튼을 추가하는 등의 다양한 여러작업이 가능하다고 들었는데, 천천히 하나씩 해보고 싶다. 우선 다음 게시글은 Frida를 이용해서 똑같은 행위를 하는 후킹코드를 작성 해볼 예정이다.





'Study > iOS' 카테고리의 다른 글

iOS Hooking#3(Cycript)  (3) 2017.05.06
iOS Hooking#2(Frida)  (0) 2017.04.19
2장 iOS 해킹 기초 (1)  (0) 2016.06.18
자주쓰는 데이터형 변환  (0) 2016.06.01
[iOS/GCC] __attribute__((constructor)) / __attribute__((desstructor))  (0) 2016.05.13

1. ptrace 

 ptrace는 여러 유닉스와 유닉스 계열 운영 체제에서 발견되는 시스템 호출이다. ptrace(이 이름은 "process trace"의 축약형이다)를 통해 컨트롤러가 대상의 내부 상태를 조사하고 조작하게 함으로써, 한 프로세스가 다른 프로세스를 제어할 수 있다. ptrace는 디버거와 다른 코드 분석, 특히 소프트웨어 개발을 도와주는 도구들에서 사용된다.

[출처] 위키백과 https://ko.wikipedia.org/wiki/Ptrace


2. 목적

 본래의 목적은 안드로이드 LD_PRELOAD 환경 변수에 라이브러리명을 인젝션하여 특정 함수를 후킹하는 것

2-1) LD_PRELOAD 

 프로세스 실행 전 라이브러리 로딩 과정에서 해당 환경변수에 추가되어있는 라이브러리를 우선적으로 로딩하게 만드는 환경변수

2-2) 메인아이디어 

 zygote를 kill하게되면 init프로세스에서 zygote프로세스를 재생성하며, 이때 LD_PRELOAD환경 변수가 재로드되고, 이때 값을 조작하여 원하는 라이브러리를 인젝션한다.


2-3) 목적 달성 과정

 - zygote process kill (성공)

 - new zygote process의 pid를 알아냄 (성공)

 - new zygote process에서 실행하는 execve 실행 시점에서 환경변수 값 조작 (실패)

 - 후킹 여부 확인 (실패)


3. aarch32 vs aarch64

3-1) register갯수가 다름

 - register갯수가 대폭 추가되면서 ptrace를 이용하여 system call을 이해하기 위해 사용되는 register번호 또한 달라졌으며, 그에 따라 코드에서 사용하는 구조체 및 상수 또한 달라졌다.

 

aarch32 

aarch64 

system call number표시 reg 

7 

 8

 IP reg

ARM_ip 

 12

 return 값 reg

0 

0 

reg표시 structure

pt_regs

 user_regs_struct

 syscall number 참조

 리눅스 syscall number와 동일

ndk-bundle\include\asm-generic\unistd.h


 - aarch64 레지스터 설명

r30 (LR): The Link Register, is used as the subroutine link register (LR) and stores the return address when Branch with Link operations are performed.

r29 (FP): The Frame Pointer

r19…r28: Callee-saved registers

r18: The Platform Register, if needed; otherwise a temporary register.

r17 (IP1): The second intra-procedure-call temporary register (can be used by call veneers and PLT code); at other times may be used as a temporary register.

r16 (IP0): The first intra-procedure-call scratch register (can be used by call veneers and PLT code); at other times may be used as a temporary register.

r9…r15: Temporary registers

r8: Indirect result location register

r0…r7: Parameter/result registers


3-2) zygote 프로세스

 - aarch32에서는 zygote process밖에 존재 하지 않지만, aarch64에서는 zygote / zygote64 process가 존재함 

 - aarch64에서 zygote 프로세스는 두 개지만 zygote process를 kill하면 zygote64 또한 재 실행되는 것으로 보임


3-3) zygote 프로세스 kill 후

 - 새 프로세스 생성 전 aarch32에서는 stat64 system call을 사용하여 실행 바이너리(app_process)의 정보를 얻어 오지만, aarch64에서는 fstat64 system call을 사용하여 실행 바이너리(app_process32 / app_process64)의 정보를 얻어오며, aarch64의 app_process 바이너리는 app_process64의 심볼릭 링크이다.

 - aarch32에서는 fork system call로 zygote process를 생성하지만 aarch64에서는 clone system call을 이용

 - 개인적으로 fork / clone system call의 가장 큰 차이점은 프로세스 복사(생성) 이 후 실행 할 바이너리를 경로로 넘겨주느냐(fork), file descriptor(clone)의 차이가 가장 큰 외적 차이로 보이며, 조사를 통한 내적 차이는 parent process로부터 메모리 스택을 공유(clone) / 비공유(fork)라고 생각하고, 전반적으로 clone의 system call이 fork에 비해 비교적 비용이 낮은 것으로 설명이 되어있었다.


3-4) execve system call 탐지 가능 여부

이 부분은 aarch64에서도 아마도(?) 탐지가 가능할 것이나 내 능력/자료가 부족한 것으로 생각된다.

 - ptrace를 사용하여 레지스터 값들을 조사할 때 실행되는 system call number에 execve system call에 해당하는 220번이 탐지 되지 않음

 - strace를 이용하여 값을 조사했을 때는 execve system call이 실행되는 것이 확인됨


4. aarch64에서 ptrace사용

4-1) 레지스터 값을 가져오기 위한 구조체 선언

1
2
3
4
5
6
7
8
9
10
//#include <linux/PTRACE.h>
//#include <sys/PTRACE.h>
 
//aarch64에서 달라진 구조체
struct user_regs_struct gregs;
 
//aarch64에서 추가로 필요한 부분
struct iovec iovecs;
iovecs.iov_base = &gregs;
iovecs.iov_len  = sizeof(gregs);


4-2) ptrace attatch

1
2
3
4
5
6
7
8
// step 1. init프로세스에 PTRACE attatch 
ret = PTRACE(PTRACE_ATTACH, INIT_PID, (void *)1, 0);
if(ERROR == ret){
    printf("[ERROR] PTRACE_ATTACH failed return = %d\n", ret);        
}
else{
    printf("[INFO] PTRACE_ATTACH SUCCESS\n");    
}



4-3) 레지스터 값 얻어오기

1
2
3
4
5
6
7
8
9
10
11
// cpu 레지스터 획득
ret = PTRACE(PTRACE_GETREGSET, INIT_PID, (void *)NT_PRSTATUS, &iovecs);
        
if ( ret < 0 ) {
    printf("[ERROR] PTRACE_GETREGSET ERROR : %d\n", ret);
            
}       
else{
    printf("[INFO] PTRACE_GETREGSET SUCCESS : %d\n", ret);                
}








4-4) system call 탐지

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
#define SYSCALL_REGISTER(r)     r.regs[8]
#define RESULT_REGISTER(r)      r.regs[0]
#define IP_REGISTER(r)          r.regs[12]
 
//gregs.regs[28]이 0이 무엇을 뜻하는 지는 알수 없으나,
//여러 번 반복해보는 과정을 통해 0인 경우일 때가 new pid가 리턴되는 것을 확인함
//그 중에서도 리턴 값이 정상인 것과 비정상인 값이 있었는데,
//정상 값을 찾기 위해 maximum pid값을 지정함(cat /proc/sys/kernel/pid_max -> 32768)
if ( 220 == SYSCALL_REGISTER(gregs) && 
      40 == IP_REGISTER(gregs)        && 
       0 == gregs.regs[28]             &&
   32768 >= RESULT_REGISTER(gregs) ) {
            printf("[*] Found a new zygote64 process: %ld\n", RESULT_REGISTER(gregs));
            
            new_zygote_pid = RESULT_REGISTER(gregs);
}



4-5) ptrace detach

1
2
3
4
5
6
7
//ptarce detach
if(PTRACE(PTRACE_DETACH, INIT_PID, (void*)1, 0) < 0) {
        printf("[ERROR] PTRACE_DETACH error\n");
}
else{
        printf("[INFO] PTRACE_DETACH SUCCESS\n");
}



'Study > 안드로이드' 카테고리의 다른 글

진술서전송앱  (0) 2022.11.03
JDB이용하여 앱 동적 분석하기  (0) 2017.02.13
Drozer 기본 명령어  (0) 2017.02.09
안드로이드 재서명 하기  (2) 2016.05.08
안드로이드 apk서명  (0) 2016.05.02

1. JDB

The Java Debugger, jdb, is a simple command-line debugger for Java classes. It is a demonstration of the Java Platform Debugger Architecture that provides inspection and debugging of a local or remote Java Virtual Machine.

[출처] http://docs.oracle.com/javase/7/docs/technotes/tools/windows/jdb.html

간단히 정리하면 로컬 혹은 원격 자바 가상머신에서 실행되는 자바 프로그램을 디버깅할 수 있는 디버거입니다.

이 JDB를 이용하여 앱을 디버깅 할 수 있습니다.

위치 : ..../JDK_HOME/bin/jdb


2. 안드로이드 앱에 JDB Attach방법

2.1 디버깅 앱 포트번호 알아내기

먼저, 안드로이드 앱에서 사용하고 있는 포트번호를 알아내야합니다. 

앱 실행 전 adb jdwp 실행 결과와 디버깅할 앱 실행 후 adb jdwp 결과를 비교하여 앱에서 실행하는 포트를 알아냅니다.

아래는 결과물을 diff하여 알아낸 창입니다.

 보통은 맨 아래에 추가가 되는 형태인 듯하네요. 예시에서 디버깅 할 앱에서 사용하고있는 포트 번호는 8160입니다.


2.2 디버깅 포트를 로컬 포트로 포워딩

adb 명령어를 통해 디버깅 포트를 로컬 포트로 포워딩해줍니다.

adb forward tcp:[로컬포트] jdwp:[디버깅포트]


2.3 jdb실행

로컬포트를 이용하여 jdb를 attach합니다.

위의 예시는 디버깅포트가 8218을 사용하고 있고, 로컬포트 11111로 포워딩 해주고 난 후

jdb -connect com.sun.jdi.SocketAttach:hostname=localhost,port=11111(포워딩한 로컬포트) 를 실행하여

JDB를 Attach하였습니다.


3. 기본 JDB 명령어

명령어 

사용법 

설명 

next

next 

다음 라인 실행 

local

local 

현재 로컬 영역 변수 보기 

threads 

threads 

현재 실행 중인 스레드 확인 

methods 

methods [Class Name] 

해당 클래스가 사용하는 

메서드 출력 

stop in

stop in [method name] 

해당 메서드에 

브레이크포인트 설정 

print

print [value] 

특정 변수 값 출력 

eval 

eval [Java Code] 

자바코드를 실행시킴 

 run

run 

현재 브레이크 포인트
무시하고 실행 

[참조] 안드로이드 모바일 앱 모의 해킹(지은이. 조정원, 김명근, 조승현, 류진영, 김광수)




'Study > 안드로이드' 카테고리의 다른 글

진술서전송앱  (0) 2022.11.03
aarch64에서 LD_PRELOAD Injection을 통한 함수후킹(실패)  (0) 2017.04.10
Drozer 기본 명령어  (0) 2017.02.09
안드로이드 재서명 하기  (2) 2016.05.08
안드로이드 apk서명  (0) 2016.05.02

Drozer 기본 명령어 정리 

Drozer_command.xlsx



'Study > 안드로이드' 카테고리의 다른 글

aarch64에서 LD_PRELOAD Injection을 통한 함수후킹(실패)  (0) 2017.04.10
JDB이용하여 앱 동적 분석하기  (0) 2017.02.13
안드로이드 재서명 하기  (2) 2016.05.08
안드로이드 apk서명  (0) 2016.05.02
안드로이드 apk꺼내기  (0) 2016.05.02

File Download 취약점

외부 입력 값에 대해 경로 조작에 사용될 수 있는 문자를 필터링 하지 않으면, 예상 밖의 접근 제한 영역에 대한 경로 문자열 구성이 가능해져 시스템 정보누출, 서비스 장애 등을 유발 시킬 수 있는 취약점

출처: http://skynarciss.tistory.com/37 [IT 보물창고]


1. 대상 확인

작성된 게시글의 첨부파일을 다운받는 페이지를 살펴봅시다.

업로드된 파일명을 클릭하면 다운로드를 받을 수 있습니다.

Burp Suite를 이용하여 파일 다운로드 요청이 어떻게 전송되는지 살펴보겠습니다.


파일 다운로드를 하기 위해 fileDown.jsp로 요청을 보내는데, 파일명을 GET방식으로 fileName이라는 파라미터에 값을 셋팅하여 전송하고있습니다.


GET방식이기 때문에, 같은 url을 입력하면 파일을 다운 받을 수 있습니다.

 


2. 로직

이 게시판에서 파일을 다운받게 해주는 로직을 추측해보고, 실제 소스코드를 봅시다.

1. GET 파라미터인 fileName에 파일명이 전달된다. 

2. 파일 업로드 시 파일을 저장한 저장 디렉토리의 위치에 파일명을 덧붙혀 파일경로를 완성한다.

3. 해당 파일 경로에 있는 파일을 클라이언트로 전송한다.


실제 소스코드를 보면 위에서 추측한 로직과 동일한 것을 알 수 있습니다.

이 게시판은 C드라이브 아래에 있는 save_dir 디렉토리에 파일을 저장하고 있었네요.


3. 공격

File Download 취약점이 존재하는 지 알아 보기 위해 디렉터리 이동 명령어들이 실행 되는지를 아래와 같이 확인해 볼 수 있습니다.

파라미터는 test/../148609......jpg 의 형태로 입력이 되었습니다.

이 파일 명이 의미하는 바는 잘 아시다시피 현재 경로에서 test디렉터리 아래 -> 한 단계 상위 -> 에 있는 148609......jpg가 됩니다. test디렉터리 아래 -> 한 단계 상위는 서로 상쇄되어 결국 148609......jpg가 되는 것인데,

이 테스트의 의미는 디렉터리 이동 명령어들이 필터에 걸리지 않는 지, 혹은 다른 조치가 되어 있는 지를 확인하는데 의미가 있습니다.

위 테스트를 하였을 때 성공적으로 튤립 그림을 다운받을 수 있었으므로, File Download취약점이 있다고 보여집니다.


파일 이동 명령어가 실행이 되는 상태라면 자유자재로 서버의 파일들을 다운 받을 수 있습니다.(물론 원하는 파일의 위치를 알아야겠지만요)

이 게시물에서는 예시로 C:/Window/System32 경로에 test.txt파일을 만들어서 공격 예시를 들어보도록 하겠습니다.


구조는 어렵지 않고 다만 파라미터에 원하는 경로를 조립하여 넘겨주었습니다.

결과적으로 해당 경로에있는 test.txt파일을 다운 받을 수 있었습니다.



4. 조치 방법

각 개발 프레임 워크 별 설정방법이 있는 것 같습니다만, 우리 게시판 프로젝트는 순수 jsp로 짜여진 게시판이므로ㅠㅠ 간단한 필터링을 통해 조치를 해보도록 하겠습니다.

위의 소스코드와 같이 입력받은 파라미터를 곧바로 사용하지 않고 디렉터리 이동에 사용되는 문자("\.", "..", "/"들을 공백으로 치환해주었습니다.

그리고 파일이 존재 하지 않는 경우에는 (더 좋은 처리가 있겠지만..) 더미 파일을 전송하도록 하여 처리를 했습니다.






'Study > WEB' 카테고리의 다른 글

jspBoardProject#4(SQL Injection / Blind SQL Injection)  (0) 2017.02.07
jspBoardProject#3(파라미터 변조)  (0) 2017.02.06
jspBoardProject#2(XSS)  (0) 2017.02.06
jspBoardProject#1  (0) 2017.02.06

SQL

RDBMS(Relation DataBase Management System)의 데이터를 관리하기 위해 설계 된 특수 목적 프로그래밍 언어로써 쉽게 말해 데이터베이스를 핸들링 하기 위해 사용하는 언어입니다.


SQL Injection

응용 프로그램 보안 상의 허점을 의도적으로 이용해, 개발자가 생각지 못한 SQL문을 실행되게 함으로써 데이터베이스를 비정상적으로 조작하는 코드 인젝션 공격 방법입니다.

[출처] 위키백과(https://ko.wikipedia.org/wiki/SQL_%EC%82%BD%EC%9E%85)


Blind SQL Injection

SQL Injection의 결과를 이용하여 참, 거짓 값을 구별 할 수 있을 때 사용할 수 있는 방법으로 장님이 길을 지팡이로 짚으며 가는 듯한 과정이 있어 이를 Blind SQL Injection이라고 합니다.


1. 대상 확인

언제나 처럼 게시판을 이용하여 정리해보도록 하겠습니다.

먼저 게시판의 검색 부분을 살펴보겠습니다.

검색조건을 선택하고 검색 키워드를 입력한 후 검색 버튼을 누르면 해당하는 내용을 검색 할 수 있습니다.

검색 조건은 작성자 / 키워드 / 작성자 + 키워드이며 공란인 경우 아래와 같은 알럿메시지를 표출합니다.

검색에 이용되는 키워드는 쿼리 작성에 사용이 될텐데 검색 후 URL에 파라미터가 표시되지 않는 것으로 보아 POST방식으로 파라미터가 전달 되고 있는 것 같습니다.

검색 할 당시의 패킷을 Burp Suite로 확인 해보도록 하겠습니다.


위에서 추측한대로 검색에 관련된 파라미터들(검색 조건/검색 키워드)이 POST방식으로 전달되고 있는 것을 확인 할 수 있습니다. (searching_condition=title&searching_keyword=TE)


2. 우회 과정

이 키워드에 전달되는 파라미터에 쿼리를 인젝션하여 특정 게시물의 비밀번호를 알아내보겠습니다.

결론부터 이야기하자면 인젝션하여 서버에서 실행 될 쿼리의 예시는 아래와 같습니다.

SELECT letterNum, userID, letterTitle, secretYN
FROM board
WHERE userID LIKE '%USER%' 
AND ((ascii(substr((SELECT letterPW from board where letterNum = 6), 1, 1))) = 48)#%'

현재 서버에서 실행되고 있는 쿼리는 

SELECT letterNum, userID, letterTitle, secretYN
FROM board
WHERE userID LIKE '%{INPUT}%'

의 형태이고, 이 INPUT안에 쿼리를 삽입하여 위처럼 공격 쿼리를 만들어 내야합니다.

(지금은 직접 개발한 게시판이기 때문에 DB정보와 쿼리문의 구조를 알고있지만,

실제로는 추측/유추 해야하는 과정이 필요합니다.)

따라서 INPUT에 삽입될 쿼리는 아래와 같습니다.

USER%' 
AND ((ascii(substr((SELECT letterPW from board where letterNum = 6), 1, 1))) = 48)#%'

AND 뒷 부분이 핵심이므로 이 부분을 상세히 살펴보도록하겠습니다.

1) SELECT letterPW FROM board WHERE letterNum = 6

-> 이 예시에서는 게시글 번호 6번 글에 대한 패스워드를 유추하고 있습니다. 따라서 6번 게시물의 패스워드를 조회해 옵니다.


2) substr( 6번게시물 패스워드, 1, 1)

-> mysql에서 실행되는 함수로 문자열의 첫 번째 글자부터 한 글자를 조회해옵니다.

-> 결과적으로 6번 게시물 패스워드의 맨 첫 글자를 가져올 수 있습니다.


3) ascii(문자)

-> 해당 문자를 아스키 코드 값으로 변환해줍니다.


4) 결과

6번 게시물 패스워드의 첫 글자의 아스키코드가 아스키코드 값 48과 같은 지를 반환합니다.

위의 결과가 true인 경우, 원래의 쿼리와 결과가 종합되어 모든 게시물이 출력되고(true and true이므로),

false인 경우 게시물 조회 결과가 없음으로 표시됩니다.


패스워드를 한 글자씩 찾는 스크립트가 필요합니다. 

스크립트 풀 소스는 첨부 하고, 주요 부분만 확인하도록 하겠습니다.  : )

첨부 :  blinSqlInjection.py

실습환경이기때문에, 비밀번호는 숫자와 영대소문자로만 이루어져있다는 가정을 하였습니다.

스크립트는 파이썬으로 작성하였으며 스크립트 실행 전 설치해야할 파이썬 라이브러리로는

http리퀘스트를 위한 requests와 결과를 파싱하기 위한 Beautifulsoup가 있습니다. 


헤더 값은 Burp Suite에서 얻은 패킷의 값과 동일하게 맞추어주고, 파라미터를 변경합니다.

우리가 수정해서 삽입할 쿼리를 완성시킨 executeSql을 키워드 파리미터에 셋팅해줍니다.

requests를 이용하여 리퀘스트를 보내고 받은 결과를 BeautifulSoup를 사용하여 파싱합니다.

해당 게시판의 list.jsp 응답 내용 중 "총 게시물 : x개" 로 body에 응답이 오는데 이 부분을 파싱하여

0개인 경우에는 찾지 못한 것으로, 0개 이상인 경우에는 찾은 것으로 판별하였습니다.


아래는 파싱하여 게시물의 갯수를 int형으로 변환하여 리턴해주는 함수입니다. 

첫 째줄에서는 공백을 제거하였고, ":"로 스플릿한 뒷부분을 공백제거하여 이 후

첫 글자를 int형으로 변환한 후 리턴해줍니다.


비교할 검사 문자는 0~9, a ~ z, A ~ Z 입니다. 각 문자들이 아스키 코드표 상 연속되어 존재하지 않기 때문에

구간 구간 점프를 뛰어야하는 부분을 if문으로 걸러주었으며, 찾는 문자 구간에 문자가 없으면 패스워드의 끝으로 인식하고 있습니다. ( elif int(asciiNum) > 122 부분)

문자를 찾은 경우에는 targetPW라는 필드에 찾은 문자를 덧 붙혀주고, 검사 문자 순서를 다음으로 넘긴 후

비교 문자를 0('48')로 초기화 시켜주고, 쿼리문을 갱신합니다.


위 과정을 모두 마친 후 추출해낸 패스워드를 확인합니다.


스크립트 실행 결과


3. 조치 방법

1. jspBoardProject#2(XSS) 에서 조치했던 것 처럼 입력 값에 필터링을 수행하여 검사할 수 있습니다.

2. JAVA/JSP에서는 쿼리 실행을 Statement클래스를 사용하지 않고 PreparedStatement를 사용하는 방법이 있습니다.


필터링에 관해서는 앞서 다뤄본 방식과 별반 다르지 않기 때문에, PreparedStatement를 사용하는 방법으로 조치해보도록 하겠습니다.

먼저, 문제가 되는 부분의 소스코드를 살펴보면,

아래와 같이 변수가 쿼리에 직접적으로 연결되는 구조로 Injection하기 너무나 편리하게 되어있는 것을 확인 할 수 있습니다.



이 부분을 PreparedStatement 인터페이스를 사용하여 다음과 같이 조치 할 수 있습니다.

바뀐 점은 일반 Statement인터페이스에서는 쿼리와 Input value가 직접적으로 연결되어 실행이 되지만,

PreparedStatement에서는 쿼리문에서는 ? 로 인자 표시를 하고 후에 setString과 같은 메서드를 사용하여

변수를 추가 해주고있습니다.

코드 수정 후 스크립트 결과를 보면 아래와 같이 조치가 된 것을 확인 해볼 수 있습니다.



여담.

order by 뒷 부분 역시 PreparedStatement방식으로 사용 해보려고했으나, setString(4, sorting_cond); 와 같은 방식으로 추가했을 때 sorting_cond가 상수 값으로 인식되어 정상적으로 정렬이 되지 않았습니다.

외부에서 직접적으로 입력을 받는 부분이 아니기때문에 문제가 없을 것으로 생각되어 기존처럼 쿼리에 연결을 하였습니다.

'Study > WEB' 카테고리의 다른 글

jspBoardProject#5(File Download)  (0) 2017.02.08
jspBoardProject#3(파라미터 변조)  (0) 2017.02.06
jspBoardProject#2(XSS)  (0) 2017.02.06
jspBoardProject#1  (0) 2017.02.06

+ Recent posts

티스토리툴바