[clearfix]
1. 개요
Man In the Middle attack, MITM / 中間者攻擊두 사람이 서로 통신을 주고 받는데, 중간에 제 3의 인물이 끼어서 데이터를 중계한다면, 이 제3자는 그 내용을 모두 알 수 있고, 데이터를 위/변조할 경우 두 사람에게 서로 잘못된 정보를 전달하게 만들 수도 있다.
| 고전 유머 보안관이 용의자를 검거하고 심문하는데, 말이 안 통하여 통역사를 불렀다. 보안관: 네가 은행을 털었지? 순순히 돈 숨긴 곳을 불면 목숨은 살려주마. 통역사: (잘 번역하여 용의자에게 전달) 용의자: 잘못했어요. 살려주세요. 돈은 저희 집의 앞마당에 묻어 놨습니다. 통역사: 이놈이 글쎄, 보안관님은 총도 못쏘는 바보 얼간이라는군요. 자기는 겁 안 나니 쏠 테면 빨리 쏴보라네요. |
정리하자면 물리적으로든 논리적으로든 두 시스템의 연결 사이에 제3자가 끼어들어가서 둘 사이에 오가는 통신을 가로채거나 변조하는 공격이다. 가장 직관적으로 들 수 있는 대표적인 예시는 두 컴퓨터를 연결한 랜선을 중간에서 뚝 잘라서 해커의 컴퓨터에 꽂아놓은 꼴이지만 중간자 공격의 대상은 물리적인 PC뿐만 아니라 프로그램이 될 수도 있다.
예를들어 어떤 컴퓨터에서 온라인게임을 켠 상황을 상정해보자. 당연히 이 게임은 접속해야 할 게임서버로 접속을 시도하게 될것이다. 이 때 만약 게임을 실행한 유저가 악의적으로 다른 프로그램을 이용해 게임이 보내려던 통신 데이터를 가로채서 다른 엉뚱한 주소로 접속하게 만들거나 통신 내용을 마음대로 변조시켜버릴 수 있는데 이런 경우에도 한 컴퓨터 내에서 프로그램 간에 일어난 일이긴 하지만 공격당한 온라인게임의 입장에선 전형적인 중간자 공격이 된다.
아무튼 이런 상황에 놓이게 되면 당연히 공격자가 피해자들이 주고 받는 데이터를 모조리 훔쳐 볼 수 있는건 고사하고 특정 통신을 차단하거나, 상대가 실제로는 보내지도 않은 통신을 보낼 수도 있는 등등 당하는 입장에선 방어도 매우 어렵고 당하고 있음을 알아채기도 매우 어렵다. 설상가상으로 서로 암호화 통신을 하더라도 첫 통신 중 서로 암호화를 위한 약속[1]을 주고 받는 과정까지 해커가 다 들여다 볼 수 있기에 이마저도 손쉽게 무력화 되어 소용이 없다. 때문에 RSA 암호화처럼 중간자 공격으로부터 안전한 알고리즘이 표준화 되기 전까지 대단히 오랫동안 악명을 떨쳤다.
2. 실제 악용 사례
- 피싱 사이트
- DNS 스푸핑
- DHCP 스푸핑
- ARP 스푸핑
- 암호 알고리즘 - 대칭형 암호 방식은 암호화와 복호화에 사용하는 키가 동일하다. 때문에 해커에게 키가 노출되면 내용을 해독할 수 있게 되므로 중간자 공격을 당할 위험이 있다.
- 럭키패쳐
- 유해사이트 차단 - 2019년 인터넷 검열 사건 이후로는 HTTPS 패킷에도 통신사가 중간자 공격을 시도하여 필터링을 하고 있다.
- 공인 IP 접속대수 감시 - 현재는 HTTPS 패킷에도 적용되고 있다.
3. 방어
이 공격법을 방어하기 위한 목적으로 만들어진 것이 TLS 통신이다. TLS 통신은 처음 연결 시에 암호화에 쓰는 키와 복호화에 쓰는 키가 서로 다른 비대칭 암호 알고리즘을 이용한다. 즉 암호화 키가 노출되더라도 복호화 키는 노출이 되지 않아 해커가 중간자 공격을 하더라도 데이터를 해독할 수 없게 만드는 것이 핵심인 것이다.상세한 내용은 TLS 문서를 참조하면 되지만 대략적인 동작 방식을 정리하자면 아래와 같다.
1. 클라이언트가 서버로 연결을 요청한다.
2. 서버는 자신의 공개키(암호화 키)를 포함한 인증서라는걸 보내준다.
3. 클라이언트는 서버가 보내준 내용을 자신이 갖고 있는 인증서 정보와 비교해 상대 서버의 신분을 검증한다.[2]
4. 클라이언트는 자신과 통신할 임의의 대칭형 암호화 키를 생성한다음 서버의 공개키를 이용해 암호화 시켜서 서버로 보내준다.[3]
5. 서버는 인증서의 공개키에 대응하는 비밀키를 알고 있으므로 클라이언트가 보낸 암호화 키를 해독할 수 있다. 이제 클라이언트가 준 암호화 키로 대칭형 암호화 통신을 시작한다.
6. 이 연결 수립 과정의 모든 부분에서 서버의 복호화 키와 클라이언트의 대칭형 암호 키가 전혀 노출 되지 않았기에 중간자 공격으로도 통신 내용을 해독할 방법이 없다.[4]
여기서 중요한 점은 루트 인증서를 신뢰할 수 있어야 한다는 것이다. 보안성이 충분이 보장되지 않았거나, 내부적으로 악용할 가능성이 있거나 하는 루트 인증서는 비밀키가 노출될 위험이 크고 비밀키가 노출되어 버리면 비대칭 암호화의 이점이 모조리 사라지게 되므로 절대로 허용해서는 안 된다는 약점이 있다.
일반적인 응용 프로그램 수준에서는 그냥 공개키와 비밀키를 임의로 만들어서 써도 된다. 그러나 많은 사람들이 임의의 웹서버에 접속하는데 사용되는 웹브라우저 같은 프로그램에 탑재되는 인증서들은 해당 웹사이트와의 통신이 중간자 공격을 당할 수 있느냐 없느냐의 아주 중대한 문제가 되므로 일반적으로 발급이 아주아주 까다롭다. 그러나 마이크로소프트나 구글이 온 세상에 있는 사이트의 인증서를 발급하고 관리할 수는 없는 노릇이므로 아예 이걸 전문적으로 관리하는 신뢰할 수 있는 기업들만이 TLS 인증서를 발급할 권리를 위탁 받는다.
한국의 GPKI(행정전자서명) 인증서는 보안성을 검증받지 못해 파이어폭스의 자체 루트 인증서 저장소에 탑재되지 못했는데, 마이크로소프트는 정부기관이라는 이유로 보안성 검증 없이 윈도우의 루트 인증서 저장소에 GPKI 루트 인증서를 넣었다. 이러면 정부기관이 해당 인증서의 비밀키를 알고 있다는 것이 되므로 보안사고에 의해 해커가 비밀키를 획득하거나 정부기관이 해당 인증서를 사용하는 통신의 감찰을 시도하게 되면 얄짤없이 중간자 공격이 가능해진다. 이 때문에 윈도우에서 크롬, IE, 엣지 등의 브라우저는 GPKI 인증서를 사용하는 사이트에 접속할 수 있지만 파이어폭스는 HTTPS 인증을 실패해서 접속할 수 없다.
윈도우에는 마찬가지로 파이어폭스 등에서 탑재를 거부한 중국 정부의 루트 인증서 역시 탑재되어 있으며, 이러면 위와 마찬가지로 TLS 연결을 하더라도 중국 정부가 중간에서 내용을 해독할 수 있게 되어 암호화의 의미가 사라지고 황금방패와 같은 국가 수준의 인터넷 검열에 악용되게 된다. 이것은 생각보다 정말로 치명적인데 중간자 공격은 둘째 치고 국가간 인터넷망에서 중국 정부의 루트 인증서를 이용한 복호화가 되지 않을 경우 연결을 강제로 차단해버린다면 중국 내의 모든 웹서버들이 무조건적으로 중국 정부의 루트 인증서를 사용할 것을 손쉽게 강제할 수 있고 해외 연결조차도 큰 노력 안들이고 감시를 할 수 있게 된다.
종단간 암호화를 지원하는 보안 메신저에는 중간자 공격을 방어하기 위해 상대방의 RSA키를 서로 검증하는 시스템을 가지고 있다. 검증 후 상대방의 키가 갑자기 바뀐다면 해킹으로 간주되고 사용자에게 알린다.
TLS는 OSI 모형의 5 ~ 7계층 수준에서 작동하는 표준이다. 따라서 TLS 통신을 한다해도 이보다 낮은 계층에서 작동하는 송신자 IP 주소와 수신자 IP 주소, 그리고 TCP 포트 같은 정보는 당연히 암호화가 적용되지 않으므로 노출 될 수 밖에 없다. 그리고 보통 암호화 통신의 사용은 컴퓨터에서 실행되는 각 프로그램마다 개발자들이 암호화를 하느냐 마느냐에 결정되는 것이므로 한 컴퓨터에서도 각 프로그램마다 암호화 통신을 하기도 하고 안하기도 한다.[5] 심지어 인터넷에서 매우 중요한 역할을 하는 DNS도 의외로 암호화가 되어 있지 않다보니 중간자 공격에 취약한 편이고 TLS 1.3 버전 기준으로는 접속하는 웹사이트의 도메인 이름(SNI 필드) 역시 숨겨주지 못한다. 이 정보들이 노출된다고 해서 비밀번호와 같은 민감정보까지 노출되는 것은 아니지만, 도메인 이름은 사용자 식별이나 인터넷 검열로 악용될 수 있으며, 이에 따라 도메인 이름까지 TLS의 보호 범위에 포함시키는 ECH (Encrypted Client Hello) 기능의 도입과 표준화가 논의되고 있다.
4. 기타
입자의 하나인 중간자(中間子)와는 무관하다. 번역 과정에서 한자음이 겹친 것.몇몇 백신 또는 광고 차단 소프트웨어[6]들은 이 방식으로 통신 내역을 읽어 광고를 차단한다. 특히 HTTPS 필터링 기능을 사용할 경우 인증서를 신뢰할 것을 요구하는데, 이는 웹사이트 로그인 등 민감한 데이터가 모두 해당 프로그램으로 흘러간다는 뜻이다. 이런 방법은 심각한 보안 위협을 초래할 수 있으며, 가급적 사용하지 않을 것이 권장된다. 광고 차단이 필요하다면 Intra와 같은 DNS 변경 프로그램으로 광고 차단이 지원되는 DNS를 사용하거나, 확장 프로그램이 지원되는 파이어폭스 웹 브라우저 또는 광고 차단이 지원되는 파이어폭스 포커스, Brave, Cromite등을 사용하는 것이 좋다.[7][8] 광고 차단 프로그램에는 보통 바이러스나 맬웨어 유포 사이트도 차단하는 기능이 있다. 미심쩍은 파일을 받지 않는 등 보안 수칙을 지키면 모든 통신정보를 백신에 보내지 않더라도 위협은 현저히 줄어든다.
[1] 암호 키 교환 등등[2] 이 과정이 필요한 이유는 중간자 공격 중인 해커가 자신이 임의로 만든 인증서를 던져줄 수 있기 때문이다. 해커가 자신이 생성한 임의의 공개키를 던져준다는 것은 사실상 해당 공개키에 상응하는 비밀키도 알고 있다는 소리가 되므로 이대로 진행하게 되면 암호화가 무의미해진다. 그러므로 인증서 교환을 통해 연결을 요청한 서버가 정말로 연결하고자 하는 그 서버가 맞는지를 검증한다. 공개키로 비밀키를 알아낼 수 없고 비밀키로 공개키를 알아낼 수도 없기 때문에 일단 상용 서버들의 공개키가 넘어가면 해커는 절대로 손을 댈 수 없다.[3] 보통 인증서 교환과 같이 첫 연결 수립 시에만 비대칭 암호를 쓰는데 그 이유는 보통 대칭형 암호가 훨씬 가볍고 빠르기 때문이다. 대칭형 암호들도 키만 노출 되지 않으면 마찬가지로 복호화가 매우 어렵기에 일단 연결이 수립되면 대칭형 암호를 주력으로 쓴다.[4] 심지어 클라이언트가 매 연결마다 임의의 대칭형 암호 키를 생성하기 때문에 아예 해커가 클라이언트 프로그램의 완벽한 소스코드를 들고 있더라도 해독할 방법이 없다.[5] 물론 각 프로그램들의 의사와는 상관없이 모든 통신을 암호화 하는 경우도 있으며, 대표적으로 VPN이 있다.[6] AdGuard의 (확장 프로그램이 아닌) 윈도우, 안드로이드용 프로그램이라든지, Avast 안티바이러스의 HTTPS Scanning 등[7] 하지만 2022년 현재 대부분의 사용자는 이런 방법을 선호하지 않을 것이다. 광고 차단 기능이 내장된 브라우저나 단순히 광고 차단을 지원하는 DNS를 이용하는 것만으로는 Anti-AdBlock 스크립트에 의해 사이트 열람 자체가 막히는 경우가 부지기수이기 때문. AdGuard 등에 탑재된 Anti-Anti AdBlock 기능으로 광고 없이 사이트를 보기 위해서라도 어쩔 수 없이 사용해야 하는 측면이 있다.[8] 다만 컴퓨터공학과 계열 지식이 있어서 HTTP 송수신 내역을 분석하거나 자바스크립트 코드를 이해할 수 있는 사람은 기존대로 DNS단에서만 차단하는 프로그램을 사용하면서 Anti-AdBlock 스크립트는 수동으로 커트해내는 방법도 있긴 하다. 스크립트 소스가 난독화되지 않았거나 정확한 원인 파일을 규명할 수 있는 경우 개발자도구의 네트워크 단에서 해당 스크립트 파일의 다운로드를 차단해버리거나 Interval ID를 색출해서 ClearInterval 함수를 통해 반복 실행을 해제시키고 페이지를 복구시키면 되며(대부분 경고창 element로 본문 위를 가리게 덮어쓰는 경우가 제일 많고 조금 더 발전된 경우에는 CSS 및 자바스크립트를 통해 컨텐츠를 숨김 처리 하거나 지워버리는 경우가 많은데 덮어쓰는 경우에는 덮는 개체를 개발자도구 element 탭에서 찾아 날려버리면 되고 CSS나 JS로 내용을 망치는 경우에는 소스를 분석하여 display: none;과 같은 문제를 유발하는 속성과 코드를 제거하여 복구하면 된다.) 난독화가 되어 있거나 페이지를 사용하기 위해 필요한 정상적인 기능에 anti-Adblock 스크립트가 섞여 있는 경우에는 위의 방식으로 사이트를 분석하여 복구 스크립트를 짜고 그걸 setInterval로 반복 실행시켜서 anti-Adblock이 페이지를 망쳐 놓으면 곧장 복원시켜서 페이지 사용이 가능하게 만드는 무식한 방법으로 파훼 가능하다. Adblock 경고창이 깜빡거려서 거슬리긴 하지만 어쨌든 백엔드 단에서 페이지 제공을 막지 않는 이상에야 홈페이지 내용은 볼 수 있으니까..