Se impartirán conocimientos de tecnologías y enlace a pg que den información de tendencias tecnológicas, también se informara sobre otros aspectos..
Traemos ahora un nuevo integrante para el blog que es el Hacking, algo que esta evolucionando el mundo después de saber que la guerra se puede hacer ya de forma Cibernética.....
Ehtools Framework (Entynet Hacker Tools) es un conjunto de herramientas de penetración para redes WiFi desarrollado por entynetproject. Se puede usar para todo, desde instalar nuevos complementos hasta hacer contacto WPA en segundos. Ademas, es fácil de instalar, configurar y usar. Como todas las tecnologías, el WiFi también tiene algunos problemas de seguridad, especialmente para las redes publicas WiFi. Cualquier intruso puede atacar nuestros dispositivos accediendo a nuestras redes WiFi (puedes hacer una prueba con Wifiphisher). Entonces, debemos analizar nuestra red inalambrica de vez en cuando para evitar ataques de hackers. Existen muchas herramientas para hacer pruebas de penetración de WiFi, pero la herramienta que discutiremos aquí es un poco diferente a las demás. Sobre Ehtools ¿Que es lo que hace que el marco de trabajo de Ehtools sea diferente de otros? Cuando hacemos pruebas de penetración WiFi, tendemos a usar diferentes herramientas para diferentes tareas.
Obtener enlace
Facebook
X
Pinterest
Correo electrónico
Otras aplicaciones
Prevención ante ataques phishing – Parte 2 – Evasión de protocolos SPF, DKIM y DMARC
Obtener enlace
Facebook
X
Pinterest
Correo electrónico
Otras aplicaciones
En el anterior artículo vimos, principalmente, cómo identificar un ataque phishing analizando el propio correo y sus cabeceras. Sin embargo, dejamos una cuestión pendiente. ¿Por qué, si claramente se trataba de un ataque phishing, el servidor de correo lo dejaba pasar a la bandeja de entrada? La clave está en los protocolos SPF, DKIM Y DMARC.
En esta segunda parte procederemos a estudiar estos tres protocolos, a la misma vez que vamos a ir analizando los resultados SPF, DKIM Y DMARC del correo phishing de PayPal visto en el artículo anterior.
Protocolos de suplantación de identidad en correos electrónicos
Las herramientas SPF, DKIM y DMARC tienen la misión conjunta de comprobar la autenticidad y veracidad de los correos entrantes. De esta forma se garantiza, en la medida de lo posible, la suplantación de identidad.
A continuación, vamos a explicar detalladamente estos protocolos, a la vez que su interpretación y análisis en las cabeceras de correo. Para ello, imaginemos que hemos comprado el dominio payosrangers.es y queremos configurar los protocolos anteriores con el fin de evitar que un atacante nos suplante.
Sender Policy Framework (SPF)
La protección SPF se encarga de comprobar los servidores autorizados para enviar correos electrónicos a nombre de un dominio. Para ello, el servidor receptor comprobará en el DNS del dominio la lista de equipos permitidos para dicho fin.
Registrar SPF en el DNS
Para que pueda llevarse a cabo la comprobación SPF, se debe registrar en el DNS de tu dominio qué equipos autorizas para que envíen correos electrónicos en tu nombre.
Un ejemplo simple para la configuración SPF en el servidor DNS de payosrangers.es podría ser el siguiente, donde se indican en los parámetros ip4 los equipos autorizados.
A continuación, este registro se almacenaría en el DNS de tu dominio. De esta forma, cualquier servidor de correo podría consultar qué equipos están autorizados para enviar un email con origen en payosrangers.es.
Verificación SPF
Imaginemos que el servidor de correo B recibe un correo de A, donde el campo From es pepito@payosrangers.es . Entonces B, cuando recibe el correo, revisa en primer lugar este valor:
From: Pepito <pepito@payosrangers.es>
Por otro lado, B debe coger la IP del emisor (servidor A en este caso) para contrastar la información en el DNS del dominio payosrangers.com. En este ejemplo, la IP de consulta va a ser 194.57.88.211.
Esquema SPF
Por lo tanto, una vez que B tiene la lista de IPs permitidas para enviar correo en nombre de payosrangers.es, puede comprobar que la IP de A está autorizada.
Cabecera Received-SPF
Esta cabecera indica el resultado SPF determinado por el servidor destinatario. Los posibles valores son los siguientes:
Pass
Se ha verificado en el DNS que la IP consultada está autorizada para enviar correos electrónicos en nombre del dominio.
SoftFail / Fail
Se ha verificado en el DNS que la IP consultada no está autorizada para enviar correos electrónicos en nombre del dominio.
Neutral
No se ha podido verificar en el DNS que la IP consultada esté autorizada para enviar correos electrónicos en nombre del dominio. Puede deberse a que no se haya configurado ningún registro SPF o el DNS no esté autorizado para indicar dicha información.
None
Este valor indica que no se ha configurado ningún registro SPF en el servidor DNS. Se comporta igual que Neutral.
El resultado de la cabecera Received-SPF podría ser en este caso la siguiente, donde el servidor de destino (perteneciente a Gmail) indica que el dominio de la cuenta pepito@payosrangers.es permite a la IP 194.57.88.211 enviar correos electrónicos en su nombre.
Received-SPF: pass (google.com: domain of pepito@payosrangers.es designates 194.57.88.211 as permitted sender) client-ip=194.57.88.211;
SPF en correo phishing de PayPal
En primer lugar, el servidor destino revisaría la cabecera From.
Siguiendo el formato Nombre del remitente <dirección de correo>, podemos ver que el dominio de la cuenta emisora es numborlma.service-login-unauthorizeds.business y no ics.paypal.com.
Al hacer la consulta SPF al DNS de este dominio, el resultado ha indicado que no hay configurado ningún registro SPF para el mismo. Por lo tanto, no va a poder comprobar si la IP del servidor que le ha pasado el mensaje está autorizada o no para ello.
Received-SPF: None (google.com:
numborlma.service-login-unauthorizeds.business does not designate permitted sender hosts)
Esto puede deberse, entre otros casos, a que este dominio se encuentre en un hosting gratuito, donde no se permite configurar estos valores.
DomainKeys Identified Mail (DKIM)
La protección DKIM se encarga de firmar el mensaje para autenticar el emisor, haciendo uso de un par de claves pública-privada. A parte de ello, pretende garantizar la integridad del mensaje, es decir, que no sea modificado por ninguna entidad intermedia.
Registrar DKIM en el DNS
Para que pueda llevarse a cabo la comprobación DKIM, la persona encargada de gestionar el dominio debe generar un par de claves pública-privada. Una vez creadas, se procede a insertar la clave pública en el DNS del dominio.
Almacenamiento de clave pública en DNS
Por su parte, la clave privada será utilizada para firmar el correo que se envíe. Para ello el remitente, antes de enviar el mensaje, elige las cabeceras del email que quiere incluir en la firma DKIM. De esta forma, en caso de que estos parámetros sean modificados durante el trayecto, la integridad del mensaje no será válida.
Una vez elegidas las cabeceras, el remitente configurará su plataforma de correo electrónico para crear automáticamente un hash de las mismas, convirtiendo el texto legible en una cadena de texto única, conformada por caracteres alfanuméricos.
Para este ejemplo, vamos a suponer que elegimos los siguientes campos para que sean cifrados.
To: manolita@gmail.com
From: Pepito <pepito@payosrangers.es>
Reply-to: Pepito <pepito@payosrangers.es>
Subject: Entradas de cine
Una vez elegidos los campos, se procederá a realizar el cifrado mediante un algoritmo hash como, por ejemplo, SHA-256.
Antes de enviar el correo electrónico, esa cadena de hash es codificada utilizando la clave privada que generamos con anterioridad.
Autenticación DKIM con clave privada
De esta forma, cuando se realice la consulta DKIM con la clave privada, se podrá verificar la autenticación.
Cabecera DKIM-Signature
Esta cabecera de correo indica la firma proporcionada por el emisor del mensaje para comprobar las propiedades de autenticación e integridad de este. Vamos a explicarla mejor con un ejemplo.
Imaginemos que al servidor B le va a llegar un correo, en el cuál se encuentra esta cabecera. Para no extendernos, vamos a ir directos a los campos más interesantes.
El campo a indica el esquema de criptografía y la firma criptográfica. En este caso son rsa y sha256, respectivamente.
El campo s indica el nombre del registro donde está almacenada la clave pública en el DNS. En este caso el registro se llama miclave.
El campo h indica las cabeceras encriptadas. En este caso son To, From, Reply-To y Subject.
El campo b contiene el hash realizado a las cabeceras definidas en el campo h. Esto se define como la firma DKIM.
Al existir esta cabecera, generada por el servidor A que es el emisor, el servidor B tendrá que comprobar la firma DKIM. Para ello, en primer lugar el servidor B revisará el campo From con el fin de conocer el dominio de origen.
From: Pepito <pepito@payosrangers.es>
Una vez lo tenga, realizará una consulta al DNS del dominio para desencriptar el hash con la clave pública alojada en el mismo. De esta forma estamos asegurando la autenticación del mensaje.
Esquema DKIM
Una vez el servidor de correo B tiene el hash, comprueba si coincide con el hash contenido en el parámetro b de la cabecera DKIM-Signature. Si es así, significa que el contenido no ha sido alterado por el camino, por lo que se garantiza la integridad del mensaje. A continuación, podemos ver que ambos coinciden.
Esta cabecera indica un resumen de las valoraciones dadas por el servidor final tras realizar las comprobaciones SPF, DKIM y DMARC. Será en la misma donde nosotros, como analistas, podremos ver la valoración del protocolo DKIM. Los valores posibles de éste son los mismos que en el caso de SPF: pass, neutral, fail, softfail o none.
La cabecera Autentication-Results para el protocolo DKIM del ejemplo anterior sería la siguiente, donde podemos ver que el receptor ha determinado que el mensaje es auténtico e íntegro debido a que el parámetro dkim es igual a pass.
En caso de que la cabecera DKIM-Signature no existiera, no se realizarían los pasos anteriores, sino que el resultado del parámetro dkim sería none o, incluso, no aparecería dkim contenido en la cabecera Authentication-Results (depende del servidor).
DKIM en correo phishing de PayPal
En primer lugar, el servidor comprueba que exista la cabecera DKIM-Signature. De lo contrario, no habría ninguna firma DKIM que validar y, por lo tanto, no se realizarían los siguientes pasos.
Con estos datos, realiza la petición de la clave pública al servidor DNS del dominio numborlma.service-login-unauthorizeds.business, en concreto del registro 20150623 (que es donde se encuentra la clave según indica el parámetro s).
Cuando obtiene el hash, comprueba si coincide con el parámetro b de la cabecera DKIM-Signature, e indica los resultados en el parámetro dkim del campo Authentication-Results.
Authentication-Results:
spf=none (sender IP is 209.85.221.68) smtp.mailfrom=numborlma.service-login-unauthorizeds.business; hotmail.com;
dkim=pass (signature was verified) header.i=@numborlma.service-login-unauthorizeds.business; hotmail.com; header.s=20150623 header.b=gnSTKkU6;
dmarc=none action=none header.from=numborlma.service-login-unauthorizeds.business;
El resultado de la firma DKIM para el correo phishing de PayPal es pass, es decir, se ha autenticado al emisor. Sin embargo, se ha autenticado para el dominio numborlma.service-login-unauthorizeds.busines. Por lo tanto, es normal que sea pass si el atacante ha configurado la firma DKIM para su dominio. En caso de que se estuviese comprobando la firma para paypal.com, el resultado no hubiera sido precisamente pass.
La protección DMARC se encarga de indicar al servidor destinatario qué hacer con el correo si las valoraciones dadas por SPF y DKIM han determinado que el mensaje es una suplantación de identidad. Por lo tanto, para que un mensaje sea validado por DMARC, debe pasar la autenticación SPF y/o la autenticación DKIM. En cambio, si ambas fallan, el mensaje será rechazado.
Al contrario que podríamos pensar, esta decisión no la toma exclusivamente el servidor destino. Si yo soy el propietario del dominio payosrangers.es, configuro un registro dmarc en el DNS indicando qué acción quiero que tome un servidor que reciba un correo suplantando mi identidad. Por lo tanto, al igual que los protocolos anteriores, se debe registrar primero en el DNS la configuración DMARC. Para entenderlo mejor, vamos a seguir con nuestro ejemplo anterior.
Imaginemos que somos los encargados de gestionar el dominio payosrangers.es. Para la configuración DMARC, debemos registrar primero en el DNS de dicho dominio el registro correspondiente. Un ejemplo sería el siguiente:
_dmarc.payosrangers.es IN TXT "v=DMARC1; p=quarantine; sp=quarantine; rua=mailto:admin@payosrangers.es; adkim=r; aspf=r;"
El parámetro clave es p. Este define cómo quieres que el servidor receptor gestione los mensajes sospechosos que le llegan haciéndose pasar por tu dominio. Este campo puede estar compuesto por uno de los siguientes valores:
NONE
Le indica al servidor que no haga nada con el mensaje y siga sus propias políticas para determinar el destino del mismo. Le va a indicar una cuenta de correo a la que quiere que se le notifique con un informe del mensaje sospechoso, indicada en el parámetro rua. Este es el valor por defecto.
QUARANTINE
Le indica al servidor que marque los mensajes como spam y que los mantenga en cuarentena a la espera de seguir tratándolos. También se enviaría notificación a la entidad suplantada.
REJECT
Le indica al servidor que rechace el correo, evitando que llegue al destinatario. Al igual que los anteriores, se enviaría notificación a la entidad suplantada.
Por otro lado, se encuentran los parámetros adkim y aspf. A modo resumen, estos campos tienen dos posibles valores: relaxed (r) o strict (s). Según la combinación de estos parámetros, se determinará si el correo es o no una suplantación de identidad.
ADKIM
ASPF
Veredicto
Relaxed
Relaxed
Con que uno de los protocolos SPF o DKIM sea pass, neutral o none el
correo es verídico.
Relaxed
Strict
Para determinar que el correo es verídico, por lo menos SPF debe ser
distinto de fail/softfail.
Strict
Relaxed
Para determinar que el correo es verídico, por lo menos DKIM debe ser
distinto de fail/softfail.
Strict
Strict
Ambos protocolos, SPF y DKIM, deben ser distintos de fail/softfail para determinar el correo como verídico.
Para entender mejor su funcionamiento, imaginemos que llega un correo al servidor B. Una vez comprueba SPF y DKIM, le toca el turno a DMARC. En el siguiente esquema podemos ver la lógica que sigue este protocolo.
Esquema DMARC cuando el registro dmarc está configurado en el DNS
Cabecera Authentication-Results
Para no alargarnos con este protocolo, vamos a ir directos al análisis de sus resultados. Como analistas, podremos ver la valoración DMARC descrita en la cabecera Authentication-Results exclusivamente. Los valores posibles del parámetro dmarc son los mismos que en el caso de SPF y DKIM: pass, neutral, fail, softfail o none.
Un ejemplo de esta cabecera podría ser la siguiente:
Tal y como podemos observar, el resultado del protocolo DMARC sería pass debido a que tanto SPF como DKIM han dado como resultado que el correo es verídico (son distintos de fail/softfail). En caso de que el correo hubiese sido catalogado como phishing, se hubiera movido a la bandeja de spam, debido a que el parámetro p indica el valor QUARANTINE.
DMARC en correo phishing de PayPal
En el caso del correo phishing de PayPal, los protocolos SPF y DKIM han determinado que no se trata de una suplantación de identidad. Por lo tanto, DMARC no sospecha que el correo sea falso y lo categoriza como legítimo.
Authentication-Results:
spf=none (sender IP is 209.85.221.68) smtp.mailfrom=numborlma.service-login-unauthorizeds.business; hotmail.com;
dkim=pass (signature was verified) header.i=@numborlma.service-login-unauthorizeds.business; hotmail.com; header.s=20150623 header.b=gnSTKkU6;
dmarc=none header.from=numborlma.service-login-unauthorizeds.business;
Si nos fijamos, el resultado en este caso es none. Esto indica que no hay configurado ningún registro DMARC en el DNS del dominio numborlma.service-login-unauthorizeds.business. En este caso, se sigue la siguiente lógica:
Esquema DMARC cuando el registro dmarc no está configurado
Es decir, el servidor destinatario aplicaría sus propias reglas para decidir qué hacer con el correo. Debido a que SPF y DKIM han determinado que el correo no es sospechoso, se fía y lo envía a la bandeja de entrada.
Ejemplo de un correo phishing detectado por SPF, DKIM y DMARC
En caso de que el campo From del correo de PayPal hubiese sido support@paypal.com, seguramente el servidor de correo lo hubiese bloqueado o enviado a spam. Los protocolos SPF, DKIM y DMARC serían parecidos a los siguientes:
SPF
Se habría comprobado en el DNS de paypal.com (dominio suplantado en el campo From) que el host 209.85.221.68 (servidor de correo del atacante) no está autorizado para enviar correos a nombre de dicho dominio. Por lo tanto, el resultado sería softfail ó fail.
DKIM
Sería absurdo establecer una firma DKIM en estos casos debido a que la comprobación en el DNS de paypal.com daría como resultado fail o softfail. Además, en hostings gratuitos no es posible configurar los registros SPF, DKIM y DMARC. Por lo tanto, lo normal en este caso es que dkim sea none.
DMARC
Hay herramientas online bastante interesantes donde buscar el valor de los registros spf, dkim y dmarc de un dominio concreto. Una de ellas es mxtoolbox.com, donde podemos buscar cuál es el registro dmarc configurado para el dominio paypal.com.
Tal y como podemos observar, PayPal quiere que cualquier servidor de correo que detecte una suplantación en su nombre rechace de inmediato el email y le avise a la cuenta d@rua.agari.com.
Por otro lado, mientras no se indique lo contrario, los valores por defecto de aspf y adkim son relaxed. Es por ello que, con que spf ó dkim sea fallido, el servidor va a determinar el correo como phishing. Como en este caso SPF ha dado como resultado softfail, este correo va a ser catalogado como suplantación de identidad y, directamente, va a ir a la basura.
La cabecera Authentication-Results en este caso sería la siguiente:
Authentication-Results: mx.google.com;
spf=softfail (google.com: domain of transitioning support@paypal.com does not designate 209.85.221.68 as permitted sender) smtp.mailfrom= support@paypal.com
dkim=none;
dmarc=fail (p=reject sp=reject dis=reject) header.from=paypal.com
Conclusiones
Un buen ejemplo de ataque phishing actual es el que hemos visto de PayPal. Paraevitar ser descubiertos, los atacantes hacen uso de dominios propios, ya sean comprados o proporcionados en hostings gratuitos. De esta forma, en lugar de suplantar el campo From, arriesgándose así de que su correo no llegue a la bandeja de entrada de la víctima, hacen uso de un dominio propio sin ocultarse.
A veces es bastante evidente que el correo no es verídico (solo hace falta ver el dominio numborlma.service-login-unauthorizeds.business). Sin embargo, con esta táctica se aseguran de evadir los protocolos de seguridad implementados en los servidores de correo, tales como SPF, DKIM y DMARC, siendo el usuario final el encargado de evaluar si el correo es o no legítimo. En caso de que el usuario no esté bien formado, puede caer en la trampa sin percatarse de tal ataque.
Tal y como hemos visto, no siempre los parámetros SPF, DKIM y DMARC son fiables para determinar si un correo es o no un ataque phishing. Es por ello que no se debe dejar en manos de herramientas automatizadas la decisión final, sino ayudarse de analistas que revisen todas las evidencias que dejan este tipo de ataques.
Por último, si eres administrador de dominio aconsejarte configurar SPF y DKIM por lo menos (y si haces uso de DMARC mejor que mejor). Aunque se haya mostrado que a veces no es posible parar estos correos, cuantas más trabas y obstáculos le pongas al enemigo, mejor que mejor
pfSense Dashboard El increíble pfSense Community Edition es el primero de mi firewall y gateway de seguridad de Internet en casa de tres capas. Tengo una configuración de doble WAN con suscripciones tanto a Verizon FiOS como a Comcast Xfinity, con el lado de LAN alimentando un Sophos UTM 9 que está más protegido por ClearOS. Ejecuto pfSense en una máquina virtual. Sin embargo, hay excelentes enrutadores de firewall dedicados con pfSense preinstalado que puede conectar simplemente entre su WAN y su LAN, como esta (incluye mi enlace de afiliado de Amazon): Soy un gran fanático de las listas de bloqueo y, a lo largo de los años, he establecido un conjunto funcional de listas de bloqueo de IP y DNSBL utilizadas con el maravilloso paquete pfBlockerNG en mi instalación del servidor de seguridad de enrutador de código abierto de la comunidad pfSense. He deshabilitado completamente IPv6; todas las siguientes listas de bloqueo son para IPv4 y para DNSBL, nombres de dominio.
A continuación, te dejamos información vital que te puede servir al momento de escoger el hosting que mejor se adapte a tu empresa. Una buena parte del alcance de un negocio depende del posicionamiento de su sitio web en los buscadores de Internet, específicamente ¡Google!; actualmente, vivimos en una era en la que todos estamos conectados a la red, esto significa que la empresa que no se encuentre con facilidad, virtualmente no existe para aquellos clientes o socios potenciales que estén buscando sus productos o servicios. Por esta razón, es prioritario e imprescindible para el equipo empresarial, contar con el hosting más adecuado para sus necesidades comerciales; éste, garantizará el funcionamiento óptimo del sitio y de sus distintas aplicaciones cuando sus prospectos decidan realizar la búsqueda. Escoger un buen plan de hosting es prioritario para garantizar un óptimo funcionamiento del sitio web, según las necesidades comerciales de cada empresa Para sabe
No hace mucho hice un pequeño aporte a la comunidad enseñando mi mini-proyecto para la creación de una botnet: " https://underc0de.org/foro/hacking/winp-una-botnet-desde-tu-casa!/ ", pocos usuarios pero con palabras que debo escuchar, requerían de documentación o algún tutorial acerca de esto, así que les traigo "Tutorial de Winp". Antes de seguir debemos saber ... ¿Que es una botnet? Una pequeña definición según wikipedia: "Botnet es un término que hace referencia a un conjunto o red de robots informáticos o bots, que se ejecutan de manera autónoma y automática. El artífice de la botnet puede controlar todos los ordenadores/servidores infectados de forma remota." ¿Que es Winp? Winp, es un proyecto de código abierto para la interacción múltiple de varias terminales remotas o... básicamente un script para la creación de una botnet. Características * - Cifrado híbrido (AES256 y RSA) * - Múltiples conexiones * - Uso de un
Comentarios
Publicar un comentario