¿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.

Aleatoriedad y juegos interesantes

Dados

Volvemos a hablar de aletoriedad. En esta ocasión How Stellaris fails to solve strategy gaming’s “bad luck” problem habla de juegos y del compromiso entre hacerlo suficientemente interesante, a la vez que impredecible:

Designing a game that’s both random and consistently engaging is a problem I thought about constantly during my recent time with Stellaris, Paradox’s latest epic space strategy game.

Porque, claro, una cosa es que sea aleatorio (soprendente, impredecible, …) y a la vez las decisiones que haya que tomar (o que se puedan tomar) hagan que el juego mantena el interés:

Developers should be expected to ensure that most (if not all) of their “randomized” strategy campaigns at least encourage the players to make interesting choices.

Lectura interesante.

¿Cómo son las preguntas de seguridad?

Puerta

Las preguntas de seguridad son esas que algunos proveedores utilizan para tratar de asegurarse de que somos nosotros cuando tratamos de reactivar nuestra contraseña principal olvidada. Es un método bastante denostado (Ver, por ejemplo Recuperación de contraseñas con preguntas personales aunque también tienen sus defensores (sobre todo, en condiciones adecuadas: Las claves).

En todo caso, traemos hoy aquí una nota sobre Estudio de contraseñas cognitivas en la filtración de datos del Banco Nacional de Catar (QNB) donde los usuarios podían elegir las preguntas. Aquí llaman preguntas cognitivas a esas preguntas de seguridad.

La ¿sorpresa?:

Si les dan a elegir, repiten los patrones impuestos desde siempre por los servicios en la red… el nombre de soltera de la madre, mascotas, gustos, lugar de nacimiento… todos datos muy fácilmente deducibles o con un rango de error muy pequeño con fuerza bruta (¿cuál es tu color favorito?). Muy pocos echan mano de la imaginación.

Al menos para los usuarios VIP. Aunque el resto de clientes tampoco parece echarle mucha imaginación.

Según Sergio de los Santos:

La solución es mentir si nos obligan a usar esas contraseñas cognitivas, empleando cadenas aleatorias a modo de contraseñas que, junto con la real del servicio, serán almacenadas en un buen gestor de contraseñas (sabiendo que, si se almacena bien la real, ni siquiera se necesitarán las cognitivas).

Si no usamos el gestor, como decían en uno de los artículos enlazados arriba, tendremos problemas.

Un programador aburrido

La tendencia ya la conocemos: gente súper-chachi que hace cosas súper-molonas y que se deja la vida en ello. Parece que es un modelo popular y que nos hace imaginar momentos gloriosos porque, ¡oh sorpresa!, casi siempre terminan bien.

I'm a rocker

Sin embargo, cuando hablamos de programas (y de sistemas informáticos en general) lo que esperamos para que todo vaya bien es un comportamiento aburrido: siempre igual, predecible, que no falle y que no haya que dejarse la vida para conseguir nuestros objetivos. Eso sí, esperamos que sean muy emocionantes y nos llenen la vida de ilusiones (vale, muchas veces tampoco, que al final todo es trabajo, resolver problemas y marcharnos a casa tranquilos).

Por eso me gustó leer I’m a boring programmer (and proud of it) donde habla justamente de estas cosas.

El autor prefiere el silencio y el orden:

Instead, like a librarian I enjoy quiet and order. When code is well organized, things are easy to find and less likely to break, avoiding a bunch of noise and heartache.

Le gusta analizar problemas, probar distintas perspectivas y compartir sus descubrimientos con otros:

Like a scientist I enjoy analyzing problems, trying different angles to solve them, and then sharing my findings. I want to understand how things work, and I want others to benefit from that understanding

También tiene su parte artística, utilizando la cratividad y aceptando la imperfección.

Like an artist I need to occasionally think outside the box, tap my creativity, and be able to see in abstracts. I want to embrace imperfection.

Finalmente, como un carpintero, le gusta construir cosas:

And like a carpenter, I really enjoy building things. Sometimes that means following a specific plan, and other times you just work with what you’ve got.

Todas estas características son interesantes y valiosas pero nos alejan del modelo ‘ninja’ o ‘estrella del rock’ que parece tan popular y llamativo.

Bien por él.

Libros sobre programación en C

Si escuchamos/leemos las tendencias modernas el C estaría olvidado en algún rincón y ya nunca nadie le prestaría atención más. Sin embargo, sigue teniendo su hueco en el corazoncito de mucha gente e incluso en los topes: Interactive: The Top Programming Languages 2017 así que, poca broma.

Programando juegos

En todo caso, a mi me pudo la parte más sentimental (algunas líneas de C tiramos en su momento y, pocas veces, alguna vez nos toca mantenerlas, actualizarlas y volver a mirarlas). Por eso recomiendo echarle un ojo a Some Books on C, algunos actuales (y disponibles para descargar) y otros que son clásicos.

Código seguro para dispositivos médicos

Como casi siempre, traemos un informe con un poco de retraso. Lamentablemente (porque siguen apareciendo casos) eso no hace que pierdan actualidad. Por ejemplo, podíamos leer estos días la llamada a 465000 pacientes con marcapasos para una actualización del software de sus dispositivos 465,000 Patients Need Software Updates for Their Hackable Pacemakers, FDA Says. No es la primera vez que hablamos de marcapasos, ni de actualizaciones obligatorias de software, aunque creo que no iban juntos en las otras ocasiones.

Sensor

El informe fue el resultado de un encuentro patrocinado por IEEE Cybersecurity Initiative and the National Science Foundation y Carl Landwehr de la George Washington University y Tom Haigh of Adventium Labs (ret.) fueron los organizadores.

Posteriormente elaboraron el informe [PDF] Building Code for Medical Device Software Security que es bastante básico pero puede servir como llamada de atención para mucha gente, iniciación para algunas personas interesadas y, definitivamente, como recordatorio para las personas con más experiencia.

Algunos errores comunes tratando de arreglar problemas de 'Cross Site Scripting'

El ‘cross site scripting’ es un fallo frecuente en desarrollo web que consiste en permitir a los usuarios inyectar código ejecutable (típicamente javascript pero también otros) en páginas que pueden ver y utilizar otros usuarios. De esta forma los atacantes pueden robar información, saltarse algunos sistemas de control de acceso…

Cruce roto

En Secure Coding 101: 4 Common Mistakes Developers Make When Fixing Cross-Site Scripting nos recuerdan cuatro errores frecuentes:

  • Utilizar listas negras. Por largas y completas que sean siempre será posible que algún atacante encuentre una forma de saltárselas. En seguridad informática siempre que sea posible hay que concentrarse en permitir lo que está bien, y no en prohibir lo que está mal.
  • Aplicar filtros en lugar de ‘escapar’ la salida. Es muy difícil filtrar correctamente todos los caracteres necesarios en una aplicación normal, es mucho mejor aplicar códigos que evitan que determinados caracteres sean interpretados como caracteres de control (comillas, metacaracteres, …).
  • ‘Escapar’ los caracteres de forma inconsistente. Cuando utilizamos esta técnica, hay que hacerlo siempre y en todas las partes de nuestro programa. No sólo para evitar algún problema que ya hemos encontrado (o nos han encontrado).
  • ‘Escapar’ los caracteres que no son. A pesar de que es una solución recomendada, tampoco es trivial de realizar. Por ejemplo, ¿qué sucedería si tus cadenas de texto que han sido tratadas de manera individual son concatenadas después?