gnosis@kim:~#

gnosis@kim:~ # cat blog/android-intent-redirection-cve-2024.md

# Android Intent Redirection (with. CVE-2024-26131)

[Analysis]8 min read[ko]

#CVE#Android#App_Security

🧭 인트로

안드로이드 앱 해킹에서 Intent 시스템은 공격자 입장에서 가장 흔하게 노리는 표면입니다.
컴포넌트 간 메시지(인텐트)를 다루는 과정에서 개발자가 놓치기 쉬운 부분,
특히 Intent Redirection 취약점은 실제 앱에서 꾸준히 발견되고 있습니다.

이번 글에서는 아래와 같은 목차로 Intent Redirection 취약점에 대해 알아보겠습니다.

  • 인텐트 구조와 공격 표면
  • Intent Redirection 취약점의 원리
  • 해커/분석자 시점의 취약점 발굴법
  • 실제 발생한 CVE-2024-26131 사례 분석
  • 대응책 및 실전 체크리스트

출처: https://medium.com/@0x3adly/android-intent-redirection-a-hackers-gateway-to-internal-components-ebe126bbb2e0

출처: https://medium.com/@0x3adly/android-intent-redirection-a-hackers-gateway-to-internal-components-ebe126bbb2e0


1️⃣ 안드로이드 Intent: 구조와 공격 표면

📌 인텐트(Intent)란?

  • 안드로이드에서 Activity, Service, BroadcastReceiver 등 컴포넌트 간에 명령/데이터/이벤트를 주고받는 메시지 객체입니다.
  • 내부뿐 아니라 앱 간(외부) 통신도 가능해 외부 입력이 곧 공격 벡터가 됩니다.

📌 인텐트의 주요 속성

속성설명예시
Action수행할 동작 (ACTION_VIEW, ACTION_SEND 등)Intent("android.intent.action.VIEW")
DataURI, 파일 등 동작 대상 데이터Intent.setData(Uri.parse("http://example.com"))
Extra추가 정보(토큰, 경로 등)Intent.putExtra("token", "value")
Flags실행 방법(새 태스크 등)Intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK)
Component명시적 대상(클래스명)Intent.setComponent(new ComponentName(...))

📌 명시적 vs 암시적 인텐트

  • 명시적(Explicit): 대상 컴포넌트 명확 지정
  • 암시적(Implicit): Action, Data 등만 지정. Manifest의 인텐트 필터에 따라 실행 컴포넌트 결정

📌 공격 표면

  • 외부 호출 가능한 컴포넌트(exported=true)
  • 입력 검증 없이 내부 민감 컴포넌트에 인텐트를 전달하는 코드
  • 암시적 인텐트 처리 후 후속 동작에서 검증 누락

2️⃣ Intent Redirection 취약점이란?

📌 정의

Intent Redirection은
외부 입력(Intent)의 정보(component/action/data 등)을
검증 없이 민감한 내부 컴포넌트로 전달(redirect)함으로써
권한 상승, 인증 우회, 데이터 노출 등의 공격이 가능한 취약점입니다.

📌 발생 원리

  1. 외부에서 export된 컴포넌트에 인텐트 전송
  2. 앱이 입력 인텐트를 검증 없이 내부 컴포넌트로 전달
  3. 공격자가 인텐트 정보를 조작하면 민감 기능/권한이 우회 실행

📌 일반 공격 흐름 예시

[공격자] --(crafted intent)--> [취약 앱의 export된 컴포넌트]
                           \
                            --(검증 없이 redirect)--> [민감 Activity/Service]

📌 공격 예시

adb shell am start -n com.example.vuln/.ExportedActivity \
    -a android.intent.action.VIEW \
    --es component "com.example.vuln/.SensitiveActivity"
  • 결과: ExportedActivity가 인텐트의 component 파라미터를 검증 없이 내부 SensitiveActivity로 전달해 실행하면 취약점 존재

3️⃣ 실제 사례: CVE-2024-26131 (Element Android)

  • 악성 앱이 extra 파라미터로 내부 Activity를 지정해 전달
  • 검증 없이 실행 → 공격자는
    • 임의 웹 페이지 표시 및 악성 JavaScript 실행
    • PIN 보호 우회
    • 가짜 로그인 화면(피싱) 생성
    • 계정 탈취(임의 홈 서버로 인증 정보 전송)
      등의 공격을 실제로 할 수 있었음
    • 공식 상세 정보:
    • CWE 분류
      • CWE-923: Improper Restriction of Communication Channel to Intended Endpoints
      • CWE-940: Improper Verification of Source of a Communication Channel
  • 외부 앱이 crafted intent를 통해 내부 모든 Activity를 임의로 실행할 수 있었습니다.

4️⃣ 해커/분석자 시점: 취약점 찾는 방법

4-1. 정적 분석

📌 Manifest 분석

  • exported=true 컴포넌트(외부 호출 허용)
  • permission 미설정(권한 없는 액세스)
  • intent-filter 활용 액션/데이터 필터 유무

📌 코드 분석

  • startActivity, startService, sendBroadcast 등 입력 검증 없는 인텐트 전달 여부
  • setComponent, setClassName 등 인텐트 내부 조작
  • 인증/권한 검사 로직 부재

📌 체크리스트

점검 항목내용
[ ] exported/intent-filter 노출 컴포넌트외부 호출 가능 여부
[ ] startActivity/getIntent 등 검증 여부입력 검증/필터링 부재 여부
[ ] 민감 Activity/Service에 인텐트 전달 경로우회 실행 경로 존재 여부
[ ] 권한/인증 검사 적용 여부코드상 권한/인증 필수 여부

4-2. 동적 분석 및 PoC 실습

📌 PoC 실험 예시

adb shell am start -n com.example.vulnerable/.ExportedActivity \
    -a android.intent.action.VIEW \
    --es component "com.example.vulnerable/.SensitiveActivity"
  • ExportedActivity가 별도 인증/검증 없이 인텐트의 component를 읽어 내부 SensitiveActivity를 실행하면 취약점이 실제로 존재

📌 분석 포인트

  • 민감 Activity/Service가 외부 인텐트로 실행되는지 확인
  • 인증/권한 체크 없이 동작하는지 로그(logcat) 및 UI로 검증
  • 예상치 못한 정보 노출, 기능 실행 여부 확인

4-3. 자동화 분석 도구

  • MobSF: APK 정적 분석, 컴포넌트 권한/노출 자동 탐색
  • IntentFuzzer: 인텐트 기반 공격 자동화
  • adb shell/am 명령어: PoC 실습, 입력 변조

5️⃣ 실전 대응법 & 하드닝

📌 Manifest 하드닝

  • 불필요한 경우 exported=false
  • 내부 전용 컴포넌트는 반드시 외부 노출 차단
  • permission으로 민감 기능/컴포넌트 보호

📌 코드 하드닝

  • 입력 검증 필수:
    • 전달받은 인텐트의 action/component/extra 등 반드시 화이트리스트/필터 적용
    • 신뢰할 수 없는 데이터는 내부에 전달 금지
  • 권한/인증 확인:
    • 민감 Activity/Service 진입 전 사용자 인증/권한 체크 필수

예시 (개선 코드)

// 취약: 검증 없이 getIntent() 전달
startActivity(getIntent());

// 안전: action, permission 등 체크 후 실행
Intent in = getIntent();
if ("MY_SAFE_ACTION".equals(in.getAction())
    && checkCallingOrSelfPermission("MY_APP_PERMISSION") == PackageManager.PERMISSION_GRANTED) {
    startActivity(new Intent(this, SafeActivity.class));
}

✅ 실전 체크리스트

  • Manifest 내 exported/permission 설정 확인
  • 입력 검증/필터링 미비 코드 탐색
  • PoC(실제 인텐트 조작)로 취약 동작 확인
  • logcat 등에서 민감 Activity/Service 실행 여부 검증
  • 코드/설정 하드닝 적용 후 재테스트
  • 공식 가이드/보안 문서 최신 정보 반영

🔗 참고자료


✍️ 마무리

Intent Redirection은 개발자가 아주 사소한 입력 검증/설정 실수만으로
앱 전체의 권한 경계를 무너뜨릴 수 있는 치명적 취약점입니다.

최신 CVE 사례(CVE-2024-26131)처럼,
실제 앱/서비스에서 반복적으로 발견되는 공격이므로
Manifest 설정, 코드 입력 검증 등을 통해 취약점을 확인할 수 있습니다.

그렇다고 요청이 어떻게 가는지도 모르는데, 공격을 남발하지 맙시다.. 잡혀갑니다....