Sigue El lado del mal en Telegram
Chema Alonso en Threads
Chema Alonso en Mastodon
Chema Alonso en BSKY
Chema Alonso en Linkedin
DragonJAR
8.8 Chile
Ekoparty
e-Hack MX 
AREA 51 
Comunidad Dojo Panamá 
ARPAHE SOLUTIONS 
Carta de Gerónimo, root de los Apache
Si eres un seguidor de los "Nativos Americanos", habrás recibido un mensaje con señales de humo de nuestro gran jefe Indio Gerónimo, también conocido como el Root de los Apahces. Este mail es debido a que, a causa de un XSS en Apache han hackeado varios servidores de la infraestructura de Apache.
Carta de Gerónimo, root de los Apaches
El ataque se ha hecho, como dice el informe del incidente, a través de un ataque XSS que hacía un robo de la cookie para hacer un hijacking de la sesión de los pobles administradores que pincharon en una URL acortada.
Pilla por la orilla. Una vez dentro, y tras haber probado ataques de fuerza bruta contra el login, metieron software que puede haber robado todas las contraseñas. Sólo con el hecho de que metieran software, hay que suponer que se han podido llevar la base de datos de passwords, así que... ¡ale! todos a cambiar la password.
Este incidente me ha recordado al ataque que se hizo a Zone-h con un XSS en un webmail para hacer un hijacking, pero este tenía el ingrediente del acortamiento de URLs al que los administradores hicieron clic. Delicioso y Delicado.
Como decía César Cerrudo en su twitter.. "¿Quién decía que un XSS no puede ser pelígroso?".
Saludos malignos!
Carta de Gerónimo, root de los Apaches
El ataque se ha hecho, como dice el informe del incidente, a través de un ataque XSS que hacía un robo de la cookie para hacer un hijacking de la sesión de los pobles administradores que pincharon en una URL acortada.
Pilla por la orilla. Una vez dentro, y tras haber probado ataques de fuerza bruta contra el login, metieron software que puede haber robado todas las contraseñas. Sólo con el hecho de que metieran software, hay que suponer que se han podido llevar la base de datos de passwords, así que... ¡ale! todos a cambiar la password.
Este incidente me ha recordado al ataque que se hizo a Zone-h con un XSS en un webmail para hacer un hijacking, pero este tenía el ingrediente del acortamiento de URLs al que los administradores hicieron clic. Delicioso y Delicado.
Como decía César Cerrudo en su twitter.. "¿Quién decía que un XSS no puede ser pelígroso?".
Saludos malignos!
9 comentarios:
Si es que luego la gente no me cree cuando les cuento sobre los peligros del XSS...
Hay que reconocer de todas maneras que el reporte esta muy bien escrito y da mas detalles de los que uno podria esperar.
Ver para creer, de verdad, gente con tantos conocimientos y luego caen en cosas "básicas".
Esto dañará en algo a apache como plataforma mayoritaría en servidores web? No lo creo, pero si les dará una mala reputación por un tiempo.
NaCl u2
@Rigolox, tus saludos con el Cloruro de Sodio me han hecho volver a clase de química en el instituto....
}:P
Me ha hecho recordar la demo que hicistes Pedro en el Microsoft University Tour del 2007 creo que fue, del robo de cookie de sesión con XSS y JavaScript. Curiosidad... =)
Yo creo que los problemas de XSS son importantes generalmente sólo en dos casos: si pueden obtenerse credenciales y/o si se puede hacer un "gusano XSS" (con persistent XSS).
Aunque pueden tener efectos demoledores en ciertas situaciones (ataques altamente dirigidos, para robo de credenciales, como en este caso) hay muchos "hackers" que encuentran un XSS en una página absurda (generalmente reflected XSS sin robo de credenciales) y quieren darle una importancia que no tiene, sólo para obtener su "minuto de fama". En el 90% de los casos, los XSS que se encuentran son más un problema de "relaciones públicas" que un fallo de seguridad crítico. Además, XSS por sí no te permite ejecución de código en el servidor, por lo que suele ser sólo el inicio del ataque (no hace el XSS menos importante, pero hay que distinguir claramente). No distinguir entre esas distintas situaciones le hace un flaco favor a la seguridad.
@Rigolox, no veo que ser víctima de un XSS sea un fallo básico: en páginas dinámicas es muy fácil cometer estos fallos, y no hay muchas formas de proteger a los clientes frente a ellos. Sí, está noscript y la protección del IE y desactivar javascript (por listas blancas o no) y todo eso, pero hay que ser realista y aceptar que no todo el mundo sabe protegerse, ni del lado de los desarrolladores ni del de los usuarios. Y no quiero entrar a discutir el tema de la protección anti-XSS de IE, que sigue rota. El XSS es un problema del diseño de HTML que no es tan fácil de resolver como parece.
Totalmente de acuerdo con el anonimo anterior.
Ademas hay que tener en cuenta que este caso es muy muy especial... el sistema permite al atacante enviar un input, el texto del problema, con lo cual la url que se visualizara desde la propia aplicacion. Asegurando asi no solo que el usuario esta previamente logeado en la aplicacion, sino que ademas que no tenemos que "descubrir" cual es su e-mail pues lo visualizara utilizando esta misma aplicacion....
Hola!! pasaba por aquí... interesante noticia, como todas.
Alguien podría 'adornarla' con algunos informes que reflejen cuánto son más vulnerable los 'nativos americanos' de Apache, frente a otros servidores 'no Apache', pero no menos 'americanos' sólo en lo que vá de año?
Ando corto de tiempo.
Gracias por la rápida información. Me la quedo y la cuelgo por ahí.
Buenas,
realmente no me refería al ataque y al XSS, ya que ha sido un ataque muy bien dirigido, sino el abrir así directamente un enlace acortado, sin antes comprobar cuál era realmente el contenido del enlace.
Para más información y en español: http://www.hispasec.com/unaaldia/4190
@Maligno, y te gusto volver a hace 10, 15 o 20 años???? ;P
NaCl u2
@Rigolox
En serio tú abres primero todos los enlaces a tinyurl con el curl e interpretas el HTML antes de usar el navegador? Si es así, te sale más rentable usar el lynx :)
Una alternativa "razonable" contra XSS es usar un perfil (de Firefox, claro :P) distinto (o los modos "porn" de IE, Chrome, etc.) para ver URLs desconfiables. Pero vamos, de un 0-day en el navegador no te salva ni d10x.
Publicar un comentario