'iphone'에 해당되는 글 3건

  1. 2012.10.05 iOS Hooking (2)
  2. 2012.09.29 The process changing memory buffer while all threads are suspended
  3. 2010.08.05 iPhone / iPad 0-day PDF Exploit!

2012.10.05 11:43 System

[+] Introduction


 

오늘의 주절 거림 대상은 감성의 iOS 입니다.


맛폰 사용률이 급격히 늘어나면서 모바일 보안쪽도 덩달아 관심을 받고 있는데요.


개방적인 안드로이드에 비해서 iOS는 상당한 제약을 두고 있죠.


그 덕에 루팅은 매우 쉽게 되고 있는 반면, 탈옥 쪽은 iOS가 버전업을 할 떄마다 전투가 벌어집니다.


Soft 단에서는 물론 Hard 측에서도 탈옥 감지 루틴을 넣어두었고 탈옥폰에서는 동작 하지 않도록 하는 어플들도 


간혹 보이고 있습니다. 


전에는 bootrom, loader, kernel 정도만 수정했어도 됐는데 말이죠. 라고


쉽게는 말했지만 그렇게 호락호락한 작업은 아닙니다.


boot rom , loader 의 check를 우회하고 들어가서 loader를 교체하고 kernel을 수정해야 합니다.


그러니까 교도관을 속이고 감옥에 들어가서 탈출할 수 있도록 시스템을 분석 후 교체 하고 


최후에는 우리쪽 교도관을 세워야 된다는 소리죠.


프리즌 브레이크보다 더 스릴 넘치는 이야기가 아닐 수 없군요.


 

<Fig. 시도조차 못하겠는데요>



 

이렇게 사람들이 저마다 석호필을 꿈꾸며 탈옥하고자 하는 이유는 여러가지가 있습니다.


애플이 막아둔 기능의 활성화 , customizing  혹은 사형선고를 받은 형을 구하러 간다던가 하는 걸로요.


다행스럽게도 이번 포스팅에서 다룰 부분은 탈옥한 상태의 iPhone을 대상으로 이루어집니다. 괜찮아요. 어렵지 않아요.


kernel patch, boot loader 수정 원리 등은 추후 포스팅에서 다룰 수 있... 지 않을까 생각해봅니다.

 

iPhone 의 Hooking은 Mobile Substrate라는 기본 탈옥 library를 이용하며 본 포스팅은 이를 분석하는 글입니다.

 

Library의 함수명 , 사용 방법 보다는 동작 원리 등에 중점을 두고 쓰도록 하죠.

 

 

 

 


[+]  Find how to patch the code 


 

가장 기본이 되는 Hooking의 원리는 물론 Code Patching 이겠죠.

 

그런데 이 Code Patching 을 어떻게 하느냐?

 

 

 

1. 원격으로 Thread를 만들어 Code를 삽입. 실행.

 

- Code Injection 얘기죠. 다만, 이미 실행되 Process를 Target으로 잡고 있으며 ,

 

새로 실행되는 Process를 감시해야되는 점이 단점으로 남죠.

 

게다가 iOS의 특성상 Sandbox 로 각 Process간에 벽이 존재하는 점 또한 큰 걸림돌이 됩니다.

 

탈옥 했다는 것은 곧 Sandbox를 탈출했다는 소리지만, 일반 앱들은 아직 mobile user 로 돌아가며

 

Sandbox 내에 있어요.

 

 

 

2. dylib 를 injection 한다.

 

 - Windows의 DLL Injection과 유사한 방법입니다. 다만 특정 Process에서 Target Process로 DLL을 Load 시키는 것이 아니라

 

[ 이 방법대로 하면 Code Injection 과 별 다를바가 없죠 . ]

 

Process가 실행 될 때 dylib [ 동적 library ]를 강제로 Loading 하게 만들고 내부에서 Code를 수정하는 방식입니다.

 

Windows 에서도 Process 시작시에 DLL을 강제 Loading하는 방법이 있죠.

 

자기 자신에서 Code를 바꾸기 때문에 Sandbox도 문제가 될 건 없어요.

 

다만.. iOS의 kernel은 기본적으로 한 메모리 구역에 쓰기 속성과 실행 속성을 동시에 줄 수 없습니다.

 

이 부분은 kernel 단에서 수정이 되어야 하는 것이고, 탈옥을 하면서 이루어진 kernel patch 중 하나가 됩니다.

 

하지만 기본적으로 text 영역엔 쓰기 속성이 없기 때문에 Patch 하기 전에는 쓰기 속성을 주셔야겠죠.

 

 

 

3. kernel level의 system call table을 바꾼다.

 

- kernel hooking 입니다. 사실 불특정 다수의 Process를 control할 때 가장 우아한 방법이긴 합니다만, 

 

이번 포스팅의 주제는 User level hooking 이므로 넘어가도록 하겠습니다.

 

iOS의 Kernel level hooking 은 이미 작년에 유동훈님이 성공하셨다고 하더군요. 시연은 Android만 하셨다고 들었습니다.

 

이번 Code Engn 에서 android 취약점 공격 분석에 관해 발표도 하셨더라구요.

 

http://codeengn.com/file/conference/2012/2012_6th_CodeEngn_[x82]_%EB%AA%A8%EB%B0%94%EC%9D%BC_%EC%8A%A4%EB%A7%88%ED%8A%B8_%ED%94%8C%EB%9E%AB%ED%8F%BC_%EC%9B%90%EA%B2%A9_%EB%A1%9C%EC%BB%AC_%EC%B7%A8%EC%95%BD%EC%A0%90_%EA%B3%B5%EA%B2%A9_%EB%B6%84%EC%84%9D.pdf

 

 

흥미로운 주제니 한번씩 보고 가시는것도 좋을거 같네요.

 

 

 

[+] Analysis the hooking method 


dylib를 로딩 시켰다면 이제 쓸 영역에 쓰기 권한을 주어야 합니다.

 

vm_protect 함수를 이용하여 해당 부분에 쓰기 권한을 주고 난 후 Code를 바꿔봅시다.

 

여기서 주의할 점은 ARM + THUMB mode 둘 다 생각하셔야 된다는 건데요,

 

16bit instruction 을 지원하기 위해 만든 THUMB mode 가 아직도 사용됨에 따라 그쪽 분기를 따로 만들어야 합니다.

 

[ 물론 이 부분은 mobile substrate에서 자동으로 해줍니다. ]

 

아무튼 mode가 달라지면 patch 해야 하는 code 자체가 달라지므로 주의를 해야 합니다.

 

ARM mode는 1 instruction 이 4byte고 THUMB mode는 1 instruction 이 2byte 라서 말이죠.

 

그렇기 때문에 같은 명령어라도 THUMB mode에서는 ARM mode에서 존재하는 instruction 을 재현하기 위해

 

여러가지 instruction 을 조합해서 쓰곤 합니다.

 

그렇게 때문에 hooking 하는데 쓰이는 code는 mode별로 크게 다르지 않아요.

 

THUMB mode 같은 경우는 ARM mode로 바꾼 후 patch 하는게 편하겠죠.

 

windows에서 흔히 쓰는 방법과 크게 다르지 않습니다. JMP! JMP!

 

 

 

<Fig1. Hooking 할 함수에 code patching 을 한 상태>

 

bx pc 명령어를 사용하여 제자리 JMP!

 

그리고 ARM mode로 변경합니다.

 

 

 

<Fig2. Hooking 할 함수중 일부. ARM mode로 변경>

 

ldr 명령어를 통해 pc counter가 가리키는 곳의 주소로 다시 JMP! 합니다.

 

*gdb에서는 끝자리가 홀수 일경우 THUMM mode , 짝수일 경우 ARM mode로 출력합니다.

 

 

<Fig3. 다음 점프할 곳은 0x658984!>

 

0x658984는 저희가 입력한 Code가 있는 곳입니다.

 

 

<Fig4. 사용자가 지정한 custom function 으로 이동한 모습>

 

중간에 blx는 원본 함수를 호출한 건데요. 이 부분은 code patching으로 잘려나간 원본 함수의 초반 부분과

 

JMP 이후의 원본 함수의 주소 값으로 다시 되돌아가는 명령어가 있습니다.

 

<Fig5. intermediate code>

 

 

<Fig6. 되돌아갈 함수의 주소>

 

그리고 원본 함수 대신 실행된 code는 저희가 지정한 dylib에 있어야 정상일테니 확인해봅시다.

 

<Fig7. hooked code가 지정한 dylib에 있는 것을 확인한 모습>

 

 

[+]Conclusion 


 

 

 

<Fig. 뭐래는거야>

 

 

제가 작성했는데도 뭔 소린지 모르겠어요.

 

정리해봅시다. 

<Fig8. Hooking의 흐름>

 

이렇게 보니 별거 아니군요?

 

비슷한 방법이다 보니 Hooking 을 방지 하는 방법도 windows와 비슷한 맥락에서 막을 수 있을거 같습니다.

 

1차적으로는 탈옥되었는지 여부를 판단하면 되겠죠.

 

실제로 skype는 이를 감지하여 비정상 동작을 하더군요. 게다가 gdb도 못붙이게 하구요.

 

아무튼 , 기회가 된다면 다음엔 탈옥시 kernel patch 하는 부분을 살펴볼까 합니다.

 

근데 iOS image내부에 kernelcache 가 IV , Key가 안맞는지 풀리지 않아서 언제가 될런지는 모르겠네요.
 

 

 

 

 

 

 

 

 


Posted by LinkC

2012.09.29 13:47 System

 [+] Introduction


 

모든 Thread가 멈춰있는데 memory 가 변경되는 process가 있을까요?

 

<Fig0. 흥미로운데 이거>

 

 

 

 

[+] Analysis 


 

몇가지 짐작 해 볼 수 있는 건 있네요.

 

1. Remote Create Thread를 이용한 다른 프로세스의 간섭

 

 - 아, 이건 결국 Thread를 Target Process에 생성하고 그 Thread도 멈춰있다고 생각하면 기각이겠군요.

 

2. Shared Memory 를 이용한 접근

 

 -  Thread는 정지 하고 있어도 값이 변경되니 이게 정답일까요?

 

 

하지만 iOS의 sandbox가 출동하면 어떨까?

 

Windows 는 Process 서로 간의 벽이 낮지만 iOS는 상당히 폐쇄적입니다.

 

모래 상자 하나씩 잡고 각자 놀아요.

 

하지만 예외가 있는데요.

 

Audio 처리가 바로 그 중 하나 입니다.

 

iOS의 Audio 처리는 Core Audio 를 기반으로 하죠.

 

다음은 iOS Dev Center에서 가져온 Core Audio 구조입니다.

 

 

<Fig1. iOS Core Audio architecture>

 

 

Core Audio는 kernel realtime thread 를 지원받는 Frame work 인데요.

 

Audio unit 을 통해 이에 접근 할 수 있고 Real time 으로 처리되는 Audio Data를 얻을 수 있다는 거죠.

 

아래 그림을 통해 좀 더 쉽게 이해해봅시다. 마찬가지로 DevCenter 펌

 

 

<Fig2. Audio processing graph>

 

앞서 Real time 처리 된다고 언급 했던 것을 기억하시나요?

 

AudioUnitRender 함수를 호출시 얻어오는 Audio Data가 그 시간의 정적인 Data를 Copy 해오는게 아니라

 

계속 변하고 있는 Memory 의 주소를 가리킨다는 것입니다.

 

공유 메모리와 비슷한 개념으로 이해하시면 될 것 같군요.

 

다만 User level process간 통신이 아니라 kernel 과 User level process간의 공유메모리로 보심이 옳겠죠. 

 

 

 

<Fig3. gdb 로 Bp가 걸려 있는 시점에서 같은 주소를 Dump했을 때 Data가 달라지는 모습>

 

[+] Conclusion 


처리 방식이 상당히 흥미롭습니다.

 

Audio Unit을 사용하는 Process가 많으면 많을수록 Overhead가 줄어들것이고 kernel 과의 통신을 통해

 

sandbox 의 존재 의의를 지켰다는 점에서도 이 감성은 높이살만 한 거 같습니다.

 

흠.. kernel의 Audio module 쪽에 접근하여 경계를 깰 수 있다면 이것 또한 재밌는 이슈가 되겠네요.

 

내용 정리는 위키에게 맡깁니다.

 

 

 

다음 포스팅은 iOS Hooking에 관한 것이 될 거 같군요.

 

올해 안에 다시 뵙도록 하겠습니다 ㅂㅂ

 

 

Posted by LinkC

2010.08.05 13:51 Etc../잡담

지난 3일

iPhone은 보안제품이 필요없다고 외치던 사람들을 비웃기라도 하는듯

iPhone / iPad / iPod 에서 모두 Remote Exploit 가능한 0-day가 등장했습니다 XD


그림1. vupen 에 등재된 iphone 취약점

에서 보시면 알겠지만 이미 Critical 한 취약점으로 분류되어 등재되어 있구요

어떤 식으로 이 Exploit 이 이루어지느냐 하고 찾아봤더니


그림2. Exploit의 적용점 

그림을 보면 아시겠지만, 많은 사람들이 초기에 FlateDecode에 취약점이 있다고 생각했으나

결국 CFF와 kernel 취약점의 아름다운 조화로 이루어진 결과였음이 밝혀졌습니다

PDF 문서의 CFF [ Compact Font Format ]을 처리할때 메모리 충돌이 일어나는 것인데, 이를 이용해서 

공격자가 임의의 코드를 삽입할 수 있습니다

이에 짬뽕으로 적용된 커널 취약점은 권한을 상승시키고 Sand box 제한을 우회하는 것을 가능케 합니다

한마디로 PDF 파일 하나로 타인의 폰을 정 ㅋ 벅 ㅋ 할 수 있게 된겁니다


라는 유명한 아이폰 탈옥 자동화 사이트에서 이용된 PDF 파일이 시발점 [욕 아닙니다 :D] 

이 되었다고 합니다

아직 애플에서 대응은 없으며, 악의를 가지고 있는 사이트에 접속만 하면 그대로 자기 폰은

알 수 없는 악의 무리의 마수에 빠지게 됩니다

더구나 , Adobe 문제도 아니고 Apple 측의 문제로 확실시 되고 있어

아이폰 사용자들의 불안은 커질 수 밖에 없겠죠



실제 Exploit 장면이 담긴 영상입니다

악의적인 목적은 아니지만, 이정도면 얼마나 심각한지 아시겠죠?
현재 치료법... 이라고 말하긴 뭐하지만

임시 방편으로써, 위와 같은 PDF 파일을 실행 시킬때 사용자의 의사를 묻는 그런 앱이 등장했습니다


그림3. 임시 방편으로 등장한 App

매우 아이러니 하게도 현재 취약점은 Jail Break 여부에 상관하지 않고 적용되고 있는데

Jail Break 한 iPhone 에서만 작동이 가능하다는군요 


흠.. 아무튼 

이번건 꽤 큰 이슈가 될 것 같군요

한창 사람들이 스마트폰에 눈독을 들이고 있는 참이니까요

우리나라만 해도 벌써 전체 핸드폰 수가 인구수를 넘어섰고

스마트폰 사용자는 괄목할 만한 성장세를 타고 있다고 합니다

이는 아이폰 4가 출시되면 더 가속화하겠죠

아이폰 4가 나온 다른 나라야 뭐 할말도 없구요

저는 아직도 노예계약이 1년도 넘게 남은지라 꿈도 못꾸고 있지만요 ㅠ,.ㅠ

봇넷이 이런 취약점으로 이용되면 어떨까요?

대 스마트폰 봇넷 시대가 열리는 걸까요? :D




 





Posted by LinkC
이전버튼 1 이전버튼

블로그 이미지
LinkC

태그목록

Tistory Cumulus Flash tag cloud by BLUEnLIVE requires Flash Player 9 or better.

공지사항

Yesterday301
Today84
Total298,301

달력

 « |  » 2018.02
        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      

최근에 받은 트랙백

글 보관함


. .