Se bienvenido a estas tierras digitales...
...especialmente si eres un molino....
Código y seguridad de la memoria.
La seguridad en la gestión de memoria es un problema persistente que ha afectado a la industria del software durante décadas. Se estima que más del 65% de las vulnerabilidades críticas en el software de propósito general tiene su origen en fallos de seguridad en memoria, lo que ha permitido desde infecciones masivas de malware hasta ataques dirigidos contra infraestructuras críticas.
Lenguajes como C y C++, fundamentales en la construcción del ecosistema de software actual, han sido responsables de muchas de estas vulnerabilidades debido a su gestión manual de memoria y la falta de mecanismos intrínsecos para evitar accesos indebidos (claro, más allá de los que ofrece el propio sistema operativo). A pesar de las mejoras en herramientas de mitigación y buenas prácticas, los avances en técnicas de explotación han convertido la seguridad en memoria en una carrera armamentista constante.
Sin embargo, estamos en un punto de inflexión: existen tecnologías con la capacidad de romper esta tendencia y permitir una adopción generalizada de software seguro por diseño. Para lograrlo, la industria necesita un estándar unificado y neutral que defina los requisitos para software seguro en memoria.
¿Por qué seguimos fallando en la seguridad en memoria?
El problema de seguridad en memoria no es nuevo. Desde el Morris Worm de 1988, que explotó vulnerabilidades en la gestión de buffers de UNIX, hasta ataques recientes como Spectre, Heartbleed y BlueKeep, los errores en el acceso a memoria han demostrado ser un punto de entrada privilegiado para atacantes. Hay que ser conscientes de que en las clases de ingeniería hay que prestarle más atención, y es por esto que en la asignatura de Periféricos e Interfaces se le presta mucha atención a los accesos a memoria desde la IOMMU, MMU, chipset, PCI, DMA, etc.
Pero centrándonos eminentemente en el software, algunas razones clave por las que persisten estos fallos incluyen:
Base de código heredada en C/C++: Con miles de millones de líneas de código aún activas (y depositadas en repositorios de Github – de donde aprende CoPilot), la migración a alternativas más seguras es costosa y compleja.
Estrategias de mitigación parciales: Técnicas como ASLR (Address Space Layout Randomization), DEP (Data Execution Prevention) o CFI (Control Flow Integrity) dificultan la explotación, pero no eliminan las vulnerabilidades subyacentes. Son sólo controles desde el Sistema Operativo, que recordemos que se apoya sobre el sistema de arranque (de hecho hay mucho esfuerzo invertido en hacerlo seguro, algo que también analizamos en Periféricos e Interfaces).
Ausencia de un marco estandarizado: No existe un conjunto de reglas universalmente aceptado que defina cuándo un sistema puede considerarse «seguro en memoria». Ni lo habrá. Porque la «Seguridad NO es un ESTADO es un PROCESO de continua EVOLUCIÓN«.
Tecnologías emergentes que ayudan en la seguridad en memoria
A pesar de estos desafíos, el panorama está cambiando con la maduración de diversas tecnologías enfocadas en prevenir vulnerabilidades en lugar de mitigarlas después de su explotación.
Lenguajes de programación con seguridad en memoria
- Rust: Garantiza la seguridad en memoria sin necesidad de recolección de basura, usando un sistema de propiedad y préstamos de referencias.
- Swift y SPARK: Incorporan verificaciones estáticas para evitar accesos inseguros a memoria.
- Subconjuntos seguros de C++: Iniciativas como Core Guidelines y RustBelt buscan limitar el uso inseguro de punteros y asignación dinámica en C++.
Protecciones de hardware avanzadas
- CHERI (Capability Hardware Enhanced RISC Instructions): Permite gestionar accesos a memoria de forma más granular, evitando accesos no autorizados incluso en código vulnerable.
- Memory Tagging (MTE en ARMv9): Detecta accesos indebidos en tiempo de ejecución mediante etiquetas de memoria.
Verificación formal y análisis estático
- Herramientas como Coq, Isabelle o Lean permiten demostrar matemáticamente que el código cumple propiedades de seguridad en memoria.
- CompCert (compilador formalmente verificado) garantiza que las optimizaciones del compilador no introducen errores de memoria.
Compartimentalización y aislamiento
- Técnicas como eBPF, WASM y sandboxing limitan el impacto de vulnerabilidades al restringir el acceso a recursos críticos.
Desafíos y estrategias de adopción
La implementación de un estándar global no será sencilla. Hay obstáculos importantes como:
Compatibilidad con código ya desarrollado e implantado: No es viable reescribir desde cero todo el software en lenguajes seguros, por lo que es necesario facilitar transiciones graduales.
Resistencia del ecosistema industrial: Empresas con software basado en C/C++ pueden percibir los cambios como una carga innecesaria en costes y tiempos de desarrollo.
Evaluación de costes frente a beneficios: Muchas organizaciones aún priorizan rendimiento sobre seguridad, sin considerar los costes ocultos de vulnerabilidades explotadas.
El escenario se complica con Copilot
La seguridad en memoria ya no es un lujo, sino una necesidad urgente. La tecnología está lista para el cambio, pero falta un esfuerzo coordinado entre academia, industria y gobierno para lograr una adopción efectiva. No podemos avanzar de manera descoordinada. Y un ejemplo claro es el de la iniciativa en la implantación de la IA. En el que los tres sectores, me da la impresión, que caminan sin comunicación.
Los modelos de inteligencia artificial aplicados al desarrollo de software, como GitHub Copilot, han revolucionado la productividad de los programadores. Copilot, basado en modelos de lenguaje como GPT, sugiere fragmentos de código basándose en un entrenamiento masivo con código público de GitHub. El problema es que estos modelos aprenden tanto código seguro como código plagado de vulnerabilidades.
Un estudio reciente analizó el código generado por Copilot en 89 escenarios que representaban tareas comunes de programación, evaluando su seguridad frente a los 25 principales tipos de vulnerabilidades listados por MITRE CWE. Los resultados: el 40% del código generado por Copilot contenía vulnerabilidades de seguridad.
Y es que este modelo, en particular, aprende de todo el código almacenado en Github y como cabría esperar se encuentran prácticas de programación obsoletas en el código generado.Inconsistencias en la calidad del código según el lenguaje de programación: Copilot es más seguro en Python que en C o C++, donde la gestión manual de memoria aumenta el riesgo. Falta de mecanismos de seguridad en el entrenamiento del modelo: «Garbage in, garbage out», Copilot absorbe patrones de código inseguro y los replica sin control.
Se deben usar modelos auditados. Digo yo, o al menos garantizar:
- Implementación de modelos de verificación automática para detectar vulnerabilidades antes de la producción.
- Revisión humana obligatoria en proyectos críticos, evitando una dependencia ciega de la IA.
- Regulaciones como ISO/SAE 21434 (Automoción) y Common Criteria (Infraestructura Crítica) deben incluir requisitos específicos para código generado por IA. Y esto es casi un «must».
La inteligencia artificial generativa ha comenzado a ocupar un lugar relevante en el análisis de malware, especialmente como herramienta auxiliar para las fuerzas y cuerpos de seguridad del Estado en su lucha contra el cibercrimen organizado. La creciente sofisticación de las amenazas, como el ransomware y otros tipos de malware, ha desbordado los enfoques tradicionales de ciberseguridad. Aquí es donde la IA puede marcar la diferencia: no como una solución mágica, sino como un catalizador para acelerar y mejorar la capacidad de respuesta.
En la siguiente tabla puedes ver las dos muestras de malware más populares estos días, y sí, su target principal son los terminales móviles que es donde lo llevamos todo.
| Nombre del Malware | Descripción | Método de Propagación | Recomendaciones | Fuente |
|---|---|---|---|---|
| ToxicPanda | Troyano bancario que afecta dispositivos Android, intercepta contraseñas OTP y roba información confidencial. | Phishing y smishing a través de correos o SMS maliciosos con enlaces a páginas falsas. | Descargar apps solo desde Google Play. | SER Madrid Sur |
| BadBox | Malware preinstalado en dispositivos Android, evade autenticación de dos pasos, comete fraudes publicitarios y controla dispositivos para ataques DDoS. | Insertado en el dispositivo antes de salir de fábrica; se activa al conectarse a Internet. | Desconectar y desechar dispositivos afectados. | AS |
| Aplicaciones espía | Doce aplicaciones en Android que graban conversaciones y realizan actividades invasivas en segundo plano. | Descargadas desde Google Play y otras fuentes mediante estafas románticas y phishing. | Evitar descargar aplicaciones desconocidas; desinstalar las apps identificadas. | HuffPost |
Imagina que la IA generativa actúa como un «asistente incansable» en el laboratorio de análisis de malware. Puede desofuscar código malicioso, generar firmas de detección y predecir cómo ciertas piezas de software podrían comportarse en entornos específicos. Este enfoque no solo alivia a los analistas de tareas repetitivas, sino que también les permite centrarse en los puntos críticos de una amenaza. Por ejemplo, una IA puede simular cómo mutará una familia de malware frente a diferentes contramedidas, ayudando a anticipar los movimientos de los atacantes. Y es que hay que señalar que el malware está preparado para no «detonarse» en un entorno que sea detectado como entorno de análisis.
En lo que respecta a malware especialmente orientado a PC, las muestras más relevantes a fecha de hoy, podemos considerar que son las que se presentan en la siguiente tabla (según https://cybersecuritynews.es/estas-son-las-diez-familias-del-malware-mas-activas-en-espana-actualmente ):
| Nombre del Malware | Descripción | Método de Propagación | Recomendaciones |
|---|---|---|---|
| Formbook | Infostealer que roba credenciales, captura pantallas y registra pulsaciones de teclado. | Campañas de phishing con archivos adjuntos maliciosos. | No abrir archivos adjuntos sospechosos, utilizar software de seguridad actualizado. |
| Remcos | Troyano de acceso remoto (RAT) que evade el UAC de Windows para controlar sistemas. | Documentos de Office maliciosos enviados por correos de spam. | Bloquear macros de documentos y analizar adjuntos antes de abrirlos. |
| NanoCore | RAT activo desde 2013, utilizado para espionaje corporativo y robo de información confidencial. | Phishing y sitios web comprometidos. | Configurar firewalls y sistemas de detección de intrusos. |
| Qbot | Troyano bancario que incluye capacidades de robo de credenciales y distribución de ransomware. | Correos electrónicos de phishing y exploits en software vulnerables. | Parchear vulnerabilidades de software y evitar enlaces sospechosos en correos. |
| Emotet | Troyano que ha evolucionado a una plataforma de distribución de otros tipos de malware, incluidos ransomware. | Correos de phishing con enlaces o adjuntos maliciosos. | Analizar correos antes de interactuar con ellos y usar protección antimalware. |
Otros: CloudEye, NJRat, AgentTesla, Mirai, Phorpiex, AsyncRat…
Además, hay algo fascinante en cómo estas tecnologías pueden modelar comportamientos maliciosos. Con las herramientas adecuadas, se puede «entrenar» a una IA para que detecte patrones de ataque emergentes antes de que las fuerzas tradicionales lo hagan. Es como dotar a los investigadores de una lente que amplifica lo invisible, algo especialmente útil cuando se enfrentan a mafias transnacionales que trabajan con recursos casi ilimitados. Y no se trata solo de detección; la IA puede incluso colaborar en la construcción de contramedidas, desarrollando parches y soluciones personalizadas en tiempo récord.
Sin embargo, no todo es prometedor. Existe el riesgo real de que estas tecnologías sean una espada de doble filo. Los mismos algoritmos que facilitan la defensa también pueden ser usados para la ofensiva, ya sea para generar malware más evasivo o para diseñar ataques que burlen herramientas de detección actuales. Y aunque parezca una paradoja, la dependencia excesiva de la IA podría convertirse en un problema. Si se automatiza demasiado, se corre el riesgo de perder el criterio humano, que sigue siendo insustituible en contextos donde la intuición y la experiencia marcan la diferencia.
Por otro lado, la implementación de estas tecnologías plantea desafíos estratégicos. No es suficiente desplegar una IA generativa; también hay que formar a las personas que la manejarán, desarrollar protocolos claros para su uso y establecer marcos éticos sólidos que guíen su aplicación. El análisis de malware no es solo un ejercicio técnico, sino también un campo en el que se cruzan privacidad, legalidad y soberanía digital.
A pesar de todo, la idea de utilizar IA generativa para combatir el cibercrimen organizado no solo es viable, sino necesario. Estas herramientas no reemplazan a los analistas humanos, pero los potencian, les dan la ventaja que necesitan para enfrentarse a amenazas cada vez más rápidas y letales. Es una carrera en la que cada segundo cuenta, y donde la IA podría marcar la diferencia entre contener un ataque o permitir que paralice infraestructuras críticas. En última instancia, el éxito dependerá de cómo se integre esta tecnología en las operaciones y de si somos capaces de equilibrar su poder con la responsabilidad de usarla de forma ética y estratégica.
El 22 de enero se va a celebrar, en la Universidad de Almería, las I Jornadas de Ciberseguridad: Ciberdefensa y Seguridad Nacional. Durante las jornadas se van a debatir asuntos que nos afectan como Sociedad y que impactan severamente en la vida digital que está cada vez más anidada en cada uno de nosotros.
Descubriremos que hay organismos estatales que convierten nuestra protección en su desvelo, pues aunque la red nos da muchas facilidades también es cierto que nos expone sobremanera. Además, conoceremos a las unidades judiciales, tanto de policía nacional como de guardia civil y cómo operan ante los ciberdelitos. No sólo en la labor de investigación sino también en la tarea de comunicar las evidencias y hallazgos a Fiscalía.
Temas tan interesantes como la actividad del Centro Criptológico Nacional, Las actuaciones contraterroristas, el trazado y seguimiento de las criptomonedas, etc… .
Si os interesa, estad atentos porque en breve pondré más información.
Civismo al servicio del olvido: los parques y calles bajo el reinado de los dueños irresponsables de perros
Los parques de nuestra ciudad, otrora espacios verdes y lugares de encuentro, han caído víctimas de un fenómeno que parece desafiar toda lógica: el incivismo canino, o más bien, el incivismo de sus propietarios. ¿Acaso las normativas municipales son meras piezas de papel sin valor alguno?
Según la Ordenanza Municipal de Almería, los propietarios de perros tienen la obligación de recoger las deyecciones de sus animales (Art. 19) y evitar que circulen sin correa (Art. 17). Además, está explícitamente prohibido que estos animales deterioren los jardines y parques infantiles. Pero la realidad dista mucho de la normativa. Las calles y parques están plagados de heces, orines que inundan los alrededores con olores insoportables, y setos que sucumben bajo la acción destructiva de animales fuera de control.
A esto se suma la flagrante falta de cumplimiento de la obligación de censar a los animales y asegurar su correcto control sanitario. Los responsables municipales deberían tomar medidas drásticas: multas ejemplares, campañas de concienciación efectivas y vigilancia activa en los puntos más afectados.
¿Dónde quedó el sentido de responsabilidad? Estos parques no son propiedad privada de quienes tienen perros. Son bienes públicos, y su destrucción es una afrenta directa a quienes disfrutamos de estos espacios con respeto.
Si las normativas no se aplican y los responsables continúan ignorando sus obligaciones, el mensaje será claro: en Almería, ser cívico y cumplir las normas es opcional. Y para aquellos dueños de perros que sí respetan las reglas, ¡gracias por demostrar que el civismo no es una utopía!
El Quijote Digital 