Vulnerabilidad crítica PHP: Ciberseguridad y protección de datos

Análisis del impacto técnico, regulatorio y de gestión de riesgos ante fallos críticos en la infraestructura web.

El problema y la contingencia inmediata

Ya es mundialmente conocida la detección de las vulnerabilidades que afecta a las soluciones tecnológicas basadas en el lenguaje de programación PHP. Sin embargo, es una vulnerabilidad que había sido descubierta el 1 de agosto de este año gracias a investigación humana asistida por la IA (curiosamente).

¿Cuál es el problema?

Las vulnerabilidades permiten a un atacante remoto no autenticado ejecutar código con los privilegios del proceso web.

Veamos el siguiente relato ordinario. Los actores de esta historia son el edificio de oficinas (el servidor), el recepcionista con un juego de llaves (PHP) y quienes tocan el timbre de la puerta de entrada (visitantes de la página web):"El atacante remoto no necesita estar en el edificio. Tocaría el timbre desde la calle. Le abren la puerta y, sin identificación alguna, le entrega al recepcionista un formulario rellenado de forma tan retorcida que este se confunde y lo toma como una orden del jefe para dar instrucciones tales como: 'abre el archivo de clientes y fotocópialo. Luego me haces el favor de dejar la puerta trasera abierta'. El recepcionista procederá a seguir estas instrucciones de acuerdo a lo que las llaves le permitan entrar a las distintas áreas del edificio."

La vulnerabilidad es de tal criticidad que voceros institucionales como el CERT-EU e INCIBE han indicado que, si los sistemas no pueden ser actualizados con los parches de seguridad o migrados a una versión PHP que no se encuentre afectada, deben ser aislados de las redes públicas. Esto básicamente es: tumba tu página web lo antes posible hasta que logres parchear.

Para el mundo entero esto supone un quebradero de cabeza sin lugar a duda. Las páginas web son posiblemente uno de los principales sistemas de información (SI) con los que cuentan las organizaciones para sus distintos propósitos. La indisponibilidad de recursos tecnológicos de uso diario conlleva pérdidas de toda índole. Esto sin contar qué sucede si se han visto efectivamente comprometidos por una vulnerabilidad explotada con éxito.

Los que estamos en este mundillo de la privacidad, el cumplimiento normativo y la ciberseguridad lo primero que se nos viene a la mente es: ¿Qué dimensiones de seguridad puede afectar esta vulnerabilidad y cómo podemos gestionar el riesgo?

Antes de cualquier análisis técnico-jurídico que cada uno asumirá respectivamente de acuerdo a su olfato, lo prioritario es adoptar cuanto antes la medida sugerida por los voceros oficiales: Aislar hasta solucionar.

Luego procede el planteamiento estratégico que dependerá de tu rol en la sociedad:

• ¿Eres una administración pública?

• ¿Una empresa que presta sus servicios mediante tus páginas web?

• ¿Eres proveedor de desarrollo web para empresas y autónomos?

Análisis técnico-jurídico y contexto regulatorio

A nivel de protección de datos personales, el RGPD lo deja claro en su capítulo IV, secciones 1 y 2: los principios y obligaciones generales que son comunes para los responsables y encargados del tratamiento.

Creo que el inciso nuclear que debe primar el análisis técnico-jurídico de esta contingencia ha de ser el principio de la protección de datos desde el diseño y por defecto. Es lo primero que las autoridades de protección mirarán en casos de brechas de datos personales (que habrá si las vulnerabilidades son explotadas por los atacantes).

Los responsables y encargados del tratamiento que diseñen o encarguen el diseño de sistemas de información debieron y deben ser responsables proactivos en poder cumplir con sus obligaciones, tanto de aquellas derivadas de las leyes como de aquellas que son derivadas del contrato.

Esto se traduce en preguntarse: ¿Mis sistemas de información fueron concebidos desde el inicio y por defecto tomando en cuenta el estado de la técnica en cuanto a la seguridad?

La respuesta pasa por verificar las medidas técnicas y organizativas adoptadas, contrastadas con el estado de la técnica imperante de aquel entonces (Y la actual también, por cierto. El accountability no es estático a una fecha determinada, se contrasta diariamente). En este caso particular de la vulnerabilidad PHP, sería importante indicar que desde la versión 8.1 y anteriores, el propio fabricante las ha listado como no soportadas, ya habiendo cumplido su ciclo de vida útil.

De acuerdo a lo anterior e independientemente de que la vulnerabilidad afectaba incluso a las versiones vigentes de PHP, el artículo 32 del RGPD obliga a los actores a preguntarse irremediablemente cuál era la versión sobre la que trabajaba su sistema de información y si esa respuesta sostiene justificarlo.

En mi opinión, ante una investigación por parte de una autoridad, saldrá mejor parado aquel que tuvo la diligencia de mantener su SI en las versiones actuales y vigentes de PHP que, además, recibieron los parches de seguridad primero y listas para instalar. Versiones anteriores a la 8.2 han recibido parches parciales de forma excepcional y sin garantía de que no puedan volver a ser vulnerables. En todo caso, ya han sido declaradas obsoletas. Versiones más viejas sencillamente no recibieron ningún tipo parche: la única solución es migrar.

¿Y qué pasa en el contexto venezolano?

Ya David, pero estás hablando de estándares europeos, mi empresa está en Venezuela, ¿Qué sugieres para nuestro contexto? Es verdad que allí no existe una ley general de protección de datos como el RGPD o la LOPDGDD española, pero eso no significa ausencia de responsabilidad.

• La Constitución reconoce el habeas data y protege la intimidad frente al uso de la informática.

• La Ley Especial contra los Delitos Informáticos tipifica el acceso indebido y el sabotaje a sistemas.

• Y, sobre todo, el Código Civil exige cumplir las obligaciones con la diligencia de un buen padre de familia.

Frente a un cliente cuyos datos se filtraron por una web sin actualizar, la pregunta será la misma que en Europa: ¿hiciste lo razonable para protegerlos?

Gestión del riesgo y conclusiones

No se trata de ser puritanos o más papistas que el Papa en cuanto a esta debida diligencia que considero, las organizaciones deben tener. Se trata de una sencilla medida de gestión de riesgos que, asumida, te permite valorar cómo tratar dicho riesgo: aceptarlo, transferirlo, mitigarlo o evitarlo. El problema real muchas veces no son estas vulnerabilidades o ataques cibernéticos sino el desconocer que existen este tipo de riesgos en tus propias filas.

Es por ello que cada vez más importa tener la asesoría de especialistas en las áreas de ciberseguridad, privacidad de los datos, gobernanza e informática porque de otro modo, se ignora lo que se cuece día a día.

Estos auditarán mediante su ojo clínico ese estado de la técnica que impera en dichos sistemas de información y detectarán los riesgos que transversalmente existen y/o podrían eventualmente existir para la organización.