SMTP Parte 1 - Mojándonos el potito
__________________________ |\ From: neo .__. /| | \ To: sigint.in | | / | | \ ._-.. '""'/ | | /\__________________/\ | | / \ | |/ -.,-_ \| |__________________________|
.--[ 0 - Contexto ]--------------------
Originalmente, este era un post muy largo sobre el protocolo SMTP, su historia, su funcionamiento y sus falencias. Ya que no me puedo concentrar en más de una cosa a la vez, lo dejé un poco botado y la verdad es que se veía bien feo publicado sin terminar. Por lo tanto, decidí transformarlo en una serie indefinida de posts en donde partiré desglosando el protocolo SMTP, para luego atacarlo y suplantar identidades de correo.
Muchas personas inteligentes, a quienes iré citando cuando corresponda, ya han hablado de este tema en charlas, papers y publicaciones personales. Aún así, creo que puedo sazonar un poco la ensalada de ideas que está dando vueltas con algunos alcances propios.
Esta primera parte es más como para pegarse el show que para introducir el tema. Es bien básica y nos ponemos hands-on al tiro para que se sientan bacanes haciendo algo.
.--[ 1 - Qué, cómo y cuándo ]----------
El protocolo SMTP saluda al mundo en noviembre del año 1982 con piñatas y confetti, en la forma de un RFC titulado “Simple Mail Transfer Protocol” (Protocolo Simple de Transferencia de Correos)[0]. Como su título lo indica, este documento detalla minuciosamente la implementación de un protocolo de comunicación que pronto formaría parte del día a día de miles de personas, transformándose en un pilar fundamental del internet que hoy conocemos.
La estructura fundamental del protocolo es relativamente sencilla. Existen las siguientes partes en juego:
\- Usuario: Quien quiere enviar el correo
\- Cliente SMTP
\- Servidor SMTP
+----------+ +----------+
+------+ | | | |
| User |<-->| | SMTP | |
+------+ | Client- |Commands/Replies| Server- |
+------+ | SMTP |<-------------->| SMTP | +------+
| File |<-->| | and Mail | |<-->| File |
|System| | | | | |System|
+------+ +----------+ +----------+ +------+
SMTP client SMTP server
Fuente: RFC5321
En donde el usuario inicializa un envío a través del cliente SMTP, quien establece un canal de comunicación con el servidor SMTP. A través de este túnel, el cliente envía comandos -especificando los detalles del correo- y el servidor responde con códigos de estado a cada uno de estos. Uno de estos intercambios se podría ver algo así:
C = Cliente
S = Servidor
S: 220 sigint.in Simple Mail Transfer Service Ready
C: EHLO demon.cl
S: 250-sigint.in greets demon.cl
C: MAIL FROM:<miku@demon.cl>
S: 250 OK
C: RCPT TO:<neo@kirby.cl>
S: 250 OK
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: From: Miku <miku@demon.cl>
C: Subject: Importante.
C: To: Neo <neo@kirby.cl>
C:
C: Querido Neo:
C: Olvidé cuándo tenía que enviarte el correo falso para el blog.
C: Quedo atento.
C:
C: - Miku
C: .
S: 250 OK
C: QUIT
S: 221 sigint.in Service closing transmission channel
En otras palabras:
____________________________________________________________________________________
/ \
| .------------------------------------------------------. |
| ( Hola, soy sigint.in. Estoy listo para recibir comandos ) |
| '---------------------------------------------.--------'-------------------. |
| ( Hola sigint.in, soy demon.cl ) |
| .-------------. '----------------------------' |
| ( Hola demon.cl ) |
| '------------.'------------------------------------------------------------. |
| ( El usuario que va a *transmitir* el mensaje es miku@demon.cl ) |
| .---. '------------------------------------------------------------' |
| ( Oki ) |
| '---' .-----------------------------------------------------------------. |
| ( El usuario que recibe el mensaje y las respuestas es neo@kirby.cl ) |
| ,---. '-----------------------------------------------------------------' |
| ( Oki ) |
| '---' .--------------------------------------------. |
| ( Ahora te voy a pasar el contenido del correo ) |
| .------------------ ----. '--------------------------------------------' |
| ( Dele nomás, usted avisa ) |
| '----.------------------'--------------------------------------------------. |
| / El usuario que va a componer el mensaje es Miku (miku@demon.cl) \ |
| | Asunto: "Importante." | |
| | Que el receptor vea que el mensaje va dirigido a Neo (neo@kirby.cl) | |
| | Mensaje: "Querido Neo:..." | |
| \ Listo / |
| .----'.--------------------------------------------------------------------' |
| ( Ok ok ) |
| '-----' .---------------. |
| ( Ok chao besitos ) |
| .----------. '---------------' |
| ( Chaooo uwu ) |
| '----------' |
\____________________________________________________________________________________/
Chat entre nosotros (demon.cl) y el servidor de correo (sigint.in)
Esto dejaría un mensaje a nombre de miku@demon.cl en la cola para neo@kirby.cl.
Muy bonito todo, pero un poco preocupante en realidad. Como mencioné antes, SMTP es el protocolo que se usa actualmente (2023) para el envío de correos. Un poco extraño, considerando que fundamentalmente sigue siendo igual y se creo hace más de 40 años queee. Así es amigos y amigas, uno de los protocolos que sostiene gran parte de la comunicación moderna es antiguo, vulnerable y definitivamente no diseñado para el internet del siglo XXI.
Analicemos cómo funciona con más detalle y busquemos los problemas de diseño inherentes que viene arrastrando desde hace más de cuatro décadas.
.--[ 1.1 - ¿Integridad? ]--------------
Dado el contexto en el que nació SMTP, el diseño original no contempla ningún mecansismo para asegurar la integridad del mensaje o para establecer si el remitente de este es genuino realmente.
Para entender esto, veamos cómo es que se transporta la información enviada.
SMTP transporta estructuras llamadas “Objetos de correo”, compuestass por dos partes: un sobre y contenido. El sobre se configura a través de una serie de transacciones una vez que se inicia la conexión, mientras que el contenido se especifica utilizando el comando DATA. En el ejemplo de la parte anterior, el objeto de correo habría quedado algo así:
.-----------------------------.
| EHLO demon.cl |
| MAIL FROM: <miku@demon.cl> | <- Sobre SMTP
| RCPT TO: <neo@kirby.cl> |
| . ----------------------------.
| | FROM: Miku <miku@demon.cl> |
'---| TO: Neo <neo@kirby.cl> | <- Cabecera del contenido
| SUBJECT: Importante. |
!-----------------------------!
| Querido Neo:... | <- Cuerpo del contenido
'-----------------------------'
[!] El mensaje no se ve realmente así. Estos valores se reflejan en otras cabeceras de distinto nombre.
Si se fijan bien, hay algunos valores que parecen ser redundantes: MAIL FROM/FROM y RCPT TO/TO. Sin embargo, son solo los primeros -aquellos presentes en el sobre- los que realmente importan para el enrutamiento del mensaje. FROM y TO sirven unicamente como feedback visual para el usuario y son los valores que se muestran en los campos “From” y “To” (“De” y “Para” in spanish). Esto significa que no existe ningún mecanismo que nos obligue a homologar los valores del sobre y el contenido, por lo que es posible ingresar datos arbitrarios y enviar correos a nombre de otros usuarios y dominios.
Para demostrar esto, levanté un servidor SMTP en uno de los servidores de sigint.in con python (pueden hacer esto localmente pero me gusta complicar todo):
$ python3 -m smtpd -n -c DebuggingServer 0.0.0.0:1337
Luego, me conecté usando telnet y envié un correo tal y como describí en la parte anterior. Sin embargo, reemplacé los valores de “MAIL FROM” y “FROM” por “sigint.in@cloudflare.com”. Esta dirección de correo no existe y es solo para demostrar que el protocolo no valida estos campos de ninguna forma.
$ telnet mail.sigint.in 1337
Trying xx.xxx.xx.xx...
Connected to mail.sigint.in.
Escape character is '^]'.
220 localhost Python SMTP proxy version 0.3
EHLO elmejorblogdelmundo
250-localhost
250-8BITMIME
250 HELP
MAIL FROM:<sigint.in@cloudflare.com>
250 OK
RCPT TO:<neo@sigint.in>
250 OK
DATA
354 End data with <CR><LF>.<CR><LF>
To: neo@sigint.in
From: sigint.in@cloudflare.com
Subject: ¿Integridad?
Creo que no :)
.
250 OK
QUIT
221 Bye
Connection closed by foreign host.
Volviendo al servidor SMTP, nos damos cuenta de que el correo llegó exitosamente, junto con el remitente falso.
$ python3 -m smtpd -n -c DebuggingServer 0.0.0.0:1337
---------- MESSAGE FOLLOWS ----------
b'To: neo@sigint.in'
b'From: sigint.in@cloudflare.com'
b'Subject: \xc2\xbfIntegridad?'
b'X-Peer: xxx.xxx.xxx.xxx'
b''
b'Creo que no :)'
------------ END MESSAGE ------------
Los dejo invitados a recrear este experimento y estudiar como se comportan los distintos comandos del protocolo, junto con las cabeceras que producen posteriormente.
.--[ this.next.peek() ]----------------
En la siguiente parte vamos a ver cómo se usa el protocolo en el internet moderno, junto con las medidas de seguridad que ha implementado.
Eso, bai