모바일 앱에서의 MITM 공격 — 정의, 유형 및 가로채기로부터 보호

MITM 공격이란?

Man-in-the-Middle(MITM)은 공격자가 두 당사자 간의 통신 채널에 은밀하게 침투하는 사이버 공격 유형입니다. 공격자는 양측에 보이지 않는 상태에서 전송된 데이터를 가로채고, 읽고, 수정할 수 있습니다.

모바일 앱에서 MITM 공격은 특히 위험합니다. 장치가 집, 사무실, 카페 및 공항의 공공 Wi-Fi 등 다양한 네트워크에 지속적으로 연결되기 때문입니다. 각 네트워크 전환은 잠재적으로 공격의 창을 만듭니다. Verizon Mobile Security Index(2025)에 따르면, 조직의 43%가 기업 모바일 장치에 대한 MITM 공격을 한 번 이상 경험했습니다.

MITM의 주요 위험은 은밀성입니다. 사용자와 서버는 가로채기의 신호를 받지 않습니다. 세션은 정상적으로 보이고, 데이터는 전송되며, 인증서 오류가 없습니다(공격자가 자신의 인증서를 사용하는 경우). 공격은 네트워크 인프라 수준이나 전문 도구를 통해서만 감지할 수 있습니다.

개발자는 전송 계층 보안에만 의존하지 않고 애플리케이션 수준에서 보호를 설계하기 위해 MITM 공격 메커니즘을 이해해야 합니다.

MITM 공격의 주요 유형

MITM 공격의 분류는 통신 채널 침투 방법에 따라 여러 유형을 포함합니다. 모바일 개발에서는 세 가지 유형이 가장 관련이 있습니다.

로컬 네트워크에서의 ARP Spoofing

ARP Spoofing은 공격자가 로컬 네트워크에 가짜 ARP 패킷을 보내 자신의 MAC 주소를 게이트웨이 IP 주소와 연결하는 기술입니다. 그 후, 피해자의 모든 트래픽은 공격자의 장치를 통해 라우팅되며, 공격자는 보이지 않는 상태에서 게이트웨이로 전달합니다.

공격을 실행하려면 ARP 스푸핑을 자동화하는 Ettercap 또는 BetterCAP과 같은 도구로 충분합니다. 공격은 단일 서브넷 내에서만 가능하므로 공공 Wi-Fi 네트워크 사용자가 가장 취약합니다. 관리형 스위치에서 DAI(Dynamic ARP Inspection)를 갖춘 최신 네트워크는 이 유형의 공격을 차단합니다.

ARP Spoofing으로부터 애플리케이션 수준에서 보호하는 것은 불가능합니다 — 이것은 네트워크 인프라 문제입니다. 그러나 애플리케이션은 iOS용 TrustKit 또는 Android용 Network Security Config와 같은 라이브러리를 사용하여 네트워크 연결의 이상을 감지할 수 있습니다.

DNS Spoofing 및 트래픽 가로채기

DNS Spoofing(또는 DNS 캐시 포이즈닝)은 클라이언트에서 DNS 서버로 가는 경로에서 DNS 레코드를 변조하는 것입니다. 공격자는 애플리케이션의 DNS 요청을 가로채서 가짜 IP 주소를 반환하고, 합법적인 서버 대신 자신의 서버로 트래픽을 리디렉션합니다.

이 공격은 DHCP를 통해 DNS 서버가 자동으로 할당되는 공공 네트워크에서 특히 효과적입니다. 공격자는 대상 도메인에 대해 위조된 IP 주소를 반환하는 자체 DNS 서버를 설정할 수 있습니다. 사용자는 브라우저에서 합법적인 URL을 보지만 공격자의 서버에 연결됩니다.

DNS Spoofing으로부터 애플리케이션 측의 보호는 DNS 쿼리를 암호화하는 DNS-over-HTTPS(DoH) 또는 DNS-over-TLS(DoT)를 통해 구현됩니다. Android 9+ 및 iOS 14+는 시스템 수준 DoH를 지원하며, 애플리케이션이 이 옵션을 명시적으로 활성화할 수 있습니다.

SSL Stripping — HTTPS 우회

SSL Stripping은 공격자가 보안 HTTPS 연결을 안전하지 않은 HTTP로 다운그레이드하는 공격입니다. 이 기술은 많은 사용자가 https://example.com 대신 수동으로 example.com을 입력하고 첫 번째 연결이 HTTP를 통해 설정된다는 사실을 악용합니다.

sslstrip(Moxie Marlinspike, 2009) 및 bettercap과 같은 도구는 HTTP 요청을 자동으로 가로채고, 서버와 HTTPS 연결을 설정한 다음, 복호화된 트래픽을 HTTP를 통해 클라이언트에 전달합니다. 브라우저에 자물쇠 아이콘이 표시되지 않으며 — 사용자는 연결이 안전하지 않다는 것을 알지 못합니다.

최신 보호 — HTTP Strict Transport Security(HSTS): 서버가 브라우저에 모든 향후 연결이 HTTPS만 사용해야 한다고 알립니다. HSTS Preload List는 첫 번째 공격으로부터도 추가로 보호하지만, 도메인 사전 등록이 필요합니다.

모바일 앱에서 MITM 공격이 작동하는 방식

모바일 앱에 대한 일반적인 MITM 공격은 네 단계를 거칩니다. 각 단계는 다른 취약점을 악용하며, 완전한 보호를 위해서는 모든 벡터를 포괄해야 합니다.

첫 번째 단계 — 침투: 공격자가 장치와 서버 간의 트래픽 경로에 위치합니다. 이는 로컬 네트워크에서의 ARP Spoofing, 가짜 Wi-Fi 액세스 포인트(Evil Twin) 또는 제공업체의 DNS 서버 손상일 수 있습니다. 모바일 장치는 개방형 네트워크에 자동으로 연결될 때 특히 취약합니다.

두 번째 단계 — 가로채기: 침투 후, 공격자는 앱과 서버 간에 교환되는 모든 패킷을 읽기 시작합니다. 이 단계에서 요청 URL, 패킷 크기, 쿠키, 헤더 등의 메타데이터를 수집합니다. 데이터가 암호화되어 있더라도, 메타데이터는 애플리케이션 구조와 비즈니스 로직을 드러낼 수 있습니다.

세 번째 단계 — 복호화(트래픽이 암호화된 경우): 공격자는 두 개의 TLS 연결을 설정합니다 — 하나는 서버와(위조 인증서 사용), 다른 하나는 클라이언트와 연결합니다. 앱은 연결을 안전하다고 간주하지만, 공격자는 모든 데이터를 평문으로 봅니다. Certificate Pinning이 없으면 시스템 저장소에 설치된 모든 인증서에 대해 이것이 작동합니다.

네 번째 단계 — 수정 및 유출: 공격자는 전송된 데이터를 읽을 뿐만 아니라 수정할 수도 있습니다. 금융 앱에서는 수취인의 계좌 번호를 변경하는 것을 의미할 수 있으며, API 요청에서는 권한 부여 매개변수를 수정할 수 있습니다. iOS와 Android는 애플리케이션 수준에서 응답 무결성 검사를 구현할 것을 권장합니다.

코드 예제: Android 및 iOS에서 가로채기로부터 보호

Kotlin과 Swift에서 Certificate Pinning을 사용한 MITM 공격으로부터 보호의 실제 예제를 살펴보겠습니다. 이 예제들은 시스템 저장소가 손상된 경우에도 인증서 교체를 차단합니다.

Android에서의 Certificate Pinning (OkHttp)

OkHttp는 CertificatePinner를 지원하는 Android용 표준 HTTP 라이브러리입니다. 서버 인증서의 SHA-256 해시를 지정하면 다른 모든 인증서는 거부됩니다.

import okhttp3.CertificatePinner
import okhttp3.OkHttpClient

val certificatePinner = CertificatePinner.Builder()
    .add(
        "api.example.com",
        "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA="
    )
    .build()

val client = OkHttpClient.Builder()
    .certificatePinner(certificatePinner)
    .build()

iOS에서의 Certificate Pinning (URLSession)

iOS에서는 URLSessionDelegate를 사용하여 서버 인증서를 수동으로 확인합니다. SecCertificateRef를 로컬에 저장된 복사본과 비교합니다.

class SessionDelegate: NSObject, URLSessionDelegate {
    func urlSession(
        _ session: URLSession,
        didReceive challenge: URLAuthenticationChallenge,
        completionHandler: @escaping (
            URLSession.AuthChallengeDisposition,
            URLCredential?
        ) -> Void
    ) {
        guard let serverTrust = challenge.protectionSpace
            .serverTrust else { return }

        let pinnedCert = SecCertificateCreateWithData(
            nil,
            pinnedCertData as CFData
        )

        let serverCerts = (0..<SecTrustGetCertificateCount(serverTrust))
            .compactMap { SecTrustGetCertificateAtIndex(serverTrust, $0) }

        if serverCerts.contains { CFEqual($0, pinnedCert) } {
            completionHandler(.useCredential, URLCredential(trust: serverTrust))
        } else {
            completionHandler(.cancelAuthenticationChallenge, nil)
        }
    }
}

Android에서의 Network Security Config

Android는 코드를 작성하지 않고 OS 수준에서 트래픽을 차단하는 network_security_config.xml 파일을 통한 선언적 보호를 지원합니다.

<!-- network_security_config.xml -->
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">api.example.com</domain>
        <pin-set expiration="2027-07-01">
            <pin digest="SHA-256">AAAAAAAAAAAAAAAAAAAAAAAAAAAA</pin>
        </pin-set>
    </domain-config>
</network-security-config>

모바일 앱을 MITM으로부터 보호하는 방법

MITM 공격으로부터의 포괄적인 보호는 애플리케이션, 서버 및 네트워크 인프라 수준의 조치를 포함합니다. 아래는 Android 및 iOS에 대한 주요 권장 사항입니다.

Certificate Pinning 사용 — 애플리케이션 코드에 서버 인증서를 바인딩합니다. 시스템 저장소의 모든 인증서를 신뢰하는 표준 TLS 검증과 달리, Certificate Pinning은 특정 인증서 또는 그 공개 키를 확인합니다. Android의 OkHttp와 iOS의 TrustKit은 이 메커니즘의 기성 구현을 제공합니다.

HTTPS 및 HSTS 강제: 모든 네트워크 요청은 HTTPS를 통해 이루어져야 하며, 서버는 Strict-Transport-Security 헤더를 반환해야 합니다. Android의 경우 매니페스트에 android:usesCleartextTraffic="false"를 추가합니다 — 이는 OS 수준에서 HTTP 연결을 차단합니다. iOS는 iOS 9부터 App Transport Security(ATS)를 통해 기본적으로 HTTP를 차단합니다.

응답 무결성 검사 구현: 앱이 확인하는 디지털 서명으로 서버 응답에 서명합니다. 공격자가 HTTPS 트래픽을 가로채더라도(프록시를 통한 인증서 재설치), 서버의 개인 키 없이는 서명을 위조할 수 없습니다. 중요한 작업에는 RS256 또는 HMAC 서명이 있는 JWT를 사용하세요.

서버 측에서 HTTP Public Key Pinning(HPKP) 활성화 — 브라우저나 앱에 특정 도메인에 대해 어떤 인증서를 유효한 것으로 간주해야 하는지 지시하는 지시문입니다. 그러나 HPKP는 주의가 필요합니다: 잘못된 구성은 장기간 애플리케이션 액세스를 차단할 수 있습니다. Google은 백업 인증서와 함께 HPKP만 사용할 것을 권장합니다.

NIST SP 800-52 Rev. 2(2024)에 따르면, TLS 1.3, Certificate Pinning 및 HSTS의 조합은 모바일 앱에 대한 알려진 MITM 공격 벡터의 99%를 제거합니다. 개발자는 애플리케이션을 게시하기 전에 mitmproxy와 같은 도구로 보호를 테스트하는 것이 좋습니다.