Crónica del ataque a los servidores de la fundación Apache
El pasado día 13 de abril, a través de un post en el blog oficial del equipo de infraestructuras de Apache, se publicaron los detalles acerca de un ataque dirigido sobre los servidores de la fundación Apache.
En esta ocasión emplearon una vulnerabilidad desconocida en JIRA (un software de gestión de errores e incidencias en proyectos) que permitía efectuar ataques de cross-site scripting. Los atacantes, a través de un servidor virtual comprometido (alojado en SliceHost), abrieron una incidencia en JIRA en la cual incluyeron una URL corta redireccionada por el servicio TinyURL que desencadenaba el cross-site scripting; consiguieron comprometer varias sesiones de usuario, incluyendo algunas con derechos de administrador.
A la vez, emplearon un ataque por fuerza bruta sobre la página de login de JIRA ("login.jsp") en la que se llegaron a contabilizar, según Apache, cientos de miles de combinaciones de passwords.
Sin llegar a especificar que método fue exitoso, los atacantes lograron obtener una cuenta de administrador de JIRA que usaron para desactivar las notificaciones de cierto proyecto y cambiar la ruta, sobre la que se depositan los adjuntos, a una con permisos de escritura y ejecución de páginas JSP.
Mediante los cambios efectuados consiguen abrir incidencias para subir archivos en los adjuntos. Dichos archivos eran scripts JSP que integraban una especie de shell con la que copiaron los directorios "home" y archivos de varios usuarios de la máquina local.
Con la idea de obtener una cuenta con privilegios en la maquina, instalaron un JAR (una aplicación Java empaquetada) que servía de recolector de credenciales y enviaron correos al personal del equipo de infraestructuras pidiéndoles que resetearan sus cuentas en JIRA.
El personal del equipo, en vez de sospechar del correo, pensaron que se trataba de un error en JIRA y usaron el password temporal del correo para loguearse en la cuenta y resetearlo, volviendo a usar el mismo. Uno de esos password, ya interceptado por la aplicación de los atacantes, resultaba ser el mismo que una de las cuentas de la máquina local con el agravante de que la cuenta permitía hacer sudo.
La máquina comprometida alojaba, además de JIRA, las aplicaciones Confluence (una suerte de wiki), un Bugzilla y varias credenciales cacheadas de Subversion. Con estás credenciales accedieron a otra máquina, la que aloja el servidor people.apache.org e intentaron sin éxito escalar privilegios.
En este punto, después de seis horas transcurridas desde el reseteo de los passwords, el equipo de Apache comenzó a contrarrestar el ataque.
Apache notificó a Atlassian, el fabricante de JIRA, acerca de la vulnerabilidad usada por los atacantes y en respuesta se han publicado dos boletines de servicio que corrigen el error.
Se lamenta Apache que aun después de dos días tras avisar a SliceHost, la empresa de hosting propietaria del servidor virtual comprometido, aun continuaba bajo el dominio de los atacantes e incluso fue empleado para efectuar un ataque adicional sobre Atlassian.
Fuente: Hispasec
En esta ocasión emplearon una vulnerabilidad desconocida en JIRA (un software de gestión de errores e incidencias en proyectos) que permitía efectuar ataques de cross-site scripting. Los atacantes, a través de un servidor virtual comprometido (alojado en SliceHost), abrieron una incidencia en JIRA en la cual incluyeron una URL corta redireccionada por el servicio TinyURL que desencadenaba el cross-site scripting; consiguieron comprometer varias sesiones de usuario, incluyendo algunas con derechos de administrador.
A la vez, emplearon un ataque por fuerza bruta sobre la página de login de JIRA ("login.jsp") en la que se llegaron a contabilizar, según Apache, cientos de miles de combinaciones de passwords.
Sin llegar a especificar que método fue exitoso, los atacantes lograron obtener una cuenta de administrador de JIRA que usaron para desactivar las notificaciones de cierto proyecto y cambiar la ruta, sobre la que se depositan los adjuntos, a una con permisos de escritura y ejecución de páginas JSP.
Mediante los cambios efectuados consiguen abrir incidencias para subir archivos en los adjuntos. Dichos archivos eran scripts JSP que integraban una especie de shell con la que copiaron los directorios "home" y archivos de varios usuarios de la máquina local.
Con la idea de obtener una cuenta con privilegios en la maquina, instalaron un JAR (una aplicación Java empaquetada) que servía de recolector de credenciales y enviaron correos al personal del equipo de infraestructuras pidiéndoles que resetearan sus cuentas en JIRA.
El personal del equipo, en vez de sospechar del correo, pensaron que se trataba de un error en JIRA y usaron el password temporal del correo para loguearse en la cuenta y resetearlo, volviendo a usar el mismo. Uno de esos password, ya interceptado por la aplicación de los atacantes, resultaba ser el mismo que una de las cuentas de la máquina local con el agravante de que la cuenta permitía hacer sudo.
La máquina comprometida alojaba, además de JIRA, las aplicaciones Confluence (una suerte de wiki), un Bugzilla y varias credenciales cacheadas de Subversion. Con estás credenciales accedieron a otra máquina, la que aloja el servidor people.apache.org e intentaron sin éxito escalar privilegios.
En este punto, después de seis horas transcurridas desde el reseteo de los passwords, el equipo de Apache comenzó a contrarrestar el ataque.
Apache notificó a Atlassian, el fabricante de JIRA, acerca de la vulnerabilidad usada por los atacantes y en respuesta se han publicado dos boletines de servicio que corrigen el error.
Se lamenta Apache que aun después de dos días tras avisar a SliceHost, la empresa de hosting propietaria del servidor virtual comprometido, aun continuaba bajo el dominio de los atacantes e incluso fue empleado para efectuar un ataque adicional sobre Atlassian.
Fuente: Hispasec
0 Comments:
Publicar un comentario
Gracias por dejar un comentario en Segu-Info.
Gracias por comentar!