728x90

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는 모든 사용자가 사용하지만, 각자의 파일만 삭제할 수 있음
728x90
728x90

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 데이터는 반드시 형식과 내용을 검증

 

최신 보안 패치 적용

사용중인 파서 라이브러리, 프레임워크의 최신 보안 업데이트 적용

 

 

 

728x90
728x90

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
728x90
728x90

 

 VPN (Virtual Private Network)란?

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

 

 

 VPN의 주요 기능

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

 

 

 VPN의 기본 동작 원리

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

 

 

 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, 방화벽 우회 용이
보안성 강력 (넓은 범위) 강력 (특정 목적)
사용 사례 사무실 간 연결, 전체 사설망 접근 원격 사용자, 특정 서비스 접근

 

 

 

 

 

728x90
728x90

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 차단

 

728x90
728x90

 

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.

 

728x90
728x90

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)
728x90
728x90

 

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)

 

728x90
728x90

 

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

세션 하이재킹은 사용자가 웹 애플리케이션 또는 서비스에 로그인한 뒤 서버로부터 부여받은 세션 식별자(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: 시퀀스 번호 및 세션 모니터링

 

728x90
728x90

 

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 범위 내에서만 동작해야 합니다.
728x90

+ Recent posts