Buenas prácticas contra el phishing por parte de los bancos: SPF
El envío de correo es un sistema que, por definición, carece absolutamente de seguridad. Esto permite que, por ejemplo, sea tan sencillo falsificar un remitente de un email. Para solucionar esto, se han propuesto varios métodos que son como "parches" en el protocolo SMTP. Uno es "Sender Policy Framework" (SPF) que se considera una buena práctica contra la falsificación de correos en general y el phishing en particular.
El phishing se suele basar en el envío de correos falsos, que dicen venir de la entidad bancaria. Para conseguir dar credibilidad a estos correos, los atacantes suelen, entre otros métodos, utilizar logotipos de entidad atacada o el envío desde direcciones pertenecientes al dominio de la entidad. Por ejemplo, es más probable que una potencial víctima del phishing dé más credibilidad a un correo que viene de soporte@banco.com, que si viene de soporte@gmail.com pidiendo las contraseñas de la que es cliente.
SPF se basa en que un correo de un dominio, debe haber sido enviado desde el servidor de correo de ese dominio, y nada más. Cuando un email llega a un servidor, el programa se cuestiona: Este correo dice venir de @banco.com, y ha sido enviado desde la dirección IP 1.2.3.4. ¿Está la dirección 1.2.3.4 autorizada a enviar correos en nombre de ese domino? Y a continuación le pregunta a @banco.com por sus IPs autorizadas. Solo los correos enviados desde el servidor de correo legítimo de banco.com, se considerarán válidos. ¿Cómo sabe el servidor qué direcciones IP son las válidas? Esta información se deja en un registro DNS público de la entidad, en el que básicamente se constata qué direcciones IP están autorizadas a enviar y qué con qué política marcar a los correos que no han sido enviados desde ellas. Y las políticas (entre otras) que se pueden seguir son estas:
Dejar pasar los válidos y marcar el resto como "hardfail", o sea, que se marcan en la cabecera como correos falsos a todas luces.
No hacer nada.
Dejar pasar los válidos y marcar el resto como como "softfail", o sea, que se marcan como falsos pero tampoco "tajantemente".
En realidad, las dos últimas opciones se suelen usar para comprobar que funciona en fases de pruebas. Es responsabilidad de la entidad una buena configuración de sus registros DNS para que funcione correctamente el SPF.
Imaginemos que un phisher envía un correo a una cuenta de Gmail cualquiera, diciendo que es seguridad@banco.es y lo envía desde una IP (1.2.3.4) que no corresponde al registro SPF del banco (la lista de IPs que considera legítimas para enviar correo en su nombre). Gmail marcará el correo en su cabecera con esto:
Received-SPF: fail (google.com: domain of seguridad@banco.es does not designate 1.2.3.4 as permitted sender)
Donde vemos un "fail", o sea, un hardfail. El administrador del servidor de correo al que llega (en este caso Gmail), decide qué hacer con esto. Por ejemplo, descartarlos o desterrarlos al spam y que no llegue el buzón de los usuarios (que probablemente sea lo más conveniente, tratándose de un "hardfail").
En resumen, SPF ayuda a que los correos con el remitente falsificado lleguen en menor medida a las bandejas de entrada de los usuarios, pero no es definitivo. Primero porque el phisher puede usar otro dominio inventado (por ejemplo @soportebanco.com) que no use SPF y que también puede convencer a la víctima. Segundo porque es el servidor que recibe el email el que elige qué hacer con el correo... siempre se marca, pero no garantiza que lo descarte totalmente por fallar en el SPF, aunque puede tomarlo como un punto más en la evaluación como correo basura. Y tercero porque, si no se configura bien, el atacante podría usar otros dominios legítimos para engañar al usuario, por ejemplo, enviarlo desde @www.banco.com, que también tendría credibilidad a los ojos de una potencial víctima.
Existen otros métodos más efectivos como DKIM para validar el correo, pero son menos populares entre los administradores y mucho más complejos de implementar. La ventaja de SPF es que es trivial de configurar, y mitiga en parte el impacto del phishing.
Fuente: Hispasec
El phishing se suele basar en el envío de correos falsos, que dicen venir de la entidad bancaria. Para conseguir dar credibilidad a estos correos, los atacantes suelen, entre otros métodos, utilizar logotipos de entidad atacada o el envío desde direcciones pertenecientes al dominio de la entidad. Por ejemplo, es más probable que una potencial víctima del phishing dé más credibilidad a un correo que viene de soporte@banco.com, que si viene de soporte@gmail.com pidiendo las contraseñas de la que es cliente.
SPF se basa en que un correo de un dominio, debe haber sido enviado desde el servidor de correo de ese dominio, y nada más. Cuando un email llega a un servidor, el programa se cuestiona: Este correo dice venir de @banco.com, y ha sido enviado desde la dirección IP 1.2.3.4. ¿Está la dirección 1.2.3.4 autorizada a enviar correos en nombre de ese domino? Y a continuación le pregunta a @banco.com por sus IPs autorizadas. Solo los correos enviados desde el servidor de correo legítimo de banco.com, se considerarán válidos. ¿Cómo sabe el servidor qué direcciones IP son las válidas? Esta información se deja en un registro DNS público de la entidad, en el que básicamente se constata qué direcciones IP están autorizadas a enviar y qué con qué política marcar a los correos que no han sido enviados desde ellas. Y las políticas (entre otras) que se pueden seguir son estas:
Dejar pasar los válidos y marcar el resto como "hardfail", o sea, que se marcan en la cabecera como correos falsos a todas luces.
No hacer nada.
Dejar pasar los válidos y marcar el resto como como "softfail", o sea, que se marcan como falsos pero tampoco "tajantemente".
En realidad, las dos últimas opciones se suelen usar para comprobar que funciona en fases de pruebas. Es responsabilidad de la entidad una buena configuración de sus registros DNS para que funcione correctamente el SPF.
Imaginemos que un phisher envía un correo a una cuenta de Gmail cualquiera, diciendo que es seguridad@banco.es y lo envía desde una IP (1.2.3.4) que no corresponde al registro SPF del banco (la lista de IPs que considera legítimas para enviar correo en su nombre). Gmail marcará el correo en su cabecera con esto:
Received-SPF: fail (google.com: domain of seguridad@banco.es does not designate 1.2.3.4 as permitted sender)
Donde vemos un "fail", o sea, un hardfail. El administrador del servidor de correo al que llega (en este caso Gmail), decide qué hacer con esto. Por ejemplo, descartarlos o desterrarlos al spam y que no llegue el buzón de los usuarios (que probablemente sea lo más conveniente, tratándose de un "hardfail").
En resumen, SPF ayuda a que los correos con el remitente falsificado lleguen en menor medida a las bandejas de entrada de los usuarios, pero no es definitivo. Primero porque el phisher puede usar otro dominio inventado (por ejemplo @soportebanco.com) que no use SPF y que también puede convencer a la víctima. Segundo porque es el servidor que recibe el email el que elige qué hacer con el correo... siempre se marca, pero no garantiza que lo descarte totalmente por fallar en el SPF, aunque puede tomarlo como un punto más en la evaluación como correo basura. Y tercero porque, si no se configura bien, el atacante podría usar otros dominios legítimos para engañar al usuario, por ejemplo, enviarlo desde @www.banco.com, que también tendría credibilidad a los ojos de una potencial víctima.
Existen otros métodos más efectivos como DKIM para validar el correo, pero son menos populares entre los administradores y mucho más complejos de implementar. La ventaja de SPF es que es trivial de configurar, y mitiga en parte el impacto del phishing.
Fuente: Hispasec
Comentarios
Publicar un comentario
siempre es bueno, leer tus comentarios