Publicada guía de referencia de NMAP 6

En Security Art Work hemos hablado mucho acerca de Nmap. Hemos comentado algunas de sus características, y novedades en sus últimas versiones (aquí y aquí); hemos visto ejemplos de su uso, desde el más habitual como escáner de red y herramienta de fingerprinting hasta usos más avanzados, para detectar vulnerabilidades y realizar ataques; hemos comentado otros aspectos de la aplicación; e incluso hemos hablado de cómo defendernos ante posibles escaneos de terceros.

A pesar de la popularidad de que goza Nmap, y de su gran comunidad de usuarios, a veces es difícil encontrar información concisa, y sobre todo, en español, de algunas de sus funcionalidades.

Si bien es cierto que existen varios listados de comandos o guías de referencia rápida (también conocidos como chuletas o cheatsheet, en inglés), siendo uno de los más populares por nuestras tierras el de SecurityByDefault para Nmap 5, su contenido es básico, aunque no por ello deja de ser muy útil.

Es por ello que desde CSIRT-cv hemos publicado un listado de comandos (cheatsheet) para Nmap 6, realizado por José Luis Chica (@BufferOverCat) y un servidor (@jovimon). En ella se puede encontrar un listado extensivo de todas las opciones que tiene la última versión de Nmap, con una pequeña descripción de su funcionamiento y observaciones, consejos sobre su uso o incluso en algunos casos el significado de los valores devueltos por la aplicación.

A pesar de no tratarse de un cheatsheet al uso, ya que ocupa un total de 6 páginas, el objetivo de este listado de comandos es servir de guía de consulta rápida sobre las características y el funcionamiento de Nmap 6. Vamos, lo que vendría a ser un nmap –help pero con un formato, con información adicional que ayude a entender el funcionamiento de cada parámetro y, lo más importante, en castellano.

Podéis obtener el documento en el portal de CSIRT-cv. También podéis ver más guías y documentación en su sección de descargas.

Esperamos vuestros comentarios.

Descifrando contraseñas con hashcat

Hoy le toca el turno a hashcat, una aplicación para obtener contraseñas a partir del hash de las mismas. Esto puede ser de utilidad cuando, en la realización de una auditoría, nos encontramos con una base de datos o un fichero que guarda credenciales cifradas de usuarios.

Tuve la oportunidad de probar hashcat hace unos días, y la verdad es que quedé gratamente sorprendido. Algunas de las características más destacables en mi opinión son:

  • Viene precompilada y optimizada para Windows, Linux y OSX, con versiones de 32 y 64 bits, evitando retrasos y problemas de compilación.
  • Su versatilidad. Tiene soporte multihilo, soporta muchos algoritmos (más de 50) y permite modos de trabajo avanzados utilizando reglas o tablas de permutación, entre otros.
  • Es muy ligera. Los hilos que se encargan del grueso de trabajo corren a una prioridad baja, por lo que puedes seguir utilizando el equipo mientras está procesando.
  • Tiene una versión que utiliza la tarjeta gráfica (GPU) para las operaciones de cómputo, lo que permite acelerar mucho el proceso de obtención de las contraseñas. Para probar su rendimiento la puse a descifrar contraseñas de Joomla! con mi equipo personal (Phenom II 955 y una ATI HD5770 con 1GB de memoria) y pasé, utilizando 2 cores de la CPU, de 11 millones de pruebas por segundo a más de 1400 millones utilizando la GPU. La única «pega» es que esta versión no está para OSX.

Si queréis descargarla u obtener más información podéis pasaros por la web de la versión «clásica» (la que utiliza la CPU). Para GPU dispone de dos versiones: oclhashcat-plus, que soporta más métodos de cifrado y entornos más grandes, y oclhashcat-lite, más básica.

La aplicación clásica tiene muchas opciones, pero vamos a enumerar las más comunes, que nos serán suficientes en la mayoría de los casos.
Una línea de órdenes genérica tiene esta pinta:

<ejecutable -hashcat> [opciones] fichero-hash [mascara|diccionario|directorio]

Como fichero ejecutable elegiremos el que corresponda a la distribución elegida (p. ej.: hashcat-cli32.bin o oclHashcat-plus64.exe).

De entre las opciones, destacan las siguientes:

  • -n <num> Número de hilos a utilizar (solo versión para CPU).
  • -m <num> Tipo de hash a descifrar. El listado completo aparece al mostrar la ayuda.
  • -a <num> Tipo de ataque a realizar. Generalmente utilizaremos ataque por diccionario (por defecto, a=0) o por fuerza bruta (a=3). Listado completo en la ayuda.
  • -o <fich> Fichero donde guardar los hash descifrados.
  • -c <num> Tamaño de la caché en RAM del diccionario, en MB.
  • -[1-4] <valor> Definición de conjuntos de caracteres personalizados, si queremos acotar los posibles caracteres que tendrá la aplicación. En la ayuda aparece un listado completo de las combinaciones.

El parámetro fichero-hash contendrá los hash que queramos descifrar, uno por línea. El último parámetro será o bien una máscara de caracteres si vamos a realizar un ataque por fuerza bruta, o un fichero o directorio con diccionarios sobre los que realizar las pruebas (se pueden encontrar diccionarios útiles y gratuitos en multitud de sitios web).

Os dejo con un par de ejemplos de ejecución:

$ ./hashcat-cli32.bin   Ejecutable de 32 bits bajo Linux.
-n 2                    Vamos a utilizar 2 cores de nuestra CPU.
-a 3                    Modo fuerza bruta.
-m 400                  Tipo de hash: phpass, MD5(WordPress), MD5(phpBB3).
-o wp.pass              Fichero de salida.
wordpress.hash          Fichero que contiene los hash a descifrar.
?l?l?l?l?l?l?l          Máscara, hasta 7 caracteres en minúsculas.
> hashcat-cli64.exe  Ejecutable de 64 bits bajo Windows.
-a 0                    Modo fuerza bruta.
-m 10                   Tipo de hash: md5($pass.$salt), utilizado en Joomla!.
-o joomla.pass          Fichero de salida.
joomla.hash             Fichero que contiene los hash a descifrar.
wordlist.dic            Diccionario sobre el que buscar los hash del parámetro anterior.

Si queréis ampliar la información al respecto podéis acudir a la Wiki oficial de hashcat. Si preferís la lengua de Cervantes, hace poco se publicó un manual en español (disponible aquí o aquí).

Replicación pasiva de DNS: Introducción

Hoy vamos a ver un sistema que nos permitirá dar un enfoque diferente al tratamiento de incidentes de seguridad. Este sistema se llama replicación pasiva de DNS (Passive DNS Replication, en inglés).

Origen

Esta técnica fue desarrollada en el año 2004 por Florian Weimer, y consiste en hacer una reconstrucción parcial de la información disponible globalmente como parte del servicio DNS en una base de datos, para su posterior indexación y consulta.

Utilidad

Las bases de datos construidas a partir de este paradigma pueden servir para distintos propósitos, ya que el malware basa una parte importante de su funcionamiento en el protocolo DNS, por ejemplo para modificar rápidamente la dirección IP del servidor de control de una botnet que utilice una red de tipo Fast Flux.

[Read more…]

Cazando al destructor de ficheros

En este artículo os voy a contar una forma de auditar el uso de un sistema Linux, en concreto para saber quién ha modificado o borrado un fichero concreto.

La historia empieza cuando un amigo nos pregunta sobre la mejor forma de auditar los accesos a una carpeta concreta de un servidor linux, ya que han desplegado una aplicación nueva que interactúa con un servidor de ficheros linux y se han encontrado con que, en servidores y carpetas diferentes, se han borrado misteriosamente algunos ficheros sin encontrarse al culpable ni el porqué del borrado misterioso de los ficheros.

Tras una búsqueda de las mejores alternativas, entre las que planteamos, por ejemplo, Tripwire o algún HIDS como OSSEC, nos encontramos con audit, un demonio específicamente diseñado para monitorizar ficheros y carpetas y registrar cualquier modificación realizada.

La instalación es trivial, y existe paquete para las distribuciones más utilizadas:

Debian y derivados: apt-get install auditd.
RHEL y derivados: yum install audit.

Tras esto debemos añadir la siguiente línea en el fichero del servicio dentro de la carpeta /etc/pam.d/ que queramos monitorizar (en nuestro caso eran accesos SSH, por lo que modificamos /etc/pam.d/sshd) para que entre en funcionamiento el demonio:

session required pam_loginuid.so

Finalmente añadimos la regla para monitorizar la ruta en cuestión:

auditctl -w /home/prueba -p w

Esto crea, en el fichero de log del demonio (/var/log/audit/audit.log), entradas por cada acción de inicio y cierre de sesión que se realiza en el sistema, además de cada acción que se realiza sobre la carpeta que hemos seleccionado:

type=LOGIN msg=audit(1348584458.716:2200): login pid=28278 uid=0 old auid=0 new auid=502 old ses=148 
   new ses=202
type=LOGIN msg=audit(1348584458.716:2201): login pid=28278 uid=0 old auid=502 new auid=502 old 
   ses=202 new ses=203
type=SYSCALL msg=audit(1348584471.100:2202): arch=c000003e syscall=83 success=yes exit=0 
   a0=7f41f39dc990 a1=1ff a2=ffffffffffffffa0 a3=4000 items=2 ppid=28283 pid=28284 auid=502 uid=502 
   gid=502 euid=502 suid=502 fsuid=502 egid=502 sgid=502 fsgid=502 tty=(none) ses=203 
   comm="sftp-server" exe="/usr/lib/openssh/sftp-server" key=(null)
type=CWD msg=audit(1348584471.100:2202):  cwd="/home/prueba"
type=PATH msg=audit(1348584471.100:2202): item=0 name="/home/prueba/" inode=130822 dev=08:01 
   mode=040755 ouid=502 ogid=502 rdev=00:00
type=PATH msg=audit(1348584471.100:2202): item=1 name="/home/prueba/aa" inode=205645 dev=08:01 
   mode=040755 ouid=502 ogid=502 rdev=00:00
type=SYSCALL msg=audit(1348584476.181:2203): arch=c000003e syscall=84 success=yes exit=0 
   a0=7f41f39dc990 a1=3 a2=ffffffffffffffb0 a3=4000 items=2 ppid=28283 pid=28284 auid=502 uid=502
   gid=502 euid=502 suid=502 fsuid=502 egid=502 sgid=502 fsgid=502 tty=(none) ses=203 
   comm="sftp-server" exe="/usr/lib/openssh/sftp-server" key=(null)
type=CWD msg=audit(1348584476.181:2203):  cwd="/home/prueba"
type=PATH msg=audit(1348584476.181:2203): item=0 name="/home/prueba/" inode=130822 dev=08:01 
   mode=040755 ouid=502 ogid=502 rdev=00:00
type=PATH msg=audit(1348584476.181:2203): item=1 name="/home/prueba/aa" inode=205645 dev=08:01 
   mode=040755 ouid=502 ogid=502 rdev=00:00

En este log podemos ver como un usuario (uid 502) inicia sesión, y posteriormente accede al directorio /home/prueba y crea, para posteriormente eliminar, la carpeta /home/prueba/aa.

La aplicación utilizada para acceder a los archivos, marcado con la etiqueta “exe”, es sftp-server, ya que la aplicación utiliza SFTP para interactuar con el sistema de archivos.

En la mayoría de supuestos tendríamos suficiente con la información aportada por auditd, ya que si, por ejemplo, realizamos una orden de tipo rm <fichero>, el campo exe contendrá el comando rm lanzado y, con la información del uid del usuario que ha realizado la acción, podríamos saber quién ha borrado dicho fichero.

En este caso no tenemos información suficiente, ya que aunque sí que sabemos que es el servidor SFTP quien ha realizado el borrado, no sabemos exactamente el comando que se ha lanzado para efectuar el borrado de ficheros en nuestra carpeta monitorizada.

Para solucionar este problema, el servidor SFTP incluido en OpenSSH a partir de la versión 4.4, publicada en septiembre de 2006, ofrece la posibilidad de añadir un registro de las acciones realizadas dentro de cada sesión SFTP (ver página del man para más información). Para activar este registro debemos modificar la siguiente línea:

Subsystem sftp /usr/lib/openssh/sftp-server

añadiendo el parámetro -l INFO, por lo que quedará:

Subsystem sftp /usr/lib/openssh/sftp-server -l INFO

Tras reiniciar el servidor SSH, en el fichero /var/log/auth.log obtendremos, además de los registros habituales, otros como los siguientes:

Sep 25 16:52:16 lab1 sftp-server[28846]: session opened for local user user1 from [127.0.0.1]
Sep 25 16:52:23 lab1 sftp-server[28846]: sent status No such file
Sep 25 16:52:23 lab1 sftp-server[28846]: mkdir name "/home/prueba/aa" mode 0777
Sep 25 16:52:26 lab1 sftp-server[28846]: opendir "/home/prueba/aa"
Sep 25 16:52:26 lab1 sftp-server[28846]: closedir "/home/prueba/aa"
Sep 25 16:52:26 lab1 sftp-server[28846]: opendir "/home/prueba/aa"
Sep 25 16:52:26 lab1 sftp-server[28846]: closedir "/home/prueba/aa"
Sep 25 16:52:26 mysql1 sftp-server[28846]: rmdir name "/home/prueba/aa"
Sep 25 16:52:26 mysql1 sftp-server[28846]: opendir "/home/prueba"
Sep 25 16:52:26 mysql1 sftp-server[28846]: closedir "/home/prueba"
Sep 25 16:52:26 mysql1 sftp-server[28846]: opendir "/home/prueba"
Sep 25 16:52:26 mysql1 sftp-server[28846]: closedir "/home/prueba"

Este extracto nos permite, por ejemplo, saber que el usuario ha accedido al directorio /home/prueba, y ha creado y posteriormente borrado el directorio aa, del mismo modo que en el ejemplo anterior.

Utilizando todo esto nuestro compañero pudo finalmente descubrir cómo se estaban realizando los borrados misteriosos de ficheros y quién era el responsable.

(N.d.E. Dado que es festivo en la Comunidad Valenciana mañana nueve de octubre, les vemos el próximo miércoles. Cuidado ahí fuera.)

Introducción al uso de túneles SSH

Todos nos hemos encontrado en algún momento con que ese servicio al que queremos acceder está en un equipo inalcanzable desde nuestra red u otros problemas similares. Si disponemos de acceso SSH podemos solucionar fácilmente problemas de este tipo utilizando túneles SSH.

Planteamos un primer escenario, en el que tenemos un servidor de bases de datos al que podemos acceder por SSH, pero cuyo cortafuegos nos impide interactuar directamente con la base de datos (suponemos MySQL, que utiliza el puerto 3306).

[Read more…]

Automatizando pruebas con SoapUI

Animado por la entrada que hizo hace unas semanas Chema Alonso en su blog, os voy a contar un poco más sobre la herramienta SoapUI, utilizada para auditar WebServices. Más que en cómo utilizar la herramienta en sí, en este post me gustaría explicar de qué forma se pueden automatizar las pruebas a un WebService utilizando esta herramienta.

SoapUI permite automatizar las pruebas a un WebService utilizando lo que él llama Test Cases. A continuación podemos ver que un TestCase tiene varios pasos (TestSteps), así como varias pruebas de carga y de seguridad, que quedan fuera de nuestro objetivo.

[Read more…]

Snort: Extracción avanzada de información en preprocesadores HTTP y SMTP (II)

En mi anterior post os comentaba unas mejoras que se habían introducido en las últimas versiones de Snort, y que si recordáis nos servían para obtener más información detallada acerca de las comunicaciones HTTP y SMTP, como pueden ser: dirección real detrás de los proxys, host y URI contactados, así como direcciones de origen y destino de correos electrónicos, o cabeceras SMTP entre otros.

Al final de la entrada nos quedamos con Snort configurado, pero sin poder extraer esta información tan importante ya que actualmente no se dispone de ninguna aplicación oficial o parche que utilice estas nuevas extensiones del formato Unified2. Por suerte, un usuario de Barnyard2 publicó en la lista de correo de desarrollo de Barnyard2 un parche con el que conseguir guardar esta información en una base de datos de tipo MySQL. Cabe destacar que el parche no es oficial, y ni el usuario que lo creó ni nosotros nos responsabilizamos de los problemas que su uso pueda ocasionar.

Este usuario realizó un parche para la versión 1.9 de Barnyard2 y otro para una snapshot del SVN de la versión en desarrollo. Por comodidad, vamos a utilizar el parche para la versión 1.9. Para instalarlo es necesario descargar Barnyard2, y ejecutar el parche desde la propia carpeta de Barnyard2 con la orden:

patch -p1 < barnyard2-1.9-extra-out.diff

Tras esto, se debe compilar Barnyard2 de la forma habitual, y ejecutar el script de creación del esquema de la base de datos MySQL (cuidado con no borrar bases de datos con información, ya que el script modificado elimina las tablas para crearlas de nuevo) para que ésta pueda albergar la información de las cabeceras extras.

El último paso consiste en modificar Barnyard2 para que, dentro del plugin de MySQL, utilice la «facility» alert-extra. De esta forma conseguimos guardar finalmente estos campos en la base de datos. La línea de configuración quedaría del siguiente modo:

output database: alert-extra, mysql, dbname=snort host=localhost user=snort 
         password=snort sensor_name=snort

Como detalle cabe comentar que durante el proceso de pruebas y gracias al usuario que creó el parche que hemos utilizado, dimos con una diferencia entre la forma en que Snort trata su salida estándar, y la forma en que lo hace Barnyard. En Snort, la «facility» alert guarda únicamente la información más relevante y la «facility» log guarda información extensiva acerca de las alertas generadas, mientras que Barnyard2 trata las “facility” en el modo inverso, enviando a alert información extensiva sobre las alertas generadas y a log únicamente una parte de la información.

Para aquellos más curiosos, el cambio principal que se realiza a la base de datos es la creación de una nueva tabla, llamada extra, que contiene los campos presentes en las cabeceras extra que hemos visto anteriormente. Los campos más relevantes son:

  • sid y cid identifican la alerta asociada del mismo modo que en el resto de tablas.
  • type indica el tipo de información que contiene la fila actual, según la clasificación mostrada en el post anterior.
  • data muestra el campo finalmente obtenido.

A continuación se puede ver un extracto de esta tabla:

A partir de aquí podemos empezar a utilizar estos nuevos datos para obtener informes que nos resulten interesantes.

Por mostrar dos ejemplos, con la siguiente consulta se pueden obtener todas las alertas que disponen de cabeceras extra, mostrándolas:

select e.sid, e.cid, s.sig_name, e.timestamp, x.type, x.data from event e inner join 
      signature s on e.signature=s.sig_id inner join extra x on e.cid=x.cid and 
      e.sid=x.sid; 

La siguiente consulta nos muestra las firmas que están generando cabeceras extra:

select s.sig_name from event e inner join signature s on e.signature=s.sig_id inner join 
     extra x on e.cid=x.cid and e.sid=x.sid group by s.sig_name;

Por nuestra parte, vamos a utilizar esta información extra para tratar de descubrir los equipos detrás de proxys que tienen comportamiento anómalo (P2P, Malware, Spyware, etcétera), pero con el tiempo queremos ampliar su uso para conocer, por ejemplo:

  • Qué nombres de equipo están comprometidos y sirviendo malware.
  • A qué nombres de equipo se conectan los malware que tenemos en nuestra organización.
  • Quienes son los usuarios que envian correos con contenido malicioso.
  • Quienes son los usuarios que reciben correos con contenido malicioso.

¿Se os ocurren más usos de esta información? Si es así, escribidlo en los comentarios.

Snort: Extracción avanzada de información en preprocesadores HTTP y SMTP (I)

A partir de la versión 2.9, Snort ha ido introduciendo mejoras en sus preprocesadores de HTTP y SMTP que permiten la extracción por separado de varios campos importantes de conversaciones HTTP y SMTP.

La primera de ellas fue la posibilidad de reconocer las cabeceras X-Forwarded-For y True-Client-IP que añaden algunos proxies, para reconocer los equipos que realmente están produciendo las alertas en entornos en los que la navegación HTTP se realiza a través de estos dispositivos.

En la versión 2.9.1 se han introducido nuevos campos que pueden ser de utilidad en el análisis de alertas. Estas incluyen las siguientes:

HTTP: Dirección IPv4 True-Client-IP/XFF (Tipo 1)
HTTP: Dirección IPv6 True-Client-IP/XFF (Tipo 2)
HTTP: Datos Gzip descomprimidos (Tipo 4)
SMTP: Nombre de fichero adjunto (Tipo 5)
SMTP: Origen del correo (Campo MAIL FROM) (Tripo 6)
SMTP: Destino del correo (Campo RCPT TO) (Tipo 7)
SMTP: Cabeceras del correo (Tipo 8)
HTTP: URI de la petición (Tipo 9)
HTTP: Nombre de host solicitado (Cabecera Host) (Tipo 10)
Dirección de origen IPv6 del paquete (Tipo 11)
Dirección de destino IPv6 del paquete (Tipo 12)

[Read more…]

CuckooSandbox

cuckoo_color
Hoy les vamos a hablar de una Sandbox. Para aquellos que no estén familiarizados con este tipo de aplicaciones, una Sandbox (caja de arena en español) no es (en este caso) más que una aplicación de análisis de malware que, mediante el aislamiento del proceso o fichero malicioso que se quiere analizar, permite conocer su funcionamiento detallado, incluyendo, entre otros, información acerca de la actividad de red y llamadas al sistema.

CuckooSandbox tiene varias características interesantes. Por un lado, se sirve de técnicas de virtualización para conseguir el aislamiento de los ficheros a analizar, a diferencia de otras Sandbox que utilizan técnicas de enjaulado de procesos para conseguir su objetivo. Por otro, su estructura completamente modular permite un gran abanico de configuraciones y adaptaciones a entornos concretos, lo que permite ser válida ante situaciones muy diferentes. Además, se trata de un proyecto de software libre bajo licencia GPL versión 3.

Para instalar CuckooSandbox necesitamos un equipo con sistema operativo Linux (preferentemente Ubuntu) que disponga de Python y la versión oficial de Oracle de VirtualBox. Una vez instalados los prerrequisitos, únicamente debemos descargar la aplicación desde esta ubicación y descomprimirlo en una carpeta de nuestra elección.

En la parte de las máquinas virtuales, que servirán de base para el análisis, el proceso de configuración es un poco más elaborado, pero básicamente necesitaremos un sistema operativo Windows actual (los módulos de análisis están pensados para las versiones inglesas), Python y versiones vulnerables de las aplicaciones que deseemos instalar. El proceso de configuración y puesta a punto está perfectamente referenciado en el apartado de Instalación de la documentación oficial. El paso final de la configuración es la creación de una instantánea de la máquina virtual, que sirve de punto de inicio en cada análisis, y al que se vuelve tras cada ejecución. A partir de aquí, el proceso de ejecución de análisis es extremadamente sencillo. Por una parte se debe iniciar el proceso cuckoo.py, que constituye el servidor central de la aplicación, y el que llevará toda la carga del análisis.

cuckoo-1

Por otra, se debe lanzar el proceso submit.py, que se encarga de enviar el fichero sospechoso al servidor para que sea analizado.

cuckoo-2

El proceso de análisis es modular y se incluyen por defecto varios paquetes de análisis que cubren distintos tipos de ficheros sospechosos. Actualmente se incluyen plantillas para ficheros ejecutables, librerías dinámicas, ficheros PDF, documentos ofimáticos, y apertura de URL con Internet Explorer y Mozilla Firefox, entre otros. Estas plantillas se pueden modificar o extender, e incluso crear nuevas para analizar otros tipos de fichero no contemplados en estas categorías.

Finalmente, una vez ejecutado el análisis, es momento de revisar los resultados obtenidos. Estos resultados incluyen los ficheros que ha descargado/creado el archivo sospechoso, los logs del sistema, informes del análisis, capturas de pantalla del equipo, traza de red, configuración y log del análisis, el fichero original y la traza de red:

cuckoo-3

Si además lanzamos el servidor web incorporado, podremos ver el informe en HTML, que incluye la información más relevante.

cuckoo-4

Como conclusión podemos decir que nos encontramos ante una utilidad muy útil a la hora de realizar análisis de ficheros maliciosos, y dado su carácter modular y la facilidad de uso, estamos seguros que pronto se hará un hueco en el mercado.

NOTA: Para probar esta aplicación, se utilizaron muestras de malware obtenidas del listado disponible en esta URL.

Analizando la privacidad real de las fotos de Facebook

La semana pasada se publicó en El Mundo una noticia en la que se hablaba de que la privacidad que Facebook aplica a las fotos que subimos a la red social, de la que @mkpositivo se hizo eco a través del twitter.

En la noticia se indica que, cualquier usuario, sin necesidad de estar registrado en Facebook, puede acceder a cualquier foto hospedada en la red social, previo conocimiento de su URL.

Veámoslo mejor con un ejemplo. A continuación se puede ver una foto subida por mí a Facebook. Se puede ver como en la configuración de visibilidad aparece compartida únicamente con mis amigos.

Si pulsamos con el botón derecho encima de la foto y seleccionamos la opción “Propiedades” en Internet Explorer, “Ver información de la imagen” en Firefox, o “Copiar URL de imagen” en Chrome, podemos obtener la URL de la foto. Luego solo es necesario pegarla en otro navegador distinto, o acceder tras hacer cerrado la sesión.

[Read more…]