El índice de Google te filtra los autores de documentos privados en Google Drive

Al igual que os conté hace ya mucho tiempo en un artículo que sucedía con Skydrive donde la gente guarda de forma pública de todo, Google está indexando los contenidos de Google Drive y también se puede encontrar de todo. La gente, como viene siendo habitual en estos casos guarda sus documentos personales, sus fotografías e incluso documentos oficiales, por lo que con echar un poco de tiempo se puede encontrar una miriada de información de lo más peculiar.

Figura 0: El índice de Google leakea datos privados de Google Drive

Entre las cosas a buscar, mi compañero Ioseba Palop me dijo que buscando por las cadenas que tienen que ver con el gobierno de USA salen muchos documentos oficiales escaneados - y alguna foto que tal vez no quieras ver - y que basta con hacer un dork como éste [site:drive.google.com USG] para encontrar los docs que te interesan. Cambia las siglas de la organización por las que necesites.

Figura 2: Documentos indexados y compartidos de USG en Google Drive

Si quieres buscar entre las carpetas compartidas con documentos no indexados, puedes buscar que en la URL esté el parámetro folderview como me envió el amigo rootkit. Hay 124.000 carpetas para perder el tiempo rebuscando por allí.

Figura 3: Carpetas compartidas en Google Drive indexadas en Google

El resto del juego ya te lo conoces, rebuscar entre lo que la gente ha dejado público, que puede ser de todo. Es más que conveniente que si velas por la seguridad de tu empresa, mires a ver que documentos han subido de tu empresa, no vaya a ser que te lleves una sorpresa.

La indexación de documentos privados en Google Drive

Además de que se pueda encontrar la información que la gente publica - intencionada o por error - en Google Drive, las opciones de indexación permiten que si Google ha localizado un enlace a un documento privado, este también quede indexado, tal y como sucedía a Gmail o a Dropbox por culpa de las opciones de indexación mal configuradas.

Figura 4: URLs de documentos privados indexados en Google

Cuando esto sucede, ya sabéis que se puede acceder a la info que aparezca en la URL, como por ejemplo el nombre de un fichero, también a la información que pueda sacarse del enlace, que aparece en el título del documento y poco más.

Figura 5: La indexación filtra keywords en el título y el nombre del archivo

Sin embargo, hay un punto que me ha encantado, y es que cuando Enrique Rando (autor del libro de Hacking con Buscadores) y yo dimos la primera charla de Metadatos y FOCA en la BlackHat de hace muchos años hablábamos de que las fugas de información pueden convertirse en metadatos, y que los buscadores podrían crear esos metadatos a partir de ellas. Tienes el paper completo publicado aquí: "Disclosing Private Information from Metadata, Hidden info and lost data with FOCA".

Figura 6: Disclosing Private Information from Metadata, hidden info and lost data

Pues bien, si el documento es un archivo que Google puede indexar y es capaz de localizar el autor del archivo, este también es leakeado en los resultados en forma de metadato, tal y como puede verse en la imagen.

Figura 7: Autor de documento privado en Google Drive filtrado en el índice de Google

Google Drive tiene el mismo problema con la indexación que tenía Gmail, pero a día de hoy los enlaces no han sido borrados todavía como sí fueron borrados en Gmail, así que se pueden localizar cosas curiosas.

Saludos Malignos!

Un Phishing bancario, un Spam en Unicode y la detección temprana

Ayer por la tarde me invitaron a ir a hablar en un programa de televisión sobre las tendencias en el cibercrimen y el fraude online. Una vez más, el tema que salió fue el de los ataques a cuentas bancarias y quiso el destino que me entrara un mensaje de phishing de una campaña de spam que había logrado saltarse el filtro antispam de nuestros servidores de coreo electrónico, así que aproveché dicho ejemplo para la intervención en el programa.

Figura 1: Un Phishing Bancario, un Spam en Unicode y la detección temprana

Este es el mensaje de correo electrónico que se saltó los filtros y hay varios detalles importantes que me gustaría contaros sobre él, ya que no es habitual que me entren este tipo de mensajes en mi inbox, así que os los paso a explicar.

Figura 2: Mensaje de spam con campaña de phishing recibido

Política AntiSpoofing

El equipo de seguridad responsable del dominio santander.com.mx tiene un registro el servidor DNS con una política antispoofing en el correo electrónico basada en SPF1 con valor -all. Esto quiere decir que todo servidor que reciba un correo electrónico de santander.com.mx, si no viene de una de las direcciones IP autorizadas por el registro DNS deberá marcarlo como spam y tirarlo a la carpeta de correo no deseado o directamente a la basura.

Figura 3: Política antispoofing de e-mail en santander.com.mx

En este caso, el correo electrónico ha sido enviado suplantado un subdominio de ese dominio, lo que hace que cuando se consulte la política SPF de ese subdominio el servidor de correo entrante no tiene información para discernir si esta autorizado o no. Esto lo ha aprovechado el atacante para saltarse la protección SPF.

Figura 4: Dirección de correo electrónico suplantada

Las alternativas para detectar esto sería aplicar en los servidores de correo entrantes medidas más exhaustivas en el análisis de correos de subdominios, o establecer políticas restrictivas SPF en todos los subdominios, pero a día de hoy no son eficientes ni 100 % efectivas, por lo que es una puerta que pueden utilizar los phishers. Eso sí, el dominio principal está protegido.

Codificación Unicode Extendida

Como se puede ver en el mensaje, se ha utilizado una codificación de UTF-8 extendida del asunto del mensaje. Esta codificación permite usar caracteres de alfabetos Unicode para lograr un efecto visual similar al que se obtiene con los caracteres con codificación Punycode. 

Figura 5: Asunto en codificación con caracteres del alfabeto Unicode

Si miramos el código fuente se puede ver que el asunto está codificado entre "=?utf-8?B?" y "?=", y si decodificamos con cualquier decoder para base 64 online se obtendrá el asunto que aparece.

Figura 6: Codificación Unicode UTF-8 del asunto

Este truco ayuda a evitar que los filtros basados en cadenas como "Banca" "Acceso a Banca" o "Bloqueado" detecten cualquier mensaje de correo que esté siendo procesado automáticamente.

Detección temprana

Una de las cosas que piensa la gente es que es fácil para los ladrones de estos sitios conseguir extraer dinero rápido con estos ataques de phishing, pero lo cierto es que cada vez lo tienen mucho más complicado. En este caso, la URL de la web tiene un phishing del Banco de Santander en México, y es bastante aparente.

Figura 7: Sitio web de Phishing

Yo notifiqué este phishing a nuestro equipo de Antifraude interno y me confirmaron que ya lo habían detectado y que tras comprobar que era un phishing activo, se había reportado automáticamente a las casas de antimalware, los servicios antifraude de navegadores y a las bases de datos de seguridad de nuestras alianzas. A los minutos ya estaba marcado en Google SafeBrowsing, como se puede ver.

Figura 8: Al los pocos minutos ya estaba detectado y bloqueado

Todos los que navegaran con Google SafeBrowsing activo ya recibirián una alerta de seguridad como la que puede verse a continuación, limitando el impacto de este phishing muchísimo.

Figura 9: Alerta de seguridad de phishing

Hoy ya está detectado, según Virus Total, también por un buen número de antivirus, lo que limita aún más su posible efectividad.

Figura 10: Detectado como Phishing por más escaners

Protecciones extras para evitar el uso de credenciales robados

Los equipos de seguridad de banca tienen además un buen número de controles para detectar que una credencial ha sido robada en el momento en que se quiere hacer una transacción. Muchos de ellos se basan en el análisis de hábitos de conexión de una determinada cuenta para saber si hay alguna anomalía. Para ello se hace un scoring de cada transacción y se comprueba que es un uso habitual desde una ubicación habitual por lo que si algo cambia, se bloquea la transacción.

Figura 11: Bloqueo de credenciales y transacciones en Caja Mar

Además, los sistemas tienen sistemas de firma de transacciones y protección de cuentas. Habitualmente han usado la famosa tarjeta de coordenadas, pero desde Europa ya se ha dado muerte a este sistema, por lo que muchos bancos pasan al uso de sistemas de firma de transacciones usando OTPs derivados de los datos de la transacción o plataformas como Latch. En el caso de todas las cajas del Grupo CajaMar, por ejemplo, además de proteger la cuenta se pueden restringir las transacciones, por lo que un acceso para consultar no podría realizar la transacción. 

Recomendaciones finales

Aun así, conviene recordar a todo el mundo que los ataques de phishing suelen llegar por e-mail así que no hay que pulsar en ningún enlace, y que el robo de credenciales bancarias más peligroso sigue siendo el de los troyanos bancarios que hacen Man in the Browser, por lo que lo mejor es que tengas un cuidado exquisito de tu equipo de trabajo y lo tengas fortificado al máximo para evitar cualquier sorpresa.

Saludos Malignos!

Una primera prueba en Windows 10 con un Acer Aspire V Nitro: Spartan, Privacidad, AppContainers, FIDO y Latch

Durante el pasado Mobile World Congress 2015 en Barcelona tuve la suerte de cenar con Satya Nadella - actual CEO de Microsoft y su equipo. En la cena, entre otros muchos temas, hablamos mucho de Windows 10 y la nueva estrategia de experiencia de uso e interfaz continuo entre smartphones, tablets, latptops, equipos de escritorio y servidores, además de las famosas Hololens. En aquel momento no había tenido la oportunidad de ponerle las manos encima y estaba esperando una buena ocasión para hacerlo y revisarlo por encima. No quería probarlo en una máquina virtual, así que esperé a tener una buen equipo disponible para probarlo.

Figura 1: Una primera prueba en Windows 10 con un Acer Aspire V Nitro

Para la ocasión he tenido la oportunidad de probar Windows 10 Technical Preview instalado en un equipo portátil que más parece un servidor portátil. Creo que la comparación habitual esa de "con la potencia de ese equipo la Nasa llevó el hombre a la luna" se queda corta con el portátil Acer con el que he probado esta versión Windows 10.

Figura 2: Con Satya Nadella en el MWC 2015

El equipo en el que lo he probado es un Acer Aspire V 15 Nitro, y es algo así como un servidor portátil pensado para los gamers más que para alguien que está viajando de un lado a otro con el equipo en la mochila como yo, aunque a pesar de ser de 15" no pesa demasiado. Eso sí, es un lujo la pantalla 4K Ultra HD de 3840x2160, el Intel Core i7, los 16 GB de Ram y la GeForce GTX 860M así que si os digo que Windows 10 Technical Preview vuela en esta máquina debéis creerme, pero no sé si es por el hardware donde lo he probado o porque el sistema realmente está más acelerado.

Figura 3: Acer Aspire V 15 Nitro usado en esta prueba 

Con el sistema instalado, tenía ganas de juguetear un poco con la experiencia. ya sabéis que una de las novedades principales es la vuelta del botón de inicio que podéis ver en la figura 1, pero además se han anunciado un nuevo navegador de Internet, llamado Proyecto Spartan aún. El aspecto es el que tenéis a continuación, y parece mucho más centrado en dotar a los desarrolladores y usuarios avanzados de todas las herramientas que habitualmente se utilizan para hacer análisis de las tecnologías web. La impresión que me ha dado es que aún le falta mucho que madurar, ya que se nota falto de depuración de usabilidad y trabajo natural, pero la mayoría de las herramientas que lo acompañan funcionan bien.

Figura 4: Proyecto Spartan en Windows 10

Otra de las características que se han anunciado es la compartición de apps entre todas las plataformas que, sumada a la experiencia continua de uso entre diferentes plataformas, trae consigo la inclusión de características de configuración basadas en la interfaz del "antiguo" Windows Phone. Para encontrar Windows Defender tuve que buscar un rato el enlace que abría el interfaz clásico del antimalware de Windows.

Figura 5: Configuración de herramientas con interfaz nuevo

Para que las apps puedan correr en todos los sistemas, en Windows 10, al revisar los Integrity Levels de las apps, se puede ver que viene como AppContainer. Esta contenedor es la máquina virtual que abstrae a la aplicación del hardware, permitiendo que se ejecute en cualquier plataforma. Es decir, es una especie de virtualización de apps dentro del sistema. Como se puede ver con Process Explorer - que no viene por defecto - Proyecto Spartan viene ya en este formato para que la experiencia pueda ser continua.

Figura 6: Revisando Spartan con Process Explorer y Virus Total

Como curiosidad envié a Virus Total - aprovechando la integración que se hizo con Process Explorer - a ver si algún antimalware tomaba esta aplicación que debe abrir tantas conexiones de red como maliciosa, pero no, como era de esperar.

Figura 7: Opciones de privacidad en Windows 10

La integración con la las opciones de configuración del interfaz de Windows Phone, trae cosas curiosas, como que se puede gestionar la privacidad de las aplicaciones, sobre todo el acceso al micrófono, la localización, los contactos, etcétera, para todas las apps desde Windows 10.

Figura 8: Task Manager en Windows 10

No todas las opciones de configuración están en el mismo sito, y la impresión que da por ahora es que las cosas se pueden configurar en los lugares clásicos de configuración de todo Windows, en las opciones del nuevo interfaz de experiencia continua y en lugares residuales aún en las opciones de interfaz Moderm que aún utiliza Windows 8.1 por lo que estaría bien que acabaran unificándose en un único punto.

Figura 9: Opciones de Windows SmartScreen

En cuanto a las opciones de seguridad pura y dura, Windows 10 se ha anunciado como FIDO compliance, o lo que es lo mismo, que permitirá autenticación con 2FA haciendo un pareado de dispositivos móviles. Sin embargo, cuando fui a ver las opciones que me permitía mi instalación, el resultado fue que por ahora las mismas de siempre. Password, PIN o Password Picture como en Windows 8 y Windows 8.1. No trae por defecto las opciones de autenticación fuerte para Windows que por ejemplo tenemos en SmartID.

Figura 10: Opciones de autenticación de cuentas en Windows 10 Technical Preview

Como al final Windows 10 sigue siendo Windows, decidí probar a poner Latch para Windows para proteger con un 2FA mi login en Windows 10. El resultado fue que en un minuto de reloj había descargado Latch para Windows x64, creado una aplicación rápida en Latch, configurado el ApplicationID y el Secret para parear mi cuenta. Todo perfecto y sin problemas.

Figura 11: Latch para Windows x64 en Windows 10

La verdad es que lo mejor de todo ha sido la experiencia de probar el portátil, que va como un tiro, pero no he podido configurar muchas cosas, como las nuevas actualizaciones de seguridad que permitirán updates fuera de ciclo - sobre todo para las apps -, las nuevas opciones de biometría, o el famoso FIDO.

Figura 12: VPN SSTP en Windows 10 Technical Preview

Por lo demás, sigue siendo un Windows y todas las opciones de fortificación y seguridad de Windows siguen estando presentes, incluso las VPN SSTP que se instalaron en Windows Vista SP1 y que aún no están disponibles de serie en OS X. Ya os contaré más adelante cuando haga más pruebas.

Saludos Malignos!

Cómo usar Latch para proteger el acceso a sitios web de la Intranet publicados en Internet en un servidor Nginx

La idea de esto surge de la necesidad de poder habilitar bajo demanda la publicación de sitios en mi red hogareña a Internet de una forma simple. De esta forma se evita tener habilitados todo el tiempo en Internet servicios que se usan de forma esporádica, bajando la probabilidad de cualquier intento de acceso no autorizado. Una idea muy sencilla que pretende reducir la superficie de exposición temporal de un servicio en Internet para fortificar un servidor GNU/Linux.

Figura 1: Cómo proteger sitios en NGINX con Latch

¿Qué sale un 0day para las tecnologías que soportan el sitio? Solo tengo que esperar a parchearlo y volver a abrir el acceso. Para hacer esto utilizo Latch y un script que actualiza la configuración del webserver usado como Proxy Reverso que en mi caso es un servidor Nginx. Este es el proceso completo y los scripts que yo he utilizado para montar esta arquitectura de seguridad que publica y des-publica los sitios usando Latch.

Prerrequisitos para instalar el entorno

• Python
• Una cuenta de desarrollador del Latch
• Una cuenta de usuario del Latch
• La librería con el SDK de Latch para Python
• WebServer de su elección: Puede ser Apache Http Server, Nginx, o cualquier otro,  configurado para actuar como Proxy Reverso.
• Un rato de tu tiempo

Antes de ponernos con el paso a paso, les cuento que no tengo experiencia en Python por lo que seguramente encontraran formas más elegantes o eficientes de hacer esto, son bienvenidos los comentarios constructivos.

Integrar Latch con el Servidor Nginx: Creación de la app Latch

• Generar una cuenta de desarrollador de Latch: Una vez que tengas una cuenta de Latch, puedes convertirla en una cuenta de desarrollador. Si quieres proteger esta cuenta, ya sabes que también puedes por Latch a los accesos a Latch.

Figura 2: Poner Latch a la cuenta de desarrollador de Latch

• Generar una aplicación: El proceso es sencillo. Esto se hace primero haciendo clic en Mis Aplicaciones.  Luego en el botón Añadir una nueva aplicación. En esa parte del proceso 

Figura 3: Creación de una aplicación en Latch

• Le asignamos un nombre. En mi ejemplo: Mis Webs y luego tomamos nota de los campos remarcados (Id de aplicación y Secreto). Los necesitaremos para aparear nuestra aplicación cliente (en el celular) y el script.

Figura 4: Creación de la aplicación en Latch

Integrar Latch con el Servidor Nginx: Pareo de la aplicación con cuenta Latch

Para parear la aplicación se puede utilizar este pequeño usamos este script de Python que hace el proceso con un sencillo menú para interactuar.

pair.py:

import os
import json
import latch
appid = input("Ingrese el Applicatrion ID:")
seckey = input("Ingrese Secret Key:")

api = latch.Latch(appid,seckey)
pair_code = input("Ingrese el Pairing Code entregado por su celular:")
response = api.pair(pair_code)
responseData = response.get_data()
responseError = response.get_error()

print "Respuesta: ", responseData
if responseError != "" :
 print "Error:" , responseError

try:
    salida=json.dumps(responseData)
except (TypeError, ValueError) as err:
    print 'ERROR:', err

Antes de ejecutar el script debemos iniciar sesión en la aplicación de Latch en el terminal móvil con nuestra cuenta de usuario de Latch y marcar en la opción inferior, Añadir nuevo servicio y luego en el botón: Generar nuevo código. Cuando tengamos el código temporal de pareado visible lanzamos el script pair.py:

~/latch $ python pair.py
Ingrese el Applicatrion ID:"*****hqH3usJ4"Ingrese Secret Key:"j32mbXBfhHUyn*******************CrF"Ingrese el Pairing Code entregado por su celular:"*****Asqg"Respuesta: {u'accountId': u'7z3ZTP6p2H3***************************cHaYwmRQyHrk6JYae'}

Si este paso no muestra errores, la aplicación del terminal móvil indicará que hay un nuevo servicio asociado a nuestra cuenta de Latch. De esta forma hemos apareado la aplicación (nuestro script), con nuestra cuenta de Latch. Tomen nota del accountID, lo necesitaremos más adelante.

Figura 5: Cuenta de Latch pareada con la aplicación

Integrar Latch con el Servidor Nginx: Reverse Proxy permitido o denegado

Llegados a este punto, ya estamos listos para configurar el script que se ejecutara de forma recurrente, cada n minutos por crontab en mi caso, pero que cada uno puede configurar a su gusto. La lógica de este script es:

• Consultar el estado del Latch
• En base al cambio de estado del Latch manipularemos los archivos de configuración de Nginx para que opere como un Proxy Reverso o simplemente como una web con autenticación http.
El primer paso para hacer funcionar este script es reemplazar las tres variables appid, seckey (provistas por la web de latch) y el accid (accountId que anotamos al momento del pareo de la aplicación).
• Luego debemos generar un archivo de configuración de Nginx que bloquee el acceso y otro que lo habilite.

 A continuación un archivo de configuración que configura el Proxy Reverso:

/etc/nginx $ more rproxy.conf.allow

server {
    listen            80;
    return 301 https://$host$request_uri;
}
server {
    listen            443;
    server_name       xxxx.com;

    # Change this to the location you installed lirc_web
    root              /home/nginx/web;
    index             index.html index.htm;

    access_log        /var/log/SSL-rproxy.nginx.log;
    ssl on;
    ssl_certificate /etc/nginx/ssl/server.crt;
    ssl_certificate_key /etc/nginx/ssl/server.key;
    ssl_session_cache  builtin:1000  shared:SSL:10m;
    ssl_protocols  TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
    ssl_prefer_server_ciphers on;
    location / {
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_set_header X-NginX-Proxy true;
        proxy_pass https://sitiointerno:443/;
        proxy_redirect off;
    }
    error_page 401 /401.html;
    location ~ (401.html)$ {
      alias /usr/share/nginx/www/$1;
    }

}

Y este que lo inhabilita forzando a autenticarse :

/etc/nginx $ more rproxy.conf.deny

server {
    listen            80;
    return 301 https://$host$request_uri;
}
server {
    listen            443;
    server_name       x.x.x.x;

    # Change this to the location you installed lirc_web
    root              /home/pi/web;
    index             index.html index.htm;

    access_log        /var/log/SSL-rproxy.nginx.log;
    ssl on;
    ssl_certificate /etc/nginx/ssl/server.crt;
    ssl_certificate_key /etc/nginx/ssl/server.key;
    ssl_session_cache  builtin:1000  shared:SSL:10m;
    ssl_protocols  TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
    ssl_prefer_server_ciphers on;
    location / {
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_set_header X-NginX-Proxy true;
        proxy_pass https://sitiointerno:443/;
        proxy_redirect off;
        auth_basic "Restricted";
        auth_basic_user_file /etc/nginx/.htpasswd;
    }
error_page 401 /401.html;

location ~ (401.html)$ {
    alias /usr/share/nginx/www/$1;
    }
}

Integrar Latch con el Servidor Nginx: Consulta del estado de Latch

Con todos los puntos anteriores revisados y preparados, ya podemos correr este script para confirmar el estado de nuestro Latch:

estado.py:

import os
import json
import latch

appid = "[reemplazar por application id]"
seckey = "[reemplazar por Secret Key];"
accid = "[Reemplazar por account id]"

api = latch.Latch(appid,seckey)
response = api.status(accid)
responseData = response.get_data()
responseError = response.get_error()

#print "Respuesta: ", responseData
if responseError != "" :
 print "Error:" , responseError

try:
    salida=json.dumps(responseData)
except (TypeError, ValueError) as err:
    print 'ERROR:', err

response = json.loads(salida)

estado = response['operations'][appid]['status']
print "Estado:", estado
if estado == "on" :

 print "Ejecutando script de habilitación de Proxy Reverso"
# os.system("diff /etc/nginx/conf.d/rproxy.conf /etc/nginx/rproxy.conf.deny -q >/dev/null && sudo cp -p /etc/nginx/ rproxy.conf.allow /etc/nginx/conf.d/ rproxy.conf && sudo service nginx reload")

else:

 print "Ejecutando script de bloqueo de Proxy Reverso"
# os.system("diff /etc/nginx/conf.d/rproxy.conf /etc/nginx/rproxy.conf.allow -q >/dev/null && sudo cp -p /etc/nginx/rproxy.conf.deny /etc/nginx/conf.d/rproxy.conf && sudo service nginx restart")

Si el resultado es el esperado:

$ python /home/pi/latch/estado.py
Estado: off
Ejecutando script de bloqueo de Proxy Reverso

En este punto sólo es cuestión de descomentar las líneas del script estado.py donde se toma acción sobre el servidor Nginx:

print "Ejecutando script de habilitación de Proxy Reverso"# os.system("diff /etc/nginx/conf.d/rproxy.conf /etc/nginx/rproxy.conf.deny -q >/dev/null && sudo cp -p /etc/nginx/ rproxy.conf.allow /etc/nginx/conf.d/ rproxy.conf && sudo service nginx reload")

else:

 print "Ejecutando script de bloqueo de Proxy Reverso"# os.system("diff /etc/nginx/conf.d/rproxy.conf /etc/nginx/rproxy.conf.allow -q >/dev/null && sudo cp -p /etc/nginx/rproxy.conf.deny /etc/nginx/conf.d/rproxy.conf && sudo service nginx restart")

Por último, ya solo quedaría agregar nuestro script al crontab o similar. En este punto hay algo  que debes tener en cuenta. Si llegaste a este punto puede que te estés dando cuenta de algo muy molesto está pasando con tu terminal. Cada consulta sobre el estado del Latch (cuando este está bloqueado) nos dispara una notificación de intento de acceso no autorizado. Esto es parte de la seguridad de Latch y por ahora no existe la forma de “silenciar” las alertas de un Latch en particular. Como workaround en la configuración de Android he deshabilitado las notificaciones de la aplicación.

Autor: Gonzalo Trancillo

Nota de Chema Alonso: Desde Eleven Paths estamos trabajando en un sistema de silenciado de alertas para evitar el flooding de notificaciones en escenarios como éste. En la modalidad Silver de Latch - que puedes tener gratis si eres una Pyme Española, está disponible vía API la consulta silenciosa.

Web Browser Cache Snooping para espiar tu ubicación GPS

Durante la pasada BlackHat Asia 2015 se publicó un trabajo bastante curioso que tenía ganas de echar un vistazo. La investigación en sí se llama "I Know Where You’ve Been: Geo-Inference Attacks via the Browser Cache" y tiene como objetivo intentar saber en qué país, en qué ciudad o incluso en qué barriada estás mediante la exploración de los objetos que tienes en la caché de tu navegador.  El funcionamiento de estas técnicas es sencillo, pero merece la pena mirar unos detalles.

Figura 1: Web Browser Cache Snooping para espiar tu ubicación GPS

Para que sea fácil de entender, cuando vas a un sitio popular que está en Top 100 de Alexa, estos servidores te entregan unos u otros archivos dependiendo de tu ubicación geográfica. Una página maliciosa podría intentar cargar en su página esos recursos y en función del tiempo que haya tardado el navegador en hacerlo saber si lo tenías en la caché o no. Si lo tenías, significa que es porque estás en una determinada ubicación.

Figura 2: WhitePaper de los investigadores sobre Geo-inferencia por exploración de caché

En el paper, utilizan como ejemplo tres sitios principales, que son Google,  Craiglist y Google Maps. El primero de ellos entrega unos recursos u otros en función de país en el que estés, el segundo lo hace dependiendo de la ciudad en la que estés y el último en función de la barriada en la que te encuentres, por lo que si es posible identificar un archivo de Google Maps en la caché de tu equipo se podría saber dónde estás, si se hace con Craiglist se podría saber en qué ciudad te encuentras y con Google Maps en qué país estás.

Figura 3: Con Google, Craiglist y Google Maps se puede ubicar tu zona GPS

La pregunta  es, ¿cómo localizar si un archivo está o no en la caché? La parte sencilla es medir el tiempo de carga de un recurso en una página maliciosa. Vamos a suponer que Google entrega una imagen llamada Google_ES.jpg cuando visitas Google.com desde España. Ahora entras a una página con contenido externo que quiere saber si estás en España o no, para ello hace un procedimiento que carga contenido externo, haciendo algo como esto:

Figura 4: Geo-inferencia por carga de imagenes

Si el tiempo de carga es grande, entonces es que ha ido a pedirla a los servidores de Internet, pero si el tiempo es pequeño, entonces es que ya estaba en la caché y por tanto es porque lo había visitado recientemente. Esta técnica se basa en las mismas ideas que los ataques de DNS Caché Snooping, con la gracia de que este caso sería equivalente a leer el valor Country de una cookie.

Figura 5: Carga de resultados de XMLHttpRequest generando error de CORS

Para explorar la ubicación, también se pueden utilizar las políticas de Croos-Origin Request Sharing. Google no permite hacer que otras webs lean resultados de XMLHttpRequests desde otras páginas, el tiempo de obtención del error permite saber si esa respuesta ya estaba en la caché o no, lo que de nuevo, al ser distinta por cada ubicación permite saber en qué sitio estaba.

Figura 6: Diferencias en tiempo de generación de error entre documento en caché o no cacheado

La última de las técnicas consiste en acceder a la lista completa de las propiedades de una imagen y ver la diferencia en el tiempo de carga, para saber si estaba o no en la caché del navegador.

Figura 7: Cálculo de tiempo de carga de propiedades de una imagen

Al final, se trata siempre de intentar acceder a un recurso y ver cuál es la diferencia entre el tiempo de acceso cuando el recurso está y cuando el recurso no está en la caché. Esto aplicado con Craiglitst permite discernir en cuál de las 171 ciudades en que es diferente el sitio se ha estado conectando.

Figura 8: Cálculo de tiempo de iframe cacheado o no de Craiglist

Y lo mismo con Google Maps, que si se accede desde una determinada ubicación, el recurso que se carga deja en la caché un fichero con las coordenadas de la barriada, permitiendo saber tu ubicación.

Figura 9: Cálculo de imágenes de recursos de Google Maps a cargar según ubicación GPS

Según los investigadores, el 62 % de los sitios del TOP 100 de Alexa tienen recursos dependientes de la información Geográfica que pueden ser descubiertos en la caché con estas técnicas y por tanto descubrir tu ubicación. Por supuesto, si borras la caché o usas el modo de navegación incógnito o privado que borra en cada sesión el contenido de la caché, esto es poco útil. Aquí tienes un vídeo de cómo funcionan estas técnicas en una demostración.

Figura 10: Vídeo demostrativo de Geo-inference por caché (visto en hackplayers)

No obstante, para las empresas que se dedican a dar servicios de WebBrowsing Fingerprinting puede ser muy útil, ya que conseguir el scoring de un transacción web en escenarios de Malware-in-the-Browser podría ser útil o para cuando una persona utilice un navegador para comprar con tarjetas fraudulentas o robadas desde ubicaciones extrañas.

Figura 11: Técnicas y navegadores afectados

Las técnicas, como bien indican los investigadores son útiles en los principales navegadores de Internet, incluyendo TorBrowser.

Saludos Malignos!

Cómo sacarle partido a Google Index Retriever: Black SEO, Redes Sociales y Pentesting

Ayer por fin, después de un largo proceso de trabajo liberamos una herramienta que teníamos hace tiempo en la cola de salida de Eleven Paths. La utilidad es Google Index Retriever, de la que yo hablé en la charla de "No me indexes que me cacheo" el año pasado cuando explicaba la cantidad de cosas que se puede sacar del índice - no de la caché - de Google.

Figura 1: Cómo sacarle partido a Google Index Retriever

Ahora ya está disponible para su descarga desde la web del laboratorio de Eleven Paths y la puedes utilizar, pero para que sepas cómo sacarle partido te dejo aquí unos casos de uso.

Recuperar un contenido que ya no está

Este es el caso más fácil de entender, para ello basta con que selecciones un dork en Google que haga que solo se obtenga un resultado y luego dar al botón de Start. La idea es que utilizando todas las palabras que vayan apareciendo en el contenido de los resultados se irá intentando extraer más y más datos con el objeto de ver qué cosas distintas se pueden extraer.

Figura 2: Descargando los resultados del índice de Google

Un caso de uso claro de esto es por ejemplo un fichero de configuración, un mensaje de error o un documento que haya sido borrado. El caso de Evernote que yo contaba es un claro ejemplo de esta utilidad, donde un fichero de credenciales se había quedado en el índice de Google.

Descubrir una campaña de Black SEO en una URL

Para conseguir ver si un sitio web ha sido infectado con alguno de los habituales del BlackSEO, como la viagra, el software pirata, etcétera, hemos metido una utilidad que hace búsquedas con diccionario de hot-topics para sacar los datos que están en el índice.

Figura 3: Buscando BlackSEO en una web infectado.

Esto es útil porque ver esos datos suele ser complejo al usar técnicas de Cloaking que ocultan los datos reales a todos menos a los buscadores. Un ejemplo de este uso lo tenéis en el artículo que os publiqué sobre la web del Albacete Balompié.

Figura 4: Personalización de las keywords para hacer el ataque de diccionario

Las keywords que se utilizan se pueden configurar, por lo que se puede ajustar a cada caso. Además, los resultados que se obtienen se pueden exportar, para procesar en otros sistemas.

Contenido "privatizado" o "eliminado" de redes sociales

Con esta utilidad se puede hacer lo que veíamos ayer mismo, es decir, buscar posts en Facebook, tuits de Twitter o publicaciones en cualquier red social que hayan sido privatizadas o eliminadas de su ubicación original.

Figura 5: Datos extraídos de un post privatizado de Facebook

Tanto con la extracción directa del índice de Google usando los resultados, como con la opción de spam se podrían sacar muchas partes del contenido almacenado de esa publicación en el índice. Desde aquí puedes Descargar Google Index Retriever.

Saludos!

Facebook: Cómo ver posts privados o borrados que alguna vez fueron públicos

Ya hace tiempo que dediqué un artículo a los problemas que Facebook estaba teniendo con la indexación en Google. Uno de los lectores (gracias Manfred) , haciendo unas búsquedas en Google se dio cuenta de que los posts de una cuenta de Facebook que habían sido publicados de forma privada, había acabado en el índice de Google, por lo que me preguntó por cuál podría ser la explicación. Cuando conseguí sacar unos minutos de aquí y otros de allá, me puse a mirar a ver qué podría estar pasando, y éstas son las conclusiones.

Figura 1: Facebook: Cómo ver posts privados o borrados que alguna vez fueron públicos

Facebook y la indexación de resultados

Desde que publiqué el artículo sobre la indexación de Facebook en Google si que he visto que, al igual que hizo el equipo de Gmail, se han preocupado de borrar los datos de los correos electrónicos de por ejemplo la URL confirmemail.php, aunque parece que lo hacen manualmente ya que aún aparece un enlace en el índice de Google.

Figura 2: Dirección de correo electrónico de Facebook indexada en Google

Conociendo que todavía se podría indexar contenido de Google aunque estuviera protegido por robots.txt, es decir, que las páginas no vienen con la etiqueta noindex, pensé que esto podría ser el principal motivo. En el caso concreto de este usuario, al buscar sus posts de Facebook indexados en Google, a mí me salían dos.

Figura 3: Dos posts indexados en Google a los que no se puede acceder públicamente

La primera opción que pensé, al ver que cuando se intenta entrar a esos posts no se puede, es que estuviera ya borrados y listo, pero eso valdría para cuando el post hubiera sido borrado, y no para cuando el post estuviera en modo privado, como es el caso que nos ocupa tal y como me lo confirmaron.

¿Tendrá algo que ver Twitter?

En este caso, al buscar por la URL que Facebook utiliza para publicar los posts de un perfil, aparecen dos posts en los resultados qué, al intentar acceder a ellos no vamos a poder. Facebook, como se puede ver en el mensaje de error nos dice que no tenemos permisos.

Figura 4: Facebook dice que puede ser simplemente un tema de permisos

Como Google tiene los datos en el índice, entonces se puede hacer una extracción de los datos manualmente - como ya os conté en el caso de las passwords de Evernote - o con alguna herramienta automatizada como Google Index Retriever que automatiza este proceso. Al final, se puede acceder al contenido que, actualmente sigue estando en Facebook pero protegido por los permisos. 

Figura 5: Volcado del contenido del índice de Google de una URL con Google Index Retriever.
En este caso el contenido es del tamaño de un tweet, así que se ve completo en los resultados de Google.

Mirando los dos posts que están en el índice y no se tiene acceso a ellos se puede ver que ambos cumplen que han sido "retweeted", es decir, que alguna de las personas que sí tenían acceso a esos posts retwetearon el contenido del posts. Esa podría haber sido una explicación a este caso. Al tener acceso Twitter se podría generar una previsualización del post y estos datos son los que Google podría indexar, pero como se puede ver el contenido en los resultados de la búsqueda, parece que Google ha tenido acceso a indexar la página completa.

El que haya sido retwiteado favorece a que Google lo indexe antes, pero no a que indexe algo privado. Como os podéis imaginar, acceder con el USER-Agent de Google Bot a esos posts hubiera sido muy sencillo para saltarse la seguridad de Facebook, y claro está, eso no funciona.

¿Será un fallo de configuración de Facebook?

Además, en el momento inicial del caso existía un tercer post indexado también en Google, que no había sido retweeteado por nadie, lo que anularía la explicación de la interacción de Twitter en toda esta figura.

Figura 6: Caso inicial con tres posts privados indexados en Google

Esto lleva a otra explicación más sencilla aún. Podría ser que el post fuera publicado inicialmente en abierto, y luego se cambió el estado. Mientras que esto se producía, Google accedería al contenido y lo indexaría. Esta explicación parece la más factible, teniendo en cuenta que en el momento inicial del caso, había un tercer post que no había sido compartido en Twitter.

Sea como fuere, estar en Google Index, están

Sea como fuere este caso demuestra que las opciones de indexación que tiene Facebook permiten que si un posts ha sido publicado en algún momento en abierto y luego se ha cambiado su estado, se pueda extraer el contenido del post directamente del índice de Google con una sencilla búsqueda por la URL de posts, es decir, site:facebook.com/[nombre de la cuenta]/posts. Haciendo un poco de Hacking con Buscadores se puede ver que hay muchos miles, de ellos, [a pesar de que si buscas cualquier cosa siempre salgan primeros los de Google+].

Figura 7: Posts de Facebook indexados en Google

Recuerda que si esa personas se cambia el nombre puedes saber qué nuevo nombre se ha puesto si guardas el ID que se obtiene con el servicio Graph, así que si quieres ver los privados que alguna vez fueron públicos con todos los nombres de cuenta que usara, solo debes buscar en Google a ver qué sale con todas esas cuentas.

Figura 8: Acceso al ID de una cuenta Facebook con Graph

Esto también aplica a posts públicos que hayan sido borrados, así que si estás en un caso judicial, en el que ese post privado o borrado sea importante, recuerda que puedes utilizar eGarante para certificar la página de resultados de Google que te interese, aunque ya no está el posts disponible en Facebook para ti. Y todo esto, sin necesidad de utilizar las falsas apps mágicas para hackear Facebook o tener que robar la cuenta de Facebook en un descudio.

Saludos Malignos!