YPrefer's Develop&Security

워너크라이는 올해 5월쯤 전세계적으로 유행한 랜섬웨어 공격인데, 445포트를 통해 감염되는 것이 남다르다.

기업보안담당자 입장에서는, 전 임직원이 MS보안패치를 했는지 관리하고 확인해야 하는 의무가 있는데

그럴때 조금이나마 도움이 될수있는 스크립트가 있다.

link: https://github.com/apkjet/TrustlookWannaCryToolkit

TrustlookWannerCryToolkit은 해당 ip의 pc가 보안패치가 되어있는지 확인하여 결과를 띄워주는 python script인데,

사실 나도 써보진 않았지만 동료가 소개해줘서 글을 적어보았다.

동료의 말로는, 점검을 위해서는 선제되어야 하는 조건이 있는데,

① 445포트가 서비스 되고 있어야 한다고 한다.

결과로는

워너 크라이 패치가 되있는 pc라면 -> 점검완료(done)으로 나오거나 system is not vulnuer

워너 크라이 패치가 되있지 않은 pc라면 -> system is vulnuer

로 나온다고 한다.

XSS(Cross Site Scripting)은 OWASP TOP 10에서도 몇년째 상위를 차지할 만큼

빈번하게 발생하고 강력한 취약점이다.

이 취약점은 사용자가 입력한 값을 검사하지 않고 사용하여, 악성 스크립트가 저장 혹은 실행 되어 나타나게 되는 문제점인데,

초창기에 공격자들은 XSS를 통해 쿠키값을 탈취하는 데에 사용 하였다.

XSS를 통해 document.cookie 값을 공격자의 웹서버로 전송한다던지 하는 방식으로 공격 하였으며,

이를 막기 위해 Explorer 6이상에서 부터 HTTP-only속성이 나오게 되었다.

HTTP-only 속성은 클라이언트의 스크립트가 쿠키에 엑세스 할 수 있는지 여부를 지정하게 되고,

이 속성이 설정되어 있다면 스크립트로 쿠키에 접근할 수 없게 되어, 공격자가 쿠키값을 탈취할 수 없게하도록 하였다.

이에 공격자들은 다른 방법을 사용하게 되었는데,

스크립트를 통해 패스워드 변경(현재 패스워드 확인이 없는경우),

아이디와 패스워드를 입력하는 폼을 만들어 방심하게 하여 탈취하는 경우등으로 공격하게 되었다.

예를 들면 아래 동영상을 들 수 있는데,

이 동영상에서 Salesforce.com 우측에 스크립트가 삽입 되는 것을 공격자가 확인하고,

기존 로그인 폼과 똑같은 화면을 제작하여, 삽입한 것인데 동영상을 보면 이해가 쉽다.

동영상 링크 : https://player.vimeo.com/video/135892408

출처: https://www.elastica.net/salesforce-accounts-susceptible-to-hijacking-using-xss-flaw

XSS의 진단 방법은 간단하다.

<img src=YPrefer onerror=alert(1)> 등의 간단한 스크립트 구문을 전송 구간의 모든 파라미터에 넣어보는 것이다.

이때 입력한 값이 그대로 돌아오거나, DB에 저장되어 나중에 조회시 출력이 된다면 XSS취약점이 있는 것으로 볼 수 있다.

스크립트 구문의 입력을 막기위해 개발자들이 XSS필터를 걸기도 하지만, 완벽하지 않는 경우가 많아.

XSS Cheat Sheet를 확인하여 여러방법으로 시도를 해보아야 한다.

https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet

코드패치 하는 방법은 여러가지가 있는데, IDA를 통해서 하는 방법을 알아보자.

IDA Option을 아래와 같이 설정해 준다.

중요한 부분이 Number of opcode bytes 인데 이것을 6byte로 해주면 OPCODE에 해당하는 HEX값을 확인할 수 있다.

위와 같이 옵션값을 설정해주면 아래처럼 HEX값을 확인 할수있는데,

오른쪽 버튼의 Syncronized With를 HEXVIEW와 연동해 주고, HexVIEW를 들어가면 자동으로 해당 HEX값의 위치를 찾아준다.

여기서 F2를 누르면 HEX값을 수정할 수 있고, 다시 F2는 누르면 수정한 값이 적용된다.

적용된 화면이다.

0F 85 (JNZ) 를 0F 84(JZ)로 코드패치 하여 바뀐 것을 볼 수 있다.

적용된 값은 Ctrl + W를 눌러 다른이름으로 저장을 하면, 변경이 적용된 바이너리가 새로 저장된다.

다른 방법으로는 OP CODE를 HEX값을 알아내어 WINHEX나 010EDITOR와 같은 hexviewer를 통해 열어 직접 수정해주는 방법도 있다.

Fasoo Web DRM 을 사용해서, 웹사이트의 오른쪽 버튼과 스크린샷 방지를 하고 있는 웹사이트들이 있다

웹 DRM은 해당 웹페이지에 접근시, Response로 Fasoo를 활성화 시키는 script를 내려 주는데

Froxy Tool을 이용해 이 script를 삭제 해주면, 오른쪽 버튼과 스크린샷 등이 가능하다.

네이버 블로그 등에서도 마찬가지로 우클릭 우회가 가능한데,

IE에서는 개발자 도구(F12)를 이용해서 사용안함 탭에서 javascript를 체크

크롬에서는 개발자 도구(Ctrl+Shitft+I) 를 이용해서 설정에서 javascript 사용안함에 체크

로 쉽게 우회할 수 있다.

2016/05/31 -  [Security/Android] - [Android APK 진단] 1. 툴 소개 - 추가 16.06.07

2016/06/07 - [Security/Android] - [Android APK 진단] 2. DIVA. 앱 로그 확인하기 1, 하드코딩된 중요정보 확인하기 1

2016/06/07 - [Security/Android] - [Android APK 진단] 3. DIVA. 안전하지 않은 데이터 저장 확인하기 1

2016/06/07 - [Security/Android] - [Android APK 진단] 4. DIVA. 안전하지 않은 데이터 저장 확인하기 2

7. Input Validation Issues - Part 1

유저이름으로 정보를 검색하는 화면이다.

Hint 를 보면 세유저의 정보가 데이터베이스에 있고 그중에 하나는 admin으로 주어져 있다.

처음에 어떤 화면이 저 소스코드인지 몰라서 메인 화면을 보니까 SQL injection 액티비티인것을 확인했다.

소스를 확인하니까 database를 만들고 세 유저의 정보를 넣는 부분을 확인할 수 있다.

보통 SQL injection은 웹해킹시에 쓰이지만, android에서도 db를 만들수 있으니 sql injection공격도 가능하다.

아래와 같이 조건문이 무조건 참이 되도록 만들어주면, 모든 정보를 긁어 올 수 있도록 할 수 있다.

※ 필자의 경험공유 - 필자는 SQL injection 의 경우는 웹 해킹에서만 경험해 보았다.

웹 해킹에서는 sqlmap이라는 sqlinjection 점검 도구를 사용할 수 있는데, 이 Tool이 문제를 종종 일으켜서 같은 url에

같은 파라미터를 대상으로 시도했어도 결과가 다른 결과가 나오기도 해서 python으로 간단한 sqlinjection을 시도하는 스크립트를 만들기도 했었다.

8. Input Validation Issues - Part 2

하단에 URL을 입력하는 화면이 나온다.

소스코드를 확인해보면 입력한 구문이 webview의 url로 들어가는 것을 확인할 수 있다.

file:// 프로토콜을 이용해 단말의 데이터에 접근할 수 있는데, 현재는 nox 에뮬레이터(ROOT권한을 가짐)으로 shell로 확인할 수 있지만,

루팅되지 않은 단말의 경우 권한 에러가 뜨면서 shell에서는 접근이 불가능하다.

2016/05/31 -  [Security/Android] - [Android APK 진단] 1. 툴 소개 - 추가 16.06.07

2016/06/07 - [Security/Android] - [Android APK 진단] 2. DIVA. 앱 로그 확인하기 1, 하드코딩된 중요정보 확인하기 1

2016/06/07 - [Security/Android] - [Android APK 진단] 3. DIVA. 안전하지 않은 데이터 저장 확인하기 1

5. Insecure Data Storage - Part3

화면을 보면 아이디와 패스워드를 입력하는 부분이 나온다. 

아이디와 패스워드 등의 중요정보를 넣고 저장 버튼을 누르면 저장이 성공적으로 완료 되었다는 Toast를 볼수 있다.

코드를 확인해 보면 이번엔 로그인 패스워드와 아이디를 file로 만드는 것을 알 수 있다.

만들어진 temp 파일은 apk 설치 디렉토리 하단에 생성되고 확인해보면 아이디와 패스워드가 저장되있는 것을 볼 수 있다.

※ 필자의 경험공유 - 점검을 했던 앱중에 하나는 파일을 미리보기 할 수 만 있고, 보안정책상 다운로드나 캡쳐는 불가능 했었다.

그런데, 파일 미리보기 할 때 임시파일을 만들어둬서 이것을 중간에 빼낼 수 있었던 사례가 있다.

6. Insecure Data Storage - Part 4

화면을 보면 아이디와 패스워드를 입력하는 부분이 나온다. 

아이디와 패스워드 등의 중요정보를 넣고 저장 버튼을 누르면 저장이 성공적으로 완료 되었다는 Toast를 볼수 있다.

코드를 확인하면 외부저장장치아래에 숨김파일로 uinfo.txt를 만들어 아이디와 패스워드를 저장하는 것을 볼 수 있다.

find 명령을 사용해 해당 파일의 위치를 찾아 확인하면 아래와 같이 아이디와 패스워드를 얻을 수 있다.

find 명령을 설명하면,

/ : 루트 디렉토리 하단에

-name "*uinfo.txt*" : uinfo.txt가 파일명에 들어있는 것을 검색한다.

2>/dev/null : 검색 중 not permitted 등 에러메세지는 출력하지 않는다.

2016/05/31 -  [Security/Android] - [Android APK 진단] 1. 툴 소개 - 추가 16.06.07

2016/06/07 - [Security/Android] - [Android APK 진단] 2. DIVA. 앱 로그 확인하기 1, 하드코딩된 중요정보 확인하기 1

3. Insecure Data Storage - Part 1

화면을 보면 아이디와 패스워드를 입력하는 부분이 나온다. 

아이디와 패스워드 등의 중요정보를 넣고 저장 버튼을 누르면 저장이 성공적으로 완료 되었다는 Toast를 볼수 있다.

해당 액티비티의 코드를 확인해보면, Preference에 user와 password정보를 저장하는 것을 알 수 있다.

find / -name "*앱이름*" 2>/dev/null 명령을 통해 해당 앱이 설치된 디렉토리를 알아내고, (/data/data/패키지명/ 에 설치가 된다.)

하위 디렉토리중 shared_prefs 에 들어가 저장된 xml을 확인해보면 아래와 같이 user와 password가 저장되는 경우를 볼 수 있다.

보통 자동로그인을 구현하기위해 아이디와 패스워드를 preference에 저장해두는데, 평문으로 저장되는 경우도 있고, 암호화를 해서 저장하는 경우도

존재한다.

※ 필자의 경험공유 -  1. 암호화를 하기는 하지만 암호화 키가 소스코드에 박혀있는 경우

2. 아이디의 암호화 로직과 패스워드의 암호화 로직이 같아 암호화된 패스워드를 아이디 부분에 덮어씌우면 앱을 실행시에 로그인을 위해 복호화를 하면서 패스워드가 보이는 경우

3. preference의 암호화키가 단말마다 다르지 않아, xml 파일 자체를 빼내어 다른 단말에 넣어 로그인이 가능했던 경우

4. Insecure Data Storage - Part 2

화면을 보면 아이디와 패스워드를 입력하는 부분이 나온다. 

아이디와 패스워드 등의 중요정보를 넣고 저장 버튼을 누르면 저장이 성공적으로 완료 되었다는 Toast를 볼수 있다.

역시 소스를 확인해보면 DB에 Insert를 하는 것을 알수 있다.

위에서와 같이 설치된 경로밑의 databases폴더에 들어가면, ids2라는 파일이 보이는데, 이 파일을

adb pull /data/data/jakhar.aseem.diva/databases/ids2 명령을 통해 끄집어 낸다

끄집어낸 db파일은 sqllitebrowser를 통해 읽을 수 있다.

※ 필자의 경험공유 - 2016/06/07 - [Security/Etc] - 경험공유 - Android DB 파일 암호화 :)

전에 안드로이드 앱 점검을 하던 중 db파일을 추출해내서 데이터를 확인하려고 한 적이 있었다.

근데, 이게 분명 db파일임은 파일명에서 부터 D!B! 라고 적혀 있어서 확신할 수 있는데, Sqlbrowser을 통해 열리지가 않는 거였다.

심증은 있지만 물증이 없어 확인을 못하던 상황!

혹시나 해서 Hex Editor로 열어보니, 일반적인 DB파일은 Header가 SQL...뭐 이렇게 시작되어야 하는데,

이상한 값으로 적혀있는 걸보고 이상하다 싶어서 hex 값들을 쭉보고 있는데

보통은 00으로 섹션이 나누어지는데 이상하게 77이라는 값이 무지 많이 보였었다.

(정상적인 db파일)

여기서 XOR 연산을 했구나 싶어 malzilla를 이용해 XOR 키를 찾았더니 77을 키로 xor 연산을 한 걸 알 수 있었다.

링크 : http://malzilla.sourceforge.net/

키를 알고 그걸로 다시 복호화를 시도하니 정상적인 db파일로 떨어져서, DB내용을 볼 수 있었다.

오래 되서 잘 기억은 나지 않지만, 암호화 키를 77로 하지 않고 앱의 패스코드와 모바일의 유니크값을

섞은 것을 키로 사용하는 것으로 수정했던 것으로 기억한다.

2016/05/31 -  [Security/Android] - [Android APK 진단] 1. 툴 소개 - 추가 16.06.07

루팅된 안드로이드 단말에 대상 APK 를 설치하고,실행하면 아래와 같은 화면이 출력된다

1. INSECURE LOGGING

여기서 첫번째 안전하지 않은 로그를 살펴보자

보면, 문자열을 입력하고 check out을 누르면, Toast가 하나 뜨는것을 볼수 있는데, 이 화면에서는 입력한 문자열을 중요정보라고 가정하였다.

필자는 nox_adb를 이용해 shell에 들어왔고, 단말을 사용하면 adb shell을 이용하면 된다.

logcat 명령어를 통해 현재 디바이스의 로그를 출력하는데, 앱 패키지 명인 diva로 필터를 걸어 출력하면 아래와 같은 로그를 볼 수 있다.

아래에 credit card정보인 1234가 로그에 평문으로 찍히는 것을 볼 수 있다.

※ 필자의 경험 공유 - 세션 아이디나 아이디 패스워드 등을 출력하는 경우,

함수전달할때의 파라미터, Response 등을 로그로 출력하는 등의 경우가 있는데 이러한 정보는 직접적으로 사용되거나 공격자에게 정보를 줌으로써 다른 방법과 섞여 사용될 수 있다.

2. Hardcoding Issues - Part 1

아래 화면을 보면 key 값을 입력하고, ACCESS버튼을 누르면 접근이 제한되었다는 토스트가 나오고 있다.

JADX를 통해 소스코드를 분석해보면(DIVA난독화가 적용되어 있지 않지만, 설사 적용되어있더라도 일정부분 분석이 가능하다).

단순히 입력 문자열을 비교하는 것을 확인할 수 있고, 이를 통해 하드코딩된 key값을 얻어낼 수 있다.

하드코딩된 키 값을 입력하면 아래와 같이 접근이 허용되었다는 Toast가 출력된다.

※ 필자의 경험 공유 - 2016/06/03 - [Security/Etc] - 경험공유 - Android 데이터 암호화 :)

필자는 LG U+ VIP 인데, 이 등급인 사람에게는 한달에 2회 영화를 무료로!(물론 한명만 대상이 된다.)

볼 수 있는 혜텍이 주어진다.

그런데 예매가 오직 LG U+ 홈페이지. 그것도 데스크탑 환경에서만 가능하고, 영화 상영 1시간 전까지만 가능하다.

상영 1시간 이내에는 아래와 같이 예매 버튼이 비활성화 되어 클릭할수 없게 되는데,.

개발자 도구를 이용하면 이를 우회 가능하다.

즉, 1시간 이내 상영 영화라도 예매가 가능하다는 것이다..!

개발자 도구의 DOM 탐색기 에서 아래의 네모위에 커서 있는 버튼을 클릭하여

비활성화 된 영화를 클릭하여 확인해보면, 아래와 같이 class=soldout으로 되어있는 것을 볼수 있다.

오른쪽 버튼을 눌러 편집으로, class soldout 을 지워준다.

이렇게 해주는 것만으로도 아래와 같이 비활성화가 풀리면서 클릭이 가능해진다.

이를 통해 영화 예매가 정상적으로 가능해지는데,

이는 체크로직이 서버에 있는 것이 아니라 클라이언트의 자바스크립트에 있기 때문이다.

LG입장에서는 이것이 중요하지 않은 체크로직이라 생각해서 클라이언트에 맡겨놓은 것이겠지만,

이렇게 간단한 우회를 통해 개발자가 의도하지 않은 행동을 할 수 있다,.

이와 같이 클라이언트에서의 체크로직은 쉽게 우회가 가능하기 때문에,

암호화 (단방향암호화),  패스워드 체크로직 등이 클라이언트에서 이루어지는지 웹점검시에 확인해보아야 한다.