Una debilidad rutinaria en una aplicación web se ha vinculado a un compromiso grave de un servidor Windows, después de que unos atacantes utilizaran la inyección SQL para plantar un kit de herramientas de control remoto dentro de una base de datos Oracle.

El incidente demuestra cómo un formulario mal protegido puede convertirse en una vía de acceso desde un sitio web público hasta el sistema operativo que hay detrás.

Los atacantes se dirigieron a una aplicación Java y Tomcat orientada al público y conectada a Oracle.

Al enviar comandos de base de datos a través de una función de búsqueda de autocompletado que no comprobaba correctamente la entrada, lograron que la base de datos procesara comandos y preparara la siguiente etapa de la intrusión.

Investigadores de Huntress identificaron la actividad tras detectar intentos de robo de credenciales de un servidor que alojaba Oracle.

La investigación encontró copias de las colmenas del registro Windows SAM, SECURITY y SYSTEM, material que puede ayudar a un intruso a recuperar hashes de contraseñas y ampliar su acceso.

Huntress afirmó en un informe que el caso es relevante porque el código malicioso no fue colocado primero en el disco como un archivo de malware típico.

En su lugar, fue almacenado y compilado dentro de Oracle, donde podría ser más difícil de detectar para el monitoreo centrado en los endpoints antes de ser utilizado para controlar el host de Windows.

Ocultaron un kit de herramientas de control remoto dentro de Oracle

Los atacantes utilizaron la capacidad de Java embebido de Oracle para crear objetos de fuente Java directamente en la base de datos.

Los comandos enviados a través de la conexión JDBC de la aplicación fueron compilados como objetos de esquema almacenados, convirtiendo la base de datos en un punto de lanzamiento oculto en lugar de simplemente un lugar para guardar datos empresariales.

El kit de herramientas, llamado khunt, incluía componentes para ejecutar comandos de Windows, recopilar nombres de usuario y contraseñas de Oracle, explorar archivos, verificar que el kit estuviera activo y descomprimir archivos.

Este enfoque residente en la base de datos proporcionó al operador herramientas para explorar el servidor sin depender de un único ejecutable malicioso obvio.

Un componente abrió un shell de comandos y ejecutó un comando para identificar al usuario actual.

Este devolvió permisos de nivel SYSTEM, confirmando que el atacante había pasado del acceso a la base de datos al control del sistema operativo, un riesgo también ilustrado por la amenaza de RCE de Windows Netlogon que enfrentan los entornos de servidores expuestos.

La actividad pasó entonces a la recopilación de credenciales. El intruso utilizó utilidades de Windows para copiar colmenas del registro y enumeró los servicios en ejecución, creando archivos en el directorio de Oracle que podían ser extraídos para análisis offline. Robos similares de credenciales en colmenas del registro pueden revelar credenciales de cuentas locales.

El acceso inicial provino de una inyección SQL, no de un fallo de software recién revelado. Esa distinción es importante porque centra la atención en el diseño de la aplicación y los permisos de la base de datos, no solo en la aplicación de parches.

Cerrando la vía de la base de datos al servidor

Debes revisar cada formulario público y campo de búsqueda que pueda llegar a una base de datos, especialmente las funciones heredadas que pueden pasarse por alto durante las pruebas.

La entrada debe ser saneada y las consultas de la base de datos parametrizadas para que el texto suministrado no pueda ser interpretado como SQL ejecutable, una salvaguarda básica contra el tipo de validación incorrecta vista en el fallo de Windows Active Directory. Las cuentas de la base de datos también necesitan el conjunto más pequeño de derechos prácticos.

Una cuenta utilizada por una aplicación web no debería poder crear objetos de fuente Java, ejecutar procedimientos almacenados sensibles o ganar un acceso amplio al sistema operativo, limitando el daño incluso cuando un error de inyección se filtre. Como defensor, debes mirar más allá de los escaneos de archivos ordinarios al investigar servidores Oracle.

Buscar clases Java inesperadas en los objetos de la base de datos, revisar los envoltorios PL/SQL y comprobar los registros web y SQL en busca de comandos inusuales puede exponer actividades que las herramientas de endpoint podrían pasar por alto; también debes mantenerte al día con las actualizaciones de seguridad de Microsoft de junio para los sistemas Windows que soportan estas cargas de trabajo.

La infraestructura del atacante y los nombres de los artefactos reportados brindan pistas prácticas a los respondientes de incidentes para la búsqueda de amenazas.

Tu revisión debe priorizar los archivos inusuales creados por Oracle, los objetos de base de datos inesperados y las señales de que oracle.exe generó herramientas de línea de comandos o del registro; luego, aísla los sistemas afectados y restablece las credenciales si el material de credenciales pudo haber sido copiado, y conserva los registros relevantes para una revisión forense completa antes de reconstruir la confianza en el host.