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.

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.

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…

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?

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…

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.

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.

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!

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

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