모르는 이메일 주소에서 스팸이나 피싱 메시지를 받아본 적이 있으신가요? 공짜 여행을 제안하거나, 개인 사진과 맞바꿔 비트코인을 보내라고 요구하거나, 그저 성가신 마케팅 메일을 일방적으로 보내온 발신자 말입니다.
그 메일이 대체 어디에서 왔는지 궁금해 본 적이 있나요? 나의 이메일 주소를 도용한 스패머가 과연 어떻게 그런 일이 가능한지 의문을 품어 본 적은요?
이메일 스푸핑은 생각보다 쉽습니다
이메일 스푸핑(spoofing)이란 실제 발신지와 다른 주소에서 온 것처럼 메일을 위장하는 행위를 말합니다. 예컨대 백악관(whitehouse.gov)에서 온 것처럼 보이지만 실제로는 사기범이 보낸 메일 같은 경우죠. 놀랍게도 이런 위장은 매우 쉽게 이루어질 수 있습니다.
그 이유는 핵심 이메일 프로토콜에 인증 장치가 전혀 없기 때문입니다. 즉, '보낸 사람(From)' 주소는 사실상 누구나 임의로 채워 넣을 수 있는 빈칸일 뿐입니다.
평소 우리가 받는 이메일은 대략 다음과 같은 형태로 표시됩니다.
From: Name <name@gmail.com>
Date: Tuesday, July 16, 2019 at 10:02 AM
To: Me <Me@freecodecamp.com>그 아래로 제목과 본문이 이어지죠.
하지만 이 메일이 실제로 어디에서 출발했는지 어떻게 알 수 있을까요? 더 분석해 볼 만한 데이터는 없는 걸까요?
숨겨진 단서는 '전체 헤더'에 있다
우리가 찾아야 할 것은 전체 이메일 헤더(full headers)입니다. 위에서 본 내용은 헤더 중 극히 일부에 불과합니다. 전체 헤더에는 이메일이 어디에서 시작되어 어떤 경로를 거쳐 수신함에 도달했는지에 대한 핵심 정보가 담겨 있습니다.
직접 헤더를 확인하고 싶다면 Outlook이나 Gmail에서 헤더를 여는 방법부터 익혀 보세요. 대부분의 메일 프로그램도 비슷한 방식으로 동작하며, 간단한 검색만으로 다른 메일 서비스의 헤더 보기 방법도 찾을 수 있습니다.
이 글에서는 실제 헤더를 하나씩 해부해 봅니다. 호스트명, 타임스탬프, IP 주소 등 민감한 정보는 모두 가렸습니다.
헤더는 위에서 아래로 읽되, 한 가지 유의할 점이 있습니다. 새로운 서버는 자신의 헤더를 메일 본문 최상단에 덧붙이기 때문에, 결과적으로 마지막 메일 전송 에이전트(MTA)의 기록부터 시작해 처음 메시지를 접수한 최초의 MTA 방향으로 거슬러 올라가며 읽게 됩니다.
1. 내부 전송 구간 (Internal Transfers)
Received: from REDACTED.outlook.com (IPv6 Address) by REDACTED.outlook.com with HTTPS via REDACTED.OUTLOOK.COM; Fri, 25 Oct 2019 20:16:39 +0000첫 번째 홉(hop)에 HTTPS라는 문구가 보입니다. 이는 해당 서버가 표준 SMTP로 메시지를 수신한 것이 아니라, 웹 애플리케이션으로 입력된 내용을 바탕으로 메시지를 생성했다는 뜻입니다.
Received: from REDACTED.outlook.com (IPv6Address) by REDACTED.outlook.com (IPv6Address) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1358.20; Fri, 25 Oct 2019 20:16:38 +0000
Received: from REDACTED.outlook.com (IPv6Address) by REDACTED.outlook.office365.com (IPv6Address) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2385.20 via Frontend Transport; Fri, 25 Oct 2019 20:16:37 +0000 Authentication-Results: spf=softfail (sender IP is REDACTEDIP)smtp.mailfrom=gmail.com; privatedomain.com; dkim=pass (signature was verified)header.d=gmail.com;privatedomain.com; dmarc=pass action=noneheader.from=gmail.com;compauth=pass reason=100Received-SPF: SoftFail (REDACTED.outlook.com: domain of transitioning gmail.com discourages use of IPAddress as permitted sender)이 두 개의 헤더 블록은 내부 메일 전송 기록입니다. Office365(outlook.com) 서버들이 메시지를 수신한 뒤 올바른 수신자에게 내부적으로 라우팅했음을 알 수 있습니다.
또한 이 메일이 암호화된 SMTP로 전송되었음도 확인할 수 있습니다. 헤더에 "with Microsoft SMTP Server"라는 문구가 있고, 그 뒤에 사용된 TLS 버전과 구체적인 암호 스위트(cipher)가 명시되어 있기 때문입니다.
세 번째 헤더 블록은 로컬 메일 서버에서 메일 필터링 서비스로 넘어가는 지점을 표시합니다. "via Frontend Transport"라는 문구가 있는데, 이는 Microsoft Exchange 고유의 프로토콜이라 엄밀히 말해 SMTP는 아니기 때문입니다.
이 블록에는 몇 가지 이메일 검사 결과도 포함되어 있습니다. Outlook.com의 헤더에는 SPF/DKIM/DMARC 검증 결과가 상세히 기록됩니다. SPF softfail은 해당 IP 주소가 gmail.com을 대신해 메일을 보낼 권한이 없다는 의미입니다.
dkim=pass는 메일이 명시된 발신자에게서 실제로 왔으며, 전송 중에 (아마도) 변조되지 않았다는 뜻입니다.
DMARC는 메일 서버가 SPF와 DKIM 결과를 어떻게 해석할지 지정하는 규칙 집합입니다. 통(pass)으로 판정되면 대개 메일이 목적지까지 계속 전달됩니다.
SPF, DKIM, DMARC에 대해 더 깊이 알고 싶다면 별도의 전문 자료를 함께 참고하시길 권합니다.
2. 내부-외부 전환 구간 (Internal/External Transition)
Received: from Redacted.localdomain.com (IP address) byredacted.outlook.com (IP address) with Microsoft SMTPServer (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id15.20.2305.15 via Frontend Transport; Fri, 25 Oct 2019 20:16:37 +0000
Received-SPF: None (Redacted.localdomain.com: no senderauthenticity information available from domain ofsender@gmail.com) identity=xxx; client-ip=IPaddress;receiver=Redacted.localdomain.com;envelope-from="sender@gmail.com";x-sender="sender@gmail.com"; x-conformance=sidf_compatible
Received-SPF: Pass (Redacted.localdomain.com: domain ofsender@gmail.com designates sending IP as permittedsender) identity=mailfrom; client-ip=IPaddress2;receiver=Redacted.localdomain.com;envelope-from="sender@gmail.com";x-sender="sender@gmail.com"; x-conformance=sidf_compatible;x-record-type="v=spf1"; x-record-text="v=spf1ip4:35.190.247.0/24 ip4:64.233.160.0/19 ip4:66.102.0.0/20ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16ip4:108.177.8.0/21 ip4:173.194.0.0/16 ip4:209.85.128.0/17ip4:216.58.192.0/19 ip4:216.239.32.0/19 ~all"마지막 부분의 긴 IP 목록이 바로 구글의 SPF 레코드입니다. gmail.com에서 왔다고 주장하는 메일이 실제로는 구글이 승인한 서버에서 발송되었음을 수신 서버에 알려주는 역할을 합니다.
Received-SPF: None (redacted.localdomain.com: no senderauthenticity information available from domain ofpostmaster@redatedgoogle.com) identity=helo;client-ip=IPaddress; receiver=Redacted.localdomain.com;envelope-from="sender@gmail.com";x-sender="postmaster@.google.com";x-conformance=sidf_compatibleAuthentication-Results-Original: Redacted@localdomain.com; spf=Nonesmtp.pra=sender@gmail.com; spf=Pass smtp.mailfrom=sender@gmail.com;spf=None smtp.helo=postmaster@redacted.google.com; dkim=pass (signatureverified) header.i=@gmail.com; dmarc=pass (p=none dis=none) d=gmail.comIronPort-SDR: IronPort-PHdr: =X-IronPort-Anti-Spam-Filtered: trueX-IronPort-Anti-Spam-Result: =X-IronPort-AV: ;d="scan"X-Amp-Result: SKIPPED(no attachment in message)X-Amp-File-Uploaded: False여기에는 추가적인 SPF/DKIM/DMARC 검사 결과와 함께 IronPort 스캔 결과가 기록되어 있습니다.
IronPort는 많은 기업이 사용하는 대표적인 이메일 필터로, 스팸·바이러스·악성 메일을 탐지합니다. 메일에 포함된 링크와 첨부파일을 스캔한 뒤, 그 메일이 악성(따라서 폐기해야 함)인지, 정상적이어서 전달해야 하는지, 아니면 의심스러운 수준인지를 판별합니다. 의심스러운 경우에는 사용자에게 주의를 환기시키는 헤더를 메일 본문에 붙이기도 합니다.
Received: from redacted.google.com ([IPAddress])by Redacted.localdomain.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; Fri, 25 Oct 2019 16:16:36 -0400
Received: by redacted.google.com with SMTP idfor recipient@localdomain.com; Fri, 25 Oct 2019 13:16:35 -0700 (PDT)
X-Received: by IPv6:: with SMTP id; Fri, 25 Oct 2019 13:16:35 -0700 (PDT) Return-Path: sender@gmail.com
Received: from senderssmacbook.fios-router.home (pool-.nycmny.fios.verizon.net. [IP address redacted])by smtp.gmail.com with ESMTPSA id redacted IP(version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);Fri, 25 Oct 2019 13:16:34 -0700 (PDT)
Received: from senderssmacbook.fios-router.home (pool-.nycmny.fios.verizon.net. [IP address redacted])by smtp.gmail.com with ESMTPSA id redacted IP(version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);Fri, 25 Oct 2019 13:16:34 -0700 (PDT)이 구간은 발신자의 최초 기기에서 출발해 Gmail의 라우팅 시스템을 거쳐 수신자의 Outlook 환경에 도달하기까지의 내부 홉 경로를 보여줍니다. 이 기록만으로도 최초 발신자가 뉴욕에서 Verizon Fios 가정용 공유기를 통해 맥북(MacBook)을 사용해 메일을 보냈다는 사실을 알 수 있습니다.
여기까지가 발신지에서 수신지까지의 전송 경로 기록의 끝입니다. 이 아래로는 이메일 본문과 평소 흔히 보는 "From:", "To:" 같은 헤더가 등장하며, 미디어 타입과 메일 클라이언트에 따라 MIME 버전, 콘텐츠 타입, boundary 등의 서식 정보가 붙을 수 있습니다.
또한 User-Agent 정보가 포함되기도 하는데, 이는 메시지를 보낸 기기의 종류를 알려주는 세부 사항입니다. 이 사례에서는 애플의 명명 규칙 덕분에 이미 맥북에서 보냈음을 알 수 있었지만, 경우에 따라 CPU 종류, OS 버전, 심지어 설치된 브라우저와 그 버전까지 드러날 수 있습니다.
상황에 따라서는 발신 기기의 IP 주소가 포함되기도 합니다(다만 많은 서비스 업체는 영장 없이는 이 정보를 숨깁니다).
이메일 헤더가 알려주는 것
이메일 헤더는 메일이 명시된 발신자에게서 실제로 보내진 것이 맞는지 판별하는 데 큰 도움이 됩니다. 또한 발신자에 대한 일부 단서를 제공하지만, 대개 그것만으로 진짜 발신자를 특정하기에는 부족합니다.
법 집행 기관은 이 데이터를 활용해 해당 ISP에 영장을 요청할 수 있습니다. 하지만 일반 사용자에게는 주로 피싱 조사 등의 참고 자료로 활용되는 수준입니다.
더욱이 헤더는 악성 서버나 해커에 의해 위조될 수 있어 분석이 한층 까다로워집니다. 각 서버 소유자에게 직접 연락해 메일에 기록된 헤더가 그들의 SMTP 로그와 일치하는지 하나하나 확인하지 않는 한, 자신의 메일 서버가 붙인 헤더를 제외하고는 헤더가 정확하다고 확신할 수 없습니다. 이 과정은 매우 번거롭고 시간이 오래 걸립니다.
DKIM, DMARC, SPF는 이러한 검증에 도움을 주지만 완벽하지 않으며, 이런 인증 장치조차 없다면 사실상 아무런 검증도 불가능합니다.
매번 직접 헤더를 분석하고 싶지 않다면, 헤더를 붙여넣으면 자동으로 분석해 주는 온라인 도구를 활용해 보세요. 헤더 읽기에 익숙해지면 스푸핑 메일을 스스로 걸러내는 눈이 분명히 생길 것입니다.