안녕하세요~

SSG 입니다.

오랜만에 블로그에 글을 쓰네요 :)

이번 SSG에서 신입생들의 학습에

도움을 주기 위해서 직접 제작한

커리큘럼을

공개하고자 합니다!!!!

박수!!

(짞짞짞짜자작짞짞)

(짞짞짞짜자작짞짞)

저희 SSG에서는 공부 방향을 잡는데 고민을 하는 신입 친구들을 위해서 제작했는데요.

꼭 이 커리큘럼대로 시행하는 것은 아니고 방향을 잡기 위한 참고용도로 사용하고 있습니다!

다른 분들에게도 도움이 되었으면 좋겠네요~

감사합니다 :)

끗 XD

쓱커리큘럼.zip

(160906 한글 깨짐 문제 수정)

-Smart Touch 사칭 안드로이드 악성코드 분석 및 제거 도구-

작성자 : 김남준(bunseokbot, 정보보호학과 15)

최근 Smart Touch를 사칭한 안드로이드 악성코드를 분석하였습니다.

파일명 - 13306WYXP.apk

MD5 - cbe7c630d78dd2f452f49680a4d5df2b

일단 파일의 전체적인 구조를 보면 아래와 같습니다

이렇게 메일 관련 자바 외부 라이브러리와, APKProtect를 적용한 난독화, Secondary DEX를 위한 a.dex 파일 등이 발견됨을 알 수 있었습니다. 또한 스미싱 악성코드에서 자주 발견되는 공유 라이브러리 파일인 libgame.so 파일도 발견된 것을 확인하였습니다.

이런 정보를 기반으로 악성코드의 기능을 추측해 보자면

- 기기 관리자를 통해 삭제 방해

- Secondary DEX 파일 로딩을 진행함, 단순 classes.dex는 그냥 loader로 작용함

- APKProtect를 통해 분석 방해

- 해당 감염자의 개인정보를 이메일로 전송

...

이렇게 나눌 수 있습니다.

일단 classes.dex 파일의 dalvik bytecode 파일의 구조를 분석한 결과

com/cocos2d/oui../ 디렉토리에 메인-엔트리포인트가 존재하는 것을 확인하였습니다.

그 중 주요 코드에 대해서 분석해 보면

실행하고 나서 "a.dex" 파일을 추가 로딩하는 부분을 확인할 수 있었고

일반적인 악성코드의 특징에서 나타나는 "부팅 완료시 자동 실행" 의 기능도 포함하고 있는 것으로 확인하였습니다.

classes.dex은 단순히 a.dex 파일을 로딩하기 위한 loader로써 작용하기 때문에 해당 파일의 추가 분석이 필요하여 진행해보니

app/plg_v67 하위에 있는 Plugin.smali 코드가 진짜 악성 행위를 하는 코드임을 확인하였습니다.

일단 로딩이 완료되면 가상 기기인지 확인하는 "휴대폰 번호가 15555로 시작하는지에 대한 검사도 진행합니다."

그 외에도 Network Operator에 대한 이름도 검사해 가상 기기의 특징이 나타나는 기기에 설치되었다면 앱을 종료합니다.

그 다음 대한민국에 있는 뱅킹 앱이 해당 단말기에 설치되었는지 확인을 진행합니다.

그 후 설치된 것이 있다면 바꿔치기를 진행하고, 악성 앱으로 바꿔치기 합니다.

정리해 보면

- 은행 앱 가로채기를 통한 개인정보 유출

인 앱인 것을 확인할 수 있었습니다.

이러한 악성 앱을 제거할 수 있는 도구를 제작하였습니다.

다운로드 링크 : http://smishing.kr/smart-touch-remover.zip

작동 방식은 exe 실행 방식인데 ADB를 이용해서 하기 때문에 먼저 USB 디버깅 활성화를 해주셔야 합니다.

인터넷에서 기종마다 활성화 방식이 다르기 때문에 해당 링크를 참고하시기 바랍니다.

http://mrhook.co.kr/207

"이외의 기종인 경우에는 해당 기종에 대해서 구글링을 해보시기 바랍니다."

활성화 한 다음에 해당 프로그램을 실행하시면 최근 발견된 악성코드의 경우에는 패턴(?)을 탐지합니다.

일단 탐지하지 못하는 경우에는.. 따로 이메일이나 댓글로 문의해 주시기 바랍니다. 

기기 관리자 같은 경우에는 자동으로 해제를 못하기 때문에.. 사람 손을 타야 합니다

물론 자동으로 기기 관리자로 이동 해주고, 화면에 나오는 대로 비활성화 하라고 시키는 대로 하면, 알아서 비활성화 되고

엔터 누르면 바로 삭제 됩니다

아래는 사용법입니다.

일단 휴대폰을 USB로 연결하고, 디버그 모드 설정 한 다음 remover 를 실행합니다

알아서 제거 시도하고. 기기 관리자 해제를 진행해 달라고 합니다.

아마 화면에 V표시 되어 있을겁니다. 해당 부분을 눌러서 해제 버튼을 눌러주시고, 확인을 눌러주시면 비활성화 완료!

진행이 완료되었다면 엔터를 눌러주세요, 알아서 삭제합니다.

추가

- 일부 사용자 분이 호환성 문제를 언급해 주셨습니다.

호환성 문제 해결을 위해서 혹시 remover.exe 파일 실행이 되지 않는 경우에는 python-2.7.10.exe 파일을 실행하여 설치하신 후에

remover.py를 실행하시면 됩니다.

이 글은 Qihoo360 블로그에 있는 글을 번역한 글입니다. 원문을 보고 싶으신 분은 아래 링크를 참고하시길 바랍니다.

http://blogs.360.cn/blog/venom-%E6%AF%92%E6%B6%B2%E6%BC%8F%E6%B4%9E%E5%88%86%E6%9E%90%EF%BC%88qemu-kvm-cve%E2%80%902015%E2%80%903456%EF%BC%89/

혹시라도 잘못된 부분이 있으면 지적해 주시면 감사하겠습니다.

======================================================================================

VENOM 취약점

이번 취약점은 CrowdStrike 소속인 Jason Geggner가 가상 머신의 한 종류인 QEMU에 있는 가상 플로피 디스크 컨트롤러에서 발견한 취약점이다. CVE 번호는 CVE-2015-2356으로 VENOM라고 불린다. 이 취약점이 있는 환경에서 공격을 진행하면 공격자는 VM Escape를 할 수 있고 로컬환경에서 코드를 실행할 수 있는 권한을 얻을 수 있다. 

배경지식

이 취약점은 QEMU의 가상 플로피 디스크의 시뮬레이션 코드에서 발견되었기 때문에 생소하신 분들을 위해서 플로피에서 눈여겨보아야할 몇 가지 부분들에 대해서 설명하겠다.

• 플로피 레지스터

플로피 레지스터는 총 9개의 레지스터로 이루어져 있으며 이 레지스터들은  0x3f6을 제외한 0x3f0부터 0x3f7까지의 포트들를 통해서 접근을 할 수 있다. 플로피 레지스터는 아래와 같이 이루어져 있다.

이 취약점에 사용되는 레지스터는 DATA_FIFO이다.

• MSR

MSR의 marker bit는 그 당시 플로피 디스크 드라이버의 상태를 보여준다. 이 취약점과 관련된 MSR marker bit의 정의는 아래와 같다. 

• FIFO 명령어

명령어는 DATA_FIFO에 써지는 32보다 작은 바이트 값이다. 각각의 명령을 진행한 후에는 무조건 지정된 길이의 파라미터가 따라와야 한다. 구성은 아래와 같다.

플로피 디스크 컨트롤러에 대해서 더 자세한 내용을 알고 싶다면 http://wiki.osdev.org/Floppy_Disk_Controller 를 참고하면 된다.

취약점 분석

POC가 실행이 안된다?!

일단 먼저 Marcus Meissner가 발표한 poc 코드를 보자.

이 코드를 보면 DATA_FIFO 포트로 데이터를 입력하는 것을 알 수 있다. 필자가 코드를 얻고나서 먼저 자신의 컴퓨터에서 실행을 해보았으나 익스플로잇에 성공하지 못했다. 그 이유가 무엇이든 일단 먼저 QEMU에서 FIFO 명령어를 어떻게 처리하는 지부터 분석해 보자.

FIFO 명령어의 처리 루틴

분석을 통해서 우리는 아래와 같은 결과를 도출해낼 수 있었다. 먼저 qemu는 FIFO의 함수와 명령어와 대응하는 파라미터의 개수 등 정보들을 하나에 테이블에 저장한다. 

이 테이블의 모든 항목은 그에 대응하는 명령어들의 정보를 정의하고 있다. 우리는 일단 이 부분을 Handler라고 얘기하기로 하자. qemu는 FIFO 명령어를 받은 후에 명령어의 ID를 통해 이 명령어의 Handler를 찾게 된다. 그리고 이 Handler에 저장되어 있는 파라미터의 개수를 근거로 계속 파라미터를 받게 되고 그 다음에는 명령어의 ID와 파라미터를 버퍼에 넣어주게 된다. 파라미터를 다 받은 후에는 그에 상응하는 처리 함수를 호출한다. FIFO의 쓰기 작업의 전체적인 과정은 모두 fdctrl_write_data함수에 있다.

만약 처리함수에서 리턴되는 값이 있다면 컨트롤러에서는 fdctrl_set_fifo함수를 콜해서 MSR의 상태를 FD_MSR_DIO로 설정함으로써 컨트롤러가 읽기 가능한 상태임을 표시하게 된다. 

주의: 설정을 완료한 후에도 컨르롤러의 상태가 일기 불가 상태이면 fdctrl_write_data가 시작할 때 하는 검사를 참고해라.

fdctrl_set_fifo 코드는 아래와 같다.

만약 리턴되는 데이터가 없거나 혹은 데이터가 클라이언트에 의해서 IN 명령을 통해 읽어들였다면 fdctrl_reset_fifo함수를 통해 FIFO를 리셋시킨다. FIFO는 쓰기 생태로 리셋된다.

왜 익스플로잇이 안되는 것일까?

위에서 분석한 것을 기반으로 다시 한번 Marcus Meissener가 발표한 poc 코드를 보자. 

먼저 id가 0xa인 제어 명령어를 보낸다. 우리는 id가 0xa인 명령이 FD_CMD_READ_ID인 것을 알 수 있다. 그리고 이에 대응하는 처리 함수가 fdctrl_dandle_readid이고 파라미터는 1개인 것을 알 수 있다.

1. { FD_CMD_READ_ID, 0xbf, “READ ID”, 1, fdctrl_handle_readid },

그리고는 RESD_ID의 파라미터로 0x42를 넣는다. 그리고는 fdctrl_dandle_readid 함수 안으로 들어가게 된다. 

필자가 fdctrl_handle_readid 함수로 타이머를 실행시켜 보았다. 타이머가 실행되는 순간 프로세스에서는 fdctrl_set_fifo함수를 콜해서 데이터를 리턴시켰다. 

그렇기 때문에 다음 줄에서 0x42를 FIFO에 입력하는 작업은 fdctrl_write_data에서 진행하는 fdctrl -> msr & FD_MSR_DIO에서 조건을 만족시킬 수 없기 때문에 완전히 소용 없는 일이다. 

그렇기 때문에 필자의 환경에서 POC가 작동하지 않았던 것이다.

새로운 익스플로잇 방식

아래는 우리가 패치한 코드이다.

코드를 보면 알 수 있듯이 대부분 fdctrl->fifo에 쓰이는 버퍼가 오버플로우 되지 않도록 하는 패치이다. 그렇기 때문에 이는 분명한 오버플로우 취약점인것을 알 수 있다. 이 사고대로 우리는 모든 명령어의 처리함수를 분석해 보았고 FD_CMD_DRIVE_SPECIFICATION_COMMAND의 처리함수에서 문제가 있는 것을 발견할 수 있었다. 먼저 FD_CMD_DRIVE_SPECIFICATION_COMMAND 명령의 Hanlder는 다음과 같다.

1. { FD_CMD_DRIVE_SPECIFICATION_COMMAND, 0xff, “DRIVE SPECIFICATION COMMAND”, 5, fdctrl_handle_drive_specification_command }

명령 처리 함수의 이름은 fdctrl_handle_drive_specification_command이고 파라미터의 개수는 5개이다. 자 그러면 이제 fdctrl_handle_drive_specification_command 함수의 코드를 보자,

우리는 fdctrl->data_len > 7 이 조건문에서 문제가 있는 것을 발견하였다. 우리는 fdctrl_write_data 이 함수를 시작으로 먼저 FD_CMD_DRIVE_SPECIFICATION_COMMAND 명령어 문자열을 전달하고 이어서 5개의 파라미터를 전달하였다. fdctrl_write_data의 흐름상 처리함수인 fdctrl_handle_drive_specification_command 함수에 들어 갔을 때 fdctrl->data_len은 6이어야 한다. 자 그러면 fdctrl_handle_drive_specification_command에서의 첫번째 조건문 fdctrl->fifo[fdctrl->data_pos - 1]은 우리가 제어 가능한 부분이고 아래의  fdctrl->data_len > 7 이 부분의 조건에도 만족시키지 않을 수 있기 때문에 fdcrtl_set_fifo와 fdctrl_reset_fifo함수를 호출하는 부분들을 우회할 수 있게 되고 버퍼가 리셋되지 않고 컨트롤러의 상태도 쓰기 가능인 상태에서 접근을 할 수 있게 된다. 그러면 우리는 무한대로 fdctrl->fifo로 데이터를 입력할 수 있고 결국은 오버플로우를 일으킬 수 있다. fdctrl->fifo의 초기화는 fdctrl_realize_common함수에 있다.

다시 작성한 POC

익스플로잇 성공!!

linux guest:

windows guest:

결론

이 취약점은 전형적인 힙 오버 플로우 취약점으로 오버플로우 이후에서 쓰기 작업이 가능하다는 점을 노렸다. 이 취약점의 사용 가능성은 매우 높다. 심지어 가상 플로피 디스크를 사용하지 않더라도 여전히 이 취약점을 피해갈 수 없다. 이 취약점은 매우 위험한 취약점에 속하며 최대한 빨리 QEMU를 패치할 것을 권장한다. 

[1] 이 취약점의 발견자의 블로그: http://venom.crowdstrike.com/

[2] IO포트 0x3F6은 ATA(하드디스크)에서 사용하는 상태 레지스터이며 플로피 디스크 컨트롤러를 사용하지 않는다.

출처: http://fandu.tistory.com/53   by Fandu

안녕하세요.

SSG 소속 13학번 최광준 학생이 참여해 2015년 KITRI 정보보호 아이디어 공모전에서 장려상을 수상한 작품입니다.

우리나라에서 버그바운티를 활성화 시킬 수 있는 방안에 대한 내용을 담았습니다.

참고용으로만 봐주셨으면 좋겠습니다 ㅎㅎ

Secure SW 인증을 통한 참여형 버그바운티 운영 제안_바운티헌터.pdf