평범한 앱이 어떻게 루트 권한까지 올라가나요
안드로이드 폰에 앱 하나를 설치했는데, 그 앱이 아무 권한도 요청하지 않고 조용히 시스템 전체를 장악한다면 어떨까요? 보안 연구 회사 Calif가 공개한 'OEMpocalypse'라는 연구가 딱 그 이야기예요. 특별한 권한이 전혀 없는(unprivileged) 일반 앱이 삼성, 샤오미를 비롯한 여러 제조사의 기기에서 루트 권한을 얻어낼 수 있다는 내용이거든요. 이름부터 'OEM'과 'apocalypse(종말)'를 합친 건데, 제조사(OEM)가 직접 손댄 부분이 문제의 근원이라는 걸 강조한 작명이에요.
먼저 '루팅'이 뭔지 짚고 갈게요. 안드로이드는 리눅스 위에서 돌아가는데, 리눅스에서 root는 뭐든 할 수 있는 최고 관리자 계정이에요. 평소 우리가 쓰는 앱은 각자 격리된 방(샌드박스) 안에서만 움직여요. 카카오톡이 은행 앱의 데이터를 못 보는 것도, 앱이 시스템 파일을 마음대로 못 고치는 것도 이 격리 덕분이고요. 그런데 루트 권한을 얻으면 이 벽이 전부 사라져요. 다른 앱의 저장 데이터를 읽고, 카메라나 마이크를 몰래 켜고, 지워지지 않는 악성코드를 시스템 영역에 심는 것까지 가능해지는 거죠.
왜 하필 '제조사 커스터마이징'이 구멍이 될까요
여기서 핵심은 취약점이 구글이 만든 순정 안드로이드(AOSP)가 아니라, 제조사가 그 위에 얹은 코드에 있다는 점이에요. 이게 뭐냐면, 삼성의 One UI나 샤오미의 HyperOS 같은 건 순정 안드로이드에 제조사가 자기네 기능을 잔뜩 추가한 버전이거든요. 자체 시스템 서비스, 전용 커널 드라이버, 지울 수 없는 기본 앱 같은 것들이요. 이런 코드는 구글의 보안 검토를 거치지 않고, 제조사가 각자 알아서 관리해요.
문제는 이런 제조사 전용 컴포넌트 중 상당수가 시스템 수준의 높은 권한으로 돌아간다는 거예요. 그런데 이 컴포넌트가 일반 앱이 보낼 수 있는 요청을 받아주는 창구를 열어놓고 있으면, 그 창구에 있는 버그 하나가 곧 '일반 앱에서 시스템 권한으로' 올라가는 사다리가 돼요. 권한 상승 공격의 전형적인 패턴이에요. 낮은 권한의 앱이 높은 권한의 프로세스에 잘못된 입력을 보내서, 그 프로세스가 대신 위험한 일을 하게 만드는 거죠. 그리고 그 사다리를 몇 개 이어 붙이면 결국 루트까지 도달하고요.
여러 제조사가 한꺼번에 영향을 받는다는 것도 눈여겨볼 대목이에요. 제조사들이 같은 칩셋 업체의 코드를 가져다 쓰거나, 비슷한 방식으로 시스템 서비스를 만들다 보니 같은 종류의 실수가 여러 브랜드에 반복되는 거거든요. 구체적인 취약점 체인과 어떤 모델이 어떤 경로로 뚫리는지는 원문 리서치를 직접 보시는 게 정확해요. 여기선 '일반 앱 하나로 루트'라는 결과가 왜 가능한지, 그 구조를 이해하는 데 집중할게요.
이 연구가 놓인 자리
안드로이드 보안 역사를 보면 큰 루팅 취약점은 주기적으로 나왔어요. 2016년 Dirty COW, 2022년 Dirty Pipe처럼 리눅스 커널 자체의 버그가 안드로이드까지 영향을 준 경우도 있었고, 퀄컴이나 미디어텍 같은 칩셋 드라이버의 버그도 단골손님이었죠. 구글의 Project Zero 팀은 몇 년 전부터 '안드로이드 취약점의 상당수는 AOSP가 아니라 벤더 코드에서 나온다'고 꾸준히 지적해왔고요.
구글도 손을 놓고 있었던 건 아니에요. 매달 보안 패치를 내고, Project Treble로 제조사 코드와 안드로이드 프레임워크를 분리해서 업데이트를 빠르게 하려 했고, Play Protect로 설치된 앱을 검사하죠. 그런데 이번 연구는 그 노력이 닿지 않는 사각지대를 정확히 찌른 셈이에요. 구글이 아무리 AOSP를 단단히 만들어도, 제조사가 얹은 코드에 구멍이 있으면 소용없다는 걸 다시 보여준 거예요. 애플처럼 하드웨어와 소프트웨어를 한 회사가 다 만드는 구조와 달리, 안드로이드는 '열린 생태계'의 대가를 보안 파편화로 치르고 있는 거죠.
한국 개발자라면 뭘 챙겨야 할까요
한국은 삼성 갤럭시 점유율이 압도적이라서 남 일이 아니에요. 앱 개발자 입장에서 생각해볼 게 몇 가지 있어요.
먼저 루팅 탐지의 한계를 인정해야 해요. 금융 앱들이 RootBeer 같은 라이브러리로 루팅 여부를 검사하는데, 이런 취약점으로 얻은 루트 권한은 su 바이너리나 Magisk 흔적을 남기지 않는 경우가 많아서 기존 탐지에 안 걸릴 수 있어요. 구글의 Play Integrity API로 기기 무결성을 서버에서 검증하는 쪽이 그나마 더 견고하고요. 결국 '클라이언트는 언제든 뚫릴 수 있다'는 전제로, 민감한 검증과 데이터는 서버에서 처리하는 원칙이 중요해요.
민감 데이터 저장 방식도 다시 볼 만해요. 루트 권한이면 앱의 private storage도 다 읽히니까, 토큰이나 키를 평문으로 두지 말고 Android Keystore의 하드웨어 보안 영역(TEE, StrongBox)을 활용하는 게 좋아요. 하드웨어 영역에 있는 키는 루트를 얻어도 꺼내기가 훨씬 어렵거든요.
회사에서 업무용 폰을 관리하는 분이라면, MDM 정책에서 보안 패치 레벨이 오래된 기기를 걸러내는 규칙을 다시 점검해보세요. 그리고 개인적으로는 뻔한 말이지만 보안 업데이트를 미루지 않는 게 제일 확실한 방어예요. 이런 연구는 보통 제조사에 먼저 알리고 패치가 나온 뒤에 공개되니까요.
정리하며
한 줄 요약: 안드로이드의 가장 약한 고리는 구글이 만든 부분이 아니라 제조사가 덧붙인 부분이고, 그 구멍 하나면 권한 없는 앱도 루트가 될 수 있어요.
여러분은 앱을 만들 때 '이 기기가 이미 뚫렸다'는 가정을 어디까지 하고 계신가요? 루팅 탐지에 얼마나 의존하고 있는지, 서버 검증으로 얼마나 옮겨왔는지 경험을 나눠주세요.
🔗 출처: Hacker News