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.