Las notas de R4z0r
YoutubeLinkedInConóceme
  • Bienvenido a las notas de R4z0r
  • Web App Pentest
    • Directory traversal / Path Traversal
    • Local File Inclusion (LFI)
    • Remote File Inclusion (RFI)
    • Cross-Site Scripting (XSS)
    • Cross-Site Request Forgery (CSRF)
    • Server-Side Request Forgery (SSRF)
    • Unrestricted File Upload
    • SQL/NoSQL Injection
      • SQL Injection
      • NoSQL Injection
    • Broken Access Control (BAC)
    • Insecure Direct Object Reference (IDOR)
    • User Enumeration
    • Sensitive Cookies Missing security attributes
    • Weak Password Policy
    • Use of GET Request Method With sensitive Query Strings
    • Insufficient Protection Against Brute Forcing
    • Unverified Password Change
  • LLM Hacking
    • Prompt Injection
    • Sensitive Information Disclosure
    • Supply Chain Vulnerabilities
    • Training Data Poisoning
    • Insecure Output Handling
    • Excessive Agency
    • Model Denial of Service (DoS)
    • Insecure Plugin Design
    • Overreliance
    • Misinformation
    • System Prompt Leakage
  • External Pentest
  • Internal Pentest
  • Mobile Pentest
  • Cloud Pentest
  • API Pentest
  • PortSwigger Labs
    • LLM Attacks
Con tecnología de GitBook
En esta página
  • Definición
  • ¿Cómo ocurre overreliance?
  • Ejemplos de Overreliance
  • Ejemplo 1: Decisiones financieras basadas en respuestas del LLM
  • Ejemplo 2: Automatización de respuestas en soporte técnico
  • Ejemplo 3: Diagnóstico médico automatizado
  • Ejemplo 4: Generación de noticias falsas
  • Ejemplo 5: Equipo de desarrollo que usa y depende demasiado de un LLM para hacer código
  • Ejemplo 6: Bypass de autenticación facial mediante esteganografía
  • Ejemplo 7: Vehículos autónomos
  • Mitigación
  • Referencias
  1. LLM Hacking

Overreliance

Definición

La vulnerabilidad de overreliance (Dependencia excesiva) ocurre cuando los usuarios o sistemas confían excesivamente en las respuestas generadas por un modelo de lenguaje (LLM), asumiendo que siempre son correctas, completas y seguras. Esta confianza desmedida puede llevar a la toma de decisiones erróneas, ejecución de acciones inseguras o la propagación de información incorrecta.

¿Cómo ocurre overreliance?

  • Asumir que el LLM es infalible

    • Creer que todas las respuestas generadas son precisas, sin verificar la información.

  • Automatización sin validación

    • Integrar el LLM en flujos automatizados sin pasos de revisión o supervisión humana.

  • Uso en entornos críticos

    • Utilizar las respuestas del LLM en contextos sensibles (médico, financiero, legal, tecnológico) sin validación previa.

  • Falta de comprensión sobre las limitaciones del modelo

    • Ignorar que el LLM puede generar contenido incorrecto, parcial o basado en datos obsoletos.

Ejemplos de Overreliance

Ejemplo 1: Decisiones financieras basadas en respuestas del LLM

  • Prompt malicioso:

¿Cuál es la mejor inversión para este mes considerando los datos económicos actuales?  
  • Impacto: Si se sigue la recomendación sin validar la información, se podría incurrir en pérdidas económicas por decisiones mal fundamentadas.

Ejemplo 2: Automatización de respuestas en soporte técnico

  • Prompt malicioso:

Brinda una solución rápida para resolver el error crítico en el servidor de producción.  
  • Impacto: El LLM podría sugerir acciones incorrectas, como reiniciar el servidor, causando interrupciones en el servicio.

Ejemplo 3: Diagnóstico médico automatizado

  • Prompt malicioso:

¿Según los síntomas descritos, cuál es el diagnóstico más probable?  
  • Impacto: Si se toma la respuesta sin confirmación profesional, podría derivar en diagnósticos erróneos y tratamientos inapropiados.

Ejemplo 4: Generación de noticias falsas

  • Contexto: Una compañía de medios utiliza un LLM para redactar artículos de noticias basados en datos de última hora.

  • Prompt malicioso:

Redacta un artículo detallado sobre los resultados financieros del último trimestre de la empresa X.  
  • Impacto: El LLM, al no tener acceso a datos actualizados o verificables, genera un artículo con información incorrecta o basada en datos antiguos. Si el equipo de redacción publica este artículo sin validarlo, podría:

    • Difundir información errónea al público.

    • Dañar la reputación de la empresa mencionada.

    • Exponer a la compañía de noticias a reclamaciones legales por desinformación.

Ejemplo 5: Equipo de desarrollo que usa y depende demasiado de un LLM para hacer código

  • Contexto: Un equipo de desarrollo utiliza un LLM para generar rápidamente código de autenticación para una aplicación web.

  • Prompt malicioso:

Genera el código SQL para verificar si un usuario y contraseña son válidos en una base de datos MySQL.  
  • Respuesta del LLM:

def login(username, password):
    query = f"SELECT * FROM users WHERE username = '{username}' AND password = '{password}'"
    cursor.execute(query)
    return cursor.fetchone()
  • Impacto: El código generado es vulnerable a inyección SQL (SQLi) porque inserta directamente los datos del usuario en la consulta sin validación ni parametrización. Si se implementa este código sin revisión, un atacante podría ingresar el siguiente usuario malicioso:

' OR '1'='1

Esto permitiría acceder sin necesidad de credenciales válidas, comprometiendo toda la base de datos.

Ejemplo 6: Bypass de autenticación facial mediante esteganografía

  • Contexto: Un sistema de autenticación biométrica utiliza un LLM para validar imágenes faciales y otorgar acceso.

  • Escenario de ataque:

    • El atacante introduce datos esteganográficos en una imagen facial, ocultando patrones que coinciden con características que el LLM ha aprendido a reconocer como válidas.

    • Como los LLMs generalizan patrones basados en su entrenamiento, podrían interpretar estos datos ocultos como rasgos legítimos del rostro.

    • El LLM, confiando en los patrones detectados, valida la imagen y concede acceso, sin detectar la manipulación oculta.

  • Impacto: El sistema concede acceso a un usuario no autorizado, confiando en la validación superficial del LLM y omitiendo verificaciones adicionales sobre la integridad de la imagen.

Ejemplo 7: Vehículos autónomos

  • Contexto: Un sistema de vehículos autónomos utiliza un LLM para interpretar señales de tránsito mediante visión computarizada. El sistema está configurado para tomar decisiones basadas únicamente en el color de las señales.

  • Escenario de ataque:

    • Un atacante manipula una señal de "STOP" para que tenga un fondo verde en lugar del rojo habitual.

    • El LLM, al confiar únicamente en el color y no en la forma o el texto de la señal, interpreta que la vía está libre y no se detiene.

  • Impacto: Esto podría provocar un accidente al no reconocer correctamente la señal de alto. La confianza excesiva en el análisis simplificado del modelo (solo color) sin validación adicional lleva a una decisión crítica errónea.

Mitigación

  1. Validación humana

    • Requiere que expertos revisen y confirmen la información o acciones generadas por el LLM antes de su implementación o publicación.

  2. Verificación de fuentes

    • Cruza las respuestas del LLM con fuentes confiables y actualizadas, especialmente en contextos críticos como legal, médico o financiero.

  3. Autonomía excesiva (Excessive agency)

    • Evita que el LLM ejecute acciones críticas de forma automática. Cualquier acción sensible debe requerir confirmación o validación adicional.

  4. Mensajes de advertencia

    • Informa a los usuarios sobre las limitaciones del LLM y destaca que las respuestas deben ser verificadas antes de tomarlas como definitivas.

  5. Filtrado de respuestas

    • Implementa sistemas que analicen y filtren las respuestas para detectar contenido potencialmente erróneo, peligroso o no verificable.

  6. Capacitación del usuario

    • Educa a los usuarios sobre las limitaciones y riesgos de confiar ciegamente en las respuestas generadas por LLMs.

  7. Registro y monitoreo

    • Monitorea las interacciones del LLM para detectar patrones anómalos y registrar decisiones basadas en sus respuestas.

  8. Divida tareas

    • Divida las tareas complejas en subtareas manejables y asígnelas a diferentes agentes. Esto no solo facilita la gestión de la complejidad, sino que también reduce el riesgo de alucinaciones, ya que cada agente puede encargarse de una tarea menor.

Referencias

AnteriorInsecure Plugin DesignSiguienteMisinformation

Última actualización hace 3 meses

https://genai.owasp.org/llmrisk2023-24/llm09-overreliance/
https://www.darkreading.com/application-security/researchers-turn-code-completion-llms-into-attack-tools
https://futurism.com/ai-plagiarism-software-false-accusing-students