Técnica y herramienta para la obtención de credenciales de usuario del aplicativo SAP
En este artículo se va a hablar del protocolo que usa SAP cuando un usuario se autentica, los fallos de seguridad que presenta, y cómo poder utilizarlo en nuestro beneficio al llevar a cabo una auditoría.
Con el crecimiento de las empresas, surge la necesidad de emplear nuevas herramientas que permiten hacer una mejor gestión del capital, tanto humano, como físico.
Así, compañías como SAP ponen a disposición de otras empresas una herramienta que les permite poder llevar a cabo esta gestión. Aunque hay varios tipos de arquitectura, lo más común es encontrarse una configuración basada en tres niveles (three-tier architecture).
Esta estructura plantea un modelo en el que los clientes (client tier) se conectan a uno o varios servidores (business logic tier), que hacen de mediadores entre el usuario y las bases de datos (database tier), que puede estar distribuida entre varias máquinas.
Dentro de esta distribución se usan distintos protocolos para la comunicación, en función de los activos que tomen parte en ella.
-
- DIAG: se utiliza durante la comunicación entre un cliente y un servidor.
- RFC: es el protocolo que se usa en la comunicación entre servidores.
- HTTP/HTTPS: estándar utilizado para aquellos servicios web que hacen uso de la aplicación, así como del acceso a través de un navegador al aplicativo.
Para este artículo se va a centrar la atención en el primer protocolo, DIAG. Partiendo del escenario propuesto, 3-tier architecture, el proceso (resumido) que se lleva a cabo cuando un usuario hace uso de la aplicación, es el siguiente:
- Los usuarios, a través de la aplicación SAP Logon, se autentican usando su usuario y contraseña, contra servidor 1. En una empresa puede haber varias aplicaciones dentro de SAP (recursos humanos, contabilidad, proyectos…), y que un usuario solo pueda tener acceso a alguno/s de ellos. En este tipo de conexión se utiliza el protocolo DIAG o SAPDIAG.
- Una vez autenticado el usuario, el servidor 1 consulta con el servidor 2 que aloja la base de datos con la información que tiene que mostrar al usuario. Protocolo RFC.
- El servidor 3 devuelve la información solicitada al servidor 1 (que es el que ha realizado la autenticación). Protocolo RFC.
- Se le envía al usuario la información mediante el protocolo DIAG.
En el paso 1, se está enviando al servidor las credenciales del usuario haciendo uso de un protocolo que es propietario de SAP, habiendo hecho su propia implementación. El problema que tiene este protocolo es que aplica un algoritmo de compresión para reducir el tamaño de la petición y, presumiblemente, para ofuscar su contenido. Esto quiere decir que aplicando el mismo algoritmo de descompresión se podría leer el tráfico ya que no está cifrado. Con respecto a esto, se han realizado varias investigaciones que permiten llevar a cabo esta descompresión. El equipo de SecureAuthCorp son los que más han avanzado en este campo. Tienen varias herramientas que son muy útiles a la hora de auditar una organización que cuenta con SAP, siendo una de ellas un plugin de Wireshark, que es del que se va a hablar a continuación.
Para llevar a cabo este ataque, es necesario, o bien que se haga creer a los usuarios que nuestra máquina es el servidor de SAP para que se le envíen las credenciales, o bien se ha vulnerado el equipo de un usuario o un servidor de SAP. No se va a tratar aquí el procedimiento para llegar hasta estos escenarios.
Suponiendo que se ha conseguido vulnerar una máquina de un usuario, se realiza en primer lugar un volcado del tráfico de red que esté intercambiando (en el caso de estar capturando el tráfico en un servidor, cuidado con la cantidad de tráfico que se captura pues se puede puede generar un fichero muy grande en muy poco tiempo llegando a agotar la memoria del disco).
- -I eth0 → se intercepta de la interfaz de red que está usando
- -w output.pcap → se escribe en un fichero para su posterior tratamiento
- dst X.X.X.X → dirección del servidor de SAP
- dst port 3200 → puerto comunmente utilizado en este protocolo. Puede variar, ya que los dos últimos dígitos dependen de la instancia del servidor (3200, 3201, 3202…)
Una vez que se ha capturado una cantidad de tráfico deseada, se importa el fichero al equipo del auditor, donde se procederá a su lectura.
Aunque en el repositorio de github se dan las instrucciones para incluir el plugin en Wireshark, se ha creado un docker para ahorrar tiempo a los auditores. Se puede encontrar aquí.
Una vez se ha instalado, se abre la herramienta, se carga el archivo con el tráfico que se ha capturado y se filtran los paquetes utilizando la siguiente regla:
Si se ha capturado tráfico del protocolo SAPDIAG (el que se está buscando), que contienen (o pueden contener) usuarios y contraseñas, aparecerán varios paquetes al aplicar el filtro, como se puede apreciar en la captura:
Ahora, se selecciona, de las pestañas de abajo, la que se llama Uncompressed Data, y se exploran los paquetes cuyo destino es el servidor de SAP, en busca de las credenciales que se quieren obtener:
De los elementos marcados, el primero indicaría el usuario, y el segundo la contraseña. Esta última, se encuentra precedida por un paréntesis, es importante prestar atención a esto, para no considerar este carácter como uno más de la clave.
Como se ha visto, SAP utiliza por defecto un protocolo de comunicación débil para transportar información sensible. Aunque es posible hacer que el tráfico vaya cifrado, es necesario obtener un componente extra, conocido como SNC y que, aparentemente, requiere de una instalación un poco tediosa.
Esperemos que la rutina y herramienta comentadas, os puedan ser útil en vuestras auditorías. Y si queréis que se hable sobre alguna otra herramienta o aspecto de seguridad de SAP, ponédnoslo en los comentarios.
