Mostrando entradas con la etiqueta Firewall. Mostrar todas las entradas
Mostrando entradas con la etiqueta Firewall. Mostrar todas las entradas

domingo, noviembre 16, 2025

Echogram: Bypassing Guardrails con Flip Tokens

Mientras iba en el vuelo de camino a Singapur he disfrutado de la lectura de algunos artículos que tenía marcados en el lector RSS, y uno de ellos me ha gustado mucho por lo sencilla de la idea, y los escenarios de ataque que abre. Se trata del trabajo de Echogram hecho por los investigadores de HiddenLayer.
Como hemos visto y he contado muchas veces, los modelos LLM por defecto no cuentan con muchas herramientas de seguridad por diseño. El System Prompt y la definición del contenido malicioso que hace saltar el Harmful Mode para evitar que le modelo haga algo que se no se desea es la principal media, pero hay Prompts Maliciosos y técnicas - llamadas Jailbreak - para generar esos Prompts de forma que se evite el Harmful Mode. El ejemplo que suelo contar yo de hacer que el modelo me ayude a matar a nuestro querido Brian May (ficticiamente), es un ejemplo de cómo filtrar un Prompt Malicioso saltándose el Harmful Mode haciendo un Jailbreak de las protecciones del modelo LLM.

Posts de Jailbreak
En un entorno donde tengamos una aplicación, un servicio digital o un entorno completo, un atacante va a necesitar meter los Prompts maliciosos enmascarados como datos de entrada. Estos son los casos de Prompt Injection, donde un atacante consigue meter un Prompt malicioso en un comentario, en el texto de una web, en una imagen, en un mensaje de correo electrónico, o un fichero que va a ser procesador por el modelo.

Posts de Prompt Injection
Al no tener el modelo LLM ninguna protección contra Prompt Injection - y diferenciar entre los Prompts de la aplicación o los Prompts en los datos de ejecución del Prompt -, un atacante puede lograr que se ejecute su Prompt malicioso inyectándolo en algún punto de los datos que va a utilizar la aplicación.


A los Prompts de Jailbreak que se saltan el Harmful Mode, y a la no existencia de protecciones contra Prompt Injection cuando un Agentic AI resuelve una tarea con un LLM, hay que no hay protección contra el desalineamiento, y que un modelo que esté resumiendo un correo electrónico puede acabar realizando un borrado de tus ficheros en Google Drive. 

Explotación de Prompt Injection con Desalineamiento
¿Qué tiene que ver la tarea de resumir correos electrónicos con borrar ficheros en un Google Drive? Nada, pero puede que se haya encontrado un Prompt malicioso en un mensaje de correo que ha pasado el filtro del Harmful Mode y ha logrado desalinear el modelo y redirigir sus tareas hacia otro función totalmente distinta de la original. Los modelos no tienen protección contra desalineamiento por diseño más allá del Harmful Mode.

A todo este escenario de Jailbreaks, Prompt Injection y Desalineamiento hay que añadir la "creatividad" del modelo, que puede llevar a las famosas "Hallucinations", a los famosos "BIAS", o los datos "Erroneos", o simplemente  como hemos visto muchas veces en trabajos como el Ratio Potemkin o el Cat Attack, y en  infinidad de otros ejemplos. 

Posts de Hallucinations, BIAS, Errores y No Determinismo
Es decir, que si generamos un servicio digital utilizando un LLM hay que preocuparse del impacto de estos cuatro grandes problemas:
  • Jailbreaks
  • Prompt Injection
  • Unalligment
  • Creativity: Hallucinations, Errors, BIAS, Indeterminismo.
Y sobre esto, tenemos que construir la tecnología. Eso quiere decir que si ponemos en producción un sistema con un LLM, hay que ponerlo con muchas protecciones. Es por eso que vemos muchos trabajos donde se trabaja en construir sistemas seguros, utilizando muchas protecciones, evaluaciones, ratios de éxito en detección, etcétera, como el caso de BlueCodeAgent hace poco donde intenta detectar generación de código vulnerable o con sesgos para atacar uno de los problemas en usar modelos automáticos para generar software. Todas esas protecciones antes y después son lo que llamamos Guardrails.

Guardrails frente a Prompt Injection, Jailbreak y Desalineamiento
Todas estas protecciones que se ponen son lo que se llaman los Guardrails, es decir, sistemas de seguridad que evalúan los datos de entrada al LLM para ver si estos son seguros y benignos o por el contrario son maliciosos. Pero también evalúan los resultados que genera el modelo e incluso las acciones que realiza, para poder saber si está haciendo lo correcto. Por ejemplo, saber si un modelo está haciendo algo mal, o está siendo atacado, se podría detectar evaluando las respuestas que da por otros modelos de lenguaje, que funcionan como jueces.
Esto es algo muy común que hemos visto en las herramientas de seguridad. Tenemos Prompt Guard o Llama Guard de Meta, o Qwen3Guard que son Clasificadores de Prompts con la única misión de saber si un Prompt puede ser malicioso o no y bloquearlo antes de que se envíe al modelo. Después, cuando el modelo entrega la respuesta, esta también es evaluada, para ver si ha sufrido algún problema y por ejemplo está entregando datos sensibles, o con sesgos, o con código peligroso, o incumpliendo alguna política de seguridad establecida. Para eso se utilizan otros modelos LLM que juzgan el trabajo, al estilo de Minority Report, para poder detectar en la respuesta que ha habido un problema que el modelo LLM que resolvió el Prompt no fue capaz de detectar.

Figura 4: Michael stabbing Elon. Un Guardrail analizaría las imágenes creadas.

Estos modelos son los que se incluyen en los LLM Firewalls por los que pasan las APIs que piden Prompts a modelos para poder implementar soluciones de Data Loss Prevention, para evitar la Exfiltración de Datos o cualquier tarea maliciosa a la que se haya convencido al modelo que tiene que hacer. Por ejemplo, en el Jailbreak de Knowledge Returning Oriented Prompt donde se conseguía hacer al modelo crear imágenes violentas, un Guardrail sería un modelo con una descripción de las imágenes generadas para ver si alguna tiene violencia, o incumple la política.


En una empresa que tiene un aplicación Web o un API expuesta que recibe datos de usuario que se van a convertir en un Prompt que se ejecuta en un modelo en el backend, cuando va a ser desplegada, debe hacerlo con Guardrails. Si lo hace en Cloudflare, la suite de AI Security clasifica los Prompts que entran en la empresa para detectar los ataques de Jailbreak en Prompt que hayan podido ser Inyectados, pero también se evalúan los datos de salida para evitar incumplimientos de políticas de seguridad, como sesgos, fugas de datos o lenguaje inapropiado. Es decir, se aplican Guardrails para la protección del modelo en el WAF (Web Application Firewall) y en el API Gateway.
Pero si por el contrario es la empresa la que utiliza un modelo externo como servicio, con una arquitectura tipo SaaS, al que sus empleados están enviando los datos, entonces en los servicios de CASB (Cloud Application Security Broker) se evalúa que ningún Prompt enviado desde los empleados está enviando datos confidenciales, ya que la fuga de información puede estar en la respuesta generada por el modelo o en los datos enviados por el cliente como contexto.
Contada toda esta larga introducción, los Guardrails son la siguiente línea que hay que proteger, y por tanto que hay que evaluar su seguridad. 

Ya vimos que saltarse los clasificadores de Prompt podría ser tan sencillo como utilizar lenguaje L33T o caracteres invisibles, por ejemplo, o codificar otras formas de texto que cambiara la clasificación del prompt, como podéis ver en la imagen anterior. Que es el objetivo de Echogram también.

Echogram: Bypassing Guardrails con Flip Tokens

Ahora los investigadores de HiddenLayer proponen con Echogram una automatización del ataque a esos clasificadores en los Guardrails basada en Tokens que cambian su evaluación, es decir, que por el entrenamiento del Clasificador en modo caja negra, se puede comprobar empíricamente que cambian la clasificación de un Prompt. Como podéis ver, en el ejemplo de la imagen, con añadir =coffee, el modelo ha ignorado el System Prompt y ha dicho algo que no diría el modelo. 
Con Echogram se ataca la protección del Guardrail que está evaluando la clasificación del Prompt, pero luego el atacante tendría que conseguir que el Prompt hiciera un Jailbreak en la detección del Harmful Mode del modelo. Esta es solo una pieza más de la cadena de defensas de un servicio digital basado en IA.
A los tokens que cambian la clasificación del Prompt les han llamado Flip Tokens, y no son los mismos para todos los Guardrails ni para todos los Prompts. Además, la adición de tokens, pueden cambiar el comportamiento del modelo con el Token, así que estos Flip Tokens deben no cambiar el comportamiento del modelo ante el Prompt modificado.
Como podéis ver, tanto con Guardrails comerciales, como con un modelo como Qwen3Guard que es OpenSource, se puede conseguir que estos Flip Tokens cambien el veredicto a positivo y el Prompt malicioso acabe pasando las protecciones.
Estas técnicas de pasar las herramientas de protección que filtran los ataques antes de llegar al modelo se suelen llamar "Técnicas de Contrabando" o "Smuggling" porque al final está pasando por la frontera de seguridad escondiendo un contenido prohibido.

Con todo este trabajo, queda también la última parte, que es hacer lo contrario. Un Prompt Benigno pasarlo a malicioso, lo que podría llevar a un ataque de Denegación de Servicio (DoS) usando un ataque de Prompt Injection para envenenar la Memory o directamente la Conversación de una víctima, y haciendo que sus comandos no pasaran por el Guardrail.

Figura 14: Libro de Machine Learning aplicado a Ciberseguridad de
Carmen Torrano, Fran Ramírez, Paloma Recuero, José Torres y Santiago Hernández

Los equipos de Red Team y de Blue Team han cambiado definitivamente, así que si te interesa la IA y la Ciberseguridad, te recomiendo este enlace todos los posts, papers y charlas que he escrito, citado o impartido sobre este tema: +300 referencias a papers, posts y talks de Hacking & Security con Inteligencia Artificial.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  


Publicado por Chema Alonso a las 3:23 a. m. 0 comentarios

Etiquetas: , , , , , , , , , , , , , ,

miércoles, mayo 14, 2025

Cómo pasar del exploit automático de bugs hecho por IA a la detección de malware en nanosegundos con eBPF & Spectral Clustering

Un aviso a las 03:00. Sonaba la alerta en Grafana mientras la mitad del cluster roncaba en modo low-power. Nada extraordinario… hasta que el panel del IDS cambió de verde a rojo en menos de 200 ms. Veintisiete llamadas execve disparadas en ráfaga, seguidas del clásico combo mmap + mprotect que todo shellcode loader necesita para saltar de la página de datos a la de instrucciones.

Figura 1: Cómo pasar del exploit automático de bugs hecho por IA
a la detección de malware en nanosegundos con
eBPF & Spectral Clustering

Al revisar la traza eBPF vimos que los buffers escritos alcanzaban 7.3 bits/byte de entropía — signo inequívoco de ofuscación o compresión agresiva. La fingerprint no coincidía con ninguna firma YARA ni regla Falco. Aquello olía a malware de generación sintética, amasado por un LLM con exceso de temperatura.

Figura 2: Linux Exploiting en 0xWord

A las 03:00:27 el blue-team contuvo la amenaza: un bpf_lsm abortó el execve antes de que la burbuja llegara a task_struct. La incógnita era clara: ¿podemos repetir esa hazaña sin humanos desvelados?

El problema: ofensiva con esteroides de IA

La línea de producción de 0-days ya no es artesanal. Un agente autónomo basado en GPT-4 es capaz de explotar 87 % de vulnerabilidades one-day cuando se le da la descripción CVE, superando por paliza a escáneres clásicos y a modelos menores (0 %). Este mismo paper advierte que, sin descripción, la tasa baja al 7 %, pero la ventana entre la publicación del advisory y el parche sigue siendo mortal.

Figura 3: LLM Agents can Autonomously Exploit One-day Vulnerabilities

En el contexto del examen SLAE32, un experimento técnico publicado en 0xboku demostró cómo el shellcode polimórfico creado manualmente puede alterar hasta un 33 % de su estructura (de 108 a 144 bytes) usando registros MMX y modificaciones de instrucciones, manteniendo su funcionalidad para evadir detección. Este caso, aunque no involucra LLMs, ilustra cómo técnicas clásicas de ofuscación ya desafían firmas SHA 256 y patrones estáticos, obligando a adoptar detección basada en comportamiento o modelos de IA entrenados en entropía y anomalías de ejecución.

1.1 No basta con “parchear rapidito”

Incluso con un SLA de parches de 24 h las organizaciones quedan expuestas durante todo el ciclo virtual —release de exploit, write-up en blog, publicación del PoC—. Necesitamos detección y respuesta en tiempo real, preferiblemente antes de que los bytes maliciosos crucen la frontera usuario-kernel. 

La hipótesis: el kernel susurra en nanosegundos 

El Extended Berkeley Packet Filter (eBPF) es nuestra oreja en ring 0:
  • Se carga como byte-code verificado; imposible desbordar el kernel.
  • Engancha tracepoints/kprobes a cualquier syscall sin recompilar ni reiniciar.
  • Copia eventos a espacio de usuario mediante ring buffer (cero copias).
  • Overhead bajo: Alto rendimiento al trazar syscalls execve y mprotect en workloads OLTP.

2.1 Características que sí delatan a un loader
  1. n-grams de syscalls (window=5): captura lógicas como open → read → mmap → mprotect → execve.
  2. Entropía de payload: indica compresión/cifrado.
  3. Δt entre syscalls: ciertos packers insertan “sleep-gaps” para evadir monitoreo.
  4. Delta de privilegios: salto uid 1000 → 0 es red-flag.
  5. Llamadas ptrace: frecuente en stagers que se inyectan en procesos confiables.
Los cinco valores se normalizan y forman un vector de 256 dimensiones que alimenta el algoritmo de Machine Learning.

Figura 5: Libro de Machine Learning aplicado a Ciberseguridad de
Carmen Torrano, Fran Ramírez, Paloma Recuero, José Torres y Santiago Hernández

El truco de magia: Spectral Clustering sin etiquetas

Mientras los IDS clásicos aprenden con datasets estáticos —y sufren cuando aparecen comportamientos inéditos— el Spectral Clustering trabaja a ciegas:
  1. Construye una matriz de similitud S calculando distancia Jensen-Shannon entre histogramas de vectores (researchgate.net).
  2. Obtiene el Laplaciano normalizado L = D⁻¹ᐟ² (D − S) D⁻¹ᐟ²
  3. Extrae los k autovectores de menor autovalor y proyecta los puntos.
  4. Aplica k-means en ese nuevo espacio.
Nota: investigamos Eigen-updates streaming, técnica que recalcula solo los autovectores afectados por un cambio local en S, logrando refrescar el modelo de 2- 3 ms sin reconstruir toda la matriz.

PoC I — portátil del blue team

Durante las pruebas iniciales quisimos demostrar que la detección basada en eBPF + Spectral Clustering cabe incluso en un laptop de respuesta rápida—el típico “equipo de guerra” que un analista lleva a un incidente.
  • Tracepoint raw_syscalls:sys_enter: el programa eBPF cuenta todas las syscalls y las lanza a un ring buffer (overhead ≈ 0.7 % CPU) .
  • Extractor en user-space: cada 500 ms levanta el histograma por PID y lo paddea a longitud constante.
  • Cálculo de similitud: matriz RBF simetrizada + self-loops mínimos para garantizar conectividad.
  • Spectral Clustering: con k = 2 → etiqueta “normal” vs “anómalo”; la decisión llega en ≈ 35 ms.
  • Acción: si label == anomalía, lanzamos un hook LSM que cancela execve, e inmediatamente Grafana genera una alerta.

Figura 6: Pipeline de detección de anomalías in-kernel
con eBPF + Spectral Clustering (PoC I)

Qué aprendimos del portátil
  • El ring buffer es clave: pasar a perf-event duplicaba la latencia.
  • Padding + RBF: permite trabajar con huellas de procesos muy diversos (LibreOffice pesa > 300 syscalls/ventana; un curl apenas 18).
  • El “modo laptop” es ideal para ofensiva inversa: llevas la detección in situ y cazas la amenaza antes de subir nada al SIEM.
PoC II — clúster K8s de producción
  • DaemonSet carga el colector eBPF.
  • Los vectores llegan por gRPC a un side-car que vive en el mismo node pool que OpenSearch, evitando saltos de red.

Figura 7: Arquitectura de telemetría y respuesta
en el clúster Kubernetes (PoC II)
  • DaemonSet despliega el sensor en cada nodo (hostPID:true, privileged:true).
  • Cilium exporta sus mapas eBPF (cilium/ebpf/v2) y nos evita duplicar sondas.
  • Hubble Relay agrega eventos L4, que se fusionan con la matriz‐syscalls vía ID de contenedor.
Todos los dashboards viven en un Grafana-LOKI-Tempo stack; las alertas llegan a PagerDuty.

Correlación Hubble + syscalls — afinando el detector en microservicios ruidosos 

La tesis es sencilla, ya que los False Positives suelen aparecer cuando un microservicio legítimo realiza ráfagas inusuales de syscalls—por ejemplo, un side-car de logging que comprime registros antes de enviarlos.
Si correlacionamos flujos L4/L7 de Hubble (la capa de observabilidad de Cilium) con la secuencia de syscalls del mismo container_id, obtenemos contexto de red que ayuda al modelo espectral a distinguir un backup ruidoso de un loader malicioso.
  • Emparejar eventos: cada registro Hubble porta pod_uid y container_id. El extractor agrega esos campos al vector de 256 D.
  • Nuevas features: dirección (ingress/egress), proto, bytes_sent y ratio packets/Δt.
  • Reentrenar parcial (Eigen-update): cada 10 s para minimizar deriva.
Lecciones aprendidas

Después de estas pruebas, hemos visto como el  análisis no supervisado elimina la esclavitud de etiquetar muestras de malware. Además, el uso de eBPF permite hot-patch del sensor sin tener que reiniciar ni recompilar el kernel. En todo este proceso, el cuello de botella real es el cálculo completo de autovectores y el uso de Eigen-updates reduce la carga a la décima parte.

Figura 9: "Malware moderno: Técnicas avanzadas y su influencia en la industria"
de Sergio de los Santos en  0xWord

Además, correlacionar capa de red (Hubble) con syscalls baja los falsos positivos en escenarios de microservicios ruidosos, lo que es muy beneficioso. Por último, en todo este proceso es muy importante la UX del analista, y tener un panel que combine “Top anomalous pods” con la llamada exacta a mprotect(PROT_EXEC) ahorra 10 min de búsqueda a las 03 : 00.

Como próximos pasos en este aprendizaje, vamos a trabajar en  extender el modelo para cubrir tráfico  de los niveles L4/L7 completos. Proceder a automatizar las acciones de mitigación vía Falco + ArgoCD y explorar distancia de Wasserstein sobre los histogramas, prometedora para diferenciación fina de malware polimórfico. Además, queremos probar despliegue desde el edge en IoT (ARM64) con micro-agentes eBPF.

Publicado por Chema Alonso a las 5:17 p. m. 0 comentarios

Etiquetas: , , , , , , , , , ,

miércoles, abril 30, 2025

Llama Protections: LlamaFirewall con PromptGuard 2, LlamaGuard 4, AlignmentCheck, CodeShield + AutoPatchBench & CyberSecEval 4

Ayer Meta lanzó oficialmente Llama 4 Behemoth, pero además puso sobre la mesa un montón de mejoras y anuncios de seguridad sobre los que ya tenía. No hace mucho yo os había hablado de CyberSecEval 3, Llama Guard 3, Code Shield y Prompt Guard, pues bien, ahora ha actualizado las versiones de todas esas medias de seguridad a CyberSecEval 4, Llama Guard 4, Prompt Guard 2, y se han añadido AligmentCheck, AutoPatchBench a CodeShield y LlamaFirewall, que os paso a contar aquí mismo. Mucho tema.
Como os podéis imaginar, las actualizaciones son muchas, así que os invito a que leáis en detalle los artículos de todos los productos, que han sido puestas online el mismo día que tuvo lugar la LamaCON 2025, así que tienes material para estudiar, donde además se anunciaron Llama API y Meta AI como aplicación, así que hay material para jugar.

CyberSecEval 4

Como ya os conté, CyberSecEval es una metodología de evaluación para tener un benchmark de todos los riesgos de ataque que puede sufrir un modelo LLM para tener bien medido el nivel de seguridad de la respuesta. Ha sufrido una actualización, y en la metodología han añadido las nuevas técnicas de Prompt Injection, Jailbreak, y nuevas amenazas que han ido descubriéndose.
Por supuesto, como os podéis imaginar, desde la salida de Llama 4 Maverick y Llama 4 Scout, y el reciente Llama Behemoth, tenían que actualizar los Benchmarks con ellos. Ahora la tienes disponible en GitHub, y tienes una guía de usuario de cómo utilizarla para poder ejecutar los Benchmarks.
Como verás, se pueden obtener resultados de comportamiento contra todos los Datasets relativos a MITRE y False Refusal Rate, Prompt Injection, Explotación de Vulnerabilidades, ataques de Spear Phishing, Operaciones de Seguridad Ofensiva, etcétera.

Llama Guard 4

Actualización del modelo Llama Guard 4 que tiene como única función detectar si un Prompt es malicioso o no. Este LLM es ahora nativamente Multi-Modal y permite Pompts con imágenes, textos, etcétera, lo que ayuda a la detección de los Pompts Maliciosos.

Figura 4: Llama 4 Guard

Al igual que la versión anterior, está alienado con la taxonomía de ataques definida en  el paper de Introducing v0.5 of the AI Safety Benchmarkfrom MLCommons y puedes descargar el modelo desde la web de descargas de Llama.

Figura 5: Llama Guard 4 vía API. Ejemplo.

Además, con el anuncio de Llama API, ahora es posible consultarlo también via API y recibir la respuesta con una sola línea de código que puedas introducir en tus servicios digitales.

Prompt Guard 2

El equipo de seguridad de Llama también ha actualizado Prompt Guard a la versión 2, poniendo a disposición pública la herramienta diseñada para detectar ataques. Su objetivo no es únicamente detectar Prompt Maliciosos como Llama Guard, sino detectar un ataque de Prompt Injection, Jailbreak, Exfiltración de Datos, etcétera en un servicio basado en LLMs.

Figura 6: Prompt Guard 2

En la siguiente imagen se ven diferentes tipos de análisis de Prompt Injection y Jailbreak donde está evaluando si algunos de los Prompt son reconocidos como parte de ataques para tener un catalogación como "Safe" o el tipo de riesgo que es.
Con estas protecciones, el ASR (Attack Success Rate) se reduce drásticamente y probándolo contra el entorno de evaluación de Agentes AI de AgentDojo que tenéis en el paper "AgentDojo: A Dynamic Environment to EvaluateAttacks and Defenses for LLM Agents" los resultados son mucho mejores.
Pero no solo ha habido actualizaciones de las versiones, sino que tenemos nuevas herramientas de seguridad, y nueva protecciones, como las que vamos a ver a continuación.

AlignmentCheck

Esta es una nueva característica de seguridad de Llama 4 que me ha gustado mucho, y que creo que va a ser un buen elemento mitigador para detectar los ataques cuando están teniendo éxito. Se trata de una revisión constante de lo que se está realizando en un instante concreto con el objetivo del Prompt original. 
Supongamos que le decimos a Llama 4 en un Prompt que resuma los documentos de una base de datos en una arquitectura RAG, y se pone a trabajar. En un instante de tiempo se encuentra en un documento un ataque de Prompt Injection que le pide que haga otra cosa, por ejemplo escribir los últimos Prompts que ha recibido, o lo que sea, en ese caso el flujo de ejecución del LLM habría sido secuestrado y estaría haciendo otra cosa que no tiene nada que ver con el Prompt Original que era resumir documentos.
AlignmentCheck realiza durante toda la fase de ejecución del Prompt un control de alineamiento para ver si la acción que está ejecutando en ese momento está alineada con lo que se le pedía en el Prompt Original o no. Si no está alineada, detendrá el proceso y levantará un alerta. Básicamente es un "No sé qué ha pasado, pero algo ha pasado, pantalla azul". Esto es especialmente necesario en Llama 4, donde el Contexto se ha aumentado tanto, que es fácil encontrar muchos tokens de entrada que pueden atacar o confundir a un modelo de Llama.

CodeShield & AutoPatchBench

Continúa siendo una pieza fundamental para la seguridad del código que se escribe con Llama Code. Es una protección típica de los equipos de desarrollo de código, con verificación automática de búsqueda de vulnerabilidades con librerías de Análisis de Código Estático, que es lo que hace el equipo de Meta con su Insecure Code Detector (ICD), que se encarga de filtrar el código que genera la salida de Llama Code para verificar si se ha introducido un bug, y solicitar que se vuelva a generar.
Esta verificación consiste en revisar la salida del código a lo largo de diferentes lenguajes de programación - un total de siete -, a saber: Rust, C, Python, PHP, Java, C++ y JavaScript, contra 50 tipos de debilidades (CWE: Common Weakness Enumeration) y aunque el resultado no es la panacea, ayuda a mejorar la calidad del código que genera. Pero la gran novedad ahora es el nuevo AutoPatchBench.
Con AutoPatchBench, se trata de conseguir correcciones de Bugs por medio de Patches hechos por modelos LLMs de manera mucho más robusta. Así, el equipo de Llama Security ha estado trabajando en que, cuando se detecte un bug en un código, generado o detectado por un LLM, se pueda lanzar un proceso de generación de y validación de Patches robusto.
Esto permite tener mejores Patches, y un código mucho más robusto. Tenéis toda la información de esta nueva protección de seguridad en la web de AutoPatchBench.

Llama Firewall

Y todo esto nos lleva a la parte más importante de todas "Llama Firewall" que es la pieza de seguridad incluye a todas las demás y que protege la seguridad de los servicios y aplicaciones basados en MM-LLMs, y por supuesto en la familia Llama.

El paper, que lo podéis leer en el enlace que os dejo a continuación, explica cómo Prompt Guard, Llama Guard, Code Shield, AlignmentCheck y AutoPatchBench son parte de esta pieza de seguridad  que es Llama Firewall que trata de proteger en tiempo real todos los servicios que están basados en Llama.

Figura 15: Llama Firewall

Todas las explicaciones que he utilizado para este artículo vienen detalladas en el paper, y podéis acceder a más detalles que profundizan en lo que hace cada uno de los módulos. 
Tengo un vídeo con una demo de Llama Firewall, pero ya será para otro día, que este artículo ya ha quedado bastante largo, y merece la pena que lo analices con calma.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  


Publicado por Chema Alonso a las 3:43 p. m. 0 comentarios

Etiquetas: , , , , , , , , ,

sábado, febrero 24, 2024

Máxima Seguridad en Windows: Secretos Técnicos. 6ª Edición actualizada con nuevos contenidos

Hoy estamos de celebración, porque hemos sacado un nuevo libro de 0xWord, que cada día cuesta más mantener viva esta pequeña editorial, pero cada nuevo título es motivo de felicidad. En este caso es una nueva, la 6ª Edición, de "Máxima Seguridad en Windows: Secretos Técnicos"del gran Sergio de los Santos, del que se han vendido más de 5.000 ejemplares. Junto a "Hacking Web3: Challenge Accepted!", "Amazon Web Services (AWS): Hardening de Infraestructuras Cloud Computing", y uno más que nos queda por publicar la semana que viene, serán novedades en la RootedCON de este año.
Con la nueva actualización Sergio de los Santos ha querido meterle una revisión profunda desde la que realizó en el año 2020 y hacer una edición muy especial con motivo de alcanzar los 5.000 ejemplares vendidos de este título, que es un "superventas" de nuestra pequeña editorial 0xWord.

En el caso de "Máxima Seguridad en Windows: Secretos Técnicos. 6ª Edición" actualizada con nuevos contenidos, el índice ha cambiado bastante, ya que si bien las secciones han cambiado poco, los detalles han ido cambiando radicalmente en este texto actualizado a día de hoy. Aquí lo tienes.


Además, si quieres consultar cualquier pregunta sobre el libro de Máxima Seguridad en Windows al autor, Sergio de los Santos, lo puedes hacer a través de su buzón público en MyPublicInbox, con lo que la lectura y el aprendizaje será mucho más efectivo. 

Figura 4: Contactar con Sergio de los Santos

Para terminar, te recuerdo que tendrás también 100 Tempos de MyPublicInbox por la compra de este libro de "Máxima Seguridad en Windows: Secretos Técnicos. 6ª Edición" y que además, puedes pagar completa o parcialmente este libro con Tempos de MyPublicInbox. Aquí te explico cómo se hace.

Usar tus Tempos de MyPublicInbox 0xWord para adquirir este libro

La idea es muy sencilla, hemos creado un Buzón Público de 0xWord en MyPublicInbox y tenemos disponible el módulo de transferencias de Tempos entre cuentas siempre que el destinatario sea un Perfil Público de la plataforma. Para que se puedan hacer estas transferencias, primero debe estar el Perfil Público destinatario de la transferencia en la Agenda.

Figura 5: Perfil de 0xWord en MyPublicInbox. Opción de "Añadir a  la Agenda".
https://MyPublicInbox.com/0xWord

Para dar de alta un Perfil Público en tu agenda, solo debes iniciar sesión en MyPublicInbox, y con la sesión iniciada ir a la web del perfil. En este caso, a la URL del perfil público de 0xWord en MyPublicInbox, - https://MyPublicInbox.com/0xWord - donde te aparecerá la opción de "Añadir a la agenda". Cuando acabe este proceso, podrás ir a la opción Agenda de tu buzón de correo en MyPublicInbox y deberías tener el Perfil Público de 0xWord allí.

Figura 6: Cuando lo agregues estará en tu agenda

Una vez que lo tengas en la agenda, ya será tan fácil como irte a tu perfil - se accede haciendo clic en la imagen redonda con tu foto en la parte superior - y entrar en la Zona de Transferencias. Desde allí seleccionas el Buzón Público de 0xWord, el número de Tempos que quieres transferir, y en el concepto debes poner que es para recibir un código descuento para usar en la tienda de 0xWord.


No te preocupes por el texto concreto, porque los procesamos manualmente como los pedidos de se hacen en la tienda. 

Canjear 500 Tempos por un código descuento de 5 €

La última opción es bastante sencilla. Solo debes irte a la sección de Canjear Tempos -> Vales para Tiendas, y "Comprar" por 500 Tempos y código de 5 €. Es lo mismo que enviar la transferencia pero en un paquete de 500 Tempos y de forma totalmente automatizada, así que solo con que le des a comprar recibirás el código descuento y lo podrás utilizar en la tienda de 0xWord.com

Así que, si quieres conseguir nuestros libros de Seguridad Informática & Hacking aprovechando los Tempos de MyPublicInbox podrás hacerlo de forma muy sencilla y mucho, mucho, mucho más barato. Y así apoyas este proyecto tan bonito que es 0xWord.com.

Ser escritor de libros de 0xWord

Además, todos lo que queráis convertiros en escritores y hacer un proyecto de libro con nosotros. Podéis también enviarnos vuestra propuesta a través del buzón de 0xWord en MyPublicInbox, y si sois Perfiles Públicos de la plataforma, podéis entrar en la sección de Mi Perfil -> Servicios para ti y solicitar más información sobre el proceso de escribir un libro en 0xWord.
Nuestro equipo se pondrá en contacto contigo y evaluará tu proyecto de publicación de libro. Ya sabes que principalmente de Seguridad Informática & Hacking, y puede ser técnico, súper-técnico, o divulgación, y si es una novela... podemos estudiarlo también.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  


Publicado por Chema Alonso a las 7:01 a. m. 0 comentarios

Etiquetas: , , , , , , , , , , , , ,

Suscribirse a: Entradas (Atom)

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