[모의해킹] 취약한 HTTPS 시리즈 (프로토콜, 암호 알고리즘, 컴포넌트, 재협상)

cielo ru·2024년 8월 12일
0

모의해킹

목록 보기
12/14

➰ 점검도구 설치

취약한 HTTPS 관련 취약점을 점검하기 위해 nmap과 openssl, sslscan을 설치해보자.

1️⃣ NMAP
1) 네트워크 스캐닝 및 포트 스캐닝 도구
2) Nmap은 열려있는 포트, 운영 체제 감지, 서비스 버전 감지 등을 통해 웹 서버의 상태와 노출된 포트들을 확인하는 데 사용된다.

2️⃣ OpenSSL
1) SSL/TLS 설정과 인증서 검토 도구
2) OpenSSL은 HTTPS 서비스에서 사용하는 인증서를 검토하고, 특정 SSL/TLS 버전 또는 암호화를 강제로 사용하여 서버의 반응을 테스트할 수 있다.

  • 이전에 타 취약점 점검을 위해 openssl 설치했지만 설치를 하지 않았다면 아래 사이트에 접속하여 os 환경에 맞춰 설치한다.
    (리눅스의 경우 wget 명령어를 통해 설치한다.)

    https://slproweb.com/products/Win32OpenSSL.html

3️⃣ sslscan
1) sslscan은 대상 서버에서 지원하는 SSL/TLS 버전을 감지
2) 서버가 사용하는 암호화 스위트(Cipher Suites)와 해당 스위트의 암호화 강도를 분석한다.

➰ 취약한 HTTPS 프로토콜 이용

취약한 버전의 암호 프로토콜 사용 시 암호화된 통신 내용이 유출될 수 있어 취약한 버전의 SSL(SSL 2.0, 3.0) 사용 여부를 점검한다.

🌱 SSL를 사용하면 안되는 이유?
SSL 프로토콜은 2.0과 3.0을 비롯하여 많은 버그와 취약점이 발표되었으며, 공격자는 취약점을 바탕으로 암호화된 통신 내용을 획득 할 수 있기 때문에 SSL 프로토콜 다음 버전인 TLS 프로토콜을 사용해야 한다.

➿ 점검방법

두 가지 방법 중에 한가지만 선택해서 사용하면 된다.

cmd를 열어서 아래의 명령어를 입력한다.

  • nmap을 이용한 HTTPS 프로토콜 확인
 > nmap -p [port] --script ssl-enum-ciphers [target_host]

 > nmap -p 443 --script ssl-enum-ciphers secureroot.co.kr
  • openssl을 이용한 HTTPS 프로토콜 확인
 > openssl s_client -ssl3 -connect [target_host:port]

 > openssl s_client -ssl3 -connect secureroot.co.kr:443

점검결과 - 양호


점검결과, 취약한 버전의 SSL을 사용하지 않고 TLS 를 사용하고 있으므로 점검결과는 "양호"이다.

➰ 취약한 HTTPS 암호 알고리즘 이용

보안 강도가 낮은 암호 알고리즘을 사용할 경우 암호화된 통신 내용이 유출되는 등의 위협이 존재함에 따라 암호 알고리즘의 보안 강도의 적절성 여부를 점검한다.

🌱 HTTPS 통신을 수행하는데 통신 내용이 유출될 가능성이 존재할까?
HTTPS는 데이터를 암호화하기 위해 SSL 또는 TLS(Transport Layer Security) 프로토콜을 사용한다. 특정 암호화 알고리즘을 통해 수행되며, 이 알고리즘이 얼마나 강력한지가 HTTPS 통신의 안전성을 결정한다.
따라서 취약한 암호화 알고리즘은 충분한 복잡성과 난이도를 제공하지 못한다. 예를 들어, 키 길이가 짧거나 알고리즘의 구조적 약점으로 인해 공격자가 상대적으로 적은 계산 자원으로 암호를 해독할 수 있기 때문에 HTTPS 통신을 수행해도 통신 내용이 유출될 가능성이 존재한다.

따라서 HTTPS 통신을 수행해도 강력한 HTTPS 암호 알고리즘을 이용해야 한다.

➿ 점검방법

  • nmap을 이용한 HTTPS 암호 알고리즘 확인
 > nmap -p [port] --script ssl-enum-ciphers [target_host]

 > nmap -p 443 --script ssl-enum-ciphers secureroot.co.kr

점검결과 - 양호

점검결과, 보안강도가 높은 알고리즘(A)를 사용하고 있기 때문에 "양호" 하다.

➰ 취약한 HTTPS 컴포넌트 사용

취약한 HTTPS 확장 모듈 사용 시 암호화된 정보 노출 등의 위협이 존재하기 때문에 이에 대한 취약점 존재 유무를 점검한다.

취약한 OpenSSL 버전을 사용할 경우 HTTPS 관련 주요 취약점들을 가지고 있을 수 있으며 이러한 취약점이 발견될 경우 암호화된 정보의 노출 위험성이 존재한다.

📍 취약한 컴포넌트 종류

  • CVE-2014-0160 : OpenSSL의 라이브러리에 버그가 존재하여 서버내 중요 메모리 데이터가 노출될 수 있는 취약점
  • CVE-2014-0224 : OpenSSL 통신 상의 CCS(ChangeCipherSpec)메시지 처리과정 중 취약점이 있어 암호화된 정보의 노출 및 변조 가능성이 존재하는 취약점

➿ 점검방법

  • Heartbleed, CCS-Injection, POODLE 취약점에 대해 점검한다.

1) HeartBleed(CVE-2014-0160)

> nmap -p [port] --script ssl-heartbleed [target_host]
> nmap -p 443 --script ssl-heartbleed naver.com

2) CCS-Injection(CVE-2014-0224)

> nmap -p [port] --script ssl-ccs-injection [target_host]
> nmap -p 443 --script ssl-ccs-injection naver.com

3) Poodle Attack(CVE-2014-3566)

> nmap -p [port] --script ssl-poodle [target_host]
> nmap -p 443 --script ssl-poodle naver.com

점검결과

🌱 취약하지 않은 경우
=> 아래와 같이 포트번호만 나온다.

💊 취약한경우

=> 취약한 경우, 다음과 같은 형식으로 출력된다.

=> 취약점 점검 결과는 https://nmap.org/nsedoc/scripts/ssl-heartbleed.html를 참고하였다.

➰ 취약한 HTTPS 재협상 허용

암호화된 통신내용이 노출될 가능성이 존재하는 취약한 방식의 HTTPS 재협상(Renegotiation) 허용 여부를 점검한다.

🌱 HTTPS 재협상이란?
HTTPS(SSL/TLS) 재협상이란 기존 보안 세션 내에서 다시 핸드쉐이크를 진행함으로써 새로운 세션을 맺는 것을 뜻한다.
처음에 HTTPS 연결이 설정될 때, 클라이언트와 서버는 서로 지원하는 암호화 알고리즘, 키 교환 방식, 인증서 등을 협상하여 사용한다.
재협상은 이러한 매개변수를 다시 협상하는 과정이다. 이는 주로 보안 강화 또는 연결이 장기화된 경우 암호화 키를 갱신하기 위해 사용될 수 있다.

OpenSSL 1.1.1 미만 버전에 대한 취약점으로 Insecure Client-Initiated 재협상을 통해 서버 측의 자원을 소모하도록 유도하여 DoS를 유발할 수 있는 취약점이다.

➿ 점검방법

openssl의 최신버전에서 지원하지 않고 0.9.8k 버전 이하에서 지원하므로 만약 해당 항목을 진단할 경우 openssl 0.9.8k 이하의 버전을 사용해 테스트 해야한다.

  1. OpenSSL을 활용하여 점검 대상에 HTTPS 연결을 시도한다.
> openssl s_client -connect [target_host:port]

> openssl s_client -connect secureroot.co.kr:443
  1. 연결 후 “R”을 입력하여 재협상 시도하여 재협상 여부를 점검한다.
> R

점검결과

🌱 양호한 경우
재협상이 허용되지 않는 경우 아래와 같이 에러가 발생한다.

💊 취약한 경우
취약한 경우 다음과 같은 형식으로 출력된다.

➰ 점검 후기

https 관련 취약점의 경우, 명령어만 알면 쉽게 확인할 수 있는 취약점이다. 하지만 어떠한 프로토콜과 버전을 사용하였는지에 따라서 취약점으로 잡아야 하는지 고민이 많았다. 취약한 버전의 SSL을 사용했을 경우 당연하게 취약점으로 잡아야 한다.
이 경우, 알려져 있는 취약점이 많기 때문에 대부분 SSL 을 사용하지 않는다. 그래서 TLS 를 사용하는데 최근 TLS 1.0 버전에서도 취약한 부분이 발견되었다. 1.0 버전을 사용한 부분이 있을 경우 필자는 취약점으로 잡았지만 각 사이트 마다 취약점으로 받아들이는 부분이 있었고 받아들이지 않는 사이트가 있었다. 그래서 결론은 TLS 1.0도 완벽하게 안전하지 않으므로 1.1 버전부터 사용하는 것을 권장한다. 그렇다고 TLS 1.0 이 안전하지 않은 것은 아니다.

➰ 참고

profile
Cloud Engineer & BackEnd Developer

0개의 댓글