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

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.

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.

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.

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:

• Securosis publicó un informe en noviembre: New Research Paper: Secure Agile Development. Se puede descargar directamente de [PDF] Secure Agile Development.
• An Initiative to Address the Information Security Gap es un portal sobre el tema, aunque no parece tener mucho movimiento.

Además, habíamos hablado de temas relacionados en:

• Desarrollo ágil y algunos problemas que aparecen a veces.
• Desarrollo ágil y seguridad

Al final, hay que acordarse de la seguridad independientemente del modelo de desarrollo seguido.

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

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.

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

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.

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:

• [PDF] BackTalk: The Proof is in the Testing donde el autor nos recuerda la cadena de fallos que llevaron al desastre del Arianne 5.
• [PDF] Fuzz Testing for Software Assurance donde se introduce esta idea para las pruebas: enviar entradas aleatorias para ver si fallan los programas.

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.

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.