최근 수정 시각 : 2024-08-09 19:16:33

중간자 공격

MITM에서 넘어옴
파일:man_in_the_middle_attack.gif
1. 개요2. 수법3. 실제 악용 사례4. 방어5. 기타

[clearfix]

1. 개요

Man In the Middle attack, MITM

두 사람이 서로 통신을 주고 받는데, 중간에 제 3의 인물이 끼어서 데이터를 중계한다면, 이 제3자는 그 내용을 모두 알 수 있고, 데이터를 위/변조할 경우 두 사람에게 서로 잘못된 정보를 전달하게 만들 수도 있다.
고전 유머

보안관이 용의자를 검거하고 심문하는데, 말이 안 통하여 통역사를 불렀다.

보안관: 네가 은행을 털었지? 순순히 돈 숨긴 곳을 불면 목숨은 살려주마.
통역사: (잘 번역하여 용의자에게 전달)

용의자: 잘못했어요. 살려주세요. 돈은 저희 집의 앞마당에 묻어 놨습니다.
통역사: 이놈이 글쎄, 보안관님은 총도 못쏘는 바보 얼간이라는군요. 자기는 겁 안 나니 쏠 테면 빨리 쏴보라네요.
1박 2일의 예시

2. 수법

  • 지나가는 패킷을 모두 감청하여 ID / 패스워드 / 공인인증서 등 중요 개인정보를 훔쳐 볼 수 있다.
  • DNS 정보 등을 위조하여 피싱 사이트로 연결되도록 속일 수 있다.
  • 암호 키 교환에 개입하여 암호화에 사용되는 키를 빼낼 수 있다.

3. 실제 악용 사례

4. 방어

이 공격법을 방어하기 위한 목적으로 만들어진 것이 TLS 통신이다. TLS 통신은 클라이언트가 연결을 요청하면 서버에서 자신의 공개키가 포함된 인증서를 보내고, 클라이언트는 인증서의 내용을 연결 프로그램(웹 브라우저 등) 또는 운영체제에 내장된 루트 인증서 정보와 비교하여 무결성을 검증한 뒤, 대칭형 암호화 키를 만들 수 있는 난수 정보를 인증서에 있는 공개키로 암호화해 서버로 보내며, 클라이언트와 서버가 각각 이 난수에서 암호화 키를 만들어내 암호화 연결이 개시된다.

여기서 중요한 점은 루트 인증서를 신뢰할 수 있어야 한다는 것이다. 보안성이 충분이 보장되지 않았거나, 내부적으로 악용할 가능성이 있거나 하는 루트 인증서는 허용해서는 안 된다. 한국의 GPKI(행정전자서명) 인증서는 보안성을 검증받지 못해 파이어폭스의 자체 루트 인증서 저장소에 탑재되지 못했는데, 마이크로소프트는 정부기관이라는 이유로 보안성 검증 없이 윈도우의 루트 인증서 저장소에 GPKI 루트 인증서를 넣었다. 이 때문에 윈도우에서 크롬, IE, 엣지 등의 브라우저는 GPKI 인증서를 사용하는 사이트에 접속할 수 있지만 파이어폭스는 HTTPS 인증을 실패해서 접속할 수 없다.

윈도우에는 마찬가지로 파이어폭스 등에서 탑재를 거부한 중국 정부의 루트 인증서 역시 탑재되어 있으며, 이렇게 보안성 검증 없이 신뢰되는 인증서는 매우 큰 통신 보안 위협이 된다.

종단간 암호화를 지원하는 보안 메신저에는 중간자 공격을 방어하기 위해 상대방의 RSA키를 서로 검증하는 시스템을 가지고 있다. 검증 후 상대방의 키가 갑자기 바뀐다면 해킹으로 간주되고 사용자에게 알린다.

TLS 통신이 모든 정보를 중간자로부터 숨겨주는 것은 아니다. IP 주소는 네트워크의 원리상 절대 숨기지 못하며, TLS 1.3 버전 기준으로는 접속하는 웹사이트의 도메인 이름(SNI 필드) 역시 숨겨주지 못한다. 이 정보들이 노출된다고 해서 비밀번호와 같은 민감정보까지 노출되는 것은 아니지만, 도메인 이름은 사용자 식별이나 인터넷 검열로 악용될 수 있으며, 이에 따라 도메인 이름까지 TLS의 보호 범위에 포함시키는 ECH (Encrypted Client Hello) 기능의 도입과 표준화가 논의되고 있다.

5. 기타

입자의 하나인 중간자(中間子)와는 무관하다. 번역 과정에서 한자음이 겹친 것.

몇몇 백신 또는 광고 차단 소프트웨어[1]들은 이 방식으로 통신 내역을 읽어 광고를 차단한다. 특히 HTTPS 필터링 기능을 사용할 경우 인증서를 신뢰할 것을 요구하는데, 이는 웹사이트 로그인 등 민감한 데이터가 모두 해당 프로그램으로 흘러간다는 뜻이다. 이런 방법은 심각한 보안 위협을 초래할 수 있으며, 가급적 사용하지 않을 것이 권장된다. 광고 차단이 필요하다면 Intra와 같은 DNS 변경 프로그램으로 광고 차단이 지원되는 DNS를 사용하거나, 확장 프로그램이 지원되는 파이어폭스 웹 브라우저 또는 광고 차단이 지원되는 파이어폭스 포커스, Brave, Cromite등을 사용하는 것이 좋다.[2][3] 광고 차단 프로그램에는 보통 바이러스나 맬웨어 유포 사이트도 차단하는 기능이 있다. 미심쩍은 파일을 받지 않는 등 보안 수칙을 지키면 모든 통신정보를 백신에 보내지 않더라도 위협은 현저히 줄어든다.
[1] AdGuard의 (확장 프로그램이 아닌) 윈도우, 안드로이드용 프로그램이라든지, Avast 안티바이러스의 HTTPS Scanning 등[2] 하지만 2022년 현재 대부분의 사용자는 이런 방법을 선호하지 않을 것이다. 광고 차단 기능이 내장된 브라우저나 단순히 광고 차단을 지원하는 DNS를 이용하는 것만으로는 Anti-AdBlock 스크립트에 의해 사이트 열람 자체가 막히는 경우가 부지기수이기 때문. AdGuard 등에 탑재된 Anti-Anti AdBlock 기능으로 광고 없이 사이트를 보기 위해서라도 어쩔 수 없이 사용해야 하는 측면이 있다.[3] 다만 컴퓨터공학과 계열 지식이 있어서 HTTP 송수신 내역을 분석하거나 자바스크립트 코드를 이해할 수 있는 사람은 기존대로 DNS단에서만 차단하는 프로그램을 사용하면서 Anti-AdBlock 스크립트는 수동으로 커트해내는 방법도 있긴 하다. 스크립트 소스가 난독화되지 않았거나 정확한 원인 파일을 규명할 수 있는 경우 개발자도구의 네트워크 단에서 해당 스크립트 파일의 다운로드를 차단해버리거나 Interval ID를 색출해서 ClearInterval 함수를 통해 반복 실행을 해제시키고 페이지를 복구시키면 되며(대부분 경고창 element로 본문 위를 가리게 덮어쓰는 경우가 제일 많고 조금 더 발전된 경우에는 CSS 및 자바스크립트를 통해 컨텐츠를 숨김 처리 하거나 지워버리는 경우가 많은데 덮어쓰는 경우에는 덮는 개체를 개발자도구 element 탭에서 찾아 날려버리면 되고 CSS나 JS로 내용을 망치는 경우에는 소스를 분석하여 display: none;과 같은 문제를 유발하는 속성과 코드를 제거하여 복구하면 된다.) 난독화가 되어 있거나 페이지를 사용하기 위해 필요한 정상적인 기능에 anti-Adblock 스크립트가 섞여 있는 경우에는 위의 방식으로 사이트를 분석하여 복구 스크립트를 짜고 그걸 setInterval로 반복 실행시켜서 anti-Adblock이 페이지를 망쳐 놓으면 곧장 복원시켜서 페이지 사용이 가능하게 만드는 무식한 방법으로 파훼 가능하다. Adblock 경고창이 깜빡거려서 거슬리긴 하지만 어쨌든 백엔드 단에서 페이지 제공을 막지 않는 이상에야 홈페이지 내용은 볼 수 있으니까..

분류