안녕하세요. 분석팀의 Jiyong입니다.

어느덧 한 해를 마무리하는 12월의 문턱입니다. 부쩍 추워진 날씨에 다들 건강 잘 챙기고 계신가요?

보통 이맘때가 되면 연말 선물이나 신학기 준비로 새 스마트폰을 구매하시는 분들이 많으실 텐데요. 저는 새 스마트폰을 구매하게 되면 켜자마자 불필요한 기본 탑재 앱들을 정리하곤 합니다.

저는 보안 분석가로서 평소 삭제 불가능한 선탑재 앱들이 과도한 권한을 갖는 것에 우려를 가지고 있었습니다. 그러던 차에 최근 특정 보급형 기기에서 이슈가 되고 있는 흥미롭고도 찝찝한 사례를 하나 접하게 되었습니다.

논란의 블로트웨어, AppCloud

바로 서아시아 및 북아프리카(WANA) 지역에 출시되는 삼성 갤럭시 보급형 기기에 선탑재된 AppCloud라는 앱에 대한 논란이었습니다.

이 앱의 역할은 기기 초기 설정 시 사용자에게 추천 앱이나 인기 게임을 제안하고 설치를 돕는 ‘앱 관리 도구’입니다. 쉽게 말해, 새 폰을 켰을 때 화면에 뜨는 ‘이 앱도 설치해 보세요.’ 같은 광고성 추천 기능을 가진 앱이죠.

[그림 1] AppCloud 실행 화면

하지만 최근 레딧(reddit)과 해외 보안 매체 SMEX 등에서는 이 앱의 정체를 두고 뜨거운 논쟁이 벌어졌습니다. 겉보기에는 삼성전자의 시스템 유틸리티 같지만, 실상은 이스라엘 광고 기술 기업 IronSource 사의 Aura 솔루션이라는 사실이 밝혀졌기 때문입니다.

단순히 외주 솔루션을 사용한 것이 문제가 아닙니다. 진짜 논란의 핵심은 이 앱이 삭제 불가능한 시스템 앱이라는 지위를 악용해 사용자 기기에서 과도한 정보를 수집하고, 사용자의 명시적 동의 없이 제휴 앱을 강제로 설치할 수 있는 기능까지 탑재하고 있다는 점입니다. 보안 업계에서는 이를 두고 블로트웨어를 넘어 사실상의 스파이웨어가 아니냐는 비판까지 제기하고 있는 상황입니다. 만약 이 주장이 사실이라면, 사용자의 신뢰를 기반으로 하는 대기업의 기본 앱 치고는 보안 위협이 지나치게 큽니다.

이러한 상황을 인지하고나서 저는 악성코드 분석가로서 단순한 ‘카더라’ 통신만 믿고 넘길 수는 없었습니다. 백문이 불여일견, 직접 애플리케이션을 구해 제 분석 환경에서 빠르게 팩트 체크를 해보기로 했습니다.

설치는 됐는데, 아이콘이 없다?

본격적인 분석을 위해 삼성 갤럭시 S22(Android 15) 환경을 구축하고, 선탑재앱인 AppCloud의 특성을 고려하여 실제 환경과 동일하게 작동하도록 시스템 파티션에 설치를 진행했습니다. 성공 메시지와 함께 설치는 정상적으로 완료되었지만 실행할 방법이 없었습니다.

[그림 2] 설치 후 배경화면

설정의 앱 목록에는 분명히 존재하는데 앱 서랍 어디를 찾아봐도 아이콘이 보이지 않았습니다. 런처를 통해 강제 실행을 시도해 봐도 화면이 순간적으로 반짝이고 종료되더군요.

단순한 기기 호환성 문제일까요? 아니면 의도적으로 숨은 것일까요. 이 유령 같은 앱의 속내가 궁금해진 저는 디컴파일러를 켜고 코드를 뜯어보기 시작했습니다.

그리고 그 안에서 화면에 아이콘이 없었던 이유와 그들이 노리는 것은 무엇인지를 코드로 확인할 수 있었습니다. 이번 포스팅에서는 제가 분석한 AppCloud의 내부 로직과 이것이 왜 공급망 공격의 위험한 통로가 될 수 있는지 공유해 드리고자 합니다.

왜 아이콘이 안 보였을까?

설치는 정상적으로 되었는데 실행 아이콘이 없는 기이한 현상, 이것이 단순 기기 호환성 문제였는가의 해답은 정적 분석 과정에서 드러났습니다.

앱의 초기화 로직을 담장하는 c클래스와 MainApplication 클래스를 분석하던 중 아이콘이 사라진 이유를 설명해주는 로직을 발견했습니다. 결론부터 말하자면, 이 앱은 특정 조건이 만족되지 않으면 스스로 아이콘을 지우고 숨도록 설계되어 있었습니다.

코드를 역추적한 결과, 앱은 실행 직후 아래와 같은 3가지 조건을 검사합니다.

1. 아이콘 활성화 여부(h): 실행 아이콘이 켜져있는가?
2. 초기 설정 완료 여부(b.f): 사용자가 폰을 사고 초기 세팅을 끝냈는가?
3. 데이터 수신 여부(SharedPreferences): 보여줄 광고 목록이 준비되었는가?

[그림 3] 강제 종료 메서드 조건문

[그림 4] 아이콘 비활성화 로직

저의 분석 환경에 대입해 보면 갤럭시 S22은 초기 세팅이 끝난 상태였고 앱 설치 직후라 아이콘도 기본적으로 활성화된 상태였습니다. 하지만 WANA 지역의 사용자 환경이 아니었기 때문에 IronSource 서버와 정상적인 통신이 이루어지지 않았거나, 타겟팅 대상이 아니었기 때문에 보여줄 광고 데이터를 수신하지 못한 상태였습니다.

결국 이 앱은 사용자에게 보여줄 광고 데이터가 없다고 판단을 내리고 스스로 아이콘을 지우고 숨어버린 것이었습니다. 앱을 볼 수 없었던 이유는 서버의 명령 없이는 모습을 드러내지 않는 앱의 로직이 작동했다는 증거였습니다.

과도한 정보 수집

아이콘이 사라진 의문은 풀렸습니다. 그렇다면 이 앱은 백그라운드에서 과연 무엇을 하고 있었을까요? 정적 분석을 통해 이 앱의 목적을 파헤쳐 보았습니다.

이 앱은 단순한 로그 수집을 넘어서서 사용자에게 광고를 보여주기 위한 사전 작업을 하고 있었습니다.

먼저, Tracker 클래스 분석한 결과 데이터 전송을 담당하는 것을 알 수 있었습니다. 이 앱은 삼성의 서버가 아닌 Ironsource 사의 Auralytics SDK를 사용하여 수집된 데이터를 제 3의 광고 기업에게 전달합니다.

또한 앱 초기화 시 모델명, Android ID 등 일반적인 광고 SDK가 수집하는 기기 식별 정보를 수집합니다. 여기까지는 다른 앱들에서도 흔히 볼 수 있는 수준이라 할 수 있습니다. 여기까지는 다른 앱들에서도 흔히 볼 수 있는 수준이라 할 수 있습니다.

하지만 진짜 문제는 따로 있었습니다. 이 앱은 안드로이드의 QUERY_ALL_PACKAGES 권한을 이용해 사용자 기기에 설치된 모든 앱 목록을 파악하고 있었습니다.

[그림 5] 전체 패키지 목록 스캔

설치된 앱 목록은 단순한 데이터가 아닌 민감한 프로파일링 자료입니다. 구글조차 일반적인 앱들이 이 권한을 남용하지 못하도록 엄격하게 정책을 관리하고 있습니다.

그런데 AppCloud는 사용자가 설치하거나 실행하지도 않고, 심지어는 삭제할 수도 없는 시스템 앱이라는 특권을 이용하여 사용자 동의 절차 없이 백그라운드에서 이 민감한 정보를 수집하고 있었습니다. 이는 단순한 광고 활동을 넘어선 명백한 프라이버시 침해입니다.

시스템 권한을 이용한 강제 설치

기기 정보 수집이 정찰이라면, 이제는 본격적인 작전 수행을 살펴볼 차례입니다. “사용자 동의 없이 앱이 깔린다.”라는 해외 기사의 주장은 과연 사실일까요?

저는 DeliveryDownloader → AndroidDownloadsManager → AndroidInstallerIntegration 로 이어지는 호출 흐름을 역추적했고, 그 결과 사용자의 인지 없이 앱을 설치하는 기능이 코드 레벨에서 완벽하게 구현되어 있음을 확인했습니다.

먼저 DeliveryDownloader 클래스는 서버로부터 설치할 앱 목록을 가져옵니다. 이때 주목할 점은 데이터베이스에 정의된isSilent=true 플래그입니다. “조용히 처리하라”는 속성값이 기본적으로 존재한다는 뜻입니다.

이 명령을 받은 AndroidDownloadsManager는 안드로이드 시스템의 DownloadManager를 호출하는데 여기서 충격적인 옵션을 사용합니다.

[그림 6] 상단바 알림 숨김 처리

일반적인 앱 스토어라면 다운로드 시 상단바에 진행률(%)이 떠야 합니다. 하지만 이 앱은 다운로드 메서드 인자에 VISIBILITY_HIDDEN 옵션을 꺼서 알림을 강제로 숨길 수 있는 기능이 있었습니다. 즉, 사용자가 내 폰이 지금 무언가를 다운로드하고 있다는 사실조차 알기 어렵게 만들 수 있는 것입니다.

다운로드가 완료되면 AndroidInstallerIntegration으로 넘어갑니다. 일반적인 앱은 설치 진행 시 사용자에게 동의를 구하기 위해 “이 앱을 설치하시겠습니까?”라는 팝업(Intent)을 띄워야 합니다. 하지만 시스템 권한을 가진 이 앱은 다른 앱들과 다르게 사용자 동의 없이 설치를 진행할 수 있습니다.

[그림 7] 백그라운드 설치

[그림 7]의 코드가 실행되는 순간, 다운로드된 APK는 사용자의 개입 없이 즉시 설치됩니다. 백그라운드에서 다운로드부터 설치까지 일괄 처리되는 것입니다.

이러한 구조에서 가장 심각한 문제는 AndroidInstallerIntegration 클래스 내부에서 다운로드된 APK가 위변조되지 않았는지 확인하는 로직(서명 검증, 무결성 체크)의 부재입니다. 이는 AppCloud 앱이 서버가 주는 파일이라면, 그게 무엇이든 의심 없이 시스템 권한으로 설치한다는 것을 의미합니다.

IronSource 서버가 공격자의 손에 넘어간다면?

앞선 분석을 통해 AppCloud가 사용자 몰래 앱을 설치할 수 있는 능력을 가졌다는 사실은 확인되었습니다. 그렇다면 남은 질문은 하나입니다.

추가 분석을 통해 DeliveryConfiguration 인터페이스에서 서명 값을 조회하는 코드를 발견했습니다. 이는 개발사가 최소한의 검증 메커니즘을 고려했다는 흔적으로 보이나, 이를 다운로드된 파일과 대조하여 설치를 차단하는 과정이 Installer 단계에서 명확히 확인되지 않았습니다.

설령 검증한다 해도 검증의 기준이 되는 ‘서명 값’ 자체가 외부 서버에서 내려오기 때문에 공격자가 서버를 장악해 악성 파일과 악성 파일의 서명을 세트로 내려보낸다면 이 앱은 공급망 공격의 완벽한 숙주가 될 수 있습니다.

그렇다면 공급망 공격(Supply Chain Attack)이란 무엇이고, 만약 AppCloud를 지휘하는 서버인 IronSource의 중앙 서버가 공격자에게 해킹당한다면 어떤 일이 벌어질까요?

먼저 공급망 공격이란, 보안이 철저한 사용자 기기를 공격하는 대신 사용자가 이미 신뢰하고 사용 중인 소프트웨어 개발사나 업데이트 서버를 해킹하여 악성코드를 침투시키는 해킹 기법입니다.

[그림 8] 공급망 공격 가상 시나리오

이제 해커가 IronSource의 서버의 제어권을 탈취했다고 가정해봅시다. 해커는 특정 게임을 설치하라는 명령 속의 다운로드 URL을 RAT.apk 등의 악성 APK가 담긴 주소로 바꿔치기 합니다.

WANA 지역에 있는 AppCloud가 설치된 모든 기기가 이 명령을 수신합니다. 앞서 확인했듯이 무결성 검증 로직이 부실하므로, AppCloud는 이것이 게임인지 악성코드인지 의심하지 않고 서버가 시키는 대로 파일을 내려받습니다.

다음으로 사용자 모르게 백그라운드에서 악성코드가 다운로드되고 시스템 권한으로 설치됩니다. 사용자는 수상한 문자를 클릭하거나 파일을 다운로드 받은 적도 없습니다. 하지만 스마트폰은 이미 해커의 손에 넘어가 있거나 악성코드에 감염된 상황일 것입니다.

이것은 단순한 기우가 아닙니다. 2020년 수많은 기업과 정부 기관을 대상으로 발생했던 솔라윈즈(SolarWinds) 사태가 정확히 이런 방식으로 발생했습니다. 삼성전자는 제 3자(IronSource)에게 사용자 기기의 대문을 열어주는 마스터키를 쥐여준 셈입니다. 이런 외부 코드가 내부 시스템을 통제할 수 있는 길을 열어둔 것은 보안 설계의 치명적인 구조적 결함입니다.

마치며

이번 분석에서 환경적 제약으로 인해 실제 서버와의 통신 패킷을 캡처하지 못한 점이 아쉬움으로 남습니다. 하지만 정적 분석만으로도 이 앱이 가진 기능과 위험성을 규명하는 데는 부족함이 없었습니다.

분석 결과를 요약하자면, AppCloud는 과도한 권한을 가지며 언제든 백도어(Backdoor)로 악용될 수 있는 광고 플랫폼입니다.

물론 제조사 입장에서 수익 창출과 단말기 가격 경쟁력 확보는 중요한 비즈니스 가치일 것입니다. 하지만 그 수단이 삭제 불가, 과도한 정보 수집, 그리고 검증 없는 강제 설치라면 이야기가 다릅니다. 이는 편의를 명분으로 사용자들의 보안을 담보로하는 위태로운 구조이자, 해커들에게 성문을 열어주는 레드 카펫이 될 수 있기 때문입니다.

이제는 바뀌어야 합니다. 사용자의 스마트폰의 통제권이 제조사나 광고 업체가 아닌 사용자 본인에게 있기를 바라며 이번 포스팅을 마칩니다.

긴 글 읽어주셔서 감사합니다.