Analizando la info del primer ataque exitoso de PHP2Shell, tengo una reflexión.
Aunque mis servidores están parcheados y usan PHP-FPM (hasta ahora no hay pruebas de explotación en FPM), estoy trabajando en mecanismos de detección de mi HIDS.
El problema es que las peticiones que consiguieron ejecutar comandos no siempre dejaron una entrada HTTP completa, porque el worker Apache terminó con SIGSEGV después de iniciar la shell.
Esto significa que ossec, wazuh o cualquier otro HIDS que use reglas (nosotros usamos ossec), podría fallar la detección.
Esto es relevante porque podría haber intrusiones silenciosas.
Por eso es recomendable incluir telemetría de procesos mediante auditd o eBPF, además de inotify y YARA, que ya usamos.
En mi empresa llevamos ya unos días instalando auditd y añadiendo analisis de telemetría para detección de ataques.
No es por PHP2Shell en concreto, porque parcheamos todo el día 21 de octubre a las 16h, incluidos muchos servidores para webs legacy con PHP 5.6 y 7.4, sino porque esta vulnerabilidad nos está enseñando lecciones muy importantes para mejorar la seguridad de nuestros servidores.
Esta es importante, si un ataque genera un SIGSEGV o cualquier otro fallo de segmentación de memoria, podrías quedarte sin detección ni evidencia de un ataque.
Puedo hacer publicos los cambios de telemetría y el sistema de detección que estamos instalando y probando (todo sobre Debian 13), pero no se si tengo suficientes personas interesadas entre mis seguidores en esta info y lleva trabajo hacerlo.
Por favor, comenta si te interesa y lo publico.
skeptic 🖖 @3kept1c
Primera evidencia documentada de ejecución remota de codigo (RCE), en ataques reales, usando PHP2Shell.
El proyecto de investigación 0x4D31/honeypot-data ha publicado un informe que documenta 35 ejecuciones de /bin/sh provocadas por peticiones HTTP maliciosas contra tres honeypots con PHP vulnerable.
No son sólo intentos de explotación, errores de memoria o afirmaciones sobre exploits privados como hasta ahora, esta vez son ataques reales.
Los investigadores correlacionaron:
- Capturas de tráfico HTTP, incluyendo peticiones y respuestas.
- Identificadores de los procesos Apache que atendieron las peticiones.
- Errores de memoria de PHP durante la inicialización de las solicitudes.
- Eventos de creación de procesos registrados mediante Tetragon/eBPF.
- Ejecuciones posteriores de id, PHP CLI, curl y wget.
Vamos, ataques exitosos reales, por mucho que fuera contra un honeypot.
El informe habla de dos IPs como origen del ataque, entre las 15:35 y las 18:57 UTC del 24 de octubre, lo que no implica que fueran dos atacantes, podría ser el mismo o podrían ser dos usando el mismo exploit habrá que darse una vuelta por la dark web a ver que encontramos.
Más información aquí:
