Email spoofing explained

02/04/12 Seguridad: Spoofing.
Capítulo Quinto -> eMail Spoofing | Alma Oscura
INICIO
Artículos
Gadgets
Android
iPhone/iPod Touch/iPad
Internet
Web
Noticias
Nacionales
Tecnología
Programación
Programas
Proyectos
Redes
Seguridad
Sistemas Operativos
Linux
MAC OS
Windows
Alma Oscura
Un pequeño lugar donde compartir, aprender y divertirse.

Twitter RSS
Buscar
Seguridad: Spoofing. Capítulo Quinto -> eMail Spoofing

Lunes, 8 de febrero del 2010
Publicado en Artículos . Internet . Programas . Seguridad . Windows
Por Theliel
Publicar un comentario
Me gusta
ATENCION: Los ejemplos que se van a mostrar y “tutoriales” tan solo tienen carácter educativo. En ningún aspecto comparto filosofías de invasión a la intimidad, ataques
contra un sistema informático o cuestiones similares. En la medida que sea posible siempre se usarán ejemplos y formas que puedan ser usados por cualquier persona, de forma
que pueda verificar los contenidos escritos. No obstante, por motivos más que obvios, materiales como contraseñas, nombres de usuarios o de hosts, serán omitidos o
modificado en las capturas de pantallas realizadas (o las lineas escritas). Es decir, los ejemplos serán completamente reales, los datos mostrados para poder pertrechar estos
ejemplos a vosotros, no siempre lo serán (Sí lo serán los resultados). Para que esto conste de forma clara, todo material sensible modificado o falso estará resaltado en ROJO.
Por motivos de seguridad, todo el material que sea expuesto aquí (exceptuando software propietario o libre, citaciones expresas o código de terceros) tanto texto, imágenes y
código son propiedad del autor y está completamente prohibido su reproducción completa o parcial en otros lugares, espero que se comprenda.
eMail Spoofing
Casi con toda seguridad, conjuntamente con Web Spoofing, es el Spoofing más usado y/o peligroso que podemos encontrarnos estos días. Por otro lado es el Spoofing
posiblemente que más personas identifican y tratan con él, aun cuando quizás no sepan que se llame así. Y es que a día de hoy, quien no ha recibido un correo electrónico que
parecía venir de él mismo o de cualquier otro usuario, sin que evidentemente fuese dicho usuario quien lo había enviado. Aquí no se debe de confundir eMail Spoofing con virus
que usan nuestras cuentas para reenviarse a nusetros contactos. Un virus en nusetro PC que se expande por correo electrónico usando nuestras propias herramientas, no es
Spoofing.
¿eMail Spoofing? La técnica de modificar (generalmente) el remitente de un correo electrónico, con el fin de aparentar se un correo electrónico genuino. Esto evidentemente es
una suplantación de identidad en toda regla, y es algo completamente ilegal. Para hacerse una idea, clonar una web (Phising) con el objetivo de engañar a alguien para que
introduzca unos datos es ilegal porque casi con toda seguridad no tiene derechos de autor para usar el contenido de la web original. Pero nadie puede denunciarte porque una
persona sea “estúpida” e introduzca unos datos en una web. En cambio, falsear un correo de forma que el remitente sea suplantado es ilegal. Al menos en españa, es ilegal la
suplantación de identidad. Evidentemente el daño que puede causar este tipo de Spoofing es ingente en todos los ámbitos.
Esto crea por ende un debate moral sobre si este tipo de artículos deberían de ser escritos o no. La razón es evidente… de cada 10 personas que puedan leer este artículo, casi
con toda seguridad más de la mitad no les importaría poner en práctica lo que aquí se pueda explicar para hacer uso de dichos conocemientos/formas. Similarmente al Phishing,
eMail Spoofing es un problema más que real. En la medida que pueda intentaré llevar un compromiso entre lo que es informar y lo que pueda ser dar pautas exactas de como
un lector malintencionado podría hacer cosas que no deberían de hacer. Aunque evidentemente no soy el padre ni la madre de nadie. Eso sí… estas prácticas son
completamente ilegales y son delito penal. Más vale no jugar con este tipo de técnicas.
Ahora que hablamos de eMail Spoofing, deberíamos de hacer aparecer el término SCAM. En realidad, lo que hemos llamado Phishing anteriormente (a crear una web
fraudulenta) lo más correcto es llamarlo SCAM, y llamar Phishing a la suplantación de identidad, generalmente debida al eMail Spoofing. He usado anteriormente Phishing para
referirme a la web falsa puesto que el matiz de SCAM es la realización de un Phishing con fines fraudulentos. En mi caso no podría decirse que es un SCAM, dado que tan solo
tiene fines didácticos. De cualquier forma ambos términos se suelen cruzar indistintamente, aunque personalmente para mi, la suplantación de identidad por eMail sería realmente
el Phishing y el SCAM el Web Spoofing cuando se desea engañar a los usuarios para robar su información. De todos modos visto esto, aquí no voy a hablar de Phishing para
no confundir a los lectores, solamente de eMail Spoofing, pero lo explico porque al final de todo hablaremos de Phishing.
Como hemos dicho en otra ocasión, el problema de estos sistemas y/o ataques no reside en que Internet sea más o menos segura, sino en la intención de cada persona. Si
diseñas una tecnología basada en la censura y en el recorte de libertades tendrás posiblemente un sistema mucho más seguro… pero que llega a infinitamente menos personas,
blog.theliel.es/2010/02/seguridad-spoofing-capitulo-quinto-email-spoofing.html 1/13
02/04/12 Seguridad: Spoofing. Capítulo Quinto -> eMail Spoofing | Alma Oscura
erradicas la libertad. Internet por ahora (y espero que siempre) es un lugar libre, de tal forma que todo el que quier puede formar parte y construye esa Internet, sin pasar por
gobiernos ni leyes absurdas. Esto implica que la mayoría de todos los protocolos en Internet son en su mayoría simples y pensados para ser usados por cualquiera, no están
pensados para restringir las libertades, y eso produce que siempre existirán personas que quieran aplicar la tecnología para fines nada éticos o siquiera legales.
Antes de entrar en detalles, hay que comprender como se puede enviar un correo electrónico a Internet. Aunque para muchos un eMail no es más que un texto escrito en el
ordenador y enviado a través de nuestro navegador gracias a los portales de Gmail o Live, los correos electrónicos son mucho más que todo ello. SMTP es el responsable de
los correos electrónicos, es el protocolo que hace posible este envío de información. La mejor forma de comprender el sistema de eMail, es asimilarlo siempre al correo postal
ordinario. Cuando enviamos una carta a un destinatario necesitamos conocer antes que cualquier otra cosa la dirección de dicha persona, su nombre y apellidos, código
postal… y del mismo modo escribir un remitente (si queremos) en el sobre. Pues el eMail es exactamente igual, vamos a ver como podrían ser las equivalencias:
Correo Ordinario ————————————————–> Correo Electrónico
Destinatario: Nombre y Apellidos ——————————> Destinatario: Nombre y Apellidos (Por ejemplo: Theliel Smith)
Dirección: Calle y Número/bloque —————————–> Dirección: UserID y Realm (Por ejemplo: eMailSpoofing@Theliel.es, eMailSpoofing es el UserID y @Theliel.es
el Realm)
Código Postal ——————————————————-> Registro MX en las bases de datos DNS (Por ejemplo: smtp.europe.secureserver.net)
Remitente: Nombre y Apellidos ———————————> Remitente: Nombre y Apellidos (Por ejemplo: Sandra Smith)
Dirección Remitente ———————————————–> Dirección: UserID y Realm (Por ejemplo:Sandra@live.com, Sandra es el UserID y @live.com el Realm)
Código Postal Remitente ——————————————> Servidor SMTP (Por ejemplo: smtp.live.com)
En realidad como se puede apreciar es simplemente llamar a cada cosa de forma diferente y comprender el esquema básico de esto. Cuando se comprende, se comprende
igualmente los fallos de seguridad que podría tener el esquema, pero como digo, no se planeó que fuera un sistema rígido y restrictivo, sino abierto. Esta imagen tomada de la
Wiki nos muestra más o menos el proceso:
Anque la jerga pueda ser complicada, es igual que si fuera un correo ordinario. Digamos que Alice quiere enviar un correo ordinario a Bob. Para ello rellena los datos en la
carta y la tira al buzón. El cartero la lleva a la oficina postal de su localidad, es decir, la oficina que corresponde al código postal del remitente, que en un correo electrónico
correspondería a su servidor SMTP. Una vez en la oficina, esa carta debe de ser procesada para saber su destino. Se comprueban los datos del destino (es decir de Bob), para
conocer el destino del código postal escrito en la carta (o la entrada MX en caso de un correo electrónico). El ordenador devuelve al operario la oficina a la que deben de
enviar dicha carta, es decir… la dirección de la oficina de correos que se encarga de dicho código postal. En el caso de un corro electrónico el ordenador que procesa dicha
información se llama servidor DNS. Una vez que el operario de la oficina postal tiene los datos de a qué oficina enviar la carta (no a que dirección del usuario final) llama al
transportista y envía todas las cartas para dicha oficina. En Madrid llegan todas las cartas destinadas a dicha oficina (paso 4 del gráfico). En dicha oficina se verifican las
direcciones físicas de los destinatarios para comprobar que no hay errores y el cartero las repartirá de forma correcta. En el caso de un correo electrónico vemos que es
exactamente lo mismo, los datos llegan al servidor que gestiona el servicio de correo electrónico del destino, este procesa el correo y lo entrega en la bandeja de entrada de su
usuario.
No perdamos de vista el objetivo de esta parte, eMail Spoofing. En el esquema que acabamos de explicar y pensando en la suplantación, ¿Como podríamos modificar el
remitente en una carta ordinaria? Es facil, tan solo escribiendo unos datos falsos en el remite de la carta. Con el eMail pasa exactamente lo mismo. ¿Pero entonces es así de
simple? Sí y no, como de costumbre.
En primer lugar prácticamente ningun programa nos permitiría modificar el remitente del eMail.
En segundo lugar en los servidores SMTP existne medidas de seguridad para evitar el SPAM. Siguiendo con la misma analogía, imaginar que yo he puesto de remitente a
Julia Robert con residencia en estados unidos. Cuando la carta la recoge el cartero imaginar que mira el remitente y ve algo así. El operario podría automáticamente
romper la carta, puesto es imposible que el haya podido recoger una carta del buzón con tal dirección en su oficina postal. Es decir, un método de desechar esos correos
fraudulentos sería automáticamente bloquear cualquier remitente que no pertenezca su nombre y apellidos, dirección y código postal de la oficina que recoge la carta.
Esta medida es usada casi en el 100% de los proveedores de correo electrónico, de modo que con dicha protección, sería imposible pretender enviar un correo
fraudulento usando un servidor SMTP concreto el cual no reconoce el remitente como legítimo.
En tercer lugar, la oficina podría ser aun más lista, y simplemente solicitar el carnet de identidad de cada persona que desea enviar una carta. Una vez se presenta el
carnet de Identidad, es la misma oficina quien graba el remitente en la carta. Este otro sistema es también ampliamente usado con los correos electrónicos (evidentemente
en similitud, no literalmente)
Es decir, aunque el protocolo inicial es simple, a raiz de sus más que normales carencias se han construido filtros y sistemas de seguridad para evitar el uso de la suplantación de
identidad. Con todo esto se podría pensar que entonces no es posible realizar un eMail Spoofing, y todos sabemos que no es cierto. ¿Con todas estas medidas es posible
realizar eMail Spoofing? Si, y existen 3 formas (que ahora mismo pueda pensar yo). Todas ellas tienen sus pros y sus contras. Antes de entrar en ellas vamos a explicar un poco
que es un servidor SMTP relay.
Originalmente, no se contemplaba como hemos dicho problemas de suplantaciones de identidad ni cuestiones similares, y existian los llamados Servidores Relay abiertos. Dado
que cualquier persona puede crear un servidor de correos, este servidor de correos se puede configurar como hemos dicho como se desee. Estamos acostumbrados a ver que
nuestros servidores SMTP de gmail o de Live requieren de un nombre de usuario o una contraseña. Pero si se desease, podríamos crear un servidor de eMail que no requiriese
autentificación de ningún tipo, y simplemente especificásemos remitente y destino (el que quisiésemos). Años atrás, estos relays abiertos eran muy comunes, el problema que
tenía por tanto era que cualquier persona podía enviar correos desde estos servidores para crear cantidades ingentes de SPAM. Ante este problema, casi todos los
proveedores de eMail actuaron bloqueando en listas negras los correos que proviniesen de ciertos servidores Relay abiertos. Esta fue la primera medida que se comenzó a
tomar, y tal es el efecto que a día de hoy no estoy seguro de que quede algún servidor SMTP relay abierto.
Sin embargo, la posibilidad de poder modificar el destinatario de un correo no solo es negativo, muchas veces es una función necesaria. Imaginar por ejemplo cuando tenemos
la propiedad de dos cuentas de correos diferentes y preferimos usar un solo servidor SMTP para ambas. Por ejemplo esto lo permite realizar gmail previa verificación de
dirección de correo. Otro ejemplo clásico es alguna suscripción a algún servicio, y este servicio envía correos electrónicos directamente a nuestro nombre para que el
destinatario pueda siquiere incluso con “responder” alcanzar nuestra dirección. Aun así, existen multitud de ocasiones en las que es deseable poder modificar los remitentes.
Ante esta necesidad comenzaron a aparecer los servidores Relay cerrados.
A diferencia de los Relay Abiertos, los Relays cerrados son actualmente los servicios de correo electrónico que con más frecuencia nos son ofrecidos. Muchos quizás no
comprendan la diferencia entre un servidor SMTP Relay y no Relay. Cuando usamos el término de Relay, nos referimos a un servidor SMTP que acepta conexiones
teóricamente de cualquier usuario. Si pensamos por ejemplo en el servidor SMTP de Gmail: smtp.gmail.com, no deja de ser un servidor Relay, puesto que el mismo servidor
SMTP es el que usan todos prácticamente. Lo que sucede es que es un Relay cerrado, con ciertas restricciones. Pero igualmente podemos encontrar servidores SMTP puros,
dedicados. El ejemplo más clásico de estos servidores son algunos servidores de correos empresariales o particulares. Normalmente cualquier persona que posea un dominio o
un servicio de hosting, puede crear su propio servidor SMTP sin necesidad de un servidor Relay (aunque se puede configurar como tal)
A día de hoy como se ha dicho, la mayoría de los servidores SMTP son relay, y cada uno implementa las medidas que cree necesarias. Por ejemplo, un servidor SMTP relay
de una empresa lo normal es que permita el relay local-> local local -> Internet y bloque por defecto cualquier intento de acceso tipo Internet -> Internet Internet -> Local. Es
decir, permite a los usuarios dentro de la propia red empresarial a enviar correos, pero dicho servidor relay está bloqueado externamente. Otro ejemplo sería gMail. Gmail
permite el acceso local -> local local -> Internet Internet -> Local e Internet -> Internet. Pongo el ejemplo de Gmail a conciencia… si permite todo tipo de usos… ¿no debería
de ser un servidor Relay abierto? No. Desde la época de los relay abiertos, muchos proveedores decidieron otra medida, rechazar todos aquellos correos que no realicen
proceso de autentificación en su servidor de correos SMTP. Para el servidor destino es facil comprobar esto, tan solo tiene que realizar una conexión a nuestro servidor y
comprobar si se requiere o no. La mayoría de los proveedores no permiten circular por sus redes correos que no han sido autentificados, o añadidos a una “lista blanca”. ¿Y
que es la autentificación? Ni más ni menos las credenciales que necesitamos para poder enviar o recibir correos. Existen aun muchos servidores SMTP relay los cuales no es
necesario realizar una autentificación, pero tienen filtros que impiden el relay de sus servicios Internet – > Internet Internet -> Local. Aunque todo esto suene un poco
complicado, todo cobrará sentido más adelante con los ejemplos.
Veamos ahora sí las tres formas que podemos encontrar de eMail Spoofing:
Servidor de Email propio:
Como hemos dicho Internet es libre. Tu puedes agradecer a Gmail su servicio gratuito de Internet, pero también te sometes a sus políticas de Spam, a sus restricciones, a sus
filtros… a fin de cuentas gMail es tu oficina de correo postal. Pero si internet es libre… ¿puedo construir un servidor de correos yo mismo? Sí. Es decir, es como si pudieses
crear tu propia oficina postal. Al ser tu servidor, tu eliges las normas. Internet la construimos todos, el protocolo SMTP es estandar y cualquiera puede usarlo. Por tanto
podríamos crear un servidor SMTP en casa y arreglarlo todo de tal forma que prácticamaente podríamos enviar correos desde el remiente que quisiésemos. ¿Por qué? Ya lo
hemos dicho, nosotros decimos las normas que queremos. Ojo!! esto no quiere decir que los correos sean completamente anónimos ni mucho más lejos.
Vamos a expandir esto un poco más. Si hemos comprendido el esquema de funcionamiento de un eMail, para crear nuestro propio servidor lo que hay que hacer sería primero
crear nusetra “oficina”. Lo segundo para que nuestra oficina sea localizable tener en las bases de datos mundiales nuestro código postal registrado, en nuestro caso, tener
registrado nuestro MX en los servidores de DNS. Y nada más.
En realidad no es necesario tener un registro MX si no deseamos recibir correo, el problema de este sistema es que por razones de seguridad y propensión a usar SPAM con
estos sistemas muy simples de crear, la mayoría de los servidores destino no permiten correo procedente de aquellos clientes que no posean un registro MX o que procedan de
IPs que sean estáticas. Por lo demás todo es muy simple. Tan solo sería cuestión de usar cualquier software servidor de correos, configurarlo y listo. No voy a explicar a hacer
esto paso a paso, en este caso tan solo vamos a ver los resultados, pros y contras. En mi caso he usado hMailServer, un servidor de correo gratuito.
Para este primer ejemplo de eMail Spoofing se ha usado el servidor eMail citado. En cada una de las pruebas siempre se han enviado dos copias de los correos con remitentes
falsos, una a gmail y otra a live (hotmail). En una de las pruebas se optó por usar una dirección falsa de Hotmail y en el otro caso una dirección falsa de gmail. El tercer test se
optó por una dirección prueba test.com.
Los resultados son interesantes, y demuestran puntos a favor y en contra de cada proveedor (gmail y hotmail) a la hora de manejar posibles suplantaciones de identidad.
Evidentemente tanto la cuenta de correo theliel@gmail.com y theliel@hotmail.com, no me pertenecen.
Prueba 1: Remitente theliel@hotmail.com, destino mis cuentas de gmail y live:
Gmail en este caso si permitió el acceso del correo y este alcanzó la bandeja de entrada.
Hotmail permitió la recepción pero fue filtrado una vez más como Spam -> Ver notas después de las pruebas
Prueba 2: Remitente theliel@gmail.com, destino mis cuentas de gmail y live:
Gmail no permitió siquiera la entrada del correo, dado que verificó que el remitente theliel@gmail.com tan solo podía enviar correos usando el servidor SMTP de gmail, y no
uno externo. El correo no llegó a abandonar mi gestor de correos.
Hotmail permitió la recepción del correo, pero en este caso llegó como Spam -> Ver notas después de las pruebas
Prueba 3: Remitente theliel@test.com, destino mis cuentas de gmail y live:
Gmail filtró el primer correo como Spam, pero sucesivos correos del mismo destino alcanzaron la bandeja de entrada
Hotmail lo volvió a filtrar como Spam -> Ver notas al final de las pruebas.
Live Spam
Gmail Inbox
En principio se podría pensar que Live tiene un filtrado de Spam mejor que Google. Pero esto esto tiene muchas lecturas. Efectivamente Gmail rechazó de pleno un supuesto
correo de gmail (theliel@gmail.com) simplemente presuponiendo que un correo de ellos tiene que provenir de ellos. Pero fracasó en las otras dos pruebas, dando por buenos
los correos con los remitentes falsos. Por otro lado Live los categorizó todos como Spam.
Cada proveedor tiene sus propias políticas de que es mejor filtrar o que no. Por ejemplo, es evidente que el correo Theliel@hotmail.com era un remitente suplantado, pero
Gmail prefirió no establecerlo a priori como Spam, lo que causa que en ese aspecto debemos de suspender a Gmail. Pero por otro lado bloqueó completamente
Theliel@gmail.com. Live por su parte prefirió no bloquear completamente el correo que provenía supuestamente desde sus propios servidores “Theliel@hotmail.com”, lo cual
es un punto negativo para Live. No obstante fue capaz de filtrar los otros dos correos falsos.
La política por defecto de Gmail es “Ante la duda, lo permito”. La política de Hotmail es “Ante la duda lo bloqueo”. Esto no solo es una cuestión de políticas por desgracia…
sino de dinero. Microsoft con Live presupone que no puedes o no debes de tener un servidor de eMail en tu casa a menos que seas una empresa. En realidad a Microsoft no le
importa el remitente del correo, no los detecta como Spam por ello. Si detecta que posees una IP dinámica ellos presuponen que eres un Spammer. Por otro lado, puedes
pagar a Microsoft un dinero para que categoricen tu dominio como verificado, para que no sea filtrado como Spam. Esto parece injusto, ya que si Internet es libre, cualquiera
podemos querer tener un servidor de Email sin dar cuentas a nadie, y no por ello somos unos Spammers. Google presupone inocencia, y mientras no tenga más datos sobre el
origen de dichos correos no lo categoriza como Spam y lo permite, eso sí… bloquea los correos que no proceden de sus servidores y que es de ellos… cosa más que normal.
A todo esto hay que sumarle un gran problema de seguridad respecto al Spam que tiene Live. Quitando alguna que otra dirección, siempre se pasará a la bandeja de entrada (y
no se considerará Spam) correos de direcciones que ya se han recibido. Es decir, supongamos que en realidad Theliel@hotmail.com ó Theliel@gmail.com fuese la dirección de
un amigo mío y en mi cuenta live ya tuviese algún correo de ellos, ninguno de los dos correos sería filtrado como Spam. Esto es un peligro. Esto es posible pq Live presupone
que los correos no marcados como Spam, son remitentes seguros.
En realidad no podemos ni debemos darle un tirón de orejas a ninguno. Cada cual implementa las políticas que creen más acertadas para filtrar la mayor cantidad de Spam
posible y no filtrar los correos que crean que son legítimos. Pero como en todo, no hay un sistema que sea realmente mejor que otro.
Este sistema de eMail Spoofing se ha podido ver cuales son sus principales deficiencias. Si bien es algo sencillo y rápido de pertrechar, es muy fácil que cualquier proveedor de
servicios pueda detectarnos. Por supuesto, y aunque no haya sido comentado, detectar un usuario este tipo de ataques de eMail Spoofing es muy simple, tan solo tendríamos
que acudir a la cabecera del correo entrante:
Delivered-To: xxxxxxx@gmail.com
Received: by 10.103.197.9 with SMTP id z9cs22623mup;
Sun, 7 Feb 2010 10:54:05 -0800 (PST)
Received: by 10.103.85.4 with SMTP id n4mr3722461mul.128.1265568845523;
Sun, 07 Feb 2010 10:54:05 -0800 (PST)
Return-Path:
Received: from localhost (30.Red-79-158-250.staticIP.rima-tde.net [79.158.250.30])
by mx.google.com with SMTP id u26si17461538mug.45.2010.02.07.10.54.05;
Sun, 07 Feb 2010 10:54:05 -0800 (PST)
Received-SPF: softfail (google.com: domain of transitioning Theliel@hotmail.com does not designate 79.158.250.30 as permitted sender) cli
From: Theliel
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; es-ES; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b2pre Thunderbird/3.0.1
MIME-Version: 1.0
Subject: Test
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Prueba 1
Se puede apreciar perfectamente la IP origen de dicho correo, así como la resolución inversa de ella, que se aprecia claramente como proviene de telefónica. Por otro lado se
puede ver el registro de Google sobre si es SPAM o no lo es. Si leemos lo que nos dice, es un aviso. El host citado no está designado como un emisor permitido.
Servidor Relay SMTP Sin Autentificación
La segunda opción y posiblemente la más usada a la hora de realizar eMail Spoofing, reside en los servidores Relay. Hemos dicho que prácticamente todos los servidores Relay
tienen fuertes medidas de protección para evitar el Spam o la suplantación de identidad. Como hemos dicho a día de hoy continua siendo necesario el papel de los servidores
Relay en los cuales NO EXISTE autentificación previa. Lo que sucede es que estos servidores están disponibles normalmente tan solo a grupos de clientes que pagan por usar
dichos servicios como servicios de email o de hosting, y normalmente con un número determinado de correos diarios permitidos. Por otro lado, generalmente no se permite su
uso externo. El concepto de local o internet se debe de comprender. Si por ejemplo posemos un hosting que nos permite usar su servidor Relay e intentamos hacer uso de él
desde nuestro propio equipo, pronto se dará cuenta cualquiera que la conexión es denegada, puesto que nuestro proveedor tan solo permite el uso del Relay en local. ¿Que
implica esto? Que no podemos directamente hacer uso de dicho servidor, pero dado que en dicho servidor podemos tener herramientas como SSH, PHP… podemos crear
formularios o accesos remotos para poder usar dichos recursos. La idea es claramente poder crear contenido web que nos permita la creación de formularios y otros que
llamen a nuestro servidor relay. Dado que el formulario se encuentra en nuestro servidor web, podrá utilizar el servidor Relay de nuestro proveedor.
Esto tiene una ventaja y un inconveniente. Al ser un servidor “abierto” (que no requiere de autentificación) podemos enviar cualquier correo que deseemos en nombre de quien
sea sin preocupación alguna, y casi con toda seguridad el correo será entregado y no filtrado como Spam. ¿El problema? Es necesario crear un formulario web para ello o usar
SSH para conexión remota o algún sistema similar. Para evitar este tipo de prácticas abusivas de Spam, normalmente existe como he dicho un número finito de correos que
pueden ser enviados al día.
Tanto esta sección como la siguiente, realizaremos conexiones directas en terminal para mostrar los ejemplos, esto nos hará comprender de una forma mucho más clara como
funciona SMTP y el potencial que tiene. Veamos ahora el uso y conexión de un servidor SMTP Relay sin autentificación. Cualquier respuesta por parte del servidor va
antecedida con un código númerico. El resto de texto corre a cargo por el cliente, es decir… tecleado a mano. Recordar que en rojo se resaltará siempre datos modificados por
cuestiones de seguridad.
theliel@Anarchy:~$ ncat -C smtp.relay.com 25

220 smtp.relay.relay.com ESMTP
EHLO TEST
250-smtp.relay.relay.com
250-PIPELINING
250 8BITMIME
Mail from:
553 sorry, your mail was administratively denied. (#5.7.1)
mail from: 250 ok
rcpt to: 553 sorry, relaying denied from your location [79.158.250.30] (#5.7.1)
quit
221 smtp.relay.relay.com Goodbye.
Como se puede observar, este servidor relay en concreto tiene una lista negra de hosts que no se pueden especificar como remitentes (a priori). Cualquier intento de crear un
remitente gmail, live, hotmail… devolverá el error mostrado. No obstante en principio, cualquier otro host no tan “famoso” es completamente aceptable. Aun así esto no implica
nada, ya veremos que el secreto último del Spoofing no se encuentra en la orden “mail from” del protocolo SMTP. Como se puede observar el servidor no solicita ningún tipo
de autentificación (vendría listada como se verá más adelante). Por último podemos ver la protección de dicho servidor de no permitir conexiones externas. La IP mostrada es
mi IP de telefónica en este momento, y el servidor la rechaza por ser una dirección externa a él. Es decir, para poder usar este servidor relay es necesario usarlo dentro de la
misma infraestructura. ¿Como podemos realizar esto? Ya lo hemos dicho, o por medio de PHP y un formulario web por ejemplo, o quizás podamos realizar un telnet al servidor
desde dentro del propio servidor mediante una conexión SSH:
-bash-3.2$ telnet smtp.relay.com 25

Trying xxx.xxx.xxx.xxx…
Connected to smtp.relay.com (xxx.xxx.xxx.xxx).
Escape character is ‘^]’.
220 smtp.relay.relay.com ESMTP
EHLO TEST
250-smtp.relay.relay.com
250-PIPELINING
250-SIZE 30457280
250 8BITMIME
mail from: 250 ok
rcpt to: <xxx@gmail.com>
250 ok
data
354 go ahead punk, make my day
From: Theliel To: Theliel <xxx@gmail.com>
Subject: Test
Prueba relay
.
250 ok 1265487183 qp 5150 by smtp.relay.relay.com
data
503 MAIL first (#5.5.1)
quit
221 smtp.relay.relay.com Goodbye.
Connection closed by foreign host.
En esta ocasión, el servidor no devuelve un error dado que se está ejecutando en local. El servidor está protegido para que no se acepten identidades (mail from) desde Gmail,
pero en cambio, en el mismo cuerpo del mensaje si es posible especificar el remitente con “From”, en el cual si es posible especificar gmail, live o la dirección que se desee. El
correo mostrado es entregado a la perfección a la bandeja de entrada de mi cuenta gMail. En este punto hay que recordar algo que se comentó anteriormente. Muchos
servidores no aceptan el paso de correos por sus servidores si este no está autentificado. En este caso estamos enviando un correo sin autentificación, lo cual quiere decir que
existirán servidores que no permitan la recepción desde este tipo de servidores… este es el ejemplo de live. En realidad es un problema y una falta de respeto por parte de
Microsoft, dado que esto es posible usarse con fines legítimos. Por el contrario si pagas a microsoft podrías hacer que el servidor se añadiese a una lista blanca que permitiese
su uso sin necesidad de autentificación.
Hay que tener en cuenta que este tipo Spoofing es altamente anónimos. Sí, nuestra IP quedará registrada en el servidor relay, pero ¿qué sucedería si realizáramos la conexión
SSH mediante un servidor proxy?
La búsqueda de servidores Relay “abiertos” es algo muy interesante. Permite a los atacantes un alto índice de Spam sin apenas molestarse lo más mínimo aprovechándose de
las infraestructuras de terceros. Por otro lado, si se tuneliza el tráfico mediante un servidor proxy, esto brinda un anonimato increíblemente alto. Aquí somos personas de bien, y
dado que todo esto tan solo tiene fines didácticos no me importa no tunelizar el tráfico por un proxy. Lo que estábamos comentando es la búsqueda de servidores Relay
“abiertos”. ¿Pero como hacerlo? Ya hemos dicho que para que un servidor pueda ser alcanzado, debe de tener un registro MX asociado a él en los servidores de DNS. Estos
registros MX nos están diciendo directamente el servidor SMTP “al descubierto” que tienen. Gracias a herramientas como DIG, podemos consultar estos registros e intentar
encontrar un relay abierto en dicho servidor:
C:\Users\Theliel>dig gmail.com MX
; <<>> DiG 9.7.0rc2 <<>> gmail.com MX

;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 85
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;gmail.com. IN MX
;; ANSWER SECTION:
gmail.com. 3008 IN MX 5 gmail-smtp-in.l.google.com.
gmail.com. 3008 IN MX 20 alt2.gmail-smtp-in.l.google.com.
Un buen punto de partida sería comenzar por el servidor SMTP con una preferencia menor (supuestamente el primero a usarse). A continuación comprobar si se puede hacer
algo con dicho servidor:
C:\Users\Theliel>ncat -C gmail-smtp-in.l.google.com 25
220 mx.google.com ESMTP 31si565032vws.79
EHLO TEST
250-mx.google.com at your service, [79.158.250.30]
250-SIZE 35651584
250-8BITMIME
250-ENHANCEDSTATUSCODES
250 PIPELINING
Bingo!! El servidor no responde con ninguna línea de que necesite autentificación, luego a priori podríamos pensar que hemos encontrado un buen objetivo. Si profundizamos un
poco más:
250 PIPELINING
mail from: 250 2.1.0 OK 31si565032vws.79
rcpt to: 550-5.1.1 The email account that you tried to reach does not exist. Please try
550-5.1.1 double-checking the recipient’s email address for typos or
550-5.1.1 unnecessary spaces. Learn more at
550 5.1.1 http://mail.google.com/support/bin/answer.py?answer=6596 31si565032vws.79
rcpt to: 250 2.1.5 OK 31si565032vws.79
Con lo que nos muestra, ya podemos hacernos una idea de lo que está pasando. Efectivamente es un servidor relay abierto, pero tan solo permite conexiones local -> local
internet -> local. Es decir, podemos falsear como deseemos con él nuestra identidad, pero el destinatario tan solo puede ser un correo “gmail”, es decir, una dirección local. Si
llegamos a enviar el correo a nusetra cuenta de gmail, efectivamente el correo es recivido por nuestra bandeja de entrada, dependiendo de la IP desde donde lo hagamos, será
filtrado como Spam o no.
Lo importante en este caso no es si el correo se filtra como SPAM o llega, lo importante es ver como con dos simples pasos es posible “apropiarse” de un servidor relay. No
es malo, solamente sucede que todo puede ser usado para fines buenos o fines malos. Por último veamos que sucede si hacemos lo mismo con live:
C:\Users\Theliel>ncat -C mx1.hotmail.com 25
220 bay0-mc3-f33.Bay0.hotmail.com Sending unsolicited commercial or bulk e-mail to Microsoft’s computer network is prohibited. Other restrictions are
found at http://privacy.msn.com/Anti-spam/. Violations will result in use of equipment located in California and other states. Mon, 8 Feb 2010 04:18:2
6 -0800
EHLO
250-bay0-mc3-f33.Bay0.hotmail.com (3.10.0.73) Hello [79.158.250.30]
250-SIZE 29696000
250-PIPELINING
250-8bitmime
250-BINARYMIME
250-CHUNKING
250-AUTH LOGIN
250-AUTH=LOGIN
250 OK
En este caso el servidor con el que hemos dado requiere autentificación, luego tan solo podríamos usarlo en caso de tener unos credenciales válidos. Aun así, se podría
comprobar su seguridad, pero por ahora estamos buscando servidores sin autentificación, y en este caso es un palo de ciego (pero si no se intenta, no se puede saber). En
teoría, cuando se solicita autentificación se dice… pero que suceed si intentamos forzar aun así?:
mail from:
250 test@hotmail.com….Sender OK
rcpt to:
250 test@live.com
data
354 Start mail input; end with .
From: Theliel
To: Theliel
Subject: TEST
Prueba 10
.
250 mail from IP 79.158.250.30 soft failed sender ID check. Please ensure this IP is authorized to send mail on behalf of [hotmail.com]
Bueno… se ha intentado. Efectivamente contra todo pronóstico, el servidor no nos ha expulsado por no estar autentificado, pero aun así los servidores de MS no permiten usar
dicho relay si no se tiene una IP autorizada para ello… y evidentemente la mía no lo es.
Prácticamente cualquier registro MX que veamos puede ser susceptible a ser utilizado por un atacante, el problema es que normalmente tendrán alguna política de restricción.
Otras veces podemos comprobar que existen diferentes registros MX. Que un registro MX nos lleve a un servidor SMTP más protegido, no implica que otro pueda no pueda
llevarnos a un servidor menos desprotegido. Estos servidores no es que sean todos inseguros, lo que sucede como ya dijimos en su momento, es que siempre se presupone un
uso debido de las tecnologías actuales. Aunque aquí pueda mostrar los riesgos que pueden existir, siempre defenderé un Internet limpia y libre. La mejor forma de evitar estos
ataques es el conocimiento, por parte de los administradores de sistemas y por parte de los usuarios que pueden ver comprometida su seguridad.
Servidor SMTP Con Autentificación
El uso de servidores de correo propios tiene el problema de que casi todo el contenido será marcado como Spam. El uso de servidores Relay sin autentificación tiene el
problema de que muchos proveedores filtran dichos correos. Lo ideal por lo tanto sería poder contar con servidores Relay los cuales podamos acceder con autentificación y
que no estén filtrados por nadie. El problema de este tipo de servicios es que si te autentificas en un sistema, es mucho menos anónimo, por no decir que estos servidores
puedan implementar grandes medidas de seguridad para evitar el Spoofing.
Lo primero que podríamos intentar es realizar lo que se hizo con anterioridad pero usando nuestra cuenta de gmail. El arte del “hacking” es presuponer que en algún momento
los programadores metieron la pata, y esa metedura de pata se usa para lograr los fines. Un atacante esta premisa la conoce bien. Podemos presuponer que gmail es
completamente invulnerable y no intentarlo, o tener la esperanza de hacer saltar por los aires la seguridad de ellos, buscando un olvido de los programadores. Vamos a
presuponer que no conocemos en absoluto el sistema de correos de gmail ni de live, y queremos simplemente investigar un poco. En este caso lo más probable es que una
búsqueda por registros MX no nos devuelva nada interesante, y dado que estamos buscando servidores SMTP con autentificación, vamos a tener que usar o partir de algún
servidor del cual tengamos unas credenciales.
Primero vamos a ver como se comporta gmail. Necesitamos por lo cual los datos de acceso al servidor SMTP de gmail para ello:
Servidor: smtp.gmail.com, Puertos 25, 465, 587. En teoría, sabemos que el puerto por defecto es 25 y es el puerto por defecto también de STARTTLS. Por otro lado
sabemos que normalmente 465 se usa para SMTP sobre TLS, y 587 suele ser usado para lo mismo. Visto esto, lo normal sería intentar acceder por puerto 25 para evitar TLS:
C:\Users\Theliel>ncat -C smtp.gmail.com 25
220 mx.google.com ESMTP 16sm3074639ewy.6
EHLO TEST
250-SIZE 35651584
250-8BITMIME
250-STARTTLS
250 PIPELINING
mail from:
530 5.7.0 Must issue a STARTTLS command first. 16sm3074639ewy.6
Lo cual nos está indicando claramente que por ese puerto tan solo podremos acceder mediante STARTTLS (un sistema similar a TLS… por así decirlo). Vemamos que
obtenemos por los otros dos puertos:

220 mx.google.com ESMTP 24sm11618069eyx.6
EHLO TEST
250-SIZE 35651584
250-8BITMIME
250-STARTTLS
250 PIPELINING
mail from:
530 5.7.0 Must issue a STARTTLS command first. 24sm11618069eyx.6
quit
221 2.0.0 closing connection 24sm11618069eyx.6
En el primer caso se queda esperando… esto es normal. Mientras que STARTTLS inicia una sesión encriptada dentro de la propia sesión ya establecida, TLS/SSL desde el
momento de la conexión se realiza una sesión encriptada. Por tanto se queda esperando a recibir los certificados e iniciar el proceso de encriptación del canal. En el segundo
caso podemos compronar que el puerto 587 se está usando igualmente para STARTTLS.
Por tanto vamos a intentar conectar al servidor SMTP mediante STARTTLS y mediante TLS. Una vez establecido el canal seguro, deberíamos de poder hablar con el servidor
SMTP como hemos estado haciendo anteriormente:
theliel@Anarchy:~$ openssl s_client -starttls smtp -crlf -connect smtp.gmail.com:25

CONNECTED(00000003)
[ELIMINADO POR ACORTAR]
Start Time: 1265640813
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)
—
250 PIPELINING
EHLO TEST
250-SIZE 35651584
250-8BITMIME
250-AUTH LOGIN PLAIN
250 PIPELINING
AUTH LOGIN
334 VXNlcm5hbWU6 <- Significa “Usuario”, codificado en base64 -> $echo “dGVzdEBnbWFpbC5jb20=” | openssl enc -base64 -d
dGVzdEBnbWFpbC5jb20= <- Significa “test@gmail.com” condificado en base 64 -> $echo -n “test@gmail.com” | openssl enc -base64
334 UGFzc3dvcmQ6
Y29udHJhc2XDsWFwcnVlYmE=
235 2.7.0 Accepted
mail from:
250 2.1.0 OK 26sm6346727fks.37
rcpt to:
250 2.1.5 OK 26sm6346727fks.37
data
354 Go ahead 26sm6346727fks.37
From: Theliel
To: Theliel <test@live.com>
Subject: Test
Prueba 1
.
250 2.0.0 OK 1265640966 26sm6346727fks.37
quit
221 2.0.0 closing connection 26sm6346727fks.37
Es necesario usar OpenSSL para poder iniciar la sesión y continuar con STARTTLS. En este caso Gmail acepta cualquier origen especificado en “mail from”. Esto podría ser
un paraíso para los Spammers. Y es que aunque todo el proceso parezca que funciona perfectamente bien, cuando acudimos a la bandeja de entrada vemos que los servidores
de Gmail han modificado el remitente, de forma que coincida con los datos de la autentificación. Es decir, da igual que se especifique en “mail from” ó “from”, gmail usará
nuestra verdadera identidad. Luego mediante este servidor no es posible realizar un Spoofing. He optado por la autentificación “LOGIN”, la cual nos muestra por pantalla que
introduzcamos el usuario y la contraseña. Tanto las peticiones como las respuestas se deben de hacer en base64
Podemos intentarlo por el puerto 465 y usando TLS:
C:\Users\Theliel>ncat -C –ssl smtp.gmail.com 465

220 mx.google.com ESMTP 23sm11723882eya.3
EHLO TEST
250-SIZE 35651584
250-8BITMIME
250 PIPELINING
AUTH PLAIN
334
AHRlc3RAZ21haWwuY29tAGNvbnRyYXNlw7FhcHJ1ZWJh
235 2.7.0 Accepted
mail from:
250 2.1.0 OK 23sm11723882eya.3
rcpt to: <test@live.com>
250 2.1.5 OK 23sm11723882eya.3
data
354 Go ahead 23sm11723882eya.3
from: Theliel
to: Theliel <test@live.com>
subject: Test
Prueba 2
.
250 2.0.0 OK 1265642518 23sm11723882eya.3
quit
221 2.0.0 closing connection 23sm11723882eya.3
Como podemos comprobar, obtenemos exactamente lo mismo. Aun así me ha servido el ejemplo para mostrar en este caso la conexión mediante SSL (se puede usar si se
prefiere openSSL) y como en esta ocasión hemos preferido usar autentificación “PLAIN”. En este caso, se debe de introducir las credenciales en base 64 pero con un formato
específico. La mejor forma de llevar a cabo esto es quizás utilizar algún lenguaje de scripting para que nos haga la labor más simple. Se podría componer pasando a base64
primero por un lado el ID, despues la arroba, despues el realm, despues la contraseña… es más comodo hacer lo siguiente en Perl:
“perl -MMIME::Base64 -e ‘print encode_base64(“\000test\@gmail.com\000contraseñaprueba”)’”
Nos quedaría otro método de autentificación por ver, que sería CRAM-MD5, el más seguro. De todos modos dado que que gmail solo permite mediante la creación de una
sesión encriptada, no importa usar CRAM-MD5, el cual suele usarse cuando no es posible una comuncación cifrada.
En esta ocasión ninguna de las pruebas realizadas ha tenido ningún tipo de éxito, pero tan solo hemos probado con Gmail. Esto mismo podríamos hacerlo con cualquier servidor
SMTP al cuan tengamos acceso. Como último ejemplo vamos a ver que sucedería con Live (hotmail):
ehlo test
250-BLU0-SMTP59.blu0.hotmail.com Hello [79.158.250.30]
250-TURN
250-SIZE 35840000
250-ETRN
250-PIPELINING
250-DSN
250-8bitmime
250-BINARYMIME
250-CHUNKING
250-VRFY
250 OK
auth login
334 VXNlcm5hbWU6
xxxxxxxx
334 UGFzc3dvcmQ6
xxxxxxxx
235 Authentication succeeded
mail from:
250 2.1.0 test@hotmail.com….Sender OK
rcpt to:
250 2.1.5 test@live.com
data
354 Start mail input; end with .
from: Theliel
to: Theliel
Subject: TEST
Prueba 2
.
250 2.6.0 Queued mail for delivery
Bingo!! En un principio se podría pensar que sucede exactamente lo mismo que con gmail. En cambio, si miramos la bandeja de entrada ahora si que nos topamos con una
interesante noticia… el mensaje llega correctamente a la bandeja de entrada y con el remitente completamente suplantado!! Vemos aquí un grabe agujero de seguridad por
parte de MS, dado que cualquier usuario con una cuenta live unos cuantos conceptos podría suplantar cualquier identidad que quisiese y sin que el correo sea considerado
SPAM. Evidentemente no es oro todo lo que reluce y si se mira un poco más a fondo uno comprobaría el origen REAL del correo. Pero en principio pasaría completamente
por real.
Como hemos visto, es raro encontrar un sistema que sea completamente confiable y segudo. Cuanto más experimentas y pruebas, te das cuenta que prácticamente los fallos en
la seguridad están a la orden del día. Muchos de dichos problemas son más que sabidos, pero quizás se necesitan tal y como están por otros motivos.
Hemos visto como un atacante podría crear un servidor de correo. Hemos visto como un atacante podría buscar y utilizar servidores relay. Hemos visto como podemos incluso
usar nuestros propios servicios de correo para estos fines. Es decir, por desgracia es muy fácil a día de hoy suplantar una identidad. Esto sumado al Web Spoofing o URL
Spoofing, es un arma terrible para los Spammers, Hackers… y toda la prole.
En la creación de esta parte, Email Spoofing, además de los datos suministrados, casi todos los servidores que he puesto a prueba con fines de redacción, antes o después
mostraban una vulnerabilidad, un acceso, algo que podría mejorarse considerablemente.
Por tanto… ¿como podemos defendernos ante esta más que visible amenaza? Teniendo los ojos abiertos. No hay una norma… quizás la única es desconfiar, y cuando algo nos
hace sospechar acudir a las cabeceras de los correos para ver la verdadera procedencia de este. En el mejor de los casos nos podrá decir el correo original, en el peor de los
casos tendremos que conformarmos con la IP del remitente real. El peor escenario? que estén usando contra nosotros un servidor SMTP relay al cual se haya accedido
mediante proxy, en cuyo casi no tendríamos prácticamente nada.
Es evidente que no se puede sospechar del 100% de los correos, pero si tener presente que en cualquier momento un correo de nuestra paraje, amigo, familiar… puede que no
sea realmente de ellos. Por supuesto hay que tener en cuenta, que las personas no se dedican a esto para molestar, y que el 90% de este uso es con fines de SPAM, a fin de
cuentas, tal y como comencé al inicio… ¿Quien no ha recibido alguna vez un correo falso?
Seguridad: Spoofing. Capítulo Quinto -> eMail Spoofing
Comentarios ( 5 )
Trackbacks ( 0 )
Publicar un comentario
1.
Robert Carlos
Martes, 1 de marzo del 2011 17:11
RESPONDER
CITAR
Hola muy bueno el articulo

me sirvio mucho.
Estoy programando un servidor SMTP y me pasa exactamente lo de que el gmail me ha modificado el remitente,
como se solucionaria esto?
seria ya poniendo el SMTP server en un dns con MX?

porque las practicas las hago en mi pc
o requiere algo mas
gracias por el apoyo
saludos…
2.
Theliel
Martes, 1 de marzo del 2011 17:26
RESPONDER
CITAR
Cual es el problema exactamente, no he terminado de entendederlo.
Según tu pregunta, gmail te estaría efectivamente modificando el “from” por el “mail from”. Pero esto no lo puedes evitar. Si usas el servidor SMTP de Google, te tienes
que ceñir a sus reglas, cualquier cuenta de google que acceda por SMTP, el from si no coincide con el mail from será reescrito por google, a menos claro que dicho
“from” esté dado de alta como emisor autentificado, cuestion que podemos realizar desde el propio Gmail.
Si estas programando un servidor SMTP propio, esto no tiene porqué afectarte lo más minimo, ya que solo se trata de un sistema de seguridad de los propios servidores
de Gmail.
3.
Robert Carlos
Miércoles, 2 de marzo del 2011 21:40
RESPONDER
CITAR
Muchas gracias por contestar
aber si tu me puedes ayudar
deja replanteo la pregunta,
En mi programacion del SMTP llegaron correos de a@midominio.com para b@gmail.com
osea tengo que hacer un relay de mi cuenta local y reenviar este correo al destino real que seria b@gmail.com
Tengo una cuenta perosnal de x@gmail.com para poder autenticarme lo hago por el puerto 587
envio todos lo parametros incluyendo STARTTLS me autentico y llego hasta
235 2.7.0 Accepted
logro enviar el correo

pero llega como dices con remitente cambiado me dice que el correo lo envia x@gmail.com cuando enrealidad lo manda a@gmail.com
entiendo que fue porque me autentique con x@gmail.com

pero pues no podria logearme con b@gmail porque no se la contrasena solo quiero entregarle un correo que le pertenece y lo envia a@midominio.com.
Mi pregunta seria si esto es porque las pruebas aun no las monto sobre un servidor que tenga su MX
o estoy siguiendo mal el protocolo para la entrega de correo a gmail de otros dominios
porque ami si me llegan de otros dominios los correos con el remitnte correcto.
Sabes las reglas que requiere gmail

Gracias por tu apoyo es la unica pagina que muestra mi problema ojala y pudieras ayudarme
saludos…
4.
Robert Carlos
Miércoles, 2 de marzo del 2011 22:24
RESPONDER
CITAR
Una disculpa no cambia el remitente

cambia el Sender
o por asi decirlo me cambia el

From: a@midominio.com
por
From: x@gmail.com
osea el usuario con el que me autentique
gracias…
5.
karla
Viernes, 28 de octubre del 2011 06:21
RESPONDER
CITAR
HOLA…ME PARECIO MUY INTERESANTE TU ARTICULO.

QUISIERA VER SI ME PUEDES AYUDAR EN LO SIGUIENTE:
NECESITO REALIZAR UNA PRACTICA POR EMAIL SPOOFING, QUISIERA SABER CON QUE HERRAMIENTA LO PUEDO REALIZAR, NO
ENTIENDO MUY BIEN LO DE HARMAR MI PROPIO SERVIDOR..OJALA ME PUEDAS AYUDAR ES PARA UNA PRACTICA DE MI ESCUELA,.TE LO
AGRADECERIA MUCHO
DE ANTE MANO MUCHAS GRACIAS
URL del Trackback http://blog.theliel.es/2010/02/seguridad-spoofing-capitulo-quinto-email-spoofing.html/trackback
1. Sin Trackbacks aun.
NOMBRE( requerido )
E-MAIL( requerido ) - no será publicado -
URL
Enviar Comentario
Volver a arriba
Sobre Mí
¿Quien soy? De donde vengo, a donde voy... Solo un poquito sobre mí.
¿Alguna sugerencia, pregunta, corrección... que quieras hacer?
ENTRADAS RECIENTES
Comparativa Navegadores 2012/Q1: Internet Explorer 10, Firefox 14.0, Chrome 19.0, Safari 5.2, Opera 12
Pwn2Own 2012: Chrome averguenza, IE y Firefox KO
Google Play
Angry Bird en Facebook: Como matar el tiempo “Hackeándolo”… y por supuesto aniquilando a esos malditos cerdos verdes
Elvira Lindo: “Lo que no queremos ver”
Vulnerabilidades en 2011: Windows 7, MAC OS Snow Leopard/Lion, SmartPhones y Navegadores
iPoo: Un retrete que cuesta el doble, sí, pero con estilo
Feliz Navidad y Prospero Año 2012
Samsung Nexus Vs iPhone 4S: Hardware, Software, Medios de comunicación…
Redes: ¿MTU máximo u Óptimo? (Actualizado)
Comentarios Recientes
Zairoud: Excelente comparativa, muchas gracias por tu trabajo. Saludos!

SBI-boy: Un buen resumen de lo que se trata este evento Ya salio el iPad 3 tendras un articulo...
Theliel: Estoy terminando la nueva comparativa, si quieres espera un par de días y le echas un...
Fernan: Hola, excelente analisis. Tengo Chrome pero lo deje de usar, me consumia mucho uso de...
mekkon: Muy buen articulo, casi en todas partes tenían el mismo resumen sobre el tema, aquí si...
Alberto: Muchas felicidades por el excelente análisis técnico y el riguroso desglose de todas las...
Theliel: Intenta explicar las cosas un poco mejor para que podamos entenderte, sino estamos...
gladys vizgarra .alias puppyvizgarra: MIRA TENGO UN PROBLEMITA EN MI CONECCION A INTERNET...
CATEGORIAS
Programas (148)
Noticias (146)
Tecnología (30)
Nacionales (5)
Artículos (72)
Seguridad (67)
Internet (49)
Web (5)
Proyectos (25)
Programación (6)
Sistemas Operativos (121)
MAC OS (81)
Windows (74)
Linux (25)
Gadgets (292)
iPhone/iPod Touch/iPad (276)
Android (36)
Redes (1)
ARCHIVO
marzo 2012 (3)

febrero 2012 (1)
enero 2012 (2)
diciembre 2011 (2)
octubre 2011 (4)
septiembre 2011 (1)
agosto 2011 (1)
julio 2011 (9)
junio 2011 (4)
mayo 2011 (10)
abril 2011 (7)
marzo 2011 (13)
febrero 2011 (11)
enero 2011 (10)
diciembre 2010 (3)
noviembre 2010 (1)
octubre 2010 (4)
septiembre 2010 (3)
agosto 2010 (3)
julio 2010 (11)
junio 2010 (11)
mayo 2010 (6)
abril 2010 (6)
marzo 2010 (7)
febrero 2010 (16)
enero 2010 (14)
diciembre 2009 (4)
noviembre 2009 (9)
octubre 2009 (12)
septiembre 2009 (9)
agosto 2009 (5)
julio 2009 (9)
junio 2009 (18)
mayo 2009 (4)
abril 2009 (3)
marzo 2009 (4)
febrero 2009 (1)
enero 2009 (14)
diciembre 2008 (8)
noviembre 2008 (10)
octubre 2008 (12)
septiembre 2008 (17)
agosto 2008 (21)
julio 2008 (40)
junio 2008 (17)
mayo 2008 (16)
abril 2008 (16)
marzo 2008 (19)
febrero 2008 (25)
Cambiar a la versión para móviles
Alma Oscura por Theliel licenciado bajo Creative Commons Reconocimiento-No comercial-Sin obras derivadas 3.0 Unported License.
Basado en el trabajo de blog.theliel.es.
Para otros permisos que puedan exceder el ámbito de esta licencia, contactar con el autor.

Email spoofing explained

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Email spoofing explained

Uploaded by

Copyright:

Available Formats

02/04/12 Seguridad: Spoofing.

Capítulo Quinto -> eMail Spoofing | Alma Oscura

Un pequeño lugar donde compartir, aprender y divertirse.

Seguridad: Spoofing. Capítulo Quinto -> eMail Spoofing

Correo Ordinario ————————————————–> Correo Electrónico

Código Postal Remitente ——————————————> Servidor SMTP (Por ejemplo: smtp.live.com)

Servidor de Email propio:

Prueba 1: Remitente theliel@hotmail.com, destino mis cuentas de gmail y live:

Prueba 2: Remitente theliel@gmail.com, destino mis cuentas de gmail y live:

Servidor Relay SMTP Sin Autentificación

theliel@Anarchy:~$ ncat -C smtp.relay.com 25

-bash-3.2$ telnet smtp.relay.com 25

; <<>> DiG 9.7.0rc2 <<>> gmail.com MX

Servidor SMTP Con Autentificación

C:\Users\Theliel>ncat -C smtp.gmail.com 465

C:\Users\Theliel>ncat -C smtp.gmail.com 587

theliel@Anarchy:~$ openssl s_client -starttls smtp -crlf -connect smtp.gmail.com:25

Podemos intentarlo por el puerto 465 y usando TLS:

C:\Users\Theliel>ncat -C –ssl smtp.gmail.com 465

“perl -MMIME::Base64 -e ‘print encode_base64(“\000test\@gmail.com\000contraseñaprueba”)’”

Seguridad: Spoofing. Capítulo Quinto -> eMail Spoofing

Hola muy bueno el articulo

como se solucionaria esto?

seria ya poniendo el SMTP server en un dns con MX?

o requiere algo mas

gracias por el apoyo

Cual es el problema exactamente, no he terminado de entendederlo.

Muchas gracias por contestar

aber si tu me puedes ayudar

deja replanteo la pregunta,

En mi programacion del SMTP llegaron correos de a@midominio.com para b@gmail.com

envio todos lo parametros incluyendo STARTTLS me autentico y llego hasta

235 2.7.0 Accepted

logro enviar el correo

entiendo que fue porque me autentique con x@gmail.com

Sabes las reglas que requiere gmail

Una disculpa no cambia el remitente

o por asi decirlo me cambia el

HOLA…ME PARECIO MUY INTERESANTE TU ARTICULO.

URL del Trackback http://blog.theliel.es/2010/02/seguridad-spoofing-capitulo-quinto-email-spoofing.html/trackback

1. Sin Trackbacks aun.

¿Alguna sugerencia, pregunta, corrección... que quieras hacer?

Zairoud: Excelente comparativa, muchas gracias por tu trabajo. Saludos!

marzo 2012 (3)

Cambiar a la versión para móviles

You might also like