Hay alguien ahí fuera: protege tu cartera de bitcoins

miércoles, 29 de abril de 2015

Las pérdidas ocasionadas a las plataformas que operan con criptodivisas reflejan un interés creciente de los ciberdelincuentes hacia estos medios de pago. El éxito de estos ciberataques pone de manifiesto que las medidas de seguridad implementadas no siempre son proporcionales al valor de los activos que protegen. Vamos a ver qué tipo de carteras virtuales existen, y cuáles son sus medidas de seguridad.

Varios tipos de carteras

En el caso de Bitcoin, las eWallets son las herramientas que nos permiten realizar transacciones y acreditar ante la red la propiedad de los bitcoins utilizando un esquema criptográfico de clave pública para firmarlas (actualmente, ECDSA). En función de cómo se generen el par de direcciones y claves privadas, nos encontraremos ante diferentes tipos de carteras.


  • Las "carteras random" crean el par de claves a partir de un número pseudoaleatorio. Este proceso proporciona seguridad a la cartera al dificultar la generación de claves privadas asociadas a direcciones ya creadas. El inconveniente de esta aproximación es que impediría hacer uso de estos bitcoins en el supuesto de perder el fichero que contiene la clave privada, bien porque el soporte físico se encuentre dañado o porque perdamos las credenciales de acceso.
  • En el caso de las "carteras vanity", el usuario introduce el patrón que las direcciones creadas aleatoriamente deben satisfacer. Pese a que el tiempo de generación aumenta considerablemente, este procedimiento es utilizado por algunos servicios para conseguir direcciones más amigables y fáciles de identificar. Por tener una referencia, tardaríamos alrededor de diez minutos en encontrar una dirección con el patrón 1eleven usando un equipo de sobremesa.
  • Las "carteras mentales" generan la dirección y la clave privada a partir de una palabra conocida. Aunque su utilización no requiere un almacenamiento de claves porque estas podrían generarse en el momento de necesitarlas, cualquiera podría hacerlo si conociera que el input utilizado es, por ejemplo, ElevenPathsTelefonica.


Dirección de Bitcoin y clave privada asociada a la cartera generada con la palabra ElevenPathsTelefonica.

  • Dada la irreversibilidad de las transacciones de Bitcoin, podría darse el supuesto de que los propietarios de una misma cartera no llegaran a un acuerdo para retirar el dinero y fuera necesaria la intervención de un tercero confiable que ejerciera de árbitro. Por ello, las carteras multifirma, a diferencia de las anteriores, no están asociadas a una clave privada sino a un número determinado de direcciones que autorice las transacciones, lo que además aportan una seguridad adicional ante posibles transferencias ilegítimas.

¿Ataques a carteras en local?

Una vez escogido el tipo de cartera en el que depositar bitcoins, se pueden llevar a cabo diferentes aproximaciones para vulnerar los distintos sistemas de almacenamiento de claves. Para las carteras en local, cuyas claves son almacenadas en archivos bajo control del usuario, el primer paso sería identificar equipos que tengan corriendo nodos de Bitcoin, por ejemplo, en el puerto 8333.

Ejemplo de búsqueda de equipos que tienen corriendo un nodo de Bitcoin.

En el caso de que se consiguiera acceso a alguno de estos equipos, el siguiente paso sería identificar la ubicación del fichero de la cartera (wallet.dat, en el caso del cliente bitcoin-qt) y, en el supuesto de que el fichero no se encontrara protegido, se podrían exportar las claves privadas y efectuar transacciones hacia direcciones controladas por el atacante. Si, por el contrario, este fichero se encontrara cifrado, el atacante debería optar por realizar ataques dirigidos de fuerza bruta o de diccionario o bien capturar las contraseñas utilizando técnicas de keylogging cuando esta vaya a ser utilizada.

Otro tipo de amenaza contra este sistema es el denominado ataque por aislamiento. Un atacante que controlara la forma en la que la víctima se conecta a la red tendría la capacidad de servirle transacciones fraudulentas modificando, por ejemplo, la configuración del archivo peers.dat, en el caso de bitcoin-qt.

¿Ataques a carteras mentales?

En el caso de las carteras mentales, uno de los vectores de ataque consistiría en la creación de diccionarios para generar de forma automática posibles direcciones y sus respectivas claves privadas. De esta manera, todas aquellas direcciones que contuvieran monedas podrían ser sustraídas ya que el atacante contaría con la clave privada que firmaría las transacciones.

Para confirmar la viabilidad de este ataque y estimar qué cantidad de monedas habría estado expuesta, realizamos un experimento en el que se generaron las claves privadas y direcciones de más de cuatro millones de palabras diferentes presentes en 200 diccionarios genéricos en distintos idiomas. De los cuatro millones de direcciones generadas, pudimos observar que 17.902 direcciones realizaron operaciones y que en dichas cuentas llegaron a depositarse aproximadamente 19 bitcoins.

Representación temporal de las cantidades sustraídas en dólares y en bitcoins.

Una vez conocida la facilidad de monitorizarlas, el siguiente paso fue preguntarnos si de verdad había alguien dedicado a sustraer bitcoins que se depositasen en carteras mentales. Para ello, generamos tres direcciones que no habían recibido transacciones hasta la fecha a partir de palabras conocidas. Tras transferirles pequeñas cantidades de dinero, solamente tuvimos que esperar diez segundos hasta confirmar que alguien estaba operando con las dos primeras direcciones.

Pero, ¿qué ocurrió con la tercera dirección? A diferencia de las dos primeras en las que solamente se realizó un intento de transacción, desde la tercera dirección se solicitaron hasta tres intentos de transacción simultáneos hacia tres cuentas diferentes.

Para entender cómo la red resuelve este tipo de conflictos, es necesario comprender cómo son añadidas las transacciones a la cadena de bloques. Los bloques son conjuntos de transacciones que se añaden cada 10 minutos aproximadamente. El criterio de selección de quién añadirá un nuevo bloque se realiza a partir de la resolución de un problema matemático de dificultad ajustable. En este caso, Bitcoin opta por el cómputo de un hash cuya complejidad varía en función de la capacidad de cómputo total de la red.

Será el nodo que añada el bloque el que recolecte las comisiones de las transacciones incluidas y una cantidad de BTC determinada por la cesión de su capacidad de cómputo. Aunque los criterios de adición son configurables, la propuesta más aceptada se basa en dos premisas: comisiones y prioridad. Las comisiones son cantidades elegidas por los usuarios para favorecer que su transacción sea añadida más rápidamente. Por su parte, la prioridad de añadir una transacción viene determinada por el volumen (BTC_i, en Satoshis) y antigüedad (Age_i, en número de confirmaciones) de las cantidades transferidas y el tamaño de la operación (s_t, en bytes).


En el ejemplo que llevamos a cabo, tres direcciones con características diferentes reclamaron nuestro dinero. La primera sin comisión, la segunda con una pequeña comisión y la tercera incluía la transacción como parte de una transacción mayor en la que se transferían dos inputs diferentes hacia otra cuenta, la cantidad que nosotros transferimos y cerca de 75 BTC. Cinco horas después, la red aceptó la transacción dirigida hacia esta última dirección.

La cuestión es: ¿qué habría pasado si un tercero hubiera confiado en alguna de las otras transacciones antes de esas cinco horas? En ese caso, se habría incurrido en un fenómeno de triple gasto y cualquier operación derivada de estas no habría tenido efecto real alguno.

¿Ataques a carteras en la nube?

Por último, nos encontramos con las carteras en la nube. Desde finales de 2013 y principios de 2014, hemos podido comprobar que, a partir de la información cedida por la compañía Blueliv, cuando el precio del Bitcoin se encontraba en su punto más alto de cotización se intensificó el robo de credenciales de plataformas de Bitcoin. La realidad es que si las plataformas no tienen implementadas sistemas de autenticación robustos tanto para el acceso como para la emisión de transacciones, la información procedente de una botnet destinada al robo de credenciales podría ser más que suficiente para sustraer el dinero de las cuentas.

Recomendaciones

Después de analizar diferentes ataques a las carteras, no es recomendable la generación de claves privadas a partir de carteras mentales, ni la utilización de plataformas que no dispongan de sistemas de verificación en dos pasos como Latch. En cambio, y a pesar de que solamente se utilicen actualmente en el 1% de las transacciones, las carteras multifirma son las más aconsejables desde el punto de vista de la seguridad. Además de los ataques específicos que se pudieran perpetrar contra el funcionamiento teórico de las criptodivisas, los atacantes podrán replicar los métodos utilizados contra el sector bancario adecuando la funcionalidad de familias de malware como ZeuS e intensificando las campañas de phishing para el robo de criptodivisas.

Por ello, las empresas de seguridad pueden encontrar en el mundo de las criptodivisas un nuevo target al que destinar sus productos basados en la detección de campañas de phishing, malware o aplicaciones móviles sospechosas. En este último aspecto, herramientas de investigación como Tacyt serán útiles para la identificación de abusos contra los usuarios de aplicaciones en dispositivos móviles. Asimismo, a medida que estas monedas vayan consolidándose como medios de pago, serán necesarios productos destinados a la reducción de tiempos de espera con el fin de evitar transacciones potencialmente fraudulentas y al ofrecimiento de servicios de arbitraje para la resolución de conflictos aprovechando las posibilidades de las carteras multifirma.

* El contenido de este artículo hace referencia a la ponencia titulada How I met your eWallet presentada en RootedCON 2015 cuya presentación junto con más información se encuentra disponible en: http://es.slideshare.net/mobile/elevenpaths/how-i-met-your-ewallet-rooted-2015

"Tienes más posibilidades de que te alcance un rayo, que de que se infecte tu móvil". ¿De verdad?

lunes, 27 de abril de 2015

Usar titulares con gancho para llamar la atención sobre un estudio... se ha hecho siempre, hay que permitir y entender que se tomen ciertas licencias. Pero cada vez la atención es más escasa porque el número de integrantes de una industria crece, el potencial cliente se "inmuniza" y es necesario elevar el listón... Este titular de Damballa sobre un estudio de malware en telefonía móvil suena bien, pero ¿qué hay de cierto si leemos la letra pequeña, los comparamos con otros, o incluso simplemente razonamos un poco?

El estudio

Del estudio destacan este titular, como claro reclamo para que los periodistas lo perpetúen:

Investigación sobre el 50% de los móviles estadounidenses concluye que tienes 1.3 más
posibilidades de ser alcanzado por un rayo que de tener malware en tu dispositivo de comunicación

Damballa ha realizado un estudio bastante interesante. Para evaluar los niveles de infección en móviles, no se basa en firmas (evitando todos los conocidos problemas tanto técnicos como de interpretación que surgen cuando se utilizan firmas antivirus). Disponen de DNS pasivos (o lo que es lo mismo, la capacidad de saber qué dominios resuelve un teléfono) del 50% del tráfico móvil de Estados Unidos. Entendemos que porque tienen acceso a los DNS del operador dominante, lo que ya puede suponer una desvirtualización del estudio (¿sabemos si el operador elegido define de alguna forma al tipo de usuario?) Así que, en la RSA han aprovechado para presentar su segundo estudio (el primero fue en 2012) con la siguiente metodología:

  • En el estudio realizado durante el último cuatrimestre de 2014, vieron entre 160 y 130 millones de dispositivos por día.

  • Estos dispositivos contactaron con 2.762.453 host únicos. Solo 9.688 de 151 millones de dispositivos contactaron con una lista negra de hosts. De ahí se deduce que el 0,0064% de móviles están infectados. Puesto que el National Weather Services dice que las posibilidades de ser alcanzado por un rayo son de 0,01%, el titular está servido.

¿Qué base tienen esos números?

No es difícil saber por dónde empezar: nadie tiene la verdad absoluta. Este tipo de datos, como en las encuestas, pueden cocinarse más o menos. Aunque desde el espíritu crítico, se pueden intentar señalar los potenciales puntos débiles del estudio y que pueden hacer (cuando menos) variar ostensiblemente los números. Incluso no es difícil encontrar otras investigaciones con resultados muy dispares. Pero si nos centramos en los potenciales puntos débiles del estudio, pueden esconderse en varios aspectos.

En el método y en la cantidad

No dan muchos más detalles sobre la metodología. En principio, es un método más interesante que el de las firmas antivirus. Elude los conocidos problemas de calidad de detección, de uso de motores, de interpretación, etc. y va directo al grano de la comunicación que hace el infectado: en este caso, han dado por hecho que una petición equivale a un infectado. Esto es posible porque tenían acceso al tráfico móvil en Estados Unidos. ¿Incluye conexiones WiFi? El malware más sofisticado puede intentar eludir conexión de datos, o el usuario no tener contratado este servicio. ¿Es Estados Unidos un país suficientemente representativo? Esta misma prueba, según la propia Google (cuyo interés, lógicamente, es dar un mensaje de tranquilidad sobre los niveles de infección) habría sido muy diferente según el país en el que se hubiese realizado.

Estudio oficial de Google sobre malware en Android en 2014. PHA = Potentially Harmful Apps

En la gráfica queda claro que China, Rusia, Emiratos Árabes... son países con un porcentaje cercanos al 1% de infección. El titular de Damballa no aplica en ellos. Pero centrémonos en Estados Unidos, como el estudio. En ese gráfico, la "media de infección" en US se aprecia superior al 0,1%. Aunque nos manejemos con números pequeños y sólo en este país, es del orden de 16 veces mayor que lo que afirma Damballa (0,0064%). Con aproximaciones diferentes, las conclusiones son muy diferentes.

Por ofrecer otra aproximación que igualmente no se corresponde con los resultados de Damballa: En 2013, un informe realizado por Kindsight, también basado en el estudio del tráfico en el operador (no solo dominios, sino inspeccionando el tráfico) hablaba de que el 1% de los Android estaban infectados.

Estudio de 2013 elevaba al 1% los Android con malware, basado en un método de tráfico, no de firmas

Volviendo al estudio de Damballa, no se dice durante cuánto tiempo se ha realizado el estudio. En 2012 (hay más detalles de ese estudio aquí) hablan de tres periodos de seis días. Suponemos que han calculado la media de 151 millones (entre 130 y 160 millones al día) de dispositivos diferentes conectados a diario. Aunque luego utilizan el total de dominios en lista negra contactados durante todo el tiempo, para calcular el porcentaje. ¿Son estos números representativos?

Al margen de todas estas preguntas, la espina dorsal del estudio se basa, creemos, en dos asunciones:

  • Damballa dispone de un conjunto de listas negras de dominios lo suficientemente representativo. En nuestra opinión, en este caso se están sustituyendo firmas (trozos de código o características que definen una muestra) por dominios contactados para detectar malware. Es un método interesante porque un dominio contactado en la lista negra casi "confirma" una infección, pero hereda la misma "imprecisión" de las firmas. ¿Cuántos dominios utilizas? ¿En qué se basa tu criterio para elegir dominios? Quizás se base en, precisamente, los dominios contactados por malware cazado a través de firmas antivirus. Además, la volatilidad de la lista negra de dominios es alta. ¿Se tiene en cuenta? ¿Acaso todo el tipo malware necesita contactar regularmente con dominios? La inmensa mayoría del malware para Android está basado en estafas y llamadas SMS. Muchos de ellos necesitan contactar con servidores pero otros tantos no... ¿Se tienen en cuenta? Un ejemplo claro son los clásicos ZiTM (Zeus in the Mobile), en el que el usuario descarga un programa (ahí sí podría ser detectado por el estudio) y una vez instalado, reenvía los SMS del banco al atacante. No se necesita un dominio C&C con el que contactar regularmente. ¿Qué pasa con los dominios de sistemas de anuncios, legítimos, pero que pueden ser configurados agresivamente para robar información o saturar al usuario de anuncios (adware)?... Al final, el método es tan bueno como la certeza de tu supuesto inicial. En este caso, si la calidad de los dominios en la lista negra no es buena, o si solo salen a la luz las infecciones en las que regularmente se contacta con un C&C, es un método interesante, pero tan válido o inválido como otros tradicionales.
  • Todo el que contacta con uno de esos dominios, está infectado. El que no, no lo está. Como siempre, lo interesante es lo no detectado, lo que escapa a una lista negra o heurística ya diseñada. Ese porcentaje de "infectados silenciosos" que no pueden ser catalogados ni por firma, dominio contactado u otros medios y que saldrán a la luz en futuro... o no. Lo que Damballa y cualquier otro método caza, es simplemente lo conocido en este momento. Es imprescindible añadirle un porcentaje de incertidumbre antes de lanzarse con afirmaciones absolutas.


¿Entonces el titular no es cierto?

El titular responde a la investigación, pero el mensaje es peligroso. Creemos que las posibilidades de infectar un móvil no dependen del azar, desde luego, ni que sean tan bajas. El factor fundamental para hablar de "probabilidades de infección", igual que en el escritorio, depende mucho de los hábitos de uso. Y en el mundo móvil, concretamente, está estrechamente ligado (mucho más que con el escritorio, incluso) con qué apps se instalen y de la fuente que provengan. En el mundo móvil, no son populares las infecciones por otros métodos que no sean la instalación directa (no se usan masivamente exploits todavía).

Podríamos aventurarnos en este sentido con estudios hipotéticos y sacar otras cifras basadas en estos mismos términos. Imaginemos que un usuario es cuidadoso y solo utiliza Google Play para instalar apps. Usando Tacyt, en octubre de 2014 realizamos un estudio privado en el que concluimos que un 1% de las apps en Google Play eran detectadas por 9 o más motores de VirusTotal. Otros estudios se conforman con catalogar como adware o malware las detectadas por entre 1 o 5 motores, nosotros fuimos conservadores, y aun así no consideramos que sea un método 100% certero. Además, hablamos de apks detectadas... otra cosa es que sean realmente malware, qué tipo de malware y desde luego no se hace asunción alguna sobre las no detectadas. ¿Podríamos hablar de que las posibilidades reales de infección de un usuario "normal" que solo consume Google Play, son del 1%? Esta afirmación exige tantos matices como el estudio de Damballa, pero tampoco podríamos llamarla descabellada si se documenta convenientemente, aunque las conclusiones sean absolutamente dispares.

En resumen, el estudio es correcto, aporta información, pero la conclusión debería tomarse como lo que es: Aproximadamente un 0,0064% de los dispositivos Android funcionando bajo un operador en Estados Unidos contacta con dominios en una lista negra de malware.

Sergio de los Santos 
ssantos@11paths.com 
@ssantosv

New tool: Google index Retriever

viernes, 24 de abril de 2015

Have you ever found a webpage that seems to talk exactly about what you need, but it has been removed? Yes, Google cache is the answer but... What if the cache has been removed too? What if the site is just in Google Index page? You can not get the webpage back, but you know it was there. 

Google Index Retriever will try to retrieve back the index in Google, so you can get part of the text back, and maybe that removed content you need. Google cache is not there forever. From time to time, they are just removed for good. Archive.org and its WayBackMachine does not take as many snapshots of the less popular pages... so, there are some situations where the only part of a web that is left is in the Google Index.

Google index is that little part of text in the results page that Google search engine shows when the user searches for anything. In the "index", the searched words matching appear in bold. Google Index is the last part of a web to disappear. So there will be situations where that is the only part left. Google keeps different "indexes" from the same webpage, so, if they could be all put together, the text would be reconstructed and it would maybe come up.

But that is not the only situation where the tool may be useful. What if the index contains passwords, credit card numbers or any other sensitive information? In fact that was one of the reasons to create the tool: to demonstrate that removing the webpage and cache with offensive or sensitive content is not enough. The content may be still reachable. This is all explained in this presentation.

How does the tool work?

It is very easy. The tool is fed with a Google Search that produces an index result. It will try, brute forcing the Google Search ("stimulating it") to retrieve as much as possible. Then, it has some different options:

Example with an evernote profile

  • One Shot button: It just searches once with the information provided. Use this to try to be the more specific you can with the search string before hitting on "start button".
  • Start button: It starts searching in automatic mode. Result box will display the time elapsed since the search started, the word that made the information to come up, and finally the longest possible sentence if it differs from the last one, so the user may reconstruct the webpage.


The logic to try to "stimulate" the index and get back the information is:

  • First, try to stimulate the index with the words already found in the first index result "around" the main word searched, so it tries to retrieve the whole sentences again and again.
  • If there are no more results or "words around" left, the search is repeated with keywords provided by the user, like a "dictionary attack". When this occurs, the progress bar changes its color.

Google, of course will launch a CAPTCHA from time to time because of the continuous use of their service. This is perfectly ok. Google Index Retriever will capture the CAPTCHA so it is easy to resolve and keep on going.

Google will show a CAPTCH from time to time

Spam

This tool may be used as well to check if a site has been probably compromised and injected with spam and black SEO. It is usual that attackers compromise webpages and inject spam words in them so the "steal" their pagerank.

Using the tool to find possible "hidden" Spam in a webpage

This content is not visible for visitors but only to Google robot and spider, so it is usually visible in this index. This tab works exactly the same as the other, but with another logic:

  • It directly tries to search from a different set of keywords (related to spam) in a Google index result.

So this way, it is easier to know if a webpage has been compromised and injected with SEO spam.

Other features

The program is written in Java, so it should work under any system and version, although it has been tested under Windows. The results may be exported to a html document in the local computer. Keywords and spamKeywords are completely customizable. They may be added individually or edited directly from a TXT file.

Customizable keywords
The tool is available to download here.

Nueva herramienta: Google Index Retriever

¿Has encontrado en Google alguna vez una página que parece hablar exactamente de lo que necesitas, pero que ha sido eliminada? Sí, la caché de Google es la respuesta, pero... ¿Y si la caché ha sido eliminada también? ¿Y si el texto solo se encuentra en el índice de Google? No se puede recuperar la página, pero se sabe que estuvo ahí. 

Google Index Retriever intentará recuperar el índice de Google, para poder obtener parte del texto de la web y así el contenido eliminado que se necesita. La caché de Google no está ahí para siempre. De vez en cuando, se elimina para siempre. Archive.org y su WayBackMachine no toma tantas instantáneas de las páginas menos populares, así que se dan situaciones donde lo único que queda de una página está en el índice de Google.

El índice de Google es esa pequeña porción de texto en la página de resultados del motor de búsqueda de Google que se muestra cuando se busca cualquier texto. Es el índice, las palabras buscadas aparecen resaltadas. Google Index es la última parte de una web en desaparecer. Habrá situaciones donde será la única y última parte que queda. Google mantiene índices diferentes para la misma página así que, si se pudieran poner todos juntos, el texto podría reconstruirse y tener la mayor parte de la página eliminada.

Pero no es la única situación en la que la herramienta podría ser útil. ¿Y si el índice contiene contraseñas, números de tarjeta de crédito o cualquier otra información sensible? De hecho esto fue una de las razones para crear la herramienta: demostrar que eliminar páginas con contenido sensible u ofensivo, incluso de la caché, no es suficiente. El contenido podría seguir siendo accesible. Todo esto se explica en esta presentación.

¿Cómo funciona la herramienta?

Es muy sencilla. La herramienta se alimenta de una búsqueda de Google que produce un índice como resultado. Intentará realizar una especie de fuerza bruta en la búsqueda (estimulándola) para obtener de vuelta tanto texto como sea posible.

Example with an evernote profile

  • El botón "One Shot": Busca solo una vez con la información proporcionada. Se utiliza para ser lo más específico posible con la cadena de búsqueda antes de empezar con el botón de "Start".
  • * El botón "Start": Comienza buscando en modo automático. La caja de resultados mostrará el tiempo pasado desde que comenzó la búsqueda, la búsqueda que hizo aparecer la información y finalmente la frase más larga encontrada si difiere de la anterior, para que el usuario pueda reconstruir así la página.
La lógica para intentar "estimular" el índice y recuperar la información es:

  • Primero, intenta estimular el índice con las palabras que ya ha encontrado en el resultado del primer índice y se encuentran "alrededor" de la primera palabra buscada, para poder recuperar frases enteras una y otra vez.
  • Si no hay más resultados o no quedan "palabras alrededor", la búsqueda se repite con palabras clave proporcionadas por el usuario como un "ataque por diccionario". Cuando ocurre esto, la barra de progreso cambia de color.
Google, por supuesto, lanzará un CAPTCHA de vez en cuando a causa de la búsqueda continua. Esto es perfectamente normal. Google Index Retriever capturará ese CAPTCHA para que sea fácil de resolver por el usuario y pueda continuar

Google will show a CAPTCH from time to time

Spam

La herramienta también puede ser usada para comprobar si una página ha sido probablemente comprometida y se le han inyectado spam como estrategia de Black SEO. Es habitual que los atacantes comprometan páginas e inyecten palabras relacionadas con el spam en ellas para "robar" su pagerank.

Using the tool to find possible "hidden" Spam in a webpage

Este contenido no se visible por los visitantes sino por los crawlers y robots de Google, así que normalmente se verá en ese índice. Esta pestaña del programa funciona exactamente igual que la otra pero con otra lógica:

  • Intenta buscar directamente desde un conjunto diferente de keywords (relacionados con el Spam) en el índice de Google.

De esta forma, es más sencillo saber si una página ha sido comprometida y se le ha inyectado spam relacionado con el Black SEO.

Otras funcionalidades

El programa está escrito en Java para que pueda funcionar bajo cualquier sistema y versión, aunque ha sido más comprobada en Windows. Los resultados pueden ser exportados a un documento html en local. Las keywords son completamente personalizables. Pueden ser añadidas individualmente o editadas directamente desde un fichero TXT.

Keywords configurables
La herramienta puede ser descargada desde aquí

H4ckM33ts

miércoles, 22 de abril de 2015

H4ckM33ts nace con espíritu divulgativo sobre la seguridad en el mundo digital, desde un punto de vista más práctico, realizando talleres y charlas con una participación más activa de sus asistentes.

Telefónica crea estos talleres donde se tratarán los temas más acuciantes sobre la seguridad informática, y en Internet, desde todas las perspectivas posibles, "tocando" los riesgos que corremos y analizando con que posibilidades y recursos contamos para evitarlos o en su defecto, mitigarlos.

H4ckM33ts empieza hoy su primera edición y lo hará en la ciudad de A Coruña y posteriormente, en sus próximas ediciones; en las ciudades de Barcelona, Palma de Mallorca, Bilbao y Madrid. Os lo iremos anunciando conforme se vayan acercando sus fechas de celebración.

Juan Carlos Moreno, responsable de Seguridad de Telefónica de la zona Norte de España, y propulsor de esta iniciativa, será el maestro de ceremonias y quién dará la bienvenida a estas jornadas.
Los temas y ponentes seleccionados para estos primeros talleres en Coruña son:
  • Rafa Sánchez, Analista de Seguridad en ElevenPaths, hablará y hará una demo sobre Tacyt, nuestra innovadora herramienta de ciberinteligencia de amenazas móviles.
  • Pablo González, Project Manager en ElevenPaths, impartirá un taller sobre nuestra tecnología Faast + VMS: detección persistente y gestión del ciclo de las vulnerabilidades.
  • Fran Gómez y Mariano González de Sinfonier-Project presentarán el uso de la herramienta Sinfonier a través de casos de uso aplicados al mundo de la seguridad móvil.
  • Javier Soria, del área de seguridad de Telefónica de España, hablará de análisis forense informático - telemático, contará ejemplos de análisis forense en Android, iPhone/iPad, GPS Tom Tom, y explicará cómo borrar de manera segura los dispositivos en empresas cuando se cambian o destruyen.
  • Julio Gómez, dará un taller sobre Web Security DYI y Pablo San Emeterio sobre Win32 Exploit for Scratch.

Puedes conocer más detalles en la web de H4ckM33ts así como el perfil y descripción de cada uno de los ponentes seleccionados para estas jornadas.

Además, si quieres contactar directamente con ellos, puedes hacerlo a través de la siguiente dirección de correo: info@hackmeets.com

Entérate de todo a través de su cuenta en Twitter, te lo estarán contando a partir de las 09:30 horas en directo.

Firma digital de documentos con SealSign (II)

martes, 21 de abril de 2015

En un artículo anterior vimos los distintos productos de SealSign e indicamos que se basaban en la firma digital, la cual puede utilizar tanto biometría como certificados digitales. En este artículo vamos a analizar el uso de la biometría en los productos de SealSign.


Esquema básico de cifrado de documentos
La biometría es una disciplina en constante evolución y que se basa en el análisis de los rasgos únicos de cada individuo para diferenciarle del resto. Estos rasgos pueden ser físicos (ADN, huella dactilar, iris, retina, rostro, venas de la mano, latidos del corazón, voz, etcétera), o de comportamiento (firma manuscrita, escritura, dinámica del tecleo, etcétera).

Algunos rasgos únicos no están considerados ni físicos ni de comportamiento, ya que factores externos como la edad, la salud o el estado de ánimo pueden modificarlos en el tiempo. Ejemplos de estos rasgos únicos pueden ser la voz o la dinámica del tecleo.

El uso de biometría a la hora de firmar un documento pasa por obtener en primer lugar los datos biométricos necesarios del firmante. La variedad de dichos datos dependerá totalmente del rasgo que se va a utilizar para identificarle.

El módulo BioSignature de SealSign incorpora un motor de autenticación de firmas manuscritas, por ello cuando se captura la firma manuscrita desde cualquier tipo de dispositivo con pantalla táctil como un smartphone o un PC con tableta digitalizadora, se recoge toda la información biométrica que el firmante está realizando (principalmente las coordenadas en las que se está realizando el grafo, el tiempo empleado, la velocidad de la firma y la presión del bolígrafo digital).
 
Funcionamiento del módulo BioSignature de SealSign

El módulo BioSignature se podría emplear en múltiples circunstancias en la que se necesite una firma manuscrita. Lo que hace este módulo es utilizar técnicas de biometría para conseguir una firma digital fidedigna con la que firmar un documento.

Técnicas biométricas para la firma digital
Elementos que intervienen en el proceso:
  • Un componente hardware donde el usuario firmará manuscritamente (por ejemplo una Tablet, o una tableta digitalizadora).
  • Un componente de captura creado con software de SealSign que captura la firma manuscrita y se la proporciona cifrada al servidor.
  • Un equipo servidor con software SealSign que contiene los elementos criptográficos necesarios para codificar el documento, además del propio documento que se desea firmar. Es en este equipo donde se realiza la composición del documento con la firma.

Ejemplo de firma

Para seguir paso a paso el funcionamiento de todo el proceso, vamos a suponer un sitio web que ha integrado el módulo BioSignature de SealSign, y que ofrece a sus usuarios la posibilidad de firmar digitalmente un documento pdf.

El usuario inicialmente accederá al componente de captura de SealSign (1), (por ejemplo a través de un botón en una página web) y firmará manualmente en el componente hardware (2) (por ejemplo una Tablet). Tras esto, los datos biométricos de su firma (incluido el propio trazo) están en el componente de captura (3).

Esquema del proceso de firma
El componente de captura pasa los datos biométricos (cifrados por seguridad) al equipo servidor, en donde está el módulo BioSignature que descifra dichos datos y los vuelve a cifrar utilizando una clave establecida. Tras realizar este cifrado ya se puede hablar de firma digital. El equipo servidor contiene también el documento pdf que se quiere firmar (4), por tanto el siguiente paso es firmar dicho documento. Esto consiste en incluir la firma digital en el documento pdf (al ser pdf se incluye como metadatos) (5). Finalmente tras disponer del documento ya firmado, el equipo servidor se lo devolverá al componente de captura (6). Opcionalmente también se podría almacenar el documento firmado (7).

Proceso de firma digital biométrica de documentos
Esta dinámica hace que la solución sea completamente segura debido a múltiples factores:
  • Los datos biométricos son datos personales sensibles y se cifran en el mismo dispositivo de captura para impedir su reutilización fraudulenta.
  • Cada firma está vinculada exclusivamente al contenido del documento firmado y permite la identificación del firmante mediante la participación de peritos calígrafos.
  • El documento incorpora los datos biométricos cifrados y se sella electrónicamente para proteger su integridad.
El componente de captura en modo SDK soporta dos tipos de captura:
  • Modo online: Sí existe conexión entre el componente de captura y el equipo servidor en el momento de realizar la captura de los datos biométricos
  • Modo offline: No existe conexión entre el componente de captura y el equipo servidor en el momento de realizar la captura de los datos biométricos. En este caso el SDK dispondrá de lo necesario para guardar los datos biométricos y posteriormente se sincronizará con el equipo servidor para finalizar todo el proceso.
En un próximo artículo se mostrará el uso de certificados digitales por parte de SealSign para conseguir firmar digitalmente un documento.

* Firma digital de documentos con SealSign (II)

Hackaton Sinfonier Project en la UJA

jueves, 16 de abril de 2015

Ante la necesidad de dar soporte en tiempo real al procesamiento de la información que se recolecta desde diferentes fuentes, Sinfonier pone a disposición de los usuarios una infraestructura gratuita para que puedan crear sus topologías utilizando los módulos generados por otros usuarios y disponibles en la comunidad para desarrollar los suyos propios.

Se trata de una comunidad abierta con un framework de tiempo real (Apache-STORM), un interfaz gráfico intuitivo y una capa de abstracción para facilitar el desarrollo de nuevas funcionalidades y sacar el máximo partido a la información. Pero además, Sinfonier pone a disposición de los usuarios la capacidad de trabajar sobre un entorno privado y dedicado, donde cada usuario puede disponer de todos los recursos que necesite para llevar a cabo sus proyectos.

Con menos de un año de vida, esta comunidad gratuita para desarrolladores e investigadores del ámbito de la seguridad se ha convertido en el entorno colaborativo de referencia entre organismos, compañías y especialistas en Ciberseguridad de todo el mundo.

Tras su participación en los Campus Party de todo el mundo y en eventos clave del sector, Sinfonier Project llega hoy a la Escuela Politécnica Superior de Jaén con el Hackaton Desfragmentando la Identidad.


Durante el día de hoy y hasta mañana, expertos y apasionados de la seguridad se darán cita para conocer este proyecto abierto que pretende democratizar el procesamiento de datos en tiempo real. Para ello, se plantearán diferentes objetivos enfocados al diseño y desarrollo de módulos y topologías que aporten soluciones óptimas relacionadas con el problema de la “Atribución” en base a la información de las identidades digitales.

Si quieres participar, eres alumno de la Universidad Politécnica Superior de Jaén y todavía no te has apuntado, aún puedes hacerlo. Regístrate y forma parte del punto de encuentro para la generación de inteligencia a través de fuentes abiertas de información.

¿Eres una PyME? Protege gratis tu negocio con Latch gracias a INCIBE

miércoles, 15 de abril de 2015

Las empresas, cada vez más presentes en el mundo digital, saben que están más expuestas a recibir potenciales ataques y agresiones constantes contra sus sistemas. Este hecho afecta de igual forma a grandes empresas, start-ups o PyMEs. Internet tiene esa doble cara. Por un lado, presenta innumerables ventajas tanto para empresas y negocios, pero, por el otro; oculta millones de amenazas dispuestas a aprovechar cualquier descuido y vulnerabilidad para atacar.

Latch Silver gratis gracias a Incibe
Gracias a Incibe, ahora las PyMEs españolas pueden ser más conscientes de los peligros de la red teniendo a su disposición innovadoras herramientas de seguridad y proteger su negocio online. Un proyecto con el objeto de tomar un mejor pulso a la sociedad española y conseguir que la pequeña y mediana empresa pueda mejorar poco a poco la seguridad de sus sistemas informáticos.

Latch para empresas permite a las organizaciones implementar un pestillo de seguridad en los servicios online. De esta manera, los usuarios podrán bloquear fácilmente el acceso a dichos servicios desde una sencilla app en el móvil. Por ejemplo, si tienes una tienda online, tu usuario podrá "dejar el pestillo echado" a su cuenta de acceso a la tienda y "abrirlo" sólo cuando vaya a realizar una compra. De esta forma, aunque le robaran su usuario y contraseña, nadie podría hacer compras en su nombre.





Hasta el 30 de noviembre de 2015 las PyMEs españolas podrán probar de manera gratuita la versión Silver de Latch simplemente registrándose en la web de INCIBE. Esta versión de Latch permite a las PyMEs no solo tener hasta 100 usuarios protegidos con esta herramienta sino que además pueden disfrutar de la consola de administración web Latch Support Tool por el que los administradores de las empresas pueden conocer el estado de los latches de sus usuarios y gestionar cualquier situación de soporte que se produzca. Latch Silver, al igual que Latch se puede implementar muy fácilmente en cualquier empresa.

Conoce cómo integrar Latch.
Regístrate ahora y participa en esta iniciativa para proteger tu negocio.

Aclaraciones sobre el fallo de 1997 que "vuelve" a Windows, SMB redirect (y cómo protegerse)

martes, 14 de abril de 2015

En 1997, Aaron Splanger descubrió un fallo "mítico" en Windows. Se podía forzar a Windows (y a su navegador, más bien) a que enviara las credenciales a una unidad compartida de un servicio del atacante a través de SMB. Simplemente bastaba con poner un enlace a algo como "\\recurso" en una web... y las credenciales serían "enviadas" mientras se navegaba. El fallo nunca se "corrigió" realmente, solo se mitigó, pero ahora se le ha dado una vuelta de tuerca que lo hace más sencillo de explotar... Veamos si es cierto y cómo protegerse.

Ya en 1997 se sabía que, si alguien en una web apuntaba a un recurso tipo "img src="\\1.2.3.4\share\1.jpg", un atacante en 1.2.3.4 podía tomar las credenciales de la persona que visitaba la web. Es cierto que las credenciales estarían cifradas, pero en aquel entonces se hacía con LANMAN, o lo que es lo mismo, una pantomima de protocolo de cifrado que no servía para nada.

Windows envía las credenciales por defecto para que sea muy cómodo navegar por un dominio logueado con un solo usuario, y se accedan a recursos compartidos de manera transparente. Si no son válidas, se piden nuevas, si lo son, el usuario accede en el dominio a lo que tiene derecho. Es un comportamiento ideal que parece que nunca va a cambiar en Windows, y por tanto, no se "arregló" del todo. Lo que se hizo es, sobre todo, mejorar el cifrado y que hiciera falta realmente hacer "clic" sobre algunos enlaces para entender que realmente se quería acceder a la unidad. Además, actualmente, se utiliza también NTLMv2 como protocolo, que aunque no es perfecto, sí que ofrece una seguridad razonable. O sea, aunque exista un servidor SMB malicioso en la red y se envíen "sin querer" credenciales, lo más probable es que al supuesto atacante le cueste crackear la contraseña.

¿Y qué han descubierto nuevo?

La gente de Cylance ha descubierto que se puede conseguir el mismo efecto a través de la redirección HTTP y además usando "file://recurso" (era más habitual "\\recurso") para estimular el envío de los hashes. Esto abre nuevas puertas de ataque, volviendo "un paso atrás". En resumen, estas APIs (muy populares) dentro de URLMon.dll:

  • URLDownloadToFile
  • URLDownloadToCacheFile
  • URLOpenStream
  • URLOpenBlockingStream

...permiten que, si van a una página que redirige a un recurso SMB a través de un 301 o 302 de Apache (u otros métodos de redirección HTTP), terminarán enviándose los hashes de las credenciales. Ya no es necesario tener que intentar abrir una ruta UNC, o intentar montarlo en una unidad local. Desde ahora se sabe que cualquier programa que use URLDownloadToFile, por ejemplo, y se encuentre con un "file://servidor" en su tráfico, le dará las contraseñas cifradas a ese servidor. Para conseguirlo, basta con darle a ese programa páginas HTTP que redirijan a un "file://". Y esto incluye ya no solo sistemas de Windows, sino cualquier programa que utilice URLMon.dll, que no son pocos.

¿Es grave?

El módulo de Cain que caza credenciales SMB
Por un lado sí, abre las puertas a ataques más sencillos. Un atacante que controle un poco el tráfico en una red interna podría comenzar a cazar hashes de contraseñas del usuario más rápido y con solo redirigir el tráfico HTTP a un servidor SMB malicioso. También fuera de esa red.

Microsoft le resta importancia, por supuesto (e incluso da a entender que no hay nada que arreglar). En realidad el fallo ya era y es explotable. Es cierto que aporta un nuevo vector de ataque que lo facilita, pero el atacante que ya quisiera usarlo, lo estaría haciendo (y de hecho se hace en auditorías internas). Programas como Cain ya disponían de una forma cómoda de, en una red interna, capturar estos hashes.

También es cierto que esto no afecta a los atacantes más vulgares a los que no importan quién es su víctima sino cuántas son. A ellos no les interesan las contraseñas. A quien más beneficia esta vuelta de tuerca es a atacantes que buscan una empresa concreta a la que atacar... se les ha puesto en bandeja un método muy sencillo que le permitirá recopilar contraseñas de forma todavía más automatizada. Parece que facilita el ataque alojado "fuera de la red interna" (si es que se permite el tráfico SMB hacia redes externas) y en la interna lo potencia, además en que se amplía mucho el rango de programas o incluso scripts vulnerables.

¿Cómo protegerse?

Existen al menos tres formas, que ya debían estar implementadas para protegerse del ataque de 1997... pero vamos a recordarlas:

  • Obvia: mejorando las contraseñas. Las contraseñas que se envían están cifradas. Obviamente, si es más compleja de lo normal, puede que no pueda ser crackeada en un tiempo razonable.
  • Mejorando el protocolo. Por muy compleja que sea la contraseña, si se usa LM para autenticarse en red, nada servirá. Asegurarse de que se usa NTLMv2 y solo NTLMv2 para la autenticación en red. Eso está en esta opción de Windows (ver imagen). Pero no es suficiente con la opción por defecto... puesto que permitiría realizar un "downgrade" a LM quizás bajo ciertas circunstancias. Es necesario evitar el comportamiento por defecto y realmente rechazar LM.
Configurar Windows para que solo envíe hashes a través del protocolo NTLMv2

  • Limitando el tráfico SMB que sale. Normalmente el tráfico SMB va por el puerto 445 y 139 (UDP y TCP). El cortafuegos saliente podría evitar que saliese este tráfico a la red externa... Para limitar el tráfico se puede usar el cortafuegos corporativo, o el de Windows en local.

Usando el cortafuegos saliente de Windows para crear una lista blanca
de servidores SMB a los que se accede

  • También se puede mejorar la configuración de Windows. Existe un truco poco conocido que permite hacer una lista blanca de con qué servidores SMB nos vamos a comunicar, y evitar enviar credenciales al resto. Primero hay que "Denegar todo" en la opción de seguridad correspondiente. Y luego alimentar la lista blanca de direcciones IP o nombres NetBIOS. 


Creando una lista blanca hacia servidores externos desde las políticas de seguridad

Por último, jugar con la posibilidad de firmar el protocolo SMB, pero resulta algo más complejo. En resumen, la propia Microsoft ofrece muchas herramientas para protegerse. Y la razón de que haya tantas es por flexibilidad: la mejor forma será la que cause menos incompatibilidad en el sistema en el que se aplique.


Sergio de los Santos
ssantos@11paths.com

Vote for Latch on the Internet Day awards 2015

viernes, 10 de abril de 2015




About Internet Day awards
Internet Day awards recognise those initiatives, persons and organizations that best use Internet and new technologies.

The entry
The main categories to Internet Day awards 2015 are: Best Web, Best Communication Campaign, Best Audiovisual Content, Best App Multidevice and Best Social Media Profile.

Latch app has been selected to participate in the Mobile App Multidevices category for the best app multidevice of year. Protected your accounts and online services. Discover the services where you can use Latch. Search for online services bearing the Latch: Protected badge and click on the logo to regain control of your digital life.

We can win with your vote.
Winners are selected from the on-line votes of Internet users together with the votes of a jury including recognised professionals from each category. Vote for Latch.

Thanks for being a part of Latch.

Dale tu voto a Latch en los premios Día de Internet 2015



Sobre los premios
El Día de Internet cumple ya una década desde que se celebró por primera vez como el Día Mundial de la Sociedad de la Información aquel 25 de octubre de 2005. Los premios del Día de Internet reconocen aquellas iniciativas, personas u organizaciones que más han destacado en el buen uso de Internet y las nuevas tecnologías.

La candidatura
Las categorías principales para la edición de 2015 son: mejor Web, mejor Campaña de Comunicación, mejor Contenido Audiovisual, mejor Aplicación para cada tipo de dispositivo y mejor Perfil en Redes Sociales.

La app de Latch ha sido seleccionada para la categoría de Aplicaciones móviles optando al premio de mejor aplicación multidispositivo del año. Descubre los servicios donde puedes usar Latch. Busca los servicios online con el distintivo Latch: Protected y recupera el control de tu vida digital.

Con tu voto podemos ser ganadores
Los ganadores son seleccionados con las votaciones on-line que realizan los usuarios de Internet y los votos de un Jurado compuesto por profesionales de reconocido prestigio para cada una de las categorías. Dale tu voto a Latch.

Gracias por ser parte de Latch.


Chema Alonso se incorpora al Consejo de Administración de Alise Devices

jueves, 9 de abril de 2015

En el sector de la tecnología, y concretamente en el de la seguridad, suele escasear el género femenino. A Beatriz Cerraloza, CEO de la Start-up Alise Devices, le echamos el ojo hace ya unos meses. Fue una de las sorpresas que os desvelamos en exclusiva en nuestro evento anual de innovación, Security Innovation Day 2014. Ella misma, en primera persona, nos habló sobre tecnologías de protección en documentos contra la suplantación de identidad, donde nos contaba que los ladrones de identidad mejoran cada día sus técnicas de falsificación, y por eso, es necesario innovar en los mecanismos de protección: «al igual que en la vida digital, aquí también hay una guerra. Una guerra entre los buenos y los malos. Nosotros somos los buenos y los malos que son los falsificadores».


Las falsificaciones de cosas, como pueden ser unas entradas para un concierto, los famosos bolsos de lujo, o incluso medicinas, son muy comunes. Falsificar cosas es un negocio que deja mucho dinero en el mundo hoy en día y por eso se crean medidas de seguridad físicas que permitan a los consumidores reconocer si el producto es genuino o falso. Pero para el resto de los mortales, reconocer si unas medicinas son falsas o no, se hace bastante complicado. Este hecho, nos demuestra una vez más que las medidas de seguridad están al alcance solo de los profesionales y no para todo el mundo. 

Los objetos más valiosos del mundo

Nuestro DNI o Pasaporte, están entre los objetos más valiosos del mundo y no precisamente por su valor material, si no por lo que significan y representan: nuestra identidad. Cuántas veces hemos sentido ese agobio repentino al darnos cuenta de que nos había caducado el DNI y como Murphy nunca falla, justo coincidía con que teníamos billetes de avión para un viaje con nuestros amigos. Y en el que, sin nuestro DNI o Pasaporte "en regla", nos íbamos a quedar en tierra, seguro.

El dinero es nuestro medio principal de intercambio, el más valioso y por tanto, uno de los más protegidos. Por eso, contienen medidas de seguridad, muchas veces imperceptibles a nuestros ojos, como pueden ser las medidas visuales, los hologramas, marcas de agua, o códigos numéricos dirigidas a usuarios finales además de incluir otras medidas dirigidas a usuarios no expertos.

En este mundo físico y de falsificaciones, Alise Devices ofrece una novedosa tecnología antifalsificación orientada a la protección de documentos oficiales como billetes, documentos de identidad y pasaportes, y destinada a ser verificada por el usuario final no experto.

Chema Alonso en el Consejo de Administración de Alise Devices

En la apuesta de Telefónica por seguir invirtiendo y participando en empresas pioneras para impulsar el desarrollo de una economía digital más segura, hoy anunciamos que Chema, se incorpora al Consejo de Administración de Alise Devices en calidad de representante del Grupo Telefónica. Esta incorporación refuerza la presencia de Telefónica en esta innovadora compañía, en la que ya estaba presente a través de Wayra España desde el 2013.

Desde su paso por Wayra, esta spin-off de la Universidad Politécnica de Madrid ha iniciado colaboraciones tanto con organismos oficiales emisores de documentos como con los principales líderes del sector a nivel global, para industrializar la integración de su medida de seguridad en diferentes documentos.

» Descargar Nota de Prensa

AdBlocks falsos en Chrome Web Store que llevan a... ¿adware?

martes, 7 de abril de 2015

Ninguna plataforma está libre del abuso. Chrome Web Store ha sido aprovechada como plataforma por creadores de adware en el pasado, principalmente inyectores de anuncios o malware en general. De hecho, Google acaba de eliminar casi 200 extensiones ofensivas que afectaban a 14 millones de usuarios. Pero, ¿y si las apps y las extensiones fueran "una vía" para convencer de la instalación de otro software o la visita de una página? ¿Apps y extensiones como fórmula de spam? Esto ha estado pasando durante un tiempo con "AdBlocks" falsos que llevan a otro anti-adware ruso, usando la Web Store como una plataforma para su spam.

Es, de alguna forma, una situación similar a cuando encontramos AdBlocks falsos en Google Play o el reciente uso de Google Play Books como plataforma para esparcir adware y malware. Chrome Web Store aloja AdBlocks falsos, una de las extensiones más populares para el navegador. Estas apps no son dañinas por sí mismas, puesto que se trata de redirectores a otros sitios desde donde se ofrecen otros programas. No resulta especialmente peligroso... por ahora. La técnica podría tener bastante éxito para los atacantes que quieran "spamear" su contenido, programas, adware o cualquier otra cosa. ¿Significa que Chrome Web Store almacena adware/malware directamente en estas extensiones o apps falsas? No, (alojan principalmente algunos inyectores de anuncios, pero intentan eliminarlos), pero lo que permiten es subir extensiones y apps falsas que se aprovechan de una marca reputada como AdBlock para confundir a los usuarios y conseguir que descarguen cualquier otra cosa. Nada nuevo, excepto por la plataforma utilizada. 

Cómo funcionan

Los AdBlock falsos detectados son típicas y simples apps de Chrome. Hemos encontrado el mismo programa con ligeras diferencias bajo distintas cuentas de desarrolladores. Aquí algunos ejemplos, (no todos aparecen a la vez):

Algunos de los AdBlocks detectados de diferentes desarrolladores

Estas apps no necesitan permisos. Algo extraño cuando no "imposible" si fuera el AdBlock real, puesto que estas apps deberían ser capaces de leer y modificar los datos de las páginas visitadas. Es más, deberían ser extensiones más que apps.


No necesitan permisos

Internamente, lo único que hacen estas apps es esto:

Código de los AdBlock falsos (en el fichero background.js)

  • chrome.runtime.onInstalled.addListener: Significa que, una vez se ha instalado la app, se abrirá la página del parámetro en Chrome.
  • chrome.app.runtime.onLaunched.addListener: Significa que, una vez se lance la app, se visitará la página en Chrome.
Las URLS se van modificando en diferentes apps subidas al Store.

Hacia dónde apuntan

Estos son los enlaces vistos hasta ahora:
  • hxxp://www.appforbrowsers.com/adguard.html
  • hxxp://www.surprisess.com/adguard.html
  • hxxp://www.appforchrome.com/adguard.html
Y estos son otros que, después de pasar por algún tipo de agregador de apps, redirigen al verdadero AdBlock.

  • hxxp://prodownnet.info/adblock-super/
  • hxxp://appstoreonline.blogspot.com/search/label/adblock%20chrome
  • hxxp://appstoreonline.blogspot.com/search/label/adblock%20youtube
La mayoría parece que llevan a páginas que animan al usuario a descargar un programa llamado Adguard. Se supone que se trata de un ad-blocker para PC que cuenta con sus propias extensiones para diferentes navegadores. ¿Es esto adware disfrazado de anti-adware? La respuesta nunca es fácil. Google bloquea el sitio de descarga cuando se visita con Chrome, al menos hasta hace unos días. Significa que Google (y puede que solo ellos) piensan que esta URL debe encontrarse en su lista negra.

Google bloqueando el punto de descarga del instalador Adguard
Sabemos que la app de Adguard fue eliminada (puede que por Google, puede que por otros) de Google Play el pasado diciembre. Además, algunos motores en VirusTotal piensan que se trata de algún tipo de malware, y lo detectan con firmas genéricas (excepto Rising, el antivirus chino).

Algunos motores que detectan Adguard
Podría tratarse de un falso positivo, algo que no ha sido ampliamente descubierto todavía, o quizás ese tipo de software que siendo legal, se mueve en la zona gris en la que los antivirus deben "respetarlo" y no detectarlo... pero que en cualquier caso resultan molestos y potencialmente dañinos para los usuarios una vez instalados.

La única forma de saberlo realmente, sería a través de un análisis manual. El análisis rápido del instalador muestra que cambia a menudo, y que se trata solo de un descargador de la instalación principal del programa: download.adguard.com/setup.exe que es el programa en sí y que, una vez más, es detectado por un motor con firmas genéricas, lo que no significa nada. Aunque Google y algunos AVs lo estén detectando, se trata, muy probablemente, de un programa que no resulta peligroso. Incluso es posible que no sean los responsables directos de estos falsos AdBlocks, puesto que podrían llevar un programa de recompensas por terceros que le proporcionen descargas.. quién sabe.

Conclusiones

Lo importante no es tanto que apps falsas de Chrome lleven a un bloqueador de anuncios, sino que las conclusiones podrían ser:
  • Obvio, pero cualquier plataforma es susceptible de que se abuse y "spamee" a través de ella. Chrome Web Store está siendo aprovechada de forma "inocente" (aparte de los inyectores de ads) con estas apps falsas, para inducir al usuario a visitar y descargar otro software. Usar el mismo nombre e icono que programas reputados como cebo, parece muy efectivo para los atacantes... pero también muy fácil de rastrear  y evitar para la Store.
  • Aunque parece redirigir a otro software en una campaña de spam que apunta a conseguir más visitas y poco más por ahora... ¿y si redirigiese a otra web? ¿Sería tan efectivo desde el punto de vista de los atacantes como los inyectores de anuncios con 14 millones de usuarios afectados? Puede que se vean más apps como estas en un futuro cercano que lleven a adware agresivo realmente o a malware.
  • Los usuarios deben tener cuidado a la hora de interpretar los resultados de los antivirus, para bien y para mal. Los falsos positivos se dan... y por supuesto también los falsos negativos. Pero con un ratio suficiente de cada grupo, el usuario medio nunca puede saberlo exactamente.

    El lanzador de apps de Chrome después de instalar algunos AdBlock falsos
Sergio de los Santos
ssantos@11paths.com

Fake AdBlocks in Chrome Web Store leads to... ¿adware?

No platform is free from abuse. Chrome Web Store has been abused in the past, mainly by ad injectors or general adware. In fact, Google has just removed almost 200 offensive extensions affecting 14 million users. But, what if apps and extensions are just the "way" to convince to install some other software or to visit a webpage? Apps and extensions as a spam technique? This has been happening for a while now with fake "AdBlocks" that leads to some other Russian anti-adware, using the Web Store as a spamming platform.

It is, in a way, a similar situation as when we found fake AdBlocks in Google Play and the recent use of Google Play Books as a platform for spreading adware and malware. Chrome Web Store is hosting fake AdBlocks, one of the most popular extensions for browsers. These apps (they are not extensions) are harmless "per se", since they are just redirectors to some other website where some other programs are offered. Not specially dangerous... by now. This technique may result quite successful for attackers that want to "spam" their content, programs, adware or anything else. Does this mean Chrome Web Store is storing adware/malware directly with these fake apps or extensions? Not at all (they are hosting ad injectors but trying to remove them), but they are allowing developers to upload fake extensions that take advantage of a reputed brand (like AdBlock) to confuse users and get them to download something else. Nothing new, except maybe for the platform used.

How they work

Detected fake AdBlocks are very simple typical Chrome apps. We have found the same program with little differences under several different developer accounts. Here are some samples (not all of them appeared at the same time):

Some of the AdBlocks detected from different developers


These apps need no permissions. That is strange and "impossible" if it was a real AdBlock, since these apps should be able at least to read and modify data in the websites you are visiting. Even more, they should be real extensions, rather than apps.

No permissions needed

Internally, the only thing these apps do is this:

Fake AdBlockPlus code (in background.js file)

  • chrome.runtime.onInstalled.addListener: Means that, once the app is installed, this webpage will be opened in Chrome. 
  • chrome.app.runtime.onLaunched.addListener: Means that, when it is launched, this webpage is opened in Chrome. 
URLS to go to are being changed all the time.

Where they go to

These are the links we have seen so far:

  • hxxp://www.appforbrowsers.com/adguard.html
  • hxxp://www.surprisess.com/adguard.html
  • hxxp://www.appforchrome.com/adguard.html

And there are some others that, after going to some kind of app aggregator, redirect to the real AdBlock.

  • hxxp://prodownnet.info/adblock-super/
  • hxxp://appstoreonline.blogspot.com/search/label/adblock%20chrome
  • hxxp://appstoreonline.blogspot.com/search/label/adblock%20youtube

Most of them open websites that encourage the user to download a program called Adguard. A supposed ad-blocker for PC that has its own extensions for different browsers. Is this adware disguised as an anti-adware? Not an easy answer. Google blocks the site if visited with Chrome, at least a few days ago. It means Google (and maybe just them) think or thought some day that this URL should be in a blacklist.

Google blocking adguard installer a few days ago

We know that Adguard app was removed (maybe by Google, maybe by the owners) from Google Play last December. Moreover, some engines in VirusTotal, think that this is some kind of malware, detecting it with generic signatures (except Rising, the Chinese AV).

Some engines detecting the AdGuard installer

It could be a false positive, something not widely discovered yet, or just this kind of software that are legal and moving on this grey zone where some AV engines have to "respect" them by not detecting them... but are harmful for users once installed anyway.

The only way to know it for sure, would be a manual analysis. A quick analysis shows that the exe itself is changing very often. It is just a downloader for download.adguard.com/setup.exe which is a much more complex program and, again, detected just by one engine with generic signatures... which means nothing. Although Google and some AVs are detecting it, it is, most likely, not a dangerous program. And, probably as well, they are not the ones directly responsible for these fake AdBlocks... They may have a rewarding program for websites bringing downloads... who knows.

Conclusions

The important thing is not fake Chrome Apps pointing to some adware blocker. The conclusions could be:
  • Obvious, but any platform is susceptible of being abused and "spammed". Chrome Web Store is being abused in an "innocent" way (aside the ad injectors) with fake apps, to induce the user to visit and download some other software. Using the same name and icon of reputed programs as a bait, is very effective for attackers... but easy to track and avoid for the store.
  • Although it seems to redirect to some software in a "spamming" campaign aimed to get more "visits" and that's all so far... what if it redirects to some other website? Would it be as effective from the attackers' standpoint as these ad injectors with 14 million affected users? We may see more apps like this in the future leading to real aggressive adware or malware.
  • Users have to be careful interpreting AV results, for good or bad, false positives exist... and of course false negatives do as well. But with enough ratio of both, the average user never really gets to know.

    The Chrome app launcher after installing some fake ABP
Sergio de los Santos
ssantos@11paths.com