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

domingo, junio 21, 2026

¿Cómo solucionas las vulnerabilidades del software de tu PYME? Haz un diagnóstico gratuito con ironGate CyberSecurity

Cuando hablamos con responsables de PYMEs sobre ciberseguridad, casi todos me dicen lo mismo: "tenemos antivirus" o incluso "tenemos un EDR". Y me alegra escucharlo, porque hace unos años eso ni se planteaba. Pero cuando rascas un poco más y preguntas "¿y las vulnerabilidades de tus equipos, quién las cierra?", la respuesta casi siempre es un silencio.


Y ahí está el problema. La inmensa mayoría de los incidentes que se producen en pequeñas empresas no nacen de un ataque sofisticado ni de un 0-day exótico. Nacen de una vulnerabilidad conocida, publicada, con parche disponible desde hace semanas o meses, que sencillamente nadie ha instalado. Un sistema operativo sin actualizar, una versión de un software ofimático con un CVE crítico por el que se te va a colar un ransomware, un firmware que lleva dos años igual con un bug que permite ejecución de código remoto, etcétera. La puerta estaba ahí, abierta, y nadie la cerró
Esto, con el nuevo Crimeware que usan los cibercriminales empoderados con Agentes de IA para encontrar las vulnerabilidades de las empresas, hacen que muchas empresas se estén convirtiendo en carne de cañón, y estemos viendo un repuntar de ataques e infecciones en las empresas con menos madurez en la gestión de seguridad.

Escanear no es lo mismo que remediar

Aquí es donde muchas soluciones de seguridad se quedan a medias. Hacen un escaneo de vulnerabilidades, generan un informe en PDF con una lista de CVEs ordenados por gravedad… y ahí termina el servicio. El informe se queda en una bandeja de entrada, y la responsabilidad de parchear, priorizar y comprobar que el cambio no rompe nada, recae sobre un departamento de IT que, en una PYME, normalmente no existe, o es una sola persona con otras cien cosas que hacer.

Figura 3: Gestión de parches y vulnerabilidades en ironGate Cybersecurity

Ese hueco entre "sabemos que hay un problema" y "el problema está resuelto" es exactamente donde se cuelan la mayoría de los atacantes. En ironGate Cybersecurity no nos quedamos en el informe: Remediamos vulnerabilidad a vulnerabilidad, hasta dejar el equipo a cero.


Esto es algo que en IronGate Cybersecurity hacemos de forma distinta a lo que he visto en el mercado: cuando detectamos las vulnerabilidades de un equipo, no nos limitamos a generar un aviso. Nos ponemos en contacto con el cliente y empezamos a remediar, vulnerabilidad a vulnerabilidad, hasta que ese equipo se queda completamente a cero. No es un informe que alguien tiene que interpretar y ejecutar por su cuenta: es un trabajo de remediación activa, dispositivo por dispositivo, dentro del mismo servicio de MDR que ya vigila esos equipos 24x7.

El tiempo para explotar una vulnerabilidad cada vez es más corto

Con la llegada de modelos de IA cada vez más capaces —no es necesario que sea Mythos, que está generando preocupación en la banca a nivel mundial, porque cualquiera de los que uttilizan los ciberscriminales son un buen ejemplo de ello— el tiempo que pasa entre que se publica una vulnerabilidad y que alguien la explota de forma automatizada se ha reducido muchísimo. 

Ya no hablamos de semanas de margen. A veces son horas, por eso estamos viendo un aumento de las demandas en nuestros servicios de Gestión de Seguridad. Dejar una vulnerabilidad sin cerrar durante meses, en este contexto, es jugar con fuego.

Por dónde empezar

Si no sabes cuántas vulnerabilidades tiene tu empresa ahora mismo, en ironGate Cybersecurity ofrecemos un Diagnóstico de Seguridad Gratuito que te dice exactamente eso: Qué vulnerabilidades tienen tus equipos y qué riesgo suponen. A partir de ahí, nosotros nos encargamos de cerrarlas, una por una.


Cerrar una vulnerabilidad cuesta minutos. Recuperarte de que alguien la haya explotado, cuesta mucho más —en dinero, en tiempo y en disgustos—. Si tu PYME es tu forma de vida, no dejes la puerta abierta. Además, si luego quieres este servicio, es 100% Financiable con el Kit Digital.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

miércoles, octubre 08, 2025

CodeMender: Un Agente IA para buscar bugs y parchear código fuente

Hace unos meses os dejé el artículo titulado: "Usar Deep Reasoning en GitHub para buscar ( y parchear ) Bugs en proyectos Open Source" donde hablaba de algo que parecía bastante evidente, que es utilizar, los modelos de Deep Reasoning para lo que dice el título, buscar las vulnerabilidades, avisar de ellas en los proyectos Open Source, para que quién se vaya a descargar el software sepa qué bugs tiene, que el mantenedor del código lo pueda parchear, o que directamente haya una propuesta de parche hecha directamente por un modelo de GenAI.
Es decir, que cuando se visita un proyecto OpenSource en GitHub u otra plataforma similiar, y el repositorio ha revisado ya todo el código y muestra a los usuarios que se los van a descargar si tiene vulnerabilidades conocidas o no, para que no te lo descargues o para que le llegue un aviso al mantenedor de que ese código debe ser actualizado o se marcará como inseguro. 

Y finalmente que haga con GenAI propuestas de código de parchear el proyecto automáticamente, como hace la plataforma Plexicus, que está empujando José Palanco, y que es una de las primeras soluciones profesionales que hace esto.

Figura 3: Plexicus parchea con GenAI los bugs

Ahora Google ha presentado CodeMender, que utilizando esta misma idea lo ha estado usando para analizar y parchear código de proyectos OpenSorce con un Agente AI. Y si veis el proceso en el vídeo siguiente, el modelo es muy, muy, muy similar a lo que tenéis en el vídeo anterior.
Para que veáis cómo funciona CodeMender, en la web se presentan un par de ejemplos. Este primero escanea el código razonando en busca de vulnerabilidades, de igual forma que yo os contaba en el artículo donde usaba DeepSeek. En este caso, lógicamente, utilizando Gemini.
En este caso, se pregunta qué sucede si no se sacan los elementos de la pila, lo que podría generar un error, como razona CodeMender en la siguiente fase.
A partir de este momento hace un análisis detallado de cómo se gestiona la pila en este código, y comprueba que se puede producir una situación donde los elementos no salen de ella, tal y como se ve en la imagen siguiente.
Una vez que ha descubierto que ya hay una situación errónea no controlada en el código, comienza la fase de encontrar un parche correcto y proponerlo al código.
En este caso, el proceso de DeepReasoning de Google Gemini ha estado permitiendo que CodeMender funcione en modo Agentic AI evaluando todo el código para ver si descubre algún bug, pero también puede funcionar directamente para parchear un código que se sabe ya que tiene el fallo, como se ve en este vídeo.
Según el blog, durante los últimos 6 meses durante la construcción de CodeMender, han estado analizando proyectos OpenSource y el agente ha hecho 72 Security Fixes para proyectos populares, algunos de hasta 4.5 Millones de líneas de código.
Por supuesto, como decía yo en el artículo, esta es una herramienta perfecta también para los que tienen el mundo del Bug Bounty: De Profesión "Cazarecompensas", que pueden encontrarse con premios descubiertos por estos modelos que te hagan la vida más sencilla.

Si te interesa la IA y la Ciberseguridad, tienes en este enlace todos los postspapers 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)  


viernes, mayo 16, 2025

Usar Deep Reasoning en GitHub para buscar ( y parchear ) Bugs en proyectos Open Source

Fue allá por el año 2007 comencé a trabajar en las técnicas de LDAP Injection & Blind LDAP Injection que a la postre sería mi primera charla internacional en BlackHat Europe 2008, donde presenté el paper de "LDAP Injection & Blind LDAP Injection in Web Applications" que puedes ver online. En aquel entonces, busqué aplicaciones vulnerables que pudiera usar de ejemplo, y para ello tire de proyectos Open Source, haciendo dorkings y mucho Hacking con Buscadores para encontrar las víctimas propicias.

Figura 1: Usar Deep Reasoning en GitHub para buscar
( y parchear ) Bugs en proyectos Open Source

Una de ellas fue LABE (LDAP Address Book Editor) un aplicación web para tener una libreta de direcciones basada en un árbol LDAP. Por supuesto, vulnerable a las técnicas de LDAP Injection & Blind LDAP Injection.
Ayer, después de estar revisando un nuevo paper de cómo utilizar LLMs para hacer ataques de red - del que os hablaré muy prontito - me vino el pensamiento de sería mucho más fácil y más seguro si los repositorios de código fuente tuvieran ya metadatos de seguridad y bugs para todos los proyectos que hospedan analizados con modelos de Deep Reasoning.

Repositorios que te alertan de los bugs

Es decir, tú vas a un proyecto OpenSource en GitHub u otros, y el repositorio ha revisado ya todo el código y muestra a los usuarios que se los van a descargar si tiene vulnerabilidades conocidas o no, para que no te lo descargues o para que le llegue un aviso al mantenedor de que ese código debe ser actualizado o se marcará como inseguro. Y que le dé con GenAI opciones de parchear el código automáticamente, como hace la plataforma Plexicus, que está empujando José Palanco.

Figura 4: Plexicus parchea con GenAI los bugs

Ahora mismo, los repositorios tienen secciones de "issues" donde se pueden reportar bugs, fallos, warnings, etcétera, pero todos hechos por "humanos" por ahora, y tal vez deberían estar ya aprovechando el mundo de los LLMs para mejorar la seguridad de los proyectos OpenSource de "long-tail" de manera masiva. Yo he ido a probar con el repositorio de LABE y le he pasado el código a Perplexity Pro con Deep Research, y le he pedido que busque bugs en uno de los ficheros del proyecto, y me diga cómo parchearlos.

Figura 5: Bug de LDAP Injection alertada en LABE

El primero de todos los bugs que reporta es el que ya conocía yo de LDAP Injection, pero el proyecto sigue están disponible para que más usuarios se lo descarguen sin ningún warning, y la lista de bugs es más larga.

Figura 6: LABE tiene bug de XSS persistente

Como podéis ver  en la imagen anterior, tiene un XSS persistente, pero a día de hoy cuenta también con funciones obsoletas, y acceso inseguro a variables globales como $_GET que además está obsoleta. Normal, este código tiene muchos años.

Figura 7: Más debilidades en el código de LABE

No se trata de "demonizar" LABE, sino de ver lo bien que lo hacen los modelos de Deep Reasoning para buscar debilidades y fortificaciones a un código Open Source en un repositorio, y que si lo hace el propio repositorio una vez, nos ahorramos hacerlo todos una y otra vez para ver qué nos estamos instalando.

Figura 8: CSRF y fallos de inicialización

No le he pasado todo el proyecto, sólo un fichero que ya tenía controlado con un LDAP Injection, pero como podéis ver en las imágenes ha salido también XSS, CSRF que son Client-Side Attacks, errores no controlados, variables sin inicializar, uso de funciones deprecadas, etcétera, lo que sería información muy valiosa que podría venir en los repositorios de código como GitHub y los gestores de paquetes.


También nos aparece un bug en la "cadena de suministro", ya que en el año 2024 se reportó un bug con severidad 7.3 en el framework de smarty que permite inyección de código, lo que demuestra que hay que tener un control constante de tus librerías para evitar estos peligros.

Análisis con DeepSeek Deep Think R1 

He querido probar con un repo de GitHub que también hace uso de búsquedas en árboles LDAP y que en este caso está escrito en C++, para ver cómo hace el análisis, y si GitHub podría hacer este análisis con su GitHub Copilot y dejar la info en forma de Warnings a los que se descargan el código.
Entiendo que poner issues de seguridad en los repos puede ayudar a los atacantes, pero es que los atacantes pueden hacer este trabajo, tener un 0day de un repo de long-tail y tener a GitHub entregando descargas a nuevas víctimas durante años.

Figura 11: Thinking de Deep Seek

Os ahorro las capturas del Prompt donde le paso el código del fichero que ves en la Figura 9 y le pido que busque bugs y me diga cómo corregirlos. Pero en la Figura 10 tenéis el Thinking que sí es interesante, pues en 19 segundos analiza el código y saca los resultados.

Figura 12: DeepSeek reporta un LDAP Injection

Como se puede ver, lo que reporta es  un LDAP Injection en primer lugar, ya que construye los filtros LDAP de las consultas sin ninguna sanitización, y eso se puede ver en el código como os dejo a continuación.

Figura 13: Construcción de filtros LDAP inseguros

Pero es que el análisis completo es bastante bueno, ya que sigue analizando el código y todas las implicaciones y las explica muy bien. Por ejemplo, cómo acceder con la inyección a atributos sensibles como passwords que pudieran existir en el árbol LDAP.

Figura 14: Explotación de LDAP Injection con manipulación de parámetros

En la siguiente imagen vemos cómo reporta también un problema de flujo de la lógica al no escapar los caracteres de control de LDAP que podrían cmabiar el comportamiento.

Figura 15: Escapado de caracteres de control

Y si seguimos viendo el informe, podemos ver cómo el tratamiento de errores no es seguro, permitiendo problemas en el funcionamiento del programa pero también Data Leaks de la estructura de la red al no haber controlado los errores de conexión al árbol LDAP.

Figura 16: Errores no controlados.

Para terminar aún nos da unas recomendaciones más que sensatas de seguridad añadidas que deberían ser tenidas en cuenta, como son estas dos, que yo las tendría en cuenta. Este código no lo conocía de antes, ni sabía si era vulnerable a LDAP Injection o no, y ni mucho menos del resto, pero si miráis en los issues, no hay nada de esto. 

Figura 17: Recomendaciones finales

Al final, desde hace años ya conocemos las capacidades de los LLMs para buscar bugs, esto es de lo primero que probamos, por supuesto. Así que si las usamos para fomentar que los proyectos OpenSource alerten a los usuarios que se los descargan, para que los repositorios de código incentiven a los mantenedores a parchearlos, o que lo hagan de forma automática ayudaría a reducir los bugs que acaban en los servidores de las víctimas.

PD: Si te interesa la IA y la Ciberseguridad, tienes en este enlace todos los posts, papers y charlas que he escrito, citado o impartido sobre este tema: Inteligencia Artificial (Hacking & Security): Links, Posts, Talks & Papers

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  


jueves, noviembre 03, 2011

No Lusers 107 - Magneto, el amo del metal


Hace ya más de un par de años tuve un bonito debate sobre el uptime con mi "enamigo" Sergio de Los Santos (@ssantosv). Eso nos llevó a debates sobre si hotpatching es recomendable o no, y si realmente se puede mantener un servidor único con el uptime al máximo sólo con hotpatching, y lo más importante... "si es inteligente".

Años después, habiendo ya esclavizado a Sergio "Pajarraco" de los Santos para que me escribiera el libro de "Una al día: 12 años de seguridad informática" y el libro "Máxima Seguridad en Windows", tras haberle liado para dar mil charlas y una más; tras haberle liado para toda cosa que se me pasa por la cabeza... aún me acuerdo de aquel debate, solo por si algún día puedo hacerle sufrir por llevarme la contraria.

Acordándome de que el convenio laboral que se ha aplicado a muchos informáticos ha sido el convenido del metal - por todo el morro -, nació este No Lusers, que sirve para recordarle a "Pajarraco" que no me olvido... "I'm watching you...."

Saludos Malignos!

miércoles, diciembre 23, 2009

Horney Patches

Uno de los debates que tiempo ha han dedicado mis mejores broncas en algunos de los más perdidos bares es el tema de confundir el Uptime del servidor con el Uptime del Servicio. Existes seres que cuentan el tiempo que lleva su servidor sin reiniciarse como el que cuenta los intereses de la cuenta naranja de ING y luego se defienden como gato panza arriba cuando les preguntas por los parches. Las respuestas pueden ser de lo más peculiares que yo las he ido catalogando:

A) Servidor Chuck Norrix:
Son los que usan esta distribución de Linux al más puro estilo Ranger y están por encima del bien y del mal. La respuesta suele ser:

¿Parches? Mi server es un hax0r y no tiene bugs y no necesita parches…

B) IT Pro Sherlock Holmes: Son los que ante la pregunta de por qué su servidor lleva 400 días de uptime responden:

¿Parches? Me los reviso uno a uno y sólo he instalado los que aplican a mi entorno. Y como mi equipo no tiene ni kernel, pues no le he tenido que aplicar ninguna.

¿Qué tienes majo, un Furby server?

C) El servidor en escabeche: Los servidores son como las anchoas, se conservan sin tocarlos, por lo que los servidores NO se parchean. Eso, y si puedes ponlos de cara a Internet y sin contraseñas, que tengo unos amigos locos por visitar tú servidor. Os dejo un mail de un sufrido lector de este blog:


Fijaros el trabajo que duro es. PRIMERO: Haz el parche y comunica a todo el mundo que hay un parche nuevo. SEGUNDO: Comunica a todo el mundo que no lo instale. Trabajar en Spectra es duro.

El mail lo deja claro..."Nosotros te lo instalamos, pero que sepas que... SE TE VA A JODER EL UPTIME sólo por 57 actualizaciones críticas de mierda".

D) Horney Patches: No, eso de reiniciar tras aplicar un parche es un atraso desde que existen las estrategias de parcheo en caliente.
Nosotros parcheamos on fly…

Es este último tipo de respuesta el que más me preocupa. Vaya por delante que generalmente la peña que da una de estas tres respuestas suele estar excusando una negligencia supina que se ha basado en no aplicar ninguna solución de parcheo y que lo único que busca es salir airoso del rincón donde se encuentra atrapado. La verdad es que sí tiene parches, no se ha revisado todos los parches de todos los productos que están corriendo en su servidor uno a uno y, por supuesto, no parchea en caliente.

Parchear en caliente es una solución delicada. Los sistemas MS Windows, desde Windows Server 2003 SP1, realizan, automáticamente, parcheos en caliente si está habilitada la opción de hotpatching. Para ello, los parches en caliente (que no cachondos) de los sistemas Windows llevan asociado el hotpatch, con los cambios que se deben realizar a la imagen cargada en memoria, y el coldfile, con el nuevo fichero que debe suplantarse.

Sin embargo, esto no siempre se puede realizar por lo que están catalogadas algunas limitaciones conocidas y algunos problemas de compatibilidad (que se habrán descubierto "por las malas"). Hay que tener en cuenta que el número de software instalado en un equipo es difícil de cuantificar y siempre queda la opción de que pueda darse alguna incompatibilidad que te fastidie "tu uptime".

Si el utilizar estrategias de parcheo en caliente con el software del sistema es complejo, el aplicarlo con componentes ejecutándose con altos privilegios que no vienen preparados para hotpatching es aun más temerario. La idea es que existen herramientas para que tú te crees el parche adecuado para esos componentes, es decir, el hotpach y el coldbinary utilizando herramientas externas. Esto, si estamos hablando de un servidor tan crítico que no puede ser reiniciado es una temeridad por si se produce cualquier fallo: tanto de incompatibilidad o como de cagada humana.

En resumen, si tu servicio es tan crítico que no se puede detener, entonces monta una estructura multiserver que para eso existen los clusters, los sistemas de réplica o las arquitecturas distribuidas. Si no es tan crítico el servicio, aplica los parches en la mejor franja horaria y reinicia cuando el fabricante te lo diga. Y si la has cagado a lo grande y el servicio no puede ser parado y has diseñado una arquitectura mono-servidor, entonces, y sólo entonces aplica la opción B) (por si tienes suerte) y la D) (para ver si salimos de esta).

Saludos Malignos!

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