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.
]]>Si vuestros sistemas son tan 'seguros' que se convierten en difíciles o incómodos de usar, la gente utilizará alternativas. Para cosas del trabajo. Aplica especialmente al correo y sistemas de mensajería
— fernand0 (@fernand0) February 20, 2024Creo 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.
]]>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.
]]>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.
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.
]]>Hay una cita por ahí que parece que dijo el informático Donal Knuth y que se suele escribir como: ‘la optimización prematura es el origen de todos los males’
premature optimization is the root of all evil
Bien entendido, claro, que se refería al contexto de la programación y el desarrollo de programas (aunque seguramente se pueda aplicar en más casos). Sin embargo, también es cierto que en algún momento hay que optimizar (sobre todo para programas o bibliotecas de uso amplio, donde una pequeña mejora puede hacer que nuestros programas sean mucho mejores).
El año pasado alguna gente de Google publicaron Faster sorting algorithms discovered using deep reinforcement learning donde se hace justamente eso: con aprendizaje reforzado profundo tratan de obtener versiones mejores de los algoritmos que se utilizan habitualmente.
El resultado es interesante, pero lo que más llamó mi atención (sobre todo porque lo contamos en clase, en una versión mucho más grosera y poco refinada) como el manejo de los problemas de tamaño más pequeño puede ser el que marque la diferencia. En este sentido, se pueden ver en el artículo análisis bastante refinados de código en c++, sus versiones en ensamblador y cómo algunas instrucciones pueden ser importantes a la hora de obtener soluciones eficientes.
Por ejemplo, en la figura 4 se puede ver cómo el algoritmo original proponía evaluar la longitud de lo que se quería ordenar y según fuera 2, 3, ó 4, se lanzaba un algoritmo diferente. La propuesta de AlphaDev, sin embargo, primero mira si el tamaño es 2 y lanza un algoritmo especializado, si no, lanza el algoritmo para ordenar 3 elementos; si la longitud ya era 3 el vector ya estará ordenado, y si no lo era, llama a un algoritmo especializado en ordenar 4 con los 3 primeros ya en orden.
A flow diagram of the variable sort 4 (VarSort4) human benchmark algorithm. In this algorithm, a sequence of unsorted numbers are input into the algorithm. If the sequence length is four, three or two numbers, then the corresponding sort 4, sort 3 or sort 2 sorting network is called that sorts the resulting sequence. The result is then returned and output by the function. b, The VarSort4 algorithm discovered by AlphaDev. This algorithm also receives sequences of length four, three or two numbers as input. In this case, if the length is two, then it calls the sort 2 sorting network and returns. If the length is three then it calls sort 3 to sort the first three numbers and returns. If, however, the length is greater than three, then it calls sort 3, followed by a simplified sort 4 routine that sorts the remaining unsorted number. It is this part of the routine that results in significant latency savings.
No sé si las palabras (o el gráfico) ayudan a entender bien de lo que estamos hablando pero, desde luego, nos dan una pista de cómo pequeños detalles pueden marcar una diferencia.
Se puede leer un texto de carácter más divulgativo en AlphaDev discovers faster sorting algorithms
]]>La semana pasada decía que nadie lee esto y algunas personas me dijeron que sí (hasta alguna errata habían detectado). Reconforta mucho recibir esos comentarios y la realimentación, ¡Muchas gracias!
Programamos con un conjunto de suposiciones bastante básicas (acerca del sistema, el almacenamiento, la memoria, el procesador, …), pero a veces puede ser interesante conocer un poco mejor cómo funcionan las cosas para sacar partido (o no meter la pata) de lo que estemos usando.
Sobre la memoria podemos leer What every programmer should know about memory, Part 1 que ya tiene unos años, pero que nos puede dar pistas interesantes. Hay hasta nueve partes, que se pueden ver enlazadas al final del texto, justo antes de los comentarios (se echan de menos, ¿eh? Casi nadie los mantiene por la selva en que se ha convertido la red en algunos aspectos).
]]>In the early days computers were much simpler. The various components of a system, such as the CPU, memory, mass storage, and network interfaces, were developed together and, as a result, were quite balanced in their performance. For example, the memory and network interfaces were not (much) faster than the CPU at providing data.
Después de la calurosa recepción de los comentarios sobre artículos de investigación (es broma, creo que podría escribir al revés aquí y nadie diría nada) traemos otro que me resultó intersante: Password policies of most top websites fail to follow best practices.
Y es intersante, porque con todo lo que vamos sabiendo sobre las contraseñas, muchos sitios siguen usando políticas viejas, anticuadas y hasta desaconsejadas.
En el resumen nos dicen:
We examined the policies of 120 of the most popular websites for when a user creates a new password for their account. Despite well-established advice that has emerged from the research community, we found that only 13% of websites followed all relevant best practices in their password policies. Specifically, 75% of websites do not stop users from choosing the most common passwords—like “abc123456” and “P@$$w0rd”, while 45% burden users by requiring specific character classes in their passwords for minimal security benefit. We found low adoption of password strength meters—a widely touted intervention to encourage stronger passwords, appearing on only 19% of websites. Even among those sites, we found nearly half misusing them to steer users to include certain character classes, and not for their intended purpose of encouraging freely-constructed strong passwords.
De las buenas prácticas que se recomiendan habitualmente, nos dicen:
El resultado: 71 de 120 sitios no comprueban la contraseña en absoluto, permitiendo 40 de las más frecuentes.
La recomendación. Rechazar la contraseña si aparece en alguna de estas listas. El resultado: De los que las comprueban, 19 bloquean menos de la mitad de las listas de contraseñas comunes.
La recomendación: proporcionar información en tiempo real sobre la estimación de complejidad de las contraseñas.
El resultado: Sólo 23 de los 120 sitios comprobados tenían medidor de la calidad.
El resultado: de los 23 anteriores, 10 utilizan medidores basados en el tipo de caracteres que se utililiza, sin prestar atención a nada más.
El resultado: 54 de 120 sitios exigen el cumplimiento de reglas sobre los caracteres.
El resultado: 66 de los 120 sitios exigen esa longitud, al menos.
Las conclusiones son:
Se puede descargar el artículo en [PDF] Password policies of most top websites fail to follow best practices, la [PDF] presentación de Password policies of most top websites fail to follow best practices y ver el vídeo en Password policies of most top websites fail to follow best practices.
]]>Últimamente tenía la impresión de que se ha convertido en tendencia anunciar que hemos sido víctimas de un ataque informático, decir que han utilizado medios muy sofisticados y seguir con nuestra vida. Esa impresión significaba, para mi, que era una forma fácil de eludir contar lo que había sucedido (y los medios se conformaban con la explicación, que ya les parecía suficiente). El caso ese que descubrí hace no mucho (aunque tiene más de un año) el trabajo: [PDF] A “sophisticated attack”? Innovation, technical sophistication, and creativity in the cybercrime ecosystem publicado en WEIS 2022 que parece apoyar lo que suponíamos:
We observe that almost every cybercrime is reported to be a “sophisticated attack” and explain how incentives align to misrepresent very run-of-the-mill events in this manner. We describe the cybercrime ecosystem, analysing the distinct parts and discussing what forms of sophistication and incentives can be found in each kind of work. We move on discuss how framing cybercrime as technically sophisticated attacks performed by skilled criminals has distorted criminological analysis and contributed to misaligned incentives within criminal justice and security policy. We conclude that the criminal justice system is aiming the wrong types of interventions at the wrong kinds of actor.
La cuestión es que nadie hace casi nunca más trabajo del necesario y que, en muchos casos, con poco esfuerzo se consiguen grandes resultados, al menos en el mundo de los ataques informáticos.
De las conclusiones:
We argue that this mis-attribution of sophistication is not a mere irritation or fringe issue, i.e. something which security professionals and academics might decry on social media but which bears no real impact; it is in fact contributing to a far wider mood music within law enforcement and sentencing practice, and academia that has had serious negative effects. As long as this narrative of sophistication persists, it creates perverse incentives to widen the net of law enforcement, to design interventions along misleading lines, and to draw attention away from the real drivers of harm.
Esto es, no hay tantos expertos capaces de realizar atanques verdaderamente sofisticados y esta banalización de la información puede llevarnos a tomar malas decisiones y a enfocar el problema de manera inadecuada.
En el artículo definen media docena de tipos de atacantes, que puede ser interesante señalar:
En este caso hablamos de incentivos y motivaciones económicas complejas, aunque esta es una pequeña parte de todo el ecosistema. Es costosa en tiempo, conocimientos, …
Aquí ya tenemos a personas con buenos conocimientos de lo que han encontrado otros. Son hábiles en aplicar este conocimiento y realizar los ataques. Aquí entraría la parte económica relacionada con la realización del ataque (o la defensa) y la venta de este conocimiento a quien lo pueda demandar.
Los ataques se han convertido en muchos casos en ataques como servicio ‘crime as a service, lo que significa que aparecen organizaciones que proporcionan las herramientas para que otros las usen en su propio beneficio. Esto ocurre tanto en las herramientas de ataque, como en la infraestructura necesaria para desplegarlas y no tener que preocuparse demasiado de ellas.
Esencialmente, los usuarios de las herramientas y los servicios anteriores, que sacan provecho de su conocimiento de la infraestructura.
Son gente que está empezando y que usan los servicios de otros sin mucho conocimiento, simplemente siguiendo guías y recomendaciones que otros han preparado.
No sólo hay gente interesada en estos asuntos por el dinero, sino también por ideales, ideología o principios ‘más elevados’. Son pocos, muy motivados y con muy diversos niveles en sus capacidades tecnológicas.
Por cierto, que esta clasificación me ha recordado otro artículo interesante I Watched You Roll the Die: Unparalleled RDP Monitoring Reveal Attackers’ Tradecraft donde clasificaban a los atacantes en cinco categorias:
Bardos (bards), sin un gran nivel cuyo único objetivo es usar sistemas informados para sus propios intereses (muchas veces de simple entretenimiento, accediendo a recursos que no tienen disponibles por el motivo que sea).
Guardabosques (rangers), que exploran los sistemas y encuentran algunos vulnerables o poco progegidos, abriendo el camino para otros atacantes.
Ladrones (thieves), que son los que tratan de obtener beneficio económico de los sistemas atacados.
Bárbaros (barbarians), que serían los que usan herramientas, básicamente mediante fuerza bruta, para entrar en diversos sistemas.
Magos (wizards), que utilizan estos recursos para esconder su verdadero oriigen y poder realizar acciones de su interés.
En este caso se trata de una honeynet utilizada para ver cómo se comportaban diferentes agentes que utilizan ataques a través de las herramientas de escritorio remoto RDP. Los autores habrían observado a los atacantes y su actividad cuando descubrían los recursos vulnerables.
Se puede leer algo de información en How Unparalleled RDP Monitoring Reveal Attackers’ Tradecraft
]]>Hace no mucho cayó en mis manos el artículo: I Don’t Need an Expert! Making URL Phishing Features Human Comprehensible donde se pueden leer algunas ideas sobre el phishing y las URLs y lo difícil que puede llegar a ser darse cuenta de que estamos siendo engañados.
Judging the safety of a URL is something that even security experts struggle to do accurately without additional information. \changed{In this work, we aim to make experts’ tools accessible to non-experts and assist general users in judging the safety of URLs by providing them with a usable report based on the information professionals use.} We designed the report by iterating with 8 focus groups made up of end users, HCI experts, and security experts to ensure that the report was usable as well as accurately interpreted the information. We also conducted an online evaluation with 153 participants to compare different report-length options. We find that the longer comprehensive report allows users to accurately judge URL safety (93% accurate) and that summaries still provide benefit (83% accurate) compared to domain highlighting (65\% accurate).
Creo que merece la pena su lectura (se puede descargar de [PDF] I Don’t Need an Expert! Making URL Phishing Features Human Comprehensible) para repasar conceptos básicos sobre las URLs, pero también para ver cómo los expertos se enfrentan al problema y echarle un vistazo a los datos que aparecen. En particular, yo tuve la oportunidad de hacer la prueba que indica en la Tabla 3 con un grupo y fue bastante ilustrativo (incluso para mi mismo, que no era perfectamente capaz de identificar todos los casos). Arriba también se puede ver el vídeo de la presentación en el congreso del ACM Special Interest Group on Computer-Human Interaction (SIGCHI). Arriba hay un vídeo de la presentación del artículo.
]]>