← 메인으로

🪪 전자금융 보안 모의해킹 · 서버 인증서 무결성 검증

Target: 모바일/클라이언트 TLS 연결
평가기준: 위험도 5 WEB-SER 서버 인증서 무결성(030)
💡 쉽게 말하면
아무 도장이나 찍힌 신분증을 그냥 믿으면, 위조 신분증을 든 사람이 본인 행세를 합니다. 진짜 발급기관의 도장인지 끝까지 확인하고, 미리 받아둔 지문(핀)과 같은지까지 맞춰봐야 합니다.
🔓 공격 시뮬레이션 (Red Team)
🛡️ 대응 방안 (Blue Team)
서버 TLS 연결 검증🔒 Secured Channel
앱/클라이언트가 서버 TLS 인증서의 유효성·신뢰체인·핀(pin)을 검증하지 않거나 모든 인증서를 무조건 신뢰하면, 동일 네트워크의 공격자가 MITM 프록시 인증서로 끼어들어 거래 통신을 그대로 가로채고 변조할 수 있습니다.
⚡ MITM 프록시 인증서 가로채기
모든 인증서 신뢰 → mitmproxy 인증서로 통신 열람
OFF
🖥️ 금융 시스템 처리 로그
[SYSTEM] Core Banking Channel ready.
[INFO] 거래 요청 대기 중...
⚖️ 컴플라이언스 위반 분석
공격 실행 후 분석 결과가 표시됩니다.
[심각] 전자금융 보안 기준 위반 감지
  • 평가기준 [전자금융] 서버 인증서 무결성 검증(위험도 5)
  • 전자금융감독규정 제32조: 전송구간 서버 인증서 검증 미흡
  • 부적절한 인증서 검증 / TrustManager 무력화(IN)
🛡️ 대응 코드/설정 실습

클라이언트는 서버 인증서의 기본 신뢰체인·호스트명 검증을 유지하고, 가능하면 Certificate Pinning을 적용해야 합니다. TrustManager를 비우는(모두 신뢰) 무력화는 금지입니다. 아래 코드를 보완하세요.

📚 금융보안원 평가기준 / 조치 가이드

1. 점검 항목

통신 보안 > 서버 인증서 무결성 검증

2. 위험 분석

  • 인증서 미검증 시 MITM 프록시 인증서 수용
  • 거래정보·자격증명 탈취 및 변조

3. 조치 방법

  • 기본 신뢰체인·호스트명 검증 유지
  • Certificate Pinning으로 인증서 고정
  • 모든 인증서를 신뢰하는 TrustManager 무력화 금지
🏗️ 현대 금융 IT 환경에서의 변형
인증서 피닝ACME 자동갱신CT 로그

어디가 달라졌나

인증서 자동 갱신(ACME/ACM)이 표준이 되면서 피닝과 충돌이 생겼습니다. 90일마다 인증서가 바뀌는데 앱에 고정 핀을 박아 두면 갱신 시점에 앱이 통째로 죽습니다. 실제로 이 사고로 서비스가 중단된 금융 앱 사례가 여럿 있습니다.

현대 스택에서의 조치

  • 리프 인증서가 아니라 중간 CA 또는 공개키(SPKI)에 피닝합니다. 갱신되어도 키가 유지되면 핀이 살아 있습니다.
  • 백업 핀을 반드시 포함합니다(차기 키). 핀이 하나뿐이면 되돌릴 방법이 없습니다.
  • Android 는 Network Security Configuration, iOS 는 ATS + 코드 피닝으로 선언합니다. 서버 측은 CT(인증서 투명성) 로그 모니터링으로 오발급을 탐지합니다.
<!-- Android: 핀 2개(현재+백업)와 만료일을 함께 -->
<pin-set expiration="2027-06-30">
  <pin digest="SHA-256">k3rNk9bT1r8p...=</pin>  <!-- 현재 -->
  <pin digest="SHA-256">Q2xVd8mZ4fA1...=</pin>  <!-- 백업 -->
</pin-set>
놓치기 쉬운 곳 — 피닝은 앱 업데이트 없이 못 고칩니다. 앱 심사·배포에 며칠이 걸리므로, 핀 만료일은 인증서 갱신 주기보다 넉넉히 잡고 원격 설정으로 피닝을 끌 수 있는 킬스위치를 두는 팀도 많습니다.