lunes, 15 de octubre de 2007

Anonymous Mail

h0aX [hoax_ws@yahoo.es]

Hoy les presento un título de solo 4 letras: SMTP, o si prefieres puedes llamarlo Simple Mail Transference Protocol. SMTP no es más que uno de los tantos protocolos que integran el inmenso TCP/IP y es específicamente el que nos permite enviar correos a nuestros conocidos. Para la introducción de este modesto artículo tenía pensado poner algo de la historia del SMTP, en que año surgió etc etc, pero la verdad no tengo tiempo ahora de copiar/pegar información de Wikipedia, que además, creo que está accesible para todos los lectores de esta revista. En vez de eso pienso ofrecerles información mucho más valiosa, y si al final del artículo logro enseñarles su funcionamiento y mejor uso, entonces habré logrado mi objetivo y me daré por complacido.

Empecemos con lo básico y con lo que probablemente ya conoces. SMTP o Simple Mail Transference Protocol es el protocolo que nos permite, desde cualquier parte del mundo, conectarnos a un servidor y enviar información (un correo) a otra persona que, además, puede encontrarse en cualquier otra parte del planeta. A diario nosotros somos parte de este escenario: frecuentemente revisamos nuestro correo y respondemos a nuestros amigos. Nada más normal que sentarse al PC, conectar, abrir Outlook, leer los nuevos correos y responder.

[¿Cómo funciona?]

SMTP funciona como cualquier protocolo cliente/servidor. Un programa cliente (Outlook por ejemplo) conecta con nuestro servidor SMTP (smtp.sld.cu, por mencionar alguno) que se hará cargo de satisfacer las peticiones del cliente, siempre y cuando estas sean hechas de la manera correcta.
¿Que quiere decir hacer las peticiones de la manera correcta? Pues significa que existe un estándar, una forma definida, o sea, un protocolo a seguir en la manera en que el cliente y el servidor intercambian peticiones y respuestas. Como cualquier protocolo de comunicación, debe existir un acuerdo en la forma en que se transmite la información, de nada sirve hablar con una persona extranjera si no conoce tu idioma. Entonces queda definido, según el protocolo SMTP que la comunicación cliente/servidor se hará en forma de comandos y códigos de respuesta, de esta manera se podrá lograr la sincronización necesaria para que el cliente pueda especificar al servidor las particularidades del mensaje que desea enviar.

[La práctica]

Con tanta teoría puede que alguien se pierda o aburra; la experimentación es la madre de todo conocimiento, así que, experimentemos. Asumiendo que la mayoría de los lectores de esta revista son usuarios de Infomed decidí usar su servidor SMTP para realizar las pruebas.
Para visualizar todo lo que hasta ahora he dicho abre una consola del sistema y estando conectado a Infomed teclea en ella "telnet smtp.sld.cu 25". Como podrás imaginarte con ello estarás conectando al servidor smtp.sld.cu por su puerto 25, que además es el puerto definido por defecto para el servicio SMTP. Una vez conectado podrás leer un mensaje como el siguiente:

220 smtp.sld.cu ESMTP ready

Pues felicidades, esto quiere decir que haz logrado conectar con tu servidor SMTP y este está dispuesto a atenderte. Cualquier persona que lea este mensaje es capaz de captar esa idea, principalmente por la parte que dice "ESMTP ready", pero ¿recuerdas lo que dije antes de comandos/códigos de respuesta? pues es esta la interfaz que manejan los programas clientes y no es precisamente por la frase "ESMTP ready" por la que un programa cliente sabe que el servidor está listo para atenderlo. Si eres observador verás que los tres primeros caracteres de la cadena representan un número (220), este es el código de respuesta al que me refería y es a partir del cual el servidor le hace entender al cliente que todo está bien y está listo para recibir o que en ese momento se encuentra temporalmente indisponible.
Una vez llegados aquí tenemos a nuestra disposición una serie de comandos de bajo nivel con los cuales podremos darle ordenes al servidor respecto al mensaje que queremos enviar.
Ahora teclea en la consola

HELO prueba

con lo que recibirás la siguiente respuesta:

250 cabrera.red.sld.cu Hello prueba [201.220.205.229]

Esto ha sido un pequeño saludo entre el cliente y el servidor.
Según el RFC 821 este comando es usado para identificar el sender-SMTP del receiver-SMTP. El campo argumento contiene el hostname del sender-SMTP. Como solo estamos haciendo una prueba le pasamos cualquier cosa como argumento. Este comando y su respuesta indican que tanto el cliente como el servidor están listos para comenzar y aún no hay transacción alguna en progreso. Ya habrás notado que el código de respuesta fue 250, normalmente 250 será la respuesta que siempre queremos ver, el que indica que todo está bien hasta el momento.
El siguiente comando que teclearas será

MAIL FROM:<pepe@infomed.sld.cu>

teniendo en cuenta que mi usuario de infomed es "pepe" se entiende perfectamente que con esto estoy definiendo que "pepe@infomed.sld.cu" será el buzón desde donde se envía el mensaje. La respuesta normal deberá ser un simple

250 OK

Código 250 indica que todo marcha bien. A continuación teclea:

RCPT TO:<antonio@infomed.sld.cu>

para definir el correo a donde será enviado el mensaje y la respuesta será

250 Accepted

Hasta aquí hemos hecho un gran avance, hemos creado una conexión a nuestro servidor SMTP y a nivel de comandos hemos iniciado comunicaciones y le hemos indicado que queremos enviar un correo desde pepe@infomed.sld.cu dirigido a antonio@infomed.sld.cu. Solo nos queda definir el mensaje como tal. Volviendo a la consola nos disponemos a teclear el próximo comando que será

DATA

la respuesta del servidor esta vez será

354 Enter message, ending with "." on a line by itself

El código de respuesta ha cambiado, esta vez no hemos visto nuestro querido 250, pero que no cunda el pánico, 354 no es un código de error, este número nos indica que el servidor está listo para tomar notas del mensaje que se quiere enviar. A continuación presiona enter dos veces y escribe el texto que desees, estás escribiendo el cuerpo del mensaje. Cuando termines de escribir el mensaje, para indicarle al servidor que terminaste debes presionar enter PUNTO enter. Un punto (.) sólo en una línea indica que se ha alcanzado el final del mensaje. Una vez tecleado el punto te aparecerá una respuesta como la siguiente

250 OK id=XXXXXX-XXXXXX-XX

Listo. El mensaje ha sido enviado. Ya no tienes nada más que hacer en el servidor así que mejor te desconectas con el comando

QUIT

respuesta:

221 cabrera.red.sld.cu closing connection

Pues la tarea está terminada, hemos enviado un correo usando los comandos de bajo nivel del protocolo SMTP. En este ejemplo solo hemos visto los comandos y códigos de respuesta más elementales, a continuación muestro una lista de ambos según el RFC 821.

Si quieres saber los comandos de los que dispone tu servidor SMTP y para que sirven puedes usar el alabado HELP. A continuación una lista:

HELLO (HELO)
MAIL (MAIL)
RECIPIENT (RCPT)
DATA (DATA)
SEND (SEND)
SEND OR MAIL (SOML)
SEND AND MAIL (SAML)
RESET (RSET)
VERIFY (VRFY)
EXPAND (EXPN)
HELP (HELP)
NOOP (NOOP)
QUIT (QUIT)
TURN (TURN)

Estos son los códigos de respuesta con su significado:

500 Error de sintaxis, comando no reconocido
501 Error de sintaxis en argumentos
502 Comando no implementado
503 Secuencia de comandos errónea
504 Parámetro no implementado
211 Respuesta de ayuda
214 Mensaje de ayuda
220 <dominio> Servicio listo
221 <dominio> Servicio cerrando canal de transmisión
421 <dominio> Servicio no disponible
250 Acción completada, todo OK
251 Usuario no local
450 mailbox indisponible, no se ha podido proceder
550 mailbox indisponible, no se ha podido proceder
451 Acción abortada
551 Usuario no local
452 Memoria del sistema insuficiente
552 Exceso de memoria reservada
553 Nombre del mailbox no permitido
354 Comienza el mensaje; termina con <CRLF>.<CRLF>
554 Transacción fallida

A estas alturas del artículo se supone que eres una persona con el privilegio de conocer el funcionamiento a bajo nivel del protocolo SMTP. ¿Y en qué me beneficia dicho conocimiento? Pues para empezar ya tienes las bases para escribir tu propio cliente SMTP. Además de eso... ¿Recuerdas el comando MAIL FROM:<pepe@infomed.sld.cu>? Pues claro, es el comando que define la dirección desde dónde se envía el correo. ¿Qué crees que pasaría si en vez de MAIL FROM:<pepe@infomed.sld.cu> escribiéramos MAIL FROM:<webmaster@infomed.sld.cu>? ¡Exactamente!, el mensaje llegaría a su destino como si hubiera sido enviado desde webmaster@infomed.sld.cu.

[¿Qué tanto puedo explotar este conocimiento?]

Depende de para qué lo uses. La verdad, es muy útil para enviar correos anónimos, pero ni se te ocurra usarlo con fines ilegales porque existen formas de conocer el origen verdadero del mensaje.

[Conociendo el verdadero origen del mensaje.]

Una persona que carezca de los conocimientos aquí expuestos se conforma normalmente con leer el campo "From" de su cliente de correo para identificar el origen de lo que recibe.
Casualmente la edición 28 de este boletín cuando me llego el día 1 de octubre fue desde la dirección de correo Blackhat@x.cu (me imagino que a ustedes también) cosa totalmente nueva porque siempre me llega desde el dominio gmail.com. Sabiendo que x.cu no es un dominio real es evidente que quien envió la revista lo hizo desde un cliente que le permitía poner la dirección de origen que quisiera. Normalmente los clientes de correo nos permiten una opción para visualizar los detalles de la cabecera del mensaje. Aquí están los del mensaje en cuestión.

-----------------------------------------------------------------------------
X-Apparently-To: hoax_ws@yahoo.es via 217.146.177.241; Mon, 01 Oct 2007 00:48:39 -0700
X-Originating-IP: [200.55.156.189]
Authentication-Results: mta431.mail.mud.yahoo.com from=x.cu; domainkeys=neutral (no sig)
Received: from 200.55.156.189 (EHLO mx.rimed.cu) (200.55.156.189)
by mta431.mail.mud.yahoo.com with SMTP; Sun, 30 Sep 2007 20:16:48 -0700
Received: from server-2.ipihlg.rimed.cu (unknown [192.168.157.226])
by mx.rimed.cu (Postfix) with ESMTP id 6FA693524B0;
Sun, 30 Sep 2007 21:54:38 -0400 (CDT)
Received: from 10.0.0.4 (server-4.ipihlg.rimed.cu [10.0.0.4])
(Authenticated sender: rnapoles)
by server-2.ipihlg.rimed.cu (Postfix) with SMTP id 4E1151F11CB;
Sun, 30 Sep 2007 19:17:53 -0400 (CDT)
Received: from phpmailer ([10.0.0.3])
by 10.0.0.4 with HTTP (phpmailer);
Sun, 30 Sep 2007 23:11:58 -0500
Date: Sun, 30 Sep 2007 23:11:58 -0500
To: undisclosed-recipients:;
From: Blackhat4all@x.cu
Subject: BlackHat

Message-ID: <652edaf27edbbf25ae3173eb00c3b50a@10.0.0.4>
X-Priority: 3
X-Mailer: phpmailer [version 1.65]
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="b1_652edaf27edbbf25ae3173eb00c3b50a"
------------------------------------------------------------------------------


Sin duda alguna las líneas más informativas son las siguientes:

Received: from 10.0.0.4 (server-4.ipihlg.rimed.cu [10.0.0.4])
(Authenticated sender: rnapoles)

Según la primera línea, "server-4.ipihlg.rimed.cu" ha sido el verdadero servidor desde el cual ha sido enviado el mensaje y según la segunda línea "rnapoles" es el usuario en dicho servidor que lo envió. Con lo cuál me atrevo a afirmar, sin temor a la pena de equivocarme que mi buen amigo Reinier Napoles (también colaborador de esta revista) es el actual responsable de la ardua tarea de enviar las ediciones a la creciente lista de subscriptores, tarea ya no tan ardua considerando que parece estar usando un script PHP para automatizar el envío ("by 10.0.0.4 with HTTP(phpmailer);").



Artículos relacionados


No hay comentarios: