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 global 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.

En la actualidad, MySQL es uno de los sistemas de gestión de bases de datos relacionales (SGBDR) más utilizados del mercado. Un estudio de 2019 reveló que MySQL representaba el 38,9 % del mercado, seguido de MongoDB con un 24,6 % y PostgreSQL con un 17,4 %. Hacer un seguimiento de hitos del ciclo de vida como el fin de vida útil (EOL) de PostgreSQL 13 ayuda a los equipos a evitar utilizar versiones de bases de datos sin soporte técnico a la hora de planificar parches y actualizaciones. Es igualmente importante supervisar las etapas del ciclo de vida de otros sistemas, como las fechas de fin de vida útil de MySQL, para garantizar que las bases de datos más antiguas no se conviertan en blancos fáciles. El software de bases de datos de código abierto domina la mayoría de los sitios web, los sistemas de backend y otros servidores de almacenamiento de datos gestionados por empresas.

El software de código abierto que gestiona la infraestructura ofrece numerosas ventajas, entre las que se incluyen una comunidad que contribuye a las actualizaciones, la detección de errores y el desarrollo de nuevas funcionalidades; investigadores de seguridad capaces de detectar vulnerabilidades antes de que los piratas informáticos las encuentren y las aprovechen; y un repositorio compartido que otros desarrolladores pueden bifurcar y personalizar. Sin embargo, estas ventajas conllevan un inconveniente: si un atacante encuentra un error, puede aprovecharlo en lugar de notificarlo. El resultado podría ser el aprovechamiento del software y una vulnerabilidad de «día cero» desconocida para el desarrollador hasta que se descubra el exploit o la vulnerabilidad en el código. Identificar una vulnerabilidad que se está explotando en ese momento podría llevar años, lo que hace aún más crítico que las organizaciones apliquen los parches al software MySQL tan pronto como se publique una actualización. Estas actualizaciones corrigen 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 confidencial, es imprescindible que la organización aplique los parches al 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

Como ejemplo, vea CVE-2020-2934. Hay otras vulnerabilidades CVE relacionadas con esta, todas ellas afectan a los conectores MySQL, los clientes y las 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 la 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. Del mismo modo, el fin de la vida útil de PostgreSQL14 podría introducir vulnerabilidades para las organizaciones que no realicen la actualización, lo que las pondría en riesgo de explotaciones y ataques debido a versiones no compatibles.

Para obtener información sobre las mejores prácticas de seguridad de PostgreSQL, consulta nuestro recurso específico sobre cómo reforzar las configuraciones de las bases de datos.

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 la 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 filtración de datos en un servidor de bases de datos depende en gran medida del tipo de incidente, la cantidad de datos sustraídos y la eficacia de la respuesta ante el incidente. A modo de ejemplo, la entidad crediticia 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 socios. British Airways y Marriott gastaron 100 millones de dólares cada una tras incumplir las normas del RGPD (Reglamento General de Protección de Datos), a raíz de 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 actualizados y protegidos frente a las últimas vulnerabilidades, la solución pasa por utilizar la aplicación de parches en tiempo real, de modo que el servidor reciba actualizaciones continuas sin necesidad de reiniciarse. KernelCare+ lanzará próximamente una nueva función que permitirá a los administradores aplicar parches a sus servidores de bases de datos sin necesidad de reiniciarlos. Con KernelCare+, los administradores pueden evitar costosas fugas de datos y tiempos de inactividad, al tiempo que protegen los datos críticos.