바나나맛 페이로드

많이 어플리케이션이 보안을 위해 SSL통신을 수행하고있으며, 연구나 다른 목적을 위해 SSL패킷을 스트립해야하는 경우가 생깁니다. (저는 제일 처음 모바일 게임쪽을 분석하기위해 이를 수행하였습니다.)

이를 위해 일반적으로 PC 환경에서는 SSL 스트립을 위해 MITM(Man In The Middle)을 수행합니다.

하지만 모바일 환경에서는 MITM이 쉽게 수행되지 않습니다.

가장 큰 이유는 윈도우에서도 CA체크가 되지않은 인증서의 경우 경고창이 뜨고 클릭해야 실행할 수 있듯이, 모바일에서도 CA체크를 합니다. 그리고 대부분에 SSL을 사용하는 어플리케이션에서는 CA체크에 대해서 호락호락하게 넘어가주지 않습니다. (하지만 다 할수있는 방법은 있습니다. Mitm을 수행할 필요가 있으신분은 Kandroid에서 GMS 를 분석한 자료를 보면 참고하면 됩니다. )

하지만 특정 어플에서 발생하는 SSL 트래픽을 구분하기도 힘들뿐더러, 환경을 구성하기도 번거럽습니다..

그래서 본 포스팅에서는 좀 더 쉽게(?) SSL 스트립을 할 수 있는 방법을 제시합니다. 모두가 아는방식일거고 이미 쓰는사람도 많을겁니다.

안드로이드는 SSL 통신을 위해 내부적으로 openssl 을 사용합니다.

그리고 SSL_read, SSL_write 함수를 통해 데이터 송수신을 수행합니다.

즉, SSL_read 함수와 SSL_write 함수를 후킹해서 송수신 전, 후의 데이터를 가져온다면, 인증서 생성 환경구성등의 번거러운거 없이 SSL 스트립을 수행할 수 있습니다. (이게 더 번거러울지도 모름....)

SSL_read, SSL_write 의 데이터를 가져오기 위해서는 후킹을 통해 두 함수의 기능에 로깅을 추가하면 되며, 쉽게 2가지 방법을 선택할 수 있습니다.

1) 프레임워크 소스코드를 받아 로깅기능을 추가한 libssl.so 를 재 컴파일해서 교체하면 손쉽게 로깅을 수행 할 수 있습니다. 하지만 이경우 어플에 대한 예외처리를 하지 않을경우 시스템에서 SSL 을 사용할 경우 모두 로깅이 되기 때문에 엄청난 데이터가 축적됩나다.

2) 두번째 방법으로는 고전적으로 많이 사용되던 lnline 후킹을 통해 함수에 전달되는 데이터를 추출할 수 있습니다. 특정 프로세스 메모리에 존재하는 SSL_read 함수와 SSL_write 함수를 패치하여 인자 및 수행결과를 추출할 수 있습니다. (비슷한 연구로는 collin님이 발표한 Dynamic Binary Instrumentation on Android 이 있었고, 물론 발표에 사용된 도구 모두 제공됩니다. 하지만 코어 라이브러리에 대한 후킹이 재대로 수행되지 않습니다. 이유는 따로 설명하지 않겠습니다. 그래서 저는 안드로이드 환경에서 동작하는 lnline 후킹 도구를 재 설계해 개발하였습니다.)

위 방법을 통하면 그림과 같이 손쉽게 SSL 스트립이 가능해집니다. 

아래 사진은 2번에 제시한 방법으로 inline 후킹도구를 개발하여 페이스북 어플의 SSL 통신을 스트립한 결과로 Logcat으로 로깅을 수행하였습니다.

WEB 200 (한승현 사이트 문제 이름이 생각이 안남)

사이트를 접속하면, http://211.58.255.64:8078/webprob/index.php?p= 다음과 같은 URL을 포한하고 있으며, 딱 URL이 include 취약점을 점검해보라 알려주고 있다. p라는 인자를 변경할 경우 오류와 함께 실제파일의 경로를 확인할 수 있다.

include를 수행하는 파일명의 경우 inc이기 때문에 모두 다운받을 수 있었다. 다운로드 받은 소스코드를 분석한 결과 다음과 같은 문제점이 존재했다.

로그인 성공 시 serialize를 통한 세션 생성 (loginproc.inc)

$_SESSION['memdata'] = mb_convert_encoding(serialize(mysql_fetch_array($result, MYSQL_ASSOC)), "ASCII", "UTF-8");

2. 세션정보 확인 시 unserialize를 통한 세션값 추출 (tohsy.inc)

$rowm = unserialize($_SESSION['memdata']);

저장할 때 UTF-8을 아스키로 인코딩을 하고, 실제 unserialize 할 때는 디코딩이 수행되지 않는다. 이를 확인하기 위해, 실제 코드를 작성하여 유니코드(한글)을 입력한 결과,한글 1글자가 유니코드에서는 3바이트로(원래 2바이트인줄알았는데..)로 들어가지만, 인코딩 때문에 1글자로 변하는 것을 확인할 수 있다. 때문에 unserialize에서 오류가 발생하고, 이를 이용하여 공격 수행이 가능하다는 것을 확인했다.

친절하게도 tohsy.inc에서는 오류가 있을 경우 덤프를 해준다. 이걸 보고도 쉽게 문제 의도의 유추가 가능하지만 머리가 나쁜지 초반에 이를 확인하진 못했다.

한글로 가입을 할 경우 tohsy.inc에서 덤프를 확인할 수 있으며 다음과 같은 결과를 출력한다. 한글 2글자로 가입한 결과 다음과 같은 결과를 덤프 해준다.

a:4:{s:3:"idx";s:4:"1234";s:2:"id";s:6:"??";s:2:"pw";s:1:"1";s:5:"level";s:1:"1“}

입력 가능한 값인 id와 pass를 통해 데이터의 조작이 가능하다는 것을 확인하였고 다음과 같은 코드 구성을 통해 공격을 수행하였다.

8글자의 한글 id를 통해 가입할 경우 24-8 = 16 바이트의 데이터를 덮을 수 있어, 입력한 암호를 통해 serialize된 구조의 구성이 가능하다.

a:4:{s:3:"idx";s:4:"1234";s:2:"id";s:24:"????????";s:2:"pw";s:YY:"XXXXXXXXXXXXXXXXX“";s:5:"level";s:1:"1“}

array의 크기가 4이기 때문에 기존 2개의 데이터를 제외하고 추가적으로 두 개의 데이터의 추가 및 변경이 가능하다.

본 문제에서는 다음과 같은 조건을 통해 비밀글을 보여준다.

세션이 재대로 unserialize가 되는가.

세션에 포함된 idx, level에 해당하는 사용자가 존재 하는가.

세션의 id와 디비상의 id가 같은가.

level값이 2거나, 세션의 idx와 글쓴이의 idx가 같은가

위 조건을 성립하기 위해선, idx, level 값을 조작하여, 디비에서 글쓴이의 계정정보를 읽어오도록 수행한 후, id를 조작하여 디비의 id와 맞춰주면 된다. 하지만 이 문제를 해결하기 위해서는 3개의 값의 조작이 필요하다.

$result = mysql_query("SELECT id FROM member WHERE idx=$rowm[idx] and level=$rowm[level]");

이를 해결하기 위해 다음 쿼리에 값 조회시 쿼터를 사용하지 않는 것을 확인하였으며, level 값에 sql injection 쿼리를 주입했다. 가입 시 필터링에 포함된 각종 주석 및 공백 필터를 우회하기 위해, TAB(0x09)값을 사용하였다. (Paros를 통해 전달 시 조작)

또한 추가적으로 id값을 비밀글의 계정인 readme로 변경을 수행하였다. (디비 첫 번째 값이 readme 계정)

마지막으로 level값을 2로 맞춰줘야 하는데, php에서는 “숫자 문자열” 이렇게 될 경우 앞의 숫자만을 인식하기 때문에 우회하는데 큰 어려움이 없었다. 최종적으로 다음과 같은 id, pw값으로 가입할 경우 tohsy 페이지에서 인증키의 확인이 가능하다.

ID : 8글자 한글

PASS : ;s:2:"id";s:6:“readme”;s:5:"level";s:8:"2 or 1=1“}

위의 공백은 paros를 통해 전송시 tab(0x09)로 조작하였으며, 비밀글을 확인하여 킷값을 확인할 수 있었다. 

키사측 요청으로 상세 내용은 생략합니다.

바나나팀의 막내(?) EXSO 입니다.

KISA 에선 10월부터 KISA에서 신규 취약점 포상제를 운영하고 있습니다.

포상은 분기별로 이루어지며, 취약점에 대해서 포상 단위는 개별 신고건입니다.

하지만 많은 주변 사람들이 KISA의 취약점 보상제도에 대해 아직 신뢰하지 못한 분들이 많은데 참고하시라고, 신고한 내용에 대한 결과에 대해 그대로 올리겠습니다. 긍정적인지와 부정적인지의 평가는 개인이 내려주시면 되겠습니다.

일단 제 의견은 매우 만족스러운 제도라고 생각합니다. 국내 취약점 연구에 대한 보상 자체를 국가해서 해준다는 자체가 긍정적이며, 꽤 전문적인 평가를 한다는 점과, 크게 인정받지 못하던 국내 소프트웨어 취약점에 대해 상당히 높은 보상을 해준다는 점입니다.

저같은 경우 한컴오피스 2010 파일 포멧을 이용한 code execution 취약점에 대해 신고를 했었으며 평가는 다음과 같은 식으로 이루어 집니다.

금액은 키사측에서 공지한대로 최고 500만원까지의 포상이 이루어진다고 합니다. 

또한, 보안 신고자의 credit 을 다음과 같이 게시해 줍니다. 
http://www.krcert.or.kr/kor/data/secNoticeView.jsp?p_bulletin_writing_sequence=1683
버그헌팅 분야는 공부를 시작한지 얼마 되지않아 이런거 올려주면 기분좋습니다.ㅋㅋㅋㅋ

국내 소프트웨어 취약점 연구하시는 분들은 썩혀두지 마시고 신고하셔서 국내 보안에 기여하시고, 또한 재정에 보탬이 되시기 바라면서 포스팅합니다.