← 메인으로

🧮 전자금융 보안 모의해킹 · 취약한 HTTPS 암호 알고리즘 제거

Target: 금융 서비스 HTTPS 웹서버
평가기준: 위험도 5 WEB-SER 취약 HTTPS 암호(035)
💡 쉽게 말하면
겉만 잠금장치고 속은 헐거운 약한 자물쇠를 끼워두면 도둑이 굳이 그 약한 것을 골라 따버립니다. 검증된 튼튼한 자물쇠만 쓰도록 약한 규격을 아예 빼야 합니다.
🔓 공격 시뮬레이션 (Red Team)
🛡️ 대응 방안 (Blue Team)
Cipher Suite 스캔🔒 Secured Channel
서버가 RC4·DES·3DES·NULL·EXPORT·MD5 같은 취약한 cipher suite를 협상에 허용하면, 공격자는 약한 암호로 협상을 유도해 SWEET32 등 기법으로 캡처한 트래픽을 복호화할 수 있습니다.
⚡ 취약 암호 협상(SWEET32 등)
openssl s_client로 3DES/RC4 협상 확인
OFF
🖥️ 금융 시스템 처리 로그
[SYSTEM] Core Banking Channel ready.
[INFO] 거래 요청 대기 중...
⚖️ 컴플라이언스 위반 분석
공격 실행 후 분석 결과가 표시됩니다.
[심각] 전자금융 보안 기준 위반 감지
  • 평가기준 [전자금융] 취약한 HTTPS 암호 알고리즘 제거(위험도 5)
  • 전자금융감독규정 제32조: 안전하지 않은 암호 알고리즘 사용
  • TLS 권고(RFC 7465) RC4 금지 / SWEET32 대응 위반
🛡️ 대응 코드/설정 실습

서버는 AEAD·ECDHE 기반의 강한 cipher suite만 허용하고 RC4·DES·3DES·NULL·EXPORT·MD5 취약 cipher를 제거해야 합니다. 아래 Nginx 설정을 보완하세요.

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

1. 점검 항목

서버 보안 > 취약한 HTTPS 암호 알고리즘 제거

2. 위험 분석

  • RC4·3DES 등 약한 cipher로 트래픽 복호화(SWEET32)
  • NULL/EXPORT 사용 시 암호화 무력화

3. 조치 방법

  • AEAD·ECDHE 기반 강한 cipher만 허용
  • RC4·DES·3DES·NULL·EXPORT·MD5 제거
  • 서버 cipher 우선순위 적용
🏗️ 현대 금융 IT 환경에서의 변형
ALB 정책PFS사후 양자

어디가 달라졌나

관리형 로드밸런서에서는 암호 스위트를 개별로 켜고 끌 수 없습니다. AWS·GCP 모두 미리 정의된 정책 묶음 중에서 고르는 방식이라, 점검 결과가 “어떤 스위트가 열렸는가”가 아니라 “어떤 정책을 골랐는가” 로 바뀝니다.

현대 스택에서의 조치

  • PFS(전방향 비밀성) 를 보장하는 ECDHE 계열만 남기는 정책을 고릅니다. RSA 키 교환은 서버 키 유출 시 과거 트래픽까지 복호화됩니다.
  • TLS 1.3 은 취약 스위트가 규격에서 제거되어 있어, 1.3 전용 정책이 가장 단순한 해법입니다.
  • 실제 노출은 sslscan·testssl.sh 로 엔드포인트에서 확인합니다. 설정과 실제가 다른 경우가 많습니다.
$ testssl.sh --severity HIGH https://bank.example
 NULL ciphers (no encryption)      not offered (OK)
 Anonymous NULL ciphers            not offered (OK)
 Export ciphers                    not offered (OK)
 3DES / RC4                        not offered (OK)
 PFS                               offered (OK) — ECDHE only
앞을 내다본다면 — 금융권은 사후 양자 암호(PQC) 전환 논의가 시작됐습니다. “지금 저장해 두고 나중에 복호화”(harvest-now, decrypt-later) 위협 때문에 장기 보존 가치가 큰 거래 데이터부터 하이브리드 키 교환 검토가 권고됩니다.