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.

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?

La forma de programar

Tengo mis dudas sobre el tema que traigo hoy aquí: porque soy culpable (cuando necesito hacer algo mínimamente complejo busco a ver si alguien ha hecho algo parecido y lo publicó para reutilizarlo). También porque me parece una buena práctica que favorece la economía, robustez…

Viejo ordenador

Sin embargo en NPM & left-pad: Have We Forgotten How To Program? expone algunas quejas que pueden ser relevantes.

Dice que parece que el objetivo de la comunidad alrededor de NPM fuera escribir el mínimo código utilizando bibliotecas de otros para conseguir sus objetivos:

It feels to me as if the entire job of an NPM-participating developer is writing the smallest amount of code possible to string existing library calls together in order to create something new that functions uniquely for their personal or business need.

Sin embargo, no hay ninguna garantía de que esas componentes estén bien (y lo vayan a estar en el futuro, si hay evoluciones de los sistemas):

There’s absolutely no guarantee that what someone else has written is correct, or even works well.

De hecho, esta es una de las grandes prevenciones que se suelen contar en seguridad: no sólo tienes que estar seguro de que tu código es seguro, sino también el que utilices de terceros.

El último argumento que señalé es el de que, según el autor, juntar llamadas a APIs no se puede considerar programar y que puede convertirse en hacer cosas demasiado complejas:

Finally, stringing APIs together and calling it programming doesn’t make it programming. It’s some crazy form of dependency hacking that involves the cloud, over-engineering things, and complexity far beyond what’s actually needed to create great applications.

Me parecen argumentos interesantes, pero que hay que manejar con cuidado: ni hayque volverse locos juntando piezas y creando auténticos ‘Frankensteins’; ni tampoco hay que programar todo desde cero, gastando tiempo en desarrollar cosas que podríamos aprovechar para cubrir lo que es específico a nuestras necesidades.

¿Se desarrollan los antivirus de manera segura?

Los antivirus siguen siendo necesarios: es cierto que no paran lo que no conocen (o lo intentan, pero no siempre lo consiguen) pero colocan una barrera frente a muchos problemas conocidos y reconocidos.

Bicho

En Why Antivirus Standards of Certification Need to Change hablan de antivirus y de un viejo tema por este sitio: el software de seguridad no siempre es seguro. Tavis Ormandy, del proyecto Zero de Google visita una empresa de desarrollo de antivirus y no podréis creer lo que pasó (frase escandalosa para que pudiera aparecer esto bien posicionado en determinados entornos). Él mismo lo contaba en Security Software Certification.

Ormandy came across one such problem recently.

During his work with Comodo, in whose antivirus solution he discovered “hundreds of critical memory corruption flaws,” the researcher noticed that the security firm was working on receiving its certification from Verizon

Ni que decir tiene, que consiguieron una buena calificación, lo que nos lleva a dos problemas: 1) el antivirus no está desarrollado de forma segura y 2) los que certifican el antivirus no están preocupados por esas cuestiones.

Podrían empezar utilizando alguna metodología ya conocida:

Specifically, the researcher recommends that Verizon integrate parts of Microsoft’s Security Development Lifecycle, including dynamic analysis, fuzz testing, and attack surface review, to test each certification candidate against the reality of today’s threats.

Pero el problema no era exclusivo para esta empresa:

Indeed, in its 2015 State of Infections report, Damballa found that a majority of high-profile antivirus solutions overlooked 70 percent of malware within the first hour.

Y, claro, la consecuencia es todavía peor: instalas el antivirus creyéndote seguro y no lo estás.

¡Atención!

Cifrado, seguridad y protección de la informacón: FBI contra Apple

La criptografía casi nunca es la parte débil de un sistema (lo que no nos impide recordar que inventar criptografía es difícil y que es mejor no hacer experimentos con eso). Ya hace unos meses hubo un caso en el que el FBI solicitó a Apple que aligerara los medios de protección del iPhone de un terrorista, tratando de obtener la posible información que pudiera haber en su teléfono. Apple se negó y aquello hizo bastante ruido, que llegó incluso a los noticieros ‘normales’.

Enigma

Me gustó ver Encryption isn’t at stake, the FBI knows Apple already has the desired key donde se comenta sobre el tema, y las ténicas que se utilizan para proteger la información del iPhone.

En primer lugar, para evitar los ataques de fuerza bruta contra el PIN, retrasan los intentos a partir del cuarto (cada vez cuesta más seguir probando), el teléfono se puede configurar para que se borre después del décimo intento fallido y finalmente, la forma de conseguir la clave de descifrado a partir del PIN también es lenta:

PINs, especially four-digit PINs, are highly susceptible to brute-force attacks. With four digits and hence only 10,000 possible combinations, it’s straightforward to simply try every number in sequence until you hit the right one. To combat this, the iPhone uses three specific techniques.

The first is that the iPhone imposes delays between PIN attempts. While the first four attempts can be entered back-to-back, the iPhone will force you to wait one minute before the fifth attempt, five minutes before the sixth, 15 minutes before the seventh and eighth, and a full hour before the ninth.

The second technique is that the iPhone can be configured to wipe the device after ten failed PIN attempts. When this option is turned on, the phone will discard its file system key after 10 bad PINs, rendering all the file system metadata (including the per-file keys) permanently inaccessible.

The third and final technique is that the computation used to derive the PIN key from the PIN itself is slow, taking approximately 80 milliseconds.

Por lo tanto, lo que el FBI trataba de conseguir era aligerar esas restricciones para lanzar sus propios ataques de fuerza bruta con ciertas garantías.

The FBI is asking for Apple to create a custom iPhone firmware that removes the escalating delays and omits the device wipe.

En definitiva, están reconociendo que el cifrado es bueno, y sólo tratarían de saltarse una de las barreras alrededor de ese cifrado.

Overall, the FBI’s request could be seen as a testament to just how good encryption is. The FBI can’t attack the iPhone’s encryption directly, and it can’t bypass the firmware signature mechanism. There’s no existing backdoor to the crypto.

Intersante

¿Cuál es tu segundo lenguaje de programación?

Después de la eterna discusión sobre qué lenguaje es mejor o peor y si dejamos de lado por un momento el hecho de que, probablemente, deberíamos elegir el lenguaje en función del proyecto y sus objetivos, es cierto que cada uno (y una) tenemos algún lenguaje en nuestro corazoncito.

Clase de programación En What’s Your Secondary Language? se concentran en la siguiente pregunta: una vez que tienes claro cuál es tu lenguaje favorito, ¿cuál sería el siguiente?

The important question is not “Which programming language is best?” but “What’s your secondary language?” The language you reach for to solve problems, prove that ideas work before implementing them for real, and to do interesting things with files and data.

En mi caso diría que mi lenguaje favorito es, siguiendo la línea expresada arriba, el que toca en cada momento: de vez en cuando C, pero también Perl (que no elegiría voluntariamente jamás, creo), u otros…

Pero cuando quiero hacer pruebas, jugar y desarrollar pequeños proyectos, elijo Python. Y últimamente, que hago más de esto que desarrollos más serios tengo que decir que casi se ha convertido también en el primero. Tampoco le hago ascos a un programita en la shell (shellscript) para un apaño rápido.

Eso sí, también tengo claro que no dejaría de hacer un proyecto porque tuviera que usar un lenguaje que me gusta menos, o aprender uno nuevo.

El correo como sustituto de las contraseñas

Una pequeña provocación en How to Fix Authentication: Email as a Password Manager que, en realidad, se parece bastante a lo que ya mucha gente usa cuando accede a sitios poco habituales. En estos casos, en muchas ocasiones, le damos al botón de reiniciar la contraseña, que nos llega al correo.

Candados

We want to propose dead simple and secure approach to authentication. Your email account is a password manager out-of-box. The idea is to remove passwords from classic authentication scheme and stick to email only: every time user wants to log in / sign up your app sends a link with one time password to their email

Según el autor tiene muchas ventajas que incluyen la simplicidad, no necesitar productos adicionales, gratuidad, …

No se si puede ser válido para cualquier producto pero, desde luego, es cierto que podría resolvernos algunos problemas.

Seguridad informática y niños

Siempre que hablamos de seguridad en informática tenemos que recordar que algunas herramientas las terminan usando niños y que, con ellos, todavía debemos ser más cuidadosos con la gestión de datos y otros detalles.

Robot de juguete Una opción es la táctica del avestruz: prohíbimos y nos quedamos tranquilos. Suponiendo que nos creamos que esa prohibición tiene algún efecto. Mi opinión siempre ha sido que deberíamos facilitar que los niños utilicen las aplicaciones (Siempre que tenga sentido, claro) y que sea fácil para sus padres poder controlar qué sucede con ese uso.

En todo caso, en Tech Toys And The Child Protection In The Age Of The IoT nos recuerda cómo se les ha ido la cabeza a algunos fabricantes y ponen características potencialmente peligrosas en los juguetes sin prestar mucha más atención. Y los padres las compran.

Let’s face it. Even the most powerful governments in the world are far from immune to hackers. Tell me now that you still believe that some cheap products like the internet-connected dolls and baby cams are better protected? Think again.

Hablan de la ‘internet of toys’, esto es la internet de los juguetes y los riesgos que se están asumiendo por puras estrategias que sólo se preocupan de la parte comercial.

No decimos que no haya que conectar los juguetes, o darles características que se consideran interesantes (si no, el juguete elegido será otro y ya está) pero con los niños hay que tener todavía más cuidado.

Moreover, for that alone, when dealing with children in an IoT context, their security and privacy must be your priority. In a tech toys context, the child protection must be paramount to you. You, the parent. You, the IoT maker. Right from day one.

Continúa dando algunos consejos intersantes: cifrar, compartimentalizar, proteger, no almacenar datos, actualizar, …

¡Atención!

Pistas sobre la semilla para generar números aleatorios

Dados Hacía tiempo que no traíamos el tema de la aleatoriedad. en Random number generator seed mistakes hablan justamente de los errores más frecuentes en este tema, aunque no desde el punto de vista de la seguridad. Más bien les preocupan los aspectos de simulación.

Una primera solución (no muy buena desde el punto de vista de la seguridad, por su predecibilidad y/o posibilidad de control externo) es usar como semilla la hora. Desde luego, no es una buena idea pedir la semilla al usuario (sin, al menos, darle unas instrucciones razonables).

Pero la cosa se complica cuando trabajamos con hilos en paralelo:

A more subtle problem I’ve seen with random number generator seeding is spawning multiple processes that each generate random numbers. In a well-intentioned attempt to give each process a unique seed, the developers ended up virtually assuring that many of the processes would have exactly the same seed.

No es una buena idea utilizar un generador aleatorio para generar las semillas, fundamentalmente porque no sería raro que se produzcan repeticiones:

Suppose you seed each process with an unsigned 16-bit integer. That means there are 65,536 possible seeds. Now suppose you launch 1,000 processes. With 65 times as many possible seeds as processes, surely every process should get its own seed, right? Not at all.

Casi siempre, lo que parece simple no lo es tanto.

El direccionamiento del Internet de las cosas

Cacharritos El direccionamiento de un montón de cacharros siempre ha sido la ‘amenaza’ que permitía justificar el paso el ipv4 a ipv6 (aunque las necesidades venían también del uso ‘normal’ de las direcciones, que ya llevan una temporada escaseando). Sin embargo, cuandos e habla de los temas de IoT (Internet of Things) no es algo que preocupe (o parezca preocupar) demasiado a nadie: típicamente nos encontramos en redes locales, que no tienen por qué ser públicas (y casi mejor que no lo sean, visto lo visto).

En The Challenges of IoT Addressing echan un vistazo al tema, donde no hay estándares claros:

Unlike with many other IT issues, administrators don’t have clear standards or an industry-recommended approach laid out for them where device addressing is concerned.

Como decíamos arriba, no parece necesario que cada aparato tenga su dirección única, sino que debería preocuparnos más su gestión:

He does believe that “every unique thing will need its own address,” whether that’s accomplished via IPv4 or IPv6, but he said that doesn’t mean it’s an unmanageable issue.

Para no perder de vista.

Registrando IPs de nuestros dispositivos en una hoja de cálculo en la nube

Dirección Seguimos dándole vueltas al tema de la dirección IP de los dispositivos. En ¿Quién está en mi red? abordábamos el problema desde el punto de vista del escaneo de la red.

Otra posibilidad es, claro, mirar el router y mirar los dispositivos conectados.

Sin embargo, para los dispositivos que tenemos controlados (y que nos interesan más) una posibilidad puede ser establecer un registro: cuando se conectan informan de que se han conectado, su IP, y los datos que consideremos relevantes.

Seguro que hay alguna forma canónica de hacer esto (o no, porque igual lo suyo sería tener un router que nos proporcione esta información de manera conveniente -pista: que no haga falta un navegador-) pero me pareció un buen ejercicio. Descubrí Google Spreadsheets and Python y me pareció una buena forma de intentarlo: los dispositivos podrían registrar en una hoja de cálculo los datos que nos interesen. Para la instalación y configuración básica se puede seguir ese documento. Después, tenemos que hacer un programita que recabe los datos y los almacene. El mío se basa en el ejemplo que puede verse allí.

En nuestro caso, obtendremos la IP con:

def getIp():
    return([l for l in ([ip for ip in socket.gethostbyname_ex(socket.gethostname())[2] if not ip.startswith("127.")][:1], [[(s.connect(('8.8.8.8', 53)), s.getsockname()[0], s.close()) for s in [socket.socket(socket.AF_INET, socket.SOCK_DGRAM)]][0][1]]) if l][0][0])

En este caso seguimos lo que indicaban en Finding local IP addresses using Python’s stdlib, no comentaremos más.

Además guardamos el nombre de la máquina, que nos servirá para dar nombre a la pestaña de la hoja donde almacenaremos los datos:

    hostname = socket.gethostname()

Finalmente, ya sólo nos queda escribir en la hoja de cálculo:

    sheet_name = 'Registro IPs'

A continuación accedemos a la hoja de cálculo (cuidado con la gestión de credenciales, nosotros hemos almacenado en la variable client_secret el nombre del fichero donde están los datos necesarios:

    scope = ['https://spreadsheets.google.com/feeds']
    creds = ServiceAccountCredentials.from_json_keyfile_name(client_secret, scope)
    client = gspread.authorize(creds)
    
    sheet = client.open(sheet_name)

A continuación registramos la máquina. Si ya es una máquina conocida, simplemente accedemos a la pestaña correspondiente; si no, la creamos:

    try:
        worksheet = sheet.worksheet(hostname)
    except gspread.exceptions.WorksheetNotFound:
        worksheet = sheet.add_worksheet(hostname, 5, 5)

Finalmente, escribimos en la hoja, insertando una fila antes de la segunda (la idea es que la información más reciente estará arriba, más cerca para verla). Al añadir una fila tendremos un registro de conexiones.

El código (en su versión actual) se puede ver en scripts/registerIp.py.

En

podemos ver cómo se crea la pestaña y se rellenan los datos al invocar el programa.

Para mantener este registro podemos poner en /etc/rc.local una invocación al programa de manera que cuando se arranquen los distintos sistemas registren su presencia.

Inseguridad en las empresas de seguridad

Twitter Otra historia que no merecería mayor comentario sino fuera porque demuestra que incluso las empresas que se dedican a la seguridad hacen las cosas mal de vez en cuando: RSA asks for plaintext Twitter passwords on conference reg page. La realidad nos demuestra que es difícil (muy difícil) hacer bien las cosas en el contexto que nos movemos hoy en día: a lo mejor subcontratas una parte de tu proceso y quien lo hace no está preocupado por estos detalles, o se dedica a ello alguna parte de la empresa cuyo cometido no es tan técnico y no prestan atención a esos detalles, …. O directamentelos de marquetin deciden que hay que hacerlo así.

¿Lo mejor de todo? Los asistentes, también gente interesada en la seguridad y que en un número no despreciable escribieron sus credenciales sin mayor problema.

Principios de seguridad de Saltzer y Schroeder

C3PO Muchas veces se utiliza la palabra principios como algo grandilocuente y altisonante para justificar casi cualquier cosa. En el contexto de seguridad (y seguramente en la vida también) los principios deberían ser normas o reglas de caracter general que nos permiten tomar decisiones y actuar cuando no tenemos otras normas más claras y directas. Serían las que nos permiten pensar en los problemas de los que todavía no somos conscientes, o afrontar los que ya conocemos pero para los que hemos de adoptar una aproximación más o menos consistente.

En este caso tenemos The Security Principles of Saltzer and Schroeder.

This kind of arrangement is accomplished by providing, at the higher level, a list-oriented guard whose only purpose is to hand out temporary tickets which the lower level (ticket-oriented) guards will honor

Los principios serían:

  • Economía del mecanismo. Esto es, mantener el sistema tan pequeño y simple comoo sea posible.
  • Por defecto, fallar de forma segura. Basar las decisiones sobre acceso en lo que está permitido, en lugar de lo que está prohibido. De esta forma, si algo no está permitido por error es mejor (desde el punto de vista de la seguridad) que si está incorrectamente admitido.
  • Mediación completa. Esto es, siempre comprobar la autorización antes de conceder el derecho.
  • Mínimo privilegio. Tener permiso exclusivamente para hacer lo que necestia nuestro trabajo.
  • Mínimo común mecanimo. Minimizar la cantidad de información y otros artefactos compartidas entre diferentes usuarios o de la que dependen muchos usuarios.
  • Separación de privilegios. Cuando sea posible, un mecanismo de protección que necesita dos claves es más robusto y flexible que uno que sólo requiera una.
  • Diseño abierto. El diseño no puede ser secreto y la protección no debería basarse en el desconocimiento del atancante.
  • Sicológicamente aceptable. Si lo que se propone no entra en nuestros esquemas mentales puede que lo aceptemos, pero terminaremos tratando de saltarlas, aligerarlas o evitarlas.

Vale la pena leer el artículo porque utiliza ejemplso de la saga de películas de Star Wars.

Y vale la pena recordar los principios para cuando tengamos dudas sobre cómo realizar alguna tarea para la que no tenemos las reglas claras del todo.

Buscando código erróneo en foros de ayuda

Roto Los ejemplos de código son una fuente de alivio cuando solucionan nuestro problema y una fuente de disgustos cuando no entendemos muy bien lo que tenemos entre manos (o el que nos proporciona el código no entiende muy bien lo que tiene entre manos). Todavía peor es cuando el código mal hecho aparece en fuentes de referencia como pueden ser libros o tutoriales (o incompleto, que es algo que pasa muy frecuentemente: no tienen en cuenta la seguridad/robustez, por ejemplo).

En este caso traemos un estudio al que hacen referencia en Computer science students mine software developer forums to teach coding practices y el artículo se puede ver en [PDF] Automatically Mining Negative Code Examples from Software Developer Q & A Forums.

Se basaron en el análisis de lenguaje natural y las preguntas realizadas por foreros que, frecuentemente, aportan un fragmento de código que falla y el mensaje de error que han obtenido.

Curioso.

Identificación de programadores mediante su código

Iguales pero diferentes Seguimos con artículos de investigación que nos han llamado la atención. ¿Existe el estilo de programación? ¿Podemos identificar a alguien que desarrolla programas por su código? Parece que no sólo es cierto (siempre que tengamos código para comparar, claro) sino que también sería cierto con los binarios que se generan por el compilador a partir de ese código. Al menos, eso es lo que dicen en When Coding Style Survives Compilation: De-anonymizing Programmers from Executable Binaries. La preocupación de los autores se refiere a la privacidad y anonimato de los desarrolladores.

Del resumen, descompilando el código binario observan como algunas particularidades sintácticas se conservan y pueden obtenerse de nuevo:

We examine executable binary authorship attribution from the standpoint of machine learning, using a novel set of features that include ones obtained by decompiling the executable binary to source code. We show that many syntactical features present in source code do in fact survive compilation and can be recovered from decompiled executable binary.

La capacidad de atribución alcanzó un 92% de los 100 desarrolladores de una Google Code Jam:

We demonstrate this improvement on data from the Google Code Jam, obtaining attribution accuracy of up to 92% with 100 candidate programmers

Y parece robusta frente a intentos de ofuscación, intervenciones más agresivas del compilador, …

Muy interesante.

Estudio sobre el uso del goto en GitHub

Siga la flecha Parece que GitHub es una fuente inagotable de aprendizaje. Traemos hoy [PDF] An empirical study of goto in C code from GitHub repositories. En este caso estudian la utilización de esta conocida estructura de control que permite romper el flujo de cualquier programa cuando se cumplen determinadas condiciones (o dejan de cumplirse).

En general es una estructura de control que está mal vista desde el punto de vista del desarrollo estructurado de programas. Podemos recordar aquí el famoso [PDF] Edgar Dijkstra: Go To Statement Considered Harmful, de Edsger Dijkstra, uno de los padres de la programación estructurada. Sin embargo, es cierto que en algunos casos la estructura del programa puede mejorar mucho si se utiliza con ‘sabiduría’.

El artículo habla del uso del ‘goto’ por parte de los programadores (si lo utilizan y para qué) y su aparición en la correción de fallos después de lanzar una versión.

Se usa. A nivel de fichero:

Considerable use of goto at the file level: We find that 246,657 out of the 2,150,387 files (or 11.47%) examined in our study have at least one goto statement.

A nivel de proyectos:

We find that 3,093 out of the 11,627 projects (or 26.60%) have at least one file with a goto statement. We also find that more than half the projects have about 20% of the files that have at least one goto statement.

Se utiliza, fundamentalmente, para código de sistema y de red, pero también para otras cuestiones. Mirando en las funciones parece que el uso principal es para gestión de errores, limpieza (liberación de memoria, etc.). Otra característica interesante es que la mayoría de los saltos son hacia adelante y raramente se hacen hacia atrás.

We find that, in general, the use of goto is actually well disciplined. Most uses of goto statements are reasonably structured, filling the void of miss- ing higher-level constructs found in other languages. There are of course usages that are unstructured as Dijkstra feared, but they are overall in

Después de publicar una versión la tendencia era a que se mantengan más o menos el mismo número de ‘gotos’ en el código, por lo que los proyectos no parecen considerarlos como algo perjudicial y desaconsejable.

If we assume bugs in the post-release phase of a project as a measure of harm, then the small number of goto statements being removed/modified in bug fixes implies that goto statements were not consid- ered harmful enough to be removed/modified in the post-release phase of the project in most cases.

Interesante.

Seguridad de la gestión de acceso mediante SSH

Cerrado El National Institute of Standards and Technology publica informes de lo más variado y de vez en cuando le dedica atención a la seguridad informática.

Traemos hoy aquí el informe [PDF] Security of Interactive and Automated Access Management Using Secure Shell (SSH) que habla del protocolo SSH desde el punto de vista de gestión en las organizaciones.

This publication assists organizations in understanding the basics of SSH interactive and automated access management in an enterprise, focusing on the management of SSH user keys.

Los primeros capítulos pueden ser interesantes para alguien que todavía no se haya preocupado de estos temas (a veces los informes sobre temas más complejos nos sirven para entender mejor las cuestiones básicas porque las tratan en los capítulos introductorios). Los siguientes, tendrán interés si queremos ir más allá en los temas de gestión de la seguridad.

Calidad del software y lenguajes de programación

Verificación de programas En [PDF] A Large Scale Study of Programming Languages and Code Quality in Github nos muestran una investigación realizada examinando el código de los repositorios de GitHub: analizan para diversos tipos de lenguajes la cantidad de fallos, basándose en los ‘commits’ que contienen etiquetas relacionadas con errores (‘error’, ‘bug’, ‘fix’ , ‘issue’, ‘mistake’, ‘incorrect’, ‘fault’, ‘defect’ and ‘flaw’).

El resumen sería (de manera muy básica) que los lenguajes fuertemente tipados son algo mejores que los débilmente tipados. También que los lenguajes funcionales son algo mejores que los demás.

… we report that language design does have a significant, but modest effect on software quality. Most notably, it does appear that strong typing is modestly better than weak typing, and among functional languages, static typing is also somewhat bet- ter than dynamic typing. We also find that functional languages are somewhat better than procedural languages.

En todo caso, el efecto no es muy grande.

Puede que también tengan interés en leer los comentarios del hilo de Hacker News sobre el trabajo A Large Scale Study of Programming Languages and Code Quality in GitHub.

También me gusta destacar el valor que tiene un sitio como GitHub (internet, para el caso) para poder realizar este tipo de estudios que serían bastante difíciles de realizar con el código disponible en ‘casa’ de cada uno que lo tenga.

Reforzar el acceso a nuestros sistemas

Traemos un par de lecturas sobre cómo podemos reforzar el acceso a nuestros sistemas, añadiendo seguridad de dos formas (que podrían combinarse entre sí, puesto que se ocupan de diferentes partes: acceso y autentificación a un sistema).

Candados

En primer lugar, en Using 2 factor authentication for SSH unas instrucciones sobre cómo utilizar el app Google Authenticator para establecer un sistema de dos factores para el servicio SSH.

La otra posibilidad es habilitar los servicios cuando los necesitemos, de forma que cuando no los vayamos a usar no estén disponibles. En este caso podríamos utiliar Latch. Tal y como cuentan en Fortificar GNU/Linux Ubuntu con Latch: Vídeo Tutorial se puede usar en cualquiera de los sistemas más comunes.

Publicar en Telegram las entradas de este sitio usando Python

Interactuando con el bot Siguiendo la línea de publicaciones anteriores, y tratando de alcanzar mayor difusión de las entradas de este sitio (y otro) decidimos probar el API de publicación de Telegram. Como siempre, es sencillo si encontramos las bibliotecas adecuadas y tenemos un poco de paciencia.

Pero primero tenemos que crear el bot. Siguiendo las instrucciones del BotFather. En este caso le pedimos el nuevo bot con:

/newbot

El botfather nos pide un nombre para nuestro bot, y un nombre de usuario (que deberá terminar en ‘bot’). Como respuesta nos envía el ‘token’ que nos servirá para identificarnos y poder interactuar con él. A partir de allí nuestra misión es mandarle cosas al bot.

Yo he elegido hacer un programita en Python, utilizando telepot. Las instrucciones están en telepot documentation El código que se muestra allí es muy sencillo.

import telepot
bot = telepot.Bot('***** AQUÍ VA EL TOKEN *****')

Y mandar un mensaje sería algo así como:

bot.sendMessage(999999999, 'Hola mundo')

En este caso ‘999999999’ es el identificador del bot, se puede utilizar el nombre asignado anteriormente.

En nuestro caso, como queremos que el bot avise automáticamente a sus seguidores cuando haya novedades utilizamos la fuente RSS del blog y algunos módulos de Python como feedparser.

Nos vamos a saltar esta parte porque ya la hemos contado en otro sitio y también la parte de obtener el título, el contenido y el enlace a la última entrada.

En este caso hay ciertos límites, no se pueden superar los 4096 caracteres en UTF8. Además, para que el texto tenga algo de gracia nos permiten algunas etiquetas de formato (que pueden ser HTML o Markdown). Como estamos leyendo la fuente RSS habremos leido HTML y la única prevención que hay que tener es utilizar sólo las etiquetas permitidas (negrita, cursiva, enlaces, código y texto pre-formateado). Para esto hice una chapucilla, consistente en eliminar todas las etiquetas que no le gustan al sistema:

Extraemos todas las etiquetas de nuestro texto:

tags = [tag.name for tag in soup.find_all()]

Y luego las recorremos:

for tag in tags:

Eliminando las que no son válidas:

   if tag not in validTags:

con unwrap. Previamente hemos tenido una consideración especial con las citas añadiéndoles delante y detrás unas comillas para que se refleje adecuadamente en el resultado final.

def cleanTags(soup):
    tags = [tag.name for tag in soup.find_all()]
    validTags = ['b', 'strong', 'i', 'em', 'a', 'code', 'pre']

    if soup.blockquote:
        soup.blockquote.insert_before('«')
        soup.blockquote.insert_after( '»')

    for tag in tags:
        if tag not in validTags:
            for theTag in soup.find_all(tag):
                theTag.unwrap()

Para enviar el mensaje necesitamos crear un canal FAQ channels y dar de alta como administrador al bot, para que pueda escribir en el canal:

bot.sendMessage('@'+channel, str(soup)[:4096], parse_mode='HTML')

El código está integrado en mi proyecto rssToSocial que no es un código para sentirse especialmente orgulloso. Pero permite hacer estas publicaciones sin tener que hacerlo a mano.

La explicación del código para publicar en otras redes sociales está en:

A partir de ahora (o dentro de un poco, que tengo que configurarlo) ya pueden recibir notificaciones siguiendo a mbpfernand0 en Telegram.

Primeros pasos con Omega2

Hace unos meses se anunció el proyecto de financiación de un nuevo ordenadorcito, el Omega2: $5 Linux Computer with Wi-Fi, Made for IoT. Tengo que decir que lo vi y no le presté atención, así que no participé en el proyecto. Mi hermano lo hizo y además encargó un par de cacharritos para darme uno.

Lo tengo en casa desde navidad pero hasta ahora no había tenido tiempo de escribir esta nota. En este caso lo probé y pude configurarlo con mucha rapidez. Desde el punto de vista de puesta en marcha el proyecto ha trabajado muy bien si nos olvidamos de un par de detalles que comentaremos luego: alimentamos la placa, esperamos a que arranque y crea un punto de acceso WiFi. La documentación es clara y se sigue bien. Desde cualquier otro ordenador podemos conectarnos a ese punto de acceso. Navegando desde esa red podremos conectarnos a la dirección del Omega y hacer la configuración inicial desde el navegador (o mediante ssh). Entre otras cosas le proporcionamos los datos de nuestra red WiFi y entonces se conecta. Personalmente me gusta más la configuración inicial del C.H.I.P. pero encuentro esta bastante cómoda y amigable (y mucho más que tener que buscar una pantalla a la que conectar el cacharrito, aunque sea la de la TV).

En cuanto a las pegas inciales dos, pero notables: la alimentación de la placa es a 3.3V (si compramos el ‘dock’ entonces podremos tener acceso a un puerto USB y alimentar el cacharrito desde allí, entre otras ventajas. Pero entonces hablamos de un ordenador de 20 dólares y no 5). La segunda pega es la separación de los pines: no es la estándar de una placa de prototipado así que no es posible pincharía allí y cablear, hay que poner los cables directamente a los pines (a lo mejor hay placas de prototipado con esa ditancia de pines, lo desconozco). La estoy alimentando gracias a que tenía una fuente de alimentación YwRobot.

Omega 2

Como decíamos arriba la documentación para ponerla en marcha y dar los primeros pasos está muy bien Onion Omega2 Documentation y ponerla en marcha es sencillo.

Una vez que conseguimos que arranque disponemos de un sistema funcionando que configuramos a nuestro gusto y podemos empezar a trabajar. Como punto positivo frente a otras placas nos ha parecido muy buena idea que genere su propia red y de manera simultánea pueda conectarse al router mediante interfaces virtuales. Así se pueden hacer proyectos (la documentación lo explica) para hacer un extensor de WiFi (llevar la WiFi a algún punto lejano, haciendo de repetidor), un punto de acceso, … Otro punto interesante es que utiliza LinuxWRT, con el inconveniente de tener que aprender a manejar otro gestor de paquetes, el opkg (aunque la documentación ayuda también en este aspecto).

Entramos por ssh:

El ssh en Omega 2

En cuanto al uso, tengo sentimientos enfrentados: es pequeñita, barata y sencilla de poner en marcha. Pero cuando empezamos a trabajar con el modelo básico, casi no podemos hacer nada (por falta de espacio): para empezar, hay que elegir entre tener Git o Python, porque no hay espacio libre suficiente para los dos. Podríamos aumentar el almacenamiento disponible (y hay instrucciones para ello) pero sería mejor teniendo un puerto USB para conectarlo.

Entre sus características

  • Procesador 580MHz MIPS CPU.
  • Memoria 64MB (el Omega 2+ tiene 128) y 16 Mb de almacenamiento (32 en el caso del Plus).
  • b/g/n Wi-Fi
  • Varios puertos para conectividad con diversos sistemas externos.

Tiene USB 2.0, pero sin el dock no tendremos el conector.

El tamaño es pequeñito, la mitad de lo que ocupa el C.H.I.P. aproximadamente y un poquito más que un NodeMCU.

Comparando tamaños: C.H.I.P., Omega2, NodeMCU, Arduino, Pine64, Raspberry Pi

Una cosa que me preocupaba de estos aparatitos son las prestaciones. Son bastante limitadas y he preparado una tabla para que se vea mejor. La comparación se hará con una Raspberry Pi (Model B), un C.H.I.P., una Pine 64 y también he hecho comparaciones con un PC de escritorio viejo (fecha alrededor de 2008), y mi portátil, que también tiene unos cuantos años (fecha alrededor de 2011):

Dispositivo microsegundos/iteración Nº de cores bogomips Procesador
Raspberry Pi 5.944 1 697,95 ARMv6-compatible processor rev 7 (v6l)
Omega 3 3.916 1 385,84 MIPS 24KEc V5.5
C.H.I.P. 1.125 1 1001,88 ARMv7 Processor rev 2 (v7l)
Pine 64 624 4 624 AArch64 Processor rev 4 (aarch64)
PC Escritorio 204 1 6800,56 Intel(R) Pentium(R) 4 CPU 3.40GHz
Portátil 69 2 5382,47 Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz

La conclusión para mi fue que estos cacharritos pueden cumplir un papel en muchos momentos (y lo cumplen) pero no debemos olvidar las limitaciones en cuanto a potencia, que no permitirían (aún) pensar en ellos como sustitutos de un computador de sobremesa (salvo que tengamos requisitos muy austeros).

El sistema utilizado para medir las ‘prestaciones’ es muy básico, utilicé el código que proporcionaban en Performance Comparison - C++ / Java / Python / Ruby/ Jython / JRuby / Groovy.

En esta serie hemos publicado hasta ahora:

Sobre la Raspberry no hice un primeros pasos.

Divulgación de vulnerabilidades en la industria del automóvil

Un coche Los fabricantes de automóviles han permanecido muchos años de espaldas a la informatización. Ahora empiezan a utilizarlo como argumento de ventas (esencialmente a través de sistemas de comunicación y entretenimiento) pero en medio la informatización de la instrumentación de los coches ha sido más o menos inevitable. Y la aparicion de fallos también, claro (ver Coches y ataques). La reacción de los fabricantes era, hasta hace no mucho, atacar a los investigadores pensando que así evitarían que se divulgase su conocimiento.

Por eso traemos aquí GM embraces white-hat hackers with public vulnerability disclosure program donde se decía cómo el conocido fabricante había decidido no perseguir a los investigadores que informaran sobre fallos de seguridad, mediante un programa de divulgación responsable de vulnerabilidades:

“We very highly value third-party security research,” Massimilla said. He explained that under the program, those third parties can reveal vulnerabilities they find with the guarantee that GM will work with them and not take legal action—as long as they follow the fairly straightforward guidelines posted on the program’s portal.

Almacenamiento seguro de contraseñas

Sistemas de almacenamiento Primero, que quede clara una cosa: las contraseñas no se almacenan, se almacena una transformación unidireccional que permita comprobar que la persona que la utiliza la conoce, pero que impide (en la medida de lo posible) que el que nos pudiera robar los datos los utilice de manera directa.

En Storing Passwords in a Highly Parallelized World hablan de un tema al que se le está prestando mucha atención en los últimos años: no se trata sólo de almacenar las contraseñas de manera que sean ilegibles, sino que hay que tener en cuenta los ataques que pueden sufrir si alguien consigue acceder a la información y atacarla en condiciones favorables. En ese sentido, se favorecen métodos que añaden coste computacional (cuando se trata de una sola contraseña, con la clave correcta, es un coste asumible; si se trata de hacer pruebas empieza a ser interesante desde el punto de vista defensivo):

bcrypt is a password hash. The difference to cryptographic hashes like SHA-1 is that it adds a computational cost to password hashing. In other words: it’s intentionally slow. The reasoning is that if someone steals the hashes of the passwords of your customers, it’s going to be much more expensive to compute the passwords (which are probably also the passwords to their e-mail accounts) to those hashes.

Luego habla de una competición para generar nuevos métodos de hash criptográficos y del ganador, haciendo algunas pruebas de demostración en Python:

Argon2 is a secure, memory hard password hash. It comes in two variants but for password hashing only the side-channel hardened Argon2i is relevant. On 2015-11-05, an IETF draft has been submitted in order to make it an official Internet standard ASAP.

Números aleatorios seguros en Javascript

Aleatorio Otra nota sobre números aleatorios seguros. En este caso nos avisaban en V8 Javascript Fixes (Horrible!) Random Number Generator sobre un error en la forma de generar números aleatorios en Javascript que tiene el interés de proporcionar una explicación general bastante buena, como alguien encontró el fallo al encontrar una colisión en un identificador de sesión (tan sólo un mes después de empezar) y cómo los programadores eligieron la versión incorrecta de un método que no estaba mal.

En TIFU by using Math.random() cuentan los detalles sobre la historia en primera persona. Sin olvidar que estaban utilizando un generador de números aleatorios que no era criptográfico.

De paso, podemos probar el generador de nuestro navegador en este generador de imágenes aleatorias.

Obsolescencia de algoritmos criptográficos vs realidad

 Algunos trucos para esconder programas maliciosos En SHA-1 Deprecation: No Browser Left Behind nos hablan sobre la obsolescencia del algoritmo de hash criptográfico SHA1 con algunos datos como lo que costaría hoy en día generar colisiones (recordemos que en un algoritmo de hash el poder genera un mensaje diferente que tenga el mismo ‘resumen’, esto es, encontrar colisiones es uno de los principales problemas de seguridad):

Computers keep getting faster and now SHA-1 is increasingly vulnerable to potential collision attacks. The estimate today is that it would likely cost around USD$700,000 to generate a SHA-1 collision. By 2021, the price is forecast to fall to just USD$43,000.

También hacen algunos cálculos de cuánto se utiliza su sucesor, [SHA2]/(https://en.wikipedia.org/wiki/SHA-2):

To understand the impact, we spent the last few weeks testing browser connections to CloudFlare’s network for SHA-2 support. We see approximately 1 trillion page views for more than 2.2 billion unique visitors every month, which gives us a pretty representative sample of global traffic.

Y la conclusión es que podrían utilizar este algoritmo un 98.1% de los navegadores observados por ellos que puede parecer mucho pero, en sus cuentas, deja fuera a un nada despreciable número de más de 37 millones de personas. En Estados Unidos la cosa sería un poco mejor:

The United States has 99.26% SHA-2 support, making it the 15th most modern browser market (out of more than 190 countries we saw traffic from during our test). In fact, SHA-2 support in Western Europe and North America is universally over 99%.

pero, desde luego, no el mejor de los sitios con acceso a esta tecnología (15 puesto en el ranking de navegadores más modernos).

Lamentablemente, en la cola de esta lista están algunos de los países que probablemente necesitarían tener mejores sistemas de seguridad.

Unfortunately, this list largely overlaps with lists of the poorest, most repressive, and most war torn countries in the world. In other words, after December 31st most of the encrypted web will be cut off from the most vulnerable populations of Internet users who need encryption the most.

Y, claro, esto tiene como consecuencia que sitios como Alibaba o Facebook que quieren tener clientes en esas zonas menos protegidas admitan utilizar los algorimtmos menos seguros (lo que puede afectar a todo el mundo).

For instance, Alibaba, the Chinese Internet commerce giant, supports SHA-1 fallback across many of its sites. That’s not surprising given more than 6% of their Chinese customers could not securely buy from their online store if they only supported SHA-2.

Facebook also supports SHA-1 fallback across many of their sites.

Interesante.

Condiciones de carrera

Carrera Un texto introductorio sobre las condiciones de carrera: cuando varios procesos acceden a un recurso compartido de forma que se pueden producir resultados diferentes según la temporización con que se ejecute el código. Lo cuentan en Practical Race Condition Vulnerabilities in Web Applications y me pareció un texto que valía la pena guardar por las explicaciones, ejemplos y métodos de resolución para evitar el problema.

Compartir la WiFi sin precauciones

WiFi Hace bastante tiempo solía tener mi WiFi casera abierta: pensaba que algún paseante que pudiera necesitarla le vendría bien poder conectarse un rato. La cerré por varios motivos: siempre había alguien que abusaba y se ponía a descargar utilizando mi ancho de banda y provocando molestias. El otro era una cuestión de seguridad: cuando va habiendo más dispositivos conectados en mi red, es más delicado vigilar que todo va bien y que un atacante casual (intencionado o troyanizado) no provoque un desastre.

Hace mucho menos bromeaba sobre cuánto tiempo es ‘prudente’ esperar cuando uno lllega a una casa ajena para pedir la contraseña de la WiFi sin parecer descortés.

Como visitantes, también deberíamos ser cuidadosos a la hora de conectarnos a redes extrañas, que nunca sabemos lo que puede haber entre internet y nosotros.

Por los motivos señalados arriba, me sentí muy reforzdo por No, you can’t join my wifi network Troy Hunt nos explica que no deja utilizar su WiFi a los invitados y sus motivos para ello.

La primera es que, aunque confíes en tus invitados (como personas, se entiende), no puedes confiar en que sus dispositivos sean seguros y que se comportarán adecuadamente.

That might mean as a result of introducing an infected machine into the network or picking up something unsavoury while they’re browsing around behind the confines of your firewall.

También habla de la variedad de dispositivos que tenemos hoy en día conectados a nuestra red y la información que un atacante podría obtener:

Think about what’s discoverable on your own network once a device joins it: all the devices and open ports just for a start. Your NAS, your media server, your security cameras and all manner of IoT things with nothing more than software to protect them. Just as with a corporate environment, you have to work on the assumption that any machine introduced to the network is malicious and frankly, I want to minimise that risk as far as possible.

Además nos recuerda que para visitantes casuales las conexiones móviles han evolucionado mucho y lo normal es tener buena velocidad y una tarifa con suficiente cantidad de datos para no tener que pedir prestado.

En caso de que queramos compartir la WiFi (y también es un consejo que suelo dar para pequeños negocios y sitios donde compartir la WiFi es algo que se espera), deberíamos una red para invitados en la que no haya nada que nos pueda preocupar desde el punto de vista de nuestros datos:

Of course you could always just defer to your wireless access point’s guest network (if you have that capability — and many do not), that’s what it’s designed for, right? The basic premise is that a guest network is a logically isolated network for exactly what the name suggests – giving guests access. This keeps them separated from your primary network which is a good thing, except the implementation can be kind of sucky.

Los empleados y las contraseñas

Encuestas En Half of U.S. Enterprise Employees Reuse Work-Related Passwords nos recuerdan uno de los problemas más importantes en la seguridad de las empresas: la falta de preocupación por parte de la gente que trabaja en ellas.

Se basa en una encuesta entre más de 1000 empleados de empresas en EEUU de los que casi la mitad afirmaban que re-utilizaban las contraseñas para cuentas relacionadas con el trabajo. La noticia no es negativa del todo porque en el caso de las contraseñas personales la re-utilización sube a las 2/3 partes.

A recent Ping Identity survey of more than 1,000 enterprise employees in the U.S. has found that almost half of respondents admit that they’re likely to reuse passwords for work-related accounts, and almost two-thirds reuse passwords for personal accounts.

Un 66% afirman que no las darían a cambio de nada, pero hay alrededor de un 20% que las cambiarían por dinero para la hipoteca, préstamos de estudios y otras necesidades.

And while 66 percent of respondents said they wouldn’t trade their personal email login credentials for anything, 20 percent said they would trade them for a paid mortgage or rent for one year, and 19 percent would trade them to pay off student loans or higher education tuition.

Hace algún tiempo hablábamos de encuestas similares donde la preocupación de los empleados no es suficiente cuando se trata de las contraseñas utilizadas en el trabajo (y las personales, según este estudio, todavía peor).

El juramento del programador

Teclados En Uncle Bob Proposes an Oath to Programmers justamente eso. Robert C. Martin, conocido como Uncle Bob (tío Bob) propone (traducción aproximada):

  1. No produciré código dañino
  2. El código que produzca será siempre el mejor posible. No entregaré a sabiendsas código defectuoso en su comportamiento o en su estructura.
  3. Realizaré en cada entrega una comprobación segura y repetible de que cada elemento del código hace lo que debería.
  4. Haré entregas pequeñas y frecuentes, para no obstaculizar el trabajo de otras personas.
  5. Mejoraré el código sin temor y sin descanso cada vez que sea posible. Nunca empeoraré el código.
  6. Haré todo lo posible para mantener mi productividad y la de otras personas tan alta como sea posible. No haré nada que reduzca esa productividad.
  7. Me aseguraré de forma continua que otros pueden cubrir mi trabajo y que yo puedo cubrir el suyo.
  8. Produciré estimaciones que son honestas tanto en magnitud como en precisión. No haré promesas sin certidumbre.
  9. Nunca dejaré de aprender ni de mejorar mis habilidades.

El original del juramento se puede leer en The Programmer’s Oath.

En la entrada se añden algunos comentarios recibidos en su momento en Twitter después de la publicación del juramento y se recuerda el manifiesto del software robusto The rugged manifesto sobre el que comentamos en su momento en Manifiesto del software robusto.

¿Quién actualizará los juguetes de los niños?

Juguetes Si los dispositivos no son seguros Estudio sobre vulnerabilidades en el firmware de dispositivos, ¿qué podría hacernos pensar que los dispositivos que se incluyen en los juguetes lo serán?.

En When children are breached – inside the massive VTech hack nos hablan con cierto detalle de las vulnerabilidades encontradas en esos ordenadorcitos parecidos a tabletas que están pensados para los niños pequeños:

Inyección de SQL:

Why they’re returning a SQL statement is absolutely beyond me. Lorenzo was told by the person that provided him with the data that the initial point of compromise was due to a SQL injection attack and even without seeing the behaviour above, I would have agreed that was the most likely attack vector. On seeing the haphazard way that internal database objects and queries are returned to the user, I’ve no doubt in my mind that SQL injection flaws would be rampant.

Desarrollo poco cuidadoso (sobre todo teniendo en cuenta quién va a utilizar el producto):

But what really disappoints me is the total lack of care shown by VTech in securing this data. It’s taken me not much more than a cursory review of publicly observable behaviours to identify serious shortcomings that not only appear as though they could be easily exploited, evidently have been.

Si los ‘juguetes’ de los mayores se actualizan poco, ¿quién actualizará los de los niños?

¿Cómo encajan las actualizaciones en los procedimientos actuales?

Reiniciando Esta entrada no será muy novedosa para casi nadie pero viene bien recordarla aquí. En The Problem with Patch Management: All the Humans hablan de las actualizaciones y de los problemas que nos causan: tenemos muchas cosas de las que ocuparnos, no es fácil siempre determinar si realmente nos afectan o no, tampoco es sencillo saber si afectarán a otros de nuestros procesos…

Necesitaríamos una forma de conocer las actualizaciones disponibles para nuestros dispositivos y sistemas y que pudieran ser aplicadas de forma que el impacto fuera mínimo:

What’s needed is a way to detect available updates across every operating system and all firmware on physical devices. All verified updates need to be applied in a way that minimizes or eliminates downtime. The updates must be introspectable, auditable, and repeatable. The process should minimize human interaction and required expertise.

Las actualizaciones deberían integrarse bien en los procesos modernos de integración continua:

Modern practices such as continuous delivery make this practical by constantly ensuring incoming change results in the desired behavior. Software updates should be treated as just another incoming change.

Estudio sobre vulnerabilidades en el firmware de dispositivos

Ordenador Esta es casi una continuación de la entrada anterior. En Many embedded devices ship without adequate security tests, analysis shows hablan del análisis realizado al firmware de un montón de dispositivos y las vulnerabilidades encontradas. Se analizaron 1925 dispositivos de más de 50 fabricantes.

De ellos sólo consiguieron arrancar alrededor de 250 servidores web:

The researchers started out with a collection of 1,925 Linux-based firmware images for embedded devices from 54 manufacturers, but they only managed to start the Web server on 246 of them. They believe that with additional work and tweaks to their platform that number could increase.

Intentaban encontrar problemas en las interfaces web de los dispositivos. Las encontraron, pero también en el código PHP utilizado en algunos dispositivos, inyecciones de SQL, cross-site scripting,… O sea, lo típico que suele encontrarse en cualquier sistema de complejidad mediana.

Y un aviso (más) a los usuarios/gestores/administradores que utilizan estos dispositivos.

Estudio sobre reutilización de certificados en dispositivos

Puerta cerrada La semana pasada ocurrió un ataque distribuido de denegación de servicio (DDOS) que afectó a sitios tan importantes como Twitter, Netflix, The New York Times, o GitHub (no lo comprobé, pero seguramente esta bitácora se vió afectada, al estar albergada en este último). Estaba provocado por un ataque a los servidores de nombres (DNS). Aparentemente estaría basado en la fragilidad de la seguridad de muchos dispositivos de la internet para las cosas (IoT) que casi siempre vienencon las mismas claves configuradas por defecto o con escasas características de seguridad (por lo que son fáciles de conocer por alguien interesando). Se puede leer sobre esto en Un ciberataque masivo deja inaccesibles destacadas webs de internet como Twitter o Spotify, Today’s Brutal DDoS Attack Is the Beginning of a Bleak Future, o -más técnico- DDoS on Dyn Impacts Twitter, Spotify, Reddit. Además estos dispositivos no suelen tener mecanimos sencillos de actualización, gestión, etc…

La cosa está mal y ya llevamos una temporada leyendo sobre estos temas. Yo tenia guardado House of Keys: Industry-Wide HTTPS Certificate and SSH Key Reuse Endangers Millions of Devices Worldwide donde se habla de dispositivos para los que se tiene prevista la utilización de criptografía más avanzada (incluyendo certificados digitales). Y son dispositivos de todo tipo. En un análisis de más de 4000 dispositivos de más de 70 fabricantes se encontraron solamente 580 claves únicas, lo que nos indica que hay reutilización de estas claves en diferentes dispositivos (típicamente incluídas en el firmware) e incluso estarían repetidas entre diferentes marcas, simplemente por el hecho de reutilizar entornos de desarrollos y otras herramientas. Si a eso le sumamos que muchos de estos dispositivos están conectados directamente a internet tenemos la receta segura para el desastre.

Software libre en tu empresa, ¿todo tu código es realmente tuyo?

Código Un informe que gustará incluso a los más perezosos: [PDF] OPEN SOURCE SECURITY ANALYSIS The State of Open Source Security in Commercial Applications

Aunque ya hace mucho tiempo que no es cierto, mucha gente sigue creyendo que el software no ha ‘entrado en su vida’. En este informe se habla del tema, en un aspecto en el que probablemente todavía menos gente piensa: el código libre que se ‘cuela’ en nuestras aplicaciones (por comodidad, conveniencia y lo que sea). Se dan algunas cifras como:

  • Black Duck encuentra dependencias o incluso código libre en las aplicaciones corporativas en un 95% de las aplicaciones que analizan.
  • Una aplicación comercial típica incluye un 35% de código libre.
  • Naturalmente, eso incluye las vulnerabilidades que ese código pueda tener.

Los consejos serían:

  • Tener políticas de uso de software libre
  • Hacer seguimiento de ese código y cumplir (y hacer cumplir) las políticas
  • Estar atentos a las vulnerabilidades que puedan provenir de este camino

Algunos trucos para esconder programas maliciosos

Enigma Aunque este tipo de artículos son algo técnicos, me gustó leer An Example of Common String and Payload Obfuscation Techniques in Malware que utiliza tácticas diferentes para saltarse las posibles protecciones: una lista de programas que se pueden utilizar en el análisis dinámico, cifrado de cadenas de texto para que no sea fácil encontrarlas y comunicación cifrada con el centro de control (command & control). Todo ello sin utilizar técnicas muy sofisticadas pero de eficacia suficiente.

También nos viene bien a nosotros porque es fácil de seguir y comprender los trucos que utilizan los malos a veces.

La privacidad, los datos y los usuarios

Intimidades Otro tema que sigue apareciendo de vez en cuando por aquí: tenemos muchos datos que a veces queremos compartir para análisis estadísticos y de otro tipo. El problema: la privacidad. En How do you anonymize personal databases and protect people’s privacy – over to you, NIST comentan sobre la guía de US National Institute of Standards and Technology (NIST), que se puede ver en [PDF] De - Identi fi cation of Personal Information.

Se trata de un documento en fase de comentarios y revisión con algunas lecciones interesantes:

  • El balance entre proporcionar información útil y privacidad no es fácil.

  • Hay mucho trabajo, y debe hacerse

Además, como se podía esperar, la privacidad de los famosos todavía es más complicada de proteger.

Para proteger los datos se pueden utilizar métodos sobre los propios datos, o sobre la forma de proporcionarlos.

Se pueden ver comentarios anteriores sobre anonimización y des-anonimización, por ejemplo en Sobre re-identificación de datos anónimos y seguir los enlaces, porque no es este el primer informe sobre el tema que recomendamos.

La responsabilidad de las empresas en los ataques

Geekonomics Este tema aparece por aquí de vez en cuando: en este caso, desde el punto de vista del atacado ¿son las empresas responsables de los ataques que sufren?. En 90% of directors believe regulators should hold firms liable for hacks dicen que sí.

El matiz es que se haya prestado la debida atención (‘due care’) o no:

Nine out of 10 of those surveyed believe regulators such as the FTC should hold businesses liable for cyber breaches if due care has not been followed

También es cierto que se trata de responsables concienciados, que están tomando medidas o piensan tomarlas próximamente:

While 94 percent of respondents have increased or are planning to increase their security assessments to address liability concerns, two-thirds of respondents say they have also begun or are planning to insert liability clauses into contracts with their third-party providers.

La última vez que hablamos de este tema fue en Seguridad y aseguradoras

Sobre generadores de sitios web estáticos

El sitio en GitHub Siempre me ha parecido sugerente la idea de un sitio generado de manera estática. Por eso me gustó experimentar con pyblosxom (que no está demasiado activo, la verdad) y me decidí a migrar desde Wordpress aquí (aunque lo estático de este sitio se podría poner en duda de muchas formas porque cualquiera sabe, al final, lo que realmente hay por detrás). Contábamos el traslado en Cuarta etapa.

Con todas las ventajas de los gestores de contenidos disponibles por ahí uno se quedaba tranquilo con encontrar una solución que se adapte a sus rarezas y olvida el tema. Hasta que descubre que algunos dicen que este tipo de gestores que nos gustan son ‘la próxima gran cosa’ (en su contexto, imagino). Al menos eso es lo que decían en Why Static Website Generators Are The Next Big Thing.

Tampoco vamos a volvernos locos. Asumimos que este tipo de sistemas tienen sus ventajas para unos cuantos, es bueno que existan y ya nos viene bien. Pero no me imagino que vayan a ser mayoritarios.

Si alguien está interesado en el tema se habla de StaticGen, un directorio de este tipo de generadores y el artículo también habla de los típicos sitios más-o-menos-importantes que utilizan una aproximación de este tipo.

En realidad, no deja de ser una locura para determinadas páginas web utilizar esos gestores de contenidos tan complejos y con tantas posibilidades de que algo vaya mal. Pero de ahí a pensar que la web va a volver a ser más estática, hay un pequeño trecho que no se si mucha gente recorrerá.

Habla de sitios dinámicos con frontales estáticos (caches) y otras cuestiones técnicas relacionadas. Me gustó leerlo, y por eso lo traigo aquí.

¿En quién confías? El compilador

Mac de Apple Para mi es una lectura imprescindible el [PDF] Reflections on Trusting Trust de Ken Thompson y ya hemos hablado del mismo tema en alguna ocasión, por ejemplo en Un compilador que infecta los binarios donde aquellas ideas pasaban de la teoría a la práctica.

Más recientemente podíamos leer sobre XcodeGhost, que realizaba el ataque contra el compilador Xcode de Apple para iOS y OS X:

XcodeGhost is an example of compiler malware. Instead of trying to create a malicious app and get it approved in the App Store, XcodeGhost’s creator(s) targeted Apple’s legitimate iOS/OSX app development tool called Xcode to distribute the malicious code in legitimate apps.

Los ‘malos’ habrían ‘adaptado’ el compilador para sus objetivos y habrían colgado el enlace en distintos foros para que la gente se lo bajase y lo utilizase, produciendo un buen número de infecciones en diversos programas que terminaron en la AppStore.

Nótese que es un problema muy fácil de evitar, simplemente bajándose las herramientas de sitios confiables y no escuchando los cantos de sirenas de los foros y sitios de noticias. Pero aún así, algunos desarrolladores cayeron e infectaron a sus usuarios.

Algunas cuestiones que hay que tener en cuenta con el modelado de amenazas

Modelando La seguridad absoluta no existe. Además no tiene sentido protegerse contra problemas que no tenemos, u olvidarse de los que tenemos porque no salen en los libros o en las listas de consejos. Por eso nos centramos en riesgos y cómo evitarlos/mitigarlos. Para ello podemos usar el modelado de amenazas para nuestro producto y tratar de determinar qué es lo importante aquí y cómo puede afectarnos, para tomar las decisiones adecuadas.

En Threat Modeling 101: Ten Common Traps Not to Fall Into hablan del modelado de amenazas (‘threat modelling’) y algunos trampas en las que se puede caer y que conviene tener en cuenta:

  • Usar nuestros sentimientos

Está bien que conozcamos el negocio y todo eso, pero nuestras sensaciones no son suficientes para justificar decisiones. Sobre todo por lo que podemos dejarnos en el camino.

  • Nunca terminas de hacer modelado de amenazas.

Puede ser cierto, siempre hay más cuestiones que considerar. Sugieren seguir los pasos: modelar, identificar amenazas, mitigar, validar.

  • La forma de hacer modelado de amenazas es X

Como casi siempre, la forma perfecta de hacer las cosas no existe, depende del contexto, de quién lo hace, los medios disponibles,…

  • Se trata de una capacidad (‘skill’)

En realidad se trata de un conjunto de técncias y herramientas para mejorar en nuestra habilidad de llevar a cabo el trabajo. También la lectura y formación adecuadas.

  • El modelado de amenazas se sabe, no se aprende

Como todo, se trata de aprender, practicar, perfeccionar…

  • Foco incorrecto

A veces se piensa que el objetivo es encontrar amenazas cuando en realidad se trata de mitigarlas y/o solucionarlas.

  • El modelado de amenazas es para especialistas.

En realidad cualquier desarrollador debería incluir en su proceso de desarollo estas ideas, para hacer sus programas mejores.

  • El modelado de amenazas de manera aislada.

En realidad puede ser otra forma más de ayudar a comunicar a los distintos agenets en el procseo.

  • Excesivo foco en las amenazas.

En realidad los ataques, elementos de mitigación y requisitos van de la mano. Unos pueden ayudar a comprender mejor los otros e incluso pueden obligar a tener que adaptarlos.

  • Modelado de amenazas en el momento incorrecto.

Como siempre, pensar en la seguridad al final del proceso es la receta segura para que haya cosas que ya no tengan remedio.

Se puede ver una retransmisión de la charla en Threat Modeling: Lessons from Star Wars - Adam Shostack aunque a lo mejor con las ideas principales ya nos parece suficiente.

El copyright puede facilitar algunos fraudes

Un Volskwagen en la carretera Ya hacía tiempo que no hablábamos de copyright y coches. En Draconian US copyright rules made it easier for Volkswagen to cheat reúnen el tema de las restricciones sobre el acceso a la información de nuestros vehículos y un escándalo tan sonado como es el engaño por parte del fabricante Volskwagen con respecto a las emisiones de sus vehículos.

El titular lo dice todo y no hay mucho más que añadir: puesto que ni siquiera los propietarios de los vehículos tienen acceso a sus interioridades, es bastante difícil que esa parte de la auditoría que vendría del público interesado sea realizada. Recordemos que el fraude vendría porque los parámetros del vehículo podían cambiar de la mano de algunos programas instalados que serían capaces de determinar en que circunstancias se encontraba el mismo y, en particular, cuando estuviese siendo sometidos a las pruebas de emisiones.

In the case of Volkswagen, cars with diesel engines were equipped with software that determined when they were undergoing Environmental Protection Agency testing for carbon emissions. During a test, the software would turn off mechanisms that increased engine performance, thus decreasing emissions; under normal driving conditions, the performance enhancement would be turned on and emissions were higher.

Como nota lateral, también nos alerta contra los procedimientos excesivamente fijos y automatizados que permiten que un programa pueda detectarlos y modificar este comportamiento. Un buen probador debería tener un guión, pero también debería poder incluir actividades ‘no programadas’ e imprevistas que puedan consegui saltarse el guión previsto por el que realizó el producto. Porque conviene no olvidar que esos ojos mirando podrían haber encontrado el problema, pero también podría haber ocurrido que nadie mirase en el lugar adecuado (Más fallos con una larga historia).

Ataques por ocupación de nombres de paquetes en diversos lenguajes

Paquete Queremos que todo sea fácil: descubrir algo, instalarlo, que se ejecute sin problemas y pasar a pensar en otra cosa. Basándose en la idea del typosquatting basado en DNS (esto es, cuando tecleamos de manera incorrecta el nombre de un sitio web), Nikolai Philipp Tschacher pensó en explorar la posibilidad de hacer algo parecido con los repositorios de código de diversos lenguajes: se crean paquetes con nombres parecidos a los de algunos de uso frecuente y se monitoriza el número de instalaciones de los mismos.

Lo cuenta en Typosquatting programming language package managers y desde allí se puede acceder a un documento completo en pdf.

Los resultados son interesantes: más de 17.000 máquinas instalaron esos paquetes y ejecutaron el código, siendo alrededor de la mitad las instalaciones realizaddas con permisos de administrador.

As a sample data set I will make use of my workout progress data between May 2016 and August 2016.

  • 17000 computers were forced to execute arbitrary code by typosquatting programming language packages/libraries
  • 50% of these installations were conducted with administrative rights
  • Even highly security aware institutions (.gov and .mil hosts) fell victim to this attack
  • a typosquatting attack becomes wormable by mining the command history data of hosts
  • some good defenses against typosquatting package managers might look like

Es cierto que los investigadores de seguridad se dieron cuenta con cierta rápidez de que estaba ocurriendo el problema (unos días). El experimento se realizó entre noviembre de 2015 y enero de 2016, subiendo un cierto número de paquetes de los que más de la mitad se había generado el nombre de manera aleatoria. Los lenguajes elegidos para el ataque fueron Python, Node.js (recuerden el incidente con aquél paquete …) y Ruby, aunque otros podrían tener problemas similares con los repositorios análogos (con GitHub y otros alojamientos podrían pensarse ataques similares, si alguien se toma la molestia).

Dice el autor que los requisitos para que un ataque así funcione se basa en:

  • Posibilidad de registrar cualquier nombre de paquete y subir código sin supervisión.
  • Posilibidad de conseguir ejecución de código con el paquete descargado.
  • Accesibilidad y disponibilidad de buena documentación para subir y distribuir paquetes en los repositorios.
  • Dificultad para aprender rápidamente el lenguaje objetivo.

Por supuesto, la ejecución del código no es imprescindible si pensamos en paquetes de infraestrcutura, bibliotecas y módulos, etc., que terminarán siendo ejecutadas por los programas que las invocan.

Entre las contramedidas, habría que evaluar la prohibición de determinados nombres (en particular, paquetes importantes cuyo nombre cambió con el tiempo y paquetes del core), reducir el número de caracteres disponibles para el nombre de los paquetes, añadir espacios de nombres y, claro, hacer las cosas más difíciles evitando la ejecución directa de código en la ejecución.

También se puede utilizar lo aprendido en los gestores de paquetes de código (por ejemplo, los de algunas distribuciones de Linux), así como analizar los errores que comenten los usuarios para tratar de poner las contramedidas adecuadas.

En el apartado de anécdotas y sucesos, parece que poca gente prestó atención al experimento aunque se lanzaban los avisos adecuados aunque sí que hubo alguien que lanzó un contra-ataque tratando de explotar alguna vulnerabilidad mediante inyección de SQL. También había usuarios (IPs) que realizaban instalaciones repetidas, invistiendo en el error.

Primeros pasos con Pine64

Caja del Pine64 Como decíamos el otro día, tenía pendiente de terminar de poner en marcha mi Pine64.

El Pine64 llegó hace bastantes días pero no había encontrado la ocasión de ponerme y cuando la encontré no lo conseguí a la primera. Desde luego, no es un proyecto tan bien acabado como el C.H.I.P. Primeros pasos con el C.H.I.P. y tampoco le había dedicado tiempo suficiente. El primer problema que tuve con una distribución Ubuntu que puse en una tarjeta de memoria era que intentaba buscar una conexión ethernet; como no le había puesto el cable, se quedaba atascado hasta que expiraba el tiempo correspondiente (timeout): eso me hizo perder algún rato pensando que la imagen estaba defectuosa.

Cuando por fin me di cuenta y arrancó, configuré la red y seguí teniendo problemas de conexión en la red local (no me detuve mucho a ver qué pasaba, decidí probar otra distribución).

Tampoco ayudó mucho esta entrada negativa Pine64: the un-review que exponía bastantes quejas sobre la placa.

A primera vista es una placa gigantesca: ocupa casi el mismo espacio que tres Raspberry Pi (que a la vista de los últimos dispositivos que vamos consiguiendo ya se nos hace algo grande). Además es exigente en cuanto a la alimentación necesaria (no nos servirá cualquier cargador) y la base no está muy refinada (si lo apoyamos en nuestro típico brazo de sillón de casa se enganchará).

Una de las web de referencia sería Pine64 y allí se puede ver información. En Downloads hay recopiladas diversas imágenes con sistemas operativos que incluyen Android, Remix OS, Debian (la que finalmente instalé), Ubuntu y otras…

Pine 64 al lado de la Raspberry Pi y un Arduino

Una vez que conseguimos que arranque disponemos de un sistema funcionando que configuramos a nuestro gusto y podemos empezar a trabajar. En unas pruebas sencillas se ve que es más rápida que el C.H.I.P. y la vieja Raspberry pero en la práctica la sensación no es de mucha soltura (si me preguntaran sin haber hecho alguna prueba habría dicho que el C.H.I.P. iba más fluído). Eso a pesar de tener un procesador a priori más capaz y cuatro cores.

Seguimos aprovechándonos de la copia de configuraciones desde otras máquinas para poder conectarnos en diferentes sitios y ya podemos gestionarla desde un portátil mediante ssh.

El escritorio:

Pine64 Desktop

En el apartado negativo, pedí dos módulos adicionales y sólo ha llegado uno. Aparentemente están (o han estado colapsados) y sigo sin la cámara que pedí. Confíoen que cuando se normalice todo terminaré recibiéndola.

Entre sus características

  • Procesador 1.2 Ghz Quad-Core ARM Cortex A53 64-Bit con Dual core Mali 400 MP2 GPU.
  • 512 Mb, 1Gb o 2Gb de RAM (yo tengo la de 1Gb)
  • Bluetooth 4.0 and 802.11BGN (vendida como añadido aparte).
  • Salida de vídeo HDMI 920×1200 HDMI v1.4 hasta 4K.
  • Dos puertos USB y puerto micro USB OTG (se usa para alimentación)

A ver si damos con algún proyecto adecuado para este chisme.

Primeros pasos con el C.H.I.P.

C.H.I.P. Durante el último año he apoyado algunos proyectos en Kickstarter. Por ser más concreto, el MeARm que lo tengo en dique seco, PiJuice que sigue sufriendo retrasos, Pine64, que llegó hace algunas semanas pero todavía no he podido ponerlo a funcionar (comentaré, supongo, sobre ello más adelante). Además compré un par de C.H.I.P. que no era en Kickstarter pero si ha seguido el modelo de compra anticipada y ya lo recibirás. Entre los inconvenientes de este modelo de compra es que el momento en que decides apostar por un proyecto no tiene nada que ver con el momento en el que recibes el resultado.

El C.H.I.P. llegó la semana pasada y me encanta: buena documentación, todo bien pensado para trabajar rápido y unas prestaciones adecuadas (que nadie espere supercomputación, claro).

Frente a otras placas y sistemas que nos hacen esforzarnos un poco al principio, este aparatito de 9 dólares está muy bien pensado: lo conectamos a nuestro ordenador, arranca y abre un puerto serie a través del que podemos empezar a trabajar (para los que lo prefieran, también se puede conectar a una pantalla o a la televisión para configurarlo):

If everything went OK, you can now power up your CHIP again and connect via serial as a USB gadget:

  screen /dev/ttyACM0 115200

Ya imagino que esto puede ser un freno para muchos así que tranquilos, que también se puede usar con la tele o con una pantalla y usar el ratón:

C.H.I.P. on TV

Y desde allí configurar la red (sin más cables que un USB), el ssh, el usuario de trabajo y ponerse a funcionar la próxima vez que arranque. También tiene (por si fuera necesario) un gestor de conexiones basado en texto (nmcli) y sólo si queremos redes más complicadas (de tipo empresarial) necesitaremos trabajar un poco más. Aunque gracias a eso he ‘descubierto’ las ventajas de copiar y pegar las configuraciones entre sistemas (con cuidado) e incluso se me ha ocurrido un posible proyecto: Sharing WiFi configuration files over diffferent computers. También que, aparentemente, es un tema que ya está bien resuelto en Windows 10 y en Mac OS. Tenemos que espabilar.

El escritorio:

C.H.I.P. Desktop

No he tenido tiempo de mucho más (instalar el Python, el pyenv y fantasear sobre hacer algunas pruebas con el MeArm (ahora sí).

En el apartado negativo: C.H.I.P. es un mal nombre. Buscar en internet algo que se llama chip es perder el tiempo y la paciencia (no ayuda tampoco, claro, que es un proyecto relativamente nuevo y con poca difusión). Otra pequeña pega es que cuando añades un disco USB no lo monta automáticamente (con el esritorio sí, pero no quiero usarlo con una pantalla).

Entre sus características (copiadas y traducidas de [The PocketC.H.I.P. Is the Handheld Linux Machine I’ve Been Looking For)[http://lifehacker.com/the-pocketc-h-i-p-is-the-handheld-linux-machine-ive-be-1783247338])

  • Procesador Cortex A8 R8 a 1Ghz con una GPU Mail-400
  • 512 Mb de RAM
  • 4 Gb de memoria flash
  • Wifi 802.11 b/g/n y Bluetooth 4.0
  • Salida de vídeo con conector de 3.5mm para vídeo compuesto y audio.
  • Puerto USB y puerto micro USB OTG (se usa para alimentación)

Interesante

Amazon. Elogio de los métodos formales

Bug Cuando hablemos de métodos formales en informática enseguida nos tacharán de teóricos, alejados de la realidad y poco prácticos. Tal vez sea así para programas sencillos y poco comprometidos, pero a partir de cierto nivel de complejidad una herramienta más siempre ayudará. En How Amazon Web Services Uses Formal Methods (no se si está accesible públicamente, tal vez este sí que sea fácil de leer [PDF] Use of Formal Methods at Amazon Web Services).

En concreto nos hablan de modelos formales y ‘model checking’ para ayudar a rseolver problemas difíciles de diseño en sistemas críticos. Las herramientas estándar de la industria se quedan cortas en algunos casos:

We have found the standard verification techniques in industry are necessary but not sufficient. We routinely use deep design reviews, code reviews, static code analysis, stress testing, and fault-injection testing but still find that subtle bugs can hide in complex concurrent fault-tolerant systems.

Las limitaciones de las pruebas (‘testing’):

We have found that testing the code is inadequate as a method for finding subtle errors in design, as the number of reachable states of the code is astronomical.

Tampoco es que lo utilicen de manera extensiva, claro. Lo usan para encontrar fallos sutiles y también para mejorar la comprensión y la confinanza en las mejoras que aplican en unos cuantos sistemas:

At the time of this writing, Amazon engineers have used TLA+ on 10 large complex real-world systems. In each, TLA+ has added significant value, either finding subtle bugs we are sure we would not have found by other means, or giving us enough understanding and confidence to make aggressive performance optimizations without sacrificing correctness.

En varios equipos y con apoyo al máximo nivel:

Amazon now has seven teams using TLA+, with encouragement from senior management and technical leadership.

Yo creía que esto sólo les pasaba a los principiantes, pero parece que es algo común: nos centramos en los casos normales, sin pensar en que puede haber fallos y errores.

Engineers naturally focus on designing the “happy case” for a system, or the processing path in which no errors occur.

La forma de enfrentarse al problema: cómo debería funcionar, en lugar de pensar en lo que podría ir mal:

We find this rigorous “what needs to go right” approach to be significantly less error prone than the ad hoc “what might go wrong” approach.

Para evitar fallos es necesario que todo el mundo comparta la misma visión del sistema, que debe ser correcta, ajustada, precisa, completa …:

To avoid creating subtle bugs, we need all engineers to have the same mental model of the system and for that shared model to be accurate, precise, and complete.

Los métodos formales también tienen sus inconvenientes, claro: es difícil evaluar (al menos para ellos en este momento) los fallos que provocan degradación del sistema y que se realimentan:

… surprising “sustained emergent performance degradation” of complex systems that inevitably contain feedback loops

También se habla de la forma de comenzar, los aspectos ‘sociales’ (el lenguaje utilizado):

Engineers think in terms of debugging rather than “verification,” so we called the presentation “Debugging Designs.

We initially avoid the words “formal,” “verification,” and “proof” due to the widespread view that formal methods are impractical.

¿Qué proporcionan los métodos formales? Según los usuarios ayudan a obtener buenos diseños (‘Get design right’), comprender mejor el sistema (‘Gain better understanding’) y también a escribir código mejor (‘Write better code’).

Lectura muy interesante.

Seguridad, usabilidad e incentivos

Robusto pero incómodo En Usable Security: How to Get It un artículo sobre usabilidad y seguridad. Se habla de la seguridad por culpa de los fallos, pero también se nos recuerda que muchas veces tenemos menos seguridad de la debida porque preferimos la comodidad:

Conflicts: Even more important, security gets in the way of other things you want. In the words of General B.W. Chidlaw, “If you want security, you must be prepared for inconvenience.”a For users and administrators, security adds hassle and blocks progress. For software developers, it interferes with features and with time to market.

También se habla de la seguridad como gestión de riesgos, y hay que tener en cuenta todos los costes:

Security is really about risk management: balancing the loss from breaches against the costs of security. Unfortunately, both are difficult to measure. Loss is the chance of security breaches times the expense of dealing with them. Cost is partly in dollars budgeted for firewalls, software, and help desks but mostly in the time users spend typing and resetting passwords, responding to warnings, finding workarounds so they can do their jobs, and so forth. Usually all of these factors are unknown, and people seldom even try to estimate them.

Porque, en definitiva, estamos hablando de economía:

More broadly, security is about economics.2 Users, administrators, organizations, and vendors respond to the incentives they perceive. Users just want to get their work done; …

Las organizaciones tienden a valorar sólo una parte de la ecuación:

They don’t measure the cost of the time users spend on security and therefore don’t demand usable security.

Pero todo depende de los incentivos:

People think that security in the real world is based on locks. In fact, real-world security depends mainly on deterrence, and hence on the possibility of punishment.

Lectura interesante

Sobre la autentificación de dos factores

Enséñame la patita. Vale, no tenía otra foto con patitas. Llevamos una temporada en la que uno de los mantras de los de seguridad en temas de autentificación es: ‘utiliza autentificación de dos factores’. Ya saben: normalmente una contraseña que nos sabemos y algo más (típicamente un mensaje que recibimos de alguna forma o algún dato generado de alguna forma). Aunque los beneficios están claros, me resisto a recomendarla abiertamente porque cuando funciona lo hace muy bien, pero cuando falla estamos fuera (ese SMS/correo que no llega, justo cuando más lo estamos necesitando o ese canal alternativo que en ese momento no está disponible). Sin ponernos en el caso de que alguien sea capaz de interceptar los mensajes de ese canal secundario, como nos recordaban recientemente en SMShing para robar tu 2nd Factor Authentication en tus cuentas Google o Apple #SMShing #Google #Apple. Y sin olvidar que ese canal alternativo (típicamente el teléfono móvil) se ha convertido en canal unitario.

A lo que vamos, en Why You Don’t Need 2 Factor Authentication nos lanzaban una serie de argumentos contra el sistema, que me gusta traer aquí:

  • Mito 1: lo que sabes, lo que tienes, bla, bla, bla

El autor dice que no todo es tan sencillo y que hay más categorías y más que centrarnos en esa clasificación deberíamos preocuparnos de los factorse utilizados y sus características.

  • Mito 2: la autentificación de dos factores hace mi cuenta más segura, sin consecuencias negativas

En realidad, perdemos tiempo en esa parte del proceso, la aplicación es más compleja, y no evita otros inconvenientes.

Al final, la autentificación de dos factores es un gestor de contraseñas para ‘perezosos’ (porque lo gestiona el proveedor del servicio). Me parece un punto de vista interesante, aunque conociendo la tendencia a la pereza de los usuarios igual es la única solución viable.

Manifiesto ágil para el desarrollo seguro

Agile Security Manifesto No es la primera vez que hablamos de desarrolo ágil y seguridad (Seguridad en proyectos ágiles y DevOps y seguridad. En esta ocasión nos referiremos a The Agile Security Manifesto de la empresa Cigital, que propone los siguientes principios:

  • Confiar en los desarrolladores y probadores más que en los especialistas en seguridad
  • Asegurar mientras desarrollamos mejor que cuando el trabajo está hecho
  • Implementar las características de manera segura mejor que añadir características de seguridad.
  • Mitigar los riesgos mejor que arreglar los fallos.

Interesante.

Desarrollar software cuando el software no es tu objetivo

ADN En The myths of bioinformatics software algunos comentarios sobre los programas que se utilizan en bioinformática pero que creo que se puede extender a casi cualquier rama del conocimiento: poco pensado para ser publicado y reutilizado, desarrollado muchas veces por personas sueltas o equipos muy pequeños y un poco a salto de mata, que luego es difícil de leer/modificar/mantener por otros.

También comenta con que las licencias permisivas no son una ayuda cuando se desarrolla con esa precariedad (y esos objetivos). También habla de la posibilidad de vender los programas y hasta qué punto podemos estar subvencionando a empresas privadas si les cedemos de manera gratuita los programas para uso comercial y algunas cosas más.

No estoy seguro de estar de acuerdo con todo, pero es interesante leer el punto de vista de alguien que desarolla software pero no es su misión principal.

Seguridad para usuarios no interesados en seguridad

Palabras Transmitir conceptos de seguridad a gente ya preparada es más fácil (aunque hasta en eso tengo dudas). Pero cuando hablamos de usuarios finales tenemos realmente un problema. Yo suelo decir que los usuarios (y muchos profesionales) conocen sobre seguridad lo que escuchan/leen en las noticias y esto es bastante preocupante.

De eso hablaban en Escape the Echo Chamber: Educating End-Users and Non-Security People.

El autor lleva tiempo dedicándose al tema, incluso ha escrito un libro:

Since that day in March (2014), I have studied this problem and what began as a set of practices for my family has evolved into a new book, How Not To Be Hacked. Below, I share the barriers that I discovered in educating regular people and how you can carry this forward within your own organization.

Las barreras serían:

  • Los usuarios no quieren convertirse en expertos en seguridad.

No hay mucho que comentar sobre esto. Cada uno quiere hacer su tarea, acabarla pronto y bien.

  • Demasiado preciso no es suficientemente preciso.

Si le preguntamos a algún técnico sobre algo la respuesta suele ser: ‘depende’ y esto es algo que al usuario no le sirve para nada al final. Tendríamos que cambiar este tipo de respuestas por las que sean suficientemente buenas (en lugar de perfectas).

  • Falta de inteligencia emocional.

Tenemos que empatizar con los usuarios de tecnología, ayudarles, explicarles, y simplificarles los problemas.

Creo que compraré el libro.

Un informe sobre productos criptográficos

Escondido En A Worldwide Survey of Encryption Products podemos leer un interesante informe en el que se puede leer la prometida lista de productos pero también una introducción donde se sugieren algunas ideas interesantes.

Se identifican 587 productores de este tipo de software:

The new survey also identified 587 entities that sell or give away encryption products, and of those, two-thirds are outside the US.

Se comenta sobre la eficacia de las instrucciones para añadir puertas traseras a los productos criptográficos que algunos gobiernos imponen:

Schneier argues in the paper that the survey findings call into question the efficacy of any US mandates forcing backdoors for law-enforcement access. He asserts that they show that anyone who wants to avoid US surveillance has hundreds of competing products to choose from. The report findings indicate that foreign products offer a wide variety of secure applications—voice encryption, text message encryption, file encryption, network-traffic encryption, anonymous currency—providing the same levels of security as US products do today.

Los mayores productores de criptografía serían, después de EEUU:

The most common non-US country for encryption products is Germany, with 112 products. This is followed by the United Kingdom, Canada, France, and Sweden, in that order.

Entre los datos se pueden encontrar siete productos identificados como españoles de, si no cuento mal, seis empresas diferentes:

Mirando los enlaces veo que algunas de estas empresas tienen más productos y tampoco es fácil determinar el origen así que, como decíamos arriba, igual lo más interesante son las primeras páginas del informe y echarle un ojo a la lista para hacerse una idea.

Transplantes de código para arreglar fallos

Bicho Me dan un poco de miedo las analogías ‘médicas’ porque siempre hay quien termina tomándoselas al pie de la letra (recuerdo hace un montón de años escuchar una conversación en el tren de alguien que le contaba a otro como los virus informáticos se inoculaban con una jeringuilla).

En este caso la idea es muy sugerente: MIT tests ‘software transplants’ to fix buggy code, utilizar el código de programas que funcionan correctamente para ‘reparar’ programas con fallos:

La idea se basa en entradas de datos que hacen fallar el programa y otras que no lo hacen fallar.

To fix a buggy program, CodePhage requires two sample inputs, one that causes the program to crash, and another that does not.

Se utilizan para verificar en un ‘donante’ que se obtienen los resultados correctos y a partir de allí ya se sabe que se puede utilizar ese nuevo código para corregir el programa defectuoso:

It runs those inputs through a second program, known as the donor program, that has similar functionality. The Internet is awash with open source software that could provide parts for donor programs, though there’s no particular reason the donor code needs to be open source.

Si leemos algunos detalles más en System fixes bugs by importing functionality from other programs—without access to source code podemos ver que se trata de algo que deberíamos denominar, más bien, ‘microtransplantes’, porque se trataría de pequeños bloques de código.

En el artículo (seguramente no accesible para todos), Automatic error elimination by horizontal code transfer across multiple applications se puede ver, por ejemplo un fallo en el programa gif2tiff, corregido mediante la ‘donación’ desde ImageMagick:

#define MaximumLZWBits  12
if (data_size > MaximumLZWBits)
   ThrowBinaryException(CorruptImageError,
         "CorruptImage",image.filename);

Este código sería susceptible de un ataque de desbordamiento de memoria y el programa propondría corregirlo con:

if (!(datasize <= 12)) {exit(-1);}

Me encanta.

Correo para la gestión de accesos

Asignando identificadores Traigo hoy un par de referencias sobre algo que muchas veces ya estamos haciendo los usuarios en la práctica (y que algunos proveedores han ‘estandarizado’ más o menos en lo que denominan sistemas de acceso sin clave): cuando no recordamos la contraseña utilizamos el botón de recordarla y accedemos al sitio. Posteriormente, si no es un sitio que visitamos con frecuencia la olvidamos y la próxima evez seguiremos el mismo procedimiento.

En este caso lo contaban en How to Fix Authentication: Email as a Password Manager. En este caso proponen que este sea el método de acceso y, por lo tanto, proponen que la contraseña remitida sea de un sólo uso. Las ventajas: no hacen falta aplicaciones extra, no hay problemas de sincronización (aunque a veces sabemos que los correos se ‘atascan’ o no podemos acceder a ellos de forma temporal), simple para los desarrolladores (al final los protocolos de recuperación de contraseña tienen su complejidad, recordemos Introducing the “Secure Account Management Fundamentals” course on Pluralsight), el registro y la entrada son iguales (con matices, supongo, por la cuestión de si estás ya registrado con una cuenta de correo diferente), sólo es necesario un click, podemos controlar la duración de la validez del enlace, y no necesitamos almacenar constraseñas (y, por lo tanto, no nos las pueden robar). No termino de estar de acuerdo con la ‘ventaja’ de evitar el Facebook Connect (y similares) salvo por evitar su complejidad. Y tampoco con que no se puede aplicar fuerza bruta: obviamente se puede, aunque nosotros ahora tenemos más control sobre la dificultad de encontrar los enlaces, frente a las contraseñas que los usuarios suelen elegir de manera inadecuada.

Como inconveniente, está claro que trasladamos toda la seguridad de nuestro sistema al proveedor de correo y a la gestión que el usuario haga de él. Hay más, claro, nunca nada es tan fácil como creemos al principio.

No habría que olvidar la vigilancia de las cuentas gestionadas de esta manera (observación de anomalías, cambios, novedades,…) que también parece ser una de las tendencias en seguridad de cuentas hoy en día.

En History of Email-Only Auth hay más información y opiniones de diversas personas sobre ideas similares.

Hacen falta más expertos en desarrollo seguro

Libros sobre desarrollo seguro Hoy traemos un vídeo reciente sobre la escasez de talento en temas de seguridad en la industria (en EEUU, por nuestros lares ahora parece que nos acabamos de dar cuenta de que los informáticos son importantes, lo de seguridad llegará dentro de una temporada).

En el vídeo se habla de muchos temas, algunos de los cuales hemos tratado por aquí y en clase (ejemplos inseguros y otros asuntos).

Aunque no pude dedicarle toda la atención que debería me pareció interesante porque incide bastante en el tema de la formación, la seguridad en el desarrollo (y no sólo la del sistema y esas cosas en las que pensamos normalmente cuando se habla de seguridad informática).

Biometría y autenticación

Huellas humanas Traigo aquí una entrada del blog del INCIBE sobre biometría: Patrones biométricos y autenticación dinámica.

Todavía no se puede decir que sea una tecnología de alta implantación pero ya los teléfonos móviles de gama alta llevan lector de huellas y no es raro verla en portátiles, pero los expertos (y algunos productos comerciales) ya están pensando en la siguiente generación: la autenticación contínua. Cuando estamos utilizando una máquina, ésta debería ser capaz (y es) de medir determinados parámetros y evaluar si se parecen a los ‘de siempre’ o algo ha cambiado, para tratar de detectar intentos de uso fraudulento. En realidad estamos en un nivel más allá de los métodos tradicionales de autentificación con el ‘algo que eres’ como elemento identificativo. Si lo piensan, nuestro estándar de ‘autentificación’ en el mundo físico era la firma, que ahora se podría reforzar con sistemas informáticos no sólo a su aspecto sino a otros como presión, velocidad, dinámica…

Estos mecanismos siguen un esquema de análisis en tiempo real que monitoriza pulsaciones de teclado o gestos táctiles del usuario que son contrastados con patrones previamente registrados. Estos registros almacenan varios parámetros que caracterizan los patrones de comportamiento esperados para cada individuo tales como como la velocidad de tecleo, pausas, tiempo que se mantienen pulsadas las teclas, presión, etc.

Aunque no habrá que olvidar Algunos problemas de la biometría y repasar las Guías sobre biometría del INTECO.

La seguridad como argumento publicitario

Sensor Ya hemos hablado otras veces de estos temas: la seguridad hoy por hoy no constituye un argumento de venta. Los usuarios nos fijamos más en las funcionalidades, diseño y otros argumentos. Muchas veces la seguridad la vemos como algo molesto, que nos frena.

Por eso traigo aquí una nota de prensa que ni siquiera conozco si ha tenido efecto en las ventas y si el programa sigue activo Panda Security compensará a sus clientes en caso de infección. Indudablemente, utiliza la seguridad como argumento de ventas (algunos dirán que es trampa puesto que publicitan programas anti-virus que van, precisamente, de eso) pero hasta donde yo se, es la primera (o una de las primeras veces) que un anti-virus ofrecía ese nivel de garantía. Se pueden leer los términos en Garantía Panda y dice:

Si te infectas tienes 6 meses de servicio gratis. Y si tienes daños, o no te lo resolvemos en 24 horas, te devolvemos el diner.

Ataques a la BIOS en Apple

Apple Store Uno de los problemas cuando queremos tener un sistema seguro es que hay demasiados sitios donde alguien puede querer probar a atacarnos y es bastante difícil que seamos expertos en todo y/o que podamos dedicarle atención a todos los problemas durante todo el tiempo.

Como ejemplo, en Veneno, manzanas y un amargo despertar nos cuentan la historia de un rootkit que se podía instalar en el firmware de todos los MacBooks anteriores al año 2014 mediante un ataque bastante sofisticado, que se basaba en que las protecciones contra escritura de la BIOS se encontraban desactivadas tras la vuelta del sistema desde el modo Sleep.

Hay más detalles en The Empire Strikes Back Apple – how your Mac firmware security is completely broken pero el aviso es claro: los malos tienen muchas puertas de entrada.

Almacenamiento seguro de claves

Hablando de almacenamiento Llevo dándole vueltas a este tema una temporada (incluso investigué un poquillo para un proyecto personal Storing credentials of your Python programs in the keyring, y ando jugando con el keyring en Python; se pueden ver ejemplos en cleanImapFolders.py, addToSieve.py . Tengo pendiente comentar sobre estos programas. Además he descubierto el proyecto passpie que aporta una solución de almacenamiento interesante también).

Pero me está quedando un preámbulo muy largo y en realidad quería comentar Storing Passwords Securely que es una introducción genérica (pero no superficial) y que aporta una buena panorámica a los temas que hay que prestar atención incluyendo algunos ejemplos. Lectura recomendable.

Seguridad y aseguradoras

Geekonomics Este tema me resulta muy interesante: hemos vivido (y seguimos viviendo en muchos casos) como si los programas no pudieran ocasionar daños y, si los causan, el desarrollador/vendedor no tiene ninguna responsabilidad. Eso va cambiando con el tiempo, claro. Ya hablámbamos de Las actualizaciones … ¿como ventaja competitiva? y en los casos de los coches ha habido demandas y juicios Desbordamientos de memoria y Toyota.

En este caso traemos Insurer tells hospitals: You let hackers in, we’re not bailing you out que iría en la misma línea. En este caso se observó que la seguridad informática era muy deficiente y en consecuencia la aseguradora se niega a abonar los costes asociados, reclamando su devolución:

Columbia argues that it is not liable for the payout because Cottage did not provide adequate security for its documents, a clause the California hospital network agreed to when it signed the insurance policy.

Among the allegations, Columbia claims that Cottage failed to check for and apply security patches within 30 days of release, replace default access settings on security devices, undergo annual security audits, and outsourced data to firms with poor security. Cottage is also accused of failing to provide adequate detection and tracking of changes to its network and data.

Java después de veinte años

Libro Java El año pasado Java cumplía 20 años. Por ese motivo se publicaba Java at 20: How it changed programming forever donde se hace un resumen de sus ventajas más notables.

Según el autor, su principal fortaleza consistiría en ser una herramienta para tener el trabajo hecho:

But Java’s core strength was that it was built to be a practical tool for getting work done. It popularized good ideas from earlier languages by repackaging them in a format that was familiar to the average C coder, though (unlike C++ and Objective-C) Java was not a strict superset of C. Indeed it was precisely this willingness to not only add but also remove features that made Java so much simpler and easier to learn than other object-oriented C descendants.

Habla sobre el problema de los ‘applets’ (casi en fase de certificación oficial de su muerte, en estos momentos):

The irony is that applets never worked very well. They were completely isolated from the content on the page, unable to read or write HTML as JavaScript eventually could. Security constraints prevented applets from interacting with the local file system and third-party network servers. These restrictions made applets suitable for little more than simple games and animations.

Por completar, traigo un elogio del Java hecho por un desarrollador de Python que se autocalifica como converso: Why Java? Tales from a Python Convert que destaca la máquina virtual, las bibliotecas, la robustez de los tipos de datos y la concurrencia. También habla de las construcciones más modernas. Nos ha recordado aquella serie de la que hablábamos en Motivos por los que debería gustarnos Java donde se daba un buen repaso a las principales características de Java.

Explicación de los principales algoritmos de minería de datos

Puente colgante Antes del ‘big data’ se hablaba de minería de datos (‘data mining’) como precursora (y con intersección no vacía) me resultó interesante Top 10 data mining algorithms in plain English donde justamente describen eso: los algoritmos de minería de datos más importantes descritos de una forma más o menos sencilla.

Puede ser de interés para alguien que quiera tener una idea de las posibilidades, o como recordatorio para los que ya las hayan olvidado. De paso, aprendemos un poco de terminología general.

Es difícil identificar los correos de phishing correctamente

Phishing El phishing es una técnica que utilizan los estafadores para robar información personal: se envía un correo electrónico que parece provenir de alguna entidad en la que confiamos y que nos invita a pinchar en un enlace. En el sitio de destino (que no es el que se supone que debería) se nos solicitan datos que confiadamente proporcionaremos.

Sobre este tema, tengo un par de teorías:

  • Los sitios de redes sociales han destruido cualquier tipo de posibilidad de que sigamos sosteniendo ante los usuarios aquello de que no pinchen en los mensajes de correos. Sistemáticamente recibimos mensajes invitándonos a realizar acciones, y pichar enlaces; como usuarios es lo habitual. Eso hará difícil frenar a los de marquetin de nuestra empresa para tratar de hacer cosas parecidas.
  • Para la mayoría de usuarios no es necesario hacer grandes montajes ni sitios que se parezcan mucho a los legítimos: hemos visto frecuentemente burdas páginas de solicitud de credenciales construidas con formularios de Google Docs (y otros sitios) sin ningún tipo de personalización, lo que parece indicar que muchos usuarios no son nada precavidos (por decirlo suavemente).

En Can you correctly identify phishing emails? nons hablan sobre un experimento de Intel que mostraba diez mensajes de correo y preguntaba a los usuarios cuáles eran legítimos y cuáles no:

An Intel Security quiz presented ten emails and asked respondents to identify which of the emails were phishing attempts designed to steal personal information and which were legitimate.

El resultado es bastante decepcionante porque sólo un 3% de los que respondieron fueron capaces de identificar correctamente todos los mensajes y el 80% de los que respondieron identificaron incorrectamente al menos uno de los correos de phishing como válido.

Habría que añadir que eso no es un problema en sí mismo, porque además de pinchar tenemos que seguir engañados a la hora de proporcionar nuestros datos y allí todavía podemos estar atentos. Aunque es cierto que en algunos casos, el hecho de pinchar en el enlace ya podría tener consecuencias desagradables:

In some cases, just clicking the link provided in the email will automatically download malware onto the user’s device. Once the malware is installed, hackers can easily steal the victim’s information without their knowledge.

Hay que estar atentos.

.es, la web anticuada

Respuesta servidor Una de las formas que tenemos hoy en día de averiguar como es el mundo es preguntando a la web. Se trata de desargar y analizar la información (meta-información) disponible en internet que nos puede dar pistas sobre las organizaciones en distintos ámbitos. De ello hablábamos el otro día en Alguien puede estar tratando de conocerte mejor pero hemos hablado más veces antes: demoscopía.

Hoy vamos a hablar un poquito de los servidores web en los dominios .es. En Análisis de servidores web en dominios “.es” (I) Luis Martín lanzaba un análisis a los servidores web de los dominios .es para determinar qué servidores se estaban utilizando, versiones, sistemas operativos y esas cosas. La conclusión es que el servidor mayoritario es Apache, seguido del IIS. En ambos casos, versiones no muy recientes:

Apaches con más de un año de antigüedad: 109715. Apaches con menos de un año de antigüedad: 37714.

Y también:

8799 dominios usarian IIS actualizados. 105926 usan IIS antiguos y potencialmente vulnerables.

Naturalmente, dada la naturaleza de estos datos esto no significa que todos sean vulnerables (incluso podrían estar proporcionandodatos falsos). Pero muy buena impresión no da.

El análisis continuaba con Análisis de servidores web en dominios “.es” (II), donde se analizan los lenguajes y sistemas de gestión de contenidos utilizados en estas páginas web. Los más populares parecen ser PHP y ASP.NET.

Nuevamente no parece que la actualización sea una de las prioridades de la web española.

Insisto, no hay que tomar como palabra de ley estos datos, pero a mi me dejan un poco preocupado, la verdad:

Hemos de tener en cuenta que este estudio ha sido realizado de manera muy superficial, cuidando hasta el extremo el potencial impacto y siendo lo menos agresivos posible. Toda la información obtenida está “ahí fuera” sin necesidad de “rascar”, disponible para todo el mundo incluidos aquellos sin buenas intenciones. Seguramente un enfoque más profundo (sin necesidad de ser agresivo) proporcionaría mucha más información del estado actual de servicios Joomla!, WordPress, IIS o Apache.

DevOps y seguridad

Libros de seguridad En Building Security Into DevOps: Security Integration Points hay una introducción al tema, que podemos completar con Putting Security Into DevOps.

Se hace un análisis inicial de esta forma de enfrentarse a los proyectos para después pasar a comentar las implicaciones y consecuencias desde el punto de vista de la seguridad (diseño/arquitectura, despliegue, modelo de amenazas, automatización, pruebas …). Y también las herramientas de seguridad como son el análisis estático, dinámico, fuzzing, revisión de código…

Control de versiones desde Python

Pantalla y fichas Aunque el sistema de filtros que introdujimos en Añadiendo filtros de correo a mi sistema con sievelib ha seguido evolucionando con varias características hoy quería traer aquí una que me preocupaba un poco: si vamos añadiendo reglas es bastante probable que en algún momento nos equivoquemos y añadamos alguna errónea. Como además estamos utilizando un sistema que controla los filtros también podría ocurrir que una actualización sobre-escriba las reglas que hayamos creado. La solución adoptada era guardar la historia de los cambios. Pero queríamos ir un poco más allá: ¿tendría sentido gestionar el histórico con un sistema de control de versiones? ¿Sería posible hacerlo?

Buscando encontramos GitPython que nos proporcionaba una interfaz adecuada para lo que estábamos plateando. El código completo en su estado actual se puede ver en addToSieve.py y nos vamos a dedicar a su parte final. Aviso: el resto del código no está muy bien organizado pero funciona razonablemente bien en mi día a día.

Hay que declarar el módulo:

from git import Repo

Al final, cuando ya hemos actualizado las reglas las pasamos al sistema de control de versiones. Instanciamos un repositorio con nuestro directorio de copias de seguridad. repoDir es una cadena de texto que contiene el directorio de trabajo (en mi caso es ~/Documents/config donde guardo varias configuraciones con control de versiones).

	repo = Repo(repoDir)
	index = repo.index

Elegimos el fichero de reglas que acabamos de grabar, lo almacenamos en el fichero que estamos utilizando (en mi caso se llama sogo.sieve, añadimos todos los ficheros del directorio al repositorio y hacemos el commit (con el nombre y la fecha como mensaje):

	
	sieveFile=c.getscript('sogo')
	file=open(repoDir+repoFile,'w')
	file.write(sieveFile)
	file.close()
	index.add(['*'])
	index.commit(name+'sogo')

Finalmente borraremos del servidor algunos filtros almacenados, dejando los últimos cinco nada más. No se hace el push dentro del programa para evitar el tener que teclear otra contraseña y no parece necesario.

Buscando otros proyectos he visto que en history.py hacen algo parecido en un programa de gestión de contraseñas que estoy probando, passpie.

Programando discos SSDs

Viejo disco duro Tenemos un poco descuidada la parte de programación de esta bitácora. Espero poner algo de código en los próximos días pero eso cuesta más tiempo y no es algo que fluya libremente en estos tiempos.

El caso es que lei la primera parte de Coding for SSDs – Part 1: Introduction and Table of Contents y me resultó interesante. La guardé, en parte para ponerla aquí, y en parte para leer el resto de capítulos (aquí estoy reconociendo que sólo he leído el primero). La programación a bajo nivel no es lo mío, pero siempre es bueno tener una idea sobre estas cosas.

Un fallo viejo en máquinas virtuales

Bicho Los fallos que viven y sobreviven a múltiples actualizaciones y cambios terminarán teniendo su propia categoría por aquí. No hace mucho leíamos 11-year-old VM escape bug opens host machines to compromise y lo traemos aquí a título de inventario.

“The VENOM vulnerability has existed since 2004, when the virtual Floppy Disk Controller was first added to the QEMU codebase,” the researchers shared. If you’re wondering why it is still added to new virtual machines by default, it’s because it’s still occasionally used in a number of situations.

No hay mucho más que decir. Siguiendo la moda, el fallo tiene su propia página web: VENOM.

Alguien puede estar tratando de conocerte mejor

Faro vigilando... Si tenemos acceso al registro de actividad de un servidor cualquiera podemos ver todo tipo de intentos de obtención de información; muchas veces se trata de simples troyanos de máquinas infectadas por ahí que simplemente tratan de propargarse y otras de intentos dirigidos (seguramente más raros en servidores ‘caseros’).

En Who’s Scanning Your Network? (A: Everyone) hablaban del tema entrevistando a Zakir Durumeric y Michael D. Bailey que son investigadores de la Universidad de Michigan y que, entre otros proyectos, mantienen el Internet-Wide Scan Data Repository que es un archivo público de datos recolectados mediante escaneos de la parte pública de internet. La respuesta es, como decíamos arriba, que mucha gente nos está vigilando y tratando de obtener información.

Con estos datos son capaces de detectar servidores y servicios vulnerables (e incluso avisarles en situaciones de crisis como el reciente Heartbleed del que hablamos en su momento en [Heartbleed, código y memoria](http://fernand0.github.io/Heartbleed-Y-Certificados/].

Pero no sólo eso, sino también tener cierta capacidad predictiva, com dice Durumeric en:

So, if you can watch, for example, how an organization runs their Web server, how they respond to certificate revocation, or how fast they patch — that actually tells you something about the security posture of the organization, and you can start to build models of risk profiles of those organizations. It moves away from this sort of patch-and-break or patch-and-pray game we’ve been playing.

Por supuesto, no hay que olvidar que esto mismo lo pueden hacer los ‘malos’, vigilando nuestra ‘meta’-información pueden ser capaces de encontrar nuestros puntos débiles y los mejores momentos para atacar (como en las películas ‘clásicas’ de ladrones de bancos, que el atacante aprende los protocolos y momentos adecuados para actuar).

Dicen muchas más cosas interesantes pero nos recuerdan que la seguridad no sólo es algo tecnológico, sino que también tiene que ver con nuestros procesos y forma de actuar. Y que aunque esa información no sea pública tal vez sea posible deducirla.

Claves falsas para despistar al atacante

Escondido Tengo la teoría de que una forma de acabar con el spam sería atacar los recursos de los ‘malos’: si todos respondiéramos no podrían desarrollar correctamente su labor. Tanto es así que a veces, cuando recibo algún correo de Phishing lo relleno con datos falsos con la idea de que tratarán de utilizarlos y consumo, en pequeña medida, sus recursos.

Por eso me hizo gracia leer The best way to protect your passwords may be creating fake ones donde explican una propuesta experimental para asegurar las contraseñas almacenadas con un gestor la creación de algunas nuevas (y falsas) que harían perder el tiempo a un hipotético atacante.

Además, como el almacenamiento de contraseñas estaría cifrado, el gestor genera un fichero de contraseñas de aspecto razonable para cada posible clave de descifrado que un atacante pueda probar (por fuerza bruta) así que ralentizaríamos todavía más sus ataques.

Sobre inclusión más segura de contenidos con iframes

Enmarcado La utilización de frames es vieja en la red: permite incluir contenido de otros sitios en nuestra página y es un mecanismo que algunos servicios ofrecen como el habitual para este cometido.

Nowadays, old-school (Netscape style) frames have fallen out of fashion, but iframes are more popular than ever. They’re used for advertising, social plugins (e.g. Facebook “like” buttons and “Share on Twitter” functionality), webpage widgets, and so on.

En You’ve Been Framed! A survey of iframes and the sandbox attribute se comenta sobre estas técnicas y su prevalencia, así como el atributo sandbox, que permite controlar políticas de seguridad sobre contenido incrustado en nuestra web:

Just how popular are iframes? Not all websites have them but those that do tend to have quite a lot. To find out, I recently crawled the top ranking sites on the web and counted the iframes. Most iframes are dynamically generated by javascript, so you need to use a crawler which evaluates js. I wrote about the method I used in a follow-up post.

72% of the Alexa top 5000 sites have iframes on their landing pages. Of those, each has on average 7.1 iframes. Some sites have well over 50 frames.

Of all these 25,849 iframes on the top 5000 sites, only 10 use the HTML5 sandbox security attribute. That’s a whopping 0.04%! We’ll learn more about this attribute in a bit.

Examining the top 50 sites, there are a lot fewer iframes. But no one is using the aforementioned sandbox attribute. Of the top 1000, only two sites employ it.

Los riesgos son, esencialmente, que alguien saque partido de estar en nuestra página web al estar integrando contenido que está fuera de nuestro control:

However, external content is completely beyond your control. It can control the browser and the user experience to a degree. Unrestricted iframes can run javascript, Flash and other plugins, open pop-up windows, and even navigate from the containing page. If the site is just intended to display an ad or social button, does it really need to be able to do all (or even any) of these things?

En sitios de perfil alto esto no debería ser un problema (pero mejor no fiarse) pero nunca sabemos lo que puede pasar con otros sitios: esos botones tan chulos que proporcionaba alguien y que, en algún momento, no puede seguir con el servicio, abandona el dominio y es utilizado por otra persona.

En Play safely in sandboxed IFrames se habla un poco más del marco general (principios básicos de seguridad, mínimo privilegio y compartimentalización) y se explica la forma de incluir iframes de forma más segura:

The sandbox attribute of the iframe element gives us just what we need to tighten the restrictions on framed content. We can instruct the browser to load a specific frame’s content in a low-privilege environment, allowing only the subset of capabilities necessary to do whatever work needs doing.

Algunas técnicas contra el análisis de ejecutables

Pantalla En Jugando con técnicas anti-debugging José Manuel Fernández hace una panorámica de las ténicas anti depurado que utilizan los programas maliciosos para evitar que su detección y análisis.

En particular en esta entrada hablaba de la función IsDebuggerPresent.

En Jugando con técnicas anti-debugging (II) comenta sobre el campo NtGlobalFlag.

Finalmente, en Jugando con técnicas anti-debugging (III) se habla de las técnicas basadas en tiempo (un programa ejecutándose en condiciones normales no debería tardar más de … Si tarda más, a lo mejor alguien lo está ejecutando paso a paso, o haciendo algo ‘indebido’ con él). En este caso la función es GetTickCount().

Como bola extra, la lectura recomendada de [PDF] The ultimate Anti-debugging Reference y los programas utilizados como ejemplo en reverc0de/saw-anti-debugging. Muy interesante.

SSL para todos en CloudFare y la escala

Candados Uno de los problemas e utilizar SSL (TLS hoy en día) es el coste computaional: con muchas visitas las conexiones cifradas pueden ser un sobrecoste que no estemos dipuestos a asumir.

En Universal SSL: How It Scales Nick Sullivan de CloudFlare nos habla de su proyecto (ya tiene más de un año) de proporcionar HTTPS para todos los sitios albergados por ellos (que es una decisión a la que parece que se está dirigiendo mucha más gente cada vez) y hablan de este sobrecoste:

People have asked us, both in comments and in person, how our servers handle this extra load. The answer, in a nutshell, is this: we found that with the right hardware, software, and configuration, the cost of SSL on web servers can be reduced to almost nothing.

Alguno de los trucos está basado en cuestiones como retomar sesiones:

For returning visitors of a site we have a shortcut that eliminates the need for our servers to perform these expensive operations. The shortcut is called session resumption and it’s built into the TLS specification.

Otras medidas utilizadas son el Lazy Loading:

Lazy loading of certificates helps relieve that bottleneck. Using custom modifications to nginx by CloudFlare engineer Piotr Sikora, we are able to dynamically load certificates into memory only when they’re needed. Now, if one site changes their certificate, the server does not have to reload every certificate. This change allows our servers to scale up to handle millions of HTTPS sites.

Todo ello combinado con algoritmos modernos (Criptografía de curvas elípticas, ECDSA) y hardware actualizado:

All Intel CPUs based on the Westmere CPU microarchitecture (introduced in 2010) and later have specialized cryptographic instructions.

Desbordamientos de enteros recientes

Agua desbordando Me repito. Pero cuando salen fallos de seguridad relacionados con los temas típcos no podemos dejarlos pasar sin comentarlos. En este caso se trata de desbordamientos de enteros (lectura clásica recomendada: Basic Integer Overflog).

El primero se trata de un desbordamiento de enteros en `strncat’ Integer overflow in strncat.

I didn’t look into the details but it looks like strncat(s1, s2, n) misbehave when n is near SIZE_MAX, strlen(s2) >= 34 and s2 has specific offset.

Hay algunos comentarios interesantes en Integer overflow in glibc strncat donde no queda claro del todo si es fallo o característica, pero vale la pena leerlos, sobre todo si nos gusta o no sinteresa el lenguaje C.

Por otro lado, leíamos el otro día en Desbordamiento de entero en PuTTY y en PuTTY vulnerability vuln-ech-overflow sobre un desbordamiento de enteros en PuTTY. En este caso el atacante debería ser capaz de insertar una secuencia de escape sofisticada que afectaría a una variable que almacena el número de caracteres que hay que borrar en determinadas condiciones.

The vulnerability arises because PuTTY uses signed integer variables to hold the number of characters to be erased and doesn’t adequately check for overflow. This means that by passing a very large parameter to ECH, an attacker could cause check_boundary to inspect memory outside the terminal buffer.

Lecciones aprendidas desarrollando GitHub pages

Crecimiento GitHub Pages Recientemente se ha cumplido un año que estamos escribiendo en este sitio Cuata Etapa. Me viene bien recordarlo porque recientemente leíamos Eight lessons learned hacking on GitHub Pages for six months en el que nos cuentan algunos principios generales aprendidos desarrollando el servicio.

El primero de ellos (previo, más bien) es ser usuario de tu propio servicio para conocerlo bien, conocer sus virtudes, encontrar sus defectos…

Y luego la lista:

  • Test, test, and then test again

Desarrollo basado en pruebas, para estar seguros de que cuando se introducen cambios nada va a fallar.

  • Use public APIs, and when they don’t exist, build them

En la línea del principio ‘previo’ no utilizar componentes secretos o privados y si se detecta la necesidad de algo que no existe, ponerlo a disposición de los usuarios.

  • Let the user make the breaking change

Permitir a los usuarios que controlen los cambios importantes que pueden afectar a sus sitios.

  • In every communication, provide an out

Cuando se comunican los errores se informa al usuario no sólo del problema sino también de dónde tiene que mirar para solucionar el fallo.

  • Optimize for your ideal use case, not the most common

No hay que olvidar que el servicio es para dar a conocer los proyectos. Eso debería ser lo más fácil de hacer, independientemente de lo que la gente esté haciendo.

  • Successful efforts are cross-team efforts

Como tantos proyectos, no son cosa sólo de un equipo que se encarga de ellos, sino que, seguramente, hará falta hablar y trabajar con otros equipos.

  • Match user expectations, then exceed them

Que los usuarios tengan lo que esperaban del proyecto, pero mejor. No hay mucho que añadir aquí.

  • It makes business sense to support open source

Una parte de su producto está basado en Jekyll, que es software libre y que ha ganado su propio espacio como producto independiente, que siguen apoyando y en el que siguen participando.

Condiciones de carrera en algunos sitios famosos

Carrera Cuando explicamos las condiciones de carrera siempre nos quedamos con la duda de si es un tema que ya todo el mundo conoce y también si no sería mejor dedicar ese tiempo a explicar otras cosas. De pronto, una entrada como Race conditions on Facebook, DigitalOcean and others (fixed) nos demuestra que más vale no olvidarlos.

Las condiciones de carrera ocurren en sistemas concurrentes, cuando dos actores acceden a o modifican una determinada información y el tiempo y la forma de acceso son importantes, porque lo que haga uno de ellos afecta a lo que el otro debería poder hacer. Se puede ver una explicación en Practical Race Condition Vulnerabilities in Web Applications y también en Condición de Carrera

En la entrada se comenta sobre varios fallos de sitios de alto nivel (que, al final, es lo que hace que valga la pena comentarlos aquí). Son secuencias de pasos para fallos de Facebook (en este caso aumentar el número de revisiones de una página o crear varios nombres de usuario para una cuenta), DigitalOcean (añadir crédito a nuestra cuenta), y LastPass (con un fallo parecido al de DigitalOcean).

Errores al final

Montaña La mente humana es curiosa. Al principio de un proyecto tomamos algunas partes con entusiasmo, pero como el final está lejos estamos relajados, exploramos, jugamos, modificamos, probamos cosas… Cuando se acerca el final vamos yendo más a lo concreto, tratando de cumplir con los hitos y ajustándonos a lo que hay que hacer. Y cuando llega el momento del cierre es un ‘sálvese quien pueda’ y dejamos algunas partes pilldas con hilos, en espera de evoluciones posteriores y cosas que haremos (tal vez) cuando vengan tiempos mejores y el proyecto esté entregado. Por lo visto también, cuando llegamos al final y todo está yendo más o menos bien perdemos tensión, creemos que todo lo tenemos controlado y nos volvemos perezosos y bajamos la guardia, llegando a ser más descuidados y confiados.

En The Last Line Effect hablan de algo que está ligeramente relacionado, y por eso lo llaman el efecto de la última línea:

I have studied numbers of errors caused by using the Copy-Paste method and can assure you that programmers most often tend to make mistakes in the last fragment of a homogeneous code block.

En este caso el autor estudia el efecto asociado a copiar bloques de instrucciones y encontrar que la probabilidad de cometer un error en el último bloque de código copiado es cuatro veces mayor que en cualquier otro bloque:

The probability of making a mistake in the last pasted block of code is 4 times higher than in any other block.

La idea es que los programadores copian y pegan framgentos de código que hacen cosas parecidas, y luego los modifican:

When writing program code, programmers often have to write a series of similar constructs. Typing the same code several times is boring and inefficient. That’s why they use the Copy-Paste method: a code fragment is copied and pasted several times with further editing. Everyone knows what is bad about this method: you risk easily forgetting to change something in the pasted lines and thus giving birth to errors. Unfortunately, there is often no better alternative to be found.

En este caso el problema sería parecido al del final de proyecto al que aludíamos en la introducción: copio, pego, modifico, ya tengo el problema casi resuelto, y de pronto estoy menos atento, así que me olvido de finalizar la cosa.

Por lo visto, es algo que también les pasa a los montañeros que, por lo visto, también es más probable que tengan un accidente cuando están finalizando la ascensión.

Añadiendo filtros de correo a mi sistema con sievelib

Laberinto Otra tarea importante que necesitamos en el correo es el filtrado: tener en nuestra carpeta principal sólo los mensajes que pueden ser importantes y llevar a otras carpetas secundarias otros avisos, como mensajes de listas de correo y cosas así. A veces es bueno apartar algunos mensajes importantes que no podemos atender cuando estamos fuera de la oficina: cuando volvamos a lo mejor ya no los vemos como nuevos y no les dedicaremos la atención necesaria.

Como decíamos el otro día el sistema se basa en Zentyal, que incorpora un sistema de filtrado de correo (mediante el webmail y los filtros basados en el protocolo ManageSieve). El problema (para mi) es que no soy usuario habitual del correo web porque prefiero otros clientes y no me resultaba cómodo tener que lanzarlo para añadir un filtro, así que anduve investigando para averiguar si se podría utilizar alguna alternativa. Mi opción preferida es un programa de línea de instrucciones.

Encontré sievelib y estuve haciendo algunas pruebas. No estoy seguro de haber manejado adecuadamente la biblioteca: yo utilizo básicamente dos tipos de reglas, las de almacenar en alguna carpeta concreta, y las de redigir a otra cuenta de correo (por ejemplo ‘newsletters’ en html que se leen mejor en GMail -del que también soy usuario). Por este motivo, sólo me he concentrado en estas reglas y ni siquiera estoy seguro de haberlo hecho en toda su generalidad. El resultado está en addToSieve.py en el estado de la versión que se comenta aquí.

El servidor de correo almacena las reglas en ficheros y hace una pequeña gestión que le permite saber cuál de ellos está activo, así que hay que conectarse e identificarse y autentificarse. Habremos leído los datos de configuración de manera análoga a cómo hacíamos con el servidor IMAP como veíamos en Jugando con IMAP en Python y seleccionar el ‘script’ que queremos modificar y analizarlo:

from sievelib.managesieve import Client

...

        c = Client(SERVER)
        c.connect(USER,PASSWORD, starttls=True, authmech="PLAIN")

...

        script = c.getscript('sogo')
        p = Parser()
        p.parse(script)

Para crear la regla vamos a basarnos en el mensaje que queremos filtrar. Mostramos los 15 mensajes más recientes y el usuario elije uno de ellos:

def selectMessage(M):
	M.select()
	data=M.sort('ARRIVAL', 'UTF-8', 'ALL')
	if (data[0]=='OK'):
		j=0
		msg_data=[]
		messages=data[1][0].split(' ')
		for i in messages[-15:]:
			typ, msg_data_fetch = M.fetch(i, '(BODY.PEEK[HEADER.FIELDS (From Sender To Subject List-Id)])')
			for response_part in msg_data_fetch:
				if isinstance(response_part, tuple):
					msg = email.message_from_string(response_part[1])
					msg_data.append(msg)
					print "%2d) %4s %20s %40s" %(j,i,msg['From'][:20],msg['Subject'][:40])
					j=j+1
		msg_number = raw_input("Which message? ")
		return msg_data[int(msg_number)] #messages[-10+int(msg_number)-1]
	else:	
		return 0

Creo que no hay mucho que comentar en este código, simplemente ordenamos los mensajes por orden de llegada y mostramos algunos campos de los 15 últimos (utilizamos BODY.PEEK para que no se marquen como leídos los mensajes que no lo estuvieran). Para extraer las cabeceras relevantes se utiliza email.message_from_string. Si todo va bien, devolvemos el mensaje return msg_data[int(msg_number)].

Ahora que sabemos qué mensaje vamos a utilizar para el filtrado elegimos qué cabecera es la que utilizaremos para filtrar

	(keyword, textHeader) = selectHeaderAuto(M, msg)

Nos interesan las siguientes cabeceras (al menos por ahora, esto puede ir evolucionando):

msgHeaders=['List-Id', 'From', 'Sender','Subject','To', 'X-Original-To']

Además prefiero filtrar por List-Id siempre que sea posible, así que en selectHeaderAuto tenemos:

	
if msg.has_key('List-Id'): 
		return ('List-Id', msg['List-Id'][msg['List-Id'].find('<')+1:-1])

Notar que hemos ‘limpiado’ el contenido para eliminar todo lo que hay antes y después de los ángulos. En caso de que no tenga esta cabecera, mostramos las otras con este código, que tiene en cuenta que algunas de ellas pueden no estar presentes:

	
		for header in msgHeaders:
			if msg.has_key(header):
				print i," ) ", header, msg[header]
			i = i + 1
		header_num=raw_input("Select header: ")
		

Tomamos la cabecera y el texto correspondiente:

	
		header=msgHeaders[int(header_num)-1]
		textHeader=msg[msgHeaders[int(header_num)-1]]

Y ahora lo limpiamos (si es una dirección de correo contendrá ángulos, y si es un asunto ‘Subject’ a veces contiene corchetes, que también nos pueden venir bien para filtrar).

	
		pos = textHeader.find('<')
		if (pos>=0):
			textHeader=textHeader[pos+1:textHeader.find('>',pos+1)]
		else:
			pos = textHeader.find('[')
			textHeader=textHeader[pos+1:textHeader.find(']',pos+1)]

		pos = textHeader.find('<')
		if (pos>=0):
			textHeader=textHeader[pos+1:textHeader.find('>',pos+1)]
		else:
			pos = textHeader.find('[')
			textHeader=textHeader[pos+1:textHeader.find(']',pos+1)]
		return (header, textHeader)

Con estas cabeceras ahora tenemos que decidir la acción que realizaremos con los mensajes que coindidan con las cabeceras seleccionadas. De esto se ocupa la función selectAction. Esta función nos ofrece como acciones posibles las que ya tengamos en los filtros (carpetas que ya hemos utilizado, sievelib.commands.FileintoCommand, y redirecciones existentes, sievelib.commands.RedirectCommand), mostrando sus valores relevantes:

	
	i = 1
	for r in p.result:
		if r.children:
			if (type(r.children[0]) == sievelib.commands.FileintoCommand):
				print i, ") Folder   ", r.children[0]['mailbox']
			elif (type(r.children[0]) == sievelib.commands.RedirectCommand):
				print i, ") Redirect ", r.children[0]['address']
			else:
				print i, ") Not implented ", type(r.children[0])
		else:
			print  i, ") Not implented ", type(r)
	

Cada resultado es una regla, que tiene como ‘hijo’ la acción y la carpeta o la dirección donde se reenvía (en ambos casos puede haber varias acciones, como veremos luego). También indica las reglas que no han sido contempladas por el programa y que, por lo tanto no tenemos posibilidad de añadir (abriendo la puerta a futuras mejoras). Finalmente, se ofrecen las opciones de añadir carpetas o redirecciones nuevas:

	
	print i, ") New folder "
	print i+1, ") New redirection"

Si reutilizamos alguna acción, simplemente copiamos lo que ya teníamos, añdiendo las carpetas o las redirecciones que haya y terminando con el stop que hace que no se analicen más reglas:

	
		action=p.result[int(option)-1].children

		for i in action:
			print i.arguments
			if i.arguments.has_key('mailbox'):
				actions.append(("fileinto",i.arguments['mailbox']))
			elif i.arguments.has_key('address'):
				actions.append(("redirect",i.arguments['address']))
			else:	
				actions.append(("stop",))
	

En el caso de que queramos utilizar una carpeta diferente, solicitamos el nombrey comprobamos que la carpeta existe (podríamos querer una carpeta que no existe, pero casi nunca es el caso, así que no contemplamos esa opción; esto nos permitirá evitar errores al teclear). Para esto es necesario estar autentificado con el servidor IMAP:

	
		folder= raw_input("Name of the folder: ")
		print "Name ", folder
		if (doFolderExist(folder,M)[0]!='OK'):

La carpeta (sólo una) se añade así:

	
			actions.append(("fileinto", folder))
			actions.append(("stop",))

En el caso de redirecciones la verificación se hace mediante una pregunta explícita:

	
		redir= raw_input("Redirection to: ")
		print "Name ", redir
		itsOK= raw_input("It's ok? (y/n)")
		if (itsOK!='y'):

Y en caso de que la validemos, añadimos la acción correspondiente:

	
			actions.append(("redirect", redir))
			actions.append(("stop",))

Aunque hemos seleccionado una cabecera para filtrar y la hemos limpiado es posible que no queramos utilizar la cabecera completa (ejemplo típico: en lugar de una dirección de correo, un dominio o una parte del usuario de correo) así que ofrecemos al usuario la posibilidad de escribir lo que considere oportuno:

	print "Filter: (header) ", keyword,", (text) ", textHeader
	filterCond = raw_input("Text for selection (empty for all): ")

	if not filterCond:
		filterCond = textHeader

Ahora construimos la regla:

	conditions=[]
	conditions.append((keyword, ":contains", filterCond))

Y creamos un filtro con ella (lo ideal sería añadirla al correspondiente si ya existía pero eso será objeto de una entrada posterior, tal vez) y lo almacenamos en un fichero (seguro que esta parte podría evitarse, pero no tengo claro cómo hacerlo):

	fs = FiltersSet("test")
	fs.addfilter("",conditions,actions)
	fs.tosieve(open('/tmp/kkSieve','w'))

Lo abrimos para analizarlo igual que el original:

	p2=Parser()
	p2.parse(open('/tmp/kkSieve','r').read())
	lenP2 = len(p2.result)

Y añadimos las reglas a las que teníamos, para finalizar escribiéndolas en un fichero:

	p.result.append(p2.result[lenP2-1])	

	fSieve=open('/tmp/kkSieve','w')
	for r in p.result:
		r.tosieve(0,fSieve)
	fSieve.close()

Guardamos el fichero original para tener un histórico y también como copia de seguridad por si algo va mal:

	name = time.strftime("%Y-%m-%d-%H-%M-%S", time.gmtime())
	c.putscript(name+'sogo',script)

Finalmente, ponemos el nuevo fichero como fichero de reglas de nuestra criba (‘sieve’):

	fSieve=open('/tmp/kkSieve','r')
	if not c.putscript('sogo',fSieve.read()):
		print "fail!"

Planes para el futuro:

  • Agrupar reglas para que las que corresponden a las mismas acciones estén juntas.
  • Modificar este programa para que la adición de reglas se haga añadiéndolas en el lugar que les corresponda, en vez de al final.
  • Gestionar las copias de seguridad de los viejos filtros. Está bien tener algunas por si algo va mal, pero no vale la pena guardar toda la historia.
  • Añadir un modo completamente manual (para el que ya hay código, pero no está integrado)
  • Automatizar todavía más la extracción de reglas (por ejemplo, intentar ‘adivinar’ cuál es la acción que podríamos elegir (?).

¿Ideas? ¿Comentarios? Estaremos escuchando en @mbpfernand0 o en @fernand0.

El valor de tu clave

Robo de credenciales Un error frecuente de muchos usuarios es pensar que no son objetivo de ningún atante (¿a quién podría interesar mi cuenta?). Lo cierto es que es posible que no seamos nada interesantes pero aún así nuestras cuentas puedan ser utilizadas como vía de acceso a otros recursos o personas y por eso hay que mentalizarse y concienciar a los usuarios.

El dato viene de 21% of users think their passwords are of no value to criminals y nos recuerda que las contraseñas son el paso necesario para obtener nuestros datos, información privada e incluso nuestro dinero. Muchas veces toda esta información está disponible gracias a las alertas y avisos que llegan a nuestra cuenta de correo. Incluso aunque no seamos famosos, un atacante puede estar interesado en alguna de nuestras propiedades (virtuales o físicas). También puede utilizarnos como puente para acceder a otros.

En este sentido puede ser una buena lectura el artículo que puede descargarse en Handcrafted Fraud and Extortion: Manual Account Hijacking in the Wild donde nos cuentan el proceso de un atacante cuando consigue las credenciales de una cuenta: formas de ataque, explotación, …

El trabajo se hizo con datos de Google:

We observe an average of 9 incidents per million Google users per day.

y habla de cómo se roban credenciales, cómo se monetiza ese robo y también (aunque para este caso es menos interesante) lo que hacen en la empresa para devolver el control al usuario.

Las técnicas de robo son las que podemos imaginar:

This can occur in a multitude of ways: phishing a user’s credentials; installing malware on the victim’s machine to steal credentials; or guessing a victim’s password. Overall we find corroborating evidence throughout our measurements that phishing is likely to be the main way hijackers compromise user accounts.

Una vez obtenidas estas credenciales se pasa al prefilado del usuario: ver qué hay interesante en la cuenta.

The account profiling part where the hijacker decides on a concrete exploitation plan and the exploitation itself.
The existence of this profiling phase is one of the most surprising insights we gained by fighting manual hijackers. Instead of blindly exploiting every account, hijackers take on average 3 minutes to assess the value of the account before deciding to proceed.

El resultado puede ser que nuestra cuenta termine siendo considerada poco valiosa (y abandonada), que encuentren algún objetivo de interés, o que intenten exteorsionarnos (pidiéndonos un rescate).

El phishing normalmente llegaría a través de mensajes de correo electrónico.

Finalmente habla de una cierta profesionalización de estos ataques: los atacantes parecen tener sus horarios, protocolos de actuación e incluso utilizan herramientas comunes.

Jugando con IMAP en Python

Hilos Hace no mucho parecía que POP iba a ser el protocolo preferido para el correo. Sin embargo, con la movilidad permanente y la necesidad de consultar nuestro correo en cualquier parte parece que todo ha cambiado y las soluciones preferidas son los sistemas de correo basados en proveedores con sus aplicaciones (y típicamente su reflejo en webmail para el escritorio. Si nuestro proveedor no tiene aplicación, parece que la solución más adecuada es el IMAP. POP estaba orientado a la descarga, e IMAP estaba pensando para que el correo permaneciera en el servidor y se accediera a él mediante conexión.

A mi me gusta seguir viviendo la ficción de que una parte de mi correo es más o menos privada y eso pasa por usar los servidores del trabajo (o de un proveedor privado) con algunos inconvenientes: por un lado, malas herramientas de filtrado y gestión del correo; por otra parte, limitaciones en el espacio (todavía hay otra, y es la capacidad de buscar que pude solucionar -más o menos- con mairix).

Estas limitaciones me llevaron a montar un servidorcillo de correo (lo que viene llamándose en los últimos tiempos hacer un Hillary Clinton). Empecé montando los servicios por mi cuenta hasta que probé Zentyal que no es exactamente lo que necesito (tiene muchas más cosas y está pensada para algo más grande, pero me libera de algunas tareas de gestión). Miro con simpatía iniciativas como mailinabox o el fallido -por ahora- ownmailbox. Zentyal me proporciona un sistema con SOGo, Dovecot, filtrado (pronto, espero, otra entrada específica sobre el tema), antispam (no va demasiado bien, al menos en mi experiencia) y algunas herramientas más.

De todas formas, lo que quiero presentar hoy aquí puede ser de utilidad para cualquier cuenta de correo. Se trata de borrar algunos mensajes de una carpeta IMAP basado en reglas sencillas: en nuestro caso, recibimos mensajes de diversas tareas de cron que repetitivamente (sobre todo cuando todo va bien) llegan a nuestro correo. Lo que haremos será recorrer las carpetas donde se reciben las copias de seguridad y borrarlas.

La primera tarea es buscar un poco para ver si existe algún proyecto que nos ayude en la tarea de programación. Python incluye la imaplib que permite hacer las tareas necesarias. El proceso será:

  1. Leer la configuración de las cuentas que vamos a examinar
  2. Solicitar las contraseñas
  3. Seleccionar los mensajes y borrarlos

Además, para añadirle un poco de gracia a la cosa hemos añadido un uso muy básico de threading de manera que se hace el borrado de manera concurrente en las cuentas que haya configuradas. El código de la versión actual del programita se puede encontrar en deleteCronMesgs.py.

Comenzamos leyendo la configuración

config = ConfigParser.ConfigParser()
config.read([os.path.expanduser('~/IMAP.cfg')])

En este fichero está la información de las cuentas de correo, tantas como sea necesario:

[IMAP1]
server:imap.server.com
user:myAccount@server.com
[IMAP2]
server:imap.otherServer.com
user:myUsername

Ahora recorremos las cuentas configuradas y pedimos la contraseña (se podrían poner también en el fichero de configuración pero no termino de sentirme confortable con eso)

for section in config.sections():
	SERVER = config.get(section, 'server')
	USER   = config.get(section, 'user')

	print SERVER
	PASSWORD = getpass.getpass()

El código para borrar los mensajes se encuentra en la función mailFolder y para ello realiza los siguientes pasos:

Primero nos conectamos al servidor, con los datos leídos del fichero de configuración y del teclado.

	M = imaplib.IMAP4_SSL(SERVER)
	M.login(USER , password)

Seleccionamos la carpeta sobre la que vamos a trabajar (en este caso el INBOX) y en ella buscamos los mensajes que nos interesan (los que contienen la cadena ‘Cron Daemon’ en el campo ‘FROM’):

	M.select()
	typ,data = M.search(None,'FROM', 'Cron Daemon')

En search se devuelven dos valores, el estado (¿ha ido todo bien?) y una lista que contiene una cadena de caracteres con los números que identifican a los mensajes que cumplen las condiciones de búsqueda.

Ahora, para borrarlos recorremos la lista y actualizamos la marca (flag) para que refleje la condición de borrado:

	if data[0]: 
		for num in data[0].split():
			M.store(num, '+FLAGS', '\\Deleted')

Además hemos incluido código para ir contando cuántos mensajes borramos y mostrar una actualización cada diez (que no mostramos aquí). Finalmente, cerramos la conexión y terminamos:

	M.close()
	M.logout()

La parte concurrente es muy sencilla, consta de tres pasos.

Para cada cuenta de correo se crea un hilo:

	t = threading.Thread(target=mailFolder, args=(SERVER, USER, PASSWORD,space*i))

En target está la función que se ejecutará cuando se active el hilo y en args los parámetros de esa función.

Ahora acivamos los hilos (hemos separado la creación de la activación para que no haya interferencias de la salida que refleja la actividad con la entrada; podríamos prescindir de la realmientación y lanzarlas sobre la marcha):

for t in threads:
	t.start()

Finalmente, necesitamos esperar a que terminen los hilos, con un par de instrucciones como:

for t in threads:
	t.join()

Siguientes pasos: no tengo claro que el código de los hilos vaya a sobrevivir. Estuvo bien recordar un poquito (¡muy poquito!) de concurrencia pero en este caso no tiene demasiado interés. Tendría sentido poder incluir más reglas de borrado para otros mensajes e incluirlo en la configuración en lugar de en el propio código (por ejemplo, una lista de cademas para buscar o incluso algo más sofisticado).

También me gustaría explorar sistemas alternativos de autentificación (GMail permite utilizar OAuth, si no me equivoco). Como mínimo, poder tener la contraseña cifrada en el fichero de configuración y tener sólo una contraseña manestra.

¿Ideas? ¿Comentarios? Estaremos escuchando en @mbpfernand0 o en @fernand0.

Actualización (2015-12-07) quise terminar esta entrada rápido y olvidé otro ejemplo que tengo a mano. En este caso se trataría de borrar basado en el contenido. Recibimos ciertos mensajes repetidos que querríamos eliminar de nuestras coias de seguridad. Para examinar el contenido de los mensajes utilizaríamos:

	typ, data = M.fetch(num, '(BODY.PEEK[TEXT])')

Para determinar si el mensaje en cuestión es repetido, calculamos el hash (que tenemos precalculado) y lo comparamos:

	m = hashlib.md5()
	m.update(data[0][1])	
	if (binascii.hexlify(m.digest())==HASH):
		M.store(num, '+FLAGS', '\\Deleted')
		i = i + 1

Eliminar la aleatoriedad en un juego

Juegos

En Deterministic Doom hace la prueba de eliminar la aleatoriedad del conocido juego Doom. Para ello, primero observa que el juego no utiliza ninguna fuente de aleatoriedad externa, sino que incluye una tabla de valores de donde se toman los valores para diversas acciones en el juego:

Rather than consume system randomness, Doom has a fixed 256-value random number table from which numbers are pulled by aspects of the game logic

Por otra parte, los efectos son los que uno podría imaginar (y algunos otros): desde el comportamiento de los atacantes a diversos efectos de imagen, pasando por las armas que se utilizan.

Prueba con distintos valores, por ejemplo:

With 0x00, monsters never make their idle noises (breathing etc.) On the other hand, with 0xFF, they always do: so often, that each sample collides with the previous one, and you just get a sort-of monster drone. This is quite overwhelming with even a small pack of monsters.

Curioso.

Más fallos con una larga historia

Bicho

Es un tema recurrente hablar sobre el mito de los miles de ojos mirando. Ni en código abierto Bugs con una larga historia. El caso de LZO ni, por supuesto, en código propietario (supuestamente profesionalmente controlado).

Traemos esta vez un fallo con casi 20 años, 18-year-old bug can be exploited to steal credentials of Windows users en el que no entraremos en los detalles técnicos:

A new technique for exploiting an 18-year-old bug in Windows Server Message Block (SMB), which would allow attackers to intercept user credentials, had been uncovered by Cylance researcher Brian Wallace.

Pero que muestra que a veces los fallos son muy resistentes al paso del tiempo. Y algún día se descubren.

Para los interesandos, más detalles técnicos en SPEAR: Redirect to SMB.

Firmar el código que se ejecuta en el cliente o en el servidor

Firmas Desde hace tiempo tengo una idea un poco loca: en estos tiempos en los que tanto software se ejecuta directamente en un servidor y no tenemos ninguna forma de verificar lo que sucede sería interesante poder ‘certificar’ de alguna forma que el código que se ejecuta es el debido. Por ejemplo, si alguien está usando el servidor web Apache, tal vez debería ser posible en algunos casos poder verificar que efectivamente se ejecuta el código sin modificar, etc. Ya que no podemos auditar el programa que utilizamos, sería una forma de poder ver el código (que tal vez estaría disponible en algún repositorio) y estar seguros de que lo que se ejecuta es justamente lo que vemos.

Por eso me llamó la atención la propuesta/pregunta de Propuesta: ¿Un plugin para autorizar JS en cifrados online? donde se limita el problema a la ejecución de código en JavaScript:

En todos estos casos se emplea código javascript (JS) que se descarga y ejecuta en el navegador del usuario, de manera que el servidor nunca llega a conocer su pasword, desarrollándose todo el proceso de cifrado y descifrado siempre del lado del cliente.

El punto débil de este criptosistema ocurre cuando la web ve comprometida su seguridad y con ella la de su código JS, ya sea por la intervención de un programador deshonesto de la misma organización, ya sea por la intervención de terceros que pueden introducir fragmentos de código malicioso con objeto, por ejemplo, de abrir un socket durante el proceso de cifrado para capturar y enviar la clave del usuario a un determinado sitio.

No se si la propuesta ha avanzado en alguna dirección pero a lo mejor valía la pena probar.

Motivos por los que debería gustarnos Java

Libro: De Euclides a Java Nunca he sido un gran fan de Java. Tampoco he hecho programas de tamaño suficinte como para poder criticarlo o alabarlo con criterio, la verdad. El otro día leía una ‘queja’ que ahora no soy capaz de encontrar donde alguien decía que Oracle no le estaba prestando suficiente atención. Y también otra ¿Se ha convertido Java en un problema para el acceso a la administración electrónica? aunque en este caso no termino de tener clara la conclusión porque me resisto a creer que nadie haya sido capaz de superar el problema de los certificados utilizando algo que no sea el navegador y Java.

A pesar de todo lo dicho, me gustó leer una serie de diez entradas que se pueden leer a partir de 10 Reasons Why Java Now Rocks More Than Ever: Part 1 – The Java Compiler donde se van desgranando diversos motivos por los que debería gustarnos la plataforma.

Para perezosos y personas interesadas sólo en alguna de las partes (o como anzuelo para, a partir de ahí, leerlas todas), el índice:

  1. The Java Compiler
  2. The Core API
  3. Open-Source
  4. The Java Memory Model
  5. High-Performance JVM
  6. Bytecode
  7. Intelligent IDEs
  8. Profiling Tools
  9. Backwards Compatibility
  10. Maturity With Innovation

Lo de la compatibilidad hacia atrás me ha recordado una historia vieja de Joel Spolsky How Microsoft Lost the API War. Lo enlazámabos en su día en la bitácora de BarraPunto, que allí sigue: Joel, la API de Windows y el desarrollo web. Pocas veces nos acordamos cuando empezamos un proyecto nuevo que su vida debería larga y que eso tiene consecuencias cuando apostamos por tecnologías muy novedosas.

Actualización (2015-11-25): El amigo @vrruiz me señala Even If Oracle Is Losing Interest In Java, Should You Worry? como una posible fuente acerca de lo que comentaba arriba de la pérdida de interés en Java por parte de Oracle. Allí se enlaza a esta nota Insider: Oracle has lost interest in Java que creo que es la que yo vi en su momento. Quede aquí referenciada por completitud.

Las actualizaciones ... ¿como ventaja competitiva?

En la carretera Seguimos con el tema de las actualizaciones.

En la introducción de la parte de la asignatura de desarrollo seguro en la que participo, comentábamos el otro día (transparencias en [PDF] Algunos datos sobre desarrollo y seguridad de aplicaciones que no podemos esperar que los usuarios actualicen (y mucho menos que lo hagan rápidamente).

En los últimos años se ha conseguido que determinados grupos de usuarios estén pendientes, al menos, de las últimas versiones de sus sistemas e instalen las actualizaciones, pero todavía parece que no es lo habitual entre la generalidad de los usuarios (ejercicio: observar la reacción de cualquier usuario medio ante las alertas de actualización de su dispositivo móvil; leer los mensajes con ellos para ver qué interpretan y sus intenciones al respeto).

Si pasamos al internet de las cosas (internet of things, IoT) con dispositivos de lo más variopinto conectados la cosa se complica: las interfaces son más escuetas y los sistemas de actualización pueden ser algo más complicados.

Recientemente se descubrían fallos de seguridad que permitían atacar a algunos modelos de Jeep Cherokee. También otros fallos que permitirían realizar algo parecido a través del sistema de información y entretenimiento del Tesla Model S (lo cuentan en How the Jeep Hack Reveals Tesla’s Biggest Advantage.

En el caso de los primeros la firma se vio obligada a hacer una llamada a los propietarios de los vehículos y/o a enviarles un USB con la actualización:

But the big difference between these scenarios is what happened next. Fiat Chrysler had to recall 1.4 million Jeeps that could potentially be vulnerable to the hack, but the “recall” actually amounted to mailing Jeep owners a USB stick that they could plug into their vehicle’s dashboard port in order to give the car the necessary patch.

En el segundo caso, al tratarse de coches conectados y que reciben actualizaciones a través de internet (OTA, Over The Air) la actualización fue envíada por ese sistema y los coches actualizados (parece que tenían que aceptar, pero seguramente están en ese sector que actualiza y agradece las novedades; estaría bien poder conocer el porcentaje de los que dijo ‘no’):

Tesla, on the other hand, was able to automatically send a patch to all its Model S vehicles on Wednesday through an over-the-air update, a method more akin to how your smartphone gets software fixes.

En Researchers Hacked a Model S, But Tesla’s Already Released a Patch hablan de ventaja en seguridad (‘Tesla cars have one security advantage that a lot of other cars don’t’) y cuentan más detalles de los fallos.

En todo caso, parece una ventaja desde el punto de vista de la seguridad clara para Tesla, con la preocupación que siempre tendremos de que no sabemos qué ocurre realmente con esas actualizaciones ni qué incluyen.

Lo que no tengo tan claro es que alguien pueda terminar decidiéndose por un modelo u otro en función de esos factores; sí que puede ser un factor determinante para las marcas, que empiecen a darse cuenta del ahorro que puede suponer (¿con sus riesgos asociados?) instalar en los vehículos sistemas de actualización adecuados.

Esta entrada está basada en Las actualizaciones … ¿como ventaja competitiva?.

Actualizando. Espere

Actualización Como por efecto mágico, nuestro sistema siempre decide actualizarse cuando menos conviene. Es paradigmático y forma parte de casi cualquier acto que se organiza cuando esos PCs proporcionados por la organización empiezan a mandar avisos diversos, muchos de ellos de actualizaciones de programas.

En este caso no sabemos si es la típica excusa (‘mi perro se comió los deberes’, ‘falló el ordenador’) pero nos contaban en German pro basketball team relegated to lower division due to Windows update de un equipo de baloncesto que habría visto afectada su participacińo en la liga cuando el equipo que manejaba el marcador comenzó a actualizarse antes de empezar el partido y retrasó todo.

“But as both teams warmed up, the computer crashed,” he said. “When we booted it again at 7:20pm, it started automatically downloading updates. But we did not initiate anything.”

After all the updates were installed, Paderborn was ready to start the game at 7:55pm.

¿Quién no tiene alguna anécdota que contar relacionada con las actualizaciones?

Confíamos en que los equipos están allí dispuestos para atender nuestras necesidades sin proporcionales ni prestar atención a las suyas más básicas.

Al final, no es más que dedicar tiempo e incluir en nuestros procesos el mantenimiento para que no nos sucedan estas situaciones desagradables

Elogio de Python por el equipo de ingeniería de PayPal

Portada Libro Python Desde hace algún tiempo, cuando tengo que hacer un programita para resolver un problema de manera rápida mi lenguaje elegido es Python. También voy encontrándome mis limitaciones, esencialmente por no dedicarle atención suficiente a todo el entorno que ofrece para trabajar. De hecho, ya algunas entradas sobre Python en esta bitácora. Principalmente desarrollos que he ido haciendo pequeñitos que tal vez podrían servirle a alguien más alguna vez.

Por eso me gustó leer 10 Myths of Enterprise Python que es un elogio por parte del equipo de ingeniería de PayPal, tratando de aclarar algunas ideas erróneas sobre el lenguaje. Las listo:

  1. Python is a new language
  2. Python is not compiled
  3. Python is not secure
  4. Python is a scripting language
  5. Python is weakly-typed
  6. Python is slow
  7. Python does not scale
  8. Python lacks good concurrency support
  9. Python programmers are scarce
  10. Python is not for big projects

Vale la pena leerlas y echarles un vistazo para ver los argumentos.

Mi relación con Python se basa fundamentalmente en que es rápido para hacer pruebas (con la ventaja del intérprete para terminar de comprender cosas que no tienes muy controladas) y, a la vez, permitiría evolucionar a proyectos más grandes (que con scripts de shell no es trivial). También sus ‘batteries included’ con bibliotecas disponibles casi para cualquier cosa que podamos querer hacer.

Mis quejas con el lenguaje, que también las hay, tendrían que ver con su incómodo sistema de gestión de codificaciones (quién no se haya enfrentado nunca al problema que nos diga como lo hizo), y la transición a Python 3 que no termina de llegar del todo.

Entre mis carencias, la gestión y pruebas con distintas versiones del lenguaje y el lío que (creo que) tengo montado en mis sistemas con la instalación de bibliotecas de terceros de manera poco adecuada. Estoy empezando a explorar Virtual Environments y pyenv para ver si controlo estas cosas un poco mejor.

Demandas por fallos de software: los coches

Portada Geekonomics De ven en cuando se habla de la responsabilidad de los desarrolladores de programas informáticos. El otro día preparando una clase recuperaba y actualizaba un par de enlaces sobre el tema: Is It Time For Software Liability? y Should Software Companies Be Legally Liable For Security Breaches? al que añadiré este que comento aquí. También se publicó hace unos años el libro Geekonomics: The Real Cost of Insecure Software (es un extracto del primer capítulo) donde se hacía un análisis sobre el tema desde diversas perspectivas.

En Lawsuit seeks damages against automakers and their hackable cars hablan justamente del tema en la industria del automóvil basándose en que los fabricantes no han tomado las medidas necesarias para proteger los vehículos de los atacantes. Incluso un Senador de los EEUU respaldaría esa idea:

The lawsuit also cites a study released last month by Sen. Edward Markey (D-Mass.) that claims automakers have fallen far short in their responsibility to secure their vehicles’ electronics

El informe está en [PDF] Analysis of automobile manufacturers’ efforts reveals security and privacy gaps Tracking & Hacking: Security & Privacy Gaps Put American Drivers at Risk.

Eso sin hablar de las limitaciones informáticas de los coches modernos, en los que normalmente (y afortunadamente, si hacemos caso a los riesgos aparecidos) hay muy pocas de las posibilidades que nos ofrece un ordenador aprovechadasa adecuadamente:

“You can get into five-year-old luxury car and it…feels like a Nintendo game…compared to the experience on your smartphone,” Morrison said in an earlier interview with Computerworld.

Que también tiene que ver con lo rápido que se quedarían anticuados (¿imaginas una pantalla como la de tu teléfono móvil de hace 5 años para tener en el vehículo durante otros cinco años más?).

En Senate Bill Seeks Standards For Cars’ Defenses From Hackers nos cuentan los planes sobre cómo abrodar el problema. Sin embargo, parece que las propuestas irían más bien en la línea de buscar ‘standards’ y buenas prácticas que las propias leyes (que era algo que se comentaba también en Informe sobre ciberseguridad nacional en EEUU.

No se cómo andará la reclamación legal pero desde luego parece que hay un problema y ya han aparecido los primeros intentos de soluciones legales. Hemos hablado de coches en mbpfernand0 y coches en esta bitácora.

Al final, todo tiene mucho que ver con las consecuencias económicas que tendrían ciertas consecuencias drásticas: probablemente la informática costaría más (dinero y/o tiempo) y todo tendría que ir algo más despacio tomando, tal vez, menos riesgos. Pero seguramente este es un debate que vamos a seguir presenciando en los próximos tiempos.

Command and Control con GMail

Cuadro de mandos Una de las tareas que tienen los ‘malos’ para organizar sus ataques es la gestión de los equipos comprometidos. No hace tanto esto se hacía mediante canales de IRC, y la cosa ha ido evolucionando hacia redes sociales y otros sistemad de comunicacación (nuestro propio bot -no malicioso-, del que hemos hablado a veces no es más que un sistema de control de un computador remoto, mediante XMPP Segundo bot: avanzamos). Un ataque de este tipo sólo necesita que el programa malicioso pueda escuchar de alguna manera las instrucciones y pueda comunicarnos las respuestas.

En este caso podíamos leer hace algún tiempo ¿Gmail como server de C&C? OMG! – Parte I. Lamentablemente la parte II no se ha llegado a materializar aún donde se comenta sobre Pyexfil - Using Python to make Gmail a C&C server .

Se trata de un programa en Python que permite controlar un equipo infectado mediante el envío y recepción de mensajes de correo electrónico. El programa es capaz de leerlos, ejecutar las instrucciones y responder, si es necesario. Si conseguimos hacer que se ejecute en el equipo de vez en cuando tendremos un mecanismo para comunicarnos que además puede ser bastante sigilioso (¿cómo va a despertar la sospecha una consulta a un servidor de correo de amplia implantación?).

Curioso.

Informe sobre ciberseguridad nacional en EEUU

Portada del informe Seguimos con informes. Este es de julio del año pasado y se puede conseguir en varios formatos desde Surviving on a Diet of Poisoned Fruit: Reducing the National Security Risks of America’s Cyber Dependencies

… offers key insights about how to improve U.S. national security policymaking to address cyber insecurity. In the report, the author examines existing information technology security weaknesses and provides nine specific recommendations for the U.S. government and others to cope with these insecurities.

Los consejos:

  1. Suponer que los sistemas gubernamentales críticos tienen vulnerabilidades y compensar mediante una estrategia basada en: reducir las capacidades a lo esencial para minimizar las vulneratbilidades, añadir medidas no informáticas en los sistemas informáticos (evitaría la excesiva automatización), añadir diversidad (para que un fallo no afecte a todos los sistemas de manera global), e invertir en capacidades de descubrimiento y recuperación.
  2. Identificar sistemas no gubernamentales críticos y utilizar incentivos, estándares, información de ataques y autoridades regulatorias para mejorar la situación. Sin olvidar la difusión de información.
  3. Permitir las decisiones del sector privado sobre ciberseguridad para sistemas que no sean críticos o que sean suficientemente capacidad de recuperacion.
  4. Reconocer que las normas y regulaciones quedan obsoletas rápidamente, mejor utilizar incentivos y formación. Cuando sea necesaria la regulación, concentrarse en los objetivos antes que en las medidas.
  5. Buscar el desarrollo de normas y restricciones limitando el uso de ciber-armas para alcanzar efectos en el mundo físico.
  6. La ciberseguridad no es solo un problema técnico, es necesario invertir también en investigación socioeconómica, para comprender mejor el comportamiento de la industria y sus incentivos, así como el de los posibles atacantes. Evaluar sistemáticamente las respuestas de otros gobiernos ante los problemas de seguridad.
  7. Financiar un consorcio de recolección de datos para comprender mejor la magnitud del problema de ciberseguridad, siguiendo el modelo de incidentes en aviación. Desarrollar terminología y métricas.
  8. Invertir en investigación y desarrollo junto a la industria y otros países para hacer las arquitecturas informáticas más robustas.
  9. Evitar la falsa ilusión de que una agencia central de control o un ‘zar’ son alcanzables o deseables. Aumentar la capacidad reforzando las capacidades de la Casa Blanca con el objetivo de aportar fortaleza a la ciberseguridad civil que ha sido menos considerada por estar la mayor parte de la gestión orientada a los aspectos militares y de defensa.

Infecciones e internet

Gusano Ya hace tiempo hablábamos del tema en Borrar datos es difícil donde se cuentan algunos detalles sobre lo difícil que puede ser eliminar completamente cualquier rastro de datos de nuestros discos.

Ya hablamos hace tiempo del bloqueo de usuarios infectados por parte de sus proveedores de internet ¿Deberían los proveedores de acceso desconectar a los usuarios infectados?. La propuesta allí era ponerlos en cuarentena más allá de los avisos que algunos ya mandan: al final, el tráfico pasa a través de sus redes y tienen cierta capacidad de ver cuándo algunas cosas van mal: It’s time to quarantine infected computers

ISPs on an on-going basis should take advantage of the threat intelligence feeds of the security industry to identify compromised systems connected to their networks. Those systems should be moved to quarantine, the account owners should be contacted and directed to resources which will enable them to clean up and rectify the situation. Until such time as the infection is remediated the computer should be able to access only limited Internet resources. Don’t care will be made to care.

Esto tiene algunos problemas (inspección del tráfico, pérdida de productividad si nos desconectan…), en algunos casos no triviales.

También habíamos hablado del caso de Australia ¿Tienes malware? ¡Te desconectamos! y de algunas empresas Gusanos: las defensas de IBM y HP .

Recientemente hemos conocido alguien que da un paso más allá, New vigilante malware protects your computer from the bad guys. Se trata de un troyano llamado Linux.Wifatch que elimina algunas familias conocidas de ‘malware’ que habitualmente se pueden encontrar en routers caseros. Parece que el propio troyano está protegido contra posibles usos maliciosos:

As far as the researchers have found after months of investigation, however, Wifatch’s creator has yet to do anything malicious. In fact, using cryptographic signatures, the malware’s creator has even programmed the virus to guard against other hackers surreptitiously using the same network or backdoors.

Ya sabemos que mantener actualizados determinados dispositivos es difícil, porque los fabricantes y proveedores no nos dan demasiadas facilidades. Y también sabemos que es bastante frecuente encontrarse con casos de ataques como contábamos el otro día en Mala seguridad, routers y ataques pero como también podíamos leer sobre ataques lanzados utilizando cámaras de vigilancia Attackers hijack CCTV cameras and network-attached storage devices to launch DDoS attacks así que uno no sabe si tener miedo de estos ‘héroes’ que nos protegen o agradecer su trabajo para que las infecciones no se propaguen más.

Más sobre borrado seguro de datos

Discos Ya hace tiempo hablábamos del tema en Borrar datos es difícil donde se cuentan algunos detalles sobre lo difícil que puede ser eliminar completamente cualquier rastro de datos de nuestros discos.

En 48 Percent of Used Hard Drives Sold Online Contain Residual Data publicaban algunas estadísticas de recuperación de información en discos usados que se encuentran a la venta por ahí. Todo el mundo intenta alguna forma de borrado antes de desprenderse del disco, pero pocas son eficaces:

“One of the more glaring discoveries from our study is that most people attempt in some way or another to delete their data from electronic equipment. But while those deletion methods are common and seem reliable, they aren’t always effective at removing data permanently and they don’t comply with regulatory standards.”

Hacen referencia al estudio A study on data security in used mobile devices & hard drives.

Además, en ¿Seguro que lo has borrado? David García nos hace un breve resumen del tema y una presentación de algunas herramientas para borrado seguro.

Recuperación de contraseñas con preguntas personales

Intento de robo de credenciales

Tengo que reconocer que me encanta el tema de las contraseñas, gestión, almacenamiento, recuperación… También que se leen muchas cosas por ahí y que no siempre están respaldadas por información actualizada y obtenida por medios más o menos rigurosos. Por eso me he leído rápidamente un artículo de Joseph Bonneau, Elie Bursztein, Ilan Caron, Rob Jackson y Mike Williamson, Secrets, Lies, and Account Recovery: Lessons from the Use of Personal Knowledge Questions at Google donde se habla de algunos datos obtenidos en Google sobre la validez y gestión de los sistemas de recuperación de cuentas basados en preguntas secretas. Recordemos que el ‘folklore’ suele decir que una pregunta secreta sólo es una contraseña más débil.

Su análisis parece confirmar que la pregunta de seguridad rebaja el nivel de seguridad y esto sucede, curiosamente, porque los usuarios no son sinceros y tratan de inventarse las respuestas para hacerlas más seguras (lo que, en agregado, hace que sean peores). También muestran que es casi imposible conseguir preguntas cuyas respuestas sean fáciles de recordar y que a la vez sean seguras.

Abstract: We examine the first large real-world data set on personal knowledge question’s security and memorability from their deployment at Google. Our analysis confirms that secret questions generally offer a security level that is far lower than user-chosen passwords. It turns out to be even lower than proxies such as the real distribution of surnames in the population would indicate. Surprisingly, we found that a significant cause of this insecurity is that users often don’t answer truthfully. A user survey we conducted revealed that a significant fraction of users (37%) who admitted to providing fake answers did so in an attempt to make them “harder to guess” although on aggregate this behavior had the opposite effect as people “harden” their answers in a predictable way. On the usability side, we show that secret answers have surprisingly poor memorability despite the assumption that reliability motivates their continued deployment. From millions of account recovery attempts we observed a significant fraction of users (e.g 40\% of our English-speaking US users) were unable to recall their answers when needed. This is lower than the success rate of alternative recovery mechanisms such as SMS reset codes (over 80%). Comparing question strength and memorability reveals that the questions that are potentially the most secure (e.g what is your first phone number) are also the ones with the worst memorability. We conclude that it appears next to impossible to find secret questions that are both secure and memorable. Secret questions continue have some use when combined with other signals, but they should not be used alone and best practice should favor more reliable alternatives.

Hay muchos más hallazgos y vale la pena leer el artículo; por ejemplo, algo que no nos soprenderá: la respuesta a las preguntas secretas es peor conforme pasa el tiempo porque no la recordaremos.

Hace algún tiempo comentábamos en Las claves sobre los sistemas de recuperación y el entrevistado los defendía, si se seleccionaban adecuadamente las preguntas secretas. Por cierto, en la Forgot Password Cheat Sheet sigue incluyendo la parte de las preguntas aunque habla más bien de asegurarse de la identidad, lo que significa que el enfoque también ha cambiado un poco.

¿La apuesta de Google hoy en día? Recuperación a través del móvil (SMS) y el correo.

Aunque los malos ya se lo han aprendido (Si Google te envía un SMS para decirte que alguien ha accedido a tu cuenta… ¡Cuidado! y seguramente veamos dentro de poco más ataques sobre estos sistemas (sin olvidar que son muy poco fuera de banda, al estar muchas veces en el mismo dispositivo que las apps que intentan autentificarse).

Mala seguridad, routers y ataques

Antenas

Otra entrada sobre un ataque (esta vez a gran escala) por malas prácticas de seguridad. En Lax Security Opens the Door for Mass-Scale Abuse of SOHO Routers nos cuentan algunos erores de seguridad que llevaron a tener conectados a internet en casa de mucha genet routers con configuraciones inseguras. Gracias a eso, fue posible orquestar ataques distribuidos de denegación de servicio (DDOS) con una cierta incidencia.

Se trataba de routers SOHO cuya interfaz de configuración estaba accesible a internet sin problemas, y configurados con claves elegidas por defecto por el proveedor (amiguitos, cambiad la clave de vuestro router. ¡Ya!):

However, further inspection revealed that all units are remotely accessible via HTTP and SSH on their default ports. On top of that, nearly all are configured with vendor-provided default login credentials.

En este caso estas vulnerabilidades no se utilizaban para atacar a los propios usuarios (aunque seguramente en algunos casos también) sino para infectar los propios routers y lanzar los ataques desde allí. Naturalmente, esto también implicaba la idea de infectar nuevos routers que pudieran estar a su alcance.

Anatomía de un ataque

Intento de robo de credenciales

Una fuente habitual de los problemas de seguridad es la interacción insegura entre sistemas que pueden ser (más o menos) seguros. También puede ocurrir que no lo sean, claro. En Anatomy of a Hack nos contaban el caso de Partap Davis:

In the early morning hours of October 21st, 2014, Partap Davis lost $3,000. He had gone to sleep just after 2AM in his Albuquerque, New Mexico, home after a late night playing World of Tanks. While he slept, an attacker undid every online security protection he set up. By the time he woke up, most of his online life had been compromised: two email accounts, his phone, his Twitter, his two-factor authenticator, and most importantly, his bitcoin wallets.

Davis había seguido todos los consejos de seguridad habituales (claves fuertes, doble factor, ….). Pero a través de un fallo en su proveedor de correo (mail.com) el atacante va haciéndose con el control de otras cuentas del usuario hasta hacerse con su cuenta de Bitcoins (que supone coste económico, claro).

Me ha recordado otro que comentamos hace tiempo en Los riesgos de la nube donde se contaba otro ataque similar.

Cuando alguien va a por nosotros (o tenemos mala suerte y alguien nos dedica atención) tenemos pocas posibilidades.

¿Te puedes fiar del vendedor de tu ordenador?

Web

Si has estado atento a las noticias de informática en los últimos meses seguramente has oído/leído algo sobre Superfish. Con la intención de ofrecer productos similares a los que los usuarios supuestamente podrían estar interesados Lenovo introdujo una herramienta para interceptar el tráfico web (y, en particular, el tráfico cifrado).

Traigo aquí un resumen en A third-party, man-in-the-middle proxy used by Superfish is also used in other apps donde nos alertaban. No solo de lo mala que era la idea en sí sino también, claro, de las consecuencias laterales (y no previstas): que otras aplicaciones traten de sacar partido de este ‘truquillo’.

La explicación del modo de funcionamiento, un proxy que se colocaba entre nuestra conexión y los sitios que queríamos visitar:

Superfish uses a man-in-the-middle proxy component to interfere with encrypted HTTPS connections, undermining the trust between users and websites. It does this by installing its own root certificate in Windows and uses that certificate to re-sign SSL certificates presented by legitimate websites.

La utilización de un certificado común para todos los sistemas:

Security researchers found two major issues with this implementation. First, the software used the same root certificate on all systems and second, the private key corresponding to that certificate was embedded in the program and was easy to extract.

Y, finalmente, la utilización de componentes de terceras partes para toda esta maniobra, lo que haría posible su utilización por parte de otros programas

But it gets worse. It turns out Superfish relied on a third-party component for the HTTPS interception functionality: an SDK (software development kit) called the SSL Decoder/Digestor made by an Israeli company called Komodia.

Para eliminarlo hay instrucciones en Superfish, Komodia, PrivDog vulnerability test (updated again!) y también la propia Lenovo proporciona herramientas: SuperFish Uninstall Instructions.

A lo mejor lo más directo sería borrar el sistema e instalar uno limpio (con la ventaja de que, seguramente, quitaríamos otras cosas que no sean tan peligrosas, pero puedan ser molestas o poco convenientes).

Ya hemos hablado algunas veces de confianza por aquí y siempre conviene recordar el clásico Reflections on trusting trust y uno más reciente del que hablábamos en La confianza.

Algunos problemas de la biometría

Dedo

Recientemente hemos visto alguno de los problemas de la biometría: una vez que te roban, no puedes cambiar de huellas dactilares 5.6 million reasons fingerprints shouldn’t be used as passwords

Este verano se celebró el Black Hat USA 2015 y entre las presentaciones disponibles en la web acabo de ver una que habla de más problemas: [PDF]Hidden Risks of Biometric Identifiers and How to Avoid Them donde el autor hace una buena presentación del tema.

Según él, los riesgos son:

  • Confiabilidad de la biometría la percepción que tenemos de ella.
  • Falta de discusión sobre las consecuencias de los errores.
  • Irreversibilidad de los datos biométricos y sus implicaciones.
  • Nuestros datos biométricos pueden ser obtenidos sin nuestro consentimiento
  • Nuestro comportamiento puede delatarnos - a veces de manera incorrecta
  • Proporcionar nuestros datos biométricos y comportamentales puede llegar a ser obligatorio (al menos, de facto).
  • Ladrones de datos biométricos y agregadores

Hace algún tiempo comentamos las “Guías sobre biometría del INTECO” con algunos enlaces más.

Informe sobre la seguridad de datos en empresas

Patching

Hoy traemos un informe sobre seguridad de datos en las empresas, patrocinado por Oracle: [PDF] DBA-Security superhero lo que más me ha gustado (o llamado la atención) es una de las últimas gráficas. Concretamente la figura 32: en ella podemos ver que casi un 50% de los que respondieron a la encuesta actualizan los parches críticos dentro del ciclo o en el siguiente. Lo que nos deja con algo más del 50% que irían con un retraso de más de 9 meses y un nada despreciable 15% que no actualizan nunca o se encuentran en otra situación.

Ya hemos hablado de Las actualizaciones o en Los parches hay que aplicarlos.

Sobre GCC, LLVM, competencia, obsolescencia y avances

Obsolescencia

Hace mucho que no se habla demasiado de compiladores. Sin embargo, ya lleva entre nosotros una temporada The LLVM Compiler Infrastructure que es una plataforma para desarrollar un compilador reutilizable que, además, permitiría la construcción de compiladores no libres sobre su infraestructura (lo que lamentaba Richard Stallman en Re: clang vs free software.

En todo caso, para los amantes de la velocidad y la mejora la competencia es buena y, en ese sentido, es posible que merezca la pena darle una oportunidad para algunos proyectos.

En todo caso, traigo aquí Defending GCC considered futile donde Eric S. Raymond donde hace autocrítica sobre el GCC:

The reason has nothing to do with any philosophical issue but merely the fact that compiler technology has advanced significantly in ways that GCC is not well positioned to exploit.

En parte refuerza el argumento anterior, la competencia nos hace reconsiderar algunas posturas; por otra parte, iniciar un proyecto nuevo nos libera de decisiones pasadas.

Interesante, aunque no te intersen para nada los compiladores.

Aleatoriedad y juego en línea

Casino físico

Si alguien nos preguntase sobre si la aletoriedad es importante en seguridad, seguramente diríamos que sí. Si luego nos preguntaran cuánta atención habíamos dedicado a ella en nuestros proyectos tengo serias dudas sobre las respuestas. En este sitio se nos van acumulando ya las lecturas sobre el tema, pero siguen apareciendo nuevas. Y nos gusta referenciarlas.

Ahora es The Role of Randomness in Online Gambling. En este caso el artículo me ha gustado porque no incide tanto en la parte más teécnica como en los aspectos relacionados con el juego y los jugadores.

Sobre la percepción de la necesidad:

We intuitively recognize that, if the chance element of the game was not truly random—and if some players had knowledge of the non-randomness—then informed players would have an unfair advantage over uninformed players.

Sobre la forma de medirla:

Often randomness is asserted through the results of statistical analysis. Software like Dieharder will take a sample of output from a supposedly random source and identify statistically improbable outcomes. The result is confidence (not proof) that a given result set is random.Predictability has to do with whether or not the outcome of a random event can be known in advance (partially or completely).

No todo es aleatorio todo el rato:

Consider poker: there is exactly one random event in a game of poker. The deck is shuffled randomly. That’s it. The rest of the game is down to the actions of the players.

Últimamente hemos hablado de aleatoriedad en.

Números aleatorios seguros en Java

Generador de números aleatorios de Intel

Un informe sobre ciberseguridad en Europa

Mandos

El verano es para ponerse al día con las lecturas pendientes (que es algo que no he conseguido). En este caso, a título de inventario un informe: EU Cybersecurity Dashboard de la BSA - The Software Alliance. Interesante para comparar unos países con otros, ver las cosas que se están haciendo (y las que no).

El resumen para España:

Spain adopted the National Cyber Security Strategy in 2013. It is a comprehensive document, which sets objectives and targeted lines of actions. It is compatible with, and references, both the National Security Plan and existing security laws; and these plans and laws work together as a package.

Spain has established two CERTs, INTECO-CERT and CCN-CERT, and the National Centre for Critical Infrastructure Protection (CNPIC). The latter appears to be the premier agency for information security and cybersecurity, while the role of the CERTs is limited to dealing with cybersecurity incidents. CNPIC is responsible for ensuring coordination and cooperation between the public and private sector. It also runs sectoral working groups and is working toward the development of sector-specific cybersecurity plans.

Additionally, cooperation with the private sector is formalised through the National Advisory Council on Cybersecurity, established in 2009, whose members are private sector representatives. The council is tasked with providing policy advice to the government, although its current status is somewhat unclear. Private sector associations are also active, with two prominent bodies dedicated specifically to cybersecurity and information security, as opposed to general IT matters.

Sobre re-identificación de datos anónimos

Dinero

Un tema muy iterensante con el auge de la publicación de datos abiertos y el ‘big data’ (ya lo era, pero ahora es cada vez más real y cercano, en cierto modo) es la re-identificación de datos anonimizados. Podíamos leer en Researchers show how easy it is to de-anonymize shoppers.

En este caso Yves-Alexandre de Montjoye y su equipo analizaron 3 meses de registros de transacciones con tarjetas de crédito de 1.1 millones de personas y consiguieron identificar de manera única al 90% de ellos siempre que tuvieran cuatro ‘informaciones’ (pieces of information) acerca de sus movimientos en días determinados (lo que se publica en Facebook, Instagram, Twitter, …). Si está disponible el valor de una transacción la probabilidad de reidentificación aumenta (un 22% en media) y sería más fácil re-identificar a mujeres y gente de alto poder adquisitivo.

El estudio completo está accesible en Unique in the shopping mall: On the reidentifiability of credit card metadata.

Ya habíamos hablado de anonimización en Un borrador para un código de anonimización de datos, En internet cada vez es más difícil esconderse y en Sobre la desanonimización de la gente en internet, por ejemplo.

Un informe sobre seguridad del internet de las cosas

Antenas

Si has pasado el verano enterrado, oculto y no has escuchado las noticias sobre los ataques a coches conectados (demostraciones de la posibilidad, aún nadie está realizando los ataques, que sepamos) este informe debería ser tu lectura para estos días. En FTC Report on Internet of Things Urges Companies to Adopt Best Practices to Address Consumer Privacy and Security Risks se puede descargar un informe sobre la seguridad y la privacidad de la internet de las cosas y los análisis realizados por un grupo de expertos bajos los auspicios de la FTC (Federal Trade Commission).

Las conclusiones e ideas no resultarán novedosas para nadie que haya estado un poco atento, pero pueden servir para los despistados y como recopilatorio de lo que se sabe (con referencias a otras fuentes de información). Interesante.

El informe: Internet of things: Privacy & Security in a Connected World.

Ya habíamos hablado de Seguridad e Internet de las cosas y se pueden leer algunos casos concretos y más informes en etiqueta hogar del viejo blog.

Manejo de memoria en Gmail

Buzón

Aunque lo que necesitan los grandes proveedores está muchas veces fuera de nuestro alcance (y poco relacionado con nuestras propias necesidades) siempre vale la pena leer documentos como este Effectively Managing Memory at Gmail scale que nos habla de los problemas de gestión de memoria al usar JavaScript en Gmail. También el proceso de mejorar el navegador y el intérprete correspondiente para obtener mejores prestaciones.

Análisis de intentos de entrada a una instalación de Wordpress

Libro WordPress

Cada instalación tiene sus peculiaridades, pero siempre es interesante la recopilación de datos sobre intentos de ataques: sobre todo porque muchos son automatizados y tratan de explorar contraseñas comunes, debilidades frecuentes y esas cosas.

En Analysis of WordPress Login Attempts hay justamente eso, un análisis de 241082 intentos de acceso a una instalación de WordPress y un resumen de las claves utlizadas, sus tamaños, …

También hay un análisis temporal donde puede verse que hay dos intentos bastante ‘ruidosos’ pero el resto del tiempo parece tratarse de una actividad mantenida, contrarrestada por las medidas de seguridad habilitadas por el propietario.

Medidas anti-fraude molestas

Banco

Lo cuento a veces, cuando hay que explicar que hay que ser cuidadosos con las medidas anti-fraude: estás en una conexión que no es la tuya, tienes prisa y el Google (o Facebook, o tu banco) de turno te hace pasar por algún paso extra de verificación. Más nervioso te pones y todo va peor. O cuando por pereza vas retrasando compras por no ir a buscar la tarjeta que no la tienes a mano y se te acumulan unas cuantas: las haces todas de vez y en tu banco saltan las alarmas correspondientes y et paran las operaciones.

Justamente de esto último hablaba Paul Wallich en Don’t pay your bills all at once (recomendable el The Risks Digest.

The suspicious transactions: one small purchase from an online retailer we use often, and three $100-plus payments over the course of 30 minutes to what turned out to be the local cable company, electric company and a mobile phone provider.

Está claro que los sistemas anti-fraude tienen que mejorar, pero tenemos que ser conscientes como usuarios de su existencia y estar preparados para ser ‘frenados’ en cualquier momento.

Adjuntos MIME

Correo malicioso

Ya hablamos sobre como Enviar una imagen por correo en Python. Por eso me pareció interesante leer Adjunto MIMEtizado donde Sergio Brisa da un repaso a las consideraciones que hay que tener a la hora de abrir y analizar un mensaje de correo electrónico sospechoso.

Para ello nos da un repaso a cómo se envía un correo electrónico con adjuntos, la forma de verlo, decodificarlo…

Insertar fórmulas de libreoffice en un CSV

Calculadora

Supongamos que tenemos un montón de ficheros de texto que contienen datos que queremos procesar de una determinada manera con nuestra hoja de cálculo. El proceso de extracción de la información se puede hacer con más o menos facilidad utilizando un script sencillito (con sus grep, awk, …) y generamos algo que parece que tiene filas y columnas con datos.

Si los datos forman agrupaciones sobre las que querríamos hacer ciertos cálculos (por ejemplo, la media de un valor cada cierto número de filas) podríamos trabajar con el propio script, pero a veces necesitamos ‘masajear’ los datos para ver qué sucede.

Por eso estuve el otro día viendo cómo se podría hacer y lo comparto aquí. Primero, libreoffice permite insertar fórmulas en un CSV (comma separated values) siempre que la fórmula vaya entre comillas y al insertarla desde un fichero (importarla) no tengamos marcada la opción (‘Quoted field as text’).

Y luego insertamos la fórmula correspondiente en los lugares que nos parezca oportuno. Por ejemplo:

# Sum of the last 10 rows
sum='"=SUM(INDIRECT(ADDRESS(ROW()-10;COLUMN())&"":""&ADDRESS(ROW()-1;COLUMN())))"'
# Divide the last two columns
avg='"=INDIRECT(ADDRESS(ROW();COLUMN()-2))/INDIRECT(ADDRESS(ROW();COLUMN()-1))"'

En estas fórmulas:

  • [ROW()](https://help.libreoffice.org/Calc/Spreadsheet_Functions#ROW) es el número de la fila actual (puede llevar una referencia). Se le pueden sumar y restar valores, ROW()-10 hace referencia a la fila menos 10. COLUMN() es análogo.
  • [ADDRESS()](https://help.libreoffice.org/Calc/Spreadsheet_Functions#ADDRESS) se refiere al nombre de la celda como texto (y por eso se utiliza el & para concatenar y las comillas (dobles, para que no se interpreten como las comillas que finalizan la fórmula) para introducir texto…
  • [INDIRECT()](https://help.libreoffice.org/Calc/Spreadsheet_Functions#INDIRECT) es la referencia especificada por una cadena de texto.

Finalmente, con SUM hacemos la suma de esos valores. En las dos líneas de arriba vemos dos ejemplos (el primero podríamos usarlo para sumar los diez valores de una columna, y el segundo para hacer la división entre el número de valores -no tienen por qué ser válidos todos-).

¿Se podría hacer de otra manera? Claro, en lugar de los scripts (o con ellos, pero con algo más de trabajo) podríamos incluir las sumas y operaciones en el propio programita.

Otra alternativa sería utilizar sistemas orientados a la generación final del informe, como Documentos de Latex que incluyen código de R a los que tal vez algún día podamos dedicar algo de nuestro tiempo y paciencia.

¿Otras ideas?

Evaluación del generador de números seudo-aleatorios

Azar

Por algún motivo he estado leyendo unas cuantas cosas sobre generación de números aleatorios (la última vez en Aleatoriedad y seguridad) que no soy capaz de agrupar en menos entradas, así que vuelve a salir como tema recurrente.

En How do you know if an RNG is working? justamente hablan de ese tema(afortunadamente con un enfoque diferente): ¿podemos confiar en nuestro generador de números aleatorios? Siempre se habla de que hay que medir la entropía pero no es algo que sea fácil de realizar ni que todo el mundo esté dispuesto a hacer.

If you look at the literature on random number generators, you’ll find a lot of references to statistical randomness testing suites like Diehard or NIST’s SP 800-22. The gist of these systems is that they look a the output of an RNG and run tests to determine whether the output is, from a statistical perspective, “good enough” for government work (very literally, in the case of the NIST suite.)

Luego pasa a analizar las cosas que pueden ir mal (la propia inclusión de código para evaluar un generador podría introducir sus propios problemas, por ejemplo). ¿La conclusión?

Solving this problem, at least in software, so we can ensure that code is correct and does not contain hidden ‘easter eggs’, represents one of the more significant research challenges facing those of us who depend on secure cryptographic primitives. I do hope some enterprising graduate students will give these issues the attention they deserve.

Que sería otro aviso de: no tratéis de hacerlo solos y en casa. O algo así.

El viajante y su Tesla

Mapas

Una entrada muy chula en Traveling Salesman Problem donde se mezcla un problema clásico, el viajante de comercio (Traveling Salesman Problem) y algo de actualidad, como son los coches con batería, que hay que recargar.

El problema del viajante de comercio es un viejo conocido: dada una lista de ciudades y sus distancias encontrar el recorrido más corto que pase por todas ellas y vuelva a la de inicio TSP en Wikipedia. Es uno de los problemas conocidos como NP difíciles (o NP-duros).

La formulación de esta entrada habla de los puntos de recarga de las baterías del Tesla y ese hipotético recorrido entre ellas, con código, mapas y todo para poder jugar con él. Muy chulo.

Mejorando las prestaciones de la biblioteca matemática en glib

Laplace

En Improving math performance in glibc pudimos leer hace algún tiempo una entrada precisamente sobre eso: mejorar las prestaciones de la biblioteca matemática de glib.

Sobre la forma en que algunas funciones trabajan:

Transcendental functions in glibc are implemented as multiple phases. The first phases of computation use a lookup table of pre-computed values and a polynomial approximation, a combination of which gives an accurate result for a majority of inputs. If it is found that the lookup table may not give an accurate result the next, slower phase is employed. This phase uses a multiple precision representation to compute results to precisions of up to 768 bits before rounding the result to double. As expected, this kills performance; the slowest path for pow for example is a few thousand times slower than the table lookup phase.

Esto es, primero buscan algunos valores precalculados en una tabla y si no se tiene el restultado, se calculan de alguna forma.

Sobre la implementación de números grandes:

The multiple precision number is implemented in glibc as a structure with an integral exponent and an array of numbers for the mantissa.

The exponent e can be any integer value and the array d represents the mantissa. Each number in d is a non-negative integer less than 224. Only 32 of the 40 digits are used (the rest being there for additional precision for rounding), giving a maximum precision of 768 bits. The first question one may have is why the mantissa digits are double and not int if their values are going to be only integral.

Y luego ya se mete en detalles más próximos a las operaciones, por ejemplo con la multiplicación y su efecto en el cálculo de potencias:

As much as 97% of the time in computation of pow is spent in the multiplication function! So it is obvious that the first place to look at to get improvements is the multiplication routine.

Lectura interesante.

Aleatoriedad y seguridad

Azar

No es tan frecuente encontrar textos explicando cosas de las que nos gusta comentar aquí. Por eso me gustó leer Cómo se usa la aleatoriedad en la seguridad que es un tema del que hablamos de vez en cuando por aquí (etiqueta random.

Se muestran algunos ejemplos negativos, como el bug de Debian que me suena que habíamos comentado (pero no lo encuentro) y algunos más. También los sistemas de obtención de números aleatorios en sistemas Linux (/dev/random y /dev/urandom).

Por completar, hace tiempo hablábamos de Números aleatorios y seguridad.

Contraseñas y dispositivos móviles

Escribiendo

En Why passwords should not be stored on a mobile device unas cuantas razones para evitar esa práctica de almacenar contraseñas que se utilizan para conectarse a diversos servicios en nuestro dispositivo móvil.

This often raises the question how to store the username and the password on the device securely. The easy answer to this is: unfortunately not possible.

La solución pasaría por utilizar protocolos de autentificación modernos en los que el dispositivo no almacena una contraseña, sino un token que le identifica y que la concede permisos para determinadas actividades:

The question for an app developer now is: How can you make sure that the customers can use the app with all features without storing the password on the device? The solution: a token-based approach like OAuth 2.0 [4].

La clave está en la limitación para realizar sólo determinadas actividades (para otras se le pediría la contraseña en el momento) de forma que no está almacenada, no tiene que teclearla en cada ocasión que necesita hacer algo y el acceso a las partes más valiosas (pero menos frecuentemente utilizadas) sigue protegido con la contraseña.

Podemos recordar aquí que ya hemos hablado algunas veces de OAuth. En OAUTH y seguridad y allí enlazábamos a algunos programitas que lo utilizan.

Conferencia sobre 16 años de Hispasec

Libro Hispasec

Entre las lecturas que recomiendo para estar al tanto de las cosas que van sucediendo en temas de seguridad está el Una al día de Hispasec. Allí podemos esperar de todo: desde análisis del código de algún fallo de seguridad importante a los boletines mensuales de Microsoft, pasando por casi cualquier tema de seguridad. Acabo de mirar y el Una al día más antiguo que tengo es del año 2002.

Ya nos hicimos eco de la publicación del libro en el 11 años de Hispasec y ‘Libro Una al Día’ y ahora traemos un vídeo.

Dentro de las jornadas TEMAS AVANZADOS EN SEGURIDAD Y SOCIEDAD DE LA INFORMACIÓN TASSI Curso 2014 - 2015 ha habido una serie de conferencias interesantes. Como decía, recomiendo la de Antonio Ropero. Me hubiera encantado asistir pero uno tiene que balancear la vida familiar, el trabajo y las cosas que nos gustan…

Se trata de un repaso de su actividad durante estos años y de un buen recordatorio de como algunas cosas siguen repitiéndose y haciéndose mal y la pequeña historia de estos años en los que han sucedido tantas cosas.

Hola Lola. Construyendo un hexápodo sencillo

Araña

Ya hace algún tiempo que no hablábamos de nuestro proyecto de robot. Si no recuerdo mal, la última vez fue con lo de Una pata robótica, donde dábamos cuenta de nuestros avances con las patas del robot. Algo hemos avanzado desde entonces y esta entrada es para contar un poco de esos avances. En este momento tenemos una plataforma con seis patas que puede avanzar en línea (más o menos recta).

En esta entrada hablaremos principalmente de la parte física del hexápodo (construcción y componentes) y en una que publicaremos más adelante hablaremos de los programas. Permanezcan atentos a la etiqueta Lola.

Vamos por partes:

Para la plataforma elegí un panel que compré en una tienda de esas de todo a X que hay por el barrio (y que tanto juego están dando para este proyecto): el tamaño parecía adecuado, y el material se demostró ligero y fácil de trabajar.

Servos en la (proto)montura

A photo posted by Fernando Tricas García (@ftricas) on

Fue sencillo hacer los orificios para albergar los motores y comenzar a hacer las primeras pruebas:

Plataforma y patas #leg

A photo posted by Fernando Tricas García (@ftricas) on

Aún no tenía suficientes motores, así que tuve que conformarme con cuatro patas, que mostraban capacidad suficiente para levantar la plataforma (sin mucha alegría, la verdad):

Cuatro patas #raspi

A video posted by Fernando Tricas García (@ftricas) on

Otro problema que ya se anticipaba era el lío de cables, como puede verse en el vídeo y en esta foto:

Cables y polvo #raspi

A photo posted by Fernando Tricas García (@ftricas) on

Con cuatro patas hacen falta un cable de señal para cada motor (12 motores) más la alimentación para cada uno de ellos. Estas primeras pruebas nos hicieron pensar en un rediseño de las patas, cambiando la forma de unir los servos de la segunda y tercera articulación (la ¿rodilla?). Si los acoplamos de manera secuencial el resultado no es muy robusto (hay movimientos entre ellos que hacen que la posición de la pata no sea predecible del todo).

Para resolver el lío de cables estuve buscando información y encontré que existen controladores de servos que permiten centralizar las conexiones, tanto de señal como de alimentación y descargar al controlador principal de algunas tareas. Además permiten gestionar mejor la velocidad de los movimientos, y también dan la posibilidad de hacer que varios motores se muevan a la vez (esto no había mirado como hacerlo con la Raspberry -ni con Arduino-; puedo imaginar que sea cuestión de enviar las señales una detrás de otra, casi simultáneamente, pero no lo he comprobado). Los controladores más populares parecen ser los de Pololu (por ejemplo Mini Maestro 24-Channel USB Servo Controller (Assembled)) pero no encontré una forma fácil de conseguirlos aquí (para ser exacto, la gente de Cooking Hacks me dijeron que lo traerían pero con un puente enmedio la respuesta llegó cuando ya había encargado otra solución). El otro que encontré (y por el que me decidí) fue el Veyron Servo Driver que también tenía 24 canales y que estaba disponible a través de alguna tienda que hacía envíos aquí con un coste razonable. Hay que tener en cuenta que para las seis patas sería suficiente con tener 18 canales, pero puede ser una buena idea tener algunos libres por si queremos añadir más motores en algún momento.

Se puede conectar por el puerto USB y mediante comunicación serie enviarle las instrucciones. Por ejemplo:

#0 P1490 #3 P1490 #6 P1490 #9 P1490 #12 P1490 #15 P1490 T200

Esta instrucción indicaría al controlador que mueva los motores 0,3,6,9,12 y 15 a la posición 1490 (aproximadamente la mitad de su recorrido) en un tiempo de 200 milisegundos. Como puede verse, se trata de una sintáxis cómoda y sencilla para gestionar desde nuestros programas los motores. El controlador:

Controlador de servos y Alicia

A photo posted by Fernando Tricas García (@ftricas) on

Pueden verse los conectores para los servos (azul la señal, rojo polo positivo, negro tierra). Arriba en verde los conectores de alimentación, abajo el conector USB para recibir los datos (también puede servir de alimentador para el dispositivo; no para los motores). Además pueden añadirse expansiones para hacer conexiones inalámbricas y controlarlo remotamente. Y alguna cosilla más.

Aquí podemos verlo en acción:

Probando el controlador de servos

A video posted by Fernando Tricas García (@ftricas) on

También puede verse la nueva forma de unir los motores de la ‘rodilla’ a la que aludíamos arriba: los acoplamos por la parte más ancha, mediante una brida.

El segundo problema que había que resolver era la alimentación: el controlador tiene prevista una alimentación separada para los motores y para su propio funcionamiento. Se puede hacer mediante una batería (o más, claro) pero de momento nos hemos conformado con re-aprovechar una vieja fuente de alimentación de un PC siguiendo los consejos de un montón de páginas que explican cómo hacerlo. Las hay que dan instrucciones para hacer todos los pasos necesarios Fuente de alimentación casera con fuente ATX (1 de 2) y alimentación casera con fuente ATX (2 de 2) por unos cinco euros. Hace falta, eso sí, cortar cables, compara algunas componentes y hacer algunas soldaduras (y algo de trabajo y habilidad si queremos que quede más o menos ‘presentable’).

También descubrí que se venden adaptadores para conectar a una fuente de alimentacióna lo que simplifica mucho la parte de las conexiones sin tener que trabajar apenas. Justo en esos días Javier Loureiro anunció su placa ATX Board en plan casi crowdfunding: la encargábamos y en unas semanas la tendríamos en nuestras manos. Mi placa:

ATX Board #staticboards

A photo posted by Fernando Tricas García (@ftricas) on

Podemos utilizar el conector que se ve a la derecha, que es compatible con el que tienen las fuentes normales y corrientes, y tenemos disponbibles los bornes de conexión pequeños de la derecha (para 5V y menos) y los más grandes que se ven abajo (para 12v y también más intensindad). Puede verse un análisis en Probando una placa ATX Board de Staticboards así que no comentaré mucho más sobre esto.

Con todo esto hemos ido haciendo las pruebas de movimiento. Nuevamente nos hemos enfrentado con las leyes de la física: el robot se resbalaba. Primero añadimos unos tacos de madera a ver si daban mejor resultado que el plástico (que no fue el caso pero alargó un poco las patas). Posteriormente, y después de varias pruebas, tuvimos que ponerle unos ‘zapatos’ que consistían en unas gotas de silicona que parece que han mejorado el agarre, que en aquel momento no causaba muy buena impresión:

Como que ya quiere andar

A video posted by Fernando Tricas García (@ftricas) on

Sobre el movimiento, decir que me costó bastante dar con el truco: no lo explican demasiado bien en ningún sitio (o yo no lo entendía bien) y algún rato me tuve que pasar viendo vídeos de otros para captar la idea. Por si es de utilidad para alguien guardé una lista de reproducción de hexápodos en YouTube donde pueden verse varios proyectos interesantes.

Con un hexápodo el secreto es que en cada momento hay tres patas en el suelo formando un triángulo que lo sostiene y otras tres en el aire. Para que se produzca el movimiento las que están en el aire avanzan hacia su destino, y las que están en el suelo se mueven hacia atrás, lo que provoca el avance (siempre que el ‘bicho’ esté bien equilibrado y no haya resbalones). Se ve bastante bien (y otros movimientos) en el primer vídeo de la lista y en algunos otros.

También se pueden apreciar las posibilidades que nos dan diversas posiciones relativas de las articulaciones, aunque la que hemos elegido es bastante simple y simplifica la parte mecánica, sin necesidad de construir/obtener piezas más o menos sofisticadas.

En este vídeo:

Pueden verse los movimientos (todavía algo desgarbados) que conseguimos en aquel momento siguiendo estas ideas.

Esta entrada ya ha quedado un poco larga así que dejamos para una próxima la versión actual del movimiento y algo de los programas con los que estamos haciendo las pruebas.

Diez fallos de seguridad que harán que te despidan

Líneas

Traigo una lectura ligerita con una lista de cosas. Se trata de 10 security mistakes that will get you fired.

La lista es:

  • Interrumpir alguna actividad crítica para el negocio
  • Interrumpir el acceso del jefe a alguna cosa
  • Pasar por alto algún suceso importante de seguridad.
  • Leer información confidencial.
  • Invadir la privacidad de nuestros usuarios.
  • Utilizar datos reales en sistemas de prueba.
  • Utilizar una contraseña corporativa en un sitio externo.
  • Abrir algún hueco con permisos para que cualquier persona pueda acceder a todo (ANY ANY)
  • No cambiar las contraseñas
  • Tratar cualquier vulnerabilidad como si fuera la más importante.

Desbordamiento de enteros en YouTube

Psy

A veces tenemos coincidencias curiosas: acabo de encontrarme con un desbordamiento de un rango de índices para un vector en Pascal, de la mano de un par de estudiantes que no habían tenido las prevenciones adecuadas (con el compilador de Free Pascal: ponían (por ejemplo) vector[-1] y no saltaba ningún error, así que colocaba datos en otra parte del registro (estamos trabajando estructuras de datos ‘más’ complejas) y el programa funcionaba mal.

La coincidencia es que al ir a mirar qué poner hoy en este sitio me he encontrado con que hace algunos días guardé la historia del desbordamiento de enteros en YouTube, por gentileza de Psy y el número de visualizaciones que ha tenido su vídeo en esa plataforma: Gangnam Style overflows INT_MAX, forces YouTube to go 64-bit

The maximum value of this number type, 2,147,483,647, is well known to C programmers as INT_MAX. Once INT_MAX is reached, attempting to record another view will normally roll over to -2,147,483,648.

YouTube isn’t the only software that this number is a problem for. Unix systems record time values as the number of seconds since 00:00:00 UTC on January 1, 1970. 32-bit systems use a signed 32-bit integer for this, so they will wrap around 2,147,483,647 seconds after that date. Two billion seconds is about 68 years; on January 19, 2038, at 03:14:07 in the morning, 32-bit Unix clocks will roll over.

Son ese tipo de errores en los que se piensa: ¿cómo podría llegar a alcanzarse esta cantidad? Y un buen día se alcanza. El próximo límite, con sus 64 bits, tardará un poco más en ser un prolema (4 mil millones de años, si los cálculos del artículo son correctos).

También lo cuentan en We never thought a video would be watched in numbers greater than a 32-bit integer ….

Si alguien tiene ganas de ver el vídeo:

Gangnam Style

Las primeras contraseñas

Login

Un poco de historia nunca viene mal. En The World’s First Computer Password? It Was Useless Too hablan de los primeros ordenadores de tiempo compartido (ejecutaban los programas de varios usuarios, en lugar de un usuario cada vez, cuando le tocaba) y de la ‘necesidad’ de las primeras contraseñas:

It probably arrived at the Massachusetts Institute of Technology in the mid-1960s, when researchers at the university built a massive time-sharing computer called CTSS. The punchline is that even then, passwords didn’t protect users as well as they could have. Technology changes. But, then again, it doesn’t.

Aunque en realidad en aquella época la seguridad no era una gran preocupación:

The irony is that the MIT researchers who pioneered the passwords didn’t really care much about security.

El primer robo de contraseñas documentado:

In the spring of 1962, Scherr was looking for a way to bump up his usage time on CTSS. He had been allotted four hours per week, but it wasn’t nearly enough time to run the detailed performance simulations he’d designed for the new computer system. So he simply printed out all of the passwords stored on the system.

“There was a way to request files to be printed offline by submitting a punched card,” he remembered in a pamphlet written last year to commemorate the invention of the CTSS. “Late one Friday night, I submitted a request to print the password files and very early Saturday morning went to the file cabinet where printouts were placed and took the listing.”

Desarrollo seguro: las pistas de Adobe

Ordenadores

En The Simplest Form of Secure Coding un articulito introductorio en la bitácora de seguridad de Adobe sobre el tema de desarrollo seguro en las empresas.

Incide en el tema de que los consejos sobre desarrollo seguro suelen tener un solapamiento fuerte con los consejos sobre buenas técnicas de desarrollo (mejores prácticas y esas cosas).

As you can see, regardless of your coding language, security best practices tend to overlap with your developer best practices. Following them will either directly make your code more secure or make it easier to integrate security controls later. In meetings with management, developers and security people can be aligned in requesting adequate time to code properly.

Aunque no es lo único. Como sabemos, un programa puede ser técnicamente correcto y tener fallos de seguridad desde muchos puntos de vista.

Todo lo que necesitas saber de POODLE

Puerta cerrada

El año pasado estuvo bastante animado con fallos muy mediáticos (nombres propios, webs dedicadas, etc.). En Everything you need to know about the POODLE SSL bug Troy Hunt hacía un resumen bastante amplio del tema y que vale la pena conservar después de haberlo leído.

Sobre el nombre:

Enough with the crazy bug names, why Poodle?!

No, not Poodle, POODLE – the Padding Oracle On Downgraded Legacy Encryption. In the modern era of fancy bug names, the guys who names this must have been ecstatic when they realised that the acronym actually made a whole heap of sense! But really, that’s exactly what it is – a protocol downgrade support that then exploits a legacy encryption implementation. Nice one guys!

Naturalmente, también escribió Everything you need to know about the Shellshock Bash bug, que también es interesante.

Algunos detalles sobre simuladores de Fórmula 1

Coche de carreras

Ahora que acaba de empezar la temporada de Fórmula 1 puede ser un buen momento para recordar esta entrada del blog F1Metrics donde explicaban en Building a race simulator algunos parámetros de los simuladores que se utilizan para analizar (y preparar) la estrategia: orden en el uso de las ruedas, número de paradas. Para ello hay que analizar diversos parámetros y alimentar el programa con los datos adecuados para que los resultados tengan sentido.

Muy interesante, si te interesan los temas de simulación o las carreras.

Seguridad en proyectos ágiles

Linotipia

Desde hace algún tiempo tengo rondando por aquí un par de documentos sobre seguridad en proyectos ágiles pero nunca he tenido el tiempo necesario (ni tampoco es un tema que salga tan frecuentemente) para re-visitarlos y escribir aquí. Así que, por si le son de utilidad a alguien los dejo sin mucho comentario:

Además, habíamos hablado de temas relacionados en:

Al final, hay que acordarse de la seguridad independientemente del modelo de desarrollo seguido.

Construir sistemas seguros y compartir herramientas

Construyendo

Lo voy a decir desde el principio. La frase que más me gustó de este texto es:

“You go to the security conferences, and it’s all about breaking things,” Sullivan says. “It’s not about building things.”

Esencialmente coincide con mi forma de ver las cosas: ‘romper’ sistemas y encontrar fallos puede ser muy interesante y hasta ‘sexy’ pero no estoy seguro de que sea la forma en que la mayoría de nosotros deberíamos enfrentarnos a los temas de seguridad. Tenemos que aprender, creo, pautas para desarrollar sistemas (y programas) lo mejor posible, teniendo en cuenta la usabilidad, la gestión y todo el proceso que va alrededor de estos productos. Tiene sentido conocer las cosas que han ido mal y por qué se han roto, pero el enfoque debería ser hacia construirlas para evitar esos problemas.

El artículo es Facebook, Google, and the Rise of Open Source Security Software se habla de algunos responsables de seguridad de empresas como Facebook y Google que no sólo piensan lo de construir sistemas seguros. Pero no sólo eso, también comparten sus desarrollos para que otros puedan sacar partido de ello:

“The concept of releasing software—and the specific ways we go about making infrastructure more secure—hasn’t really caught on yet with the wider security community, but we’re getting there,” says Arpaia. “I think OSquery can be a good push in that direction.”

Borrado remoto de datos en relojes Pebble

Pebble

Mucho se está hablando últimamente de los relojes inteligentes, sobre todo con la puesta a la venta del Apple Watch. La inteligencia de esos aparatos viene de que son ordenadores y, como tales, pueden ser el objetivo de los atacantes y víctimas a través de diveras vulnerabilidades.

En Un atacante remoto puede borrar todos los datos del reloj Pebble nos contaban el caso de los relojes Pebble, uno de los primeros casos de éxito.

En este caso el problema parecía ser una denegación de servicio cuando se reciben demasiados mensajes (que podría ser una simple olestia) que se convierte en borrado de datos porque se produce una restauración del dispositivo a su estado inicial.

No es la primera vez que nos encontramos con fallos en los mensajes: SMS y fallos. Ahora en Windows Phone y Nuevos ataques con SMSs. Hay más. Pero yo me he acordado de uno bastante más viejo: Hackeando una red de telefonía con SMS’s. En este se exploraban los límites de los teléfonos de la época (mucho menos capaces que ahora, era el año 2005) y las propias redes.

En DoSing Pebble SmartWatch And Thus Deleting All Data Remotely se puede leer algún detalle más.

Publicar en Linkedin las entradas de este sitio usando Python

Seguimos tratando de difundir el contenido de este sitio en diferentes redes sociales. Me da la impresión de que Google no presta demasiada atención a estos blogs (tampoco estoy muy seguro de que nadie fuera a buscar esto, en cualquier caso) pero sí que creo que se les puede dar (algo de) visibilidad en diferentes redes sociales.

Ya hicimos el acercamiento a Twitter (Publicar en Twitter las entradas de este sitio usando Python) y Facebook (Publicar en Facebook las entradas de este sitio usando Python).

Enlaces en Página de Facebook

Suelo compartir en Linkedin (y en los otros sitios) entradas de mi bitácora de enlaces, Notas Rápidas. Normalmente se trata de información que voy viendo por ahí; muchas veces la pongo incluso antes de leerla. De vez en cuando, alguien comenta, re-comparte… Pensé que también tendría sentido publicar allí lo que voy poniendo en mis blogs.

LinkedIn utiliza Oauth para la autentificación. En la sección de desarrolladores explican estas cosas y en Share on Linkedin explican la parte de publicar allí. En Authenticating with OAuth 2.0 nos indican qué cosas hay que configurar: dar de alta la aplicación en nuestro espacio de trabajo, lo que generará las correspondientes “API Key” y “Secret Key” y también los tokens “OAuth 1.0a User Token” y “OAuth 1.0a User Secret” que podremos incluir en nuestro programa (esto es, por ahora no necesitamos utilizar los tokens de la versión 2 de OAuth). También podríamos pasar por el proceso de autorización con el programita (que es algo que no he hecho) o bien utilizar las herramientas que nos proporcionan otros.

Una búsqueda rápida de algún módulo para interactuar con LinkedIn en Python nos conduce a python-linkedin.

Con este módulo todo se parece a los programas que hemos hecho en otras ocasiones (y me saltaré los detalles aquí). Se puede ver el código en su versión actual en rssToLinkedin.py.

  • Se leen los blogs que estén configurados (igual que otras veces) y se selecciona uno para publicar.
  • Se obtiene el título, el contenido y el enlace de la última entrada.

Una nota para el contenido: LinkedIn tiene límites sobre lo que se puede poner (actualmente 700 caracteres), así que hay que tener cuidado. Reservamos 7 caracteres para indicar que el texto sólo es un resumen.

print theSummary.encode('utf-8')[0:693].rsplit(' ', 1)[0]+" [...]"
  • Luego se busca una imagen y se incluye si la hay.

A partir de aquí comienza el proceso de autentificación:

authentication = linkedin.LinkedInDeveloperAuthentication(
			config.get("Linkedin", "CONSUMER_KEY"),
			config.get("Linkedin", "CONSUMER_SECRET"),
			config.get("Linkedin", "USER_TOKEN"),
			config.get("Linkedin", "USER_SECRET"),
			config.get("Linkedin", "RETURN_URL"),
			linkedin.PERMISSIONS.enums.values())

Seguidamente ponemos un texto (en mi caso ‘Publicado’) a modo de introducción y luego publicaremos el resto:

comment='Publicado!'

application.submit_share(comment, theTitle, theSummary, theLink, imageLink)

Con el trabajo desarrollado para los programas anteriores lo que hay que hacer aquí es simplemente utilizar el método adecuados para publicar.

Siguientes pasos: tengo tres programas para publicar en diferentes redes sociales y me pregunto si debería unificarlos para utilizar las partes comunes (esencialmente selección del blog porque el resto tiene pequeñas diferencias), o pensar en una mejor organización.

Pero esto será algo para pensar más adelante.

Algunos artículos sobre pruebas

Bugs Suelo echarle un vistazo a la revista CrossTalk. Como ya comentábamos hace algún tiempo en Desarrollo ágil y algunos problemas que aparecen a veces se ttrta de una revista sobre ingeniería del software militar), donde tratan temas actuales con un punto de vista de gestión. Suelen ser articulitos cortos que se leen fácil y aportan puntos de vista interesantes a veces.

En el último número hablan sobre Test and Diagnostics y a mi me han interesado especialmente:

Hemos hablado bastante de fuzzing (ver (tag fuzzing)[https://mbpfernand0.wordpress.com/tag/fuzzing/] en el blog antiguo) y Coches y ataques en este mismo blog.

Bugs con una larga historia. El caso de LZO

Bugs En Raising Lazarus - The 20 Year Old Bug that Went to Mars otra historia de esas que nos recuerda que hacer software seguro (o bien) es difícil. En este caso es una fallo sutil que ha escapado durante años a las revisiones que se hayan podido hacer (si es que se hicieron, que es otro de los temas que aparecen de vez en cuando relacionadas con el desarrollo de programas).

En esta ocasión se trata de diversos desbordamientos de enteros a la hora de ir almacenando valores y contabilizando el espacio que ocupan.

En este caso, además, se añade el interés de que hay varias implementacionesd el algoritmo LZO (Lempel-Ziv-Oberhumer) que comparten algunas partes de su código.

Ya habíamos hablado de El mito de los miles de ojos y más fallos con historial largo: Un fallo de 17 años, Alguien puso un troyano en mi servidor de IRC y Diaspora: lecciones de seguridad.

OAUTH y seguridad

Identificación Últimamente es raro el sitio que no permite identificarse con nuestra cuenta de Google, Facebook, Twitter u otras. La ventaja para el desarrollador está clara: desde un punto de vista de usuarios que re-utilizan contraseñas y que no son muy fiables a la hora de gestionar correctamente sus credenciales, delegamos ese trabajo en empresas más pontentes y que seguramente lo harán mejor que nosotros. Aunque puede que no sea una ventaja completa porque queramos tener un sistema de acceso para todas aquellas personas que no quieran utilizar este tipo de mezclas. Desde el punto de vista del usuario también está clara la ventaja: no tenemos que andar dándonos de alta en montones de sitios, con contraseñas (idealmente) diferentes y cofiando en administradores de plataformas que apenas conocemos.

Del tema de delegar la gestión de cuentas en otros se hablaba en Introducing the “Secure Account Management Fundamentals” course on Pluralsight que enlazamos en su momento desde Fundamentos de gestión de cuentas.

Para estas cosas se utiliza, entre otros OAuth que es un protocolo bastante completo y que permite cosas más sofisticadas. Nosotros lo hemos visto de pasada cuando hemos hablado de Publicar en Facebook las entradas de este sitio usando Python, Publicar en Twitter las entradas de este sitio usando Python, porque estos sitios no permiten que utilicemos la contraseña directamente, sino que prefieren que nos identifiquemos a través de OAuth.

Esencialmente se basa en que nos autentificamos una vez en el sitio proveedor (o más, si fuera necesario en el tiempo) y este nos proporciona unos tokens de acceso que permiten realizar ciertas operaciones en el propio sitio o, simplemenete nos reconoce como usuarios y eso le basta al sitio de origen como identificación.

El historial de seguridad de este protocolo ha tenido sus incidentes y por eso me gustó encontrar OAuth Security Cheatsheet que nos da las ideas principales sobre el flujo de datos y las precacuciones que debemos tomar a la hora de implementarlo/utilizarlo.

Los nombres y las cosas

Cerrado Una fuente frecuente de problemas de seguridad son los nombres: cuando esperamos que algo se llame de una determinada forma y también se puede referenciar con nombres alternativos (que no tuvimos en cuenta) es posible que se produzcan problemas: eso incluye la utilización de paths, diversas codificaciones, …

En la propia historia dicen que es un rumor (o algo que se dice) pero sirve como un ejemplo de lo que podría haber pasado (sin saber si es cierto o no): Windows 9 Reportedly Skipped as Name Would Have Created Code Bugs: la idea sería que en algunos casos se habrían utilizado búsquedas del nombre para identificar el sistema Operativo del estilo de ‘if(version,startswith(“windows 9”) que inevitablemente producirían confusiones en el caso de que se hubiera lanzado un hipotético Windows 9.

Sea cierta o no, una buena historia para un sábado. Y un recordatorio para los casos en que, efectivamente, los nombres han sido un problema.

Seguridad y principio del mínimo privilegio

Cerrado El principio del mínimo privilegio consiste esencialmente en conceder a las aplicaciones y usuarios los permisos necesarios para realizar las acciones que tengan que llevar a cabo, pero no más. Esto durante el tiempo necesario.

En Improving security through least-privilege practices hablan del tema introduciendo las ideas generales y la motivación.

Me quedo con esta frase:

A tip I often give my clients is to not see accounts as privilege but see privilege as accounts. What I mean by this is an account that is used for backup administration, or an account that is used to create users on a domain should be used as such and not for anything else. If your user’s accounts have these privileges then you have lost control of your network, data and systems and any malicious user or application will eventually exploit this vulnerability.

Aprender programación en 2014

Seguridad y cultura En Teaching Code in 2014 algo que ya llevamos tiempo diciendo: se sigue enseñando a programar (no a nivel básico, sino incluso después) sin tener en cuenta la seguridad.

Los consejos que da tienen que ver con:

  • No hay excusa para utilizar ejemplos inseguros
  • La seguridad debería estar integrada, no añadida
  • Usando Node.js también hay que tener en cuenta la seguridad
  • Hay que cambiar la forma de enfrentarse a este problema

En definitiva, hay que enseñar buenas prácticas, incluir ejemplos no sólo correctos desde el punto de vista de la funcionalidad sino también pensando en la seguridad.

Consejos sobre claves

Barrera Aunque de vez en cuando se anuncia la sustitución de las contraseñas con diversas tecnologías, lo cierto es que parece que vamos a convivir con ellas durante una buena temporada. En Passwords: Real-world issues, tips and alternatives se entrevista a Per Thorsheim y hablan sobre el tema. Se habla de las contraseñas, algunas alternativas, mejorar la facilidad de uso. Thorsheim es el organizador de la PasswordsCon, un encuentro centrado en estas cuestiones.

Da la casualidad de que tengo por una de las pestañas de mi navegador el resumen sobre gestores de contraseñas que hacían recientemente en Lifehacker Faceoff: The Best Password Managers, Compared. Hace un poco más leíamos Top password managers compared.

También podíamos leer el otro día un texto generalista y orientado a audiencias más amplias, con consejos que incluso algunos que deberían saber mejor estas cosas olvidan a veces Web Security for the Tech-Impaired: Passwords that Pass the Test:

  • Utilizar claves diferentes para sitios diferentes
  • Tu clave no debería tener menos de 12 caracteres
  • Utilizar una mezcla de minúsculas, mayúsculas, números y caracteres especiales
  • No utilizar secuencias predecibles a la hora de organizar estas mezclas.

Ya hemos hablado más veces de contraseñas por aquí, por ejemplo en Algunos enlaces interesantes sobre claves y allí había más enlaces.

Seguridad e Internet de las cosas

Cosas conectadas En 6 Tips for Developing Secure IoT Apps un nuevo recordatorio: los aparatos conectados a la red programables son peligrosos, sobre todo si no se tiene en cuenta que la conectividad cambia el contexto y aparecen nuevos riesgos.

Los consejos: contratar desarrolladores con conocimientos adecuados, utilizar plataformas probadas, comprobar las actualizaciones del firmware de los dispositivos, asegurarse de que los datos están seguros frente a ataques físicos y utilizar componentes de hardware seguros.

Se hace referencia a un estudio de HP: [PDF] Internet of Things Research Study y seleccionamos algunos comentarios.

Hay muchos dispositivos que fallan:

It found that every one of 10 popular Internet-connected security systems – which include video cameras and motion detectors – had significant security vulnerabilities which would allow hackers to access the devices and control them remotely.

Sobre esto, suelo emplear una referencia relativa a dispositivos WiFi y Bluetooth, [PDF] CODENOMICON WHITE PAPER. Wireless Security: Past , Present and Future para hacer notar que los fallos de seguridad no sólo aparecen en los programas, sino también en dispositivos. La cantidad de evidencias y casos sigue aumentando.

Las vulnerabilidades y los fallos no son nuevos:

They are well understood, and most of the specific vulnerabilities could probably be easily avoided by following best practices and recommendations for secure coding. The problem, according to Miessler, is that many IoT developers simply don’t follow them.

Las aplicaciones inseguras vienen de los propios fabricantes:

It’s noticeable that many of the insecure IoT applications (such as some of those in HP’s study) come from IoT hardware device vendors who offer software to work with their products.

Ya hemos hablado en el pasado de seguridad y aparatos ‘domésticos’. La internet de las cosas es un nuevo episodio:

Seguridad ‘hogareña’ Coches e informática Y unas cuantas más, por ejemplo relacionadas con coches, hogar . Hace nada volvíamos a hablar de coches en: Desbordamientos de memoria y Toyota y en Coches y ataques

También recientemente conocíamos la noticia de cómo hacía falta actualizar un montón de coches BMW actualiza el software de más de 2 millones de automóviles por una vulnerabilidad o el también reciente de las ‘televisiones espía’: It’s not just smart TVs. Your home is full of gadgets that spy on you: How internet giants are collecting your personal data through their high-tech devices y alguno más que van ocurriendo cada día.

Heartbleed, código y memoria

Rojo Uno de los sucesos más llamativos de seguridad del año pasado fue Heartbleed un fallo en la implementación de OpenSSL que permitiría a un atacante obtener información en conexiones cifradas (desde claves a contenidos).

Aunque en Answering the Critical Question: Can You Get Private SSL Keys Using Heartbleed? tratan de resolver esta pregunta y el mensaje es tranquilizador, lo más interesante es el análisis del código responsable del problema, los detalles de la pila y ese tipo de análisis más técnicos que nos gusta referenciar por aquí.

Mitos sobre /dev/urandom y más sobre aleatoriedad y su medida

Dados No se si el año pasado fue el de la aleatoriedad, o que por casualidad yo encontré más lectura sobre el tema. O, a lo mejor, simplemente estaba prestando más atención.

En Myths about /dev/urandom una buena lectura sobre el tema, donde se habla de /dev/urandom, sus parecidos y diferencias con /dev/random y, al final, algunas discusiones sobre “aletaoriedad verdadera”.

I don’t want to dive into that issue too deep, because it quickly gets philosophical. Discussions have been known to unravel fast, because everyone can wax about their favorite model of randomness, without paying attention to anyone else. Or even making himself understood.

Lectura recomendable.

Podemos recomendar también la lectura de How do you know if an RNG is working? donde se aborda justamente ese tema: mucho se habla de números aleatorios y generadores. Pero cuando se piensa en la calidad de lo que se obtiene se dice que hay que medirla y poco más. Aquí da ideas, algún recordatorio interesante y, en definitiva, nos recuerda que el diablo está en (todos) los detalles.

Más sobre aleatoriedad y generadores

Desbordamientos de memoria y Toyota

Coches y carretera Interesante documento en Are We Shooting Ourselves in the Foot with Stack Overflow? donde se hace un resumen de los problemas con los aceleradores de algunos modelos de Toyota. El fallo se atribuye a un desbordamiento de memoria (concretamente en la pila) y cómo esto podía producir que determinadas variables (del sistema) se vieran alteradas, con consecuencias.

De hecho, parece ser uno de los peores casos de corrupción de variables por desbordamiento de memoria, porque en lugar de manifestarse inmediatamente (en este caso, probablemente a baja velocidad todavía) aparecía algo más tarde con las consecuencias ya conocidas.

Luego propone algunas medidas que podrían mejorar la situacion, tanto desde el punto de vista de la gestión de memoria como del sistema operativo y las pruebas (tests).

En The Toyota Owners Left Holding the Bag podemos leer una descripción que simplemente habla de ‘código espagueti’, algunas consecuencias legales, los seguros…

Actualización (2015-03-01) Nos enlazó Juanjo Navarro fernand0 @ GitHub.io y recursividad y lo agradecemos aquí. Casi seguro que volveremos sobre este enlace acerca de nuestros sesgos y enfoques. Y también que hablaremos alguna vez de lo que Juanjo hable en su sitio. ¡Gracias!

Mantener una web estática con Git

Tela de araña Mantengo una página web con las cosas del trabajo desde hace bastante tiempo (la primera versión que hay en archive.org tiene una página que pone 1996, pero la verdad es que no recuerdo la fecha exacta, podría ser un poco antes). Se puede ver en Fernando Tricas WWW Homepage. Entonces no había sistemas de gestión de contenidos ni nada parecido y la manera en que hacíamos las páginas era copiando alguna que nos gustaba y poniendo nuestro contenido.

En algún momento empecé a gestionarla de la siguiente manera: mantenía una copia local donde editaba; cuando estaba satisfecho (o quería ver los cambios) copiaba los ficheros cambiados al servidor (con un programita que busca los ficheros que han sufrido cambios desde la última versión y scp). El objetivo era doble: evitar editar en el servidor, y tener una copia de seguridad local (que se sumaría a la que nos hacen en el servidor). En su momento (allá por el 2004) integré un blog con la página (esencialmente publico en la página los titulares de mi blog docente -por cierto, por si alguien le interesa lo mantengo con PyBlosxom-). La página web sigo usándola para información más permanente (aunque tengo compañeros que han dado el salto a blogs o wikis con páginas concretas dedicadas a eso mismo).

Evalué en algún momento manejar la página con un sistema de control de versiones (CVS era lo que se usaba entonces) pero no me decidí. Últimamente estoy re-pensando un poco algunos flujos de trabajo para tener un sistema mejor de copias de seguridad, con control de versiones. Además estoy trabajando bastante con git y he ido añadiendo partes de mi trabajo que están controladas con ese sistema, así que pensé que era el momento de mi página web.

Hice una búsqueda rápida en internet y encontré Using Git to manage a web site. Aunque hay alguna pequeña diferencia, me ha servido como guía.

Lo primero que quería hacer era pasar la copia local de mi ordenador de trabajo (que ya no está encendido tanto tiempo como solía) a otro que actúa como servidor para otras cosas y que siempre suele estar en marcha. Para ello, lo primero es crear un directorio:

ftricas@localServer:~/Documents$ mkdir www && cd www

Después, lo inicializamos como repositorio git y copiamos el contenido de la webdesde donde la teníamos.

ftricas@localServer:~/Documents$ git init
ftricas@localServer:~/Documents$ ssh ftricas@webServer "tar cpf - /home/ftricas/directorioWeb/* " | tar xpf - -C .

Añadimos a git estos ficheros

ftricas@localServer:~/Documents$ git add .
ftricas@localServer:~/Documents$ git commit -am"Primera versión de la web"

En el servidor donde se aloja la web necesitamos crear otro repositorio git:

ftricas@webServer:~/git-backup$ mkdir www.git && cd www.git
ftricas@webServer:~/git-backup$ git init --bare

Ahora en el servidor que vamos a usar como copia local de trabajo, ponemos este como remoto

ftricas@localServer:~/git-backup$ git remote add www ssh://webServer/home/ftricas/git-backup/www.git
ftricas@localServer:~/git-backup$ git push www +master:refs/head/master

En mi caso además hizo falta decirle a git dónde están algunos programas auxiliares de git en el servidor (seguramente esto no es necesario en muchos servidores):

ftricas@localServer:~/Documents$ git config remote.www.receivepack /donde/esta/git-receive-pack
ftricas@localServer:~/Documents$ git config remote.www.uploadpack /donde/esta/git-upload-pack

Y ya podemos sincronizar los repositorios:

ftricas@localServer:~/Documents$ git push www +master:refs/head/master

Este paso era para tener la primera versión, que ya estaba en el servidor en la web. Ahora necesitamos un paso más, para que podamos automatizar un poco la subida de los ficheros cuando hagamos cambios. Para ello utilizamos un hook y la variable GIT_WORK_TREE que permite tener la parte de control en el directorio que hemos creado antes y los ficheros en otro directorio diferente: no me gustaba la idea de tener mezclada la parte del control de versiones con los ficheros de la web y esto soluciona ese problema.

Para esto hacemos en el servidor web:

ftricas@webServer:~/git-backup$ cat > hooks/post-receive
#!/bin/sh
GIT_WORK_TREE=/var/www/miWeb git checkout -f
ftricas@webServer:~/git-backup$ chmod +x hooks/post-receive

O sea, copiamos esas dos líneas en el fichero post-receive y le damos permiso de ejecución. La idea es que este programita se ejecuta cada vez que hacemos una petición push con los ficheros que hayan cambiado.

Si cambiamos algo, habrá que hacer el correspondiente commit, si añadimos ficheros o directorios habrá que utilizar las instrucciones correspondientes add y luego enviarlas al servidor:

ftricas@localServer:~/Documents$ git push www

Con versiones modernas de git puede ser necesario tener en cuenta que puede ser necesario fijar el comportamiento por defecto del push. Yo elegí:

ftricas@localServer:~/Documents$ git config --global push.default simple

Lo explican, por ejemplo, en Warning: push.default is unset; its implicit value is changing in Git 2.0 aunque el propio git nos avisa de lo que podríamos hacer.

A partir de este momento, cada vez que editamos en local la web y ya estamos satisfechos (o simplemente queremos subir algo al servidor web para ver cómo queda9 podemos hacer el commit correspondiente y después el push. La web se irá actualizando, y tendremos las versiones controladas para el caso de que queramos recuperar la evolución de nuestra página web.

Algunos recursos adicionales:

PCI y Europa

Banco Seguimos con las tarjetas. Ya hemos hablado alguna vez del estándar PCI pero no teníamos muchos datos sobre Europa. En Survey: Just 1 in 3 Euro biz slackers meets card security standards se habla de un informe de Verizon sobre el tema y Europa no sale bien parada. Como dicel titular sólo un tercio de los negocios europeos examinados cumplen el 80 por ciento o más de los requisitos de PCI Data Security Standard (DSS).

Se le echa la culpa a las diferentes regulaciones locales y también a las diferencias culturales.

La última vez que hablamos de PCI fue en PCI y desarrollo seguro

Tarjetas, seguridad e incentivos

Monedas En Why the US Doesn’t have Chip-and-PIN Credit Cards Yet nos recordaban que la seguridad no sólo se basa en tecnología o en recursos disponibles, sino que muchas veces se trata de una cuestión relacionada con los incentivos, amenazas, riesgos, costes…

Se habla del caso de la utilización de tarjetas con banda magnética en EEUU en lugar de las más modernas (y seguras) tarjetas con chip.

Y también los usos y costumbres de la gente. El ejemplo es Europa (territorios pequeños, con dificultades para perseguir a los defraudadores cuando cruzan la frontera) vs EEUU (un país grande, con ciudadanos que no salen tanto fuera) y las costumbres (y necesidades) de sus ciudadanos, las características de movimientos y viajes…

Una pata robótica

Esta entrada es más una ‘nota para mi mismo’ (note to self) que algo de valor real. Pero me encuentro con algunos pequeños avances, unas cuantas pestañas abiertas en el navegador y creo que es mejor compartirlo aquí para futura referencia que esperar a una (eventual) finalización de algo más avanzado. Quién sabe si puede servirle a alguien para algo.

En Una cámara móvil ya anticipábamos la posibilidad de hacer algo que se moviera. De hecho, ya se sugería la inspiración en Stubby. Full featured, miniature hexapod. También se puede ver información en Stubby the (Teaching) Hexapod.

Mi único problema con ese diseño eran las habilidades y herramientas necesarias: corte de madera, mecanizado… Estuve dándole vueltas a las alternativas realizables y pensé en tubos de madera. Con la idea de que sólo sería necesario cortarlos a la medida adecuada, perforarlos y montar el armazón adecuado.

También descubrí otros proyectos interesantes como A spider called “Chopsticks” que utilizaba palillos orientales para las patas y Popsicle Stick Hexapod R.I.P. que utiliza palos de helado, lo que iba más en la línea de lo que estaba pensando y me animó bastante. También había visto Build a 12-Servo Hexapod que tiene menos posibilidades pero que también es muy interesante.

Buscando en la red hay un montón de proyectos más, como Hexpider que sigue otro tipo de diseño (y es capaz hasta de escribir) y este otro 6-legged robot project que me han servido para tener algunas ideas sobre movimiento y configuración de las articulaciones (a nivel básico, todavía no he estado pensando demasiado en esa parte).

Con estas ideas me fui a la tienda de bricolaje más cercana a ver qué tenían. Aunque llevaba en la cabeza la idea de los tubos de madera allí encontré un tubo de plástico que me pareció muy adecuado: pensé allí mismo que sería más fácil de cortar y más ligero. También tenían tubos de aluminio que quedarían mucho más impactantes a la vista, pero de momento ese no es el objetivo.

Palo

A photo posted by Fernando Tricas García (@ftricas) on

Como suponía, el tubo de plástico es fácil de trabajar y podemos hacerle un agujero y poner un tornillo para sujetar un servo sin complicarnos mucho la vida, como puede verse en esta foto:

La pata #raspi #servo

A photo posted by Fernando Tricas García (@ftricas) on

La fotografía no es muy buena, pero creo que es suficiente para hacerse una idea de cómo se pueden unir las partes, es lo que más he agradecido ver en los proyectos de otra gente para copiar/inspirarme. Como puede verse, he elegido un diseño con tres servos

También podemos poner bridas de plástico para fijar una articulación con otra, aunque imagino que hará falta una sujección más sólida cuando llegue el momento de que todo esto se mueva. Pero nuevamente parece sencillo hacer rebajes y pegar unas piezas con otras cuando tengamos una idea más clara del proyecto.

Ha sido sorprendente para mi ver lo rápido que he podido llegar a tener esta configuración, ya veremos si después sigo avanzando tan rápido (con el inconveniente de que no tengo suficientes motores, así que hacen falta algunas compras y esas cosas).

Para el movimiento de las articulaciones ya teníamos la experiencia de Añadiendo movimiento: servos , si bien es cierto es que re-escribí casi todo el código siguiendo las ideas de PiCam; al fijar mejor la cámara (que es algo que no conté por aquí), el movimiento suave ya no era tan necesario.

Rápido-lento-rápido #raspi #err #errbot

A video posted by Fernando Tricas García (@ftricas) on

En la parte de los programas, por ahora, he hecho un par de programitas que están en servo.

El primero sirve para mover cada articulación de manera independiente desde la línea de órdenes (para poder establecer los puntos de referencia fácilmente): legOneMove.py.

Tenemos las tres articulaciones en los puertos GPIO correspondientes:

servoGPIO=[17, 23,15]

y utilizamos una función para transformar un ángulo en el pulso necesario para mover el servo:

def angleMap(angle):
    return int((round((1950.0/180.0),0)*angle)/10)*10+550

Y la función que mueve el motor es muy sencilla:

def movePos(art, pos):
    servo = PWM.Servo()
    print art
    servo.set_servo(art, angleMap(pos))
    time.sleep(VEL)

Para mi vergüenza, notar sólo recientemente descubrí la necesidad del temporizador final, porque si no el programa no da tiempo a que el movimiento se complete. Finalmente, en

movePos(servoGPIO[int(sys.argv[1])], int(sys.argv[2]))

Directamente pasamos el primer argumento de la llamada como articulación que hay que mover (que se corresponderá, recordemos, con el GPIO adecuado) y el segundo es el ángulo de movimiento. No lo hagáis así, amiguitos: no os olvidéis nunca añadir en proyectos ‘reales’ los límites y comprobaciones adecuadas para no llevarnos más tarde sorpresas desagradables.

El segundo programa sería legServo.py que no es más que una simulación de lo que podrían ser los movimientos necesarios para que el hipotético robot ande: levantar un poco la pata, moverla hacia adelante, bajar la pata, moverla hacia atrás, … Y así sucesivamente. Seguro que hay que hacer ajustes después pero nos da una cierta idea de que hemos llegado a algún sitio.

A continuación podemos ver un vídeo de estos movimientos repetidos varias veces, que he grabado con ayuda de mi hijo

En movimiento #servo #raspi

A video posted by Fernando Tricas García (@ftricas) on

También podemos ver en el siguiente vídeo algunas pruebas previas, aprovechando el sensacional editor de vídeos de YouTube, con dos articulaciones y con tres:

Los siguientes pasos deberían ser hacer el resto de las patas (como mínimo cuatro, aunque creo que quedará mejor con seis) y ver si será necesario algún hardware adicional (para controlar los 18 motores y, tal vez, algo más las salidas dela Raspberry podrían ser insuficientes) y alguna idea adicional para el ‘cuerpo’ del robot. Seguiremos informando.

Cabeceras de seguridad HTTP que deberías estar usando

Ratón

Es difícil estar al día de todos los cambios que van añadiendo los diferentes sistemas con los que interactúan las aplicaciones (en este caso web). Por eso vienen bien recordatorios como el de 4 HTTP Security headers you should always be using donde se habla justamente de eso, de algunas cabeceras de seguridad que deberíamos añadir:

  • Content-Security-Policy
  • X-Frame-Options
  • X-Content-Type-Options
  • Strict-Transport-Security

Naturalmente, también conscientes de que es posible que el navegador de nuestro usuario no los conozca/use/respete/tenga en cuenta.

Fallos y seguridad

Bicho mirando

En Every Bug Has a Sad, Sad Song un comentario interesante sobre la relación entre bugs (fallos de programación) y fallos de seguridad.

Suele decirse que cuando un programa tiene bugs es posible que estos den lugar a vulnerabilidades, y a problemas de seguridad.

Pero el autor se queja del abuso que se hace de este ‘deslizamiento’ y que los que señalan esos fallos deberían ayudar a los desarrolladores a aprender sobre seguridad y no criticarlos sin más.

Aleatoriedad y juegos

Hablando de sorteos

Ya hemos hablado algunas veces de aleatoriedad desde el punto de vista de la seguridad. En algunos casos, la aleatoriedad necesaria tiene que ver con producir resultados suficientemente diversos, pero en otros casos hay que pensar en más cosas. En “Not So Random Randomness” in Game Design and Programming discuten sobre el tema y cómo puede ser interesante influir en la ‘aleatoriedad’ para tener un juego más interesante.

Habemus tags

Meta

Uno de los problemas que encontré con este alojamiento es que no tiene etiquetas (tags). De hecho, no sólo no las tiene sino que no está previsto que se incluyan fácilmente con la configuración actual porque no hay plugins disponibles Using Jekyll Plugins with GitHub Pages (Wow, un plugin de emojis, y otro de menciones!).

Pongo estas ideas aquí por si alguien me da pistas sobre cómo hacerlo mejor y/o por si alguien más puede aprovecharlas en su sitios.

Puesto que no puedo añadir plugins para las etiquetas y tampoco quiero generar todo el sitio estáticamente (quiero imaginar que es mejor utilizar jekyll en las github pages) pensé utilizar alguno de los plugins que hay para generar sólo las etiquetas. De los que encontré estoy probando jekyll-tagging que ha sido bastante fácil de instalar y configurar, como se explica más abajo. Hay más formas, como jekyll-tags-plugin, y en Tags In Jekyll hay otra explicación. Incluso llegué a pensar en hacerme un programita para generarlo pero me parecía demasiado trabajo tener que ver cómo va el sistema de plantillas y todo eso…

Primero, hago una nueva copia del sitio en local (con git clone): me servirá para generar el sitio con sus etiquetas y todo.

En este sitio sigo las instrucciones de los desarrolladores del plugin README para instalarlo. En particular, instalar la gema, generar el fichero Gemfile, poner el código en el directorio _plugins y modificar el _config.yml.

  • Genero el sitio con jekyll build --watch y en _site lo tengo en estático.
  • Copio al sitio donde mantengo el repositorio local (donde edito, genero y publico los posts) el directorio _site/tags a la raíz (parte estática pages) , lo añado con git add y publico.
  • Ahora tengo el sitio servido por jekyll con las etiquetas en modo estático.

Los problemas de esta forma de trabajar parecen evidentes: necesito dos copias en local del sitio, el flujo de trabajo complicado (aunque se puede automatizar). ¿Las ventajas? Tratar de mantener en la medida de lo posible el funcionamiento en github.io obteniendo la funcionalidad que nos ofrezcan. Veremos si es acertado o será mejor cambiar más adelante pero … ¡Tachán! Tenemos etiquetas.

Próximamente: Entiendo que podremos generar las categorías de una forma parecida (espero que no haga falta una tercera copia). Nunca he recibido muchos comentarios, pero espero poder incluirlos de alguna forma: la gente utiliza sitios como disqus pero fantaseo con algo más cercano a GitHub (¿tal vez a través de las issues? Veo que no soy el primero que lo piensa en GitHub hosted comments for GitHub hosted blogs. La limitación será entonces que para usarlo será necesario estar registrado en GitHub pero … ¿Saben por qué me apunté yo aquí? ¡Justo! Porque alguien me sugirió que lo hiciera (vimblog.vim: publicar en wordpress.com fácilmente).

Seguiremos informando.

Leer código de otros y buenos consejos de programación

Letras en la terminal

Esta entrada casi es una promesa a mi futuro yo porque no he leído el código de Doom ni es algo que prevea que vaya a poder hacer próximamente.

En The Exceptional Beauty of Doom 3’s Source Code hablan justamente de eso, el código de este juego y muestran ejemplos de codificación e ideas que tal vez podrían resultarnos útiles.

Siempre me ha interesado leer guías de estilo de codificación y ese tipo de cosas de diversas empresas y proyectos porque es útil para saber lo que queremos (o no querríamos) hacer con nuestro propio estilo. Sí que leo con cierta frecuencia código de otros en GitHub y en los proyectos de programación de nuestros estudiantes, que de todo el mundo se aprende.

El código de los proyectos de software libre (y las normas/consejos) de los propios proyectos nos pueden servir para leer un buen montón de código que es algo que, me temo, no hacemos con la suficiente frecuencia.

Mostrar la contraseña en el formulario o no

Entrada

Aunque es un tema que trato de traer a la discusión cuando se habla del diseño del proceso de identificación/autentificación con un formulario, veo que sólo enlazamos hace algún tiempo en Algunas ideas para simplificar el proceso de identificación y autentificación a Innovative Techniques To Simplify Sign-Ups and Log-Ins donde se habla de eso y alguna cuestión más.

Se trata de la idea (extendida y aplicada) del enmascaramiento de contraseñas cuando nos estamos autentificando en un sitio. Lo cierto es que puede ser una buena idea, pero para muchos usuarios es una molestia y, seguramente, es mejor darles la oportunidad de decidir si están en un entorno donde la contraseña debería enmascararse o no. De eso habla Luke Wroblewski en Showing Passwords on Log-In Screens continuando con algo que ya anticipó en Mobile Design Details: Hide/Show Passwords y que es un nuevo factor al que deberíamos darle algunas vueltas antes de diseñar nuestro sistema.

Muestra varios ejemplos y aprovecha también para introducir algunas ideas nuevas relativas a la identificación biométrica (con los iPhones, fundamentalmente).

Una buena lectura si te interesan estos temas.

Publicar en Facebook las entradas de este sitio usando Python

Enlaces en Página de Facebook

Ya anticipamos esta entrada hace un par de semanas en Extraer enlaces de una página web. Allí hablábamos de formatear una entrada de este sitio (u otro que proporcione RSS) para publicarla en Facebook (o donde nos parezca, claro). También en Publicar en Twitter las entradas de este sitio usando Python vimos algunas ideas sobre este tema, entonces para Twitter.

En este caso utilizamos el API oficial de Facebook y un paquete no oficial que la implenenta en Python, Facebook Python SDK.

Podemos instalarlo

fernand0@aqui:~$ sudo pip install facebook-sdk

Para su correcto funcionamiento necesita BeautifulSoup y requests y tal vez algunos módulos más. Si no están instalados en nuestro sistema, recibiremos las ‘quejas’ correspondientes.

Para obtener las credenciales tenemos que registrar nuestra aplicación en Facebook My Apps. Hace falta ir al menú avanzado (es más fácil registrar aplicaciones web, la verdad) y se nos asignarán algunos identificadores (fundamentalmente el token OAUTH, que podemos mirar en https://developers.facebook.com/tools/explorer/APPID/?method=GET&path=me%3Ffields%3Did%2Cname&version=v2.2, donde APPID es el que nos hayan asignado), que en nuestro caso almacenamos en ~/.rssFacebook y leeremos desde el programa.

El programa es muy sencillo, se puede descargar en rssToPages.py V.2015-01-26 (enlazo a la versión actual por si en el futuro hago algún cambio).

Como decíamos arriba, empezamos leyendo la configuración relativa a los blogs de los que queremos leer para elegir uno. Si sólo hubiera uno se elegiría directamente:

config = ConfigParser.ConfigParser()

config.read([os.path.expanduser('~/.rssBlogs')])

print "Configured blogs:"

i=1
for section in config.sections():
	print str(i), ')', section, config.get(section, "rssFeed")
	i = i + 1

if (int(i)>1):
	i = raw_input ('Select one: ')
else:
	i = 1

print "You have chosen ", config.get("Blog"+str(i), "rssFeed")

Esta configuración debe contener una sección por blog y para cada uno de ellos contendrá la fuente RSS, el nombre de la cuenta de Twitter y el nombre de la cuenta de Facebook. Para este sitio tendría el siguiente aspecto:

[Blog1]
rssFeed:http://fernand0.github.io/feed.xml
twitterAc:mbpfernand0
pageFB:fernand0.github.io

También puede contener un campo más, linksToAvoid que se usa en el programa de extraer los enlaces para evitar algunos de ellos (lo uso en otro blog para eliminar los enlaces a las categorías).

if (config.has_option("Blog"+str(i), "linksToAvoid")):
	linksToAvoid = config.get("Blog"+str(i), "linksToAvoid")
else:
	linksToAvoid = ""

Leemos la última entrada del blog y extraemos el texto y los enlaces de manera similar a como hacíamos en Extraer enlaces de una página web.

Y para evitar los enlaces que no queríamos a la hora de generar el contenido de la página:

		print linksToAvoid
		print re.escape(linksToAvoid)
		print str(link['href'])
		print re.search(linksToAvoid, link['href'])
		if ((linksToAvoid =="") 
			or (not re.search(linksToAvoid, link['href']))):
			link.append(" ["+str(j)+"]")
			linksTxt = linksTxt + "["+str(j)+"] " + link.contents[0] + "\n"
			linksTxt = linksTxt + "    " + link['href'] + "\n"
			j =  j + 1

Finalmente, buscamos si la entrada contiene alguna imagen. Si no la hay no pondremos nada, pero Facebook lo hará su cuenta (puede ser nuestra foto, un botón, lo primero que haya). Tal vez podríamos configurar una por defecto cuando nuestra entrada no tenga una, si no nos gusta la que sale por defecto (en mi caso es mi foto; como no me gusta verla allí esto me obliga siempre a pensar en una foto para el post):

pageImage = soup.findAll("img")
#  Only the first one
if len(pageImage) > 0:
	imageLink = (pageImage[0]["src"])
else:
	imageLine = ""

Leemos la configuración para Facebook y empezamos a trabajar, solicitando la lista de páginas de las que somos administradores (el nombre de la página en la que queremos publicar lo habremos puesto en ~/.rssBlogs):

config.read([os.path.expanduser('~/.rssFacebook')])
oauth_access_token= config.get("Facebook", "oauth_access_token")

graph = facebook.GraphAPI(oauth_access_token)
pages = graph.get_connections("me", "accounts")

El fichero de configuración tiene este aspecto en este caso:

[Facebook]
oauth_access_token:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Podría haber más cuentas de Facebook, pero no lo he probado así que no garantizo que todo vaya a funcionar correctamente.

De las páginas que gestionamos se elige la que queremos (que se pone en el apartado de configuración del blog, ~/.rssBlogs).

for i in range(len(pages['data'])):
	if (pages['data'][i]['name'] == pageFB):
		print "Writing in... ", pages['data'][i]['name']
		graph2 = facebook.GraphAPI(pages['data'][i]['access_token'])
		graph2.put_object(pages['data'][i]['id'], 
			"feed", message = theSummary, link=theLink, 
			picture = imageLink, 
			name=theTitle, caption='',
			description=theSummary.encode('utf-8'))

statusTxt = "Publicado: "+theTitle+" "+theLink

Ya llevo más de un mes probando con un par de blogs y la solución parece que funciona bastante bien. Lo más molesto fue conseguir las credenciales y dar de alta la aplicación (con un ‘falso’ paso a producción; falso porque no la usa nadie más, al ser de escritorio).

Dudas, comenarios, ideas… ¡Hazme un pull request o un issue!

Técnicas para evitar ataques comunes a la memoria

Vale, no es memoria, pero la analogía me sirve

Un texto interesante en Software defense: mitigating common exploitation techniques sobre diversas técnicas que los sistemas Windows ofrecen para proteger nuestros programas frente a ciertos ataques comunes, en particular relacionadas con la gestión de la memoria y dificultar a un atacante la posibilida de encontrar los datos en lugares predecibles.

De la misma serie también se pueden leer:

Una introducción a la criptografía elíptica

El escondido

La criptografía es de mis temas ‘menos’ favoritos en seguridad. Siempre nos avisan de que es algo difícil de hacer bien. Por lo tanto nos relega al papel de meros consumidores, eso sí, tratando de estar al día en los tamaños de claves, algoritmos criptográficos y esas cuestiones.

En A (relatively easy to understand) primer on elliptic curve cryptography se publicaba hace algunos meses justamente lo que dice el título: una introducción a la criptografía de curvas elípticas que puede servirnos como introducción para recordar/ponernos al día en este tema.

Empiezan hablando de RSA y las propiedades que lo hacen interesante (la factorización es costosa -lenta- y la multiplicación es rápida).

The RSA algorithm is the most popular and best understood public key cryptography system. Its security relies on the fact that factoring is slow and multiplication is fast. What follows is a quick walk-through of what a small RSA system looks like and how it works.

Incluso muestran un pequeño ejemplo:

Let’s make this more concrete with an example. Take the prime numbers 13 and 7. Their product gives us our maximum value of 91. Let’s take our public encryption key to be the number 5. Then using the fact that we know 7 and 13 are the factors of 91 and applying an algorithm called the Extended Euclidean Algorithm, we get that the private key is the number >29.

Y sigue…

Luego, entra más a fondo en la criptografía de curvas elípticas:

An elliptic curve cryptosystem can be defined by picking a prime number as a maximum, a curve equation, and a public point on the curve. A private key is a number priv, and a public key is the public point dotted with itself priv times. Computing the private key from the public key in this kind of cryptosystem is called the elliptic curve discrete logarithm function. This turns out to be the trapdoor function we were looking for.

Interesante.

Atacando a un jugador de póquer

Ordenador

Ya habíamos hablado de ataques dirigidos a personas concretas (por ejemplo: Ataques dirigidos: el caso de Facebook).

En Sharking: High-Rollers in the Crosshairs contaban el caso de un ataque a un jugador profesional de póquer. En su hotel de Barcelona le robaron el portátil y lo infectaron con un troyano que les permitía ver las jugadas cuando se conectaba a sitios de juego en línea. En este caso el ataque dirigido consiste en un robo físico, aprovechando la presencia en un hotel y que el propietario no tomó precauciones al salir de la habitación.

Fundamentos de gestión de cuentas

Defensa

Aunque sólo se trata de una hipotética conversación entre un desarrollador y el experto en seguridad Troy Hunt podemos leer en Introducing the “Secure Account Management Fundamentals” course on Pluralsight un resumen de bastantes de las cuestiones que hay que tener en cuenta a la hora de desarrollar o poner en funcionamiento un sistema de gestión de cuentas para nuestra aplicación web, algunas bastante sutiles.

Avisos, almacenamiento de las contraseñas, recuperación de las mismas, correos de registro, reputación, sesiones, bloqueo ante ataques, cambios,…

En clase solemos decir que parece más fácil de lo que realmente resulta ser al final.

PCI y desarrollo seguro

Donde vive el dinero

Una de las cosas que nos gustó ver cuando nació PCI Data Security Standards fue su atención al desarrollo seguro de programas. En particular el punto 6 y algunos otros inciden en ese tema. En 2013 se anunció la versión 3.0 y este año debería ser la transición de la versión 2.0 que sigue vigente a la nueva.

Nada más salir, en 2013 PCI Standards se comentaban los cambios y novedades del estándar en el punto relativo al desarrollo de programas.

There is plenty of discussion elsewhere about the new standards, so I thought I would focus on the PCI DSS changes in Requirement 6 (Develop and Maintain Secure Systems and Applications):

  • 6.1 & 6.2 Switched the order of requirements 6.1 and 6.2. Requirement 6.1 is now for identifying and risk ranking new vulnerabilities and 6.2 is for patching critical vulnerabilities. Clarified how risk ranking process (6.1) aligns with patching process (6.2) and also clarified that the latter applies to “applicable” patches.
  • 6.3 Added a note to clarify that the requirement for written software development processes applies to all internally- developed software and bespoke software, and now mentions “industry standards” as well as “industry best practice”.
  • 6.3.1 Added “development/test accounts” to “custom accounts” to clarify intent of requirement
  • 6.4 & 6.4.1-6.4.4 Enhanced, more specific, testing procedures to include document reviews for all requirements.
  • 6.4.1 Aligned language between requirement and testing procedures to clarify that separation of production/ development environments is enforced with access controls.
  • 6.5 Updated developer training to include how to avoid common coding vulnerabilities, and to understand how sensitive data is handled in memory.
  • 6.5.x Updated requirements to reflect current and emerging coding vulnerabilities and secure coding guidelines. Updated testing procedures to clarify how the coding techniques address the vulnerabilities.
  • 6.5.10 New requirement for coding practices to protect against broken authentication and session management.
  • 6.6 Increased flexibility by specifying automated technical solution that detects and prevents web-based attacks rather than “web-application firewall.” Added note to clarify that this assessment is not the same as vulnerability scans required at 11.2.

Se puede descargar de la Sección de documentos de la web de PCI.

Extraer enlaces de una página web

Enlaces en Página de Facebook

Hace algunas semanas hablábamos de Publicar en Twitter las entradas de este sitio usando Python y prometíamos hacer lo mismo con Facebook.

Echando un vistazo al API de Facebook y haciendo algunas pruebas me encontré con que no podía publicar enlaces con su texto (Facebook los transforma para que podamos pinchar en ellos, pero no permite -o no encontré la forma- que los pongamos con su texto y esas cosas). Por otro lado, quería experimentar con la posibilidad de publicar las entradas de esta bitácora completas allí; Facebook no favorece que introduzcamos textos largos porque nos muestra un trocito y permite abrir ‘el resto’.

Siempre me ha llamado la atención la ‘netiqueta’ de algunas listas de correo donde suele ponerse al lado del texto de los enlaces un número y al final del mensaje la lista de esos enlaces, cada uno asociado al número correspondiente.

Esto fue lo que decidí hacer para publicar en la página de Facebook de fernand0.github.io (y otras, claro). El programa que traemos hoy hace justamente eso, como paso previo a la publicación en la página de Facebook (y, tal vez, ¿para poder enviar las entradas por correo a los interesados?).

El programa puede verse en rssToLinks.py (apuntamos, como siempre, la versión actual por si hubiera cambios en algún momento).

Algunas formas de extraer los enlaces serían: buscarlos con expresiones regulares, o también con algún parser de HTML (en el Blogómetro hace años utilizábamos el Simple SGML parser. Buscando un poco encontré el proyecto Beautiful Soup que presume de ser una manera rápida de recorrer el contenido de una página web y decidí darle una oportunidad.

Para utilizarlo incluímos los módulos necesarios. Para obtener el contenido utilizamos la fuente RSS, así que también necesitaremos feedparser:

import feedparser
from bs4 import BeautifulSoup
from bs4 import NavigableString
from bs4 import Tag

Leemos la fuente RSS y vamos recorriendo las entradas:

feed = feedparser.parse(url)

for i in range(len(feed.entries)):

Y empieza la ‘magia’ de Beautiful Soup:

        soup = BeautifulSoup(feed.entries[i].summary)
        links = soup("a")

Esto es, le pasamos los datos al analizador, y lanzamos la pregunta de lo que queremos extraer. En este caso tenemos una entrada en el summary y queremos obtener los enlaces (etiqueta a) para la entrada que ocupa la posición i. Nos devolverá una lista de elementos html que incluyen dicha etiqueta.

En algunas entradas ponemos imágenes, que no queremos que aparezcan en el texto, así que utilizamos isinstance para comprobar si dentro del contenido del enlace hay otra etiqueta para evitarla (¿es posible que encontremos algún caso más adelante que sea problemático?). Recorremos la lista de enlaces (que vienen con las etiquetas y todo, claro). Ademas utilizamos el contador j para ir asociándoles números a los sucesivos enlaces (en el HTML original, todavía no lo hemos eliminado):

	j = 0
	linksTxt = ""
	for link in links:
		if not isinstance(link.contents[0], Tag):
			# We want to avoid embdeded tags (mainly <img ... )
			link.append(" ["+str(j)+"]")
			j =  j + 1

El contenido del enlace (ahora que ya sabemos que no es una etiqueta HTML) estará en link.contents[0] (puede haber más contenido, nuestros enlaces suelen ser ‘sencillos’).

	linksTxt = linksTxt + "["+str(j)+"] " + link.contents[0] + "\n"

El enlace está en link['href'].

	linksTxt = linksTxt + "    " + link['href'] + "\n"

Ahora necesitamos el texto del HTML:

	print soup.get_text()

En algunos casos el texto puede tener muchos saltos de línea, espacios, … Se podrían eliminar. Nuestras entradas suelen estar bien estructuradas y no aparece ese problema.

Ahora, si había algún enlace (¿publicaremos alguna vez una entrada sin ningún enlace?), lo añadimos al final:

	if linksTxt != "":
		print
		print "Links :"
		print linksTxt

Números aleatorios seguros en Java

Azar

El tema de los números aleatorios de calidad para aplicaciones con requerimientos de seguridad no aparece habitualmente más que en los comentarios más técnicos. En Proper use of Java’s SecureRandom hay un texto donde se comenta el uso del generador de números seudo aleatorios seguro de Java.

When generating random numbers in Java for cryptographic purposes, many developers often use the java.security.SecureRandom class. And while the java.security.SecureRandom class is designed to generate cryptographically secure random numbers, there are a few subtleties in the API, and if it is used improperly the output can become predictable. At Cigital we have witnessed a number of cases where this is true. The following is a guide to the proper use of Java’s java.security.SecureRandom class.

Los consejos:

  • Always specify the exact PRNG and provider that you wish to use. If you just use the default PRNG, you may end up with different PRNGs on different installations of your application that may need to be called differently in order to work properly. Using the following code to get a PRNG instance is appropriate: SecureRandom sr = SecureRandom.getInstance(“SHA1PRNG”, “SUN”);
  • When using the SHA1PRNG, always call java.security.SecureRandom.nextBytes(byte[]) immediately after creating a new instance of the PRNG. This will force the PRNG to seed itself securely. If for testing purposes, you need predictable output, ignoring this rule and seeding the PRNG with hard-coded/predictable values may be appropriate.
  • Use at least JRE 1.4.1 on Windows and at least JRE 1.4.2 on Solaris and Linux. Earlier versions do not seed the SHA1PRNG securely.
  • Periodically reseed your PRNG as observing a large amount of PRNG output generated using one seed may allow the attacker to determine the seed and thus predict all future outputs.

Esto es, especificar el generador que se va a utilizar explícitamente (para evitar terminar utilizando diferentes generadores en diferentes configuraciones e instalaciones); cuidado con que la incialización se haga de manera correcta (e imprendecible); las versiones recomendadas eran en aquel momento JRE 1.4.1 para Windows y JRE 1.4.2 para Solaris y Linux por lo menos; reinicializar la semilla del PRNG para reducir la utilidad de la información generada.

El otro día hablábamos del Generador de números aleatorios de Intel y allí se pueden encontrar un par de enlaces más sobre el tema.

Una introducción a la autentificación basada en riesgos

Acciones posibles en Facebook

La autentificación parece ser el gran problema de los últimos tiempos: elegimos malas contraseñas, picamos con facilidad en muchos sitios que nos engañan para que las divulguemos ….

Las soluciones tecnológicas existen, y se pueden utilizar: pero en muchas ocasiones estaremos consiguiendo molestar a nuestros usuarios, que reutilicen contraseñas o que hagan todo lo posible para no seguir nuestras directrices (o peor: irse con la competencia).

Por eso me gustó Risk-based Authentication: A Primer donde se introduce la idea de mezclar la autentificación con una estimación del riesgo (que es, por otra parte, lo que creo que están haciendo últimamente muchos sistemas de uso masivo): se asocia a la sesión una ‘puntuación’ que determina si nuestros parámtros son ‘normales’.

Esto es, mira la localización geográfica, datos de conexión, pautas de comportamiento… Se trata, en definitiva, de ver si todo parece razonable o hay algo que no se ajusta a lo habitual y en caso de que haya motivos para desconfiar se toman medidas adicionales:

If the risk score for a user’s access attempt exceeds the system’s risk threshold, authentication controls are automatically elevated, and the user may be required to provide a higher level of authentication, such as a PIN or token. If the risk score is too high, it may be rejected outright.

Coches y ataques

Ya hemos hablado en vidas anteriores de la seguridad y los coches: es el caso típico de una cierta configuración, pensada en un contexto que de pronto (o poco a poco) cambia sin adaptarse a los nuevos riesgos. Esta vez traemos un artículo generalista de divulgación, Car hackers mess with speedos, odometers, alarms and locks.

Control

Por ejemplo, acceso a la red de comunicación interna:

… they gained access to the CAN and began fuzzing against to identitfy which of the arbitration ID packets were sent to particular components of the vehicle such as the speedometre, brakes and dashboard indicators.

Incluso poniendo a disposición de otros una herramienta:

The trio were keen for others to enter the hacking field and have produced a $25 open-modular source hardware tool for reading CANs that has the capability of those worth tens of thousands.

Como decía, hemos hablado más veces de este tipo de ataques a coches:

¿Pueden atacar tu coche?

Más ataques a coches

Seguridad ‘hogareña’

El coche, el mp3 y cosas malas que pueden suceder

Ataques a los sistemas de arranque sin llave en coches

Los sistemas de inmovilización de coches no funcionan bien

Las optimizaciones del compilador y la seguridad

Un compilador no sólo genera código ejecutable a partir de nuestros programas escritos en un lenguaje de alto nivel. Tradicionalmente los compiladores han tratado de mejorar el código desarrollado por los programadores para hacerlo más eficiente (sacando partido de las características de la arquitectura en la que se va a ejecutar, los mecanimos de los procesaores, sus recursos…).

Letras en la terminal

Compilers are great at taking your hand crafted human-readable program, translating it into machine code and, in the process, optimizing it so it runs as efficiently as possible

Los investigadores del MIT Xi Wang, Nickolai Zeldovich, M. Frans Kaashoek y Armando Solar-Lezama han presentado un artículo donde se evalúan las consecuencias de seguridad que puede tener la eliminación de código que puede hacer el compilador por ser considerado innecesario.

… research from MIT points out, in their zeal to optimize your code, compilers can go too far and remove code that they shouldn’t, which can make the system or application more vulnerable.

También han desarrollado una herramienta, que nos avisará del código que es susceptible de tener este tipo de problemas, para que lo podamos arreglar:

The good news is the researchers have developed a model and a static checker for identifying unstable code. Their checker is called STACK, and it currently works for checking C/C++ code. The idea is that it will warn programmers about unstable code in their applications, so they can fix it, rather than have the compiler simply leave it out. They also hope it will encourage compiler writers to rethink how they can optimize code in more secure ways.

En Dude, where’s my code? se pueden ver más ideas y algún ejemplo:

A classic example, explains Xi Wang, a graduate student in EECS and first author on the new paper, is the assumption that if a program attempts to store too large a number at a memory location reserved for an integer, the computer will lop off the bits that don’t fit. “In machines, integers have a limit,” Wang says. “Whenever you exceed that limit, the input value basically wraps around to a smaller value.”

Seasoned C programmers will actually exploit this behavior to verify that program inputs don’t exceed some threshold. Rather than writing a line of code that, say, compares the sum of two numbers to the known threshold for an integer (“if a > int_max - b”), they’ll check to see whether the sum of the numbers is smaller than one of the addends (“if a + b < a”) — whether, that is, the summation causes the integer to wrap around to a smaller value.

Presentación de RSA en Scientific American

En Martin Gardner, RSA y otros pasatiempos matemáticos cuentan una historia sobre la presentación de RSA en la revista Scientific American (traducida como Investigación y Ciencia por aquí). El matemático martin Gardner tenía una columna sobre pasatiempos matemáticos y en agosto de 1977 presentaba los fundamentos de RSA con un reto a los lectores sobre la factorización de números primos, que es una historia que a veces contamos en clase cuando hablamos de la parte algorítmica de estas cosas.

El desafío consistía en factorizar la clave pública en sus dos factores y emplearlos para descifrar el mensaje. El texto llano es una frase inglesa convertida en un número mediante el procedimiento habitual (a=0, b=1…) elevado a 9007 módulo r. Rivest estimaba que usando el mejor algoritmo de factorización conocido y el más rápido de los ordenadores disponibles (del año 77) serían necesario del orden de 40 cuatrillones de años para resolver el reto.

La cosa tiene su gracia porque, al final, el desafío se resolvió 17 años después (utilizando, eso sí) 600 voluntarios con alrededor de 1600 máquinas calculando durante seis meses.

Puede leerse gratis el principio del artículo traducido en Comunicaciones secretas y el artículo original escaneado en A new kind of cipher that would take millions of years to break.

Buena lectura para estos días de navidad.

Consejos para almacenar las claves

En Do any security experts recommend bcrypt for password storage? y, en particular, en la primera respuesta un buen texto sobre el almacenamiento de claves y los algoritmos adecuados para hacerlo. Se discute sobre Bcrypt y PBKDF2 y se comenta sobre alguno más.

Para este tipo de almacenamiento hoy en día hay que tener en cuenta ataques bastante esotéricos con GPU (procesadores gráficos) y FPGA como herramientas de cálculo masivo de manera muy eficiente. Los nuevos algoritmos tienen que tener en cuenta no sólo la velocidad de cálculo, sino también la cantidad de RAM utilizada y otros parámetros.

Se puede completar la lectura con The Theory que es un enlace directo a la primera respuesta de otra pregunta sobre el tema, con un análisis de las necesidades actuales, ventajas en inconvenientes de las principales soluciones…

La conclusión, en este caso es:

Use bcrypt. PBKDF2 is not bad either. If you use scrypt you will be a “slightly early adopter” with the risks that are implied by this expression; but it would be a good move for scientific progress (“crash dummy” is a very honourable profession)

Que es bastante parecida a la del artículo anterior.

Inyección de SQL basada en la evaluación de enteros en expresiones anidadas

En Exploiting Integer Based SQL Injection in Nested SQL Queries una demostración más de que las cosas que pueden ir mal se encuentran en cualuquier parte.

En este caso se trata de una pregunta SQL anidada que evalúa los parmámetros enteros que se le pasan como parámetro. Y también, cuando evaluamos otras cosas que el sistema de gestión de bases de datos sabe evaluar. Es un proceso bastante manual, claro, pero en los casos en los que no se hace validación de los datos puede permitir conocer cosas sobre la base de datos que no debería.

Cuidado con la gestión de nombres

Dar un curso de desarrollo seguro (y de seguridad en general) es bastante ‘agradecido’ desde el punto de vista de encontrar ejemplos, porque la actualidad siempre nos trae sorpresas.

Estábamos hablando en clase sobre los problemas de los nombres y de tomar decisiones sobre ellos y justo aparece el fallo en git: Vulnerability announced: update your Git clients

The vulnerability concerns Git and Git-compatible clients that access Git repositories in a case-insensitive or case-normalizing filesystem. An attacker can craft a malicious Git tree that will cause Git to overwrite its own .git/config file when cloning or checking out a repository, leading to arbitrary command execution in the client machine. Git clients running on OS X (HFS+) or any version of Microsoft Windows (NTFS, FAT) are exploitable through this vulnerability. Linux clients are not affected if they run in a case-sensitive filesystem.

La negrita la he puesto yo.

Se puede leer también el anuncio en la lista de desarrollo de git, [ANNOUNCE] Git v2.2.1 (and updates to older maintenance tracks) y Git 1.8.5.6, 1.9.5, 2.0.5, 2.1.4 and 2.2.1 and thanking friends in Mercurial land.

Si nos interesa ver el código, al menos a una parte, podemos echarle un vistazo a path: add is_ntfs_dotgit() helper, donde hablan de:

On NTFS (and FAT32), there exist so-called “short names” for backwards-compatibility: 8.3 compliant names that refer to the same files as their long names. As “.git” is not an 8.3 compliant name, a short name is generated automatically, typically “git~1”

Y también a: read-cache: optionally disallow HFS+ .git variants donde se ven las invocaciones a la función añadida y alguna cosa más.

Esta entrada se ha publicado orginalmente en Cuidado con la gestión de nombres.

Ataques cada vez más enfocados

En Watering hole: nuevos términos para ¿nuevos? ataques se habla del nombre que se ha empezado a dar a los ataques dirigidos realizados desde sitios web más o menos comunes (‘watering hole’ sería el bebedero a donde acuden los animales a saciar su sed).

fuente

La analogía sería un sitio web frecuentado por un determinado número de personas, entre las que se encuentra el objetivo. Como se trata de un sitio que seguramente visitaría con frecuencia, relajaría las condiciones de acceso y sería menos precavido.

Ya habíamos hablado de Ataques a objetivos concretos y Puedes estar vigilado. También de los ‘bebederos’, en un ataque a Facebook: Ataques dirigidos: el caso de Facebook.

¿En qué confíamos?

En Un compilador que infecta los binarios hablábamos de la confianza y recuperábamos una lectura clásica sobre el tema de en qué podemos confiar y cómo en algún momento cedemos el control.

Se me había pasado la técnica que propuso David A. Wheeler’s Page on Fully Countering Trusting Trust through Diverse Double-Compiling (DDC) - Countering Trojan Horse attacks on Compilers donde habla de cómo se podría mejorar la confianza en los binarios que generemos, mediante doble compilación diversificada, “Diverse Double-Compiling” (DDC). En el resumen:

In the DDC technique, source code is compiled twice: once with a second (trusted) compiler (using the source code of the compiler’s parent), and then the compiler source code is compiled using the result of the first compilation. If the result is bit-for-bit identical with the untrusted executable, then the source code accurately represents the executable.

Hay un vídeo sobre la PhD Public Defense of Fully Countering Trusting Trust through Diverse Double-Compiling

Hay esperanza. Pero … ¿Estamos dispuestos a pagar el precio de la complejidad añadida?

Algunos datos sobre el uso de ssh

En We scanned the Internet for port 22 un estudio sobre el puerto 22 y su utilización.

Yesterday (Sept. 12) we scanned the entire Internet for port 22 – the port reserved for “SSH”, the protocol used by sysadmins to remotely log into machines. Unlike our normal scans of port 80 or 443, this generated a lot more “abuse” complaints, so I thought I’d explain the scan.

De los resultados, se puede ver:

In other words, the top result of 1,730,887 systems on the Internet show an SSH banner of “SSH-2.0-OpenSSH_4.3”. (Note: this is actually only 60% of the Internet, I’ve got corruption in the files for 40% of the results that I need to fix).

También es interesante ver como hay quien se enfada por recibir este tipo de pruebas y quien anima a realizarlas.

Las claves muy largas también pueden ser problemáticas

Una pregunta frecuente cuando alguien empieza a preguntarse por los temas de seguridad es por qué no poner la contraseña, o lo que sea, más grande para estar un poco más seguros. Normalmente eso puede ser un problema porque mayor tamaño implica más necesidades de cálculo, de almacenamiento…

En Too long passwords can DoS some servers se refieren a un fallo en Django, donde no hay una restricción para el tamaño máximo de las claves y que podría poner a algunos servidores en problemas.

Hay más detalles en Security releases issued.

The default password hasher in Django is PBKDF2, which has the virtue of allowing the complexity of computing the hash to be effectively arbitrarily high, by repeated “rounds” of application before producing the final result. This increases the difficulty of attacks which use brute-force methods to compute the hashes of many possible plaintext values, in hopes of discovering which plaintext password corresponds to a given hashed value.

Unfortunately, this complexity can also be used as an attack vector. Django does not impose any maximum on the length of the plaintext password, meaning that an attacker can simply submit arbitrarily large – and guaranteed-to-fail – passwords, forcing a server running Django to perform the resulting expensive hash computation in an attempt to check the password. A password one megabyte in size, for example, will require roughly one minute of computation to check when using the PBKDF2 hasher.

Interesante.

Por cierto que sobre el tema del ‘hashing’ de contraseñas había un resumen interesante en About Secure Password Hashing.

Algunos enlaces interesantes sobre claves

Primero, un artículo periodístico-‘literario’ donde se intenta justificar las malas contraseñas y por qué la gente hace eso. The Secret Life of Passwords

Llaves

Llaves en Instagram

A continuación tres artículos que tienen bastantes puntos en común; discuten sobre algunas justificaciones que se dan de vez en cuando para imponer ciertas normas de seguridad sobre las claves.

Esencialmente se discuten algunas reglas habituales en la gestión de contraseñas que, según los autores, podrían no ser tan interesantes/útiles en muchos casos.

Traemos también un informe del SANS Institute, con información histórica: [PDF] Password Security– Thirty-Five Years Later.

Y, para terminar,

Ya habíamos hablado de contraseñas, en la versión anterior de este sitio por ejemplo en Claves y usabilidad, Sobre claves y control de acceso en sitios web, La autenticación y las aplicaciones y los espectaculares (desde mi punto de vista) artículos enlazados en Contraseñas, usabilidad y uso que están bastante alineados con los que poníamos al principio.

Publicar en Twitter las entradas de este sitio usando Python

No creo que el RSS esté muerto. Pero vemos que mucha gente prefiere recibir información a través de los sitios de redes sociales. Hasta publicaba lo que aparece en mis blogs utilizando servicios como IFTT y dlvr.it. Son bastante cómodos y funcionan muy bien. Sin embargo, uno siempre se pregunta si podría hacerse unos programas a medida que nos permitan gestionar esa parte de la publicación y aprender un poco de paso.

Empecé con la publicación en páginas de Facebook pero todavía no estoy satisfecho del resultado así que hablaremos primero de Twitter: al fin y al cabo sólo tenemos que publicar el título de la entrada y el enlace (y, tal vez, algún texto introductorio).

Encontré el proyecto twitter que ya tiene una parte importante del trabajo realizada. Podemos instalarla con pip:

fernand0@aqui:~$ sudo pip install twitter

Para su correcto funcionamiento necesita BeautifulSoup y tal vez algunos módulos más. Si no están instalados en nuestro sistema, recibiremos las ‘quejas’ correspondientes.

Después podemos ejecutarlo. Nos vendrá bien porque necesitamos autentificarnos en Twitter y el programita que he preparado no se ocupa de esta parte. Hace no tanto se podía leer y escribir tuits simplente con el usuario y la contraseña pero Twitter decidió pasarse a un sistema de autentificación más sofisticado basado en OAuth.

fernand0@aqui:~$ twitter

Cuando hacemos esto se lanza el navegador para que nos autentifiquemos y demos permiso a la aplicación para actuar en nuestro nombre. Esto genera los tokens adecuados de identificación/autenticación, que se almacenan en ~/.twitter_oauth (en un sistema de tipo Unix, se agradecerán comentarios sobre otros sistemas) que podremos reutilizar en nuestro programita.

El programa es muy sencillo, se puede descargar en rssToTwitter.py V.2014-12-07 (enlazo a la versión actual por si en el futuro hago algún cambio).

Empezamos leyendo la configuración:

config = ConfigParser.ConfigParser()

config.read([os.path.expanduser('~/.rssBlogs')])
rssFeed = config.get("Blog1", "rssFeed")
twitterAc = config.get("Blog1", "twitterAc")

Esta configuración debe contener una sección por blog (este programa sólo utiliza la configuración del primero) y para cada uno de ellos contendrá la fuente RSS, el nombre de la cuenta de Twitter y el nombre de la cuenta de Facebook. Para este sitio tendría el siguiente aspecto:

[Blog1]
rssFeed:http://fernand0.github.io/feed.xml
twitterAc:mbpfernand0
pageFB:fernand0.github.io

Este programa no utiliza la página de Facebook, claro. Por otro lado, también hay que leer la configuración para Twitter:

config.read([os.path.expanduser('~/.rssTwitter')])
CONSUMER_KEY = config.get("appKeys", "CONSUMER_KEY")
CONSUMER_SECRET = config.get("appKeys", "CONSUMER_SECRET")
TOKEN_KEY = config.get(twitterAc, "TOKEN_KEY")
TOKEN_SECRET = config.get(twitterAc, "TOKEN_SECRET")

Allí aparecen los datos de la aplicación (los podemos copiar directamente de la que nos hemos instalado; en mi sistema están en /usr/local/lib/python2.7/dist-packages/twitter/cmdline.py y los tokens estarán en el fichero ~/.twitter_oauth

El fichero de configuración tiene este aspecto en este caso:

[appKeys]
CONSUMER_KEY:xxxxxxxxxxxxxxxxxxxxxx
CONSUMER_SECRET:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
[mbpfernand0]
TOKEN_KEY:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
TOKEN_SECRET:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Podría haber más cuentas de Twitter, si se desea. Nótese que el nombre de la segunda sección corresponde con el que se ha utilizado en el fichero de configuración anterior.

A continuación leemos la fuente RSS para extraer los datos que nos interesan:

feed = feedparser.parse(rssFeed)

i = 0 # It will publish the last added item

soup = BeautifulSoup(feed.entries[i].title)
theTitle = soup.get_text()
theLink = feed.entries[i].link

Lo primero de todo, utilizamos feedparser para decargar la fuente RSS y procesarla.

Elegimos la entrada que ocupa la primera posición (la 0), que será la última publicada. Para Twitter seleccionamos el título y el enlace. El título lo procesamos con BeautifulSoup para evitar las posibles etiquetas que pueda contener (de estilo, entidades HTML, …)

Finalmente, construimos el tuit:

statusTxt = "Publicado: "+theTitle+" "+theLink

Nos identificamos, autentificamos y publicamos:

t = Twitter(
	auth=OAuth(TOKEN_KEY, TOKEN_SECRET, CONSUMER_KEY, CONSUMER_SECRET))

t.statuses.update(status=statusTxt)

La abstracción detrás de un programa sencillo

Solemos olvidar (y muchos ni se imaginan) la complejidad que hay detrás de la ejecución de una simple línea de código. En [PDF] A study of code abstraction hacen un recorrido desde una sencilla línea de código en Perl hasta la invocación de los módulos del kernel implicados en la ejecución del trabajo.

Un poco denso en algunos momentos pero vale la pena echarle un vistazo.

Evitar los 10 fallos de diseño más graves para la seguridad

La IEEE lleva unos años fomentando la idea del desarrollo seguro. Una forma ha sido mediante la serie Building Security In (IEEE Security & Privacy, Series Editor: Gary McGraw), bastante relacionada con el podcast de Gary McGraw Silver Bullet.

Más recientemente han lanzado The IEEE Computer Society Center for Secure Design y una de sus primeras publicaciones ha sido Avoiding the Top 10 Security Flaws. Gary McGraw diferencia siempre que puede entre bugs (fallos de seguridad en el código, fundamentalmente) y fallos de diseño (flaws).

En esa línea viene la lista, que ha desarrollado junto con otros autores:

  • Gánala o concédela, pero nunca supongas la confianza.
  • Utiliza mencanismos de autentificación que no puedan ser modificados ni evitados.
  • Autorizar después de autentificar.
  • Separar de manera estricta los datos del control. Nunca procesar instrucciones de control recibidas de fuentes no confiables.
  • Definir una aproximación que asegure que todos los datos se validarán de manera explícita
  • Utilizar correctamente la criptografía.
  • Identificar los datos sensibles y cómo deberían manejarse.
  • Siempre tener en cuenta a los usuarios.
  • Comprender la forma en que cambia nuestra superficie de ataque la integración de componentes externas.
  • Ser flexible cuando se consideren los cambios futuros de objetos y actores.

Algunas frases que señalé:

various binary protection mechanisms can delay the leaking of sensitive material.

Sobre autorización:

Authorization should be conducted as an explicit check, and as necessary even after an initial authentication has been completed. Authorization depends not only on the privileges associated with an authenticated user, but also on the context of the request.

Validación de datos:

Liberal use of precondition checks in the entry points of software modules and components is highly recommended.

Seguro que ustedes encuentran las suyas.

Algunos enlaces que me han resultado útiles para comenzar este sitio

Tengo una mala costumbre cuando estoy instalando/actualizando/configurando cosas: empiezo a abrir pestañas en el navegador que se van acumulando sin mucho orden y que luego nunca termino de eliminar. Ahora que esta bitácora está medio funcionando, voy a poner aquí esos enlaces con dos objetivos: cerrar esas pestañas, y tener recopilada la información para el futuro, o por si le sirve a alguien más.

La primera inspiración vino de Bruce Eckel, en este post: New Programming Blog Site y luego su introducción Using Github Pages for Blogging de donde aprendí las primeras ideas.

La página de GitHub Pages y la explicación sobre cómo albergar un blog en Using Jekyll with Pages.

El artículo de Barry Clark que describe Build A Blog With Jekyll And GitHub Pages y que da algunas pistas y proporciona enlaces a algunos blogs donde buscar inspiración. Por ejemplo, este post Blogging Like a Hacker. El blog del propio Barry Clark, o el How I built my blog in one day de Eric Jones. Me queda pendiente resolver la gestión de categorías y etiquetas, y veo algunas pistas en Tags In Jekyll.

Información técnica sobre las plantillas en Jekyll templates.

No puedo imaginar una bitácora sin RSS. Para añadirlo miré Jekyll RSS Feed Templates. Interesante también la página sobre Plugins en Jekyll. Y sus limitaciones en Using Jekyll Plugins with GitHub Pages.

Finalmente, para integrar mejor el proceso de publicación con el editor (a mi me gusta vim), vim-jekyll.

Cuarta etapa

Repito aquí una historia ya contada unas cuantas veces, a la que le vamos añadiendo matices y novedades.

Copio de Tercera Etapa:

Esta bitácora nació allá por el 2001 en forma de MiBarrapunto: se trataba de un invento que hicieron los creadores de BarraPunto para permitir a los usuarios tener su propia sección con algunas ideas que ya me gustaría ver en alguna plataforma ahora, pero que no cuajaron por problemas de escalabilidad del programa y falta de recursos en aquel momento para mejorarlo (destacable, la promiscuidad absoluta: cualquiera podía tomar una entrada cualquiera del sitio -en particular, de otros usuarios- y reformarla o simplemente republicarla en su propia página).

Parte de esas ideas se han establecido en GitHub, donde el código puede copiarse, transformarse y reenviarse al autor original o a otros con herramientas bastante accesibles.

Con ese espíritu empecé a subir los contenidos de algunos de mis sitios a GitHub: Archivo bitácoras fernando para posteriormente descubrir que GitHub permitía publicar Páginas personales y para los proyectos y el sistema que las gestiona, Jekyll, que también permite gestionar un blog: nuestra página estaría albergada en el sistema con las mismas características de gestión del código fuente de los programas: fork permitido, copiar, pegar, modificar y reutilizar. Todavía no es tan fácil como era en la época de BarraPunto, pero aquí lo tenemos. Y aquí estamos.

No creo que la mayoría de la gente vaya a utilizar esto, y tampoco creo que nadie vaya a reutilizar estos contenidos. Pero siento que encaja bien con mi forma de trabajar y publicar (editar en local, subir al sitio y publicar) así que vamos a probar. Desde este momento, la bitácora anterior queda congelada y seguimos por aquí.

Bienvenidos a la cuarta etapa. Proximamente algo más de información sobre cómo gestionar un sitio aquí e ir resolviendo las carencia que aún tenemos (ya hay RSS, las categorías y las etiquetas no funcionan aún).

Segunda Prueba

Esto es la segunda prueba para ver si el RSS se genera bien.

Prueba

Esto es una prueba de un nuevo intento de Blog, esta vez en GitHub

Una imagen

Eliminado el resumen y el “Read More” en index.html

Complejidad algorítmica y ataques

Esta entrada se publicó originalmente en Complejidad algorítmica y ataques. La traigo aquí para comprobar el funcionamiento con fechas anteriores y para que haga de nexo de unión con el blog anterior. Decíamos:

Leía hace unos días el artículo algorithmic complexity attacks and libc qsort() donde se hace un análisis del Quick Sort, lo que pueden costar algunas de sus implementaciones y fantasea con la posiblidad de utilizarlo para algún tipo de ataque de denegación de servicio (o al menos ralentización).

Son de esas cosas que nos trae el software libre e internet.