Email Injections
Usa Trickest para construir y automatizar flujos de trabajo fácilmente con las herramientas comunitarias más avanzadas del mundo. Obtén acceso hoy:
Inyectar en correo electrónico enviado
Inyectar Cc y Bcc después del argumento del remitente
El mensaje se enviará a las cuentas de destinatario y destinatario1.
Inyectar argumento
El mensaje se enviará al destinatario original y a la cuenta del atacante.
Inyectar argumento de Asunto
El asunto falso se añadirá al asunto original y en algunos casos lo reemplazará. Depende del comportamiento del servicio de correo.
Cambiar el cuerpo del mensaje
Inyecta un salto de línea de dos líneas, luego escribe tu mensaje para cambiar el cuerpo del mensaje.
Explotación de la función mail() de PHP
El 5to parámetro ($additional_parameters)
Esta sección se basará en cómo abusar de este parámetro suponiendo que un atacante lo controla.
Este parámetro se añadirá a la línea de comandos que PHP utilizará para invocar el binario sendmail. Sin embargo, será sanitizado con la función escapeshellcmd($additional_parameters)
.
Un atacante puede inyectar parámetros adicionales para sendmail en este caso.
Diferencias en la implementación de /usr/sbin/sendmail
La interfaz de sendmail es proporcionada por el software MTA de correo electrónico (Sendmail, Postfix, Exim, etc.) instalado en el sistema. Aunque la funcionalidad básica (como los parámetros -t -i -f) permanece igual por razones de compatibilidad, otras funciones y parámetros varían considerablemente dependiendo del MTA instalado.
Aquí hay algunos ejemplos de diferentes páginas de manual del comando/interfaz sendmail:
Sendmail MTA: http://www.sendmail.org/~ca/email/man/sendmail.html
Postfix MTA: http://www.postfix.org/mailq.1.html
Exim MTA: https://linux.die.net/man/8/eximReferences
Dependiendo del origen del binario sendmail, se han descubierto diferentes opciones para abusar de ellos y filtrar archivos o incluso ejecutar comandos arbitrarios. Consulta cómo en https://exploitbox.io/paper/Pwning-PHP-Mail-Function-For-Fun-And-RCE.html
Inyección en el nombre del correo electrónico
Ten en cuenta que si logras crear una cuenta en un servicio con un nombre de dominio arbitrario (como Github, Gitlab, CloudFlare Zero trust...) y verificarla recibiendo el correo electrónico de verificación en tu dirección de correo, podrías acceder a ubicaciones sensibles de la empresa víctima.
Partes ignoradas de un correo electrónico
Los símbolos: +, - y {} en raras ocasiones pueden ser utilizados para etiquetar y son ignorados por la mayoría de los servidores de correo electrónico.
Por ejemplo, john.doe+intigriti@example.com → john.doe@example.com
Comentarios entre paréntesis () al principio o al final también serán ignorados.
Por ejemplo, john.doe(intigriti)@example.com → john.doe@example.com
Bypass de lista blanca
Citas
IPs
También puedes usar IPs como nombres de dominio entre corchetes:
john.doe@[127.0.0.1]
john.doe@[IPv6:2001:db8::1]
Codificación de correo electrónico
Como se explicó en esta investigación, los nombres de correo electrónico también pueden contener caracteres codificados:
Desbordamiento de PHP 256: La función
chr
de PHP seguirá sumando 256 a un carácter hasta que se vuelva positivo y luego realizará la operación%256
.String.fromCodePoint(0x10000 + 0x40) // 𐁀 → @
El objetivo de este truco es terminar con una inyección como RCPT TO:<"collab@psres.net>collab"@example.com>
que enviará el correo electrónico de verificación a una dirección de correo electrónico diferente de la esperada (por lo tanto, introducir otra dirección de correo electrónico dentro del nombre del correo y romper la sintaxis al enviar el correo).
Diferentes codificaciones:
Payloads:
Github:
=?x?q?collab=40psres.net=3e=00?=foo@example.com
Nota el
@
codificado como =40, el>
codificado como=3e
ynull
como=00
Enviará el correo de verificación a
collab@psres.net
Zendesk:
"=?x?q?collab=22=40psres.net=3e=00==3c22x?="@example.com
El mismo truco que antes pero añadiendo una comilla regular al principio y la comilla codificada
=22
antes del@
codificado y luego comenzando y cerrando algunas comillas antes del siguiente correo para corregir la sintaxis utilizada internamente por ZendeskEnviará el correo de verificación a
collab@psres.net
Gitlab:
=?x?q?collab=40psres.net_?=foo@example.com
Nota el uso del guion bajo como un espacio para separar la dirección
Enviará el correo de verificación a
collab@psres.net
Punycode: Usando Punycode fue posible inyectar una etiqueta
<style
en Joomla y abusar de ella para robar el token CSRF a través de la exfiltración de CSS.
Tooling
Hay un script de Burp Suite Turbo Intruder para fuzzear este tipo de combinaciones para intentar atacar formatos de correo electrónico. El script ya tiene combinaciones potencialmente funcionales.
También es posible usar Hackvertor para crear un ataque de división de correo electrónico
Other vulns
Third party SSO
XSS
Algunos servicios como github o salesforce permiten crear una dirección de correo electrónico con cargas útiles de XSS en ella. Si puedes usar estos proveedores para iniciar sesión en otros servicios y estos servicios no están sanitizando correctamente el correo electrónico, podrías causar XSS.
Account-Takeover
Si un servicio SSO te permite crear una cuenta sin verificar la dirección de correo electrónico dada (como salesforce) y luego puedes usar esa cuenta para iniciar sesión en un servicio diferente que confía en salesforce, podrías acceder a cualquier cuenta. Ten en cuenta que salesforce indica si el correo electrónico dado fue o no verificado, pero la aplicación también debería tener en cuenta esta información.
Reply-To
Puedes enviar un correo electrónico usando From: company.com y Replay-To: attacker.com y si se envía alguna respuesta automática debido a que el correo fue enviado desde una dirección interna, el atacante podría ser capaz de recibir esa respuesta.
Hard Bounce Rate
Ciertos servicios, como AWS, implementan un umbral conocido como la Tasa de Rebote Duro, típicamente establecido en un 10%. Esta es una métrica crítica, especialmente para servicios de entrega de correo electrónico. Cuando se supera esta tasa, el servicio, como el servicio de correo electrónico de AWS, puede ser suspendido o bloqueado.
Un rebote duro se refiere a un correo electrónico que ha sido devuelto al remitente porque la dirección del destinatario es inválida o no existe. Esto podría ocurrir por varias razones, como que el correo se envíe a una dirección no existente, un dominio que no es real, o la negativa del servidor del destinatario a aceptar correos.
En el contexto de AWS, si envías 1000 correos y 100 de ellos resultan en rebotes duros (debido a razones como direcciones o dominios inválidos), esto significaría una tasa de rebote duro del 10%. Alcanzar o superar esta tasa puede hacer que AWS SES (Simple Email Service) bloquee o suspenda tus capacidades de envío de correos electrónicos.
Es crucial mantener una baja tasa de rebote duro para asegurar un servicio de correo ininterrumpido y mantener la reputación del remitente. Monitorear y gestionar la calidad de las direcciones de correo electrónico en tus listas de correo puede ayudar significativamente a lograr esto.
Para más información detallada, se puede consultar la documentación oficial de AWS sobre el manejo de rebotes y quejas en AWS SES Bounce Handling.
References
Use Trickest to easily build and automate workflows powered by the world's most advanced community tools. Get Access Today:
Last updated