Shine Myself

1. 개요

안드로이드 어플리케이션 설치 시 APK 파일 용량을 줄이기 위해 앱 번들을 많이 사용하고 있습니다. 기업에서 앱 번들을 구글 PlayStore에 업로드하면, PlayStore가 설치를 요청하는 사용자의 디바이스에 필요한 파일만 앱 번들에서 꺼내 디바이스로 전달 후 설치하는 방법인데 이를 Dynamic delivery라고 칭합니다.

즉, 최근에는 Dynamic delivery라는 기술로 분리할 수 있는 리소스들을 여러 apk로 분리하고 디바이스에 전달하며, Split apk라는 기술을 사용하여 필요한 apk들만 디바이스에 설치하고 있습니다.

왼편의 사진과 같이 PlayStore에서 어플리케이션을 다운받을 경우,

- 코드(dex)가 포함된 base.apk 파일

- 그 외, 설정 리소스가 포함된 apk 파일들이 분할되어 설치되는 것이죠.

2. Split APK 파일 설치 방법

그렇다면, 이 분할된 APK파일을 PlayStore와 같은 정상적인 루트 말고 다른 방법으로 설치하는 방법을 알아보도록 하겠습니다.

Sol 1. SAI(Split APKs Installer) 어플 이용

1) SAI(Split APKs Installer) APK 다운로드 후 설치

>> https://apkplz.net/app/com.aefyr.sai

2) SAI 앱 실행 후 [Install APKs] 버튼 클릭하여 분할되어 있는 APK 파일들 모두 선택 → 설치 진행

Sol 2. ADB 명령어 이용

1) adb connect 명령어/USB 커넥터로 디바이스 연결

2) adb install-multiple 명령어로 Split APKs 설치

>> adb install-multiple [APKs 파일명]

ex) adb install-multiple base.apk split_config.x86.apk split_config.xhdpi.apk split_countrycodekr.apk split_countrycodekr.config.xhdpi.apk

※ 참고자료

- https://codechacha.com/ko/android-app-bundle/

- https://medium.com/daangn/%EB%8D%94-%EC%9E%91%EC%9D%80-apk%EB%A5%BC-%EC%9C%84%ED%95%9C-android-app-bundle%EC%97%90-%EB%8C%80%ED%95%B4%EC%84%9C-345a656eee85

저작자표시 비영리 변경금지

'Study > Mobile' 카테고리의 다른 글

[ETC] Burp Suite + Fiddler 연동 (1)	2020.06.24
[Android] Apk_Manager Tool Compile 오류 해결 (0)	2020.01.07
[IOS] 모바일 진단 - 탈옥 및 무결성 검증 (1)	2019.12.11
[Android] Apk_Manager Tool Decompile 오류 해결 (0)	2018.09.21
[IOS] Burp Suite > unknown_ca 문제 해결 (0)	2018.09.21

1. 개요

저 같은 경우 웹/모바일 진단 시, 전송되는 패킷을 가로채 전송/변조하는 Proxy 툴로 Burp Suite를 많이 사용하고 있습니다. 하지만, 특정 모바일 어플리케이션을 진단할 때, Burp 툴로 패킷이 잘 잡히지 않고 매우 느려 진단이 불가능할 정도의 상황이 발견되었습니다. 처음에는 SSL 인증서 문제여서 Pinning을 고려해보았으나, SSL 패킷이 잡히긴 한다는 점에서 다른 방법을 물색해보았습니다. 이러한 경우 Fiddler라는 또 다른 Proxy 툴을 이용하여 패킷을 가로챈 후 Burp로 보내는 방법으로 이를 해결할 수 있습니다. (원리는 잘 모르겠네요ㅠ)

2. 방법

Step 1. Fiddler Tool Download

>> https://www.telerik.com/download/fiddler

위 링크에서 피들러 툴 다운로드 받기(개인 이메일 주소 필요)

Step 2. Fiddler Option Setting

1) PC에 Fiddler 인증서 설치

Fiddler 실행 후 [Tools - Options - HTTPS 탭 - Actions 버튼 - Trust Root Certificate - Yes] 클릭하여 인증서 설치

2) HTTPS 패킷 캡쳐 옵션 활성화

[Tools - Options - HTTPS 탭] 에서 "Capture HTTPS CONNECTs", "Decrypt HTTPS traffic" 옵션 선택하여 HTTPS 통신의 패킷을 캡쳐한다.

Step 3. Mobile Device Setting

1) 피들러의 [Tools - Options - Connections 탭] 에서 Fiddler 리슨 포트 확인한다. (디폴트가 8888로 설정)

2) PC의 IP 확인 후 모바일에서 프록시 설정 진행

3) 모바일 디바이스에서 Fiddler 인증서 설치

모바일 브라우저에서 [컴퓨터 IP:Fiddler listen port](192.168.0.115:8888)로 접근 후 [Fiddler Root certificate] 버튼 클릭하여 인증서 설치

※ 왼쪽의 Fiddler Echo Service 화면이 나오지 않는 경우, PC에서 피들러 툴을 끈다음 다시 실행 후 재접근!

Step 4. Fiddler & Burp Connect

1) 피들러의 [Tools - Options - Connections 탭]에서 "Allow remote computers to connect" 체크하여 활성화

2) Burp Suite를 실행한 후 [Proxy - Options - Proxy Listeners] 메뉴에 "All interfaces"로 피들러와 연결할 포트 설정

3) 다시 피들러의 [Tools - Options - Gateway 탭 - Manual Proxy Configuration] 설정

4) 피들러 툴 재시작

※ Fiddler에서만 패킷이 잡히고 Burp에서는 잡히지 않는 경우

Fiddler의 [Tools - Options - Gateway 탭]에서 "No Proxy" 체크 후 저장 → Fiddler 재시작 후 Step 4의 3) 재설정(피들러의 [Tools - Options - Gateway 탭 - Manual Proxy Configuration] 설정)

3. 결론

즉, 그림으로 쉽게 표현하면 아래와 같습니다(위의 세팅으로 설정한 경우)

모바일 디바이스의 패킷을 Burp Suite 툴로 바로 캡쳐하는 경우 속도가 매우 느리지만(경우에 따라 다름),

중간에 Fiddler 툴을 두어 속도를 향상시킬 수 있습니다.

저작자표시 비영리 변경금지

'Study > Mobile' 카테고리의 다른 글

[Android] Split APKs(분할 APK) 설치 방법 (0)	2020.06.29
[Android] Apk_Manager Tool Compile 오류 해결 (0)	2020.01.07
[IOS] 모바일 진단 - 탈옥 및 무결성 검증 (1)	2019.12.11
[Android] Apk_Manager Tool Decompile 오류 해결 (0)	2018.09.21
[IOS] Burp Suite > unknown_ca 문제 해결 (0)	2018.09.21

[Bug Bounty] 카테고리에 해커원에서 발표한 취약점을 정리하려고 했는데,, 이제야 첫 글을 쓰네요ㅠ

위 취약점은 https://www.forescout.com 사이트에서 발견되었으며, DOM Based XSS 취약점입니다.

해커는 바운티로 $1,000를 받았네요. 타 사이트에 비해 XSS 취약점 바운티로 큰 금액을 받은 것 같습니다.

DOM Based XSS(Cross Site Scripting)란?

DOM(Document Object Model)은 HTML 및 XML 문서에 접근하는 방법을 표준으로 정의하는 문서 객체 모델입니다.

즉, 구조화된 문서를 표현하는 방식으로 W3C의 공식 표준입니다.

DOM Based XSS(=type-0 XSS)는 피해자의 브라우저에서 DOM 환경을 수정하여 클라이언트 측 코드가 예상치 못한 방식으로 공격 구문이 실행되는 XSS(Cross Site Scripting) 공격입니다. 즉, 페이지 자체(HTTP 응답)는 변경되지 않지만, 페이지에 포함된 클라이언트 측 코드는 DOM환경에서 발생한 악의적인 변조로 인해 공격 구문이 실행됩니다.

익히 알고 있는 Stored XSS, Reflected XSS 취약점인 경우 서버 측 결함으로 인해 응답 페이지에 악성 스크립트 구문이 포함되어 브라우저로 전달되는 것이지만, DOM Based XSS 취약점인 경우 서버와 관계없이 브라우저에서 발생합니다.

DOM Based XSS(Cross Site Scripting) 공격 시나리오

1. 아래와 같은 URL로 호출되는 페이지가 존재한다고 가정

http://www.test.com/page.html?default=English

2. Attacker에 의해 DOM Based XSS 공격 페이로드 전송

http://www.test.com/page.html?default=<script>alert(document.cookie);</script>

3. 피해자가 2번 링크를 클릭하면, 브라우저가 다음 요청을 전송

/page.html?default=<script>alert(document.cookie);</script>

4. 서버(www.test.com)에서 위 자바 스크립트 코드가 포함된 페이지로 응답/브라우저는 페이지에 대한 DOM 객체 생성

http://www.test.com/page.html?default=<script>alert(document.cookie);</script>

5. 브라우저에 의해 Attacker의 악성 스크립트 구문 실행

alert(document.cookie);

즉, 서버에서 전송된 HTTP 응답 값에는 Attacker의 공격 구문이 포함되어 있지 않으며, DOM 객체 생성 시 클라이언트 측 스크립트에 포함되는 것입니다.

Bug Bounty Case

이번에는 실제 버그 바운티 사례를 보도록 하겠습니다.

https://www.forescout.com/#<img src=x onerror=alert('XSS')>

간단합니다. 해커는 단순히 위의 공격 페이로드를 이용해 DOM Based XSS 취약점을 유발시켰습니다.

그러나, 해당 취약점은 Microsoft Edge와 Internet Explorer 브라우저에서만 실행 가능했다고 합니다.

크롬이나 파이어폭스 브라우저일 경우, 기본적으로 system hash url 인코딩 기능이 적용되어있었기 때문입니다.

아래는 취약한 코드입니다. window.location.hash 함수에 대한 입력값 필터링이 없어 악성 스크립트 구문이 실행 가능합니다.

jQuery(window).load(function() {
jQuery('a.fancybox-inline[href="' + window.location.hash + '"]:first').each(function() {
jQuery(this).delay(700).trigger('click');
});
});