드로저(Drozer)를 활용한 앱 취약점 진단 | part.2 - 컴포넌트 분석

1. 액티비티(Activity) 분석

명령어 : < run app.activity.info -a [패키지명] > -- 노출된 액티비티를 보여줍니다.

 

위와 같이 5개의 노출되어있는 액티비티들이 출력되었습니다.

 

이제, 실제로 액티비티를 실행시킬 수 있는지 테스트 해보겠습니다.

 

명령어 : < run app.activity.start --component [패키지이름] [컴포넌트 이름] >

 

명령어를 통해 디바이스에서 패스워드 변경 창이 나왔습니다.

원래는 로그인을 한 후에 이 화면을 볼수 있고 Username 부분에 자신의 ID가 입력되어있지만,

 

노출된 액티비티로 인해 Username 입력값이 채워지지 않은채로 패스워드 변경 화면이 실행이 되어버리기 때문에 다른 유저의 패스워드를 임의로 변경할 수 있는 위험이 있습니다.

2. 브로드캐스트 리시버(Broadcast Receiver) 분석

명령어 : < run app.broadcast.info -a [패키지명] >

 

MyBroadCastReceiver라는 이름의 브로드캐스트 리시버를 확인할 수 있습니다.

3. 콘텐츠 프로바이더(Contents Provider) 분석

명령어 : < run app.provider.info -a [패키지명] >

 

결과값을 보면, "TrackUserContentProvider" 가 노출되었습니다.

콘텐츠 프로바이더는 데이터베이스에 있는 정보를 URI로 공유하기 때문에 데이터베이스에 접근하기 위해서는 URI에 대한 정보가 반드시 필요합니다.

 

따라서 URI 정보를 찾으려면

명령어 : < run app.provider.finduri [패키지이름] >

 

아래 결과값이 나왔습니다. URI주소는 특정 데이터에만 접근하도록 제한하여 공유하게 되어있습니다.

얻은 URI 정보로 어떤 정보에 접근할 수 있는지 확인해보겠습니다.

 

명령어 : < run scanner.provider.sqltables -- uri [URI주소] >

 

android_metadata, names, sqlite_sequence 이렇게 3개의 테이블에 접근할 수 있었습니다.

이제 app.provider.query 명령어를 통해 직접적인 데이터를 추출해보겠습니다.

명령어 : < run app.provider.query [URI] >

 

로그인했던 사용자들의 ID가 로그인한 순서대로 출력되는 것을 확인할 수 있습니다.

위의 결과를 뽑은 테이블 외에 다른 테이블이 존재하는지 확인하기 위해 sqlite_master 테이블을 확인해보겠습니다.

 

* sqlite_master 테이블 -- 현재 엡에서 사용하고 있는 테이블들의 정보가 담긴 테이블.

 

명령어 : < run app.provider.query [URI] --projection "* FROM SQLITE_MASTER WHERE type='table';--" >

projection 뒤로 적힌건 사용자가 지정한 쿼리구문입니다.

위와 같이 sql_master 테이블이 조회되었습니다.

이렇게 사용자가 쿼리문을 직접 조작하여 데이터베이스에 적용할 수 있기 때문에 sql injection도 발생할 수 있습니다.

 

지금까지 콘텐츠 프로바이더 정보 분석 -> URI 정보 획득 -> 쿼리문 생성하여 sql injection 공격 가능 확인

이라는 절차를 밟았습니다.

 

이러한 작업을 자동으로 해주는 scanner.provider.injection 모듈을 사용해보겠습니다.

명령어 : < run scanner.provider.injection -a [패키지명] >

 

아래 결과처럼 취약한 URI와 공격 방법 별로 분류하기 때문에 많은 데이터를 분석할 때 유용합니다.

4. 서비스(Service) 분석

서비스는 화면에 보이는 액티비티와 반대로 UI가 없으며, 백그라운드에서 실행되는 컴포넌트입니다. (ex. 음악앱)

명령어 : < run app.service.info -a [패키지명] >