Shine Myself

APK_Manager Tool을 사용하다가 디컴파일은 잘 되는데, 컴파일 오류가 발생한 경우라 정리해본다.

우선, 디컴파일은 오류없이 진행되었지만 아무 작업(위변조)을 하지 않았는데도 Sign 작업이 이루어지지 않았다.

https://ddungkill.tistory.com/67

이전 글을 참고해서 3가지 작업을 진행했는데도 컴파일 오류가 발생해서 툴 디렉터리 내 LOG 파일을 오픈했다.

 해당 로그파일을 보면 에러의 원인이 나오는데, 리소스 속성이 없다고 한다...

SOLUTION 1)

이유는 모르겠지만 구글링을 해보았더니,

프로젝트 파일 내에 존재하는 '/res/layout-v26/abc_screen_toolbar.xml' << 해당 파일을

 <android.support.v7.widget.ActionBarOverlayLayout android:id="@id/decor_content_parent" android:fitsSystemWindows="true" android:layout_width="fill_parent" android:layout_height="fill_parent" xmlns:android="http://schemas.android.com/apk/res/android" xmlns:app="http://schemas.android.com/apk/res-auto">  <android.support.v7.widget.ActionBarContextView android:theme="?actionBarTheme" android:id="@id/action_context_bar" android:visibility="gone" android:layout_width="fill_parent" android:layout_height="wrap_content" style="?attr/actionModeStyle" /> </android.support.v7.widget.ActionBarOverlayLayout>

위 내용을 덮어 써주니 정상적으로 컴파일이 가능했다.

APK_Manager 관련 에러는 로그 파일을 통해 대부분 해결 가능할 것으로 보인다.

출처 : https://github.com/iBotPeaches/Apktool/issues/1725

SOLUTION 2)

/Users/XXXX/(Library)/apktool/framework/1.apk << 1.apk 파일을 삭제한다.

PHP - assert() 함수 문제를 풀어보겠습니다.

취약한 부분을 찾아서 .passwd 파일을 읽어야합니다.

우선, assert() 함수란, 조건이 참이 아닌 경우(거짓인 경우) 경고/에러를 출력하게 하는 함수로, 주로 디버깅 시 많이 사용됩니다. 

문제에 들어가보면, [Home], [About], [Contact] 3개의 탭이 있습니다.

일단, [About] 탭을 눌러보겠습니다.

"page" 라는 파라미터가 GET 메소드로 전송되고 있고, [About] 탭에 해당하는 페이지가 출력되고 있습니다.

"page" 파라미터에 상위 폴더로 이동 가능한 특수문자 "../" 을 입력해보았더니,

assert() 함수로 인해 에러가 출력되고 있습니다.

strpos 함수는 문자열이 포함되는지 검사하는 함수인데, 문자 ".." 때문에 공격이 탐지됨을 알 수 있습니다.

이번에는 "./" 을 입력해보았는데, 공격이 탐지가 되지는 않지만, 파일이 없다고 나오네요.

혹시 될까 싶어서 .passwd 파일을 바로 넣어 보았는데, .php가 자동으로 합쳐져서 없는 파일이라고 출력되는 것을 다시 한 번 확인할 수 있었습니다.

"../"을 입력했을 때 출력된 에러메시지를 이용해서 strpos 함수를 강제로 완료한 후 system 명령어를 작성해보았습니다.

system 명령어는 따로 문자열 검사를 하지 않아서 공격으로 간주되지는 않아 보였습니다.

하지만, .php가 강제로 붙어 버려서 syntax 에러가 발생하는 것을 알 수 있습니다.

강제로 완료한 strpos 함수를 뒤에 다시 써주고, .passwd 파일을 여는 시스템 명령어를 삽입하면!

FLAG 값을 얻을 수 있습니다.

','ㅁ') << 이 ㅁ 부분에 a, b 등이 들어가면 문자열 탐지로 인해 공격으로 간주하는 것 같습니다...

탐지가 안되는 문자 값을 입력해주어야 합니다.

JSON Web Token(JWT) 관련 문제를 풀어보았습니다.

우선, JWT란 사용자와 서버간에 안전하고 신뢰할 수 있는 정보를 전달할 수 있는 토큰 값입니다.

주로, 회원 인증이나 안전하게 정보를 전달할 경우 사용되는데, 전달되는 정보들이 sign(서명)되기 때문에 탈취/변조되지 않았는지 판단할 수 있기 때문입니다.

문제에 들어가면, 로그인 폼이 나오는데, 여기서 Admin 계정을 탈취하는게 목표입니다.

[Login as Guest!] 버튼을 클릭해봅니다.

쿠키 값으로 jwt 값이 전송되는 것을 확인할 수 있습니다.

jwt 값은 1. 헤더(Header), 2.정보(Payload), 3.서명(Signature) 값으로 분리되는데, 각각을 BASE64로 인코딩해서 "."으로 구분한 후 전송합니다.

위 스크린샷의 jwt 값을 예로 들으면

이렇게 나뉘어 집니다. 

https://jwt.io/ << 여기에서 jwt 값을 디버깅하고 검증 및 생성할 수 있습니다.

헤더(Header)에서는 토큰의 타입(JWT), 해싱 알고리즘(HMAC SHA256 / RSA 등...)을 정의하고 있습니다.

정보(Payload)에서는 전송할 정보 데이터를 담고 있으며,,

서명(Signature)에서 헤더의 인코딩 값과, 정보의 인코딩 값을 합친 후 비밀키로 해싱하여 생성합니다.

저는 이 문제를 단순히 정보(payload) 부분의 "guest"를 "admin"으로 변조한 후 전송하면 된다고 생각했습니다.

그래서 PAYLOAD 부분을 admin으로 변조하여 생성된 값을 guest 로 로그인 시 전송되는 jwt 쿠키 값에 삽입해보았습니다.

그랬더니... 서명값에 오류가 있다고 출력되더라고요. 

비밀키를 모르는데 어떻게 변조를 하지 고민하다가 구글링으로 JWT Attack 케이스를 발견하였습니다.

CASE1. 중요 정보 노출(이거는 jwt.io로 디버깅/BASE64로 디코딩 했을 때 노출되는 정보들..)

CASE2. algorithm 값이 none

CASE3. algorithm 변조(RS256 to HS256)

CASE4. HS256 key Cracking

이렇게 4가지 케이스가 있더라고요. 저는 CASE2 방법을 이용해보았습니다.

헤더(Header) 부분의 alg 값을 none으로 변조하고, 서명(Signature) 값을 제거한 후 전송하는 방법입니다.

즉, 위와 같이 인코딩한 값을 [Header + "." + Payload + "."] 서명 값 없이 서버로 전송하였더니,

※ 참고로 jwt 값은 공백과 엔터 없이 BASE64로 인코딩되어야 하며, 인코딩 시 뒤에 패딩 문자(=, ==)는 제거해서 전송

Admin 권한을 획득할 수 있었습니다!!

참고자료

문제되는 경우 삭제 처리 하겠습니다...