Login en Linux y caracteres no imprimibles

En una de las preguntas que teníamos que hacer en clase para un ejercicio de la asignatura de Seguridad Informática, se nos preguntaba acerca de las contraseñas en Linux (expiraciones, limitaciones, …) Al final resultó ser más entretenido que un simple y típico chequeo, con un final interesante y curioso, al menos para mi, es por eso que lo publico. He buscado un poco y no he visto ningún documento que lo recoja, así que me parecía interesante escribirlo.

Toda la historia tiene como centro al comando passwd, que es el que nos permite cambiar la contraseña de nuestro usuario actual. Su funcionamiento es simple: escribimos passwd, introducimos la contraseña actual, e introducimos dos veces la nueva contraseña. Nada nuevo.

Hay varios conjuntos de contraseñas que no podemos poner, ya porque sean simples, fáciles, etc. De hecho, estos son algunos de los errores que nos pueden dar si tratamos de introducir algunas contraseñas.

Este es un extracto del man del passwd.

Then, the password is tested for complexity. As a general guideline,
passwords should consist of 6 to 8 characters including one or more
characters from each of the following sets:

·   lower case alphabetics
·   digits 0 thru 9
·   punctuation marks

Care must be taken not to include the system default erase or kill
characters.  passwd will reject any password which is not suitably
complex
.

Tal y como pone, nos podriamos imaginar que el passwd tiene las restricciones que ahí nos puede hacer entender que tiene. Sin embargo, lo interesante viene cuando lo hacemos con el sudo. En este caso, básicamente, se lo traga absolutamente todo. Fuimos probando los palíndromos que antes no nos dejaba poner, y signos raros, y si, se podía meter de todo.

El caso es que, después de probar a meter todo tipo de símbolos, probamos incluso a teclear Esc, RePag, AvPag.. y sorpresa, también se los tragaba. Es decir, podíamos tener un usuario que para loguearse necesitara que introdujeses 7 veces Esc. ¿Qué “problemas” trae esto? Principalmente, que en el entorno gráfico es imposible loguearte. No hay manera de introducir esto, pues cuando le damos a Esc, deselecciona el usuario, y con AvPag y demás, simplemente no mete nada.

Lo primero que pensamos fue que no tenía nada sentido, ya que cuando estamos en el entorno gráfico de un sistema operativo o incluso en la propia terminal, si pulsamos Esc no pasa absolutamente nada. Pero me vinieron a la mente el concepto de los caracteres no imprimibles, y buscamos en una tabla ASCII a ver.

Y exáctamente ahí lo teníamos. Esc es un carácter no imprimible, y de alguna forma se metía. Importante decir que los caracteres no imprimibles se los traga sin el sudo.

Después de llegar a esta conclusión, comprobamos esta teoría de manera muy sencilla.

cat > prueba
Ahí pulsamos Esc una vez, y luego lo cerramos. Abrimos con el vi, lo ponemos para que se muestre en hexadecimal (:!%xxd) et voilá. Ahí tenemos a nuestro 1B (Esc).

Como curiosidad y con respecto al error del palíndromo. Un palíndromo es una palabra que se lee igual a ambos lados. Insisto en el concepto palabra, porque si ponemos de contraseña 3avpag+2repag+3avpag no nos dice que sea un palíndromo (aunque técnicamente lo sería). Si después de tener esta contraseña se nos ocurre escribir 2repag+3avpag, nos salta el error de “New password is just a wrapped version of the old one”. Si todo esto lo hacemos con letras (sin ser un palíndromo) nos diría “New and old password are too similar”. Curioso ¿no?

¿Entradas ARP Estáticas contra ataques Man in the Middle?

Un poco de teoría sobre MitM y ARP

El protocolo ARP es el encargado de traducir de direcciones IP a MAC (y el inverso, traduce de MAC a IP lógicamente). Cuando estamos conectados a internet desde un portátil a traves de una red wireless, usamos este protocolo para saber a dónde tenemos que enviar nuestros paquetes (al router claramente) para que puedan ir a través de Internet y demás.

El envenenamiento de las tablas ARP consiste en decirle al ordenador víctima desde el ordenador atacante “el router se encuentra en esta otra dirección (la del atacante)”. De esta manera, la víctima piensa que le está enviando los paquetes al router, y realmente se los envía al atacante. Así, éste puede ver todo el tráfico de la víctima, que luego redirige al router, y realiza el camino inverso.

En la siguiente imagen, vemos una tabla ARP normal. Subrayado y en primer lugar, tenemos la dirección del router. Luego, dos direcciones de un par de equipos, broadcast, etc. Aquí no hay nada raro, está todo en orden.

Ahora, vamos a envenenar la tabla ARP desde un ordenador atacante.
Como podemos ver, aparece otro ordenador con IP 192.168.2.103 (el atacante), y la MAC del router ha cambiado. Si os dais cuenta, es la misma que la del atacante.

Nota: para ver la tabla ARP desde Windows se hace mediante arp -a

Solución: ¿Poner entradas ARP estáticas?

Teóricamente, si ponemos entradas estáticas estamos seguros, ya que de esta forma ningún atacante puede cambiarlas para hacer pensar al ordenador víctima que el router está en otra dirección distinta. ¿Es lógico no? Si no se puede cambiar esto, se enviará siempre hacia el router.

Pues bien, vamos allá. Poner entradas ARP estáticas en Windows es más complicado que usar simplemente el comando ARP. Nuestra primera intención es hacerle caso a lo que nos dice la ayuda de ARP de la consola, y es usar:

arp -s IP MAC

Pero no funciona. Como he dicho, es algo más complicado. De hecho, uno de los motivos de crear esta entrada es para guardar cómo se hace, y así no tener que buscarlo si en un futuro es requerido hacerlo.

Primero de todo, necesitamos saber el nombre de la conexión. Para ello lo hacemos mediante:

netsh interface ip show config

Como podemos ver, el nombre de mi conexión es “Conexión de red inalámbrica”.
Después, ejecutamos el siguiente comando:

netsh interface ipv4 add neighbors “NOMBRE_CONEXIÓN” IP MAC

Importante: daros cuenta que la MAC está separada por guiones y no por dos puntos.

Volvemos a reproducir el ataque

¿Qué sucede si reproducimos de nuevo el ataque? ¿Seremos completamente invulnerables? La respuesta es no, no estamos seguros. Y ahora viene el porqué: el envenenamiento de la tabla ARP consiste en enviar paquetes hacia la víctima y el router para que le envien los paquetes al atacante. De esta forma ve todo lo que va de la víctima al router (y por tanto hacia Internet) y viceversa. Si le decimos al ordenador víctima que el router está en una dirección (con entradas estáticas), el router todavía seguirá pensando que el ordenador atacante es en realidad el de la víctima.

Paquetes ARP que envía el atacante. Como podemos ver, le dice al router “la dirección del ordenador (víctima) está en mi MAC” y le dice a la víctima “la dirección del router está en mi MAC”.

Un dibujo de cómo quedaría ahora el envío de paquetes:

Conclusiones

Principalmente de este asunto saco dos conclusiones importantes.
La primera de todas es, que para que sea realmente seguro, habría que poner estática también la entrada ARP del router que vaya dirigida hacia el ordenador. De esta forma no se alteraría nada de nada, y todo iría por su camino correspondiente.

La segunda conclusión es la siguiente: ¿realmente nos merece la pena poner entradas estáticas en nuestro ordenador en caso de no poder hacerlo en el router? Me explico: si no lo hacemos en el router, el atacante podrá obtener los paquetes que vienen del router (e Internet) hacia la victima y no los otros vale, pero es interesante tener las entradas dinámicas, para que si un atacante nos envenena nuestra tabla, nos demos cuentas (hay programas que detectan cuando una tabla ARP es cambiada y nos avisan, como Marmita).

Conclusión de las conclusiones: si podemos poner estáticas las entradas del ordenador y el router perfecto. Si no, es interesante dejarlas dinámicas y tener un programa que nos avise cuando sean cambiadas.

Desarrollando un sistema de encriptación útil y básico

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

Parte 2 – Descuido en Vodafone.es permite acceder a cualquier cuenta de usuario y obtener datos de cualquier teléfono

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

Descuido en Vodafone.es permite acceder a cualquier cuenta de usuario y obtener datos de cualquier teléfono

Nota: han arreglado algunas cosillas, aunque todavia sigue quedando este fallo. Parte 2 del Post.

“Esto” está descubierto y reportado desde hace más de medio año… He intercambiado mails y conversaciones telefónicas con Vodafone y con la propia policia (GDT). Tenia un post explicándolo todo detalladamente además de un PDF que mandé a ambas partes, pero visto que no lo arreglan nunca, no lo voy a publicar. Lo que haré será un mini resumen, y se acabó, ya que quiero olvidarme de este tema completamente.

Antes de nada os hago un spoiler: no es nada del otro mundo. Solo es una muestra de cómo una absurda tonteria, nos permite hacer cosas que no deberiamos. Es más, esto indica que este descuido es realmente grave, ya que cualquiera puede explotarlo.

Empezaré con el debate respecto al título elegido de esta entrada. Ojalá hubiera podido poner “Bug en Vodafone.es…” o “Fallo de seguridad/Vulnerabilidad..”. En fin, múltiples son los adjetivos para ello. Pero no, pongo descuido por no poner incompetencia, ya que guardar en una cookie el nombre de usuario (teléfono) y la contraseña (encripada, pero eso da igual) no es un fallo de programación, no es un bug, no es una vulnerabilidad… es ser un incompetente. Menciono también que tiene XSSs varios, sin ir más lejos, creo recordar que el propio buscador tenía.

Como dije anteriormente, voy a ser breve, y no voy a dar detalles. Solo decir esto: no seas gilipollas.

Como dice el título, este descuido nos permite meternos en la cuenta de usuario a partir únicamente de su número de teléfono. Y si no tiene cuenta, también nos lo permite porque le podemos registrar nosotros mismos.
Uno de los orígenes de este problema, es que si le damos a “olvidar contraseña”, podemos poner el número de teléfono objetivo y nuestra dirección de correo. Nos mandan una clave numerica de 4 digitos al movil para que la introduzcamos y establezcamos una nueva contraseña. Pues bien, podemos hacer fuerza bruta tranquilamente que al final, daremos con esa clave que no puede ser otra que alguna entre 0000 y 9999. Una forma para hacer fuerza bruta sin ser un 5uP3RH4X0R es usar el iMacros para Firefox, haciendo:

SET !LOOP 1000
URL GOTO=http://canalonline.vodafone.es/cpar/do/alta/changePassword?uuid=XXXXXXXX&claveAntigua={{!loop}}&claveNueva=1234&rePassword=1234

(Esta iría desde 1000 hasta 9999, y estableceria como nueva contraseña 1234).
Así que nada, después de esto ya podemos meternos en la cuenta. Pero no podemos acceder a todos los datos, que pena. No podemos porque tenemos que ser titular, y para eso, tenemos que validarnos. ¿Como? Pues hay varias formas. Una de ellas es introduciendo los 4 últimos dígitos de nuestra cuenta bancaria asociada.

¿Otra vez 4 números? Esto me suena de antes… Exacto. iMacros de nuevo. Y claro, si aquí tampoco ponemos nada que nos impida un bruteforce como un captcha o una expiración de la sesión, pues igualmente podemos petarlo. Y efectivamente, se puede.

Datos comprometidos (entre otros tantos): DNI, nombre, dirección postal, factura electrónica (con mas telefonos claro, que a su vez igual tambien son de Vodafone), códigos PIN y PUK (ideal por si robamos un teléfono verdad?)…

Yo flipo con las empresas. Pero sobretodo con su pasotismo a la hora de no arreglar nada, ni contactar conmigo siquiera. En fin…

Conclusiones:
-Se puede bruteforcear todo vodafone.es sin problemas
-Se puede robar una cookie con datos como la contraseña y usuario para suplantarse (ya que presenta varios XSS).
-Poned un puto captcha! de una vez.
-Insisto en que la gravedad de este asunto es que es demasiado fácil realizar esto, no hay que ser un experto ni tener conocimientos de nada.
-Seria curioso saber cuantas leyes se pasan por el forro los de Vodafone, como la de las auditorias (a saber si las hacen siquiera, o si les hacen caso), sin contar con las que hacen mención a que hay que proteger bien los datos.

Dato adicional: Vodafone no es la única compañia de telecomunicaciones cuya identidad de sus usuarios se basa en algo tan simple. Aunque lo de guardar en la cookie las password, todavia me sigue costando creerlo. Ahí lo dejo caer…

Retweetealo!
Mi Twitter

Seguridad a la hora de crear entradas en WordPress

INDICE
0.-Resumen
1.-Introducción
2.-Buscando un algoritmo
3.-Implementando nuestro sistema en WordPress
3.1.-Añadiendo posts a nuestra base de datos
3.1.1.-Analizando la tabla de wp_posts
3.1.2.-Nuestra consulta
3.1.3.-La tabla wp_postmeta
3.2.-Implementando la seguridad en nuestra aplicación
3.3.-Conclusión y funcionamiento final
4.-Códigos finales completos

0.-Resumen

En este post intentaré explicar un método casero para poder escribir en nuestro respectivo blog de WordPress desde cualquier lugar sin tener que preocuparnos en que nos estén analizando el tráfico. Ideal por si estamos en una red que no es la nuestra, como en casa de algún conocido o en un hotel.

1.-Introducción

Una de las responsabilidades que tenemos/tienen los bloggers es de mantener actualizado nuestro blog que tanto queremos, incluso si nos encontramos en otros lugares. Sin embargo, no todos disponemos de 3G y algunos tenemos que ir mendigando WiFi por los hoteles, o en casa de un pariente. Yo, con lo paranoico que soy que incluso uso la versión encriptada de Google, siempre trato de intentar comprometer lo menos posible mis datos.

Si no tenemos puesto SSL en nuestro blog de WordPress, y nos logueamos en una red que puedan tener monitorizada, fácilmente nos sacan nuestro user y pass, por lo que tendremos que buscar una alternativa para loguearnos que sea más segura que nuestra propia cuenta.

2.-Buscando un algoritmo

Una idea que se me ha ocurrido para esto, es identificarnos con un hash que varíe, de forma que si es obtenido por algún tercero, no le sirva para nada. Lo más fácil de recordar que varíe, es el tiempo, así que podriamos usar un algoritmo basado en:

  • Caracteres alfanuméricos.
  • Caracteres especiales.
  • Caracteres que varien automáticamente (en función del tiempo).
  • Caracteres que varien de forma controlada.
  • Mayúsculas y minúsculas.

Un ejemplo podria ser en base al siguiente:
///XXlipmanYY///
En donde XX es el dia del mes, y YY la hora. He elegido este par de números debido a que varian lo suficientemente rápido como para que no se reutilicen, y lo suficientemente lento como para controlarlos. Además de esto, usaremos un truco para añadir un caracter aleatorio fácil de recordar. Dependiendo del dia de la semana (lunes, martes…) teclearemos una tecla debajo de los números, dependiendo del dia que sea. Por ejemplo, cuando sea lunes, pulsamos la Q, cuando sea martes la W… (notese que seria en mayúsculas).

Ejemplo completo:
Lunes 20 a las 8AM: ///20Qlipman8///
Martes 21 a las 15PM: ///21lWipman15///
Viernes 24 a las 2AM: ///24lipmTan2///

Notese que las letras mayúsculas “aleatorias” las vamos alternando en las posiciones entre la palabra “lipman”. Para que quede bien, necesitamos palabras de 6 caracteres.
De aquí también podemos descatar lo imprescindible que es que una contraseña no empiece por números o por letras cercanas a los extremos del alfabeto, para que sea todavia más improbable que un brute force nos descubra la contraseña.

3.-Implementando nuestro sistema en WordPress

Ya tenemos el diseño (respecto a la seguridad) de nuestra aplicación, por lo que queda la parte más entretenida: realizar una aplicación para comunicarnos con WordPress implementando nuestro sistema. Voy a poner solo lo que es esencial: comunicación entre nuestra aplicación y la base de datos para añadir entradas. Por nuestra cuenta podriamos desarrollar más cosas, como una mejor interfaz gráfica, pero esto lo dejaré a parte ya que seguramente dejaré esto como un plugin (ya hablaré más adelante) y haré mejoras en todo.

3.1.-Añadiendo posts a nuestra base de datos

Para nuestra suerte, la base de datos de WordPress (y en general la de cualquier CMS) suele ser sencillita, así que no deberiamos de tener problemas para manejarla.
Lo primero de todo, aprovecharemos el fichero de wp-config.php para conectar a nuestra base de datos. Este fichero es el primero que se genera cuando creamos nuestro sitio en WordPress, y contiene los datos de nuestra base de datos: nombre, usuario, contraseña… Así que le haremos un include.

3.1.1.-Analizando la tabla de wp_posts

Lo interesante de este tipo de situaciones, es analizarlas y aprovecharlas para intentar entender el funcionamiento interior de WordPress, por ello, no me limitaré a hacer, copiar y pegar código simplemente, sino que se intentará explicará todo.

A continuación, vamos a escribir los campos que tendremos que tocar (osease, todos menos los que suelen ir a NULL), explicandolos un poco, sobre todo, los que sean menos obvios.

Nombre Comentario
ID Id (PK) del post
post_author ID del autor
post_date Fecha de escritura
post_date_gmt Fecha de escritura (GMT)
post_content Contenido del post
post_title Titulo
post_status Estado: publicado, borrador..
comment_status Permitir comentarios
ping_status Permitir pingback
post_name Nombre parseado (*)
post_modified Fecha de modificación
post_modified_gmt Fecha de modificación (GMT)
post_parent A quien pertenece (*)
guid URL parseada (*)
menu_order Orden: 0
post_type Indica si es un post
comment_count Contador de comentarios

-Nombre parseado: Se obtiene en función del titulo. Si tenemos el siguiente titulo: “Hola Mundo”, obtendremos: “hola-mundo”. Osease, lo que aparece (si lo tenemos configurado así) de enlace.

-A quien pertenece: Esto solo hace referencia a los borradores y demás. Con respecto a los posts publicados, ni caso.

-URL parseada: Esta seria la URL del post en el caso de tenerlo configurado de manera que se viera la ID en la URL. Un ejemplo, en el caso de delanover, si escribiesemos un post con ID 1234, este campo seria: http://delanover.com/?p=1234

3.1.2.-Nuestra consulta

De momento, llevamos lo siguiente:

//Incluimos los datos de configuración de nuestra base de datos
include('wp-config.php');

mysql_connect(DB_HOST, DB_USER, DB_PASSWORD) or die("Error al conectar");

//Creamos la consulta
$consulta_principal = "INSERT INTO `wp_posts`(`ID`, `post_author`, `post_date`, `post_date_gmt`,
	`post_content`, `post_title`, `post_status`, `comment_status`, `ping_status`,
	`post_name`,`post_modified`, `post_modified_gmt`,
	`post_parent`, `guid`, `menu_order`, `post_type`, `comment_count`) VALUES
	('$id', 1,$fecha,$fecha_gmt,'$contenido','$titulo','publish','open','open',
	'$titulo_parseado',$fecha,$fecha_gmt,0,'$id_parseada',0,'post',0)";
		
$resultado_principal = mysql_query($consulta_principal);

Como podemos observar en nuestra consulta, hay variables y valores constantes. Me limitaré a contar un poco las variables al igual que la forma de obtenerlas, ya que los valores constantes son un tanto redundantes.

-ID: Es la ID que tendrá nuestro post. Esta ID se consigue obteniendo el valor máximo de todas las IDs que ya hay, incrementando su valor en uno, de la siguiente manera:

SELECT MAX(ID) from `wp_posts`

-Fecha: Es la fecha de creación de nuestra entrada. Tiene un formato específico y estricto que deberemos seguir para que nos funcione correctamente. El formato es el siguiente: AAAA-MM-DD HH:MM:SS
Obtendremos este formato de la siguiente manera:

$fecha = "DATE '" . date("Y-n-j H:i:s",time()) . "'";

Nota: notese que hay que concatenar “DATE ‘” a nuestra fecha, para que a la hora de introducirlo a la BD lo reconozca como tal.

-FechaGMT: Lo mismo que el anterior, incrementando +2 horas. Todo esto de las fechas, depende totalmente de donde nos encontramos.

$fecha_gmt = "DATE '" . date("Y-n-j ",time()) . (date("H",time())+2) . date(":i:s",time()) . "'";

-Contenido y Titulo: Este par de campos, sencillamente son lo que escribimos de titulo y contenido, por lo que no hay que tratar demasiado.

-ID parseada: Como comenté anteriormente, no es muy dificil de conseguir, simplemente seria concatenando una constante a la ID:

$id_parseada = "http://delanover.com/test_wordpss/?p=" . $id;

-Titulo parseado: Esta la he dejado para el final ya que es la más largilla de hacer, para la cual he creado una función específica. En principio, al ser el enlace, lo unico que puede contener son letras (quitaré las tildes), numeros, guiones bajos y guiones. Por lo que haré lo siguiente:

$titulo_parseado = parsear_titulo($titulo);

function parsear_titulo($titulo){
  //pasamos a minusculas y cambiamos caracteres
  $titulo = strtolower($titulo);
  $titulo = str_replace(" ", "-", $titulo);
  $titulo = str_replace("á", "a", $titulo);
  $titulo = str_replace("é", "e", $titulo);
  $titulo = str_replace("í", "i", $titulo);
  $titulo = str_replace("ó", "o", $titulo);
  $titulo = str_replace("ú", "u", $titulo);
  
  $caracteres_permitidos = array("a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m", "n", "ñ", "o", "p",
  			"q", "r", "s", "t", "u", "v", "w", "x", "y", "z", "1", "2", "3", "4", "5", "6", "7", "8", "9",
  			"0", "_", "-");
  			
  //Si nos encontramos con un caracter no permitido (que no salga en el array anterior), lo eliminamos
  for($a=0;$a

3.1.3.-La tabla wp_postmeta

Afortunadamente para nosotros, el tratamiento de esta tabla será todavia más sencillo, y limitaré mi explicación por no tener demasiado que ver con el tema principal.

Explicaré brevemente los detalles dentro del código fuente:


//Obtenemos el ID maximo
$consulta_metapost = "SELECT MAX(meta_id) from `wp_postmeta`";
$respuesta_metapost= mysql_query($consulta_metapost);
if($resultado=mysql_fetch_array($respuesta_metapost))
	$_id = $resultado[0]+1;

//Introducimos el ID recogido, el ID anterior que teniamos del post, y dos valores constantes
$consulta2 = "INSERT INTO `wp_postmeta`(`meta_id`, `post_id`, `meta_key`,
`meta_value`) VALUES ($_id,$id,'_edit_last',1)";
$resultado_consulta2 = mysql_query($consulta2);
	
$_id++; //Aumentamos el ID ya que vamos a insertar otra fila
//Obtenemos un valor que meteremos, compuesto por el tiempo y el ID del autor
$meta_valor = time() . ":1";
$consulta3 = "INSERT INTO `wp_postmeta`(`meta_id`, `post_id`, `meta_key`,
`meta_value`) VALUES ($_id,$id,'_edit_lock','$meta_valor')";
$resultado_consulta3 = mysql_query($consulta3);

3.2.-Implementando la seguridad en nuestra aplicación

Muy bien, con todo esto ya deberia de funcionarnos el sistema, pero claro, falta lo más importante, implementar la seguridad con ese hash dinámico que generamos.

Lo más sencillo es crear una función que nos devuelva un valor booleano, en función de si el hash introducido es verdadero (entonces se ejecuta) o falso (devolviendo un error).

function comprobar_hash($hash){
$hora = date("H", time())+6; //Obtenemos la hora (la adecuamos en función de la hora del servidor a la hora de nuestro pais)
$dia = date("j", time()); //Obtenemos el dia

//Nuestro salt
$cadena = "lipman";

//En función del dia, generamos un resultado u otro
switch(date("N", time())){
  case 1:
  $nueva_cadena = "Q" . $cadena[0] . $cadena[1] . $cadena[2] . $cadena[3] . $cadena[4] . $cadena[5];
  break;
  case 2: $nueva_cadena = $cadena[0] . "W" . $cadena[1] . $cadena[2] . $cadena[3] . $cadena[4] . $cadena[5]; break;
  case 3: $nueva_cadena = $cadena[0] . $cadena[1] . "E" . $cadena[2] . $cadena[3] . $cadena[4] . $cadena[5]; break;
  case 4: $nueva_cadena = $cadena[0] . $cadena[1] . $cadena[2] . "R" . $cadena[3] . $cadena[4] . $cadena[5]; break;
  case 5: $nueva_cadena = $cadena[0] . $cadena[1] . $cadena[2] . $cadena[3] . "T" . $cadena[4] . $cadena[5]; break;
  case 6: $nueva_cadena = $cadena[0] . $cadena[1] . $cadena[2] . $cadena[3] . $cadena[4] . "Y" . $cadena[5]; break;
  case 7: $nueva_cadena = $cadena[0] . $cadena[1] . $cadena[2] . $cadena[3] . $cadena[4] . $cadena[5] . "U"; break;
  default:
  	$nueva_cadena = "error";
  	
}

//Obtenemos la cadena formada y la pasamos a MD5
$resultado = "///" . $dia . $nueva_cadena . $hora . "///";
$resultado = md5($resultado);

//Finalmente comprobamos si coincide con el hash pasado por parámetro
if($resultado==$hash)
	$final = "Verdadero";
else
	$final = "Falso";

return $final;
}

3.3.-Conclusión y funcionamiento final

Nos falta diseñar la página de "login" en la que tendriamos que recoger el titulo de la entrada, el contenido, y el hash en MD5. Este hash en MD5 recordemos que es nuestra contraseña aleatoria pasada a MD5. Un apunte respecto a esto: imaginemos que nos están esnifando la red y tal. Vale, usamos este sistema y todos felices, pero si a la hora de crear nuestro hash MD5 (para que posteriormente lo valide) usamos una herramienta externa en una página web, nos esnifan esto, y no tiene mucho sentido.

Para ello, recomiendo que tengais un programa o algo, ya que desde la consola de Windows, a diferencia de la Linux, no se puede obtener el MD5 de una cadena. Si no, si teneis un servidor web instalado, lo haceis desde ahí usando la función de PHP "md5".

4.-Códigos finales completos

crear.html




Metemos el hash

Titulo

Contenido

create.php

error
"; function parsear_titulo($titulo){ //Pasamos a minusculas y quitamos las tildes $titulo = strtolower($titulo); $titulo = str_replace(" ", "-", $titulo); $titulo = str_replace("á", "a", $titulo); $titulo = str_replace("é", "e", $titulo); $titulo = str_replace("í", "i", $titulo); $titulo = str_replace("ó", "o", $titulo); $titulo = str_replace("ú", "u", $titulo); $caracteres_permitidos = array("a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m", "n", "ñ", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z", "1", "2", "3", "4", "5", "6", "7", "8", "9", "0", "_", "-"); //Si encontramos un caracter que no está en el array de permitidos, lo eliminamos for($a=0;$a

Cómo proteger entradas de GRUB con contraseña

Siempre es bueno añadir un nivel más de seguridad a tu equipo, pues ahí está tu información, ¿y qué mejor que impedir el arranque de un sistema operativo a extraños? Si tienes el gestor de arranque GRUB (que es lo más común si has instalado un sistema operativo adicional, como Ubuntu o Fedora), puedes proteger cada entrada del menú de GRUB con una contraseña; de este modo, cada vez que elijas un sistema operativo para arrancar, se te preguntará la contraseña que hayas especificado para poder arrancar el sistema. Y como beneficio adicional, si roban tu equipo los intrusos (y tu hermana) no podrán acceder a tus archivos. Se oye bien, ¿no? Y hacer esto es relativamente fácil.

Comencemos abriendo el entorno de GRUB. Abre una terminal y escribe grub. Después, introduce la siguiente orden:

md5crypt

Se te preguntará cuál es la contraseña que deseas. Escríbela y presiona Enter. Obtendrás una contraseña cifrada, que guardarás con mucho cuidado.

Ahora, con permisos de administrador, abre el archivo /boot/grub/menu.lst con tu editor de textos favorito (p.ej.: sudo gedit /boot/grub/menu.lst). Para ponerles contraseña a las entradas del menú de GRUB que prefieras, debes añadir lo siguiente a cada una de las entradas que deseas proteger:

password --md5 encrypted_password

Esto quedaría parecido a lo siguiente:

Antes:
title Ubuntu, kernel 2.6.8.1-2-386 (recovery mode)
root (hd1,2)
kernel /boot/vmlinuz-2.6.8.1-2-386 root=/dev/hdb3 ro single
initrd /boot/initrd.img-2.6.8.1-2-386

Después:
title Ubuntu, kernel 2.6.8.1-2-386 (recovery mode)
root (hd1,2)
kernel /boot/vmlinuz-2.6.8.1-2-386 root=/dev/hdb3 ro single
initrd /boot/initrd.img-2.6.8.1-2-386
password –md5 $1$w7Epf0$vX6rxpozznLAVxZGkcFcs

Guarda el archivo y reinicia. ¡Vualá!

Visto en Ubuntu Buzz

Análisis de tráfico en las aplicaciones de Twitter más “seguras” para Android

Parte 1
Parte 2

En relación al post acerca de la seguridad de nuestros tweets pudiendo ser atacados por un MitM, he decidido analizar el tráfico de datos generado por cada una de las cuatro aplicaciones que usaban SSL para transmitir los tweets y alguna otra información. La verdad es que me he llevado una sorpresa un tanto desagradable, puesto que no hay ninguna que sea segura en su totalidad.

Las aplicaciones analizadas son: Twitter (Oficial), TweetDeck, Seesmic y HootSuit. Tienen en común estas aplicaciones, que se pueden acceder a ellas y ver los tweets cargados anteriormente, junto con lo que esto conlleva (avatares, biografias…). Esto quiere decir que esta información está guardada dentro del teléfono y cada vez que nos conectamos a Internet se va actualizando y reemplazando. Esto es un tanto obvio la verdad. Lo que también deberia ser obvio, es que para el transporte de estos datos, de Internet al telefono, se hiciese todo mediante el protocolo seguro y no es así.

Por un lado, las cuatro aplicaciones cargan los avatares que posteriormente son guardados en el teléfono sin usar SSL, así que con un MitM podriamos sacar todos los avatares.

La otra falta de seguridad que comparten las cuatro aplicaciones son que, si subimos una imagen desde la aplicación para twittearla junto con nuestro estado, esta imagen también se puede recuperar al realizar un ataque MitM y cualquiera que esté escuchando, podria obtenerla, al contrario que en la versión web de Twitter, que si subimos una imagen, no se puede obtener (en la versión segura claro está).

Twitter (Oficial)

Como anteriormente dije, se pueden obtener los avatares que se cargan en la aplicación:

Cabe destacar que la recuperación de tweets, privados, menciones, búsquedas, listas, y todo en general, se hace a través de SSL, por lo que no podrán leer lo que escribimos o recibimos.

Sin embargo, como anteriormente también dije, si que podemos recuperar una imagen que subamos a Twitter directamente desde la aplicación, como podemos ver a continuación:

Finalmente, añadir que otro dato que también podemos recuperar con total precisión, es la geolocalización, es decir, la localización que se recupera al usar el propio GPS del teléfono móvil para posteriormente incluirla en los tweets. Como podemos ver, recuperamos las coordenadas que luego las ponemos en GMaps y tan tranquilamente vemos el sitio, aunque ciertamente poco sentido tiene si esto se realiza en un MitM puesto que al realizarlo en un entorno controlado, ya sabemos donde está.

TweetDeck

Al sincronizar todo por primera vez, como con todas las aplicaciones, se transfieren los avatares, incluso podemos ver que llega un paquete cuyo host es: tracking.tweetdeck.com y realiza una petición GET a la siguiente URL: /track/add_account?cl=android&tw=103288301&tz=120&v=2 de la obtenemos el número identificador de la cuenta de twitter (se hablará sobre esto en otra entrada).

Al actualizar la timeline, tweets de perfiles, privados y demás, se realiza todo mediante SSL, aunque cada 15 minutos (configurable) al actualizarse automáticamente, podemos interceptar un paquete sin tampoco demasiada importancia aunque con ciertos datos, cuyo contenido también es una petición GET de URL /track/ping?android-model=MT15i&android-sdk=2.3.3&cl=android&interval=900&tw=103288301&tz=120&v=2&ver=1.0.7.3. Aparecen el identificador, el modelo, versión de Android y el intervalo de tiempo.

Por otro lado, al subir una imagen, podemos recuperarla al igual que con la aplicación anterior, pero no solo eso, sino que también disponemos del link de la subida que se ha generado, como podemos ver:

Otra característica curiosa que tiene TweetDeck es la posibilidad de traducir tweets o biografias, pero esto tampoco pasa por SSL y es totalmente transparente, por lo que podemos ver el mensaje traducido y el original:

Por último, al agregar y desagregar de favoritos, recibimos los identificadores de los tweets que nos sirven para saber qué tweet hemos añadido o no, también en texto plano.

Como podemos ver, tenemos el identificador del tweet 104311621911982080. De esto también se hablará próximamente.

Seesmic

Al sincronizar por primera vez nuestra cuenta de twitter, además de recoger los avatares de los usuarios, podemos obtener nuestra descripción y último tweet. Al subir una imagen, además de poder recuperarla como en las demás aplicaciones, podemos ver el enlace generado junto con nuestro nombre de usuario e identificador.

Por otra parte, en un paquete de datos, vemos que alguna información es guardada en la siguiente ruta de nuestro teléfono: /sdcard/ANdroid/data/com.seesmic/stats.txt

HootSuit

Esta, es la más insegura de las cuatro sin lugar a dudas: cierto es que los tweets y privados que enviamos se hace a través de la capa segura, pero al actualizar de forma automática (cosa que hace cada 300 segundos) o de forma manual, son totalmente visibles los tweets de nuestro timeline, de nuestro usuario, y nuestros privados. Además, al sincronizar por primera vez también aparecen algunas cookies interesantes junto con nuestra descripción.

Y por supuesto, al subir alguna imagen, también la podemos obtener junto con el enlace en donde se ha subido:

Conclusión

Tristemente, no hay ninguna aplicación segura en su totalidad, pero si de alguna manera tuvieramos que ordenarlas por orden de más seguro a inseguro, seria el siguiente:

Twitter (Oficial) > Seesmic > TweetDeck > HootSuit

Resumen:
–>Todos:
-Recuperación de avatares.
-Recuperación de imágenes subidas al enviar tweet.

–>Twitter (Oficial):
-Recuperación de coordenadas al usar el GPS para ubicarnos.

–>TweetDeck
-Enlace de la imagen subida
-Sistema Operativo, versión y modelo del teléfono.
-ID del tweet que faveamos o desfaveamos.
-Nuestro ID identificador de twitter.
-Obtención de los tweets que traducimos (ambos, el original y el traducido).

–>Seesmic
-Enlace de la imagen subida.
-Nuestro ID identificador de twitter.
-Nuestro nombre de usuario de twitter.
-Sistema Operativo, versión y modelo del teléfono.

–>HootSuit
-Obtención de cookies interesantes.
-Enlace de la imagen subida.
-Obtención de los tweets de nuestro timeline, perfil y privados (junto con información de los usuarios).

Un saludo, lipman

Seguridad en las aplicaciones de Twitter para Android

Parte 1
Parte 2

Desde mi reciente adquisición de un teléfono móvil con Android (más concretamente el Xperia NEO) no he parado de usarlo y descubrir cosas sobre él, ya que era la primera vez que tenia un Android en mi poder (un poco tarde, lo sé). Como soy un adicto al Twitter y no estoy sujeto a una tarifa de datos 3G, siempre que veo una red abierta velozmente activo el Wifi para ver las novedades de mi red social favorita como no (y aquí algunos nos daremos por aludidos, verdad?).

Además de eso, como me gusta probarlo todo (las aplicaciones) para luego poder elegir, busqué por Internet aplicaciones para Twitter y demás, y me topé con un post que listaba un top 10 de tales aplicaciones.

Por ello, me dispuse a instalarme las ocho que me faltaban (ya que siempre he usado la oficial, y la última de la lista la descarté), y tras realizar un MitM entre el dispositivo y el router, pude comprobar que solo cuatro de ellas transmiten los tweets por SSL:

Aplicación ¿SSL?
Plume NO
Tweetdeck SSL
Twicca NO
Twitter Oficial SSL
TweetCaster NO
Twitdroyd NO
Seesmic SSL
HootSuit SSL
TweetTopics NO

Así que si sois de los que nada más detectais una red Wifi abierta os conectais y no os importa correr el riesgo de lo que pueda pasar, al menos usad un cliente de Twitter que use SSL para enviar los tweets.

Un saludo, lipman

[IEWatch] Analizando tráfico de red con este complemento para Internet Explorer

Índice:
1.-Breve Introducción
2.-Acerca del Interfaz de Usuario
3.-Datos de los paquetes filtrados
4.-Tráfico HTTPS
5.-Análisis HTML
6.-Conclusión final

A través de los comentarios de un tocayo mio, en el post de Realizar búsquedas encriptadas con Google me enteré de la herramienta (más bien complemento) IEWatch.

1.-Breve Introducción

IEWatch es un addon para Internet Explorer que nos permite analizar el tráfico de red que pasa por este navegador mientras lo usamos para navegar. Esto supone una ventaja frente a otros analizadores de red, y es que directamente podemos ver el tráfico único que pasa por el navegador sin la necesidad de aplicar ningún filtro. Además de esto, dispone de un analizador de elementos HTML bastante útil y una utilidad que nos permite realizar peticiones POST que veremos más adelante. Finalmente destacar que podemos ver también los contenidos cifrados por HTTPS.

Las pegas que le veo a este complemento para empezar son el precio, ya que no es gratuito (aunque lo podemos tener por el módico precio de 170$ USD) y la incomodidad que supone a la hora de trabajar, ya que si queremos trabajar cómodamente, el complemento ocupará un gran tanto por ciento de la pantalla, dejando poquito espacio para la navegación en si.

Se puede descargar una versión de evaluación de aquí.

2.-Acerca del Interfaz de Usuario

La verdad que se podría resumir en que deja bastante que desear la verdad. Por un lado, en el “análisis HTTP” (del tráfico de red) se divide en tres zonas (en realidad dos): la zona superior donde aparecen los paquetes de red capturados junto con una breve descripción. Finalmente, en la parte inferior, a pesar de estar dividida en dos partes, se tratan de características y datos que contienen los paquetes de datos capturados.

En la parte superior, en el log de los paquetes capturados, no podemos ver ningún tipo de leyenda ni nada parecido para saber qué datos son los mostrados, sino que tenemos que aventurarnos a adivinarlos.

Por otro lado, como dije anteriormente, si quieres trabajar completamente cómodo con el complemento, tienes que expandirlo hasta el punto en que la navegación se vuelve incómoda. Tampoco podemos expandir los campos para ver totalmente los contenidos largos que no caben en la pantalla.

3.-Datos de los paquetes filtrados

Podemos ver cómodamente:

  • Datos de la cabecera
  • Cookies
  • Datos pasados por POST
  • Parámetros y valores pasados por la URL
  • Response Headers
  • Response Cookies
  • Content

Podemos aplicar filtros, como podemos ver en la posterior imagen, sin embargo me parecen un poco escuetos. Sin ir más lejos, en los filtros por tipo de contenido solo se permiten esos tres (text, html y css), echando de menos el javascript. También dispone de un buscador, aunque este no acepta expresiones regulares. Por último, destacar que se pueden exportar e importar resultados en formato XML.

4.-Tráfico HTTPS

La verdad es que siempre me han parecido interesantes los snifers de tráfico SSL y su funcionamiento. Desde que se mostró que aun puede ser inseguro estar tras una página que use HTTPS con sslstrip, han surgido por la red sniffers de este tipo. Sin embargo, sslstrip funcionaba muy fácilmente: es un script en Python que sustituia una versión segura de una página web por una insegura, haciendo que los datos viajen en texto plano en lugar de cifrados, haciendo creer al usuario que está seguro para posteriormente esnifar su conexión con cualquier sniffer.

Sin embargo, no sé como funciona realmente esta funcionalidad de IEWatch , incluso les he enviado un correo para que me expliquen un poco qué han hecho. Al principio me aventuré pensado que podría simplemente crearnos la falsa sensación de que estamos navegando en una página HTTPS siendo que nuestros datos iban en texto plano (en plan sslstrip pero más bonito), pero esto no es así, ya que puse un sniffer a la vez que el IEWatch y pude comprobar que la información viajaba todo el rato cifrada.

También pensé que simplemente podria saber qué estamos introduciendo en el navegador (ya que al ser un complemento, seguro que tiene cierta facilidad para ello) y a partir de eso, crear la falsa sensación de magia para decir que “descifra” los datos que viajan por el protocolo seguro. Pero tampoco es esto cierto, ya que esto funcionaría en el caso de los datos que nosotros enviamos, pero los datos que recibimos (como los valores de los datos de sesión) también se nos muestran descifrados.

Por último, recuerdo haber leido (aunque puedo estar equivocado) que a partir de tener el certificado y las claves (esto ya entraría más bien en el funcionamiento del propio SSL) es relativamente fácil y no sería muy complicado “crackear” el cifrado de los datos, así que definitivamente me aventuro a decir que funciona de esta manera o de otra que no se me ha ocurrido, pero repito que les envié un mensaje y espero que me respondan para poder explicar cómo lo consiguen.

5.-Análisis HTML

No es casualidad que una herramienta de análisis de tráfico de red lleve incorporado una subherramienta (por llamarlo de alguna manera) que analice los elementos HTML de las páginas, sobre todo si se trata de un complemento incorporado en el navegador.

De forma sencilla se pueden visualizar datos como: el código HTML, imágenes, enlaces, formularios, scripts, y todavía más, como podemos ver en la siguiente imagen.

Como podemos ver en la parte izquierda, disponemos de una estructura a modo de árbol, en la que al clickear encima de un elemento (como un script) podremos ver a la derecha su contenido.

Otro par de características interesantes son los botones de HTML Spotlight y HTML Designer. La primera de ellas nos permite mostrar el código HTML de un elemento tras clickearlo, y la segunda, nos permite editar una página web en modo local, como si se tratase de un documento, es decir, clickeando en donde queramos añadir o editar texto, y demás.

6.-Conclusión final

Esta es la clase de herramientas (en este caso, complementos) que usamos una vez cada mil. El complemento no está nada mal, sin embargo, por el precio que cuesta (incluso por el simple hecho de costar dinero, habiendo analizadores de red y de HTML mejores y gratuitos en el mercado) no merece la pena ni tenerlo, ya que el dia menos esperado nos salta el aviso de que se nos ha acabado la versión de prueba.

Como dije anteriormente, es muy sustituible (salvo por el tema de ver HTTPS sin cifrar) en cuanto a analizar la red (función principal) ya que con Wireshark simplemente poniendo un filtro diciéndole que nos muestre el contenido HTTP o similares, tendriamos lo mismo. Y con respecto a la función de analizador HTML, me quedo sin duda con firebug.

Un saludo, lipman