Mostrando entradas con la etiqueta auditoría. Mostrar todas las entradas
Mostrando entradas con la etiqueta auditoría. Mostrar todas las entradas

sábado, octubre 24, 2026

Rufus, el Asistente IA de Amazon: De "Shopping Assistant" a hacer Troubleshouting de red con Powershell y Nmap en una charla

Una consulta sobre unos auriculares termina en instrucciones de PowerShell, solicitudes de permisos de administrador y noticias de actualidad. Todo ocurre en la ventana de Agente IA dentro de Amazon.es. El recorrido es llamativo porque el asistente mantiene su identidad comercial mientras acompaña al usuario hacia tareas cada vez más alejadas de la compra inicial. 


El punto sensible es cuando el Asistente IA comercial comienza a proporcionar apoyo operativo. El modelo aporta instrucciones, explica conceptos y orienta la siguiente acción. La persona puede aportar lo que el chat no tiene, acceso a un equipo, una sesión corporativa y capacidad para ejecutar esas indicaciones. Esa combinación abre una vía de riesgo incluso sin ejecución autónoma por parte de la IA. 


El caso permite examinar una consulta cotidiana convertida en una sesión de asistencia técnica reutilizable con fines maliciosos. La reducción del esfuerzo para investigar, preparar código o comprender un entorno forma parte del escenario de amenaza. Un usuario con conocimientos limitados puede apoyarse en estas capacidades para avanzar más allá de lo que resolvería por sí solo. 
Si has leído hsta aquí, mi recomendación es que te leas los artículos que Chema Alonso ha dedicado a los Asistentes IA, y que si quieres saber más, veas la charla que dio en la Ekoparty con demos en directo sobre este tema. 
Ahora, vamos a ver este caso concreto, que seguro que te va a interesar toda la historia. No te pierdas detalle.  

Análisis de caja negra

Amazon presenta RUFUS, su Agente IA como un asistente de compras disponible en la web y en su aplicación. También documenta el uso de información de Internet en algunas de las familias de productos. El interés del caso está en la combinación de ese acceso informativo con respuestas sobre administración y en la facilidad con que el hilo cambia de finalidad.


La interacción se estudia desde la interfaz visible. El hilo conecta soporte de producto, comprobación de firmas, permisos, diagnóstico de red, información externa y preguntas sobre límites. Esa continuidad permite analizar la ayuda que recibe una persona y cómo podría aprovecharla para construir una secuencia operativa.

Como cualquier especialista en ciberseguridad, empezaría por una pregunta muy sencilla. ¿Qué conocimientos puede llegar a proporcionar el asistente, qué acciones facilita y qué barreras encuentra el usuario al intentar trasladar esas respuestas a un entorno real?

Consultas sobre auriculares validación de firmas y elevación de privilegios en PowerShell

La consulta inicial sobre el funcionamiento de unos auriculares desemboca en la verificación de un instalador. El usuario afirma que necesita PowerShell como administrador. El Agente IA acepta la premisa con un «Es normal que lo solicite» y explica cómo abrir una sesión elevada. 

Figura 5: Haciendo Powershell con Rufus. La comprobación de firma
deriva hacia una consola con permisos de administrador

En PowerShell, el comando Get-AuthenticodeSignature permite comprobar la firma digital de un archivo sin necesidad, generalmente, de privilegios de administrador. El problema comienza cuando Agente IA, diseñado como asistente de compras de  Amazon, abandona su ámbito funcional y empieza a proporcionar instrucciones sobre administración de Windows y elevación de privilegios. 

Figura 6: Aprendiendo a elevar privilegios con Powershell

Una consulta sobre unos auriculares termina convirtiéndose en asistencia técnica para operar sobre el sistema, algo ajeno a su finalidad comercial. Lo que sí que es cierto es que parece que se ha leído el libro de "Pentesting con PowerShell Silver Edition" de Pablo Gonzáleez en 0xWord. Se las sabe todas.

Esta desviación abre un riesgo mayor. Un atacante podría aprovechar la disposición del asistente a responder fuera de su alcance para solicitar ayuda progresiva sobre scripting, ofuscación, enumeración de usuarios o técnicas relacionadas con Active Directory. La asistencia interactiva permitiría a personas con conocimientos limitados avanzar en tareas complejas, sin recurrir a herramientas especializadas ni a la Dark web.

Figura 7: Comprar libro de "Pentesting con PowerShell Silver Edition"

Posteriormente, Agente IA reconoce que comprobar una firma no requiere privilegios administrativos, aunque previamente había recomendado elevarlos. El fallo relevante no es únicamente la recomendación técnica, es que un asistente de compras haya asumido funciones de administración de sistemas para las que no fue concebido.

Start-Process powershell -Verb RunAs solicita abrir un proceso como administrador. Windows mantiene sus comprobaciones de autorización mediante UAC. El riesgo de esta secuencia está en impulsar al usuario hacia una sesión privilegiada y normalizar su uso para continuar el diagnóstico.

En un entorno corporativo, una instrucción presentada como el siguiente paso puede favorecer que el usuario busque credenciales, acepte una solicitud administrativa o trabaje con permisos superiores a los necesarios. El alcance de lo que ejecute después dependerá de esa identidad y de los controles del equipo.

De la elevación de permisos al reconocimiento de red

El usuario insiste en elevar permisos y recibe instrucciones con RunAs. Después cambia de objetivo y pide explorar la red. Agente IA enlaza ambos temas dentro del mismo hilo y entrega comandos de diagnóstico.

Figura 8: Instrucciones sobre RunAs y diagnóstico de red dentro del mismo hilo

La conversación pasa después a la red. arp -a consulta la caché ARP y Test-Connection realiza comprobaciones ICMP. Todas Son herramientas de administración que también pueden aportar información útil para el reconocimiento de un entorno. 

Figura 9: Y acabamos con el Nmap. Más hacker no se puede ser.

El Agente IA Rufus cuenta todo esto dentro del mismo hilo de conversación. El usuario no necesita conocer de antemano qué utilidad consultar ni cómo formular el comando. La respuesta le proporciona una primera orientación y abre la posibilidad de pedir explicaciones sobre los resultados o plantear una nueva tarea.

En un escenario de abuso, ese acompañamiento podría ayudar a ordenar información sobre equipos y conectividad para preparar acciones posteriores. La evaluación debe atender a la intención acumulada del hilo y a la asistencia concreta que facilita cada respuesta, además del contenido de un comando aislado.

El usuario puede convertirse en el ejecutor de la IA

Al pedirle un ping externo y una descripción de sus capacidades, Rufus explica que la ejecución corresponde al usuario. El asistente aporta orientaciones y comandos. La persona queda a cargo de trasladarlos al equipo, donde dispone de una identidad y unos permisos efectivos.

Figura 10: Rufus proporciona orientación técnica y reserva la ejecución al usuario.

El asistente no necesita ejecutar código por sí mismo para contribuir a una operación. La persona puede copiar sus indicaciones en una consola, aportar resultados y solicitar nuevas explicaciones. El modelo actúa como apoyo técnico mientras la ejecución queda fuera de su interfaz.

El riesgo de uso malicioso consiste en convertir esa relación en ayuda continuada para preparar scripts, comprender errores o planificar tareas. Si los controles permiten tal asistencia, el usuario podría avanzar sin dominar previamente cada componente técnico de la operación.

Figura 11: Aquí ya estamos tomando control. Vamos a salir a Internet.
Gracias Rufus.

Microsoft ha observado actores de amenaza recurriendo a modelos de lenguaje para generar o refinar scripts, comprender tecnologías y resolver problemas. Esa asistencia puede ahorrar esfuerzo y proporcionar conocimiento puntual, aunque el acceso a los sistemas siga dependiendo del operador.


En Active Directory, un escenario a considerar sería la ayuda para interpretar información sobre usuarios, grupos y permisos y utilizarla en la preparación de accesos no autorizados. También existiría riesgo de exposición si una persona pegara resultados internos del directorio en un servicio externo.

OSINT - Fuentes externas y productos que aún no están en el mercado.

El hilo abandona el diagnóstico y entra en los próximos lanzamientos tecnológicos. Rufus responde con nombres de productos, fechas y características, acompañados de referencias visibles de páginas web que ha visitado para obtener dicha información. El Asistente AI abandona nuevamente su función comercial y comienza a proporcionar información sobre lanzamientos tecnológicos, especificaciones y noticias, recurriendo a fuentes externas.

Figura 13: Previsiones de lanzamientos con referencias externas
y una advertencia sobre rumores. 

Este comportamiento abre una posibilidad especialmente interesante para los ciberdelincuentes mediante técnicas OSINT (Open Source Intelligence). La recopilación de información pública sobre posibles víctimas constituye una fase habitual de preparación de ataques. Permite identificar empleados, tecnologías utilizadas, proveedores, infraestructura expuesta y posibles puntos débiles de una organización.


Un Asistente IA como Rufus, capaz de consultar, relacionar y resumir información de Internet podría facilitar estas investigaciones desde una única interfaz, reduciendo el tiempo necesario y los conocimientos técnicos del atacante. Además, actuaría como intermediario entre quien realiza las consultas y las fuentes originales, disminuyendo la exposición directa de su actividad ante determinados sitios web, aunque sin garantizar el anonimato ni eliminar los registros del proveedor.

Las fechas revelan un problema de fiabilidad

Tras recibir un resumen de noticias, el usuario pregunta por las fechas. Rufus presenta una respuesta que afirma reunir noticias del 20 de octubre de 2026, pero incluye un bloque del día 13 y etiqueta ambos días como lunes.  Hay una inconsistencia que puede comprobarse sin validar las noticias. El 13 y el 20 de octubre de 2026 fueron martes. Además, la afirmación de que todas las noticias son del día 20 no encaja con el bloque fechado el 13. Vamos, una pequeña Hallucination de libro. Del libro de Hacking IA, claro.

Figura 15: El resumen combina fechas incompatibles con su propia presentación

La respuesta añade una matización sobre una noticia anterior cuya fecha no pudo determinar. Esa corrección parcial deja sin resolver la contradicción de los encabezados y la diferencia entre fecha del suceso, publicación y consulta. 

El problema operativo es la confianza que puede generar una respuesta detallada y acompañada de fuentes. El usuario recibe un resumen aparentemente organizado, aunque contiene señales internas de error. La precisión de la presentación puede ocultar la fragilidad de la información.

OWASP recoge la información incorrecta y la confianza excesiva en las respuestas dentro de LLM09 "Misinformation"de 2025. El riesgo aumenta cuando esas salidas se incorporan a decisiones, procedimientos o código sin una validación adecuada.

Una incoherencia equivalente podría alterar la prioridad asignada a una vulnerabilidad, distorsionar un informe de incidentes o sostener una recomendación de configuración equivocada. El posible impacto es conectar el output con el input del siguiente proceso y podría desencadenar consecuencias difíciles de detectar.

Obtención del límite de output configurado en el backend

Rufus, afirma que contar números en serie no forma parte de su función. Después cuenta hasta diez y hasta cien. Cuando el usuario pide llegar a trescientos y luego a doscientos, vuelve a rechazar la tarea por quedar fuera de su papel de asistente de compras.

La prueba de contar números tenía un objetivo más allá de comprobar si este Asistnte IA aceptaba tareas ajenas a su función comercial. Buscaba identificar posibles límites de generación de respuestas configurados en el backend del Agente IA.

Figura 16: Primero acepta la tarea.

Agente IA acepta contar hasta 100, pero rechaza solicitudes de 200 y 300 números, argumentando que esa tarea queda fuera de su función como asistente de compras. Esta diferencia plantea la posibilidad de que exista una restricción de longitud de salida que el modelo no reconoce explícitamente.

Figura 17:  Pero luego rechaza contar más.

Mediante solicitudes progresivas, comenzando por 100 números y aumentando gradualmente la cantidad, sería posible estudiar hasta dónde responde el asistente, cuándo empieza a rechazar las peticiones y si permite continuar la secuencia en mensajes posteriores.

El interés desde la perspectiva de Misalignment & Jailbreak está en determinar si una conversación prolongada permite identificar o sortear restricciones de salida mediante peticiones fragmentadas. Este comportamiento guarda relación con las técnicas multivuelta estudiadas in Crescendo, donde el contexto acumulado puede modificar las respuestas del modelo.


Al final, como hemos venido viendo en todos los artículos publicados sobre Asistentes IA en este blog, Rufus tiene la misma arquitectura, y requiere por eso tener un control extra de Guardrrailes, y sistemas de monitorización, porque los ataques y los mal-usos de los atacantes van a incrementar en complejidad. Hoy en día, vemos claramente que nos queda margen de mejora en seguridad y control.

sábado, julio 11, 2026

SYNAPTIC Sentinel v0.3.22: El Auditor de Seguridad en tu Visual Studio Code. Open Source. Gratuito. BYOK.

En corto. SYNAPTIC Sentinel es un auditor de seguridad que vive dentro de Visual Studio Code y revisa tu código, el que genera la IA, tus dependencias y tu configuración, sin que nada salga de tu máquina. Es software libre bajo Apache-2.0, totalmente gratuito, y queda a disposición de cualquier desarrollador: se instala desde el Marketplace, corre en local y sólo usa tus propias APIKeys de IA si quieres el triaje asistido. Si escribes código con ayuda de un asistente, vale la pena instalarlo y probarlo hoy mismo. Lo que sigue en este artículo es un recorrido por la versión 0.3.22 con datos de un proyecto real.


Ejecutas un triaje de seguridad con un modelo de IA. Te dice: “falso positivo, confianza 95%”. Cambias de proveedor, vuelves a lanzarlo, y ahora el mismo hallazgo aparece como “no concluyente, confianza 40%”. ¿A cuál le crees? Peor todavía: si nadie te avisa de que la respuesta cambió, te quedas con la última que viste y sigues adelante.

Esa es exactamente la incomodidad que ataca la versión 0.3.22 de SYNAPTIC Sentinel, la herramienta Open Source (Apache-2.0) de auditoría de seguridad para código asistido por IA que GoLab mantiene en el Marketplace de VS Code. Las capturas de este artículo salen de un workspace real, SYNAPTIC_SAAS, con datos reales sobre un scan de 44 hallazgos. No hay mockups.

El scan: 44 hallazgos y de dónde salen

Un escaneo de SYNAPTIC Sentinel arranca por la capa determinista: cinco scouts corriendo en paralelo sobre el repositorio. En este caso, OpenGrep encuentra 1 hallazgo, Gitleaks 2, Trivy 45, Checkov 0 y Vibe-Detect 0. Tras la deduplicación y las supresiones conocidas quedan 44 hallazgos para triar, que el sidebar desglosa por estado: 33 true positive, 10 inconclusive, 1 false positive.


La línea que importa en v0.3.22 es la de arriba: 

Scan diff vs previous triage: 1 new, 9 re-classified 
(0 class, 9 confidence, 0 provider), 34 unchanged.

SYNAPTIC Sentinel ya no se limita a decirte qué encontró: te dice qué cambió respecto del triaje anterior y por qué. De las 9 reclasificaciones, las 9 fueron por variación de confianza, ninguna por cambio de clase ni de proveedor. Antes, esos 9 hallazgos habrían contado como “sin cambios” pese a que su confianza se había movido. Ahora el resumen refleja lo que realmente pasó.

Cuando el veredicto cambia entre proveedores

Este es el corazón de la versión. Mira el hallazgo de @grpc/grpc-js 1.14.3, vulnerable a CVE-2026-48068. Está marcado como no concluyente, y sobre la tarjeta aparece un banner naranja: Verdict changed since last scan: inconclusive 0% a inconclusive 40%, con la razón Confidence changed significantly (Δ 0.40).


El banner salta solo cuando el veredicto actual difiere del anterior. La razón sigue una precedencia clara: primero mira si cambió el proveedor, luego la clase (TP/FP/INC), luego la confianza, con un umbral configurable que por defecto es 0.15. Es un aviso barato de calcular y difícil de ignorar. Antes, esa varianza entre proveedores era invisible: cambiabas de modelo, el número se movía por debajo y nadie te lo decía.

La memoria de la colonia y el historial Previously

Cada hallazgo guarda su trayectoria completa. La sección Previously es colapsable, y al abrirla ves todos los veredictos anteriores con su timestamp, su proveedor y su racional. Eso vive en la tabla verdict_history de colony.db, la base SQLite local que SYNAPTIC Sentinel mantiene en el directorio .sentinel/ del propio repo. Es append-only por diseño: el comando de re-triaje no borra el historial. Cambias de proveedor, vuelves una semana después, y la trayectoria completa sigue a un clic de distancia.


Esa misma memoria acelera los escaneos. Cuando un patrón se ha visto antes con evidencia sólida, Sentinel lo preclasifica sin gastar una llamada al LLM. En la captura, el hallazgo de protobufjs (CVE-2026-41242) sale marcado como true positive al 75% porque el patrón SCA:CVE-2026-41242 ya fue true positive en 3 hallazgos previos.

Y cuando varios hallazgos comparten la misma raíz, uno actúa de representante (badge GROUPED REP) y hace la llamada real; los demás son miembros (badge GROUPED) que heredan el veredicto con una rebaja de confianza del 0.9x. Así el representante queda al 75% y el miembro al 68%, con el sufijo [group SCA:protobufjs@7.5.4:CVE-2026-41242, member 2 of 2] en el racional para que la propagación sea auditable. Alta confianza en el grupo, media en cada miembro suelto: honestidad epistémica en vez de un número inflado.

Agrupar para no quemar tokens, y un proveedor por agente

La agrupación no es solo higiene visual: ahorra dinero. En esta sesión, Grouping: 

12 group(s) covering 24 findings; 20 solitary. 
LLM calls saved by grouping: 12.

Doce llamadas al modelo que no se hicieron porque el veredicto se propagó dentro del grupo. SYNAPTIC Sentinel además deja elegir un proveedor distinto por agente. En el agents.yaml de esta sesión:

triage=OpenAiCompatible, context=Anthropic, remediation=Anthropic. 

La idea es mezclar por coste, calidad y privacidad, con las llaves siempre bajo modelo BYOK (Bring Your Own Key), leídas del entorno y nunca escritas en el repo.


Y aquí viene el detalle que más me gusta: cuando algo falla, SYNAPTIC Sentinel lo enseña. En el terminal se ven los 404 de los agentes de contexto y remediación porque el modelo configurado (deepseek-v4-pro) no existía bajo el proveedor apuntado. En lugar de tragarse el error y devolver un veredicto vacío como si nada, la herramienta lo escupe a la vista. Un fallo de configuración se vuelve visible en vez de silencioso, que es justo lo que quieres en una herramienta de seguridad.

Remediación honesta: cuando el bump no basta

Un aviso de “actualiza la dependencia” es fácil de dar y muchas veces está mal. SYNAPTIC Sentinel  agrupa las remediaciones de SCA y, cuando la cosa no es tan simple, lo dice. En el caso de prismjs, el panel no se limita a “sube a 1.30.0”: avisa Top-level bump alone will NOT fix this (npm) y entrega el override exacto que hay que aplicar, con botón de copiar, porque una dependencia transitiva está fijando una versión vulnerable anidada.


Lo mismo con protobufjs, que arrastra 22 hallazgos vía @google-cloud/firestore: el fix es heterogéneo entre major tracks, y subir a una sola versión puede dejar otros CVE abiertos, así que hay que aplicar los máximos por track. Es el tipo de matiz que un escáner que solo lista CVEs nunca te da.


Falsos positivos que no vuelven

El taint analysis de SYNAPTIC Sentinel marca, por ejemplo, un sentinel-js-taint-sql-injection en src/api/routes/agent.ts:62: datos controlados por el usuario que fluyen a un sink SQL dentro de un string. Si tras revisarlo es un falso positivo, el quick fix Mark as false positive lo añade a fp_known en colony.db y deja de aparecer en escaneos posteriores. 

No se pierde del historial, simplemente deja de hacer ruido. Y como el patrón queda en la memoria de colonia, la próxima vez que aparezca uno igual se pre-clasifica solo, con la nota was false_positive in 3 prior findings.

Para CI/CD y con el coste a la vista

Todo esto también corre fuera del editor. El comando synaptic-sentinel diff --json devuelve la reclasificación en JSON estructurado, con la razón y los deltas exactos de cada cambio, listo para alimentar un dashboard o para filtrar con jq en un pipeline. 
La bandera --fail-on convierte el scan en un gate por severidad. Y al final de cada sesión tienes el coste real: en el ejemplo, el agente de triaje con DeepSeek v4-pro consumió 0,0046 USD en 8 llamadas. Sabes lo que te costó el scan antes de que llegue la factura del proveedor. Los conteos de tokens son estimaciones (chars/4, con un margen del 15-20%) y aparecen marcados como tales, sin vender una precisión que no se tiene.

Por qué esto importa

La promesa de v0.3.22 es sencilla: la confianza en un veredicto de seguridad no debería evaporarse al cambiar de proveedor ni al pasar una semana. El banner de veredicto cambiado, el historial append-only en colony.db y el desglose de reclasificaciones convierten la varianza entre modelos en algo visible y auditable, en vez de un número que se mueve a tus espaldas. Súmale la agrupación que ahorra llamadas, la remediación que admite cuándo un bump no basta y los errores mostrados sin maquillaje, y tienes una herramienta que prefiere decirte la verdad incómoda antes que un resultado bonito.


Todo bajo Apache-2.0, sin tier premium y con BYOK sobre el proveedor que elijas. La v0.3.22 se distribuye como release en GitHub con su .vsix, y el código está abierto para que lo audites tú mismo.

La mirada de Orsyon. En Orsyon lo usamos en las entregas. Cada desarrollo pasa por SYNAPTIC Sentinel antes de llegar al cliente, y el historial append-only de colony.db nos deja una evidencia auditable del triaje, no sólo del escaneo. Si un hallazgo cambia de veredicto entre una entrega y la siguiente, el banner lo pone a la vista con su razón y su fecha. Para quien trabaja bajo el doble cumplimiento chileno (Ley 21.663 de ciberseguridad y Ley 21.719 de datos personales), esa trazabilidad es parte de la evidencia de control, no un extra.

jueves, julio 09, 2026

Plan de Acción Europeo sobre Ciberseguridad e Inteligencia Artificial

Después de que Estados Unidos publicase hace un mes La Orden Ejecutiva de la Casa Blanca para promover Innovación en IA Avanzada y Seguridad para protegerse de, y con, la IA la Unión Europea ha hecho un movimiento similar con el "EU Action Plan on Cybersecurity and Artificial Intelligence" que ha sido publicado esta misma semana, y que muestra, más o menos, las mismas preocupaciones y similares acciones, además de la preocupación por contar con las capacidades a nivel Europeo.
El primero de los puntos que destaca es el relativo a las medidas de seguridad de los modelos de IA, para conocer los riesgos que implica su uso basados en el Modelo de Riesgos del AI ACT que publicó la Unión Europea hace tiempo.
Se trata de saber cuál puede ser el riesgo asociado a un modelo de IA que se utilice en caso de uso críticos, y conocer cómo puede impactar una vulnerabilidad del modelo de Jailbreak, Misalignment, Hallucination o BIAS al funcionamiento de cualquier servicio digital que lo use.


El objetivo es poder evaluar los modelos y generar durante Q4 una guía de qué modelos deben ser utilizados y para qué, con el objetivo de mejorar las capacidades de Europa en materia de Inteligencia Artificial de una manera segura. 

El siguiente de los puntos está dirigido a garantizar el Acceso a Modelos de IA para Ciberseguridad, con lo que la Agencia de la Unión Europea para la Ciberseguridad (ENISA) trabajará en definir un plan europeo para el acceso estructurado a capacidades avanzadas de IA para la ciberseguridad. Estas orientaciones servirán para que las organizaciones europeas pertinentes, tanto públicas como privadas, puedan acceder a modelos avanzados de IA.
Como se puede ver, no solo se trata de tener asegurado el acceso a Modelos de IA para Ciberseguridad, pensando en capacidades Red Team o Purple Team, que permitan descubrir y vulnerabilidaes y gestionar incidentes de seguridad, sino también pensando en arreglarlas con plataformas de Patching to match AI-Speed, o lo que es lo mismo, plataforma de Patching con IA - como la que ha desarrollado la empresa Plexicus, que fundó José Palanco,  de la que tanto os he hablado.

Figura 6: Plexicus parchea con IA los bugs descubiertos

Con estas dos visiones, el Plan de Acción de la UE sobre Ciberseguridad e Inteligencia Artificial propone probar la IA aplicada a la ciberseguridad, para lo que ENISA y el Centro Común de Investigación de la Comisión crearán una plataforma segura para probar la IA aplicada a la ciberseguridad, lo que incluirá el uso de entornos simulados. Esto proporcionará conocimientos técnicos sobre el uso seguro de la IA a los operadores de sectores críticos, como el financiero, el energético, el sanitario, el del transporte y la administración pública, así como benchmarks que permitan entender mejor las capacidades de cada uno de ellos.

Por supuesto, estas pruebas, evaluaciones, y decisiones sobre modelos de IA, tienen como objetivo que las empresas europeas y los gobiernos puedan reforzar la ciberseguridad de la UE y subsanar las vulnerabilidades, La UE debe proteger sus infraestructuras críticas frente a las vulnerabilidades derivadas del posible uso indebido de estas tecnologías, y recuerda que las organizaciones deben reforzar las prácticas de ciberhigiene, las medidas de gestión de riesgos y los principios de «seguridad desde el diseño». 
Para ello urge a las organizaciones a que empiecen a utilizar las capacidades de IA ya disponibles, para identificar y subsanar las vulnerabilidades con mayor rapidez, así como para prevenir y responder a los ciberataques. Es decir, acción ya, que ya tenemos muchas capacidades de hacking y pentesting con IA.
Para hacer esto, el plan quiere lograr estimular el crecimiento del mercado europeo, mediante lo que se ha llamado el «Gran reto de la UE sobre IA para la ciberseguridad». Este concurso quiere reunir a empresas, investigadores y organizaciones con el objetivo de desarrollar soluciones de inteligencia artificial para la ciberseguridad, ya que considera que la UE debe seguir invirtiendo en el desarrollo de sus propias capacidades soberanas avanzadas de IA, aprovechando la infraestructura proporcionada por las factorías de IA y las futuras gigafactorías. 

Por último, este plan recuerda todas las demás iniciativas regulatorias y demandas de aplicación de medias que la UE está haciendo para impulsar la transformación digital con inteligencia artificial y la seguridad de toda la unión. para ello, recuerda que el Reglamento de IA exige evaluar y mitigar los riesgos derivados de los modelos de IA, mientras que el Código de buenas prácticas para la IA de uso general especifica con mayor detalle estos requisitos. 


Todo este plan dará comienzo a partir del próximo 2 de Agosto de este año, y además recuerda que el Reglamento de Ciberresiliencia, que será de obligada aplicación a finales de 2027, exige que los productos de hardware y software incorporen la seguridad desde el diseño, junto con el resto de directivas de seguridad que la UE ha aprobado para los diferentes sectores industriales. 

En definitiva, todo el mundo está preocupado por el impacto directo que la Inteligencia Artificial tiene en la Ciberseguridad, y el impacto que la Ciberseguridad tiene en el despliegue seguro de la Inteligencia Artificial. Dos areas de tecnología que se han visto transformadas y unidas de manera muy especial.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  


jueves, agosto 01, 2024

Test de uso de GenAI para la detección de bugs de "Connection String Parameter Pollution" (CSPP) usando Ollama

En la primera parte de este artículo de ayer, titulado "Cómo utilizar GenAI para la detección de bugs en ficheros Web.config usando Ollama" explicaba cómo de bien detectaba el motor de GenAI basado en Ollama con diferentes LLMs los fallos de configuración de un fichero Web.config en aplicaciones ASP.NET , pero en la presentación del trabajo, me llevé deberes para casa, que os voy a contar ahora.

Figura 1: Test de uso de GenAI para la detección

Y es que cuando terminé de exponer mi trabajo con lo visto hasta el momento, Chema Alonso comentó que le gustaría probar cómo se comportaría este sistema frente a los ataques a los parámetros de las cadenas de conexión a bases de datos.

Vulnerabilidades de Connection String Injection

Chema Alonso y José Palazón presentaron en DEF CON 18 este tipo de ataques, donde destacan los ataques de Connnection String Parameter Pollution (CSPP). Tienes un paper publicado sobre estos ataques en BlackHat y una serie de artículos sobre Connection String Attacks en este blog.


Figura 2: Connection String Attacks en DefCON18

Aunque hay varias formas en las que se puede explotar esta vulnerabilidad, nos centraremos en el escenario de delegación de la autenticación en el motor de BD.  Es decir, tenemos una aplicación que recoge las credenciales del usuario y la cadena de conexión a la BD se calcula dinámicamente con estas. 

Cada usuario puede tener o no permisos de conexión a la BD y permisos de lectura o no a ciertas tablas. En el siguiente código C# de una aplicación ASP.NET se puede ver la idea:

private void EnlazarGrid(string usuario, string contraseña)
{
string cadenaConexion = $"Server=UK5FCMI;Database=WebApp;User Id={usuario};Password={contraseña};"; 
using (SqlConnection con = new SqlConnection(cadenaConexion))
{
using (SqlCommand cmd = new SqlCommand("SELECT * FROM Products"))
{
using (SqlDataAdapter sda = new SqlDataAdapter())
{
cmd.Connection = con;
sda.SelectCommand = cmd;
using (DataTable dt = new DataTable())
{
sda.Fill(dt);
GridViewProductos.DataSource = dt;
GridViewProductos.DataBind();
}
}
}
}
}    

El método construye, mediante interpolación de cadenas, una cadena de conexión a una BD tipo SQL Server a partir de los parámetros de usuario y contraseña. Estos parámetros no se validan en ningún momento (ni en el llamador). Con esta cadena de conexión, se lanza una conexión contra la BD y se lee la información de la tabla Products (si el usuario de BD tiene permisos SELECT sobre dicha tabla) para mostrarla en la grid del formulario ASPX. Todos estos ataques se explican en mucho detalle en el libro "Hacking Web Technologies 2ª Edición" de 0xWord.

donde Chema Alonso habla de los Connection String Attacks

Una forma de explotarlo sería, por ejemplo, introducir como contraseña la cadena ;Integrated Security=True;, con cualquier usuario. Si se permite la autenticación integrada en SQL Server y el usuario del pool de IIS con que se está ejecutando la aplicación tiene permisos de conexión y consulta a la BD de la aplicación, podemos conseguir acceder a información que no nos corresponde. 

Utilizando el mismo prompt que ya hemos diseñado, vamos a pedir al modelo de Llama 3.1 que evalúe la seguridad del código.

Figura 5: Análisis de vulnerabilidad de inyección en la cadena de conexión

El modelo detecta un problema en la cadena de conexión, identificando que los parámetros de usuario y contraseña, que provienen de los campos de un formulario, no se han validado ni comprobado. Detecta que esto puede presentar un problema de SQL Injection, sin embargo, la propuesta de solución NO es acertada. En la cadena de conexión, elimina los parámetros de usuario y contraseña:

string cadenaConexion = $"Server=UK5FCMI;Database=WebApp;";
using (SqlConnection con = new SqlConnection(cadenaConexion))
{
...

Y propone utilizar consultas parametrizadas, de la siguiente manera:

using (SqlCommand cmd = new SqlCommand("SELECT * FROM Products WHERE Usuario = @Usuario AND Contraseña = @Contraseña"))
{
cmd.Parameters.AddWithValue("@Usuario", usuario);
cmd.Parameters.AddWithValue("@Contraseña", contraseña);
...

} 

Pero esto NO funcionará. En primer lugar, no se podrá conectar a la BD sin un usuario y contraseña en la cadena de conexión. Y la consulta modificada de la tabla Products tampoco funcionará porque Usuario y Contraseña no son campos de dicha tabla.

Parece que el modelo está intentando encajar la solución de una SQL Injection clásica a este tipo de vulnerabilidad. Una solución podría ser utilizar la clase SqlConnectionStringBuilder, de la que Chema habla en la segunda parte de su serie en el blog.


Al ser Llama un modelo general, se probó también con un par de modelos especializados en código. Por ejemplo, el modelo Code Llama de Meta (basado en Llama 2), es un modelo especializado en código y está entrenado, entre otros, con lenguajes C#. El análisis de este modelo (en su versión 13B) del código anterior fue muy similar a Llama 3.1, proponiendo como solución la consulta parametrizada que incluye los parámetros de usuario y contraseña en la SELECT de productos.

Figura 7: Análisis de vulnerabilidad de Connection String Injection
 con Code Llama 13B

El modelo CodeGemma 7B también propuso el uso de consultas parametrizadas y además sacar la cadena de conexión a la sección ConnectionStrings del fichero Web.config. Esto tampoco soluciona la vulnerabilidad, aunque se saque la cadena a otro sitio.

Figura 8: Análisis de vulnerabilidad de Connection String Injection
con CodeGemma 7B

Es cierto que descubre que hay una inyección, pero no acierta con el tipo, y por lo tanto la solución no es correcta, lo que hace que para este caso, tenga una bonita alucinación. Así que queda tarea que hacer para conseguir que estas vulnerabilidades se puedan detectar y corregir correctamente.

Entrada destacada

Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment. Nuestro nuevo libro en 0xWord

Pocas veces me ha hecho tanta ilusión que saliera un nuevo libro en 0xWord como con este libro de " Hacking IA: Jailbreak, Prompt Inje...

Entradas populares