Clase 07: Inyección de comandos en otros componentes

Taller de Seguridad Web

Claudio Salazar (csalazar spect cl)



Sky - Beige - Simple - Serif - Night - Default

Agenda

  • Sistema operativo.
  • XML.
  • Peticiones HTTP.
  • Otros tipos.


Esta clase está basada en el capítulo 10 "Attacking Back-End Components" del libro "The Web Application Hacker's Handbook 2".

Sistema operativo

Inyección en el S.O.

  • Se inyectan comandos válidos en consultas pasadas a la shell.
  • Un vector válido dependerá del sistema operativo subyacente.
  • Este tipo de inyección no está relacionada sólo con aplicaciones web.

Demo de inyección en el S.O.

Inyección a través de ejecución dinámica

Algunos lenguajes web permiten ejecución dinámica de código en tiempo de ejecución. Además de ser una práctica no recomendada, se podrían ejecutar comandos arbitrariamente.


El vector de inyección dependerá del lenguaje de programación usado y su configuración.

Prevención

  • Ocupar APIs si es posible, en vez de realizar la consulta al S.O.
  • Usar funciones seguras proporcionadas por el lenguaje.
  • Al igual que en el lado del cliente, evitar ejecutar datos como código.

XML

Inyección de entidades externas (XEE)

  • Algunas bibliotecas soportan el uso de referencia a entidades.
  • La especificación XML soporta referencias externas que son solicitadas por el parser.

  • 
        <!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd">]>
        <search>&xxe;</search>
        

Demo de XEE

Inyección en servicios SOAP

  • SOAP es un protocolo que usa XML para encapsular datos.
  • Así, parámetros recibidos por la aplicación forman parte de un documento XML enviado a un servicio.
  • Se puede dar el caso de inyectar etiquetas que generen comportamientos inesperados.
  • La solución es aplicar codificación HTML a los datos contenidos en los parámetros iniciales.

Peticiones HTTP

Redirección HTTP

  • Datos suministrados por el usuario son usados para realizar peticiones por el servidor.
  • Dependiendo de cómo se usan estos datos, se podrían consultar servicios.
  • El siguiente nivel es Server Side Request Forgery (SSRF).
  • http://example.org/index?loc=192.168.1.50:22

    Server Side Request Forgery [1]

    • El equivalente de CSRF pero en el lado del servidor.
    • Se caracteriza por ser un puente para explotar otras vulnerabilidades.
    • La criticidad dependerá del grado de control sobre la petición inyectada.

    Server Side Request Forgery: Flujo [1]

    • Se envía paquete A a servicio A.
    • Servicio A envía paquete B a servicio B.
    • Servicios pueden estar en el mismo o diferentes hosts.
    • Se pueden manipular algunos campos del paquete B dentro del paquete A.
    • Diferentes ataques dependerán en cuantos campos del paquete B se controlen.

    Inyección de parámetros HTTP (HPI)

    • Parámetros HTTP son pasados a futuras peticiones HTTP al back-end.
    • Lo anterior busca atacar la lógica de la aplicación.
    • Descubrimiento complicado sin código fuente de la aplicación.

    http://example.org/index?param1=12345%26param2%3dvalue

    Contaminación de parámetros HTTP (HPP)

    • Comparte un vector de ataque similar a HPI.
    • Se ataca la lógica de cómo el servidor accede a los parámetros.
    • Posibilita bypass de filtros.
    • También posible cuando URLs son reescritas.

    http://example.org/index?param1=12345&param1=67890

    Otros tipos

    Inyección LDAP

    • Debido a que es un lenguaje de consulta se pueden dar inyecciones.
    • También existen vectores para hacer explotaciones ciegas.
    • La solución es escapar los carácteres conflictivos.

    Demo de inyección LDAP

    Inyección SMTP

    • Algunas veces la aplicación genera la conversación con el servidor SMTP.
    • Es posible añadir nuevo contenido al email usando saltos de línea.
    • Una validación rigurosa debe ser aplicada para este tipo de escenarios.

    This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.