martes, 26 de febrero de 2013

China, ciberguerra y el informe Mandiant (I)

Recientemente han aparecido en la prensa noticias sobre la supuesta responsabilidad del Ejército Chino en ataques y robos de información a empresas y organismos. Por supuesto el Gobierno Chino lo ha desmentido.

El origen de esta información ha sido un informe emitido por la empresa Mandiant, especialista en seguridad informática.

Es informe  se puede descargar desde este enlace y sin ser demasiado extenso ni profundo dice cosas muy interesantes y que merecen ser explicadas.

Empieza el informe indicando que lleva investigando desde el 2004 a los grupos más activos en ataques, reconoce que tiene identificados a más de 20, a los que llama APT (Advanced Persistent Thread). Curiosamente la amenza china es el APT1. Lo que es toda una declaración de intenciones de que empezaron por China.
Es de suponer que entre esos grupos APT se encuentren también grupos como Anonymous.
Así define a la APT1

  y más adelante aclara con un organigrama este galimatías.


Poco clara el informe sobre el tamaño de esta unidad. Habla de varios cientos quizá miles de personas con al menos alguna de las siguientes habilidades:


Y las dimensiones de los recursos son espectaculares:

Miles de sistemas dedicados en casi 1000 Centros de Control diseminados en 13 paises, aunque la mayoría de estos centros de control está en la propia china (según demuestran las IP's obtenidas).

Antes de entrar en otras cuestiones indicaré que la mayoría de los ataques están dirigidos a la industria:


Siguiendo un patrón clásico.

En este sentido poca novedad aporta APT1:

  • Reconocer
  • Penetrar
  • Escalar privilegios
  • Mantener el acceso. 

Según la fuente la principal forma de comprometer lo sistemas es mediante ataques de phishing. Sí, sí, la ingeniería social está detrás
APT1 mediante en la fase reconocimiento inicial identifica nombres y personas del objetivo y crea falsas cuentas de correo a través de las cuales se dirige a otros empleados.

¿Quien desconfiaría de un correo dirigido por el CEO de la compañía, usando el lenguaje habitual y todos las firmas, logos e imagén de los correos corporativos?
Y si además tenemos un anexo tan tentador como este:

 Una buena ingeniería social hará que este correo se mande solo a las personas adecuadas y en los momentos adecuadas.

Una vez un sistema está comprometido el siguiente paso es abrir una puerta trasera. Normalmente, y para evitar a los cortafuegos pobremente configurados la puertas traseras son activas, es decir hace que los equipos infectados se conecten al atacante.
Esta técnica también tiene un punto débil: hace más complicado camuflar la dirección IP del atacante. Aunque parece que los amigos de APT1 tampoco eran demasiado escrupulosos en ese sentido porque según dicen en el resumen el 97% de los ataques identificados provenían de direcciones registradas en Shangai.

Este es uno de los puntos que sirven al Gobierno Chino como argumento para negarlo todo. Lo poco determinante que puede ser una dirección IP para demostrar una autoría.

Las siguientes etapas siguen el manual: obtener los hashes de las contraseñas para poder efectuar ataques de fuerza bruta offline, explorar el entorno  y obtener un sitio seguro donde colocar las puertas traseras que nos garanticen el acceso durate el tiempo necesario para sacar la información deseada.

Por no alargarme demasiado doy punto final a este post y deja para un futuro post un estudio de los recursos usados por APT1 para llevar a cabo los ataques.


jueves, 14 de febrero de 2013

Han hackeado mi web... ¿Y ahora qué?

En anteriores post escribí sobre la detección de vulnerabilidades en Joomla ( Post 1 y Post 2)  y como fortalecer nuestra Web en Joomla. Finalizaba este último post con la pregunta que da título al este artículo.

Hemos sido atacados


Hace ya unos cuantos años, bastantes, iba tranquilamente paseando por el Paseo de las Delicias de Madrid cuando sonó mi teléfono.
Un amigo, presidente de una asociación a la que le había confeccionado su web en Joomla.
- Juanma, tío, que nos han hackeado la web.
- Vale cuando llegue a casa lo miro. - dije con falso aplomo porque en realidad no tenia ni puta idea  de lo que podía estar pasando ni de como afrontar el problema.
Ya en casa me conecto a la web navego por unas páginas y no veo nada raro. Llamo a mi amigo para que me de mas detalles. Albergo todavía la esperenza de que sea una falsa alarma.
Me comenta que si se entra desde una búsqueda de Google aparece un mensaje de sitio malicioso. ¡¡­­Bueno una pista!!
Busco el Google la asociación e intento acceder a ella desde el link que me suministra y me aparece una pantalla similar a esta:










­­¡¡¡ufff!! No  me atrevo a seguir.

Arranco una máquina virtual que tengo para experimentos y veo, con mucha alegría, que me lleva a otro sitio web, concretamente del dominio .tk

Me tranquilizo un poco, por lo visto no es mi web la que está marcada como sitio peligroso.

Accedo a otras webs conocidass en Joomla y veo que se accede correctamente.

Llega el momento de hacer la primera recopilación.


  1. Cuando accedo a la web por su URL se llega a la web que, aparentemente esá  bien.
  2. Cuando accedo desde una búsqueda de Google me lleva a un sitio que está  marcado como malicioso.
  3. No parece ocurrir con otras webs escritas en Joomla.

Por humildad he de descartar que alguien haya hackeado Google para perjudicar a la web de la asocación, luego de he pensar que, en efecto, algo tiene mi web que hace que cuando se accede desde Google te redirige hacia otro sitio.

¿Cual es el siguiente paso?


Pues realmente no tenía en esos momentos demasiados conocimientos de Joomla y casi nulos de hacking. En esas condiciones poco más podía hacer que buscar por Google alguna información sobre mi problema.

Busqu‚ en español ( "google me redirige a otro sitio", la URL maliciosa, ) y lo mismo en inglés.

Tras un rato de análisis ya tenía claro como solucionarlo. Se trataba de localizar la siguiente sentencia en el código php:


eval(base64_decode("DQplcnJv..................................................KfQ0KfQ=="));

Los datos de la función no siempre coincid¡an en todas las búsquedas pero era un punto para seguir

Me descargue todo el sitio web a mi m quina virtual y con el comando grep localic‚ el string: eval(base64_decode

A partir de ahí hice una búsqueda en Google más concreta intentando hacer coincidir todo el literal y, no podía ser de otra manera, también la encontré. En este caso coincidía además el sitio malicioso al que te redirigía
Las indicaciones para eliminar el virus eran simples: eliminar esa l¡nea del código php. Aunque no eran muchos los ficheros infectados sí eran los suficientes como para desmotivarme ir eliminando esa línea fichero a fichero.
Con una concatenacion de los comandos find y grep logre eliminar el código malicioso y subir los ficheros limpios.

Una vez realizado esto comprobé que el acceso a través de Google era correcto.

El punto de entrada.


Aunque la web estaba arreglada, seguía sin saber como habia sido infectado el sitio y mientras no supiera eso estaría a merced de un nuevo ataque.

Puede fijar gracias a mi amigo el ataque con una precisión de 24 horas así que me descargué el log de accesos del servidor y me puse a buscar peticiones GET o POST que se salieran de los estándares de joomla y localicé varias de ellas, puse un orden de prioridad a aquellas que me parecían, por simple intuición, mas sospechosas.
Con esa información pregunté en foros de Joomla y me aconsejaron que una vez identificado el componente objeto de la URL sospechosa  consultara en la VEL y así lo hice.

Localicé vulnerabilidades en dos componentes que podían estar relacionadas con el ataque.
Ya tenía una pista de por donde podía haber venido el ataque así que volví a buscar en foros ataques similares al que sufrí y también vi como aparecía que en varios ellos el componente sospechoso estaba en los sitios infectados y además en la misma versión que el que yo tenía instalado.
Sólo me quedaba visitar la Web del fabricante. En su blog reconocía que existía la vulnerabilidad y recomendaba la urgente subida de versión.

Conclusiones.


Antes de seguir he de decir que tuve mucha suerte. Se trataba de un ataque inofensivo, que no compromet¡a la web y de fácil erradicación.

Dada mi poca experiencia en aquellos momentos si el ataque hubiera sido mas sofisticado no habría podido recomponer la situación.

Indistintamente de la complejidad del ataque, de las herramientas y de los conocimientos lo imporatante es el método.
  • Identificar los síntomas del ataque
  • Fijar con la m xima precisión posible cuando pudo ocurrir el ataque
  • Buscar en información sobre el ataque (Google, BB.DD. vulnerabilidades, foros).

Con esta información:
  • Reparar
  • Proteger

Y para finalizar

 Realmente la cosa era menos dramática ya que tenía varias copias de seguridad y lo primero que hice fue verificar que pod¡a recuperar el sistema, pero si lo cuento al principio la cosa pierde interés ;-)