안드로이드 앱은 개발자가 생성한 인증서 기반 서명에 따라 배포
안랩, 공식 앱 서명 인증서 유출 관련 공격유형과 사례분석 및 대응방안 소개
[보안뉴스 김영명 기자] 코드 서명 인증서 유출로 인한 악성코드 유포 행위가 꾸준히 확산되고 있다. 마이크로소프트는 지난해 말과 올해 초에 ‘악의적으로 사용되는 Microsoft 서명된 드라이버에 대한 지침’을 발표했다. 또한, 해킹 단체 랩서스(Lapsus$)가 엔비디아 코드 서명 인증서를 탈취해 해당 인증서로 서명된 멀웨어도 발견되기도 했다.
안드로이드 애플리케이션(이하 ‘앱’)은 개발자가 자가 생성한 인증서를 기반으로 서명 및 배포된다. 이는 구글 플레이스토어(Google Play Store) 등 마켓에 업로드할 때 개발자와 사용자를 구분하는 용도로 사용되며, 개발자가 자신이 개발한 앱임을 증명하는 중요한 수단이다. 또한, 앱 업데이트도 해당 서명을 확인해 일치할 경우에만 가능해 앱 자체를 보호하는 역할도 한다.
이러한 가운데 안랩은 공식 앱 서명 인증서와 관련해 ‘유출 인증서 취득 후 공격자 행위 유형’과 함께 ‘유출된 인증서 활용 악성 행위 감행 사례’를 정리하고, 악성 행위에 대한 안랩의 대응정책을 소개했다.
앱 서명 인증서 정책은 개인 개발자가 자유롭게 앱을 만들어 업로드할 수 있도록 하기 위해 만들어졌다. 따라서, 별도의 인증기관을 두지 않고 개발자가 자체적으로 인증서를 관리하도록 했다. 앱 개발과 배포의 진입장벽을 낮추고 사용자들이 더 폭넓게 앱을 경험할 수 있다는 장점이 있지만, 반대로 해당 요소들이 복합적으로 작용해 서명 인증서 유출 등의 문제도 발생한다.
먼저, 공격자가 유출된 서명 인증서를 활용해 수행한 악성 행위 유형은 크게 ‘인증서로 악성코드 탐지 회피’와 ‘인증서의 공식 서비스 앱 데이터 공유’ 등 두 가지로 구분된다. ‘인증서로 악성코드 탐지 회피’에서는 공식 서비스를 수행하는 앱에 서명된 인증서로 악성코드를 서명하는 것이다. 이를 통해 보안 솔루션의 검사에서 악성으로 탐지되는 것을 회피한다.
두 번째로, ‘인증서의 공식 서비스 앱 데이터 공유’를 보면 안드로이드 시스템에서 ‘콘텐트 프로바이더(Content Provider)’는 앱 간 데이터를 공유하도록 한다. 공식 앱이 콘텐트 프로바이더 설정을 ‘서명 공유’로 지정한 경우, 해당 인증서로 서명된 모든 앱이 콘텐츠 프로바이더에 접근할 수 있다. 즉, 악성 앱으로 내부 사용자 데이터를 취득하며, 실질적으로 공식 앱 공격 기법으로 활용된다.
아직은 공식 서비스 앱을 공격하는 악성 앱은 확인되지 않았으며, 화이트리스트(Whitelist) 기반 보안 솔루션의 탐지를 회피해 악성 행위를 발현시킬 목적의 샘플만 발견됐다. 유출된 인증서를 획득해 공격자가 악성행위를 감행한 국내 사례는 ‘악성 기능이 추가된 앱을 플레이스토어에 업로드’, ‘N사 인증서 유출’, ‘스마트폰 제조사 펌웨어(Firmware)용 인증서 유출’, ‘공격자의 고의적인 화이트 인증서 생성 시도’ 등 네 가지가 있다.
먼저, ‘악성 기능이 추가된 앱을 플레이스토어에 업로드’ 사례는 2019년 ‘광주버스’라는 앱이 플레이스토어에 업데이트됐는데, 해당 앱에 악성 기능이 포함돼 있어 문제가 발생했다. ‘광주버스’ 앱은 버스 노선도, 도착 예정 시각 등을 알려준다. 해당 앱은 2012년에 서비스를 시작했으며, 2018년 개발자가 개발 및 업데이트를 중단했지만, 인증서 정보는 폐기하지 않았다. 그 이후 공격자는 인증서와 코드, 그리고 플레이스토어에 업로드한 개발자의 아이디 및 패스워드를 취득했고, 이를 활용해 해당 앱에 악성코드를 추가해 플레이스토어에 재업로드했다.
또한, 해당 악성코드가 포함된 앱이 정상적으로 업데이트돼 개인 사용자의 구글 아이디와 비밀번호를 탈취했다. 공격자는 ‘광주버스’ 앱 개발자가 개발했던 다른 앱도 비슷한 유형의 악성코드를 추가해 업로드했다. 해당 악성코드는 ‘libAudio.3.0.so native’ 라이브러리 파일을 추가, ‘libMovie.so’라는 추가 라이브러리 파일을 내려받아 구글 아이디 등 개인정보를 탈취했다.
두 번째로, ‘N사 인증서 유출’이 있다. 지난해 8월, N사 인증서로 서명된 금융 앱이 수집되면서 확인된 유형이다. 구체적으로는 N사에서 개발된 앱을 대상으로 한 공격이 아닌, 보안 솔루션에서 악성코드로의 탐지를 회피하려는 수단으로 N사 인증서를 사용한 것으로 확인됐다. 일부 안드로이드의 화이트리스트 기반 보안 솔루션은 비교적 검증이 간단한 서명 정보를 추출해 공식 마켓에 등록돼 있는 서명 정보인 경우 정상적인 앱으로 처리할 수 있다. 이때, 해당 앱의 악성 행위는 검사하지 않고, ‘화이트(White)’로 처리하는 현상이 발생할 수 있다.
해당 악성코드는 기존 금융 관련 보이스피싱 앱, 일명 ‘kaishi’ 악성코드다. 수신번호 조작 및 발신 번호 조작 기능을 수행하며, ‘다운로더(Downloader)’ 악성코드이기도 하다.
세 번째로, ‘스마트폰 제조사 펌웨어(Firmware)용 인증서 유출’ 사례가 있었다. 지난해 11월 12일, 구글은 Google APVI Report를 통해 플랫폼 인증서가 유출된 정황이 확인됐다고 밝혔다. 참고로, APVI(Android Partner Vulnerability Initiative, 안드로이드 파트너 취약점 이니셔티브)’는 구글 파트너사 장비의 취약점까지 발견하고 대응하겠다는 취지에서 시작됐다.
플랫폼 인증서(Platform Certificate)란 시스템 이미지에서 안드로이드 앱에 서명하는데 사용하는 앱 서명 인증서다. 해당 인증서로 서명된 앱은 ‘sharedUserId’를 ‘android.uid.system’으로 지정해 시스템 권한을 획득할 수 있다. 즉, 제조사 인증서로 서명된 악성 앱이 해당 제조사의 스마트폰에 설치될 경우, 시스템 권한과 함께 ‘사용자 데이터’(user data) 영역에 접근하는 권한이 부여된다. 이는 실제 OS와 같은 접근 권한으로 동작할 수 있게 되는 것이다.
발견된 악성앱은 구글 펌웨어 인증서로 서명됐으며, 해당 제조사 스마트폰에서만 악성 행위를 수행한다는 점이 기존과는 다른 특징이다. 악성 앱을 실행하면, 시스템 권한을 획득해 사용자 개인정보, 통화 내용, 통화 시 자동 녹음 기능을 수행하고 녹음 기록 등을 공격자에게 전송한다.
네 번째로, ‘공격자의 고의적인 화이트 인증서 생성 시도’ 사례가 있었다. 해당 사례는 2021년 12월 7일, 구글 플레이스토어에 등록된 앱의 사례로 샘플 분석을 통해 발견됐다. 해당 앱은 비트코인 관련 앱으로 플레이스토어에 등록됐다. 해당 앱은 dex 파일이나 여타 실행 가능 코드 없이 단순 패키지 이름과 서명 정보만 있어 설치를 할 수 없는 파일로 확인됐다.
해당 앱은 구글의 심사를 통과해 정상으로 업로드됐고, 지난해 2월 16일까지 주기적으로 버전 코드만 변경해 업데이트됐다. 업데이트 시 사용한 서명 정보는 지난해 12월 5일부터 kaishi 악성코드를 서명할 때 사용됐다. 해당 앱을 플레이스토어에 업로드한 것은 화이트리스트 기반 보안 솔루션 회피를 위한 의도적인 시도로 보인다. 플레이스토어에서 주기적인 업데이트를 제공하고, 해당 인증서를 일정 기간 노출시켜 신뢰를 쌓은 후 악성코드 서명에 사용한 것으로 추정된다.
이와 관련 안랩은 허용 기반의 ‘화이트리스트(Whitelist)’와 차단 기반의 ‘블랙리스트(Blacklist)’를 함께 사용하고 있다고 밝혔다. 명백한 정상 앱은 화이트리스트로 관리하면서, 악성 샘플은 기능의 특징을 수집해 블랙리스트로 관리한다. 별도로 관리되는 블랙리스트로 화이트리스트 샘플에서 악성 행위가 탐지될 경우에는 분석가가 즉각 샘플의 악성 여부를 상세 분석해 적절한 조치를 취한다는 설명이다.
이를 기반으로 악성 기능을 담은 앱을 플레이스토어에 올리면, 해당 샘플은 기존 플레이스토어에서 화이트 샘플로 관리됐지만, libAudio.3.0.so 파일이 다운로더 악성코드로 탐지된 이후, 분석가는 해당 인증서가 유출된 것으로 판단하고 악성으로 분류했다.
N사 인증서 유출과 관련해서는 해당 샘플은 수집 즉시 전형적인 kaishi 악성코드로 확인돼 곧바로 N사에 해당 정보를 공유하고 악성 기능 샘플로 분류했다. 해당 서명 정보로 서명된 앱을 지속해서 수집하고 추가 분석 및 악성 분류를 수행 중이라는 게 안랩 측의 설명이다.
스마트폰 제조사 펌웨어(Firmware)용 인증서 유출과 관련해서는 이제는 스마트폰 단말 생산을 중단한 L사에서 해당 인증서로 서명된 앱이 아직까지 사용돼 ‘악성 기능이 포함된’ 앱만 악성으로 분류했다. 삼성, 레노보(Lenovo), 미디어텍(MediaTek) 등은 해당 인증서를 과거에 폐기해 최신 기기에 영향을 미치지 않는 것으로 확인됐으며, 해당 앱은 악성으로 분류했다.
안드로이드는 운영체제 및 마켓의 특성상 앱 개발과 업로드가 자유로워 인증 및 관리에 공신력 있는 기관의 개입이 없어 앱의 유지보수와 보안 관리는 전적으로 개발자에 책임이 있다.
이러한 앱 서명 인증서 유출로 인한 악성코드 확산에 대해서는 일부 개선책이 필요하다는 지적이다. 먼저 ‘인증서 관리 체계에 대한 인식 제고’ 측면에서 앱 개발자가 소유 및 관리하는 인증서는 별도의 인증기관이 없기 때문에 그만큼 개별적으로 관리에 주의를 기울여야 한다는 의미다. 따라서 앱 서명 인증서는 자체적으로 더 높은 수준으로 관리해야 하며, 이를 체계적으로 수행할 방안도 마련해야 한다.
또한, ‘보안 솔루션 개선 체계 마련’이 필요하다. 보안 솔루션이 개인과 기업 개발자의 인증서를 쉽게 신뢰하면 현존 위협의 대응에 한계가 있다. 이를 인지하고, 악성 샘플을 기능 기반으로 분류하는 기법을 복합적으로 활용해 악성 행위를 방지할 수 있도록 해야 한다고 안랩은 설명했다.
[김영명 기자(boan@boannews.com)]
안랩, 공식 앱 서명 인증서 유출 관련 공격유형과 사례분석 및 대응방안 소개
[보안뉴스 김영명 기자] 코드 서명 인증서 유출로 인한 악성코드 유포 행위가 꾸준히 확산되고 있다. 마이크로소프트는 지난해 말과 올해 초에 ‘악의적으로 사용되는 Microsoft 서명된 드라이버에 대한 지침’을 발표했다. 또한, 해킹 단체 랩서스(Lapsus$)가 엔비디아 코드 서명 인증서를 탈취해 해당 인증서로 서명된 멀웨어도 발견되기도 했다.
[이미지=utoimage]
안드로이드 애플리케이션(이하 ‘앱’)은 개발자가 자가 생성한 인증서를 기반으로 서명 및 배포된다. 이는 구글 플레이스토어(Google Play Store) 등 마켓에 업로드할 때 개발자와 사용자를 구분하는 용도로 사용되며, 개발자가 자신이 개발한 앱임을 증명하는 중요한 수단이다. 또한, 앱 업데이트도 해당 서명을 확인해 일치할 경우에만 가능해 앱 자체를 보호하는 역할도 한다.
이러한 가운데 안랩은 공식 앱 서명 인증서와 관련해 ‘유출 인증서 취득 후 공격자 행위 유형’과 함께 ‘유출된 인증서 활용 악성 행위 감행 사례’를 정리하고, 악성 행위에 대한 안랩의 대응정책을 소개했다.
앱 서명 인증서 정책은 개인 개발자가 자유롭게 앱을 만들어 업로드할 수 있도록 하기 위해 만들어졌다. 따라서, 별도의 인증기관을 두지 않고 개발자가 자체적으로 인증서를 관리하도록 했다. 앱 개발과 배포의 진입장벽을 낮추고 사용자들이 더 폭넓게 앱을 경험할 수 있다는 장점이 있지만, 반대로 해당 요소들이 복합적으로 작용해 서명 인증서 유출 등의 문제도 발생한다.
먼저, 공격자가 유출된 서명 인증서를 활용해 수행한 악성 행위 유형은 크게 ‘인증서로 악성코드 탐지 회피’와 ‘인증서의 공식 서비스 앱 데이터 공유’ 등 두 가지로 구분된다. ‘인증서로 악성코드 탐지 회피’에서는 공식 서비스를 수행하는 앱에 서명된 인증서로 악성코드를 서명하는 것이다. 이를 통해 보안 솔루션의 검사에서 악성으로 탐지되는 것을 회피한다.
두 번째로, ‘인증서의 공식 서비스 앱 데이터 공유’를 보면 안드로이드 시스템에서 ‘콘텐트 프로바이더(Content Provider)’는 앱 간 데이터를 공유하도록 한다. 공식 앱이 콘텐트 프로바이더 설정을 ‘서명 공유’로 지정한 경우, 해당 인증서로 서명된 모든 앱이 콘텐츠 프로바이더에 접근할 수 있다. 즉, 악성 앱으로 내부 사용자 데이터를 취득하며, 실질적으로 공식 앱 공격 기법으로 활용된다.
▲Content Provider 설정이 ‘서명 공유’로 지정된 경우[자료=안랩 ASEC 분석팀]
아직은 공식 서비스 앱을 공격하는 악성 앱은 확인되지 않았으며, 화이트리스트(Whitelist) 기반 보안 솔루션의 탐지를 회피해 악성 행위를 발현시킬 목적의 샘플만 발견됐다. 유출된 인증서를 획득해 공격자가 악성행위를 감행한 국내 사례는 ‘악성 기능이 추가된 앱을 플레이스토어에 업로드’, ‘N사 인증서 유출’, ‘스마트폰 제조사 펌웨어(Firmware)용 인증서 유출’, ‘공격자의 고의적인 화이트 인증서 생성 시도’ 등 네 가지가 있다.
먼저, ‘악성 기능이 추가된 앱을 플레이스토어에 업로드’ 사례는 2019년 ‘광주버스’라는 앱이 플레이스토어에 업데이트됐는데, 해당 앱에 악성 기능이 포함돼 있어 문제가 발생했다. ‘광주버스’ 앱은 버스 노선도, 도착 예정 시각 등을 알려준다. 해당 앱은 2012년에 서비스를 시작했으며, 2018년 개발자가 개발 및 업데이트를 중단했지만, 인증서 정보는 폐기하지 않았다. 그 이후 공격자는 인증서와 코드, 그리고 플레이스토어에 업로드한 개발자의 아이디 및 패스워드를 취득했고, 이를 활용해 해당 앱에 악성코드를 추가해 플레이스토어에 재업로드했다.
▲정상 샘플과 악성코드 추가 샘플 비교[자료=안랩 ASEC 분석팀]
또한, 해당 악성코드가 포함된 앱이 정상적으로 업데이트돼 개인 사용자의 구글 아이디와 비밀번호를 탈취했다. 공격자는 ‘광주버스’ 앱 개발자가 개발했던 다른 앱도 비슷한 유형의 악성코드를 추가해 업로드했다. 해당 악성코드는 ‘libAudio.3.0.so native’ 라이브러리 파일을 추가, ‘libMovie.so’라는 추가 라이브러리 파일을 내려받아 구글 아이디 등 개인정보를 탈취했다.
두 번째로, ‘N사 인증서 유출’이 있다. 지난해 8월, N사 인증서로 서명된 금융 앱이 수집되면서 확인된 유형이다. 구체적으로는 N사에서 개발된 앱을 대상으로 한 공격이 아닌, 보안 솔루션에서 악성코드로의 탐지를 회피하려는 수단으로 N사 인증서를 사용한 것으로 확인됐다. 일부 안드로이드의 화이트리스트 기반 보안 솔루션은 비교적 검증이 간단한 서명 정보를 추출해 공식 마켓에 등록돼 있는 서명 정보인 경우 정상적인 앱으로 처리할 수 있다. 이때, 해당 앱의 악성 행위는 검사하지 않고, ‘화이트(White)’로 처리하는 현상이 발생할 수 있다.
해당 악성코드는 기존 금융 관련 보이스피싱 앱, 일명 ‘kaishi’ 악성코드다. 수신번호 조작 및 발신 번호 조작 기능을 수행하며, ‘다운로더(Downloader)’ 악성코드이기도 하다.
[이미지=utoimage]
세 번째로, ‘스마트폰 제조사 펌웨어(Firmware)용 인증서 유출’ 사례가 있었다. 지난해 11월 12일, 구글은 Google APVI Report를 통해 플랫폼 인증서가 유출된 정황이 확인됐다고 밝혔다. 참고로, APVI(Android Partner Vulnerability Initiative, 안드로이드 파트너 취약점 이니셔티브)’는 구글 파트너사 장비의 취약점까지 발견하고 대응하겠다는 취지에서 시작됐다.
플랫폼 인증서(Platform Certificate)란 시스템 이미지에서 안드로이드 앱에 서명하는데 사용하는 앱 서명 인증서다. 해당 인증서로 서명된 앱은 ‘sharedUserId’를 ‘android.uid.system’으로 지정해 시스템 권한을 획득할 수 있다. 즉, 제조사 인증서로 서명된 악성 앱이 해당 제조사의 스마트폰에 설치될 경우, 시스템 권한과 함께 ‘사용자 데이터’(user data) 영역에 접근하는 권한이 부여된다. 이는 실제 OS와 같은 접근 권한으로 동작할 수 있게 되는 것이다.
발견된 악성앱은 구글 펌웨어 인증서로 서명됐으며, 해당 제조사 스마트폰에서만 악성 행위를 수행한다는 점이 기존과는 다른 특징이다. 악성 앱을 실행하면, 시스템 권한을 획득해 사용자 개인정보, 통화 내용, 통화 시 자동 녹음 기능을 수행하고 녹음 기록 등을 공격자에게 전송한다.
네 번째로, ‘공격자의 고의적인 화이트 인증서 생성 시도’ 사례가 있었다. 해당 사례는 2021년 12월 7일, 구글 플레이스토어에 등록된 앱의 사례로 샘플 분석을 통해 발견됐다. 해당 앱은 비트코인 관련 앱으로 플레이스토어에 등록됐다. 해당 앱은 dex 파일이나 여타 실행 가능 코드 없이 단순 패키지 이름과 서명 정보만 있어 설치를 할 수 없는 파일로 확인됐다.
해당 앱은 구글의 심사를 통과해 정상으로 업로드됐고, 지난해 2월 16일까지 주기적으로 버전 코드만 변경해 업데이트됐다. 업데이트 시 사용한 서명 정보는 지난해 12월 5일부터 kaishi 악성코드를 서명할 때 사용됐다. 해당 앱을 플레이스토어에 업로드한 것은 화이트리스트 기반 보안 솔루션 회피를 위한 의도적인 시도로 보인다. 플레이스토어에서 주기적인 업데이트를 제공하고, 해당 인증서를 일정 기간 노출시켜 신뢰를 쌓은 후 악성코드 서명에 사용한 것으로 추정된다.
▲애플리케이션 구조[자료=안랩 ASEC 분석팀]
이와 관련 안랩은 허용 기반의 ‘화이트리스트(Whitelist)’와 차단 기반의 ‘블랙리스트(Blacklist)’를 함께 사용하고 있다고 밝혔다. 명백한 정상 앱은 화이트리스트로 관리하면서, 악성 샘플은 기능의 특징을 수집해 블랙리스트로 관리한다. 별도로 관리되는 블랙리스트로 화이트리스트 샘플에서 악성 행위가 탐지될 경우에는 분석가가 즉각 샘플의 악성 여부를 상세 분석해 적절한 조치를 취한다는 설명이다.
이를 기반으로 악성 기능을 담은 앱을 플레이스토어에 올리면, 해당 샘플은 기존 플레이스토어에서 화이트 샘플로 관리됐지만, libAudio.3.0.so 파일이 다운로더 악성코드로 탐지된 이후, 분석가는 해당 인증서가 유출된 것으로 판단하고 악성으로 분류했다.
N사 인증서 유출과 관련해서는 해당 샘플은 수집 즉시 전형적인 kaishi 악성코드로 확인돼 곧바로 N사에 해당 정보를 공유하고 악성 기능 샘플로 분류했다. 해당 서명 정보로 서명된 앱을 지속해서 수집하고 추가 분석 및 악성 분류를 수행 중이라는 게 안랩 측의 설명이다.
스마트폰 제조사 펌웨어(Firmware)용 인증서 유출과 관련해서는 이제는 스마트폰 단말 생산을 중단한 L사에서 해당 인증서로 서명된 앱이 아직까지 사용돼 ‘악성 기능이 포함된’ 앱만 악성으로 분류했다. 삼성, 레노보(Lenovo), 미디어텍(MediaTek) 등은 해당 인증서를 과거에 폐기해 최신 기기에 영향을 미치지 않는 것으로 확인됐으며, 해당 앱은 악성으로 분류했다.
안드로이드는 운영체제 및 마켓의 특성상 앱 개발과 업로드가 자유로워 인증 및 관리에 공신력 있는 기관의 개입이 없어 앱의 유지보수와 보안 관리는 전적으로 개발자에 책임이 있다.
이러한 앱 서명 인증서 유출로 인한 악성코드 확산에 대해서는 일부 개선책이 필요하다는 지적이다. 먼저 ‘인증서 관리 체계에 대한 인식 제고’ 측면에서 앱 개발자가 소유 및 관리하는 인증서는 별도의 인증기관이 없기 때문에 그만큼 개별적으로 관리에 주의를 기울여야 한다는 의미다. 따라서 앱 서명 인증서는 자체적으로 더 높은 수준으로 관리해야 하며, 이를 체계적으로 수행할 방안도 마련해야 한다.
또한, ‘보안 솔루션 개선 체계 마련’이 필요하다. 보안 솔루션이 개인과 기업 개발자의 인증서를 쉽게 신뢰하면 현존 위협의 대응에 한계가 있다. 이를 인지하고, 악성 샘플을 기능 기반으로 분류하는 기법을 복합적으로 활용해 악성 행위를 방지할 수 있도록 해야 한다고 안랩은 설명했다.
[김영명 기자(boan@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
김영명기자 기사보기
[2024-04-18] 
.jpg)
.jpg)
.jpg)
