Algunas ideas para trabajar en ciberseguridad

Protección En So you want to work in security (but are too lazy to read Parisa’s excellent essay) algunas ideas interesantes si pensamos que trabajar en ciberseguridad podría ser una opción para nosotros.

  1. Ciberseguridad tiene que ver con la discordancia entre el comportamiento real del sistema y lo que esperaban que fuera el comportamiento sus diseñadores.
  2. Se trata de una protociencia. Mucha información, que todavía no tenemos bien organizada y en la que algo puede fallar donde menos se espera.
  3. La gente podrá confiar en nosotros, pero no hay forma de medir la efectividad de lo que hagamos.
  4. Puede que creas que eres más listo que los desarrolladores de software, pero no es así.

Principios de seguridad de Saltzer y Schroeder

Grabado en piedra Es bien conocida la frase de Groucho Marx: ‘Estos son mis principios. Si no le gustan… tengo otros’. Sin embargo, los principios tiene su interés y utilidad como conceptos o valores que nos guían en el comportamiento: cuando nos enfrentamos a una nueva situación o nos movemos en terreno incierto, los principios nos pueden ayudar a tomar decisiones.

En ese sentido traemos hoy aquí The Security Principles of Saltzer and Schroeder que presentaron sus principios sobre protección de la información en sistemas informáticos. Serían:

  • Economía en el mecanismo (tan simple y pequeño como sea posible).
  • Fallo en modo seguro por defecto (si algo va mal, el sistema queda en un estado seguro).
  • Mediación completa (para cada acceso a un objeto del sistema se debe comprobar la autorización).
  • Mínimo privilegio (Cada agente debe tener los permisos necesarios para realizar su tarea, pero no más).
  • Mínimo mecanismo común (no compartir estado entre diferentes agentes. Si alguien puede corromperlo, podrá influir en el comportamiento de los que dependan de él).
  • Separación de privilegios (separar las acciones de manera que cada una tenga permiso para realizar la parte que sea necesaria para su actividad; evitar hacer una única pieza que tiene permiso para realizar las distintas tareas).
  • Diseño abierto (el diseño no debería ser secreto o, al menos, su seguridad no debería depender de la ignorancia de los atacantes sobre sus internalidades).
  • Psicológicamente aceptable (si las reglas no son razonables, será difícil que sean aceptadas y seguidas con cierto rigor).

El autor juega con los principios y la saga de ‘Star Wars’ así que puede valer la pena echarle un vistazo, más allá de los principios.

Fuzzing para detección de fallos en Google

Líado Creo que hace un montón de tiempo que no hablábamos de Fuzzing: esencialmente (aunque últimamente se ha ido sofisticando) enviar basura diversa a las interfaces de entrada de los programas para detectar problemas de seguridad.

En Announcing OSS-Fuzz: Continuous Fuzzing for Open Source Software una iniciativa de Google para poner el sistema de fuzzing como servicio a disposición de desarrolladores de software libre. Ya ha servido para encontrar fallos en algunos proyectos:

OSS-Fuzz has already found 150 bugs in several widely used open source projects (and churns ~4 trillion test cases a week). With your help, we can make fuzzing a standard part of open source development, and work with the broader community of developers and security testers to ensure that bugs in critical open source applications, libraries, and APIs are discovered and fixed.

El proyecto está disponible en oss-fuzz con algo más de información.

Recordemos que Microsoft fue uno de los primeros promotores del fuzzing dentro de su ciclo de vida del desarrollo seguro (por cierto, más recientemente también ha puesto a disposición del público Microsoft opens fuzz testing service to the wider public y también que Coverity Scan es otro proyecto que ofrece sus servicios a los desarrolladores de software libre, desde otra perspectiva.

Consejos sobre seguridad para trabajadores en movilidad

Telefonía móvil Cuando todavía no tenemos clara la seguridad en los dispositivos fijos, nos está pasando por encima todos los aparatos móviles que lleva la gente, que se conectan a nuestras redes, a nuestros servidores y donde haga falta. En 10 ways to secure a mobile workforce, utilizando una de las formas más horribles de presentar la información en internet (pase de diapositivas), algunos consejos.

Yo me quedo con un par de ideas, la primera, que no podemos ser excesivamente rígidos o exigentes. Eso se volverá contra nuestras políticas de seguridad de manera inevitable. Las restricciones y las políticas deberían ser realistas:

If you implement policies that are too rigid or out of place with the current maturity of your company’s security program, chances are that your employees are going to subvert or ignore them altogether. If your employees find that the policies are strict, but workable, they will be more open to approaching you with issues or concerns on how they can meet policy and still get their work done.

La segunda, una con la que no solo estoy de acuerdo, sino que creo que todos tratamos de aplicar: cuando haya incidentes, aprovecharlos para recordar las partes relevantes de nuestras políticas de seguridad:

For example, when a well publicized security issue, like the resurfacing of the 2012 LinkedIn hack, it is a perfect opportunity to provide a refresher to personnel on the risk of password reuse and the benefits of strong passwords.

No debemos olvidar a la gente aunque estemos siempre tratando de mejorar la seguridad de nuestras organizaciones.

Innovación informática en el Gobierno de Gran Bretaña

Cuando celebrábamos el día del software libre No todas las noticias que nos llegan de Gran Bretaña son malas. Llevamos una buena temporada escuchando señales de su zona de internet donde se muestra que han decidido apostar por desarrollos abiertos, sostenibles, amigables…

En Open Source Development at the UK Government nos lo contaban y yo me anoté algunas cuestiones, que paso a detallar.

Primero, la voluntad de cambio de gobierno desde la tecnología, y que yo mismo me he apropiado ya en alguna ocasión. Hacer herramientas tan buenas que la gente quiera usarlas:

Our job is to change the way the government works, said Shipman. The UK government wants to provide digital services which are so good that people want to use them; services which are leading to better interaction between the government and citizen.

Además, proporcionar el código a los demás, hacerlo abierto, salvo que haya razones de seguridad para no abrirlo:

The UK government has committed to making code open; new code should be open by default, said Shipman. There might be exceptions for code to do with security or configuration, but even some of this code is becoming open.

Y no sólo proyectos infraestructurales y bibliotecas (que es lo que casi siempre se libera):

And not just libraries either. You can find the code for HMRC’s web frontends and domain-driven microservices that are actually running on gov.uk

Ojalá cunda el ejemplo. Nosotros, modestamente, trataremos de seguirlo.

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.