정보보안 스터디 - 21주차 1일 - JWT 취약점, 모바일 앱 해킹
☞ XXE(XML External Entity) Injection
즉 XML 외부 객체 인젝션입니다.
XML(extensible markup language)는
이름과같이 html같은 마크업 언어에서 확장된 버전입니다.
만들어진 초기에 데이터를 체계적으로 주고받기 위해서 개발했습니다.
데이터의 관리 즉 데이터베이스 처럼 활용할 수 있는 것입니다.
학생들의 정보를 관리할 때의 형식은 트리구조입니다.
이런식으로 되어있구요.
각 마크업 태그 하나가 XML Entity(객체) 입니다.
처음에 나왔을 때는 주고받기가 너무 좋았습니다.
원래는 POST방식으로 바디부분에 id=wonder&pass=1234 로 되던 것을
XML형식으로도 관리가능합니다.
SQL injection을 할 때는
원래했던방식과 비슷하게 id에 wonder' and 1=1 로 삽입하면 들어갑니다.
☞ JSON
그다음 발전된 방식은 JSON형식입니다.
키-값이 한쌍이 되는 데이터형식입니다.
최근에는 이 방식을 많이 씁니다.
{id:"wonder", pass:"1234"}
이렇게 되어있고
더 추가하거나 안에 또 JSON을 추가할 수 있습니다.
☞ XML DTD (document type definition)
<!DOCTYPE test [ <!ENTITY wonder "Hello Asian">] >DOCTYPE는 많이 보셨을 겁니다.
C언어의 자료형 선언처럼 데이터타입을 지정하는 것입니다.
쉽게 말해 변수 선언이라고 생각하면 됩니다.
내부 / 외부로 나뉩니다.
내부DTD는 내부의 파일을 가져올 수 있습니다. 실제 사례로는 내부 소스코드 열람을 들 수 있겠습니다.
burp에서 요청을 변조할 때 xml부분 위에 DOCTYPE 변수를 선언해주는 방식입니다.
<!DOCTYPE test [ <!ENTITY wonder "Hello Asian">] >
<login>
&wonder;
</login>이렇게 선언한 변수를 호출할 수 있기 때문에 응답에도 적용되어 뜹니다.
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM 'file:///etc/passwd'>] >
<login>
&xxe;
</login>내부 파일을 가져오는 예시입니다.
외부DTD는 ext로 url을 받아올 수 있습니다.
<!DOCTYPE test [ <!ENTITY ext SYSTEM 'http://wonder.com'>] >
<login>
&ext;
</login>이런식으로 외부 url을 받아옵니다.
하지만 지금은 XML 자체를 많이 사용하지 않기 때문에 잘 발견되는 개발환경이 아닙니다.
또한 외부사용자의 리소스를 받아서 출력하는 기능을 막아놓을 것이기 때문에 취약점조차 발견하기 흔치않습니다.
정말 옛날 사이트에서는 나오겠죠.
중요도는 떨어지지만 꼭 알아 두고 있어야할 취약점입니다.
☞ JWT(JSON Web Token)
비교적 최근에 나오는 형태고 많이 나올 수 있습니다.
쿠키와 세션의 차이점부터 얘기 해봅시다.
쿠키는 클라이언트측에서 검증 즉 변조할 수 있는 취약점이 있습니다.
헤더 또는 바디에 username=anonymous를 > admin으로 바꿀 수 있는 것입니다.
이를 해결하기 위해서 세션이라는 것을 만들었습니다.
세션은 서버측에서의 검증이며 클라이언트측의 값을 믿지 않겠다는 것입니다.
하지만 세션ID는 클라이언트한테 줍니다.(쉽게 말해 보여지는 쿠키죠)
하지만 세션이라는 기능에도 단점, 취약점이 있습니다.
서버측에서 검증이 이뤄지기 때문에
세션 생성, 검증에 대한 요청이 많아지면 부하가 많이 생길 수 밖에 없습니다.
이를 해결하기 위해서
되돌아가서 쿠키처럼 클라이언트가 알아서 하도록 할 수 없을까? 라는 고민에서 개발되었습니다.
하지만 수정이 불가능하도록 하였습니다. JSON구조를 이용한 JWT입니다.
구조는 이렇게 됩니다.
3덩어리로 나눠
헤더 / 페이로드 / 시그니처 부분에
알고리즘.계정정보.해시값
를 주요하게 넣습니다.
{"alg":"HS256", "typ":"JWT"}.{id:"wonder", pass:"1234"}.ewasdfjk~헤더는 > 알고리즘, 포맷 입니다.
시그니처는
헤더와 페이로드 부분 값을 합쳐 암호키를 넣어서 서명값을 만듭니다.
변조되지 않는 것을 무결성이라고 하는데
무결성을 위해 기존 서명값과
입력값으로 적용된 서명값을 비교하여
같은지, 요청이 변조되지는 않았는지 확인합니다.
만약 id를 관리자 admin으로 변조를 하려고 한다면
입력값으로 적용된 서명값이 달라지므로 그렇게 하지 못하도록 제한합니다.
보통 요청 쿠키에 jwt라고 직접적으로 뜨진 않고
auth=base64인코딩~으로 뜹니다.
ey를 base64로 "를 뜻하기 때문에 ey~.ey~ 구조가 많이 뜬다면
jwt임을 단번에 알 수 있습니다.
burpsuite로 봤을 때 base64로 인코딩되어 보여집니다.
하지만 이게 인코딩이지 암호화가 아니기 때문에 디코딩을 통한 평문확인이 가능합니다.
또한 JWT editor 플러그인으로 바로 번역된 모습과 바로 변조까지 가능함을 보여줍니다.
여기서 개발자들이 또 실수하게 되는 게 있는데
부하가 발생하지 않기 때문에 DB처럼 관리할 수 있지 않을까? 한겁니다.
휴대폰번호, 비밀번호와 같은 민감한 데이터를 넣기 시작합니다.
사실 이 토큰은 자바스크립트 XSS를 이용해서 탈취를 할 수 있기 때문에
민감한 데이터가 노출될 위험이 있다는 겁니다.
id, pass 를 입력하는 순간
사용자측에 jwt토큰을 건내줍니다.
예를 들어 백신pass도 인증이 마치면 토큰을 건내주는 구조였기 때문에
많은 사람들이 인증함에도 불구하고 서버에서 부하없이 진행할 수 있었습니다.
최근에 만들어진 기능이다보니까 초기에는 개념을 제대로 잡히지 않은 상태에서 만들어진 라이브러리를 가져와서 개발하기 때문에 생각보다 문제점이 많습니다.
☞ JWT 취약점
0) 아까 말했던 개발자의 민감한 데이터 입력 실수가 첫번째입니다.
1) 무결성 검증을 안하는 경우
아주 기초적인 정보도 없을 경우 하는 실수인데 if{}else{} 서버측 코드검증 없이 그냥 받아서 사용합니다.
2) none algo를 허용하는 경우
즉 알고리즘을 none으로 바꿀수있습니다.
알고리즘은 원래 변경할 수 없게해서 무결성을 지키도록 해야하는데
그러니까 아이디와 비밀번호 등 계정정보를 변조할 수 없게 고유 해시값처럼 값을 비교하여 변조되지 않았는지 확인이 가능합니다.
하지만 알고리즘키 값을 none처리가 가능하다는 점입니다.
none으로 바꾸면 무결성 기능이 해제되기 때문에 계정정보를 변조하여 넣을 수 있습니다.
3) 암호키가 짧거나 약한 문자열일 경우
john the ripper으로 충분히 암호화된 문자를 뚫을 수 있기 때문에 취약합니다.
☞ Mobile APP Hacking
요즘은 모바일 앱해킹까지 해야하는 이유는
반응형웹사이트의 개념과는 조금 다릅니다.
모바일로 접속하면 앱처럼 보이게 만들어놓았습니다.
껍데기안에 Web View라고 크롬같은 게 들어간 구조입니다.
하나만 만들면 PC, Android, iOS까지 3개환경을 제작할 수 있기 때문에 많이 선호하는 추세입니다.
또한 개발 트렌드가 웹만하지 않고 모바일 앱까지 같이 의뢰하기 때문에
같이 공부해둬야합니다.
모바일 앱 해킹의 틀을 먼저 잡고 빈 곳을 채우면서 공부해나가는 것이 효율적입니다.
☞ 모바일 애플리케이션 해킹 vs 모바일 해킹
모바일해킹은 웹해킹으로 쳤을 때 웹브라우저를 뚫는 것과 같습니다.
모바일 애플리케이션은 말그대로 앱의 취약점과 어떤 것까지 가능한지, 어떤 정보가 노출되는지 점검하는 해킹입니다.
1) 단말기 취약점
스마트폰 기기 내에서 발생합니다.(정보 노출, 프로세스 흐름 조작)
2) 서버측 취약점
휴대폰 단말기 <==> 서버
모바일로 접속했을 때의 서버취약점 탐색으로 그냥 기존에 웹해킹과 많이 닮아있기 때문에 SQL, 파일업로드, 파일다운로드 등 취약점을 찾아나갈 수 있습니다.
☞ 필수적으로 있어야할 진단환경
- 안드로이드, iOS 단말기가 필요합니다.
애플 단말기는 버전은 너무 최신버전은 탈옥자체가 안되어있고
이전버전은 사용지원을 안하는 경우도 있기 때문에 적당한 버전을 사용합니다.
- 또는 에뮬레이터로 가능합니다.
NOX 처럼 하드웨어까지 구현한 에뮬레이터를 사용합니다. 설정에가서 루팅기능을 체크하면 손쉽게 설정 됩니다.
시뮬레이터는 소프트웨어까지 흉내었기 때문에 불가능하며 적합하지 않습니다.
- 단말기의 조건은 루팅 또는 탈옥이 되어잇어야합니다.
기본적으로 단말기는 기본권한으로만 되어있습니다. 루팅은 최고관리자 권한을 얻게하는데
나중에 필요한 파일dump, 파일삭제, 권한파일 확인 등 기능을 할 때 필요합니다.
세팅
burp와 단말기앱을 연결시켜야합니다.
프록시 리스너를 추가해야줘야합니다. All interface로 하여 *:8080 식으로 추가해줍니다.
단말기에서는 세팅을 컴퓨터 IP주소를 써줍니다.
>> 패킷이 하나씩 쌓일 겁니다. 단말기에서 클릭하면서 확인해봅니다.
APP이 어떻게 실행되는지, 정보를 저장하고 있는지 살펴보기위해서는
frida 동적 분석합니다.
또한 frida는 앱 흐름 조작, 즉 동적 후킹이 가능합니다.
실행
윈도우에서 adb shell > 단말기 쉘로 연결합니다.
#를 보면 루트권한인것을 확인합니다.
☞ 모바일 앱 솔루션
모듈같은 것입니다.
나머지는 비교적 쉽지만 가장 어려운 점은 앱솔루션 우회입니다.
덱스 2중 처리부터 해커가 분석하는 것을 방해하기 위해서 난독화도 하고 많이 되어있습니다.
또한 루팅된 폰은 실행이 안되도록 설정해 놓았습니다.
가장 오래걸리는 작업입니다.
전체적으로 봤을 때 어플리케이션 자체의 분석도 그렇고
솔루션이 적용된 apk파일이라면 크랙하는 능력 즉 리버싱능력이 필수적이여보입니다.
☞ 앱 분석 방법
분석도구로는 jadx-gui가 있는데 bat파일로 되었으며
분석할 apk를 그냥 넣어주면 됩니다.
자동으로 분석해주며 decompile까지 진행합니다.
항상 분석할 땐 제일 먼저 어떤 코드를 실행시키는지 start point 를 찾아야합니다.
PEVIEW처럼
어떻게 구조로 되어있는지 확인할 수 있고
보면 처음은 Resource> manifest.xml (xml 파일형식) 생각보다 디테일하고 친절하게 구조가 나와있습니다.
메뉴얼 역할을 하며 앱에서 요구하는 권한을 확인합니다.
함수 등 어플이 작동하는 것을 분석하기 위한 파일은 자바언어로 되어있습니다.
여기서 주목해야할 점은
1) 패키지 이름
임의의 앱이름으로 사용하는 것이 아니라 나중에 명령어 실행을 위한 식별ID입니다.
com.insecureshop
2) activity 태그
activity는 한 화면을 말합니다.
<action ~ MAIN>이 처음 화면이기 때문에 이걸 중심으로 분석을 시작합니다.
처음 실행되는 함수는 뭔지 함수를 쫓아가 디테일하게 분석을 합니다.
productactivity 가 가장먼저되며
OnCreate 등 기능을 알아둡니다.
context는 현재 상태를 가져옵니다.
Loginactivity
Layout : 버튼들을 연결해둡니다.
☞ 앱에서 계정 정보를 탈취하는 방법
1) 정보를 평문으로 저장해둔 경우
어플의 로그인을 시도하기만했는데 단말기에 저장되는 경우가 있기 때문에
결국 공격자는 단말기만 뚫어서 파일 경로(data/data/ > shared_prefer)를 찾으면 됩니다.
2) DB SQLite 라는 파일로 저장될 수 있습니다.
이러면 DB Viewer로 계정 또는 토큰을 탈취당할 수 있습니다.
3) memory창 확인 시 정보가 평문일 경우
메모리 덤프를 떠서 데이터가 평문이면 취약합니다.
4) 관리자의 계정정보가 소스코드 어딘가에 하드코딩되어 있는 경우
이것도 역시 리버싱으로 경로를 찾아볼 수 있습니다.
☞ 로그인 페이지 우회 방법 (단말기 접근 제한 우회 )
1) 리버싱으로 로그인 화면 자체를 점프하거나, 무조건 false/true 값을 나오게 하여 로그인 접근을 허용합니다. 또한 게임앱 등이라면 포인트 값을 바꿀 수 있습니다.
2) 흐름 제어
☞ Frida
분석도구로
코드 흐름 제어
솔루션 우회
메모리 덤프
의 기능을 합니다.
☞ 언어
Android - JAVA, kotlyn
지금 이 어플도 kotlyn기반으로 되어있지만 디컴파일하여 보여줄 때 JAVA언어 기반으로 보여주기 때문에
JAVA를 할 수 있어야합니다
iOS는 - objective-d, swift
안드로이드와 마찬가지인 경향입니다.
objective-d 가 기준이되지만 최근에는 swift 관련 정보가 더 많습니다.
처음에는 복잡하고 어떤 기능을하는지 모를텐데
가장 쉽게 해킹을 시작하고 배울 수 있는 방법은 앱을 직접만들어 보는 것입니다.
그러면 자동적으로 읽을 수 있고 함수의 역할을 알 수 있을 것입니다.
난이도
오히려 iOS가 더 안까다롭고, 보안솔루션 개발이 별로 없으며, 트릭같은 게 없습니다. 하지만 개발자들은 진입장벽이 높다고 생각할 수 있기 때문에 접근하지 않습니다.
iOS는 운영체제만 오픈소스가 아니고 까다롭지 않고
안드로이드가 사람들에게 많이 알려지고 자바언어로 이뤄져있어서 그런지 쉽게 다가가는 것 같습니다.
그리고 이런 테스트용 어플도 쉽게 딱 깔끔하고 디테일하게 정리되어있습니다.
하지만 안드로이드 어플 솔루션이 적용된 APK같은 경우에는 정말 극도의 난이도를 보여주고 있습니다.
덱스를 2중,3중으로 덮여있거나 난독화는 물론 리버싱을 진행할 때 함수에 맞는 경로찾기가 어렵다는 뜻입니다.
참고로 iOS 신버전은 탈옥취약점이 발견될 때까지 기다려야합니다.
이렇게 잡은 틀을 기반으로 모바일 앱 해킹을 시작해봅시다.
