[Android] 루팅, 중간자 공격, 후킹, Frida — 앱 보안의 공격자 이해하기

5 분 소요

개요

인증서 피닝, 루팅 탐지, 앱 무결성 검사 같은 앱 보안 기법을 공부하다 보면 “그래서 이걸로 무엇을 막는 건지”, “왜 이것만으로는 부족하다고 하는지”가 헷갈리기 쉽다. 방어를 이해하려면 먼저 공격자가 무엇을 할 수 있는지를 알아야 한다.

이 글에서는 모바일 앱 보안에서 자주 등장하는 네 가지 개념인 루팅, 중간자 공격(MITM), 후킹, Frida가 각각 무엇인지, 왜 앱 보안에서 문제가 되는지, 그리고 앱이 이에 맞서 할 수 있는 것과 그 한계를 방어자 입장에서 정리한다.

두 종류의 공격자

앱 보안에서는 공격자가 어디에 있느냐에 따라 할 수 있는 일이 완전히 달라진다.

구분	네트워크 경로의 공격자	기기를 장악한 공격자
위치	앱과 서버 사이 (공용 와이파이, 악성 AP 등)	앱이 실행되는 기기 자체
예	같은 네트워크에서 트래픽을 엿보는 제3자	자기 기기에서 앱을 분석하는 사람, 보안 점검자
할 수 있는 것	트래픽 관찰·변조 시도	기기 권한 장악, 앱 메모리·코드·트래픽 전부 관찰·변조
기본 방어	TLS(HTTPS)	앱 단독으로는 완벽한 방어 불가

모바일 앱 보안 점검은 대개 기기를 장악한 공격자를 기준으로 한다.

아래에서 다루는 루팅, 후킹, Frida는 모두 이 공격자가 쓰는 수단이다.

루팅

루팅이란

Android는 앱마다 서로 다른 리눅스 사용자 ID를 부여해 격리한다(앱 샌드박스). 그래서 앱 A는 앱 B의 데이터 디렉터리에 접근할 수 없다. 루팅은 이 체계의 최상위 권한인 root 권한을 얻는 것이고, root는 샌드박스 경계를 넘어설 수 있다.

어떻게 이루어지나

일반적으로 루팅은 부트로더 잠금 해제에서 시작한다.

부트로더 잠금 해제 — 공식 절차상 이때 기기의 개인 데이터가 모두 삭제된다.
잠금이 풀린 기기는 Verified Boot 상태가 ORANGE가 되고, 부팅할 때마다 “소프트웨어 무결성을 보장할 수 없다”는 경고가 표시된다.
이후 부트 이미지를 수정해 root 권한을 얻는다. 대표적인 도구가 Magisk로, 부트 이미지를 수정해 앱에 root 권한을 제공하고, 모듈로 읽기 전용 영역을 바꾸거나 앱 프로세스 안에서 코드를 실행하는 기능을 제공한다.

루팅되면 무엇이 가능해지나

가능해지는 것	앱 보안에 미치는 영향
다른 앱의 데이터 디렉터리 접근	앱이 기기에 저장한 토큰·설정·DB를 읽을 수 있다
시스템 영역 변경	기기의 신뢰 CA 저장소를 바꿔 HTTPS 트래픽을 들여다볼 수 있다 (아래 MITM)
다른 프로세스 계측	실행 중인 앱에 코드를 주입해 동작을 바꿀 수 있다 (아래 후킹·Frida)

앱에서 할 수 있는 것과 한계

앱은 루팅 흔적(su 바이너리, 루팅 관리 앱, 시스템 속성 등)을 확인하는 루팅 탐지를 할 수 있다. 하지만 루팅 도구 쪽에도 특정 앱에서 루팅 흔적을 숨기는 기능이 있고, 탐지 코드 자체도 앱 안에서 돌기 때문에 조작될 수 있다.

그래서 앱 안의 루팅 탐지만으로는 부족하고, 기기 상태를 서버 쪽에서 판정하는 방식(예: Play Integrity API의 기기 무결성 판정)을 함께 쓰는 추세다.

중간자 공격 (MITM)

중간자 공격이란

중간자 공격(Man-in-the-Middle, MITM)은 공격자가 통신하는 두 당사자 사이에 끼어들어, 양쪽 모두 상대와 직접 통신한다고 믿게 만든 채 트래픽을 관찰하거나 변조하는 공격이다.

HTTPS면 안전하지 않나

기본적으로는 안전하다. TLS는 서버 인증서가 기기의 신뢰 CA로 서명됐는지 검증하므로, 중간자가 만든 가짜 인증서는 거부된다. 그래서 MITM이 성공하려면 공격자는 기기가 자신의 CA를 신뢰하게 만들어야 한다.

Android 7.0(API 24) 이상을 타깃으로 하는 앱은 기본적으로 사용자가 설치한 CA를 신뢰하지 않는다. 설정 앱에서 CA를 설치하는 것만으로는 최신 앱의 트래픽을 볼 수 없다
그래서 기기를 장악한 공격자는 보통 루팅 후 시스템 신뢰 저장소에 자신의 CA를 넣는 방법을 노린다
Android 14부터는 시스템 CA 저장소가 업데이트 가능한 모듈(Conscrypt)로 옮겨져, 여기에 CA를 넣는 일이 이전보다 까다로워졌다

왜 문제가 되나

트래픽이 보이면 공격자는 API의 구조, 요청 파라미터, 응답 형식을 그대로 파악할 수 있다. 그리고 요청 값을 바꿔 보내면서 서버가 이를 제대로 검증하는지 시험할 수 있다.

방어자 입장에서 중요한 결론은 이것이다. 기기 주인은 결국 자기 기기의 트래픽을 볼 수 있다고 가정해야 한다. HTTPS는 네트워크 경로의 제3자로부터 트래픽을 지켜주지만, 기기를 장악한 사람으로부터 API를 숨겨주지는 않는다. 그래서 서버는 클라이언트가 보낸 모든 값을 다시 검증해야 한다.

앱 쪽에서 MITM을 어렵게 만드는 대표적인 방법이 인증서 피닝이다. 이에 대해서는 다음 글에서 따로 다룬다.

후킹

후킹이란

후킹(hooking)은 실행 중인 프로그램의 함수 호출을 중간에 가로채서 인자를 보거나, 반환값을 바꾸거나, 동작 자체를 바꾸는 기법이다. 원래 디버깅·성능 분석·기능 확장 등에도 쓰이는 일반적인 기술이지만, 앱 보안에서는 앱의 보안 로직을 무력화하는 수단으로 쓰인다.

대상	설명
자바/코틀린 메서드	ART(Android 런타임) 위에서 도는 앱 코드의 메서드를 가로챈다
네이티브 함수	C/C++로 작성된 라이브러리(.so)의 함수를 가로챈다

대표적인 도구로 Frida와 Xposed 계열 프레임워크(LSPosed 등)가 있다.

왜 문제가 되나

후킹이 가능하다는 것은 앱 안에서 내려지는 판단의 결과를 바꿀 수 있다는 뜻이다.

“이 기기는 루팅되었는가?” → 항상 “아니오”로
“서버 인증서가 핀과 일치하는가?” → 항상 “예”로
“앱이 변조되지 않았는가?” → 항상 “정상”으로
클라이언트에서 하는 입력값 검증 → 건너뛰기

즉 앱 안에서 “검사하고 통과/차단을 결정”하는 구조라면, 그 결정 지점이 곧 공격 지점이 된다.

Frida

Frida란

Frida는 동적 계측(dynamic instrumentation) 툴킷이다. 실행 중인 프로세스에 자바스크립트 런타임을 주입하고, 스크립트로 그 프로세스의 함수를 관찰하거나 바꿀 수 있게 해준다. Android, iOS, Windows, macOS, Linux를 지원하고, 모바일 앱 보안 점검에서 사실상 표준 도구로 쓰인다.

동작 방식

공식 문서는 Frida의 동작 방식을 크게 두 가지로 설명한다.

방식	설명	전제 조건
주입(Injected)	기기에서 frida-server를 실행하고, PC에서 연결해 실행 중인 앱 프로세스에 주입한다	Android 공식 가이드는 루팅된 기기를 전제로 한다
임베드(Embedded)	frida-gadget 라이브러리를 앱 안에 넣어 함께 실행되게 한다	앱에 라이브러리를 넣어야 하므로 앱을 다시 패키징해야 한다

방어자 입장에서 볼 점

주입 방식은 루팅을 전제로 하므로, 루팅 탐지·기기 무결성 판정이 첫 번째 방어선이 된다
임베드 방식은 앱을 다시 패키징해야 하므로 서명이 원래 앱과 달라진다. 앱 서명 검증이나 서버 쪽 앱 무결성 판정으로 걸러낼 여지가 생긴다
Frida 실행 흔적을 직접 탐지하는 방법도 있지만, 그 탐지 코드 역시 앱 안에서 돌기 때문에 후킹 대상이 될 수 있다

정리

네 가지를 합쳐 보면, 기기를 장악한 공격자 앞에서 앱 안의 방어는 결국 우회될 수 있다는 결론에 이른다. 그래서 앱 보안은 하나의 완벽한 방어가 아니라 여러 겹의 방어로 공격 비용(시간·난이도)을 높이고, 중요한 판단은 서버에서 하는 구조로 설계한다.

위협	앱에서 할 수 있는 것	한계	함께 써야 할 것
루팅	루팅 탐지	숨김 기능·탐지 코드 조작으로 우회	서버 쪽 기기 무결성 판정
MITM	TLS + 인증서 피닝	기기를 장악하면 피닝도 우회 가능	서버 쪽 입력값 검증
후킹·Frida	후킹 도구 탐지	탐지 코드도 후킹 대상	난독화, 검사 분산, 서버 판정
리패키징	앱 서명 검증	검증 로직 자체가 변조될 수 있음	서버 쪽 앱 무결성 판정