Archivo de la categoría ‘Seguridad’

WhatsApp (Android): Como volver a tener la opción de “Descarga automática de imágenes”, para poder deshabilitarla (Actualizado)

Actualizado: A fecha de de 2 de Junio, las versiones a partir de la 2.10.509 (aun no disponibles en Play Store pero deberían de estarlo dentro de poco tiempo) disponen de opciones personalizadas para permitir o denegar la descarga automática de imágenes, vídeos o audio dependiendo de si estemos por WIFI, por datos o en Roaming. Gracias por replantearse la política de empresa al respecto.

 

Lo cierto es que ha sido un amigo el que me ha dicho esta mañana que la opción para permitir o denegar la descarga automática de imágenes le había desaparecido con la última actualización. En realidad no se trata de la última actualización, es un cambio que hace ya muchos meses efectuó WhatsApp, lo único que sucede es que para que la aplicación no falle por tener activadas ciertas opciones (y no tener que “resetearlas”), todos aquellos que tenían dicha opción deshabilitada han mantenido teniendo dicha opción dentro de los ajustes de su WhatsApp. En cambio, todo aquel que instalase de nuevas la aplicación o tuviese que eliminar los datos de ella por cualquier motivo, no tiene acceso a ella. Por suerte para todos, la aplicación continúa manteniendo exactamente el mismo comportamiento, simplemente oculta la opción para que no pueda modificarse… y es ahí donde entramos nosotros.

Sinceramente no entiendo cual ha sido la razón por la que WhatsApp a quitado la opción, me parece genial que por defecto la mantuviese activada, pero siempre con la opción de quitarla. Del FAQ de su web nos dicen lo siguiente:

“As part of a product decision, we have removed the ability to turn off auto-download images from recent versions of WhatsApp. If your friends still see this feature on their phones, they most likely have an older version of the app.

We understand your concern for data usage; however, images on WhatsApp are down-sized, resulting in a typical image size and data usage of approximately 40-50KB per image. In comparison, the average web page on the internet is 1 MB (1000 KB).

Keep in mind this applies only to image files and not to videos or audio notes, since videos and audio files are significantly larger.

Therefore, even if your WhatsApp contacts send you 100 images every day for an entire month (30 days), that would total to 135MB of data usage. Of course, that’s an extreme case and more often the average WhatsApp user receives 19 images per month; this is equivalent to 855KB, or 0.83MB per month. Rest assured, this amount is covered by even the smallest data plans.

You can also check your actual data usage within WhatsApp by going to Settings > Account Info > Network Usage

You can see the exact media data usage under “Media bytes received.”

In order to stop the WhatsApp images from appearing in your gallery, we recommend that you create a .nomedia file or folder inside of your WhatsApp images folder. You can do this using a file explorer, or by hiding the folder in Quickpic.”

Sinceramente me parece una explicación bastante mala. Traduciendo y resumiendo, la única explicación que dan de dicho cambio es que las imágenes transferidas por WhatsApp ocupan muy poco (aparentemente), y pro tanto no hay razón por no descargarlas automáticamente. Y para aquellos que puedan pensar: “Ya no se trata de lo que ocupen, también una cuestión de privacidad porque CUALQUIERA puede enviarte cualquier imagen, y si por defecto se autoacepta esta va a la galería.” WhatsApp termina respondiendo que si no se quiere que aparezcan que se cree un archiv ollamado “.nomedia” en la carpeta raiz de WhatsApp para inhibir que aparezca en la galería.

Es cierto que Android permite ese “truco” para inhibir que una carpeta sea listada en la galería o en el reproductor de medios, pero sigo sin entender porqué pasamos de tener una opción que TOODOS podían activar o desactivar a voluntad sin mayores problemas, a tener que fastidiarnos y tener que hacer “trucos” molestos si queremos apalear solo algunos de los problemas que implica tener dicha opción activada.

En el artículo de WhatsApp: Lo que todo buen bromista debería de conocer, creo que dí motivos más que suficiente del peligro que implica tener esta opción marcada, ahora marcada o sí o también:

a) Cualquier puede enviarnos una imagen, eso implica que conozcamos al usuario o no puede mandarnos el tipo de imagen que queramos y el móvil la recibirá sin problema. Esto significa que si un desconocido nos manda a nuestro teléfono la imagen de un muchacho haciendo guarrerías con cualquier animal, esa imagen va directamente a nuestra galería.

b) Por mucho que diga WhatsApp, es un gran consumo de ancho de banda, y si estamos dentro de grupos numersos en los que se suelen compartir imágenes, el ancho de banda puede incrementarse considerablemente. Por otro lado es mentira que la media de los datos usados sean de 40-50KB por imagen, si hago media de lo que tengo ahora mismo en mi galería, me da 80KB, una horquilla entre 70-130KB, dependiendo de las imágenes. Eso significa que esas 100 imágenes al día que dice WhatsApps tendría un consimo de ) serían entorno a los 380MB, SOLO en imágenes de WhatsApp.

c) Como ya expliqué en el artículo anteriormente citado, puedo crear en un momento una imagen de 1GB si quiero, y dado que el usuario no tiene forma humana de deshabilitar la descarga automática de la imagen, su dispositivo empezará a descargar dicha imagen de 1GB me conozca o no me conozca, y en todo caso podrá cancelar la descarga (si es que puede) una vez se de cuenta de lo que está pasando, lo cual es también relativo porque se le puede engañar al sistema para que el usuario crea que la imagen ocupa tan solo 10KB. dicho de otro modo, forzando al usuario a dicha opción, lo condena a quedarse sin datos si cualquiera que tenga su número le gusta ser un bromista pesado. Y si dicha imagen la manda en un grupo de 20 personas, seguramente ni siquiera se daran cuenta de lo que ha pasado, hasta que estén bien jodidos.

 

Visto esto, solo nos quedan tres soluciones… cuatro. La primera pasa por empezar a usar en la medida de lo posible HangOut, que aunque no sustituye todas las funciones de WhatsApp, es mucho mejor, pero eso ya entra dentro de lo personal de cada cual.

La segunda y posiblemente casi cualquiera pueda realizarla, pasa por instalar una versión antigua de WhatsApp que permitiese aun tener dicha opción, posiblemente alguna versión 2.8.xxx, estoy seguro que por google pueden encontrase. La idea por tanto sería sencilla, desinstalar WhatsApp, instalar la versión vieja, desmarcar la opción de descarga automática, actualizar a la versión más actual y listo. Cualquiera podría realizar este proceso, siempre y cuando WhatsApp no haya bloqueado ya las versiones viejas.

La tercera opción e igualmente sencilla, aunque tan solo temporal de nuevo, radica en editar el archivo de configuración de WhatsApp y añadirle la opción que deseamos. Como he dicho, Whatspp al iniciarse chequea si ya existía dicha opción en el archivo de configuración. Si existe la deja, si no existe (porque sea una instalación limpia o cualquier otro motivo, la opción no existe. El problema de este método es que necesitamos tener el dispositivo Rooteado, porque necesitamos editar el archivo de configuración de WhatsApp que se encuentra en la partición /data, exactamente en la ruta “/data/data/com.whatsapp/shared_prefs/com.whatsapp_preferences.xml”. Al encontrarse en la carpeta data de la aplicación, implica que dicho archivo tan solo lo puede editar la misma aplicación o un usuario con permisos superiores, es decir root.

Suponiendo que tengamos el dispositivo rooteado, tan solo hay que editar dicho archivo y añadir en la lista de opciones:

Para evitar que la aplicación tenga acceso a él mediante lo hacemos, podemos detener la aplicación por completo en el administrador de aplicaciones de Android, realizar la modificación y lanzar de nuevo la aplicación. Como si por arte de magia fuese la opción vuelve a aparecer (y con la opción desactivada por defecto). El único inconveniente es que no sabemos cuando WhatsApp eliminará por completo dicha opción, o que tendremos que repetir el proceso si realizamos una instalación limpia o se borran los datos de la aplicación.

La cuarta opción es la más útil, pero la más “complicada”, ya que de nuevo se trata de modificar el código de la aplicación. En este caso la modificación es muy muy sencilla, porque el código de WhatsApp ya permite dicha opción. Si lo que hace WhatsApp es chequear si la opción está o no está presente en el archivo de configuración, traducido a código lo que buscamos es un salto condicional, un sencillo “if”: Si la opción existe mostrar lo siguiente… Si sabemos encontrar ese pedazo de código, bastaría simplemente con eliminar la condición, con lo que la opción aparecería SIEMPRE, con independencia de que sea una instalación nueva o vieja. La complejidad de nuevo radica en que hay que:

a) Decompilar la aplicación
b) Encontrar el archivo y el lugar exacto de la edición
c) Saber que editar/añadir/eliminar
d)Saber recompilar la aplicación
e) Firmar la aplicación de nuevo (si queremos que Android la acepte perfectamente, pero al iniciarla tendremos q restaurar una copia de seguridad porque detectará que se ha modificada) o dejarle los certificados antiguos para que no de error al verificar la cuenta (pero entonces tendremos que tener parcheada la verificación de certificados). Personalmente me gusta más siempre la primera opción, pero cada cual escoge su sistema favorito, en el caso de WhatsApp se podría terminar de modificar la aplicación para que tampoco se quejase en la verificación de los certificados, pero sería más edición.

Todos los demás puntos los hemos visto aquí varias veces, así que tan solo voy a ayudar d enuevo con el punto b y el punto c.

En este pequeño cambio, solo hay un archivo implicado, una sencilla búsqueda con findstr en Windows o grep en linux rápidamente nos pondría en la pista de lo que estamos buscando. Es muy sencillo, sabemos como se llama la opción, así qeu si buscamos por “autodownload” llegaremos al id en hexadecimal de la etiqueta, y si buscamos por dicho id, llegaremos al archivo implicado y a la sección de este. Si miramos un poquito más arriba de donde encontramos el id de la etiqueta, tenemos la condición que se ejecuta, con lo que tan solo habría que eliminar la instrucción if que lo precede. Esto en lenguaje de alto nivel sería trivial, en Dalvik es un poquito más engorroso porque hay que saber que borrar o que no borrar, no leemos un sencillo if… sino toda una estructura basada en registros que va cargando los valores necesarios para invocar la condición. Es un bloque pequeño de todos modos, y tampoco es complicado verlo ni eliminarlo

Una vez terminada la edición, se guardan los cambios, se recompila, se firma, se vuelve a colocar la aplicación y aquí no ha pasado nada, volveremos a tener nuestra nuestro WhatsApp con la opción deseada. Claro que si actualizamos perderemos el cambio y tendríamos que volver a realizarlo, lo cual puede ser un poco engorroso para muchos. De ahí a que llega un momento en que es más sencillo crearte tus propias herramientas que automatizan todo el proceso por tí. En cualquier caso, de nuevo se trata de ser didáctico, y de paso decirle a los chicos de WhatsApp que no tiene ningún sentido el cambio que han realizado, lo cual evidentemente nos dice que tienen otros motivos que no están contándonos 😉

whats

Vulnerabilidades en 2012: Windows 7/8, OSX, SmartPhones y Navegadores

Este año las felicitaciones navideñas y el próspero año nuevo se quedaron en aguas de borrajas, aunque no por eso quiera decir ni mucho menos que los días de escribir algunas cosillas en el blog terminaron. Así que antes de comenzar, aunque vaya un mes tarde, espero que todos pasásemos unas felices navidades, y que este año sea próspero para todos.

Dicho esto, ya el año pasado hice exactamente lo mismo para con los datos de 2011. Así que este año había que hacer lo mismo para el año 2012 que ya hemos dejado atrás. Los datos de nuevo están extraídos desde Secunia y el NIST

Muchos pueden creer que no es importante estos datos, pero sinceramente al menos para mí, no como aficionado a la materia sino como usuario diario de estos software es de suma importancia, lo suficiente muchas veces como para ver si uso el software correcto, o a la hora de aconsejar a otros sobre que productos decantarse. Es algo que siempre me ha sorprendido enormemente, cualquier persona se escandaliza si ve una pantalla de publicidad con un mensaje extraño, pero nadie se escandaliza cuando le dicen que su dispositivo o su equipo se encuentra en serias deficiencia en cuanto a seguridad, y que cualquier Hacker inteligente podría tomar el control de su dispositivo. Cuando intentas contarle esto a las personas te miran raro, o te dicen eso de: “Total para lo que tengo…”. En cambio, es cuando a esa persona le sucede algo por culpa de ello, es ya siempre tarde, y no son uno ni dos ni tres los casos al año, raro es el mes que no leo en mi correo o por cualquier otro medio alguien que tiene un problema, y no precisamente por que el navegador no deja de reenviarle a webs pornográficas.

Es por todo ello, que el principal problema de seguridad que existe a día de hoy es la ignorancia, el creer que nadie puede estar interesado en nuestros datos (cuando son oro puro para muchos), el creer por pura fe lo que le dicen otros, que posiblemente tienen aun más problemas que él, aunque no lo sepa. La mejor forma de enseñar, no es con miedo, no es con críticas baratas, es simplemente mostrando datos, enseñando que hay, que no hay, y que cada cual sea por tanto quien saque sus propias conclusiones.

 

Bien, el objetivo de este post como el del año pasado, es ver el número de fallos de seguridad (vulnerabilidades) acumulado durante este año pasado 2012 en sistemas operativos de escritorio, de dispositivos portátiles y de navegadores web. Eso no quiere decir que no existan otros problemas de seguridad ni mucho menos, los datos que puedo mostrar son datos PÚBLICOS que cualquiera puede tener acceso, en concreto mis datos recogidos son simplemente los CVE registrados. CVE son los reportes (un identificador) que asigna un organismo internacional a vulnerabilidades/fallos de seguridad. Hay que tener en cuenta ciertas cosas a la hora de interpretar los datos

Primero, un CVE NO IMPLICA de modo alguno que un hacker podría hacerse con el control total de tu dispositivo a través de él, un CVE es un problema potencial de seguridad que puede ser explotado con fines malignos o no, y que por supuesto su peligrosidad varía enormemente en relación con el tipo de fallo descubierto. De este modo, tenemos problemas de seguridad menos peligrosos como los que “simplemente” exponen datos de nuestro sistema o datos sensibles al exterior sin nuestro consentimiento, pasando por fallos de seguridad que permiten el Spoofing, el Cracking, escaladas de privilegios, ataques de denegación de servicio… y por supuesto hasta llegar al peor de los males, como es el acceso al sistema, que son vulnerabilidades que se pueden aprovechar para la ejecución de código remoto (digamos, el santo grial siempre del Hacker)

Segundo, hacer una tabla con el número de fallos de seguridad sin tener en cuenta otros datos sería totalmente demagogo, hay que entender muchas veces como se recogen dichos datos, si puede existir una explicación “decente” a dichos números… de lo contrario entraríamos de nuevo en escribir artículos partidistas en los que el redactor siempre haría que ganasen unos y otros en función de sus intereses. Aquí no se trata de ganar o perder, se trata de exponer datos y explicar lo que puede explicarse con las razones que puedan darse. A partir de ahí, cada cual tendrá que pensar un poco por si mismo y sacar sus conclusiones, no creerse los datos expuestos y fijarse simplemente en una tabla de datos.

Por el segundo punto, voy por ello a recalcar con mucho énfasis la gran importancia de esos “atenuantes” o “detonantes” de este número de vulnerabilidades. De echo en mi humilde opinión, que un producto haya obtenido el mayor número de vulnerabilidades a lo largo del año no implica que sea un producto inseguro per sé, eso hace solo un 50%, el otro 50% reside (de nuevo en mi opinión) en las políticas de actualizaciones/distribuciones de los desarrolladores, y del índice de penetración del mercado que posee cada producto. Las políticas de actualizaciones/distribución es esencial para tener nuestros sistemas dispositivos siempre al día, y la penetración del mercado es esencial para entender que plataformas están mucho más expuestas a todo tipo de ataques, a fin de cuenta nadie quiere encontrar un fallo de seguridad que afecte a un 1% de la población, lo intentan buscar en productos que afecte a un 50%, aunque sea 100 veces más complicado el hacerlo.

Las versiones usadas en cada caso, correspondería con las versiones que dicho producto ha tenido durante estos pasados 365 días. Por ejemplo en el caso de Windows, se han sumado los fallos de seguridad de Windows 7 de TODO el año conjuntamente con los de Windows 8 de TODO el año (desde que se terminó la versión de oro en Agosto. Lo mismo para cada producto. El índice de penetración de mercado se calcula simplemente tomando el porcentaje global de cada producto, y este a su vez se divide en función del índice de penetración que posee dicha versión dentro de dicho producto, si posee más de una versión ese producto en el período a tratar (2012), se suma dicho porcentaje. Es  decir, que si Windows posee por ejemplo un 90% de cuota de mercado y fuésemos a tratar SOLO windows XP, y que este fuese un 50% de todos los Windows instalados, el porcentaje real de Windows XP sería por tanto de un 45%, el 50% de ese 90%. Es simple.

 

Sistemas Operativos: Windows 7/8 VS OSX Lion/Montain Lion

Escritorio

 

Los datos son escalofriantes un año más, tanto en fallos de seguridad como en cuota de mercado.

  • Windows 7 en conjunto con Windows 8 poseen una cuota de mercado aproximado de un 50%, y terminaron el año con solo 50 fallos de seguridad
  • OS X Lion en conjunto con OS X Montain Lion posee una cuota de mercado conjunta aproximado del 5%, y terminaron el año con la friolera de 164

Los datos que tendríamos que obtener serían totalmente inversos, dado que Windows 7/8 posee una cuota de mercado 10 veces superior, el número de fallos de seguridad quizás no tendría que ser proporcionalmente también diez veces superior, pero evidentemente superior. En cambio el panorama no es así. A pesar de que Windows 7/8 están asentados en el 50% de los PCs de escritorio (un 92% aproximadamente todas las versiones de Windows en su conjunto), y a pesar de que OS X tan solo posee una cuota de mercado (sumando todas sus versiones) de un 6-7%, OS X posee una tasa de problemas de seguridad muy superior a Windows, la triplica!! Con el índice tan bajo de cuota de mercado y dicha tasa de problemas, teniendo en cuenta que OS X es igualmente software de código cerrado, deja claro sin lugar a dudas que es un sistema muy vulnerable.

Como ya dije anteriormente, hay que ver también la política de empresa de cada desarrollador de cara a las actualizaciones o el despliegue de su software. Una tasa alta de fallos de seguridad es mala, pero dentro de lo malo puede ser menos malo si se implementan políticas de actualizaciones rápidas, de respuesta inmediata ante cualquier tipo de vulnerabilidad que se descubra. Estos datos son igualmente públicos y se conoce la política de estas dos grandes empresas ante los fallos de seguridad:

  • Microsoft: Publicación estándar mensual de todos los boletines de seguridad, así como actualización de las definiciones de malware y otras actualizaciones (no de seguridad). Dicha publicación se realiza el segundo martes de cada mes. Al margen de este ciclo estándar, a veces también se han lanzado actualizaciones esporádicas en cualquier momento del año cuando se había detectado un problema de seguridad muy grave o para solucionar un fallo existente que ya se estaba usando para causar estragos. Eso quiere decir que en el año 2012 Microsoft lanzó sus actualizaciones en al menos 12 entregas.
  • Apple: No posee un calendario fijo de actualizaciones, suele lanzar sus actualizaciones en forma de macropaquetes, distribuidos a lo largo de todo el año. El problema es que a lo mejor en todo el año tan solo lanza 3-4 de estos. Eso quiere decir que aun cuando aparece un fallo de seguridad grave, el usuario puede necesitar de al menos unos meses para que Apple haga caso. A lo largo de 2012 Apple lanzó 5-6 paquetes de este tipo, y solo intervino en una actualización espontánea no ante la gravedad del fallo de seguridad que les afectaba, sino porque dicho fallo saltó a los medio de prensa. Es una pena, pero Apple tan solo lanza actualizaciones de forma rápida cuando el problema se ha hecho eco en los medio.

De nuevo, otro fracaso por parte de Apple y su OS X, fracasa en fallos de seguridad al año, fracasa en número de fallos de seguridad si tenemos en cuenta la tasa de mercado estrepitosamente, y lo que es peor, la política de actualización de Apple es pésima, lo que hace que los usuarios sean propensos de sufrir problemas de seguridad por exploits y otros medios que llevan circulando por la red a lo mejor durante meses, sin que Apple haga nada.

 

SmartPhones: Android VS iOS VS Windows Phone

 smarphones

 

En este caso no tenemos dos competidores, tenemos 3, y si bien es cierto que Windows Phone aun no tiene una cuota de mercado importante, es previsible que vaya subiendo poco a poco. Pero discutamos estos resultados teniendo en cuenta la penetración en el mercado que tiene cada OS:

  • Windows Phone posee tan solo un 3% aproximadamente de cuota de mercado dentro de los Smartphones, y tan solo se ha conocido un boletín CVE en todo 2012. Este resultado por tanto es totalmente consistente, es decir, con una tasa de mercado que ronda el 3%. al margen de lo seguro o lo inseguro que sea el sistema, es comprensible que el número de fallos sacados a la luz en este año sea mínimo. De nuevo esto no quiere decir que el sistema sea más o menos seguro que el resto, pero al menos sus datos son repito consistentes.
  • Android posee un índice de mercado entorno al 75%, eso quiere decir que más o menos 3 de cada 4 dispositivos Smartphones que se venden es Android. A pesar de ello terminó el año con 8 CVE, un dato bastante bueno para tener un 75% de cuota de mercado, ya que implica que Android es a día de hoy la plataforma más… “jugosa” de cara a los Hackers
  • iOS posee una cuita de mercado entorno al 15%, que no es poco ni mucho menos, pero en su caso terminó el año con la friolera de 94 fallos de seguridad. Que sea mucho o poco no podemos juzgarlo de forma sencilla, pero si simplemente lo comparamos con Android que posee una penetración de mercado 5 veces superior y menos de la décima parte de fallos de seguridad…

Estos datos son aun más inexplicables si tenemos en cuenta otro factor que aun no se ha comentado, que es que software que vamos a ver aquí, es de código libre. Cuando un software es de código libre cabe esperar que en igualdad de condiciones registre siempre un mayor de fallos de seguridad publicados. Esto es muy sencillo de entender, si es de código abierto CUALQUIERA puede acceder al código fuente y buscar y encontrar vulnerabilidades de forma mucho mucho mucho más sencilla. Esto lo veremos con claridad un pelín más adelante con los navegadores Web.

Bien, Android es de código abierto, y además posee una cuota de mercado de un 75%, esto significa que los resultados habrían sido consistentes y relativamente lógicos si fuese Android y no iOS quien tuviese esos 94 fallos de seguridad. Es más, si así hubiese sido, durante un mes estaríamos escuchando en todos los medios lo vulnerable que es Android. Lejos de eso, es iOS con tan solo un 15% (mucho si tenemos en cuenta el total, poco si lo comparamos con Android), a pesar de código totalmente cerrado, alcanza la friolera de 96.

En cuanto a políticas de actualizaciones y distribuciones:

  • Microsoft al igual que hace con su OS de escritorio, suele ser relativamente rápido a la hora de tapar cualquier problema de seguridad. No podemos saber no obstante su política exacta ante Windows Phone, puesto como ya se ha dicho con tan solo un fallo de seguridad en 2012 no se puede cuantificar demasiado bien su tiempo de respuesta.
  • Google por su parte es conocido en todos los ámbitos por dar siempre una respuesta casi inmediata ante cualquier fallo de seguridad, este es inmediatamente corregido en los repositorios AOSP para que cualquiera pueda aplicar el fix que sea necesario. Aquí hay que indicar que existe un retraso significativo no a la hora de actuar contra el problema, sino en que los fabricantes lo adepten. No es un fallo de Google de echo, es de las políticas de cada uno de los fabricantes. Lo general es que ante un fallo de seguridad grave, los fabricantes puedan tardar en lanzar actualizaciones a sus dispositivos hasta dos y tres meses.
  • Apple aplica la misma filosofía que con OSX, hasta que el fallo no trasciende a los medios de comunicación le da igual la gravedad del problema, y por desgracias tenemos muchos ejemplos de ello. De echo, precisamente aparece en los medios, porque es algo fragante que está totalmente extendido. Así aun recordamos todos el fallo de seguridad que permitía tomar el control de cualquier iPhone simplemente a través de unos SMS que se enviaban, o al menos 4-5 fallos de seguridad críticos que permitían igualmente apoderarse del control total del dispositivo simplemente haciendo que el usuario accediese a una web concreta. Fueron necesario meses y meses antes de siquiera lanzar una actualización para ello, a lo que a partir de aquí hay que sumar el tiempo que tardaría cada cual en aplicar dicha actualización.

 

Navegadores WEB: Opera 11/12, Internet Explorer 9/10, Firefox 10..17, Safari 5/6. Chrome 17..23

 navegadores

 Veamos en esta ocasión la consistencia de los fallos de seguridad de cada navegador atendiendo a su cuota de mercado, aunque en el caso de los navegadores hay que añadir un factor adicional que posee tanto Firefox como Chrome y que se debe de tener muy en cuenta:

  • Opera registra el menor número de fallos de seguridad, con tan solo 34 boletines CVE si sumamos los fallos de seguridad de todo 2012 a las versiones que estuvieron en funcionamiento en él, pero hay que tener en cuenta que posee una tasa de mercado muy pequeña, entorno al 3%. Es necesario por tanto ver el resto de navegadores para ver si sus datos son consistentes, y lo cierto es que más o menos si lo son. No es una tasa demasiado elevada, era de esperar que al tener tan poca tasa de mercado sería el que menor número de boletines acapararía. Aun así, desde mi punto de vista, para tener tan solo 3% de cuota me parece un valor alto
  • Internet Explorer 9 y 10 suman un total de 39 problemas de seguridad, algo más que Opera, pero con una gran diferencia, y es que IE tiene una penetración que ronda el 39%, eso multiplica por 10 la expansión de IE frente a Opera, y aun así tan solo llega a 39. Este dato es muy sorprendente.
  • Firefox si lo comparamos con los datos del año pasado a sufrido un incremento exponencial (que ya veremos debido a que), terminado 2012 con 216, muy superior a los 39 de IE sin duda alguna, y posee un share entorno al 25%, nada despreciable tampoco.
  • Safari alcanza los 274, pero en este caso el share de este es igualmente mínimo, rondaría el 6%.
  • Chrome por su parte comparte todos los pros y contra de Firefox, solo que en este caso llega a los 277 boletines, con un mercado que ronda el 36%, eso significa la segunda posición en cuanto a su uso.

Antes de analizar esto, hay que tener en cuenta que tanto Chrome como Firefox son de código abierto, y que ambos ademeás poseen ciclos de productos muy cortos, solo hay que ver que en todo 2012 el resto de los navegadores difícilmente cambiaron en uno la versión de sus productos, mientras que Firefox vivió 2012 con 8 versiones diferentes, y Chrome lo hizo con 7. Esto es a tomar muy en cuenta, ciclos cortos permiten un progreso más rápido de los navegadores, pero también implica que aparecerán más problemas de seguridad, aunque (y esto es importante) solo afecten a versiones concretas de ellos. Es decir, Chrome y Firefox poseen una tasa mucho más alta fundamentalmente a que participan con muchas más versiones, pero no quiere decir que todos esos fallos de seguridad afectasen a todas las versiones, de echo si dividimos el número CVE entre el número de versiones lanzadas, vemos que el resultado es mucho más cercano al que logra obtener IE.

Dicho esto, de todos modos el ganador indiscutible es Internet Explorer, aunque es cierto que es de código cerrado, con una tasa tan grande de mercado y con tan solo 39 fallos de seguridad en todo 2012, nadie puede acercarse. Impresionante trabajo por marte de Microsoft. El segundo lugar sería más complicado, Opera tiene un resultado muy bueno, pero un 3% es muy poco significativo, por tanto el segundo lugar sería quizás para Firefox, sí, son 216 CVE, pero si tenemos en cuenta que posee un 25% de mercado, ciclos cortos y de código libre, hay que entender el gran trabajo que hay de fondo. Del mismo modo y rozando los talones estaría Chrome con algunas más, aunque también con un porcentaje de mercado algo superior. Después si situaría a Opera, y por último tendríamos Safari, que aun cuando tendría que partir de una postura ventajosa como Internet Explorer, fracasa estrepitosamente en todo. Con tan solo un 6% de mercado, aun asiendo de código cerrado y con ciclos largos, obtiene el el segundo peor número, muy cercano al de Chrome, con 274. A diferencia de Chrome, Safari no tiene excusa alguna de tal número de fallos de seguridad, y tampoco puede culparse a las diferentes plataformas ya que desde Safari 6, este tan solo se usa en OS X.

Las políticas de actualizaciones y distribución en algunos casos son las mismas ya comentadas:

  • Opera actúa ciertamente con bastante rapidez ante cualquier problema de seguridad, no tiene una actuación inmediata, pero se puede tener la cierta seguridad de estar protegido por fallos de seguridad que salen día a día. Si es un fallo crítico, posiblemente tendrían una actualización lista en dos o tres días.
  • Microsoft aplica a Internet Explorer su misma política que a Windows, usa los boletines de seguridad mensuales de Windows para actualizar Internet Explorer, y solo cuando un problema grave de seguridad es detectado se plantea el lanzamiento de una actualización fuera de su ciclo normal. Eso nos dice que con seguridad Internet Explorer suele estar actualizado y protegido con un intervalo de un mes, y si es urgente de nuevo casi de forma inmediata, unos días como mucho
  • Mozilla y Google al usar un navegador de código abierto y ciclos cortos, la actuación ante problemas de seguridad es prácticamente inmediata, en cuanto es conocida o comunicada, sin importar demasiado el grado de importancia que tenga problema encontrado es corregido con la mayor presteza en los repositorios oficiales, y en cuanto son probados se lazan actualizaciones inmediatas al propio navegador, que se actualiza el sólo sin intervención siquiera muchas veces del propio usuario. Sin duda alguna son las dos compañías que reaccionan más rápido ante cualquier amenaza. Bravo por ambos.
  • Apple por su parte usa también la misma filosofía que en OS X o en iOS, actualizaciones esporádicas en las que aprovechan para parchear todo lo que tengan pendiente, no importa si el fallo de seguridad lleva circulando dos días o un mes, si no ha trascendido a la prensa no cambian su calendario. Eso hace evidentemente que el navegador del usuario se encuentre constantemente en peligro, y más si vemos el gran numero de fallos que acumula, con 274 fallos de seguridad tenemos una media de 0.7 fallos diarios, lo que quiere decir que el usuario de Safari está sencillamente “jodido”, usar Safari implica estar expuesto a cualquier Hacker básicamente.

Pronto será el Pwn2Own como todos los años, en el que los navegadores se expondrán en un concurso de Hackers a ser destrozados. Aquí es donde vemos realmente no lo bueno o malo que sea el navegador en aguantar (que también), sino las políticas de empresa de cada cual. Cuando veos que dos o tres días antes del Pwn2Own Apple lanza apresuradamente un macro paquete de actualizaciones, algo te dice que es mejor huir de dicho navegador. Google hace lo mismo no nos engañemos, aprovechará días antes para parchear al máximo Chrome e intentar pasar indemne la prueba del Pwn2Own, pero en su defensa tenemos que decir que es un patrocinador oficial del Pwn2Own y que hace precisamente estos días una competición similar, dicho de otro modo y pese a intentar aprovecharse el día antes para actualizar su navegador, posiblemente es la empresa que se toma más en serio la seguridad de los 5, o al menos lo demuestra. Microsoft el año pasado ya optó por jugar limpio y no lanzar ninguna actualización a destiempo, es decir, fue el único que jugó limpio…. veremos este año que sucede.

Es por eso que aunque Firefox o Chrome posean las tasas mas altas de problemas de seguridad (quitando Safari), es casi imposible que ninguno de esos fallos de seguridad pueda afectar al navegador, a menos que alguno de ellos sea lo que se conoce como un Zero Day Exploit, es decir, un exploit que se aproveche de un fallo de seguridad que aun no ha sido comunicado o hecho público. Es la única forma, puesto de lo contrario si el usuario mantiene su navegador actualizado (que generalmente se automantienen ellos), estará siempre protegido. Internet Explorer es igualmente complicado atacarle con un CVE ya publicado, aunque es posible, si un exploit aparece para aprovechar un CVE, con suerte es posible usarse durante unos días. Ese es el problema de Sarafi, que es posible usar contra él exploits que afectan a CVE publicados incluso meses antes, sin que el usuario pueda hacer nada al respecto porque no hay ninguna actualización que le protega ante ellos, y hablamos de exploits y fallos de seguridad, aquí no sirven de nada los corta fuegos o cualquier otro tipo de medidas.

 

Tener un número alto de fallos de seguridad es malo, este número es alto o bajo solo si lo comparamos con productos similares y vemos que número podría ser más o menos aceptable o lógico, es cuando vemos la capacidad realmente de los programadores y lo serio que pueden tomarse la seguridad. Pero eso no hace ni mucho menos que nuestros dispositivos sean más o menos seguros, es importante, pero no es algo que lo decida por completo, como hemos dicho con Google o Mozilla, es incluso más importante el tener una actuación inmediata ante cualquier problema, es la única forma de tener la certeza, o al menos la garantía más alta, de que estamos seguros. Vale, no hay nada seguro, y un exploit Zero Day hará trizas cualquier sistema por protegido que esté, pero hay que poder encontrarlo y usarlo. Y sí, los hay, siempre los habrá.

Un saludo.

WhatsApp: Secretos que todo buen bromista usuario debería de conocer

He aquí otro gran ejemplo de lo que la tecnología nos brinda: WhatsApp, y otro gran ejemplo del desconocimiento que se tiene de la tecnología. Nadie duda ya que la tecnología haya relanzado nuestro modo de vida, sin contar con los cambios profundos que ha sufrido nuestra sociedad actual debido a ella. Posiblemente uno de los grandes cambios que hemos sufrido en estos últimos años haya sido la manera de comunicarnos unos con otros. Desde las antiguas Cartas postales, pasando por el telégrafo, el teléfono fijo, el correo electrónico, el teléfono móvil, la mensajería instantánea, las redes sociales… la tecnología a día de hoy nos permite comunicarnos prácticamente con cualquier persona del mundo en tiempo real, ya sea por mensajes, por videollamadas… y esto realmente es increible y no seré yo quien diga que esto es algo dañino. Lo que es dañino es vivir en la ignorancia sin preguntarnos como funcionan las cosas o el peligro que puedan entrañar dichos sistemas de comunicación.

Son malas las redes sociales? No, lo que es malo es ceder tu alma a Facebook haciéndole dueño de toda tu vida personal. Es malo el uso de WhatsApp? No, lo que es malo es hacerse fotos/vídeos desnudos y enviarlos a cualquier persona desde redes públicas. Lo que quiero decir es que cualquier herramienta es buena siempre y cuando se sepa usar, o al menos que sepamos los pros y los contras que ellas acarrean, y así podemos decidir si nos compensa o no usarlos. Bien, pues como ya he dicho hoy le toca a esa gran aplicación que estoy seguro la gran mayoría de los lectores tienen o conocen (yo el primero): WhatsApp. ¿El por qué de esta publicación? Sinceramente por dos motivos. El primero por la gran cantidad de fallos de seguridad y privacidad que tiene desde mi punto de vista, y segundo porque como ya he dicho a día de hoy posiblemente sea una de las aplicaciones para dispositivos portátiles más usadas (sea cual sea la plataforma). Y por qué no, también he decir que me ha causado grandes momentos de risa floja gastando alguna que otra broma…

Por descontado, antes de comenzar quiero recordar como es costumbre que el interés particular es mostrar y enseñar las virtudes y defectos de esta aplicación, no enseñar a otros lammers o usuaurios malintencionados a aprovecharse de ellos! sino a proteger a los usuarios que puedan sufrirlos. Dicho esto, vamos a tocar algunos temas interesantes:

  • Apuntes generales sobre el funcionamiento de WhatsApp: Transmisión de datos, recepción, servidores de WhatsApp…
  • Historiales de conversaciones: Utilidad, peligro, Desencriptado de las copias de seguridad…
  • Aplicación práctica: Manipulación de los “metadatos” de los mensajes para la creación de miniaturas falsas en las imágenes transmitidas o el envío de imágenes gigantescas para agotar los datos de cualquiera

 

 

Funcionamiento

 Bueno, el funcionamiento de WhatsApp está muy bien pensado y aunque aquí deje algunos tirones de oreja no implica que no esté de acuerdo con la gran mayoría del sistema usado.

En realidad, WhatsApp no ha creado nada nuevo de cero (o muy poco), sino que ha cogido lo mejor de cada programa de mensajería que ya teníamos y lo ha puesto todo junto. Eso no quiere decir que sea el mejor programa de mensajería, o que sea imprescindible, e incluso personalmente considero mucho más imprescindible Google Talk. No obstante la gran ventaja que ha hecho de WhatsApp que su uso sea exponental no ha sido ni mucho menos el poder compartir fotos, vídeos o ser multiplataforma. Lo que ha hecho de WhatsApp tan extendido ha sido a su vez lo que yo considero el peor fallo que tiene: No hace falte añadir/aceptar a nadie.

Los usuarios que lo instalan tan solo tienen que acceder al programa y este les dice automáticamente no solo quienes lo usan!! sino también el mensaje personal de cada uno, si está en línea, cuando fue la última vez que se conectó… es decir que tan solo te hace falta el número de teléfono de una persona para saber todos esos datos, e incluso si quieres ponerte en contacto con él o aplicar alguna de las “técnicas” pernisiosas que veremos al final del todo. No necesitas que el conocido o desconocido te acepte, te conozca… si tiene WhatsApp, puedes hablar con él. Sí, muchos dirán que puedes bloquear a quien quiera por supuesto, pero para cuando llegue ese caso igual ya es tarde. ¿El lado positivo de todo ello? Fácil, que no tienes que agregar a nadie y lo que ello implica. Como vemos, ya desde el comienzo vemos el balance constante que hay que tener entre Comodidad Vs Seguridad y privacidad… en este caso el usuario prefiere Comodidad… (craso error en mi opinión)

 

Para entender el funcionamiento de WhatsApp por desgracia, tenemos que entender aunque solo sea por encima como funcionan las plataformas móviles que tenemos la inmensa mayoría a día de hoy, ya sean dispositivos Android o iOS. Podría citar también Windows Phone o BlackBerry, pero sinceramente solo Android copa casi el 70% del mercado, si a eso le sumamos la aportación de iOS… ¿Por qué es importante como funcionan nuestros dispositivos? porque para ser posible usar ciertos servicios, muchas veces la limitación o viene de la imaginación del de fuera, sino de nuestros dispositivos en sí mismos.

Enviar un mensaje desde un dispositivo a otro es fácil y no tiene complicación alguna, pero.. ¿que pasa si el otro dispositivo no está disponible? A fin de cuenta, de que sirve un programa de mensajería de este tipo si tan solo podemos ponernos en contacto con nuestros allegados cuando la otra persona tiene cobertura de datos o WIFI. Esta tontería implica automáticamente la necesidad de una infraestructura importante y una forma totalmente diferente de enfocar este tipo de programas. No sirve los métodos tradicionales de realizar comunicaciones directas Origen<>Destino, que aunque suelen ser mucho más rápidos y seguros no son viables a menos que Origen y Destino estén siempre 24 horas al día conectados. Eso hace necesario un servidor (o varios) de la compañía del programa (en este caso WhatsApp) que centraliza TODO. Dicho de otro modo, cada mensaje, imagen, contacto, vídeo… que se transmite (o creemos transmitir) a un contacto, dichos datos en realidad NO VAN a nuestro contacto, se envían siempre absolutamente todos a los servidores de WhatsApp. El servidor de WhatsApp está en contacto continuamente con cada dispositivo que está conectado a WhatsApp por medio de un canal (supuestamente seguro), que usa no solo para recibir datos del usuario, sino para enviarle (o avisarle) de que tiene un mensaje nuevo.

En realidad es diferente como funciona WhatsApp para iOS o para Android. En el caso de Android, los dispositivos son todos multitarea, lo que implica que WhatsApp se encuentra SIEMPRE ejecutándose y funcionando, si el servidor de WhatsApp recibe un mensaje para nosotros, nos envía el mensaje por medio de ese canal abierto que tiene con nosotros, y nos entrega el mensaje de inmediato. iOS no es así. iOS no es multitarea, lo que implica que cuando el usuario NO TIENE por delante la aplicación de WhatsApp abierta, WhatsApp NO ESTA funcionando. En este caso WhatsApp lo que hace es hacer uso de las notificaciones Push de iOS, envía una notificación Push al dispositivo del usuario para avisarle de que tiene un mensaje para él (NO LO ENTREGA), y hasta que el usuario no acepta la notificación o accede de nuevo a WhatsApp, el mensaje no es recibido por el teléfono. Este de echo es el motivo por el cual es muy sencillo saber si un usuario de iPhone está o no mirando WhatsApp. Ya no solo por que aparezca su estado “En línea”, sino porque WhatsApp nos notifica al emisor con el símbolo de la Aspa o la Doble Aspa si el mensaje lo ha recibido el contacto (Un Aspa implica mensaje recibido en los servidores de WhatsApp, dos Aspas implican que el usuario lo ha recibido). Dado que iOS tan solo puede recibir los mensajes una vez abre WhatsApp, podemos usar esa información. En caso de Android no es posible, ya que obtendremos el doble aspa normalmente en cuanto le enviemos el mensaje, da igual que el usuario lo lea o no lo lea, acceda a WhatsApp o no, porque el mensaje habrá sido recibido por su aplicación sin necesidad de que el usuario acceda a ella.

 

La transmisión de “objetos” (entendiendo por objetos audio, imágenes, geolocalización…) se hace de forma diferente. Cuando cualquier usuario manda un objeto a otro, el proceso es diferente:

  1. En caso de ser una imagen, WhatsApp la redimensiona a un máximo de 800*600
  2. Nuestro WhatsApp transmite primero el objeto a los servidores de WhatsApp en una ubicación a priori aleatoria dentro del servidor de WhatsApp
  3. Una vez que ha transmitido la imagen, envía un “mensaje” al contacto en cuestión, pero este mensaje aunque tiene la misma estructura interna que un mensaje de texto, no contiene texto, sino los datos del objeto que ha enviado, como la ubicación del objeto (la URL donde se encuentra), el tipo de objeto que es (imagen, audio…), nombre del archivo… y otros metadatos
  4. WhatsApp como si se tratase de un mensaje normal y corriente de texto, envía el mensaje (o la petición si es iOS) al destino
  5. El destino recibe un mensaje EXACTAMENTE igual que si fuese de texto, pero los metadatos del mensaje informan al dispositivo que hacer. Es decir, si el dispositivo recibe un mensaje con los metadatos de que tiene que descargar una imagen, accederá a la URL de la imagen (que será donde esté alojada la imagen que nos envío nuestro contacto) y la descargará.

 Esto que puede carecer de importancia, veremos como puede tener gran utilidad para un usuario “listo”.

Este sistema, deja abierta la incógnita sobre dos cuestiones principalmente. La primera, dado que los “objetos” no son enviados al otro usuario en una comunicación directa, si pueden ser accedidos desde otros dispositivos o si alguien puede tener acceso a ellos. La segunda, dado que nuestros “objetos” tienen que ser almacenados de forma temporal en los servidores de WhatsApp, ¿Por cuanto tiempo?

Respecto a la primera pregunta, siento decir que por absurdo que resulte CUALQUIER usuario puede acceder a CUALQUIER contenido enviado por CUALQUIER otro usuario, siempre que se den dos premisas: Conozca la ubicación de dicho archivo y no haya sido eliminado de los servidores de WhatsApp. Tampoco hay que ser alarmista, y resultaría bastante complicado poder acceder a dichos contenidos. Recientemente WhatsApp ha hecho cambios que impiden a priori a este contenido de forma directa (a través de un navegador), pero tan solo afecta a las nuevas versiones y para el contenido que se genera por estas, cualquier contenido que se genere por las versiones antiguas o que fue generado por estas, es totalmente accesible.

Respecto a la segunda pregunta, sinceramente desconozco el tiempo por el cual el contenido continua siendo almacenado en los servidores de WhatsApp y no es eliminado. La teoría podría decirnos que en cuanto el “objeto” es descargado por el usuario en cuestión, dicho contenido se elimina de los servidores de WhatsApp, pero esto no es así. Seguramente podrían excusarse con que si reenvías el mensaje no es necesario volver a enviar el archivo a los servidores de WhatsApp o ni siquiera tener dicho contenido en nuestro teléfono. Personalmente no me vale esa excusa, el único dueño de dicho contenido debe de ser el usuario, y por privacidad, el contenido debería de ser eliminado nada más enviarse. De forma fiable, puedo decir que durante más de un mes el contenido permanece disponible, pero a partir de ahí… puede ser un mes o un año.

 

 

Historial de conversaciones

Aunque no se ha citado en el punto anterior, WhatsApp guarda de forma automática una copia de seguridad de todas las conversaciones que tenemos abiertas en WhatsApp. La utilidad de esta copia de seguridad es la de conservarlas en caso de que actualicemos la aplicación, la desinstalemos y la volvamos a instalar… o simplemente restablezcamos nuestro dispositivo. Sin estas copias de seguridad, sería imposible que nuestro dispositivo pudiese restablecerlas.

Esta función a priori  esencial tiene dos problemas fundamentales. El primero y principal es que esta función no puede deshabilitarse, de nuevo el usuario no tiene capacidad de decidir si quiere esas copias de seguridad o no las quiere, para ser exactos quiera o no quiera su WhatsApp guardará una copia de seguridad (en Android) sistemáticamente a las 4.00 de la noche. Las copias de seguridad son acumulativas por otro lado, lo que quiere decir que lo que contiene una copia de seguridad en el momento de realizarse es una copia exacta de TODAS las conversaciones con todo su historial de mensajes en ese mismo instante. Además, estas copias de seguridad no se sobrescriben por la del siguiente día, sino que se guarda un período mínimo de 7 días, es decir, que se conservan siempre al menos 7 copias de seguridad diferentes, en las que como hemos dicho al ser acumulativas, la más actual contendrá siempre toda la información que puedan tener las otras, siempre y cuando (y aquí está la cuestión) no se haya eliminado ningún contenido.

¿Que pasaría si antes de las 04.00 elimino una conversación completa (o parte de ella) que mantuve dos días atrás con una persona? Que en la nueva copia de seguridad dicha conversación no existiría, pero si existiría en la copia de seguridad de 2 días atrás, y dependiendo de cuando se realizase esa conversación, incluso en las copias de seguridad de una semana atrás o incluso más. Esto es interesante desde el punto de vista de la privacidad, puesto que podríamos recuperar de forma legítima o ilegítima el contenido de conversaciones de WhatsApp que fueron borradas tiempo atrás.

 

El segundo problema fundamental al que me refería reside en la seguridad de dichas copias de seguridad. En el caso concreto de iPhone, dichas copias de seguridad se encuentran en la partición pública de este, con lo que bastaría cualquier aplicación que use el protocolo de trasferencia de Apple para acceder a tales archivos. En el caso concreto de Android estas se encuentran en el espacio designado como “SD”, lo cual implica que conectando simplemente el terminal a un PC tendríamos accedo a dichos archivos, o incluso simplemente retirando la SD (en caso de ser externa) y copiarla en otro equipo. Esto no es que suene muy seguro, puesto que sería tremendamente sencillo copiar en segundos todo los historiales de conversación (y lo mismo para imágenes, audios…) que se tenga en WhatsApp.

Ante esta segunda opción, WhatsApp hace unos meses ya implementó por fin un sistema de seguridad de cifrado, haciendo que estas copias de seguridad residiesen de forma cifrada en estos almacenamientos más accesibles por cualquiera. No obstante, el sistema optado por WhatsApp es totalmente inservible. Cifrar las copias de seguridad no es una mala idea, pero entonces tendrías que cifrar no solo las copias de seguridad, sino el historial que usa el propio WhatsApp de forma activa. Es decir, cuando abrimos WhatsApp y vemos todas nuestras conversaciones, estas no son las de las copias de seguridad, que son las que se cifran. Es cierto que los datos de la aplicación en sí están más protegidos y son de más difícil acceso que las copias de seguridad que se almacenan en espacios más sencillos, pero cualquier iPhone puede realizarse JailBreak para acceder al sistema de archivos íntegro, y en Android tres cuarto de lo mismo cuando se Rootea.

No obstante no digo que el sistema de cifrado de WhatsApp sea totalmente inservible por esto (que también), sino porque de forma totalmente inexplicable WhatsApp usó la misma Key de cifrado para absolutamente TODOS los dispositivos. No voy a entrar siquiera en las numerosas alternativas que tendrían a su alcance, pero sí a recordar lo absurdo que es cifrar absolutamente todas las copias de seguridad que WhatsApp hace con la misma clave. ¿Por qué? Porque eso quiere decir que está codificada en la misma aplicación cuanto menos, y que simplemente viendo el código de la aplicación se puede extraer dicha key. ¿A efectos prácticos?

Si conocemos el cifrado usado por WhatsApp y sabemos la clave de descifrado, tendremos desencriptadas las copias de seguridad que deseemos. En este caso, actualmente WhatsApp usa el estándar AES 192, con un esquema de codificación ECB (Electronic CodeBook). Quien quiera saber más de esto puede leer esta publicación de hace tiempo: Cifrado de datos. No tengo nada en contra de usar AES 192 como sistema de cifrado, aunque por otro lado nadie en su sano juicio a día de hoy usaría ECB. Sea como sea, teniendo en cuenta estos datos, solo nos quedaría conocer la clave escogida por WhatsApp para realizar la tarea de cifrado y descifrado (cifrado simétrico), que es:

“346a23652a46392b4d73257c67317e352e3372482177652c”

 

Si usamos por ejemplo OpenSSL para poner todo ello junto, con una simple línea de comando podríamos descifrar las copias de seguridad de cualquier usuario que queramos:

“openssl enc -d  -aes-192-ecb -in cifrado.db -out descifrado.db -K 346a23652a46392b4d73257c67317e352e3372482177652c”

Esto no es un secreto que digamos, y por tanto hace que el cifrado que hace WhatsApp sea totalmente carente de sentido, ya que cualquiera que pudiese tener interés especial en obtener dichas copias de seguridad puede seguir obteniéndolas.

 

 

Aplicaciones prácticas

Lo cierto es que podríamos aplicar todo lo anterior a bastantes aplicaciones prácticas bastante curiosas, ya se sabe que la imaginación es el único límite. Aquí solo voy a centrarme en dos en particular por lo “divertido” o lo “funestas” que pueden llegar a ser y lo simple de llevarlas a cabo.

  • Imágenes Falsas: Imágenes cuya miniatura es una foto y la foto real al verla es otra cosa
  • Imágenes interminables: Imágenes que pueden ocupar 100MB, 200MB… lo que se quiera, obligando a agotar los datos de cualquiera.

 

Hace ya algún tiempo, llegaba a mi terminal por WhatsApp una imagen en la que podía apreciarse en la miniatura de la conversación la foto de un chico “sexy”. Nada más lejos, era un joke, un hoax, ya que en realidad cuando procedías a verla/descargarla en su lugar lo que te encontrabas era con la foto de un mono sacando el dedo. Más exactamente, aquí podemos ver la minuatura que aparecería en la conversación (arriba a la izquierda) y la imagen una vez vista/descargada:

 

 

Esto es posible precisamente por algunas de las cosas explicadas anteriormente. Pero no hay que tomarse este tipo de cosas como simples “bromas” (que puede ser el ejemplo anterior), sino cuestiones a tomar bien en serio, recordemos que los dispositivos Android tienen la posibilidad (activada por defecto) de descargar de forma automática las imágenes. Dicho de otro modo, podríamos enviar todo tipo de bromas de muy mal gusto a cualquier usuario, y las imágenes “de mal gusto” se quedarían en su teléfono hasta que se eliminasen… imaginar que aquel que las está recibiendo no las revisa todas u olvida que están… cualquiera que acceda a su galería de imágenes podrá llevarse una sorpresa desagradable. Y aun cuando las imágenes no se descarguen de forma automática es lo mismo, puedes enviar una imagen a cualquier persona (aunque ella no te conozca) y…

 

Dejando a un lado las cuestiones de siempre y volviendo a esta publicación y al primer punto de las imágenes falsas, ¿como se pueden crear este tipo de imágenes? Las dos cosas que vamos a ver aquí en realidad están basadas en el mismo principio, la modificación de los metadatos de los mensajes que enviamos y recibimos, por lo que antes de seguir vamos a ver que son esos metadatos, como “verlos”, y lo demás vendrá de corrido.

 Vamos a asumir a partir de aquí que el usuario tiene un dispositivo Android con acceso de Root, no es obligatorio ni ser Root ni tener Android, pero por simplificar y facilitar las cosas es lo que vamos a tratar. Así como también para facilitar la lectura vamos a suponer que nuestro número de teléfono es el 666123123 y el de cualquier contacto será siempre 666123124:

 

Cuando WhatsApps se ejecuta tiene que cargar evidentemente nuestras conversaciones, luego eso está en algún lado, y ya hemos dicho que no son las copias de seguridad. Si sabemos buscar en nuestros dispositivos pronto encontraríamos que estos datos se encuentran en la ubicación de nuestro terminal:

/data/data/com.whatsapp/databases/

El archivo en cuestión es “msgstore.db”

Es un archivo de bases de datos, concretamente SQLite, así que el siguiente paso sería abrirlo para ver que es lo que realmente tendríamos dentro, lo cual al ser una base de datos SQLite el proceso sería trivial. Una vez abierto nos damos cuenta la gran información y posibilidades de este archivo:

 

En realidad no es necesario pasarse horas explicando el significado de cada tabla/columna de estas. En nuestro caso nos centraríamos en la tabla “messages” que contendría TODOS nuestras conversaciones tal y como las guarda y gestiona WhatsApp. Cada entrada en la tabla messages corresponde a un mensaje enviado o recibido, y recordemos una vez más que cualquier objeto que se manda o se recibe cuenta también como mensaje, no solo cuando se manda/recibe texto. Dentro de esta Tabla encontramos diferentes campos para cada una de las entradas (los mensajes enviados y recibidos) que podemos ver reflejado en la imagen anterior. El significado de cada campo varía fundamentalmente dependiendo del tipo de mensaje que sea, pero por lo general es fácil conocer cada uno de ellos:

 

_id:

Es el primary Key, el índice de los mensajes por así decirlo, el cual se incrementa en uno cada vez que se recibe o envía un mensaje. Por ejemplo, si tenemos 27176 entradas en la tabla messages y el valor de “_id” del último mensaje es 27455, significa que se han borrado 279 mensajes, lo cual ya de por sí puede ser útil para saber si un usuario es de esos desconfiados (o tiene algo que ocultar) y le gusta ir eliminando mensajes o conversaciones que pudiesen no ser del agrado de otros.

Key_remote_jid:

Designa la persona con la que se intercambió dicho mensaje, exceptuando los mensajes a los grupos o a más de una persona. Si el mensaje es enviado o recibido a un contacto en concreto, este campo comenzará con el número de teléfono de dicho contacto: “34666123124@s.whatsapp.net”. Si es un mensaje enviado a un grupo por el contrario, el formato será similar (no igual), en el que el número será el del creador del grupo y un ID, seguido del dominio @g.us. Ni que decir tiene que este campo sería el indicativo esencial para conocer para quien o de quien era ese mensaje

Key_from_me:

No hay que ser un lince para saber que significa. Es un campo que contendrá un “1” cuando el mensaje es enviado por nosotros y un “0” cuando el mensaje es enviado por otros. Es decir, es el campo que especifica si el mensaje es enviado o recibido.

 key_id:

Es un timestamp (una marca de tiempo) en formato UNIX que se añade a cada mensaje conteniendo el día y la hora de la última vez que se ha accedido a WhatsApp, con un contador adicional que se incrementa en uno por cada mensaje que es enviado durante ese día/sesión. Un ejemplo: “1350766259-45” (Que se traduciría como 20 de Octubre de 2012 a las 20.50. Mensaje 45)

status

Marca con un número que tipo de mensaje es en función de un código numérico de 0-6. Así por ejemplo, todos los mensajes de grupos tendrán en este campo un “0” si son enviados por otros contactos, “4” para los enviados por nosotros y “6” cuando son de control. Para los mensajes normales es similar, existen diferentes códigos para diferentes tipos de mensajes

 needs_push

 Imagino que este campo tan solo es usado en dispositivos como el iPhone, que al no ser multitarea como hemos dicho, accede a los mensajes mediante el sistema de notificación Push de Apple. Es decir que los mensajes no llegan al teléfono hasta que este abre la aplicación en cuestión. Posiblemente este campo marque cierto tipo de mensajes para poder acceder a ellos.

data

En los mensajes de texto, contiene el texto del mensaje propiamente dicho, en los mensajes de objetos este campo estará simplemente vacío

timestamp

Marca de tiempo en formato UNIX de cuando son enviados los mensajes

media_url

Ubicación Web en la cual se encuentra el recurso al que se está intentando tener acceso, por tanto este campo estará vacío en caso de ser un mensaje de texto, y contendrá la dirección a los servidores de WhatsApp de la imagen, el audio… del objeto transferido

media_mime_type

MIME hace referencia al tipo de archivo que se quiere transmitir, es un “código” por así decirlo usado universalmente para indicar a los navegadores web y otras aplicaciones el tipo de contenido al que se está accediendo. WhatsApp hace exactamente lo mismo. Por ejemplo, si se va a transmitir una imagen JPG, el tipo MIME será “image/jpeg”, si fuese un vídeo podría ser “video/3gp” ó “video/mp4”. Este campo no obstante no es a fin de cuentas necesario para WhatsApp, o al menos para todos los dispositivos, si lo eliminásemos veríamos que todo funcionaría igual. Evidentemente si se está transmitiendo texto, este campo estará vacío

media_wa_type

Este campo si es esencial, y es este y no el anterior el que dice a WhatsApp que tipo de contenido se está intentando abrir. Es decir, el que dice si lo que nos han mandado tiene previsualización porque es una imagen y lo tiene que abrir el visor de imágenes o si es un vídeo y tiene que abrirlo el reproductor de vídeo (por ejemplo). En este caso, el valor de este campo es de nuevo un entero de 0-5, cada uno de ellos indentifica un contenido diferente.

0 -> Texto, 1 -> Imágenes, 2 -> Audio, 3 -> Vídeos, 4 -> Contactos, 5 -> Geoposición

media_size

El tamaño del objeto que se transmite en Bytes.

media_name

El nombre del objeto tal y como estaría en nuestro dispositivo, por ejemplo si es una imagen sería el hash de esa imagen con la extensión suya. Evidentemente este campo está vacío para el texto

latitude y longitude

Cuando se transmite un objeto de tipo ubicación (tipo 5), estos campos contienen ni más ni menos que la geolocalización, la latitud y la longitud. En cualquier otro caso, estos campos están a “0”.

thumb_image

Contenido binario que almacena casi siempre la ubicación local (y nombre) del objeto en cuestión. Por ejemplo si es una imagen que ha llegado a nuestro dispositivo, contiene la ubicación dentro de nuestro dispositivo donde se encuentra.

remote_resource

Indica el origen de los mensajes que son enviados dentro de un grupo, el número de teléfono de quien los envía. El formato es el mismo que el usado en Key_remote_jid, de echo realiza la misma función que este, pero en los grupos. (recordemos que en los grupos key_remote_jid  identifica al creador del grupo siempre)

received_timestamp

Otra marca de tiempo, pero en este caso de cuando el mensaje fue recibido. Gracias a este campo y al anterior, podemos saber cuando se envió el mensaje y cuando fue recibido (siempre desde el punto de vista de nuestro dispositivo), que es lo que se usa de forma visual. Un aspa cuando se envía, un segundo aspa cuando se ha recibido (nada que ver si se ha leído o no)

send_timestamp

No se usa, su valor es “-1” siempre, supongo que simplemente porque el campo “timestamp” realiza la misma función

receipt_server_timestamp

Marca de tiempo que especifica cuando el servidor de WhatsApp recibió el mensaje

receipt_device_timestamp

Marca de tiempo que especifica cuando el destino recibe el mensaje. Las marcas de tiempo son todas diferentes aunque tengan nombres diferentes. Así por ejemplo, en cuanto enviamos un mensaje tendríamos la primera marca de tiempo. La segunda sería impuesta por el servidor de WhatsApp que es cuando ellos lo reciben. La tercera sería cuando el usuario recibe en su dispositivo el mensaje y la introduce el dispositivo del destinatario, y al final la cuarta es la que pone nuestro propio dispositivo cuando ha recibido la confirmación de que el mensaje le ha llegado al usuario en cuestión.

raw_data

Contenido binario que contiene una imagen en miniatura de la imagen que se está transmitiendo (cuando el objeto es una imagen)

media_hash

Hash en formato Base64 del objeto transmitido. En realidad no se usa/verifica, o al menos no es enteramente necesario.

 

Con todo esto, ya podemos empezar a ver las grandes posibilidades que tiene conocer este archivo, y es cuando podemos hacernos preguntas ciertamente interesantes, y es cuando podemos empezar a aplicar de forma práctica algunas cosas:

  • Si puedo ver la base de datos, puedo modificarla y volverla a colocar en su sitio? -> Por supuesto, igual que se extrajo se mete de nuevo
  • Que pasa si modifico el campo raw_data y meto otra miniatura? -> Que la miniatura es una imagen y la foto real es otra
  • Que pasa si especifico la URL de un objeto que no está en los servidores de WhatsApp? -> No pasa nada, el destino descargará el contenido desde el sitio remoto que se especifique igualmente
  • Que pasa si modifico el key_remote_jid en un grupo? podría acceder a un grupo ya creado sin invitación? -> Todo es probar a ver que pasa

 

Empecé diciendo que veríamos un par de aplicaciones prácticas sencillas. La primera como enviar imágenes “falsas” a otro contacto y la segunda como enviar imágenes de cientos de MB si queríamos. Visto todo esto es bien simple hacer esto

 

Como enviar imágenes falsas que ni siquiera están en WhatsApp

  1. Extraer la base de datos
  2. Disponer en el PC de la miniatura (por ejemplo en 100×100 pixeles) y de la imagen real
  3. Modificar el campo raw_data con la miniatura
  4. Modificar el campo media_url con la ubicación web en la cual se encuentra la imagen real a trasferir
  5. Modificar por seguridad el campo media_size con el tamaño de la imagen remota
  6. Guardar los cambios y volver a colocar la base de datos en el móvil
  7. Abrir la conversación en la que hemos modificado el mensaje y veremos que ya de por si la miniatura ha cambiado, dejar pulsado y reenviar al contacto que queramos

Al reenviar no estamos cargando de nuevo imágenes, estamos reenviado simplemente los metadatos de esta, con lo que a nuestro contacto les llegará una imagen para descargar con una miniatura que nada tiene que ver con la imagen real

 

Como enviar imágenes gigantescas con el fin de agotar los datos de cualquiera?

  1. Extraer la base de datos al PC
  2. Ubicar en inet alguna imagen gigantesca o cualquier otro contenido que se pueda acceder de forma directa
  3. Modificar el campo media_url con dicho contenido
  4. Modificar por seguridad media_size con el tamaño del nuevo objeto
  5. Guardar los cambios y volver a colocar la base de datos
  6. Abrir la conversación, buscar el mensaje y reenviar a quien queramos

De nuevo, el remitente tendrá dos problemas. Si tiene activada la descarga automática de fotos comenzará sin saberlo a descargar una imagen de 300MB si se quiere (incluso podemos poner la miniatura que queramos). Si no tiene activada la descarga automática basta con poner una miniatura suculenta para que le dé. Para cuando se de cuenta (si se da) ya han podido descargarse decenas de MB. Si el usuario está por WIFI no es un problema, si está por datos uno es capaz de hacerse idea de la “gracia”

Recordemos a todo esto que WhatsApp permite enviar mensajes a todo un grupo o mensajes en multidifusión. Imaginar que pasaría si mandásemos una imagen de 500MB a un grupo de 200 personas, eso sin olvidar que WhatsApp funciona sin necesidad de que otro usuario nos invite, con lo que podríamos directamente enviar una supuesta imagen sugerente (por la miniatura) a cualquier teléfono móvil que tenga WhatsApp instalado con el contenido que queramos, desde una imagen broma a una imagen de cientos de MB que posiblemente nunca podrá descargar del todo y que posiblemente podrá agotar la memoria incluso de muchos dispositivos.

Solo puedo recomendar algunas cosas… deshabilitar las descargas automáticas de imágenes, tener cuidado con que descargamos y en la medida de lo posible usar GTalk 😉

 

Un saludo a todos

Windows 8: Como activarlo usando servidores KMS

 

Para el que no lo sepa aun, Windows 8 llegó a la versión de oro (RTM, Release To Manufacturing) no hace siquiera dos días. Esto significa básicamente que Windows 8 está terminado, y aunque no verá la luz al público hasta dentro de un mes y medio más o menos, no quiere decir que la nueva versión de Microsoft no esté terminada.

Este período de tiempo se usa no para pulir fallos, sino para que los desarrolladores de software, los OEM, los fabricantes de hardware… puedan adaptar sus programas, drivers, dispositivos… a la versión final de Windows 8. Esto siempre ha implicado, y esta vez no ha sido menos, que el mismo día que se termina la versión RTM, esta se filtre a diversos canales, y termine la imagen original de Windows en manos de todo aquel que busque un poco por la red. En realidad esto incluso le viene bien a Microsoft, además de un poco de publicidad, hace que algunos usuarios y expertos en tecnología comiencen a escribir sobre las novedades de Windows 8, un producto ya terminado.

Ya sé que es empezar por el final sin antes explicar el principio, pero hoy no vamos a hacer una review de Windows 8 (eso para otro día), ni tampoco a explicar cada uno de los sistemas de activación y protección nuevos con los que cuenta. Hoy la cosa va a ser mucho más específica, a explicar tan solo uno de los sistemas de activación de Windows 8, y que es el que ahora mismo está usando algunos cuantos para activar copias piratas de Windows 8. Y es que en este mundillo, todo es posible, por difícil que sean las cosas.

 

La mayoría de las copias piratas de Windows 7 eran activadas por medio del uso del sistema OA 2.1 (OEM Activation). Se llegó a asimilar que el sistema más cómodo, rápido (y en teoría infalible) para que las copias de Windows 7 fuesen o pareciesen 100% legítimas era o modificar la Bios para incluir la activación OA o instalar un Loader para emularla. Lo malo de este sistema es que había que tocar la bios que siempre es peligroso o instalar Loaders que no es que lo sean menos. ¿Por qué se usaba este sistema? porque era el único sistema para poder realizar una activación offline. Cualquier otro sistema que se usase, se tendría que realizar una comprobación online del Key introducido, y por descontado que Microsoft bloquearía Keys usadas o inválidas.

Windows 8 ha cambiado este esquema. OA 2.1 se ha actualizado a OA 3.0, y aunque el proceso de cara al usuario es el mismo (una activación totalmente transparente), ya no es posible engañar tan fácilmente al sistema con una modificación de Bios, puesto aunque la Bios es la misma en todos los equipos, no lo es la Key que se le inyecta antes de entregarlo, la cual es únuca, haciendo complicado que pueda usarse una modificación de Bios para aprovechar este sistema. Con esta opción por ahora anulada, tan solo quedaría la activación online que ya hemos dicho no es viable, y la validación de las licencias VL, es decir, licencias múltiples. Este tipo de licencias son las que usan las empresas, como comprenderéis una empresa que tiene o actualiza 10.000 equipos no les van a entregar un sobre con 10.000 keys, sería totalmente inviable. Lo que se hace es usar un servidor KMS (Key Management Serveice)

A groso modo, lo que se hace es que Microsoft entrega una key maestra a una empresa, la cual instala un servidor KMS que gestiona LA EMPRESA. Para que dicho servidor KMS funcione, necesita evidentemente una key maestra, que una vez introducida, esta se valida ANTE los servidores de Microsoft. Si Microsoft da el visto bueno, dicho servidor KMS es activado.

Pero cual es la función de estos servidores KMS? Fácil, activar software de microsoft, en este caso concreto las ediciones de Windows 8 Pro/Enterprise con licencias VL. De este modo Microsoft no tiene que entregar una key a cada equipo, sino que estos son activados de forma temporal (180 días) por medio del servidor KMS de la empresa. La pega es que como he dicho es temporal. Por seguridad y por la licencia misma, los equipos intentarán revalidar su activación por otros 180 días cada 30 días, de este modo mientras el servidor KMS esté en activo, nungún equipo de la empresa tendrá que preocuparse jamás de nada. Si en 180 días no fuese posible la reactivación, Windows 8 pasaría al modo de pruebas.

¿Como afecta esto a la piratería? Bueno en teoría el sistema está perfectamente montado para que no sea posible la activación de copias piratas pero… ¿que pasaría si cualquier usuario instala en su casa una copia de Windows 8 Enterprise con licencia VL? En principio podría instalarla y hacerla funcionar en modo de prueba hasta que la validase en un tiempo de 30 días. Y si ese usuario tiene un padre, un tío un amigo que tiene acceso a un servidor KMS activado que está preparado para activar Windows 8? Pues que si el usuario tiene acceso a dicho servidor de forma directa o indirecta y lanza la petición de activación a dicho servidor… Windows 8 quedaría activado, al menos durante 6 meses.

Por supuesto, es muy posible que dentro de muy poco aparezca un activador portatil que cualquier usuario podrá ejecutar en su mismo equipo para activar su propia copia.

 

Con fines totalmente didácticos, como ya sabéis, tan solo he aplicado todo lo anterior. Lo que sabemos y podemos afirmar:

  • Podemos activar cualquier copia de Windows 8 si tenemos acceso de un servidor KMS activado y con soporte por supuesto para activar Windows 8.
  • Los servidores KMS deben de estar siempre funcionando ya que cada 30 días los equipos activados tendrían que acceder a él para no cumplir los 180 días. Esto hace que generalmente estén ubicados siempre en el mismo lugar (ubicación de red, no geográfica) puesto que los equipos clientes se configuran al inicio y ya está, lo que significa que una vez tengamos acceso a uno de ellos es muy posible que continúe siendo válido por mucho tiempo
  • En teoría un servidor KMS ya activado no requiere de comunicación con Microsoft, con lo que en la práctica usando este sistema las copias piratas serían validadas totalmente como genuinas (al menos durante 180 días).
  • La teoría nos dice que los servidores KMS deberían siempre ubicarse en la red interna de la entidad/empresa/organización evidentemente, es decir que no fuese posible acceder a ellos de forma externa. Pero como todos sabemos la práctica siempre nos ha dicho lo contrario, que a lo mejor 9 de cada 10 sí están detrás de una red interna, pero 1 de cada 10 no, y
    este podría ser alcanzado desde cualquier punto del mundo.
  • Sabemos también que los servidores KMS por defecto usan el puerto TCP 1688 para las activaciones.

Con todo esto, no debería de ser complicado al lector habitual por donde van los tiros. Como ya vimos en el artículo de la “Caza y Captura de iPhone” y en el artículo de “Como consumir los datos de cualquier iPhone de forma remota“. La teoría aplicada sería la misma. Un puerto abierto es siempre un puerto abierto! Lo más importante es que siempre podemos buscarlo. Eso no quiere decir que cada equipo en el que encontremos un puerto TCP 1688 abierto, implique sin lugar a dudas que hemos encontrado un servidor KMS activo y que pueda validar copias de Windows 8 VL. Pero si implica que potencialmente hemos podido encontrarlo.

Al igual que se hizo en el artículo de la búsqueda y captura de iPhone, se aplica el mismo principio. El puerto es lo que buscamos, ¿pero como sabemos donde buscar? Y es aquí donde de nuevo las bases de datos públicas de IP nos rescatan de nuevo. Como vimos en el artículo que explicaba entre otras cosas IP, existen 5 entidades que gestionan los rangos IP de todo el mundo: Ripe, Arin, APNIC, AficNIC y LACNIC. Cada una de ellas se encarga de una zona diferente del mundo. Estas bases de datos son públicas, y entre otras cosas almacenan la pertenencia de cada rango IP asignado por ellos. Eso quiere decir que podemos ser un poco imaginativos y buscar por empresas/entidades/organizaciones que presuponemos tendrán servidores KMS, pero podemos extrapolarlo a cualquier OEM o multinacionales, dado que la mayoría de ellas casi con total seguridad tengan un rango asignado. Estos rangos no son demasiado dinámicos con el tiempo, lo cual quiere decir que podemos construirnos una buena lista de rangos en los que posiblemente pueda encontrarse una presa.

Por supuesto esto no quiere decir que en 10 segundos encontremos uno. Hablamos de que la lista de rangos obtenida puede poseer cientos de miles y millones de posibles direcciones IP, en las cuales se podría encontrar, hipotéticamente, un servidor KMS, y que dicho servidor pudiese estar preparado para activar copias de Windows 8. Dicho así parecería casi imposible, pero como ya he dicho tan solo hay que ser un poco imaginativo, sin contar con que es posible escanear miles de equipos en tan solo segundos.

En el artículo de la caza y captura de iPhone se usaban redes que son más lentas, y aun así en unos días había escaneado cientos de miles y millones de dispositivos de toda clase. Con que tan solo 1 de cada 1.000.000 de equipos escaneados fuese un servidor KMS válido, sería más que factible. 5000 IPs por minuto (y tirando por lo bajo) nos daría 1.000.000 de IPs escaneadas en tan solo 3 horas (no quiere decir que sean 1.000.000 de equipos, solo IPs escaneadas). Pongamos que tan solo 1 de cada 10 IPs está conectada a un PC, ¿33 horas en escanear 1.000.000 de equipos? Aunque tardásemos toda una semana en encontrar un solo servidor KMS válido, este sería casi con toda seguridad válido para uno o dos años y para activar cuantas copias se quisiesen. Y eso sin contar con la colaboración de otros usuarios.

Este sistema es viable por dos razones:

a) El sistema puede automatizarse completamente con un script en Bash por ejemplo, el cual vaya escanenado de fondo todos y cada uno de las IPs que hayamos preparado, ya sea IP a IP o rangos de IP completos. Cada equipo encontrado se registraría en un documento externo para analizarlo después.

b) Como ya he dicho, cada servidor encontrado posiblemente podría ser usado por mucho tiempo, más que nada poque la misma empresa necesita que el servidor esté activado y en funcionamiento!! con lo que aunque pueda ser una gruesa tarea al principio, después compensaría. Es decir, pensando como un pirata no es de extrañar que dentro de poco se filtren servidores KMS. El problema es que posiblemente Microsoft esté al tanto y vaya cerrando el acceso a ellos llamando a los administradores de ese servidor KMS.

c) Podemos acotar la búsqueda si pensamos con la cabeza quien puede tener servidores KMS instalados o como comprobar también de forma automática cuales de ellos están activados y preparados para activar licencias de Windows 8, o incluso Windows 7 (el sistema es el mismo en las VL).

 

Dicho esto y como es costumbre un simple ejemplo práctico. Actualmente digamos que se está usando el servidor xx.xxx.135.121 para realizar la activación. Aplicando la lógica común podemos pensar que dicha empresa u organización posee otros servidores en su red por razones de multiplicidad o simplemente servidores de prueba o… Así que como probar no cuesta nada, tan solo tuve que mirar a quien pertenecía dicha IP y el rango que tenía asignado en la que se encontraba dicha IP: xx.xxx.128.121-xxx.xxx.135.255. Eso nos da un total de 3840 IPs posibles!! Puede parecer mucho, pero es irrisorio.

En tan solo 40 segundos el escaner estana terminado:

Tiempo total: 40 segundos
Hosts posibles: 3840
Posibles servidores KMS descubiertos: 9

xxx.xxx.135.83
xxx.xxx.135.121 <- El servidor KMS filtrado
xxx.xxx.147.41
xxx.xxx.147.49
xxx.xxx.148.34
xxx.xxx.148.246
xxx.xxx.148.226
xxx.xxx.149.236
xxx.xxx.148.249

En 40 segundos he encontrado 9 posibles servidores!! entre los cuales por supuesto se encuentra el que actualmente se está usando. El resto pueden ser servidores sin key maestra o incluso servidores KMS para validar Windows 7 o Windows Vista. Puede también que exista algún otro servidor KMS de Windows 8. Esto podría verificarse uno a uno o automatizando también el proceso, sería muy sencillo.

Una vez se dispusiese de un servidor KMS válido, solo restaría introducir un par de comandos en el sistema para que este se comunicase con el servidor y lo validase:

slmgr /skms servidor.kms.com
slmgr.vbs -ato

 

Es evidente que a día de hoy tampoco es que existan muchos servidores KMS para activar Windows 8, sobretodo porque la versión final no tiene ni 2 días, y hasta dentro de mes y medio ni siquiera estará al público. Es decir, que a día de hoy no creo que muchas empresas o entidades tengan servidores KMS para Windows 8. Posiblemente el servidor filtrado esté usando un emulador con una key maestra filtrada igualmente, quien sabe… pero lo que está claro es que dentro de un mes o dos meses lo que no nos van a faltar van a ser servidores KMS que puedan validar copias de Windows 8. Igual me equivoco y Microsoft cambia las reglas del juego, igual me equivoco y este sistema se queda en desuso por otro mejor… pero lo que está claro es que el sistema es viable y funcional.

Un saludo.

Más de 450.000 cuentas de correo (usuario/contraseña) publicadas por Hackers debido a negligencia de Yahoo!. Como ha sucedido y como evitarlo.

 

Parece increíble, que a día de hoy, una empresa de la supuesta categoría de Yahoo! pueda sufrir un ataque de estas características, tanto por el sistema que habrían usado los Hackers como por tener dicha información Yahoo! en texto plano.

La noticia saltaba en todos los noticieros de tecnología hace unas horas, y es que un grupo de Hackers había filtrado un listado de más de 450.000 cuentas de correo, con sus respectivas contraseñas, de un servicio de Yahoo! llamado “Yahoo Contributor Network”. Dado que no es un servicio solamente asociado a las cuentas de Yahoo, la filtración afecta a cualquier usuario con independencia del proveedor de correo electrónico que use. El listado hecho público puede verse en el enlace publicado por el mismo grupo en la siguiente dirección por si cualquier usuasrio quiere comprobar si está o no en la lista.

http://74.208.161.170:81/yahoo-disclosure.tar.gz

 

Pero antes de ver las negligencias por parte de Yahoo! creo que es igualmente importante ver las repercusiones de filtraciones de este tipo y calibre:

 

-El eterno problema de usar una contraseña para todo

La filtración tan solo son credenciales de acceso a un servicio de Yahoo!, eso quiere decir que cualquier usuario podría haberse dado de alta con una cuenta de correo cualquiera y una contraseña cualquiera, no necesariamente la contraseña de su cuenta de correo. ¿Que sucede? Que de todos es bien sabido que la mayoría de los usuarios usan una o dos contraseñas a lo sumo para todo. Eso quiere decir que muchos de los usuarios/contraseñas del listado, son las mismas credenciales de esos usuarios de sus correos electrónicos y otros servicios.

-Cuentas antiguas

Es cierto que la filtración pertenece a cuentas antiguas, muchos de los correos electrónicos que aparecen ya no existen desde hace años, y la mayoría del resto modificaron hace tiempo sus contraseñas. Eso no quiere decir que no existan muchas cuentas válidas. Hablamos de algo menos de medio millón de cuentas, y son muchos los que desde hace casi 24 horas están apurándose en cambiar al verse en la lista publicada.

 

Comencé hablando de negligencia por parte de Yahoo!, y es así. Veamos, es evidente que a día de hoy no hay un sistema de seguridad que sea totalmente invulnerable, y los métodos de ataques de los hackers pueden ser extremadamente sofisticados. No obstante, parece mentira que una gran empresa como Yahoo! se vea expuesta primero por vulnerabilidades más que conocidas, y por otro lado que no tenga el grado de seguridad que se exige a cualquier particular o empresa que maneje datos sensibles.

 

Inyección SQL

En primer lugar, los hackers lograron el acceso a la base de datos por medio de una técnica llamada SQL Injection. Básicamente lo que se hace en estos casos es tomar cualquier formulario, campo de búsqueda,URL preformada… lo que sea haga uso directo de la base de datos que se quiere tomar, y se introducen datos específicos para lograr un comportamiento deseable y predecible a esa base de datos, generalmente volcar de ella determinados campos como por ejemplo los usuarios y las contraseñas. En realidad el ataque en sí es simple es simple, lo complicado es saber donde, como y por qué.

Para quien quiera saber algo más del asunto. A día de hoy prácticamente todas las aplicaciones web o servicios web usan bases de datos para almacenar toda nuestra información, desde nuestras credenciales de seguridad, fechas y horas de accesos, flags, comentarios, cookies de sesión… de todo. El ejemplo más minimalista sería por ejemplo que la base de datos tan solo tuviese una tabla con dos columnas: Usuario y Contraseña. ¿Que utilidad podría tener una tabla así? Es evidente, el sistema tiene que tener almacenados de algún modo la información de sesión de los usuarios, así cuando este quiere acceder a esos servicios, al introducir la información esta pueda cotejarse en la base de datos, si ambos valores coinciden, se permite el acceso. Por tanto, es evidente que en algún momento del proceso de identificación, cambio de contraseña, validación… de este ejemplo, los datos introducidos por el usuario deben de ser enviados al servidor del proveedor de servicios, una vez allí se usarán en alguna petición que se hará frente a la base de datos y la base de datos simplemente se limitará a responder en función de la información suministrada. A priori este sistema tendría que ser totalmente seguro ya que está todo gestionado en el mismo servidor, pero el usuario podría introducir en sus casilleros (ya sea en el del a contraseña, en el del nombre de usuario, en el de búsqueda…) un valor que inteligentemente haga que la petición teórica que debía de hacer el servidor a la base de datos sea otra. Esto es posible cuando el servidor no comprueba (o se le escapa algo) sobre todo los caracteres especiales tipo $, >, <, “, @… Dichos caracteres generalmente son usados en consultas en las bases de datos, o son simplemente caracteres de fin de petición o inicio de otra, caracteres condicionales… si el servidor no es capaz de filtrarlos correctamente, el usuario en vez de a lo mejor estar introduciendo su nombre de usuario para que sea cotejado en la base de datos, está introduciendo una cadena de caracteres que hará que la petición inicial de devolver el nombre de usuario realmente devuelva su contraseña, o por ejemplo el listado completo de la tabla:

Pongamos que el código SQL de un servidor para una petición es el siguiente:

SELECT lista
  FROM tabla1
 WHERE campo1 = '$EMAIL';

En teoría es una petición simple sin ningún posible error. Lo que haría esa petición sería seleccionar de la tabla1 en la base de datos las filas en las que el campo (columna) “campo1” coincidiese con la variable $Email que el sistema toma de nosotros. Es decir, si el usuario hubiese introducido el correo: pepe@perico.es, la variable $Email sería dicho correo electrónico, y dicha petición por tanto devolvería al servidor un listado con todas las filas en las que aparece dicho correo electrónico en la columna correo. Como digo esto a priori no tiene mayor problema. ¿Pero que pasaría si el sistema no es capaz de filtrar correctamente el caracter especial ‘ (apostrofe)? Si dicho caracter fuese posible introducirlo, al servidor en la variable $Email le llegaría como dato simplemente ese apostrofe, quedandose la última línea en algo como esto: WHERE campo1 = ”’;

Esto es un problema enorme. Si jugásemos un buen rato, a lo mejor podríamos introducir algo como “z’ OR apellido like ‘%Ruiz%”. Eso haría que en el lado del servidor se construyese algo totalmente diferente:

SELECT lista
  FROM tabla1
 WHERE campo1 = 'z' OR apellido LIKE '%Ruiz%';

Es decir, habríamos inyectado códjgo SQL en la petición original. Con z’ el servidor tomaría la sentencia en dos partes, la primera como ‘z’ (y de ahí a la utilidad de poder enviar un apostrofe) . De este modo el servidor ejecutaría simplemente nuestra segunda sentencia por estár condicionada con un simple OR, devolviendonos a lo mejor el correo electrónico o el nombre o incluso la contraseña (dependiendo de la base de datos claro está) de cualquier usuario en el que se encontrase “ruiz” en su apellido.

 

 

Texto Plano

 Igualmente peligroso y complementa inexplicable es el almacenaje de contraseñas en texto plano. De echo aquí en España la LOPD (Ley Orgánica de Protección de Datos) prohíbe taxativamente que cualquier organismo, entidad e incluso usuario. que almacene contraseñas sin estar protegidas. Así queda establecido en el Reglamento de la Ley Orgánica de Protección de datos (RLOPD) en su artículo 93 (Real Decreto 1720/2007):

 

Artículo 93. Identificación y autenticación.

1. El responsable del fichero o tratamiento deberá adoptar las medidas que garanticen la correcta identificación y autenticación de los usuarios.
2. El responsable del fichero o tratamiento establecerá un mecanismo que permita la identificación de forma inequívoca y personalizada de todo aquel usuario que intente acceder al sistema de información y la verificación de que está autorizado.
3. Cuando el mecanismo de autenticación se base en la existencia de contraseñas existirá un procedimiento de asignación, distribución y almacenamiento que garantice su confidencialidad e integridad.
4. El documento de seguridad establecerá la periodicidad, que en ningún caso será superior a un año, con la que tienen que ser cambiadas las contraseñas que, mientras estén vigentes, se almacenarán de forma ininteligible.

 

Queda por tanto totalmente prohibido bajo sanciones muy duras (repito, aquí en España al menos) el uso de cualquier sistema que almacene nuestras credenciales en texto legible/reversible (lo que llamamos comunmente “texto plano”). La siguiente pregunta que se hacen mucho es que si no se almacena nuestras contraseñas en texto plano ¿como puede verificar un servidor si los datos introducidos son correos o no? Muy simple, simplemente por comparación, usando hash criptográficos por ejemplo. Un ejemplo simple:

Contraseña en texto plano introducida por el teclado por el usuario: Mariposa
Hash SHA1 aplicado a Mariposa: 8ACEF7C1C4B46DABCAB5A7B70AF2C52CD72FD00A

El servidor en este caso no almacenaría en su base de datos en el campo contraseñas el texto “Mariposa” sino la cadena “8ACEF7C1C4B46DABCAB5A7B70AF2C52CD72FD00A”. El usuario cuando introduce su contraseña en la página de inicio de sesión de este servicio de ejemplo, esta sería convertida en el mismo equipo del usuario a su Hash SHA1. El Hash sería el que viajaría por todo internet hasta llegar al servidior de destino, donde simplemente se cotejaría con el valor almacenado en su base de datos. Si coincidiesen se permitiría el acceso.

Este sistema garantizaría que aun cuando se filtrase un listado que incluyese tanto nombres de usuarios como sus contraseñas (en forma de Hash criptográfico), la repercusión sería mínima, ya que una de las propiedades principales de los Hash Criptográficos es la de convertir cualquier cadena (por ejemplo una contraseña) en una cadena de caracteres hexadecimales generalmente de longitud fija IRREVERSIBLE, en la que cualquier cambio en la cadena de entrada alteraría totalmente la cadena de salida. Eso quiere decir que aunque supiésemos que la contraseña cifrada de un usuario es 8ACEF7C1C4B46DABCAB5A7B70AF2C52CD72FD00A, no tendríamos forma humana (aceptable) para revertirlo a su origen, “Mariposa”.

Por supuesto, se podría crear una tabla en nuestro equipo con los Hash SH1 de todo el diccionario español y se podría comparar el hash obtenido con nuestra base de datos de Hash y ver si existiese una correspondencia… pero para evitar esto existe igualmente multitud de técnicas como el uso de Salt, Hash aplicados dos veces… etc etc etc.

Esta es la razón por la que cualquier servicio que tenga una seguridad mínima, siempre podrá permitirnos resetear nuestra contraseña, pero jamás debería poder reenviarnos la contraseña antigua, puesto que ni el propio servidor debería de ser capaz de conocerla. Dicho de otro modo, si le damos a recordar contraseña a cualquier servicio que tengamos que esté en un servidor Español, y nos llega un correo con la contraseña antigua, podemos denunciar ante la Agencia de Protección de Datos Española dicha empresa, y les caerá un buen paquete.

 

 

Como protegernos

Nunca hay que ser alarmista, a día de hoy existen medidas de seguridad prácticamente invulnerables, y en conjunción con la buena praxis debería de mantenernos siempre alejado de posibles peligros. Evidentemente no siempre depende de nosotros, y no podemos saber como son tratados nuestros datos por terceros o si sus sistemas cumplen con un mínimo de seguridad. Pero por otro lado si hay mucho que podamos hacer, y que en su gran mayoría nadie hace… ya sea por desconocimiento o por pura imprudencia. Todas ellas son de fácil aplicación:

 

  • Acceso mediante Certificado electrónico (DNI-e, CERES) cuando sea posible: Bancos, Administración Pública…
  • No acceder jamás a sitios sensibles en redes públicas o privadas de gran difusión sin conocer bien los sistemas de seguridad que usan dichos con antemano: En el trabajo, universidades, redes Wifi de terceros…
  • Proteger correctamente las redes WIFI Domésticas para que sea imposible que un topo se cuele y pueda acceder a nuestro tráfico que no se esté cifrando: Usar WPA2-PSK con AES y frases de paso.
  • Jamás usar contraseñas repetidas en la medida de lo posible, o por lo menos en aquellos servicios importantes: Paypal, Bancos, Correo Electrónico…
  • Usar siempre contraseñas alfanuméricas combinando letras mayúsculas/minúsculas y números para evitar que sea posible ataques de FuerzaBruta: SoyLaRe1naDeLosMares
  • No usar jamás palabras simples de nuestro diccionario, no usar jamás nombres propios, de mascotas…
  • Conocer un poco los servicios que usamos y si brindan un mínimo de seguridad, comprobar si almacenan nuestras contraseñas haciendo uso del restablecer contraseña clásico
  • No usar preguntas de seguridad, existen método de identificación auxiliares infinitamente más fiables: SMS con códigos de identificación, llamadas al móvil para verificar la identidad…
  • No almacenar en los navegadores de equipos de terceros las contraseñas de nuestros sitios, e incluso pensar detenidamente si queremos que se guarden en el nuestro ante la posibilidad de que alguien tenga acceso a nuestro equipo
  • No usar en lo posible dispositivos de terceros para acceder a nuestros datos, no sabemos si han sido manipulados.
  • Asegurarnos de que antes de introducir cualquier contraseña el tráfico se esté realizando bajo protocolos seguro tipo TLS/SSL (https en las webs), y que por supuesto la comunicación se mantiene cifrada durante toda la sesión.
  • Usar cuando sea posible sistemas de autentificación doble: SMS o tablillas de coordenadas de los bancos, la Doble autentificación de Gmail…

Por mucho que duela, el 90% de todas las infracciones de seguridad, de todos los robos de contraseñas, accesos a cuentas y otros comienzan porque el usuario cometió alguna imprudencia. En este caso concreto es cierto que fue Yahoo! el responsable por culpa de un doble fallo de seguridad (La injección SQL y el almacenaje en texto plano de las contraseñas), pero es el usuario quien si hubiese sido un poco cauteloso habría usado primero una contraseña totalmente independiente a sus servicios más importantes, y segundo habría comprobado si almacenan sus credenciales en texto plano o cifrado. Igual que a día de hoy se enseña a los más pequeños el uso de las tecnologías, de Internet, de las redes sociales, de los correos electrónicos, de los foros, de… sinceramente no entiendo como Educación no ha impuesto igualmente temas sobre seguridad básica. No hablamos de ser un experto, hablamos que tomando unas medidas básicas que pueden enseñarse a la perfección en una hora como muchísimo, el usuario podría tener prácticamente la total seguridad de que navega de forma segura y de que sus datos también están a buen recaudo. Por supuesto siempre hay alguien que es capaz de lidiar con todas las medidas de seguridad y hace posible lo imposible, pero al menos no dejemos la puerta de nuestra casa abierta de par en par con un letrero que diga: “Por favor, entren a robar.”

Al margen de todo ello, es evidente que a Yahoo! le espera posiblemente una buena sanción económica por parte de las autoridades estatales. Como digo aquí en España y posiblemente en Europa sería una violación directa, y dado el tamaño del a filtración (casi medio millón de afectados), la multa sería muy severa…

 

Un saludo.

 

Volver a arriba

Sobre Mí

Alma Oscura por Theliel is licensed under a Creative Commons Reconocimiento-No comercial-Sin obras derivadas 3.0 Unported License.
Política de Privacidad.
Para otros permisos que puedan exceder el ámbito de esta licencia, contactar en blog.theliel.es/about/contactar.