A última hora de la noche del domingo, el 28 de marzo de 2021, Nikita Popov, un confirmador principal de PHP, emitió una declaración que indica que se habían enviado dos confirmaciones maliciosas al php-srcrepositorio de git. Estas confirmaciones se impulsaron para crear una puerta trasera que hubiera permitido a los atacantes lograr la ejecución remota de código a través de PHP y un encabezado HTTP.

La ejecución remota de código hace posible emitir comandos a un servidor de forma remota, lo que permite a los atacantes hacer cosas como crear nuevos archivos, robar datos en el servidor, eliminar archivos y, esencialmente, hacerse cargo del servidor afectado por cualquier sitio web impulsado por PHP.

En esta publicación, analizamos el compromiso y el código enviado al repositorio, al mismo tiempo que discutimos cómo esto afecta a WordPress.

PHP es de código abierto como WordPress

PHP es un lenguaje de código abierto, lo que, como WordPress, significa que cualquier individuo puede contribuir a su desarrollo.

“Cualquiera que programe en PHP puede ser un miembro contribuyente de la comunidad que lo desarrolla e implementa”.

Antes del compromiso, PHP Group manejaba todo el acceso de escritura al repositorio en su propio servidor git http://git.php.net/ utilizando un sistema interno “Karma”. Este sistema de Karma esencialmente otorgó a los contribuyentes diferentes privilegios de acceso y les permitió contribuir directamente a varios recursos en función de su Karma. El Karma de un colaborador también debía solicitarse explícitamente y, si se concedía, se le asignaría una @php.netcuenta al colaborador .

Debido al compromiso de ayer, PHP Group ha declarado que se alejarán de su actual infraestructura de git autohospedada y administrada y se mudarán a GitHub para convertir sus repositorios “reflejados” en repositorios “canónicos”, lo que significa que todos Los cambios adicionales serán rastreados y administrados en GitHub. PHP Group también ha anunciado que se alejarán del sistema Karma actualmente administrado y exigirán que los contribuyentes sean parte de la organización PHP en GitHub. También requerirán que la autenticación de dos factores esté habilitada en todas las cuentas con acceso de escritura para combatir los compromisos de contraseña que podrían conducir a confirmaciones no autorizadas en el repositorio.

Análisis del compromiso

El sábado 27 de marzo de 2021, la primera de las dos confirmaciones se envió al repositorio. La primera confirmación tenía la descripción de Fixes minor typo. Signed-off-by: Rasmus Lerdorf <rasmus@lerdorf.com>por parte del confirmador rlerdorf. Esta cuenta pertenece a Rasmus Lerdorf, coautor del lenguaje PHP.

El segundo compromiso no tenía descripción, sin embargo, el título fue el Revert "Revert "[skip-ci] Fix typo""que revirtió la reversión del compromiso original rlerdorf, lo que indica que el atacante revirtió el intento original de Nikita de revertir esta puerta trasera. Esta confirmación se hizo para que pareciera que procedía de la nikiccuenta. Esta cuenta pertenece a Nikita Popov, un colaborador muy respetado del proyecto PHP.

El uso de estas dos cuentas individuales hizo que pareciera que las confirmaciones provenían de colaboradores y autores de gran confianza, lo que se hizo en un intento de que las confirmaciones parecieran auténticas y de buena reputación. El atacante también se aseguró de que los cambios parecieran ser correcciones menores para corregir un error tipográfico con el fin de ocultar sus intenciones.

A primera vista, puede parecer que rlerdorflas nikiccuentas de y están comprometidas, sin embargo, el grupo PHP ha declarado explícitamente que creen que las confirmaciones maliciosas fueron el resultado de un compromiso dentro de su infraestructura de git en lugar de una cuenta individual.

Además de agregar código utilizando confirmadores confiables, los atacantes también agregaron un comentario en los cambios que indicaban "REMOVETHIS: sold to zerodium, mid 2017"que implicaba que el exploit se vendió a Zerodium, una empresa de adquisición de exploits para vulnerabilidades de día cero. Esto puede haber tenido la intención de engañar a los revisores para que piensen que el compromiso se produjo debido a una filtración de la empresa Zerodium o una posible venta del exploit a la empresa. Sin embargo, Chaouki Bekrar, el CEO de Zerodium, emitió un comunicado en Twitter negando cualquier participación en las confirmaciones maliciosas que se enviaron al repositorio.

La siguiente es una captura de pantalla de la confirmación que parecía provenir de la rlerdorfcuenta.

La siguiente es una captura de pantalla de la confirmación que parecía provenir de la nikiccuenta.

El código es el mismo para ambos intentos. Básicamente, el código comprueba si el encabezado HTTP del agente de usuario personalizado contiene la cadena “zerodium”. Si PHP procesara una solicitud con este agente de usuario, ejecutaría la función zend_eval_stringque podría usarse para ejecutar comandos y lograr la ejecución remota de código. Si bien las confirmaciones fueron bastante simples, podrían haber resultado en una enorme cantidad de daño si se hubieran lanzado en una versión de producción de PHP, considerando que PHP potencia alrededor del 80% de los sitios web que utilizan programación del lado del servidor. Afortunadamente, estas confirmaciones maliciosas se detectaron con bastante rapidez y solo estaban en una versión de desarrollo de PHP.

Análisis del actor de amenazas
En contraste con el compromiso de SolarWinds que vimos en diciembre de 2020, esto parece haber sido el trabajo de un individuo, potencialmente un “niño de guiones” habilidoso que solo buscaba algo de diversión o un simple “ciberdelincuente” que podría haber querido para intentar vender el exploit si la versión de PHP se había puesto en producción con el código malicioso sin ser detectado.

Al analizar el compromiso, podemos ver que la puerta trasera no estaba muy bien oculta, lo que indica que el atacante pudo haber esperado ser atrapado o que no tenía la habilidad para ocultarlo muy bien. Además, dado que este fue un compromiso menor con muy poco ocultamiento, es muy poco probable que haya sido el trabajo de más de un individuo. La falta de complejidad y el uso aparentemente irónico de “zerodium” en toda la puerta trasera nos lleva a creer que este ataque puede haber sido realizado como una broma de alto perfil o como una forma de simplemente decir que lo hicieron.

¿Afecta esto a WordPress?

Este compromiso no afecta a ningún sitio de WordPress en producción. Afortunadamente, las confirmaciones se detectaron muy rápidamente y solo estuvieron activas durante unas pocas horas en una rama de desarrollo. En un comunicado emitido a Bleeping Computer , Nikita Popov dijo: “Los cambios estaban en la rama de desarrollo de PHP 8.1, que se lanzará a fin de año”, lo que significa que el código malicioso se envió a una rama de PHP que no es está en producción. También afirmaron que “los cambios no se hicieron en ninguna etiqueta ni liberaron artefactos”, lo que indica que el código malicioso nunca se lanzó realmente. Esto significa que la versión comprometida de PHP no llegó ni llegará nunca a su servidor.

¿El cambio a GitHub evitará que esto vuelva a suceder?

Pasar de un repositorio autohospedado a GitHub agrega algunos controles que no estaban disponibles antes y descarga parte de la administración de seguridad involucrada en el autohospedaje de su propia infraestructura de git que debería mejorar la postura de seguridad de la administración de git de la organización PHP. Además, un requisito para examinar a los confirmadores a medida que se agregan a la organización PHP debería agregar un nivel adicional de seguridad que debería evitar que esto vuelva a ocurrir en el futuro.

Como ocurre con todos los ataques a la cadena de suministro, existen ciertos riesgos para cualquier base de código. Afortunadamente, PHP Group respondió rápidamente para combatir este compromiso y tomó medidas para evitar que esto vuelva a suceder en el futuro, lo que indica cuán en serio se toman la seguridad.

La buena noticia es que estos cambios maliciosos fueron detectados rápidamente por la comunidad PHP y no hay informes de sitios de producción afectados por este código malicioso. La naturaleza de código abierto de la comunidad PHP proporciona el mismo tipo de protección que también disfruta WordPress, lo que garantiza que el código o las actividades anómalas se identifiquen y gestionen rápidamente.

Conclusión

En la publicación de hoy, analizamos el compromiso de PHP que ocurrió durante el fin de semana y le brindamos algunas ideas sobre lo que sucedió exactamente. Este compromiso no debería tener ningún efecto en ningún sitio de WordPress, ya que el código malicioso nunca se lanzó a producción ni se incluyó en ninguna etiqueta o artefacto de lanzamiento. A medida que esta historia evolucione, continuaremos manteniéndolos actualizados.

Open chat
WhatsApp
Hola 👋
¿En qué podemos ayudarte?