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

외국에 공개된 멋진 코드는 아래와 같다...

더보기







 

모토로이(Motoroi) 루팅 2번째 실패기...(XT720)

Posted 2010/04/14 22:21 by silverbug


[실패기]
여러 방법을 통해 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. 커널 취약점 나올때까지 죽어라 기다린다........................
(이걸 우리는 자포자기라고 부르죠. 거지근성..)


아이폰을 버리고 모토로이를 선택한 이유는 단 하나.... 미개척 분야... 앞으로의 미래....

근데 말이지.................................. 아이폰이랑 아이패드가 땡기는건 어카니~~ 어카니~

아들아!! 널 위해 꼭 루팅 해주마..!! 네가 컸을때는 자유로운 세상이.... ㅋㅋㅋ

Android Rooting(루팅)에 대한 오해와 진실

Posted 2010/03/16 14:43 by silverbug

루팅에 관해 많은 사람들이 살짝쿵 오해를 하는거 같아서 정리를 해보도록 합니다.

* 루팅하면 정상적인 업데이트를 할 수가 없으며, A/S가 불가능 하데요..

루팅이란... 루트를 획득하는 방법입니다. root .. uid가 0인 최고 관리자를 말하죠.

현재 안드로이드(Android)를 살펴보면, 모든 일반 프로세스는 app_숫자 형태의 유저명을 가지고 프로세스가 생성이 됩니다. (크게 봤을때 Android는 root/system/일반유저 3개의 계정으로 나눠진다고 봐도 크게 무방함)

즉 일반 유저로 프로세스가 생성(어플리케이션 실행)이 된다는거죠.

자 여기서 루팅하는 방법을  짚고 넘어가 보도록 하죠.

- 커널 취약점 이용하여 root 권한 획득

-  펌웨어 업데이트를 통한 root 권한 획득

- 부트로더 수정을 통한 업데이트.

3가지 방법으로 크게 나눠진다고 볼 수가 있겠습니다.

자 그럼.. 루팅하면 정말로 정상적인 업데이트가 불가능 하고 A/S가 불가능할까요?

커널 취약점을 이용하거나, 부트로더를 통해서 su 명령어를 복사하는 방법을 통해서 root 권한을 획득하는 방법은 단지 권한만 획득하는 과정이기 때문에.. 업데이트 할때 루팅을 했는지 체크 할 방법이 없습니다. 또한 A/S 센터에 가져가기 전에 su 명령어 등을 삭제하시면 A/S 센터에서도 루팅 했는지 알수가 없습니다.

물론 부트로더를 통해서 루팅을 했다면.. 로그가 남기 때문에 추측은 가능하겠지만, 추측은 추측일뿐입니다.

여기서 말하는 업데이트 불가/A/S 불가는 펌웨어를 업데이트 해버리거나, 부트로더를 업데이트 하는 행위에 대해서는 탐지가 가능하기 때문에, 아마도 제약이 있을 수 있습니다.

롬 업데이트 / 부트로더 패치 등만 하지 않으시면 루팅... 아무런 제약이 없을 것입니다.

부트로더 통해서 update.zip 파일 SD 카드에 넣고 하시는 분들은 zip파일 열어보시면 스크립트 존재할껍니다. 단지 su 명령어 복사하고 퍼미션 수정하는거라면 편하게 하셔도 될듯....

커널 취약점 이용해서 하는 방법 (특정 어플리케이션 깔아서 원샷~ 실행) 또한 문제 없습니다.

단지 조심해야 할껀 위에 말씀 드린대로~ 롬 업데이트... 부트로더 패치만 조심하시길.....

루팅 후 파티션 정보 변경, SD 카드 사용으로 메모리 공간 확보, 쓸데 없는 SK~ 프로그램 삭제, 불 필요 프로세스 제거 등... 충분히 많은 일들을 할 수 있습니다.

현재 국내 출시된 모토로이는 루팅이 되지는 않지만... 아래 글을 참조하면 충분히 가능성은 존재합니다. RSA 서명된 업데이트 파일 하나만 있으면 Game Over.....

그냥 쓸데 없는 잡담이었습니다.


모토로이(XT720) 루팅(Rooing) 시도. 실패....

Posted 2010/03/08 14:25 by silverbug

1. [Why] 왜? 우리는 최고 권한인 루트를 획득하려고 하는가...
  - 내가 정당한 댓가를 지불하고 구입한 기기로, 기기의 활용성(?)/성능(?)을 극대화 시키기 위해.(안드로이드에서 제공되는 어플은 한계가 많음)
  - 현재 안드로이드는 용량 제한으로, 100메가 정도 사용 가능. (허나 최고 권한을 획득하면, 용량 제한 해결 가능)

2. [How] 어떠한 방식으로 최고 권한인 root를 획득할 것인가?
  - 기존 외국에서 공개된 루팅 방법 시도.
  - 취약점 분석.

[기 발표된 루팅 방법]

  - 커널 취약점 
 초창기 루팅 방법은 커널 취약점을 이용한 방법으로 루팅을 했었다. 리눅스 기반으로 만들어진 안드로이드는.. 리눅스 커널 취약점에 노출되어 있었고, 이를 활용하여 루팅 가능했음.

취약점 : CVE-2009-2692
Android exploit : http://milw0rm.com/sploits/android-root-20090816.tar.gz

그외 커널 취약점.
CVE-2009-3547
CVE-2009-2848
CVE-2009-3624
CVE-2009-2584
CVE-2009-3286
CVE-2009-1895
CVE-2009-1527

다 테스트 해볼 수가 없어서 가장 마지막에 나온  pipe 취약점(CVE-2009-3547)만 테스트 해봤으나, killed...  패치 된걸로 파악...

다음 새로 나올 커널 취약점을 기대해야 할듯....


* 모토로이 가능성 : 취약점 패치 된걸로 파악됨
  - 부트로더 recovery를 통한 수정.
    이 방법은 SD Card에 업데이트 할 파일과 설정 파일을 넣어두고 (구성을 맞춘 후 update.zip 으로 압축) SD Card에 존재하는 업데이트 설정파일을 통해 su 명령어 설치 및 퍼미션, 마운트 읽기 쓰기 모드로 재 설정을 통해 root를 획득하는 방법이다. (su 명령어를 통해 바로 root로 진입.)

  1. update.zip 파일을 sd카드에 넣어둔다.

  2. 전원 OFF

  3. 카메라 버튼 +  전원 버튼을 꾸욱~ 눌러주면 부트로더 모드로 진입하게 된다.
   진입했으면 두번째 apply sdcard:update.zip 을 선택해 준다.

  4. 완료메시지 확인 후 재부팅

  5. su 명령어를 통해 root 권한 획득.

update.zip에 존재할 스크립트 updater-script
/*
mount("MTD", "system", "/system");
ui_print("Rooting your phone...");
package_extract_file("system/bin/su", "/system/bin/su");
package_extract_file("system/app/Superuser.apk", "/system/app/Superuser.apk");
set_perm(0, 0, 04755, "/system/bin/su");
set_perm(0, 0, 0644, "/system/app/Superuser.apk");
unmount("/system");
*/



* 모토로이 가능성. Low....

일단 테스트 에러....
Verifying update package...
E:EOCD marker occurs after start of EOCD
E:signature verification failed
Installation aborted


왜 안될까?
   - 실제 부트로더 소스 코드를 살펴보면 왜 안되는지 알수가 있다.
       커널 소스를 살펴보면, update.zip 파일의 사인을 체크하게 되어 있다. (RSA 공개키 기반)

체크 순서를 살펴보면..
  1. zip 파일 제일 마지막 6바이트를 가져와 검증.
  2. EOCD 헤더 검증 22바이트
  3. SHA + RSA 검증

공개키는 /res/keys에 존재하는 키를 사용. 즉 키를 알지 못하면 update.zip 파일을 서명할 수가 없기 때문에, 기존의 방식은 사용할 수가 없다.

근데 드로이드/마일스톤은 된다던데?? 어떻게 했을까??!! 기존 버전이었나? 최신 버전도 되나?? 좀더 연구를 진행....................................

최근 모토로이 자체 서비스의 취약점을 찾고 공격을 진행하였으나, 일반 권한으로 실행... 좌절... OTL.....

루트를 획득하는 그날까지.... 영원하라...
 

p.s
 현재 상황 :: RSA 키로 사인된 업데이트 파일하나만 배포되면.. (업데이트 시 사용되는 파일) 루팅 가능할걸로 추정...  열심 분석 끝에 RSA 인증 부분까지 넘어왔음.           
RSA 재 사인 하면 가능.


MOTOROI(XT720) A/S & SKT 사용 후기

Posted 2010/02/19 17:52 by silverbug

SKT에서 떠들석 하게 광고 하는 모토로이입니다.

안드로이드에 관심이 많았던 저는  A/S 2년 정책에 혹~ 반해서 12년 쓰던 번호를 버리고 010으로 번호 이동...(LGT->SKT)

모토로이 A/S
근데 실수로 2일 만에 휴대폰 떨궈서 앞 강화 유리 깨짐. 

사용자 실수라 유상 수리 예상하고 A/S 받으러 감.

부품 없다고 A/S 거부.

A/S 2년이라매~~~~~~~~~~~~ A/S 안되는건 머지??

고객 센터 전화... 부품 언제 들어올지 기약 없음. 무조건 기다리라.. 죄송하다고만 함...

(모토로라~야 나 고객이거든.. 물건 팔아 먹고 장땡? 새 제품 팔 물건은 넘치고 고쳐줄 부품은 없어???? 고객한테 그렇게 하쇼..)

SKT 고객대응
안되겠다 싶어서 임대폰이라도 쓸 생각으로 SKT에 문의... 3일만에 답변 도착.

임대폰 : 신규 가입 14일 이전 고객 임대폰 지급 불가.
기기 변경 : 신규 가입 14일 이전 고객 기기 변경 금지..


그냥 휴대폰 떨어뜨린 고객인 내가 잘못했으니 휴대폰 쓰지 말라고? 그러면서 요금은 다 받아 먹겠다고???

SKT.. 생각대로 T???? 니들 생각대로 하면서.. 그게 생각대로 T냐???



아래 보상 기준은 ... 니들한테는 적용이 안되나부지??

품질보증기간이내 수리용 부품이 없는 전기통신기자재 보상기준(소비자과실로 인한 수리)

-유선전화기 등의 전기통신기자재를 사용하던 중, 품질보증기간이내 소비자 고의,과실로 수리가 필요하나 수리용 부품이 없어 수리가 불가능한 경우 보상기준은? (부품보유기간이내)

-유상수리에 해당하는 금액징수 후 제품교환요구 가능함


지금 생각으로는 휴대폰 돈 다 지불해버리고... 다 깨버리고 싶은 심정이네..


잘 먹고 잘 살아라... 니들은 고객이 돈으로 밖에 안보이지??







본 글은 가능성(?)을 염두해두고 쓴 글이며, 감청과 전혀 관련이 없습니다.



남자들이라면(?), 많은 사람들이 저런 페이지를 한번쯤 보았을것이다. 훔............

그냥 어떤식으로 사이트를 막는지 궁금해서 분석해본 결과를 토대로 작성해보도록 한다.

과연 어떤식으로 막을까???

추측 1.
   - 사용자가 웹사이트를 방문하기 위해 인터넷 익스플로러의 URL 창에 도메인을 치게 되면, 자신의 컴퓨터는 그 도메인의 아이피를 DNS 서버에 요청하여 아이피를 얻어오게 된다.
그리고 그 아이피로 접속하여, HTTP 헤더를 보내고 응답을 받아 웹페이지를 뿌려준다.

 즉 이러한 DNS 서버에 도메인을 요청할때,  경고 페이지가 있는 IP를 돌려줘서, 경고 페이지로 접속하게 한다.

추측 2.
  - 도메인에 해당하는 IP에 한해, 무조건 경고 페이지가 존재하는 서버로 돌려버린다.

추측 3.
  - 패킷을 까서, HTTP 헤더중 Host: 필드를 보고, 불법 사이트일 경우, 경고 서버 페이지로 리다이렉션 시킨다.


추측 1에 대한 실험.
  - DNS 서버를 외국 서버로 맞춰놓고 테스트 결과, 이상무.
  - nslookup 결과, 실제 불법 사이트 아이피 돌려줌. 이상무.

추측 2에 대한 실험
  - ip로 바로 접속했을 경우, 정상적인 접속 가능함. 이상무

추측 3에 대한 실험.
  1. nslookup을 통한 ip조회.
  2. ip로 접속.
      telnet ip 80
  3. 간단한 헤더 요청.
     GET / HTTP/1.0
  4. 정상적인 응답. - 이상무 -
  5. 다시 헤더 요청
     GET / HTTP/1.0
     Host: 불법사이트
  6. 차단. warning.or.kr 사이트로 이동
  7. 혹시 모든 아이피에 대해서 패킷 보고 검사?? - 테스트 -
  8. 외부 다른 서버의 아이피로 헤더 요청
     GET / HTTP/1.0
     Host: 불법사이트
  9. 차단 하지 않음. ( 그래야지요~ )
  
  결론>
      위 방식은 dest ip 로 가는 패킷 중 Host: 불법 사이트 에 대해서만 필터링하는 것으로 파악.

      살짝 바꾸면, 외부 다른 패킷 감시 가능하것군.....................................................

질문>> 너한테 저런 차단 프로그램 의뢰가 왔다면 어케 할껀데??
답변>> 나도 저렇게 짠다. 방법 없다 -_-;

이글을 쓴 이유... ::  너무 오래 블로그 관리 안해서 ................................. 심심풀이용.....


믿고 살아야지요.. 아암 그렇구 말구요... 전에 뉴스 보니깐 댓글 실시간 감시 한다던데....
우움.. 이미 기술은 갖춰져 있는 상태고.. 바로 시행 가능하겠네요.... 냠냠.....................

싸이월드 추적기 불법으로 판결. 쿠키값 저장했다고~~~~...
그럼 저거 패킷 저장하면 불법인데........ 쿠키값은 빼고~ 저장해야지요.. 그럼 누가 누군지 어케 알지 -_-;; 냠 심심풀이용............. 글....... 

이 글을 읽는 당신은 낚였습니다.



Windows 용 API라서 Wine 소스에 있는 VariantTimeToSystemTime 함수를 뽑아서 재작성해보았다.

Linux , PHP 등에서 사용하면 될듯.. 혹시나 찾는 사람들이 있을까봐..

소스 코드는 절대 완벽하지 않으며, 재 조립하면서 문제점이 있을 수 있음.

#include <math.h>

typedef long            HRESULT;
#define DATE_MAX 2958465
#define DATE_MIN -657434
#define S_OK 0
#define TRUE 1
#define FALSE 0
#define E_INVALIDARG -1
#define IsLeapYear(y) (((y % 4) == 0) && (((y % 100) != 0) || ((y % 400) == 0)))
#define FAILED(stat) ((HRESULT)(stat)<0)


typedef unsigned short WORD;
typedef unsigned long ULONG;
typedef unsigned short USHORT;
typedef unsigned char BYTE;

typedef struct _SYSTEMTIME{
        WORD wYear;
        WORD wMonth;
        WORD wDayOfWeek;
        WORD wDay;
        WORD wHour;
        WORD wMinute;
        WORD wSecond;
        WORD wMilliseconds;
} SYSTEMTIME, *PSYSTEMTIME, *LPSYSTEMTIME;

typedef struct {
    SYSTEMTIME st;
    USHORT wDayOfYear;
} UDATE;


더보기


int VariantTimeToSystemTime(double dateIn, LPSYSTEMTIME lpSt)
{
  UDATE ud;


  if (FAILED(VarUdateFromDate(dateIn, 0, &ud)))
    return FALSE;

  *lpSt = ud.st;
  return TRUE;
}

int main()
{
char szBuff[8] = { 0xab, 0xaa, 0xaa, 0xaa, 0xe2, 0x87, 0xe3, 0x40 }; //2009/07/05 02:00:00
double *zz = (double*)szBuff;

SYSTEMTIME system_time;

VariantTimeToSystemTime(*zz, &system_time);
printf("%04d.%02d.%02d, %02d:%02d:%02d\n",
system_time.wYear, 
system_time.wMonth,
system_time.wDay,
system_time.wHour,
system_time.wMinute,
system_time.wSecond);
}

KBS 웹 사이트 해킹? DNS 오류? 직원 실수?

Posted 2009/07/09 21:06 by silverbug
KBS 접속 하니 네이버로 이동한다????

사이버 테러 DDOS 문제로 골치 아픈 시국에... 또 다른 해킹이 퍼지는건 아닌가..
급 신경이 곤두선 가운데, 분석을 해보았다..

(인터넷 커뮤니티에서 해킹 아니냐. kbs가 해킹 당한건가?? 트래픽 몰아주기(?)냐.. 말들이 많아서, 미리 사전 대응책도 마련할 겸 분석해보았다.)


인터넷 커뮤니티에서 많은 사람들이 네이버로 접속한다고 해서, 분석 해 본 결과 해킹은 아닌 것으로 추정된다.

아래 분석을 통해 확인해보면 다음과 같다.

정상적인 kbs ip
#ping kbs.co.kr
Pinging kbs.co.kr [211.233.32.35] with 32 bytes of data:
Reply from 211.233.32.35: bytes=32 time=17ms TTL=241

바뀐 kbs ip
#ping kbs.co.kr
Pinging kbs.co.kr [116.126.87.xx] with 32 bytes of data:
Reply from 116.126.87.xx: bytes=32 time=17ms


kbs.co.kr을 wget 을 통해 페이지를 긁어와봤다.

fw:tmp {108} wget http://www.kbs.co.kr/
--2009-07-09 20:35:40--  http://www.kbs.co.kr/
Resolving www.kbs.co.kr... 116.126.87.xx
Connecting to www.kbs.co.kr|116.126.87.xx|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: `index.html'

    [ <=>                                   ] 198         --.-K/s   in 0s

아래와 같이, 네이버로 프레임이 이동한걸 볼 수가 있다.

fw:tmp {128} cat index.html
<HTML>
<HEAD>
<meta http-equiv="Content-Type" content="text/html; charset=euc-kr">
<TITLE>안녕하세요</TITLE>
</HEAD>
<FRAMESET ROWS="100%,*" border=0>
<FRAME src=http://naver.com></FRAMESET>
</HTML>

처음에는 해킹을 의심했으나, 여러 분석 끝에 DNS 문제로 추정되었다.

DNS 문제라 추정하고, kbs.co.kr 후이즈 검색을 통해 등록된 네임서버로 접속하여, 확인해보았더니 역시나, kbs 아이피가 아닌 다른 116.126.87.xx 아이피 주소가 찍혔다.

ns1.whoisdomain.kr 로 등록되어 있었다.

위 네임서버로 검색된, 도메인들을 찾아 검색해본 결과, 후이즈 도메인 포워딩 서비스인걸 확인할 수가 있었다.

[변경 된 IP]
fw:tmp {125} nslookup
> server ns1.whoisdomain.kr
Default server: ns1.whoisdomain.kr
Address: 218.50.6.252#53
> kbs.co.kr
Server:         ns1.whoisdomain.kr
Address:        218.50.6.252#53

Name:   kbs.co.kr
Address: 116.126.87.xx

[아직 변경되지 않은 IP]
fw:tmp {133} nslookup
> server 164.124.101.2
Default server: 164.124.101.2
Address: 164.124.101.2#53
> kbs.co.kr
Server:         164.124.101.2
Address:        164.124.101.2#53

Non-authoritative answer:
Name:   kbs.co.kr
Address: 211.233.32.35


kbs.co.kr에 접속이 될때가 있고, 네이버로 이동할 때가 있고 각각 틀린것은 네임서버가 여러군데에 많이 있는데, 그 전체 서버들이 아직 전부 적용이 되지 않은 이유 때문이다.

[후이즈 정보]

문제 된 시점에서의 후이즈 결과
#whois -h whois.nic.or.kr kbs.co.kr
[whois.nic.or.kr]

query: kbs.co.kr

# KOREAN

도메인이름                : kbs.co.kr
등록인                    : 한국방송공사
등록인 주소               : 서울 영등포구 여의도동 한국방송공사 18번지
등록인 우편번호           : 150790
책임자                    : 한국방송공사
책임자 전자우편           : domain@kbs.co.kr
책임자 전화번호           : 02-781-2753
등록일                    : 1994. 06. 20.
최근 정보 변경일          : 2009. 07. 09.
사용 종료일               : 2009. 10. 15.
정보공개여부              : Y
등록대행자                : (주)후이즈(http://whois.co.kr)

1차 네임서버 정보
   호스트이름             : ns1.whoisdomain.kr


문제 해결 후 후이즈 결과
#whois -h whois.nic.or.kr kbs.co.kr
[whois.nic.or.kr]

query: kbs.co.kr

# KOREAN

도메인이름                : kbs.co.kr
등록인                    : 한국방송공사
등록인 주소               : 서울 영등포구 여의도동 한국방송공사 18번지
등록인 우편번호           : 150790
책임자                    : 한국방송공사
책임자 전자우편           : domain@kbs.co.kr
책임자 전화번호           : 02-781-2753
등록일                    : 1994. 06. 20.
최근 정보 변경일          : 2009. 07. 09.
사용 종료일               : 2009. 10. 15.
정보공개여부              : Y
등록대행자                : (주)후이즈(http://whois.co.kr)

1차 네임서버 정보
   호스트이름             : kbsnt.kbs.co.kr


네임서버 정보는 누가 바꿨을까? 응? 누구? 응? 누가 바꿨을까!! 독해~~~


후이즈 실수인가?!!
후이즈에 등록된 kbs 계정을 누군가 훔쳐서 바꾼것인가?

아직도 의문점이 남긴하다. 며느리도 몰라

급하게 쓰느라 글이 ㅠ.ㅠ.ㅠ.ㅠ.ㅠ.

결론은.. kbs.co.kr 네임서버가 포워딩 서비스로 되어 있어서, 위와 같은 문제가 생겼다입니다.


// 추가
글쓴 시간 9시 10분경.... 현재 KBS가 정상적으로 동작한다.

역쉬나 도메인 네임서버 설정이 포워딩 서비스로 이동한거였군..

//추가
DNS서버가 당했다라고 말씀하시는 분들이 있는데...
DNS 서버가 당한건 아니고...  도메인 정보(네임서버 부분)가 변경(후이즈 포워딩 네임서버)으로.. kbs.co.kr 도메인이 후이즈 포워딩 서비스로 잠시 등록된겁니다.

즉 해킹이라면, 후이즈에 있는 KBS계정이 해킹당했을것이고...
실수라면........... 도메인 관리자(후이즈 또는 KBS 도메인 담당자) 실수겠죠..

0day openssh remote exploit

Posted 2009/07/07 11:40 by silverbug

Exploit은 아직 공개 되지 않고, 테스트 결과만 공개된 사항이라, 사실인지는.... 모르겠습니다만.. 실제 Exploit이 공개 된다면 상당한 파장(웜등으로 인해)이 예상되네요..

redhat enterprise linux 5.3의 openssh 4.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

더보기


출처 : http://baoz.net/0day-openssh-remote-exploit/

Apache 설정 문제점 (mod_mime Module)

Posted 2009/04/15 13:48 by silverbug

위 취약점은 오래전 발견하여, 국XX에 신고 및 아파치 재단에 알렸으나, 국XX은 설정상의 문제라 어찌할 수 없다는 답변을 받았고, 아파치 재단은 설정에서 수정하면 되니, 소스 코드에서는 수정할 이유가 없다. 원래 기능일 뿐이다라고 답변..

국내 많은 보드들이 위험한데... 패치해주길 바라는 마음에서...
(국내 취약한 보드들로 인해 위험하여, 그냥 묻어둘려고 했으나 sans에서 발표하는 바람에 그냥 올리게 되었음.)

   일반적인 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 파일을 업로드 하여, 웹 서버의 사용자 권한을 획득할 수 있다.

 

 

   문제점 해결 방법

가)  Application 에서의 보안

     파일 업로드 기능을 가지고 있는 웹 어플리케이션에서 확장자 체크를 끝부분만 하지 않고 임시적으로 전체 파일명에 대해 필터 링 기능을 가지고 있어야 한다

     등록 불가능한 확장자를 체크하는 방식보다는 등록 가능한 확장자만을 체크하여 필터링 하여야 한다.

     파일을 업로드 할 때 실제 파일명은 데이터베이스에 기록하고, 실제로 파일이 저장될 때 파일명/확장자를 임의적으로 저장(File, DB)하도록 한다.

 

나)  httpd.conf 파일 수정

FileMatch를 사용하여 확장자 끝부분($)만 비교하도록 설정한다.

 

다음과 같다.

 

CGI 파일 확장자(다른 확장자 사용시, 그에 맞는 확장자 확장 설정 필요)

<FilesMatch \.cgi$>

SetHandler cgi-script

</FilesMatch>

 

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 문서는 다운로드 받아서 보세요!~

« PREV : 1 : 2 : 3 : NEXT »