ssl certificates

MK·2024년 2월 6일

인증서 없는 암호 통신의 문제
ssl을 이용하여 통신을 암호화하기 위해선 암호화에 사용할 공개키가 필요하다.
근데, 인증서 없이 공개키 암호를 사용한다면..? MITM 공격에 취약진다

  • MITM :
    중간자가 통신 대상의 공개키가 아닌 자신의 공개키로 바꿔치기할 수 있다. 이를 통해 중간자는 암호화 통신을 복호화할 수 있다.

인증서를 통한 MITM 해결
인증서는 Trusted CA로부터 발급받으며, 중간자가 공격을 성공하기 위해선 CA로부터 발급받은 인증서를 제시해야 한다.

인증서는 말 그대로 신뢰기관 CA에서 해당 호스트에 부여한 인증 마크라고 생각하면 되겠다.

"나는 신뢰기관(CA)이며, 너가 지금 통신하려는 A는 중간자가 아니고, A가 맞다는 것을 내가 보증하니 안심해라"


인증서가 포함하는 정보
인증서엔 다음과 같은 정보가 포함된다.

  • 발급된 대상 도메인
  • 발급받은 사람, 조직, 장치
  • 인증기관과 디지털 서명
  • 발급 날짜와 만료 날짜
  • 공개키

도메인이 자신의 소유임을 입증하여야 CA에서 인증해준다.


브라우저의 인증서 활용
브라우저는 인증서의 만료기간, Trusted CA 발급 여부, 도메인과 호스트네임의 일치 여부를 확인한다.

브라우저는 신뢰기관 리스트를 가지고 있으며, 인증서 확인 후 발급자가 신뢰기관이 아닐 경우(self signed인 경우) https임에도 안전하지 않은 것으로 간주한다.


인증서 예시

[ 검색 대상 도메인 ]

[ 인증서 정보 ]
Fingerprint : 인증서 핑거프린트
Subject : 발급받은 자 정보
Issuer : 발급자 정보


[ 실제 도메인과 인증서의 Subject CN이 일치하지 않는 경우 ]


인증서 취소

CA는 침해당한 시스템의 도메인에 대해 인증서를 취소할 의무를 가진다.
그러나 self-signed 인증서는 CA 에서 발급하지 않았으므로, 취소되지 않아 악의적 행위에 많이 사용된다.
Let's Encrypt에서 발급한 Free Certificate 또한 Let's Encrypt 측에서 취소시켜주지 않아 논란임


The State of SSL/TLS Certificate Usage in Malware C&C Communications (TrendMicro)

https://www.trendmicro.com/content/dam/trendmicro/global/en/research/21/i/ssl-tls-technical-brief/ssl-tls-technical-brief.pdf

멀웨어와 C2 서버간 통신에 사용되는 TLS 인증서에 관한 보고서이다.

May 2019 ~ June 2021 기간동안 264 malware families 의 ssl/tls 통신 현황

ip.tcp : 8 (3%)
ip.tcp.http : 177 (67%)
ip.tcp.smtp : 79 (~30%)

  • http : 공격자 웹서버에 직접 연결하거나, Discord, Telegram, Slack, Pastebin, and GitHub REST API 이용
  • legitimate 통신과 완벽하게 융화하기 때문임.
  • smtp를 이용한 data exfiltration도 존재했으며, gmail이 가장 많이 이용됨

인증서 CA

  • Sectigo SSL,DigiCert SSL, Symantec SSL, RapidSSL, GeoTrust SSL, Thawte SSL, ZeroSSL or Let’s Encrypt
  • Let's Encrypt와 ZeroSSL 이외에는 모두 발급 비용이 요구됨
  • free certificate는 90 days 만 유효함.

Abuse.ch의 SSLBL는 봇넷과 C2 서버에서 사용한 악성 tls certificate 를 탐지하는 목적의 프로젝트임.

AsyncRAT, QuasarRAT 관련이 다수.

해당 데이터 분석 결과,
1,067 (~60.4%) of 1,767 가 self-signed certificate 였으며,
1,067 중 96 은 x.509 버전 1 사용
1,067 중 982 은 x.509 버전 3 사용


malware family 마다 특정 CN을 사용하는 것을 발견

OpenSSL에서 default certificate 를 생성할 때, "C=AU, ST=Some-State, O=Internet Widgits Pty Ltd" 와 "C=XX,
L=Default City, O=Default Company Ltd" 는 default 값이다.

인증서 유효기간이 “2015-11-19 14:51” to “1979-09-19 9:23” 인 경우도 있었는데, openssl은 인증서 유효기간 설정 시 음수값을 지원하지 않으므로, 바이너리단에서 수정된 것으로 볼 수 있으며, 이처럼 유효기간이 비정상인 인증서는 모니터링할 필요가 있다.

시리얼 넘버의 길이도 제각각인데, 90000개의 WordPress 사이트 중 시리얼 넘버가 8바이트 이하인 trusted certificate는 없었다.
너무 짧은 길이의 시리얼 넘버를 가지는 certificate도 주시할 필요가 있다.

AsyncRAT

  • malware가 실행될 때, 내장된 인증서의 public key 의 전자서명을 하드코딩된 해시값과 비교하여, 검증에 실패할 시 실행을 종료한다.
  • 서버와의 통신이 성립되고, 서버의 인증서를 받아왔을 때, 내장된 인증서와 비교하여 같지 않으면 실행을 종료한다.

멀웨어 입장에서 보면, 통신하는 서버가 중간자가 아닌 진짜 c2서버 임을 인증하기 위해 certificate pinning을 함. 즉, 멀웨어가 신뢰하는 self-signed certificate 를 하드코딩하고, 서버와 통신 시 인증서를 비교하여 검증하는 절차를 수행함.

정리하자면, 여러 c2 서버는 self-signed 인증서, 또는 trusted 인증서를 사용함.
trusted 인증서를 사용함으로써 legitimate 트래픽에 쉽게 융화될 수 있음
고유 값을 갖는 자체 서명 인증서는 탐지가 쉽다 (AsyncRAT 등)
인증서 피닝을 사용하여 중간자 공격을 방지하기도 함.


SSL/TLS without HTTPS
HTTPS 가 아닌데 SSL/TLS (and pre-shared key instead of x.509 key exchange) 를 사용한다면 주시되어야 한다.

또한 Delayed Client Hello 또한 주시되어야 한다.
3 way handshake 이후 바로 clienthello가 오는게 정상인데,
3 way handshake -> malicious payload download -> X.509 Key Exchange 순으로 진행되는 경우 의심해봐야 한다.

profile
computer security

0개의 댓글