XS-Leaks. XSS para extraer información sobre los usuarios

Centro de Exposiciones del Centro de Conocimiento sobre servicios públicos electrónicos. Almacenamiento.

En Introduction to Cross-Site Leaks (XS-Leaks) – Attacks and Mitigations hay una introducción a este ataque, que sirve para recolectar información acerca de los usuarios, a través de fallos de programación cruzada (Cross-site scripting (XSS)) y la utilización estos fallos para acceder a información como atributos de los usuarios, permisos, papeles (roles). Y también al historia de palabras de búsqueda y otras informaciones que se almacenan en memorias temporales (caches).

XS-Leaks then allow attackers to collect information about website visitors that is usually not available. This information can give the attacker clues about the user’s identity. This can include if the victim is logged into other web applications allowing access to user attributes, permissions, or roles. Additionally, a victim’s keyword search history can be queried as well as privately cached browser objects, such as images, based on how the website caches these resources.

Interesante.

Seguridad, facilidad de uso y pensar en las personas

Creo que ya lo he dicho aquí pero no me importa repetirme: la ciberseguridad tiene que ir de la mano de la usabilidad (ergonomía, comodidad, facilidad de uso ,…) y de la economía (¿cuánto cuesta? en todos los sentidos, se entiende). Y por ello nombro siempre que puedo Symposium on Usable Privacy and Security (SOUPS) y Workshop on the Economics of Information Security (WEIS). Trato de leer todos los años unos cuantos de los artículos que allí se publican. Hoy solo hablaremos de la parte de comodidad de uso. La economía queda para otro día.

Por este motivo me alegró leer When Security Gets in the Way que es de hace unos años, pero que hablaba del tema.

Both conferences were attended by experts in usability, security, and privacy. Both conferences emphasized that if we ever are to have systems with adequate security and privacy that people are willing to use, then the three fields must work together as a team. Without usable systems, the security and privacy simply disappears as people defeat the processes in order to get their work done.

Muchas veces las recomendaciones de seguridad son arbitrarias, y además los profesionales se las saltan sin demasiados problemas, nos dice:

We are being sent a mixed message: on the one hand, we are continually forced to use arbitrary security procedures. On the other hand, even the professionals ignore many of them.

Necesitamos mejor comprendes los problemas, las herramientas que proporcionamos a los desarrolladores y al resto de personas que interactuarán con los sistemas.

If this endeavor is to be successful, we need more understanding of the issues, better toolkits to deliver to developers, and a comprehensive set of tools, scripts, and templates to provide the administrative support staffs around the world so that the rules and polices they develop will be consistent both with one another and with best practices of the security and privacy community.

¿Es necesario que mejorar la seguridad haga todo más difícil de usar? Cuando sean necesarios pasos adicionales, ¿la gente se quejará? No necesariamente.

Does added security make things more difficult to use? Will people always resent the extra steps? The answer to both questions is the same: Not necessarily.

Más tarde comenta sobre uno de los fallos de este tipo, relacionado con las contraseñas: mitos, sobreactuación, …

Want a classic example of a failure? Passwords. There are several myths in the world about security, but the most pervasive of these has to do with password security. Look at Northwestern University’s password requirements: an over-reaction to the problem of password discovery through brute-force attacks.

Dice muchas más cosas. Lectura interesante.

Me he autocitado en el tuit de arriba porque el otro día me encontré un caso de una organización que ponía tantas dificultades a sus usuarios para utilizar el correo corporativo que terminábamos comunicándonos con ellos a través de sistemas alternativos de correo. Eso no es seguridad.

Generación de paquetes Android, seguridad y tranquilidad

El Android de Eduardo Siempre he pensado que en el mundo del sofware libre es difícil estar seguros de que estamos ejecutando el programa del que tenemos el código en dos situaciones: cuando instalamos un binario que alguien nos proporciona, o cuando utilizamos una aplicación web. Si hablamos de teléfonos móviles y las tiendas de aplicaciones, en muchas ocasiones miro en F-Droid antes de instalar una aplicación de la ‘tienda’ de Google. Es más fea y tiene menos programas, pero también nos da la tranquilidad (si nos instalamos programas con un historial razonable y gente confiable) de que estamos un poquito más cerca del desarrollador.

Por eso me gustó leer algunas novedades que anunciaron hace algunas semanas en Reproducible builds, signing keys, and binary repos.

Las construcciones reproducibles (reproducible builds) nos aportan garantías desde el punto de vista de poder verificar que lo que se instala corresponde, efectivamente, al código fuente asociado. A eso le han añadido la posibilidad de que el desarrollador firme los paquetes que instalamos, lo que nos protegería frente a un ataque malicioso que sustituyera algo en la plataforma.

A few advantages are pretty clear: higher trust is the first thing coming to mind, as now two parties (F-Droid and the developer) can both confirm the integrity of the distributed APK.

El artículo desarrolla un poco más algunos temas, pero dejamos a quien tenga interés su lectura.

Ciberseguridad, cumplimiento y gestión de recursos

Patio Mantengo la idea de que en un mundo en el que poca gente presta atención a la seguridad, parece que las únicas medidas que puedan ayudarnos un poco son las leyes. No lo digo solo yo, utilizo de vez en cuando un artículo de Bruce Schenier en el que hablaba del tema, Why Was SolarWinds So Vulnerable to a Hack? y me gusta citar un par de párrafos completos sobre el tema (los pongo al final).

El caso es que con las leyes, el cumplimiento y los procedimientos puede ocurrirnos que sigamos perdiendo de vista el objetivo, que es estar más seguros. De eso hablaban en Is the cybersecurity community’s obsession with compliance counter-productive?.

El ejemplo con el que empieza es ilustrativo: ¿alguien cree que en caso de accidente de nuestro avión tenemos más probabilidades de sobrevivir si las mesitas están correctamente plegadas y las maletas de mano están adecuadamente posicionadas en su lugar?

Does anyone think the chances of surviving a plane crash increase if our tray tables are locked and our carry-on bags are completely stowed under our seats?

Pero alguien lo indicó en alguna regulación y a nadie se le pasaría por la cabeza saltarse ese procedimiento.

Luego nos dice: casi todos los problemas de seguridad que aparecen en las empresas tienen que ver con vulnerabilidades no solucionadas, robo de credenciales y por ataques de programas maliciosos (que entran típicamente a través del phishing).

Esto no tiene mucho que ver con la normativa y, a lo mejor, centrarse en ella nos resta tiempo y personas para dedicarse a lo importante.

And how many would deploy those compliance and auditing resources to patch more vulnerabilities, invest in additional cybersecurity expertise, tools to identify and reduce their external threat footprint, and myriad other effective measures to genuinely reduce their organization’s cyber risk?

Luego reconoce que, seguramente, la gente de ciberseguridad sigue ese camino porque les permite tener las espaldas cubiertas.

The less obvious reason for our community’s love for compliance is that it covers behinds. “Yes, we were breached, but we did everything we were supposed to do, so don’t blame us.”

Pudiendo estar de acuerdo en la gestión de recursos creo que el autor pierde de vista que hay un número grandísimo de organizaciones que dedican cero recursos a la ciberseguridad. Así que, a lo mejor, poner leyes es una forma de obligarles a pensar en ella. En un mundo ideal todo el mundo haría su trabajo y, efectivamente, a lo mejor cada quien debería poder elegir a qué destina sus recursos. Pero el mundo no es así, lamentablemente.

Los párrafos de los que hablaba arriba:

There are two problems to solve. The first is information asymmetry: Buyers can’t adequately judge the security of software products or company practices. The second is a perverse incentive structure: The market encourages companies to make decisions in their private interest, even if that imperils the broader interests of society. Together these two problems result in companies that save money by taking on greater risk and then pass off that risk to the rest of us, as individuals and as a nation.

The only way to force companies to provide safety and security features for customers and users is with government intervention. Companies need to pay the true costs of their insecurities, through a combination of laws, regulations and legal liability. Governments routinely legislate safety — pollution standards, automobile seatbelts, lead-free gasoline, food service regulations. We need to do the same with cybersecurity: The federal government should set minimum security standards for software and software development.

Un ataque para viajar todo lo que se quiera en el metro de Boston

https://i.imgur.com/5UjaUYD Uno se sorprende de que todavía sucedan estas cosas (bueno, en realidad no, porque pasan con mucha frecuencia) pero tenemos lo que tenemos. Proteger algunos sistemas tiene sus propias dificultades, porque a veces supone adaptar dispositivos físicos, como pueden ser las tarjetas, los lectores, y otras infraestructuras, en un sistema de transporte. En Teens Hacked Boston Subway Cards to Get Infinite Free Rides—and This Time, Nobody Got Sued hablan del caso del metro de Boston donde unos quinceañeros consiguieron replicar un suceso de hace 15 años donde unos estudiantes ya habían conseguido viajar de manera gratuita en el metro de Boston. Y es que la historia se repite y estos quinceañeros consiguieron reproducir el ataque y mejorarlo, incluyendo la posibilidad de añadir cualquier cantidad de dinero a sus tarjetas, transformarlas en tarjetas de estudiante con descuento o incluso en una tarjeta de empleado con, claro, viajes gratis.

So the four teens extended other research done by the 2008 hacker team to fully reverse engineer the CharlieCard, the RFID touchless smart cards the MBTA uses today. The hackers can now add any amount of money to one of these cards or invisibly designate it a discounted student card, a senior card, or even an MBTA employee card that gives unlimited free rides. “You name it, we can make it,” says Campbell.

En esta ocasión, y por diferenciarse de la anterior, no sólo no han intentado bloquear la difusión de la investigación, sino que les han invitado a las oficinas del mentro a explicar cómo lo habían hecho. También, eso sí, les han pedido que expliquen poco alguna parte delicada, para que no sea tan fácil de reproducir.

El truco parece basarse en el análisis de varias tarjetas para observar en qué se parecen y en qué se diferencian, y así descubrir qué cambiar y cómo.

Muy interesante.