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.
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 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 |
