위험은 내 중간이름 안드로이드 앱 SSL 취약점 실험

초록

이 연구는 다운로드 수 1천만 회 이상이며 전체 네트워크 접근 권한을 요구하는 100개의 인기 안드로이드 앱을 대상으로 정적·동적 분석을 수행한다. 정적 분석 결과 32%의 앱이 모든 인증서와 호스트명을 무조건 허용하고, 4개의 앱은 민감 데이터를 암호화 없이 전송한다는 사실을 발견했다. 동적 실험에서는 MITM 공격 시, 공격자가 기기에 인증서를 설치했을 경우 91%의 앱이 민감 정보를 탈취당할 수 있음을 확인했다. 논문은 개발자를 위한 보안 권고사항을 제시하고, 향후 연구 과제로 모바일 SSL 구현 검증 자동화와 사용자 인식 개선을 제안한다.

상세 요약

본 논문은 안드로이드 애플리케이션의 SSL/TLS 구현 취약성을 체계적으로 측정하기 위해 두 단계의 분석 프레임워크를 설계하였다. 첫 번째 단계인 정적 분석에서는 APK 파일을 역컴파일하고, 주요 네트워크 라이브러리(OkHttp, Apache HttpClient, HttpURLConnection 등)의 SSLContext 초기화 코드를 추출하였다. 여기서 TrustManager와 HostnameVerifier 구현을 검사하여, 모든 인증서를 수락하거나 모든 호스트명을 검증하지 않는 ‘accept‑all’ 패턴을 식별하였다. 결과적으로 32개의 앱(전체 32%)이 이러한 패턴을 포함하고 있었으며, 이 중 12개는 커스텀 TrustManager를 사용해 인증서 검증 로직을 완전히 비활성화하였다.

두 번째 단계인 동적 분석에서는 실제 기기와 에뮬레이터 환경에서 MITM 프록시(예: mitmproxy, Burp Suite)를 이용해 트래픽을 가로채었다. 실험은 두 가지 시나리오로 구분되었다. (1) 공격자가 자체 서명 인증서를 기기에 설치하지 않은 경우, (2) 공격자가 루트 인증서를 설치해 시스템 전역 신뢰 저장소에 추가한 경우. 시나리오(1)에서는 58%의 앱이 여전히 연결을 허용했으며, 이는 앱이 인증서 핀닝(pinning)이나 강제 검증을 수행하지 않음을 의미한다. 시나리오(2)에서는 91%의 앱이 완전히 무방비 상태가 되었으며, 이때 탈취된 데이터에는 로그인 자격 증명, 세션 토큰, 개인 식별 정보(PII), 신용카드 번호 등이 포함되었다. 특히, 금융 관련 앱 4개는 HTTPS를 사용했음에도 불구하고 POST 파라미터를 평문으로 전송하는 버그를 보여, 네트워크 레이어와 애플리케이션 레이어 간 보안 경계가 제대로 설정되지 않았음을 드러냈다.

또한, 논문은 취약점이 발생하는 근본 원인을 세 가지 카테고리로 정리한다. 첫째, 개발자가 SSL 구현을 단순히 ‘동작 보장’ 수준으로만 테스트하고, 인증서 검증 로직을 생략하거나 디버깅용 코드(예: TrustAllCertificates)를 배포 단계까지 남겨두는 경우다. 둘째, 서드파티 라이브러리의 업데이트 부재로 인해 오래된 SSL/TLS 버전과 취약한 암호 스위트가 그대로 사용되는 경우이며, 이는 안드로이드 플랫폼 자체가 TLS 1.2 이상을 기본 지원함에도 불구하고 하위 호환성을 위해 허용되는 설정 때문이다. 셋째, 앱이 자체 서버와 통신할 때 인증서 핀닝을 적용하지 않아, 중간자 공격 시 인증서 교체가 자유롭게 이루어지는 구조적 결함이다. 이러한 원인 분석을 통해 연구자는 개발 단계에서 자동화된 정적 검사와 동적 테스트를 결합한 CI/CD 파이프라인 구축의 필요성을 강조한다.