1. 개요

- 모바일 보안 위협은 (보이스)피싱, 스미싱 등 다양하게 발생하며 피해가 지속적으로 보고되고 있음

- OWASP에서 모바일 보안 위협 TOP 10을 발표

> OWASP(The Open Web Application Security Project): 웹 애플리케이션 보안과 취약성을 평가하는 단체로 비정기적으로 보안 위협을 조사해 발표

[사진 1] 모바일 TOP 10 2016 2023 비교

 

2. 주요내용

구분 위험 설명
1 부적절한 자격 증명 사용 하드코딩된 자격 증명 또는 부적절한 자격 증명 사용(인증 정보 평문 전송, 부적절한 검증, 자동 저장 등)으로인해 인증 우회 등이 발생가능한 취약점
- 데이터 침해, 사용자 개인 정보 유출, 관리자 권한 접근 등 피해 발생 가능
인증 정보의 하드코딩 금지, 인증 정보 암호화 전송, 비밀번호 저장 기능 사용 금지 등의 조치
2 부적절한 공급망 보안 공급망을 악용하여 악성코드가 삽입된 업데이트 파일 등을 유포하여 사용자의 기기에 접근해 악성행위를 가능하도록 하는 취약점
- 내부자, 써드파티, 악성코드가 포함된 오픈소스 등의 사용으로인해 발생 가능
- 데이터 침해, 사용자 개인 정보 유출, 관리자 권한 접근 등 피해 발생 가능
모바일 앱 개발 수명주기 전반에 걸친 코드 검토 및 시큐어 코딩, 검증된 라이브러리 사용, 주기적 업데이트 적용, 모니터링 등의 조치
3 안전하지 않은 인증/권한 부여 부적절한 인증(인증 체계 누락 등)를 통해 정식 인증 우회 및 권한(과도한 권한 부여 등)을 악용 추가적인 악성행위를 수행
- 데이터 침해, 사용자 개인 정보 유출, 관리자 권한 접근 등 피해 발생 가능
인증 절차의 강화, 최소권한부여, 서버 측에서 인증 요청 검증, 비밀번호 저장 기능 사용 금지 등의 조치
4 불충분한 입력/출력 검증 입력 데이터에대한 검증 및 삭제가 불충분하여 임의 명령 실행 등이 발생 가능한 취약점
- 데이터 침해, 임의 명령 실행, 관리자 권한 접근 등 피해 발생 가능
입력 길이 제한 및 삭제 등 엄격한 입력값 검증 적용, 데이터 무결성 검사, 시큐어코딩 적용 등의 조치
5 안전하지 않은 통신 네트워크를 통해 데이터를 평문으로 전송하거나 취약한 네트워크 사용 등으로 인해 발생 가능한 취약점
- 인증 정보 도용, 중간자 공격 등 피해 발생 가능
암호화 전송, 엄격한 인증서 관리 등의 조치
6 부적절한 개인 정보 보호 제어 공격자가 알려진 취약점을 이용해 시스템을 침해한 후 부적절하게 관리되고 있는 개인정보에 접근이 가능하게되는 취약점
- 사용자 개인정보 불법거래, 유출 정보를 이용한 2차 피해 등이 발생 가능
목적 범위 내 필요한 최소한의 정보만 저장, 가명화 또는 익명화 적용, 목적 달성 등 불필요시 즉시 삭제 등의 조치
7 바이너리 보호가 부족함 리버싱 등으로 소스코드에 하드코딩된 정보, 키(API, 암복호화 등) 등을 탈취하거나 코드를 변조하여 악성 코드를 포함하도록 하는 등의 취약점
- 키 정보의 유출, 코드 위변조, 악성코드 삽입 후 재배포 등이 발생 가능
소스코드 난독화, 무결성 검사, 모니터링 등의 조치
8 잘못된 보안 구성 불필요한 권한 설정, 부적절한 액세스 제어, 평문 전송 등 잘못된 보안 구성으로 인해 발생가능한 취약점
- 데이터 침해, 관리자 권한 접근 등의 피해 발생 가능
기본 계정정보 변경, 최소권한부여, 입력값 검증, 암호화 등의 조치
9 안전하지 않은 데이터 저장 취약한 암호화, 부적절한 데이터 보호, 평문 저장 등으로 민감정보, 내부 정보의 유출이 발생할 수 있는 취약점
- 데이터 침해, 무결성 문제 등 피해 발생 가능
강력한 암호화, 입력값 검증, 적절한 액세스 제어 등의 조치
10 암호화가 불충분함 취약하거나 불충분한 암호화로인해 민감 정보와 데이터의 기밀성과 무결성이 저하되는 등의 문제가 발생가능한 취약점
- 데이터 침해, 무결성과 기밀성 등 피해 발생 가능
안전한 암호 알고리즘 적용, 안전한 암호화 키 관리 등의 조치

 

2.2 모바일 운영체제별 보안 위협

구분 위협 설명
안드로이드 리버스 엔지니어링 - 안드로이드 앱은 이클립스(Eclipse)와 같은 통합개발환경을 갖춘 자바(Java)로 개발
> 자바 앱은 인터넷에서 쉽게 검색 가능한 다양한 도구로컴파일 이전으로 복구가 가능

- 바이트코드를 변경하거나 APK 파일 형식으로 재패키징할 수 있음
> 테스트 로그인 자격증명 등 정보와 함께 암호화 유형의 세부정보도 노출될 수 있음
> 공격자는 이를 악용해 복호화로 디바이스 해킹이 가능
안전하지 않은 플랫폼 사용 - 앱 개발자가 보안에 불안전한 안드로이드 인텐트(Intent)나 플랫폼 권한 설정을 통해 모바일 OS와 통신할 때 보안 위협이 발생 가능

- 안드로이드 OS는 브로드캐스트리시버(BroadcastReceiver) 구성요소를 이용해 앱과 시스템 전체의 브로드캐스트를 송수신
> 브로드캐스트 리시버 인스턴스를 수신하기 위해 안드로이드 디바이스에 스누핑 공격을 수행할 수 있음

※ 스누핑(Snooping): 네트워크 상의 정보를 염탐하여 불법적으로 얻는 것을 의미
업데이트 무시 - 구글은 안드로이드에서 새로운 취약점에 대응하기 위해 끊임없이 OS 보안 패치를 발표
> 개발자(또는 사용자)가 업데이트를 적용하지 않음으로 발생가능
루팅된 디바이스 - 안드로이드 OS는 사용자가 서드파티 앱을 이용해 디바이스의 루트 권한을 획득하도록 허용
> 루팅된 디바이스가 해커나 악성 소프트웨어를 통한 위변조에 노출될 수 있음을 깨닫지 못하고 있음

- 개발자는 앱이 루팅된 환경에서의 실행을 차단하거나 사용자에 경고 메시지를 띄우는 것이 필요
새로운 공격 벡터를 통한 
스파이론 애플리케이션 증가
- 최근 간편하게 소액 대출을 제공하지만 높은 이자율과 추가 수수료가 부과되는 ‘스파이론(Spyloan) 앱’이 증가
> 대출 승인 전에 과도한 개인정보를 무단 수집 및 스캔들 메시지 발송 및 사진 조작 등 피해 발생
iOS 탈옥 - ‘탈옥(Jailbreak)’은 사용자가 서명되지 않은 코드를 모바일 디바이스에서 실행하도록 커널의 보안 허점을 이용하는 것
사용자 인증 - iOS는 얼굴인증(Face ID)이나 지문인증(Touch ID) 등으로 보안을 강화
> OS와는 별도로 전용 마이크로 커널에서 실행되는 ‘시큐어 인클레이브(Secure Enclave)’를 적용한 프로세스를 사용하도록 설계

- 공격자는 그레이시프트(Grayshift) 사의 iOS 암호 크랙인 그레이키(GrayKey)를 활용하면 인증을 뚫을 수 있음
데이터 저장소 보안 위험성 - 대부분의 앱은 SQL 데이터베이스, 쿠키, 바이너리 데이터 저장소 등을 사용해 데이터를 저장
> 데이터 저장소는 운영체제, 프레임워크 또는 컴파일러의 취약점이 있을 때 해커에 위치가 노출될 수 있음

- 공격자는 DB에 접근하고, 앱 변조로 자신의 컴퓨터에 사용자 정보가 수집되도록 조작할 수 있음
> 탈옥된 디바이스라면 복잡하게 설계된 암호화 알고리즘도 손쉽게 노출될 수 있음
참고 - iOS에서 사용할 수 있는 애플리케이션은 모두 애플에서 직접 만든 앱스토어를 통해서만 다운로드할 수 있음
- iOS 애플리케이션은 애플의 앱 개발 전담팀에서 2주간의 검수 과정을 통해 악성코드, 바이러스, 멀웨어 등의 감염과 피해 등을 철저하게 조사한 후 등록
> 앱 보안 위협은 상대적으로 낮은편

- 애플의 iOS는 안드로이드 OS와 달리 보안 정책이 엄격하며 폐쇄형
- iOS 앱은 다른 앱과 통신 또는 디렉토리나 데이터에 직접적으로 접근할 수 없

 

3. 대응방안

① 개발자는 앱을 플랫폼에 공개하기 전 철저한 보안 검사가 필요

- 사용자의 보안 강화를 위해 데이터 암호화 및 방화벽과 보안도구 사용을 포함해 전반적인 데이터 보안 정책과 지침을 수립

- 새로운 앱을 개발했을 때 개발자는 앱을 앱스토어에 등록하기 전에 외부인을 통해 앱 보안 취약점을 점검

 

② 사용자는 앱 사용이 끝나면 해당 사이트에서 로그아웃하고 종료

- 금융권 웹사이트를 사용할 때는 비밀번호를 저장하지 않고, 로그아웃 여부를 재차 확인하는게 중요

 

③ 사용자가 웹사이트나 앱에 로그인할 때 기본적인 로그인 외에 멀티팩터(Multi Factor) 인증으로 보안을 강화

- 아이디와 패스워드 이외에 2차로 지문·홍채 등 생체인식, 인증서, 이메일, OTP 등이 사용되며, 로그인 시 별도의 비밀코드를 제공

 

모의 침투 테스트

- 앱 내의 알려진 취약점을 확인

 

⑤ 사내 네트워크에 개인 소유 디바이스를 연결할 때는 사전 보안 검사

 

적절한 권한 부여, 키 관리 등

- 스마트폰 내에 디폴트 권한을 넘어 특별한 기능의 권한까지 부여되면 보안에 심각한 위협을 유발

- 키는 사용자 디바이스가 아닌 안전한 컨테이너에 보관하는 습관

- 개발자는 256비트 키를 사용하는 SHA-256 해시 등 최신 암호화 표준과 API를 사용

 

주기적인 앱 보안 테스트

- 랜섬웨어, 피싱 등 다양한 보안 위협에서 스마트폰을 안전하게 사용하기 위함

 

4. 참고

[1] https://owasp.org/www-project-mobile-top-10/
[2] https://www.boannews.com/media/view.asp?idx=121927&page=2&kind=5

[캡쳐 1] https://owasp.org/Top10/A10_2021-Server-Side_Request_Forgery_%28SSRF%29/

서버 측 요청 변조(Server-Side Request Forgery, SSRF)는 2021년에 신설된 항목이다. SSRF는 서버 측에서 위조된 요청을 보내도록 하는 취약점이다. 애플리케이션이 사용자 제공 데이터에 대해 적절한 검증 없이 사용할 경우 서버로 하여금 공격자가 강제한 제어 동작을 수행하게 된다.

대응방안으로는 클라이언트가 제공한 입력값을 검증하도록 하고, 클라이언트 요청에 대한 응답을 전송하기 전에 서버측에서 결과를 검증한다. 또한, 방화벽을 통해 접근제어 규칙을 적용하여 네으퉈크단에서 필터링을 수행한다.

 

취약점 유형

사용자 입럭 데이터에 대한 적절한 검증없이 로컬 혹은 원격 리소스에 접근하도록 하는 경우

 

공격 시나리오

추후 업로드 예정

 

대응방안

내부 네트워크간 통신의 경우에도 방화벽을 통해 접근통제 규칙을 적용
모든 사용자 입력 데이터에 대한 검증
클라이언트 요청 수행 후 응답에 대해 서버측 결과 검증

[캡쳐 1] https://owasp.org/Top10/A09_2021-Security_Logging_and_Monitoring_Failures/

보안 로깅 및 모니터링 오류(Security Logging and Monitoring Failures)는 OWASP TOP 10 2017에서는 A10로 소개된 불충분한 로깅 및 모니터링(Insufficient Logging & Monitoring) 항목으로 변경되었다.

적절한 로깅과 모니터링이 부재할 경우 침해(공격)을 감지 및 대응하지 못하기 때문에, 데이터 유출 시 공격자의 접근 경로나 유출된 데이터 항목에 대한 확인이 불가하며, 이에 대한 조치 또한 불가하게 된다.

대응 방안으로는 모든 로그인 시도, 데이터 접근 시도 등을 로깅으로 기록하고, 이를 주기적으로 모니텅링하며, 백업하여 보관한다. 또한, 인가된 접근과 비인가 접근에 대해 탐지 및 대응할 수 있도록 지속적인 모니터링을 수행한다.

 

취약점 유형

로그인, 접근 시도 등 중요한 기능에 대한 로깅이 없는 경우
로깅은 생성하나 불명확하거나 부정확한 로깅을 생성하는 경우
로깅 및 모니터링이 존재하나 필요 영역에 대해 불명확한 로깅 및 모니터링이 수행되는 경우
로깅에 대한 백업 절차가 없는 경우

 

공격 시나리오

적절한 로깅이나 모니터링이 없어 데이터가 유출된 후 뒤늦게 인지하고 조치를 수행하거나, 혹은 데이터 유출이 발생한지에 대해 인지하지 못할 가능성 또한 존재한다.

 

대응방안

모든 로그인, 접근 제어, 인증 실패에 대해 로깅을 생성하고, 백업을 수행
로그 관리 솔루션 등을 사용해 로깅이 적절히 생성되는지 확인
모니터링을 통해 비인가 접근 및 의심 행위에 대한 신속한 탐지 및 대응
침해 사고 대응 및 복구 계획 수립

[캡쳐 1] https://owasp.org/Top10/A08_2021-Software_and_Data_Integrity_Failures/

소프트웨어 및 데이터 무결성 오류(Software and Data Integrity Failures)는 OWASP TOP 10 2017에서는 A08로 소개된 안전하지 않은 역직렬화(Insecure deserialization)를 포함해 2021에서 신설된 항목이다.

애플리케이션이 신뢰할 수 없는 소스, 저장소 및 CDN의 플러그인, 라이브러리 또는 모듈에 의존하는 경우 발생할 수 있다. 충분한 무결성 검증 없이 수행되는 자동 업데이트 기능을 악용해 공격자가 직접 업데이트를 업로드해 조작된 파일을 배포하고 설치, 실행 할 수 있다. 

대응 방안으로는 신뢰할 수 있는 라이브러리를 사용하고, 전자서명이나 해시를 통해 무결성을 확인한다. 또한, CI/CD(Continuous Integration/Continuous Deliver_지속적 통합/지속적 제공) 파이프라인의 경우 개발 및 배포 과정에서 변조되면 무결성이 훼손될 가능성이 있으므로, 무결성 검증 과정을 추가해야한다.

 

취약점 유형

사용중인 라이브러리에 무결성 검증 기능이 없어 변조가 가능한 경우
업데이트에 대한 검증이 없는 경우 - 공급망 공격 가능
CI/CD 파이프라인에 대한 보안성 검토가 부족하거나 없는 경우
직렬화된 데이터에 대한 무결성 검증이 없는 경우

 

공격 시나리오

공격자는 공급망 공격(시스템 및 데이터에 접속할 수 있는 외부 협렵업체나 공급업체를 통해 시스템에 침투하여 합법적인 앱 감염 후 멀웨어 배포)을 통해 시스템을 장악한 후 인증서 탈취, 코드 패치, 업데이트 위장 등의 방식으로 악성코드를 업로드할 수 있다. 악성코드는 정상 파일로 위장되어 배포되고, 사용자들이 이를 다운로드하면서, 악성코드 감염 및 추가 공격을 수행할 수 있다.

 

대응방안

전자서명, 해시 알고리즘을 통한 무결성 검증
사용중인 라이브러리에 대한 신뢰성 확인 및 중요한 서비스일 경우 내부 라이브러리 사용
CI/CD 파이프라인에 대한 보안성 검토
직렬화된 데이터에 대한 무결성 검증 수행

[캡쳐 1] https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/

식별 및 인증 실패(Identification and Authentication Failures)는 OWASP TOP 10 2017에서는 A02으로 소개된 취약한 인증(Broken Authentication)를 포함해 2021에서는 A07로 소개되었다. 2017 대비 조금 더 넓은 의미를 포함한다.

대응 방안으로는 2중 인증을 구현하고, 비밀번호 설정 정책을 적용하고, 다수 로그인 실패 시 계정 잠금을 통해 지속적인 비인가 로그인 시도를 예방한다. 임의의 랜덤한 값으로 세션 ID를 생성해 부여하고, 암호화된 채널을 통해 전송 및 세션 ID를 재사용하지않고 폐기해야 한다.

 

취약점 유형

유효한 계정 목록을 가지고 있는 경우 Brute Forcing 등 자동화된 공격을 시도, 허용하는 경우
기본 계정 정보를 사용하는 경우
다중 인증이 존재하지 않는 경우
URL에 세션 ID를 노출하는 경우(GET Method)
세션 ID를 재사용하거나 만료된 세션 ID를 파기하지 않는 경우

 

공격 시나리오

유효한 계정 목록을 가진 공격자는 자동화 툴을 사용해 Brute Force 공격을 시도할 수 있고, 이때 , admin/admin 등 기본 계정 정보나 잘 알려진 계정 정보를 사용하고 있는 경우 공격자는 계정을 탈취해 임의의 명령을 수행하는 등 악의적인 행위를 수행할 수 있다.

 

대응방안

다중 인증 구현
기본 계정 정보를 사용 금지
안전한 패스워드 설정 정책 생성 및 인증 실패 횟수 제한 적용
임의의 랜덤한 세션 ID 생성, 암호화 채널 등 안전한 전송 수단을 통한 전송 및 재사용 금지와 만료된 세션 ID 파기 

[캡쳐 1] https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/

취약하고 오래된 구성 요소(Vulnerable and Outdated Components)는 취약한 버전이나 EoS, EoL(기술 지원 종료)인 소프트웨어를 계속 사용하는 경우 발생가능한 유형이다. 서비스를 구성하는 모든 요소(OS, WEB, DB, API 등)가 영향을 받는다.

대응방안으로는, 형상관리를 통해 불필요한 서비스를 제거하고, 버전 정보를 확인하여 최신 버전으로 업데이트를 적용한다. 또한, 모니터링을 통해 취약점이 발생한 버전을 확인하여 조치한다. 추가적으로, 애플리케이션 또는 포트폴리오의 수명 주기 동안 업데이트 또는 구성 변경을 모니터링, 분류 및 적용하기 위한 지속적인 계획을 수립해야 한다.

 

취약점 유형

기술 지원 종료된 OS를 사용하는 경우
취약점이 존재하는 애플리케이션, 프레임워크, 라이브러리 등을 사용하는 경우

 

공격 시나리오

[캡쳐 2] Apache struts 2 취약점(CVE-2018-11776)

취약한 버전의 아파치 스트럿츠 2(Apache struts 2)를 사용하고 있는 경우, 원격의 공격자가 서버를 공격해 원격코드를 실행할 수 있다.

 

대응방안

불필요한 소프트웨어나 서비스, 기능, 문서 등 제거
패치 관리, 형상 관리 프로세스 정립 - 소프트웨어 버전 확인 및 업그레이드
 취약점 모니터링을 통한 취약한 소프트웨어 사용 유무 확인

[캡쳐 1] https://owasp.org/Top10/A05_2021-Security_Misconfiguration/

보안 설정 오류(Security Misconfiguration)는 설정 오류 또는 잘못된 설정, 미비한 설정으로 인해 발생되는 취약점이다. 최초 설치시 또는 업데이트 시 보안성을 고려하지 않은 설정을 적용하는 경우가 해당된다. 2017년 A04로 소개된 XXE(XML External Entity) 항목이 포함되었다.

대응방안으로는, 애플리케이션 설치 시 기본으로 제공하는 기능, 구성 요소, 문서 및 샘플을 제거한다. 신규 또는 업데이트 시에 적절한 보안 설정이 적용되었는지 검토하고, 검증하는 프로세스를 구현한다. 또한, 보안헤더를 적용해 보안을 강화한다.

 

취약점 유형

애플리케이션에 적절한 보안 강화가 누락되었거나 클라우드 서비스에 대한 권한이 부적절하게 구성된 경우
불필요한 기능이 활성화 또는 설치되어 있는 경우(ex. 불필요한 포트, 서비스, 페이지, 계정 또는 권한)
Default 계정 및 암호가 활성화되어 있으며, 변경되지 않은 경우
오류 메시지를 통해 어플리케이션 정보가 사용자에게 보여지는 경우
보안 헤더 설정 누락

 

공격 시나리오

[캡쳐 2] 관리자 페이지 노출 (https://blog.naver.com/harang8069/222442475481)

애플리케이션 설치시 기본으로 제공하는 관리자 페이지에 보안 설정 없이 사용하여 외부에 노출되는 경우 공격자가 이용할 수 있다.

 

대응방안

최초 설치 시 불필요한 기능, 구성 요소, 문서 및 샘플 제거
보안 헤더 적용
모든 환경에 대하여 보안 설정을 검토 및 검증하는 프로세스 구현

[캡쳐 1] https://owasp.org/Top10/A04_2021-Insecure_Design/

안전하지 않은 설계(Insecure Design)는 2021에 새로 추가된 항목이다. 이는 초기 기획 및 설계 단계에서 보안이 제대로 고려되지 않아 발생하는 보안 결함을 뜻한다. 즉, 누락되거나 비효율적인 제어 설계로 표현되는 다양한 취약점을 나타내는 카테고리이다. 안전하지 않게 설계된 애플리케이션은 개발 완료 후 코드를 수정하여도 보안 결함을 완벽히 방어하는데 한계가 있다. 따라서, 설계 단계에서부터 보안을 적절히 고려해야 할 필요가 있다.
 
안전한 보안 설계를 위해서는 보안 설계, 보안 개발 수명 주기, 위협 모델링 등이 필요하다.

 

[캡쳐 2] 소프트웨어 개발보안 방법론 (출처 : 행정안전부)

 

+ Recent posts