YPrefer's Develop&Security

워너크라이는 올해 5월쯤 전세계적으로 유행한 랜섬웨어 공격인데, 445포트를 통해 감염되는 것이 남다르다.

기업보안담당자 입장에서는, 전 임직원이 MS보안패치를 했는지 관리하고 확인해야 하는 의무가 있는데

그럴때 조금이나마 도움이 될수있는 스크립트가 있다.

link: https://github.com/apkjet/TrustlookWannaCryToolkit

TrustlookWannerCryToolkit은 해당 ip의 pc가 보안패치가 되어있는지 확인하여 결과를 띄워주는 python script인데,

사실 나도 써보진 않았지만 동료가 소개해줘서 글을 적어보았다.

동료의 말로는, 점검을 위해서는 선제되어야 하는 조건이 있는데,

① 445포트가 서비스 되고 있어야 한다고 한다.

결과로는

워너 크라이 패치가 되있는 pc라면 -> 점검완료(done)으로 나오거나 system is not vulnuer

워너 크라이 패치가 되있지 않은 pc라면 -> system is vulnuer

로 나온다고 한다.

Fasoo Web DRM 을 사용해서, 웹사이트의 오른쪽 버튼과 스크린샷 방지를 하고 있는 웹사이트들이 있다

웹 DRM은 해당 웹페이지에 접근시, Response로 Fasoo를 활성화 시키는 script를 내려 주는데

Froxy Tool을 이용해 이 script를 삭제 해주면, 오른쪽 버튼과 스크린샷 등이 가능하다.

네이버 블로그 등에서도 마찬가지로 우클릭 우회가 가능한데,

IE에서는 개발자 도구(F12)를 이용해서 사용안함 탭에서 javascript를 체크

크롬에서는 개발자 도구(Ctrl+Shitft+I) 를 이용해서 설정에서 javascript 사용안함에 체크

로 쉽게 우회할 수 있다.

전에 안드로이드 앱 점검을 하던 중 db파일을 추출해내서 데이터를 확인하려고 한 적이 있었다.

근데, 이게 분명 db파일임은 파일명에서 부터 D!B! 라고 적혀 있어서 확신할 수 있는데, Sqlbrowser을 통해 열리지가 않는 거였다.

심증은 있지만 물증이 없어 확인을 못하던 상황!

혹시나 해서 Hex Editor로 열어보니, 일반적인 DB파일은 Header가 SQL...뭐 이렇게 시작되어야 하는데,

이상한 값으로 적혀있는 걸보고 이상하다 싶어서 hex 값들을 쭉보고 있는데

보통은 00으로 섹션이 나누어지는데 이상하게 77이라는 값이 무지 많이 보였었다.

(정상적인 db파일)

여기서 XOR 연산을 했구나 싶어 malzilla를 이용해 XOR 키를 찾았더니 77을 키로 xor 연산을 한 걸 알 수 있었다.

링크 : http://malzilla.sourceforge.net/

키를 알고 그걸로 다시 복호화를 시도하니 정상적인 db파일로 떨어져서, DB내용을 볼 수 있었다.

오래 되서 잘 기억은 나지 않지만, 암호화 키를 77로 하지 않고 앱의 패스코드와 모바일의 유니크값을

섞은 것을 키로 사용하는 것으로 수정했던 것으로 기억한다.

점검한 앱중에 중요한 데이터를 단말에 저장하는 앱이 있었다.

개발자와 인터뷰를 통해 단말에 저장되는 데이터는 어떻게 관리가 되는지 물었더니 

특별한 방법을 사용해서 볼 수 없도록 만들었다 라는 자신감 넘치는 대답을 들었다.

링크 : https://www.eldos.com/solfs/

어떻게 했는지 코드를 분석하여 확인해보니 solfs라는 가상 스토리지를 사용하는 것으로 보여졌고,

이 스토리지를 이용하는데 필요한 패스워드는 하드코딩 되어있었다.

패스워드는 알고 있으니 보는 방법을 구글링 해봤는데, Solfs Explorer란 것이 있었고

이 프로그램을 구하기 위해 반나절을 족히 썻다.

결국 설치 파일을 구해서 설치하고 패스워드 넣으니

자신감 있었던게 무색하게 허무하게 데이터를 열람 할 수 있었다.

필자가 경험한 펌웨어 분석경험을 흐름대로 정리한 것이다.

어떤 제품인지는 보안상 적을 수 없지만, 이런 식으로 한다는 느낌적인 느낌을 남겨놓으려고 정리한다.

펌웨어 분석

<!--[if !supportLists]-->①    <!--[endif]-->펌웨어 파일을 확인할 수 있는 도구 : Firmware mod kit, binwalk

펌웨어를 웹에서 다운받거나, Flash memory에서 덤프하는 방법으로 얻어낸다. 필자의 경우 점검이라 제공을 받았다.

Root:~#Binwalk –e rootfs2.2.0release를 하면 cramfs파일이 나오고,

이 cramfs는 7zip으로 풀리기도 하고 mount-t type cramfs로 마운트하여 내용을 확인할 수 도 있다.

또, firmware mode kit의 기능중에 uncram하는 기능이 있어 이를 통해 확인할 수 도 있다.

이렇게 나온 cramfs파일은 Root:~#file cramfs하면, Linux Compressed Rom File System data인인 것을 확인할 수 있다.

풀린 파일의 etc/shadow파일을 확인하면 hdd에 링크되어 있는 것을 확인할 수 있고,

Hdd를 풀기위해 타입을 확인해야 하는데 etc/fstab을 확인하면, 타입을 yaffs2타입인 것을 확인할 수 있다.

Hdd.2.8.2.release를 unyaff나 binwalk로 풀면 shadow file의 내용을 확인할 수 있고, john the ripper를 이용해 root 의 패스워드를 얻을 수 있다.

<!--[if !supportLists]-->②    <!--[endif]-->Nmap을 이용해 월 패드를 포트스캔하여 현재 서비스중인 포트들을 확인하고, 펌웨어의 바이너리 파일중 bind, listen, accept등 소켓통신시 사용되는 함수를 쓰는 바이너리 파일을 찾는다.

이 바이너리 파일들을 IDA를 이용해 리버싱 하여, 포트에 맞는 바이너리 파일을 찾아낸다.

그중 펌웨어 업데이트를 수행하는 바이너리를 찾아내고 업데이트 서버의 id/pwd를 알게 되면, 

telnet을 서비스하게 변조한 펌웨어로 업로드하는 명령을 내려, telnet을 서비스하도록 만들어 외부에서 접속이 가능하다.

 ARM환경구축

<!--[if !supportLists]-->①    <!--[endif]-->구축에 사용한 도구 : QEMU, gdb, strace, ida등

QEMU 에뮬레이터를 이용해 ARM OS를 올릴 수 있어 동적 디버깅을 시도해볼 수 있다.

https://people.debian.org/~aurel32/qemu/armel/ 에서 qemu를 다운받아 실행하고, proxy setting을 해주어 apt-get으로 update후 

build-essential, gdb, strace를 설치한다.

qemu-system-arm -M versatilepb -kernel vmlinuz-3.2.0-4versatile -initrd initrd.img-3.20-4-versatile -hda debian_wheezy_armel_standard.qcow2 -append "root=/dev/sda1" -redir tcp:2222::22

위와 같이 qemu를 실행하면 2222번 포트로 qemu에 ssh서비스를 붙을수 있어 scp로 파일전송이 용이하다.

<!--[if !supportLists]-->②    <!--[endif]-->lsdaemon프로그램을 qemu로 옮기고, ldd를 이용해 ASLR이 적용된 OS라면

sysctl -w kernel.randomize_va_space=0를 적어 ASLR기능을 끄고, strace로 확인하면 관련라이브러리가 없음을 알수 있고, 관련라이브러리를 펌웨어에서 찾아 넣어주고 없는 파일을 touch로 빈파일을 만들어준다.

그러면 정상실행이 되지만 app_init에서 죽는 것을 확인할 수 있는데, 이것을 확인하기 위해, gdb로 따라가서 확인하면 daemon(0,0)에서 죽는 것을 알 수 있고 이 부분의 코드를 NOP으로 코드패치를 한다.

ld --verbose ./lsdaemon | grep SEGMENT_START 를 실행하면 baseaddress를 얻어낼 수 있다.

이를 통해 ida에서 edit->segment->rebaseprogram에서 baseaddress를 설정해주면,

실행 중인 주소와, ida의 주소값을 맞춰줄 수 있다.

이때 코드패치는 IDA의 hexview에서 F2를 누르고 apply를 해주면, 코드패치가 된다. 코드패치된 파일을 다시 넣어주고 실행하면 hostname을 불러오는 곳에서 죽고, hostname을 펌웨어의 것과 맞추어 주어 실행하고, strace로 에러를 제거해주는 방법을 반복해서 구축하여 동적디버깅을 실시한다

APK 를 분석하기 위해선, apktool로 까보고 소스를 분석하는게 제일 먼저가 된다.

그래서 이 소스를 보기 어렵게 하는 난독화 기술이 있는데 보통 개발 전 단계에서 android에서는 Proguard와 dexguard를 사용하는 것으로 알고있다.

Proguard는 무료고 dexguard는 상용인데 이것들도 까보면 물론 매우 엄청 분석하기 짜증나고 힘들지만

어느정도는 따라가 볼 수 있다.

근데 최근에 만나게 된 Dexprotector란 녀석은 상용이긴 한데 class조차 보이지 않았다.

보이는건 ProtectedMainApplication 딱 하나.

처음 접했을때 무지 황당하더라..

소스 분석은 아예 접고 다른 부분을 보긴 했지만, 아직도 이게 적용된게 다시 나온다면 어떻게 해야 할지 모르겠다.

알아보니 개발 후 단계에서 사용하는 난독화 Tool 이라고 하는데, 가격이 좀 비싸다.

이것과 같은 단계에서 사용하는것이 Medusah와 APK Protect란 것도 있다고 한다.

링크 : http://medusah.com/ https://sourceforge.net/projects/apkprotect/

혹시 Web 변두리 어디엔가 있는 이 블로그에 방문해서 이 포스트를 보는 누군가가

관련정보를 공유해주시면 정말 블로그를 시작하기에 잘했다는 생각이 들거 같다.

점검을 하다보면, Hmac 기술이 적용된 어플리케이션을 볼 수 있다.

Hmac이란 Hash-based Message Authentication Code 의 약자인데, 사용자가 값을 변조했는지 아닌지 알아차리기 위한 기술이다.

이 기술은 서버에 요청할때의 값을 정상적일때 Hash 값과 함께 보내서 변조를 막기 위함인데,

물론 완벽하게 막지는 못하지만 최소한 공격자를 귀찮게 만들 수 있다.

사례를 들어 설명 하자면, 전에 점검 했던 Web 중에 한 사이트가 Hmac 기술을 적용하고 있었는데

사이트 URL을 공개하기는 좀 그러니까

이 사이트에서 요청하는 값이 http://www.yprefer.com 이고, post로 value=aaa 란 값을 전송하는게 정상적이라고 가정하자.

이때 이곳에서는 로그인 할때 Chip 값을 사용자에게 주고, 이 Chip 값과 url 그리고 aaa라는 Value 값을 섞어

HASH값을 만들어내어 HTTP Header로 같이 Request를 보냈었다.

그러면 공격자가 Proxy Tool을 이용해 aaa라는 값을 bbb로 변조 하였을 때,

서버에서는 동일한 HASH알고리즘을 사용해서 CHip 값, url, bbb를 섞어 HASH값을 만들어내고, 사용자가 보내온 Header의 HASH값과 비교하여

맞는 요청인지 아닌지 확인하는 방식으로 변조를 막았었다.

물론, 여기에서 HASH 값을 만들어내는 로직은 사용자의 javascript에 있기때문에, script를 분석하면 HASH값을 만들어 낼수 있고,

변조된 bbb의 값을 가지고 HASH를 만들어 데이터와 HASH값을 동시에 변조하면 막을 수 없는 맹점이 있긴 하지만

분명 공격자에게 script를 분석해야 하는 귀찮음과 요청시 hash값을 계산해야 하는 번거로움을 안겨줄 수 있는 방법임은 틀림없다.