암호화 되지 않은 중요정보 - 금융권 모의해킹 시뮬레이터

인터셉트된 요청

수정된 요청

취약점 발견

🎯 Burp Suite Professional Intercepting

🔍

대기 중... 은행 로그인을 시도하면 요청이 여기에 표시됩니다.

#	Method	URL	Status	Length	MIME	Protocol
1	POST	http://bank.example.com/api/login	200	342	JSON	HTTP
2	GET	http://bank.example.com/api/account/1234	200	1024	JSON	HTTP
3	POST	http://bank.example.com/api/transfer	200	156	JSON	HTTP

🔧 Proxy Settings

Proxy Listener:

✓ Running on 127.0.0.1:8080

⚠️ 발견된 취약점

🚨 HIGH: Unencrypted Communication

• HTTP 프로토콜 사용 (암호화 없음)
• 민감정보 평문 전송 (비밀번호, 계좌번호)
• MITM 공격에 취약
• 권장: HTTPS (TLS 1.2 이상) 적용

⚠️ MEDIUM: Sensitive Data Exposure

• Response에 민감정보 노출
• 잔액 정보가 암호화 없이 전송됨
• 권장: 데이터 암호화 적용

📊 모의해킹 분석

🎯 Burp Suite 사용법

1단계: Proxy 설정

• 브라우저 프록시: 127.0.0.1:8080
• Burp Suite Proxy Listener 활성화

2단계: Intercept ON

• "Intercept is on" 버튼 활성화
• 모든 HTTP 요청이 가로채짐

3단계: 요청 분석

• Request 내용 확인
• 평문으로 전송되는 민감정보 식별

4단계: 수정 및 재전송

• 요청 내용 수정 가능
• Forward로 서버에 전송

💀 발견된 문제점

HTTP 사용: 평문 통신으로 모든 데이터 노출
비밀번호: 암호화 없이 그대로 전송
계좌번호: 중요 금융정보 평문 전송
세션토큰: Response에 민감정보 포함

🛡️ 실전 대응 방안

금융권 필수 보안 조치:

HTTPS 필수: TLS 1.2 이상 사용
HSTS 적용: HTTP 강제 차단
Certificate Pinning: 인증서 고정
End-to-End 암호화: 클라이언트-서버 암호화

📚 참고 자료

Burp Suite Documentation
OWASP Testing Guide
전자금융거래법 보안성 심의 기준
금융보안원 보안 가이드라인

📖 Burp Suite란?

웹 애플리케이션 보안 테스팅을 위한 통합 플랫폼으로, 모의해킹 전문가들이 가장 많이 사용하는 도구입니다.

Proxy: HTTP/HTTPS 트래픽 가로채기
Repeater: 요청 수정 및 재전송
Intruder: 자동화된 공격 수행
Scanner: 자동 취약점 스캔 (Professional)

🎓 학습 포인트

이 시뮬레이터로 배울 수 있는 것:

Burp Suite의 기본 인터페이스
Intercept 기능으로 요청 가로채기
HTTP History에서 트래픽 분석
평문 전송의 위험성 실습
실제 모의해킹 시나리오 체험

스니핑 시도

데이터 탈취

공격 차단

🏦 한국금융은행 로그인 시스템 취약

🏦

한국금융은행

인터넷뱅킹 로그인

⚙️ 전송 방식 선택

📡 네트워크 패킷

Method: POST /api/login

Host: bank.example.com

Content-Type: application/x-www-form-urlencoded

Body:

username=hong123&password=myPassword1234!&account=1234-5678-9012

📊 공격 분석

💡 공격 시나리오

1단계: HTTP 프로토콜로 로그인 시도

2단계: 네트워크 스니핑 도구 실행

3단계: 평문으로 전송되는 패킷 가로채기

4단계: 사용자 ID, 비밀번호, 계좌번호 탈취

🔧 사용 도구

Wireshark: 네트워크 패킷 캡처 및 분석
tcpdump: 명령줄 패킷 스니핑
mitmproxy: MITM 공격 프록시
Burp Suite: 웹 트래픽 가로채기

⚠️ 취약점

HTTP는 평문으로 데이터를 전송합니다!

• 사용자 ID, 비밀번호가 그대로 노출
• 계좌번호, 거래내역 모두 열람 가능
• 공용 Wi-Fi에서 특히 위험
• MITM 공격에 무방비 상태

📖 네트워크 스니핑이란?

네트워크를 통해 전송되는 데이터 패킷을 가로채서 내용을 확인하는 공격 기법입니다.

평문 전송: 암호화 없이 데이터를 그대로 전송
MITM: 중간자 공격으로 통신 가로채기
패킷 캡처: Wireshark 등으로 패킷 분석

🛡️ 방어 대책

구분	취약한 방식	안전한 방식
프로토콜	HTTP (평문)	HTTPS (TLS/SSL)
비밀번호	평문 전송	해시 + 암호화
계좌정보	암호화 없음	AES-256 암호화
세션	평문 쿠키	암호화된 토큰

DB 침투 시도

데이터 유출

유출 차단

💾 고객 정보 데이터베이스 취약

💾

고객정보 DB

Users Table

⚙️ 저장 방식 선택

🗄️ 데이터베이스 내용

SELECT * FROM users LIMIT 3;

ID: 1, Name: 홍길동, SSN: 850101-1234567

Password: myPassword123!

Account: 1234-5678-9012-3456

Balance: ₩15,430,000

ID: 2, Name: 김철수, SSN: 920303-2345678

Password: password1234

Account: 9876-5432-1098-7654

Balance: ₩8,750,000

📊 공격 분석

💡 공격 시나리오

1단계: SQL Injection으로 DB 접근 권한 획득

2단계: 고객 정보 테이블 조회

3단계: 평문으로 저장된 개인정보 확인

4단계: 주민번호, 계좌번호, 비밀번호 대량 유출

💀 유출 가능 정보

주민등록번호: 평문 저장 시 그대로 노출
비밀번호: 해시 없이 원본 그대로
계좌번호: 암호화 없이 조회 가능
잔액정보: 금융 정보 전부 유출

⚠️ 법적 책임

개인정보보호법 위반 시 과징금 부과!

• 주민번호 평문 저장: 최대 3억원 과태료
• 암호화 의무 위반: 매출액의 3% 과징금
• 전자금융거래법 위반: 영업정지 가능
• 집단소송 및 손해배상 청구

📖 DB 암호화의 중요성

데이터베이스에 중요 정보를 평문으로 저장하면 DB가 유출될 경우 모든 정보가 그대로 노출됩니다.

주민번호: 개인정보보호법상 암호화 필수
비밀번호: bcrypt, PBKDF2 등 단방향 해시
계좌정보: AES-256 등 양방향 암호화

🛡️ 암호화 방법

비밀번호: bcrypt.hashpw(password, salt)
주민번호: AES-256-CBC 암호화
계좌번호: 애플리케이션 레벨 암호화
TDE: 데이터베이스 전체 암호화 (Transparent Data Encryption)

로그 접근 시도

정보 유출

유출 차단

📝 애플리케이션 로그 취약

📝

시스템 로그

app.log

⚙️ 로깅 방식 선택

📄 로그 파일 내용

[2024-12-14 09:23:15] INFO: Login attempt - user=hong123

[2024-12-14 09:23:16] DEBUG: Password validation - password=myPassword123!

[2024-12-14 09:23:17] INFO: Login successful

[2024-12-14 09:25:42] INFO: Transfer request - from=1234-5678-9012

[2024-12-14 09:25:42] DEBUG: Transfer to=9876-5432-1098, amount=₩1,500,000

[2024-12-14 09:25:43] INFO: OTP verification - code=847293

[2024-12-14 09:25:44] INFO: Transfer completed

[2024-12-14 10:14:23] INFO: Login attempt - user=kim456

[2024-12-14 10:14:24] DEBUG: Password check - password=password1234

[2024-12-14 10:14:25] ERROR: Login failed - invalid credentials

[2024-12-14 11:03:11] INFO: Account inquiry - SSN=850101-1234567

[2024-12-14 11:03:12] DEBUG: Card number=1234-5678-9012-3456, CVV=123

📊 공격 분석

💡 공격 시나리오

1단계: 서버 취약점으로 로그 파일 접근

2단계: app.log 파일 다운로드

3단계: 로그에 기록된 평문 정보 확인

4단계: 비밀번호, OTP, 계좌번호 등 수집

💀 로그에 남는 정보

비밀번호: DEBUG 레벨 로깅 시 평문 기록
OTP 코드: 인증번호가 그대로 노출
계좌번호: 거래 로그에 포함
주민번호: 조회 로그에 기록
카드정보: 카드번호, CVV 노출

⚠️ 개발자 실수

디버깅 중 민감정보를 로그에 남기는 실수!

• logger.debug("Password: " + password)
• System.out.println("Card: " + cardNumber)
• console.log("SSN: " + ssn)
• 운영 환경에서 DEBUG 레벨 활성화

📖 안전한 로깅

로그는 문제 해결을 위해 필요하지만, 민감정보가 포함되면 안 됩니다.

마스킹: 비밀번호는 ****, 계좌는 1234-****-9012
로그 레벨: 운영 환경에서는 INFO 이상만
로그 암호화: 중요 로그는 암호화하여 저장
접근 제어: 로그 파일 권한 엄격히 관리

🛡️ 로깅 모범 사례

절대 금지: 비밀번호, 주민번호, 카드번호 로깅
마스킹 필수: 계좌번호, 전화번호 등
로그 순환: 일정 기간 후 자동 삭제
암호화 저장: 민감한 로그는 암호화

🔓 암호화 되지 않은 중요정보

🔧 Proxy Settings

⚠️ 발견된 취약점