보안취약점 관점에서 안드로이드
기존의 OWASP에서 추구하는 웹 취약점 중 몇개만 접목이 가능한것으로 보인다.
일반적인 jsp가 아닌 java .class파일 처럼 배포 한다고 생각 하면 편할것이다.
메모리 오염 취약점은 의미가 없다. java에서 bof, fsb 컴파일 에러나 Out of Memory를 토해내고,
취약점이 발생한다고 해도 WAS처럼 미들웨어 서버가 없기 떄문에 자기 자신의 스마트폰에 대한 권한만 획득 된다.
루틴과 악성코드 관점에서도 Local exploit이기 때문에 큰 의미가 없다.
안드로이드 App을 진단 할때는 원격에 존재하는 DB서버를 어떻게 털것인가에 대한 부분에 포커스를 맞춰야 된다.
1] 세션 예측 취약점
DB세션을 쓴다고 하여도 사용자에 id/pw에 대한 로그인 인증을 하여야 된다.
사용자가 많은 APP의 경우 충분히 공격 해볼만 하다.
(웹 경우 브라우저에 저장되지만 어떻게 저장되고 어떻게 확인하는지는 더 살펴 봐야 되는 부분)
2] sql 인젝션
사용자 입력값에 쿼리 구문을 삽입하여 논리적인 오류를 유발시키는 취약점이다.
이만큼 허접하게 만든 App은 이제 없지 않을까 싶다.
나야나같은 경우도 있지만 이제 많이 알려진 취약점 이고 생각보다 개발자들 수준도
많이 발전 하였다.
3] DB connection 정보 활용
웹과 APP의 가장 큰 차이점은 미들웨어가 존재하냐 존재하지 않느냐 차이이다.
웹에서는 WAS에서 DB connection정보
호스트, DB계정, DB계정 패스워드, DB Name
저장되어 있지만
APP에서는 xml형태에 암호화 되어서 클라이언트 배포파일에 저장될 가능성이 높다.
그래서 그걸 바로 DB에 붙을수도 있지 않을까?
이 부분이 너무 위험해 보인다면 미들웨어 형태 처럼 DB connection 정보를 저장하는 서버를 따로 둘 가능성도 있다.
규모에 따라 다르겠지만 소규모 회사의 App은 충분히 취약점 여부를 파악해 볼만하다.
분석한 정보로 쿼리 분석기 같은 툴로 충분히 찾아낸 접속 정보로 공략 해볼만 하다.
4] 파라메터 변조
KT가 털린 방법이다. 사용자 인자값에 다른 사람의 값을 집어 넣는 형태다.
SP 형태로 인자가 바로 쓰여진다면 더 공약하기 쉽다.
5] 평문으로 데이터 전송
권한 관리를 제대로 하지 않았다면 평문으로 인자가 전달 된다면 충분히 조작해 볼만하다.
4,5번은 큰 차이가 없다.
원격의 DB서버에 대한 접근 방법에 대해서만 나열해 보았다.
안드로이드는 local공격은 의미 없다.
시큐어코딩으로도 저런 취약점은 찾아내기 힘들것이다.
관련 공부를 더 해보면서 차근 차근 접근해 봐야겠다.
1. 세션 타임아웃 설정
2. 로그인 비밀번호 3회이상 틀릴 시 잠금
3. 구간 암호화
