Sender spoofing in Proton Mail via display-name homograph
Proton Mail에서 표시 이름으로 발신자 위장 가능
Proton Mail에서 발신자 표시 이름과 글꼴의 유사 문자를 악용해 실제 주소와 다른 발신자를 믿을 만하게 보이게 하는 문제가 보고됐습니다. DMARC 정책이 없는 도메인에서 인증 실패 경고도 나타나지 않으며, 제보자는 Proton이 수정에 동의하고 포상금을 지급한 뒤에도 2026년 9월까지 문제가 재현됐다고 밝혔습니다.
- 주제
AI 요약
Proton Mail의 웹 인터페이스에서 발신자 표시 이름(display name)을 조작하면 실제 발신 주소와 다른 신원을 진짜처럼 보이게 만들 수 있다는 보안 문제가 공개됐습니다. 제보자는 2025년 2월 Proton Security에 신고했고, Proton은 4월 문제를 확인해 포상금을 지급하고 수정 방침을 밝혔습니다. 하지만 제보에 따르면 수정은 배포되지 않았고, 2026년 9월에도 재현됐습니다.
표시 이름이 주소처럼 보입니다
이메일 발신자는 From 헤더의 표시 이름을 임의로 정할 수 있습니다. Proton Mail은 표시 이름에 주소처럼 생긴 문자열이 들어가도 실제 주소를 눈에 띄게 구분하지 않습니다. 독자가 발신 주소라고 여기기 쉬운 자리에 표시 이름이 노출됩니다. 여기에 Reply-To 헤더를 공격자가 관리하는 주소로 지정하면, 사용자가 헤더를 직접 펼쳐 확인하지 않는 한 답장이 다른 주소로 전달되는 점도 알아채기 어렵습니다.
글꼴에서 구분되지 않는 문자
제보 사례는 gmail.com의 소문자 l 대신 대문자 I를 넣은 gmaiI.com을 사용했습니다. macOS의 기본 글꼴인 SF Pro를 비롯해 일부 system-ui 산세리프 글꼴에서는 두 문자가 똑같이 보입니다. 따라서 주소를 주의 깊게 읽어도 차이를 찾기 어렵습니다. 이 수법은 유니코드 문자를 섞거나 punycode를 쓰지 않습니다. Proton이 일부 인코딩 기반 동형 문자(homograph)를 막더라도, 같은 글꼴 안에서 생기는 I/l 혼동은 별도로 걸러야 합니다.
DMARC 설정에 따라 달라지는 경고
발신 도메인에서 SPF 인증이 실패하고 DMARC 레코드도 없으면, Proton은 메시지를 받은편지함에 전달하면서 인증 실패 경고를 표시하지 않는다고 제보자는 설명합니다. 반대로 DMARC를 게시한 도메인에서 SPF가 실패하면 ‘인증 실패, 위조일 수 있음’ 경고가 나타납니다. 제보자는 이 차이 때문에 위조 메시지가 경고 없이 정상 메일처럼 보인다고 지적했습니다.
제보자는 표준 SMTP 테스트 도구 swaks로 Proton의 수신 MX 서버에 STARTTLS 연결을 맺어 자신의 계정에 시험 메시지를 보냈습니다. From 표시 이름에는 유명인의 이름과 gmaiI.com 주소를 넣고, Reply-To에는 공격자가 관리하는 별도 주소를 설정했습니다. 서버는 메시지를 대기열에 넣고 받은편지함으로 전달했습니다. 시험은 제보자 본인의 계정으로만 진행했으며, 다른 Proton 사용자에게 원치 않는 메일을 보내지는 않았다고 밝혔습니다. 위조된 발신자 표시는 웹 인터페이스뿐 아니라 macOS 데스크톱 알림에도 나타났습니다.
신고와 공개 경과
제보자는 2025년 2월 13일 재현 절차와 헤더 정보를 Proton에 제출했습니다. Proton은 4월 15일 조사 뒤 조치를 하겠다고 답했고, 동형 문자 위장 위험을 이유로 100달러의 포상금을 지급했습니다. 제보자는 포상금을 스페인의 동물 보호소에 기부했습니다. 이후 제보자가 보안 기여자 페이지 등재를 위한 정보를 보냈고, Proton은 관련 팀에 요청했다고 답했습니다.
제보자는 2026년 8월 말에도 문제가 재현된다고 다시 알렸습니다. Proton은 해당 문제가 이미 신고됐고 새 신고로는 포상금 대상이 아니라고 답했습니다. 제보자는 전년도에 포상금을 받은 바로 그 문제라고 설명했고, Proton은 담당 엔지니어링 팀과 확인하겠다고 밝혔습니다. 제보자는 Proton이 문제를 인정하고 수정 요청을 했는데도 16개월 넘게 고치지 않았다고 주장합니다.
제보자가 제안한 대응
인터페이스에서 표시 이름을 발신 주소처럼 보여주지 말고 실제 주소를 분명히 표시하는 방법이 제안됐습니다. 발신자 문자열에서 서로 혼동하기 쉬운 문자를 정규화하거나 경고하는 방안도 있습니다. DMARC 레코드 유무와 관계없이 인증 실패 신호를 일관되게 표시하는 방법도 함께 제시됐습니다.
Reddit 반응
- @u/paultendo — 패치 없이 18개월이나 둔 점은 심각합니다. I/l 바꿔치기는 생각보다 더 나쁩니다. 유니코드를 전혀 쓸 필요가 없기 때문입니다. 제가 관련 연구를 했는데, 시험한 텍스트 글꼴 140종 가운데 79종에서 대문자 I와 소문자 l이 비슷하게 보였습니다. macOS 시스템 글꼴, Helvetica, Arial, Roboto도 포함됩니다. 그래서 흔한 동형 문자 방어로는 막히지 않습니다. punycode도 혼합 스크립트도 없으니 일반적인 필터가 표시할 만한 것도 없습니다. 언급하신 대로 실제 발신 주소를 보여주는 게 해결책입니다. 메일 클라이언트가 표시 이름과 실제 도메인을 비교하기 전에 비슷하게 보이는 문자를 하나로 정규화할 수도 있습니다. 그러면 gmaiI.com을 gmail.com과 같은 것으로 보고 둘이 다를 때 경고할 수 있습니다. 주요 메일 도메인 목록을 두고 유사 문자열을 비교하는 방법도 있겠습니다. 제 연구 측정 자료는 공개돼 있습니다: https://github.com/paultendo/confusable-vision
- @u/nekro_neko — 이 공격에 강한 글꼴을 추천해 줄 줄 알았습니다.
원문: Reddit / 번역·요약: Trawling