Algunos ejemplos y defensas contra el clickjacking

martes, 29 de octubre de 2013

El clickjacking fue descubierto por Jeremiah Grossman y Robert Hansen en 2008. También se le conoce como UI redressing. El concepto es sencillo, y las técnicas para conseguirlo no son difíciles de implementar. Se podría decir que la técnica se basa en un fallo de diseño de HTML y por tanto toda web es "vulnerable" por defecto. Las soluciones hasta ahora son en realidad "parches" aplicados tanto al protocolo como a los navegadores, que han aparecido para intentar mitigar el problema.
El fin del clickjacking es conseguir que un usuario pulse en un enlace (y realice una acción) sin que lo sepa, o creyendo que lo hace en otro enlace con otro fin, con todas las consecuencias que eso puede acarrear. Puede ser un enlace de votación (que vote a alguien que no desea), seguir a alguien en Twitter, un "Me gusta" de Facebook... El atacante "disfraza" un enlace no deseado, volviéndolo atractivo para la víctima. Para conseguirlo, se basa en el juego de capas que se puede conseguir con HTML e "iframe". Iframe es una (anticuada en cierta forma) técnica para cargar una web dentro de otra. Clickjacking está basado normalmente en el iframe.

Para una explicación de cómo realizar este ataque, se debe entender el funcionamiento por capas intrínseco al HTML. Una web maliciosa (roja, en la figura) debe cargar una web legítima (gris) delante pero , de forma transparente (con opacidad cero). La web roja consistirá en un mensaje atractivo, en el que el usuario desee pinchar. La web legítima será la "víctima" en el sentido de que el usuario realmente pulsará sobre ella sin quererlo. Además, será víctima del ataque porque permite que se "abuse" de ella (veremos cómo evitarlo). Si se posiciona correctamente un enlace sobre otro, y se cuadran las capas, el efecto puede ser el del "secuestro" del clic del ratón.



Para preparar la página maliciosa, el atacante debe contar con dos componentes básicos:
  • Un iframe a cualquier otra página, que en este caso será la "víctima", o en rigor, la página que será finalmente pulsada, sin que lo sepa el usuario.
  • Este iframe debe servirse desde la página maliciosa aplicando un estilo concreto que permita que sea transparente y quede posicionada por delante, en el punto correcto. Por ejemplo
El "style" definirá el ataque.
  • opacity:0. Vuelve transparente al elemento. Su valor va de 1 (totalmente opaco) a 0, transparente e invisible.
  • position: El elemento se coloca en relación a su primera posición (no estática) elemento antecesor.
  • top:0px;left:0px;width:99%;height:95%;margin:0px;padding:0px. Estos parámetros permiten tomar todo el ancho de una página y que se acople a sus márgenes para que la cubra totalmente
  • z-index:1. Permite que se posicione por delante/encima de cualquier otro elemento. Si este número se incrementa (puede valer 100, por ejemplo), se posicionará delante de todo lo que tenga un z-index menor. Si el número es negativo, se posicionará por detrás.
El ataque completo, podría ser algo así:

Y cuando el usuario crea pulsar sobre un enlace muy atractivo o conveniente para él, en realidad puede que esté realizando una transferencia, por ejemplo.
Una ventaja de esta técnica que la diferencia del CRSF (cross site request forgery), es que con ella se sigue disponiendo del token válido en el caso de páginas que necesiten sesión, y si el usuario está presentado en la web "víctima", lo hará con el mismo token y como si realmente la acción se hubiera realizado desde la página original.
Pero se puede ir más allá. El problema inicial se definió en 2008 con este vídeo, en el que se presentaba un ejemplo en el que la víctima activaba inadvertidamente su cámara web al presionar botones en la propia página de Adobe.


Un ejemplo concreto

Imaginemos un sistema de votación muy sencillo, alojado en un dominio culaquiera, en la web vulnerable.php.

El atacante utiliza test.html, que carga mediante un iframe la página vulnerable.php de forma transparente con opacidad 0. La carga "por delante" de test.htm, pero al ser transparente, el usuario solo visualiza el contenido de test.html. En ella propone votar a otra web cualquiera, por ejemplo elladodelmal.com. Este es el reclamo. Pero el usuario que pulse sobre el botón, realmente estará votando a elevenpaths.com.


La última secuencia muestra una imagen de la aplicación test.htm con opacidad 1, lo que significa que se puede ver la aplicación vulnerable.php y test.php claramente una sobre la otra.

Evitar el ataque: en un sitio web
¿Qué puede hacer una página para que no sea utilizada como víctima del clickjacking? No puede hacer mucho más que evitar que se cargue ella misma dentro de un iframe. Así ningún atacante podrá ponerla "invisible" y sobre otra que el propio atacante ha creado. Una de las soluciones "antiguas" era la de evitar con JavaScript que una página no estuviera siempre en el "top".

Se debería incluir este código en cada página. Pero estas técnicas podían, a su vez, ser evitadas por el atacante.
Como solución más práctica, se ideó añadir al protocolo HTTP una cabecera llamada X-Frame-Options. Las páginas que envíen estas cabeceras al navegador, pretenden protegerse de aparecer en un iframe. Se propusieron varios métodos más o menos flexibles para intentar ayudar a las que legítimamente necesitaran incluirse dentro de un iframe. Sus valores son:
  • DENY, el navegador evita que la página sea renderizada si está contenida dentro de un iframe
  • SAMEORIGIN, la página solo puede ser mostrara en un frame que provenga del mismo origen que la propia página.
  • ALLOW-FROM uri, el navegador bloqueará la renderización sólo si el origen de nivel superior está en un contexto de navegación que es diferente al valor uri proporcionado en la directiva 
Los usuarios deben confiar en que las páginas las envíen, y que su navegador las interprete correctamente. Esto último hace tiempo que ya lo implementan la mayoría. Por ejemplo, Chrome desde su versión 4.1.249.1042, Firefox desde 3.6.9, Internet Explorer desde la 8, Opera desde la 10.5...
Evitar el ataque: desde el cliente
Pero aunque la mayoría de páginas  ya se aprovechan de estas cabeceras, ¿qué pasa con las que no? El usuario debe protegerse. Ciertos antivirus detectan en el navegador comportamientos "extraños" de este tipo, y les han asignado firmas. Por ejemplo Avira, lo detecta como  HTML/Infected.WebPage.Gen2. 

Otro método para protegerse es utilizar la funcionalidad "clearclick" del conocido plugin NoScript, que ofrecerá protección al usuario para FireFox.

Ejemplos de alertas sobre ClickJacking. Fuente: http://blogs.computerworld.com/sites/default/themes/cw_blogs/cache/files/u91/noscript_clickjack.jpg 

Fuente: http://hackademix.net/2008/10/08/hello-clearclick-goodbye-clickjacking/


Ricardo Martín Rodríguez
ricardo.martin@11paths.com

Fake WhatsApp (adware) in Google Play

viernes, 25 de octubre de 2013

During yesterday and even today, an almost exact copy of WhatsApp appeared in Google Play that is, actually, simple adware. There are thousands of malicious programs in Google Play, created daily... but this case is a little special for several reasons.

There is a lot of malware in Google Play, adware and all kinds of surprises. That is not breaking news. "Open doors" policy and apps that do not need to be digitally approved or signed, makes it easy. Few days ago ElevenPaths discovered a copycat of a fake AdBlock Plus that (when Kaspersky published it, crediting us) made some noise. The funny thing of that issue is that AdBlock Plus was "retired" long ago from Google Play because ads is Google's business, and do not like applications to block them. So, an exact copycat of this application in its market was very attractive for the user... and the attackers.

Same with WhatsApp. Is one of the most used and downloaded apps in Spain, and many other countries, used by more than 10 million people, just in Spain in 2011, and hundreds of millions of accumulated downloads.

We would like to clear up the different kinds of malware that can be (permanent or ephemerally) hosted in Google Play:
  • Malware and spy apps. Without copying any apps, they are simple tracking and spying systems. For users that directly want to trojanize someone.
  • Apps that "look" like others, but they aren't really. They try to confuse the user.
  • Apps that look like others, they really work like the originals, but aside they include adware. Attackers "repack" the original adding malware just as the "classic" trojan programs did long ago.
  • Apps that, in Google Play are presented as exact copies of some others (excluding the vendor name) but are just malware, they do not have any real functionality. This would be "fake apps" that we are talking about.
These last ones are the most interesting, because it's where the user may be fooled more easily. Only by knowing the real vendor name (that you don't always know), paying attention to the number of downloads and stars (that even the attackers try to raise), date of the program... and being very careful may prevent the user from falling victim of malware.

In this case, as we already stated, there are many Google Play fake apps. But since a few months, a certain team of attackers are focusing in WhatsApp as a fake app. We have researched a bit and have some indications about these attackers being from the Chinese Shandong province, and are making the same model of attack since a few months ago (we will go on investigating, since there is another group of attackers that use WhatsApp as a decoy as well). Since today, they didn't "dare" to create an almost identical copy, not with the same name or icon. These are just some examples of what they have been doing since the last month. You can tell that sometimes they have used the old icon and sometimes they have added some element to the current one... and the name was always different in some way.







 But the one used as a fake app today is:


And the original one:

That makes them different just because of the background transparency (that we guess it has been the attacker's carelessness). The fake App is less than 300 kilobytes, and the original one is 11 megabytes. It is not detected by any antivirus engine (because it does not contain code recognized by adaware, and does not abuse of permissions), and its only functionality is to send intrusive ads to the user once installed, is has no useful functionality even remotely related with the app it's trying to fake. As a funny note, it needs less permissions than the original app:
  • complete access to network
  • see network connections
  • check identity and state of the telephone
  • modify or remove content from USB storage
  • install shortcuts
  • access to USB storage filesystem
  • try access to protected storage
Why do they sometimes resemble more to the original one and sometimes less? Because the more they look similar, the riskier it getsGoogle Play will remove them sooner. When the name or icon are not exactly the same, the fake app can make it longer in the market. It's a trade off between effectiveness and "attack duration".


Sergio de los Santos
ssantos@11paths.com

WhatsApp falso (adware) en Google Play

jueves, 24 de octubre de 2013

Durante el día de ayer y hoy ha aparecido una réplica casi exacta de Whatsapp en Google Play que se trata en realidad, de adware. Existen miles de programas maliciosos en Google Play, y aparecen nuevos a diario... pero este caso es un poco especial por varias razones.

En Google Play pulula mucho malware, adware y todo tipo de sorpresas. No es novedad. Su política de "puertas abiertas" y no necesitar firmar las aplicaciones, lo facilita. Hace un tiempo descubrimos en ElevenPaths una réplica de AdBlock Plus falso, que (cuando la noticia la publicó Kaspersky, con los créditos correspondientes) hizo bastante ruido. Lo curioso de aquel caso era que AdBlock Plus fue "expulsada" hace mucho de Google Play porque Google "vive" de la publicidad, y no desea aplicaciones que la bloqueen. Por tanto, una réplica exacta de esta aplicación en su market resultaba muy atractiva para el usuario... y para los atacantes.

Lo mismo ocurre con WhatsApp. Una de las apps más usada y descargada en España y muchos otros países, utilizada por más de 10 millones de personas solo en España ya en 2011 y cientos de millones de descargas acumuladas.

Aclarar antes de nada las "categorías" de malware que se pueden encontrar (permanente o efímeramente) en Google Play:
  • Malware y aplicaciones espía. Sin intentar imitar a nadie, son realmente sistemas de rastreo, espía, etc. Pensadas para usuarios que deseen directamente espiar/troyanizar a alguien.
  • Programas que "parecen" otros, pero no lo son realmente. Intentan confundir al usuario.
  • Programas que parecen otros, lo son e incluso puede que funcionen, pero además incluyen adware. Los atacantes reempaquetan el original al más puro estilo de los troyanos clásicos.
  • Programas que, en Google Play son presentados como réplicas exactas de otros (excepto en el nombre del fabricante) pero que son simplemente adware, no contienen la funcionalidad. Serían las "fake apps" de las que estamos hablando.
Estos últimos son los más "interesantes", porque es donde el usuario puede ser engañado con mayor facilidad. Solo conocer el nombre del fabricante real (que no siempre se sabe), fijarse en el número de descargas y estrellas (que los atacantes se encargan de engordar), la fecha... y estar muy atentos en general, pueden prevenir a la potencial víctima.

En este caso, y como hemos comentado, aplicaciones falsas en Google Play hay demasiadas. Pero desde hace unos meses, un cierto equipo de atacantes se está centrando en WhatsApp como fake app. Hemos investigado y al menos disponemos de varios indicios de que se trata de un grupo chino de la provincia de Shandong que lleva varios meses con el mismo modelo de ataque (seguiremos investigando, puesto que hay otro grupo que también utiliza Whatsapp como reclamo). Hasta hoy, no se había "atrevido" a crear una réplica exacta, ni con el nombre ni con el icono. Estos son solo algunos ejemplos de lo que han venido haciendo durante el último mes. Se aprecia que en ocasiones han usado el antiguo icono de la app y en otras complementado el actual... y siempre han variado en cierta forma el nombre.







 Pero la utilizada como fake app hoy es:


La original:

Y solo las diferencia la transparencia del fondo de imagen (que suponemos un descuido del atacante). La aplicación falsa pesa menos de 300 kilobytes, frente a los 11 megas de la original. No es detectada por ningún motor antivirus (porque no contiene código reconocible como adware, ni abusa de los permisos), y su única función es enviar publicidad invasiva al usuario cuando se instala, en ningún momento contiene funcionalidad útil del programa que suplanta. Curiosamente, necesita incluso menos permisos que la original.
  • acceso completo a red
  • ver conexiones de red
  • consultar la identidad y el estado del teléfono
  • modificar o eliminar contenido del almacenamiento USB
  • instalar accesos directos
  • acceder a sistema archivos de almacenamiento USB
  • probar acceso a almacenamiento protegido
¿Por qué a veces se parecen más a la original y a veces menos? Porque cuanto más se parezca, más arriesgada la operación. Google Play los retirará antes. Cuando no usan exactamente el mismo nombre o imagen, la aplicación falsa puede perdurar más en el market. Es un caso de sacrificio entre efectividad y "duración" del ataque.


Sergio de los Santos
ssantos@11paths.com

So is it true that malware for Firefox OS has been found?

The power of a good headline is hypnotic. The one taking a lot of security news during these days is the "Found first malware for Firefox OS". The title is attractive, but, is it right? Reading the news invites to think about what has really happened, what is this "discovering" about, and why we haven't overcame still so many myths.

Firefox OS is a recent operative system based on web. All its programs are web based, created using JavaScript, CSS3 and HTML5. This implies that applications may be distributed in two ways: in a zip that contains it all, or via an URL that hosts it and is later visited.


A 17 years old by has developed a malware proof of concept for Firefox OS. He will be presenting its research in a convention in November. He states that his application allows to perform some potentially unwanted remote tasks over the device, and that is able to control it sending remote commands.

First of all, security model


According to Firefox OS security model"uses a defense-in-depth security strategy to protect the mobile phone from intrusive or malicious applications. This strategy employs a variety of mechanisms, including implicit permission levels based on an app trust model, sandboxed execution at run time, API-only access to the underlying mobile phone hardware, a robust permissions model, and secure installation and update processes". So far (except the way hardware is accessed), nothing that any other operative system doesn't implement (and nothing that really may stop "infections").

https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Security/Security_model

Something that, in some way, may make a difference in Firefox OS, is how it classifies permissions in apps. There will be three different kinds:
  • Certified: the ones installed by the vendor and critical functionality (telephone, SMS, bluetooth, clock, camera...). They will be able to access any API. For example, only certified apps (the ones coming with the device) will be able to make phone calls.
  • Privileged: The ones reviewed, approved and digitally signed by an authorized marketplace. They will have access to a subset of APIs accessible to certified ones.
  • Untrusted: The other ones that will not be in a market. These will have only access to a subset of APIs that may not make any harm.
Let's see now what can be deduced from the announce of the program created by Shantanu Gawde.


Differenciate between the "what" and the "how"

A teenager has created an application that makes unwanted actions on the system. He talks literally about "infecting" and "control like a botnet". About sending commands to access SD card, about "spooking the user remotely controlling FM radio", "upload and download multimedia files". It seems to be able to control certain device apps, but we do not know how far it may go.



Official description in http://g0s.org/key-focus-areas/
Is this malware? It depends. There will be legit applications that will need to access SD card data, contacts, etc. It will be allowed because the user will trust the vendor or developer. As the Firefox OS security description document states, the model is based on application trust.

What may attract some attention is the state about controlling other apps (he specifically talks about controlling FM radio). Talking about "sending commands" invites to call it "malware", too, though, once the application is installed, it seems quite easy to send commands... so in general, the problem is not so much "what" does this proof of concept do, but "how", how does it get the necessary permissions and how it got to get them. With the information we have, we guess the user launches an application hosted in a server and accomplish some tasks that may be potentially unwanted by the user.

More questions than answers

To get to the real scope of the statement, we should answer these questions.

  • Is this program able to bypass some security restriction in Firefox OS? This would include elevation of privileges, accessing without permissions to privileged API, bypass security dialogs, warnings that could alert the user... any way that implies bypassing, breaking or evading Firefox OS security model. It seems to do that, but it's not clear.
  • Does the malware replicate itself in some way, for example leveraging some vulnerability or design flaw? Does not seem so. If Gawde had found a way to spread a program without human interaction, that would have been breaking and disturbing news. But, with the information we have, it does not seem to be the case.
  • Does the malware hide itself in some way, for example in legit apps? It does not seem so, either. It would have been interesting if a way of launching hidden or embedded apps had been disclosed, just as the first "virus" did. What may be a problem with Firefox OS is, that confusing or obfuscated URLs hiding apps would execute just with a click... and that has been alerted since long ago.
  • Are special circumstances needed for the proof of concept to work? Are just some devices vulnerable?, Does it work with default configuration? Or is is necessary to keep some service, or app working...?
  • Does it use any technique to hide its execution from the user? Something that attracts attention is that the developer itself says "there is no way to detect the attacks or even stop them". In security, such convincing assertions are usually misguided. We suppose he refers to a model where an URL is visited and it results in an app executing that starts, without user interaction, some information exchange between the "victim" and the attacker, that may control the device.
Without these answers (between others), information may be based just on speculation. And the developer should have answered them beforehand in his statement, just like others do, so we can understand (without the need of technical details) how he got it and not describing so much what he got. It should be highlighted that he states that the purpose of the PoC is of course to motivate developers to ensure better security on their platforms rather than providing inspiration to those with malicious intents.

Anyhow, the "malware" or any other in the future will not be exactly a surprise. When execution of uncontrolled applications and alternative "markets" are allowed, abuse is practically guaranteed. Although it's through restricted applications, many of them will not need special permissions to infect with "adware" and show ads, and some other may just find some ways to bypass permissions leveraging vulnerabilities or design flaws.

A Firefox OS spokesman states that possible, Gawde relied on 
developer mode functionality, which is common to most Smartphones but disabled by default. In addition, we believe this demonstration requires the phone to be physically connected to a computer controlled by the attacker, and unlocked by the user. In other words, they think he has "cheated". Of course, they try to downplay the issue because of the lack of information.

So, without any more actual data, the headline should be that a researcher has possibly found a design flaw or a way to bypass some security in Firefox OS, executing privileged remote actions on the device. But we can't be sure yet. What is for sure is that, talking about "malware" confuses the user, that may feel menaced without an actual reason to... yet.



Sergio de los Santos
ssantos@11paths.com

¿De verdad se ha encontrado malware para Firefox OS?

miércoles, 23 de octubre de 2013

El poder de un buen titular es hipnótico. El que copa muchas noticias de seguridad estos días es el "descubrimiento del primer malware para Firefox OS". El título es atractivo, pero ¿es correcto? El desarrollo de la noticia invita a la reflexión sobre qué ha ocurrido exactamente, en qué consiste el "descubrimiento" y por qué todavía no se han superado ciertos mitos.

Firefox OS es un reciente sistema operativo basado en web. Todos sus programas son web, creados a partir de JavaScript, CSS3 y HTML5. Esto implica que las aplicaciones se puede distribuir de dos formas: En un zip que lo contenga todo, o a través de una URL que la aloje y se visite.


Un chico de 17 años ha creado una prueba de concepto de malware para Firefox OS. Presentará sus investigaciones en una convención en noviembre. Dice que su aplicación permite realizar ciertas acciones potencialmente no deseadas sobre el dispositivo de forma remota, controlándolo a través de comandos.


Primero, el modelo de seguridad


Según el modelo de seguridad de Firefox OS "Se basa en una estrategia de seguridad en profundidad para proteger al dispositivo de aplicaciones maliciosas. Se utilizan diferentes mecanismos que incluyen niveles implícitos de permisos basados en un modelo de confianza en la app, sandbox en tiempo de ejecución, acceso a través de APIs al hardware, un sistema de permisos robusto y un sistema de instalación y actualización seguro". Hasta aquí (exceptuando la forma en la que se accede al hardware), nada que no implementen todos (y nada que impida realmente "infecciones").


https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Security/Security_model

Algo que diferencia en cierta forma a Firefox OS es cómo clasifica los permisos de las apps. Las habrá de tres tipos:
  • Certificadas: las que instale el fabricante y las críticas para la funcionalidad básica del teléfono (teléfono, SMS, bluetooth, reloj, cámara...). Tendrán acceso a todas las APIs. Por ejemplo, solo las apps certificadas (que son las que vienen con el dispositivo) podrán acceder a la API de teléfono y realizar llamadas.
  • Privilegiadas: las revisadas, aprobadas y firmadas digitalmente por un market autorizado. Tendrán acceso a un subconjunto de APIs menor que las certificadas.
  • No confiables: El resto, que no estarán en un market. A estas se les deja solo acceso a un subconjunto de APIs que se entiende no entrañan peligro.
Veamos ahora qué es lo que se puede deducir del anuncio del programa creado por  Shantanu Gawde.


Diferenciar entre el qué y el cómo

Un chico ha creado una aplicación que realiza acciones no deseadas en el sistema. Habla literalmente de "infectar" y de "controlar como una botnet". De enviar comandos para acceder a la tarjeta SD, de "asustar al usuario controlando la radio FM", "subir y bajar ficheros multimedia". Da la sensación de poder controlar ciertas aplicaciones del dispositivo, pero no sabemos hasta dónde.



Descripción oficial de la charla en http://g0s.org/key-focus-areas/
¿Es esto malware? Depende. Habrá aplicaciones legítimas que necesiten acceder a datos en la SD, a los contactos, etc. Se les permitirá porque el usuario normalmente confiará en el fabricante/programador. Como bien describe el documento sobre seguridad de Firefox OS, existe un modelo basado en la confianza en la aplicación.

Lo que llama la atención es el control de aplicaciones ajenas (habla de controlar la radio). También invita a llamarlo "malware" que el se hable de "enviar comandos", aunque una vez la aplicación está instalada, parece sencillo enviar comandos... así que en general el problema no es tanto qué haga esa prueba de concepto que se ha creado sino cómo lo hace, cómo llega a disponer de esos permisos o cómo ha conseguido hacerlo. Por lo poco que sabemos, suponemos que el usuario lanza una aplicación alojada en un servidor, y esta realiza ciertas acciones que pueden ser potencialmente no deseadas por el usuario. 


Más preguntas que respuestas

Pero para conocer el verdadero alcance del anuncio, deberíamos responder estas cuestiones.

  • ¿El programa creado es capaz de eludir alguna medida o de seguridad de Firefox OS? Esto incluiría elevar privilegios, acceder sin permiso a APIs privilegiadas, evitar diálogos, advertencias que pudieran prevenir al usuario... cualquier método que implique eludir, romper u obviar un modelo de seguridad de Firefox OS. Parece que sí, pero no queda claro.
  • ¿El malware se replica de alguna forma, por ejemplo aprovechando alguna vulnerabilidad o debilidad de diseño? Parece que no. Si Gawde hubiera encontrado una forma de propagar un programa sin apenas interacción humana, la noticia sería más inquietante. Pero por los datos revelados, no parece el caso.
  • ¿El malware se esconde de alguna forma, por ejemplo en apps legítimas? Tampoco parece el caso. Hubiera sido interesante si se declara una forma de lanzar aplicaciones ocultas o incrustadas en otras, tal como hacían los primeros "virus". A lo que sí se presta Firefox OS fácilmente, es a que URLs confusas u ofuscadas oculten aplicaciones que se lanzan solo con visitarlas... y eso sí es un problema grave del que se lleva alertando desde hace tiempo.
  • ¿Se debe dar alguna circunstancia especial para que funcione la prueba de concepto? ¿Ocurre solo en algunos dispositivos, con la configuración por defecto, o es necesario mantener activo algún servicio, aplicación...?
  • ¿Se abusa de alguna técnica para ocultar su ejecución al usuario? Algo que llama la atención es que el propio descubridor afirma que "no hay forma de detectar los ataques ni de detenerlos". Las afirmaciones tan contundentes en seguridad suelen ser desafortunadas. Entendemos que se refiere a un modelo en el que se visita una URL que resulta una aplicación y comienza, sin interacción por parte del usuario, un intercambio de información entre la "víctima" y un atacante que puede ejercer poder sobre el dispositivo.
Sin estas respuestas (entre otras), la información solo puede basarse en la especulación. Y el creador podría haberlas respondido de antemano en su anuncio, como hacen otros investigadores, para entender (sin necesidad de dar detalles técnicos) cómo lo ha conseguido, sin poner tanto el énfasis en qué efecto ha conseguido. Destacar que ha explicado que su prueba de concepto tiene como fin último "concienciar a desarrolladores" y no "inspirar" a atacantes.

Aunque en realidad, la aparición de "malware" (este u otro) no pillará por sorpresa. En el momento en el que se permite la ejecución de aplicaciones no controladas y "markets" alternativos, su abuso está prácticamente garantizado. Aunque sea a través de aplicaciones restringidas, muchas no necesitarán permisos para infectar con "adware" y mostrar publicidad, y otras puede que encuentren métodos para saltarse los permisos, a través de vulnerabilidades o fallos de diseño.


Un portavoz de Firefox OS afirma que posiblemente, Gawde ha usado el modo desarrollador, desactivado por defecto en el equipo y que incluso piensan que requiere que el dispositivo esté conectado a un ordenador y desbloqueado. En otras palabras, creen que ha hecho "trampa". Lógicamente, su interés es quitar hierro al asunto a falta de más información.


Concluyendo, sin más datos en la mano, el titular debería ser que posiblemente, un investigador ha encontrado un fallo de diseño o una forma de eludir cierta seguridad de Firefox OS, realizando acciones privilegiadas de forma remota. Pero no podemos estar totalmente seguros.  Lo que sí es seguro es que hablar de "malware" confunde al usuario final, que se sentirá amenazado sin motivo aparente... todavía.



Sergio de los Santos
ssantos@11paths.com

How to use Metashield protector for Client and why using it

lunes, 21 de octubre de 2013

Metashield is an Eleven Paths product that allows to clean up metadata from most of office documents. It tries to cover a gap where there seems not to exist any unified solutions to remove all metadata from documents.

Why is it so important to remove metadata?

In 2003 Tony Blair presented a report in the british upper house, received from US intelligence service. It was supposed to be an undeniable proof of the existence of weapons of mass destruction in Irak. The prime minister denied that the document had been manipulated or modified in any way by the British government. Nevertheless the document was released in the government's webpage and metadata revealed a list of certain users that proved that it had been manipulated by British government staff.

On December 2010, a document released as a press notice from AnonOps (Anonymous Operations) showed a name in its metadata. It was the graphical designer Alex Tapanaris, that was put under arrest because of his relation with Anonymous.

A "defacer" that hacked some official United States webpages, published some photos of his girlfriends neckline, mocking with impunity. He forgot to clean up the metadata and his GPS coordinates where found inside the photo. The FBI arrested him.

In December 2013, John McAfee was on the run from the Belize police when declared as a "person of interest" after one of his neighbors was found shot to death. Some journalist showed a photo boasting of being with him. Metadata revealed his exact location. 

How to clean up metadata?

Metashield Protector For client  is a tool to remove metadata in a fast an effective way. It creates a copy of the document, so the original document remains untouched. Eleven Paths has developed this tool for Windows environments, and is able to remove metadata from Office, Open Office, StarOffice, Pdf, Jpg and even iWorks Apple documents. It is enough to spot one or several documents in the computer (or inside of a shared network directory) and remove the metadata with a mouse-click.

This tool allows to select two kinds of "cleaning":
  • Clean keep original files: It generates an exact copy of the document, with no metadata keeping the original one untouched. 
  • Clean Metadata: It removes the metadata from the original file.

The speed of the process depends on the number of selected documents and their size.


The examples mentioned before, show how unknown metadata is, and how metadata can be reached in digital documents by anyone in the net. On the other hand, a metadata-free document implies professionalism, responsibility and dedication from its owner, not disclosing any kind of sensitive information aside from the strictly necessary.

Cómo usar Metashield protector for Client y por qué utilizarlo

Metashield es un producto de Eleven Paths que permite limpiar los metadatos de la gran mayoría de documentos ofimáticos. Intenta cubrir un hueco en el que parecen no existir soluciones unificadas para eliminar todos los metadataos de la mayoría de documentos ofimáticos.

¿Por qué es importante limpiar los metadatos?

En 2003 Tony Blair presentó un informe en la cámara alta del gobierno británico que había sido recibido desde el servicio de inteligencia de los Estados Unidos. Era una prueba irrefutable de que en Irak existían armas de destrucción masiva. El presidente negó qu eel documento hubiera sido manipulado, modificado o tratado de alguna forma por el gobierno británico. Sin embargo se publicó en el sitio web del gobierno y los metadatos revelaron una lista de ediciones realizadas por ciertos usuarios que demostraban que sí había sido manipulado por personal del gobierno británico.

En abril de 2008, el ayuntamiento de Leganés adjudicó unas obras a una empresa a través de un pliego de condiciones y un concurso. Cuando se analizaron los metadatos del documento que recogía las condiciones, se pudo comprobar que el creador pertenecía a la empresa que ganó el concurso. Lo mismo ocurrió en junio de 2011 con un documento con un pliego para Plan de Movilidad del valle de Egüés.

En abril de 2009, desde Security By Default analizaron documentos de la sociedad DAMA, donde trabajaba la entonces ministra de cultura Ángeles González-Sinde. En los documentos se pudo leer que el propietario de las licencias del producto era la SGAE, lo que dejaba entrever la relación entre DAMA y SGAE.

En diciembre de 2010, un documento lanzado como nota de prensa de AnonOps (Anonymous Operations) mostraba en los metadatos un nombre. Se trataba del diseñador gráfico Alex Tapanaris fue detenido por su vinculación con Anonymous.

Un "defacer" de ciertas webs oficiales de Estados Unidos publicó en Facebook una fotografía del escote de su novia, burlándose con impunidad. Olvidó limpiar los metadatos y en la fotografía quedaron las coordenadas GPS de donde se habían tomado. El FBI lo detuvo.

A finales de 2011, se publicó en PDF el programa electoral del PP. El análisis de los metadatos mostraba un título del que se había copiado y que los datos de la persona que había publicado el documento. Un becario de las FAES.

En diciembre de 2012 John McAfee estaba huído de la justicia y siendo buscado por la policía tras ser declara "persona de interés" cuando se encontró a uno de sus vecinos muerto por disparo. Un  periodista alardeó de encontrarse con él y lo demostró con una foto. Los metadatos revelaron su localización exacta.

¿Cómo limpiar los metadatos?

Metashield Protector For client  es una herramienta que elimina los metadatos de forma rápida y efectiva. Crea una copia del documento limpia de metadatos permitiendo mantener intacto el documento original. Eleven Paths ha desarrollado esta herramienta para entornos Windows, y es capaz de eliminar metadatos de documentos Office, Open Office, StarOffice, Pdf, Jpg e incluso de documentos iWorks de Apple. Solo es necesario localizar uno o varios documento en la máquina (o dentro de algún directorio compartido de la red) para realizar con un clic de ratón la operación.

Esta herramienta además permite poder seleccionar qué tipo de limpieza se quiere realizar:
  • Clean keep original files: Generando una copia exacta del documento limpia de metadatos manteniendo el original intacto. 
  • Clean Metadata: Limpiando directamente los metadatos del documento original.

La velocidad del proceso dependerá de la cantidad de archivos seleccionados y su tamaño.


Los ejemplos anteriores, recuerdan que son muchos los que desconocen que existe metadatos en los documentos digitales y que son accesibles a cualquiera en la red. Por otro lado, un documento libre de metadatos indica seriedad, responsabilidad y dedicación por parte de su propietario, al no divulgar ningún tipo de información sensible fuera de lo estrictamente necesario.

DNS poisoning gracias a los sistemas de protección anti-DDoS

jueves, 17 de octubre de 2013

Un método habitual para mitigar los ataques de denegación de servicio distribuido basados en la amplificación DNS, se sustenta en ignorar ciertos mensajes cuando se sospecha que son consultas destinadas a generar un ataque. Pero esta técnica destinada a mitigar los ataques DDoS, pone en riesgo a los servidores que los utilizan, porque facilita a un atacante envenenar la caché de los servidores DNS que la usan. Vamos a explicarlo en detalle.

El protocolo DNS en general siempre ha sido el punto débil en la red. Ataques de spoofing con diferentes técnicas, cachés envenenadas, la vulnerabilidad de Kaminsky (que es un problema de diseño intrínseco al protocolo), los fallos propios y vulnerabilidades de implementación de BIND... Su importancia, sencillas características y falta de seguridad se prestan a todo tipo de abusos. Últimamente el protocolo DNS está siendo usado para realizar ataques DDoS aprovechando la amplificación de tráfico. Pero en ciertos casos, parece que el remedio aplicado es peor que la enfermedad, porque facilita el envenenamiento de caché. Así lo han demostrado Florian Maury y Mathieu Feuillet en su investigación "Blocking DNS Messages is Dangerous".

Amplificación DNS

Hasta hace relativamente poco, para "tumbar" páginas web importantes bastaba con tener una botnet lo suficientemente grande como para generar el tráfico necesario. Pero la "globalización" de servicios y mejora de los sistemas DDoS en general, hacen que cada vez sea más complejo para un atacante disponer de los bots mínimos para causar daño. Así que necesitan "amplificar" ese tráfico que generan para poder atacar. Esto lo conseguían en los 90 con ataques tipo "smurf", pero actualmente (el ICMP era fácil de capar) se usa sobre todo el DNS. Tanto ICMP como UDP permiten falsificar al emisor y sobre todo, generar respuestas "muy grandes" a consultas muy pequeñas.

Así, lo que los atacantes hacen es:
  • Envían una petición pequeña (pocos bytes) desde muchas máquinas, falsificando la dirección de origen y haciendo pensar que  las realiza la víctima. Hago así como

    dig ANY microsoft.com @195.5.64.2
  • Las envían a servidores DNS abiertos, que resuelven cualquier petición. Estos servidores DNS reciben las miles de pequeñas preguntas y devuelven las miles de respuestas gigantescas (hasta 50 veces más bytes que la pregunta) a la víctima, que recibe un tráfico muy grande que no ha solicitado. Algo así como esta respuesta por cada pregunta:

; <<>> DiG 9.7.0-P1 <<>> @195.5.64.2 microsoft.com ANY +norecurse
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2663
;; flags: qr ra; QUERY: 1, ANSWER: 11, AUTHORITY: 5, ADDITIONAL: 7

;; QUESTION SECTION:
;microsoft.com. IN ANY

;; ANSWER SECTION:
microsoft.com. 3591 IN TXT "FbUF6DbkE+Aw1/wi9xgDi8KVrIIZus5v8L6tbIQZkGrQ/rVQKJi8CjQbBtWtE64ey4NJJwj5J65PIggVYNabdQ=="
microsoft.com. 3591 IN TXT "v=spf1 include:_spf-a.microsoft.com include:_spf-b.microsoft.com include:_spf-c.microsoft.com include:_spf-ssg-a.microsoft.com include:spf-a.hotmail.com ip4:131.107.115.215 ip4:131.107.115.214 ip4:205.248.106.64 ip4:205.248.106.30 ip4:205.248.106.32 ~all"
microsoft.com. 3591 IN SOA ns1.msft.net. msnhst.microsoft.com. 2013101607 300 600 2419200 3600
microsoft.com. 2244 IN A 64.4.11.37
microsoft.com. 2244 IN A 65.55.58.201
microsoft.com. 3591 IN MX 10 microsoft-com.mail.protection.outlook.com.
microsoft.com. 172791 IN NS ns3.msft.net.
microsoft.com. 172791 IN NS ns4.msft.net.
microsoft.com. 172791 IN NS ns1.msft.net.
microsoft.com. 172791 IN NS ns5.msft.net.
microsoft.com. 172791 IN NS ns2.msft.net.

;; AUTHORITY SECTION:
microsoft.com. 172791 IN NS ns5.msft.net.
microsoft.com. 172791 IN NS ns1.msft.net.
microsoft.com. 172791 IN NS ns4.msft.net.
microsoft.com. 172791 IN NS ns2.msft.net.
microsoft.com. 172791 IN NS ns3.msft.net.

;; ADDITIONAL SECTION:
ns1.msft.net. 993 IN A 65.55.37.62
ns2.msft.net. 2540 IN A 64.4.59.173
ns3.msft.net. 993 IN A 213.199.180.53
ns4.msft.net. 993 IN A 207.46.75.254
ns4.msft.net. 2629 IN AAAA 2404:f800:2003::1:1
ns5.msft.net. 3124 IN A 65.55.226.140
ns5.msft.net. 943 IN AAAA 2a01:111:200f:1::1:1

;; Query time: 905 msec
;; SERVER: 195.5.64.2#53(195.5.64.2)
;; WHEN: Thu Oct 17 10:34:30 2013
;; MSG SIZE rcvd: 832
Se han encontrado incluso scripts PHP colgados en páginas comprometidas que facilitan esta labor.

http://www.webroot.com/blog/2013/09/10/web-based-dns-amplification-ddos-attack-mode-supporting-php-script-spotted-wild/

Recursivo e iterativo


Además de la botnet y las peticiones falsificadas, los atacantes necesitan "resolvedores" que se presten a este juego amplificando el tráfico. Los servidores configurados como recursivos públicamente (se estima que existen sobre el millón accesibles en la red) son los nuevos servidores de correo que permitían el "open relay" de los 90, y contra ellos se está luchando.

Servidor DNS actuando en modo modo iterativo
Un servidor DNS opera en general en dos modos:
  • Modo iterativo: El usuario pregunta al servidor DNS por un dominio. Si no lo tiene, lo deriva a otro DNS (un root, por ejemplo) que lo sepa y deja que pregunte él mismo. En resumen, le envía un "referral" y que sea el cliente el que trabaje, preguntando varias veces. Ambos comparten el "esfuerzo" de generar y recibir tráfico.
  • Modo recursivo: El servidor DNS, si no sabe cómo resolver un dominio, se ocupa de todo. Pregunta al servidor root, hasta llegar al autoritativo del dominio, recopilar toda la información, y devolvérsela al cliente. Así el tráfico está mal repartido. Al cliente le hacen todo el trabajo y, con pocos bytes, consigue que se devuelva una respuesta enorme. Si además se falsifica la fuente... el DDoS está servido. Desde hace pocos años BIND cambió su configuración por defecto para intentar mitigarlos.

Esquema de ataque con el servidor DNS actuando en modo recursivo
El modo recursivo tiene su utilidad en redes internas en los que los usuarios solo acceden a un DNS corporativo y no pueden consultar a otros... pero si se administra mal y no se limita para este servidor recursivo solo responda a las IPs de su LAN... nos encontramos con que los atacantes disponen de servidores de los que abusar.

El ataque            

Se basa en buena parte en el problema descubierto por Kaminsky en 2008, que permitía engañar a la caché de un servidor DNS. Muy simplificado, se enviaban muchas respuestas falsas a preguntas que nunca hizo el servidor. Si alguna coincidía en el puerto de origen con una pregunta, el servidor devolvía la respuesta falsa como verdadera a la víctima. El problema encontrado por Kaminsky se resolvió introduciendo más entropía al cálculo del puerto fuente en la respuesta. Desde entonces las probabilidades de que coincidan son tan bajas que el ataque no resulta práctico.

Lo que pensaron estos investigadores es que, si el problema es que existe mucha entropía, quizás con más tiempo para probar más posibilidades, podrían volver a conseguir que el ataque de Kaminsky fuera viable. Y así fue. Si se ayudan de los mecanismos anti-DDoS, es posible que el ataque de envenenamiento de caché sea práctico de nuevo. Fundamentalmente, los métodos anti-DDoS abren una ventana de tiempo que puede ser aprovechada por el atacante. Lo que ocurre es que:
  • El atacante, desde cualquier punto, envía una petición de resolución al servidor DNS del que se va ayudar, y que dispone de un sistema anti-DDoS.
  • Este servidor DNS realiza la recursión, preguntando al servidor autoritativo del dominio que corresponda, porque él no sabe la respuesta.
  • La botnet del atacante avisa deliberamente al servidor autoritativo, diciéndole que ese servidor DNS está siendo usado para amplificar, y que active sus mecanismos de protección que fundamentalmente consisten en que ignore a ese servidor DNS que le pregunta: que no le responda o que lo haga más tarde.
  • Mientras el servidor espera, el atacante le envía ataques Kaminsky al servidor (respuestas falsas que cacheará), porque tiene tiempo de sobra para hacerlo. El servidor cree que vienen del servidor autoritativo y las cacheará. El ataque de envenenamiento puede ser otro, pero ellos han usado Kaminsky, por resultar un problema de diseño intrínseco al protocolo DNS.

En resumen, aprovechar ese tiempo de "baneo" para enviar masivamente respuestas y aumentar las probabilidades de éxito en el envenenamiento de caché.

En realidad, es vulnerable cualquier dispositivo que, queriendo usar DNS "Response Rate Limiting" para precisamente evitar ataques, llegue a desestimar peticiones DNS por considerarlas peligrosas. Incluso ciertos cortafuegos.

La solución a todo problema de DNS es DNSSEC, pero como no es probable que se instaure a corto plazo... la contramedida ofrecida es responder a todos los paquetes, incluso si es con un "REFUSED", pero nunca dejar esperando al servidor simplemente ignorando sus consultas.

Sergio de los Santos
ssantos@11paths.com

How to take advantage of Chrome autofill feature to get sensitive information

martes, 15 de octubre de 2013

At the end of 2010, Google introduced autofill in Chrome, a comfortable feature, that may be a security problem for its users. Even after some other browsers suffered security problems related to this feature, and the feature itself were questioned, it is still possible to steal information stored from the user filling up a form, without him to notice.

As a rule of thumb, storing sensitive data in the browser is not a good idea. Just before Chrome implemented autofill, during 2010 summer, it was discovered how to disclose data stored in Safari, by bruteforcing with JavaScript. The user filled up an input field but the browser was able to rescue all other stored data pieces, just by trying letters and letting the browser do the rest. The vulnerability was patched short after. Not long ago, in 2013 summer, it was hardly discussed how easily you could recover passwords stored in Chrome, which could be viewed in clear text.

With an easy method, a user may give unconsciously his data to a third party, just by filling up an innocent form.

How does it work?

Chrome’s autofill allows to store postal addresses (divided in some other data like name, surname, telephone, postal code...) and credit card (divided in cardholder name, number and expiration date). Every data piece (except credit card) can be synchronized with a Google account. The configuration menu and how to get to it, may be observed in the following image sequence.



Different autofill configuration screenshot in Chrome
For a form to take advantage of autofill feature, input fields has to be properly identified so Chrome knows what values go with them.


It relies on some heuristics for the fields to match. For example, it knows that autocomplete="mail" should be autofilled with the same content that autocomplete="Work email".

The "attack"

An attacker may take advantage of this characteristic to obtain private information like an address or credit card data. We set out a scenario where the victim visits a specially crafted https web page, fills up some data, and the attacker uses browser's autofill to get stored sensitive data. And this, despite the easy-to-bypass obstacles that Chrome introduces in its code to avoid this situation.

For example, as a precaution, Chrome only fills up credit card number with autofill under https pages. This is not a problem for the attacker, since he just have to operate from a SSL connection. There are fraudulent webpages that work with certificates issued for free.

The second step is to set up a form and hide the inputs the attacker is interested in from the user. First idea is to use a "hidden" tag. But it’s forbidden in Chrome. A second idea would be to introduce the form inside a div tag with visibility set to "hidden"... but Chrome avoids to autofill inputs under this conditions. How to get it then?

A formula would be to take advantage of the scroll property, rising up the layer some pixels so the inputs used to steal information are unseen. In this case, the "decoy" form would be:


By using this specially crafted "div", we get to hide inside it all these inputs and the browser will not show them (but will autofill them):

div style ="overflow:hidden;height:25px;"


Chrome will fill up all that information without the user noticing anything. The attacker, may pick up the information and get much more information than the user thought he had given.


In summary, although it is comfortable to use (for systems used by a single person), autofill should be avoided since it is proven to be a risk. A victim could offer to any https webpage sensitive data such as credit card number and expiration date, without the victim noticing.

To avoid this problem (or any other potential one in the future), the best remedy by now is to simply not use this functionality.

Ricardo Martín Rodríguez
ricardo.martin@11paths.com