Seguridad y tranquilidad para los usuarios

Consejos de seguridad Una de las cosas que me está preocupando últimamente (sobre todo porque estoy implicado en la toma de decisiones sobre ello) es la de qué aconsejar (y exigir, en su caso) a los usuarios desde el punto de vista de seguridad. Hay una tentación fuerte de poner la normativa y decir que hay que seguirla. Pero, claro, eso muchas veces choca de frente con el usuario normal, que no tiende bien los términos técnicos, las razones detrás de las decisiones.

Por no hablar de que, simplemente, en la mayoría de las ocasiones los usuarios no deberían necesitar tomar decisiones. Ni siquiera ser conscientes de que alguien las tomó por ellos.

Además está acostumbrado a otras cosas que le simplifican la vida, en lugar de complicársela (¿Tienen Amazon o Google una política de contraseñas? Respuesta: no, han añadido sus propios controles y en caso de duda nos hacen ponerla otra vez, o utilizan el doble factor, o lo que sea…). También es fácil pensar que si nosotros lo comprendemos (¿seguro?), cualquiera podría.

En esa línea creo que va el estudio sobre el que se habla en Why asking you to change your password makes it easier to hack the system en el que se nos recuerda que enviar demasiados mensajes con restricciones sobre temas de seguridad hace que los usuarios se relajen y dejen de prestarles atención:

It’s an actual phenomenon, studied by behavioral scientists and computer security experts. It happens when users get bombarded with security warnings and demands for compliance. As a result, the studies show, three-quarters of computer users know how to make strong passwords but don’t practice what they know. It just seems too overwhelming.

También se habla del tema en ‘Security Fatigue’ Can Cause Computer Users to Feel Hopeless and Act Recklessly, New Study Suggests (y en muchos sitios más, la verdad).

Los consejos son simples: limitar el número de decisiones sobre seguridad que tiene que hacer el usuario, hacer que la decisión segura sea la sencilla, y tratar de que las decisiones se tengan que hace de manera consistente:

The data provided evidence for three ways to ease security fatigue and help users maintain secure online habits and behavior. They are:

  1. Limit the number of security decisions users need to make;
  2. Make it simple for users to choose the right security action; and
  3. Design for consistent decision making whenever possible.

No puedo estar más de acuerdo con estos términos y, desde luego, tenemos trabajo por hacer.

Inseguridad social

USB El otro día nos preguntábamos por las practicas de seguridad de la gente especializada en seguridad en ¿Se preocupa de la seguridad la gente de seguridad? y la conclusión era que no mucho. Hoy traemos el caso de la gente ‘normal’. Cualquiera que interaccione con temas relacionados con la seguridad y usuarios sabe que son presa fácil. Mensaje de Phishing: alquien caerá (y no por ser poco inteligente, estar poco preparado, o simple ignorancia; vas con prisas, no te fijas y adiós). No instales: alguien lo hará. Actualiza tu sistema (no, es que si lo actualizo deja de funcionarme Y)… Y así.

Pero, a veces, hay gente que se toma la molestia de hacer experimentos. Yo hace años empecé a utilizar unos que hicieron en una conferencia de seguridad muy importante en Londres como ejemplo, pero cada día surgen nuevos datos para mostrar. En esta ocasión, los discos USB: Does dropping malicious USB sticks really work? Yes, worryingly well…. Alguien dejó 300 memorias USB en una universidad y luego comprobó si alguien los había usado. El 98% fueron utilizados y un 45% no sólo fueron utilizados sino que la gente pinchó en los ficheros:

…we dropped nearly 300 USB sticks on the University of Illinois Urbana-Champaign campus and measured who plugged in the drives. And Oh boy how effective that was! Of the drives we dropped, 98% were picked up and for 45% of the drives, someone not only plugged in the drive but also clicked on files.

Luego se preguntaba a los que los abrían si querían responder a una encuesta.

¿Cosas malas que podrían haber pasado? (pero que no pasaron porque era un experimento).

Tal vez poner un ejecutable, o un fichero HTML que descargase cualquier cosa de internet.

The most basic – and simplest to conduct – attack would have seen malicious code placed in the HTML file that would have been automatically activated upon viewing, perhaps downloading further malware from the internet.

Pero el propio dispositivo USB podría haber contenido un simulador de un teclado y hacer lo que el atacante quisiera con la máquina del usuario.

A more sophisticated attack, however, would see the use of a device using HID (Human Interface Device) spoofing to trick a computer into believing that it was in reality a keyboard. As soon as the “USB stick” is plugged in it would inject keystrokes – building a set of commands that could open a reverse shell that could give a hacker remote access to the victim’s computer.

Espeluznante.

¿Se preocupa de la seguridad la gente de seguridad?

Candados La pregunta es una pequeña provocación y además ya hemos comentado en vidas anteriores que no siempre es así. En esta ocasión traemos Las CONs de Seguridad españolas suspenden en la configuración del SSL/TLS: En casa del herrero cuchara de palo donde se llega a la conclusión de que no.

Se trata de un análisis de la información en las páginas web (y la configuración del servidor correspondiente) de las CONs (conferencias de seguridad) españolas, comprobando los siguientes parámtros:

a) Autenticación

a.1.- Certificado del servidor

a.2.- Certificados adicionales

a.3.- Cadena de certificación

b) Configuración

b.1.- Protocolos

b.2.- Cifrados empleados

b.3.- Simulación de handshakes

b.4.- Detalles del protocolo

b.5.- Misceláneo

La conclusión es que los resultados no son lo que deberían. Es cierto que todos sabemos que la web de un congreso o actividad no tiene por qué ser lo más importante y que su configuración no afecta a lo que los organizadores saben/piensan, o que tal vez la ha hecho alguien que no es de la organización, … Pero hay una componente de ejemplo que no se debería descuidar:

Como conclusión y a la vista de los resultados, podemos decir que son muy mejorables en general las medidas de seguridad mínimas en cuanto a la implementación de protocolos empleadas en sus servidores. Por tanto, se da muy bien organizar todo tipo de CONs pero no tanto dedicar algo de tiempo a ser los primeros en dar ejemplo y tener los servidores correctamente configurados …

Seguridad en internet de las cosas

Cosas conectadas En How to Engineer Secure Things: Past Mistakes and Future Advice nos hablan de las cosas conectadas a internet y las seguridad.

Se centra en estos puntos: las actualizaciones (que deben realizarse, y debe hacerse de forma segura), la utilización insegura de la criptografía (con algunos consejos), diseño inseguro (para obtener aplicaciones seguras hay que diseñar pensando en la seguridad, no es algo que se pueda añadir después).

Probablemente la más propia (porque las otras dos se ven habitualmente en todo tipo de aplicaciones) sea la de las actualizaciones que creo que es el gran olvidado en los aparatitos conectables a internet a pesar del tiempo que ha pasado y lo que ha costado resolver (o, al menos, tener la infraestructura adecuada) el problema en los sistemas tradicionales.

Los nombres y la seguridad. El caso de Python y PyPI

Libro sobre Python Cada vez pasa menos tiempo desde que alguien describe un problema de seguridad hasta que alguien lo aplica de manera (más o menos) efectiva. Hace algún tiempo podíamos leer Typosquatting programming language package managers donde se hablaba de la posibilidad de utilizar los errores de tecleo de los usuarios para suplantar algunos paquetes bien conocidos de sitio PyPi, que es un repositorio público para alojar paquetes desarrollados en Python que luego pueden instalarse de forma muy sencilla.

En este caso el experimento consistió en crear 200 paquetes y subirlos al repositorio:

All in all, I created over 200 such packages and equipped them with a small program and uploaded them over the course of several months. The idea is to add some code to the packages that is executed whenever the package is downloaded with the installing user rights.

Estos paquetes contenían un cierto código que ‘llamaba a casa’ e informaba de su instalación.

El resultado fue interesante puesto que 17289 computadores instalaron estos programas:

In two empirical phases, exactly 45334 HTTP requests by 17289 unique hosts (distinct IP addresses) were gathered. This means that 17289 distinct hosts executed the program above and sent the data to the webserver which was analyzed in the thesis.

No sólo eso, sino que al menos 43.6% de esas IPs ejecutaron el programa de notificación con privilegios de administrador:

At least 43.6% of the 17289 unique IP addresses executed the notification program with administrative rights. From the 19603 distinct interactions, 8614 machines used Linux as an operation system, 6174 used Windows and 4758 computers were running OS X. Only 57 hosts (or 0.29%) could not be mapped to one of these three major operating systems.

Cuando lo estuve leyendo me pareció un trabajo muy interesante y supuse que los administradores de PyPI lo tendrían en cuenta y tomarían algún tipo de medida.

La sorpresa ha sido ver que no sólo no se han tomado medidas, sino que parece haber habido un ataque real: Ten Malicious Libraries Found on PyPI - Python Package Index. Se trataba de utilizar nombres similares e incluir código malicioso en ellos:

NBU experts say attackers used a technique known as typosquatting to upload Python libraries with names similar to legitimate packages — e.g.: “urlib” instead of “urllib.”

Se puede leer el aviso ‘oficial’ en http://www.nbu.gov.sk/skcsirt-sa-20170909-pypi/index.html. Allí también recuerdan la forma de detectar si hemos instalado alguno de estos paquetes:

pip list --format=legacy | egrep '^(acqusition|apidev-coop|bzip|crypt|django-server|pwd|setup-tools|telnet|urlib3|urllib) '

Y luego podríamos utilzar el pip uninstall <paquete> si es que tenemos alguno de esos.