SMTP Vulnerability Analysis
Intro
링크에 따르면 메일의 약 85%가 스팸 메일이라고 합니다. 이렇게 스팸 메일이 많은 이유는 2가지가 있습니다. 첫 번째는 클라이언트가 smtp 서버로 메일을 전송하는 것과 메일을 relay하는 구조가 같은 구조이기 때문입니다. 두 번째는 클라이언트가 smtp 서버로 메일을 전송할 때 클라이언트를 인증하는 절차가 없기 때문입니다. 이렇게 스팸 메일의 원인이되는 smtp의 취약점에 대해서 한번 정리해보고자 합니다. 나아가 그 해결 방안까지도 생각해보겠습니다.
Vulnerability 1: No authentication
smtp는 수신자나 송신자에 대한 인증을 하지 않습니다. 이러한 특성은 스팸 메일의 양을 증가시키는 가장 큰 원인이기도 합니다. 이 특성은 그 이외에도 다양한 문제를 유발합니다. 예를 들어서, 악의적인 해커가 자신의 c&c 서버에 사용할 좀비 pc를 추가하기 위해 악성 코드가 담긴 메일을 전송하여 누군가의 컴퓨터를 감염시킬 수 있습니다. 이처럼 신원이 보장되지 않은 발신자를 통해 전달된 메일을 다시 전달하거나 받는 것은 심각한 취약점으로 작용할 수 있습니다.
그럼 처음에 smtp가 만들어질 때 왜 authentication없이 만들어졌을까요? 그 이유는 인터넷이 개발된 초창기에 smtp가 설계되었기 때문입니다. (인증이 없는 대부분의 기능은 인터넷의 초창기에 설계되었다고 보아도 무방할 정도로, 인증은 어디에나 구현되어 있는 것 같습니다.) 인터넷이 개발된 초기에는 사용자들이 많이 없었고, 사용자들끼리 서로 신뢰가 가능했습니다. 따라서 smtp도 사용자들끼리 서로 신뢰할 수 있다는 전재로 설계가 되었습니다. 그로 인해 smtp는 인증 과정이 없고, 마찬가지로 앞에 접두사가 ‘R’인 명령어들은 실행될 때 인증 과정이 없습니다.
Solution 1-1: Add autentication to MTA
인증이 없다는 문제점을 해결하기 위한 방법으로 여러 가지를 제시할 수 있습니다. 그 중에서 첫 번째는 MTA에 발신자 메일 주소를 제한하는 메커니즘을 추가하는 것입니다. 예를 들어 송신자나 수신자의 주소가 자신의 도메인인 경우만 허용하면 신뢰할 수 없는 도메인에서 발생한 dos 공격이나 스팸 메일 등을 모두 막을 수 있습니다.
Solution 1-2: SMTP-AUTH
인증이 없다는 문제를 해결하려면 인증을 구현하면 될 겁니다. 하지만 인증을 하기 위해서만 하더라도 여러 가지 방법이 존재합니다. 보편적으로는 SMTP Authentication 이라고해서 SMTP-AUTH로 사용자를 인증하는 방법이 있습니다. 이 방법을 사용할 경우에는 MTA와 MUA 모두 SMTP-AUTH 방식의 인증을 사용해야합니다. 인증 메커니즘으로는 SASL(Simple Authentication ans Security Layer)를 사용합니다.
Solution 1-3: POP before SMTP
SMTP-AUTH와 유사하게, POP before SMTP 이라는 인증 방법이 있습니다. 이 방법은 메일을 보내기 전에 POP3를 통해서 유저 인증을 먼저 수행합니다. 인증에 성공하면 일정한 시간 동안 메일 보내는 것을 허가합니다. (MTA에서는 POP3 서버가 인증한 유저의 정보를 보고 다시 허가하는 방식입니다.)
Solution 1-4: Authenticate Domains
앞서 제시한 방법들 이외에도 IP나 디지털 서명을 이용해서 도메인이 유효한지 인증하는 방법이 있습니다. 이처럼 송신 도메인이 유효한지 인증하는 과정을 통해서 스팸이나 dos 공격을 막을 수 있습니다. 도메인을 인증하는 방법은 크게 2가지가 있습니다.
첫 번째는 ip 주소를 사용하는 방식입니다. ip 주소를 이용하는 방식에도 2가지 종류가 있습니다.
- SPF
- 첫 번째 종류는 SPF(Sender Policy Framework)를 이용하는 방식입니다. 미리 발신자의 DNS서버에 유효한 메일 서버의 IP 주소(SPF 레코드)를 등록해두고, 그를 이용해 메일 서버를 인증합니다. 수신측 메일 서버는 해당 도메인의 DNS서버에게 메일 서버의 정보를 문의합니다. 그 결과 유효하다면, 해당 메일을 수신하게 되는 방식입니다.
- Sender ID
- 두 번째는 Sender ID Framework를 이용하는 방식입니다. 이 방법은 SPF와 상당히 유사합니다. 하지만 메일에서 어떤 도메인의 유효성을 검사하는냐에서 차이점이 존재합니다.
ip 주소를 통해 유효성을 검사하는 방식을 사용하면 상대적으로 메일 서버의 부담이 적다는 장점이 있습니다. 하지만 발신자를 위조하지 않은 메일이나 스푸핑하지 않은 메일은 필터링할 수 없다는 단점이 있습니다. 치명적인 단점으로는 DNS 서버에 등록이 되지 않은 메일 서버로 부터 온 메일은 유효하더라고 유효하지 않다고 판단한다는 것입니다.
두 번째 디지털 서명을 사용하는 방식입니다. 이 방식은 미리 발신자의 DNS 서버에 유효한 메일 서버의 공개키를 등록해둡니다. 그럼 발신자는 그와 함께 자신의 비밀키를 이용해 메일에 서명하고 메일을 보냅니다. 메일을 수신한 메일 서버는 DNS 서버에서 발신자의 공개키를 획득하고 그를 이용해 메일의 유효성을 확인합니다. 디지털 서명을 이용한 방법은 메일이 여러 메일 서버를 거쳐 왔더라도 검증이 가능합니다. 하지만 ip 주소를 이용하는 방식과는 다르게 송신측, 수신측 모두 이 방식을 지원해야 하고 상대적으로 메일 서버의 부담이 크다는 단점이 있습니다. 추가적으로 유효한 메일이 중간에 스푸핑되어 내용이 변경되더라도 그를 탐지하지 못한다는 단점도 존재합니다.
Solution 1-5: Using Spam Filter
첫 번째 취약점의 마지막 해결 방법은 spam filter를 이용하는 것입니다. 바닐라 버전의 smtp에서는 스팸을 막기 어렵기 때문에 메일 필터링을 이용해서 스펨 메일을 서버에서 막아야 합니다. 이와 다르게, 메일 필터링을 위한 프로그램을 따로 사용하는 방법도 있습니다. 이는 ip나 메일의 데이터를 대상으로 유효하지 않은 메일을 파악하여 그를 차단하는 방식입니다. 문자열 패턴을 약간씩 바꾸어 이를 우회하는 것을 막기 위해서는 베이지안 필터링, 딥러닝 등을 사용할 수도 있습니다.
Vulnerability 2: Open Relay
SMTP 릴레이란 메일 서버 외부에서 메일 서버를 경유하여 다른 메일 서버로 메일을 보내는 것을 의미합니다. 이 때 경유한 서버를 메일 릴레이 서버라고 합니다. 오픈 릴레이는 모든 전자메일 메시지를 릴레이하는 것을 의미합니다. 오픈 릴레이 메일 서버는 스팸메일 발신자의 메일 서버로 사용될 수 있는데, 이는 서버가 여러 RBL에 스팸메일 서버로 등록되는 결과를 초래합니다.
Solution 2-1: OP25B
오픈 릴레이 방식이 앞서 언급한 여러 방법에 의해 막히는 경우가 많아지면서, 클라이언트를 직접 감염시켜 ISP의 MTA가 아닌 아웃바운드 서버의 25번 포트를 통해서 메일을 발송하는 시도가 많아졌습니다. 이를 막는 방법 중에는 OP25B라고 하는 방법이 있습니다.
OP25B(Outbound Port 25 Blocking)는 ISP의 아웃바운드 서버를 통해 대량 원하지 않는 전자 메일을 고의 또는 의도하지 않게 보내는 것을 방지하기 위한 조치입니다. 대부분의 스팸은 포트 25를 사용하여 수신자의 서버로 직접 라우팅됩니다. 따라서 포트 25를 차단하면 포트 25의 사용을 제한할 수 있으며 그에 따라 스팸의 흐름을 차단할 수 있습니다. (정상적인 메일의 경우는 submission 포트인 587포트를 사용합니다.)
Vulnerability 3: No Encryption
이전에 언급했던 것과 같은 이유로, SMTP는 암호화를 지원하지 않습니다. 따라서 데이터가 여러 메일 서버들을 통해 이동하는 중에 외부에 노출되게 됩니다. 이러한 취약점은 당연히 Spoofing attack 등의 공격의 표적이 됩니다. 결국 메일의 민감한 정보를 공격자가 탈취할 수 있게 됩니다.
Solution 3-1: Using TLS
가장 확실한 방법은 암호화를 제공하는 프로토콜인 TLS를 사용해서 SMTP 통신 전체를 감싸 암호화하는 방식입니다. 하지만 이 방법은 필요 이상으로 비용이 드는 방법입니다. 더욱 합리적인 방법은 각 서버의 공개키로 메일을 암호화하는 것입니다. 하지만 RFC 8689에 따르면 MTA가 제대로 동작하지 않을 경우에 Confidentiality가 보장되지 않습니다. 그러므로 REC 4880의 OpenPGP나, RFC 8551의 S/MIME를 사용해서 MTA로부터 데이터를 보호하는 방법을 사용해야 합니다.
Vulnerability 4: Mail Boom
Mail boom 공격은 자동으로 메일 서버에 메일들을 생성하고 수많은 메일들을 동시에 전송해서 서버를 마비시키는 공격입니다. 이 공격은 DoS 공격과 마찬가지로 일반적인 메일 서비스를 사용하지 못하도록 합니다.
Solution 4-1: Count Mail and Block IP
이 경우 단순하게 mail boom인지를 확인하고, mail boom이라고 판단된다면 해당 IP 주소를 block하는 방법으로 예방할 수 있습니다.
Vulnerability 5: HELP, EHLO, HELO
마지막으로 HELP, EHLO, HELO에 관한 취약점을 분석해보겠습니다. HELP는 임의의 서버의 정보를 얻기 위해서 사용됩니다. 하지만 HELP는 안전하지 않습니다. HELP는 주로 서버의 type이나 버전과 같은 정보를 응답으로 제공하는데, 사용자의 입장에서는 이 정보들이 매우 유용한 정보이지만 그만큼 악의적인 공격자에게도 유용한 정보가 됩니다. 즉, 공격자들이 HELP로 공격 대상 서버의 정보를 아주 쉽게 얻을 수 있습니다. 따라서 HELP의 응답으로 서버의 정보를 제공하는 것은 취약합니다.
Solution 5-1: Replace response
이러한 명령어들의 취약점은 단순하게 이 명령어들의 응답을 유저가 대체함으로써 쉽게 해결 가능합니다. 해당 명령어에 대한 응답을 전혀 주지 않거나, 엉뚱한 정보를 제공하도록 하면 악의적인 공격자가 자신의 서버를 공격하는데 필요한 정보를 쉽게 얻을 수 없습니다.
Conclusion
SMTP에 대한 5개의 취약점에 대해서 알아보고 그 해결방안에 대해서 생각해보았습니다. 더 많은 취약점이 있지만 그 중에서도 쉽게 발생할 수 있는 취약점들을 분석해보았습니다. 아무래도 인증에 관련된 부분이 많은데, 그만큼 인증이 보안에 있어 중요한 역할을 한다는 것을 반증하는 것 같습니다.