Publicado el 28/04/2023 12:04:00 en Hacking Web.
Author: M20191 | Total de votos: 8   Vote

En este post escribiré acerca de lo que me apasiona, el pentesting web.
Lo haré de manera didáctica, clara, sencilla para todos.

* Formato
• Explicación
• Reportes / Ejemplos
• Recursos
• Resumen

- Explicación
Hablaré sobre la vulnerabilidad lo mejor posible

- Reportes / Ejemplos
* Cada ejemplo de vulnerabilidad tendrá este formato:
• Informe
• Fecha
• Recompensa
• Tipo
• Descripción

- Recursos
Te daré paginas web, maquinas virtuales, archivos, artículos, sobre la vulnerabilidad, para que investigues más y te adentres en el funcionamiento de la misma y al mismo tiempo puedas "vulnerar" ejemplos sencillos hasta avanzados.

Temario

Vulnerabilidades

• XSS (Cross-Site Scripting)
• HTMLi (HTML Inyection)
• HPP (HTTP Parameter Pollution)
• SQLi (SQL Injection)
• NoSQLi (NoSQL Injection)
• GraphQL Injection
• Command Execution
• RCE (Remote Code Execution)
• LFI (Local File Inclusion)
• RFI (Remote File Inclusion)
• Log Poisoning (LFI -> RCE)
• Directory Traversal
• XXE (XML External Entity)
• SSTI (Server-Side Template Injection)
• CSTI (Client-Side Template Injection)
• SSSI (Server-side Script Injection)
• SSRF (Server-Side Request Forgery)
• CRLF (Car-Return Line-Break)
• CSRF (Cross-Site Request Forgery)
• CSV-Injection
• Open-Redirect
• XSLT
• Content Injection
• LDAP Injection
• IDOR
• LaTex Injection
• OAuth
• XPATH Injection
• Bypass Upload Tricky
• Authentication bypass
• Information disclosure
• Clickjacking
• Open redirect
• Session hijacking
• Buffer overflow
• JSON injection
• Broken access control
• Insufficient authentication and authorization
• Insecure direct object references
• Insecure communications
• Improper error handling
• Weak cryptography
• Business logic vulnerabilities
• Prototype pollution
• Cross-origin resource sharing (CORS) misconfiguration
• HTTP response splitting
• Object injection
• Mass assignment vulnerabilities
• Race conditions
• HTML injection (also known as injection via untrusted input)
• Broken cryptography
• Broken authentication and session management
• Server-side cache poisoning
• Server-side deserialization
• Websocket vulnerabilities
• Information leakage vulnerabilities
• Server-side subdomain takeover
• Insecure file upload
• Sensitive data exposure
• Broken access controls
• Click-to-play attacks
• Authentication weaknesses
• Web cache poisoning
• OAuth and OpenID Connect weaknesses
• HTTP request smuggling
• Insufficient transport layer protection
• Insecure storage of sensitive information
• Insecure password management
• Insecure permissions
• Insecure random number generation
• Insufficient logging and monitoring
• Mobile app vulnerabilities
• API vulnerabilities
• Business logic flaws
• Docker and containerization vulnerabilities
• Race conditions
• Insecure deserialization
• Subdomain takeover
• Bypassing rate limits
• Social engineering attacks
• DNS cache poisoning
• Host header injection
• Security misconfigurations
• Clickjacking (also known as UI redressing)
• HTML5 security issues
• HTTPS stripping
• DNS rebinding
• Cryptographic attacks, such as Padding Oracle attacks and POODLE attacks
• Side-channel attacks
• Buffer overflows
• Time-of-check to time-of-use (TOCTTOU) vulnerabilities
• Unvalidated redirects and forwards
• Broken function-level authorization
• Server-side request forgery (SSRF) with DNS rebinding
• Cross-Site WebSocket Hijacking (CSWSH)
• Insecure third-party dependencies
• Man-in-the-middle (MITM) attacks
• Exploiting weak password policies
• Cross-Site WebSocket Forgery (CSWF)
• Cryptographic key management issues
• Security misconfigurations in serverless applications
• Insecure direct object references in RESTful APIs
• Insecure storage of secrets in mobile apps
• Insecure deserialization in RESTful APIs
• Insufficient monitoring and logging of API activities
• Business process vulnerabilities in e-commerce applications
• Improper certificate validation in SSL/TLS
• Exploiting insecure default configurations of software components
• Vulnerabilities in biometric authentication systems

Vulnerabilidades

XSS | Cross-Site Scripting | Ataque de Script de Sitio Cruzado

Explicación

Esta vulnerabilidad se presenta cuando una página incluye código javascript no deseado, este mismo puede ser cargado en formularios, en un payload, en un comentario, etc... por consecuencia el dicho código es enviado al usuario el cual ejecuta este código en sus navegadores.

Normalmente esta vulnerabilidad se presenta cuando hay una mala sanitización de los datos entrantes.

El ejemplo más inofensivo de esta vulnerabilidad es:

alert('XSS')

Esto dará paso a crear la función "alert" de javascript que cargará una ventana emergente con el texto 'XSS'.

Tipos de XSS

- XSS Reflectivo
- XSS Almacenado
- XSS Self
- XSS DOM


XSS Reflectivo
Este tipo de ataque no es persistente, esto quiere decir que se ejecutará en base a una petición y respuesta.

XSS Almacenado
Este tipo de ataque es persistente, es decir permanece guardado y luego es ejecutado cuando el usuario ingresa a la web con código malicioso.

XSS Self
Este tipo de ataque no es persistente, funciona regularmente engañando al usuario para que el mismo se ejecute un XSS.

XSS DOM
Este tipo de ataque ocurre cuando el código malicioso es ejecutado por el navegador del usuario, sin que la información maliciosa sea transmitida al servidor.

Reportes / Ejemplos

Reportes
- Ventas al por mayor en Shopify
- Buscador de imágenes de Google
- Self XSS Iframe DiosDeLaRed cookie based

Ventas al por mayor en Shopify
Informe: Reporte Hackerone
Fecha: 21 de Diciembre, 2015
Recompensa: $500
Tipo: Reflectivo

• Descripción:
El objetivo de la pagina de Shopify era ingresar el nombre de un producto, pero este mismo formulario no estaba bien escapado por lo tanto un hacker pudo ingresar el payload más básico que puede ocurrir.

Escapo la consulta y inserto código javascript de la siguiente forma:

asd';alert('XSS');'

Recomendaciones
- Pon antecion cuando puedas visualizar un texto ingresado, trata de codificar el código de prueba.
- Los XSS no tienen porqué ser complicados, es una de las vulnerabilidades más básicas.


Buscador de imágenes de Google
Informe: Reporte by ZombieHelp54
Fecha: 12 de Septiembre, 2015
Recompensa: No divulgada
Tipo: Reflectivo

• Descripción:
Mientras Mahmound Jamal estaba buscando una imagen de perfil para hackerone se deparo que podía modificar el parámetro imgurl en el buscador de imágenes, el cual sustituyo por un javascript:alert(1), luego desplazándose con el TAB pudo obtener el mensaje "1" el cual es muestra evidente del XSS reflectivo.

La url era
"http://www.google.com.eg/imgres?imgurl=https://lh3.googleusercontent.com/-jb45vwjUS6Q/Um0zjoyU8oI/AAAAAAAAACw/qKwGgi6q07s/w426-h425/Skipper-LIKE-A-BOSS -XD-fans-of-pom-29858033-795-634.png&imgrefurl=https://plus.google.com/103620070950422848649&h=425&w=426&tbnid=ForZveNKPzwSQM:&docid=OEafHRc2DBa9eM&itg=1&tei=9ID8VSBhKgLU"

Con el cambio de parametro
"http://www.google.com.eg/url?sa=i&source=imgres&cd=&ved=0CAYQjBwwAGoVChMIjsP-48OByAIVxNMUCHh3pSQ98&url=javascript:alert(1)&psig= AFQjCNGcADmmDJe6-BWjcDAJ1pV84euDZw&ust=1442698210302078 "



Video de demostración




Self XSS cookie based with Iframe | DiosDeLaRed
Informe: Reporte by M20191
Fecha: 8 de Mayo, 2023
Recompensa: No divulgada ($0.00)
Tipo: Guardado (Solamente en local)

Esta Vulnerabilidad de se aprovecha del sistema el cual está basado la subida de archivos en dios de la red

Pude observar como eran guardados los archivos, estos mismos se subían en una cookie local.


Cargando el contenido de esa cookie en un url decoder pude visualizarlo de manera clara lo cual me permitió manipularlo


Cargamos un iframe payload


Vuala! XSS cookies Based

Recursos sobre XSS

* Articulos
- OWASP XSS
- _Y000_ XSS
- Hacksplaining

* Maquinas virtuales
- bWAPP | Suit completo de vulnerabilidades web
- DVWA | Suit básico de vulnerabilidades web
- Web4Pentesters | Suit básico de vulnerabilidades web
- Web Academy PortSwigger (Online)

* Payloads
- @tarunkant XSS
- Ismail Tasdelen XSS

Resumen

Cuando busques vulnerabilidades XSS te recomiendo lo siguiente:
- Prueba: No importa que tan pequeña o grande sea la empresa, intentarlo y fallar no te hará menos, y si logras algo serás bien recompensado.
- Modifica: Intenta jugar con los parámetros codificados, intenta escapar strings, intentalo no pierdes nada.

HTML Injection | Inyección HTML

Explicación

Esta vulnerabilidad consiste en la inyección mal intencionada de código HTML (Lenguaje de Marcado de Hipertexto) el cual forma la estructura de todo el sitio.
Esta vulnerabilidad es posible regularmente cuando el sitio permite la inclusión de etiquetas HTML dentro de si, de tal manera que el atacante puede modificar y jugar con los parámetros permitidos para modificar totalmente el sitio. A esto también se lo reconoce como ataque de desfiguración virtual.

Debido a que HTML es el lenguaje utilizado para definir la estructura de la pagina web, si un atacante puede lograr con éxito la inyección de código, podría ir desde modificar completamente el sitio hasta crear formularios para engañar al usuario pidiéndole por ejemplo que se vuelva a registrar.

Reportes / Ejemplos

Reportes
- Comentarios en Coinbase
- Contenido engañoso en el sitio Within Security

Comentarios en Coinbase
Informe: Reporte Hackerone
Fecha: 10 de Diciembre, 2015
Recompensa: $200

• Descripción:
El hacker identifico que Coinbase en su sección de comentarios estaba decodificando valores URI que estaban codificados cuando era cargado el texto.

Por lo tanto utilizo estos valores para escribir código HTML y que este sea renderizado.





Contenido engañoso en el sitio Within Security
Informe: Reporte Hackerone
Fecha: 16 de Enero, 2016
Recompensa: $250

• Descripción:
Within Security fue construido en base a Wordpress el cual incluía una ruta al login /wp-login.php
Un hacker se dio cuenta que cuando el acceso era denegado el texto provenía de un payload cargado por GET, por lo tanto se podría modificar.

Cuando ocurría un error

https://withinsecuriey/wp-login.php?error=acceso_denegado

Valor modificado

https://withinsecuriey/wp-login.php?error=Su%20cuenta%20ha%20sido%20hackeada

La clave fue simple, fijarse en el parámetro y modificarlo a nuestro gusto.

Recursos sobre HTMLi

* Articulos
- OWASP HTMLi
- Video Coinbase HTMLi

* Maquinas virtuales
- bWAPP | Suit completo de vulnerabilidades web
- DVWA | Suit básico de vulnerabilidades web
- Web4Pentesters | Suit básico de vulnerabilidades web
- Web Academy PortSwigger (Online)

Resumen

Esta vulnerabilidad es bastante simple pero muy peligrosa, actualmente los sitios web implementan una seguridad mayor a este tipo de vulnerabilidad pero no quiere decir que no exista o que no se va a encontrar más.

Para explotar este tipo de vulnerabilidades no siempre consiste en enviar texto plano HTML y estar en espera inmediata de un código representado. Es jugar y explorar mucha más allá, como en el caso de Coinbase con el texto codificado en URI, en síntesis, pensar fuera de la caja te hará ir mucho más lejos...

HPP | HTTP Parameter Pollution | Contaminación de parámetros HTTP

Explicación

Este tipo de vulnerabilidad sucede cuando el sitio web acepta datos provistos por el usuario en un parámetro payload HTTP, y utiliza estos datos provistos por el usuario en otro sistema sin validar la entrada de los mismos.

Puede suceder tanto del lado del cliente como del lado del servidor.

Un fabuloso ejemplo por SilverlightFox de un ataque HPP en el lado del Servidor:
Tenemos un servicio que transfiere dinero en esta url

https://www.example.com/enviarDinero.php

El cual puede ser accedido por el método POST tomando los siguientes parámetros:

?cantidad=100&desdeCuenta=12345

Este payload es procesado mediante el sistema con una solicitud POST a otro sistema backend que procesa la transacción con un nuevo parámetro prefijo "haciaCuenta".

URL del sistema separado: https://backend.exaplame.com/realizarTransferencia.php
Parámetros del backend separado: ?haciaCuenta=9876&cantidad=1000&desdeCuenta=12345

Suponiendo que el sistema backend tome solo el ultimo parámetro ingresado, este podría ser vulnerable a que lo modifiquemos, es decir estaríamos duplicando el parámetro y según la tecnología aplicada en el sitio podría ser tomado y utilizado como si fuera el parámetro verdadero. (ejemplo: PHP).

?cantidad=100&desdeCuenta=12345&haciaCuenta=99999

Si fuera vulnerable a este tipo de ataque podría enviar la solicitud a otro sistema backend de la siguiente forma:

?haciaCuenta=9876&cantidad=1000&desdeCuenta=12345&haciaCuenta=99999

En este caso el ultimo parámetro podría anular al primero y como consecuencia enviar el dinero a la cuenta 9999 en vez de la cuenta establecida en el primer parámetro 9876.

Desde otra perspectiva, el ataque HPP en el lado del cliente tiene que ver con la inyección no deseada de parámetros adicionales a los enlaces con la finalidad de engañar al usuario.
Ejemplo de OWASP

<? $val=htmlspecialschars($_GET['par'], ENT_QUOTES); ?>
<a href="/page.php?action=view&par=' . <?=val?>.'" >Mirame, hazme clic!</a>

Este código toma el valor del parámetro desde la URL, se asegura que solo recibirá caracteres validos y no extraños, de esta manera podríamos hacer que se ejecuten códigos no deseados dentro de esa etiqueta "a".

Reportes / Ejemplos

Reportes
- Interacciones web en Twitter
- Desinscribirse de las Notificaciones en Twitter


Interacciones web en Twitter
Informe: No disponible
Fecha: Noviembre, 2015
Recompensa: No revelada

• Descripción:
De acuerdo a su documentación, las interacciones vía web en sitios externos a twitter, proveen flujos optimizados en ventanas emergentes para trabajar con tweets o interactuar con usuario de Twitter por medio de: Tweet, Respuestas, Retweet, Me gusta, Seguir.
Esto hará posible que los usuarios interactúen con los contenidos de twitter en el contexto de tu sitio web sin dejar la pagina que se encuentra visitando o tener que autorizar una nueva aplicación web para tener la interacción previamente mencionada.
(Básicamente esta vulnerabilidad aprovechaba una ventana emergente sobre interacción de twitter en algunos posts.)



https://twitter.com/intent/follow=screen_name=twitter&screen_name=erictest2

Como dije previamente, un parámetro arriba de otro parámetro puede permitir anular al primero y eso es lo que hizo Eric.

Eric también descubrió que de forma similar al presentar interacciones para dar me gusta a un tweet podría incluir el parámetro screen_name para dicha acción.

https://twitter.com/intent/like?tweet_id=123456789123456789&screen_name=erictest3
Dando me gusta a ese tweet.


Desinscribirse de las Notificaciones en Twitter
Informe: No disponible
Fecha: 23 de Agosto, 2015
Recompensa: $700

• Descripción:
Mert Tasci detectó una URL interesante mientras se estaba desincribiendo de recibir notificaciones de Twitter.
https://twitter.com/i/u?t=1&cn=b2V&sig=657&iid=F6542&uid=1134885524&nid=22+26

Modificando el parámetro uid de la petición podrías de-suscribir a otro usuario de las notificaciones por correo.

Recursos

* Articulos
- Owasp
- Zap
- Web Academy PortSwigger (Online)

Resumen

El riesgo que posee HTTP Parameter Pollution depende realmente a las acciones realizadas con los argumentos que van a ser utilizados.

SQLi | SQL Injection

Explicación

Los ataques de inyección son un tipo muy común de ataque web, donde un atacante envía una entrada maliciosa a una API que tiene un intérprete o analizador que procesa la entrada y la pasa a un sistema o base de datos de back-end.
Si el intérprete/analizador no valida o desinfecta la entrada, entonces el atacante puede obtener acceso o manipular datos confidenciales.


Ejemplo básico de SQLi

$name = $_GET['name'];
$query = "SELECT * FROM users WHERE name = $name";

Url https://example.com/?name=

En este caso el atacante podría hacer lo siguiente:

Url https://example.com/?name=test" or 1=1;--
Obteniendo información adicional que no deberíamos de poder obtener.

En algunos casos la sentencia podría verse de esta manera:

$query = "SELECT * FROM users WHERE (name = $name AND password = 12345");

con el test' or 1=1;--

$query = "SELECT * FROM users WHERE (name = 'test' OR 1=1 AND password = 12345");

Esta consulta se comportaría de manera diferente obteniendo todos los datos donde el nombre sea igual a test y la contraseña igual a 12345, para obviar la contraseña podríamos ingresar un 1' or 1=1; -- a más.
Agregando el ;-- se interpreta como todo lo siguiente sea comentario por lo tanto no se interpretaría la contraseña y obtendríamos solamente todos los usuarios test.

Algunos tipos de SQLi

- SQLi basado en errores
- SQLi basado en uniones
- SQLi basado en booleanos
- SQLi basado en tiempo
- SQLi basado en voz

SQLi basado en errores
Este tipo de ataque se basa en provocar errores en la consulta SQL para obtener información de la base de datos.

SQLi basado en uniones
Este tipo de ataque utiliza la función UNION de SQL para combinar los resultados de dos o más consultas y obtener información de la base de datos.

SQLi basado en booleanos
Este tipo de ataque utiliza operadores booleanos como AND, OR y NOT para obtener información de la base de datos.

SQLi basado en tiempo
Este tipo de ataque utiliza retrasos en las respuestas de la base de datos para obtener información de la base de datos.

SQLi basado en voz
Es un método de ataque de inyección de sql que se puede aplicar en aplicaciones que brindan acceso a bases de datos con comando de voz. Un atacante podría extraer información de la base de datos enviando consultas SQL con sonido.

Es importante tener en cuenta que existen otros tipos de SQLi, y que cada uno de ellos puede tener distintos niveles de complejidad y peligrosidad
NOTA: ¡Más Información!

Reportes / Ejemplos

Reportes
- Inyección SQL a ciegas en Yahoo Sports


Inyección SQL a ciegas en Yahoo Sports
Informe: esevece tumblr40
Fecha: 16 de Febrero, 2014
Recompensa: $3,705

• Descripción:
Gracias al paramero year en http://sports.yahoo.com/nfl/draft?year=2010&type=20&round=2 se puso encontrar una SQLi a ciegas.



Stefano añade -- a la consulta


Con esto, Stefano empezó a escarbar información sobre la base de datos de Yahoo


Esto nos indica que la versión de la base de datos no es 5 porque no se devolvió ningún resultado. Es importante revisar la hoja de trucos de MySQL en la página de Recursos para obtener más funcionalidades cuando estemos probando una SQLi.

La razón por la que se llama "inyección a ciegas" es porque Stefano no pudo ver directamente los resultados, sólo vio que Yahoo estaba devolviendo jugadores. Sin embargo, si manipulaba la consulta y comparaba el resultado con la consulta base, podría obtener más información de la base de datos de Yahoo.

Recursos sobre SQLi

* Articulos
- PortSwigger SQLi
- OWASP SQLi
- InfoSec | Info + Payloads
- HackTricks | Info + Payloads
- SQL Injection Bypassing WAF

* Maquinas virtuales
- bWAPP | Suit completo de vulnerabilidades web
- DVWA | Suit básico de vulnerabilidades web
- Web4Pentesters | Suit básico de vulnerabilidades web
- Web Academy PortSwigger (Online)

* Payloads
- PayloadBox SQLi

Resumen

Las inyecciones SQL si son ejecutadas correctamente podrían llegar a ser bastante perjudiciales para el sitio web al que estemos queriendo atacar, por lo tanto el valor de la recompensa también lo será.

NoSQLi (NoSQL Injection)

Explicación

La inyección NoSQL, también conocida como NoSQLi, es un tipo de ataque que se dirige a bases de datos NoSQL, a diferencia de la inyección SQL que se dirige a bases de datos relacionales. Los sistemas NoSQL son populares por su escalabilidad y flexibilidad, pero a menudo carecen de los controles de seguridad y validación adecuados para protegerse contra los ataques de inyección.

Los atacantes utilizan técnicas similares a las utilizadas en la inyección SQL para enviar entradas maliciosas a la aplicación web y engañar al sistema para que ejecute comandos no deseados o divulgue información confidencial.

Al igual que con la inyección SQL, es importante seguir las mejores prácticas de seguridad para proteger tus aplicaciones web de ataques de inyección NoSQL. Esto incluye la validación adecuada de la entrada del usuario, la implementación de consultas parametrizadas y la limitación de los privilegios de base de datos a los usuarios necesarios.

Ejemplos

Para poder realizarse una NoSQLi se debe de enviar datos JSON a un servidor, ya que con esto podremos manipularlos y insertar sentencias NoSQL

Equivalencias SQL - NoSQL:

> es $gt, < es $lt, >= es $gte, y <= es $lte.

' or 1 = 1 — a es, {$gt:}

Mediante nuevos modulos de Node.JS se puede convertir los parámetros de las peticiones HTTP en objetos JSON.
Una petición del estilo username[valor]=admin&password[valor]=admin se convertiría a {username:{valor:admin},password:{valor:admin}}.

Se ejecutaría un codigo como este para la comprobacion del usuario:
db.collection(collection).find({username:username,password:password}).limit(1)


Ingresando el siguiente payload {$gt:} estariamos forzando a que la password nos devuelva un TRUE.
De este modo podriamos acceder al admin sin necesidad de contraseña.



Tambien existen otras formas de vulnerar un NoSQLi, puedes verificarlas en los articulos.

Recursos No-SQLi

- Inyección noSQL BY LETHANI
- Hacktricks - No-SQLi

Resumen

La inyección NoSQL es una amenaza emergente en aplicaciones web que utilizan bases de datos NoSQL.
Es importante tomar medidas para protegerse contra estos ataques, incluyendo la validación adecuada de entrada de usuario y la implementación de consultas parametrizadas.
A medida que los sistemas NoSQL se vuelven más populares, la prevención de la inyección NoSQL se vuelve cada vez más importante para mantener la seguridad de tus aplicaciones web.

GraphQL Injection

Explicación

GraphQL es un lenguaje de consulta y manipulación de datos que se utiliza para interactuar con una API en la web. A diferencia de REST, que utiliza diferentes endpoints para diferentes tipos de datos, GraphQL utiliza un solo endpoint para toda la API.
Cabe aclarar que ñas solicitudes de datos se realizan mediante una única URL HTTP utilizando el método POST. La solicitud se compone de una sola cadena de consulta GraphQL que define los datos solicitados y los argumentos de consulta opcionale

POST /graphql HTTP/1.1
Host: example.com
Content-Type: application/json
Authorization: Bearer <token>

{
  "query": "query ($userId: ID!) { user(id: $userId) { name, email } }",
  "variables": {
    "userId": "12345"
  }
}

En este ejemplo, la solicitud se realiza mediante el método POST a la URL "/graphql" en el servidor "example.com". La solicitud incluye el encabezado "Content-Type" establecido en "application/json" y un encabezado de autorización que proporciona un token de autenticación.

La cadena de consulta GraphQL se define en el cuerpo de la solicitud y utiliza la consulta "user" con el argumento "id" establecido en "12345". También se incluye una variable de GraphQL llamada "userId" que se utiliza como valor para el argumento "id". La respuesta del servidor incluirá los campos "name" y "email" para el usuario correspondiente al "userId" proporcionado.


GraphQL es especialmente vulnerable a los ataques de inyección por varias razones
1) GraphQL presenta nuevas superficies para inyecciones, a través de funciones como nombres de operaciones y alias.
2) GraphQL introduce nuevos pasos en el flujo de procesamiento. Cada uno de los analizadores, la puerta de enlace y los resolutores de subgráficos pueden ser objetivos de un ataque.
3) GraphQL convierte lo que serían varias llamadas API con una API REST en una sola llamada. Esta única llamada puede dirigirse a múltiples áreas y multiplicar las combinaciones de inyección debido a la naturaleza de forma libre de GraphQL.

Al realizar ataques de fuerza bruta en su directorio, asegúrese de agregar las siguientes rutas para verificar las instancias de graphQL

* /graphql
* /graphiql
* /graphql.php
* /graphql/console

Una vez que encuentre una instancia de graphQL abierta, necesita saber qué consultas admite.
Esto se puede hacer usando el sistema de introspección, se pueden encontrar más detalles Aquí

Simple Query

{
  __schema {
    types {
      name
    }
  }
}

Ejemplos de ataques de inyección
Los ataques de inyección de GraphQL pueden conducir a algunos escenarios diferentes:
* DoS (sobrecargar el analizador o resolver hasta el punto de fallar)
* Extraer datos
* Manipular datos

A continuación, cubriremos algunas tácticas específicas que los atacantes pueden usar en un ataque de inyección, incluidos alias, inyecciones SQL, inyecciones de comandos, ataques XSS y NoSQL.

SQL injection

query {
  customer(id: "22371' OR 1=1–") {
    name, 
    email, 
    address, 
    contact
  }
}

Durante la fase de ejecución, el código anterior haría que la consulta devolviera todos los detalles del cliente en lugar de solo el cliente que coincidía con la consulta original.

NoSQL injection

query {
    users(search: "{"username": {"$regex": "jan"}, "email": {"$regex": "jan"}}",
          options: "{"skip": 0, "limit": 10}") {
        _id
        username
        fullname
        email
    }
}

El atacante podría modificar los campos de tipo de datos JSON para incluir MongoDB u otros comandos específicos de la base de datos NoSQL, que luego serían ejecutados por la base de datos cuando se procesa la consulta GraphQL.

Command injection

query {
  getUser(id: "1; ls -la") {
    name
    email
  }
}

Si el servidor usa una API que interpreta una cadena como un comando de shell (por ejemplo, usa child_process.execFile), esto haría que el servidor ejecutara el comando ls -la.

XSS (Cross-Site Scripting)

query {
  getComment(id: "1") {
    user
    comment: "<script>alert('XSS Attack')</script>"
  }
}

Cuando un usuario ve los resultados de esta consulta, el script malicioso se ejecutará en su navegador.

HTML injection
Las inyecciones de HTML son similares a los ataques XSS.
La siguiente consulta demuestra cómo un atacante puede crear una inyección HTML:

mutation {
 createPaste(title:"<h1>hello!</h1><script>alert('Attack')</script>", content:"zzzz", public:true) {
   paste {
     id
   }
 }
}

Resumen

Articulos
Inigo
Hacktricks
Boitatech
Yeswerhackers

* Online Exploit
Graphiql

Command Execution

Explicación

Command Execution (Ejecución de Comandos) es una vulnerabilidad en la cual un atacante puede ejecutar comandos en el sistema comprometido a través de una entrada de usuario insegura.
En otras palabras, un atacante puede introducir comandos maliciosos en un sistema vulnerable y el sistema los ejecutará como si fueran comandos legítimos, permitiendo que el atacante realice actividades maliciosas.

La vulnerabilidad de Command Execution generalmente se explota utilizando funciones en PHP que permiten ejecutar comandos del sistema operativo, como por ejemplo:
• exec()
• system()
• passthru()
• shell_exec()
• popen()
• proc_open()

Estas funciones pueden ser utilizadas para ejecutar comandos en el sistema operativo que aloja la aplicación PHP.

Un simple ejemplo de como se podría llegar a ocasionar un CE en php:

    // Recupera el comando a ejecutar del usuario
    $command = "ls ".$_GET['modifiers'];
 
    // Ejecuta el comando utilizando la función system
    $output = system($command);
?>

Ejemplos

Pentester Lab (lvl 1 CE)

Ejemplo simple de Code Execution

Podríamos suponer el código PHP que se esta ejecutando

    // Recupera el comando a ejecutar del usuario
    $command = "ping ".$_GET['ip'];
 
    // Ejecuta el comando a nivel del sistema
    $output = exec($command);
?>

En el ejemplo anterior usamos el ; ya que se utiliza en la consola Linux para separar comandos.
De esta manera podemos saltar e inyectar otro tipo de comando.

Teniendo esto en cuenta podemos mencionar otros tipos de separadores:
• El tubo (|) se utiliza para separar comandos y ejecutarlos uno después del otro.
• El punto y coma (;) se utiliza para separar comandos y ejecutarlos uno después del otro, sin importar el resultado del comando anterior.
• El doble ampersand (&&) se utiliza para ejecutar el segundo comando sólo si el primer comando se ejecutó correctamente.
• El doble tubo (||) se utiliza para ejecutar el segundo comando sólo si el primer comando falló

Teniendo esto en cuenta podríamos volver al ejemplo anterior y modificar el parámetro. (; a |)

Obtenemos el mismo resultado

Te invito personalmente a que sigas avanzando de nivel en este reto, verás que no siempre es usar un ;, &&,... ¡Suerte!

Reporte

- Informe: HackerOne
- Fecha: October 5, 2021
- Severity High (7 ~ 8.9)
- Recompensa: $1000

"El parámetro seed_id será vulnerable a los ataques de inyección de comandos del sistema operativo"
De esa forma empieza el reporte, brevemente nos explica que un parámetro "seed_id" ingresado mediante un payload en la url es vulnerable a OS Command Injection, también aclara que la respuesta de lo que inyectemos no se verá reflejada en la página pero sí es posible su comprobación mediante un una carga útil de tiempo o haciéndola interactuar con otros dominios.

Petición por defecto
https://api.seedr.ru/uploads/521b62f5b7132de722027388%7Cnslookup%20-q=cname%200vwm3493ytajvrc4a2g7ptfmgdm7a04o0crzhn6.burpcollaborator.net.&.zip

Decoded
https://api.seedr.ru/uploads/521b62f5b7132de722027388|nslookup -q=cname 0vwm3493ytajvrc4a2g7ptfmgdm7a04o0crzhn6.burpcollaborator.net.&.zip

Petición con retraso de tiempo
https://api.seedr.ru/uploads/521b62f5b7132de722027388%7Cping%20-n%2021%20127.0.0.1%7C%7C%60ping%20-c%2021%20127.0.0.1%60%20#'%20|ping%20-n%2021%20127.0.0.1||%60ping%20-c%2021%20127.0.0.1%60%20#\%22%20|ping%20-n%2021%20127.0.0.1.zip

Decoded
https://api.seedr.ru/uploads/521b62f5b7132de722027388|ping -n 21 127.0.0.1||'ping -c 21 127.0.0.1' #' |ping -n 21 127.0.0.1||'ping -c 21 127.0.0.1' #" |ping -n 21 127.0.0.1.zip

Recursos

* Articulos
- OWASP CI
- CrashTest
- BrightSec
- HackTricks
- PortSwigger
- HackerOne
- StackHawk

* Maquinas virtuales
- WebGoat
- OWASP Juice Shop
- Damn Vulnerable Web Application (DVWA)
- Mutillidae II
- Web4Pentesters | Suit básico de vulnerabilidades web

Resumen

Es importante tener en cuenta que la vulnerabilidad de Command Execution puede tener graves consecuencias en la seguridad de un sistema y en la privacidad de los usuarios. Por esta razón, es fundamental tomar medidas preventivas para evitar su explotación, como validar y sanitizar adecuadamente las entradas de usuario y limitar los privilegios de los procesos que ejecutan comandos en el sistema.

RCE (Remote Code Execution)

Explicación

El término ejecución arbitraria de código hace referencia a la capacidad de un atacante para ejecutar comandos o inyectar código en una aplicación remota, conectándose a ella a través de redes públicas o privadas.

Un atacante puede lograr RCE de varias maneras diferentes, que incluyen:

Ataques de inyección: (Injection Attacks)
Muchos tipos diferentes de aplicaciones, como consultas SQL, utilizan datos proporcionados por el usuario como entrada para un comando.
En un ataque de inyección, el atacante proporciona deliberadamente una entrada mal formada que hace que parte de su entrada se interprete como parte del comando. Esto permite a un atacante dar forma a los comandos ejecutados en el sistema vulnerable o ejecutar código arbitrario en él.

Ataques de deserialización: (Deserialization Attacks)
Las aplicaciones suelen utilizar la serialización para combinar varios datos en una sola cadena para que sea más fácil de transmitir o comunicar.
La entrada de usuario con formato especial dentro de los datos serializados puede ser interpretada por el programa de deserialización como código ejecutable.

Escritura fuera de los límites: (Out-of-Bounds Write)
Las aplicaciones asignan regularmente fragmentos de memoria de tamaño fijo para almacenar datos, incluidos los datos proporcionados por el usuario.
Si esta asignación de memoria se realiza incorrectamente, un atacante puede diseñar una entrada que escriba fuera del búfer asignado y con esto lograr que se ejecute código.

Reportes / Ejemplos

Reportes
- Log4j
- ETERNALBLUE
- CVE-2021-1844
- CVE-2020-17051
- CVE-2019-8942

Log4j
Log4j es una popular biblioteca de registro de Java que se utiliza en muchos servicios y aplicaciones de Internet.
En diciembre de 2021, se descubrieron múltiples vulnerabilidades RCE en Log4j que permitieron a los atacantes explotar aplicaciones vulnerables para ejecutar cryptojackers y otro malware en servidores comprometidos.
Log4Shell Minecraft

ETERNALBLUE
WannaCry introdujo el ransomware en la corriente principal en 2017.
El gusano ransomware WannaCry se propagó al explotar una vulnerabilidad en el Protocolo de bloqueo de mensajes del servidor (SMB). Esta vulnerabilidad permitió a un atacante ejecutar código malicioso en máquinas vulnerables, lo que permitió que el ransomware accediera y cifrara archivos valiosos.

CVE-2021-1844
Una vulnerabilidad en los módulos del sistema operativo de Apple iOS, macOS, watchOS y Safari.
Cuando una víctima usa un dispositivo vulnerable para acceder a una URL controlada por un atacante, el sistema operativo ejecuta una carga maliciosa en ese dispositivo.

CVE-2020-17051
Una vulnerabilidad que afecta a un protocolo de comunicación de Microsoft Windows, NFS (Network File System)v3.
Un atacante puede usarlo para conectarse a un servidor NFS vulnerable y enviar una carga útil para que se ejecute en el punto final de destino.

CVE-2019-8942
Una vulnerabilidad en WordPress 5.0.0, que permite a los atacantes ejecutar código arbitrario en WordPress cargando un archivo de imagen especialmente diseñado que incluye código PHP en su metadata Exif.

Ejemplos de RCE con PHP

Similar a la función system() en C, system() en PHP ejecuta todas las entradas como comandos de shell en la máquina.
Si se pasan las entradas mediante el usuario, esto conducirá a la ejecución del código.

<?php
$cmd = $_GET['cmd'];
system($cmd); 
?>

http://www.example.com/?cmd=command
La documentación de PHP advierte a los desarrolladores que no lo utilicen sin una función de saneamiento de entrada.

RCE tiene muchas más variantes de las que cubrí, intente explorarlas, ya que vale la pena dedicarle tiempo.
Por ejemplo, existen muchas técnicas para eludir los firewalls de aplicaciones web y otros programas de desinfección.

Recursos

* Articulos
- Crowdstrike
- Techtarget
-
Sr. Mudhalai
- Qualys Blog

* Maquinas virtuales
- WebGoat
- Damn Vulnerable Web Application (DVWA)
- Mutillidae II
- Web4Pentesters | Suit básico de vulnerabilidades web

* Payloads
- HackTricks

LFI (Local File Inclusion)

Explicación

La inclusión de archivos locales es una técnica de ataque en la que los atacantes engañan a una aplicación web para que ejecute o exponga archivos en un servidor web.
Los ataques LFI pueden exponer información confidencial y, en casos graves, pueden generar secuencias de comandos entre sitios (XSS) y ejecución remota de código (RCE).

Las inclusiones de archivos son una clave para cualquier lenguaje del lado del servidor y permiten que el contenido de los archivos se use como parte del código de la aplicación web.

Aquí hay un ejemplo de cómo LFI puede permitir a los atacantes extraer información confidencial de un servidor. Si la aplicación usa código como este, que incluye el nombre de un archivo en la URL:

https://example-site.com/?module=contact.php

Un atacante puede modificar la URL y proponer lo siguiente:

https://example-site.com/?module=https://example-site.com/?module=/etc/passwd

Y en ausencia de un filtrado adecuado, el servidor mostrará el contenido confidencial del archivo /etc/passwd.

Impacto

1). Divulgación de información
Aunque no es el peor resultado de una vulnerabilidad de inclusión de archivos locales, la divulgación de información puede revelar información importante sobre la aplicación y su configuración. Esa información puede ser valiosa para un atacante para obtener una comprensión más profunda de la aplicación y puede ayudarlos a detectar y explotar otras vulnerabilidades.

2). Directorio Traversal
Una vulnerabilidad de inclusión de archivos locales puede conducir a ataques de Directorio Traversal, donde un atacante intentará encontrar y acceder a archivos en el servidor web para obtener información más útil, como archivos de registro. Los archivos de registro pueden revelar la estructura de la aplicación o exponer rutas a archivos confidenciales.

Un servidor configurado incorrectamente puede dar a los atacantes acceso a archivos de configuración de usuario, dándoles acceso a otros archivos en su servidor o incluso obtener acceso de administrador.

Si desea obtener más información sobre el directorio transversal, tenemos un gran artículo que cubre esta vulnerabilidad con mayor profundidad – Directorio Traversal: ejemplos, pruebas y prevención

3). Ejecución remota de código
Combinado con una vulnerabilidad de carga de archivos, una vulnerabilidad de archivo local puede conducir a la ejecución remota de código. En este caso, el atacante usaría LFI para ejecutar el archivo no deseado.

Para agravar las cosas, un atacante puede cargar un archivo en el servidor para obtener la capacidad de ejecutar comandos de forma remota, lo que hace que el atacante pueda controlar todo el servidor de forma remota.

Ejemplos

Una forma de realizar pruebas en una aplicación web es colocar un valor inexistente en una variable, por ejemplo en una URL como http://web.com/index.php?page= se puede colocar un valor inexistente como http://web.com/index.php?page=x7uk. Si al hacer esto, la aplicación devuelve un error como "Warning: main()..." o "Warning: include()..." es posible que exista una vulnerabilidad de RFI o LFI en la aplicación.

Codigo vulnerable:

<?php
include $_GET['pagina'];
?>

Codigo NO vulnerable:

<?php
include('page.php');
?>

Para que una web sea vulnerable a LFI, se necesita poder modificar los parámetros de lo que se va a incluir. Si el código que se muestra es "include('page.php')", no es vulnerable a LFI porque no hay nada que se pueda modificar. Sin embargo, si el código es "include $_GET['pagina']", es posible modificar los parámetros que se van a incluir a través de la URL, como en el caso de "http://web.com/index.php?pagina=x7uk.php". De esta manera, se puede incluir cualquier archivo en el servidor, como el archivo de contraseñas de Linux "/etc/passwd".




Inyección de bytes nulos
El carácter nulo (también conocido como terminador nulo o byte nulo) es un carácter de control con el valor cero presente en muchos conjuntos de caracteres que se utiliza como carácter reservado para marcar el final de una cadena. Una vez utilizado, se ignorará cualquier carácter después de este byte especial. Por lo general, la forma de inyectar este carácter sería con la cadena codificada de URL %00 agregándola a la ruta solicitada. En nuestro ejemplo anterior, realizar una solicitud a http://vulnerable_host/preview.php?file=../../../../etc/passwd%00 ignoraría la extensión .php que se agrega al nombre de archivo de entrada , devolviendo a un atacante una lista de usuarios básicos como resultado de una explotación exitosa.

$theme=$_GET['theme'];
require($theme."/config.php");

En el caso:
?theme=/etc/passwd%00

Reportes

- Full local fylesystem access (LFI/LFD) as admin via Path Traversal in the misconfigured Java servlet from
U.S. Dept Of Defense


Full local fylesystem access (LFI/LFD) as admin via Path Traversal in the misconfigured Java servlet from
U.S. Dept Of Defense
- Informe: HackerOne
- Fecha: Febrero 18, 2019
- Recompensa: No divulgada

Descripción:
Este reporte mantiene las urls ocultas pero no el payload y por lo tanto es útil para que vean como se realiza un LFI/LFD

Se trata de acceder al archivo c:/windows/System32/drivers/etc/hosts

GET /gwtmain//..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252fwindows/System32/drivers/etc/hosts HTTP/1.1
Host: ----------
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close

En el buscador

https://-------/gwtmain//..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252fwindows/System32/drivers/etc/hosts

Testeando si tiene permisos de administrador

GET /gwtmain//..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252fUsers/Administrator/NTUser.dat HTTP/1.1
Host: ----
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close

El sistema retorna 200 ok sobre el archivo Users/Administrator/NTUser.dat el cual es accesible solamente para cuentas del administrador.

Payloads

En un LFI, los payloads pueden ser utilizados para incluir archivos locales del sistema que normalmente no deberían ser accesibles, como archivos de configuración, contraseñas y otros datos sensibles.
Algunos ejemplos de payloads comunes incluyen "../" para acceder a un directorio padre, o "../../../etc/passwd" para acceder al archivo de contraseñas del sistema.
Los métodos utilizados para explotar una vulnerabilidad de LFI incluyen HTTP GET y POST, así como otros métodos de petición HTTP. El uso de estos métodos puede variar según la aplicación y el objetivo del ataque.

Recursos

* Articulos
- OWASP
- Brightsec

* Maquinas virtuales
- WebGoat
- OWASP Juice Shop
- Damn Vulnerable Web Application (DVWA)
- Mutillidae II
- Web4Pentesters | Suit básico de vulnerabilidades web
- Hacktricks

* Payloads
- Hacktricks

Hacking Webs

• Attack-Defense
• Alert to win
• CTF Komodo Security
• CryptoHack
• CMD Challenge
• Exploitation Education
• Google CTF
• HackTheBox
• Hackthis
• Hacksplaining
• Hacker101
• Hacker Security
• Hacking-Lab
• HSTRIKE
• NewbieContest
• OverTheWire
• Practical Pentest Labs
• Pentestlab
• Hackaflag BR
• Penetration Testing Practice Labs
• PentestIT LAB
• PicoCTF
• PWNABLE
• Root-Me
• Root in Jail
• SANS Challenger
• SmashTheStack
• The Cryptopals Crypto Challenges
• Try Hack Me
• Vulnhub
• W3Challs
• WeChall
• Zenk-Security
• Cyberdefenders
• LetsDefend
• Vulnmachines
• Rangeforce
• Ctftime
• Pwn college