Aumentar la seguridad de las bases de datos MySQL eliminando el tiempo de inactividad

El software de código abierto (OSS) ha transformado rápidamente el modo en que se crean las aplicaciones modernas y su código subyacente. El acceso a proyectos de software de código abierto robustos y de alta calidad ha permitido a los desarrolladores integrar rápidamente nuevas capacidades en sus aplicaciones sin reinventar la rueda. Como resultado, ahora se estima que entre el 80% y el 90% del código de la mayoría de las aplicaciones modernas está formado por componentes de código abierto. Del mismo modo, muchas de las herramientas que han permitido el crecimiento de DevOps y CI/CD, como Jenkins, Kubernetes y Docker, son a su vez proyectos de código abierto.

En 2019, el número total de CVE de código abierto publicadas (968) se duplicó con creces en comparación con cualquier año anterior. Las vulnerabilidades crecieron un 130 % entre 2018 y 2019 (de 421 CVE a 968 CVE) y fueron un 127 % superiores a las de 2017 (435), que fue el segundo año con más CVE del estudio. Este aumento no parece ser un destello, ya que el descubrimiento de nuevos CVE también se mantiene en niveles históricamente altos hasta los tres primeros meses de 2020. Este volumen aumenta la complejidad de la gestión de la superficie de ataque de una organización tanto para los desarrolladores como para los equipos de TI y de seguridad. El servidor de automatización Jenkins fue el que más CVEs registró en general, con 646, y le siguió de cerca MySQL, con 624. Asimismo, estos proyectos empataron en el mayor número de vulnerabilidades con 15 (vulnerabilidades para las que existe código de explotación). Este artículo investiga las razones de estas vulnerabilidades de software y muestra cómo proteger las bases de datos MySQL de posibles incidentes de seguridad.

Contenido:

1. Breve descripción de MySQL y su importancia en el mercado de las bases de datos relacionales

2. Vulnerabilidades en MySQL 

3. Peligros de los servidores de bases de datos sin parches

4. El software de bases de datos vulnerable debe parchearse rápidamente

5. Conclusión

Breve descripción de MySQL y su importancia en el mercado de las bases de datos relacionales

Existen varias bases de datos en el mercado, pero MySQL es una de las más utilizadas tanto en operaciones internas de backend como en aplicaciones de cara al público, como sitios web y portales de clientes. Aunque es una base de datos de código abierto, MySQL fue adquirida por Sun Microsystems, que posteriormente fue comprada por Oracle. Se introdujo por primera vez en la década de 1990, pero rápidamente se convirtió en una opción popular frente a la base de datos Microsoft SQL Server, dominante hasta entonces. La sintaxis de MySQL es similar a la de otros lenguajes SQL (por ejemplo, Oracle y Microsoft), por lo que es una opción conveniente para desarrolladores y organizaciones que necesitan una base de datos más asequible.

Actualmente, MySQL es uno de los sistemas gestores de bases de datos relacionales (SGBD) más utilizados del mercado. A 2019 estudio mostró que MySQL era el 38,9% del mercado, seguido de MongoDB con el 24,6% y PostgreSQL con el 17,4%. El software de base de datos de código abierto domina una mayoría de sitios web, sistemas backend y otros servidores de almacenamiento de datos ejecutados corporativamente.

El software de código abierto que ejecuta la infraestructura tiene muchas ventajas, como una comunidad que contribuye a las actualizaciones, la detección de errores y las características, investigadores de seguridad que pueden encontrar vulnerabilidades antes de que los hackers las encuentren y las exploten, y un repositorio compartido que puede ser bifurcado y personalizado por otros desarrolladores. Sin embargo, estas ventajas conllevan un inconveniente. Si un atacante encuentra un fallo, puede explotarlo en lugar de denunciarlo. El resultado podría ser la explotación del software y una vulnerabilidad de día cero desconocida para el desarrollador hasta que se encuentre el exploit o la vulnerabilidad del código. Podría llevar potencialmente años identificar una vulnerabilidad que esté siendo explotada, lo que hace aún más crítico para las organizaciones parchear el software MySQL tan pronto como se publique una actualización. Estas actualizaciones parchean sistemas de vulnerabilidades que podrían haber existido durante meses, y posiblemente años. Si el exploit afecta a una base de datos MySQL de producción que almacena información sensible, es imperativo que la organización parchee el sistema lo antes posible.

Vulnerabilidades en MySQL 

Entre el tiempo que MySQL lleva a disposición del público y su código fuente abierto, el software de base de datos cuenta con numerosas CVEs (Vulnerabilidades y Exposiciones Comunes) - 1308 en total. Algunas de estas CVEs están relacionadas con aplicaciones o software como archivos de aplicación PHP que permiten la inyección SQL para manipular contenido web y ejecutar Cross-Site Scripting (XSS) persistente, pero otras tienen como objetivo el núcleo del motor de base de datos. Algunas vulnerabilidades tan recientes como 2020 permiten la escalada de privilegios, el acceso a la red para comprometer al cliente MySQL y la ejecución remota de código (RCE).

Una base de datos comprometida es un evento de seguridad crítico, ya que pueden surgir otros problemas si se permite a los atacantes acceder a ella. Dependiendo del exploit, los atacantes pueden exfiltrar datos de un servidor comprometido, otorgarse privilegios administrativos en el servidor o inyectar sus propios datos en las tablas. En un ataque XSS persistente, cualquier aplicación que no codifique los datos de la base de datos podría ser vulnerable al robo de datos o cookies. Si un atacante puede realizar una escalada de privilegios en el servidor, podría manipular datos, exfiltrar datos a un servidor controlado por el atacante o realizar movimientos laterales a través de las bases de datos de la empresa. La ejecución remota de código es especialmente peligrosa, porque un atacante puede ejecutar su propio malware en el servidor, que podría ser cualquier cosa, desde keyloggers a ransomware.

Peligros de los servidores de bases de datos sin parches

Por ejemplo CVE-2020-2934. Hay varios otros CVEs relacionados con esta vulnerabilidad, todos los cuales afectan a Conectores MySQL, clientes y sesiones de red. La explotación exitosa de esta vulnerabilidad podría permitir a un atacante ejecutar comandos CRUD (Crear, Leer, Actualizar o Eliminar) en el servidor de base de datos o lanzar un ataque de denegación de servicio (DoS). Un atacante con la capacidad de ejecutar comandos CRUD puede leer sus datos o realizar cambios en ellos.

Las violaciones de datos en una base de datos se consideran críticas y tienen un impacto duradero en la lealtad de los clientes, la confianza, los ingresos y la productividad. La mayoría de las organizaciones no disponen de un equipo interno de respuesta a incidentes, lo que obliga a recurrir a consultores externos que cobran cientos de dólares por hora. En algunos casos, los administradores de TI optan por apagar los sistemas críticos para contener la brecha y bloquear el acceso de los hackers al servidor de base de datos. Este remedio temporal impide que el atacante robe más datos, pero también interrumpe las aplicaciones que necesitan acceder a la base de datos para funcionar.

Las violaciones graves en las que un atacante utiliza ransomware para cifrar datos o corrompe archivos requieren copias de seguridad y un plan de recuperación de datos. Incluso en las grandes empresas, los planes de recuperación pueden fallar y necesitan el apoyo de consultores externos. Mientras la base de datos permanece inactiva, la organización pierde ingresos por el tiempo de inactividad, que puede ser de miles de dólares por hora en las grandes empresas.

El coste de una violación de datos en un servidor de base de datos depende en gran medida del tipo de compromiso, la cantidad de datos robados y la eficacia de la respuesta al incidente. Por ejemplo, el prestamista canadiense Grupo Desjardins gastó 53 millones de dólares tras una filtración de datos que reveló información personal de 2,9 millones de sus miembros. British Airways y Marriott gastaron 100 millones de dólares cada una tras infringir la normativa de cumplimiento del GDPR (Reglamento General de Protección de Datos), a raíz de sendas filtraciones de datos.

El software de bases de datos vulnerable debe parchearse rápidamente

Un punto en común con cada CVE listada en la base de datos de MITRE para MySQL es que cualquier aplicación listada con vulnerabilidades debe ser parcheada. Los CVE podrían ser software de terceros que permite la inyección SQL y otros exploits o vulnerabilidades podrían encontrarse en el propio motor de base de datos MySQL. Puede que no utilice la aplicación de terceros, pero cualquier vulnerabilidad de la base de datos MySQL debe ser parcheada lo antes posible.

Dado que MySQL es un componente de infraestructura tan crítico, los administradores y gestores de bases de datos (DBA) pueden programar a menudo la aplicación de parches para una fecha posterior. También pueden esperar varias semanas para parchear el sistema, de forma que se puedan realizar pruebas exhaustivas y evitar tiempos de inactividad en un servidor de base de datos de producción. Cada día que pasa es una ventana de oportunidad para que un atacante explote el software del servidor MySQL sin parchear.

Con más de 1300 CVEs y contando, puede parecer una batalla perdida para los administradores y DBAs mantenerse al día con los parches del servidor. Cualquier tiempo de inactividad en un servidor de producción significa pérdida de productividad, de ventas, y suele ser difícil de programar, ya que los administradores no pueden interrumpir los servicios durante las horas de mayor actividad.

Conclusión

Para mantener los servidores parcheados y protegidos de las vulnerabilidades más recientes, la respuesta es utilizar live patching, de forma que el servidor reciba actualizaciones continuas sin necesidad de reiniciar. KernelCare+ lanzará en breve una nueva función que permitirá a los administradores aplicar parches a sus servidores de bases de datos sin necesidad de reiniciar. Con KernelCare+, los administradores pueden evitar costosas brechas de datos y tiempos de inactividad, y seguir salvaguardando los datos críticos.