인증서 없는 암호 통신의 문제
ssl을 이용하여 통신을 암호화하기 위해선 암호화에 사용할 공개키가 필요하다.
근데, 인증서 없이 공개키 암호를 사용한다면..? 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 측에서 취소시켜주지 않아 논란임
멀웨어와 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%)
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
멀웨어 입장에서 보면, 통신하는 서버가 중간자가 아닌 진짜 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 순으로 진행되는 경우 의심해봐야 한다.