WhatsApp Llamadas: Un phishing con estadísticas en tiempo real que distribuye malware para Android

Ayer, en el blog de Eleven Paths, nuestro compañero hacía una reflexión sobre las apps para Android que venían con RATs (Remote Administration Tools), y que estaban siendo distribuidas a través de Google Play. Hoy, siguiendo con el malware, quiero hablar por aquí de una campaña de sitios de phishing que se han publicado en múltiples dominios creados para la ocasión, como son Whatsappsite.com, WhatsAppVid.com, WhatsAppCallsInvitation.com o WhatsAppCallsInvite.com. Todos estos sitios están incitando a viralizar la inclusión de más contactos en esta falsa campaña distribuyendo un mensaje que supuestamente permite conseguir acceso a la función de WhatsApp Llamadas para realizar llamadas gratis. Por supuesto, el objetivo de todo esto no es otro que infectar a los usuarios con apps maliciosas.

Figura 1: Campaña de phishing de WhatsApp Llamadas distribuye malware

El aspecto que tienen los sitios de la campaña, además de los que han sido infectados, es el que se puede ver a continuación. En el solo hay dos botones, para invitar y para continuar el proceso. El segundo de los botones no permite continuar si no se ha realizado antes el proceso de invitar. Si te conectas con uno de los navegadores habituales, a día de hoy el sitio sale marcado como un sitio malicioso, pero si te conectas por alguna navegador sin protección de sitios antiphishing, no dará ninguna alerta.

Figura 2: Mensajes de Phishing utilizado en los sitios webs para distribuir el malware

Si pulsas a invitar, podrás ver que el objetivo es conseguir que se abra dentro de WhatsApp y se envíe a más contactos para que visiten, también desde WhatsApp, este mismo sitio de phishing. 

Figura 2: El hipervínculo que sale cuando se da a "Invite Now"

Para saber cómo les está yendo el negocio, los responsables de la campaña están utilizando paneles de control de estadísticas, que se pueden ver en las páginas de phishing. Esto no es muy común, pero si miras en el código fuente de WhatsAppSite.com puedes ver el siguiente script.

Figura 3: Script de estadísticas para contabilizar cuánta gente visita el sitio de phishing

Esto hace referencia a un panel de estadísticas en la web Amung.us que está disponible online, y donde se puede ver en tiempo real cómo las víctimas se conectan a los diferentes portales y el número de ellos a los que ha alcanzado la campaña.

Figura 4: Panel de estadísticas de WhatsAppSite.com en Among.us

También se puede ver por donde se ha distribuido geográficamente, con lo que se tiene una idea de cuál es el objetivo inicial de la misma y cómo va evolucionando.

Figura 5: Distribución de las víctimas en tiempo real. Muchas en Latinoamérica y España

Si tienes amigos y conocidos, avísale de que tenga mucho cuidado si le llega una de estas invitaciones. A día de hoy se está aprovechando del buzz mediático de cualquier tema para hacer este tipo de campañas de malware - y no se iba a desperdiciar el interés que despierta WhatsApp -así que hay que tener mucha prudencia con cualquier mensaje que llegue similar a estos.

Saludos Malignos!

OSB-Rastreator: Cómo localizar automáticamente todos los bugs que tiene tu Ubuntu (o cualquier GNU/Linux)

Encontrar vulnerabilidades puede parecer más difícil hoy en día de lo que a priori puede llegar a ser. Este pensamiento es el que nos llevó a realizar una pequeña prueba de concepto de lo que podría hacer cualquiera de nosotros en su casa. Todo este mini proyecto nace de un tweet de mi compañero en Eleven Paths David Barroso en el que, tras los incidentes de seguridad que sufrió el pasado 2014 - y que parecen continuar en 2015 - el mundo del Open Source enunciaba:

“GNU has given a lot to the tech companies. Now it’s time to help GNU and audit many of its core components”. (@lostinsecurity).

Esto me hizo pensar en el gran número de aplicaciones Open Source que diariamente están expuestas en los repositorios. Una de las primeras preguntas que me hice fue, "¿Cuántos paquetes de software tenemos al alcance del comando apt-get install? ¿Este código será revisado en busca de vulnerabilidades?"

Figura 1: OSB-Rastreator: Cómo localizar automáticamente los bugs que tiene tu Ubuntu

Quise resolver la duda a mi primera pregunta realizando un simple ejercicio con apt-get. Para ello instale la última versión de Ubuntu, y ejecuté en una shell la instrucción: apt list | cut –d’/’ -f1 >> openSource.txt. Luego simplemente con un wc –l sobre el fichero podría ver el número de paquetes de software que, por defecto, tenemos accesibles desde Ubuntu. ¿Por qué Ubuntu? Está claro, es una de las distribuciones más utilizadas, si no la que más, en el mundo Linux. El resultado obtenido sobre el número de paquetes de software disponibles por defecto puede sorprender a más de uno. Cada usuario que instala Ubuntu tiene alrededor de 45.000 paquetes de software, en mi caso exactamente 45.494.

Figura 2: 45.494 paquetes disponibles en Ubuntu

A la pregunta de si el código es revisado puede haber varias opiniones, aunque por lo que parece tras un análisis muy básico probable la respuesta correcta es que "No lo suficiente". Ya en el pasado hemos visto estudios de hacking con buscadores sobre repositorios de código OpenSource utilizados para buscar vulnerabilidades de tipo SQL Injection, XSS o RFI, e incluso del tipo LDAP Injection. Solo con lanzar consultas adecuadas sobre el código fuente es posible sacar estos datos.

Creando OSB-Rastreator

Pensando sobre algunas vulnerabilidades clásicas, y que a día de hoy siguen apareciendo, llegué a la conclusión de que un buen punto de partida serían las funciones inseguras ampliamente conocidas. Aquí me surgió una nueva pregunta, ¿Seguirán utilizándose de manera masiva las funciones strcpy(), sprintf(), gets() o scanf(), entre otras? ¿Quién no vio su primer buffer overflow con un strcpy() o alguna de las mencionadas anteriormente? Esto fue el origen de la creación de OSB-Rastreator.

Pensando sobre esto quise buscar estas funciones, pensando que encontraría una cantidad ridícula de software con estas funciones en su código. Pensando un poco la mayoría del código que podemos encontrar en los repositorios de Linux será código en Lenguaje C, pero aun así seguía pensando que estas funciones potencialmente inseguras no tendrán mucho rastro por los repositorios, ¿o quizá sí? El siguiente paso era conseguir, de la manera más sencilla, y que cualquiera en su casa pudiera realizar, descargar todo el código fuente de los más de 45.000 paquetes de software. Para llevar a cabo la descarga de todos los paquetes de software se implementó un script en bash con el siguiente funcionamiento:

1. Leer paquete del fichero openSource.txt
2. Descargar paquete
3. Descomprimir tar.gz
4. Búsqueda de código C
5. Búsqueda de función insegura
6. Eliminar paquete (tar.gz y código descomprimido)

En la siguiente imagen se puede ver parte del código de descarga de los paquetes de software, algo muy sencillo y que automatizaba todo el proceso de obtención del código de los repositorios.

Figura 3: Descarga de paquetes y búsqueda de funciones inseguras en códigos C

Este código era la primera prueba de concepto para ver si el proceso era viable en un tiempo razonable. Decidí utilizar una máquina en la nube para llevar a cabo el proceso. Por cada paquete de software del que descargábamos el código fuente, hay que entender que podríamos obtener N ficheros de código en Lenguaje C, y cada fichero debía ser analizado buscando las funciones inseguras. En este punto aparte de pensar en las funciones inseguras recordé grandes “cagadas” de algunos developers a la hora de programar y comentar el código, por lo que pensé, "¿Qué puedo encontrar en los comentarios?" De esta forma decidí que también los comentarios debían ser buscados en esta primera pasada.

Figura 4: Resultados de búsqueda de funciones inseguras por el script

El fichero denominado down.sh tardó más de 8 días en realizar el proceso de descarga y búsqueda de información interesante en el código. ¿Qué ocurría cuando se encontraba una función insegura o un comentario? Pensando en que encontraría pocas cosas para su posterior análisis, decidí almacenar por carpetas las funciones inseguras. Es decir, el script encontraba un strcpy() y almacenaba dentro de la carpeta strcpy un fichero con el nombre de la aplicación y en el interior del fichero los ficheros de Lenguaje C pertenecientes al paquete de software, con la línea dónde se encontraba la función.

Figura 5: Un strcpy en Hydra 7.5

El script puede funcionar mucho más rápido si se distribuye, pero en este caso el tiempo no era importante para la prueba de concepto. En este momento y teniendo los resultados en la mano me quedé sorprendido. Estos son los resultados:

• La función strcpy() tenía 9567 ocurrencias, es decir, fue identificada en ese número de paquetes de software.
• La función gets() tenía 607 ocurrencias.
• La función scanf() tenía 1257 ocurrencias.
• La función sprintf() tenía 9426 ocurrencias.
• Por último, fueron identificados 15647 paquetes de software con comentarios multilínea. En este caso, solo multilínea.

Realmente mi gozo en un pozo. Por un lado me sorprendió ver tanto software que utilizase funciones inseguras, lo que fue algo positivo para esta prueba de concepto. Por otro lado analizar todo esto iba a ser algo inviable, por falta de recursos y tiempo. Para poder ver en qué partes encontraríamos bugs sin que fuera una pérdida el tiempo, decidí analizar a mano algunas aplicaciones.

Analizando los resultados en busca de bugs

Una de las primeras en las que me fijé fue dnsmasq, y analizado las llamadas strcpy() observé una por encima del resto strcpy(ifr.ifr_name, argv[1]) en un fichero llamado dhcp_release.c. Esto tiene que ser vulnerable sí o sí, no puede haber ejemplo más claro. Tras comprobarlo, efectivamente, no se comprueba el límite que se introduce en argv[1] por lo que tendremos un desbordamiento.

Esto me volvió a hacer pensar y preferí automatizar el proceso de búsqueda de patrones “curiosos” o “potencialmente vulnerables” como son los argv[x] que podemos encontrar, o por ejemplo las variables de entorno que son pasadas sin validación a través de la función getenv() a un strcpy(). En la imagen se puede ver como ejecutando el script search.sh se busca dentro de los resultados el patrón que nosotros queramos. En este caso se busca el texto getenv sobre resultados de funciones inseguras, por ejemplo buscando llamadas a getenv() que se pasan directamente a strcpy().

Figura 6: Búsqueda de patrones en los resultados de funciones inseguras

Otra prueba que quise automatizar viendo el gran número de argv[x] que se pasaban a funciones como strcpy() fue la de instalar automáticamente las aplicaciones que contengan esto, que automáticamente se intente desbordar el buffer y, a posteriori, se desinstalasen las aplicaciones. La imagen dónde se puede ver la ejecución de este script se encuentra unificada, para que se pueda ver rápidamente la instalación, la provocación del fallo y la desinstalación. Este script fue denominado buffer.sh y un ejemplo de su ejecución es la siguiente:

Figura 7: Instalación, prueba y explotación de buffer overflow automáticamente

Se encontraron fallos muy sencillos de detectar, pero sorprendió el número de errores, por lo que se puede decir que NO hay un análisis básico de seguridad o de validación de parámetros en la publicación o subida de aplicaciones a los repositorios de forma automatizada. En función de qué permisos utilice una aplicación o con qué usuario se ejecute estos fallos pueden ser más o menos graves.

Antes de instalar un paquete analiza los bugs

Llegados a este punto pensé en cómo se puede ayudar al usuario, o que al menos esté notificado de la calidad del código que está instalando, y quizá una solución viable es la modificación de apt-get para que cuando un usuario ejecute la instrucción apt-get install se realice un análisis de las funciones de la aplicación mediante expresiones regulares. Al final el trabajo fue presentado en Hackron 2015, (sí, sé que puedo dar envidia por el carnaval vivido allí y que no dejo indiferente a nadie…) Dicho esto, he de decir que por falta de tiempo no me pegue con apt-get y realicé un script que podría ser invocado como alias de apt-get para llevar a cabo las instalaciones de paquetes de software.

Figura 8: La instalación de un paquete antes verifica las funciones inseguras que tiene

El script denominado apt-get-install.sh antes de llevar a cabo la instalación del software realiza una serie de comprobaciones en el código, basadas en lo que se automatizó con down.sh. En primer lugar descarga el código fuente, aplica las expresiones regulares que podemos configurar sobre los ficheros en Lenguaje C y en el instante que detecta alguna función no segura notifica al usuario antes de seguir con la instalación.

Figura 9: Antes de instalar muestra las funciones inseguras

El script te permite ver las líneas dónde se encuentran las funciones no seguras y te permite acceder al código completo por si se quiere hacer alguna comprobación manual. Por último, se solicita al usuario la confirmación de instalación al usuario.

Figura 10: El usuario decide si instalar o no el paquete sabiendo ya la información de las funciones inseguras

Este sistema me parece un buen método de sentido común, sobre todo en casos en los que se quiere realizar un proceso de fortificar un servidor Linux. Con estos avisos se tiene mucha más información a la hora de extender la superficie de exposición, y del riesgo en que se está incurriendo en cada nuevo paquete que se instala.

Personalizando la automatización de búsqueda de bugs

Por último hay que decir que, tal y como se comentó anteriormente, la personalización a la hora de realizar las búsquedas en los paquetes de software es algo imprescindible. Cada uno puede tener distintas intenciones, o puede realizar distintas búsquedas a través de diferentes expresiones regulares basándose en esta arquitectura. Puede ser que en un momento dado salga cierta vulnerabilidad conocida implementada de alguna forma y que añadiendo la expresión regular al sistema podamos localizar más software vulnerable en los repositorios de Linux para explotar algunos ejemplos concretos.

Figura 11: Expresiones regulares para buscar distintos tipos de bugs

Para añadir las expresiones regulares al sistema disponemos de un fichero denominado regexp.txt, dónde por cada línea se indica la carpeta dónde se almacenará y la expresión regular. Este punto es importante porque da mucha flexibilidad al script y las posibilidades ya dependen de lo que cada uno quiera encontrar.

Figura 12: Búsqueda de bugs con ficheros de expresiones regulares

En la imagen anterior se puede ver como se lanzará el script denominado down_customize.sh, siendo el primer parámetro el fichero de texto que tiene el nombre de todos los paquetes de software y el segundo parámetro el fichero dónde se encuentran las expresiones regulares de lo que queremos encontrar en el código fuente.

Resultados y un Exploit de Memory Corruption en Chemtool

Los paquetes de software disponibles por defecto en una instalación de Ubuntu son 45.494. Tras lanzar alguna pasada más con el script personalizado se obtuvieron 13.670 paquetes de software distinto que contenía la función strcpy() y ni mucho menos esto significa que sean vulnerables, habría que llevar a cabo un análisis. Manualmente es una locura, pero basándose en pequeños tricks, intuiciones y herramientas se pueden detectar nuevos bugs.

En 13.430 paquetes de software se encontraron funciones sprintf() que también son potencialmente inseguras. En 1.789 paquetes de software se encontró la función scanf(), mientras que en 973 paquetes de software se encontró la función gets(). Respecto a los comentarios en el código, prácticamente la mitad del código analizado contenía comentarios, lo cual no es malo, pero se podría utilizar el script search.sh para buscar patrones o cadenas clave como password, user, connection, etcétera.

Para la charla de Hackron 2015 se quiso demostrar que cualquier podría sacar bugs de manera sencilla con este sistema o cualquiera similar que una persona se puede montar en casa. Por esta razón una de las aplicaciones encontradas que tenía un bug fue notificada al autor de la misma. Tras esto a través de Exploit-DB se lanzó la vulnerabilidad en la aplicación Chemtool, la cual contenía Memory Corruption.

Figura 13: ChemTool

El crasheo de la aplicación era llevado a cabo de dos maneras, la primera y más sencilla por no controlar el parámetro de entrada argv[1] cuando la aplicación era lanzada desde una terminal. Tras ver esto, quise analizar cómo se comportaba la aplicación al pasarle un fichero con contenido no esperado. Para crear el fichero malicioso se utilizó un pequeño script en Ruby:

#/usr/bin/ruby
buf = "a"*3000
filename = "crash.png"
file = open(filename,'w')
file.write(buf)
file.close
puts "file created!"

¿Se podría ejecutar código arbitrario? Es bastante probable, aunque no he comprobado esta parte. Con OSB-Rastreator me basé en encontrar puntos débiles y bugs de aplicaciones que se encuentran expuestas por defecto a millones de usuarios de Ubuntu en el mundo. Un par de días antes del evento de Hackron decidí enviar el bug para que OSVBD la diera de alta, si ellos lo consideraban. Al día siguiente tenía disponible el ID que identificaba el bug y podría mostrarlo en la charla.

Figura 14: El bug en OSVBD

A partir de aquí se puede ver por Internet como distintos sitios se hacen eco de la vulnerabilidad, por ejemplo en 1337day Inj3ct0r. Esto ejemplifica que cualquiera con ideas y conceptos básicos puede llevar a cabo un proyecto que permita de manera masiva hacer un análisis básico y obtener resultados sorprendentes.

Figura 15: Bug de ChemTool

En conclusión, por defecto existe gran cantidad de software en los repositorios que distribuciones como Ubuntu proporcionan a los usuarios que son vulnerables y fácilmente accesibles a los usuarios. Lógicamente, si añadimos repositorios a sources.list el número de paquetes de software a analizar serían mayores, por lo que se podrá detectar un mayor número de vulnerabilidades.

Hoy día técnicas como el Pentesting Persistente que encontramos en servicios como Faast, ayudan a mejorar y detectar vulnerabilidades de forma temprana. Aunque el sistema propuesto aquí está pensado para analizar repositorios muchas de las aplicaciones que podemos encontrar nuestros sistemas Linux de Ubuntu, en dichos repositorios podrían estar los paquetes de servidores Web, FTP, SSH o, directamente, tener interacción remota. Continuaremos evolucionando esta idea.

Autor: Pablo González Pérez (@pablogonzalezpe), Project Manager en Eleven Paths
Escritor de los libros "Metasploit para Pentesters" y "Ethical Hacking"

Bar Mitzvah: Nuevo ataque a SSL/TLS te roba las sesiones

En la reciente Black Hat Asia 2015 se acaba de presentar un nuevo trabajo de investigación sobre las vulnerabilidades de las conexiones SSL/TLS cuando estas utilizan el algoritmo de cifrado RC4. Éste es uno de los algoritmos criptográficos comúnmente utilizado en el cifrado de comunicaciones digitales, y de él se conocen vulnerabilidades que lo hacen totalmente inseguro desde hace más de trece años. Ahora en este nuevo trabajo, publicado por Imperva se ha mostrado un ataque curioso al que han denominado Bar Mitzvah, y que está correctamente explicado en el artículo de investigación.

Figura 1: Bar Mitzvah: Nuevo ataque a SSL/TLS te roba las sesiones

Para entender los ataques, hay que describir primero el concepto de Invariance Weakness que ellos utilizan como base de su investigación. Esta debilidad se conoce desde hace tiempo y se produce por el sistema pseudo-aleatorio que tiene el algoritmo RC4 para generar las claves. Este fallo hace que el motor de aleatoriedad, produzca unas claves de cifrado inseguras concretas - a las que denominan "Hits" - con un patrón en forma de L que las caracteriza.

Figura 2: Claves inseguras en forma de L generan que los LSB (Least Significant Bit)
del Pseudo-Random Stream sean inseguros

En el paper "Weaknesses in the Key Scheduling Algorithm of RC4" se estudia en profundidad y se dice que, de todas las claves que se utilizan en una implementación RC4 hay muchas que tienen debilidades y podrían romperse.

Figura 3: Paper que estudia las debilidades de las claves utilizadas en RC4

Estas claves con el bug de Invariation Weakness permiten que un atacante pueda descifrar en poco tiempo los primeros 100 bytes de una conexión SSL/TLS, dejando parte del tráfico de la sesión al descubierto. Esos 100 bytes no son mucho, más teniendo en cuenta que el Handshake de la sesión SSL/TLS ya se lleva 35 bytes, pero conseguir descifrar 65 bytes puede ser más que suficiente, como han demostrado.

Ataque 1: Captura de tráfico de red sin ataque man in the middle

En un escenario de ataque de red en el que solo se pueda acceder al tráfico, se podrían estar escuchando todas las sesiones SSL y descifrar los 65 bytes de aquellas que vinieran cifradas con una clave "Hit". Una vez analizados esos 65 bytes, se procedería a ver qué contenido va en esos, para lanzar un ataque a posteriori.

Figura 4: Bytes que se pueden descifrar. Desde el 36 al 100 del Upstream.
(Upstream: del cliente al servidor)

El éxito del ataque es cuando en esos 65 bytes se puede sacar parte de la cookie de sesión de la aplicación. Con una parte de 65 bytes de una cookie de sesión de ASP.NET o de PHP, se puede realizar un ataque de fuerza bruta para conseguir obtener una cookie válida en tiempo y forma. Una vez conseguida las cookies, se podría hacer un hijacking completo. En el estudio, los investigadores también hacen sus cálculos de si en esos 65 bytes vienen partes de una contraseña, para saber cuánto se tardaría en crackear la contraseña de forma total.

Ataque 2: Captura de tráfico de red con un ataque man in the middle

Como se puede suponer en el ataque 1, para conseguir tener éxito hay que tener algo de fortuna para capturar las claves "Hits" y que en los 65 bytes que se pueden descifrar haya algo que permita crackear información sensible para secuestrar una cuenta o sesión. Sin embargo, si se tuviera un control en el cliente mediante un ataque de man-in-the-middle similar al que propone BEAST, se puede entonces generar mucho más tráfico en la sesión del cliente para conseguir más "Hits" y por tanto conseguir más partes de la cookie de sesión o de una clave.

Figura 5: Porcentajes de contraseñas crackeadas en ataques utilizando más o menos LSBs

Al final, existiendo estas debilidades, y conociendo todo lo que ya ha pasado en las redes WiFi que utilizan WEP - basado en RC4 - está claro que la conclusión a la que llegan los investigadores es la adecuada. Deshabilita RC4 en el servidor y en el cliente.

Saludos Malignos!

Congreso Internet 3.0: 24 y 25 de Abril en Alicante

Durante el próximo mes, además de estar en el Foro Aslan en Madrid, daré una charla en el Congreso Internet 3.0 el día 24 de Abril, viernes. El evento se realizará los días 24 y 25 de Abril, en la preciosa ciudad de Alicante, y tratará distintos temas que tienen que ver con la comunicación, los negocios y las empresas en Internet, contando con un buen número de presentaciones.

Figura 1: Internet 3.0 los días 24 y 25 de Abril en Alicante

Durante los dos días que dura el congreso estaremos un total de doce más uno ponentes dando alguna sesión sobre los temas dichos. La lista completa de todos los ponentes que nos daremos cita en Alicante la tienes en la web del congreso, que como puedes ver es variada.

Figura 2: Los ponentes de Internet 3.0

En mi caso, yo estaré el primer día del congreso, con una charla sobre cómo creer en la magia puede llevar a muchas personas a tener problemas. No os anticipo mucho más que lo que pone en la agenda, donde tienes todas las charlas que se van a dar.

Figura 3: Mi sesión en Internet 3.0 el día 24 de Abril

Si bajas a Alicante a pasar un fin de semana y ver el congreso, nos vemos allí. Yo iré con el gorro, aunque viendo las fechas puede ser que toque uno de esos días en Alicante en los que mejor ir con chanclas y a lo loco.

Saludos Malignos!

Cyberbullying: El Precio de la Vergüenza

Mucho se ha hablado en los últimos tiempos del Cyberbullying - o Acoso Cibernético en la red - aunque a mi parecer sigue sin ser suficiente. El ver que día tras día personas intentan espiar las cuentas de personas cercanas, o que diariamente en las redes sociales se mofan de las personas confundiendo "libertad de expresión" con ofensa gratuita y en muchos casos acosos. Es triste ver como la gente utiliza Twitter o Facebook como si fuera el graderío de un espectáculo bárbaro en el que insultar para conseguir Likes o Retweets. Pero mucho peor es cuando se ataca a una persona en particular de forma grupal haciéndole todo tipo de memés, chistes, montajes fotográficos, etcétera.

Figura 1: Cyberbullying - El Precio de la Vergüenza

Cuando esto se hace a una persona en un círculo reducido, como por ejemplo el ámbito de una clase o una escuela, estamos hablando de Acoso Cibernético y en las mentes de jóvenes puede terminar causando estragos y llegando en algunos momentos al suicidio. He de reconocer que el caso de Amanda Todd, la joven canadiense que se suicidó por ser ver víctima de Cyberbullying y Sextorsión, me impactó de manera brutal. Aquí está el vídeo en el que explica ella misma por qué se suicidó.

Figura 2: Vídeo del Suicidio de Amanda Todd

Hoy quería aprovechar para intentar ayudar un poco a mi amigo Angelucho en la labro de difusión y su esfuerzo continuo con las iniciativas que lanza desde El Blog de Angelucho y dejaros una conferencia que me gustó mucho sobre este tema, titulada El Precio de la Vergüenza. La imparte Monica Lewinsky, que como dice ella, fue la primera persona en sufrir la burla y el acoso mundial en Internet ya que su caso eclosionó justo en plena explosión de Internet.

La conferencia dura 20 minutos, pero cuenta muy bien su historia y cómo sus padres la hacían ducharse con la puerta del baño abierto o como no la dejaban sola ni un minuto mientras dejaban que el tiempo pasara y pasara. Más de una década en silencio de esta mujer, que tiene una historia que contar y merece la pena escuchar.

Figura 3: Conferencia de Monica Lewinsky sobre el Cyberbullying o Acoso Cibernético

Si estás siendo víctima de Acoso Cibernético en tu escuela, en tu instituto, universidad o trabajo por compañeros, o "amigos", denúncialo a la comisaría. No les permitas que se salgan con la suya. Tienes mi apoyo y el de mucha gente para ayudarte a terminar con eso. No lo permitas. Toma evidencias y denúncialo.

Saludos Malignos!

¿Y tú cómo juegas con el QueryString en un pentesting?

Los pocos ratos libres que saco en cafeterías, aeropuertos, viajes en tren o noches de desvelo los dedico a seguir jugando con lo que más me apasiona. Dedico ratos a revisar artículos que he guardado para leer después, a revisar alguna herramienta o a probar alguna nueva idea. Lo bueno de la seguridad informática y el hacking es que siempre hay posibilidad de dar una nueva vuelta de tuerca a cualquier parte. Siempre se puede probar algo nuevo y siempre puedes probar una nueva aproximación. En el mundo de la seguridad de las aplicaciones web, una de mis grandes pasiones, siempre puedes sacar un rato, abrir el navegador y enredar por ahí a ver qué sale.

Figura 1: ¿Y tú cómo juegas con el QueryString?

A lo largo de todos estos años, mi visión era que para hacer una auditoría web completa había que probar todo. Al igual que los investigadores que van en busca de bugs en binarios utilizan técnicas de fuzzing para localizar cualquier anomalía que pueda llevar a descubrir un fallo de seguridad, en las aplicaciones web mi idea es que hay que conseguir hacer lo mismo. Por supuesto, éste no es exactamente el mismo entorno, ya que con un binario puedes trabajar en tu equipo y aprovechar al máximo la potencia de computo de tu máquina, mientras que en un servidor web tienes que contar con la línea de comunicaciones en medio y las medidas de seguridad que protejan el sitio.

Aún así, es fundamental probar todo lo probable, todo lo improbable y parte de lo imposible si quieres conseguir encontrar los secretos que detrás de una URL esconde un servidor web. Hay que jugar con el QueryStging a ver quién hay detrás y cómo se comporta, que muchas veces te sorprende. Yo me dedico a jugar mucho con él, y si sale alguna nueva pieza de información útil, a la mañana siguiente que pase por la oficina de Eleven Paths me siento un rato con los compañeros que llevan los plugins de nuestro sistema de Pentesting Persistente para que metan en la knowledge base de Faast las pruebas pertinentes para detectar en los servidores de nuestros clientes ese defecto, bug, leak o trick.

Figura 2: Un sencillo fuzzing con parámetros puede generar un error no esperado

El QueryString, tomado como una cadena de caracteres que pueda ser procesada como un string puede dar mucho juego. Por ejemplo, cuando haces una llamada a un determinado servidor web con un QuerySgtring cualquiera, eso antes puede pasar por los elementos de seguridad de red. Sabiendo eso puedes intentar hacer saltar el WAF y sacar información de él. Esto ya os lo conté en el artículo que explicaba lo fácil que es simular un ataque de LFI para hacer cantar al WAF. Esta misma idea se puede aplicar de igual forma con los ataques de inyección de código Server-Side y Client-Side.

Figura 3: Errores por protecciones contra ataques de HTML Injection

En muchos servidores IIS, por ejemplo, es suficiente con simular un ataque de Inyección de comandos HTML para obtener un Error 400 o un Error 500 que lo identifique, o, como se ve aquí, hacer saltar por los aires una aplicación .NET como en el caso de la propia Microsoft.com.

Figura 4: Error forzado en Microsoft.com simulando un ataque de HTML Injection

Dedicarse a hacer fuzzing del QueryString añadiendo caracteres a un determinado nombre de dominio o directorio puede dar muchas sorpresas. Hay que tener en cuenta que muchas veces, puede que ese QueryString esté siendo parseado por algún módulo del servidor que esté haciendo URL Rewrite o que directamente esté siendo entregado a una aplicación que va a procesar el QueryString completamente. Una cosa que hacen muchos sitios es, cuando se solicita por URL una dirección que una aplicación que no existe, el módulo de tratamiento de errores, en lugar de enviar un Error 404 directamente lanza una consulta a ver si puede extraer alguna otra página y devuelven documentos.

Figura 5: El QueryString sirve para buscar páginas con el título que tengan en Rolling Stones

En el momento en del QueryString se saque una cadena de caracteres y se trate como un parámetro, esto podría desembocar en un ataque de inyección de código tanto del lado del cliente como del lado del servidor. Podría acabar en una consulta a una base de datos o en un parámetro que se imprimiese en la página del cliente. En muchos casos, simplemente porque el QueryString se ha copiado íntegramente en la página de respuesta.

Figura 6: En esta página el QueryString puede convertirse en una cadena de búsqueda.
Además sufre una sanitización peculiar.

Por supuesto, hacer fuzzing en el QueryString puede desembocar en la generación de mensajes de error en todos los niveles que pueden interpretarlo, lo que ayudaría a poder sacar mucha información del sitio objetivo. Pensad que solo el QueryString puede ser procesado por el WAF, por el WebServer, por el motor del Engine que ejecute la aplicación, por el programa en concreto que se ejecute, por el sistema de ficheros y por los programas que se lanzan en el tratamiento de errores. Así aparecen cosas como el bug de IIS, los leaks del módulo de Mod_Negotiation, los mensajes de errores con tanta información de PHP, de TomCat, ColdFussion y demás.

Figura 7: Elementos que pueden acabar procesando el QueryString según el flujo

La gracia está en que, depende de cómo esté construido ese QueryString, vas a poder comunicarte con uno u otro de los elementos de toda la cadena y, tal vez, sacar información diferente de cada uno de ellos para encontrar, quién sabe, un nuevo camino. ¿Qué pruebas haces tú cuando te enfrentas un www.server.com para jugar con el QueryString?

Saludos Malignos!

China está lista para admitir que tiene un Ciberejercito

Hoy en día casi está mal visto no tener unidades militares centradas en el mundo cibernético con plena capacidad operativa. Parece una debilidad que no se debe permitir ningún país moderno porque esta guerra encubierta que comenzó hace años parece que ya no es "encubierta" nunca más. Hoy en día es más como un juego de "alguien ha owneado a alguien", donde el gran problema sigue siendo la atribución de quién te ha atacado, pero que te han atacado y lo están haciendo ahora mismo es un hecho. Equipos Rojos de ataque y Equipos Azules de defensa son fundamentales en los ejércitos de los principales países que deben ocuparse de proteger la tierra, el mar, el aire, el espacio y el ciberespacio de su patria.

Figura 1: China está lista para admitir que tiene un Ciberejercito

Una de las naciones que primero contó con un ciberejercito fue China, o así lo declaraba el informe APT 1 de Mandiant, donde se llegaba a citar la posición exacta en la que se encontraba dentro de la escala militar del Ejercito de Liberación del Pueblo.

Figura 2: La unidad de ciberguerra es la Unidad 61398 dentro del PLA (People Liberation Army)

Cuando aquel informe se hizo público, con el objetivo de conseguir un impacto en los medios de comunicación, en la sensibilidad de la sociedad y, quien sabe si también, en los presupuestos que le podrían caer al Departamento de Defensa Americano, desde China hubo un vídeo de ridiculización del informe que me encantó. La propaganda al servicio del InfoSec para viralizar por las redes una idea ridiculizando el informe, algo que han utilizado los países largo tiempo, incluso los USA como vimos en el hackeo de HBGary. El vídeo pretende mostrar de forma ridícula y humorística que lo que el informe APT 1 de Mandiant dice no tiene ningún sentido. ¿Cómo iban a reclutar a jóvenes fumadores gamers para meterlos en el ejercito Chino? 

Figura 3: Vídeo de InfoSec poniendo en duda el informe APT1 de Mandiant

Hoy ya, según plantea un libro que va a ser publicado por un investigador del Center for Intelligence Research and Analysis, parece ser que China ha admitido en varios documentos que tiene capacidad militar operativa en el ciberespacio, con grupos dentro del ejercito militar, grupos dentro de las fuerzas civiles y organizaciones terceras que colaboran en caso de necesidad.

Figura 4: China revela información de su ciberejercito

Después de que se pasaran años negándolo, parece que ya no tiene mucho sentido negar lo evidente, y menos después de que Edward Snowden desvistiera las operaciones de espionaje de su gran oponente por la supremacía mundial hoy en día. Hora de quitarse las máscaras, comienza una nueva fiesta.

Saludos Malignos!

Google tira las apps de JSSMSers: Bórralas de tu Android

Esta semana pasada, utilizando Tacyt localizamos otro grupo de apps maliciosas subidas en Google Play para que se instalen sistemas operativos Android que habría subido la misma empresa que está detrás de las estafas de la linterna molona y los JSDialers. En este caso, de nuevo usando un esquema de generación de dinero mediante la suscripción automática de las víctimas a servicios de SMS Premium. El truco es el de siempre, te instalas la app que te avisa de que te va a suscribir a un servicio de SMS Premium y sin que hagas nada más quedas suscrito.

Figura 1: Google ha tirado las apps de la red JSSMSers, bórralas de tu Android

Para ello utiliza los permisos sobre los servicios SMS que solicita durante el proceso de instalación para realizar de forma silenciosa todo el proceso de alta del usuario en el servicio de SMS Premium.

Figura 2: Permisos de SMS que solicita la app en su instalación

En esta ocasión, a diferencia de otras apps anteriores, algunas muestran el botón de suscribir, por lo que el usuario es mucho más consciente de que se van a producir cargos - además de que Android avisa de que los permisos para enviar SMS pueden suponer cargos extras -.

Figura 3: A la derecha la imagen de suscripción que verá el usuario en esta app

Todas ellas, han sido eliminadas entre ayer y hoy, pero si la tienes o la has tenido instalada, debes cancelar la suscripción en primer lugar - si no te vendrán cargos en la factura de teléfono - y eliminar las apps después.

Figura 4: Apps pertenecientes a esta estafa de JSSMSers

Como se puede ver, la lista es de 14 apps y algunas se subieron de forma rápida, con nombres de paquetes en inglés con fallos de escritura y con descripciones cortas, pero con contenido en Español.

Figura 5: Más apps de JSSMSers

Entre las sigularidades de estas apps, aparecen ficheros reutilizados de la estafa de JSDialers y además las fechas coinciden, así que parece que estos tipos están constantemente fabricando este tipo de apps. 

Figura 6: El resto de las apps mostradas en Tacyt junto con una de JSDialers

Esperemos que los servicios de revisión manual que Google Play dice haber lanzado desde este mes de Enero empiecen a filtrar este tipo de apps, para que las apps que se encuentren los usuarios sean de calidad y no este tipo de negocios greyware del mundo del fraude online que solo perjudican a la imagen de Google y al usuario.

Saludos Malignos!

Acta de Navegación NO certifica el contenido de una web

Recientemente un abogado, me preguntaba, cómo podría certificar los contenidos de una web, por lo visto, uno de sus clientes estaba siendo mancillado en un blog y quería adjuntar a la querella una evidencia digital que diera solidez a la demanda. Se estuvo planteando la idea de contratar un notario y que levantase un acta notarial de las injurias ya que el blog se actualizaba con bastante periodicidad. Fue así como, buscando los dos por Internet, dimos con el servicio de Colorirus "Acta de Navegación". ¿Servirá este servicio para certificar los contenidos de una web.

Figura 1: Acta de Navegación NO certifica el contenido de una web

A primera vista, según anuncia la propia web, este servicio sirve para garantizar la navegación por Internet desde un equipo a una hora en concreto mediante sellado de tiempo. Es decir, la navegación que se ve desde un equipo, y para nada que en un determinado servidor haya un determinado contenido.

Figura 2: Descripción del servicio de Acta de Navegación

Esto, para algunos, puede querer significar que se está certificando que lo que se graba es lo que hay en los servidores, pero nada más lejos de la realidad. Solo se graba que desde un equipo se comenzó una navegación a una hora concreta y que se terminó a otra hora, viéndose desde el equipo algo.

Figura 3: Dice valer como acta notarial, pero demuestra que el contenido que ves es el que hay

Con el objeto de demostrarme a mí mismo y al abogado que me solicitaba un servicio para certificar webs, que esta no es una solución hecha para esto, decidí probarme fehacientemente que sí sería posible alterar el contenido de la navegación, y certificar una navegación manipulada. Nada sería más desastroso que llevar un acta de navegación al mundo judicial y que luego un perito le sacase los colores impugnando, y con razón, la prueba que sustenta la demanda al demostrar que se pueden conseguir actas de navegación con este servicio alteradas - tal y como ya había hecho con el servicio de las fotografías con certificación de ubicación GPS en el pasado -.

Demostración de que Acta Notarial certifica lo que ves, no lo que hay

En una primera prueba de concepto, quise comprobar si sería posible certificar un contenido alterado, así que se me ocurrió hacer una prueba sencilla, y modificar mi archivos "hosts" de resolución de nombres de dominios, para redirigir el tráfico de, por ejemplo, la página del PP www.pp.es a sus amigos de Podemos www.podemos.info y ver qué pasaba. Grabé la prueba que podéis ver en el siguiente video:

Figura 4: Demostración con Acta de Navegación 1

Efectivamente, como habéis podido comprobar, tengo un certificado de navegación que garantiza que he navegado a unas determinadas horas, pero el contenido que se ve no tiene por qué estar de verdad en la web tal y como se ve en el vídeo certificado. El problema real es que alguien piense, al comprar esta solución, que esto sirve para certificar de alguna forma el contenido que hay en una web. Nada más lejos de la realidad como se puede ver.

Para que si a alguien le queda alguna dura de que esto no sirve para certificar de ninguna manera el contenido de una web, decidí dar un paso más y certificar algo más arriesgado y maligno. ¿Que tal tiendas online, con una modificación "on the fly" de los precios? Para esta segunda prueba, he usado BurpSuite gracias a una idea que me dio un amigo y su opción de "match and replace", para modificar los precios, y hacer que los productos sean un poco más asequibles.

Figura 5:  Demostración con Acta de Navegación 2

Si realmente "Acta de Navegación" ofreciera cualquier tipo de validez jurídica con respecto al contenido, acabaría de meter en un buen lío a El Corte Inglés y Mediamark, pero no es así. El sistema solo certifica que una navegación hecha desde un equipo veía a unas horas esas cosas, pero eso no demuestra que el sitio tuviera ese contenido, así que nunca en un juzgado debería ser tomada como prueba de que había un contenido cualquiera en una web. Cualquier perito forense que se precie tiraría esa prueba si se presentase como prueba en un caso.

Conclusiónes a tener en cuenta

Acta de Navegación, parte de un error grave de concepto si en algún momento hubiera pretendido ser un servicio que certificara el contenido de una servidor web. Podría servir para certificar lo que ve una máquina en un instante de tiempo, pero este resultado podría diferir entre la realidad por uso fraudulento del sistema - como se ha hecho en este caso -, por culpa de un ataque de malware que hiciera un man in the browser o de un atacante que manipule las conexiones de la red, por cualquiera de los múltiples ataques de red en IPv4 o IPv6.

Si vas a un juicio y quieres certificar que una web hay un determinado contenido, este no es el servicio de certificación de contenido en web que esperas. Hay otras soluciones que se basan en terceros de confianza que verifican el contenido de un servidor conectándose ellos mismos,  y no dejando que sea el cliente el que se conecte.

Autor: J.A.Esteban
Twitter: @Erratum_

Google, un Operador Dominante que "ha hecho un daño real a usuarios e innovación"

La agresividad y la competencia que tienen las grandes empresas tecnológicas es mítica. Como las moléculas luchando por los átomos se atacan y se defienden empleando al máximo posible sus recursos. Estos pueden ser tecnologícos, proponiendo cada día nuevos servicios y productos que consoliden su posición, económicos, fagocitando cualquier empresa tecnológica de buen ver o con una propuesta de innovación distinta, y políticos, aprovechando cualquier escenario posible para hacer lobby.

Figura 1: Google ha hecho un daño real a los usuarios y la innovación

Cuenta la historia que cuando Mark Zuckerberg adquirió uno de los edificios de la antigua Sun Microsystems para poner un cuartel de su Facebook, no quitó el logo y solo le dio la vuelta para que nadie se olvide de que mañana otro puede llegar y poner su logo ahí.

Figura 2: El logo de Sun Microsystems oculto tras el de Facebook

Google no es menos que los demás, y aprovecha sus armas igual que los demás. Igual que Microsoft, igual que Apple, igual que Facebook. Esa guerra brutal es la que lleva a que los servicios de valor sean cada vez menos interoperables, y a que cada uno de los grandes esté viendo cómo montar su jardín privado donde cultivar sus beneficios, con dispositivos, clientes de Internet y servicios en la red que permita crear un círculo virtuoso de generación de beneficios. Así es la ley de los nuevos negocios sostenibles a largo plazo.

Google y la competitividad

Centrándonos en caso de Google, la compañía lleva años peleando por crecer utilizando estrategias curiosas, antaño no esperadas por los expectantes admiradores de la compañía "que era solo un buscador sin publicidad ni más distracciones en los resultados", que se resumieron en el famoso Google, don´t be Evil de la compañía, que hubo que acabar por ocultar.

Su negocio, aunque han crecido mucho en otros sectores, siguen siendo los ads. La publicidad que ponen en todos los medios que les es posible. Ads en el buscador, ads en el correo electrónico, ads en los blogs, ads en los vídeos de Youtube, ads en las apps de Android, ads en las apps de gestionar ads. Poner anuncios sobre todo lo que sea posible, para lo cual necesitan controlar los grandes nichos de publicación de contenido donde poner los ads. Es decir, de nada te serviría poner muchos ads si nadie va a visitarlos, y nadie irá a visitarlos si no hay buen contenido ... o alguien los re-dirige allí.

En el caso de los contenidos, Google comenzó a generar sus propios sistemas de contenidos para controlar que en ellos no se pusiera otra publicidad que no fuera la suya. Por ello lanzó Gmail, al que seguirían proyectos como Google Maps, Google Earth, o la adquisición de Youtube, para controlar el mercado de los vídeos en Internet y tener una buena posición en el mercado de los contenidos a la carta servidos con ads, aunque estos ads se pongan sobre películas subidas ilegalmente que estén alimentando a los piratas a hacerlo más y haciendo daño a los creadores de contenido - que más da, son ads -. 

Figura 3: Ads en copias piratas de películas subidas en youtube 

Otros temas más polémicos de "adquisición" de contenido para controlar datos y hábitos fueron el caso de los Orphan Books, que al final consiguieron sacar adelante gracias a trabajo de lobby, y Google News - que les acabaría generando problemas con los medios de publicación a los que atajaría el presidente Barack Obama hablando de "Neutralidad en la red" la misma semana que sucedió todo -. En este último caso no ponían adds, pero sí que generan tendencias y podrían - y está por ver si lo hacían o no según el último informe de la FTC - dirigir el tráfico hacia medios que usaran sus ads y no los de otros.  Sí, a Google le preocupa muy mucho qué ads tiene tu sitio, por eso cuando navegas con el User-Agent del Bot de Google en un sitio, procura no servir ads de sus plataformas para no perder dinero pagando a otros. 

Con la irrupción del mundo de los blogs, también adquirieron las plataformas donde se gestionaba el contenido, como el caso de Blogger y Feedburner, y potenciaron el famoso Google Reader, un gestor de feeds RSS que a todos nos encantaba, pero que decidieron sacrificar en pro de intentar coger la ola de los ads en las redes sociales que ya tantas veces se le ha escapado. Se les adelantó en las plataformas de mensajería primero Microsoft Messenger, luego Skype con la vídeoconferencia, luego Facebook con las redes sociales, luego WhtasApp en el mundo del móvil, y ellos no consiguieron estar ahí ni con GTalk, ni con Orkut, ni con el actual Google+ que la gente utiliza muy poco y solo como forma de garantizar que el buscador de Google dé un mejor trato al contenido que se publica en esas redes.

La guerra por el navegador: Batalla en el subcomité ECMA T39

Poner los ads y que otros no te lo pongan, esa es la clave. Para ello, hay que cerrar el camino entre el usuario que ve ads y los ads que sirve la compañía sin que nadie te intermedie en el futuro. Con ese objeto lanzaron su navegador Google Chrome, justo después de que impulsaran un cambio en el estándar de ECMA Script que hizo saltar la banca por los aires y generar un conflicto que duro años e hizo la vida de todos los programadores web mucho más complicada.

Ellos apostaron por impulsar una versión de ECMA Script que NO era compatible hacia atrás 100% con todas las aplicaciones de Internet que se habían creado ya mientras que Yahoo! y Microsoft apostaron por diseñar ECMA Script 3.1 (que sería cerrado en 2009) para dar compatibilidad hacia atrás de forma estable. Durante años los desarrolladores tuvieron que hacer una página web para Internet Explorer - ECMA Script 3.0 - y otra para Google Chrome que apostó por la versión previa de ECMA Script 5.0 - ya que ECMA Script 4.0  estaba denostada - sin que entendieran muy bien por qué pasaba esto.

Lógicamente, todo esto se fraguó meses antes de que Google anunciara Google Chrome (Septiembre de 2008), porque puestos a conseguir usuarios que mejor que obligar a migrar a todo el mundo las aplicaciones web. De hecho, aún sabiendo que Internet Explorer no implementaba ECMA Script 4.0/5.0, los creadores del test ACID3 (Lanzado en Marzo de 2008) - empleados de Google - que estaba basado en ECMA Script 5.0, se empeñaban en lanzarlo sobre Intenter Explorer para señalarlo con el dedo, lo que generó mucha polémica en contra de la compañía. Con Internet Explorer 9 e Internet Explorer 10 Microsoft decidió implementar ECMA Script 5.0 y más estándares acabados (no en draft) con un modo de compatibilidad hacia atrás en el navegador que permitiera ejecutar aún ECMA Script 3.0 y dar soporte a las aplicaciones. No sería hasta la llegada de HTML 5 y los estándares de ECMA Script 6.0 cuando se cerraría este capítulo de problemas para todos generado por una decisión de competencia.

Hay que tener en cuenta que si un fabricante tenía una app que funcionaba con Internet Explorer no se vería obligado a migrar su aplicación a los nuevos estándares, lo que haría que no se pudiera usar un nuevo navegador. Si se forzaba el cambio, se podría introducir el nuevo navegador, aprovechando el cambio - y más cuando Google Chrome ya estaba cuasi preparado para salir cuando se debatía todo esto-

La guerra por el navegador: Elección de navegador pero no de Proxy

En este capítulo por la lucha y la supervivencia, vimos como el lobby de Google consiguió ganar otra batalla a Microsoft. Consiguió que en el sistema operativo Windows se obligara a elegir qué navegador se quiere utilizar por defecto, haciendo que la compañía de Redmond tuviera que lanzar una alerta a todos sus usuarios con un selector de navegador por defecto.

Figura 4: El banner que tuvo que poner Microsoft en todos los Windows

Me gustaría ver a Google hoy en día haciendo algo similar en Android, o dejando seleccionar con un cuadro de dialogo al inicio qué buscador se quiere configurar por defecto. No, eso no va a pasar. Para que os hagáis una idea, con la llegada de HTTP 2.0 (basado en SPDY), Google no pretende dar a elegir para nada cuál debe ser el proxy que se llevará el tráfico no cifrado, lo que hace que si tú te conectas desde tu casa a la web de tu empresa y no lleva HTTPs y está en tu misma ciudad, todo el tráfico desde Google Chrome vaya directamente a los servidores Proxy de Google (ahora en USA) y luego al servidor de tu empresa. ¿Podrá elegir el usuario el servidor Proxy al que se enviará? Por ahora no y parece que será así.

Figura 5:  Funcionamiento de SPDY (y HTTP 2.0)

Batalla en el dispositivo: Android, Google Play y el Wardriving

En el mundo de los sistemas operativos móviles, de iOS es el que se lleva el dinero mientras Android se lleva el grueso de los usuarios, ha estado utilizando una estrategia de dejar que se suban apps de cualquier tipo - solo con el objeto de conseguir números de apps similares a las de iOS - pero la calidad de las mismas dista de ser ni parecida y los controles automáticos son saltados día sí y día también por gente que quiere hacer negocio con viejos esquemas de fraude online como los dialers, las suscripciones a mensajes SMS Premium, los clics en la publicidad o las botnets en Google Play. Ahora han anunciado que desde este año revisan manualmente las apps para que lleguen apps de calidad a los usuarios. Yo os dejo esta aquí para no comentar mucho más sobre el tema de la calidad de las apps.

Figura 6: App publicada en Google Play sobre cómo descargar WhatsApp gratis

En el orden de polémicas con la justicia, más allá de las peleas con la competencia, hay que recordar el caso del Google Car haciendo Wardriving y llevándose los datos de las redes WiFi. En ese momento lo que trataba la compañía era de tener un mapa de redes WiFi para poder usarlos en proyectos de triangulación y posicionamiento. Luego se darían cuenta de que no tenía sentido usar el coche como Wardriver cuando podían utilizar directamente el sistema operativo Android - tal y como hace también iOS de Apple - para llevarse toda esa información y saber dónde estás solo por las redes WiFi que ves. El caso del Google Car le generó registros en sus oficinas y demandas en países como España que al final se saldaron con poco ruido.

Google y el Espionaje publicitario saltándose estándares

Otro incidente que sí que afectó directamente a su línea de negocio fue el escándalo destapado por el Wall Street Journal en el que se demostraba que Google estaba saltándose los estándares de Do not Track en los navegadores con el fin último de poder entregar a las empresas de publicidad que contratan sus servicios de ads datos de navegación cruzada. Es decir, para poder pasarle a una empresa los datos de por donde ha navegado un usuario a través de los ads que le ha ido sirviendo. Esto le costó un denuncia y un multa ínfima, comparada con los réditos económicos que le sacaría a la venta de esa información a las empresas. Ads con tus datos y con tu información de navegación. 

Figura 7: El escándalo de Google saltándose Do not Track destapado por el Wall Street Journal

Google y la manipulación de resultados

La lista de casos es larga, pero el que ahora nos ocupa es de supina importancia, ya que el operador que recibe más del 90% de las búsquedas en Internet (Google, Youtube, Android, Google Now, Maps, etcétera) en muchos países, ha podido estar manipulando los resultados para mejorar sus servicios. Así lo piensan los miembros de la FTC (Federal Trade Commission) tras 19 meses de análisis y deliberaciones. Según documentos publicados por el Wall Street Journal, Google podría haber estado posicionando mejor en los resultados sus servicios, por encima de otros con mejor información, mejores datos o más ajustados a los objetivos de los usuarios, dañando a los usuarios, a la libre competencia y a la innovación.

Figura 8: Google ha hecho "daño real a los usuarios y la innovación"

Es decir, que Google, bajo supuestos cambios en su algoritmo y supuestas características, habría hecho que sus servicios estuvieran mejor situados para competir aprovechando su posición dominante en las búsquedas. Algunas casos, como los de Yelp o TripAvisor especialmente, donde Google ha estado copiando críticas de usuarios sobre hoteles y restaurantes para alimentar su propia base de datos - copiando contenido para mejorar su sistema.  Lo que debería hacer la compañía es tratar su enlaces de sus servicios como ads y no como resultados si no están bien situados.

Neutralidad en la red

Al final, esto se saldará con una denuncia y a otra cosa, porque tampoco vamos a rompernos las vestiduras con estas cosas, pero lo que sí que es cierto es que empecemos a entender que una empresa que tiene más del 90% de las búsquedas en Internet en muchos países, que se ha convertido en la puerta de entrada a la red de muchos usuarios, tiene que empezar a ser tratado como lo que es, como un Operador Dominante. La falta de transparencia hace que, como muchos sospechan, el gobierno de USA y la NSA pudieran llegar a manipular - con un ligero cambio en el algoritmo - qué noticias de un determinado tema salen antes en los resultados, las de un medio con una línea editorial cercana a un partido político o las de un medio con una línea editorial cercana a otro partido político. 

Figura 9: Google dio beneficios este año (antes es que estabamos en crisis y no podían ayudar)

Si estamos a favor de la neutralidad en la red, tenemos que estarlo a favor en todo su significado. Si a Microsoft se le hace sacar una versión de su Windows sin Media Player para permitir la competencia, un operador que gestiona el 90 % de las búsquedas y el 90 % de los ads de la mayoría de los países es un operador dominante que no tiene competencia, y por tanto debe ser tratado como tal. Sí, sabemos que la pobre Google no va bien económicamente y que a pesar de que en España controla las búsquedas y los ads, la pobre compañía solo ha pagado impuesto de beneficios este año (1.75 M€) porque los otros tres años atrás ha dado pérdidas - menos mal que autónomos y pequeñas empresas les han ayudado los anteriores en España pagando los impuestos solidariamente que parece que la crisis en España afectó mucho a Google, no te preocupes Google, ya irá mejor -.

Si una empresa controla el 90% de un servicio, sea cual sea ese servicio debe ser tratarse como tal, ya que en muchos países Europeos, una compañía con el 30 % del mercado puede ser considerado como tal y obligado a muchas cosas.

Saludos Malignos!