본문 바로가기
3. 웹 애플리케이션 취약점 진단

취약한 HTTPS 취약점 진단하기

by Robert8478 2024. 7. 17.

개요

요즘 대부분의 웹 사이트는 전부 HTTP가 아닌 HTTPS를 기본으로 사용하고 있다. 그렇기 때문에 데이터 평문 전송 등의 취약점은 자주 나오지 않는 편인데 HTTPS 통신을 사용한다고 하더라도 이와 관련된 취약점들이 또 존재한다.

대표적으로 현재는 취약한 것으로 알려진 SSL 3.0이나 TLS 1.0, 1.1 등의 버전을 사용하는 것, 취약한 암호 알고리즘을 이용하는 것 등의 취약점이 존재하고 있는데 아래에서 자세히 진단해보겠다.

 

취약한 HTTPS 프로토콜 사용

SSL 2.0, 3.0, TLS 1.0, 1.1 등의 취약한 버전 암호 프로토콜을 사용하면 해당 항목에 취약점이 존재한다고 볼 수 있다. 위 버전들은 기본적으로 현재는 사용해서는 안되는 취약한 버전의 프로토콜이며, 해당 프로토콜을 서버에서 지원 시 암호화된 내용이 복호화되거나 버전 자체의 취약점이 악용되는 등의 공격이 발생할 수 있다.

모 사이트에 대한 진단을 해본 결과 TLS 1.0, 1.1 버전을 지원하고 있는 것을 확인할 수 있었다. 공격자들은 이러한 정보를 쉽게 얻을 수 있으며 해당 버전의 취약점을 활용한 공격을 시도할 수 있다.

위 취약점의 진단 방법은 아래와 같다.

 1. nmap을 이용한 HTTPS 프로토콜 확인

nmap -p [port] --script ssl-enum-ciphers [target_host]

nmap -p 443 --script ssl-enum-ciphers target.co.kr

 

2. openssl을 이용한 HTTPS 프로토콜 확인

openssl s_client -ssl3 -connect [target_host:port]

openssl s_client -ssl3 -connect target.co.kr:443

 

이에 대한 조치 방안으로는 가장 안전하다고 알려진 TLS 1.2 버전만 지원하도록 하고 무엇보다 가장 위험한 SSL 2.0, SSL3.0 버전을 지원하는 경우 POODLE 취약점 등이 존재하므로 반드시 이를 사용하지 않도록 구성해야 한다.

 

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

보안 강도가 낮은 암호 알고리즘을 사용하게 되면 공격자에 의해 암호화 내용이 복호화 될 우려가 존재한다. 취약한 암호 알고리즘이라고 해서 복호화가 쉬운 것은 아니지만, 공격의 가능성이 열린다는 측면에서 이러한 취약점 또한 보완하는 것이 권고된다.

해당 취약성의 진단은 아래와 같은 방법을 이용한다.

1. nmap을 이용한 HTTPS 암호 알고리즘 확인

nmap -p [port] --script ssl-enum-ciphers [target_host]

nmap -p 443 --script ssl-enum-ciphers target.co.kr

명령어를 수행하면 이렇게 출력이 되는데 warnings 란에서 SWEET32와 같은 잠재적 CVE 취약성이 존재함을 확인할 수 있고 ciphers에는 각각의 암호 알고리즘과 동시에 알파벳이 붙는데 이 알파벳이 의미하는 바는 아래와 같다.

  • A (Authentication):
    • 인증 메커니즘에 취약할 수 있다는 의미로 서버 인증 절차에서의 취약점이나 암호화 키의 불충분한 길이 등이 존재함을 의미
  • C (Confidentiality):
    • 기밀성에 취약할 수 있다는 의미로 암호화 알고리즘 자체의 안전성 문제나, 암호화 키 관리의 취약점 등이 존재할 수 있음을 의미
  • E (Encryption):
    • 인증과 기밀성(A,C) 모두에 대한 취약성이 존재할 수 있다는 의미로, 암호화 알고리즘 전체적인 안전성과 관련이 있으며, 공격자가 메시지의 암호화된 내용을 해독할 수 있음

 

이에 대한 대응방안으로 아래의 3가지 방안을 적용할 수 있다.

  1. 112비트 미만의 키 길이를 사용하는 암호 알고리즘, Anonymous Diffie-Hellman(ADH), NULL 암호화, Export 키 교환 방식의 사용을 중단
  2. 암호 알고리즘 협상 시, 서버에서 선호하는 Server’s preference 암호화 알고리즘을 사용하도록 웹서버 환경 설정을 수정
  3. 웹 애플리케이션 방화벽 설정을 점검

 

취약한 HTTPS 컴포넌트 사용

취약한 HTTPS 확장 모듈을 사용하는 지 여부를 진단하게 되며 이에 취약할 시 CVE 기반 공격 등을 받아 정보 노출 등의 위협이 존재할 수 있다.

취약한 HTTPS 컴포넌트 사용으로 인해 발생 가능한 대표적인 CVE 취약점은 아래와 같다.

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

이러한 취약점을 진단할 수 있는 방법은 아래에 정리해두었다.

 

1. nmap을 이용한 취약한 HTTPS 컴포넌트 사용 여부 확인

  • HeartBleed(CVE-2014-0160)

nmap -p [port] --script ssl-heartbleed [target_host]

  • CCS-Injection(CVE-2014-0224)

nmap -p [port] --script ssl-ccs-injection [target_host]

  • Poodle Attack(CVE-2014-3566)

nmap -p [port] --script ssl-poodle [target_host]

 

추가적으로, 본인은 HSTS 취약점(Https 사이트에서 Http 프로토콜 요청 시 HSTS 기능이 미흡하여 Https로 강제 리턴이 되지 않는 경우)이 존재하는 경우 해당 취약점으로 진단을 하기도 한다.

예를 들면 로그인 페이지에서 프로토콜을 http로 변조 후 http로 로그인이 가능하게 된다면 WireShark 등으로 패킷을 스니핑하면 로그인한 계정 정보가 그대로 평문으로 노출될 것이다.

이에 대한 대응방안으로는 하기의 방안 적용을 권장한다.

  1. 웹 애플리케이션 방화벽 설정 변경
  2. 벤더 사에 문의하여 존재하는 취약점에 대한 보안패치 진행
  3. (HSTS) HSTS 기능 부재 시 웹 서버 설정에서 HSTS 기능을 적용하여 http 요청은 https로 강제로 리다이렉트 시키도록 조치

 

취약한 HTTPS 재협상 허용

기존 HTTPS 연결에서 새로운 암호화 키를 협상하는 과정에서 발생하는 취약점으로, 서버가 취약한 방식의 협상 방식을 사용하고 있다면 암호화된 통신 내용이 노출될 가능성이 존재한다.

HTTPS 재협상(Renegotiation) 방식에는 총 4가지가 존재하는데, 여기서 점검하는 재협상 방식은

Client-initiated insecure renegotiation(CVE-2009-3555) 방식이다.

  • Client-initiated secure renegotiation
  • Client-initiated insecure renegotiation(CVE-2009-3555)
  • Server-initiated secure renegotiation
  • Server-initiated insecure renegotiation

기본적으로 해당 취약점은 일부 환경에서 발생될 수 있는데 이는 다음과 같다.

취약할 수 있는 환경 : TLS 1.0, TLS 1.1, OpenSSL 0.9.8k 이하

 

해당 취약성 검증 방식은 하기와 같으며, openssl 0.9.8k 이하 버전을 설치하여 진단해야 한다.

 

1. openssl(0.9.8k 이하)을 이용한 취약한 HTTPS 재협상 허용 여부 확인

openssl s_client -connect [target_host:port]

openssl s_client -connect target.co.kr:443

위 명령어 입력 시 이런 상태가 출력되는데 여기서 R 을 입력하고 엔터친다.

최종 결과값에서 위 사진과 같이 에러가 발생하면 양호한 것으로 볼 수 있으며, 정상적인 재협상이 가능한 경우 취약점이 존재하는 것으로 볼 수 있다.

이에 대한 대응 방안은 하기의 방안을 적용할 수 있다.

  1. 설정 파일 내 RenegotiationLevel “secure” 설정 값을 적용
  2. (위 설정이 불가한 경우) 웹 서버 별 해당 취약점의 대응 방안으로 지정된 설정 값을 적용