OWASP TOP 10 모바일 취약점 진단항목 정리(2016년 기준)

M1 부적절한 플랫폼 사용(Improper Platform Usage)

• 부적절한 플랫폼의 사용이란 안드로이드, IOS 같은 플랫폼 기능들을 잘못 사용하거나, 보안 통제를 적용하지 않아 문제가 발생하는 것을 말한다. 보통 루팅체크를 위주로 한다. 루팅을 하면 루트권한을 가져 모든 권한에 대해 접근을 할 수 있기에 루팅이 된 폰에서는 접근 할 수 없도록 체크하는 것이 핵심이다. 또한 어플자체가 과도하게 권한을 가질 경우도 공격에 활용 될 수 있다.

대응방안

• 앱 개발 시 접근권한을 과도하게 부여하지 말아야하며 루팅이 된 모바일 기기에서는 접근이 되지 않게 설정한다.

 

 

M2 안전하지 않은 데이터 저장(Insecure Data Storage)

• 보통 모바일 앱을 설치하고 난 뒤에 중요한 정보들이 앱에 입력된다. 자동로그인 같은 편의기능의 사용을 위해 비밀번호나 개인정보같은 중요정보들이 모바일 기기에 저장돼야 할 때가 있는데 이 때 중요 정보들이 평문으로 저장되거나 한다면 모바일 기기를 분실하였을 때나 악의적인 어플을 다운받았을 때 중요정보가 노출 될 수 있다.

대응방안

• 중요정보는 모바일 기기에 저장되지 않게 하거나 저장이 필요한 경우 안전한 암호화 알고리즘을 채택해 저장한다.

 

 

M3 불안전한 통신(Insecure Communication)

• 불안전한 통신은 서버와 사용자간의 통신을 수행할 때 비밀번호와 같은 중요한 정보가 암호화 되지 않고 통신이 이루어지는 경우거나 암호화가 되더라도 불안전한 SSL 버전을 사용하는 경우를 말한다.

대응방안

• 통신 시 안전한 암호화 알고리즘으로 암호화를 수행하거나 취약점 패치가 이루어진 SSL 버전을 사용한다.

 

 

M4 불안전한 인증(Insecure Authentication)

• 기존 웹 어플리케이션에서는 사용자가 항상 온라인 상태이고 서버를 통해 실시간으로 인증이 되지만 모바일에서는 웹과 다르게 오프라인 상태에서 인증을 해야 하는 경우가 있다. 기존 웹 앱과 다르게 인터넷 연결의 안정성이 낮기 때문이다. 이러한 오프라인 상태에서의 인증은 바이너리 공격으로 인증을 우회 할 수 있다.
• 모바일에서는 인증을 할 때에 가용성을 높이기 위해 짧은 비밀번호를 사용하는 경우가 있다(보통 4자리 숫자 기반의 짧은 암호 권장). 암호의 길이가 짧기때문에 레인보우 테이블 등의 공격으로 암호를 쉽게 유추할 수 있고 서버의 암호파일이 노출된 경우 공격자는 쉽게 암호를 추측할 수 있다.

대응방안

• 가능하면 모든 인증 요청이 서버측에서 이루어질 수 있도록 해야한다.
• 4자리 숫자와 같은 단순한 비밀번호 인증방식을 사용하지 말아야한다.
• 로그인유지와 같은 기능을 사용할 때에 사용자의 암호는 기기에 저장하지 말아야한다.
• 휴대폰 인증, 이메일 인증과 같은 추가적인 인증채널을 사용하면 보안을 강화 할 수 있다.

 

 

M5 불충분한 암호화(Insufficient Cryptography)

• 불충분한 암호화는 3가지 유형이 있다.
• 1. 취약한 키 관리 프로세스 : 공격자가 접근 할 수 있는 디렉터리에 키를 보관하거나 바이너리 내에 키를 하드코딩.
• 2. 커스텀 된 암호화 프로토콜 사용 : 자체적으로 암호화 알고리즘을 제작하고 사용한다.
• 3. 취약한 알고리즘의 사용 : MD5, RC2, SHA1 과 같은 취약한 암호화 알고리즘 사용

대응방안

• 공격자가 접근할 수 없는 곳에 키를 관리한다.
• 안전한 암호화 알고리즘 사용(보통 SHA-256 이상 권장)

 

 

M6 불안전한 권한부여(Insecure Authorization)

• 불안전한 권한부여를 알기 전에 알아야 할 것이 인증(Authentication)과 권한(Authorization)에 대해 차이점이다. 인증은 개인을 식별하는 행위이며, 권한은 인증을 한 개인의 수행할 수 있는 행위의 범위를 나타내는 것이다.
• 모바일 환경에서 정당한 인증을 마친 사용자의 권한을 체크하지 않는 경우나 클라이언트 측의 권한과 관련된 요청을 일방적으로 신뢰하는 경우 문제가 있을 수 있다.
• 권한 체크 로직의 부재로 권한이 없는 사용자의 요청에 서버가 응답하거나 앱에서 사용하지 않는 테스트용 기능들을 제거하지 않는 취약점들이 공격자에게 악용 될 수 있다.

대응방안

• 모바일 장치의 권한 정보에 의존하지 말고 중요 기능에 대한 사용자 요청 시 반드시 서버측에서 검증한다.
• 테스트용으로 개발된 기능들은 배포 전 삭제하여 정보노출을 최소화한다.
• 중요 기능들에 대해서는 요청되어지는 값들에 대해 서버를 통한 검증절차를 독립적으로 진행하도록 한다.

 

 

M7 취약한 코드 퀄리티(Client Code Quality)

• 취약한 코드 퀄리티는 주로 모바일 환경에서 실행되는 코드들을 적절히 사용하지 못해 발생하는 문제점이다.(서버에서 실행되는 코드가 아니라 모바일 장치에서 실행되는 코드)
• 이 문제점들로 인해 C의 버퍼오버플로우 또는 DOM based XSS가 발생 할 수 있다.
• 잘못된 API를 사용하거나 안전하지 않은 API를 사용시에 발생한다.

대응방안

• 조직의 구성원들이 일관된 코딩 패턴을 유지한다.
• 읽기 쉽고 문서화를 잘 할 수 있는 코드를 사용한다.
• 버퍼를 사용할 때는 입력값이 버퍼의 길이를 초과하지 않는지 검증한다.

 

 

M8 코드변조(Code Tampering)

• 해당 취약점은 무결성과 관련된 취약점이다. 보통 공격자는 정상적인 어플리케이션 파일을 디컴파일링하여 악성코드를 삽입 후 재컴파일링하여 해당 파일을 배포한다. 주로 게임이나 은행어플들을 노린다.
• 해당 취약점으로부터 여러가지 공격들과 사기행위가 이루어지고 결과적으로 어플리케이션의 매출감소와 명성에 영향을 주게된다.

대응방안

• 해당 어플리케이션이 변조되었는지 무결성을 확인한다.
• 어플리케이션을 변조하기 어렵도록 난독화한다.

 

 

M9 리버스 엔지니어링(Reverse Engineering)

• 해당 취약점은 디컴파일링과 관련된 취약점이다. 일반적인 프로그램들은 한번 컴파일링을 하게되면 역으로 디컴파일링을 하기 쉽지 않지만 대부분의 모바일 어플리케이션 같은 경우는 디컴파일링이 가능하다.
• 공격자는 디컴파일링이 가능한 해당 취약점을 이용하여 코드변조와 같은 공격을 할 수 있다.

대응방안

• 바이너리 암호화
• 어플리케이션 코드 난독화

 

 

M10 불필요한 기능(Extraneous Functionality)

• 종종 개발자는 의도하였던 의도하지 않았던 불필요한 기능들(백도어, 주석)을 어플리케이션에 남겨 놓는 경우가 있다. 해당 기능들이 남아있을 경우 공격자는 이를 활용하여 루트권한 탈취 등과 같은 공격을 할 수 있다.

대응방안

• 제일 좋은 방법은 수동으로 코드의 보안성을 검토하는 것이다.
• 배포 전 로그를 검사하여 불필요한 설명이나 기능들이 기록되어 있지 않는지 검토한다.

 

 

참고 : OWASP Mobile Top 10 – 2016