Yuzi download

Los días 20 y 21 de Mayo tendrá lugar en la ciudad de Estambul “Locard Cyber Security Summit” un evento con carácter Internacional enfocado a la lucha contra el Cibercrimen, el enfoque será desde un punto de vista visionario, institucional, y a la vez técnico, por lo que apuesta por un equilibrio difícil de encontrar, sus fundadores: Musa Savas, Nurhan Demirel, y Igor Lukic somos los responsables en llevar a cabo dicha tarea y convertir el evento como referente en la región EMEA.

Figura 1: Locard - Istambul Ciber Security Summit

Uno de sus propósitos es rotar anualmente un país invitado como partner, este primer año le toca inaugurar a España por lo que el equipo inicial que lo forma son: servidor, Deepak Daswani, David Meléndez, Juan Garrido, junto a la participación del Grupo de Delitos Telemáticos de la Guardia Civil de la mano del Teniente D. Marcos Hermoso y Chema Alonso de Eleven Paths.

España es y debe seguir siendo reconocida como una potencia importante en el conocimiento de la Ciberseguridad, transmitir este conocimiento al mundo y la región de EMEA nos permite afianzar lo indiscutible, que tenemos en este país a grandes expertos en esta compleja industria.

El evento también cuenta con un importante apoyo de Turk-Telekom siendo el sponsor estratégico del evento, su CEO Rami Aslan dará un acto de inauguración del evento, junto al resto de autoridades turcas, como el Ministro de Transportes y Comunicaciones Binali Yldirim, o el responsable de la Ciberpolicia Turca Halvasan,  Ahmet Hamdi Atalay avalando la seriedad del congreso.

Figura 2: Ponentes de LOCARD

Por supuesto, Turquía dispone de buenos expertos en la materia de ciberseguridad como el conocido Ibrahim Balic, o Halil Ozturkci entre otros, como keynote especial Russell Hanson CEO de BrainBackups.com presentara su innovador proyecto que consiste en realizar copias de seguridad a nuestros cerebros, por lo que imaginarse un dump de un cerebro brillante para poder analizarlo puede ser más real de lo que parece.

El evento No se retrasmitirá en streaming en esta primera edición, por lo que aquellos que deseen asistir deberán de desplazarse a la ciudad de Estambul, pueden ampliar información de la agenda en Locard.org.

Autor: Igor Lukic (@igorlukic)

Llevo un tiempo estudiando y aprendiendo mucho sobre el mundo del Big Data. No es que el mundo del Big Data fuera un gran desconocido para mí, pero he querido focalizarme este tiempo en dedicar más esfuerzos en jugar un poco más a fondo con las tecnologías más populares y unirlo con mi pasión por la seguridad informática. Hay muchas caras, a diferentes niveles, en el prisma que se crea cuando se juntan las tecnologías de Big Data y las de Seguridad Informática.

Quizá la más evidente es la posibilidad de crear nuevas herramientas de seguridad que manejen grandes volúmenes de datos para tener plataformas que antes no se podían ni imaginar imaginar. Nuestros servicios Tacyt, Sinfonier, Faast, Sandas o CyberThreats son claros ejemplos de tecnologías de seguridad que antes no eran ni imaginables sin el incremento en el volumen de datos que es posible manejar a día de hoy con ellas. 

Por supuesto, el gran manejo de datos que es posible realizar hoy en día permite a las empresas capturar detalles, insignificantes a priori, de sus usuarios que llevan a un conocimiento tal de los mismos que la privacidad queda en serio riesgo. Exponente de este tipo son las tecnologías de WebBrowsing Fingerprinting que son capaces de llegar al mínimo detalle de los usuarios para saber quién es quién sin necesidad de que se lo diga. De esto hice una charla hace ya unos años.

Otra de las caras del prisma en el que convergen la seguridad y el mundo del Big Data son los servicios de pentesting y auditoría de los mismos. No son nuevos los problemas con estos entornos, como ya vimos en el caso de los servidores MongoDB que podemos localizar por Internet sin ningún control de seguridad, y con todos los datos expuestos con solo hacer un poco de hacking con buscadores. Además, tampoco son inmunes a las técnicas de inyección de comandos, como ya vimos en el artículo de técnicas de MongoDB Injection.

Pero esto se exacerba aún más cuando vemos la gran miriada de tecnologías que Big Data que aparecen y desaparecen rápidamente. Cómo una tecnología puede o no eclosionar en este mundo y desaparecer rápidamente. Es un entorno joven en el que las tecnologías más conocidas apenas tienen unos años de vida. La primera versión de MongoDB es del año 2009 y la primera de Apache Cassandra es del año 2010 - aunque el proyecto lo liberara Facebook en el año 2008 -.

Cassandras inseguros en Internet

De esas primeras versiones a meterse de lleno en el mundo de las empresas aún les faltaría un tiempo, así que podemos decir que son tecnologías que se han hecho populares en los últimos tres o cuatro años. Si miramos el ecosistema de aplicaciones creadas alrededor de ellas aún estamos hablando de proyectos mucho más jóvenes de dos, tres años de vida, por lo que aún están lejos de alcanzar la madurez a la que deberán llegar si sobreviven.

En muchos de estos entornos nos volvemos a encontrar los mismos errores de pasado una y otra vez, y debido a su juventud no es complicado ver que muchas de ellas adolecen de seguridad por defecto en sus plataformas. Al igual que sucedía con MongoDB, con las bases de datos Cassandra sucede un poco lo mismo. Cassandra es una base distribuida en la que los datos almacenados se copian en diferentes nodos con un factor de replicación y es fácil localizar muchos entornos en los que no hay ninguna autenticación por defecto. 

Es tan sencillo como realizar una búsqueda en Shodan - o en Censys - por el puerto 9160 y localizar las bases de datos de Cassandra que no tienen ninguna autenticación Shodan ya lo pone fácil ya que basta con localizar aquellos en los que los KeySpaces están disponibles en los resultados. En la imagen se puede ver que hay casi 2.000 bases de datos alcanzables directamente por el puerto 9160 desde Internet.

Una vez que se localiza una base de datos que tiene abierto el sistema sin ninguna autenticación, es fácil ir al siguiente paso y buscar algún cliente para conectarse a ellas y analizarlas. No hay tantos por Internet, pero se pueden utilizar alguno como Helenos o Datastax OpsCenter.

La gracia es que estas tecnologías, como el caso de Datastax OpsCenter son también muy jóvenes y también adolecen de problemas de seguridad por defecto. De hecho puede realizarse una búsqueda en Google para localizar paneles de Datastax OpsCenter abiertos a Internet que ya contienen clusters de bases de datos Cassandra expuestas a todo el mundo.

También se pueden localizar por medio de Shodan sacando la firma "Server:" del software utilizado, algo que ya sabemos que hay que quitar para evitar el dorking, y que en este caso es Twistedweb por el puerto 8888, y localizar algunos paneles más que tienen abierto el panel sin autenticación alguna.

Desde estos paneles se puede gestionar la lista de clusters que estén ya conectados, o conectar un nuevo cluster de Cassandra de los que Shodan informa que están abiertos al público. Es decir, localizando un panel de OpsCenter se puede usar dicho servidor para gestionar remotamente un cluster Cassandra ubicado en otro lugar de Internet.

Este es solo un ejemplo de cómo errores del pasado se repiten una y otra vez, y en este nuevo entorno de tecnologías de Big Data es fácil localizar muchas nuevas herramientas que hay que fortificar con el mismo cariño que las más tradicionales. Como esto da mucho juego, en las siguientes partes - porque serán varios artículos sobre este tema - os iré contando cómo están otras herramientas utilizadas habitualmente en el mundo de las tecnologías Big Data.

Saludos Malignos!

El próximo 25 de Mayo hará 6 años que, desde el equipo de Informática 64 reportamos al equipo de seguridad de Chromium que en Google Chrome 4 había un comportamiento anómalo de seguridad por como gestionaba las opciones de protección contra la carga del contenido que se hace en una página web. Básicamente, existía un caso en el que aún habiendo sido bloqueada la carga de contenido JavaScript desde un determinado dominio, si este se metía en un iframe se saltaba esta protección.

Para estudiar aquel caso se abrió un ID en el sistema de reporte de bugs con el número 44985 donde dejamos toda la información. Al principio, algunos de los ingenieros defendieron ese comportamiento y lo llegaron a calificar como un problema en la explicación de la "Feature", por lo que en la clasificación le asignaron un "WordFix" y lo dieron por cerrado en una primera catalogación.

Por supuesto, al poco, comenzó el debate cuando algunos ingenieros no tenían tan claro que ese debiera ser el comportamiento de Google Chrome ante el contenido cargado desde un iframe si el usuario había expresado claramente que no quería cargar ningún JavaScript desde un determinado dominio - viniera o no ese contenido en un iframe -, por lo que se volvió a abrir y se convirtió en una "Issue" en una segunda catalogación.

Con el paso del tiempo, este "Issue" se unió con otras conversaciones que fueron apareciendo posteriormente durante el año 2014 y se le asignó el ID 444744 para que lo estudiaran. En ese momento, la catalogación de este Issue pasó a ser de Privacy & Security-UX Feature con prioridad 3 para ser arreglada.

Con este tratamiento, ya se puso en la cola de tareas a corregir, pero aún no se pusieron manos a la obra a corregirla. Tendríamos que esperar aún un par de años para que esto se tomara de otra forma.

Como yo abrí el caso, cada vez que hay un cambio en el estado de este "Issue" recibo una alerta, y la última me ha traído como sorpresa que ha sido recatalogado esta vez como Security & Privacy Bug con prioridad 2. 

Es decir, la Feature mal explicada que se catalogó inicialmente como un WordFix, que luego se catalogó como Issue, que luego se puso como Privay & Security-UX Feature, ha terminado como Security & Privacy Bug al cabo de 6 años. Hemos pasado de la versión 4 a la versión 49 de Google Chrome, pero nunca es tarde si al final lo acaban corrigiendo.

Saludos Malignos!

Posted by Isabella Chen, Software Engineer

We launched a fully revamped Sign-In API with Google Play services 8.3 providing a much more streamlined user experience and enabling easy server authentication and authorization. We’ve heard from many developers that they’ve found these APIs simple and less error prone to use. But when we look at applications in the Play Store, we see many that are still using legacy Plus.API / GoogleAuthUtil.getToken and do not follow best practices for authentication and authorization. Not following best practices can make your apps easily vulnerable to attack.
It’s also worth noting that developers who don’t want to worry about managing the security implications of different API flows or keeping up to date with the latest  APIs can use Firebase Authentication to manage the entire authentication lifecycle.

Ensuring your apps are secure

Developers should ensure that their apps are not open to the following vulnerabilities:

• Email or user ID substitution attack After signing in with Google on Android, some apps directly send email or user ID in plain text to their backend server as the identity credential. These server endpoints enable a malicious attacker to easily forge a request and gain access to any user’s account by guessing their email / user ID.
  
  Figure 1. Email / User ID Substitution Attack
  We see a number of developers implement this anti-pattern by using getAccountName or getId from the Plus.API and sending it to their backend.
  
  Problematic implementations, DO NOT COPY
  

• Access token substitution attack After signing in with Google on Android, many apps send an access token obtained via GoogleAuthUtil.getToken to their backend server as the identity assertion. Access tokens are bearer tokens and backend servers cannot easily check if the token is issued to them. A malicious attacker can phish the user to sign-in on another application and use that different access token to forge a request to your backend.
  
  Figure 2. Access Token Substitution Attack
  Many developers implement this anti-pattern by using GoogleAuthUtil to retrieve an access token and sending it to their server to authenticate like in the following example:
  
  Problematic implementation, DO NOT COPY

Solution

1. Many developers who have built the above anti-patterns into their apps simply call our tokenInfo (www.googleapis.com/oauth2/v3/tokeninfo) which is debug-only or unnecessarily call the G+ (www.googleapis.com/plus/v1/people/me) endpoint for user’s profile information. These apps should instead implement our recommended ID token flow explained in this blog post. Check out migration guide to move to a both secure and efficient pattern.
2. If your server needs access to other Google services, e.g. Drive, you should use server auth code flow. You can also check out this blogpost. Worth mentioning, you can also get an ID token using server auth code flow, from which you can retrieve user id / email / name / profile url without additional network call. Check out the migration guide.

Improving the user experience and performance of your apps

There are still many apps using GoogleAuthUtil for server auth and their users are losing out the improved user experience while the developers of those apps need to maintain a significantly more complicated implementation.
Here are some of the common problems that we see:

Requesting unnecessary permissions and displaying redundant user experience

Many apps request GET_ACCOUNTS permission and draw their own customized picker with all email addresses. After getting the email address, the app calls either GoogleAuthUtil or Plus.API to do OAuth consent for basic sign in. For those apps, users will see redundant user experience like:
Figure 3. GET_ACCOUNTS runtime permission and redundant user experience

The worst thing is the GET_ACCOUNTS permission. On Marshmallow and above, this permission is displayed to the user as ‘Contacts’. Many users are unwilling to grant access to this runtime permission.

Solution

Switch to our new Auth.GOOGLE_SIGN_IN_API for a streamlined user consent experience by providing an intuitive one-tap interface to provide your app with the user’s name, email address and profile picture. Your app receives an OAuth grant when the user selects an account, making it easier to sign the user in on other devices. Learn more

Figure 4. New streamlined, one-tap sign-in experience

Getting ID Token from GoogleAuthUtil for your backend

Before we released revamped Sign-In API, GoogleAuthUtil.getToken was the previously recommended way to retrieve an ID token via a “magic string.”

Wrong pattern, DO NOT COPY

GoogleAuthUtil.getToken needs to take an email address, which usually leads to the undesirable user experience in Figure 3. Also, user’s profile information like name, profile picture url is valuable information to store in your server. The ID token obtained via Auth.GOOGLE_SIGN_IN_API will contain profile information and your server won’t need additional network calls to retrieve them.
Solution Switch to the ID token flow using the new Auth.GOOGLE_SIGN_IN_API and get the one-tap experience. You can also check out this blogpost and the migration guide for more details.

Getting auth code from GoogleAuthUtil for your backend

We once recommended using GoogleAuthUtil.getToken to retrieve a server auth code via another “magic string.”

Wrong pattern, DO NOT COPY

In addition to the possible redundant user experience in Figure 3, another problem with this implementation was that if a user had signed in to your application in the past and then switched to a new device, they would likely see this confusing dialog:

Figure 5. Confusing consent dialog for returned user if using GoogleAuthUtil.getToken for auth code
Solution

To easily avoid this “Have offline access” consent dialog, you should switch to server auth code flow using the new Auth.GOOGLE_SIGN_IN_API . We will issue you an auth code silently for a previously signed-in user. You can also check out this blogpost and migration guide for more info.

Should I ever use GoogleAuthUtil.getToken?

In general, you should NOT use GoogleAuthUtil.getToken, unless you are making REST API call on Android client. Use Auth.GOOGLE_SIGN_IN_API instead. Whenever possible, use native Android API in Google Play services SDK. You can check out those APIs at Google APIs for Android.
And starting from Google Play services SDK 9.0, you will need to include -auth SDK split to use GoogleAuthUtil.getToken and related classes
AccountChangeEvent/AccountChangeEventsRequest/AccountChangeEventsResponse.
dependencies { compile com.google.android.gms:play-services-auth:9.0.0 }

Ever since I updated to the June Security Patch, Ive been having a problem with the recents screen. Usually about once a day, it will state that there are no recent apps when I push the recents capacitive button. I have to reboot in order for any apps to appear in the recents screen again.

Anybody else have this problem? And more importantly, does anybody have a solution?