SSL/TLS 검사 및 브라우저 중간자 공격

현재 HTTPS는 Malware 다운로드, 명령 및 제어 채널, 데이터 유출을 포함한 Web 트래픽의 90% 이상을 차지합니다. TLS를 검사할 수 없는 경계 Security 도구는 암호화된 데이터 덩어리만 볼 수 있어 공격자가 적극적으로 악용하는 사각지대가 생깁니다. SSL/TLS 검사(SSL 가로채기, SSL 범핑 또는 HTTPS에 대한 심층 패킷 검사라고도 함)를 사용하면 Security Gateway가 HTTPS 트래픽을 엔드포인트에 도달하기 전에 복호화하고 검사한 다음 다시 암호화할 수 있습니다. 대부분의 트래픽이 HTTPS인 환경에서 이러한 가시성은 Web 콘텐츠 필터링, DLP, 안티 Malware 검사에 필수적입니다.

SSL 검사는 조직 자체의 Security 인프라가 수행하는 통제된 중간자 공격입니다. 과정은 다음과 같습니다. 1단계: Client가 회사 CA가 서명한 Proxy의 Certificate를 사용하여 Proxy와 TLS를 설정합니다. 2단계: Proxy가 Server의 실제 Certificate를 사용하여 실제 Server와 별도의 TLS 세션을 설정합니다. 3단계: Proxy가 Client에서 오는 트래픽을 복호화하고 검사한 후 다시 암호화하여 Server로 전달합니다(반대 방향도 동일함). 모든 관리되는 엔드포인트에 MDM 또는 Group Policy를 통해 회사 CA Certificate가 미리 설치되어 있으므로 Client는 Proxy의 Certificate를 신뢰합니다.

모든 트래픽을 검사해야 하는 것은 아닙니다. 조직은 일반적으로 법적 또는 윤리적으로 민감한 데이터를 전송하는 범주를 제외합니다. 여기에는 Banking 및 Financial 사이트, Healthcare 포털, 법률 연구 데이터베이스, Certificate 투명성 및 OCSP URL(Certificate 검증 중단을 방지하기 위해), Certificate 고정을 사용하는 사이트(다시 서명된 Certificate를 거부하여 애플리케이션이 중단됨)가 포함됩니다. 예외는 검사 Policy의 우회 목록으로 관리합니다. 일부 관할권에서는 직원 모니터링 법률에 따라 개인 Web 탐색 검사가 제한될 수 있으므로, 허용 가능한 사용 Policy에 이를 명확히 공개해야 합니다.

Certificate 고정은 애플리케이션이 특정 Server에 사용할 예상 Certificate 또는 공개 키를 코드에 하드코딩하고, 해당 Certificate가 유효하며 OS의 CA 저장소가 신뢰하더라도 일치하지 않으면 연결을 거부하는 기법입니다. Proxy가 다시 서명한 Certificate는 고정된 값과 일치하지 않으므로 SSL 검사가 중단됩니다. 모바일 애플리케이션(Banking 애플리케이션, 결제 애플리케이션)은 중간자 공격을 방지하기 위해 Certificate 고정을 자주 사용합니다. Enterprise는 고정된 애플리케이션에 대해 검사를 우회해야 하며, 그렇지 않으면 애플리케이션이 작동하지 않습니다. 이는 SSL 검사를 회피하려는 공격자가 Malware에 고정을 구현할 수도 있다는 의미이기도 합니다.

SSL 스트리핑은 공격자가 HTTPS 트래픽을 가로채 HTTP로 강등하여 Content를 평문으로 읽고 수정할 수 있게 하는 중간자 공격입니다. 이 공격은 HTTPS로 Redirect되기 전에 HTTP로 시작하는 연결에서 작동합니다. 공격자는 최초 HTTP Request를 가로채고, 피해자와는 HTTP 연결을 유지하면서 정상 Server와는 HTTPS 연결을 설정한 뒤 트래픽을 투명하게 중계합니다. 피해자에게는 사이트가 HTTP로 표시됩니다. HTTP Strict Transport Security(HSTS)는 사용자가 HTTP를 입력하더라도 Browser에 해당 도메인에서 항상 HTTPS를 사용하도록 지시하여 SSL 스트리핑을 방어합니다.

Browser 내 중간자(Man-in-the-Browser, MitB) 공격은 Banking 트로이 목마의 한 형태로, 악성 확장 프로그램 또는 Browser 프로세스 삽입을 통해 Web Browser 내부에 침투한 후 사용자가 알아차리지 못하는 사이에 Web 페이지와 거래를 수정합니다. 네트워크 중간자 공격과 달리 MitB는 암호화된 세션의 내부, 즉 Browser 계층에서 작동하므로 TLS가 보호 기능을 제공하지 못합니다. MitB Malware(Zeus, SpyEye)는 결제 금액 변경, 수취인 계좌 번호 변경, 일회용 비밀번호 탈취, 사용자가 양식을 작성한 후 양식 내용을 조용히 수정하는 등의 작업을 수행할 수 있습니다. 이러한 수정은 TLS 복호화가 끝난 후, 사용자가 렌더링된 페이지를 보기 전에 이루어집니다.

MitB 악성 코드는 애플리케이션 계층에서 브라우저 API에 후킹합니다. Windows에서는 DLL 주입 또는 COM 하이재킹을 사용해 브라우저 프로세스(Chrome, Firefox, IE)에 코드를 주입한 다음, JavaScript 함수와 DOM 조작 API에 후킹합니다. 사용자가 은행 사이트를 방문하면 악성 코드가 페이지와 거래 확인 화면을 렌더링하는 JavaScript를 가로채 수취 계좌를 공격자의 계좌로 바꿉니다. 서버는 올바른 거래를 확인하므로 서버 측 HTTPS 기록에는 특이 사항이 나타나지 않습니다. 사용자는 자신이 의도한 금액이 표시된 올바른 확인 화면을 보지만, 실제 이체는 공격자의 계좌로 이루어집니다.

MitB를 방어하려면 여러 계층의 통제 수단이 필요합니다. 브라우저 격리(Menlo Security, Zscaler Browser Isolation)는 원격 클라우드 VM에서 브라우저 렌더링을 실행하고 사용자의 화면에는 픽셀만 스트리밍하므로, 악성 코드가 원격 환경에서 실행 중인 브라우저 프로세스에 주입될 수 없습니다. 거래 검증: 은행은 대역 외 채널(거래 세부 정보가 포함된 SMS OTP 등)을 통해 거래 정보(금액 + 수취인)를 확인하므로, 사용자는 서버가 실제로 받은 내용을 검증해야 합니다. 브라우저 프로세스에 대한 DLL 주입을 탐지하는 엔드포인트 EDR은 MitB 감염을 식별할 수 있습니다. 브라우저 확장 프로그램 허용 목록을 사용하면 악성 확장 프로그램을 차단할 수 있습니다.

악성 브라우저 확장 프로그램은 중요한 단말 위협입니다. 확장 프로그램은 광범위한 권한을 가지므로 페이지 내용을 읽고, 요청을 수정하고, 양식 제출을 가로채고, 쿠키에 접근할 수 있습니다. 유용한 도구(광고 차단기, 다크 모드)로 위장한 확장 프로그램은 자격 증명을 수집하거나, 광고를 삽입하거나, 트래픽을 리디렉션하거나, MitB 에이전트로 동작할 수 있습니다. 기업 통제: Group Policy 또는 MDM을 사용해 확장 프로그램 설치를 승인된 허용 목록으로 제한하십시오. Chrome 웹 스토어 또는 Firefox Add-ons 이외의 출처에서 확장 프로그램을 설치하지 못하도록 차단하십시오. 관리되는 단말에 설치된 확장 프로그램을 정기적으로 감사하여 정책 위반 여부를 확인하십시오.

SSL 검사를 구현하는 조직은 직원에 대한 개인정보 보호 영향을 해결해야 합니다. 많은 관할권과 고용 관련 법률에서는 암호화된 트래픽을 모니터링하기 전에 명확한 고지를 요구합니다. 모범 사례는 다음과 같습니다. HTTPS를 포함한 네트워크 트래픽을 검사할 수 있음을 명시한 Acceptable Use Policy (AUP)를 게시하고, 입사 절차 중 직원이 AUP를 확인하도록 하며, 개인 은행 업무 및 의료 사이트에는 우회 범주를 적용하고, 복호화된 트래픽 기록은 필요한 기간 동안만(일반적으로 30~90일) 보관하십시오. 특히 GDPR이 직원 모니터링에 더 엄격한 제한을 두는 EU 국가에서는 배포 전에 법률 자문을 통해 검사 프로그램을 검토해야 합니다.

Certificate Transparency는 공개적으로 신뢰되는 모든 TLS 인증서를 브라우저가 신뢰하기 전에 공개적으로 감사할 수 있고 추가만 가능한 CT 로그에 기록하도록 요구하는 프레임워크(RFC 6962)입니다. CT를 사용하면 도메인 소유자가 잘못 발급된 인증서를 모니터링할 수 있습니다. 공격자가 어떤 방법으로든 CA를 설득해 해당 도메인의 인증서를 발급받더라도(2011년 DigiNotar에서 발생한 사례처럼), CT 로그를 통해 거의 실시간으로 탐지할 수 있습니다. crt.sh와 같은 도구를 사용하면 보안 팀이 해당 도메인에 발급된 모든 인증서를 CT 로그에서 검색할 수 있습니다. 브라우저는 TLS 핸드셰이크에 포함된 로그 포함 증명(Signed Certificate Timestamps, SCTs)을 요구하는 방식으로 CT를 적용합니다.

이 단원에서는 다음을 배웠습니다. SSL/TLS 검사는 관리되는 단말이 신뢰하는 기업 CA 인증서를 사용해 프록시에서 HTTPS 트래픽을 복호화하고, 검사한 후 다시 암호화합니다. SSL 스트리핑은 HTTPS를 HTTP로 낮추며 HSTS로 방어할 수 있습니다. 또한 브라우저 내부자 공격은 TLS 계층 위의 브라우저 프로세스에 주입되어 거래를 보이지 않게 수정하므로, 브라우저 격리 또는 대역 외 거래 검증으로 방어해야 합니다. 다음 단원에서는 안전하지 않은 프로토콜을 이에 대응하는 안전한 프로토콜로 교체하는 방법을 살펴보겠습니다.