[사설] Android 보안 동향 - 2020 KISA 리포트를 바탕으로

 

Android 가 어떤 보안적인 취약점을 거치고 보안했는지 궁금해서 관련 자료를 찾다가 "2020 KISA REPORT" 를 찾았고 "안드로이드 11까지 안드로이드를 지탱해 온 보안 (최필식, 기술작가)" 이라는 주제로 작성된 글을 바탕으로 그간의 안드로이드 보안 내용을, 개인적인 의견을 더해서 살펴보고자 한다.

https://www.kisa.or.kr/uploadfile/202006/202006300929063919.pdf

 

안드로이드 보안에서는 크게 운영체제 자체의 보안 + Application 단에서의 보안으로 나눌 수 있다.

운영체제 보안은 당연히, 안드로이드에서 운영체제 개념이 새로 도입된 게 아니니 처음부터 무척 신경썼을 것이다.

운영체제의 기본이 보안 취약점을 찾아내고 보안하는 것인데, 시간이 지날수록 안드로이드는 운영체제에서 발견한 취약점을 '빨리 메워야' 했다. 그래서 운영체제 전체를 업데이트하지 않고 보안 업데이트를 하는 식으로 적용했다.

 

또한, 허용된 사용자만의 데이터 접근은 데이터를 다루는 곳이면 어디든 중요한 기술이다.

안드로이드 운영체제도 이와 관련된 보안 및 암호화 기술을 강화했다.

 

이 외로도 앱을 유통하는 '스토어'에 대한 보안도 강화됐다.

아무리 안드로이드 시스템을 잘 만들었다고 한들, 그 위에서 돌아가는 Application 이 악의적이라면 안드로이드 시스템이 건들 수 없을 수 있다. 실제로도 악의적인 앱을 만들어서 개인 정보를 탈취하려는 시도가 많았고, 특히 최근에는 생체 정보 (지문, 홍채, 얼굴 인식 등) 를 스마트폰에서 접근하는 일이 잦아지면서 이 문제는 더욱 중요해졌다.

 

 

이제부터 안드로이드 버전별로 어떻게 보안적인 사항이 추가되었는지 살펴본다.

 

안드로이드 1.5: 운영체제 자체의 공격을 중심으로

• 스택 버퍼 오버런 방지 / 정수 오버플로우 / double free() 취약점 방지
• 청크 통합 공격 방지
• 메모리 할당 중 정수 오버플로우 방지

 

안드로이드 2.3 (진저브레드): NFC 지원

• NFC 는 도청, 데이터 손상 및 조작, 가로채기 등 보안 위협이 많기 때문에, 이를 지원한다는 것 자체가 굉장한 시도였다.

 

안드로이드 3 (허니콤): 태블릿 전용

• 안드로이드 최초로 태블릿 전용으로 출시된 운영체제.
• 상대적으로 강화된 보안성
• 사용자 데이터를 암호화하는 기능 제공
• 응용 프로그램의 지정된 저장소 외의 저장소 (메모리 카드 등) 에 대한 쓰기 권한 제한

 

안드로이드 4.0 (아이스크림 샌드위치): 얼굴 인식 잠금 해제

• 2011년에 발표하였는데, 얼굴 스캔 방식의 완성도가 매우 낮아서 우회할 수 있었다. (얼굴 구조가 비슷한 사람이나 사진만 있어도 가능)
• 데이터 전송을 위한 '안드로이드 빔'은 암호화되지 않은 정보를 전송할 수 있었다. (도난성)

 

안드로이드 4.2 (젤리빈): 안드로이드 보안의 큰 변화. SELinux (Security Enhanced Linux)

• 허용되지 않은 모든 것을 거부하는 접근 제어 모듈을 추가하여,
• 안드로이드 커널을 보호 + 응용 프로그램의 데이터 및 시스템 로그 접근 제어
• 악성 프로그램의 권한 자체를 줄이고자하는 시도였으나 앱에 강제적으로 적용된 것은 아니었다...

 

안드로이드 5.0 (롤리팝): 가장 많은 변화와 새로운 보안 취약점

• 기존 자바 실행 컴파일러였던 Dalvik 을 JIT 로 교체하면서 성능 향상을 꾀했다.
• 안드로이드 오버로드 결함을 악용한 보안 취약성
• 공격자가 잠금 해제를 하지 않고도 접근할 수 있는 '카메라' 화면에서 악의적으로 작동하도록 하면 (굉장히 긴 문자열 이용 등) 카메라 앱과 홈 런처가 충돌하여 잠금이 해제됨
• 이후 수정을 통해 장치 암호화를 기본값으로 변경,
• 모든 앱의 SELinux 강제 모드를 필수로 설정
• 원격으로 공장 초기화할 수 있는 킬 스위치 (Kill Switch) 도입

 

안드로이드 6 (마시멜로우): 다른 스토어를 통한 악의적 장치 권한 획득 보안 취약점

• 상대적으로 안드로이드 자체의 보안 문제보다, 공식 앱스토어 (구글 플레이) 가 아닌 다른 앱스토어에서 다운로드한 앱으로 특정 회사의 모바일 프로세서를 탑재한 장치의 권한을 획득할 수 있는 보안 취약점이 이슈였다.
• 구글은 안드로이드 보안 게시판을 만들어 보안 취약성에 대해 보고하고 보안 패치를 자동으로 업데이트하는 시스템을 만들었다.

 

안드로이드 7.0 (누가): 보안 측면에서의 많은 변화

• 장치 암호화 저장소 및 자격 증명 암호화 저장소 등 데이터를 2개 그룹으로 나누었다.
• 강력한 파일 기반 암호화
• 스테이지프라이트 (StageFright, 2015년 악명 높았던, 안드로이드 비디오 재생 라이브러리를 오버플로우 시켜 상승한 권한으로 악성 코드를 실행) 를 방지하기 위한 미디어 서버 개선
• VPN 상시 작동
• 업무 시간이 지나면 모든 업무 관련 앱을 사용 중단 시키는 작업 모드 아이콘 추가

 

안드로이드 8.0 (오레오): 앱의 변조 방지를 위한 정책과 보안 기술

• 구글 플레이가 악성 스토어에서 사용자가 앱을 설치할 때의 위험성을 인식, 기존 한 번만 설정하면 설치할 수 있는 사이드 로드 앱을 다운로드하는 앱부터 차단할 수 있도록 설정을 강화했다.
• 구글 플레이 프로텍트: 구글 플레이에서 배포되는 앱에서도 보안 위협을 확인할 수 있도록 조치
• 프로젝트 Treble : 빠른 업그레이드를 위해, 파티션을 나누어 기존 운영체제와 별개로 새 운영체제를 설치한 뒤 이동

https://android-developers.googleblog.com/2017/05/here-comes-treble-modular-base-for.html

• HAL 제공: 커널 드라이버에 직접 접근하지 않고 하드웨어를 쓸 수 있도록 샌드박스화
• 안전하지 않은 SSL 버전에 대한 지원 중단, TLS 폴백도 보안 문제로 인해 삭제
• (운영체제가 아니라) 하드웨어의 변조를 방지하는 물리 모듈을 탑재한 장치 지원
• 블루투스 또는 NFC 를 이용한 물리적 보안 키 지원
• 강화된 안드로이드 Verified Boot 2.0 의 도입: 운영체제 변조 방지를 위해, 이전보다 취약한 운영체제로 다운그레이드할 경우 장치 부팅을 못하도록 설계

 

안드로이드 9.0 (파이): 앱에 대한 감시 + 보안 인증 강화

• 안드로이드 장치의 안전을 위해 보인 확인을 강화하는 2단계 인증이 도입
• 각 앱이 어떤 권한을 요청하는지 확인하고 허용 여부를 결정
• 나중에 권한을 조정할 수 있도록 관리 기능 강화
• 일부 앱이 백그라운드에서 실행되며 카메라와 마이크를 활성화하던 기능을 제외
• 생체 인식을 비활성화하는 대신 PIN, 패턴, 비밀번호만 잠금 작동하도록 새로운 잠금 모드 추가
• 기기를 초기화/복원할 때 안전하게 더 작업할 수 있도록 PIN 을 이용한 이중 인증 방식 적용

 

안드로이드 10: 안드로이드 보안 업데이트를 손쉽게 할 수 있는 장치 추가

(참고: 안드로이드 10부터 정책이 변경되어 디저트 이름을 붙이지 않고 숫자를 붙인다. (원래 코드명은 레드벨벳 케이크))

• 프로젝트 메인라인(Project Mainline) 도입: 구글 플레이에서 설치한 앱을 업데이트하는 것처럼, 업데이트해야 하는 보안 모듈만 운영체제 프레임워크에 탑재할 수 있게 되어 보안 업데이트마다 대규모 데이터를 다운로드해 업데이트하던 일이 사라졌다. -> 취약점 발견에 따른 보안 패치를 빠르게 적용 가능
• 애플리케이션 서명 체계 도입
• 아디안텀(Adiantum) 이라는 새로운 저장 장치 암호 체계 도입, 성능 저하를 줄였다.
• 각 앱은 관련되지 않은 디렉토리의 파일에 접근하는 것을 차단. 권한을 얻어야 한다.
• 위치 공유에 대한 이용자의 제어 권한 강화
• 하드웨어를 특정할 수 있는 IMEI 나 다른 일련번호를 알 수 없도록 제한

 

안드로이드 11: 로그인 관리 강화 + 디지털 신원 증명 + 앱의 권한 제어

• 2020년 9월 8일에 출시
• 블록 스토어: 앱에 로그인한 사용자의 인증 토큰을 장치에 저장하고 클라우드에 백업한 뒤 새 장치에 해당 앱을 설치하고 실행하면 암호를 재입력하지 않고 복원하는 기술. 장치/클라우드 모두 토큰을 암호화하여 저장.
• 원탭: 가입을 해야 하는 서비스가 원탭을 지원하고 구글 계정으로 연동되어 있으면 원탭 로그인 또는 계정 자동 완성을 표시해 계정 및 비밀번호 입력 없이 곧바로 로그인할 수 있는 기능
• 디지털 신원 증명에 대비하는, 암호화 방법 및 표준화 절차를 따르는 전자 ID 라이브러리 탑재
• 새로 설치되는 앱에 대한 권한 제어: 마이크/위치/카메라에 대해 영구적 권한을 부여하는 옵션을 제거. -> 실행 중에만 / 이번 실행에만 / 거부 의 3가지 선택 항목을 제공한다. -> 백그라운드에서 권한을 악용하지 못하도록

 

이 외로 안드로이드 12 는 2021년 10월 4일 (한국시간 10월 5일) 에 공개되었다.

* 이 내용은 https://developer.android.com/about/versions/12/summary 을 참고해서 작성했습니다.

 

안드로이드 12의 변경 또는 새로운 '보안 및 개인 정보 보호' 에서 주목할만한 점들을 작성해보면,

• 마이크 및 카메라 표시기: 앱에서 마이크/카메라에 액세스할 때마다 상태 표시줄 아이콘이 표시된다.
• BouncyCastle 구현 삭제: 이전에 지원 중단된 암호화 알고리즘의 여러 BouncyCastle 구현을 삭제
• 클립보드 액세스 알림: 앱이 다른 앱의 클립보드 데이터에 액세스할 때 사용자에게 알림이 전송
• 앱이 시스템 대화상자를 닫을 수 없음 (앱이 시스템 대화상자를 닫는 인텐트를 더 이상 호출할 수 없다)
• 대략적인 위치: 앱에서 정확한 위치 정보 액세스 권한을 요청하면 이제 사용자가 대신 대략적인 위치 정보 액세스 권한만 부여하도록 선택할 수 있다.
• 안전하지 않은 인텐트 실행: 안전하지 않은 인텐트 실행을 감지하는 디버깅 기능을 도입
• 개인 정보 대시보드: 위치, 카메라, 마이크 데이터 액세스 기록을 보여주는 새 시스템 설정 화면 도입
• 블루투스 권한: 앱에서 위치 정보 액세스 권한을 요청하지 않고도 근처 블루투스 기기를 검색할 수 있는 새 권한을 도입
• 메시지 앱의 피싱 감지(Pixel만 해당): 지원되는 Pixel 기기에서, 인기 있는 메시지 앱에서 수신된 메시지에 피싱 감지를 실행

 

 

 

 

안드로이드 개발을 할 때 권한을 요청하는 작업을 수행했었지만,

안드로이드 개발자이면서 동시에 안드로이드 사용자로서 앱이 사용자에게 권한을 요청하는 일은 필수적이면서 당연하다고 생각했다.

물론 개발할 때는 번거롭긴 했지만 내가 사용자라는 생각을 하면 너무나 필요한 기능이었다.

(실제로 나는 웬만해서는 권한을 최소한으로 제공한다.)

그런데 이 기능이 생각보다 최근에 제공된 것을 알고 다소 충격을 받았다.

 

그 외로도 안드로이드 1부터 어떤 주요한 보안 사항이 있었는지 차례로 살펴보는 과정을 통해 어떤 부분이 문제였고, 어떻게 개선했는지 전체적인 시각으로 살펴볼 수 있었다.

그리고 개발자로서 보안에 대한 경각심을 더욱 가질 수 있었다.

안드로이드 개발자 또는 보안 관련자라면 깊게는 아니더라고 이렇게 쭉 살펴보는 것이 중요하다고 생각했다.

 

또한, 어떤 시스템이라도 처음부터 완벽한 것은 없고, 결국 계속해서 개선해나가는 것이 중요함을 알게 되었다.

 

 

나는 개발할 때 처음부터 완벽한 서비스 구조를 잡으려 해서 자주 머리를 싸맸다.

이는 사실상 앞으로 일어날 일을 예측하는 것이나 다름없고, 어느 정도 바뀔 여지가 있는 프로젝트를 하다 보니 언제나 수정 사항이 발생할 수 있다.

물론 처음에 구조를 잘 잡고 개발을 시작하는 것은 무척이나 중요하다!

하지만, 나처럼 자주 어떤 새로운 기술을 가지고 프로젝트에 뛰어든다면 모든 부분을 알고 구조를 짜기란 어려워서, 처음에 공부하느라 시간을 많이 쓰고 스트레스틀 받는다.

 

그래서 최근에는 조금은 완벽한 구조에 대한 짐을 내려놓고, 일단 구현해보면서 기술을 더 이해하고 구조를 잡아가는 방식으로 나의 개발 패턴을 변경하였다. (그렇다고 전체 아키텍처를 안짠다는 것은 아니다)

아직까지도 구조를 전체적으로 짜야 한다는 '빅피쳐' 에 대한 욕구가 있기는 하지만,

어쩄든 나를 위한 길이라고 생각하며 기술을 실제로 사용하는 것을 조금 더 앞당겼다.

 

안드로이드 보안 동향을 살펴보면서 이런 생각에 이르는 것이 조금 민망?하지만,

어쨌든 어떤 시스템이든 계속해서 개선해나가는 것이 매우 중요함을 깨달았다.

그 유명하고 점유율이 높은 안드로이드도 처음에는 종잇장 (까진 아닌가) 으로 시작해서 지금은 보안적인 측면이 많이 강화되지 않았나.

 

또, 최근에 들은 멘토링에서 자신이 개발한 결과물을 프로젝트가 끝났다고 던져버리는 것이 아니라, 다시 열어보고 작동시켜 보면서 수정 및 보수를 해보는 것이 중요하고 좋은 경험이 된다고 하셨는데, 나도 해놓은 것들을 다시 돌아보는 시간을 좀 가져야겠다는 생각이 들었다.

 

그리고 안드로이드 12 의 많은 보안적 변경 및 추가 사항을 더 면밀하게 살펴보고 왜 이런 기능을 도입했는지, 아쉬운 점 (이런 기능도 있으면 어떨까?) 이 있는지 추가적으로 분석해봐야겠다.

 

[사설]인 만큼 개인적인 의견을 많이 담아서 마무리한다.