Multipath Reliable Connection (MRC): Un protocolo de red diseñado para los LLMs

Este fin de semana he estado leyendo sobre este nuevo protocolo de red creado especialmente para resolver el problema de la congestión del tráfico de red que se produce en los mega-datacenters utilizados para entrenar los nuevos LLM cuando se mueven datos de GPU a GPU en los centros de datos. En estos casos, estamos hablando de interconexión de datos entre clusters que pueden contener centenares de miles de GPUs, por lo que los protocolos que envían los datos por la red son críticos en la reducción del tiempo de entrenamiento, mediante una reducción de la latencia de envío de paquetes de red y, por consiguiente, reducción del consumo de energía. 

Figura 1: Multipath Reliable Connection (MRC).

Un protocolo de red diseñado para los LLMs

MRC está creado específicamente para resolver esos problemas, y ha sido publicado en el paper de Open Compute "Multipath Reliable Connection (MRC) Specification" donde equipos de OpenAI, Microsoft, NVIDIA, Broadcom y AMD han estado trabajando para definir el nuevo protocolo que ya han puesto en producción en los clusters de entrenamiento de OpenAI y Microsoft, incluidos centros de datos de entrenamiento de Oracle.

Figura 2: Multipath Reliable Connection (MRC)

El protocolo MRC se basa en RoCEv2 (RDMA over Converged Ethernet v2), es decir, que sigue aprovechando las capacidades de RDMA (Remote Direct Access Memory) para enviar tráfico por la red de computador a computador desde la memoria de uno hasta la memoria de otro sin pasar por la CPU utilizando RoCEv2, que está diseñado especialmente para las redes Ethernet.

Figura 3: La red es el punto de congestión de los mega-datacenters

Sin embargo, en entornos de alta congestión - como es el de entrenar un LLM de frontera en un datacenter con cientos de miles des GPUs pasándose datos - , es que la red necesita una arquitectura de capas (Tiers) para conectar switches, de tal manera que dependiendo de la distancia física que exista entre las GPUs que se pasan los datos, hay que atravesar muchas capas de Switches de interconexión, y es ahí donde se produce la congestión. 

Figura 4: La propuesta de OCP es MRC con Packet Spraying

Para resolver esto, la solución es ampliar el número de capas, ampliando la latencia, para que existan más rutas posibles, lo que tampoco es una solución perfecta. Lo que propone MRC es utilizar Packet Spraying, es decir, dividir los datos que se van a enviar en pequeños paquetes de red que utilizarán, cada uno de ellos, una ruta diferente dentro de las rutas posibles.

Figura 5: Arquitectura en Tiers de Switches

Para eso es necesario conocer el estado de calidad de la red, los puertos disponibles, y poder crear una ruta para cada paquete de la red. Esto se hace con un protocolo llamado  SRv6 (Segment Routing over IPv6) que se encarga de crear la ruta para cada paquete dentro de la estructura de Tiers de los Switches de interconexión. 

Figura 6: Control de Congestión con QPCP

La especificación completa, donde se definen los estados de los protocolos de control de la congestión y calidad de la red en cada momento QP Congestion Protocol (QPCP) están todos correctamente descritos en la especificación, ya que se trata de un protocolo abierto, y tienes el paper académico de Resilient AI Supercomputer Networking using MRC and SRv6 con las pruebas realizadas publicado.

Figura 7: Resilient AI Supercomputer Networking using MRC and SRv6

Este es un ejemplo de cómo la necesidad de innovar con Inteligencia Artificial está impulsando la innovación en otras áreas adyacentes de forma masiva, como es la gestión de la energía, los protocolos de red o la gestión de grandes volúmenes de datos. 

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Un "Hardening Tip" de BBDD - de mi Lost & Found - contra las "Heavy Queries Malignas"

Hace muchos años, cuando estaba trabajando en mi Ph.D en los Time-Based Blind SQL Injection using Heavy Queries, en uno de mis documentos de la universidad escribí sobre las técnicas de "hardening" para dificultar este tipo de ataques y lo tenía preparado en un post, pero lo fui dejando sin sacar, y un día me olvidé de publicarlo, hace unos quince años más o menos.

Figura 1: Un "Hardening Tip" de BBDD - de mi Lost & Found -

 contra las "Heavy Queries Malignas"

Sin embargo, hablando sobre las capacidades de usar ChatGPT, Claude o Gemini para investigar en ciberseguridad, y lo fácil que hubiera sido construir las diferentes Heavy Queries para explotar un bug de SQL Injection usando una técnica Time-Based, me he acordado con él, y se lo he preguntado directamente a Gemini.

Figura 2: Whitepaper de "Time-Based Blind SQL Injection using Heavy Queries"

Por supuesto, de las técnicas de Time-Based Blind SQL Injection using Heavy Queries, hablé en el libro de "Hacking de Aplicaciones Web: SQL Injection", mientras que de las técnicas de LDAP & Blind LDAP  Injection in Web Applications,  y Connection String Parameter Pollution hablé en el libro de "Hacking Web Technologies".

Figura 3: Libro Hacking de Aplicaciones Web: SQL Injection
de Enrique Rando y Chema Alonso

Pero hoy en día, encontrar estas técnicas es tan fácil cómo preguntarle a los modelos, que ellos ya se han aprendido todos los papers, por ti, así que, preguntándole por ayuda para localizar si me han hecho un ataque a un aplicación web con un Microsoft Access 2003, obtienes rápidamente la información de sobre este ataque con Heavy Queries.

Figura 4: La tabla del sistema a explotar en Access 2003

Como podéis, ver, rápidamente nos hace el análisis de la tabla del sistema a explotar, y nos dice que la forma de explotarlo es usando Join de ella misma ene veces, tal y como explicamos en el paper, para lograr un volumen de datos tan grande que generar un delay medible. 

Figura 5: El método para explotarlo

Y por último, nos da la inyección completa que se puede utilizar para hacer el Time-Based Blind SQL Injection Using Heavy Queries, lo que genera la explotación completa de la vulnerabilidad. 

Figura 6: Inyección completa tipo Time-Based Blind SQL Injection using Heavy Queries

El resultado es que en un segundo puedes encontrar cómo hacerlo, y no ha habido que hacer ningún Jailbreak ni nada por el estilo, así que vamos a ver ahora la parte de fortificación de la que os he estado hablando.

Figura 7:"Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment"

escrito por Chema Alonso con la colaboración de Pablo González, Fran Ramírez,  Amador Aparicio, Manuel S. Lemos y José Palanco en 0xWord

Si vamos ahora a las protecciones, primero hay que entender por qué sigue siendo importante tener protecciones contra esta forma de explotar la base de datos, generando una Heavy Query. Estas técnicas se pueden usar para hacer un DoS o para extraer información de la BD, especialmente en motores que no tienen funciones de tiempo, o en entornos bajo WAF que están filtrando las queries.

Figura 8: Por qué sigue siendo importante esto

Y aquí viene el Hardening "Tip" del pasado, que no saqué en ninguno de los blog posts que escribí sobre ello, que consiste en que una vez construida la consulta, se pueda comprobar que la consulta tiene un Time-Out acorde con el tipo de Query que se está lanzando.

Figura 9: Poner un límite de tiempo a las consultas SQL

Por supuesto, usar consultas parametrizadas, detectar el tipo de los datos que se inyectan en los parámetros y no construir consultas concatenando strings es la clave, pero que una aplicación pueda vulnerar el rendimiento de la aplicación y de la propia base de datos por no controlar los límites de consumo de recursos de una consulta SQL es fundamental.

Figura 10: Límite temporal a nivel de TRANSACCIÓN en PostgreSQL

Para ello, en los diferentes motores de Bases de Datos existen formas de controlar el máximo tiempo que se va a permitir en ejecución una consulta, que es de lo que estuve escribiendo hace quince años, pero aquí tenéis, preguntándole a Gemini, la fácil que es limitar estos tiempos.

Figura 11: Límites en MySQL versiones 5.7.8+

Por supuesto, si no hay SQL Injection, no hay necesidad de tener esto, pero lo cierto es que esta protección se puede añadir no sólo a nivel de aplicación, sino también a nivel de DBFirewall, a nivel de Driver de conexión, o incluso como hacíamos con los ataques a nivel de red haciendo un Network Packet Manipulation con un Man-in-the-middle.

Figura 12: En Transat-SQL a nivel de Server,

a nivel de Conexión y a nivel de Query

Hay que tener en cuenta que en una arquitectura de Zero-Trust, la base de datos no debe fiarse nunca de las aplicaciones, así que, al igual que hacíamos con el Paranoid Mode para evitar las manipulaciones en bases de datos por parte de ataques de SQL Injection, controlar el consumo descontrolado de recursos es fundamental.

Figura 13: Controles en Oracle a nivel de SESSION y con Perfiles

Al final, si eres responsable de una base de datos de alto rendimiento, con muchas aplicaciones colgando de ellas, limitar el consumo de recursos lo puedes hacer preventivamente - evitándolo con límites - o reactivo, viendo qué está comiéndose la memoria y la CPU de la base de datos.

Figura 14: Límites en Access 2003 y SQLite

Ya os conté muchas veces que en la universidad yo me especialicé en Bases de Datos, que me encantaban, y que mis primeros trabajos tuvieron que ver con Tuning de bases de datos Oracle y de aplicaciones que corrían sobre ellas, así que estas cosas las tenía muy presentes cuando comencé con el trabajo de Time-Based Blind SQL Injection Attacks using Heavy Queries.

Figura 15: Resumen de posibilidades

Esta es una buena práctica de seguridad, sobre todo si eres de los que gusta tener los entornos Hardened in Paranoid Mode, así que si no la conocías o no lo estás aplicando, a lo mejor encuentras un punto donde tener estos controles y evitas estos ataques.

Figura 16: Por qué es útil esto

Lo cierto, que es a lo que iba la conversación inicial, es que esto que dejé a medio escribir hace quince años como un post, tenía que actualizarlo para ver cómo se establecen los límites temporales en todas las bases de datos, y en todos los puntos posibles, pero gracias a la existencia de los LLMs hoy en día, ha sido tan fácil como pedirle a Gemini que me lo dé, por eso os lo he compartido hoy y he borrado una tarea del pasado que tenía en mi To-Do.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

El amo de los datos

Ayer tuve una jornada interesante de transformación digital en Londres. Hablando de datos, ML, GenAI, arquitecturas RAG, y normalización de datos. Cosas habituales hoy en día en cualquier empresa. En uno de esos momentos en los que estaba escuchando, sobre casos de uso que que se iban a crear usando ML, el debate acabó una vez en los datos. El Catálogo, el Data-Fabric, el Data Wharehouse, Data Curation, la validación de la ingesta, los Data Streams, etcétera. Cosas habituales en la vida de la digitalización de empresas.

Figura 1: El amo de los datos

Para mí, eso fue el día a día cuando en al año 2016 tuve la responsabilidad de ser el Chief Data Officer de Telefónica y tuve que tomar muchas, muchas, muchas decisiones sobre estos temas que, a día de hoy que soy el Chief Digital Officer, siguen perdurando en nuestro trabajo diario. 

Estando en ese debate, mi cabeza viajo temporalmente a mis inicios con los datos. Cuando bajaba la calle Barcelona de Móstoles, pasaba por delante del Eco Móstoles, y me metía en un pequeño parque a medio terminar que se encontraba y se encuentra a espaldas de calle Libertad de Móstoles. Allí estaba uno de los locales de la Academia RUS de la que os he hablado muchas veces. Tendría yo 14 o 15 años e iba a mi clase de Informática diaria. A seguir aprendiendo a programar.

En aquellos años ya había dejado el BASIC y el Logo atrás, y estaba con con COBOL, SQL y MS/DOS. También tocaría aprender DBASE, C y Pascal, pero antes de ellos, mi paso era hacer códigos con la IDENTIFICATION DIVISION y la PROCEDURE DIVISON. Había que aprender a identar el código, usar muchas mayúsculas, y ser muy disciplinado en la forma de hacer programas con este lenguaje llamado COBOL.

Las clases a las que asistía de informática se multiplicaban en mi agenda, normalmente hacía tres cursos a la semana diferente, haciendo clases los lunes y miércoles, y los martes y jueves, y repitiendo algunas de 17:30 a 18:30 y de 18:30 a 19:30, y luego había algunos cursos que se daban los viernes y sábados. De los 12 a los 16 años fueron años en los que mi afición era programar, así que no me importaba pasarme dos horas cada día en la academia, e incluso quedarme los viernes y sábado. ¿Qué podría haber más divertido que eso? Además, de vez en cuando daba yo la clase, y me llevaba de maravilla con Bea, mi profesora muchos de esos años.

Nada de lo que aprendí en aquellos años fue en vano. Todo ese aprendizaje sigue en mí, cambiado, adaptado, y mejorado, pero como base sobre la que construí mucho de mi conocimiento futuro. Y ayer me acordé de la época de COBOL y el acceso a Datos para hacer cosas. En aquellos momentos, cuando pasé de BASIC a COBOL, entré en el mundo de las reglas de estilo y la programación estructurada con técnicas de diseño de software muy metódicas. Formas de hacer las cosas de manera industrial. El trabajo de programador como factoría de software. Dados unos requisitos, escribir código como si fueras una máquina tú.

Los programas de gestión, hechos con COBOL y datos almacenados en bases de datos o ficheros tenían siempre las mismas estructuras. Y todos mis primeros Menús eran siempre ALTAS, BAJAS, MODIFICACIONES y CONSULTAS. Tendía que definir las fuentes de datos, los tipos de datos que iba a utilizar, si eran ficheros, los accesos que serían Secuenciales (si eran en cinta), acceso aleatorio (si eran en cintas modernas con aceleración de rebobinado y avanzado) o de acceso directo (si el almacenamiento era en disco). O los tipos de datos que se iban a leer de las bases de datos, en forma de registros que había que procesar,  pintar por pantalla en listados, etcétera.

La programación era una ingeniería. Las cosas tenía una forma de hacerse. Había metodologías de desarrollo de software. Hablábamos de los modelos de solucionar cada uno de los problemas. Y teníamos guías de estilo de programación, nombres de variables, llamadas a procedimientos, factorización del software, etcétera, para hacerlo mantenible, aduitable, y permitir que cualquier código fuera tocado por cualquier programador de COBOL. Me encantaba saber que era una pieza de parte de una industria de desarrollo de software. Podría ser programador o mi sueño entonces, ser "Analista", para poder asignar las tareas a los programadores siguiendo las guías de desarrollo del software de una empresa. 

Podéis imaginaros lo que un niño de 14 o 15 años sentía cuando se veía ahí. Siento un analista de software. Metiendo líneas de código y jugando con los decimales como Richard Prior en Superman III, desde tu terminal. Identando tu código. Flipante.

Y os cuento todo esto, porque de aquella época también aprendi parte de la gestión de los datos que décadas después usé como Chief Data Officer en Telefónica. Y es que, allí, en aquellos años, me explicaron cómo la Banca creaba sus aplicaciones para preservar sus datos. Cómo los informáticos habían creado para COBOL una metodología de trabajo con datos basada en mantener el core más sagrado de la empresa, LOS DATOS, a salvo de malos programadores. Metiendo una capa de seguridad, metiendo una capa de protección. 

Y yo escuchaba atento. ¿Cuál sería el truco? ¿Cómo lo han hecho? ¿Cuál es el secreto?

No había mucha magia. O sí. Según se mire. 

Lo habían hecho otros informáticos que llegaron a interesarme tanto o más que los Analistas, se trataba de tipos más duros aún. Que tenían más poder porque protegían el activo más valioso de las empresas. De la poderosa industria bancaria. Los datos, que al final de día era dinero. Se trataba de los Administradores de Bases de Datos.

¡¡Buaahhh!

¡Qué pasada!

Resulta que había unos tipos que para que los Analista de Programación pudieran diseñar sus programas de ALTAS, BAJAS, MODIFICACIONES y CONSULTAS, con sus infinitos listados por pantalla y por impresora (no conté yo espacios ni nada para cuadrar listados en papel continuo de impresoras matriciales), estos Analistas tenían que hablar con los Administradores de Bases de Datos para que les disponibilizaran los datos que necesitaban utilizar para sus programas. Y ellos decidían cómo lo hacían.

Esto, tenía su ciencia. Porque no iban a dejar que cualquier Programador tocara cualquier dato, así que se dedicaban a crear VISTAS, VISTAS para Actualización de datos, y Tablas de solo lectura que disponibilizaban a los Analistas para que hicieran su aplicación de ABMyC sobre estas fuentes de datos. Los Analistas repartían las tareas a los Programadores, y la Factoría de Software de la empresa seguía produciendo sistemas de información para la empresa.

Si habéis leído esto, sabréis porque cuando llegué a la Universidad me centré en aprender todas las asignaturas de Bases de Datos. A aprender a hacer el diseño lógico y el diseño físico de las bases de datos. A aprender cómo funcionaban los Tablespaces, las p-codes de las consultas de bases de datos, a descubrir los detalles de las formas normales de Boyce-Codd, a aprender PL/SQL, T-SQL, hacer optimización de bases de datos y aplicaciones, etcétera. El resto, ya os lo sabéis, trabajé mucho con las bases de datos Oracle cuando salí de la Universidad, luego llegó el SQL Injection... y el resto es historia moderna, desarrollando mi perfil profesional en datos y hacking.

Pero ayer volví a ello una vez más, porque el debate nos llevaba a cómo preservar los datos y disponibilizarlos a los modelos. Hoy hablamos de Data Streams, de Gestores de Consentimientos para acceso a datos, de políticas y procedimientos de anonimización y pseudoanonimización, de consultas con algoritmos de cifrado homomórfico, de roles de seguridad, de las plantillas de cumplimiento regulativo, etcétera. 

Entonces, el Administrador de la Base de Datos era el "amo de los datos" y de todo eso. Y yo lo aprendí en una academia de barrio de Móstoles. Leyendo libros y deseando un día poder ser parte de esa Industria y la Ingeniería del Software. Flipante.  

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

La década de Yahoo! en el trono de la Web

El otro día vi un vídeo de esos que hacen estadísticas sobre todo, aprovechando los datos de webs como Statista, y me sorprendió ver lo que mostraba. Se trataba de ver el TOP 10 de webs con más tráfico desde el nacimiento de Internet hasta hoy en día. Los datos se muestran mes a mes y pensé que no me iba a sorprender lo que viera, pero.. sí, sí que me sorprendió.

Figura 1: La década de Yahoo! en el trono de la Web

Saber que Yahoo! había sido el WebSite con más tráfico no era algo nuevo para mí. Estuve invitado a la Yahoo! Security Week allá por el año 2009 y pude conocer de primera mano mucha de la grandeza de esa compañía. Según los datos, alcanzó el número 1 de los WebSites más visitados en el año 2.000. En Junio del año 2.000. Cuando yo cumplía 25 años. 

Está claro que Yahoo! es la ganadora de la llamada época de las ".COM", donde los portales horizontales y verticales comenzaban a inundar la red. Portales de contenido. Contenido creciendo de manera exponencial. Y como consecuencia, los buscadores, para que los usuarios llegaran de la forma más rápida a la información más precisa.

Figura 2: Top 10 de Junio de 2002

De aquella época de las .COM, con las arquitecturas de aplicaciones de tres capas, que venían con sus servidores de base de datos Oracle, sus servidores de aplicaciones en entornos como BEA WebLogic con frontales HTTP/S, y sus servidores SUN Microsystems. Una época donde las empresas ganadoras parecían auténticos monstruos que iban a ser los reyes durante mucho tiempo.

Lo cierto es que en aquella época, los datos de tráfico web son bastantes "pequeños" comparados con los que tenemos hoy en día. En aquellos momentos aún no había llegado la movilidad, no habían llegado las apps, y las nuevas formas de utilizar Internet. Lejos estaba la Web 2.0 aún. Estábamos en ".COM", a los pocos años de haber nacido la World Wide Web.

En el año 2006, justo en los albores de la Web 2.0 y la llegada masiva de la movilidad, de iPhone, el 3G, y las redes sociales con clientes móviles, Google consiguió adelantar un mes en tráfico a Yahoo!, pero volvió a ponerse por delante, y en Junio de 2006, Yahoo! estaba otra vez en al cabeza. Ya no hablábamos de .COM. Ya Sun Microsystems no era tampoco la empresa que había sido antes. Y tampoco la forma de hacer aplicaciones. 

Figura 3: Top Ten en Mayo de 2006

Ya no hablábamos de arquitecturas en tres capas, sino de BigData, de High Perfomance Computing, y los albores del Cloud Computing. Acababa de nacer apenas unos meses atrás AWS, proponiendo una nueva forma de hacer aplicaciones escalables, además de ver que el interfaz web iba a dar cada vez más paso al Internet móvil. Pero Yahoo! aguantó en la web.

Figura 4: Top Ten en Junio de 2010

Y aguantó hasta el año 2010. Junio de 2010 y Yahoo!, ya con números de 11.5 B de usuarios por mes, seguía aguantando a Google en la cabeza de lista. Ya estaba, como podéis ver, Facebook, Amazon, Youtube y Google, apretando los números.  Y desde ahí, Yahoo! ha ido perdiendo tráfico. 

En Enero de 2022, el Top 5 lo forman Google, Youtube, Facebook, Twitter e Instagram. Y Yahoo! aguanta con 3.5B , mucho menos de lo que llegó a ser, peleando por no ser adelantado por XVideos, y sobre todo teniendo en cuenta que Google va por 90B de usuarios mes. Un crecimiento brutal.

Figura 5: Top Ten en Enero de 2022

Sin embargo, el mundo ya no es "Web", ya hay mucho mundo móvil, donde otras plataformas como TikTok tienen mucho que decir en el mundo móvil, o con mundos virtuales que cierran el tráfico en sus apps, o con los nuevos mundos virtuales descentralizados que comienzan poco a poco a crecer. Hay que tomarse esta gráfica como lo que es, una simple visión puntual reflejo de un cambio, que no es todo lo que ha pasado en estos años, pero sí que es reflejo del cambio continuo y agresivo de esta era digital en la que vivimos, donde las revoluciones duran... unos años.

Al final, este artículo solo es un recordatorio para ver que cuando llegan los cambios tecnológicos, luchar con el éxito es un problema para todas las empresas. Los ganadores de la Web, de las .COM, o de la Web2.0 no tienen porque ser los ganadores en esta nueva evolución. Ya veremos.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Apúntate al OpenExpo Business Live: Cloud Day 2022 para el próximo 24 de Febrero

El próximo 24 de Febrero, los compañeros de OpenExpo Europe han organizado la jornada OpenExpo Business Live: Cloud Day 2022 que es 100% gratuita y online (solo debes registrarte aquí) con conferencias y mesas de debate para tratar temas de gran interés, como el uso de la Cloud en la Administración Pública, el uso de Cloud para Startups, Entrepeneurs & Developers, el uso de soluciones PaaS vs. IaaS, o el funcionamiento de bases de datos como MySQL en la nube.

Figura 1:  Apúntate al OpenExpo Business Live: Cloud Day 2022

para el próximo 24 de Febrero

La jornada es 100% gratuita y online, y esta formada por tres ponencias y dos mesas de debate. que os paso a contar a continuación en detalle, pero tienes aquí la agenda con horarios completa, que también puedes ver en la web del evento.  La primera sesión será una ponencia a las 16:05 a cargo de Nacho Fernández, que es Business Development Manager para SMB Partners & Products en Arsys y que hablará de "Cloud Services: el camino hacia la Nube".

Figura 2: El camino hacia la nube por Ignacio Fernández

La primera mesa de debate cuenta con la presencia de ponentes de la talla de María Álvarez, Responsable de Políticas Públicas y Relaciones Gubernamentales de Google, Gema T. Pérez Ramón, Directora de la Agencia Tributaria de Madrid del Ayuntamiento de Madrid, Jorge Bermúdez, Fiscal experto en ciberseguridad de la Fiscalía General del Estado y Sofía Fernández Vázquez, Jefa de Gabinete del Área Delegada de Innovación y Emprendimiento del Ayuntamiento de Madrid, para la primera mesa de debate.

Figura 3: Mesa de debate de "Cloud Computing para las administraciones

públicas por transformación digital"

Después tendremos a Matias Sosa, que es Cloud Specialist & Product Marketing Manager en OVHCloud, que dará una ponencia donde hablará de "¿Por qué adoptar soluciones PaaS en Cloud?" Algo que suele significar procesos de re-ingeniería de aplicaciones, productos y servicios pero que tiene sus ventajas, ya que se aprovecha de las principales capacidades de la tecnología de Cloud Computing.

Figura 4: ¿Por qué adoptar soluciones PaaS? por Matías Sosa

Posteriormente contaremos con una mesa de debate de Cloud Native Developed Business Apps en la que contaremos con Ignacio Melero, que es Azure Developer Technical Lead en Microsoft, Daniel Suarez, que es el CEO de Zapiens.ai, Estela Gil Berlinches, consultora especialista en eCommerce, Marketing Digital y SaaS, y Gabriel Cuesta Arza, que es el CIO/CTO en Mobius Group.

Figura 5: Mesa de debate "Cloud Native Developed Business Apps"

Y para completar la jornada, tendremos una sesión de Vittorio Cioe, que es Principal Solutions Engineer de MySQL Oracle, que hablará de "Cómo crear soluciones preparadas para el futuro con MySQL Database Service y HeatWave". 

Figura 6: Ponentes del Cloud Day 2022 en MyPublicInbox

Además, el evento estará presentado por Beatriz Cerrolaza, CEO de Alise Devices y MyPublicInbox, junto con Andrea Andrade, Marketing Communication Manager en OpenExpo Europe. Por último, recordarte que para poder asistir, solo debes reservar tu plaza registrándote en el OpenExpo Business Live Cloud Day 2022, y si quieres comunicarte con los ponentes, puedes hacerlo a través de MyPublicInbox, que están accesibles en https://mypublicinbox.com/publicprofiles/CloudDay2022

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Y de tu SAP a conocer tu motor de Bases de Datos

Llegar al Sistema Gestor de Bases de Datos (SGBD) en cualquier proceso de Ethical Hacking es fundamental. Ahí están los datos y suele ser la pieza más preciada. Si un atacante consigue llegar y acceder con privilegios se verían afectados los pilares de la seguridad: La confidencialidad, la Disponibilidad y la Integridad. En otro día vimos en un artículo cómo es posible descubrir la infraestructura SAP de una organización, y hoy vamos a ver cómo continuar para descubrir dónde está el SGBD que utiliza el sistema SAP de una empresa gracias a un componente fundamental en los entornos SAP: el ICM (Internet Communication Manager), responsable de la comunicación del sistema SAP con Internet mediante los protocolos HTTP, HTTPS y SMTP.

Figura 1: Y de tu SAP a conocer tu motor de Bases de Datos

Todos los sistemas SAP utilizan un Sistema Gestor de Base de Datos Relacional (SGBDR) donde mantienen centralizada la casi totalidad de la información manejada por este software de gestión (información de clientes, pedidos, proveedores, etcétera). Dada la naturaleza de esta información, lo lógico es que este SGBD se encuentre en la red interna de la empresa y sólo desde allí se admitan las peticiones a las bases de datos.

Figura 2: Arquitectura del sistema que recibe las peticiones desde Internet

En este artículo se veremos cómo, aprovechándonos de una mala configuración en el ICM del sistema SAP, en ocasiones, es posible conocer el tipo de SGBD es utilizado por el sistema, parte del direccionamiento interno de la empresa donde se encuentra el SGBD, así como el sistema operativo que corre en el host del servidor de bases de datos.

Módulo sap_icf_public_info

Para descubrir el SGBD del sistema SAP de una empresa, puede usarse el módulo sap_icf_public_info de Metasploit disponible en el GitHub de la empresa Rapid7.

Figura 3: Información del módulo sap_icf_public_info en Metasploit desde Kali Linux

Lo que hace este módulo es aprovechar parte de la configuración por defecto del componente ICM, para que éste pueda reenviar peticiones HTTP/S a un recurso XML que guarda la información sobre el SGBD usado en el sistema SAP, versión del sistema operativo del host sobre el que corre el servidor de base de datos, direccionamiento IP interno, etcétera.

La configuración del módulo es muy es sencilla, ya que la mayoría de las veces basta con indicar el en parámetro RHOSTS la dirección pública del sistema SAP expuesto en Internet (set RHOST 200.x.x.x). Por defecto, el módulo realizará peticiones HTTP al puerto 8000/TCP del sistema SAP.

Figura 4: Configuración del módulo sap_icf_pulic_info 

Descubriendo los Sistemas Gestores de Bases de Datos

Tras lanzar el módulo, observamos que devuelve información sobre un SGBD, en este caso Oracle, el nombre del servidor de base de datos, sappbobd, el nombre del host sobre el que corre, sapboci, así como la dirección IPv4 interna que tiene asignada, 192.168.241.40. Además, el sistema operativo es un SunOS.

Figura 5: Información de un SGBD Oracle y el host en el que corre

En este otro caso, tenemos que el SGBD es MSSQL de Microsoft, el nombre interno del servidor de base de datos es SVRPROERP\PRD, el nombre del host es SRVPROER y el sistema operativo es un Windows NT.

Figura 6: Información de un SGBD MS SQL Server del Host en que corre

En este otro ejemplo, tenemos que el SGBD es un DB/400 de IBM, el nombre del host y del SGBD coinciden, sapprod, el sistema operativo sobre el que corre el SGBD es OS/400 de IBM.

Figura 7: Información de un SGBD DB/400 de IBM y el host en que corre

Análisis del tráfico de red generado por el módulo

Siempre que se lanza un módulo en Metasploit es interesante capturar y analizar el tráfico de red que genera, ya que puede proporcionarnos más información que la meramente devuelta por el módulo. Descubrimos que el módulo sap_icf_public_info realiza una petición por GET vía HTTP de un recurso XML cuya URI es /sap/public/info.

Figura 8: Flujo TCP de la petición realizada al sistema SAP

Dado que es una petición bajo el protocolo HTTP, conociendo la URI (/sap/public/info), la dirección IP del sistema SAP y el puerto TCP que recibe la petición, es posible construir la URL completa y acceder al recurso XML directamente desde un navegador web.

Figura 9: Resultado de la petición generada desde un navegador web

Conclusiones

Para evitar este tipo de fugas de información del sistema SAP y evitar que sea indexada por los principales motores de búsqueda, bastaría impedir que el componente ICM realice la petición del recurso XML directamente desde Internet mediante el protocolo HTTP, permitiendo las peticiones únicamente desde la dirección 127.0.0.1 de localhost o indicando qué hosts son aquellos que sí tienen permiso para consultar la información del recurso XML.

Figura 10: Zona de la configuración de los hosts con acceso al recurso XML

Autor: Amador Aparicio de la Fuente (@amadapa)
Escritor del libro "Hacking Web Technologies"