모바일 SDK 스푸핑 방지 심층 분석

모바일 애플리케이션의 확산은 편리함을 가져다주었지만 새로운 보안 문제도 야기했습니다. 점점 더 정교해지는 위협 중 하나는 모바일 SDK 스푸핑으로, 악의적인 행위자가 합법적인 앱 내의 소프트웨어 개발 키트(SDK)를 조작하거나 교체하여 무단 액세스 또는 데이터 손상을 일으키는 것입니다. 이 글에서는 모바일 SDK 스푸핑의 작동 방식, 관련 위험 및 앱 어테스태이션과 모바일 상호 TLS(mTLS)를 포함한 강력한 완화 전략을 심층적으로 살펴봅니다. 또한 Didit의 신원 플랫폼이 이러한 취약점을 해결하는 방법을 살펴볼 것입니다.

핵심 내용 1: 모바일 SDK 스푸핑은 공격자가 모바일 애플리케이션에 통합된 타사 라이브러리의 기능을 가로채거나 수정하거나 교체할 수 있도록 합니다.

핵심 내용 2: 앱 어테스태이션은 모바일 애플리케이션 환경의 무결성을 확인하고 변조를 감지하며 스푸핑 위험을 줄이는 데 중요한 기술입니다.

핵심 내용 3: 모바일 mTLS는 클라이언트(앱)와 서버가 모두 디지털 인증서를 사용하여 서로를 인증하도록 요구하여 보안 계층을 추가하고 무단 액세스를 방지합니다.

핵심 내용 4: 진화하는 SDK 스푸핑 기술보다 앞서 나가기 위해서는 사전 모니터링 및 지속적인 위협 인텔리전스가 필수적입니다.

모바일 SDK 스푸핑 이해

모바일 애플리케이션은 거의 고립되어 작동하지 않습니다. 분석, 광고, 결제 처리 및 특히 신원 확인과 같은 기능을 위해 타사 SDK에 의존하는 경우가 많습니다. 공격자는 SDK 통합의 취약점을 악용하여 악성 코드를 주입합니다. 이는 다음과 같은 여러 방법을 통해 달성할 수 있습니다.

• 바이너리 패칭: 컴파일된 애플리케이션 패키지(Android의 APK, iOS의 IPA)를 수정하여 합법적인 SDK 코드를 손상된 버전으로 교체합니다.
• 동적 계측: Frida 또는 Xposed(Android)와 같은 프레임워크를 사용하여 런타임에 SDK 동작을 가로채고 수정합니다.
• 중간자(MitM) 공격: 앱과 SDK 제공자 간의 네트워크 트래픽을 가로채 악성 응답을 주입합니다.
• 재패키징: 애플리케이션을 분해, 수정 및 재구성하여 악성 SDK를 사용합니다.

성공적인 모바일 SDK 스푸핑의 결과는 데이터 침해, 사기성 거래, 계정 탈취 및 평판 손상과 같이 심각할 수 있습니다. 손상된 신원 확인 SDK의 경우 공격자가 보안 검사를 우회하고 민감한 사용자 데이터에 액세스할 수 있습니다.

앱 어테스태이션의 역할

앱 어테스태이션은 하드웨어 기반 보안 기능을 활용하여 애플리케이션이 변조되지 않았음을 확인하여 모바일 애플리케이션의 무결성을 확인하는 보안 메커니즘입니다. Android의 SafetyNet Attestation 및 iOS의 DeviceCheck는 이러한 시스템의 예입니다.

일반적인 작동 방식은 다음과 같습니다.

1. 앱은 운영 체제에서 어테스태이션 보고서를 요청합니다.
2. OS는 하드웨어 기반 키를 사용하여 보고서에 암호화 방식으로 서명합니다.
3. 보고서에는 장치의 무결성, 소프트웨어 버전 및 앱이 수정되었는지 여부에 대한 정보가 포함됩니다.
4. 서버는 OS의 신뢰할 수 있는 루트에 대해 어테스태이션 보고서를 확인하여 앱의 진위 여부를 확인합니다.

어테스태이션이 실패하면 앱이 변조되었음을 나타내며 서버는 해당 앱의 요청을 처리하지 않아야 합니다. 완벽하지는 않지만(루팅/탈옥은 어테스태이션을 우회할 수 있음) 공격자의 진입 장벽을 크게 높입니다. 그러나 어테스태이션만으로는 충분하지 않습니다. 단순히 특정 시점의 장치 상태를 확인할 뿐이며 지속적인 무결성을 보장하지는 않습니다.

모바일 mTLS: 연결 강화

모바일 mTLS(mutual Transport Layer Security)는 클라이언트(모바일 앱)와 서버가 모두 디지털 인증서를 사용하여 서로를 인증하도록 요구하여 보안을 한 단계 더 강화합니다. 이를 통해 양 당사자가 주장하는 신원인지 확인하고 무단 액세스와 MitM 공격을 방지합니다.

기존 TLS 핸드셰이크에서는 서버만 클라이언트에 인증서를 제시합니다. mTLS에서는 클라이언트도 서버에 인증서를 제시합니다. 이 인증서는 일반적으로 앱 온보딩 프로세스 중에 프로비저닝되거나 신뢰할 수 있는 인증 기관을 통해 얻습니다.

mTLS의 이점은 다음과 같습니다.

• 강력한 인증: 앱과 서버의 신원을 확인합니다.
• 향상된 보안: 무단 액세스 및 MitM 공격을 방지합니다.
• 제로 트러스트 아키텍처: 모든 연결을 확인하여 제로 트러스트 원칙에 부합합니다.

모바일 mTLS를 구현하려면 신중한 인증서 관리와 장치에 대한 안전한 키 저장 메커니즘이 필요합니다. 하드웨어 보안 모듈(HSM) 또는 보안 영역은 종종 개인 키를 보호하는 데 사용됩니다.

Didit의 도움

Didit의 신원 플랫폼은 모바일 SDK 스푸핑의 과제에 대해 다층적 접근 방식을 취합니다.

• 내장된 앱 어테스태이션: Didit은 앱 어테스태이션 서비스와 통합되어 모든 요청을 처리하기 전에 애플리케이션 환경의 무결성을 확인합니다.
• mTLS 지원: Didit은 앱과 서버 간의 보안 통신을 위한 mTLS를 지원하여 승인된 애플리케이션만 신원 확인 서비스에 액세스할 수 있도록 합니다.
• SDK 변조 감지: SDK 내에서 런타임 무결성 검사를 사용하여 수정 또는 변조 시도를 감지합니다.
• 지속적인 모니터링: Didit의 위협 인텔리전스 팀은 새로운 SDK 스푸핑 기술을 지속적으로 모니터링하고 그에 따라 방어 체계를 업데이트합니다.
• 보안 키 관리: 민감한 자격 증명을 보호하기 위해 안전한 키 관리 사례를 사용합니다.

Didit 플랫폼은 보안을 핵심 원칙으로 구축된 신원 확인, 사기 탐지 및 규정 준수를 위한 통합 솔루션을 제공합니다.

시작할 준비가 되셨습니까?

오늘날의 위협 환경에서 모바일 SDK 스푸핑으로부터 모바일 애플리케이션을 보호하는 것은 매우 중요합니다. Didit은 이러한 위험을 완화하기 위한 강력하고 포괄적인 솔루션을 제공합니다.

오늘 저희 플랫폼을 살펴보세요: Didit.me

데모를 요청하세요: 데모 센터

FAQ

앱 어테스태이션과 장치 어테스태이션의 차이점은 무엇입니까?

자주 상호 교환적으로 사용되지만 앱 어테스태이션은 애플리케이션 자체가 변조되지 않았는지 확인하여 애플리케이션의 무결성을 확인하는 데 중점을 둡니다. 반면에 장치 어테스태이션은 장치 및 운영 체제의 전체 무결성을 확인하여 루팅, 탈옥 또는 기타 수정을 확인합니다. 앱 어테스태이션은 SDK 스푸핑 방지에 더 관련성이 높은 경우가 많습니다.

앱 어테스태이션을 우회할 수 있습니까?

예, 앱 어테스태이션은 특히 루팅되거나 탈옥된 장치에서 우회할 수 있습니다. 그러나 어테스태이션을 우회하려면 상당한 노력과 전문 지식이 필요하므로 대부분의 공격자에게는 억제 요인으로 작용합니다. 악의적인 활동에 대한 진입 장벽을 크게 높입니다.

모바일에서 mTLS를 구현하는 데 따르는 어려움은 무엇입니까?

모바일에서 mTLS를 구현하려면 신중한 인증서 관리, 안전한 키 저장 및 잠재적인 성능 오버헤드가 필요합니다. 인증서 프로비저닝 및 로테이션을 적절히 수행하고 장치에서 개인 키를 보호하는 것이 주요 과제입니다. 보안 영역과 같은 하드웨어 기반 보안 기능을 사용하는 것이 중요합니다.

mTLS에 사용되는 인증서는 얼마나 자주 로테이션해야 합니까?

인증서 로테이션 빈도는 위험 감수 수준 및 규정 준수 요구 사항에 따라 다릅니다. 일반적으로 6~12개월마다 인증서를 로테이션하는 것이 좋습니다. 더 짧은 로테이션 기간은 보안을 강화하지만 운영 복잡성도 증가시킵니다. 로테이션 프로세스를 자동화하는 것이 좋습니다.