Delanover

Blog sobre Informática y Seguridad

Artículos publicados por lipman

Como todos sabemos (o deberiamos saber), al menos en España disponemos de los derechos de acceso, modificación, cancelación y oposición, y la gran mayoria de la gente no lo sabe, o no los usa.

Por poner un ejemplo práctico, al cabo del tiempo a nuestr mail nos llegan muchos correos de falso spam. Digo falso spam porque para nosotros es spam (ya que es correo no deseado) pero nos lo mandan porque tiempo atrás nos registramos en algún sitio y accedimos a que guardasen nuestros datos y nos enviasen correo. Es cierto que se tarda medio segundo en eliminarlo, por eso se suele hacer ya que es lo mas fácil y rápido, pero si nos detenemos un momento en el mensaje, en la parte de abajo suele (o deberia) tener un enlace para poder evitar que nos manden más correo (darnos de baja).

El caso es que con la legislación española, además de facilitarnos un medio para poder ejercer nuestros derechos (acceso, modificación…) debe de indicar quién es el responsable del fichero de datos y dónde está situado. Hace tiempo salió una noticia de que uno pidió sus datos en Facebook, y se lo dieron y tal, y bueno, ha llovido bastante desde es momento y en Facebook tenemos ya la opción de descargar nuestros datos (y archivos subidos).

Si nos vamos a configuración de la cuenta, en la parte de abajo tenemos un enlace que dice “Descarga una copia de tu información.” que incluye además como dije, archivos subidos, como imágenes. Esto no es instantáneo, sino que lo has de solicitar y tarda un tiempo en prepararse (cuestión de horas), y luego si que puedes descargarlo.

Total, que me hice la pregunta de, ¿y Tuenti qué guardará de nosotros? Así que no me lo pensé dos veces. A pesar de conocerme el procedimiento legal, primero de todo les envié un mail solicitando información, y me dijeron que tenia que enviarles una carta a una dirección adjuntando una copia del DNI, una carta con mis datos (nombre, edad, ubicación), y un impreso que tenia que firmar (el primero). Envié la carta, y además la certifiqué para confirmar que había llegado.

Volviendo al tema legal, he de comentar dos cosas: legalmente, nos tienen que responder en el periodo de máximo un mes. Una vez realizado el derecho de acceso a tus datos personales, si no es por causas mayores, no puedes volver a hacerlo hasta dentro de un año.

Hace poco recibí el paquete de vuelta cuyo contenido era un par de hojas impresas y un CD, del cual pude deducir que estaba escrito por una chica (y posteriormente los metadatos me dijeron que se llamaba Laura y usaba un Mac, gracias FOCA).

El contenido del CD era un PDF (lo que me habian imprimido) y una carpeta que contenia un screenshot y 4 CSV’s.

El screenshot es el siguiente:

Con respecto a los CSV’s, el primero de ellos contiene datos respecto a los amigos: nombre, ciudad, edad, ID, y fecha de cuando empezamos a ser amigos en la red social.
El segundo CSV es un simple log de las IP desde donde se ha conectado a la cuenta: Id, fecha, IP, “admin ID” (ni idea que es esto, igual es en el caso de ser admin?, me lo pone a 0 todo el rato). Importante destacar que viene desde el momento de registro, en mi caso desde 2009.
El tercer CSV contiene los mensajes privados, aunque de una forma más caótica, ya que técnicamente no es un CSV, ni siquiera sé muy bien como lo han hecho. De repeten aparecen varios contactos, luego un mensaje, luego más contactos…
El último CSV contiene datos del muro con los siguientes datos: Nombre, ciudad, edad, ID, fecha, texto y tipo. He de decir que también está ordenado de forma caótica y no es completamente un CSV.
La verdad es que me esperaba que me adjuntasen también las imágenes que habia subido (como en el caso de Facebook)… pero no ha sido el caso.

Conclusión hasta aquí: es interesante ver qué tienen las empresas sobre nosotros, así que animo a que ejerzais vuestros derechos, que para algo están.

Con respecto al tema de la seguridad me han surgido varias preguntas y reflexiones:
-Lo único personal que tuve que enviar fue una fotocopia del DNI (ni siquiera compulsada) además de los datos que están en la red social y cualquiera puede verlos. Se podría hacer la fotocopia a alguien sin que se diera cuenta y enviarlo en su nombre? No me cabe la menor duda, sobre todo si se trata de alguien cercano como un familiar, o si se piensa un poco la manera.
-Si se pudiese suplantar la identidad y poder realizar los derechos de acceso, ¿podriamos realizar también los derechos de oposición? (vamos, cerrarle el Tuenti a alguien).

Desde hace mucho tiempo que la criptología es uno de los temas que apasionan, aunque para indagar de verdad necesitas alto conocimiento matemático que espero algún dia nos enseñen en la uni. Sin ningún tipo de conocimiento básico, lo primero que se nos puede ocurrir para encriptar un texto, es la rotación (método Cesar) o la traducción.

El término traducción al que me refiero puede ser muy amplio, y esta idea que le da un toque personal a esta entrada, me viene de hace muchos años cuando oí en la tele que el japonés originariamente se diseñó para que unos cuantos lo hablasen y no les entendieran, como un tipo de encriptación del lenguaje. Cierto o no, nos vamos a valer de eso.

El tema de la rotación no tiene mucho misterio. Se basa en rotar el abecedario, de manera que si hacemos una rotación 3:

Osease, que el texto “hola mundo”, podria quedar encriptado de la siguiente manera, “krod pxpgr”. Una persona que vea esto puede sacar algunas deducciones y hacer pruebas.

  • Al haber un espacio entre dos grupos de letras, se puede deducir que se tratan de dos palabras.
  • Al no ser de un tamaño raro, se pueden considerar letras que forman palabras, sin más.
  • Para desencriptarlo, lo primero que se nos puede ocurrir es hacer una rotación debido a lo fácil que es programar algo, para que nos rote un texto de manera automática de todas las formas posibles.

Como podemos deducir, la rotación sin más, no es un método seguro. Pero, ¿y si además de rotar hacemos una traducción? Esa era mi idea desde el principio, y valiéndome de lo que conté del japonés, podemos usar los propios kanjis del japonés para traducir (aunque usaré ‘kanas’ para los más quisquillosos).

De manera que (traduciendo también el espacio en blanco), nuestro “krod pxpgr” se puede transformar en un “ゼかとつこにギヲちな” por poner un ejemplo.

Ya parece un poco más complicado de desencriptar, ¿verdad? Vamos a pararnos aquí y vamos a pensar en la herramienta desencriptradora, ya que si hacemos una encriptación, es lógico que necesitamos otra herramienta que nos recorra el camino inverso.

En este proceso, hemos necesitado dos premisas: la primera de ellas es la rotación que hemos tomado, y la segunda, la traducción. El tema de la traducción no tiene ningún misterio, ya que en una matriz podemos tener todos los caracteres que vamos a traducir, y en otra la traducción de cada uno. Y por último, el tema de la rotación, lo podemos pasar en la propia cadena, me explico, después de traducir “hola mundo” por “krod pxpgr”, al usar una rotación 3, podemos traducir el texto originario a “krod pxpgr3″. Y posteriormente lo traducimos a kanjis japoneses ゼかとつこにギヲちな. De esta forma hacemos lo siguiente para desencriptar: traducimos -> obtenemos el número de rotación -> rotamos.

Perfecto, pues ya tenemos nuestra cadena encriptada a un lenguaje con símbolos raros que no tienen absolutamente nada que ver con los nuestros. Sin embargo, esto sigue teniendo varios fallos.

A lo largo de la historia, las personas han sido capaces de desencriptar lenguajes escritos (como los jeroglíficos por ejemplo), entonces, desencriptar un simple “hola mundo” debe ser pan comido. Esto lo han conseguido observando el patrón que siguen las palabras, la cantidad de veces que se usan las letras (por ejemplo, para el castellano en particular, las vocales y los espacios en blanco son muy usados) ¿Cómo podemos hacer más fuerte el sistema? Podemos hacer algo en relación a lo que hemos explicado anteriormente con la rotación.

Podemos hacer que cada vez que hagamos un mensaje, aunque sea el mismo, se traduzca de distinta manera, ya que cada vez lo rotamos de forma distinta. Esto no es muy complicado, ya que como pasamos en el propio mensaje las posiciones en las que lo rotamos, desrotarlo debe ser dificil.

De esta forma, cuando encriptemos una frase, en esa propia frase estará la clave para desencriptarla.

Todavía más
¿Cómo podemos hacer esto todavia más fuerte? Recordais las dos matrices de las que hablé antes?, una con los caracteres a traducir y otra con la traducción. Para hacer todavía más fuerte esto, podemos valernos de caracteres de distintos idiomas (para liarlo más) y que, a la hora de traducir, en lugar de traducir letras, traduzcamos sílabas. Tendremos más cosas que traducir claro está, pero será más fuerte por tener más variedad en el conjunto.

Un saludo, lipman

Mitad por entretenimiento y mitad por motivos personales, me vi desarrollando una aplicación en Bash que me permitiera obtener los datos de una cuenta de Twitter, a partir del nombre de usuario del que quisiera obtener dichos datos.

Hace algunos dias la terminé, y ayer la traducí a PHP, puesta hoy pública (aunque todavia no el código) para detectar posibles fallos y ser reportado de algún tipo de bug o comentario, es por eso por lo que animo a que cualquiera que tenga un rato la pruebe: http://delanover.com/twitter.

Quisiera relatar un poco la experiencia que tuve en este post. Como dije, al principio la escribí en Bash. Viene muy bien saber comandos de linux para esto, y en el proceso de creación del script descubrí algunas cosas interesantes de Bash.

El comando paste, nos permite juntar dos ficheros desde la consola. Pero no de la misma forma que hariamos con cat archivo1 archivo2. De esta última forma, concatenariamos archivos. Entenderemos este comando mejor con un ejemplo:
Archivo 1
Hola
Adios
Archivo 2
Mundo
Mundo

Realizamos: paste archivo1 archivo2 > final y obtenemos un fichero final cuyo contenido es:
Hola Mundo
Adios Mundo
(Palabras separadas por un tabulador)

Parece que no, pero puede ser útil este comando, y con lo sencillo que es, me parecia raro no haber oido hablar de él.

También tuve que lidiar con la búsqueda de expresiones regulares de forma un-greedy (o non-greedy). ¿Qué es esto? Lo veremos también claro con un ejemplo. Imaginemos que tenemos la siguiente string: inicio intermedio fin basura basura fin y queremos obtener lo que hay entre inicio y fin (el primer fin, no el último). Usando expresiones regulares, podriamos pensar en algo así:

grep 'inicio.*fin' -o archivoCualquiera (el -o es para que nos muestre todo lo que abarca esa expresión regular. Es decir, que nosotros queremos: “inicio intermedio fin basura basura fin“, pero en lugar de eso, nos devuelve “inicio intermedio fin basura basura fin“. ¿Pero por qué? Porque primero busca “inicio”, después busca todos los carácteres posibles (todos los que simbolizan el punto) y cuando ya los tiene todos, se pone a buscar hacia atrás (de izquierda a derecha) “fin”. En otras palabras se podría interpretar con que empieza a buscar “inicio” por la izquierda y “fin” por la derecha, y muestra todo lo que hay de por medio.

El caso es que yo no quería esto. Yo quería que empezase a buscar por la derecha, y siguiese buscando desde ese momento hacia la derecha. De esta forma obtendríamos el “inicio intermedio fin basura basura fin“. Pues bien, este método de buscar se llama non-greedy o un-greedy, y nativamente, bash no lo permite y digo nativamente, porque grep tiene un parámetro que nos permite usar expresiones regulares de Perl y este sí que permite hacer lo que buscamos.

Solución final: grep -P 'inicio.*?fin' -o archivoCualquiera

Simplemente añadiendo un símbolo de interrogración tras el asterisco.

Volviendo al tema del script, mencionar que he usado la API de twitter que podeis encontrar aquí: https://dev.twitter.com/docs/api
Un apunte: Twitter permite como máximo 150 peticiones por hora por IP. Parecen suficientes o incluso muchas, pero innumerables veces me ha saltado el error de que he excedido el límite.

Por otra parte, al re-programarlo en PHP y al tratarse de que las respuestas vienen dadas en formato JSON, éste tiene una función que ayuda mucho: json_decode. El resultado no se trata como una matriz cualquiera, así que hablaré un poco. Por un lado, miraremos la estructura de esto. Para acceder a las propiedades del primer nivel sería tan fácil como:

$objeto = json_decode($cadena_json);
echo $objeto->{'created_at'}; //Ejemplo de acceso a un primer nivel
echo $objeto->{'user'}->{'name'}; //Ejemplo de acceso a un segundo nivel

De esta forma podemos acceder individualmente. Para ver todo el contenido de la petición es todavía más sencillo:

$objeto = json_decode($cadena_json);
var_dump($objeto);

Insisto en que lo probeis y me comentéis algo: http://delanover.com/twitter

Un saludo, lipman

Siento todo este tiempo sin escribir, he estado ocupado con temas de la universidad hasta este dia. Pero bueno, intenté despedirme durante un tiempo con una entrada especial como la de Vodafone.

Aunque no haya publicado nada desde entonces, tengo en mente varias entradas, así que volver a estar asiduo (o eso espero).

Empezaré la entrada lanzando una pregunta. ¿Estamos preparados para perder nuestro smartphone? Todos sabemos que la respuesta es no. En ese caso la mayoria de la gente perdería desde contactos hasta fotos. Pero vamos a intentar que este no sea nuestro caso.

Paso 1: la nube puede ser nuestra amiga.

Desde hace tiempo, he dejado de agregar contactos al móvil de forma tradicional, es decir, desde el propio teléfono añadir el contacto. Desde ahora, uso mi cuenta de GMail para agregar ahí a los contactos y posteriormente, actualizar los de mi teléfono teniéndolo sincronizado a dicha cuenta.

Ventajas:
Como principal ventaja, está si perdemos el teléfono, los contactos los seguimos teniendo en nuestra cuenta. Igualmente añado, que podemos añadir contactos desde el teléfono a la cuenta de GMail.
Control de tus contactos desde el ordenador, clasificación, puedes ponerles imágenes, y todo lo que puedes hacer desde tu teléfono, pero más cómodo incluso.

Paso 2: copia de seguridad de todos nuestros archivos

El objetivo original de esta entrada era mayormente este paso, ya que era el entretenido realmente, pero ya que estoy, he añadido el paso anterior ya que también me parece interesante.

Lo primero que haremos será bajarnos una aplicación para Android (gratuita): FTPDroid (también existe la versión de pago).

Esta aplicación nos permitirá convertir nuestro teléfono en un servidor FTP en donde nos conectaremos desde el ordenador y haremos copias de seguridad. Si, para hacer copias de seguridad solo necesitamos un cable y copiar-pegar, pero eso no es entretenido, se busca una manera más entretenida.

Configuración:


Añadimos un usuario y contraseña, y por defecto, la ruta en la cual accederemos será la de la tarjeta. Podriamos hacer una copia de seguridad de todo el teléfono, pero a mi personalmente me interesa la tarjeta, ya que es ahí en donde solemos meter canciones, recibir archivos, guardar ficheros, fotografias, grabaciones, etc. En este ultimo caso, cambiariamos la ruta que está, por / aunque algunos archivos no nos dejan copiarlos (supongo que teniendo el teléfono rooteado si que te dejará).

En la parte de opciones, desactivamos “Enable anonymous” para que solamente podamos acceder al teléfono a través del nombre de usuario y contraseña previamente establecido (por si acaso).

Una vez configurado esto, ya podemos acceder a nuestro teléfono desde el navegador. Si la IP local de nuestro teléfono fuese 192.168.1.100, accederiamos de la siguiente manera: ftp://192.168.1.100:2121

Comando lft
Ahora, desde la consola realizaremos la copia de ficheros, pero en lugar de usar el comando ftp como todos hemos pensado, usaremos lftp.

A diferencia de ftp, lftp permite realizar algunas más cosas, pero nos centraremos en una sola, y es en la función “mirror”.

Usaremos esta función para hacer copia de seguridad de nuestra tarjeta. Desde la consola, nos situamos en la carpeta en donde queremos llevar la copia de seguridad y seguimos los siguientes pasos:

sftp 192.168.1.100 -p 2121

Tras conectarnos establecemos el nombre de usuario y contraseña

user Usuario Contraseña

Usamos la función mirror, estableciendo que queremos copiar desde la ruta / (Nota: se copia recursivamente por defecto) (Nota 2: recordemos que / equivale a /mnt/sdcard ya que es lo que hemos configurado en nuestro teléfono).

mirror /

Este proceso nos puede llevar largos minutos, dependiendo de lo que tengamos en el teléfono claro. Ahora viene lo realmente beneficioso e interesante. Al cabo del tiempo habremos sacado nuevas fotos y tendremos nuevos archivos. ¿Tendremos que copiarlos todos de nuevo? No. ¿Hay alguna función que nos permita copiar solo los nuevos? En efecto. Además, esto también nos es útil por si hemos tenido algún problema al hacer la primera copia, como una desconexión a internet o algo.

mirror / -n

Nos queda hacer un último paso. Al realizar esto, igual tenemos problemas con los permisos. Yo mismo he tenido problemas haciéndolo en Windows, ya que no me dejaba accceder a nada de lo que habia copiado.

Para ello, realizamos un cambio de permisos. Si no nos queremo complicar y estamos en Windows, nos vamos a la carpeta donde hemos hecho la copia y hacemos un chmod recursivo:

chmod -R 777 /

Algo más acerca de LFTP

Dentro de las opciones que nos ofrece el comando mirror, podemos hacer un reverse mirror, que viene siendo lo mismo pero al revés, es decir, en vez de bajarnos del servidor un arbol con sus descendientes, lo subimos.

mirror / -R

En general, lftp es más potente que ftp. Una diferencia con respecto el comando ftp es que con lftp podemos combinar comandos locales de la consola y comandos propios de lftp. Por ejemplo, desde una sola línea podriamos comprimir el directorio actual (local), subirlo al servidor, y luego borrarlo del directorio local:

!(tar -cvvf target.tar * && gzip target.tar) && put target.tar.gz && !(rm target.tar.gz)

Como podemos ver, el símbolo de exclamación nos permite ejecutar en el sitio local.
Otra diferencia es que con lftp podemos trabajar fácilmente con el grep. Imaginemos que queremos todos los ficheros que no sean carpetas de nuestr servidor:

ls | grep '^[^d]'

lftp además de soportar transferencias ftp como hemos estado viendo, también soporta http y sus respectivas versiones encriptadas (ftps y https).

Por último, también interesante, es que lftp puede ejecutar scripts mediante el comando -f de la siguiente manera. Suponiendo que tenemos un archivo llamado script con el siguiente contenido:

connect 192.168.1.100 -p 2121
user Usuario Contraseña
ls

Al ejecutar lftp -f script se ejecuta todo el contenido del script, nos devuelve el ls del directorio remoto y volvemos a tener la consola operativa.

Un saludo, lipman

Parte 1 del Post.

Tras meses sin hacer nada los de Vodafone.es, el pasado jueves dia 8 publiqué un Proof of Concept de la inseguridad que esta página proveia, hasta el punto de poder entrar en cualquier cuenta a partir únicamente del número de teléfono de la “víctima”.

En este momento (dia 14 de diciembre), unos 6 días después de la publicación, he vuelto a entrar a Vodafone.es y me he dado cuenta de que han mejorado la seguridad: en lugar de tener que pasar una puerta delgada de madera, tenemos que pasar a través de dos.

El principal fallo residía en la obtención de una nueva contraseña, dándole a “recordar contraseña”. Esto es lo que habia antes de ser “arreglado”:

Ahora:

Como podemos ver no ha cambiado mucho, podemos elegir de poner nuestro teléfono, y es realmente lo mismo. Donde si notamos el cambio es en la segunda parte. Antes:

Ahora:

La primera parte (lo de la pregunta secreta) aparece una vez la hemos establecido (la primera vez que realicé la prueba no aparecia, y al finalizarla, me pedia que la introdujese). Lo que si que aparece ya fijo es lo demás.
Por un lado, necesitamos la identificación (vease, DNI y demás) y por otro, podemos elegir entre: introducir la entidad en donde tenemos domiciliada nuestra factura, o introducir los 4 últimos dígitos de nuestra cuenta (hmm interesante esto último…).

Aquí ya va mi primer comentario y el resultado de más pruebas realizadas:

  • Necesitamos el DNI (cosa relativamente fácil de conseguir, vease ingeniería social. Además, es obvio que si esto se le hace a alguien, es porque se le conoce).
  • Se puede volver a usar fuerza bruta. Si señores, se puede volver a usar fuerza bruta. Sigue sin haber ningún tipo de expiración por cantidad de veces, captcha, o cualquier tipo de arreglo.

Tras esto, nos vamos al paso 3. El paso 3 anteriormente era el siguiente:

Ahora es este:

¿Diferencia? ninguna. ¿Se puede volver a usar fuerza bruta? Si, se puede.

Conclusión hasta el momento: Han hecho el sistema algo más seguro, siendo necesario ahora el DNI de la víctima. Como dije anteriormente, no lo han arreglado, simplemente han puesto una traba más, que tampoco es nada del otro mundo.

Problema añadido: Si nos fijamos en el paso dos (el antes y el después), a partir de ahora hay que meter los 4 últimos dígitos del número de cuenta. ¿Qué quiere decir esto? Que ya no habrá diferencia entre “titular” y “usuario”, y si logramos entrar, veremos todos los datos sin ningún tipo de impedimento (aunque el que habia antes tampoco es que lo fuera demasiado).

Otras mejoras de seguridad

Con respecto al tema de la fuerza bruta, se han puesto al dia en lo que es el login principal. Solamente nos deja meter un cierto número de intentos, 5 para ser exactos. Y aquí si que realmente no se puede bruteforcear. Sin embargo, repito, el fallo principal no está en el login, sino en la parte de recuperar la password, por lo que todavia queda por arreglar.

Por otra parte, el buscador lo han cambiado (al fin) ya que sufría más de un XSS en distintos argumentos, en el que insistí mucho. Buscador viejo:

Buscador nuevo:

El tema de las Cookies

La verdad es que en el otro post lo mencioné muy por encima porque tampoco queria entrar al tema, ya que no era tan importante como el problema principal. De todos modos, estoy contento de que por lo visto, algún tipo de efecto ha tenido que haber tras hacer la publicación anterior, ya que como dije, en meses no lo habian arreglado, y de repente, 6 dias después de la publicación (justo antes de publicarla volví a comprobar si habian hecho algo nuevo y nada..) me encuentro con que han hecho algo, poco, pero algo.

Principalmente, una de las partes que más me sorprenden de Vodafone, es que guarda la contraseña y el usuario (y el usuario es ni más ni menos que el número de teléfono), en una cookie, de la siguiente forma.

Todo el mundo sabe (o debería) que nunca jamás se debe guardar en una cookie los credenciales, aunque estén encriptados. En el caso de robar una cookie de alguien, podemos obtener su teléfono (punto de ataque) y su contraseña, que aunque esté encriptada, no es difícil de mostrar tras esos asteriscos.

Fallos XSS con los que podriamos robar cookies:
Viejos
Uno
Dos

Todavia persistentes
[Uno] [Enlace]
[Filtro interesante (WAF)] [Filtro Bypasseado] [Imagen] (En varios argumentos de la URL)

Otros:
[Este lo han intentado arreglar de alguna forma.. pero la página nunca termina de cargar]

Animo a que pongais más si los encontrais.

Un saludo, lipman