CVE-2018-3110: Una vulnerabilidad en Oracle Database se da a conocer

Otro día, otra vulnerabilidad que necesita ser parcheado tan pronto como sea posible. Oracle ha informado de un fallo de seguridad que afecta a las versiones de bases de datos Oracle 11.2.0.4 y 12.2.0.1 se ejecuta en Windows.

Oracle ha lanzado una alerta de seguridad para abordar una vulnerabilidad en múltiples versiones de Oracle Database que podría permitir a un atacante remoto tomar el control de un sistema afectado. Waratek no ofrece actualmente un parche virtual para CVE-2018-3110, pero el Arquitecto de Seguridad de Waratek, Apostolos Giannakidis, ofrece orientación sobre cómo abordar esta vulnerabilidad de nivel crítico. El fundador y CTO John Matthew Holt también ofrece sus ideas en una sesión de preguntas y respuestas a continuación.

Acciones recomendadas

Waratek está de acuerdo con la recomendación de Oracle de que los usuarios de los productos impactados de Oracle Database tomen medidas inmediatas. CVE-2018-3110 afecta el componente JVM del servidor de base de datos de Oracle en las versiones 11.2.0.4 y 12.2.0.1 en Windows y la versión 12.1.0.2 en Windows y la base de datos Oracle en Linux y Unix.

La primera acción debería ser desactivar / eliminar OJVM del RDBMS, si no es necesario. Si es necesario, considere las siguientes acciones:

• Establecer la política de contraseña de la base de datos también impone la complejidad de la contraseña (consulte la publicación especial NIST 800-63B, Apéndice A ).

• Tome medidas adicionales para fortalecer el sistema:

  • La vulnerabilidad es explotable por atacantes de bajo privilegio que tienen el privilegio "Crear sesión". Por lo tanto, los administradores deben revisar los privilegios que se han otorgado a los usuarios de la base de datos y revocar el privilegio "Crear sesión" de los usuarios que no lo requieren. Las organizaciones deben considerar revocar este privilegio de todos los usuarios hasta que se aplique el parche. Tenga en cuenta que esto podría causar problemas de funcionalidad.

  • La vulnerabilidad es explotable por los usuarios que tienen acceso a la red a través de Oracle Net. Por lo tanto, los clientes de Oracle deben revisar qué usuarios tienen acceso a la red a través de Oracle Net y revocar el acceso de los usuarios que no requieren dicho acceso.

  • El tráfico de los usuarios que requieren acceso a la red a través de Oracle Net debe ser monitoreado y examinado para detectar actividad irregular.

  • Verifique que los usuarios de la base de datos tengan los permisos de seguridad de Java2 apropiados y los privilegios de la base de datos para acceder a los recursos almacenados en la base de datos (consulte Seguridad de las aplicaciones Java de la Base de Datos Oracle ). Estos recursos incluyen:

    • Recursos de base de datos, como tablas y paquetes PL / SQL

    • Recursos del sistema operativo, como archivos y sockets

    • Clases Oracle JVM

    • Clases cargadas por el usuario

  • Supervise la actividad del oyente de la base de datos Oracle para las alertas generadas.

  • Auditar actividades sospechosas comunes. Las actividades sospechosas comunes son las siguientes:

    • Usuarios que acceden a la base de datos durante horas inusuales

    • Varios intentos fallidos de inicio de sesión de usuario

    • Intentos de inicio de sesión por usuarios inexistentes

• Asegure y endurezca el sistema operativo del host desactivando todos los servicios innecesarios del sistema operativo.

  ¿Por qué deberían preocuparse los usuarios de Oracle?

CVE-2018-3110 es una vulnerabilidad de compromiso casi "perfecta" debido a la calificación de 9.9 CVSS. Como resultado, esta vuln es lo más insidiosa que se puede obtener: cuando alguien empuja un script de exploit hacia la naturaleza, cualquier script kidny de dos peniques podrá tomar como rehén a uno de los sistemas de bases de datos más populares y extendidos en uso por las compañías y gobiernos en todo el mundo, en un solo clic.

¿Qué tan fácil o difícil es para alguien explotar CVE-2018-3110?

Oficialmente, Oracle lo calificó con la calificación de complejidad de ataque más baja en la escala de riesgo de CVSS 3.0. En otras palabras, las vulnerabilidades no son más fáciles de explotar. Lo que esto significa en la práctica es que todo lo que se necesita es una simple secuencia de comandos estática, y tan pronto como uno se libera en libertad, cualquiera puede manejar esta vuln con un solo clic.

¿Cuáles son, si las hay, algunas de las condiciones que deben existir para que un atacante pueda explotar la falla (por ejemplo, qué tipo de acceso necesitaría el atacante, por ejemplo?).

Solo se requiere una condición y eso es el acceso para crear una sesión. Un atacante tendrá que posicionarse primero para abrir una sesión con la base de datos antes de que puedan usar esta vuln. Eso puede hacer que el vuln sea menos probable que sea explotado por actores externos sin acceso a la creación de una sesión. Para la mayoría de las organizaciones, el principal riesgo serán los actores internos, como los empleados deshonestos o los atacantes externos que hayan comprometido los sistemas laterales en la red corporativa interna.

En general, ¿cuánto tiempo tardan las organizaciones en parchear agujeros de seguridad en Oracle y otras bases de datos (dadas las preocupaciones que tienen las personas sobre la confiabilidad de los parches y la interrupción de los sistemas de producción)?

¡Siglos! Los mismos Oracle afirman que su cliente promedio se ejecuta casi un año después en la aplicación de parches críticos. Otros proveedores de pruebas de software de terceros afirman que el 86% de los defectos más graves tardan más de 30 días en solucionarse. Sin embargo, los atacantes que usan escáneres automáticos pueden identificar objetivos y lanzar ataques a las pocas horas de que se anuncie una vulnerabilidad y un parche.

¿Tiene algún otro comentario sobre parches / vulnerabilidades en la base de datos para ofrecer?

Waratek no ofrece actualmente parches para el producto Oracle Database, pero sí ofrecemos una solución robusta de parche "sin downtime / no source code change" para aplicaciones Java y .NET. Ofreceremos protección de base de datos en el futuro.

Sin embargo, esta no es la última vez que es probable que veamos vulnerabilidades amplias similares reveladas en el software ubicuo. De hecho, a medida que nuestro mundo conectado se conecte más, se encontrarán más vulnerabilidades, se encontrarán con más frecuencia y se explotarán más rápido cada vez.

La comunidad de seguridad necesita desesperadamente nuevas soluciones al " problema de parches ". Lo que la industria está haciendo hoy - el parcheo manual - no funciona: lleva demasiado tiempo, es demasiado perturbador y cuesta demasiado.

¿El resultado? Millones de software sin parches, bibliotecas, plataformas y servicios que ejecutan cargas de trabajo de misión crítica en todas las organizaciones virtuales de todas las industrias.

El "problema de parches" realmente es el hijo olvidado de la industria de seguridad de TI. Donde ha habido miles de millones de dólares de inversión e innovación en seguridad de redes, seguridad de puntos finales, escáneres de virus, etc., históricamente no ha habido innovación en la solución del "problema de parches".

En los últimos 2 años esto ha cambiado: algunas de las empresas más grandes del mundo han comenzado a adoptar la solución de Waratek para resolver los problemas de parches en las partes más olvidadas de la cadena de suministro de software de TI: bibliotecas de aplicaciones, middleware servicios y plataformas de tiempo de ejecución. Utilizando el compilador JIT presente en casi todos los idiomas contemporáneos y plataformas de aplicaciones, Waratek aplica cambios de parches en tiempo real mientras la aplicación se ejecuta como parte de la canalización de compilación de JIT normal para la aplicación.

A diferencia de los parches manuales donde los artefactos binarios deben subirse a los puntos finales y las aplicaciones deben cerrarse y probarse manualmente, las soluciones de parcheo del compilador JIT literalmente proporcionan parches instantáneos con garantías duras de compatibilidad binaria, cero falsos positivos y cero tiempo de inactividad. Para muchas aplicaciones de misión crítica, esta nueva forma de parcheo virtual es la única forma para que la aplicación logre el cumplimiento de parches y se elimine de las listas rojas de registros de riesgos corporativos y multas de auditores.