PendingIntent 근원 혼동을 이용한 Android SDK 인증 우회

초록

본 논문은 파트너 SDK에서 PendingIntent.getCreatorPackage()를 이용해 호출 앱을 인증하는 방식이 ‘근원 혼동(provenance confusion)’ 취약점을 내포하고 있음을 밝힌다. 악성 앱이 NotificationListenerService를 통해 정당 파트너 앱의 PendingIntent를 탈취하고 재사용하면, SDK 제공 서비스는 여전히 생성자를 정당 파트너로 인식해 인증을 통과한다. 변형 가능/불변 플래그와 무관하게 공격이 성공하며, 저자는 8가지 IPC 인증 메커니즘을 평가하고 Binder UID 검증과 서버‑사이드 인증서 해시 검증을 결합한 3계층 방어 구조를 제안한다.

상세 분석

논문은 Android 크로스‑앱 SDK 환경에서 발생하는 인증 문제를 근본적으로 재조명한다. 파트너 SDK가 제공하는 서비스는 호출 앱을 식별하기 위해 PendingIntent 객체의 creatorPackage 속성을 조회한다. 이 설계는 “누가 토큰을 만들었는가”와 “누가 토큰을 제시하는가”를 동일시하는 논리적 오류, 즉 ‘근원 혼동(provenance confusion)’을 내포한다. PendingIntent은 생성 시점에 creatorPackage를 고정하지만, 시스템은 토큰을 실제로 전달한 프로세스의 UID를 검증하지 않는다. 따라서 악성 앱이 NotificationListenerService(NLS)를 통해 다른 앱이 생성한 PendingIntent를 획득하면, 해당 토큰을 그대로 SDK 제공 서비스에 전달해 정당 파트너로 가장할 수 있다.

핵심은 Android 12부터 도입된 FLAG_IMMUTABLE/FLAG_MUTABLE 플래그가 토큰 내용의 변조를 방지할 뿐, 토큰을 보유·제시할 수 있는 주체를 제한하지 않는다는 점이다. 즉, 불변 토큰이라 하더라도 ‘누가 제시했는가’를 확인할 메커니즘이 없으므로 인증 우회가 가능하다. 논문은 이 공격이 실제 기기와 Android 14 환경에서 100 % 성공률을 보였으며, 기존 권한 기반 BroadcastReceiver, ContentProvider, getReferrer() 등 8가지 인증 방식과 비교 분석한다. 대부분의 기존 방식은 동일한 근원 혼동 문제를 공유하거나, Binder UID 검증이 누락된 경우가 많다.

방어 측면에서는 Binder.getCallingUid()를 이용해 커널 수준에서 호출자의 UID를 직접 확인하고, 서비스와 서버 간에 파트너 앱의 서명 인증서 해시를 교환·검증하는 3계층 구조를 제시한다. Bound Service를 사용해 IPC 경로를 제한하고, 서버‑사이드에서 인증서 해시와 매칭함으로써 토큰 탈취가 있더라도 UID 불일치 혹은 인증서 불일치로 인증이 차단된다. 이 설계는 SDK 업데이트 없이 서버 측 파트너 리스트만 관리하면 되므로, 대규모 파트너 에코시스템에 적용하기 용이하다.

결론적으로, PendingIntent 기반 인증은 근원 혼동이라는 근본적인 설계 결함을 가지고 있으며, 이를 보완하기 위해서는 커널‑레벨 UID 검증과 서버‑사이드 인증서 기반 검증을 결합한 다중 방어선이 필요함을 입증한다.