Buscando el “lado oscuro” de los aplicativos cliente/servidor

Carlos Ávila    27 diciembre, 2018
Buscando el “lado oscuro” de los aplicativos cliente/servidor
En la actualidad, cuando se evalúa la seguridad de las empresas, por lo general, dentro de los vectores de ataque, está muy presente por parte de los auditores las tecnologías más actuales como: aplicaciones web, dispositivos de red, aplicaciones móviles, IoT (Internet of Things), VoIP, entre otros. En este artículo, no pretendemos hablar de esas tecnologías, sino más bien enfocarnos en algunas que han existido por mucho tiempo y siguen operando en muchas de las empresas.
 
A las que estamos haciendo referencia es a los aplicativos conocidos como cliente/servidor o también con diferentes nombres –en inglés– como ‘Fat Client’, ‘Heavy Client’, ‘Rich Client’, ‘Thick Client’… Todas, por lo general, siguen una arquitectura cliente servidor. Estos aplicativos son desarrollados ‘in-house’ o por terceros e implementados por las empresas en las estaciones de trabajo de sus usuarios. Por ejemplo, una persona del área de contabilidad hace uso de un cliente instalado en su computador para realizar sus procesos contables que están en frecuente comunicación con el servidor central de este aplicativo.
Hoy en día, en el camino de los procesos de pentesting o evaluaciones de seguridad (dependiendo del enfoque), los auditores se pueden encontrar con aplicativos clientes (instalados en el host del usuario) de tipo ejecutables (DotNet, Java, C, C++, etc.), Applets de java, swf de Flash.
 
 
Estructura de Cliente/Servidor (Bypass Aplicativo Cliente)
Estructura de Cliente/Servidor (Bypass Aplicativo Cliente)
 
Comúnmente se menciona que cada aplicativo instalado en una computadora es un potencial vector de ataque. Aquí mencionamos algunos de estos vectores que podrían analizarse para encontrar debilidades que puedan ser explotadas por un tercero y usarlas para alguna finalidad maliciosa dentro de la red.
  • Análisis de tráfico
  • Decompilación del código
  • Backend (webservices, APIs)
  • DLL Hijacking
  • Archivos de configuración
Durante este año, mis compañeros de laboratorio han escrito una serie de post sobre protecciones de binarios, que sirven como punto de partida para el análisis y control de protección (por ejemplo, contra desbordamiento de buffer) al momento de la compilación del aplicativo. Es por esto, que para motivos de ilustración y que se pueda evidenciar el impacto que podría conllevar el que no hayan sido aplicado controles necesarios, a nivel de la infraestructura, y sobre todo prácticas de desarrollo seguro de software (S-SDLC) en este tipo de aplicativos, hemos definido algunos escenarios con debilidades obtenidas de pruebas en diferentes aplicativos con el fin de ayudar a su entendimiento. 

Escenario De-Compilación:

Usando herramientas de reversing se puede llegar a de-compilar los archivos ejecutables (binarios), en este caso un aplicativo .NET donde se obtiene el código legible y a través de estas técnicas obtener datos “hardcodeados” (credenciales de conexión a DBMS SQL Server).

Decompilacion de Código en Memoria (Aplicativo ClickOnce .NET) imagen
Decompilacion de Código en Memoria (Aplicativo ClickOnce .NET)
 

A través de estos datos un atacante se podría conectar arbitrariamente al servidor SQL y obtener datos de la empresa. Este tipo de datos se podrían usar para escalar privilegios, por ejemplo.

Conexión a la base de datos exitosa con credenciales obtenidas del Aplicativo Cliente imagen
Conexión a la base de datos exitosa con credenciales obtenidas del Aplicativo Cliente

Otro tipo de ataque podría ser algún tipo de ejecutable .jar que se pudiera decompilar, modificar y volver a empaquetar.

Escenario Debilidades en Backends (Webservices/APIs):
En varias ocasiones, este tipo de aplicativos tienen conexión a servidores de base de datos o aplicaciones web (webservices/API). Por esto, es otro potencial riesgo ante ataques más allá del binario; los mismos que podrían mantener debilidades en las vulnerabilidades ya conocidas para aplicaciones web.
 
Análisis y descubrimiento de comunicación con Backend (Webservices) imagen
Análisis y descubrimiento de comunicación con Backend (Webservices)
 
Ataques generados al Webservices (Inyección SQL explotada) imagen
Ataques generados al Webservices (Inyección SQL explotada)
 
Escenario DLL Hijacking:
Mediante este tipo de ataques, un potencial atacante con privilegios más bajos podría usar técnicas de ‘DLL Hijacking’ para que a través del aplicativo cliente, cargar en tiempo de ejecución o sobrescribir los archivos binarios en el directorio de instalación con una copia maliciosa. El aplicativo cliente/servidor ejecutándose en el host de algún usuario podría explotarse para realizar una escalada de privilegios a algún usuario administrador en caso de ejecutarse de esta manera el aplicativo cliente.
 
Detectando potenciales DLL Hijacking en Aplicativo Windows imagen
Detectando potenciales DLL Hijacking en Aplicativo Windows
 
Estos solo son algunos de los escenarios de ataque que podría usar un auditor dentro de un test de intrusión o un atacante para escalar de privilegios dentro de una estación de trabajo o una red corporativa. Se puede observar que los vectores aparentemente son viejos conocidos, pero sin embargo, en varios análisis que hemos realizado de manera aleatoria en la actualidad de ciertos aplicativos de este tipo identificamos varias de estas debilidades que aún persisten.
 
Podemos realizar pruebas a mayor detalle como carga arbitraria de archivos, lógica del negocio, gestión de sesiones, manipulación de registros deserialización de objetos, análisis de memoria y más.  En definitiva, los vectores migran, se actualizan, mejoran y se diversifican, pero los riesgos siempre están presentes a través de cualquier aplicativo dentro de tu red; con lo cual, acerca de las debilidades, ¿te has preguntado cuántos de tus programas cliente has analizado en detalle?

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *