일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 |
- 모듈러 연산
- 동적타이핑
- 포너블
- 확장 유클리드 알고리즘
- 디오판투스 알고리즘
- 한국정보보호산업협회기자단
- package-lock.json
- 한국정보보호산업협회
- 한국산업인력공단
- 웹 프레임워크
- 백엔드입문
- 개인정보보호위원회
- node.js
- function scope
- package.json
- pwnable.tw
- 마감임박
- 호이스팅
- 가명정보처리
- 국가인적자원개발컨소시엄
- 개인정보안전성
- 무료교육
- arrow function
- 덧셈 암호
- 유클리드_알고리즘
- 개인정보보호교육
- Writeup
- 백엔드
- 개인정보보호
- 곱셈 암호
- Today
- Total
짱짱해커가 되고 싶은 나
[안드로이드 취약점 진단] 1-4. 안드로이드 앱 취약점 점검 기준 본문
글을 쓰기 앞서 15년도 책인 '쉽게 배우는 안드로이드 앱 취약점 진단'을 참고해 작성한 정보이기 때문에 현재 기준과는 상이할 것이다. 안드로이드 취약점 점검을 전반적으로 공부 한 뒤 올해 기준에 맞게 새로 작성할 예정이다. 참고하시길 !
금보원 - 스마트폰 전자금융서비스 보안가이드
14년도에 작성된 보안 가이드 자료다.
- 적용 대상 : 스마트폰 기반 전자금융서비스를 제공하는 금융회사 및 전자금융업자
- 적용 범위 : 스마트폰에서 전자금융거래를 제공하는 앱 기반 전자금융 서비스 4개 분류 13개 항목
각 영역 별 보안 위협과 설계, 개발, 설치, 이용 및 시스템, 관리 단계를 포함한 단계별 보안 가이드를 제공하고 있다.
전체정리 ^*^
[용어 정리]
스마트폰 전자금융서비스 : 금융회사가 스마트폰을 통해 금융상품 및 서비스를 제공하고, 이용자가 금융회사의 종사자와 직접 대면하거나 의사소통하지 않고 스마트폰 전자금융서비스 앱을 이용해 자동화된 방식으로 이를 이용
난독화 : 암호화, 안티디버깅, 가상화 등의 기법을 활용해 리버싱 공격에 대비하여 코드를 읽기 어렵게 만드는 것
루팅 : 안드로이드 기반의 스마트폰 보안기능을 해제해 개인의 취향에 맞도록 기능 및 성능 등을 개선하는 행위
jail break : iOS 기반의 스마트폰을 대상으로 루팅하는 것
배포 인증서 : 앱 프로그램을 배포하기 위해 배포처에서 요구하는 인증서 (배포처 ex. 구글 스토어)
파밍 : 정상적인 홈페이지 주소로 접속해도 피싱 사이트로 접속하도록 유도
큐싱 : QRcode + 피싱
API : 프로그램 또는 app이 os에 어떤 처리를 위해 호출할 수 있는 서브루틴 or 함수의 집합
[스마트폰 전자금융서비스 보안위협]

1. 설치, 개발 단계 보안위협
- 앱 개발 시 위협 - 소스코드 보안 약점, 앱 보안기능 약화 시 위협
- 예로, 입력값 검증 누락, 무한반복, 접근권한, 취약한 암호화 알고리즘, 암호화 통신, 리버싱 취약점 등
- 앱 배포 시 위협 - 검증되지 않은 앱 배포 시 위협
2. 설치, 이용 단계 보안위협
- 스마트폰 - 정보 유출, 배터리 소진 등 단말기 DoS 공격, 키로거 감염, 공격 경로로 활용 등
- 앱 - 정보 유출, 인증정보 탈취, 악성 앱 설치 유도
- 이동통신망/무선 네트워크 - 중간자 공격을 통한 권한 획득, 세션 탈취, 패킷 도청, 정보 유출
3. 시스템, 관리 단계 보안위협
- 내부 시스템 (전자금융서비스 관련 시스템) - 서버 DoS 공격, 데이터 오용 및 유출, 감사 추적 불가
- 보안 관리 - 악성 앱 설치 유도, 정보 수집, 유출
[보안위협 시나리오]
- 입력, 출력, 저장, 전송 과정에서 중요정보 유출 가능

case1. 스마트폰 전자금융서비스 앱 취약점 분석 및 앱 위조
리버싱을 통해 앱 분석 -> 위조 앱 생성 -> 앱 스토어 등록 -> 앱 스토어에 연결하는 URL이 포함된 스미싱 메시지 발신 -> 이용자가 설치 및 실행 -> 개인정보 입력 -> 입력 정보 공격자에게 전송 (에러 메시지로 공격자가 취득한 사실을 인지하지 못하도록 함)
case2. 취약한 웹 서버를 통한 PC 감염
취약한 웹 서버 해킹 -> 웹 페이지에 악성코드 감염시킬 수 있게 변조 -> 이용자 PC 감염 -> 이용자가 스마트폰에 파일을 복사하기 위해 PC와 폰을 usb 케이블로 연결 -> 스마트폰에 악성 앱 강제 설치 -> 내부에서 중요 정보 전송 -> 공격자가 해당 정보를 바탕으로 전자금융서비스에 로그인 시도 -> 거래 인증 문자메시지를 가로채서 공격자에게 재전송 & 문자 삭제 -> 금전 취득
[단계별 보안]

1. 안전한 앱 구현 - 보안 요구사항 정의, 개발환경 구성, 테스트 데이터 이용, 프로그램 작성(시큐어 코딩)
2. 보안 기능 적용 - 보안 기능 적용 및 강화, 중요 기능 고려(앱 권한 관리, 이용자 정보수집 최소화, OS 임의 개조 탐지 및 이용 제한, 무결성 검증, 악성코드 위협 대응, 암호, 인증서 유효성), 앱 분석 방지 (리버싱 방지 기술 적용 - ex. 중요 기능은 네이티브 라이브러리 등으로 구현, 난독화 등 적용)
3. 앱 보안성 확인 - 보안기능 확인, 보안성 확인(자체 테스트)
4. 안전합 앱 배포 - 배포 인증서 관리, 안전한 앱 배포(공식 배포처 이용)
5. 앱 업데이트 관리 - 기능변경 시 검증, 앱 업데이트 관리(보안조치 - 루팅 탐지, 무결성 검증 등 주기적으로 강화)
6. 설치,실행환경 관리 - 보안설정 변경 금지, os 임의 개조 탐지 및 이용 제한, 악성코드 위협 대응, 이용자 정보 수집 최소화
7. 앱 무결성 검증 - 백신프로그램 구동/최신버전 여부, 종단간 암호화 적용 여부, 입력정보 보호 대책 적용 여부, 멀티 로그인 차단 등
8. 이용자 확인 강화 - 이용자 확인, 서비스 가입절차 강화, 멀티 로그인 관리
9. 안전한 통신 - 암호 적용(통신 구간, 중요 정보), 거래전문 무결성 검증, 서버 인증서 유효성 검증
10. 이용자 교육 - 이용자 교육/홍보, 이용자 유의사항
11. 시스템 보안 - 거래정보 관리, 거래기록 보관, 로그 관리, 보안성 검증, 내부 서버 시스템 보안 관리
12. 보안 관리 - 접속 정보 제공, 서비스 이용내역 제공, 분실/도난 시 대응절차, 이상금융거래 탐지 시스템
ps. 부록이 핵심인 듯 (취분 관점에서)
(입력 값 유효성 검증) 텍스트 데이터의 입력·URL을 통해 전달되어지는 데이터·이용자가 제출한HTML과 같이 신뢰할 수 없는 데이터의 열람 등 비정상적인 입력 값을 통해 예기치 않은 다양한 정보를 취득할 수 있다.
(Race Condition) 프로세스 간 동시 또는 거의 동시수행을지원하는 병렬시스템에서 프로세스의 비정상적인 행동을 유도하여이용자에게 사전에 주어진 권한 이상을 수행하는 취약점에 대한고려가 필요하다.
(접근통제의 검증) 프로그램이 이용하는 각종 기능은 적절한 접근통제 정책을 갖고 있으며 해당 통제가 우회되었을 경우에 대한 대비책이함께 고려되어야 한다.
ex. 다른 프로세스 또는 이용자가 쓰기 가능한 위치에 파일이 위치한 경우, 파일 생성 전 파일의 형식·ID·링크 등의 검사가 실패하는 경우, 파일 생성 후 결과 코드가 실패하는 경우
(관리자 상승 권한 기능의 제한) 관리자권한으로 동작하는 기능을 최소화 하여야 하며 이용자 중요정보의 수집 또는 수정되는 기능이 포함되어서는 안된다.
(데이터 보호) 프운영체제에서 지원하는 암호화 기술을 이용할 수 있도록해야 한다.
(예외처리에서 중요정보 노출의 제한) (비인가 API 사용의 제한) (상용 API 이용의 검증)
(임의 파일 업로드의 방지) 외부 파일 업로드 기능이 필요할 경우 전용 디렉토리를 별도로 생성하고 해당디렉토리의 실행권한을 제거해야 하며, 업로드 가능한 파일의 확장명을 정의하고 해당 파일만이 업로드 되도록 설계 및 구현하여야 한다.
(데이터 은닉)
(Null 매개변수의 검사) 일부특정 함수로 기능 구현 시 매개변수 검사를 하지 않는 습관에 의해 예기치 못한 동작이 발생할 수 있으므로 이에 대한 검사를 실시하여야 한다.
- Object.equals(), Comparable.compareTo(), Comparator.compare() 로 구현 시 매개변수를 Null과 비교
(소프트웨어 구동 정보의 보호) Manifest.xml에서 “공유아이디 설정의 삭제”·“외부접근 금지 설정” 등을통해 비정상적인 접근 행위를 방지하여야 한다.
(버퍼오버플로우 검증) (프로세스 간 통신에 대한 검증) (올바른 포인터의 이용) (검증된 API의 이용)
[앱 기반 Push 서비스 보안 고려사항]

- public push - 외부에 구축되어 있는 push 메시지 전송 시스템 활용
- private push - 금융회사 내부의 push 메시지 전송 시스템 구축
- 장점 - 앱 간 내부 데이터 접근 불가능, 메시지 탈취, 삭제 등이 어려움
- 단점 - push 서비스 시스템 해킹, 통신 시 메시지 정보 유출 등
- 사용자별 Push ID 저장 등 Push 메시지 전송 및 앱서비스 시스템에 대한보안 강화 적용 필요
- 통신 시 Push 메시지 유출 등을 방지하기 위한 메시지 및 통신구간 암호화 등 보안 방안 적용 필요
- 안전한 중요 정보(Push ID 등) 저장, 신뢰된 이용자 단말기 인증 등을 위한보안 방안(중요 정보 추출 및 활용 방지 방안, 위․변조 방지 방안 등) 적용 필요
원문은 아래 링크에서 다운 받을 수 있다.
https://t1.daumcdn.net/cfile/blog/277C0E385646EEAF36?download
행정자치부 - 모바일 대인서비스 보안가이드
- 적용 대상 : 전자정부법 제 2조에서 정의하는 행정기관, 공공기관
SW 개발 주기에 따라 발생할 수 있는 취약점을 다룬다.
읽으면 좋을 것 같은데 140pg여서.. 나중에 따로 작성해보도록 하겠다.
아래는 22년 개정본이다.
미래창조과학부 - 모바일 오피스 정보보호 안내서
- 적용 대상 : 모바일 오피스 운영자와 사용자
미래창조과학부 기업에서 모바일 구축 및 운영 시 검토해야할 점검 항목 제공
기타 보안컨설팅 업체의 점검 기준
구분 | 번호 | 취약항목 |
1. 입력값 검증 | 1-1 | 공격 문자열 필터링 여부 |
1-2 | 악성파일 업로드 차단 여부 | |
1-3 | 파일다운로드 경로 검증 여부 | |
1-4 | 매개변수 조작 검증 여부 | |
1-5 | 앱 내부에 저장된 데이터 조작 검증 여부 | |
2. 인증 | 2-1 | 강화된 인증 방식 사용 여부 |
2-2 | 안전한 계정관리 사용 여부 | |
2-3 | 인증 실패 통보 여부 | |
2-4 | 중요 기능 인증 적용 여부 | |
2-5 | 타 사용자 도용 통제 여부 | |
3. 권한 | 3-1 | 적절합 앱 권한 퍼미션 설정 여부 |
3-2 | 서비스 권한 상승 행위 통제 여부 | |
3-3 | 기능제한 우회 금지 여부 | |
3-4 | 불필요하거나 사용하지 않는 activity 제거 여부 | |
3-5 | 인텐트 사용에 대한 안전성 여부 | |
3-6 | 마스터 키 취약점 대응 여부 | |
4. 예외 처리 | 4-1 | 안전한 에러처리 구현 여부 |
5. 암호화 | 5-1 | 중요정보 전송시 암호화 여부 |
5-2 | 전송 패킷의 복호화 함수 및 키 보유 금지 여부 | |
5-3 | 인증서 변조 탐지 미흡으로 인한 통신구간 정보유출 | |
6. 앱 보호 | 6-1 | 앱 자체 보호 및 소스 코드 난독화 여부 |
6-2 | 앱 무결성 검증 여부 | |
6-3 | 루팅 머신 상태 체크 여부 | |
6-4 | 보안 프로그램 적용 여부 | |
7. 데이터 저장 | 7-1 | 저장된 데이터 및 메모리 내 중요정보 노출금지 |
7-2 | 소스 코드 내 중요정보 노출금지 여부 | |
7-3 | 안전한 복호화 알고리즘과 키 길이 사용 및 앱 내부에 복호화할 함수 및 키 보유 금지 여부 |
OWASP Mobile TOP 10
최종 리스트는 2016년도로 14년과 정보가 좀 바꼈다. 16년도 정보에 따르면 M1 ~ M10은 다음과 같다.
(1) M1: Improper Platform Usage (적절하지 않은 플랫폼 사용)
플랫폼의 보안에 대한 개발지침 위반, 기존 관습 사례를 따르지 않았을 경우 혹은 의도하지 않았지만 작업 중 실수 했을 경우 생기는 취약점
(2) M2: Insecure Data Storage (취약한 데이터 저장소)
14년도 M2 + M4, 안전하지 않은 데이터 저장 및 의도하지 않은 데이터 유출
ex. SQLite DB에 중요정보를 평문 형태로 저장하거나 중요정보가 포함된 로그 및 XML 파일, cache 디렉토리에 저장된 데이터 노출, 클립보드에 의한 데이터 노출, 디버그 로그에 의한 정보노출 등
(3) M3: Insecure Communication (취약한 통신)
모바일 -> 모바일, 앱 간 통신, 모바일 -> 다른 쪽 통신 모두 포함
ex. 악의적인 hand shaking, 잘못된 SSL 버전, 민감정보의 평문 통신
(4) M4: Insecure Authentication (취약한 인증)
최종 사용자 인증 또는 잘못된 세션 관리
ex. 사용자 식별을 못하는 경우, 신원이 유지되지 않는 경우, 세션 관리 취약점
(5) M5: Insufficient Cryptography (취약한 암호화)
근본적으로 결함이 있는 암호화/복호화 프로세스를 사용할 수 있다.
(6) M6: Insecure Authorization (취약한 권한부여)
ex. 클라이언트 측의 권한 부여, 강제 검색 등
(7) M7: Client Code Quality (취약한 코드 품질)
모바일 클라이언트의 코드 구현 문제 (서버 측 코딩 실수와 구별)
ex. bof, fsb 등
(8) M8: Code Tampering (코드 변조)
ex. 바이너리 패치, 로컬 리소스 수정, 메소드 후킹, 메소드 변경 및 동적 메모리 수정
(9) M9: Reverse Engineering (리버싱)
ex. 소스 코드, 라이브러리, 알고리즘, 최종 코어 바이너리 분석
IDA Pro, Hopper, o'toole 및 기타 바이너리 검사 도구로 내부 동작 파악
(10) M10: Extraneous FUnctionality (불필요한 기능)
ex. 숨겨진 백도어 기능, 프로덕션 환경으로 배포하지 않을 예정인 기타 내부 개발보안 컨트롤을 생성할 경우
https://owasp.org/www-project-mobile-top-10/
OWASP Mobile Top 10 | OWASP Foundation
OWASP Mobile Top 10 on the main website for The OWASP Foundation. OWASP is a nonprofit foundation that works to improve the security of software.
owasp.org
'모바일' 카테고리의 다른 글
[안드로이드 취약점 진단] 2-2. adb (0) | 2022.06.09 |
---|---|
[안드로이드 취약점 진단] 2-1. 분석 환경 설정 (인시큐어뱅크, apktool, dex2jar, jadx, BytecodeViewer) (0) | 2022.06.09 |
[안드로이드 취약점 진단] 1-3. 안드로이드 파일시스템 및 프로젝트 파일 구성 (0) | 2022.06.07 |
[안드로이드 취약점 진단] 1-2. 안드로이드 애플리케이션 구성요소 (0) | 2022.06.07 |
[안드로이드 취약점 진단] 1-1. 안드로이드 아키텍처 (0) | 2022.06.07 |