'2014/01'에 해당되는 글 1건

  1. 2014.01.04 Executing shellcode in android using vulnerable library (1)

2014.01.04 17:57 System


[+] Blah Blah 

 


 

 

2014년 첫 포스팅입니다.

 

마지막 포스팅이 13년 5월 이었으니까 하 죽일놈의 게으름.

 

최근에 모바일쪽 일을 하고 있어서 이번 글 역시 모바일 관련 이야깁니다.

 

android app을 사용하여 shell 을 띄우려면 어떻게 해야 할까요?


크게 2가지 방법이 있습니다.

 

1. App 내에서 shell 실행

 

2. App 에서 호출하는 library 내에서 shell 실행

 

전자는 dalvik vm 내에서 , 후자는 library 가 직접 실행하게 됩니다.


전자의 경우는 app 내의 취약점이라기 보다는 repacking 공격에서 사용되겠죠.

 

본문은 후자의 방법을 통해 취약점을 공략해보는 방법을 기술합니다.

 

 


[+] about vulnerable library

 


 

pc에서 사용되는 많은 library들이 cross-compile을 통해 모바일에서도 재사용되곤 합니다.

 

그 덕에 취약한 library도 자기 영역을 확장시켜가고 있고 여러 플랫폼으로 배포가 이루어진 library들은

 

비단 하나의 플랫폼에만 취약한게 아니게 되었습니다.

 

예를 들어 libpng 라는 이미지 처리 library를 들어보죠.

 

해당 library는 open source project로서 linux의 system library로 실제 사용되고 있으며

 

cross-compile이 가능한 덕에 android에서도 사용하는 사람이 있죠.

 

compile 옵션과 compiler 버전에 따라 약간 달라질 수 있겠지만 취약점이 있으면 사용하고 있는 다른 플랫폼도 취약점에

 

노출될 수 있다는건 누구나 다 알 수 있습니다.  

 

더구나 이미지 파일의 특성 상 파일 전송을 통한 공격이 매우 수월한 것은 두 말 할 필요도 없겠죠.


그런 이유로 android app 내부에서 jni 형태로 호출되는 취약한 image library 가 본문의 희생양으로 출현해주셨습니다.


<Fig 1. libpng 공식 사이트에 올라온 보안 위협>

 

 



[+] attack

 


 

 

libpng의 취약점 중 입맛에 맞는 것으로 하나 골라 공격합니다.

 

x86 shell code 대신 arm shell code를 삽입하고 환경에 맞게 stack 위치만 조정해주면 공격에 성공합니다.

 

참 쉽죠?

 

는 구버전에서만 가능한 일이고, 최신 버전에서는 DEP 덕에  ROP를 사용해야 합니다.

 

ASLR이 적용되어 있기는 하나, system library는 아예 고정적으로 사용하고 있는 경우도 많고 그렇지 않다하더라도

 

대부분 system library 들은 load되는 memory 위치가 대동소이 합니다.

 

그렇기 때문에 ROP 체인을 구성 하실 때, 하나의 system library에서만 모아서 구성하시면 모든 파일에 ASLR이 적용되어있더라도

 

공격 성공 확률을 높이실 수 있습니다.

 

더구나 Process가 다르더라도 system library 들은 같은 위치에 load되는 경우가 많아 한 앱의 memory map을 구했다고 하면

 

공격은 거저 먹는게 되죠. 

 

<Fig2. 두 Process의 memory map 비교>

 

 

필자의 경우 ARM shell code의 재활용을 위해 mprotect를 활용하여 stack에 권한을 주고 shell 을 띄우는 방법을 선택했고,

 

전체 code는 아래 Fig3 처럼 구성될 수 있습니다.

 

<Fig3. ROP 체인 구성>

 

물론 위 code는 얼마든지 유동적으로 바뀔 수 있습니다.

 

모로가도 서울만 가면 되니까요.

 

정리하자면 아래와 같습니다.

 

 

<Fig4. ROP 체인 구성 정리>

 

 

원하는 명령어를 포함하는 ROP 체인 검색 스크립트 +  ROP 체인 구성 스크립트 + 취약 image 생성 스크립트

 

대략 이 3가지 스크립트가 사용된거 같네요.


이렇게 만들어진 취약한 Image를 피해자에게 전송하면 파일 내에 삽입된 code가 실행되고 

 

최종적으로 reverse shell을 얻을 수 있습니다.

 

 

<Fig5. reverse shell을 얻은 모습>




 

[+]  More and more


 

library 내에서 execve 류 함수가 실행되면 Process가 아예 바뀌기 때문에 앱이 죽게 됩니다.

 

물론 시스템에서 재 실행 시켜주기 때문에 잠깐 깜빡거리는 수준이지만 ..


앱이 아예 죽지 않고 임의의 코드를 실행하려면 아래 조건을 만족해야 합니다.

 

1. execve 류 함수 사용 X 

 

2. fork 사용 X [ System 함수는 fork & execve의 조합 사용이므로 역시 불가 ]

 

library 내에서 fork를 사용하게 되면 Fig6 과 같이 정상적으로 생성되지 않고 zombie가 됩니다.


android app은 fork 함수를 지원하지 않는 거 같네요.

 

<Fig6. fork 사용 후 Process>

 

3. stack 복구

 

취약점 발생 구간과 메모리 참조 영역을 주의 깊게 살펴보셔야 합니다.


덮어 씌운 부분이 후에 참조될 경우 crash가 날 수 있으니까요.


취약 함수가 return 값을 가지고 있는지, 가지고 있다면 어디서 참조 하는지 ..


호출된 jni 함수가 아예 void return 이면 그 쪽으로 단번에 넘어가버리는 게 가장 좋겠죠.

 

아무튼 이런 조건이 맞는다면 execve 함수 사용이 제한되기는 하나 특정 코드는 무인지 공격이 가능하게 됩니다.

 

예를 들어 stack 에 권한을 주는 코드를 무인지로 실행한다던가 말이죠.

 

 

 

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

블로그 이미지
LinkC

태그목록

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

공지사항

Yesterday73
Today48
Total320,221

달력

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

최근에 받은 트랙백

글 보관함


. .