nickstadb/pocRepositorio de exploits y herramientas de prueba de concepto.
Repositorio de exploits y herramientas de prueba de concepto.
Exploit de ejecución remota de comandos no autenticado para el agente RSCD de BMC Server Automation. El exploit funciona contra servidores afectados por CVE-2016-1542 (detectado por Nessus).
Esto ahora es un módulo de Metasploit, consulta exploits/multi/misc/bmc_server_automation_rscd_nsh_rce
El exploit fue creado haciendo que Nessus escaneara un script de Python que registraba paquetes y los enviaba/respondía con basura a Nessus. Con los paquetes capturados, el formato de datos fue trivial de "invertir" para crear un exploit semi-funcional. Más tarde obtuve acceso al software del agente afectado y pude usar un depurador y algo de fuzzing para pulir los detalles y convertir esto en un exploit de RCE sólido.
Consulta mis publicaciones de blog sobre cómo construí el exploit para más detalles:
Exploit de ejecución remota de código no autenticado para HP Device Manager versiones 5.0.0 a 5.0.3 (CVE-2020-6926, CVE-2020-6927).
El exploit aprovecha un servicio Java RMI no autenticado que tiene una vulnerabilidad de inyección de Hibernate Query Language. Se utiliza inyección ORM para introducir un payload de inyección SQL de Postgres que sobrescribe el archivo pg_hba.conf en el servidor de HP Device Manager, permitiendo el acceso remoto a la base de datos Postgres que se incluye con HPDM. Una vez habilitado, se utiliza una cuenta de superusuario backdoor para autenticarse en la base de datos Postgres y ejecutar comandos arbitrarios del sistema operativo.
Consulta mi publicación de blog sobre cómo descubrí estas vulnerabilidades para más detalles:
Si bien este exploit solo funciona contra HPDM 5.x, el servicio Java RMI no autenticado está presente en todas las versiones de HPDM anteriores a 5.0.4 y 4.7 service pack 13. El impacto de explotar este servicio puede ser menor, pero aún existe una vulnerabilidad HQLi/SQLi, junto con la capacidad de extraer configuración (potencialmente incluyendo contraseñas de otros servicios), y todos los nombres de usuario de cuentas de HPDM con sus correspondientes hashes MD5 de contraseñas.
Exploit de ejecución remota de código no autenticado para endpoints de servicio Java JNBridge configurados de forma insegura. Basado en el trabajo de Moritz Bechler (CVE-2019-7839).
El protocolo de red implementado por JNBridge está diseñado únicamente para facilitar la ejecución remota de código para la interoperabilidad entre aplicaciones Java y .NET. Por lo tanto, esto no es técnicamente un exploit, sino un práctico script de Python para ejecutar comandos arbitrarios contra un endpoint Java de JNBridge.
Consulta mi publicación de blog para un recorrido de mi viaje desde el aviso de seguridad hasta producir un exploit completo:
Este exploit ataca la funcionalidad insegura de actualización automática en WordPress para colocar un shell PHP en el servidor subyacente. El exploit ha sido probado con éxito hasta WordPress 4.9.8, que es la última versión en la fecha de publicación.
Cuando WordPress comprueba actualizaciones, intenta una conexión HTTPS segura a api.wordpress.org. Si esta conexión falla, por ejemplo porque se presenta un certificado no confiable, WordPress recurre a usar una conexión HTTP insegura.
El segundo problema es que WordPress confía en las actualizaciones de traducción. No actualiza automáticamente plugins, temas o versiones principales principales, presumiblemente debido a los riesgos de instalar código nuevo en el servidor. Sin embargo, sí actualiza automáticamente las traducciones. Desafortunadamente, WordPress no valida correctamente los archivos de traducción, por lo que mientras el archivo ZIP de traducción contenga al menos un archivo con la extensión .po y un archivo con la extensión .mo, WordPress extraerá el contenido al servidor subyacente (incluido el shell insertado allí por el MitM).
Me topé con estos problemas por accidente, pero cuando los reporté (noviembre de 2017), el equipo de WordPress básicamente dijo WONTFIX debido a la compatibilidad con versiones anteriores. Si alguien ejecuta WordPress en un servidor que no puede establecer una conexión SSL/TLS saliente, dice que aún debería poder actualizar WordPress automáticamente por razones de seguridad.
¯\_(ツ)_/¯
Consulta mi publicación de blog para más detalles:
Algunos fragmentos de JS para usar al explotar vulnerabilidades XSS de WordPress.
